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

Martin,

On Fri, Sep 5, 2014 at 7:09 PM, Michael Sweet <msweet@apple.com> wrote:
> Martin,
>
> I'm arguing based on personal experience with IPP (which unfortunately also sought to make a "clean break" WRT cipher suites and TLS) where the mandatory cipher suite chosen (TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) is no longer required and (based on what I see on the TLS list) is probably getting cut for TLS/1.3.  That choice also made it hard to push for TLS/1.2 support in printers (though we've been successful there) since the TLS/1.0 and cipher suite still needs to be dragged along...
>
> This isn't a process issue, this is a "don't write a spec you'll have to update only because something in TLS has changed" issue. Instead of requiring specific cipher suites or outlawing others, require conformance to the current TLS specification and best practices, including the use (or exclusion) of cipher suites as defined by the TLS or UTA WGs.  Or if you really feel like you need to make a stand, put it in a companion document (that can be updated separately as needed) on HTTP/2 security that the main spec references.
>

FWIW, I agree with what Michael says above.

We have presented interoperability issues and Michael speaks from real
world experience, so there is something tangible to take into account,
and what is being suggested above seems a reasonable compromise.

I could not find any discussion in the mailing lists about what
ciphers to include or exclude, so can you please provide context about
when there was a consensus to choose these particular ciphers ?

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

Received on Friday, 5 September 2014 17:30:26 UTC