Re: Concluding discussion on #612 (9.2.2)

On Thu, Oct 09, 2014 at 10:16:18PM +1100, Greg Wilkins wrote:
> Ilari,
> 
> I'll take your comments out of order:
> 
> 
> On 9 October 2014 21:36, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> wrote:
> 
> >
> > How does this handle version skew (and "surprise" ciphers), both at client
> > and
> > server?
> 
> 
> Both proposals handle surprise ciphers by having a strong handshake that
> will not fail to connect if
> an end point decides that an unknown cipher is h2 acceptable.   If both end
> points decide that
> a new cipher is h2 acceptable then it may be used for h2 - regardless if it
> fits the 9.2.2
> compliance or not.    But most importantly, the strong handshake allows one
> end-point to take that
> step without risking connection failure.
> 
> The entire point of having a robust handshake is to handle the unexpected
> development in ciphers.
> It is the current handshake that is fragile when presented with surprise
> ciphers.
 
What about following case:

1) Client sets priority "NORMAL:-KX-ALL:+PFS:-MAC-ALL:+AEAD" (offer only
   (most of) 9.2.2-compliant ciphers).
2) Client sets mandatory ALPN to ["h2"] (HTTP/2 only).
3) Client connects to server.
4) Server TLS stack picks ALPN "h2" and ciphersuite XYZ (must be 9.2.2-
   compliant because of 1).
5) The HTTP/2 stack has no (or only partial[1]) idea what XYZ is.

Does the server generate INADEQUATE_SECURITY?

If yes, you get interop failure (with client that did nothing wrong).

If no, one potentially lets some[2] non-9.2.2 ciphers through.


> > Disabling any ciphers as response to TLS handshake abort (which is
> > completely unauthenticated[2]!) is a VERY bad idea (the proposal does not
> > say to do it, but neither it says to not do it)[3].
> >
> 
> Neither proposal implies disabling ciphers in response to a handshake abort.
> The first proposal adds ciphers and removes h2 from a retry.  The second
> proposal just removes h2 from a retry.
 
Might be a good idea to explicitly say not to downgrade TLS version or
remove any ciphersuites.


[1] On some TLS stacks, it might be possible to reliably identify e.g.
PFS, NULL or RC4 ciphers, but not stream/block ciphers.

[2] If by nothing else, query for the ciphersuite number or name and run
it against blacklist of bad ciphersuites (if one has names, one can build
a reasonable blacklist with a couple of regex's[3]).

[3] The following should pick most of the stuff:

NULL ciphers:   .*_WITH_NULL_.*
EXPORT ciphers:   .*_EXPORT_WITH_.*
RC4:    .*_WITH_RC4_[0-9]+_.*
CBC (block ciphers):  .*_CBC_[^_]*
RSA key exchange:  TLS_RSA_.*
PSK key exchange:  TLS_PSK_WITH_.*
Non-PFS Diffie-Hellman:  TLS_[^_]*DH_.*

(Note: There are some cipher names that typo DHE_PSK as PSK_DHE)


-Ilari

Received on Friday, 10 October 2014 11:10:00 UTC