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

[HTTP issue updates <[e-mail]>]

@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