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 <b...@google.com> Sent: Friday, October 27, 2023 4:55 PM To: David Benjamin <david...@chromium.org> Cc: Michael P1 <michael...@ncsc.gov.uk>; 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 <david...@chromium.org<mailto:david...@chromium.org>> wrote: Responses inline. On Fri, Oct 27, 2023 at 5:04 AM Michael P1 <michael...@ncsc.gov.uk<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 draft aims to correct that. DNS hints may not help decide which is best as we explicitly are not using key_shares. I don't understand this comment. The point of DNS hints is not to help decide which is best. It's to help the client decide which to predict, in order to minimize roundtrips. The entire point of this draft is to clarify that the client's prediction set is not a statement preference. I.e. it is explicitly not about deciding which is best. 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? No, this draft does NOT propose to define duplicate groups. The proposal is that going forward, any new groups we define will be prediction-safe. In particular, we need to make sure that all post-quantum groups are prediction-safe, so that we can better navigate the tradeoffs between wanting to reliably negotiation postquantum groups, and their size cost. It is, broadly, not a problem 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 <say...@gmail.com<mailto:say...@gmail.com>> Sent: Tuesday, October 17, 2023 9:08 PM To: David Benjamin <david...@chromium.org<mailto:david...@chromium.org>> Cc: Andrei Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>>; tls@ietf.org<mailto: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 <david...@chromium.org<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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
