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

> On 17 Jan 2016, at 9:20 pm, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> 
> Mark Nottingham <mnot@mnot.net>: (Sun Jan 17 09:07:01 2016)
>> 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?
> 
> + 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 
> 
>>> On 17 Jan 2016, at 7:04 am, Patrick McManus <pmcmanus@mozilla.com> wrote:
>>> 
>>> 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
>>> 
>>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 

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

Received on Monday, 18 January 2016 00:24:17 UTC