Re: #612: 9.2.2 requirements

On Mon, Oct 27, 2014 at 09:39:23PM -0400, Patrick McManus wrote:
> On Mon, Oct 27, 2014 at 4:54 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> > Thoughts?
> 
> 
> poodle is direct evidence that algorithms that are necessary for interop
> simply don't get deprecated in the field even when they are superceded..
> Requiring current best practices at least makes a clean break for h2 which
> doesn't have the interop baggage. Half measures are an un-necessarily weak
> effort.

Unfortunately, H2 does have interop baggage. If it ran on its own port,
instead of sharing one with H1, it didn't, but sharing port means interop
baggage.

Now, if TLS stacks were capable enough, one could do all sorts of things,
but with things the way are now, I don't see anything beyond setting
TLS 1.2 minimum (as is done) as doable.

And to me, POODLE was a painful demonstration that unauthenticated fallbacks
are a bad idea.

Oh, and when TLS 1.3 comes out, there will be more fun about that: SSL 3.0
key exchange is quite bad, and it isn't until TLS 1.3 where they really
fix things. So TLS 1.2 pretty much shares the bad SSL 3.0 key exchange.


As for pushing better algorithms, that would be mostly in H1. I really don't
think that SHA-1 in EE certificates is the most pressing security problem in
H1 over TLS (CA certificates are another matter).


> This is exacerbated by the previous decision to move from NPN to ALPN - a
> client interested in restricting h2 to newer security suites can no longer
> effectively do so as the server is allowed to choose old (perhaps h1
> suitable suites) along with h2. That problem would not be symmetrical for a
> server with NPN wishing to enforce a higher level of security as it still
> selects the cipher suite. Brian provided convincing reasoning previously on
> why a peer would want to do so.

ALPN has some limitations compared to NPN, yes.


-Ilari

Received on Tuesday, 28 October 2014 18:42:00 UTC