W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Upgrade status for impl draft 1

From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 27 Feb 2013 13:20:44 -0800
Message-ID: <CA+9kkMDYyWcOpHH+ngG4pQNhGu50ZafeBhBofTZiobj4nvCz3A@mail.gmail.com>
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,

Received on Wednesday, 27 February 2013 21:21:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC