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
Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)
On Tue, Oct 25, 2022 at 3:43 AM Bas Westerbaan wrote: > > 1% of Cloudflare's TLS 1.3 handshakes today used an HRR. > ... > For those reasons I think it's a bit early to consider retiring HRR. > OK, that's more than I expected, although I kind of wonder what combinations are doing this. But, dropping HRR is a bigger change than EKR intended to make anyway, so I guess the group can look again in a few years. thanks, Rob ___ 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 10/25/22 06:30, Rob Sayre wrote: That's ok. I noticed that no one seems to test it very well. That's why I raised the possibility of deletion. I don't think anyone actually uses it, but Stephen's request for data is probably the way to go. Hi, HRR is used as well to the cookie return-routability check, important for DTLSv1.3. In my opinion, this wasn't an happy choice because it obliges the DTLS server to implement lot of logic statelessly in order to understand if the CH is acceptable or not. Marco ___ 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 6:30 AM Rob Sayre wrote: > I don't think anyone actually uses it, > 1% of Cloudflare's TLS 1.3 handshakes today used an HRR. I hope a de facto PQ kex will emerge — the old strategy of just sending multiple keyshares is more expensive with large PQ public keys (~1kB). We probably will need to complicate how the server picks the keyshare [1] By the way, forcing an HRR by not sending any keyshares might be a useful workaround if it turns out large initial ClientHello's are problematic for, say, QUIC load balancers. For those reasons I think it's a bit early to consider retiring HRR. Best, Bas [1] https://mailarchive.ietf.org/arch/msg/tls/pmJMSyf1-PGlLwcgF_jtEYKxQ-g/ ___ 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 Mon, Oct 24, 2022 at 8:58 PM Martin Thomson wrote: > > Removing HRR might be possible... That's ok. I noticed that no one seems to test it very well. That's why I raised the possibility of deletion. I don't think anyone actually uses it, but Stephen's request for data is probably the way to go. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] HRR delenda est (was Re: Published RFC 8446bis -05)
On Tue, Oct 25, 2022, at 13:57, Stephen Farrell wrote: > Is there any public info as to how often HRR happens? > (Sorry if that's well known, but it's not well known to > me:-) > > Were that rare enough, I'd hope it'd be a thing where we > could reach consensus for deprecation. If it's not yet > sufficiently rare, it might be worth considering if we > could change something to make HRR less likely. I don't think that it is that simple. Right now, we're at an equilibrium point, where most clients and servers have moved toward a common set of algorithms for key exchange. In future, I expect that we'll see increased use of HRR as we move to new equilibria. One of these is likely coming with a move to a PQ KEM. 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
