Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)
Hiya, This is a "just wondering" type email... On 26/10/2022 23:32, Martin Thomson wrote: harder part: getting people interested in deploying a fix. If ECH+PQ-hybrid turns out to be problematic (size-wise) and PQ-hybrid by itself increases occurrences of HRR, and if ECH is generally desirable, I wonder would people then be more interested in additional guidance as to ClientHello content being placed in HTPPS RRs? Too early to say I'd guess, but maybe worth pondering. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)
On Thu, Oct 27, 2022, at 09:23, Martin Thomson wrote: > On Thu, Oct 27, 2022, at 00:01, Ilari Liusvaara wrote: >> Idea > > We're not short on ideas (your idea is not new). We're short on the > willingness to implement and deploy them. I should apologize here. Ilari's idea is - I think - a relatively good one. However, I don't think that a lack of ideas is the issue here. It might have been Stephen that first mentioned this idea, which got some traction. At the time, and since then, the problem continues - such as it is - without much engagement on what I think is the harder part: getting people interested in deploying a fix. >From my view, HRR is awkward, but it is used enough for me to be confident >that it isn't broken in practice. Proofs of TLS 1.3 also make me confident >that it is secure (with the usual caveats). So it's a case of "ain't broke". ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)
On Thu, Oct 27, 2022, at 00:01, Ilari Liusvaara wrote: > Idea We're not short on ideas (your idea is not new). We're short on the willingness to implement and deploy them. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)
> > OK, that's more than I expected, although I kind of wonder what > combinations are doing this. > It varies a bit over time, but today most were caused by a certain client sending a P-384 keyshare while also announcing support for P-256. On the other hand, most clients today send x25519 key share > by default, which seems to be the weakest supported group in TLS 1.3. I'd say that title goes to ffdhe2048. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)
On Tue, Oct 25, 2022 at 02:57:47PM +1100, Martin Thomson wrote: > > Removing HRR might be possible if we look at putting more stuff in > DNS or something along those lines, but that would require a bunch > of care and preparation. That's effort that - at least to me - > might be better spent elsewhere. Idea: SVCB/HTTP key preferredgroups. Value is one or more group ids encoded as 2 octet big endian and concatenated, in order from most preferred to least preferred. When connecting, the client should scan the list for first group it supports and send a share for that (send no share if no overlap?). Supported_groups still contains full supported group list. ... The problem with this is that in some servers, key share affects group selection. This could lead into downgrade attacks with such servers. On the other hand, most clients today send x25519 key share by default, which seems to be the weakest supported group in TLS 1.3. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
