Well, the other thing about HSTS is that it's specified to be only "for web sites" It is right in the first sentence.
"This specification defines a mechanism enabling web sites..." I asked about this with regard to ACME, and they told me to get lost. Fine (also kind of funny), but we need to be careful about whether we're discussing TLS in general, or just web browsers. thanks, Rob On Tue, Feb 4, 2025 at 6:10 AM Bas Westerbaan <bas= [email protected]> wrote: > 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
