- From: Ted Hardie <ted.ietf@gmail.com>
- Date: Wed, 27 Feb 2013 13:20:44 -0800
- To: Eliot Lear <lear@cisco.com>
- Cc: "William Chan (陈智昌)" <willchan@chromium.org>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Feb 26, 2013 at 10:27 PM, Eliot Lear <lear@cisco.com> wrote: > > On 2/27/13 4:43 AM, William Chan (陈智昌) wrote: > > > QQ over here. Is this assuming only unencrypted HTTP/2? I believe Patrick > was hoping to bootstrap serving http:// URLs via HTTP/2 over SSL, using the > external discovery mechanism (DNS most likely). If so, I'm unclear on > whether or not we need to describe behavior WRT TLS-NPNesque negotiation. > Perhaps we should fork the thread for this... > > > This *is* possible, but with a big caveat: DNS should offer alternatives > that have the same security level –– UNLESS DNSSEC is in play. Otherwise > there's a downgrade attack in the making. > > Eliot Hi Eliot, While I agree with you, the difficulty is that linking that sort of policy statement (DNS alternatives presented should have equivalent security levels) is not something that is easy to find an enforcement point for inside the DNS. In some HTTP use cases you may will have no integrated DNS clients (e.g. mobile apps) and in lots of them you will have no DNSSEC validation routines. So doing it in the DNS client code may be equally problematic. Can we express this instead as "clients should reject candidates found via external discovery if the candidates are not protected by TLS"? That eliminates the downgrade but makes the HTTP client the enforcement point rather than the DNS. DNSSEC remains useful and a good addition, but it is no longer critical path. Just two cents, Ted
Received on Wednesday, 27 February 2013 21:21:11 UTC