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

Barry Leiba <barryleiba@computer.org> Thu, 31 December 2015 06:43 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A521A86F2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Dec 2015 22:43:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.39
X-Spam-Level:
X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ya_s8ENgQ49 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Dec 2015 22:43:20 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862C81A86F1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Dec 2015 22:43:20 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aEWtJ-0007v5-EB for ietf-http-wg-dist@listhub.w3.org; Thu, 31 Dec 2015 06:39:17 +0000
Resent-Date: Thu, 31 Dec 2015 06:39:17 +0000
Resent-Message-Id: <E1aEWtJ-0007v5-EB@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <barryleiba@gmail.com>) id 1aEWt5-0007uK-R4 for ietf-http-wg@listhub.w3.org; Thu, 31 Dec 2015 06:39:03 +0000
Received: from mail-vk0-f44.google.com ([209.85.213.44]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <barryleiba@gmail.com>) id 1aEWt3-0003BQ-D9 for ietf-http-wg@w3.org; Thu, 31 Dec 2015 06:39:03 +0000
Received: by mail-vk0-f44.google.com with SMTP id k1so86253718vkb.2 for <ietf-http-wg@w3.org>; Wed, 30 Dec 2015 22:38:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=qwDV/COv/5BB0obIHa8k8LehmQtexzRgiMqJU82u2Mk=; b=umj8Et8JAMJl3qJBUzfoZ2C1vg4gMJqsc5z08zd2SFmx4oCIFT/Mw2v9hR9lfWZVLu OhainUw7DfccRFWOZYUo4TuLREcU37d1rC8LLn2m7cvpRopOdQA0vzk7a/p8f2JMvOG9 yg5Uh+tWbzt6hayV30M3ohjW8P7K1y/+qK/6IGEJAKEb7kj0+i9H5/S/2N01G/Ua+AKx 9TlEUKE+mj2xR8mOrOJtBdYaHZtWzErAeIy+BucEZKvOqDsmEI5gndAOAIoTmdIzs1b0 tqUx25lmaTaHFFSsWYhKryPt/4llc29WjHB7fc4iyW1UoksbnVVyjAp++zyswKmLzCgP 9SNw==
MIME-Version: 1.0
X-Received: by 10.31.47.70 with SMTP id v67mr40108224vkv.130.1451543915148; Wed, 30 Dec 2015 22:38:35 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.31.182.211 with HTTP; Wed, 30 Dec 2015 22:38:35 -0800 (PST)
Date: Thu, 31 Dec 2015 01:38:35 -0500
X-Google-Sender-Auth: gWFLa_-UxnVgXl7LgqYkN8u_xcE
Message-ID: <CALaySJK5fYy_JCv0Y7Fs3QpPk95fUxyt272JMc-QUpVKO7_gJA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: draft-ietf-httpbis-alt-svc@ietf.org
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a1143ebc2703ce505282be75e"
Received-SPF: pass client-ip=209.85.213.44; envelope-from=barryleiba@gmail.com; helo=mail-vk0-f44.google.com
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, HTML_MESSAGE=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: maggie.w3.org 1aEWt3-0003BQ-D9 8e083828bc26a827b57d9bdfd2a2aa0e
X-Original-To: ietf-http-wg@w3.org
Subject: AD review of draft-ietf-httpbis-alt-svc-10
Archived-At: <http://www.w3.org/mid/CALaySJK5fYy_JCv0Y7Fs3QpPk95fUxyt272JMc-QUpVKO7_gJA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30831
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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

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

   alt-authority = quoted-string ; containing [ uri-host ] ":" port

This seems poor.   Why not this?:

NEW
   alt-authority = DQUOTE [ uri-host ] ":" port DQUOTE
END

   The field value consists either of a list of values, each of which
   indicating one alternative service, or the keyword "clear".

Typo: "indicates"

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

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

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

--
Barry