I also believe this should move forward. > On Sep 10, 2024, at 4:05 PM, Bas Westerbaan > <bas=40cloudflare....@dmarc.ietf.org> wrote: > > Same. > > On Tue, Sep 10, 2024 at 11:51 PM Andrei Popov > <Andrei.Popov=40microsoft....@dmarc.ietf.org> wrote: > 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 > _______________________________________________ > 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
