Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
Yup, that's right! (Ah yeah, it was confusing to talk about key shares reflecting preferences because we might be talking about the relative order or which were included or omitted. I was thinking the latter since the relative order already comes from supported_groups. I.e. I was thinking of the key_share order as just a syntactic restriction.) On Mon, Nov 6, 2023, 05:55 Eric Rescorla wrote: > Hi David, > > Thanks for posting this and for the discussion on the list. > > Before commenting on this proposal, I'd like to make sure we're all > on the same page about the situation. > > > # Background > > 1. RFC 8446 states that both supported_groups and key_shares >are in client's preference order but doesn't say what it >means for a value to be omitted from key_shares. > >When sent by the client, the "supported_groups" extension indicates >the named groups which the client supports for key exchange, ordered >from most preferred to least preferred. > >... > >client_shares: A list of offered KeyShareEntry values in descending > order of client preference. > > 2. Some clients only send a subset of their supported groups in key >shares, either to save space/computation or because they are >concerned about compatibility. > > 3. Some servers negotiate by picking the most preferred key_share >that is present rather than the most preferred common group in >supported groups. > > > When we combine (2) and (3), the result is that the server may > choose a group which is less preferred by both the client and > server because it is included in the key_shares whereas the > more preferred group is not. > > > # Downgrade > > The draft here talks about there being a downgrade issue. ISTM > that there are two things going on here. > > 1. If the client chooses its key_shares based solely on authenticated > signals, or, as is presently common, consistently for every server, > then the server may choose a suboptimal combination (from the perspective > of group selection, though not from the perspective of latency), but > the attacker cannot influence this selection. > > 2. If the client chooses its key_shares based on unauthenticated > signals, such as DNS or falling back on apparent network error > (e.g., due to apparent intolerance of large CH), then the attacker > can exploit the behavior described in (3) to downgrade the selected > groups. > > > Is this a reasonably accurate summary of the situation? > > -Ekr > > > > > On Tue, Sep 26, 2023 at 9:46 AM David Benjamin > wrote: > >> Hi all, >> >> A while back, we discussed using a DNS hint to predict key shares and >> reduce HelloRetryRequest, but this was dropped due to downgrade issues. In >> thinking through post-quantum KEMs and the various transitions we'll have >> in the future, I realized we actually need to address those downgrade >> issues now. I've published a draft below which is my attempt at resolving >> this. >> >> We don't need a DNS hint for the *current* PQ transition—most TLS >> ecosystems should stick to the one preferred option, and then clients can >> predict that one and move on. However, I think we need to lay the >> groundwork for it now. If today's round of PQ supported groups cannot be >> marked "prediction-safe" (see document for what I mean by that), >> transitioning to the *next* PQ KEM (e.g. if someone someday comes up >> with a smaller one that we're still confident in!) will be extremely >> difficult without introducing downgrades. >> >> Thoughts? >> >> David >> >> -- Forwarded message - >> From: >> Date: Mon, Sep 25, 2023 at 6:56 PM >> Subject: New Version Notification for >> draft-davidben-tls-key-share-prediction-00.txt >> To: David Benjamin >> >> >> A new version of Internet-Draft >> draft-davidben-tls-key-share-prediction-00.txt >> has been successfully submitted by David Benjamin and posted to the >> IETF repository. >> >> Name: draft-davidben-tls-key-share-prediction >> Revision: 00 >> Title:TLS Key Share Prediction >> Date: 2023-09-25 >> Group:Individual Submission >> Pages:11 >> URL: >> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ >> HTML: >> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html >> HTMLized: >> https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction >> >> >> Abstract: >> >>This document clarifies an ambiguity in the TLS 1.3 key share >>selection, to avoid a downgrade when server assumptions do not match >>client behavior. It additionally defines a mechanism for servers to >>communicate key share preferences in DNS. Clients may use this >>information to reduce TLS handshake round-trips. >> >> >> >> The IETF Secretariat >> >> >> ___ >> TLS mailing list >> TLS@ietf.org >>
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
Hi David, Thanks for posting this and for the discussion on the list. Before commenting on this proposal, I'd like to make sure we're all on the same page about the situation. # Background 1. RFC 8446 states that both supported_groups and key_shares are in client's preference order but doesn't say what it means for a value to be omitted from key_shares. When sent by the client, the "supported_groups" extension indicates the named groups which the client supports for key exchange, ordered from most preferred to least preferred. ... client_shares: A list of offered KeyShareEntry values in descending order of client preference. 2. Some clients only send a subset of their supported groups in key shares, either to save space/computation or because they are concerned about compatibility. 3. Some servers negotiate by picking the most preferred key_share that is present rather than the most preferred common group in supported groups. When we combine (2) and (3), the result is that the server may choose a group which is less preferred by both the client and server because it is included in the key_shares whereas the more preferred group is not. # Downgrade The draft here talks about there being a downgrade issue. ISTM that there are two things going on here. 1. If the client chooses its key_shares based solely on authenticated signals, or, as is presently common, consistently for every server, then the server may choose a suboptimal combination (from the perspective of group selection, though not from the perspective of latency), but the attacker cannot influence this selection. 2. If the client chooses its key_shares based on unauthenticated signals, such as DNS or falling back on apparent network error (e.g., due to apparent intolerance of large CH), then the attacker can exploit the behavior described in (3) to downgrade the selected groups. Is this a reasonably accurate summary of the situation? -Ekr On Tue, Sep 26, 2023 at 9:46 AM David Benjamin wrote: > Hi all, > > A while back, we discussed using a DNS hint to predict key shares and > reduce HelloRetryRequest, but this was dropped due to downgrade issues. In > thinking through post-quantum KEMs and the various transitions we'll have > in the future, I realized we actually need to address those downgrade > issues now. I've published a draft below which is my attempt at resolving > this. > > We don't need a DNS hint for the *current* PQ transition—most TLS > ecosystems should stick to the one preferred option, and then clients can > predict that one and move on. However, I think we need to lay the > groundwork for it now. If today's round of PQ supported groups cannot be > marked "prediction-safe" (see document for what I mean by that), > transitioning to the *next* PQ KEM (e.g. if someone someday comes up with > a smaller one that we're still confident in!) will be extremely difficult > without introducing downgrades. > > Thoughts? > > David > > -- Forwarded message - > From: > Date: Mon, Sep 25, 2023 at 6:56 PM > Subject: New Version Notification for > draft-davidben-tls-key-share-prediction-00.txt > To: David Benjamin > > > A new version of Internet-Draft > draft-davidben-tls-key-share-prediction-00.txt > has been successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draft-davidben-tls-key-share-prediction > Revision: 00 > Title:TLS Key Share Prediction > Date: 2023-09-25 > Group:Individual Submission > Pages:11 > URL: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt > Status: > https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ > HTML: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction > > > Abstract: > >This document clarifies an ambiguity in the TLS 1.3 key share >selection, to avoid a downgrade when server assumptions do not match >client behavior. It additionally defines a mechanism for servers to >communicate key share preferences in DNS. Clients may use this >information to reduce TLS handshake round-trips. > > > > The IETF Secretariat > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
I support adoption of this document. On Tue, 26 Sept 2023 at 20:46, David Benjamin wrote: > > Hi all, > > A while back, we discussed using a DNS hint to predict key shares and reduce > HelloRetryRequest, but this was dropped due to downgrade issues. In thinking > through post-quantum KEMs and the various transitions we'll have in the > future, I realized we actually need to address those downgrade issues now. > I've published a draft below which is my attempt at resolving this. > > We don't need a DNS hint for the current PQ transition—most TLS ecosystems > should stick to the one preferred option, and then clients can predict that > one and move on. However, I think we need to lay the groundwork for it now. > If today's round of PQ supported groups cannot be marked "prediction-safe" > (see document for what I mean by that), transitioning to the next PQ KEM > (e.g. if someone someday comes up with a smaller one that we're still > confident in!) will be extremely difficult without introducing downgrades. > > Thoughts? > > David > > -- Forwarded message - > From: > Date: Mon, Sep 25, 2023 at 6:56 PM > Subject: New Version Notification for > draft-davidben-tls-key-share-prediction-00.txt > To: David Benjamin > > > A new version of Internet-Draft draft-davidben-tls-key-share-prediction-00.txt > has been successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draft-davidben-tls-key-share-prediction > Revision: 00 > Title:TLS Key Share Prediction > Date: 2023-09-25 > Group:Individual Submission > Pages:11 > URL: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt > Status: > https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ > HTML: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction > > > Abstract: > >This document clarifies an ambiguity in the TLS 1.3 key share >selection, to avoid a downgrade when server assumptions do not match >client behavior. It additionally defines a mechanism for servers to >communicate key share preferences in DNS. Clients may use this >information to reduce TLS handshake round-trips. > > > > The IETF Secretariat > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Mon, Oct 16, 2023 at 9:18 AM David Benjamin wrote: > I've thus rephrased it in terms of just one group, which I think is much > tidier. How does this look to you? > > https://github.com/davidben/tls-key-share-prediction/commit/310fa7bbddd1fe0c81e3a6865a59880efc901b33 > I agree with the sentiment, but I still see one problem. This text seems really tough to write, so I sympathize. The only remaining problem I see is "Restricting to prediction-safe groups". Maybe "Restricting this selection to..."? I don't have a strong opinion, but I'm pretty sure "Restricting to" is not right. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Fri, Oct 13, 2023 at 1:29 AM Rob Sayre wrote:
> On Wed, Oct 11, 2023 at 8:43 AM David Benjamin
> wrote:
>
>> Tossed onto GitHub and removed the discussion of authenticated records
>> in
>> https://github.com/davidben/tls-key-share-prediction/commit/cabd76f7b320ab4f970f396db3d962ca9f510875
>>
>
> Apologies in advance for this one, but what is the document trying to say
> here?
>
> It says the client "MAY" use the result, Otherwise, it "SHOULD" ignore it?
> It is probably better to get more direct:
>
> "If the resulting prediction is consistent with client preferences, as
> described in {{tls-client-behavior}}, the client MAY use the result to
> predict key shares in the initial ClientHello."
>
> That's probably the way to go, since I think the goal is to avoid obsolete
> negotiations. I think this one works, because the server can always insist
> on an algorithm, and the client can ignore the DNS recommendation. But, a
> flaw of RFC 2119 is that a "SHOULD" ropes in "there may exist valid reasons
> in particular circumstances". So the circumstances would be troubling!
> Use bad encryption due to reasons? It's probably better not to put that
> sentence in.
>
Thanks! I agree that is weird. I went to rewrite it and, as I did, I
realized that text is actually kinda weird in lots of ways. It's written as
if the client might predict multiple named groups, but once we've gotten a
decent signal of what the server supports, I can't imagine why anyone would
bother with multiple. I've thus rephrased it in terms of just one group,
which I think is much tidier. How does this look to you?
https://github.com/davidben/tls-key-share-prediction/commit/310fa7bbddd1fe0c81e3a6865a59880efc901b33
David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Wed, Oct 11, 2023 at 8:43 AM David Benjamin
wrote:
> Tossed onto GitHub and removed the discussion of authenticated records in
> https://github.com/davidben/tls-key-share-prediction/commit/cabd76f7b320ab4f970f396db3d962ca9f510875
>
Apologies in advance for this one, but what is the document trying to say
here?
It says the client "MAY" use the result, Otherwise, it "SHOULD" ignore it?
It is probably better to get more direct:
"If the resulting prediction is consistent with client preferences, as
described in {{tls-client-behavior}}, the client MAY use the result to
predict key shares in the initial ClientHello."
That's probably the way to go, since I think the goal is to avoid obsolete
negotiations. I think this one works, because the server can always insist
on an algorithm, and the client can ignore the DNS recommendation. But, a
flaw of RFC 2119 is that a "SHOULD" ropes in "there may exist valid reasons
in particular circumstances". So the circumstances would be troubling!
Use bad encryption due to reasons? It's probably better not to put that
sentence in.
thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
> But if we can at least make it secure, that gives us a bit more breathing > room in case anyone needs it. > For those who missed it: we need it for Edge -> Origin connections, as some origins do break on split ClientHello. (See e-mail sept 29th.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Tue, Oct 10, 2023 at 1:24 PM Bas Westerbaan wrote: > OK, I see. It's worse than a compatibility risk, though, isn't it? If you >> just let them break in case (a), and then maybe try again with (b), that >> opens up a downgrade attack. Intermediaries can observe the size of the >> Client Hello and make it break >> > > Exactly. > Yup! The draft fixes that downgrade, should any clients take such an (a) + (b) fallback strategy. I would very much prefer not needing such a strategy (so Chrome's current rollout attempt simply does (a)), since such fallbacks have other bad consequences. But if we can at least make it secure, that gives us a bit more breathing room in case anyone needs it. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
> > OK, I see. It's worse than a compatibility risk, though, isn't it? If you > just let them break in case (a), and then maybe try again with (b), that > opens up a downgrade attack. Intermediaries can observe the size of the > Client Hello and make it break > Exactly. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Tue, Oct 10, 2023 at 10:01 AM David Benjamin wrote: > On Tue, Oct 10, 2023 at 12:42 PM Rob Sayre wrote: > >> On Tue, Oct 10, 2023 at 8:28 AM David Benjamin >> wrote: >> >>> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson >> 40dennis-jackson...@dmarc.ietf.org> wrote: >>> To make sure I've understood correctly, we're trying to solve three problems: - Some servers don't tolerate large Client Hellos - Some servers don't implement HelloRetryRequest correctly - Some servers prefer fewer round trips and accept an offered key share even if both client and server would prefer a different group (for which no key share was sent). This is especially troubling if we have to migrate between PQ KEMs since we can't afford multiple key shares in the ClientHello. >>> First and third, yeah. I was mostly focused on the third one, but yeah >>> we'll also need this if the first can't be cleared. (I hope we can just >>> clear through it though. Even if we solve the downgrade problem, >>> compatibility hacks for the large ClientHello will be bad for the ecosystem >>> and very hard to remove later. But if we need it, we need it.) >>> >> >> The impression I got in reading the various PQ experiment reports (and I >> think David Benjamin did some of them...) was that the issues with large >> Client Hellos *will* arise with PQ Client Hello messages. So... if a server >> adds support for PQ, they will have to fix any underlying issues with large >> Client Hello messages as a prerequisite, right? Can we cross the first >> point off the list here? I'm a little confused about that point. >> > > No, issues with large ClientHellos cannot be crossed off so simply. Keep > in mind we cannot update the internet all at once. The client does not have > a priori knowledge that the server implements PQ, but it needs to construct > a ClientHello. It can choose to either: > > a) Send a ClientHello with Kyber in key_shares > b) Send a ClientHello without Kyber in key_shares > > If it picks (a), any *non-Kyber-supporting* servers that break with large > ClientHellos will break. If there are sufficiently few of these, we can > maybe clear through it, but it is a compatibility risk we need to deal > with. But the important thing is that we are precisely concerned with the > non-Kyber servers here. It's not as simple as saying you fix that when you > deploy Kyber. > OK, I see. It's worse than a compatibility risk, though, isn't it? If you just let them break in case (a), and then maybe try again with (b), that opens up a downgrade attack. Intermediaries can observe the size of the Client Hello and make it break. I understand it now, thanks for taking the time to explain. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Tue, Oct 10, 2023 at 12:42 PM Rob Sayre wrote: > On Tue, Oct 10, 2023 at 8:28 AM David Benjamin > wrote: > >> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote: >> >>> To make sure I've understood correctly, we're trying to solve three >>> problems: >>> >>>- Some servers don't tolerate large Client Hellos >>>- Some servers don't implement HelloRetryRequest correctly >>>- Some servers prefer fewer round trips and accept an offered key >>>share even if both client and server would prefer a different group (for >>>which no key share was sent). This is especially troubling if we have to >>>migrate between PQ KEMs since we can't afford multiple key shares in the >>>ClientHello. >>> >>> >> First and third, yeah. I was mostly focused on the third one, but yeah >> we'll also need this if the first can't be cleared. (I hope we can just >> clear through it though. Even if we solve the downgrade problem, >> compatibility hacks for the large ClientHello will be bad for the ecosystem >> and very hard to remove later. But if we need it, we need it.) >> > > The impression I got in reading the various PQ experiment reports (and I > think David Benjamin did some of them...) was that the issues with large > Client Hellos *will* arise with PQ Client Hello messages. So... if a server > adds support for PQ, they will have to fix any underlying issues with large > Client Hello messages as a prerequisite, right? Can we cross the first > point off the list here? I'm a little confused about that point. > No, issues with large ClientHellos cannot be crossed off so simply. Keep in mind we cannot update the internet all at once. The client does not have a priori knowledge that the server implements PQ, but it needs to construct a ClientHello. It can choose to either: a) Send a ClientHello with Kyber in key_shares b) Send a ClientHello without Kyber in key_shares If it picks (a), any *non-Kyber-supporting* servers that break with large ClientHellos will break. If there are sufficiently few of these, we can maybe clear through it, but it is a compatibility risk we need to deal with. But the important thing is that we are precisely concerned with the non-Kyber servers here. It's not as simple as saying you fix that when you deploy Kyber. If it picks (b), non-Kyber-supporting servers behave as before, buggy or not. However, Kyber-supporting servers not only suffer a round-trip but also may not even pick Kyber. For example, if you were to add Kyber to OpenSSL today, it would pick X25519 when presented with (b). See https://github.com/openssl/openssl/issues/22203. BoringSSL will behave correctly, because we anticipated this issue when we first implemented TLS 1.3. I think NSS also knows about group preferences? But clearly the spec wasn't clear enough here. Thus this draft exists to resolve this. *This* server fix *can* be done as servers add Kyber support, but only if we remember to tell them that. Now, I'm hoping we can just make (a) work. Sending (b) also makes the preferred option (Kyber) take a round-trip and more complex schemes like fallbacks have a tendency to overstay their welcome. But different folks will have different risk preferences and deployment strategies, so I think it is worth making sure strategies involving (b) remain viable. And, of course, there's still the third problem. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Tue, Oct 10, 2023 at 8:28 AM David Benjamin wrote: > On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson 40dennis-jackson...@dmarc.ietf.org> wrote: > >> To make sure I've understood correctly, we're trying to solve three >> problems: >> >>- Some servers don't tolerate large Client Hellos >>- Some servers don't implement HelloRetryRequest correctly >>- Some servers prefer fewer round trips and accept an offered key >>share even if both client and server would prefer a different group (for >>which no key share was sent). This is especially troubling if we have to >>migrate between PQ KEMs since we can't afford multiple key shares in the >>ClientHello. >> >> > First and third, yeah. I was mostly focused on the third one, but yeah > we'll also need this if the first can't be cleared. (I hope we can just > clear through it though. Even if we solve the downgrade problem, > compatibility hacks for the large ClientHello will be bad for the ecosystem > and very hard to remove later. But if we need it, we need it.) > The impression I got in reading the various PQ experiment reports (and I think David Benjamin did some of them...) was that the issues with large Client Hellos *will* arise with PQ Client Hello messages. So... if a server adds support for PQ, they will have to fix any underlying issues with large Client Hello messages as a prerequisite, right? Can we cross the first point off the list here? I'm a little confused about that point. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
> If the client is happy with either X25519 alone or X25519Kyber768, why not > send shares for both in the first ClientHello? > This is what Chrome does, and what we do if the user opts for "preferred" mode. [1] Would be good if draft-tls-westerbaan-xyber768d00 either mentions this as a > blessed implementation choice, or conversely disrecommends it and explains > why. > Ah, you mean using the same X25519 key in both the X25519 and Xyber keyshare? We do not use that optimisation, but I do not see anything wrong with it from a protocol perspective. I would not want to encourage it, as it complicates code to generate keyshares as it crosses abstraction layers. Best, Bas [1] The issue is, as I described in my previous e-mail, that a small fraction of origins breaks on a large ClientHello. Whether we send X25519 along with X25519Kyber768 in the CH doesn't make a difference. It does prevent issues with origins that have broken HRR, and do not support Kyber. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Fri, 29 Sept 2023 at 15:45, Bas Westerbaan wrote: > We have been investigating turning on post-quantum key agreement for > connections from Cloudflare to origin servers. In testing, we found that > 0.34% of origins will fail to establish a connection if we send > X25519Kyber768Draft00 keyshare directly (while still advertising support > for classical keyshares.) As expected, a significant portion of failures > seem to be caused by the large ClientHello. Interestingly though, the > majority of these failures don't seem to be specific to the size of the > ClientHello, but are rather caused by the origin not supporting > HelloRetryRequest correctly. We're still digging into it, and will share > our findings later on. > > Anyway, even though it's a small fraction of origins, we cannot send a PQ > keyshare immediately and completely break the websites in front of those > few origins. Instead, we are going [1] for the following approach: we send > a X25519 keyshare, but advertise support for Xyber. > If the client is happy with either X25519 alone or X25519Kyber768, why not send shares for both in the first ClientHello? Yes, that adds more bloat there (but it's already large) but it need not require any additional computation (because the prefix of a X25519Kyber768 share is a valid X25519 share, and the server can only proceed with one). Would be good if draft-tls-westerbaan-xyber768d00 either mentions this as a blessed implementation choice, or conversely disrecommends it and explains why. Thanks, Joe ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
This is a useful and very timely draft — I would like to see it adopted. I'll argue it's more urgent than sketched by David. We have been investigating turning on post-quantum key agreement for connections from Cloudflare to origin servers. In testing, we found that 0.34% of origins will fail to establish a connection if we send X25519Kyber768Draft00 keyshare directly (while still advertising support for classical keyshares.) As expected, a significant portion of failures seem to be caused by the large ClientHello. Interestingly though, the majority of these failures don't seem to be specific to the size of the ClientHello, but are rather caused by the origin not supporting HelloRetryRequest correctly. We're still digging into it, and will share our findings later on. Anyway, even though it's a small fraction of origins, we cannot send a PQ keyshare immediately and completely break the websites in front of those few origins. Instead, we are going [1] for the following approach: we send a X25519 keyshare, but advertise support for Xyber. A server that supports Xyber can then use HelloRetryRequest for a post-quantum connection. Undoubtedly due to GREASE (thanks David), we did not see any issues with this approach. [2] This comes at the cost of an extra roundtrip. To get rid of it, we're scanning key agreement support of origins, and in the future will send Xyber immediately if we see the origin supports it without failing. Now we come to the usefulness of this draft: without it we cannot guarantee that we will negotiate PQ even if both the client and server are configured to prefer it. The problem is that many TLS servers are content with a supported keyshare, and will not HRR even if a more preferred key agreement is available. Indeed: a MitM can break our PQ test connections, which will make us send X25519, while advertising support for Xyber. Despite advertising support for Xyber, many TLS servers will now be content with X25519. Best, Bas [1] https://blog.cloudflare.com/post-quantum-to-origins/ [2] Of course, when a server that can't handle large ClientHello or HRR adds Xyber, it will still need to fix those issues, but importantly they don't block the rest anymore. PS. We have also included some stats on classical key agreement support and preference of origins in [1]. On Tue, Sep 26, 2023 at 6:46 PM David Benjamin wrote: > Hi all, > > A while back, we discussed using a DNS hint to predict key shares and > reduce HelloRetryRequest, but this was dropped due to downgrade issues. In > thinking through post-quantum KEMs and the various transitions we'll have > in the future, I realized we actually need to address those downgrade > issues now. I've published a draft below which is my attempt at resolving > this. > > We don't need a DNS hint for the *current* PQ transition—most TLS > ecosystems should stick to the one preferred option, and then clients can > predict that one and move on. However, I think we need to lay the > groundwork for it now. If today's round of PQ supported groups cannot be > marked "prediction-safe" (see document for what I mean by that), > transitioning to the *next* PQ KEM (e.g. if someone someday comes up with > a smaller one that we're still confident in!) will be extremely difficult > without introducing downgrades. > > Thoughts? > > David > > -- Forwarded message - > From: > Date: Mon, Sep 25, 2023 at 6:56 PM > Subject: New Version Notification for > draft-davidben-tls-key-share-prediction-00.txt > To: David Benjamin > > > A new version of Internet-Draft > draft-davidben-tls-key-share-prediction-00.txt > has been successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draft-davidben-tls-key-share-prediction > Revision: 00 > Title:TLS Key Share Prediction > Date: 2023-09-25 > Group:Individual Submission > Pages:11 > URL: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt > Status: > https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ > HTML: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction > > > Abstract: > >This document clarifies an ambiguity in the TLS 1.3 key share >selection, to avoid a downgrade when server assumptions do not match >client behavior. It additionally defines a mechanism for servers to >communicate key share preferences in DNS. Clients may use this >information to reduce TLS handshake round-trips. > > > > The IETF Secretariat > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
