Subject: Re: Alt-Svc WGLC

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jan 2016 17:22:29 +0100

On 2015-12-15 16:35, Hervé Ruellan wrote:
> ...
>> 2) In
>> <https://github.com/hruellan/http-extensions/commit/fabd0943cde7e8af07f20b74acc2e48ac16e5f3e>,
>>
>> Hervé proposes a change that IMHO is not editorial as it affects a
>> normative requirement. Feedback appreciated.
>
> Yes, this affects a normative requirement. However my proposed addition
> is already in the spec, in the third paragraph of "9.2 Changing Hosts",
> which is referring to 2.1. I find it better to have the whole
> description in 2.1.
> ...

I just noticed that I failed to reply to this. The proposed change is to 
replace

"Clients MUST NOT use alternative services with a host that is different 
from the origin's without strong server authentication; ...."

by

"Clients MUST NOT use an alternative service with a host that is 
different than the origin's without strong server authentication linking 
the alternative service with the origin's identity. ..."

My remaining concern is that "...linking the alternative service with 
the origin's identity..." might not sufficiently precise for a normative 
requirement. More feedback appreciated.

Best regards, Julian

---

From: Kyle Rose <[email-masked]>
Date: Mon, 11 Jan 2016 11:05:04 -0500

> "Clients MUST NOT use an alternative service with a host that is different
> than the origin's without strong server authentication linking the
> alternative service with the origin's identity. ..."
>
> My remaining concern is that "...linking the alternative service with the
> origin's identity..." might not sufficiently precise for a normative

How about "Clients MUST NOT use an alternative service with a host
that is different from the origin's without strong server
authentication of the alternative service declaration"?

Kyle

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jan 2016 10:43:38 +1100

> authentication of the alternative service declaration"?

That changes the intent.  The server that is ultimately contacted
(after all the alt-svc shenannigans) MUST be authoritative for the
origin of the resources that it serves.

Yes, we want to authenticate the alt-svc declaration, but that isn't
actually a necessary precondition on getting what we really want: an
authority for the resource itself.

---

From: Kyle Rose <[email-masked]>
Date: Mon, 11 Jan 2016 19:49:43 -0500

Got it. (I don't like the language in the proposed change, but I don't
think my misunderstanding is necessarily reflective of ambiguity, more
of my thinking this was from a different section of the draft,
drastically changing the context in my mind.)

>From host_security, the issue seems to be:

 * If strong authentication is not used, then the origin and the
alternative service host must be the same
 * If strong authentication *is* used, then the host for the
alternative service must authenticate itself as the origin

Is the language in the second bullet point both precise enough to
limit the alt-svc hosts to what we mean, but broad enough to encompass
existing authentication schemes? If so, then maybe something like:

"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."

It has to be somewhat imprecise (what does it mean to "authenticate
itself as the origin"?) to be broadly applicable.

Kyle

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jan 2016 13:09:16 +1100

> 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.

---

From: Kyle Rose <[email-masked]>
Date: Mon, 11 Jan 2016 21:51:23 -0500

> 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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jan 2016 13:13:08 +1100

> 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
2. if the alt-svc advertisement isn't authenticated, the host can't be
different to the origin.

If your intent is to capture the second, then this isn't right,
because I read this as a restatement of the first.

---

From: Kyle Rose <[email-masked]>
Date: Tue, 12 Jan 2016 22:03:54 -0500

> 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

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jan 2016 14:22:11 +1100

On 13 January 2016 at 14:03, Kyle Rose <[email-masked]> wrote:
> with the origin's identity."

There may be some reluctance to write text that duplicates other RFCs.

I think that we can get over that and include that statement.  Adding
a citation for RFC 7230 should avoid any potential confusion about
whether this is intended to override any guidance there.

...
> strongly authenticated."

That works for me.  Julian, do you think that these statements could
be added to the root of Section 9?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Jan 2016 22:17:24 +0100

> be added to the root of Section 9?

I welcome concrete text or pull request. That being said, if we 
add/change normative statements, this should go into the main part of 
the spec, not the security considerations...

Best regards, Julian

---

From: Erik Nygren <[email-masked]>
Date: Wed, 13 Jan 2016 17:42:16 -0500

> > 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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Jan 2016 14:04:16 +1100

On 14 January 2016 at 09:42, Erik Nygren <[email-masked]> wrote:
> without strong server authentication; this mitigates the attack described in
> Section 9.2.

Does this refer to the alternative service server, or the server that
advertises the alternative service?  That's a major source of
confusion here.

---

From: Erik Nygren <[email-masked]>
Date: Wed, 13 Jan 2016 22:21:19 -0500

I'd been assuming the alternative service server.  Good point we should be
more explicit.
Perhaps:

Clients MUST NOT use alternative services without strong server
authentication to the alternative using the name of the origin; this
mitigates the attack described in Section 9.2.

(The following paragraph gives an example)

---

From: Kyle Rose <[email-masked]>
Date: Wed, 13 Jan 2016 22:36:08 -0500

> mitigates the attack described in Section 9.2.

I might go with my wording from earlier in the thread: "Clients MUST
NOT use an alternative service that does not strongly authenticate
with the origin's identity; this mitigates the attack described in
Section 9.2."

Kyle