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

[Jim Manico <[e-mail]>]

I'm thinking about the safely of users....

Today, TLS can support the null cipher or painfully weak ciphers and the user is none the wiser. 

Some indicator of the strength of the current TLS connection or some standard where TLS connections with painfully weak ciphers are not allowed is critical to a secure future.

Aloha,
--
Jim Manico
@Manicode
[phone]

> On Sep 22, 2014, at 12:18 PM, Eric Rescorla <[e-mail]> wrote:
> 
> 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 <[e-mail]> wrote:
>> 
>>> On 19 September 2014 00:03, Patrick McManus <[e-mail]> 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, GCM, CWC, EAX, IAPM, and OCB, 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
>