- From: Jeffrey Yasskin <jyasskin@google.com>
- Date: Tue, 30 Jan 2018 23:46:56 +0000
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: Jana Iyengar <jri@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANh-dX=p1YWqU1E1sFMcFsJmBAff-7zzBb6CXwjTjPPfUUjK6w@mail.gmail.com>
On Tue, Jan 30, 2018 at 2:50 PM Eric Rescorla <ekr@rtfm.com> wrote: > > > On Tue, Jan 30, 2018 at 2:00 PM, Jeffrey Yasskin <jyasskin@google.com> > wrote: > >> On Tue, Jan 30, 2018 at 1:42 PM Eric Rescorla <ekr@rtfm.com> wrote: >> >>> >>> >>> On Tue, Jan 30, 2018 at 1:26 PM, Jeffrey Yasskin <jyasskin@google.com> >>> wrote: >>> >>>> On Tue, Jan 30, 2018 at 1:13 PM Eric Rescorla <ekr@rtfm.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jan 30, 2018 at 12:35 PM, Jeffrey Yasskin <jyasskin@google.com >>>>> > wrote: >>>>> >>>>>> On Tue, Jan 30, 2018 at 12:18 PM Eric Rescorla <ekr@rtfm.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 30, 2018 at 11:50 AM, Jana Iyengar <jri@google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I'm watching from the sidelines, but a clarification question: >>>>>>>> >>>>>>>> Thanks for taking a look at this. However, I don't think it really >>>>>>>>> addresses the concern that I raised, which is not solely about talking to >>>>>>>>> the origin but about having a digital signature from the origin server >>>>>>>>> substitute for an HTTPS connection to the origin. >>>>>>>>> >>>>>>>> >>>>>>>> In the current world, client does DNS lookup, establishes a TCP >>>>>>>> connection, creates a secure channel to an authenticated origin, and gets >>>>>>>> content from it over this channel. >>>>>>>> >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> >>>>>>> Per my understanding, the proposal here basically removes the DNS >>>>>>>> lookup + TCP connection to the origin, but creates a secure channel to an >>>>>>>> authenticated proxy, and separately authenticates content that it gets from >>>>>>>> it. >>>>>>>> >>>>>>> >>>>>>> Well, the proxy is largely irrelevant here, as the client has no >>>>>>> particular relationship with it. From a security perspective, the client >>>>>>> gets some content from a random location and trusts it because it's >>>>>>> digitally signed by the origin server. >>>>>>> >>>>>>> >>>>>>> The client would previously have authenticated the channel to the >>>>>>>> origin and gotten any content from it. In this proposal, a client does a >>>>>>>> TLS handshake to secure the channel to the proxy, and then authenticates >>>>>>>> content that comes over it. Is this understanding correct? If so, it >>>>>>>> *seems* equivalent security to HTTPS. >>>>>>>> >>>>>>> >>>>>>> I don't think that's true. At *most* it provided data origin >>>>>>> authentication/integrity (feel free to argue non-repudiation, but that's >>>>>>> not really relevant here). It doesn't provide confidentiality to the origin >>>>>>> server at all. >>>>>>> >>>>>> >>>>>> Exactly, it's confidentiality to the physical server (given the >>>>>> recently-added privacy guidance to restrict package fetches to TLS) but not >>>>>> to the origin server. >>>>>> https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-02#section-7 >>>>>> explains why that's not quite as bad as for a "random" location, but it's >>>>>> still a different guarantee than the lock icon usually claims. >>>>>> >>>>> >>>>> Rather then nitpicking "random location".... It seems like the >>>>> situation is that if o2.com has produced a signed package than anyone >>>>> with a TLS certificate who can get you to connect to them can present you >>>>> content with origin o2.com, no? >>>>> >>>> >>>> Yes, if you follow a link, whoever presented the link can know you >>>> followed it (either via javascript or via a 302 redirect), and the link can >>>> result in content from o2.com. signed-exchanges change whether there's >>>> a physical connection to o2.com, but that physical connection isn't >>>> user-visible in any case. >>>> >>> >>> I'm not sure what you mean by "not user-visible". That's the semantic >>> that we currently have that this proposal breaks. >>> >> >> How does the user know which physical connections were made? If I see >> o2.com in my URL bar, that might mean that my browser made a connection >> to o2.com, or that it served something out of the cache without making >> any connections. >> > > What it definitely knows is that you didn't connect to some other random > server. > > > More importantly, is it a violation of confidentiality for *fewer* >> entities to be told that I'm visiting a resource? >> > (With the caveat that a certificate could be crafted that leads to the >> same number of entities being told.) >> > > The confidentiality issue is that the data that was sent to the client was > protected in transit, not shared with some random third party. > Clearly we're not communicating well, so I'm going to take a night to sleep on it and try to compose clearer questions. Thanks for taking the time to reply so far. Jeffrey
Received on Tuesday, 30 January 2018 23:48:09 UTC