Hi Martin, On Tue, Jun 9, 2015 at 6:26 PM, Martin Thomson <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote: Hi Kathleen, I've responded separately to the secdir review. There was a lot of overlap between that and Stephen's review. Yes, thank you for your response. I'm sorry you didn't see my No Objection before responding to this as I did see the discussion and the responses shortly after issuing the discuss and changed it. Thanks for your work on this draft. Kathleen On 9 June 2015 at 13:59, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com <mailto: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). -- Best regards, Kathleen
Received on Wednesday, 10 June 2015 08:03:16 UTC