[TLS] Re: [EXTERNAL] draft-ietf-tls-key-share-prediction next steps

[Bas Westerbaan <[e-mail]>]

Same.

On Tue, Sep 10, 2024 at 11:51 PM Andrei Popov <Andrei.Popov=
[e-mail]> wrote:

> I support staying the course, continuing work on the key share prediction
> draft and allocating the code point.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* David Benjamin <[e-mail]>
> *Sent:* Tuesday, September 10, 2024 2:40 PM
> *To:* <[e-mail]> <[e-mail]>
> *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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>