RE: AD review of draft-ietf-httpbis-alt-svc-10

The concern goes the other way, too – Alt-Svc mappings that you’ve previously discovered continuing to be used in Incognito.  If a server gave you an Alt-Svc of “chrisbentzel-laptop-2.tracking.example.com” previously and you used it once you entered Incognito, they could persist your identity into that mode regardless of whether you persist updates you see while Incognito.

Having a separate cache of Alt-Svc mappings that gets used only for that session would seem like a reasonable mitigation.

From: Chris Bentzel [mailto:chris@bentzel.net]
Sent: Friday, January 15, 2016 1:04 PM
To: Mark Nottingham <mnot@mnot.net>; Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Barry Leiba <barryleiba@computer.org>; Julian F. Reschke <julian.reschke@gmx.de>; draft-ietf-httpbis-alt-svc@ietf.org; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: AD review of draft-ietf-httpbis-alt-svc-10

Chiming in (very) late on the "In particular, clients configured for anonymous usage SHOULD NOT use alternative services."

I'm actually not sure what folks here have in mind when they think of "anonymous usage" configurations.

Assuming that something like Chrome's Incognito Mode falls under that bucket, it is likely that Chrome would use alternative services within an incognito session but not persist the alternative service mappings - they'd go away when the incognito session ends.

On Thu, Jan 14, 2016 at 10:32 PM Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
In some side discussions, I've come across other people who are unhappy with this state of affairs, so I don't think you're alone. I'll leave it up to them to decide how to participate here.

To be explicit -- we are opening up a potential same machine attack (specifically, someone on a shared HTTP server who has the ability to both add response headers -- such as with .htaccess or a CGI script -- and listen to another port (possibly, ANY port) on the same box can then hijack traffic intended for other users.

The motivation for doing so is to enable the HTTP Opportunistic Security specification, which offers weak protection against pervasive monitors, but is vulnerable to active attackers, and doesn't improve Web security in other (and important) ways that HTTPS does. We have only one implementation of that specification in a browser, and no sign that it will be adopted by others.

Is this a reasonable tradeoff? We are planning to publish this is Experimental, so the question might also be "is this a responsible experiment to run?"

Cheers,



> On 14 Jan 2016, at 6:18 am, Stephen Farrell <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> wrote:
>
>
>
> On 13/01/16 19:16, Mike Bishop wrote:
>> Yes, that's obviously a mitigation servers can set up, but that means
>> we're telling existing servers they need to disallow something that's
>
> Well s/need/can/ I think, but sure.
>
>> newly defined in order to prevent their users from hijacking them.
>> And I don't believe retroactive guidance like that is reasonable --
>> that will lag actual deployment of the protocol, and will never be
>> 100%.
>>
>> My proposal was that ~eve remains able to advertise an Alt-Svc, but
>> that alternative must then authenticate itself as users.example.com<http://users.example.com>
>> (which Eve's proxy cannot do) before clients will use it.
>>
>> I remain a little unhappy with this as it stands, but if no one else
>> thinks it's a problem, I'll stop now.
>
> Yeah, ditto:-)
>
> Cheers
> S
>
>>
>> -----Original Message----- From: Stephen Farrell
>> [mailto:stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>] Sent: Wednesday, January 13, 2016
>> 2:19 AM To: Barry Leiba <barryleiba@computer.org<mailto:barryleiba@computer.org>>; Mike Bishop
>> <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>> Cc: Julian Reschke
>> <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>>; draft-ietf-httpbis-alt-svc@ietf.org<mailto:draft-ietf-httpbis-alt-svc@ietf.org>; HTTP
>> Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>> Subject: Re: AD review of
>> draft-ietf-httpbis-alt-svc-10
>>
>>
>> Hiya,
>>
>> Yes, I'm fine that ~eve in Mike's scenario can muck with ~alice as
>> specified. (And such servers still do exist, we have one still.)
>>
>> I'd say best would be to call that attack out in the draft, but I
>> don't think the mitigation for the misbehaviour is to authenticate
>> ~eve, which is what the text below seems to be saying. Authenticating
>> the web server for the name will help of course, but surely the real
>> mitigation for that attack is for the server to scrub the alt-svc
>> headers? (And to be clear, yes the port number thing is fine, I don't
>> think system ports is a deal these days.)
>>
>> All of the above of course also assumes that the "changing host"
>> stuff is worked out well, which I'm sure it is or will be, but
>> haven't checked.
>>
>> S
>>
>> On 13/01/16 00:34, Barry Leiba wrote:
>>> The point with all this, in my mind and with respect to the text we
>>> have, is whether it makes any practical difference any more
>>> whether Eve sets this up on port 23412 or on port 1000.  My
>>> contention is that it doesn't, these days (while it might have in
>>> the past), and that implying that it's safe if the alt-svc is on a
>>> low-numbered port, but not safe (or less safe) if it's on a
>>> high-numbered port isn't doing any service to anyone.
>>>
>>> I think we should alert people to the possible
>>> attack/issues/whatever, but that we should not imply that any set
>>> of ports enjoy any sort of immunity against or resistance to those
>>> attacks.
>>>
>>> b
>>>
>>>
>>> On Tue, Jan 12, 2016 at 5:09 PM, Mike Bishop
>>> <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>> wrote:
>>>> More whether you're okay with that text as mitigation to this
>>>> hypothetical attack:
>>>>
>>>> http://users.example.com is a shared server which hosts user home
>>>> pages.  Eve places a config file in her wwwpages directory to add
>>>> an Alt-Svc header to pages served out of
>>>> http://users.example.com/~eve announcing an alternative service
>>>> for http://users.example.com on port 23412.  Bob is using an
>>>> Alt-Svc-capable browser.  After Bob has visited
>>>> http://users.example.com/~eve, he visits
>>>> http://users.example.com/~alice.  His browser, obeying Eve's
>>>> Alt-Svc header, accesses the alternative service on port 23412,
>>>> where Eve is running a forward proxy that replaces all pages
>>>> except her own with dancing hamsters.
>>>>
>>>> The original mitigations proposed in the text were "prohibit
>>>> normal users from setting the Alt-Svc header" (which is
>>>> retroactive on pre-Alt-Svc servers) or "prohibit normal users
>>>> from listening for incoming requests" (which is contrary to the
>>>> security model of any shared machine I've used).  This scenario
>>>> originally made me want to require strong auth on any change of
>>>> endpoint, but that breaks the opportunistic security draft.  The
>>>> current text, which I agree does very little, was as strong as we
>>>> could think of a way to make it without breaking the way Opp-Sec
>>>> wanted to work.
>>>>
>>>> I haven't seen such a server since I was in college, so I don't
>>>> know whether they still actually exist and run that way.  I
>>>> presume they do, even if rare, but I have no data.
>>>>
>>>> -----Original Message----- From: Stephen Farrell
>>>> [mailto:stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>] Sent: Tuesday, January 12,
>>>> 2016 12:32 PM To: Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>>;
>>>> Barry Leiba <barryleiba@computer.org<mailto:barryleiba@computer.org>>; Julian Reschke
>>>> <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>> Cc: draft-ietf-httpbis-alt-svc@ietf.org<mailto:draft-ietf-httpbis-alt-svc@ietf.org>;
>>>> HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>> Subject: Re: AD review
>>>> of draft-ietf-httpbis-alt-svc-10
>>>>
>>>>
>>>>
>>>> On 11/01/16 16:45, Stephen Farrell wrote:
>>>>>
>>>>>
>>>>> On 11/01/16 16:34, Mike Bishop wrote:
>>>>>> Haven't heard back from Stephen on the port-change issue we
>>>>>> wanted him to weigh in on; I sent him a reminder.
>>>>>
>>>>> 2nd one worked:-)
>>>>>
>>>>> Lemme go back and read the mail. Please hassle me if I've not
>>>>> gotten back by tomorrow sometime
>>>>
>>>> So as I understand it (thanks Barry), the issue is whether or not
>>>> this text is ok:
>>>>
>>>> "Clients can reduce this risk by imposing stronger requirements
>>>> (e.g. strong authentication) when moving from System Ports to
>>>> User or Dynamic Ports, or from User Ports to Dynamic Ports, as
>>>> defined in Section 6 of [RFC6335]."
>>>>
>>>> FWIW, I have no problem with that. I'm not sure quite what it's
>>>> telling a client to do, but I don't think there's much difference
>>>> these days between lower numbered and higher numbered ports. (If
>>>> that's wrong, I'm sure someone will correct me:-)
>>>>
>>>> Note that I've not read the rest of the document, just that bit.
>>>>
>>>> Cheers, S.
>>>>
>>>>>
>>>>> Cheers, S.
>>>>>
>>>>>>
>>>>>> -----Original Message----- From: barryleiba@gmail.com<mailto:barryleiba@gmail.com>
>>>>>> [mailto:barryleiba@gmail.com<mailto:barryleiba@gmail.com>] On Behalf Of Barry Leiba Sent:
>>>>>> Sunday, January 10, 2016 9:20 AM To: Julian Reschke
>>>>>> <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>> Cc:
>>>>>> draft-ietf-httpbis-alt-svc@ietf.org<mailto:draft-ietf-httpbis-alt-svc@ietf.org>; HTTP Working Group
>>>>>> <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>> Subject: Re: AD review of
>>>>>> draft-ietf-httpbis-alt-svc-10
>>>>>>
>>>>>>>>> I don't think this is a 2119 "MAY": what *else* can it
>>>>>>>>> do?  You have no other guidance about which alternative
>>>>>>>>> alternative to pick, so....  I think this should just
>>>>>>>>> say, "it chooses the most suitable...."
>>>>>>>>
>>>>>>>> Agreed. I haven't changed that yet as it affects
>>>>>>>> normative language but I will unless somebody wants to
>>>>>>>> defend it soonish.
>>>>>>>
>>>>>>> <https://github.com/httpwg/http-extensions/commit/a9df1e33703a2cb4

>>>>>>>
>>>>>>>
> 6c
>>>>>>> 9b
>>>>>>>
>>>>>>>
>>>>> 441bfca5bbc04fff80d1>
>>>>>>
>>>>>> Nice.  Is this the last of the updates, or are we still
>>>>>> working on any?  Whenever you're ready to post a new I-D
>>>>>> version, I'll give it a check and request last call.
>>>>>>
>>>>>> Barry
>>>>>>
>>>>>
>>>>>
>>>
>

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