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

Re: Alt-Svc WGLC

From: Erik Nygren <erik@nygren.org>
Date: Wed, 13 Jan 2016 17:42:16 -0500
Message-ID: <CAKC-DJjRv6oFoLZzT264WFc1+3xOVr_oU-w2PbaCo+8tsask3Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Kyle Rose <krose@krose.org>, Julian Reschke <julian.reschke@gmx.de>, Hervé Ruellan <herve.ruellan@crf.canon.fr>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jan 12, 2016 at 10:22 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 13 January 2016 at 14:03, Kyle Rose <krose@krose.org> wrote:
> >> 1. the alternative service must be authenticated as the origin host
> >
> > If this is the case, then we should simply state that "Clients MUST
> > NOT use an alternative service that does not strongly authenticate
> > with the origin's identity."
>

The draft does state that in Section 2.1 but with a caveat:

"2.1.  Host Authentication

   Clients MUST NOT use alternative services with a host that is
   different than the origin's without strong server authentication;
   this mitigates the attack described in Section 9.2.  One way to
   achieve this is for the alternative to use TLS with a certificate
   that is valid for that origin."

That caveat ("host that is different than the origin's") is also the root
of the "AD review" thread.  If we were to give up on supporting Alt-Svc
for unauthenticated use-cases (ie, if the OppSec draft then required
strong server authentication for the "HTTP scheme over TLS" use-case)
then a number of these concerns go away and we end up with less
ambiguity both here and in the OppSec draft.  That would also mostly address
Mike Bishop's concerns around port switching since the destination port
would need to authenticate as the host.

For example, if 2.1 switched its first sentence to:

   Clients MUST NOT use alternative services
   without strong server authentication;
   this mitigates the attack described in Section 9.2
<https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10#section-9.2>.

which might also allow various things to be cleaned out of Security
Considerations.

What are the unauthenticated same-host use-cases of Alt-Svc that we
both really want to preserve and which are reasonably safe?

         Erik
Received on Wednesday, 13 January 2016 22:42:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:10 UTC