Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

[Ilari Liusvaara <[e-mail]>]

On Tue, Jul 26, 2016 at 07:48:05AM +0000, Peter Gutmann wrote:
> Ilari Liusvaara <[e-mail]> writes:
> 
> >I recently (tried to) implement(ed) TLS 1.2 ciphersuite negotiation in a way
> >that always negotiates something if at least one valid configuration exists,
> >and respects TLS 1.2 rules.
> >
> >The resulting code was totally insane, and I am very much not surprised to
> >see buggy implementations. Nor can I say my implementation is not buggy, as
> >testing that mess is just about impossible (and it it will very much do GIGO
> >in order to maximize interop).
> 
> Do you have any more details on some of the issues you ran into?  It'd be good
> to know for anyone else in this situation.
> 
> (I've had to do the same thing, with awkward logic that backs off and retries
> different options if an earlier attempt fails.  This was one of the motivators
> for the Grigg's Law cipher-suite handling in TLS-LTS).

The basic problem (let's ignore non-cert modes for a bit):

When choosing the certificate, you need to consider if you have a
ciphersuite that can use some supported group and protection/prf-hash
available.

Similarly, when choosing a group, you need to consider that you have
a ciphersuite that is consistent in other (possible) choices.

And protection/prf-hash also has to be consistent with other
choices.


The reason these choices couple is because the client can send
pretty much arbitrary combination of oters that depends on each
considered factor.

And the selections have to be consistent: The current leading
hypothesis about this interop issue is that certificate selection
consisers ciphersuite valid candidate when protection selection does
not.


TLS 1.3 negotiation revamp would solve this by ensuring that
whichever you choose first, you don't restrict choice on others
(PSK modes are special here, so need to be chosen first[1]), so
whatever you have chosen so far, there either is next valid
choice, or the whole problem has no solution.


[1] There are some couplings here too, but one only needs to check
group overlap for ke and signature/cert overlap for auth (and these
overlap decisions can be used for normal dhe/cert anyway). And one
does not need to consider interaction of those two.



-Ilari