RE: #612: 9.2.2 and ALPN

Implementations might choose to handle that failure in any of several heuristics, which are outside the scope of the h2 spec.  Another reasonable response might be trying again, offering only !BAD ciphers, for example, now that you know the server supports h2 (and thus, hopefully, the MTI ciphersuite).

From: Greg Wilkins [mailto:gregw@intalio.com]
Sent: Tuesday, November 11, 2014 8:59 PM
To: Mark Nottingham
Cc: HTTP Working Group
Subject: Re: #612: 9.2.2 and ALPN


On 12 November 2014 13:03, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:

-8<-
If the ciphersuite selected for h2 is...
BAD = peer MAY INADEQUATE_SECURITY
!BAD = peer MUST NOT INADEQUATE_SECURITY

Peers probably shouldn't negotiate BAD

where BAD is a fixed in-spec blacklist
->8-

That looks very encouraging.   An in-spec blacklist for BAD ciphers together to the !BAD==MUST NOT INADEQUATE_SECURITY, I think is a good compromise.  It mostly addresses the fragile handshake concern while allowing h1 fallback without additional latency.
I assume that there is an implied:
  BAD = peer MAY fallback to h1 (if able to influence ALPN protocol selection)
and that will not be seen as a downgrade attack (or at least and acceptable one).
cheers




--
Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>>  @  Webtide - an Intalio subsidiary
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.