TLS ALPN Proposal v7

[David M. Lloyd]

I didn't reply on this last week, but this looks workable to me.  Thanks!

On 10/02/2015 07:19 PM, Bradford Wetmore wrote:
>
>
> On 10/1/2015 7:35 PM, Xuelei Fan wrote:
>> On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
>>> Major changes:
>>>
>>> 1.  ApplicationProtocols is gone.  The H2 black list and comparator were
>>> moved to StandardConstants.
>>>
>>> 2.  StandardConstants.  Strings for "h2" and "http/1.1" are back.  And
>>> now that you are parsing the raw network bytes, I added a convenience
>>> mapping between the two byte ciphersuite IANA-assigned value and the
>>> Java Standard Name.
>>>
>> There is no SSLExplorer in OpenJDK. I think, maybe, the map is not
>> belong to OpenJDK either.
>>
>> I think, the constants for HTTP2 is also belong to application protocol
>> (HTTP2) layer.  Application (HTTP2) implementation would take care of
>> them.  Maybe, they are not a part of JSSE framework either.
>
> Ok, I've removed all of the H2 constants from StandardConstants.  I've
> mentioned to the the H2/network team that this is something they will
> need to handle/include (e.g. Blacklist/Comparator) in their code, and
> they might want to consider APIs similar to what I had.
>
> I personally found it very useful to have a proper mapping to get the
> SSL_ vs. TLS_ prefix correct in the blacklist.
>
>> I would like to have "h2" and "http/1.1" defined as Standard Algorithms
>> Docs as we usually did for other standard constants.
>
> Of course, they will be added as Standard Algorithm names.
>
>>> 3.  SSLParameter (set/get) are moved to SSLSocket/SSLEngine.  Even
>>> though these could go into SSLParameters, this change makes backporting
>>> much easier.  The helper code simply has to reflectively look for the
>>> four methods in the implementation classes, and call if they are there.
>>>
>>> Otherwise, there would have to be reflection both in the user code
>>> (above) and implementation (to see if the passed SSLParameters had the
>>> new methods via a subclass).
>> But, looking forward, per JSSE framework, SSLParameters should be the
>> central place to define SSL/TLS configuration parameters. We'd better
>> follow the conventions so that application developers won't get confused
>> about where SSL/TLS parameters should be configured.
>
> I went back and forth on this many, many times yesterday.
>
>> Maybe, we cannot add public APIs for backporting.
>
> I figured  we'd have to use reflection on user-derived classes to see if
> the methods were there, but apparently implementation-specifc APIs can
> be added in an update release, just not Java APIs. So if we really can
> do that, then we can add a jdk.SSLParameters/
> org.openjdk.jsse.SSLParameters extends SSLParameters, and in the
> implementation, look for instanceof.
>
>> I think backporting is
>> another history, and would better not impact too much of the design for
>> JDK 9 and future releases.
>
> Ok, so get/setApplicationProtocols() is back in SSLParameters.
>
> Thanks for the comments everyone.  I'm submitting the following to the
> CCC (internal review board):
>
>      http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/
>
> Changes:
>
> 1.  No H2 Blacklist/Comparator
>
> 2.  set/getApplicationProtocols() back to SSLParameters.
>
> Thanks,
>
> Brad
>

-- 
- DML