Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

I don't have a really strong feeling on whether HTTP should mandate
specific TLS
ciphers, but I'd like to address a few technical points below.


On Thu, Sep 18, 2014 at 4:32 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 19 September 2014 00:03, Patrick McManus <pmcmanus@mozilla.com> wrote:
>
>> This thread is suffering a bit from wall-of-text syndrome for me. Is this
>> the main point below?
>>
>
> Sorry - my bad.   I understand that verbose repetition is not an adequate
> response to perceived insufficient consideration of a concern.  Yet my
> concern remains and it is a very significant one.    I believe that
> deployment of 9.2.2  will hurt h2 adoption, hinder future good cipher
> maintenance and will result in widespread future connection failures.
>
>
>
>> The scenario as I understand it is:...
>> I would say that's an implementation bug in the client.
>>
>
> I would agree with you if 9.2.2 was written in precise language so that
> any two implementations could be reasonable expected to arrive at the same
> result now or into the future.  Currently I can find no definitive list of
> acceptable AEAD modes. Wikipeadia lists : CCM
> <http://en.wikipedia.org/wiki/CCM_mode>, GCM
> <http://en.wikipedia.org/wiki/GCM_mode>, CWC
> <http://en.wikipedia.org/wiki/CWC_mode>, EAX
> <http://en.wikipedia.org/wiki/EAX_mode>, IAPM
> <http://en.wikipedia.org/wiki/IAPM_mode>, and OCB
> <http://en.wikipedia.org/wiki/OCB_mode>, but I don't think wikipeadia is
> a sutiable reference for such things.
>

I don't think this is a real concern: TLS clearly categorizes every
algorithm that is added;
in fact this is a requirement since AEAD records are processed differently.
So the
relevant CipherSuite specification in fact does document whether a cipher
is AEAD
or not. Moreover, implementations need to know this so they can perform the
record
processing correctly. See, for instance:

http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#2597



>    But even if such a list was obtainable and even if we discount the
> possibility of AEAD being superseded in the life of h2,
>

I don't actually think this is that important an issue either. As I
understood the discussion
in Zurich, the new TLS limitations were directed towards pulling users of
HTTP2 towards
modern algorithms. However, algorithms which have serious weaknesses should
probably
be deprecated in all versions of HTTP (as with
https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-00).

Say we decided that in future we preferred Aero (
https://tools.ietf.org/html/draft-mcgrew-aero-01)
to AEAD constructions. That seems like something we could roll out in HTTP3
but wouldn't
be appropriate to retroactively apply to TLS 1.2 unless there was something
seriously wrong
with AEAD (and then see above).


 it is not clear if a h2 implementation is should  enforce this list with
> some form of name matching, or should it delegate the decision to it's TLS
> layer via some isAE() API
>

IMO it should ask the TLS layer about specific properties, not do name
matching.
That seems like a generally good API-use policy.


(and there is no guarantee that such API will exist, specially for
> offloaded TLS).
>

An offloaded TLS stack would presumably have to implement this internally,
since
it has to know whether it's safe to negotiate h2 at all.

-Ekr