On 12/12/2023 2:50 PM, Stephen Farrell wrote:
Hiya,
On 12/12/2023 17:08, Russ Housley wrote:
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.
Doing a PQ version of ECH would be hard. On the other hand, doing an
8773-like enhancement to ECH should not be all that hard. It would
require that the outer CH contains a PSK shared between the client and
the fronting server, and then combining that PSK and a classic public
key to derive the key encrypting the inner CH.
To get quantum reliance we would need two PSK -- one with the fronting
server, one with the protected server. The outer PSK would be used to
harden the ECH encryption key. The inner PSK would be used to harden the
session key.
Actually, if the fronting server can pass a secret to the protected
server, this secret could be used instead of the "inner PSK" to harden
the session key.
Still another day's work, but seems doable -- and keeping with spirit of
8773, using only old tech like PSK and ECDH instead of relying on
post-quantum algorithms.
-- Christian Huitema
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
