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

[Chris Bentzel <[e-mail]>]

That seems reasonable.

On Fri, Jan 15, 2016 at 4:10 PM Mike Bishop <[e-mail]>
wrote:

> 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:[e-mail]]
> *Sent:* Friday, January 15, 2016 1:04 PM
> *To:* Mark Nottingham <[e-mail]>; Stephen Farrell <
> [e-mail]>
> *Cc:* Mike Bishop <[e-mail]>; Barry Leiba <
> [e-mail]>; Julian F. Reschke <[e-mail]>;
> [e-mail]; HTTP Working Group <
> [e-mail]>
>
>
> *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 <[e-mail]> 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 <[e-mail]>
> 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
> >> (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:[e-mail]] Sent: Wednesday, January 13, 2016
> >> 2:19 AM To: Barry Leiba <[e-mail]>; Mike Bishop
> >> <[e-mail]> Cc: Julian Reschke
> >> <[e-mail]>; [e-mail]; HTTP
> >> Working Group <[e-mail]> 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
> >>> <[e-mail]> 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:[e-mail]] Sent: Tuesday, January 12,
> >>>> 2016 12:32 PM To: Mike Bishop <[e-mail]>;
> >>>> Barry Leiba <[e-mail]>; Julian Reschke
> >>>> <[e-mail]> Cc: [e-mail];
> >>>> HTTP Working Group <[e-mail]> 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: [e-mail]
> >>>>>> [mailto:[e-mail]] On Behalf Of Barry Leiba Sent:
> >>>>>> Sunday, January 10, 2016 9:20 AM To: Julian Reschke
> >>>>>> <[e-mail]> Cc:
> >>>>>> [e-mail]; HTTP Working Group
> >>>>>> <[e-mail]> 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/
>
>
>
>
>