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

Kazuho Oku <kazuhooku@gmail.com> Fri, 07 July 2017 11:29 UTC

Return-Path: <kazuhooku@gmail.com>
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 CB497129B4C; Fri, 7 Jul 2017 04:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LaugGBbv1rvI; Fri, 7 Jul 2017 04:29:37 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CD8129B2C; Fri, 7 Jul 2017 04:29:37 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id u62so15901996pgb.3; Fri, 07 Jul 2017 04:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IEUlzBRv5plxZSUVTaichvRvfRAM4EwEQnR14+AQ7EA=; b=phqCYs5f1xP1+IMVmaGK5fYb2wcWtwk5kZ1Izk8VZRzGgctZQppIxbGcqTUx3iPvxg bZZU6ovAKp8tCs0GlTBW5J41yYZMz0owIaxBXoMzsOZ1CcUlC08ceFO6YQPovvQWzJwt e8a+r8ClpkS18Tdkt333oDsirt2BviI/Ed1Ci/GR2abOlCt5tqhEEqY4TOEJusqxSlJr IThZRUAw/8CRUCF9MIzuqFEJ6+0D8w1cpgwK6Oc8eDGccqW3p21IUS0tCweYvFA3eX1Z aETtBB2tH4AnzaPAb74ZxSVl2zwrdMh5uOokacdmfx/Ffd2CIEkKBX4ajS4PZ8Lqvx5X 2qCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IEUlzBRv5plxZSUVTaichvRvfRAM4EwEQnR14+AQ7EA=; b=W0VWlPCHDRszRBKx2CJ6/YpNUSEg5GfO+U7IPb7S9bY6/dLzCcMjNLh54fJz/WSBof r53ySxW1srAog4c1Bh6wg5AiRKFKbV/OCM9/6oS0AksZa/asLjVgQHdi5Aaaan9uBoyc 5dvhSqJt+GC3vqbJm06gbZSSem2e4u4WJ+29XzTk1JIP3zSXxJm04EnDVbz3J8vh/u9G aoZGSDuUwpIEBDPxlQVIM3d1A44t6M5e/m9CZZDdogOR7PhR+N7CnLe29duCqUfZ9g6L pGDbcEdMSpJh/XRJausxP4NMAZ200BivLwIhcq5d/tjqZmLzBMZvgnSnqY54rhNj6Yos nnYQ==
X-Gm-Message-State: AIVw112oBZKUxUJeZsi6EoaDe389B89aYn+iNgRTw0uOOGlcmNfYgc0N QMu0lG4kp87CPhre6GC49jrUaE/LSQ==
X-Received: by 10.98.79.130 with SMTP id f2mr31197225pfj.133.1499426976952; Fri, 07 Jul 2017 04:29:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.3 with HTTP; Fri, 7 Jul 2017 04:29:36 -0700 (PDT)
In-Reply-To: <20170707092316.GA27560@1wt.eu>
References: <149919703750.15996.5462759432298024921@ietfa.amsl.com> <CANatvzx8GsvoYMscHciKNrOwRzcz1v7=jTCUUp4Z5E=jO9Wd6g@mail.gmail.com> <7273f8ab-c1ff-5dff-862e-0a1ead6d28b2@gmail.com> <20170707092316.GA27560@1wt.eu>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 07 Jul 2017 20:29:36 +0900
Message-ID: <CANatvzygATN6Rd7nGPuGLSpbYs65TV01BFMFrB9Atq1ojcXHJQ@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: 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-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/HeaEui5Naahx9KA6C-KxrJK59sI>
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:29:39 -0000

2017-07-07 18:23 GMT+09:00 Willy Tarreau <w@1wt.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