TLS ALPN Proposal v5

[David M. Lloyd]

On 09/25/2015 02:11 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> The application protocol implementation chooses only valid cipher suites for
>> the protocol.  Why would it choose one that is not valid, considering that
>> the protocol implementation itself is the only thing that "knows" what is
>> valid or not?
>
> The cipher could fail for the number of reasons it fails in
> trySetCipherSuite(), even if the application has chosen the right
> combination of (application protocol, cipher, whatever else).
> At that point you have to try another application protocol.

 From my reading of that code, it can only fail if you specifically set 
up invalid combinations of cipher suite, protocol, and credentials.  The 
application code should have all the information it needs to set up a 
correct configuration though.

>> This validation should have happened before the JDK ever has a chance to be
>> involved.
>
> See above.
> Unless it is verified that trySetCipherSuite() cannot *ever* fail
> after a cipher has been chosen (but then the method should return
> void), then I don't see how your proposal could work.

The method isn't magical; it is just working off of known inputs.  If 
you give inputs that will ultimately result in a correct negotiation 
(and nothing leads me to believe that there is any reason that the 
application protocol user cannot do this), then you will get a 
successful output.  On the other hand, if (for example) the user selects 
a cipher suite that is incompatible with their credentials, or which is 
incompatible with the protocol which the user *also* selected, I don't 
see any good reason to give them another chance.

In other words, you're assuming that the only way to know if a 
configuration is correct is to try it, but that just isn't true.

> Have you written an implementation already ? That would help.

No.
-- 
- DML