I support staying the course, continuing work on the key share prediction draft and allocating the code point.
Cheers, Andrei From: David Benjamin <david...@chromium.org> Sent: Tuesday, September 10, 2024 2:40 PM To: <tls@ietf.org> <tls@ietf.org> Subject: [EXTERNAL] [TLS] draft-ietf-tls-key-share-prediction next steps Hi all, Now that we're working through the Kyber to ML-KEM transition, TLS 1.3's awkwardness around key share prediction is becoming starkly visible. (It is difficult for clients to efficiently offer both Kyber and ML-KEM, but a hard transition loses PQ coverage for some clients. Kyber was a draft standard, just deployed by early adopters, so while not ideal, I think the hard transition is not the end of the world. ML-KEM is expected to be durable, so a coverage-interrupting transition to FancyNewKEM would be a problem.) We adopted draft-ietf-tls-key-share-prediction in June to address this. There hasn't been a whole lot to do on it since. I've cut a new draft, draft-ietf-tls-key-share-prediction-01, with some very minor changes that were queued up in GitHub. I'd like to sort out next steps and move forward. Beyond that, there are a couple of minor issues in the issue tracker. I don't believe either of these need to block getting a codepoint. https://github.com/tlswg/tls-key-share-prediction/issues/4 - unless folks think otherwise, I plan to just leave this alone and close this https://github.com/tlswg/tls-key-share-prediction/issues/7 - unless folks think otherwise, I plan to just leave this alone and not require the receiver to check Finally, there's the question of downgrade protection: https://github.com/tlswg/tls-key-share-prediction/issues/11 For some background if folks have forgotten, the original key share prediction draft included a ton of complexity to accommodate existing server behavior that would preferentially pick groups out of key_share even if an otherwise more preferred group was in supported_groups. Depending on what the server was trying to do there, this could be perfectly fine (if the server believes the groups are comparable in security) or a downgrade risk (if the server actually believed they were in different security classes---PQ vs classical---but implemented a key_share-first selection algorithm anyway). Pre-adoption, my original draft took the position that it was ambiguous and we cannot safely assume the server knew what it was doing. It designed a scheme to clarify the semantics going forward and use codepoints to ratchet in whether the server implemented the new semantics. https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html After WG discussion, I think we broadly concluded the semantics were actually already present in RFC 8446, and it was not worth the trouble to second-guess the servers here. That led to the much simpler draft, which simply discusses why this is OK in security considerations: https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations As I wrote that text, I unsurprisingly agree with and am fine with this outcome. :-) But there was some chatter about it in the adoption thread (see GitHub link), so I filed the issue so we continued to discuss it. I think perhaps now is the time to discuss it, if we're going to. Do folks want to discuss it? Are there alternate proposals, or should we just stay the course? Unless we have an alternate proposal, I propose we just stay the course and go with [what I understand the conclusion to be from] the previous WG discussion. If there are no further significant changes that folks want to make, I would like to propose we get a codepoint for this and unblock implementation. The earlier this is ready, the more likely that we will be prepared by the time the next KEM transition happens. Thoughts? David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
