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

Barry Leiba <> Thu, 31 December 2015 16:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A12A81A21A9 for <>; Thu, 31 Dec 2015 08:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.29
X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2UJgmEUFe4t2 for <>; Thu, 31 Dec 2015 08:43:09 -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 882981A2119 for <>; Thu, 31 Dec 2015 08:43:09 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1aEgGA-0000Ul-St for; Thu, 31 Dec 2015 16:39:30 +0000
Resent-Date: Thu, 31 Dec 2015 16:39:30 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aEgG3-0000Tp-Qc for; Thu, 31 Dec 2015 16:39:23 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aEgG1-000504-O4 for; Thu, 31 Dec 2015 16:39:23 +0000
Received: by with SMTP id k1so91116139vkb.2 for <>; Thu, 31 Dec 2015 08:39:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QnxlB2zX+lSxG4EpVzPKJXXVSBCM8nq0YHE2pc6Nmhk=; b=MNe4plqbn4p47ucoiCyYdoFNZVA1oIbfmWyJr+Jz49C1vAyOLfQ5bllYSpjTANkXy+ 8sMWgnLxOThlTJN28/VEM629khi9midoJa/AylgerZ5lSGFMImU0DQu0TsRZ57eK+muo 5PTvRu7UchCaT2X1Ia8mtiKEJcI6ObjXrqdHKDLTvFx9zbXJTV7HlR720a3w6Q11NoI9 fM9uitq9mNuqaJUn3lKAuhw4ztBlncZR+AjQDYsGycY4NN4arpmVUJFIU1TsdHpTfBrW Bunt6Ihz/5UsY/UtxViuiWp0xA7CvHKmKlMr6n5sPdhc8iI5CTwIAwahgSgsKSe4M6cJ +f3Q==
MIME-Version: 1.0
X-Received: by with SMTP id m191mr47842297vkf.102.1451579935865; Thu, 31 Dec 2015 08:38:55 -0800 (PST)
Received: by with HTTP; Thu, 31 Dec 2015 08:38:55 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 31 Dec 2015 11:38:55 -0500
X-Google-Sender-Auth: 76QWBS5xcm2NJafOPYAoG4oHEc0
Message-ID: <>
From: Barry Leiba <>
To: Julian Reschke <>
Cc:, HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.7
X-W3C-Hub-Spam-Report: AWL=1.900, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1aEgG1-000504-O4 4dd569a08246649f2d4391b9d291f3f3
Subject: Re: AD review of draft-ietf-httpbis-alt-svc-10
Archived-At: <>
X-Mailing-List: <> archive/latest/30834
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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

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

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.