Subject: Re: ABNF related feedback to: Re: AD review of draft-ietf-httpbis-alt-svc-10

From: Julian Reschke <[email-masked]>
Date: Sun, 3 Jan 2016 14:40:08 +0100

On 2015-12-31 18:00, Julian Reschke wrote:
> On 2015-12-31 17:38, Barry Leiba wrote:
>> Hi, Julian, and thanks for the quick reply on a holiday extended weekend.
>
> Dito :-)
>
>> ...
>>>> -- Section 3 --
>>>> Please consider using RFC 7405 for the ABNF for "clear".
>>>
>>> That would replace
>>>
>>>    clear         = %x63.6C.65.61.72; "clear", case-sensitive
>>>
>>> with
>>>
>>>    clear         = %s"clear"; case-sensitive
>>>
>>> (and add a dependency to the ABNF extension).
>>>
>>> I'm not super-excited about this notation, and it seems we would be the
>>> first ones to actually use it (implying lack of validation tools etc).
>>>
>>> What do others think?
>>
>> It's a small thing, and it's up to the working group, of course.  I
>> would prefer the change, because (1) I think it makes it more
>> readable, and (2) we have put 7405 on the Standards Track, so we
>> should use it.  It wouldn't be a bad thing for us to break ground on
>> it.
>
> I might invest a bit of time to teach bap (Bill's ABNF Parser) to accept
> this; and once I can validate it I could be convinced to actually use it.

Done in <https://trac.tools.ietf.org/wg/httpbis/trac/changeset/2749>...

So what does the rest of the WG think? Should we use this bleading-edge 
ABNF feature?

>>>> -- Section 3.1 --
>>>> For the persist ABNF, why 1DIGIT, and not just DIGIT?  Or, for that
>>>> matter, why not simply "1" ?  Other specifications might then add other
>>>> values using << persist =/ "2" >>, for example.
>>>
>>> I believe the intent was that new values do not imply changing the
>>> parser
>>> (which would be implied by changing the ABNF), but simply would allow
>>> new
>>> values here.
>>
>> Three questions here, really, bundled into one:
>>
>> 1. Why "1DIGIT", rather than "DIGIT"?  Purely editorial, of course...
>> what's the benefit of using the "1"?
>>
>> 2. Why does "persist" have to be digits at all?  I'm generally not a
>> fan of unnecessarily coding concepts into numbers, rather than using
>> short words.  If it's necessary (or useful), that's fine.  I don't see
>> why here.
>
> I'll pass this to those who suggested the syntax :-)
> ...

Thinking if it some more...:

1DIGIT vs DIGIT: it's really just a matter of style, I'm ok with 
changing it.

Digits: I believe it was inspired by "DNT", where of course the same 
question could be asked.

Patrick: is Firefox shipping with support for "persist" already?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Jan 2016 08:01:01 +1100

On 1 Jan 2016, at 3:38 am, Barry Leiba <[email-masked]> wrote:

>    Furthermore, if the connection to the alternative service fails or is
>    unresponsive, the client MAY fall back to using the origin or another
>    alternative service.  Note, however, that this could be the basis of
>    a downgrade attack, thus losing any enhanced security properties of
>    the alternative service.  If the connection to the alternative
>    service does not negotiate the expected protocol (for example, ALPN
>    fails to negotiate h2, or an Upgrade request to h2c is not accepted),
>    the connection to the alternative service MUST be considered to have
>    failed.
> 
> I don't understand how this stops a downgrade attack if the alternative
> service has better security than the existing connection.  The attacker
> prevents me from establishing the better security, so I consider the
> alternative service to have failed and fall back to the existing
> connection... and the attack has succeeded, blocking me from upgrading
> the security.  No?

IIRC that last sentence is NOT being offered as a mitigation of the downgrade, but instead was something added later. Perhaps just some editorial rearranging would help here.

Cheers,

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Jan 2016 09:34:17 +1100

On 4 January 2016 at 00:40, Julian Reschke <[email-masked]> wrote:
> So what does the rest of the WG think? Should we use this bleading-edge ABNF
> feature?

This seems to be a matter that comes down to editorial discretion.
And I suspect that you and Barry are the ones who care.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Jan 2016 10:20:08 +1100

> On 4 Jan 2016, at 9:34 am, Martin Thomson <[email-masked]> wrote:
> 

+1 to that.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 5 Jan 2016 19:44:10 +0100

> And I suspect that you and Barry are the ones who care.

Okay then: 
<https://github.com/httpwg/http-extensions/commit/65fa32fa5fa83bf7d52bd60f9fadcda9ba0198e0>

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jan 2016 16:40:25 +0100

On 2015-12-31 18:54, Mike Bishop wrote:
> "persist" could as easily be a toggle; either present or not, no value.  However, the existing syntax doesn't permit that, so we defined it to be =1.  In this situation, I don't see a problem with hard-coding the value into the syntax.
>
> Fundamentally, the question is, "If I see persist=2, what should I do with it?"  If I treat it as an unrecognized value, then it's equivalent to not being present, which may or may not be what the sender wanted.  That means whoever is defining persist=2 would probably have done better to define morerefinedpersist=1-4, and leave persist intact for legacy clients to understand.
>
> If you're going to have to define a new token for other values to be useful anyway, let's formalize that and hard-code that there's only one acceptable value for this one.

Sounds right to me.

Any objections to changing this to simply "1"? Or do we want to change 
it to %s"t" (for "true")?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jan 2016 16:48:34 +0100

On 2015-12-31 15:29, Julian Reschke wrote:
> ...
> ...
>>     If a client becomes aware of multiple alternative services, it MAY
>>     choose the most suitable according to its own criteria (again,
>>     keeping security properties in mind).
>>
>> 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/a9df1e33703a2cb46c9b441bfca5bbc04fff80d1>

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Sun, 10 Jan 2016 12:20:16 -0500

> <https://github.com/httpwg/http-extensions/commit/a9df1e33703a2cb46c9b441bfca5bbc04fff80d1>

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Jan 2016 15:48:38 +1100

> On 11 Jan 2016, at 2:40 am, Julian Reschke <[email-masked]> wrote:
> 
> Any objections to changing this to simply "1"?

That seems reasonable...

> Or do we want to change it to %s"t" (for "true")?

That's a breaking syntactic change at a very late stage; what benefit does it have?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Jan 2016 08:05:41 +0100

>> Any objections to changing this to simply "1"?

Ack.

> That's a breaking syntactic change at a very late stage; what benefit does it have?

The intent was to have a more readable value. Are there any 
implementations out there this would break?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Jan 2016 09:28:52 +0100

On 2016-01-11 08:05, Julian Reschke wrote:
>>>> "persist" could as easily be a toggle; either present or not, no
>>>> value.  However, the existing syntax doesn't permit that, so we
>>>> defined it to be =1.  In this situation, I don't see a problem with
>>>> hard-coding the value into the syntax.
>>>>
>>>> Fundamentally, the question is, "If I see persist=2, what should I
>>>> do with it?"  If I treat it as an unrecognized value, then it's
>>>> equivalent to not being present, which may or may not be what the
>>>> sender wanted.  That means whoever is defining persist=2 would
>>>> probably have done better to define morerefinedpersist=1-4, and
>>>> leave persist intact for legacy clients to understand.
>>>>
>>>> If you're going to have to define a new token for other values to be
>>>> useful anyway, let's formalize that and hard-code that there's only
>>>> one acceptable value for this one.
>>>
>>> Sounds right to me.
>>>

-> 
<https://github.com/httpwg/http-extensions/commit/bc0e722fc4340f89b7b2e7029f5e2c4be00d84cd>

Best regards, Julian

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Jan 2016 16:34:39 +0000

Haven't heard back from Stephen on the port-change issue we wanted him to weigh in on; I sent him a reminder.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Sunday, January 10, 2016 9:20 AM
To: Julian Reschke <[email-masked]>
Cc: [email-masked]; HTTP Working Group <[email-masked]>
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.
>

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Jan 2016 16:45:34 +0000

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

Cheers,
S.

> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Barry Leiba Sent: Sunday,
> January 10, 2016 9:20 AM To: Julian Reschke <[email-masked]> 
> Cc: [email-masked]; HTTP Working Group
> <[email-masked]> 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/a9df1e33703a2cb46c9b
>>
>> 
441bfca5bbc04fff80d1>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Jan 2016 20:31:50 +0000

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Jan 2016 22:09:47 +0000

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:[email-masked]] 
Sent: Tuesday, January 12, 2016 12:32 PM
To: Mike Bishop <[email-masked]>; Barry Leiba <[email-masked]>; Julian Reschke <[email-masked]>
Cc: [email-masked]; HTTP Working Group <[email-masked]>
Subject: Re: AD review of draft-ietf-httpbis-alt-svc-10

On 11/01/16 16:45, Stephen Farrell wrote:
> 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:

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

Cheers,
S.

>>>>> pick, so....  I think this should just say, "it chooses the most 
>>>>> suitable...."
>>>>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Jan 2016 22:31:18 +0000

(Sorry; that should be reverse proxy.  But the issue is clear, regardless of which proxy type.)

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, January 12, 2016 12:32 PM
To: Mike Bishop <[email-masked]>; Barry Leiba <[email-masked]>; Julian Reschke <[email-masked]>
Cc: [email-masked]; HTTP Working Group <[email-masked]>
Subject: Re: AD review of draft-ietf-httpbis-alt-svc-10

Cheers,
S.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Jan 2016 19:34:08 -0500

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Jan 2016 10:18:47 +0000

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 13 Jan 2016 19:16:49 +0000

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

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, January 13, 2016 2:19 AM
To: Barry Leiba <[email-masked]>; Mike Bishop <[email-masked]>
Cc: Julian Reschke <[email-masked]>; [email-masked]; HTTP Working Group <[email-masked]>
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:
>> To: Mike Bishop <[email-masked]>; Barry Leiba 
>> <[email-masked]>; Julian Reschke <[email-masked]>
>> <[email-masked]>
>>>> [mailto:[email-masked]] On Behalf Of Barry Leiba Sent: 
>>>> Sunday, January 10, 2016 9:20 AM To: Julian Reschke 
>>>> <[email-masked]>
>>>>> <https://github.com/httpwg/http-extensions/commit/a9df1e33703a2cb4
>>>>> 6c
>>>>> 9b
>>>>>
>>>>>
>>> 441bfca5bbc04fff80d1>
>>>>
>>>> any?  Whenever you're ready to post a new I-D version, I'll give it 
>>>> a check and request last call.
>>>>
>>>> Barry
>>>>
>>>
>>>
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Jan 2016 19:18:48 +0000

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

Yeah, ditto:-)

Cheers
S

> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Wednesday, January 13, 2016
> 2:19 AM To: Barry Leiba <[email-masked]>; Mike Bishop
> <[email-masked]> Cc: Julian Reschke
> <[email-masked]>; [email-masked]; HTTP
> Working Group <[email-masked]> Subject: Re: AD review of
> 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
> 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
> 
>>  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
>> 
>> 
>>> 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:[email-masked]] Sent: Tuesday, January 12,
>>> 2016 12:32 PM To: Mike Bishop <[email-masked]>;
>>> Barry Leiba <[email-masked]>; Julian Reschke
>>> <[email-masked]> Cc: [email-masked];
>>> HTTP Working Group <[email-masked]> Subject: Re: AD review
>>> of draft-ietf-httpbis-alt-svc-10
>>> 
>>> 
>>> 
>>>>> 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:-)
>>>> 
>>> "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]."
>>> 
>>> Cheers, S.
>>>> Cheers, S.
>>>>> <[email-masked]> Cc:
>>>>> [email-masked]; HTTP Working Group 
>>>>>>>> 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.
>>>>>> 
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
>>>>> 
>>>> 
>>>> 
>>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 Jan 2016 14:27:36 +1100

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 <[email-masked]> wrote:
> 
> 
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Jan 2016 14:07:42 -0500

> I think that this stops that attack if http client also checks
> /.well-known/alternative-services when alternative service
> does not provide strong auth. This of course adds additional delay
> before alternative service is used but does not affect case
> where alternative services is used for opportunistic security
> (I assume strong auth here and therefore
> GET /.well-known/alternative-services is not needed).

No, with opportunistic encryption you *don't* have strong auth --
that's part of what makes it opportunistic.

Barry

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Jan 2016 19:10:33 +0000

But on the other hand, a publisher who wanted to enable opportunistic could publish /.well-known/alternative-services easily enough.

In that it closes the ability for one resource owner to claim authority over the entire machine, I like it.  It seems like a reasonable middle ground between always requiring strong auth and leaving things totally open.  A more effective middle ground than looking at port numbers, certainly.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Friday, January 15, 2016 11:08 AM
To: Kari Hurtta <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; Mike Bishop <[email-masked]>; Julian F. Reschke <[email-masked]>; [email-masked]; HTTP Working Group <[email-masked]>; Stephen Farrell <[email-masked]>
Subject: Re: (Possibly duplicate mail) Suggesting /.well-known/alternative-services as compromise | Re: AD review of draft-ietf-httpbis-alt-svc-10

> /.well-known/alternative-services when alternative service does not 
> provide strong auth. This of course adds additional delay before 
> alternative service is used but does not affect case where alternative 
> services is used for opportunistic security (I assume strong auth here 
> and therefore GET /.well-known/alternative-services is not needed).

No, with opportunistic encryption you *don't* have strong auth -- that's part of what makes it opportunistic.

Barry

---

From: Chris Bentzel <[email-masked]>
Date: Fri, 15 Jan 2016 21:04:14 +0000

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 <[email-masked]> 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,
>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Jan 2016 21:09:59 +0000

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:[email-masked]]
Sent: Friday, January 15, 2016 1:04 PM
To: Mark Nottingham <[email-masked]>; Stephen Farrell <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Barry Leiba <[email-masked]>; Julian F. Reschke <[email-masked]>; [email-masked]; HTTP Working Group <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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.

Cheers,

> On 14 Jan 2016, at 6:18 am, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
>> that alternative must then authenticate itself as users.example.com<http://users.example.com>
>> [mailto:[email-masked]<mailto:[email-masked]>] Sent: Wednesday, January 13, 2016
>> 2:19 AM To: Barry Leiba <[email-masked]<mailto:[email-masked]>>; Mike Bishop
>> <[email-masked]<mailto:[email-masked]>> Cc: Julian Reschke
>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; HTTP
>> Working Group <[email-masked]<mailto:[email-masked]>> Subject: Re: AD review of
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>> [mailto:[email-masked]<mailto:[email-masked]>] Sent: Tuesday, January 12,
>>>> 2016 12:32 PM To: Mike Bishop <[email-masked]<mailto:[email-masked]>>;
>>>> Barry Leiba <[email-masked]<mailto:[email-masked]>>; Julian Reschke
>>>> <[email-masked]<mailto:[email-masked]>> Cc: [email-masked]<mailto:[email-masked]>;
>>>> HTTP Working Group <[email-masked]<mailto:[email-masked]>> Subject: Re: AD review
>>>>>> -----Original Message----- From: [email-masked]<mailto:[email-masked]>
>>>>>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Barry Leiba Sent:
>>>>>> <[email-masked]<mailto:[email-masked]>> Cc:
>>>>>> [email-masked]<mailto:[email-masked]>; HTTP Working Group
>>>>>> <[email-masked]<mailto:[email-masked]>> Subject: Re: AD review of

---

From: Chris Bentzel <[email-masked]>
Date: Fri, 15 Jan 2016 21:22:54 +0000

That seems reasonable.

On Fri, Jan 15, 2016 at 4:10 PM Mike Bishop <[email-masked]>
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:[email-masked]]
> *Sent:* Friday, January 15, 2016 1:04 PM
> *To:* Mark Nottingham <[email-masked]>; Stephen Farrell <
> [email-masked]>
> *Cc:* Mike Bishop <[email-masked]>; Barry Leiba <
> [email-masked]>; Julian F. Reschke <[email-masked]>;
> [email-masked]; HTTP Working Group <
> [email-masked]>
>
>
> *Subject:* Re: AD review of draft-ietf-httpbis-alt-svc-10
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 16 Jan 2016 12:00:59 +1100

Does that suggest an "unless" or a rewrite to something like:

Clients that wish to prevent requests from being correlated (such as
those that offer modes aimed at providing improved privacy) SHOULD NOT
use alternative services for multiple requests that would not
otherwise be allowed to be correlated.

On 16 January 2016 at 08:22, Chris Bentzel <[email-masked]> wrote:
>> 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.
>>
>>
>>
>> Cc: Mike Bishop <[email-masked]>; Barry Leiba
>> <[email-masked]>; Julian F. Reschke <[email-masked]>;
>> 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.
>>
>> 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.
>>

---

From: Patrick McManus <[email-masked]>
Date: Fri, 15 Jan 2016 23:15:09 -0500

I like that rewrite.

On Fri, Jan 15, 2016 at 8:00 PM, Martin Thomson <[email-masked]>
wrote:

> identity
> listen
> other
> >> > On 14 Jan 2016, at 6:18 am, Stephen Farrell <
> >> >>>>>>> <
> https://github.com/httpwg/http-extensions/commit/a9df1e33703a2cb4
> >> >>>>>>>
> >> >>>>>>>
> >> > 6c
> >> >>>>>>> 9b
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>> 441bfca5bbc04fff80d1>
> >> >>>>>>

---

From: Chris Bentzel <[email-masked]>
Date: Fri, 15 Jan 2016 23:16:34 -0500

+1

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Jan 2016 23:25:57 -0500

> I like that rewrite.

As do I.

Barry

> On Fri, Jan 15, 2016 at 8:00 PM, Martin Thomson <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> On 16 January 2016 at 08:22, Chris Bentzel <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> > That seems reasonable.
>> >
>> > On Fri, Jan 15, 2016 at 4:10 PM Mike Bishop <
>> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> > wrote:
>> >>
>> >> From: Chris Bentzel [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
>> >> To: Mark Nottingham <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Stephen Farrell
>> >> <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> >> Cc: Mike Bishop <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Barry
>> Leiba
>> >> <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Julian F.
>> Reschke <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
>> >> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
>> HTTP Working Group
>> >> <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> >>
>> >>
>> >> On Thu, Jan 14, 2016 at 10:32 PM Mark Nottingham <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> >>
>> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> >> > wrote:
>> >> >
>> >> >
>> >> >
>> >> >> [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] Sent:
>> Wednesday, January 13, 2016
>> >> >> 2:19 AM To: Barry Leiba <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Mike Bishop
>> >> >> <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> Cc:
>> Julian Reschke
>> >> >> <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
>> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
>> HTTP
>> >> >> Working Group <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> Subject: Re: AD
>> review of
>> >> >>> <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> >> >>>> [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] Sent:
>> Tuesday, January 12,
>> >> >>>> 2016 12:32 PM To: Mike Bishop <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
>> >> >>>> Barry Leiba <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Julian
>> Reschke
>> >> >>>> <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> Cc:
>> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
>> >> >>>> HTTP Working Group <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> Subject: Re: AD
>> review
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> >> >>>>>> [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] On Behalf Of
>> Barry Leiba Sent:
>> >> >>>>>> <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> Cc:
>> >> >>>>>> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
>> HTTP Working Group
>> >> >>>>>> <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> Subject: Re: AD
>> review of

---

From: Julian Reschke <[email-masked]>
Date: Sat, 16 Jan 2016 10:19:56 +0100

> otherwise be allowed to be correlated.

I note that this proposal was triggered by a discussion about text 
that's not in the current spec. Anyway, is this supposed to go into 9.4 
("Tracking Clients Using Alternative Services", 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-alt-svc-10.html#tracking>), 
replacing the current statement:

"Clients concerned by the additional fingerprinting can choose to ignore 
alternative service advertisements."

?

In which case I'd avoid the normative SHOULD NOT that is conditional on 
a wish :-). Such as:

"Clients that wish to prevent requests from being correlated (such as
those that offer modes aimed at providing improved privacy) can decide 
not to use alternative services for multiple requests that would not
otherwise be allowed to be correlated."

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jan 2016 15:12:27 +1100

SGTM.

> On 16 Jan 2016, at 8:19 pm, Julian Reschke <[email-masked]> wrote:
> 
> I note that this proposal was triggered by a discussion about text that's not in the current spec. Anyway, is this supposed to go into 9.4 ("Tracking Clients Using Alternative Services", <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-alt-svc-10.html#tracking>), replacing the current statement:
> 
> "Clients concerned by the additional fingerprinting can choose to ignore alternative service advertisements."
> 
> ?
> 
> In which case I'd avoid the normative SHOULD NOT that is conditional on a wish :-). Such as:
> 
> those that offer modes aimed at providing improved privacy) can decide not to use alternative services for multiple requests that would not