Adding info about HSTS for the RPID to client Data.

[ve7jtb]

We have never allowed WebAuthn to non TLS origins.

HSTS adds another property of prohibiting user recourse to invalid certificates.

We should be using the existing token binding mechanism, but given the current lack of browser support for TokenBinding we need to consider other options.

Arguably RP best practice would be to use HSTS. The problem for them would be to know if at first use by the user agent the header was received and not stripped by a MIM.

There is a preload list that people can get into, but I don't know if that could be blocked by an attacker.

One simple possible solution would be to add a boolean to client data to indicate if the browser is enforcing HSTS for the RPID domain.

To cover the Token Binding functionality we would also need a mechanism to detect mis-issued certificates.

Perhaps something could be done with respect to that around CT (https://certificate.transparency.dev/), but I don't have a proposal for that.

[equalsJeffH]

on 2021-01-27 call: @agl notes that this approach does not give NIST what they want because a JS origin is a colleciton of resources loaded from mult RPs as well as the local cache --- i.e., this will not deliver what they desire. i.e., such an "hsts flag" is not usefully meaningful. maybe what they are desiring is a "secure boot" for JS origins ? i.e., the "reality - hope collision"

perhaps what they want is a sort of "taint bit" on the amalgamated JS+HTML+everythingElse origin, eg, take the sum of the sec properties of all the components of the browsing context. and if it is "1", then it is (possibly) "tainted".

you use SRI when offloading resources to CDNs. in any case a RP wishing AAL3 probably ought to minimize the collection of entities contributing to the browsing context.

how might CSP play in this? It is not clear. CSPs are included with resources, whereas webauthn is a "property" of the RP ( as noted by the browser (client platform)) making the "webauthn api" call (nav.creds.create() or get()) )

agl thinks the set of all TLS certs that have contributed resources to the browsing context might have meaning. maybe including something derived from the present in-force CSP might have (additional) meaning....

[equalsJeffH]

HSTS adds another property of prohibiting user recourse to invalid certificates.

Something to note here: HSTS was always seen by the browser/UA vendors and the websec WG as an interim solution. As the Web moves towards being more fully HTTPS-based, the nominal intention of UAs is to eventually default to trying HTTPS first, instead of insecure HTTP. In fact, we're presently at the beginning of that effort: https://9to5google.com/2021/01/11/google-chrome-address-bar-may-soon-default-to-https/

So the exigent need that underlied the invention of the website-declared HSTS policy is declining, and thus whether "secure" sites will continue to (need to) emit the Strict-Transport-Security header field is uncertain. Thus I would not necessarily base a WebAuthn feature/facet/whatHaveYou on HSTS.

An important question is whether the UAs include the "no user recourse" HSTS feature in their HTTPS-first approach. A quick search seems to indicate that there continues to be controversy over that particular HSTS feature.

ISTM that whether or not a UA enforces a "no user recourse" policy in the event of error(s) during TLS establishment is orthogonal to WebAuthn per se.

[ve7jtb]

I think that some RP will want to be assured that the assertion comes from a browser enforcing "no user recourse". That seems to be the main ask from NIST around HSTS, we already block JS that is loaded from an insecure origin.

I think including hashes of all the certs from origins contributing to the request would be more useful in preventing attacks.

[nicksteele]

Taking this issue to a farm upstate