- From: Ryan Hamilton <rch@google.com>
- Date: Tue, 18 Jul 2017 11:30:54 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Piotr Sikora <piotrsikora@google.com>
- Message-ID: <CAJ_4DfSr1O5U6Vz3sWt8SmTscr0gOEDqGJeYrX6RZqT6Cixr4Q@mail.gmail.com>
My apologies for starting this thread on Friday and then going on vacation! I'm catching up now. On Fri, Jul 14, 2017 at 10:32 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > I get that you believe that DNS resolution is valuable here, but I > don't understand your point about "proxy configuration". If you have > a proxy configured, you generally don't do the DNS lookup directly, so > are you saying that you would allow the coalescing for a CONNECT > tunnel? > Yes, I think so. > Can you verify that I understand your point about Alt-Svc: if the > origin had been previously contacted and Alt-Svc identified an IP > address that matches the current IP, then that could be a sufficient > signal. Usually Alt-Svc is a name though, so that wouldn't help. > Sorry, I wasn't very clear. What I means is that if I connection to www.example.org which presents an *.example.org certificate, I need some second piece of information before using it for mail.example.com. In the alt-svc case, if an earlier connection to mail.example.org advertised alt-svc for www.example.org, then I would be comfortable coalescing the connection and would not need to do any resolution of mail.example.org. Similarly, are you saying that CT could assert something that would > cause you to skip the DNS lookup for a name? > This was more of a straw-man than a concrete proposal, but yes. Folk in Chrome security thought that this was plausible, though probably required more thought. Or is this list just to make a more general point about raising the > bar for gaining the ability to use a name, and not something that is > specific to this particular example of DNS lookups? > Specific to the issue of skipping DNS lookups when deciding to trust a certificate.
Received on Tuesday, 18 July 2017 18:31:23 UTC