On 24/10/17 15:44, Ilari Liusvaara wrote:
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
If you think RFC7525 is lacking, feel free to propose a -bis version.
I'm not being snarky: things might have changed in the 2 1/2 years since
the document was published (and 4 years since the first private draft),
so it may be a good time for an upgrade.
OTOH, I think it would be silly to try to redo 7525 (and improve on it!)
with a few paragraphs in this document, rather than simply referring to
the BCP.
Thanks,
Yaron
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
