* …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
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
