> 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.
I like this idea
On Mon, Feb 3, 2025, 2:54 PM Dennis Jackson <ietf=
40dennis-jackson...@dmarc.ietf.org> wrote:
> 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
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
