Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
Thank you all for the detailed responses. I agree that a full review of all implementations is not going to be feasible, but I appreciate the input from the group highlighting the work already done in analysing where updates may be needed. On the DNS hints, I simply meant that it is not going to help with identifying the best common option, but understand that’s not the intended purpose. Thanks also for the interesting insight on of first connections - happy to leave my suggestion of using Section 4.2.7 of RFC8446 in favour of this draft. I felt like we might have a solved problem already here, but interesting to hear the practicalities of deployment make the use of this part of RFC8446 undesirable. I don’t have a strong preference for including this in rfc8446bis – I’d be keen to make sure changes in this draft are highlighted to implementors, but open about whether this is better done as a separate draft or as part of rfc8446bis. Thanks, Michael From: Bob Beck Sent: Friday, October 27, 2023 4:55 PM To: David Benjamin Cc: Michael P1 ; tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt You don't often get email from b...@google.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> On Fri, Oct 27, 2023 at 9:06 AM David Benjamin mailto:david...@chromium.org>> wrote: Responses inline. On Fri, Oct 27, 2023 at 5:04 AM Michael P1 mailto:michael...@ncsc.gov.uk>> wrote: Hi All, Thank you for this interesting draft, I had a couple of quick questions. OpenSSL has been mentioned in this thread, but I was wondering if you had examples of other implementations or services that use the "key_share first" algorithm outlined in Section 3.1 of the draft, so that as this document is taken forward it's both clear what the impact is and what needs to be updated? I have not done a full audit of every TLS implementation to identify which are key-share-first. From the thread, it sounds like rustls also needs to be updated. I imagine there are others. However, "needs to be updated" is a bit subtle. As the draft discusses, a key-share-first algorithm is fine if all your supported groups are equally preferable. In that case, prioritizing performance is reasonable. For instance, if you only implement X25519 and P-256, it's probably fine to just pick based on key shares. So if those implementations only implement a small handful of ECDH curves and have such a policy, there's no immediate problem. LibreSSL also needs an update, while the code is completely different it does use the same mechanism which is basically to just pick the prediction if at all possible to avoid the HRR, considering everything else as equivalently "good enough". In the old world where there really wasn't a practical "downgrade" this was a perfectly reasonable choice to make, so I expect the majority of implementations will need to be modified.. Fortunately it's not a difficult change. The problem is that this condition will obviously fail once we have a mix of postquantum and classical groups. So, at minimum, any such implementation needs to be fixed before deploying PQ. It is also quite questionable if the TLS library documents that some configuration is a preference list (as OpenSSL does), because the library would not actually be implementing a preference list with a key-share-first algorithm. If your library has pluggable groups (as OpenSSL does), this is also questionable as that means the TLS library probably does not actually know that all implemented groups are equally preferable. BoringSSL implements a preference-aware algorithm because we anticipated this. :-) I believe NSS's algorithm is similarly preference-aware. But clearly not everyone realized this when reading RFC 8446, so I think we need to fix the specification text to be clearer. In particular, this should be fixed before postquantum is widely implemented and we have a mess on our hands. Similarly, in Section 3.2 of the draft, can we be explicit about what we mean by "best common option"? As mentioned in the thread, some servers may prefer size/speed, and others security level. This is particularly relevant in the PQ algorithms case, but also applies to current implementations choosing between x25519 and secp384r1, for example. This is precisely why "best" is intentionally vague, and I think needs to stay that way. TLS specs have always left the exact selection policy up to implementation. Rather, we give semantics to the offering party's messages (e.g. we say the client list is its preferences) and leave the selecting party's response up to choice. However, we neglected to give semantics to the client's key_share list, and have ended up in a place where reasonable client and reasonable server behaviors do not mesh quite right. This dr
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
for existing ECDH groups because the > commonly implemented ones are all broadly of the same security level and > size. I don't believe there's been a significant need for clients to play > interesting prediction games. Thus, leaving them prediction-unsafe is just > fine. Indeed, the other half of the draft sets client rules that ensure > prediction-unsafe groups continue to work fine, even with the old server > behavior. > > If so, would a simpler option be to update servers to use the guidance in >> Section 4.2.7 of RFC8446 to use the information in a successful handshake >> to change the groups used in the key_share in subsequent connections? Worst >> case here is that we have a suboptimal choice on first connection which can >> be improved on even when HRR is not an option. >> > No, I don't think that works. > > The worst case scenario you describe is actually quite bad. The > "suboptimal choice" here is to not pick a postquantum option when we should > have. This means this suboptimal traffic is not protected against > store-and-decrypt attacks. > > This would impact more traffic than you may think. All of modern protocol > design (see HTTP/2 and HTTP/3) has been centered on reuse of connections. > This amortizes connection setup costs and gives time for congestion control > algorithms to stabilize. With everyone, correctly, putting all this effort > into reusing connections, your "first connection" actually comprises quite > a lot of traffic. Additionally, any 0-RTT traffic, as well as psk_ke > resumptions (for folks that implement that), in subsequent connections > would depend on that first connection's secret. > > Additionally, the guidance in 4.2.7 requires feeding information from one > connection to another. This, like any other state, is a tracking vector, > so, to protect user privacy, any effects here will be partitioned in both > scope (e.g. the top-level set of a browser) and time (e.g. across users > clearing state). That means that there will be far more "first connections" > than one may think. > > >> As a way forward, would it be worth working on this in rfc8446bis to >> clarify the desired behaviour? An example change would be to Section 2.1 >> which implies preference for key_share first selection. >> > I have no particular feelings about which document takes what text. It is > presented as one document right now because that was the clearest way to > present all the changes together. > > If rfc8446bis is still open for substantive changes (though my impression > was it isn't?), I don't mind putting things in there. Though we'd still > need to expend a lot of text to define prediction-safe and > prediction-unsafe groups, precisely because we do *not* want to define > duplicate groups. > > >> Thanks, >> Michael >> >> >> >> >> >> *From:* Rob Sayre >> *Sent:* Tuesday, October 17, 2023 9:08 PM >> *To:* David Benjamin >> *Cc:* Andrei Popov ; tls@ietf.org >> *Subject:* Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for >> draft-davidben-tls-key-share-prediction-00.txt >> >> >> >> On Tue, Oct 17, 2023 at 12:32 PM David Benjamin >> wrote: >> >> >> >> > Server-side protection against [clients adjusting HRR predictions on >> fallback] is not effective. Especially when we have both servers that >> cannot handle large ClientHello messages and servers that have buggy HRR. >> >> >> >> I think the discussion about buggy HRR is a red herring. >> >> >> >> I agree with almost everything in the email except for this part. It's >> even worse than HRR, isn't it? The initial ClientHello will fail if spread >> across too many packets on some implementations, and then a new ClientHello >> will be sent using X25519 unless you want to lose customers. The client >> won't get an HRR back on the first try, the stuff just breaks (it's their >> bug, but it must be dealt with). But, if the DNS says it should work, it >> should be ok to fail there. The trustworthiness of this hint must also be >> weighed with ECH. So, if you're using SVCB with this idea and ECH, it seems >> pretty reasonable to me. >> >> >> >> thanks, >> >> Rob >> >> >> > ___ > 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] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
This is a good document and should be adopted. I have a mild preference for a separate document because I think it is important to keep this separate from 8446 because it would require less work (at least in the doc review aspect) for programmers to fix, and I am worried that it would “get lost” in 8446bis. I think the rationale around why this is important for PQ should have more, scary, words. But that can be fixed during WG time. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
ot; here is to not pick a postquantum option when we should have. This means this suboptimal traffic is not protected against store-and-decrypt attacks. This would impact more traffic than you may think. All of modern protocol design (see HTTP/2 and HTTP/3) has been centered on reuse of connections. This amortizes connection setup costs and gives time for congestion control algorithms to stabilize. With everyone, correctly, putting all this effort into reusing connections, your "first connection" actually comprises quite a lot of traffic. Additionally, any 0-RTT traffic, as well as psk_ke resumptions (for folks that implement that), in subsequent connections would depend on that first connection's secret. Additionally, the guidance in 4.2.7 requires feeding information from one connection to another. This, like any other state, is a tracking vector, so, to protect user privacy, any effects here will be partitioned in both scope (e.g. the top-level set of a browser) and time (e.g. across users clearing state). That means that there will be far more "first connections" than one may think. > As a way forward, would it be worth working on this in rfc8446bis to > clarify the desired behaviour? An example change would be to Section 2.1 > which implies preference for key_share first selection. > I have no particular feelings about which document takes what text. It is presented as one document right now because that was the clearest way to present all the changes together. If rfc8446bis is still open for substantive changes (though my impression was it isn't?), I don't mind putting things in there. Though we'd still need to expend a lot of text to define prediction-safe and prediction-unsafe groups, precisely because we do *not* want to define duplicate groups. > Thanks, > Michael > > > > > > *From:* Rob Sayre > *Sent:* Tuesday, October 17, 2023 9:08 PM > *To:* David Benjamin > *Cc:* Andrei Popov ; tls@ietf.org > *Subject:* Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for > draft-davidben-tls-key-share-prediction-00.txt > > > > On Tue, Oct 17, 2023 at 12:32 PM David Benjamin > wrote: > > > > > Server-side protection against [clients adjusting HRR predictions on > fallback] is not effective. Especially when we have both servers that > cannot handle large ClientHello messages and servers that have buggy HRR. > > > > I think the discussion about buggy HRR is a red herring. > > > > I agree with almost everything in the email except for this part. It's > even worse than HRR, isn't it? The initial ClientHello will fail if spread > across too many packets on some implementations, and then a new ClientHello > will be sent using X25519 unless you want to lose customers. The client > won't get an HRR back on the first try, the stuff just breaks (it's their > bug, but it must be dealt with). But, if the DNS says it should work, it > should be ok to fail there. The trustworthiness of this hint must also be > weighed with ECH. So, if you're using SVCB with this idea and ECH, it seems > pretty reasonable to me. > > > > thanks, > > Rob > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
It's OK, just appeared on the admin page. The Uni email can be pretty messed up sometimes so whenever things seem to take too long I check that they're actually still working. All fine, as you were :-). Peter. From: TLS on behalf of Michael P1 Sent: Friday, 27 October 2023 22:04 To: Rob Sayre; David Benjamin Cc: tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt Hi All, Thank you for this interesting draft, I had a couple of quick questions. OpenSSL has been mentioned in this thread, but I was wondering if you had examples of other implementations or services that use the "key_share first" algorithm outlined in Section 3.1 of the draft, so that as this document is taken forward it's both clear what the impact is and what needs to be updated? Similarly, in Section 3.2 of the draft, can we be explicit about what we mean by "best common option"? As mentioned in the thread, some servers may prefer size/speed, and others security level. This is particularly relevant in the PQ algorithms case, but also applies to current implementations choosing between x25519 and secp384r1, for example. DNS hints may not help decide which is best as we explicitly are not using key_shares. Just to clarify, is the purpose of this draft to use new, duplicate groups for TLS to indicate that the server adheres to this draft? If so, would a simpler option be to update servers to use the guidance in Section 4.2.7 of RFC8446 to use the information in a successful handshake to change the groups used in the key_share in subsequent connections? Worst case here is that we have a suboptimal choice on first connection which can be improved on even when HRR is not an option. As a way forward, would it be worth working on this in rfc8446bis to clarify the desired behaviour? An example change would be to Section 2.1 which implies preference for key_share first selection. Thanks, Michael From: Rob Sayre Sent: Tuesday, October 17, 2023 9:08 PM To: David Benjamin Cc: Andrei Popov ; tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt On Tue, Oct 17, 2023 at 12:32 PM David Benjamin mailto:david...@chromium.org>> wrote: > Server-side protection against [clients adjusting HRR predictions on > fallback] is not effective. Especially when we have both servers that cannot > handle large ClientHello messages and servers that have buggy HRR. I think the discussion about buggy HRR is a red herring. I agree with almost everything in the email except for this part. It's even worse than HRR, isn't it? The initial ClientHello will fail if spread across too many packets on some implementations, and then a new ClientHello will be sent using X25519 unless you want to lose customers. The client won't get an HRR back on the first try, the stuff just breaks (it's their bug, but it must be dealt with). But, if the DNS says it should work, it should be ok to fail there. The trustworthiness of this hint must also be weighed with ECH. So, if you're using SVCB with this idea and ECH, it seems pretty reasonable to me. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
Hi All, Thank you for this interesting draft, I had a couple of quick questions. OpenSSL has been mentioned in this thread, but I was wondering if you had examples of other implementations or services that use the "key_share first" algorithm outlined in Section 3.1 of the draft, so that as this document is taken forward it's both clear what the impact is and what needs to be updated? Similarly, in Section 3.2 of the draft, can we be explicit about what we mean by "best common option"? As mentioned in the thread, some servers may prefer size/speed, and others security level. This is particularly relevant in the PQ algorithms case, but also applies to current implementations choosing between x25519 and secp384r1, for example. DNS hints may not help decide which is best as we explicitly are not using key_shares. Just to clarify, is the purpose of this draft to use new, duplicate groups for TLS to indicate that the server adheres to this draft? If so, would a simpler option be to update servers to use the guidance in Section 4.2.7 of RFC8446 to use the information in a successful handshake to change the groups used in the key_share in subsequent connections? Worst case here is that we have a suboptimal choice on first connection which can be improved on even when HRR is not an option. As a way forward, would it be worth working on this in rfc8446bis to clarify the desired behaviour? An example change would be to Section 2.1 which implies preference for key_share first selection. Thanks, Michael From: Rob Sayre Sent: Tuesday, October 17, 2023 9:08 PM To: David Benjamin Cc: Andrei Popov ; tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt On Tue, Oct 17, 2023 at 12:32 PM David Benjamin mailto:david...@chromium.org>> wrote: > Server-side protection against [clients adjusting HRR predictions on > fallback] is not effective. Especially when we have both servers that cannot > handle large ClientHello messages and servers that have buggy HRR. I think the discussion about buggy HRR is a red herring. I agree with almost everything in the email except for this part. It's even worse than HRR, isn't it? The initial ClientHello will fail if spread across too many packets on some implementations, and then a new ClientHello will be sent using X25519 unless you want to lose customers. The client won't get an HRR back on the first try, the stuff just breaks (it's their bug, but it must be dealt with). But, if the DNS says it should work, it should be ok to fail there. The trustworthiness of this hint must also be weighed with ECH. So, if you're using SVCB with this idea and ECH, it seems pretty reasonable to me. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Tue, Oct 17, 2023 at 12:32 PM David Benjamin wrote: > > > Server-side protection against [clients adjusting HRR predictions on > fallback] is not effective. Especially when we have both servers that > cannot handle large ClientHello messages and servers that have buggy HRR. > > I think the discussion about buggy HRR is a red herring. > I agree with almost everything in the email except for this part. It's even worse than HRR, isn't it? The initial ClientHello will fail if spread across too many packets on some implementations, and then a new ClientHello will be sent using X25519 unless you want to lose customers. The client won't get an HRR back on the first try, the stuff just breaks (it's their bug, but it must be dealt with). But, if the DNS says it should work, it should be ok to fail there. The trustworthiness of this hint must also be weighed with ECH. So, if you're using SVCB with this idea and ECH, it seems pretty reasonable to me. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
Answering a few questions that have come up thus far:
> Downgrade by attacker is only possible if the client attempts insecure
fallback (e.g., offer PQ key share, connection failed, retry without PQ key
share)?
> Or am I missing some other possible downgrade attack?
A fallback is certainly one possible downgrade trigger, but there are
others in the section 3.1 subsections. First, suppose we decide to do a DNS
hint, as the document suggests. DNS is broadly unauthenticated, so an
attacker could easily claim the server prefers a weaker algorithm than it
actually does. (As for why we might want a DNS hint, PQ's large key sizes
means clients will be far less willing to just predict multiple PQ KEMs
just in case. But, as much as we need to cut down on unnecessary options in
the PQ space, I don't think we can bank on never wanting to transition
between PQ KEMs ever. If AwesomeNewKEM comes along that's half the size,
that's definitely worth a transition.)
You could also have a non-attacker-triggered downgrade. Suppose we're
picking between PQ1, PQ2, and X25519. If I predict {PQ1, X25519} on grounds
that PQ1 is more likely than PQ2, and X25519 is free, a server that
supports {PQ2, X25519} and implements a key-share-first selection algorithm
will pick the wrong one.
(Also, to clarify, I very much do not want to implement a fallback for
Chrome and we don't currently plan to. So far we're running doing our
initial Kyber rollout without one. We've run into some compatibility
issues, but have been able to clear them so far. But Bas has described
Cloudflare needing some workaround here. I think, independent of this
fallback possibility, there are enough other forward-looking needs to
justify doing something here. But securing this option is a nice bonus. If
you believe the initial list is largely a prediction, it's intuitive that
this would be safe to do, yet it currently isn't.)
> Servers accepting other than the server’s top-priority group in order to
avoid HRR aren’t necessarily doing this because they honor client
preferences or assume that key_share reflects client preferences.
> They may simply find several groups acceptable and consider RTT reduction
more important than the strength difference between certain groups. I’m not
convinced that this is necessarily wrong, generally.
Yeah, if the server considers all groups equally acceptable, then yeah
that's perfectly okay. And indeed if the server is key-share-first but
believes all currently-implemented groups are equally preferable, that's
fine. I tried to capture that with this paragraph here, but it's certainly
possible I've phrased it badly! (In discussing this space with others at
Google, I found it surprisingly difficult to characterize the issue in a
way that people could understand.)
https://davidben.github.io/tls-key-share-prediction/draft-davidben-tls-key-share-prediction.html#section-3.2-2
The thing that's I think *not* okay is if it implements a key-share-first
selection algorithm *without* affirmatively preferring the RTT reduction
over the strength difference. E.g. OpenSSL has gotten very excited about
pluggable cryptography (so it cannot possibly know all possible named
groups are equally acceptable), explicitly documents that the relevant
configuration on the server is a preference list, and still implements a
key-share-first selection algorithm. That is clearly unreasonable, yet RFC
8446 does not make that clear. This draft is ultimately trying to clarify
that, and draw bounds on future hinting schemes (e.g. DNS) to account for
the past lack of clarify.
> Server-side protection against [clients adjusting HRR predictions on
fallback] is not effective. Especially when we have both servers that
cannot handle large ClientHello messages and servers that have buggy HRR.
I think the discussion about buggy HRR is a red herring. Cloudflare could
easily have avoided that by simply sending key_share={Kyber, X25519}, not
key_share={Kyber}. This issue has nothing to do with that. It's about
key_share={X25519}; supported_groups={Kyber, X25519}. If the client sends
that, the server picks X25519, and all parties agree Kyber is in a
different strength class from X25519, whether the server was wrong for not
honoring its preference, or whether the client was wrong for predicting an
option that wasn't its most preferred.
If we believe that key_share is a prediction, not a preference, then we
should believe that the server is in the wrong here. We should then also
believe that this fallback is actually secure, whether it's desirable or
not. (Like I said, I don't think it's desirable, and I hope we can stick to
that. I'm more concerned with the other desirable scenarios where this
matters.)
> If this is the concern, would it be better to just say that TLS clients
SHOULD NOT/MUST NOT implement insecure fallbacks to weaker TLS parameters?
See above. This isn't *the* concern, or even the primary one. It's, IMO,
just an added bonus. I'm much more concerned about
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Mon, Oct 16, 2023 at 5:52 PM Andrei Popov wrote: > >- But how are you going to detect whether there's a crappy TCP/IP >stack or an attack? You can't. > > Understood. This is a general problem with insecure client-side fallbacks. > Sure, but I think the aim is to say that the server does support Kyber (or something else as large), because there will be a period where the reason for a failure will be unclear. So, do you see how the DNS signal works around that? I think the idea is that if the DNS record says the server supports Kyber (or whatever), the client might not want to allow X25519. There's just going to be a lot of broken stuff for a while, even if the actual server does support a PQ algorithm. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
* But how are you going to detect whether there's a crappy TCP/IP stack or an attack? You can't. Understood. This is a general problem with insecure client-side fallbacks. It is unclear what this draft is trying to achieve: * Is this draft paving the way for TLS clients to advertise PQC groups without sending the corresponding key shares? This is available today, and yes servers may or may not HRR in this situation. Server’s decision, depends on a variety of factors. Servers that really care about PQC (or some other distinction between supported groups) will HRR. If this is the problem we’re trying to address, could this just be a security consideration in the PQC drafts? * Is this draft anticipating a new wave of TLS clients performing insecure fallbacks? Server-side protection against this is not effective. Especially when we have both servers that cannot handle large ClientHello messages and servers that have buggy HRR. If this is the concern, would it be better to just say that TLS clients SHOULD NOT/MUST NOT implement insecure fallbacks to weaker TLS parameters? Cheers, Andrei From: Rob Sayre Sent: Monday, October 16, 2023 4:36 PM To: Andrei Popov Cc: David Benjamin ; tls@ietf.org Subject: Re: [EXTERNAL] Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt On Mon, Oct 16, 2023 at 3:51 PM Andrei Popov mailto:andrei.po...@microsoft.com>> wrote: * Where these interpretations conflict, the selection may be downgraded, potentially even under attacker influence. Downgrade by attacker is only possible if the client attempts insecure fallback (e.g., offer PQ key share, connection failed, retry without PQ key share)? Or am I missing some other possible downgrade attack? I think perhaps. The problem is that PQ key shares are going to be split across packets, and some software is going to break. This is just because our current ClientHellos fit in one packet (or maybe a few, the more you add, the worse it gets). But how are you going to detect whether there's a crappy TCP/IP stack or an attack? You can't. So, as the new things roll out, this will happen. It's not really an interesting problem, but it is real. Think of how TLS 1.3 handshakes pretend to be something older. It's that sort of thing. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Mon, Oct 16, 2023 at 3:51 PM Andrei Popov wrote: > >- Where these interpretations conflict, the selection may be >downgraded, potentially even under attacker influence. > > Downgrade by attacker is only possible if the client attempts insecure > fallback (e.g., offer PQ key share, connection failed, retry without PQ key > share)? > > Or am I missing some other possible downgrade attack? > I think perhaps. The problem is that PQ key shares are going to be split across packets, and some software is going to break. This is just because our current ClientHellos fit in one packet (or maybe a few, the more you add, the worse it gets). But how are you going to detect whether there's a crappy TCP/IP stack or an attack? You can't. So, as the new things roll out, this will happen. It's not really an interesting problem, but it is real. Think of how TLS 1.3 handshakes pretend to be something older. It's that sort of thing. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
* Where these interpretations conflict, the selection may be downgraded, potentially even under attacker influence. Downgrade by attacker is only possible if the client attempts insecure fallback (e.g., offer PQ key share, connection failed, retry without PQ key share)? Or am I missing some other possible downgrade attack? * Clients that assume a server implements the new rules may introduce a downgrade attack on a pre-existing server. From the text, it is not clear to me exactly how. * It updates server behavior to clarify that key shares may not reflect client preferences. * While this algorithm avoids HelloRetryRequest whenever possible, it implicitly assumes the client prefers the values sent in key_share, and that the server has no preferences between any groups. I don’t think so. Servers accepting other than the server’s top-priority group in order to avoid HRR aren’t necessarily doing this because they honor client preferences or assume that key_share reflects client preferences. They may simply find several groups acceptable and consider RTT reduction more important than the strength difference between certain groups. I’m not convinced that this is necessarily wrong, generally. Cheers, Andrei From: TLS On Behalf Of Rob Sayre Sent: Monday, October 16, 2023 10:52 AM To: David Benjamin Cc: tls@ietf.org Subject: [EXTERNAL] 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 mailto:david...@chromium.org>> 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
