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

[David Benjamin <[e-mail]>]

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