On Fri, Oct 27, 2023 at 9:06 AM David Benjamin <david...@chromium.org> wrote:
> Responses inline. > > On Fri, Oct 27, 2023 at 5:04 AM Michael P1 <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> >> *Sent:* Tuesday, October 17, 2023 9:08 PM >> *To:* David Benjamin <david...@chromium.org> >> *Cc:* Andrei Popov <andrei.po...@microsoft.com>; 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> >> 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
