On Tue, Oct 24, 2017 at 12:09:07PM +0000, Daniel Margolis wrote: > I think we talked about minimum TLS versions or acceptable cipher suites in > the past and concluded they were more reasonable as a hypothetical v2 > feature. > > I share the fear that this would be an impediment to adoption and lead to > people simply not using STS. Conversely, if we can get v1 out the door and > show meaningful usage and adoption, I think we have a far stronger case to > make that we should also define cipher suites.
I think the comparision of problems to HTTP/2 is very flawed: In this case the client knows _beforehand_ that it has enhanced security requirements. Thus it can just drop ciphersuites that don't meet its requirements. This succeeds with any server that supports adequate security at all, regardless of priority ordering. This is _not_ the case with HTTP/2. With HTTP/2, the client can _not_ drop unsatifactory ciphersuites unless it is prepared for fallback handshake, which most clients are not. As consequence, the handshake goes out with full cipher list, and depending on priority ordering, the server can choose something that makes client puke. And since this is fresh start, the servers can be required to support reasonably modern things. And then the clients can require that or not, depending on implementation. And I think RFC 7525 does not go far enough[1]. [1] Some examples: - No requirement to support AEAD, despite everything else being broken and support being widespread. - No requirement to always support renegotiation_info, even if renegotiation is not supported. -Ilari _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
