Re: [Gen-art] Genart last call review of draft-ietf-httpbis-origin-frame-04

Mark Nottingham <mnot@mnot.net> Sun, 26 November 2017 23:38 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661FB126DCA for <gen-art@ietfa.amsl.com>; Sun, 26 Nov 2017 15:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=rxk6Q03A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ifmWycs+
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 UFeiQU1UrwIB for <gen-art@ietfa.amsl.com>; Sun, 26 Nov 2017 15:38:50 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42A31200C1 for <gen-art@ietf.org>; Sun, 26 Nov 2017 15:38:49 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2C6A920C0A; Sun, 26 Nov 2017 18:38:49 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 26 Nov 2017 18:38:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=OsdamRrxoI4ZQZYJuBHrN75gz5P+O 9wwdEOczbWvsdw=; b=rxk6Q03AOH+637Y+C3B9H1WwwrYyPWW6nNhT3qUxVPGhz WRTQkKrwsy6ukxOGvfPyHLSpXBeI3k9aDjUiYLZ1Ag2k4DIXdOp07NizpgCtUd/m p2LAZnePPw0Oaz8oI3WMBlEQm1R4i0chyBjGufHrIK59XvPBVbX/9eerUtegf33M tKNC3krpwH76CLA67ZLW2j/iNp/I0LfcUBPJt+5/Rfs4fcWjPowBMY91puyJh8+E L/GpTG00egGvHrJoqyeJ63+CCNnseaLhQuB3uwo2TC9HXd2x2xVZn9dEQB4j5tFd 4gJdv0kcT3kkUa7j2sB1caJ5RPIB4m5AoLkin+wmg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=OsdamR rxoI4ZQZYJuBHrN75gz5P+O9wwdEOczbWvsdw=; b=ifmWycs+bAwe3wbmwAwtWb ZrRvkL5e74pQslz44+UYxHZHJhxA+5G09NU/QAgLbEKUG7Zu8SqqVdVtcw5t4LkE TbIZuNOWlmnIeVE3mk9i7Bjuiv0xWKxmjtIn25xjJW8oDEG4DjqhJouI0VJJXbJf 9RhtDhpi7LZBuZBD+rjvJuNy8qbRYlPw/a7hx6d2qeRUzaRmflZfWt+/WWsa1Ggx FJaE9hHb8FAdlDp9y1IURN7aLbQv7UoBYuBxk88+vUwUZ7qASOHmkpIUCdFm/rk9 20V+1qORtugS0F8TmfsPLNV44hRf++k2bBSp0mT4dcopyrdAttTkVZUeujovvACg ==
X-ME-Sender: <xms:iVAbWpyg37MKorwi1bAexkezgBXpG1E3QPmWAj0kdgLdJiW6motdzw>
Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id E5A5A7FA6A; Sun, 26 Nov 2017 18:38:47 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <151166787103.16046.10259096251205147245@ietfa.amsl.com>
Date: Mon, 27 Nov 2017 10:38:43 +1100
Cc: gen-art@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3172984-2411-4AB0-B53D-8DC4800B51AA@mnot.net>
References: <151166787103.16046.10259096251205147245@ietfa.amsl.com>
To: Brian Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/SMQ9RWNxE9WgviYsn64coUOw0Fs>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-httpbis-origin-frame-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Nov 2017 23:38:52 -0000

Hi Brian,

Thanks for the review. Responses below.

> On 26 Nov 2017, at 2:44 pm, Brian Carpenter <brian.e.carpenter@gmail.com>; wrote:
[...]
> Minor Issues:
> -------------
> 
>> 2.1.  Syntax
> ...
>> Origin: An OPTIONAL sequence of characters ... that the
>> sender believes this connection is or could be authoritative for.
> 
> So, that implies that all data in the ORIGIN frame might be false.
> Doesn't that deserve a bit of a health warning at the beginning of the
> Security Considerations?

The first paragraph of SC is already:

"""
   Clients that blindly trust the ORIGIN frame's contents will be
   vulnerable to a large number of attacks.  See Section 2.4 for mitigations.
"""

What would you suggest?

> Also, using the word "believes" of a server
> is strange. How would the server acquire uncertain knowledge in the
> first place, and what algorithm would decide what it "believes"?

This is to emphasise that ORIGIN is advisory only -- it does not constitute proof (crypto does that).


> Appendix A doesn't show any sign of a client checking whether an
> Origin-Entry is real.

As per Section 2.4, it isn't checked when the origin set is created or updated; it's checked when the value is used.


>> 2.3.  The Origin Set
> ...
>>  o  Host: the value sent in Server Name Indication (SNI, [RFC6066]
>>     Section 3), converted to lower case
> 
> In that reference:
> 
>>> Literal IPv4 and IPv6 addresses are not permitted in "HostName".
> 
> Is that an intended or unintended restriction for the ORIGIN frame?
> In any case it should probably be mentioned explicitly to avoid confusion.
> (If IPv6 literals were allowed, they might be very convenient for server
> load balancing. But RFC6066 excludes that.)

Good catch. I don't think there's cause for confusion here (the text there isn't about what can go on the wire), but there is a corner case we haven't covered (when a client that supports SNI omits it because it's an IP literal). 

My inclination there is to say that the host is the SNI value or the server IP if SNI is missing; what do people think?

Cheers,

--
Mark Nottingham   https://www.mnot.net/