Subject: Re: [httpwg/http-extensions] Incorporate exported authenticator requests (#481)

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 13:56:02 -0800

martinthomson requested changes on this pull request.

A couple of minor things that are probably important enough to get right at this point.

-Some extensions used for certificate selection allow multiple values (e.g.
-oid_filters on Extended Key Usage). If the sender has included a non-empty
-Extensions list, the certificate MUST match all criteria specified by extensions
-the recipient recognizes. However, the recipient MUST ignore and skip any
-unrecognized certificate selection extensions.
+The Exported Authenticator `request` API defined in
+[I-D.ietf-tls-exported-authenticator] takes as input a set of desired
+certificate characteristics and a `certificate_request_context`. When generating
+exported authenticators for use with this extension, the
+`certificate_request_context` MUST be the two-octet Request-ID.

Exported authenticators require that the certificate_request_context be unpredictable.  I think that we can address this by prefixing a random sequence with the two-octet Request-ID.  Then we can ensure that we have a mapping key, but also enough entropy to avoid guessing.

> -
-Upon receipt of a completed authenticator, an endpoint MUST check that:
-
- - the `validate` API confirms the validity of the authenticator itself
- - the `certificate_request_context` matches the Cert-ID of the frame(s) in
-   which it was received
+takes as input a request, a set of certificates, and supporting information
+about the certificate (OCSP, SCT, etc.).
+
+Upon receipt of a completed authenticator, an endpoint MUST perform the
+following steps:
+ - Using the `get context` API, retrieve the `certificate_request_context` used
+   to generate the authenticator, if any.
+ - Verify that the `certificate_request_context` is the Request-ID of a
+   previously-sent `CERTIFICATE_REQUEST` frame.  Alternatively, on clients the
+   `certificate_request_context` MAY also be empty.

Verify that the authenticator has either an empty `certificate_request_context` (for clients only), or contains a Request-ID from a previously-sent `CERTIFICATE_REQUEST` frame.

> @@ -640,16 +636,18 @@ received on any other stream MUST be rejected with a stream error of type
 ### Exported Authenticator Characteristics {#exp-auth}
 
 The Exported Authenticator API defined in [I-D.ietf-tls-exported-authenticator]
-takes as input a certificate, supporting information about the certificate
-(OCSP, SCT, etc.), and an optional `certificate_request_context`.  When
-generating exported authenticators for use with this extension, the
-`certificate_request_context` MUST be the two-octet Cert-ID.
-
-Upon receipt of a completed authenticator, an endpoint MUST check that:
-
- - the `validate` API confirms the validity of the authenticator itself
- - the `certificate_request_context` matches the Cert-ID of the frame(s) in
-   which it was received
+takes as input a request, a set of certificates, and supporting information
+about the certificate (OCSP, SCT, etc.).

This statement applies to the *creation* of an authenticator.  But the following paragraph talks about validation of one.  I think that you need to make that distinction a lot clearer.

> @@ -520,10 +520,7 @@ necessary frames have been received on stream zero MUST also result in a stream
 error of type `PROTOCOL_ERROR`.
 
 The referenced certificate chain MUST conform to the requirements expressed in
-the `CERTIFICATE_REQUEST` to the best of the sender's ability. Specifically, if
-the `CERTIFICATE_REQUEST` contained a non-empty `Cert-Extensions` element, the
-end-entity certificate MUST match with regard to the extensions recognized by
-the sender.
+the `CERTIFICATE_REQUEST` to the best of the sender's ability.

This is really a requirement on exported authenticators.  Can we turn this into a statement of truth instead?  Or remove it entirely.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/481#pullrequestreview-94154207

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 14:06:30 -0800

MikeBishop commented on this pull request.

A few clarifications.  I'll work on the others in the meantime.

I'm not sure that's true -- the exported authenticator functionality is responsible for communicating the requirements and the certificate, but it's not responsible for selecting the certificate to respond with.  I think it's a requirement on whomever does certificate selection, which I believe is the HTTP layer.

Should we specify the length?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/481#pullrequestreview-94159616

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 22:16:17 +0000 (UTC)

@MikeBishop pushed 1 commit.

c6e1306  Martin's feedback; fixes #483

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/481/files/42f69c806671885e80c191e101d1a2821d6cd31c..c6e13064908d915e428d56fdcd0630c83cd4f4b4

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 23:46:40 +0000 (UTC)

martinthomson commented on this pull request.

It's not really actionable though.  If your intent is to state an interoperability requirement (why else do you use MUST), what do we lose if someone violates that?  I mean, I know that NSS could try harder to comply, but we do have better things to do than add full support for oid_filter (just for example, which is really hard to implement in practice).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/481#discussion_r166148951

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 23:47:55 +0000 (UTC)

We probably need a minimum size to stop someone from inducing lots of requests until the right number comes up (for the stolen credentials they have).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/481#discussion_r166149155

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 15:48:34 -0800

>   - Using the `get context` API, retrieve the `certificate_request_context` used
    to generate the authenticator, if any.
- - Verify that the `certificate_request_context` is the Request-ID of a
-   previously-sent `CERTIFICATE_REQUEST` frame.  Alternatively, on clients the
-   `certificate_request_context` MAY also be empty.
+ - Verify that the `certificate_request_context` is either empty (clients only)
+   or the Request-ID of a previously-sent `CERTIFICATE_REQUEST` frame.

Or *contains* the Request-ID.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/481#pullrequestreview-94184387

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 23:51:55 +0000 (UTC)

> @@ -566,9 +566,10 @@ Request:
 
 The Exported Authenticator `request` API defined in
 [I-D.ietf-tls-exported-authenticator] takes as input a set of desired
-certificate characteristics and a `certificate_request_context`. When generating
-exported authenticators for use with this extension, the
-`certificate_request_context` MUST be the two-octet Request-ID.
+certificate characteristics and a `certificate_request_context`, which needs to
+be unpredictable. When generating exported authenticators for use with this
+extension, the `certificate_request_context` MUST be the two-octet Request-ID,
+followed by at least six random octets.

I don't think that we need to stipulate order.  Can we say that it contains both the two-octet Request-ID and at least 96 bits of additional entropy.   (64-bits total isn't enough to avoid the problem I was talking about, especially when you consider that there is a good reason to choose a sequential Request-ID, which reduces that to 48 bits).

BTW, those extra bits can be constructed using HMAC(secret, Request-ID), rather than randomness.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/481#pullrequestreview-94185000

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 23:58:29 +0000 (UTC)

b42dc03  More feedback from @martinthomson

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/481/files/c6e13064908d915e428d56fdcd0630c83cd4f4b4..b42dc03ca17e590388b824f6d27f6461f0b84045

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 16:01:51 -0800

martinthomson approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/481#pullrequestreview-94186869

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 16:08:46 -0800

9cfbb2c  Typo

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/481/files/b42dc03ca17e590388b824f6d27f6461f0b84045..9cfbb2c2dfb5d8453191b2e664e9e6c46b1e4f6d

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 06 Feb 2018 00:10:19 +0000 (UTC)

Merged #481.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/481#event-1459106522