What you're describing is a usability problem. For example, HTTP/2 specifies a mandatory-to-implement suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); if the software implementing HTTP/2 followed the RFC, everything would just work. For example, they could refuse to run with invalid configuration, forcing the issue. Or they could simply add the MIT suite to the end of the configuration if not already there.
I don't think anyone likes crossing wires (and imposing TLS requirements from elsewhere), but we do it because there's an upside. Every single HTTP/2 connection uses TLS 1.2+ with AEAD and PFS. Back in the HTTP/1.x world, TLS configuration is still a mess :) On Mon, Oct 23, 2017 at 10:24 PM, Andrei Popov <andrei.po...@microsoft.com> wrote: > > - …however the HTTP/2 approach seems sound overall. > > HTTP/2 RFC violates protocol layering by imposing restrictions on TLS > parameters when the HTTP/2 ALPN ID is negotiated. When an HTTP/2 server is > running on top of a general-purpose TLS stack, the TLS stack has to either > implement HTTP/2-specific logic to restrict TLS parameters, or rely on the > admin to provide compatible HTTP and TLS settings. > > > > In practice, this has proved to be an extremely fragile arrangement: the > admin does not expect HTTP/2 to stop working as a result of > reordering/disabling certain TLS cipher suites. In my experience, a large > number of customers who have run into this problem, solved it by disabling > HTTP/2, rather than reordering TLS cipher suites. > > > > Cheers, > > > > Andrei > > > > *From:* Uta [mailto:uta-boun...@ietf.org] *On Behalf Of *Ivan Ristic > *Sent:* Monday, October 23, 2017 2:10 PM > *To:* uta@ietf.org > *Subject:* [Uta] Establishing minimum TLS requirements for use with STS > > > > At present, STS doesn't impose any restrictions on the quality of TLS > connection. Historically, new RFCs and protocols have been the only > opportunity to enforce better security. For comparison, HTTP/2 introduced a > requirement to use TLS 1.2 and suites with forward security and > authenticated encryption. > > > > I think something similar should be done with MTA-STS. In particular, > forward security strikes me as extremely important, however the HTTP/2 > approach seems sound overall. > > > > -- > > Ivan > -- Ivan
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
