Re: Alt-Svc WGLC

[Kyle Rose <[e-mail]>]

On Tue, Jan 12, 2016 at 9:13 PM, Martin Thomson
<[e-mail]> wrote:
> On 12 January 2016 at 13:51, Kyle Rose <[e-mail]> wrote:
>> "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."
>
> There are two rules we need to capture:
>
> 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." I had interpreted the draft to indicate
that only host changes required strong authentication of the
alternative service, but apparently that is not the intent (and I
suppose is what the "Changing Ports" section is all about).

It's very confusing. The "Changing Hosts" section, for instance, says that:

   This is the reason for the requirement in Section 2.1 that any
   alternative service with a host different from the origin's be
   strongly authenticated with the origin's identity

when according to your rule #1 we want to strongly authenticate with
the origin's identity even when the alternative service's host is the
same as the origin's.

If the intent is to *always* strongly authenticate the alternative
service with the origin's identity, the draft should state that
unconditionally.

> 2. if the alt-svc advertisement isn't authenticated, the host can't be
> different to the origin.

We need to cleanly separate these two requirements, because I think
both the "Changing Hosts" language and the "Host Authentication"
language do not capture this. In fact, they seem to conflate the two
issues, as I have apparently been doing.

Your two guidelines, in fact, seem to capture the required precision.
A candidate for the first is above; one for the second might be
"Clients MUST NOT use an alternative service whose host is different
from the origin's if the alternative service advertisement was not
strongly authenticated." Some explanatory language around each
requirement in section 2, or separate subsecitions under "Security
Considerations", could provide context for each of the requirements.

This needs to be made a lot clearer.

Kyle