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

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.


On Sep 5, 2014, at 12:44 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 5 September 2014 08:29, Michael Sweet <msweet@apple.com> wrote:
>> The TLS WG already has a draft outlawing RC4 for TLS/1.2.
> 
> And it hasn't really changed the fact that RC4 is widely used (and
> preferred).  Even with Microsoft penalizing RC4 users now, I don't see
> it disappearing particularly fast.
> 
> The fact is, most of what we are recommending is OLD.  TLS 1.2 itself
> is pretty old now at 6 years.  And it's all widely deployed.  What
> we're forbidding is really old, and lots of it has problems that might
> not mean that you are broken today (though RC4 is close).  And then
> there are structural issues like the absence of PFS and problems with
> the formulation (mac then encrypt).
> 
> What experience has shown is that it is really hard to remove crypto.
> Even bad crypto.  We don't get many opportunities to get a clean break
> and HTTP/2 was identified as that break point.
> 
> You might like to think that we're stepping outside of our scope of
> authority, but it's always been the case that TLS is provided as a
> tool.  Application protocols (and applications) are definitely
> empowered to profile the protocol.  They pretty much all do to some
> extent.
> 
> If you want to argue on process technicality grounds against us doing
> this, that's not going to work.  A big part of why UTA exists is
> because it is an applications area responsibility to determine how TLS
> is best used.  We're going to rely on that work, but we're grown-ups
> too and we have made some decisions for ourselves.  That's exactly how
> this works.
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair