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

Re: Alt-Svc WGLC

From: Kyle Rose <krose@krose.org>
Date: Mon, 11 Jan 2016 21:51:23 -0500
Message-ID: <CAJU8_nVQiaGEBtxXtHapOu0eigv=ovQSpT0DuEpkfo6tLQEEkw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, Hervé Ruellan <herve.ruellan@crf.canon.fr>, HTTP Working Group <ietf-http-wg@w3.org>
>> "Clients MUST NOT use unauthenticated alternative services with a host
>> that is different from the origin or authenticated alternative
>> services with a host that does not authenticate itself as the origin."
>
> I think that the second part is invariant, the first is an additional
> limitation on the use of alternative service advertisements that
> aren't properly authenticated.

The second part is bad wording.

What is the issue with the first part? My reading of the draft is that
we want to support the case in which an unauthenticated origin
provides an alternative service that *is* authenticated, just not the
case in which an unauthenticated origin provides an alternative
service that is also unauthenticated:

`This is the reason for the requirement in host_auth that any
alternative service with a host different to the origin's be strongly
authenticated with the origin's identity; i.e., presenting a
certificate for the origin proves that the alternative service is
authorized to serve traffic for the origin.`

I think we can actually skirt the confusion from the second part of my
previous proposal, and just slightly reword the existing text to more
closely match the wording in host_security:

"Clients MUST NOT use an alternative service with a host that is
different from the origin's without the alternative service strongly
authenticating with the origin's identity."

This admits:

 * unauth origin -> unauth alt svc on same host
 * unauth origin -> auth alt svc anywhere
 * auth origin -> auth alt svc anywhere

In isolation it also literally admits auth origin -> unauth alt svc on
same host, but that case is subject to the language in
changing-protocols around clients taking care about downgrading
security through the use of alternative services.

Kyle
Received on Tuesday, 12 January 2016 02:51:55 UTC

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