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

Thanks for the details, Mike.  Maybe it'd be good to loop Stephen
Farrell in here, and see whether he's OK with what's there, or has
other suggestions.

Barry

On Thu, Dec 31, 2015 at 12:45 PM, Mike Bishop
<Michael.Bishop@microsoft.com> wrote:
> As to the system versus user port, that's an artifact of one of those security wranglings I mentioned in the write-up.  I remember working on servers where two things were true:
>
>   - I could host arbitrary content at host.example.com/~username
>   - I could run a process to listen on another port
>
> I was not the server administrator, but there's no way for Alt-Svc to be scoped to a portion of the domain if the content owner is allowed to affect the headers.  An Alt-Svc client talking to such a (legacy, unmodified) server would permit the content owner to hijack traffic intended for other content owners in the future.  Scenarios where new capabilities on the client can be attacked when talking to unmodified servers make me twitch.
>
> The original text in the draft was that servers should either prohibit non-admins from adding an Alt-Svc header or prevent non-admins from accepting incoming connections.  One is a retroactive requirement imposed on legacy servers set up before this draft existed; the other doesn't seem realistic for certain classes of machine.  Those aren't effective mitigations, in my opinion.
>
> My contention was that we should require strong auth for any change of endpoint, to close attacks like this.  However, the Opp-Sec draft relies on Alt-Svc *not* requiring strong auth to change ports on the same host, and that change would break Opp-Sec in the form that consensus is/was pushing it.  The system/user port split was a compromise that I'm still only marginally happy with, but that's where we are.
>
> If there's less consensus now on keeping a hole open for Opp-Sec to crawl through, I'd be thrilled to see that tightened back up.
>
> -----Original Message-----
> From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba
> Sent: Thursday, December 31, 2015 8:39 AM
> To: Julian Reschke <julian.reschke@gmx.de>
> Cc: 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
>
> Hi, Julian, and thanks for the quick reply on a holiday extended weekend.
>
> Only on the items for which I have further comment...
>
>>>     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?
>
> I didn't see a response to this.  I expect we might see comments about this from the Security Directorate or ADs.
>
>>> -- 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.
>
>>>     alt-authority = quoted-string ; containing [ uri-host ] ":" port
>>>
>>> This seems poor.   Why not this?:
>>>
>>> NEW
>>>     alt-authority = DQUOTE [ uri-host ] ":" port DQUOTE END
>>
>> In HTTP specs, we don't like to use DQUOTE unless the thing being
>> quoted used quoted-string syntax.
>
> I don't understand that.  I particularly don't understand why we'd prefer to specify the content of the string only in the comment, when it's perfectly easy and clear to put it into the ABNF, and have it be verifiable.
>
> I'm generally not a fan of putting substantive ABNF information into ABNF comments, and prefer to reserve that sort of thing for cases when it's *not* reasonable to do otherwise.
>
>>>     The field value consists either of a list of values, each of which
>>>     indicating one alternative service, or the keyword "clear".
>>>
>>> Typo: "indicates"
>>
>> That wasn't a typo, but as you are at least the second one complaining
>> I changed it in
>> <https://github.com/httpwg/http-extensions/commit/cc7946abe12ce8c4cd3db1bd1f8a7c2e71eb9943>.
>
> Thanks.  To clarify, it could go either of these ways, and they're equally good:
>
> - "The field value consists either of a list of values, each of which indicates one alternative service"
>
> - "The field value consists either of a list of values, each indicating one alternative service"
>
> ...but "each of which indicating" doesn't work.
>
>>> -- 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.
>
> 3. Do you expect a lot of additional values?  Clearly not, if you're limiting it to ten possible ones.  In that case, as above, I prefer when the ABNF is specific about it.  Consider, for example, RFC 2045's definition of Content-Transfer-Encoding (in Section 6.1):
>
>      encoding := "Content-Transfer-Encoding" ":" mechanism
>
>      mechanism := "7bit" / "8bit" / "binary" /
>                   "quoted-printable" / "base64" /
>                   ietf-token / x-token
>
> Here, "mechanism" could have just been defined as << ietf-token / x-token >>, but enumerating the existing values in the ABNF is useful.
> And the fact is that "persist=2" is not currently valid.
>
> There's also, I suppose, the question of whether you'd want "persist=2" to be considered acceptable (and ignored), and "persist=a"
> to cause the whole field to be rejected as invalid.  If so, maybe this, to specify what's valid now and how to extend?:
>
>    persist = "1" / persist-ext
>    persist-ext = DIGIT ; extensions can be specified in future
>
>>> -- Section 9.1 --
>>> The third paragraph assumes that system ports are inherently more
>>> secure than user ports, and, as discussion during the development of
>>> RFC 6335 raised, that hasn't been the case for some time.  Many
>>> systems no longer make a distinction, and no longet require root
>>> authority to listen on system ports.
>>
>> I have no opinion on this. More feedback appreciated.
>
> There was, of course, nothing actionable in my comment, so let me add something here: Because I think there's little value in telling clients to be more strict about authentication when switching from a system port to a user port, I think it could give a false sense of security if implementors do that... particularly if they think they can be lax about authentication on system ports, because only trusted software can listen on system ports.  We should be careful about giving that impression.
>
> Yes, more feedback from others, please.
>
>>> -- Section 9.4 --
>>>
>>>     Clients concerned by the additional fingerprinting can choose to
>>>     ignore alternative service advertisements.
>>>
>>> Is there really any chance of this being exposed to users as an option?
>>> Maybe it'd be good to add to this something like, "In particular,
>>> clients configured for anonymous usage SHOULD NOT use alternative
>>> services." ?
>>
>>
>> That's an interesting proposal. What do the client implementers think?
>
> And I'm leaving this in the message just to encourage further discussion as people <strike>sober up</strike> return from their new year's celebrations.
>
> Barry
>

Received on Thursday, 31 December 2015 17:54:48 UTC