Re: #612: 9.2.2 and ALPN

On Wed, Nov 12, 2014 at 11:50 AM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 13 November 2014 03:27, Ryan Hamilton <rch@google.com> wrote:
>
>> On Tue, Nov 11, 2014 at 8:58 PM, Greg Wilkins <gregw@intalio.com> wrote:
>>
>>> 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).
>>>
>>
>> Can you explain why this would be desirable? It sure sounds like a
>> downgrade attack path to me.
>>
>
> Well I'm not the advocate for this "feature", just trying to better define
> it.     In the h2-14 draft, the final paragraph of
> 9.2.2 allows for weak ciphers that are unacceptable to h2 to be included
> in the handshake so that h1 servers that do not use h2 or strong ciphers
> can be connected to without additional round trips.        This has been
> the basis of the fragile handshake problem that I have raised as a server
> could never really tell if a cipher was being offered for h2 or not and
> thus was faced with the prospect of INADEQUATE_SECURITY if it tried h2 on
> an unknown cipher.
>
> My understanding of the current proposal is to remove the doubt associated
> with the handshake by providing an in spec black list of ciphers.   So my
> message was to clarify if those black listed ciphers are there so that they
> may be offered in the initial handshake, but only for the purposes of h1
> fallback.
>

Yes.



> So I'm trying to clarify what I server should do if it's TLS layer
> negotiates a cipher on the BAD list.
>

I assume you mean that it negotiates h2 and also negotiates a BAD cipher?
Since
if it's h1, it can just proceed with the handshake and everything should be
fine.



>   The text that Mark proposes says that it MAY send INADEQUATE_SECURITY,
> which means that it may not.   In the case that it does not send it, I'm
> assuming that is for the h1 fallback case and think that needs to be called
> out in the text.
>

Well, it certainly send INADEQUATE_SECURITY, but I think that that
MAY is primarily about the client. The bottom line here is that if a server
selects h2 and a BAD cipher suite, it is exposing itself to undefined
behavior from the client in the form of the client terminating the
connection with INADEQUATE_SECURITY.


I think it is a downgrade attack vector, but what I think this WG is trying
> to say is that it is an acceptable one.  If either peer wants to avoid it,
> they simple need to not offer the bad ciphers.
>

Can you please explain how this downgrade attack works?

-Ekr


cheers
>
>
>
>
> --
> Greg Wilkins <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.
>