8446 currently contains: > However, it is also possible to bind such connections to an external > authentication mechanism via out-of-band validation of the server's > public key, trust on first use, or a mechanism such as channel > bindings (though the channel bindings described in [RFC5929] are not > defined for TLS 1.3).
If I were part of the TLS group I'd want to see discussion of the the parenthetical at the end being replaced with something like: "such as the bindings defined in <future RFC number>". Then the parenthetical could be moved to the security considerations section or similar (right now it's quite hard to find). At the risk of veering into 8446 feedback, I have gotten a lot of push back when I mentioned that the RFC5929 channel bindings weren't defined for TLS 1.3 in the past, normally something along the lines of "that's just one random throw-away sentence in the middle of the document, why should I not implement this?" That being said, I haven't really thought about this and don't know whether this would be appropriate or not, I'm just trying to respond to your query with some initial thoughts. None of this should be taken as what I've been pushing for in the rest of this thread. —Sam On Sun, Oct 3, 2021, at 15:02, Eric Rescorla wrote: > Sorry to be difficult, but as I said, I'd prefer to focus not on the > question of the header of this document but rather on what we wish > 8446 said. To that end, what text do you think should go in 8446-bis? _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
