Subject: Re: [httpwg/http-extensions] Stream-linking frames can reference Stream Zero (#586)

From: HTTP issue updates <[email-masked]>
Date: Thu, 24 May 2018 11:44:42 -0700

@MikeBishop pushed 1 commit.

07cf01b  transaction, not transition

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/586/files/3067409864dcd5c719b99393c70c1d4e1cdf56ed..07cf01b8cb9146447805f6e5d36d7d1415783585

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 24 May 2018 13:42:16 -0700

@kazuho, @martinthomson, I would appreciate it if you could give this a look.  Do you think this is a good approach?

-- 
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/586#issuecomment-391852651

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 24 May 2018 16:37:04 -0700

martinthomson requested changes on this pull request.

This makes me convinced that we probably want to hold exported authenticators for a little while longer.  See the big comment.

-If the server does not have the desired certificate, it MUST \[see issue #564].
-In this case, or if the server has not advertised support for HTTP-layer
-certificates, the client MUST NOT send any requests for resources in that origin
-on the current connection.
+If the server does not have the desired certificate, it MUST send an empty
+`USE_CERTIFICATE` frame for stream zero.  In this case, or if the server has not

When you say empty, I think that you mean that the server sends an empty CERTIFICATE frame and then references that certificate when it wants to reject a CERTIFICATE_NEEDED request.

That is:

```
Client Sends:
CERTIFICATE_REQUEST (id=N) -->
CERTIFICATE_NEEDED (S=0, R=M) -->
...
Server can't answer, so:
<-- CERTIFICATE (Cert-ID=Q, <empty>)
<-- USE_CERTIFICATE (S=0, R=M)
```

The problem here is that the empty CERTIFICATE frame isn't bound in any way to the CERTIFICATE_REQUEST, unless your definition of "empty" isn't that the authenticator is completely absent, but that it includes a valid authenticator, but no certificate in the TLS Certificate message.  Then the `certificate_request_context` can be used to correlate CERTIFICATE with CERTIFICATE_REQUEST in the usual fashion.  That's how TLS does it - it sends Certificate without the certificate and omits the CertificateVerify message entirely if it doesn't want to authenticate.  (I just realized that I used CERTIFICATE, Certificate and certificate in the same paragraph to mean three different things, which is not at all confusing.)

I just read exported authenticators again and I don't see that use case being addressed at all.  @grittygrease should be aware of that given that TLSEA is in WGLC.  I think that TLSEA needs to address that case one way or other.  If the intent is to have the using application manage rejection, then it needs to be clear where the responsibility lies.  However, I think that having authenticated rejection is superior and that should be expressly included in the draft with a description of how that is done.

-- 
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/586#pullrequestreview-123206820

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 26 May 2018 21:53:55 -0700

MikeBishop commented on this pull request.

Actually, "empty" probably needs to be clarified here.  In the previous draft (i.e. where things were on-stream with the request), you could omit the CertID and send a USE_CERTIFICATE with a length of zero, which meant "I don't have / choose not to provide the requested certificate.  Deal."

If ExpAuth gives us an authenticated denial, I'd be fine using it.  But I'm also fine if it doesn't -- the point of ExpAuth is proving possession, and I think declining to provide an authenticator is sufficient for our purposes.  This isn't DNSsec where we want to authoritatively prove non-existence, we're just declining to supply a certificate (or, therefore, proof of possession).

-- 
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/586#discussion_r191064735