Subject: non authenticated alternate services (was Re: AD review of draft-ietf-httpbis-alt-svc-10)

From: Patrick McManus <[email-masked]>
Date: Sat, 16 Jan 2016 15:04:52 -0500

Hi All, I apologize for letting this discussion go to my backlog. As Barry
suggested, some of us need longer than others to shake off the new year's
fog.

tl;dr; I've come to agree that an additional out of band check with an
origin advertising an an-authenticated alt-service has value and we should
modify the document to define that. It certainly has more value than either
the port scheme or just allowing same host ports. Maybe something like the
.well-known approach Kari suggests would be fine. Its certainly slow, but
the whole thing migration is asynchronous anyhow so that's not a deal
killer.

I'm actually glad the port number nonsense got called out. It didn't have
real value and its the kind of window dressing only a committee could love
(I say lovingly, as member of said committee.). Although moot now, I
disagree that it was doing any harm by giving people a sense of self
confidence - in general I think that kind of argument is too clever by
half, people are generally paying no attention or less often paying enough
attention to think it through.

I do have a concern that when reviewing the registry of .well-known
https://www.iana.org/assignments/well-known-uris/well-known-uris.xml it
isn't exactly overrun with well-used mechanisms. It seems to me .well-known
is often offered up in the solutions space but not implemented as often.

I'm happy to help draft text if no one else wants to. Perhaps Mark, as
author of rfc 5785, might want to suggest a structure. (do we need a
separate document?) I think it can probably be a white list of
advertisements on separate lines and also allowing *, but that's just an
opening bid.

onward,
-Patrick

---

From: Patrick McManus <[email-masked]>
Date: Sat, 16 Jan 2016 15:11:03 -0500

> is often offered up in the solutions space but not implemented as often.
I forgot to mention, in favor of .wk, that the async nature of alt-svc
makes it a bit of a special snowflake itself.. and in that case it might
fit better with a .w-k fetch than many other problem spaces. That paragraph
was mostly just thinking out loud.

-P

---

From: Mike Bishop <[email-masked]>
Date: Sat, 16 Jan 2016 22:45:28 +0000

I wasn’t even expecting it to have that much structure.  I’d be willing to buy that an ordinary user couldn’t cause /.well-known/alt-svc to exist in the first place; its existence (even if empty) is a signal that the admin knows about Alt-Svc and has done whatever is needful to keep unauthorized persons from setting it (like restricting that header from user-controlled content).  Just check for 2XX/4XX and be done.

From: Patrick McManus [mailto:[email-masked]]
Sent: Saturday, January 16, 2016 12:05 PM
To: Mark Nottingham <[email-masked]>
Cc: Stephen Farrell <[email-masked]>; Mike Bishop <[email-masked]>; Barry Leiba <[email-masked]>; Julian F. Reschke <[email-masked]>; [email-masked]; HTTP Working Group <[email-masked]>; [email-masked]
Subject: non authenticated alternate services (was Re: AD review of draft-ietf-httpbis-alt-svc-10)

Hi All, I apologize for letting this discussion go to my backlog. As Barry suggested, some of us need longer than others to shake off the new year's fog.
tl;dr; I've come to agree that an additional out of band check with an origin advertising an an-authenticated alt-service has value and we should modify the document to define that. It certainly has more value than either the port scheme or just allowing same host ports. Maybe something like the .well-known approach Kari suggests would be fine. Its certainly slow, but the whole thing migration is asynchronous anyhow so that's not a deal killer.
I'm actually glad the port number nonsense got called out. It didn't have real value and its the kind of window dressing only a committee could love (I say lovingly, as member of said committee.). Although moot now, I disagree that it was doing any harm by giving people a sense of self confidence - in general I think that kind of argument is too clever by half, people are generally paying no attention or less often paying enough attention to think it through.
I do have a concern that when reviewing the registry of .well-known https://www.iana.org/assignments/well-known-uris/well-known-uris.xml it isn't exactly overrun with well-used mechanisms. It seems to me .well-known is often offered up in the solutions space but not implemented as often.

I'm happy to help draft text if no one else wants to. Perhaps Mark, as author of rfc 5785, might want to suggest a structure. (do we need a separate document?) I think it can probably be a white list of advertisements on separate lines and also allowing *, but that's just an opening bid.
onward,
-Patrick

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jan 2016 18:07:01 +1100

Hey Patrick,

Thanks for that.

I took a rough stab at this:
  https://github.com/httpwg/http-extensions/commit/3872a0d0fd61

Basically, it moves the exception for same-host authentication out of alt-svc into opp-sec, so that we can refine it there, getting this discussion off of the critical path for alt-svc.

Thoughts?

> On 17 Jan 2016, at 7:04 am, Patrick McManus <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jan 2016 11:23:44 +1100

> On 17 Jan 2016, at 9:20 pm, Kari Hurtta <[email-masked]> wrote:
> 
> Mark Nottingham <[email-masked]>: (Sun Jan 17 09:07:01 2016)
>> Hey Patrick,
>> 
>> Thanks for that.
>> 
> + Clients MUST strongly authenticate the alternative service as the origin. This mitigates the
> + attack described in <xref target="host_security"/>. One way to achieve this is for the
> + alternative to use TLS with a certificate that is valid for the origin.
> 
> What is "strongly authenticate" ? It may be read that some kind certificate must be always
> required.   

We're leaving that intentionally vague.

> ( My suggestion of  /.well-known/alternative-services with whitelist on original service
>  may be authentication, but is alternative service then strongly authenticated? ) 

We can discuss that as part of the Opportunistic Security draft; presumably, that draft can say (if we have consensus to do so) that same host + .well-known meets the bar of "strong authentication".

If the phrase "strong authentication" is making this hard to understand, we might use something else (e.g., "have reasonable assurances that the alternative service is under control of the origin").

The idea here is that Alt Svc is pretty late in its process, so we want the changes to it to be as minimal as possible (as experience shows us that last-minute changes often introduce bugs and ambiguities). By punting .well-known to OppSec, we make sure that it gets careful consideration.

> 
> Yes, on another document you clarifed this as
> 
> +{{I-D.ietf-httpbis-alt-svc}} requires that an alternative service only be used when it is strongly
> +authenticated as the origin.
> +
> +For the purposes of this specification, there are two ways to achieve this:
> +
> +1. Using TLS with a certificate that validates as per {{RFC2818}}, or
> +2. Using an alternative service with a hostname that is character-for-character identical to that of the origin.
> +
> +The latter approach allows deployment without the use of valid certificates, to encourage
> +deployment of opportunistic security. Therefore, in these cases the alternative service can provide
> +any certificate, or even select TLS cipher suites that do not include authentication.
> 
> I assume that "Using an alternative service with a hostname that is character-for-character 
> identical to that of the origin" is later expanded to discuss problems with different
> ports on same host.
> 
> Now that alternative service is not really "strongly authenticated" if just hostname 
> is identical.
> 
> Or what I missed?
> 
> / Kari Hurtta 
>

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 18 Jan 2016 07:50:09 +0000

Mark Nottingham <[email-masked]>: (Mon Jan 18 02:23:44 2016)

> If the phrase "strong authentication" is making this hard to understand, we might use something else (e.g., "have reasonable assurances that the alternative service is under control of the origin").

That may be more clear.

/ Kari Hurtta

---

From: Patrick McManus <[email-masked]>
Date: Mon, 18 Jan 2016 15:32:41 -0500

> We're leaving that intentionally vague.

I think the problem is that it doesn't feel very vague - strongly
authenticate should principally mean via crypto auth.. so I think its a
notch stronger than we're looking for here. The other confusing bit is
that, using the proposed .w-k approach, you're not really authenticating
the alternate as much as you're authenticating that alternate is valid for
the whole origin (as you indicate below).

>
> If the phrase "strong authentication" is making this hard to understand,
> we might use something else (e.g., "have reasonable assurances that the
> alternative service is under control of the origin").
>

that's better. maybe tweak with the "valid for the whole origin" concept?
That would certainly include both valid cert as well as the .wk approach..

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jan 2016 10:15:21 +1100

> On 19 Jan 2016, at 7:32 am, Patrick McManus <[email-masked]> wrote:
> 
> that's better. maybe tweak with the "valid for the whole origin" concept? That would certainly include both valid cert as well as the .wk approach.. 

WFM. I'll update the branch.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jan 2016 11:39:54 +1100

> On 19 Jan 2016, at 10:15 am, Mark Nottingham <[email-masked]> wrote:
> 
> 

Diff from current ED here:
  https://github.com/httpwg/http-extensions/compare/altsvc-samehost?diff=split&name=altsvc-samehost

---

From: Mike Bishop <[email-masked]>
Date: Tue, 19 Jan 2016 16:20:23 +0000

Still not wild about the character-for-character part, but as noted, that's off the critical path by moving to Opp-Sec.  The Alt-Svc changes work for me.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Jan 2016 16:05:55 +1100

Sounds like people are OK with this -- I'll merge unless I hear otherwise soon.

> On 20 Jan 2016, at 3:20 am, Mike Bishop <[email-masked]> wrote:
>