This sounds like the right approach to me. The point of the MTI is to ensure that the connection succeeds, not that it succeeds as quickly as possible. --Richard
On Wed, Jun 5, 2024 at 2:57 PM Martin Thomson <m...@lowentropy.net> wrote: > I would not mandate the use of an MTI curve, but instead recommend it on > the basis that this is most likely to avoid HelloRetryRequest and so result > in faster handshakes. > > Two reasons: > > 1. MTI doesn't always correspond to "best", particularly as the protocol > ages. > 2. If we have an MTI that is very good (or "best"), then we will not see > many HelloRetryRequest, if at all. I'm particularly concerned that we > already have implementations that cannot send HelloRetryRequest, but this > recommendation would make that worse. > > On Wed, Jun 5, 2024, at 15:07, Eric Rescorla wrote: > > In the long curve popularity thread, there has been some discussion [0] > > of what curves should be included in CH.key_shares and specifically if > > clients should be required to send key shares > > from one or more of the MTI curves [1]. I don't believe the > > specification currently requires this, but it would clearly be a small > > change if we wanted to make it. I've filed the following issue to track > > this suggestion: > > > > https://github.com/tlswg/tls13-spec/issues/1358 > > > > -Ekr > > > > [0] > > https://mailarchive.ietf.org/arch/msg/tls/JeE2watbipk6o0FVJFDa9W6J1A8/ > > [1] As Peter Gutmann notes, right now only P-256 is required so these > > are the same thing, but we might add more MTI curves (e.g., a PQ > > hybrid) in the future. > > _______________________________________________ > > 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
