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