Stephen: > >> I've been thinking about your point. Some people want to use RFC >> 8773 to protect data that is transmitted today and recorded from the >> future invention of a quantum computer. To do this, the handshake >> includes the identifier for the external PSK, and an observer can get >> tracking data by watching which clients and servers have the same >> external PSK. This tracking data does not need the same long-term >> protection as the TLS protected content. So, the high-level guidance >> in the proposed text seems appropriate. That is, rotation of the >> external PSK identity or the use of the Encrypted Client Hello >> extension. I think you are correct, the "with algorithms that a >> secure against a CRQC" should be dropped. > > Right, I think that means that ECH as-is can be used, but in the face > of a CRQC, ECH as-is won't protect against the leakage about which > John was concerned. > > If one is worried about a future CRQC, then using ECH as-is should be > fine and protects for now against that leakage. (One might even add a > bit of text recommending that this extension only be present in the > inner CH whenever ECH is in use?) > > Using some future PQ version of ECH can't be done yet, and figuring > out how a PQ-version of ECH would work and not involve too-large a CH > is another day's work.
I think that is correct, one a CRQC comes along, the attacker will be able to decrypt the identifiers for the external PSK and gain tracking information, but not the payload content. In the future, when the TLS WG tackles a quantum-resistant ECH, then this concern will be resolved. Russ
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
