Any change of getting this adopted by the WG ? On Mon, 18 Mar 2024 at 15:47, David Benjamin <[email protected]> wrote: > > > …and now I'm coming around to the idea that we don't need to do anything > > special to account for the "wrong" server behavior. Since RFC8446 already > > explicitly said that clients are allowed to not predict their most > > preferred groups, we can already reasonably infer that such servers > > actively believe that all their groups are comparable in security. > > I've now updated the draft to do this. > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-01.html > > It is now considerably simpler and just contains the DNS mechanism, plus a > discussion in Security Considerations why this is OK. > > On Tue, Mar 12, 2024 at 10:04 AM Andrei Popov <[email protected]> > wrote: >> >> …and now I'm coming around to the idea that we don't need to do anything >> special to account for the "wrong" server behavior. Since RFC8446 already >> explicitly said that clients are allowed to not predict their most preferred >> groups, we can already reasonably infer that such servers actively believe >> that all their groups are comparable in security. >> >> It makes sense for some services to prioritize RTT reduction; others may >> prioritize group strength. There are a lot of services out there >> prioritizing weaker groups for CPU savings (e.g., this is one of the reasons >> why Curve 25519 is so popular). >> >> >> >> I... question whether taking that position is wise, given the ongoing >> postquantum transition, but so it goes >> >> Servers will have to be updated and reconfigured for PQC/hybrid support, at >> which time they will likely apply a different policy. >> >> >> >> Hopefully your TLS server software, if it advertises pluggable cryptography >> with a PQ use case, and yet opted for a PQ-incompatible selection criteria, >> has clearly documented this so it isn't a surprise to you. ;-) >> >> Correct. >> >> >> >> Between all that, we probably can reasonably say that's the server >> operator's responsibility? >> >> Yes. >> >> >> >> Cheers, >> >> >> >> Andrei >> >> >> >> From: TLS <[email protected]> On Behalf Of David Benjamin >> Sent: Friday, March 8, 2024 3:25 PM >> To: Watson Ladd <[email protected]> >> Cc: <[email protected]> <[email protected]> >> Subject: [EXTERNAL] Re: [TLS] Next steps for key share prediction >> >> >> >> On Thu, Mar 7, 2024 at 6:34 PM Watson Ladd <[email protected]> wrote: >> >> On Thu, Mar 7, 2024 at 2:56 PM David Benjamin <[email protected]> wrote: >> > >> > Hi all, >> > >> > With the excitement about, sometime in the far future, possibly >> > transitioning from a hybrid, or to a to-be-developed better PQ algorithm, >> > I thought it would be a good time to remind folks that, right now, we have >> > no way to effectively transition between PQ-sized KEMs at all. >> > >> > At IETF 118, we discussed draft-davidben-tls-key-share-prediction, which >> > aims to address this. For a refresher, here are some links: >> > https://davidben.github.io/tls-key-share-prediction/draft-davidben-tls-key-share-prediction.html >> > https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-key-share-prediction-00 >> > (Apologies, I forgot to cut a draft-01 with some of the outstanding >> > changes in the GitHub, so the link above is probably better than draft-00.) >> > >> > If I recall, the outcome from IETF 118 was two-fold: >> > >> > First, we'd clarify in rfc8446bis that the "key_share first" selection >> > algorithm is not quite what you want. This was done in >> > https://github.com/tlswg/tls13-spec/pull/1331 >> > >> > Second, there was some discussion over whether what's in the draft is the >> > best way to resolve a hypothetical future transition, or if there was >> > another formulation. I followed up with folks briefly offline afterwards, >> > but an alternative never came to fruition. >> > >> > Since we don't have another solution yet, I'd suggest we move forward with >> > what's in the draft as a starting point. (Or if this email inspires folks >> > to come up with a better solution, even better! :-D) In particular, >> > whatever the rfc8446bis guidance is, there are still TLS implementations >> > out there with the problematic selection algorithm. Concretely, OpenSSL's >> > selection algorithm is incompatible with this kind of transition. See >> > https://github.com/openssl/openssl/issues/22203 >> >> Is that asking whether or not we want adoption? I want adoption. >> >> >> >> I suppose that would be the next step. :-) I think, last meeting, we were a >> little unclear what we wanted the document to be, so I was trying to take >> stock first. Though MT prompted me to ponder this a bit more in >> https://github.com/davidben/tls-key-share-prediction/issues/5, and now I'm >> coming around to the idea that we don't need to do anything special to >> account for the "wrong" server behavior. Since RFC8446 already explicitly >> said that clients are allowed to not predict their most preferred groups, we >> can already reasonably infer that such servers actively believe that all >> their groups are comparable in security. OpenSSL, at least, seems to be >> taking that position. I... question whether taking that position is wise, >> given the ongoing postquantum transition, but so it goes. Hopefully your TLS >> server software, if it advertises pluggable cryptography with a PQ use case, >> and yet opted for a PQ-incompatible selection criteria, has clearly >> documented this so it isn't a surprise to you. ;-) >> >> >> >> Between all that, we probably can reasonably say that's the server >> operator's responsibility? I'm going to take some time to draft a hopefully >> simpler version of the draft that only defines the DNS hint, and just >> includes some rough text warning about the implications. Maybe also some >> SHOULD level text to call out that servers should be sure their policy is >> what they want. Hopefully, in drafting that, it'll be clearer what the >> options are. If nothing else, I'm sure writing it will help me crystalize my >> own preferences! >> >> >> >> > Given that, I don't see a clear way to avoid some way to separate the old >> > behavior (which impacts the existing groups) from the new behavior. The >> > draft proposes to do it by keying on the codepoint, and doing our future >> > selves a favor by ensuring that the current generation of PQ codepoints >> > are ready for this. That's still the best solution I see right now for >> > this situation. >> > >> > Thoughts? >> >> I think letting the DNS signal also be an indicator the server >> implements the correct behavior would be a good idea. >> >> >> >> I'm afraid DNS is typically unauthenticated. In most TLS deployments, we >> have to assume that the attacker has influence over DNS, which makes it >> unsuitable for such a signal. Of course, if we end up settling on not >> needing a signal, this is moot. >> >> >> >> David > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
