>
> 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 just sketched one with a signal in the certificate. You point out some valid deployment challenges, but they're far from disqualifying the approach from the start, and we should give the general direction a chance. PQ HSTS (plus preload) is interesting and worthwhile for popular domains, but it can't carry the weight for the whole Internet, as it requires turning off classical crypto after the CRQC arrives. May I first challenge you to turn off plain HTTP in Firefox :)?
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
