- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 9 Jun 2015 15:26:00 -0700
- To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
- Cc: The IESG <iesg@ietf.org>, httpbis-chairs@ietf.org, Mark Nottingham <mnot@mnot.net>, draft-ietf-httpbis-tunnel-protocol.shepherd@ietf.org, draft-ietf-httpbis-tunnel-protocol.ad@ietf.org, draft-ietf-httpbis-tunnel-protocol@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
Hi Kathleen, I've responded separately to the secdir review. There was a lot of overlap between that and Stephen's review. On 9 June 2015 at 13:59, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote: > It seems to me that authentication relies on TLS. Maybe stating this > explicitly would address the concern? Is there a reason this should be > in the ALPN header(I'm not sure of that, just asking)? We're not actually authenticating this stuff. As I noted in my other response, this is a promise that the client makes and one that the proxy cannot enforce (because, TLS). So the real uses for this header field are: prioritization (move connections from slow and fat pipes to fast and thin pipes, maybe), or early and cleaner denial. The latter allows the proxy to quickly generate an HTTP status code without having to do DPI or whatever other eldritch horrors they currently are forced to do to recognize and deny things they don't want. The WebRTC case is interesting, because you can actually have some assurance about the trustworthiness of the header field. If you trust the browsers, that is (though I'm not advocating that, browser people are the most untrustworthy).
Received on Tuesday, 9 June 2015 22:26:27 UTC