On Wed, 11 Sept 2024 at 01:40, David Benjamin <david...@chromium.org> wrote: > > 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.) >
Can you detail a little bit more in terms of numbers ? -Did you discover that handshakes are failing because of the larger ClientHello ? -Some web clients aren't auto-updating ? > 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. > We should move forward with the draft. > Thoughts? > > David > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
