Re: [secdir] Secdir last call review of draft-ietf-httpbis-early-hints-03

Stefan Eissing <stefan.eissing@greenbytes.de> Fri, 07 July 2017 11:44 UTC

Return-Path: <stefan.eissing@greenbytes.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971B112EA7C; Fri, 7 Jul 2017 04:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=FK0WGOGU; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=MQie0i0t
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 9Jl7l4J-KUfb; Fri, 7 Jul 2017 04:44:23 -0700 (PDT)
Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F6B129AD2; Fri, 7 Jul 2017 04:44:22 -0700 (PDT)
Received: by mail.greenbytes.de (Postfix, from userid 117) id 9FEA615A3BC2; Fri, 7 Jul 2017 13:44:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1499427860; bh=0mXG+i6vAshXeCMWrnXN6xMGBPErEjzMWIY/WYLK54w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=FK0WGOGUzTLJiNzoqRpOB2wK6gBnNfFntSsDruDyceZc92Ww6FE7lFC7vl0Ukdrbt 1QgvlZZ55kq0OxU3ZwABUU/FRPqFhMREhK2KXJonrPuM20xCJj9g1jMwHsvK1m4OHw BIhfPhMUqunH/g5XgfwwJXUNlUkWBwipAyKuiuXs=
Received: from resistance.greenbytes.local (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 7342815A0221; Fri, 7 Jul 2017 13:44:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1499427859; bh=0mXG+i6vAshXeCMWrnXN6xMGBPErEjzMWIY/WYLK54w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MQie0i0taoJuO8AHwqH4QtSVOXq1oO0KNeiBaUttj8PPlqW+QRX6lH6e/eZg7ubT+ 5RBpMqFyR1PIi9Z7xNZUze+f7M10/GN1RckvM9S/IR3FICTflHyb9IcCVFJkNGlr7W HwyePHYRaNE9g/RL5nocMirsktNtyujtlfJUppIU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <CANatvzygATN6Rd7nGPuGLSpbYs65TV01BFMFrB9Atq1ojcXHJQ@mail.gmail.com>
Date: Fri, 7 Jul 2017 13:44:19 +0200
Cc: Willy Tarreau <w@1wt.eu>, Melinda Shore <melinda.shore@gmail.com>, secdir@ietf.org, draft-ietf-httpbis-early-hints.all@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AA1F7609-89D8-4199-AFF7-8880637DFF01@greenbytes.de>
References: <149919703750.15996.5462759432298024921@ietfa.amsl.com> <CANatvzx8GsvoYMscHciKNrOwRzcz1v7=jTCUUp4Z5E=jO9Wd6g@mail.gmail.com> <7273f8ab-c1ff-5dff-862e-0a1ead6d28b2@gmail.com> <20170707092316.GA27560@1wt.eu> <CANatvzygATN6Rd7nGPuGLSpbYs65TV01BFMFrB9Atq1ojcXHJQ@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/0tEhyRu5TJvOBwN0Sfwkj6p7q-E>
Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-early-hints-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 11:44:25 -0000

I am not a big fan of "MUST not use protocol features if it is known not to work" advise.

> Am 07.07.2017 um 13:29 schrieb Kazuho Oku <kazuhooku@gmail.com>om>:
> 
> 2017-07-07 18:23 GMT+09:00 Willy Tarreau <w@1wt.eu>eu>:
>> On Fri, Jul 07, 2017 at 05:54:41AM +0000, Melinda Shore wrote:
>>> On 7/6/17 8:40 PM, Kazuho Oku wrote:
>>>> Regarding the wording, I think it would be better to keep the tone
>>>> as-is, rather than suggesting implementers not to send an Early Hints
>>>> response over HTTP/1.1 depending on the client.
>>> 
>>> Yeah, you don't want to discourage implementation.  I think
>>> the goal is to find some balance between not putting off
>>> implementers on the one hand, and having to deal with an
>>> embarrassing incident on the other.  I'd be more comfortable
>>> with language that's a bit stronger but it's not a huge
>>> issue, certainly not one that's an impediment to moving the
>>> document forward (particularly given that it's intended for
>>> publication as an experimental standard).
>> 
>> I'm just thinking about the fact that we're not even sure that any
>> HTTP/1.1 client doesn't support these informational responses,
>> because such clients can already make use of Expect: 100-continue
>> (so they know about 100), and if I remember well when designing the
>> 101 upgrade for WebSocket, which was reused for HTTP/2, some of
>> the difficulties we faced was that some clients/intermediaries
>> were consuming 101 as 1xx and waiting for a final response after
>> it.
>> 
>> Maybe the stronger wording should be oriented differently, such as
>> "Servers MUST not send 103 to HTTP/1.0 clients nor to any client
>> known not to support 1xx informational responses" ? This way it
>> leaves the possibility opened (ie rely on version and/or user-agent
>> or anything else once an exception is known).
> 
> Considering that this is merely an advice on how to deal with broken
> clients, I think that we should not use the verbs defined in RFC 2119
> or state a strong prohibition.
> 
> I also believe that a whitelist-based approach will be a better choice
> than a blacklist-based one, since 103 is an optimization that is
> beneficial when sent to a client that is known to make use of it. For
> most websites, whitelisting the major browsers that support it (once
> they do) or the CDN they use will be enough to get the most out of the
> status code.
> 
>> Just my two cents,
>> Willy
> 
> 
> 
> -- 
> Kazuho Oku
>