TLS ALPN Proposal v7

[Bradford Wetmore]

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