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

Stephen Farrell <> Wed, 13 January 2016 10:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E784F1A1A30 for <>; Wed, 13 Jan 2016 02:23:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ilsXZ-yTczRL for <>; Wed, 13 Jan 2016 02:23:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5F391A1A33 for <>; Wed, 13 Jan 2016 02:23:27 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1aJIWO-0004Ta-5J for; Wed, 13 Jan 2016 10:19:20 +0000
Resent-Date: Wed, 13 Jan 2016 10:19:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aJIWI-0004RV-9U for; Wed, 13 Jan 2016 10:19:14 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1aJIWG-00060o-9c for; Wed, 13 Jan 2016 10:19:13 +0000
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16926BE8A; Wed, 13 Jan 2016 10:18:48 +0000 (GMT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bS0TL5wUfov4; Wed, 13 Jan 2016 10:18:47 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 75789BE80; Wed, 13 Jan 2016 10:18:47 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1452680327; bh=7O/P5sD6FYoFOXDEM7HH0FJzn4Dq4u74JtjoE2i2zn0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=HAgW8s8YujFM9iwaq/ZULBcNTs3Zo9MZJ26vw4TqcxG4/BOyQD64/jdTXIG65c1b1 uDmJy2K//tS5/Bj2tbXYsRrq05bEEUR0J4N6YpKcDueMcR69utI3zO6B99r+41ZK8t poGIOBpS0RMKmaHYkbGSlbhSZ1y6RFGImYYqYUpQ=
To: Barry Leiba <>, Mike Bishop <>
References: <> <> <> <> <> <> <> <> <>
Cc: Julian Reschke <>, "" <>, HTTP Working Group <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 13 Jan 2016 10:18:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.6
X-W3C-Hub-Spam-Report: AWL=1.750, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1aJIWG-00060o-9c c051c55b5a5506115def48cc9b68bfc5
Subject: Re: AD review of draft-ietf-httpbis-alt-svc-10
Archived-At: <>
X-Mailing-List: <> archive/latest/30918
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


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.


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
> <> wrote:
>> More whether you're okay with that text as mitigation to this hypothetical attack:
>> 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 announcing an alternative service for on port 23412.  Bob is using an Alt-Svc-capable browser.  After Bob has visited, he visits  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 []
>> Sent: Tuesday, January 12, 2016 12:32 PM
>> To: Mike Bishop <>; Barry Leiba <>; Julian Reschke <>
>> Cc:; HTTP Working Group <>
>> 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:
>>>> [] On Behalf Of Barry Leiba Sent: Sunday,
>>>> January 10, 2016 9:20 AM To: Julian Reschke <>
>>>> Cc:; HTTP Working Group
>>>> <> 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.
>>>>> <
>>>>> 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