TLS ALPN Proposal v5

[David M. Lloyd]

On 09/25/2015 10:13 AM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 4:48 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine
>> to specify the selected protocol; this would be done during setup before you
>> initiate handshake (which is why you need to explore the Hello packet in the
>> first place).
>
> You also need to add another method to specify the cipher suite that
> goes along with the application protocol.

No you wouldn't, because there already is a method for that: 
setEnabledCipherSuites().  You can only send one protocol back in the 
response, so there's nothing else to do.  Matching suites to protocols 
is the responsibility of the application protocol developer and must be 
done before handshake.

> We have already discussed this approach: it's the "tuple" approach
> where the application is given the list of TLS protocols, the list of
> ciphers, the list of application protocols, the list of aliases and
> decides what is the right tuple, and return that to the JDK.
>
>>> Also, what if the JDK implementation refuses to use the cipher you
>>> chose along with the application protocol, for whatever reason ?
>>
>> Then you'd get an alert, I'd expect.
>
> That would be wrong, because you could actually speak another protocol.

If you could, then the server would have chosen another protocol before 
handshake even begins.

>> But my point is that it's not the
>> JDK's business to introspect the application protocol!  The JDK should only
>> be looking at (TLS) protocol and cipher suite as it does today. It's up to
>> the application protocol to determine if there are unacceptable cipher
>> suites for that protocol.  Any other approach is inherently broken!  What if
>> I add a new application protocol, and some cipher suites are unacceptable
>> for it?  Should I just rely on the JDK for half the time?  Definitely not -
>> the protocol implementation *must* be fully responsible for its own security
>> policy.
>
> I don't understand where you got the impression that the JDK has to
> inspect the application protocol.
>
> We are discussing an API exposed by the JDK to applications, exactly
> because the application decides whether to accept or not the
> combination of application protocol, cipher, etc.

Yes, but doing so by SSLContext is already too late in many cases. 
Trying to make a hook into handshaking is the wrong way of looking at 
this.  The user needs to make decisions *before* handshaking is even 
initiated on the server.

-- 
- DML