Subject: Re: [httpwg/http-extensions] ORIGIN: reject origins on non-authoritative connection. (#385)

From: HTTP issue updates <[email-masked]>
Date: Sat, 26 Aug 2017 00:11:12 +0000 (UTC)

@mnot @enygren @mcmanus please take a look, the current draft is a bit underspecified when dealing with misbehaving servers. Also, I'm not sure if we should also add text saying that `servers MUST NOT send origins for which they are not authoritative`, since it's kind of given.

-- 
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/385#issuecomment-325061172

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 28 Aug 2017 01:17:09 -0700

Shutting down the connection because the client doesn't like the server's authority seems too severe; given that clients can (and will) have different policies for establishing authority, this creates a strong incentive for the server to be very conservative.

I could see a stream error; that gives information about what happened. 

-- 
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/385#issuecomment-325290646

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 28 Aug 2017 09:30:09 +0000 (UTC)

Maybe this could have been phrased better, but what I meant is the `subjectAltName` check mentioned in the sentence before, i.e. server sending an `ORIGIN` frame for a domain it didn't present the certificate for (either during initial TLS handshake or via `CERTIFICATE` frame), not the recommended CT and/or OCSP checks, since those will vary from browser to browser.

There is no mention of such scenario in the current draft, and it's unclear how clients should behave when it happens.

`ORIGIN` frame applies to the whole connection and it's not sent on a particular stream, so I don't see how clients could send a stream error, really.

-- 
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/385#issuecomment-325306735

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 28 Aug 2017 13:26:42 +0000 (UTC)

@PiotrSikora I think the concern is that the server does send a potential certificate but the client rejects its use with a particular ORIGIN due to client policy that is opaque to the server. (i.e. different trust roots, stored exceptions, etc..)

-- 
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/385#issuecomment-325352775

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 29 Aug 2017 03:56:11 +0000 (UTC)

@mcmanus Ah, that makes more sense, thanks!

However, as of right now, the certificate cannot be rejected, because the only one is provided during initial TLS handshake, which means that if it's rejected, then there is no HTTP/2 connection to begin with.

I agree that it gets a bit more complicated with the `CERTIFICATE` frame, especially because [the current draft, section 4](https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-http2-additional-certs-04#section-4) allows implementations to not terminate the connection upon receiving invalid certificate, probably for the reasons mentioned by you.

However, I feel a bit uncomfortable with a draft that doesn't even mention the malicious behavior, and doesn't define what clients should do in such cases.

At the very least, there are 2 cases to cover:

1. Client connects to `https://evil.com` (certificate valid for `evil.com`), server sends `ORIGIN` frame for `https://bank.com`.

2. Client connects to `https://evil.com` (certificate valid for `evil.com`), server sends `CERTIFICATE` frame with a certificate for `bank.com` signed by unknown CA, followed by an `ORIGIN` frame for `https://bank.com`.

How should clients behave in both of those cases? Neither is even mentioned in the current draft.

For the record, I'm fine if the consensus is different from what I suggested in this pull request, but I think that those cases should be mentioned and client behavior should be defined for them.

-- 
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/385#issuecomment-325548383

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 29 Aug 2017 04:24:35 +0000 (UTC)

With coalescing, this still applies to the one certificate.  A connection might be good for `evil.com`, but not for `bank.com`, even when both appear in the same certificate.  That might be because `bank.com` has a pinning rule or Expect-CT or any one of a host of other reasons that a certificate might appear OK, but not be (the variety of reasons being why certificates are a nightmare of complexity).

This draft probably doesn't want to get into the details of the `CERTIFICATE` frame.  In your examples, an `ORIGIN` frame for origin that the server on this connection isn't authoritative for can - or maybe SHOULD - be ignored.  That ignoring can stop at the point that the server becomes authoritative for any reason (straw man example that isn't `CERTIFICATE`: the `notBefore` time might pass).

-- 
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/385#issuecomment-325551535

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 29 Aug 2017 04:29:47 +0000 (UTC)

As for this PR, the better question is: how does a server learn that its certificate isn't good enough?  It's a much bigger question, but probably better worth addressing directly.

-- 
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/385#issuecomment-325552091

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 29 Aug 2017 19:05:25 -0700

We've talked about having a more specific stream error than PROTOCOL_ERROR for unauthoritative pushes; we agreed to wait for secondary certs to be defined in #355.

For client-initiated requests, an ORIGIN containing an origin that the current cert(s) held by the client doesn't cover implies that it can't be used on that connection until some sort of proof is obtained (probably a secondary cert). I think that's well covered by the current spec; it doesn't imply an error, because the Origin Set is *never* used as the sole source of truth regarding what the conn is good for. If you can suggest clarifications to improve understanding of this, they're welcome, but I don't *think* doing so requires new spec language.

WRT the server learning about whether a cert is good enough -- yes, but I think that's an issue for secondary certs. Probably.

BTW, @PiotrSikora - we prefer issues to be raised separately, not as PRs; it makes them more discoverable. 

-- 
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/385#issuecomment-325856699