On 01/02/2025 18:00, Eric Rescorla wrote:
2. It allows clients to safely force the server to offer a PQ chain
even if the client actually is type (3). Normally it wouldn't be
safe to only advertise PQ algorithms in signature_algorithms, but
if the server advertises a PQ TA, then the client can safely
provide only that TA in the ClientHello while offering a wider set
of TAs to other servers. This can also be used on the client
side to measure PQ support on servers.
I haven't seen this come up in discussion before, but I don't think this
is a meaningful use case.
The type 3 clients don't get any additional security unless they can
enforce the use of PQ in future connections to that site. Otherwise, an
attacker can always force this client back to advertising and accepting
a traditional algorithm. This requires some kind of active signal from
the server to the client, which the server is going to have to
consent+commit to anyway, so I don't think trying to mess around with
the Client Hello to coerce servers can deliver any benefit. Also, I'm
not sure I can imagine a scenario where there's enough server-side PQ
support for type 4 clients to exist, but with some servers still
unwilling to send PQ signatures when offered.
On 03/02/2025 12:57, Bas Westerbaan wrote:
On the negative side, I think it's not clear whether we'll reach 4
(clients stop advertising traditoinal algs) when the CRQC arrives:
there could well be sufficiently many servers that don't support PQ EE
certs yet.
On the positive side, I think we might be able to get more security
than you suggest before 4.
I agree. I expect this transition will look much like the shift from
HTTP to HTTPS so it's vital that we have a mechanism where clients and
servers which have already deployed PQ-support can benefit from it. This
means providing a way for servers to signal to clients "Please don't
ever fall back to non-PQ algorithms when connecting to me in the future"
and having clients store + enforce that signal. Putting this signal in
DNS isn't acceptable because we want to provide security even when DNS
is compromised / unauthenticated.
As Bas writes, this signal could be conveyed through a special kind of
certificate. However, besides the other issues Bas identifies, the
sketched design would be very hard to deploy because it relies on the
general body of server operators to take multiple actions: "Remember to
opt-in to the non-PQ cert package. Remember to opt-out of the non-PQ
cert package when you deploy PQ support. Remember to monitor CT going
forward." and it fails if they omit any step. It's reasonable to expect
security-motivated server operators to go out of their way to do these
things, but not the general population.
I think HSTS provides the basis for a more effective solution. It needs
only to be extended with a single additional bit ("Enforce use of PQ
signatures") and it's already well-understood by website operators.
Managing the preload list is a bit unpleasant for browsers, but strictly
speaking the preload list is an optional component of HSTS which is used
only to protect the very first connection between a client and a site
(non-preload HSTS protects all subsequent connections) and in any case I
don't think there's an alternative for first-connection protection.
Best,
Dennis
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
