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
