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

Julian Reschke <> Thu, 31 December 2015 14:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A64661A88F1 for <>; Thu, 31 Dec 2015 06:33:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lCkRRe4l5_3a for <>; Thu, 31 Dec 2015 06:33:03 -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 372111A88EF for <>; Thu, 31 Dec 2015 06:33:03 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1aEeF6-0000Jn-Fi for; Thu, 31 Dec 2015 14:30:16 +0000
Resent-Date: Thu, 31 Dec 2015 14:30:16 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aEeEz-0000J2-Sk for; Thu, 31 Dec 2015 14:30:09 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1aEeEx-00039m-7m for; Thu, 31 Dec 2015 14:30:09 +0000
Received: from [] ([]) by (mrgmx103) with ESMTPSA (Nemesis) id 0Lcjdr-1ZnWpA46Vj-00kAZg; Thu, 31 Dec 2015 15:29:32 +0100
To: Barry Leiba <>,
References: <>
Cc: HTTP Working Group <>
From: Julian Reschke <>
Message-ID: <>
Date: Thu, 31 Dec 2015 15:29:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:E3ZAf5SKqeuLzhpvailarVRb6ZkjBJAMdR3B74Ny4xd8UoLdrBp xbXsx28NwBCg+6jkq3q0PfXEuDlSuqBBpm6Lyv6kxqA9Z51lYm+GOtOYRXccv5vjkGWekYK BYV9g46Zp5GHAfSpEf8QCLTRHlcloX284KG/u8fsmWFPXK9ofH5MXKWZXXNNcLyaH41PYy6 yYCE/iwDax1aIZyobbl4g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:qw5GsEEirU0=:/691smBzEMKDTyB++3avPu U7/cyqpa+FpdspwElX0Ykbra44X2WAKmPLC3ozl6blmowNz/wGal5jXDdfSOVAMgYGX6SR23O WXcUFtwFWL4MfaiO4nG9QpOPKlggFiaD+xiExhsqVxwPme5uNS6jyeIZHcC4YEsIzZAi8qrzT s9p5tm5xRSg3UXrnaO6/H/z1Sek9QIP8ewOjAWYgkRvu+ZY3A/wztFgzqhC+/XsRezSL0TgpA H3ELbk1tSb6AEWQuzLc9XJEiWL1Zrx3hmrOmmbB6ik6e7hs0IKrm2K8p1CYSs4BkANeH7SNeT uujNzxBVCdBZEvE9QsaVEaEshCrKWWmzE2EJ3kpaR5leFVi0DRV3KcF3TDFjunl7YvhL38+Ti g3due+N2apHLvpa8AMuQAr9zQqGI9BJDEWxzb38g11/0y+Jntsv2beH56+M1/tXdjCcrYqZd/ jmiVJrcgNzLm49TCPo3hdYFpHOMls4UOjW/g8M1Rgow9cqlwuI4pZBrbEeXtmw+di8Ev70C7l uwX7h6MEJfN+vW3S+i9uOVTumR4mrWRXIpWGP/B0O1Lq2HTuK7qJDtaA4XAga37y5iSDe5hT2 wF1TBiy6McXEuUgOUJRlYAGndi5dxghZ5jXEBNOXS4jFMctH7MxZdG2wzwOAJHa+RKJFMiKys wdkWl/J068ReTeSavrs3kbEz1uGSylVixDNSc1efoAn8O+U9ezGiomm9DY9ZA5xPo1QatBjXK GyoSzO4xyoNW5KO0F7ge8/6hVvXaOcoiiaASPSXvSl7PAMgBuCK71MuyK7JYDkVR2n3j+qpnZ mtMvQoJ
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.427, BAYES_00=-1.9, 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: 1aEeEx-00039m-7m 24d0701f60f8e5d06803506a69c52589
Subject: Re: AD review of draft-ietf-httpbis-alt-svc-10
Archived-At: <>
X-Mailing-List: <> archive/latest/30833
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Barry,

thanks for the feedback; I'm tracking the changes in 

On 2015-12-31 07:38, Barry Leiba wrote:
> Some comments, none very serious.  Let's have a quick chat about the
> non-editorial ones before I send out the last call request.  And thanks,
> Mike Bishop, for the really good and helpful shepherd writeup.


> -- Section 2.1 --
>     Clients MUST NOT use alternative services with a host that is
>     different than the origin's without strong server authentication;
> Total nit: make it "different from", not "different than".


> -- Section 2.4 --
>     By their nature, alternative services are OPTIONAL: clients do not
>     need to use them.  However, it is advantageous for clients to behave
>     in a predictable way when they are used by servers (e.g., for load
>     balancing).
> The antecedent to the last "they" is unclear: it looks like it's
> "clients", when it should be "alternative services".  Best to re-word,
> as " a predictable way when alternative services are used by
> servers...."


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

>     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?
> -- Section 3 --
> Please consider using RFC 7405 for the ABNF for "clear".

That would replace

   clear         = %x63.6C.65.61.72; "clear", case-sensitive


   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?

>     alt-authority = quoted-string ; containing [ uri-host ] ":" port
> This seems poor.   Why not this?:
>     alt-authority = DQUOTE [ uri-host ] ":" port DQUOTE

In HTTP specs, we don't like to use DQUOTE unless the thing being quoted 
used quoted-string syntax.

>     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 

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

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

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

Best regards, Julian