From nobody Sat Jan 5 16:45:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8B130ED9 for ; Sat, 5 Jan 2019 16:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=Wi7FtuZn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fwg2wXkq 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 Wmb3uOcvJ7LN for ; Sat, 5 Jan 2019 16:45:21 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91632130ED4 for ; Sat, 5 Jan 2019 16:45:21 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BEED920F50 for ; Sat, 5 Jan 2019 19:45:20 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 05 Jan 2019 19:45:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=jk64eIu3xLvtnfH5i3Ja7ZrRBCAuMwO0kRwEQdszODA=; b=Wi7FtuZn MgZIhK2rgJkhQhPj0UAH3ovmgh0aVr069uU0psEsPY5dnGJ+WvXSeN3mPpmibQXy bMjxrg8HSk20ExDn6+Rk/bKD+tN60jIUvKmdTwzLylS0ValmPemwDvb8opvSARQv dnlcElxlPOmKjvGVSWjQXRTnOZYlnqZNnFHoajcikxDi5YBrNqAHtR6HEADKdWWo 4/HCM5MtoLjo0mvmsp+E1uTcQ6yFLqITeaUPtA3MGc6q/J4D+CgH8RrBAFYv1mjH crfcloZxFCt/lROTcVdeQWNnJO4OZxSh80FiY+2VPdPAJ/GAwmOue62LAuER/eEc qNyr2XaYS4r6QQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=jk64eIu3xLvtnfH5i3Ja7ZrRBCAuM wO0kRwEQdszODA=; b=fwg2wXkqW7QgJQ+hzE3mEoNR45OO+dcrcw3LGH6Yr43V8 qX5VSFtdv1yVFDllYZTIjfVzroEDAvTOQinrC+q7EkEnPgZBnCaCpNC46d555J2n EIT/sJQQYvo4p3uFmhVYWpHr3qrU3kW0auxCkSzK2/Cl6ys3IvaW17QWq4IxvDmU wWxu+1khxw57AAWOh4v1VpFE3Mnr1dHjfIru8ieYbRgKQ8OsVb4/RerJDGZNQTzP TJiK6S/LSJBgWQMyUGet58zZ19KzzX5NO1eKyGhnq5p1L1EeQ1MwvyyIoS1jSe5i kl4rDCsiRTfV923xM6McOkJwpt8JLm03LapV3YuSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdeggddvjeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusggppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeduudelrdelrdegfedrvdegudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 1335110087 for ; Sat, 5 Jan 2019 19:45:19 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 74109C01FE for ; Sun, 6 Jan 2019 00:45:16 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============1229459320221619985==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190106004516.74109C01FE@cloud.mnot.net> Date: Sun, 6 Jan 2019 00:45:16 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 00:45:25 -0000 --===============1229459320221619985== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+7/-1/=F0=9F=92=AC60) 7 issues created: - Why must we not use post-handshake client auth? (by DavidSchinazi) https://github.com/quicwg/base-drafts/issues/2294 = - Allow extra data after self-terminating h3 frames (by DavidSchinazi) https://github.com/quicwg/base-drafts/issues/2291 = - Minor typo in Transport Parameters (by goelvidhi) https://github.com/quicwg/base-drafts/issues/2287 = - STOP_SENDING is not depicted in the send FSM (by rpaulo) https://github.com/quicwg/base-drafts/issues/2283 = - What the maximum of TransportParameters.max_ack_delay? (by kazuho) https://github.com/quicwg/base-drafts/issues/2282 = - address-based access control (by kazuho) https://github.com/quicwg/base-drafts/issues/2279 = - Disallow changes of table size after 0-RTT (by martinthomson) https://github.com/quicwg/base-drafts/issues/2276 = 12 issues received 60 new comments: - #2259 amplification attack using Retry and VN triggered by coalesced In= itial packets (15 by kazuho, marten-seemann, mikkelfj, ianswett, DavidSchin= azi, martinthomson, nibanks) https://github.com/quicwg/base-drafts/issues/2259 [-transport] [design] = - #2282 What the maximum of TransportParameters.max_ack_delay? (12 by kaz= uho, ianswett, janaiyengar, martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/issues/2282 [-transport] [design] = - #2253 Consider making h3 frame types varint (9 by DavidSchinazi, kazuho= , martinthomson) https://github.com/quicwg/base-drafts/issues/2253 [-http] [design] = - #2263 Make ALPN mandatory in QUIC-via-TLS (7 by kazuho, vasilvv, mikkel= fj, erickinnear, martinthomson, LPardue) https://github.com/quicwg/base-drafts/issues/2263 [-tls] [design] = - #2291 Allow extra data after self-terminating h3 frames (5 by DavidSchi= nazi, kazuho, LPardue, mikkelfj) https://github.com/quicwg/base-drafts/issues/2291 = - #2275 Varint h3 unidirectional stream types (4 by DavidSchinazi, martin= thomson, dtikhonov, LPardue) https://github.com/quicwg/base-drafts/issues/2275 [-http] [design] = - #2223 When can you coalesce connections (2 by LPardue, ianswett) https://github.com/quicwg/base-drafts/issues/2223 [-http] [design] = - #2258 Initial maximum table size needs clarification. (2 by martinthoms= on, kazuho) https://github.com/quicwg/base-drafts/issues/2258 [-http] [design] = - #2227 It's annoying that one can't send push in 0.5RTT (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2227 [-http] = - #2162 Limit sending while in RTO (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2162 [-recovery] [design] = - #2228 How do I generate an RST? (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2228 [-http] = - #2267 loss of only two packets can lead to an unrecoverable situation (= 1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2267 [-transport] [design] = 1 issues closed: - Minor typo in Transport Parameters https://github.com/quicwg/base-draft= s/issues/2287 = Pull requests ------------- * quicwg/base-drafts (+12/-4/=F0=9F=92=AC30) 12 pull requests submitted: - Allow servers to send a preferred address of each address family (by Da= vidSchinazi) https://github.com/quicwg/base-drafts/pull/2296 = - Move some long header fields to more appropriate definitions (by DavidS= chinazi) https://github.com/quicwg/base-drafts/pull/2295 = - Follow-up on PTO wording (by ianswett) https://github.com/quicwg/base-drafts/pull/2293 = - uni not bi (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2292 = - transport: fix typos and add internal reference (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/2290 = - Allow extra data after self-terminating h3 frames (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/2289 = - draft-tls typo: replace mention of packet number protection with header= protection (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/2288 = - Incoming unidirectional stream cannot be reset (by kazuho) https://github.com/quicwg/base-drafts/pull/2286 = - Rename Final Offset to Final Size (by kazuho) https://github.com/quicwg/base-drafts/pull/2285 = - Include handshake anti-deadlock logic in pseudocode (by Ralith) https://github.com/quicwg/base-drafts/pull/2281 = - Get rid of DoS vulnerability in Reserved Bits (by martinduke) https://github.com/quicwg/base-drafts/pull/2280 = - Trivial editorial fixes (by Ralith) https://github.com/quicwg/base-drafts/pull/2278 = 8 pull requests received 30 new comments: - #2281 Include handshake anti-deadlock logic in pseudocode (8 by Ralith,= martinthomson) https://github.com/quicwg/base-drafts/pull/2281 = - #2235 Make HTTP frames a TLV format. This has several advantages: (6 by= DavidSchinazi, janaiyengar, dtikhonov, LPardue, mikkelfj) https://github.com/quicwg/base-drafts/pull/2235 [-http] [design] = - #2285 Rename Final Offset to Final Size (4 by kazuho, marten-seemann, j= anaiyengar) https://github.com/quicwg/base-drafts/pull/2285 = - #2280 Clarify Actions on nonzero Reserved Bits (4 by martinthomson, jan= aiyengar, martinduke) https://github.com/quicwg/base-drafts/pull/2280 [-tls] [-transport] [de= sign] = - #2261 Avoid data corruption with wrapped Largest Reference. (4 by bence= beky, martinthomson, csillagasz) https://github.com/quicwg/base-drafts/pull/2261 = - #2289 Allow extra data after self-terminating h3 frames (2 by DavidSchi= nazi, LPardue) https://github.com/quicwg/base-drafts/pull/2289 = - #2295 Move some long header fields to more appropriate definitions (1 b= y ianswett) https://github.com/quicwg/base-drafts/pull/2295 = - #2237 Rework Key Update (1 by kazuho) https://github.com/quicwg/base-drafts/pull/2237 [-tls] [design] = 4 pull requests merged: - transport: fix typos and add internal reference https://github.com/quicwg/base-drafts/pull/2290 = - uni not bi https://github.com/quicwg/base-drafts/pull/2292 = - Fix: detect stateless reset if connection not found https://github.com/quicwg/base-drafts/pull/2270 = - Add missing warning about ODCIL encoding https://github.com/quicwg/base-drafts/pull/2273 = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============1229459320221619985== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday January 06, 2019

Events without label "editorial"

Issues

quicwg/base-drafts (+7/-1/=F0=9F=92=AC60)

7 issues created:

12 issues received 60 new comments:

1 issues closed:

Pull requests

quicwg/base-drafts (+12/-4/=F0=9F=92=AC30)

12 pull requests submitted:

8 pull requests received 30 new comments:

4 pull requests merged:

Repositories tracked by this digest:

--===============1229459320221619985==-- From nobody Mon Jan 7 13:37:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCF312D7EA for ; Mon, 7 Jan 2019 13:37:32 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 SfFNFnbD-YK0 for ; Mon, 7 Jan 2019 13:37:30 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 F209412D4F0 for ; Mon, 7 Jan 2019 13:37:29 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id e11so753210plt.11 for ; Mon, 07 Jan 2019 13:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jCpsqQQMlSwdYPsdjq1p7Z/TrpVlyqkc9r5h6/kCSVc=; b=GA+ZX6lpHMkTcw9BNrH6U71RQ+KF3Oj6UfC0SP25d951dodi+wUoQTckMHW561kfck jQPmTBZdW3G7ECePE05k40SPZ7ZQgCTqNleNdB3ZTZYxMAPCtMC9dae2UO5rcVz7v0hz g+Arrl8Xlx5aV1bQlLueTAY90To+qSP0pwf56pNdS1EecrvYATdUkOA/Cm8rRM1k38cC N//LxOXteY7YADgD/1z8pybunx08Ca7WVLxth2uc4biKv4HiIYTg/bh+eEsYQ85gRnny i995AB/DpdJL6KKNx/lNTMhyIpSns4F+c9xDRQ5OQFXswix92T2P421IfU4/h89+Ak4E ndLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jCpsqQQMlSwdYPsdjq1p7Z/TrpVlyqkc9r5h6/kCSVc=; b=eIBanMM65o5Zm/Bv/nR/C/lnmJbWeGtvHyKJFeo/5lX8gVYel5lGVdlelp4UshbWwl pmaFHbe6JyzcxUEFunpgsDk/20d/7pqY1R5EuIcYQ10JtFbapUAJ68JaE26iDyZy6Vjn PaX9BWeiJemTBDzbKvKx1owrs+BXm+hVKdWySxcB2VrN6zRbHf8tia2IB3uZYtwHn9BX jZ1uknmDqgv+y3WHGKF8s1TjM7XlXBeNkddrx48Og9MF/LkBOusq584JeU9nJzzBof0o iErutFDM4mTYtuVDSJDazyTTQ4rnp7viTAp9UV9YlUlhRZ5tVaDGsFIjI3cv7K14nDmo 2a6A== X-Gm-Message-State: AJcUukcwipuo31G1ESIFxflEICdDZfeTROSxK6HO5T44KQ4p8XXA8c0L +dOV+QRV5lsdMwuNKbez8C074NAq6umxKa4c5DPq0hap X-Google-Smtp-Source: ALg8bN6A/eTjKc8K1pl0Rtn8ZXqHJTFzJFhHaCWoLdYcAgBcUceTObM4Qqw09U8YTjoOigHyurCzU+qJixmVT3L9Gfw= X-Received: by 2002:a17:902:9691:: with SMTP id n17mr40559757plp.9.1546897049037; Mon, 07 Jan 2019 13:37:29 -0800 (PST) MIME-Version: 1.0 From: David Schinazi Date: Mon, 7 Jan 2019 13:37:18 -0800 Message-ID: Subject: Proposal to make Version Negotiation more like Retry to punt VN to QUICv2 To: QUIC Content-Type: multipart/alternative; boundary="0000000000001cb1a4057ee5098e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 21:37:32 -0000 --0000000000001cb1a4057ee5098e Content-Type: text/plain; charset="UTF-8" Hi folks, We've been talking about Version Negotiation (VN) for a while, as the current design isn't perfect yet. In particular, it is vulnerable to subtle deadlocks and downgrades and requires a full RTT. I have a proposal for the WG that would effectively punt this issue, allowing us to focus on other QUICv1 deliverables until we actually need VN and have deployment experience. I'm working with the following assumptions: - when we'll have clients and servers supporting both QUICv1 and QUICv2, we will not be willing to pay a full RTT to negotiate which version to use - when we standardize QUICv1, we will not know what QUICv2 will look like, so cannot design compatible VN in v1 and be sure it will work with v2 - compatible VN can rely on transport parameters, so it will be possible to standardize it later as an extension to QUICv1 The proposal is to make VN packets a fatal error that effectively kills the first connection, and have them transmit a new connection ID to allow clients to create a new connection that will hit the same server (or not, based on server preference). In terms of wire format, this makes VN more like Retry by making the server send a new connection ID to the client. Here's a PR of the proposal: https://github.com/quicwg/base-drafts/pull/2313 (Note that this was mostly inspired by EKR's proposals.) Thanks, David --0000000000001cb1a4057ee5098e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folk= s,

We've been talking about Version Negotiation (VN)= for a while, as the current design isn't perfect yet. In particular, i= t is=C2=A0vulnerable to subtle deadlocks and downgrades and requires a full= RTT.

I have a proposal for the WG that would effe= ctively punt this issue, allowing us to focus on other QUICv1 deliverables = until we actually need VN and have deployment experience.

I'm working with the following assumptions:
- when we'll have clients and servers supporting both QUICv1 and QUICv= 2, we will not be willing to pay a full RTT to negotiate which version to u= se
- when we standardize QUICv1, we will not know what QUICv2 wil= l look like, so cannot design compatible VN in v1 and be sure it will work = with v2
- compatible VN can rely on transport parameters, so it w= ill be possible to standardize it later as an extension to QUICv1

The proposal is to make VN packets a fatal error that= effectively kills the first connection, and have them transmit a new conne= ction ID to allow clients to create a new connection that will hit the same= server (or not, based on server preference). In terms of wire format, this= makes VN more like Retry by making the server send a new connection ID to = the client.

Here's a PR of the proposal:
=

(Note th= at this was mostly inspired by EKR's proposals.)

Thanks,
David
--0000000000001cb1a4057ee5098e-- From nobody Tue Jan 8 18:06:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DFC12F1A5 for ; Tue, 8 Jan 2019 18:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Z0QV7fRG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JR4r51jP 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 n9mHdM6iF0fU for ; Tue, 8 Jan 2019 18:06:36 -0800 (PST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C9A12008A for ; Tue, 8 Jan 2019 18:06:36 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 09E84BB9D for ; Tue, 8 Jan 2019 21:06:35 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Tue, 08 Jan 2019 21:06:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date; s=fm1; bh=FX1VCcOsJVhgFI376m6T14QvG6 31bxyqMl/UPAV/zaE=; b=Z0QV7fRGX9NZhnVorsokONgw4VPTzR7j7zW+DKa+xn GzWF7nM0mFnmkTH+eodrzmqwPR/TPTFXAqfyurRFzMlfz6ACvI4uGA+F6z5vIkmB ZnEOZBX5d78gOGNNPqrSGCy/lXdJ9VbJxlGROn4Rdg80TMxz3IYQI1hw0NBQ8T3i prNGwTuKQLE3fzBq3DNJaUOnp2xOTZJgMz5qQQLkpChmZ2tie3I750frnhxUa/y1 HqUJSmaHmi5LgjeU0uB9MGr0CGTfwHYNftUOM8TcuMq3g4UkTixHPDtWxq5rEXFc L5XJ+aNfUY6zYG2h+SpqOWs8g7VHmqOI1YI/81XMYZnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FX1VCc OsJVhgFI376m6T14QvG631bxyqMl/UPAV/zaE=; b=JR4r51jPwirGanMK5Bw/oy XYaomAzoewyk6AW0nRkbcdpca6iLiEpaqEH7Ivrq0f33iyupmem6Gb6DDWkBgvZN BC7sRXGmkta8ibixBHnxHBYM+Ajim/1cIurbIihghDZ3nOv/CXD4srjN22f+TxVx CIj1PuvUXQwOsbT4gzIIKANsRPROpoqXvCyzoVFM+gHUir1N8w9CCX8RWZihIyIt zJDbvyAXDD7LdRsjqt1cjvRy8JtniCdx/cdmQc5fF/qz48/GpWTFnGhF+drojRA1 KtS7iLABS/Fs+8eJHW6zzWa0YBrj3CAE3k1TWXGbUt4EljP49CYZ8suAxaHWfxpQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedtgdegfeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucgoteefjeefqddtgeculdehtddmnecujfgurhepkf fhvfgggfgtoffuffesthejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhs ohhnuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthh husgdrtghomhenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 20F539E59D; Tue, 8 Jan 2019 21:06:34 -0500 (EST) Message-Id: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae1f753 Subject: Key updates Date: Wed, 09 Jan 2019 13:06:34 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 02:06:38 -0000 https://github.com/quicwg/base-drafts/pull/2237 The above PR makes some fairly significant changes to key updates. Mostly the changes are editorial in nature, but the fix to issues 2214 is non-trivial. The fix is to add another bit to key phase. That bit is used to signal whether key updates are permitted. This is necessary to avoid a corner case where it is possible to complete lose synchronization. One nice property you get from this is the ability to limit the number of keys you have to maintain to 2. There's more text on how to manage old keys and a cleanup of the language. The key update text was very old and poorly structured. Feedback would be appreciated. From nobody Wed Jan 9 06:49:51 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86469126C7E for ; Wed, 9 Jan 2019 06:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.742 X-Spam-Level: X-Spam-Status: No, score=-15.742 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 V2SoTQJuvC3v for ; Wed, 9 Jan 2019 06:49:48 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 A8C641228B7 for ; Wed, 9 Jan 2019 06:49:47 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id 96so7964313wrb.2 for ; Wed, 09 Jan 2019 06:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QqhpZyYDk/005vgW5gEGW5HyRD+KJ+WQB5GBOQVWTmo=; b=Tocn/zFuTYkbN6Wi7F/bpaK2d6faPXbOj86ZLbHUyMuYSaDuEgZSkMUhyznZXML9mW aTbDfuv68xO+ZiQBqvF39NTEG/2HiZwt/dvQaHWP7dqmkGjBt8GzYGayBgqHcdCtGug3 8XGDEAk67uAEzUns2hdvo34lBzG+GFQq9W/yi5768YYmphh1qhGCnhF3We140CicKC5K DW6R693qi74w0wXdICdV+X1+FlqANUmSkzMRBBJMMHBuNq0N2vXVNrknrMoDrW1zYDD2 p5MckgxnIok5bph+NJOg2syH58JsDKoH5KRiAniQBwfyUQQVDniZ90c6b2KRu1/RTyz5 +Jhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QqhpZyYDk/005vgW5gEGW5HyRD+KJ+WQB5GBOQVWTmo=; b=S0VHLJKRhBFCiWtl6u1Jw10FTJnDtGgfdqAdooz9ABpl1HvX0gpd9n5TmV9N2Tth0X qa0BWv04j/OWC+c+KWpT8BcFKdyU4TPMl8lNMFian9byRpg54UkaQt2msxzDfXLEevVa lZ4LtZTwljVmJPpGTZ9JCsmx/8e68jVWgWR3qiFVfV3OSQWeWTY9qve/PZKS7CcWGm5h lN6adhZrV5bQWbR1oyrUZ5dHRKsvZcJrC/8mgdLrZnDRt+EAA3uZNUVpfY+OlMci3vKD 64Sqb2vXdxzXboY0IiUrBupfZVkdgIJ/o3cJ5LjVZuA5enTO0B7EaiLsiCgx+j2m5Btj MUdg== X-Gm-Message-State: AJcUukdw6Ch61i1BmN0cgUnYmDhPZnikOVdCxRdF9C5J9QqcsoDBKGu0 JlaJR5g7hYMi6EJvHMzfGMXED5amJlPeDbWjqZOAJcnH X-Google-Smtp-Source: ALg8bN4o5XM2Ik5ajA5tzszIZUdUXtMoVDYBztsA7K+4JiEn9SJ0NEbI2A3zKDY8WUuP3l73ZtmG5EGhwvsbpe2bo4s= X-Received: by 2002:adf:a28d:: with SMTP id s13mr5706835wra.100.1547045385916; Wed, 09 Jan 2019 06:49:45 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> In-Reply-To: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> From: Ian Swett Date: Wed, 9 Jan 2019 09:49:32 -0500 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000ae4b16057f079205" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 14:49:49 -0000 --000000000000ae4b16057f079205 Content-Type: text/plain; charset="UTF-8" One question: It appears this allows a peer to permanently disable key updates by always setting the Key Update Permitted bit to 0. Do you think that's a feature or a bug? I can see implementations deciding key update isn't worth implementing given the low cost of creating a new connection, so it seems like it could be a feature to me. On Tue, Jan 8, 2019 at 9:06 PM Martin Thomson wrote: > https://github.com/quicwg/base-drafts/pull/2237 > > The above PR makes some fairly significant changes to key updates. Mostly > the changes are editorial in nature, but the fix to issues 2214 is > non-trivial. > > The fix is to add another bit to key phase. That bit is used to signal > whether key updates are permitted. This is necessary to avoid a corner > case where it is possible to complete lose synchronization. One nice > property you get from this is the ability to limit the number of keys you > have to maintain to 2. > > There's more text on how to manage old keys and a cleanup of the > language. The key update text was very old and poorly structured. > > Feedback would be appreciated. > > --000000000000ae4b16057f079205 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One question: It appears this allows a peer to permanently= disable key updates by always setting the Key Update Permitted bit to 0.= =C2=A0 Do you think that's a feature or a bug?

I can= see implementations deciding key update isn't worth implementing given= the low cost of creating a new connection, so it seems like it could be a = feature to me.

O= n Tue, Jan 8, 2019 at 9:06 PM Martin Thomson <mt@lowentropy.net> wrote:
https:/= /github.com/quicwg/base-drafts/pull/2237

The above PR makes some fairly significant changes to key updates.=C2=A0 Mo= stly the changes are editorial in nature, but the fix to issues 2214 is non= -trivial.

The fix is to add another bit to key phase.=C2=A0 That bit is used to signa= l whether key updates are permitted.=C2=A0 This is necessary to avoid a cor= ner case where it is possible to complete lose synchronization.=C2=A0 One n= ice property you get from this is the ability to limit the number of keys y= ou have to maintain to 2.

There's more text on how to manage old keys and a cleanup of the langua= ge.=C2=A0 The key update text was very old and poorly structured.

Feedback would be appreciated.

--000000000000ae4b16057f079205-- From nobody Wed Jan 9 07:12:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7A012F1AC for ; Wed, 9 Jan 2019 07:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MJtR7s7OPTXa for ; Wed, 9 Jan 2019 07:12:43 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C914A1286D9 for ; Wed, 9 Jan 2019 07:12:41 -0800 (PST) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ghFX4-0007mK-NI for quic@ietf.org; Wed, 09 Jan 2019 16:12:40 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ghFWy-0005pn-RG for quic@ietf.org; Wed, 09 Jan 2019 10:12:36 -0500 Received: (qmail 20003 invoked from network); 9 Jan 2019 15:12:31 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Jan 2019 15:12:31 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-5C7DE407-7EDB-4E05-B0D6-AB079E2A7EEC Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Wed, 9 Jan 2019 07:12:27 -0800 Cc: Martin Thomson , IETF QUIC WG Content-Transfer-Encoding: 7bit Message-Id: <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> To: Ian Swett Subject: Re: Key updates X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.20) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5kVbiMlAtSZd9kPbnph7UBd602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVirDuR/Za0PNynPHl5esK6o87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuzDn5j2tUhjYPVPi3bwTCB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaJwAHPn4EuYWIk0YD/RIopTqpzxuZ/FKz4x4mg8I92kbvMXQGvTLr+8 5FI3jUPV8Tpk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAliWlQbBThxwZFUQHKWb8B+lZYSpQQtCkh8qZ SV0LCxteCQiCUi1Vvcp87PDgawDvw8Kh3W2D7hEXvsNyaPFVH6shu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK04vW75yGJIA4He1K6wlrze9UshveVgoiypAicYsWUtdCDRZgQnFYkq0SOLr mvxpF44cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 15:12:47 -0000 --Apple-Mail-5C7DE407-7EDB-4E05-B0D6-AB079E2A7EEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I am not really supporting this proposed change. I understand that if peers e= ngage in very rapid key updates they can get out of synch, but this is a pat= hological behavior. Adding another bit in the header is not required, and in= troduces another failure mode when reneging on the enabled bit. We could use plenty of bits like that: ECN echo comes to mind. We don't. We u= se frames. =46rom that point of view, using ACK as a check is more in line w= ith the QUIC design. "Don't roll the key if you have not received at least o= ne ACK for the current phase" seems much simpler. Also, it uses an honest si= gnal, by opposition to a random bit, and that doesn't create an other class o= f misbehavior. If that doesn't convince you, then please add a specification on how to reac= t to reneging the enable bit, and also how to react to peers ignoring it. -- Christian Huitema=20 > On Jan 9, 2019, at 6:49 AM, Ian Swett wrote: >=20 > One question: It appears this allows a peer to permanently disable key upd= ates by always setting the Key Update Permitted bit to 0. Do you think that= 's a feature or a bug? >=20 > I can see implementations deciding key update isn't worth implementing giv= en the low cost of creating a new connection, so it seems like it could be a= feature to me. >=20 >> On Tue, Jan 8, 2019 at 9:06 PM Martin Thomson wrote: >> https://github.com/quicwg/base-drafts/pull/2237 >>=20 >> The above PR makes some fairly significant changes to key updates. Mostl= y the changes are editorial in nature, but the fix to issues 2214 is non-tri= vial. >>=20 >> The fix is to add another bit to key phase. That bit is used to signal w= hether key updates are permitted. This is necessary to avoid a corner case w= here it is possible to complete lose synchronization. One nice property you= get from this is the ability to limit the number of keys you have to mainta= in to 2. >>=20 >> There's more text on how to manage old keys and a cleanup of the language= . The key update text was very old and poorly structured. >>=20 >> Feedback would be appreciated. >>=20 --Apple-Mail-5C7DE407-7EDB-4E05-B0D6-AB079E2A7EEC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am not really supporting this proposed ch= ange. I understand that if peers engage in very rapid key updates they can g= et out of synch, but this is a pathological behavior. Adding another bit in t= he header is not required, and introduces another failure mode when reneging= on the enabled bit.

We could use plenty of bits like tha= t: ECN echo comes to mind. We don't. We use frames. =46rom that point of vie= w, using ACK as a check is more in line with the QUIC design. "Don't roll th= e key if you have not received at least one ACK for the current phase" seems= much simpler. Also, it uses an honest signal, by opposition to a random bit= , and that doesn't create an other class of misbehavior.

If that doesn't convince you, then please add a specification on how t= o react to reneging the enable bit, and also how to react to peers ignoring i= t.

-- Christian Huitema&nb= sp;

On Jan 9, 2019, at 6:49 AM, Ian Swett <ianswett=3D40google.co= m@dmarc.ietf.org> wrote:

One question: It appears this allows a peer to p= ermanently disable key updates by always setting the Key Update Permitted bi= t to 0.  Do you think that's a feature or a bug?

I c= an see implementations deciding key update isn't worth implementing given th= e low cost of creating a new connection, so it seems like it could be a feat= ure to me.

On Tue= , Jan 8, 2019 at 9:06 PM Martin Thomson <mt@lowentropy.net> wrote:
https://github.co= m/quicwg/base-drafts/pull/2237

The above PR makes some fairly significant changes to key updates.  Mos= tly the changes are editorial in nature, but the fix to issues 2214 is non-t= rivial.

The fix is to add another bit to key phase.  That bit is used to signal= whether key updates are permitted.  This is necessary to avoid a corne= r case where it is possible to complete lose synchronization.  One nice= property you get from this is the ability to limit the number of keys you h= ave to maintain to 2.

There's more text on how to manage old keys and a cleanup of the language.&n= bsp; The key update text was very old and poorly structured.

Feedback would be appreciated.

= --Apple-Mail-5C7DE407-7EDB-4E05-B0D6-AB079E2A7EEC-- From nobody Wed Jan 9 10:58:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B412113101E for ; Wed, 9 Jan 2019 10:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 G00SRHXm9Q2z for ; Wed, 9 Jan 2019 10:58:07 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 BD579131008 for ; Wed, 9 Jan 2019 10:58:06 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id s12so8797903wrt.4 for ; Wed, 09 Jan 2019 10:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gujYmJIEOi9DZXI5QCuOAL1CHZo6lzdqmxt4zajbTY0=; b=FgVDRC7lq4kqWvTQ1crL6yRuAh21kHDDuHjYqzCabvFKKVMXb2KvPWoCL0XdixjF8B 14Tbkozf9fABpqYBDNZ2G4UOg2pAXyiOEEmBltFbpjujjSB9wLGqnziwTKA1NhLXaESH hiuhuGt5PFD6IWnqk6S2VagZJ2K6cCDUfvK1Fi3lWRmqoJnHq1HoaMl2rDi1DktHq1y5 P9IT8DuaLb0seGrXQOpZ9aKW5/XGMRXHEAe6XlBPdf9jRmxpLdEAr54xPaGUF88D7yFc FmylREehdwstzdqciydE9JuzR4M99d4RkyALIMDSEH6YulW8RNZeshIVjeA1FlbGKvkb JWkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gujYmJIEOi9DZXI5QCuOAL1CHZo6lzdqmxt4zajbTY0=; b=URChq647cs+3Wpu5Y94p0MicFc0Qd3v7IF82atDHVdHrIpirMQ4XWgA2WN/2RffTji 9lLFW/yLgUMI3qW18jTHkqmcyjsJGijeWLjiOcjkwbETNEAgXqFm1RjCcnrTKOM24ii/ b/0go03sBwYK/uPB5Mdx3gqueE4tfwAhGhHdpwuG/UCD64SUbta5qiT0teZjHL7jigmq eMGuD82LaxWp7vSgVND19YFvTQXY9sK7kk0xXzRaoLJ4H/yfsJGoGqTs4jsrrVfm6WmF XDppAbhcVGd0XF3I8eC6I9fZ6qrnN9hLYjkOUWI/KnZMKVSS5Kk3Ub+QoGKBzplaLdXW 6fdw== X-Gm-Message-State: AJcUukebcLqUKzRXly9c/f3LYb4f7f+Zk4qy5nZJJipJwurbg/Th6IhX Gz8m7959u/S1e6X9HBVzLORtUNrILtN8JdmaOd6SRqreTH8= X-Google-Smtp-Source: ALg8bN4D+rqicB5LfFg9d0+AQXosywJ3pfRkTwUrg3eyV/6suTRqExH2tpDkDU/RhWoG5gzMMtBK0PSWU5zjCFBk9w0= X-Received: by 2002:a5d:6988:: with SMTP id g8mr5881902wru.33.1547060284722; Wed, 09 Jan 2019 10:58:04 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> In-Reply-To: <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> From: Ryan Hamilton Date: Wed, 9 Jan 2019 10:57:52 -0800 Message-ID: Subject: Re: Key updates To: Christian Huitema Cc: Ian Swett , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000b848ef057f0b0a58" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 18:58:09 -0000 --000000000000b848ef057f0b0a58 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 9, 2019 at 7:12 AM Christian Huitema wrote: > I am not really supporting this proposed change. I understand that if > peers engage in very rapid key updates they can get out of synch, but this > is a pathological behavior. Adding another bit in the header is not > required, and introduces another failure mode when reneging on the enabled > bit. > > We could use plenty of bits like that: ECN echo comes to mind. We don't. > We use frames. From that point of view, using ACK as a check is more in > line with the QUIC design. "Don't roll the key if you have not received at > least one ACK for the current phase" seems much simpler. Also, it uses an > honest signal, by opposition to a random bit, and that doesn't create an > other class of misbehavior. > I like this advice. It seems simple and obviously correct. --000000000000b848ef057f0b0a58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 9, 2019 at 7:12 AM Christian Huitema <huitema@huitema.net> wrote:
I am not really supporting this proposed = change. I understand that if peers engage in very rapid key updates they ca= n get out of synch, but this is a pathological behavior. Adding another bit= in the header is not required, and introduces another failure mode when re= neging on the enabled bit.

We could use plenty of bits l= ike that: ECN echo comes to mind. We don't. We use frames. From that po= int of view, using ACK as a check is more in line with the QUIC design. &qu= ot;Don't roll the key if you have not received at least one ACK for the= current phase" seems much simpler. Also, it uses an honest signal, by= opposition to a random bit, and that doesn't create an other class of = misbehavior.

I like this= advice. It seems simple and obviously correct.
--000000000000b848ef057f0b0a58-- From nobody Wed Jan 9 13:53:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9F7130FCB for ; Wed, 9 Jan 2019 13:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 deDm_48Yx91s for ; Wed, 9 Jan 2019 13:53:47 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 ED69312DD85 for ; Wed, 9 Jan 2019 13:53:46 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id s22so7268781ioc.8 for ; Wed, 09 Jan 2019 13:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=6c1i5rJL4TmpAeNXtRiW4Ih2U4t3AbnhQ/uLekgc8G0=; b=FvroQ0b0hAV/kihA7F+00MBzj4kRvG4ygG4Pm8J2rJHtswA4JYtEA82tFrdzZotp1W L09g4Z2++teZ3yRV8wCkjv9HdCpkXBnU/eqksLhJWFBrV3t1Awq5N57UpxfCRKScuUKC invO4GFJHEyENpjEYwLE2XBreGAkV+ARqWhaHiLyYOyfCMC0lK3sTseQT83rdTOfrtTJ EvuqiqMepzJwQ5Hh08S+hj9hZvlHXErK0qc1RXjcIfKabWRNE1SAiQ5VGxdoaOhr9LHF GEkGABcJo38LK/v2mAizprUakU/+bu4VtM0I3dwA6mVTzo4JpCpHMwqZ77uQMTSNYgll /pzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=6c1i5rJL4TmpAeNXtRiW4Ih2U4t3AbnhQ/uLekgc8G0=; b=FXjBknuhAZPciBuWeXSzyVCovTHFgwdK427l01BGeTXxcayiTFJTumdlr/1/rBHq+H oga6qkfWdnCJ5eIi4CCiQUt5vzE8AJhRmMENM8whx2r/WARmU4JDryYsXmu6xXsLtoCg m3RAZRhU5S5EyqCAfsN4/Px8LeiqAaP8tqrcEXWuXMh1mrctqlWrZPxgWdU4l2KUYgCm YhiKfvDPDbHkBcoAmGepyxK6Qsc9QIyWRiG3jsNm82EjYgFRNW8YQyrnj2vT2eXNXIoS Jzq4q2XV96szXJhpzC5zCfYJ38v7HlSTtysHth8NBk3iqRPDj3Sir8uyl/Z6mwbtkCpM 9Guw== X-Gm-Message-State: AJcUukf8UN7/JZdG5H+Qgg5tvW7Rm248N4d1eiXp6pvUxqnekOPUXKSR tIq7TFadC5dc+wuqx3NKT9+hFOOXmAdBBnKvq9xSqQ== X-Google-Smtp-Source: ALg8bN5E5DbHSdTI1o+mo9teimxqApvKUD1N1PgbAzGQzdHEJWylb/JX1xFG993yHtM1PuNBOjUtVV4CnLlcqmuhvMM= X-Received: by 2002:a6b:8d8e:: with SMTP id p136mr5270995iod.166.1547070826272; Wed, 09 Jan 2019 13:53:46 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 9 Jan 2019 16:53:45 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 9 Jan 2019 16:53:45 -0500 Message-ID: Subject: Re: Key updates To: Ryan Hamilton , Christian Huitema Cc: Martin Thomson , Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000000adceb057f0d7f79" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 21:53:49 -0000 --0000000000000adceb057f0d7f79 Content-Type: text/plain; charset="UTF-8" Agree On 9 January 2019 at 19.58.20, Ryan Hamilton ( rch=40google.com@dmarc.ietf.org) wrote: On Wed, Jan 9, 2019 at 7:12 AM Christian Huitema wrote: > I am not really supporting this proposed change. I understand that if > peers engage in very rapid key updates they can get out of synch, but this > is a pathological behavior. Adding another bit in the header is not > required, and introduces another failure mode when reneging on the enabled > bit. > > We could use plenty of bits like that: ECN echo comes to mind. We don't. > We use frames. From that point of view, using ACK as a check is more in > line with the QUIC design. "Don't roll the key if you have not received at > least one ACK for the current phase" seems much simpler. Also, it uses an > honest signal, by opposition to a random bit, and that doesn't create an > other class of misbehavior. > I like this advice. It seems simple and obviously correct. --0000000000000adceb057f0d7f79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Agree

On 9 January 2019 at 19.58.20, Ryan Hamilton (= rch=3D40google.com@dma= rc.ietf.org) wrote:

= On Wed, Jan 9, 2019 = at 7:12 AM Christian Huitema <huitem= a@huitema.net> wrote:
I am not really supporting this proposed change. I understand that if peers engage in very rapid key updates they can get out of synch, but this is a pathological behavior. Adding another bit in the header is not required, and introduces another failure mode when reneging on the enabled bit.

We could use plenty of bits like that: ECN echo comes to mind. We don't. We use frames. From that point of view, using ACK as a check is more in line with the QUIC design. "Don't roll the key if you have not received at least one ACK for the current phase" seems much simpler. Also, it uses an honest signal, by opposition to a random bit, and that doesn't create an other class of misbehavior.

I like this advice. It seems simple and obviously correct.
--0000000000000adceb057f0d7f79-- From nobody Wed Jan 9 14:13:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731B612D84C for ; Wed, 9 Jan 2019 14:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ldxvX5Zj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cjj7YNMS 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 P9eEh7sQmRvt for ; Wed, 9 Jan 2019 14:13:24 -0800 (PST) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA546126DBF for ; Wed, 9 Jan 2019 14:13:24 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.west.internal (Postfix) with ESMTP id 9675F11DD; Wed, 9 Jan 2019 17:13:23 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute1.internal (MEProxy); Wed, 09 Jan 2019 17:13:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:date:references:subject; s=fm1; bh=QqN WeYmQZ85zBD2FBBKmhhttWBJutHHwa/ZX9mG9JGU=; b=ldxvX5ZjIzCMf/2ehCh 2N3sybP3h/PLHBLRmtiJIKg3x4iBEqBrlf+kQQMNE1PIEswwybCunRY3xl8hfxsf 34SfJB5eE2o4KlR0MmPRTa3KlWdoBMIG9WY2o++LFrM4AEV/Us9xptZueXb8TGck 4Q7/uCd7bzLFmoDfHq2lt26iSRonHMZez3hVjlcFnjGMdCQ91pevfhIvZ+YCbywU S1jsBrpFHCywczrErefg1lVitWL6wq561dNuUUwmkR05IW2StAGH81q0Pz5X9HmL /3wqDNJ/y0SAdgQtQwoRdSYu2LgBsWO88Ph2zrgT8NN6QjPO7yJXLGTK/ysXlKB+ +fA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=QqNWeYmQZ85zBD2FBBKmhhttWBJutHHwa/ZX9mG9J GU=; b=cjj7YNMSfpM8iLQTn/92C4lQBN9POVCPHfPYLjfz4uMH0cwT3gni4khus II4s7MeRFhWmMShxCYcAAkIIGxs2y0tYbMOdiWPXKtHg9yE2uCuZYxhp9bsGn3Hb JM5Mh1u3/xvhelYdApbKc0wJFlIumHFdVwWTuNCjz/g40gBBSrCPjpMlk+1FDwl3 J02jDgOcdJqY2O8UxiwOb8UdXCgBEPOiqHV0TNPC17vb5WOvX9Ggb36mabkMsNnq lWjVAkBpl8PiJXnOYKJkOPeHNz6ssWnrITzgICWryfzuZJXSaBIo99p4s+w0y6i2 PjHcltQYd17bmXQBbbve5TPIDjW1w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedugdduieduucdltddurdegtdekrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkhffvggfgtgfojgfffhfusehtjeertdertdejnecuhfhrohhmpeforghr thhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0E269BA783; Wed, 9 Jan 2019 17:13:22 -0500 (EST) Message-Id: <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> From: Martin Thomson To: Christian Huitema , Ian Swett Cc: IETF QUIC WG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae1f753 In-Reply-To: <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> Date: Thu, 10 Jan 2019 09:13:21 +1100 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> Subject: Re: Key updates Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 22:13:26 -0000 On Thu, Jan 10, 2019, at 02:12, Christian Huitema wrote: > We could use plenty of bits like that: ECN echo comes to mind. We don't. > We use frames. From that point of view, using ACK as a check is more in > line with the QUIC design. "Don't roll the key if you have not received > at least one ACK for the current phase" seems much simpler. Also, it > uses an honest signal, by opposition to a random bit, and that doesn't > create an other class of misbehavior. If you look at the history of the PR, I initially proposed using ACK in exactly this way. The feedback I got was that this was difficult for people to implement, because it more tightly couples two parts of the processing pipeline than was previously necessary. That is, if you consider packet protection as a discrete stage in processing, getting information to and from the ACK frame processing might be difficult, depending on implementation structure. We've been very careful to avoid having protocol behaviour that triggers on acknowledgment. I don't think that we have any that escape the loss recovery and CC algorithms. As an architectural principle, I think that is worth preserving. > If that doesn't convince you, then please add a specification on how to > react to reneging the enable bit, and also how to react to peers > ignoring it. That I have done. Of course, as Ian points out, if the bit is never set, there isn't really any recourse, and that might be valuable enough to be considered a feature. From nobody Wed Jan 9 14:31:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9874712D84C for ; Wed, 9 Jan 2019 14:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 V43ziWdItq2e for ; Wed, 9 Jan 2019 14:31:13 -0800 (PST) Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 86858124D68 for ; Wed, 9 Jan 2019 14:31:13 -0800 (PST) Received: by mail-it1-x12a.google.com with SMTP id a6so13486674itl.4 for ; Wed, 09 Jan 2019 14:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Fp+O6781qPXk8hZl3qv+BgRYp6hSD29DY0RoJRfctPA=; b=fNa4Sor6BWV3jxStOZW2K2/dboKBdVLlaf3TpX31DFwwx6wPP19y9xU/q/9PNNOQIb 3PH/nQnnROsc6jzIkrBedqFENJ0A/pCG5FQW29BsR7dRMYi/f3w+2wPIt3LPaLwfO1Hi enX8UvL/3Bw0aMLTh/NMy2iEruNGO4QbEbUtrWDkM8uH1dwLQZbRHuIScMln4mcQi+pe Sr9XBb9QvOSZQ2QoO6c9CoDyPkT8AnHitSW/liK01IyjSjhPdnmhGtmlIEvdYB4QFFht wf+xIS9Uw358eL54/5nRo56paBvd334Bif6fNOopUzhamqSBDMfSgKbDsBqs1OrFjwDc 3qwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Fp+O6781qPXk8hZl3qv+BgRYp6hSD29DY0RoJRfctPA=; b=RsxnAjSwo9w1guRW8p1uIL/p43KD6CSOKy13rFZrxXCYpTcD+i6Ag2+sWeUSMx0Q4F c+N0gKufJ/BOnWl/9lGRecYTwJrJrdWECWhEOgfEL3zWCnVXcEfiJdQGzeddzZndgeg9 pobB3tamyjJqTUA/Yaa0y6N5msBfnKJ3cw5n4JNRZj62iT278hoZib1Yac/i+mXd7pQ3 l1PyliBEc1BknnD8mLdYw1kr33MUTszdQi6FvDHb28m32jPCFJUonHh6aMjwWy9Xzzv1 h3xAijzW3u4fNnloeNlil7p6nWw3lMRmjaO59lfuebX6OWhk8d62i2Oez47DiLDlveBU Y2TQ== X-Gm-Message-State: AJcUukcj6MuFCayMmfqav8u5fy0vjkM1alx37crbVC+OweHTkEVU2VL+ k6hUsWZGmpb3fAgyLyTk8n+sRIL37LZDWWbhHRZKiA== X-Google-Smtp-Source: ALg8bN6P7qXYEX3boknaY/T6tTqLn9PuaFm0gizirR0wYm3/cD8Q/gisk/qjv9tqFNgFe3kwOzOd8IPp5/HW3W0xODw= X-Received: by 2002:a05:660c:12c7:: with SMTP id k7mr5170047itd.148.1547073072842; Wed, 09 Jan 2019 14:31:12 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 9 Jan 2019 17:31:12 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 9 Jan 2019 17:31:12 -0500 Message-ID: Subject: Re: Key updates To: Martin Thomson , Christian Huitema , Ian Swett Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000f2cb02057f0e0450" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 22:31:15 -0000 --000000000000f2cb02057f0e0450 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m just worried about Ians comment about one endpoint being able t= o stall key updates. I can see the separation of processing argument, but you could reformulate it slightly to not use ACK=E2=80=99s: A key update is only possible after successfully decoding one packet for the current locally originated key phase. Or would that still have a race condition? Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 January 2019 at 23.13.34, Martin Thomson (mt@lowentropy.net) wrote: On Thu, Jan 10, 2019, at 02:12, Christian Huitema wrote: > We could use plenty of bits like that: ECN echo comes to mind. We don't. > We use frames. From that point of view, using ACK as a check is more in > line with the QUIC design. "Don't roll the key if you have not received > at least one ACK for the current phase" seems much simpler. Also, it > uses an honest signal, by opposition to a random bit, and that doesn't > create an other class of misbehavior. If you look at the history of the PR, I initially proposed using ACK in exactly this way. The feedback I got was that this was difficult for people to implement, because it more tightly couples two parts of the processing pipeline than was previously necessary. That is, if you consider packet protection as a discrete stage in processing, getting information to and from the ACK frame processing might be difficult, depending on implementation structure. We've been very careful to avoid having protocol behaviour that triggers on acknowledgment. I don't think that we have any that escape the loss recovery and CC algorithms. As an architectural principle, I think that is worth preserving. > If that doesn't convince you, then please add a specification on how to > react to reneging the enable bit, and also how to react to peers > ignoring it. That I have done. Of course, as Ian points out, if the bit is never set, there isn't really any recourse, and that might be valuable enough to be considered a feature. --000000000000f2cb02057f0e0450 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I=E2=80=99m just wor= ried about Ians comment about one endpoint being able to stall key updates.=

I can see the separa= tion of processing argument, but you could reformulate it slightly to not u= se ACK=E2=80=99s:

A k= ey update is only possible after successfully decoding one packet for the c= urrent locally originated key phase.
Or would that still have a race condition?
Kind Regards,
Mikkel Fahn=C3=B8e J=C3= =B8rgensen


On 9 January 201= 9 at 23.13.34, Martin Thomson (mt@lowe= ntropy.net) wrote:

On Thu, Jan 10, 2019, at 02:12, Christian Huitema w= rote:
> We could use plenty of bits like that: ECN echo comes to mind. We = don't. =20
> We use frames. From that point of view, using ACK as a check is mo= re in =20
> line with the QUIC design. "Don't roll the key if you hav= e not received =20
> at least one ACK for the current phase" seems much simpler. A= lso, it =20
> uses an honest signal, by opposition to a random bit, and that doe= sn't =20
> create an other class of misbehavior.

If you look at the history of the PR, I initially proposed using ACK in= exactly this way. The feedback I got was that this was difficult for peop= le to implement, because it more tightly couples two parts of the processin= g pipeline than was previously necessary. That is, if you consider packet = protection as a discrete stage in processing, getting information to and fr= om the ACK frame processing might be difficult, depending on implementation= structure.

We've been very careful to avoid having protocol behaviour that tri= ggers on acknowledgment. I don't think that we have any that escape th= e loss recovery and CC algorithms. As an architectural principle, I think = that is worth preserving.

> If that doesn't convince you, then please add a specification = on how to =20
> react to reneging the enable bit, and also how to react to peers = =20
> ignoring it.

That I have done. Of course, as Ian points out, if the bit is never se= t, there isn't really any recourse, and that might be valuable enough t= o be considered a feature.

--000000000000f2cb02057f0e0450-- From nobody Wed Jan 9 15:02:25 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186DA12D84C for ; Wed, 9 Jan 2019 15:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TFqsqfz-l-5z for ; Wed, 9 Jan 2019 15:02:22 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 0140512D7F8 for ; Wed, 9 Jan 2019 15:02:21 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id a62so9417674wmh.4 for ; Wed, 09 Jan 2019 15:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5QTr8u+9GYl9qZPywxZTXpqd0koijWFdFMvSR8sfzbY=; b=TiFqARFQ2VEz5fBw33UdF5BSvumjpj18PyGPOJ3+Z65YIF/si7GxtSHhUs8G38WulV kHfXWbbS4QZUCU/VEuvKIykkWpOaW3R28i5oUHXycrxpF66FM6oniDeSunPI0MclDCZN bmYVypR+uimF9Z+RnPZIryKsycmzByZnHg7XGe9h5tWMSUj/u9XEkI9h6xo14cG5zPnq 8Jts0XzzWzIn6u2S0Zbx6IXliCzCRCfCUSvFBDMpVVn7jPnnpUpDfc8CekLtu+UBEfJR x9ZiytLCiEe1D5poqHlzZwOM5aB/rzRq1BsrpieKx9X/aq6/2jzdfWE8BBINWJwCB47b h7Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5QTr8u+9GYl9qZPywxZTXpqd0koijWFdFMvSR8sfzbY=; b=Q0tXoFsNbEgNr79qHNjS+KzVhwq2Q37Zh5720yI+EaTii7cmElF6M0eP3LrQnOGssD MI952yoEkdC5bao7BE5kggD/IEeMkvqnDkFtaiyrigtMZa/tWcUrWotmnPjsyhQjLf/s r5scWCG8YqLbLtPVkRQoJ9Tl2olccJCEm9tqd++f0siHrWe1F9FIZPDrRvgRyBZwCy4S 0reCebekUDTp1ClrvE2W2WMcD6ok2MjalazPr8CIpfVH0juL0AE0/TcS2m1/y0Fp9hEl zM1ErGT9yIxdqdZTD1cCIzey+NrfFueRyIEdkdCaZMGS57savsrSfL+XonboKppLFHnh xb4g== X-Gm-Message-State: AJcUukfi9RbcJTBvTmxBlGWOrFatIavW3lJ8NLmJAelJnZFzBD3UOXiR c9oVX7pdUs3NyrDpNVrHslOcfSVpTJAqkimZywiNE+lD6rE= X-Google-Smtp-Source: ALg8bN7afSxn/CNNCKtifkgp4NCvX+2gldO+nLNd+eBmlfdGw1t1gyCT2mxVYGU+eH3vXbPPSK6eEEbaDhZzizBBOGM= X-Received: by 2002:a1c:2c44:: with SMTP id s65mr7926417wms.80.1547074939980; Wed, 09 Jan 2019 15:02:19 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> In-Reply-To: <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> From: Ryan Hamilton Date: Wed, 9 Jan 2019 15:02:07 -0800 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: Christian Huitema , Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000003d8d5d057f0e7406" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 23:02:24 -0000 --0000000000003d8d5d057f0e7406 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 9, 2019 at 2:13 PM Martin Thomson wrote: > On Thu, Jan 10, 2019, at 02:12, Christian Huitema wrote: > > We could use plenty of bits like that: ECN echo comes to mind. We don't. > > We use frames. From that point of view, using ACK as a check is more in > > line with the QUIC design. "Don't roll the key if you have not received > > at least one ACK for the current phase" seems much simpler. Also, it > > uses an honest signal, by opposition to a random bit, and that doesn't > > create an other class of misbehavior. > > If you look at the history of the PR, I initially proposed using ACK in > exactly this way. The feedback I got was that this was difficult for > people to implement, because it more tightly couples two parts of the > processing pipeline than was previously necessary. That is, if you > consider packet protection as a discrete stage in processing, getting > information to and from the ACK frame processing might be difficult, > depending on implementation structure. > > We've been very careful to avoid having protocol behaviour that triggers > on acknowledgment. I don't think that we have any that escape the loss > recovery and CC algorithms. As an architectural principle, I think that is > worth preserving. I'm not sure this principle is that important, but if it is, we could introduce a new frame for this purpose. KEY_PHASE_RECEIVED, or some such. --0000000000003d8d5d057f0e7406 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 9, 2019 at 2:13 PM Martin Thomson <mt@lowentropy.net> wrote:
=
On Thu, Jan 10, 2019, at 02:12, Christian Huitema wrote:
> We could use plenty of bits like that: ECN echo comes to mind. We don&= #39;t.
> We use frames. From that point of view, using ACK as a check is more i= n
> line with the QUIC design. "Don't roll the key if you have no= t received
> at least one ACK for the current phase" seems much simpler. Also,= it
> uses an honest signal, by opposition to a random bit, and that doesn&#= 39;t
> create an other class of misbehavior.

If you look at the history of the PR, I initially proposed using ACK in exa= ctly this way.=C2=A0 The feedback I got was that this was difficult for peo= ple to implement, because it more tightly couples two parts of the processi= ng pipeline than was previously necessary.=C2=A0 That is, if you consider p= acket protection as a discrete stage in processing, getting information to = and from the ACK frame processing might be difficult, depending on implemen= tation structure.

We've been very careful to avoid having protocol behaviour that trigger= s on acknowledgment.=C2=A0 I don't think that we have any that escape t= he loss recovery and CC algorithms.=C2=A0 As an architectural principle, I = think that is worth preserving.

I= 9;m not sure this principle is that important, but if it is, we could intro= duce a new frame for this purpose. KEY_PHASE_RECEIVED, or some such.
<= /div>
--0000000000003d8d5d057f0e7406-- From nobody Wed Jan 9 15:17:00 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1794C131073 for ; Wed, 9 Jan 2019 15:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=hsLps8OE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GQHH5S87 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 QvTcKZaluc7D for ; Wed, 9 Jan 2019 15:16:51 -0800 (PST) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F37D130FF6 for ; Wed, 9 Jan 2019 15:16:51 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.west.internal (Postfix) with ESMTP id 11FDA13FB; Wed, 9 Jan 2019 18:16:50 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute1.internal (MEProxy); Wed, 09 Jan 2019 18:16:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:date:subject; s=fm1; bh=OAi SHDxlxQATbKGW24ATJk0IqDFZZsoLpd9QU/2m6b4=; b=hsLps8OEBh4BXI5X92B A4hSOkAiHtPMNQ0iIlDPkLFLLEBGcrQf1ZufAwYU9+RyPv6BEOtKrFoYyZCFXDDH mGp+oNkWQhlxStckgKLX+r/Z+DZ1Tc9gkAMtSemkQrFeBEuV4dBGKyrAh8ROzInV jknrFPOzbHq296sQMFD605rQviCbxd5DI/yxhaZi1PJEp0s1bwwDWtpUhdBDUPxL jQSjROJDPDLukOfTaN7DBPb7F+wWdjLr8fMLTwe0vx0mA7MwdtQqbV+H1F0gUZDD oqIAYoKtDqS1bpGmJerJz43iYCaiS/eZ5B1B4uysWPsqi5Uz5dYoeX9qnFYQkNfc Osg== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=OAiSHDxlxQATbKGW24ATJk0IqDFZZsoLpd9QU/2m6 b4=; b=GQHH5S87PYzZ3EhpUCTUWfUD3Z9Qg2g8HmqLiSEp5Fk0xpQqesyYO3ZHZ GcBP6TUxOqjMH6USCnOisVZfJkNxwx1et/2cAXs1PSEQiStlc6c1EejM3OMgAELR r1Yp461DnFD6k9V9TcljmUD/tcITlLCcYMQA42r1kQ5REASfuWOBWhPMxynGH7az dBsyuKAsAAnEvvmLIb5l3ZU3U/JA8s5AYO8vs8WzECx9o8SpK8KQAzl/TO3DXYK8 vZKpsRNc4ycQxk/ocz6McsoPXLHfwkvworQhFe1y/2DxMxICX2QT0j7ohYrN+Yle 2u1eWAggtffO3PPRxVeZ4JKZnqMFg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedvgddtjeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkffhvfgggfgtofgjfhffufesthejredtredtjeenucfhrhhomhepofgrrhht ihhnucfvhhhomhhsohhnuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 38344BA783; Wed, 9 Jan 2019 18:16:48 -0500 (EST) Message-Id: <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> From: Martin Thomson To: Ryan Hamilton Cc: Christian Huitema , Ian Swett , IETF QUIC WG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae1f753 In-Reply-To: References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> Date: Thu, 10 Jan 2019 10:16:48 +1100 Subject: Re: Key updates Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 23:16:58 -0000 On Thu, Jan 10, 2019, at 10:02, Ryan Hamilton wrote: > On Wed, Jan 9, 2019 at 2:13 PM Martin Thomson wrote: > > We've been very careful to avoid having protocol behaviour that triggers > > on acknowledgment. I don't think that we have any that escape the loss > > recovery and CC algorithms. As an architectural principle, I think that is > > worth preserving. > > I'm not sure this principle is that important, but if it is, we could > introduce a new frame for this purpose. KEY_PHASE_RECEIVED, or some such. I think it is. I know that some implementations provide hooks for acknowledgments, and that wouldn't be prohibited, but it's different if those hooks become mandatory. A new frame is certainly possible, but it could eliminate what might be a useful feature (disabling key updates). We'd also need to consider what to do about this message around the end of the handshake. One thing Kazuho wants to do is block key updates until 0-RTT keys are discarded, effectively treating the 0-RTT to 1-RTT transition as a key update. From nobody Wed Jan 9 16:49:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D73412DF72 for ; Wed, 9 Jan 2019 16:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 H0vSKmoh9bU3 for ; Wed, 9 Jan 2019 16:49:34 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B6012DD85 for ; Wed, 9 Jan 2019 16:49:34 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ghOXM-0000iC-6e for quic@ietf.org; Thu, 10 Jan 2019 01:49:33 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ghOXG-0000r7-Il for quic@ietf.org; Wed, 09 Jan 2019 19:49:30 -0500 Received: (qmail 24560 invoked from network); 10 Jan 2019 00:49:23 -0000 Received: from unknown (HELO [IPv6:2607:fb90:f2b:33f2:c095:9989:4f51:2027]) (Authenticated-user:_huitema@huitema.net@[172.58.41.32]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Jan 2019 00:49:23 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16C101) In-Reply-To: <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> Date: Wed, 9 Jan 2019 16:49:22 -0800 Cc: Ryan Hamilton , IETF QUIC WG , Ian Swett Content-Transfer-Encoding: quoted-printable Message-Id: References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> To: Martin Thomson Subject: Re: Key updates X-Originating-IP: 168.144.250.223 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.12) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5pVuvT4WJQRlTQYAWFUPxJV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVid+A6pJjNCnXrhsbzubQMzc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1XpqFDyTB1Bz0n/bLAAUYB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaJwAHPn4EuYWIk0YD/RIopThgL6QxS4osK9V1p/ZT+2SxYQL3rkPJsC +1n3pW2blFVk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAliU20wPuSTm+IJBmdo0FC1ZZYSpQQtCkh8qZ SV0LCxteuSuckhomOFfvTwII94N+rHCQbycJuR1jIkYqmfn2XoIhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uKxlHEurUN5OnjeiFCqHX+Ta9UshveVgoiypAicYsWUtd8y9Ga5iCmdJFIvDE Jb+pKY4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 00:49:37 -0000 =20 > On Jan 9, 2019, at 3:16 PM, Martin Thomson wrote: >=20 >> On Thu, Jan 10, 2019, at 10:02, Ryan Hamilton wrote: >>> On Wed, Jan 9, 2019 at 2:13 PM Martin Thomson wrote:= >>> We've been very careful to avoid having protocol behaviour that triggers= >>> on acknowledgment. I don't think that we have any that escape the loss >>> recovery and CC algorithms. As an architectural principle, I think that= is >>> worth preserving. >>=20 >> I'm not sure this principle is that important, but if it is, we could >> introduce a new frame for this purpose. KEY_PHASE_RECEIVED, or some such.= >=20 > I think it is. I know that some implementations provide hooks for acknowl= edgments, and that wouldn't be prohibited, but it's different if those hooks= become mandatory. You do not have separation today. You only validate the phase bit if it come= s from a new packet. The requirement is to only rotate the key if at least o= ne of the current phase packets has been acknowledged. That's a high level s= ender side decision, typically not something you would delegate to a line ca= rd. >=20 > A new frame is certainly possible, but it could eliminate what might be a u= seful feature (disabling key updates). We'd also need to consider what to d= o about this message around the end of the handshake. One thing Kazuho want= s to do is block key updates until 0-RTT keys are discarded, effectively tre= ating the 0-RTT to 1-RTT transition as a key update. >=20 Another issue is that not setting the enabling bit at time T does not mean i= t will not be set later. So that's not a good way to indicate lack of suppor= t for key update. If you want that the proper tool is a transport parameter.= -- Christian Huitema=20= From nobody Wed Jan 9 16:50:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AF8130E1C for ; Wed, 9 Jan 2019 16:50:29 -0800 (PST) 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 KNKR10t9uDVi for ; Wed, 9 Jan 2019 16:50:27 -0800 (PST) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 E31A712DD85 for ; Wed, 9 Jan 2019 16:50:26 -0800 (PST) Received: by mail-lf1-x142.google.com with SMTP id i26so7084929lfc.0 for ; Wed, 09 Jan 2019 16:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Hdrt4s26bmlbvKt6UiCBV4Pv5Tw1DcQUeYEPolyEZsU=; b=d/yEz8YX+06EaZKj/CisgFk6KYQMdxWwT6ZJeuW/4nbHez5j0qe2a+WAZF9jqsvc9I Osr4PES2ltzyqCkSBoLwIgmohyZ6c31pkHIhXD2AiVJC3LQ2mE2KBd+7q5cTuG0hfhKd DGHzjKo98P8iHvohE0wDaMj/j3zvy/ygtN/9c+CUXfsBO8/Xq4ga44VtOiwC5uvsV3zY GXsQVGTo4FmLnhCn8Kr7E4laTWRIOTWQVL2ksPKOuyvtU3jE5Wm+/e+GR1e0/PhE6w9i 1bEK1SSGs/Mdb6NND5VR1cLc2QdXICylq4iNWTR+iz83+HsWqxXMnRMVryX0QZnnOb2O Fpxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Hdrt4s26bmlbvKt6UiCBV4Pv5Tw1DcQUeYEPolyEZsU=; b=dQqBQUyLACQ1foH8eitjbHrR0vhElv9+G55Ics+rwAncZ+573dq+uaixMDpNA52GHJ ZPCe3WTcWnsYtLHURkJETzKIUumvt33wzVvw6YXG+zuJzMeVzvlUqA6dm0KsxO3GqVgU VfKHNYcISusJvuFCXjXzTxywcxK1TAE065qNU18D/+wyhzHBNMza/ZXUA/wOjfRTJ0AF k0CoyI+/miZTGACMdAGms6O6QDe06RTFfZQXroencB3xB0DE286gCcuPF5cc10ptlvrR 6EfT4FSdG4tNp2sVX+Vob736LJzeo3b1wqwa8csgw8vuPeMtivACOJRMF4Wdmh4JAkn4 wVBg== X-Gm-Message-State: AJcUukdrxE3IYWdp0pUO0vtRADNLeFAWr89qbqbLTIRK/+3BiXTxcBqW rq8o7m5eHPtp2IcbZ59b/QrHGaclQq1Jtotx4JMTkg== X-Google-Smtp-Source: ALg8bN6pxxZ+MHcz3HRGOyajJLBpea98bK9ofPhMGGNC5TSmlS/BcWlDvyhc7Rficq124vYOzQP3g5XW9AYcgfjHbJ8= X-Received: by 2002:a19:1994:: with SMTP id 142mr4901742lfz.134.1547081425074; Wed, 09 Jan 2019 16:50:25 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> In-Reply-To: From: Kazuho Oku Date: Thu, 10 Jan 2019 09:50:13 +0900 Message-ID: Subject: Re: Key updates To: Ryan Hamilton Cc: Martin Thomson , IETF QUIC WG , Christian Huitema , Ian Swett Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 00:50:29 -0000 2019=E5=B9=B41=E6=9C=8810=E6=97=A5(=E6=9C=A8) 8:02 Ryan Hamilton : > > On Wed, Jan 9, 2019 at 2:13 PM Martin Thomson wrote: >> >> On Thu, Jan 10, 2019, at 02:12, Christian Huitema wrote: >> > We could use plenty of bits like that: ECN echo comes to mind. We don'= t. >> > We use frames. From that point of view, using ACK as a check is more i= n >> > line with the QUIC design. "Don't roll the key if you have not receive= d >> > at least one ACK for the current phase" seems much simpler. Also, it >> > uses an honest signal, by opposition to a random bit, and that doesn't >> > create an other class of misbehavior. >> >> If you look at the history of the PR, I initially proposed using ACK in = exactly this way. The feedback I got was that this was difficult for peopl= e to implement, because it more tightly couples two parts of the processing= pipeline than was previously necessary. That is, if you consider packet p= rotection as a discrete stage in processing, getting information to and fro= m the ACK frame processing might be difficult, depending on implementation = structure. >> >> We've been very careful to avoid having protocol behaviour that triggers= on acknowledgment. I don't think that we have any that escape the loss re= covery and CC algorithms. As an architectural principle, I think that is w= orth preserving. > > > I'm not sure this principle is that important, but if it is, we could int= roduce a new frame for this purpose. KEY_PHASE_RECEIVED, or some such. While that's possible, using a frame makes the design complicated, because a frame is not tied to a particular generation of a traffic key. An endpoint is allowed to retransmit a frame of lost packet as it is. That means that you cannot use the generation of the packet that carried the frame to infer for which key generation the KEY_PHASE_RECEIVED frame permits an update. Therefore, the design of such a frame needs to carry the generation of the traffic key as a number, possibly as a varint field. And the receiver would also be required to validate that the value is no more than current generation + 1. Compared to that, having the key phase bit and the update permitted bit next to each other is much simpler. -- Kazuho Oku From nobody Wed Jan 9 16:55:31 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D0C130DC9 for ; Wed, 9 Jan 2019 16:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=P2pVs/HE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vcrKTz44 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 cEi-_rIZ1kA5 for ; Wed, 9 Jan 2019 16:55:29 -0800 (PST) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B9D12DD85 for ; Wed, 9 Jan 2019 16:55:29 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.west.internal (Postfix) with ESMTP id 6806011E5; Wed, 9 Jan 2019 19:55:28 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute1.internal (MEProxy); Wed, 09 Jan 2019 19:55:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:date:in-reply-to:references:subject; s=fm1; bh=PE3 VytTJ1LBHNq0FRceACe4MKK9JorgoAU3OYLeYvh4=; b=P2pVs/HEs91iUMqA3NL BHElOmgx3m4ATklocNVNXPVlsQ5Ao5zEh40G9m0kznJm8LnsvhXbe3OYnnem+jq1 UqobvICgeZnltT+t5Ukg8D2sWfgJJuBwI6vpXKaeNU9ALRFbutONHNj/P9Kw8oS9 m2p0+a5Ca2pOttYwrkzYs/95J4b6BEeL/9IKfDKTwf13VXgXymA3bbCh/G+ngbiv /JSNjDlQZF9rK2asoCzBqX9ETYU0PMyAxgpcgJW8OnN2XdY+DyQsHHlS73IrPf92 Yk2TClgqFR81caUiPrhy4HaFbE8nsYYaDZxKWzdDovqDsNT57I59iVZrg6X1OZbA AaA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=PE3VytTJ1LBHNq0FRceACe4MKK9JorgoAU3OYLeYv h4=; b=vcrKTz444U9UuzSnxT8TPEe/wHJ/m3pAIZSIx9WRRKZewCB/vq7NYPafp TGIHAY2R4hcF30Myxaki9vFh6aDJtlpeADr36vGOQYjThP+cUDWphdsd2jy8rrwF GOY2b0xLrZeT8pexWPHF/2hX88BKg9470rS68uPxx3mnUjI8S5VgvV1vkmD+E68u su0GCaPFSZYLCCDCUS2KgWcXutM5ylasEMQwi1qRBeMOiQ+gYSqqtpfR76KLosLB zOTLiEc/qtSNbJ/TS1gj/UV+02XjBwEMOp0SS/0hqOf3TELWZMw1riPiqip+FKg8 UUPHP7VCNEOT5zg2PwjhR1InaZLqg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedvgddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof ffjghfufesthejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceo mhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 82F32BA783; Wed, 9 Jan 2019 19:55:26 -0500 (EST) Message-Id: <1547081726.463246.1630426432.2EFADC98@webmail.messagingengine.com> From: Martin Thomson To: Kazuho Oku , Ryan Hamilton Cc: IETF QUIC WG , Christian Huitema , Ian Swett MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae1f753 Date: Thu, 10 Jan 2019 11:55:26 +1100 In-Reply-To: References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> Subject: Re: Key updates Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 00:55:30 -0000 On Thu, Jan 10, 2019, at 11:50, Kazuho Oku wrote: > While that's possible, using a frame makes the design complicated, > because a frame is not tied to a particular generation of a traffic > key. I'd forgotten that. Thanks Kazuho. We could probably fix that by maintaining a counter (or epoch, to use DTLS terminology) that increments with each key update and send that in the frame if we were committed to using frames. That starts to look like a MAX_KEY_PHASE or MAX_KEY_EPOCH frame. From nobody Wed Jan 9 17:36:54 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586B613109F for ; Wed, 9 Jan 2019 17:36:53 -0800 (PST) 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 o6Ft-DNnD1C1 for ; Wed, 9 Jan 2019 17:36:51 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 EDE4E131092 for ; Wed, 9 Jan 2019 17:36:50 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id t18-v6so8228878ljd.4 for ; Wed, 09 Jan 2019 17:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iMmbqhy0zbyuwce235OJjXHbk/yPVzPY/860bcfSpU4=; b=jQMVCFoOx/N2VPZFqNP4w8JKgNXfRJ8ejeahtSZOtAbFWpm/zSimBQOzasfRm/6Xo0 KbSOVmgOdzVcZxyna21QgIuQ4k0FG4Stk3YxKJqBPPTD3vlR95F+3rv7ypl+f01RdLQ8 DeHSDpxCMP/fPV3B+3rah5XfRGd/IAC3l33uLSQ13weTEWcb0rJtMXOXgbKoC6M5NoXg rGVzlBfRE1KYWEG8WTnfG/HvDo1eX/ZIyV3Gt8z030enmiWJ0UvzDfnpFFI3flhbk0PD 3Z9ydNksbmZfHlDZKosdJ4/IkBfx3Fu3DS/bKF4reEavFGoHumdSJ7g9zHt23AjL3yQU K9mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iMmbqhy0zbyuwce235OJjXHbk/yPVzPY/860bcfSpU4=; b=CsD1GApRPi0k9hj65QXMxSFhx4SLuBSvyiHsH5L/AatcpfJxHm591Ehe2Xv1r8aRs9 V8A7sqjBQLj4IlSOFJTMNbIgUwRLTWMebzZJJiSKsbfY7Vb+36kvzQHLFSsblAtobhIa +lKSKaYdTL4MSgHGQuUc9bCH4lwnt1f0Z7KyaEBXgembgkdKOrW3CnNywt20dbbDW1bn JinGJOtX+gMHWXTUKJF0nFyz/FCm9+akP/Jm/VMwH6uIIFd2/5P6RX607TEaehEnu/Yp C2lhSi37MTNdjLC7pjf9FMAWAYo0M7p03ZqKba/CQNO29A4sCUkLm1fVC8J+2TvNi8i5 DFNg== X-Gm-Message-State: AJcUukejNBImLLODdH9DDcbbp/1hL2dN39K2DSO3PBZeFCyZCz0bIpiQ iFaosxkSuViTp+7/8jeUU1JdsWy/skJZWbSO7T6cEw== X-Google-Smtp-Source: ALg8bN5Ts68bkaef3/wtT60ywAcKFxaU7GjFhAerf9rPiBo7FMePyYLsOaNeFo7kZ7v/1NID/xIDwvtfAnNK1yRTmLo= X-Received: by 2002:a2e:9694:: with SMTP id q20-v6mr4657447lji.173.1547084209022; Wed, 09 Jan 2019 17:36:49 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> In-Reply-To: From: Kazuho Oku Date: Thu, 10 Jan 2019 10:36:37 +0900 Message-ID: Subject: Re: Key updates To: Christian Huitema Cc: Martin Thomson , IETF QUIC WG , Ian Swett , Ryan Hamilton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 01:36:53 -0000 2019=E5=B9=B41=E6=9C=8810=E6=97=A5(=E6=9C=A8) 9:49 Christian Huitema : > > > > > On Jan 9, 2019, at 3:16 PM, Martin Thomson wrote: > > > >> On Thu, Jan 10, 2019, at 10:02, Ryan Hamilton wrote: > >>> On Wed, Jan 9, 2019 at 2:13 PM Martin Thomson wro= te: > >>> We've been very careful to avoid having protocol behaviour that trigg= ers > >>> on acknowledgment. I don't think that we have any that escape the lo= ss > >>> recovery and CC algorithms. As an architectural principle, I think t= hat is > >>> worth preserving. > >> > >> I'm not sure this principle is that important, but if it is, we could > >> introduce a new frame for this purpose. KEY_PHASE_RECEIVED, or some su= ch. > > > > I think it is. I know that some implementations provide hooks for ackn= owledgments, and that wouldn't be prohibited, but it's different if those h= ooks become mandatory. > > You do not have separation today. You only validate the phase bit if it c= omes from a new packet. The requirement is to only rotate the key if at lea= st one of the current phase packets has been acknowledged. That's a high le= vel sender side decision, typically not something you would delegate to a l= ine card. The problem of using ACK as a signal is that it could provide a false illusion that a sender is permitted to update the traffic key whenever it sees an ACK for a new generation. If the sender falsely assumes that, it would emit packets that cannot be decrypted by the receiver that tries to retain minimum number of keys (i.e. 2). My preference goes to having a design that guarantees the communication to succeed without requiring the receiver to retain a greater number of keys than necessary. > > > > > > A new frame is certainly possible, but it could eliminate what might be= a useful feature (disabling key updates). We'd also need to consider what= to do about this message around the end of the handshake. One thing Kazuh= o wants to do is block key updates until 0-RTT keys are discarded, effectiv= ely treating the 0-RTT to 1-RTT transition as a key update. > > > > Another issue is that not setting the enabling bit at time T does not mea= n it will not be set later. So that's not a good way to indicate lack of su= pport for key update. If you want that the proper tool is a transport param= eter. I am not sure if I agree that using a transport parameter is better. Typically, it is not until the sender actually goes over the threshold (e.g., send 1G packets) that it knows that the peer needs to support key updates. Assuming that is the case, there is no difference between communicating the information during the handshake and when key update becomes necessary. > -- Christian Huitema --=20 Kazuho Oku From nobody Thu Jan 10 05:34:01 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1FD130F1C for ; Thu, 10 Jan 2019 05:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 dV24OleoNjx3 for ; Thu, 10 Jan 2019 05:33:57 -0800 (PST) Received: from mail-out-4.itc.rwth-aachen.de (mail-out-4.itc.rwth-aachen.de [134.130.5.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6E9130F0E for ; Thu, 10 Jan 2019 05:33:56 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BoBAB1SDdc/xUN4oljHQEBBQEHBQGBZ?= =?us-ascii?q?YExU4FoMYN2lAmMIo9dDSyEQBmCDSI4EgEDAQECAQECbSiFdBFXASICJgIEMBU?= =?us-ascii?q?SBIM1ggIBrDyBL4VCg2aBDoELizSCFoERJx+HZIJyMYImAqF1BwKBF5BoGIoTh?= =?us-ascii?q?2maYYEnNiEogS5xeQGCQpBbghqIBwGBHgEB?= X-IPAS-Result: =?us-ascii?q?A2BoBAB1SDdc/xUN4oljHQEBBQEHBQGBZYExU4FoMYN2lAm?= =?us-ascii?q?MIo9dDSyEQBmCDSI4EgEDAQECAQECbSiFdBFXASICJgIEMBUSBIM1ggIBrDyBL?= =?us-ascii?q?4VCg2aBDoELizSCFoERJx+HZIJyMYImAqF1BwKBF5BoGIoTh2maYYEnNiEogS5?= =?us-ascii?q?xeQGCQpBbghqIBwGBHgEB?= X-IronPort-AV: E=Sophos;i="5.56,461,1539640800"; d="scan'208";a="28941051" Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-4.itc.rwth-aachen.de with ESMTP; 10 Jan 2019 14:33:55 +0100 Received: from messenger-mbx.win.comsys.rwth-aachen.de (messenger-mbx.win.comsys.rwth-aachen.de [137.226.13.43]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id 9E36A42279 for ; Thu, 10 Jan 2019 14:33:54 +0100 (CET) Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) by messenger-mbx.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 10 Jan 2019 14:33:54 +0100 Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c]) by messenger-mbx.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c%12]) with mapi id 15.00.1076.000; Thu, 10 Jan 2019 14:33:54 +0100 From: =?utf-8?B?SmFuIFLDvHRo?= To: IETF QUIC WG Subject: QUIC Version 101? Thread-Topic: QUIC Version 101? Thread-Index: AQHUqOkhp061wTKi2E2SPGB3JNC9BA== Date: Thu, 10 Jan 2019 13:33:53 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.226.12.26] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 13:34:00 -0000 SGksDQoNCg0KSeKAmW0gY3VycmVudGx5IHJ1bm5pbmcgYSBzY2FuIGZvciBRVUlDIGRyYWZ0LTE3 IGluIElQdjQgdG8gc2VlIGlmIHRoZXJlIGlzIGFscmVhZHkgc29tZSAtMTcgb3V0IHRoZXJlIGFu ZCB3aGF0IGVsc2UgdHlwaWNhbGx5IGNvbWVzIGJhY2suDQoNCkknbSBleGVyY2lzZSB0aGUgdmVy c2lvbiBuZWdvdGlhdGlvbiBmZWF0dXJlIGJ5IGFubm91bmNpbmcgYSByZXNlcnZlZCB2ZXJzaW9u IChpLmUuLCAweD9BP0E/QT9BKS4NCg0KVGhlIHNjYW4gaGFzIG5vdCBmaW5pc2hlZCBidXQgSSBh bHJlYWR5IGdvdCBzb21ldGhpbmcgYmFjayB0aGF0IGxvb2tzIG9kZCwgc2VlOg0KDQp7ICJpbmZv IjogIlZlcnNpb24gbmVnb3RpYXRpb24iLCAic2FkZHIiOiAiNTIuMTk0LjIxNi40MyIsICJjbGFz c2lmaWNhdGlvbiI6ICJxdWljLWRyYWZ0MTciLCAidmVyc2lvbnMiOiAiMDAwMDAwNjUsMUExQTNB OEEiLCAic3VjY2VzcyI6IDEgfQ0KeyAiaW5mbyI6ICJWZXJzaW9uIG5lZ290aWF0aW9uIiwgInNh ZGRyIjogIjk3LjY0LjE5LjU0IiwgImNsYXNzaWZpY2F0aW9uIjogInF1aWMtZHJhZnQxNyIsICJ2 ZXJzaW9ucyI6ICJGQTRBN0FFQSwwMDAwMDA2NSIsICJzdWNjZXNzIjogMSB9DQp7ICJpbmZvIjog IlZlcnNpb24gbmVnb3RpYXRpb24iLCAic2FkZHIiOiAiNTIuMTk4LjMuMjIyIiwgImNsYXNzaWZp Y2F0aW9uIjogInF1aWMtZHJhZnQxNyIsICJ2ZXJzaW9ucyI6ICIwMDAwMDA2NSxEQTdBMEFGQSIs ICJzdWNjZXNzIjogMSB9DQp7ICJpbmZvIjogIlZlcnNpb24gbmVnb3RpYXRpb24iLCAic2FkZHIi OiAiMzcuMTg3LjU1LjE0NCIsICJjbGFzc2lmaWNhdGlvbiI6ICJxdWljLWRyYWZ0MTciLCAidmVy c2lvbnMiOiAiMDAwMDAwNjUsMUFGQUJBMEEiLCAic3VjY2VzcyI6IDEgfQ0KeyAiaW5mbyI6ICJW ZXJzaW9uIG5lZ290aWF0aW9uIiwgInNhZGRyIjogIjIwMy4xODkuOTcuNjYiLCAiY2xhc3NpZmlj YXRpb24iOiAicXVpYy1kcmFmdDE3IiwgInZlcnNpb25zIjogIjAwMDAwMDY1LDBBRkE5QTdBIiwg InN1Y2Nlc3MiOiAxIH0NCnsgImluZm8iOiAiVmVyc2lvbiBuZWdvdGlhdGlvbiIsICJzYWRkciI6 ICI0Ny43NC4yMzEuMTYxIiwgImNsYXNzaWZpY2F0aW9uIjogInF1aWMtZHJhZnQxNyIsICJ2ZXJz aW9ucyI6ICI2QTFBMEE2QSwwMDAwMDA2NSIsICJzdWNjZXNzIjogMSB9DQp7ICJpbmZvIjogIlZl cnNpb24gbmVnb3RpYXRpb24iLCAic2FkZHIiOiAiMTQ0LjM0LjE2MC41MCIsICJjbGFzc2lmaWNh dGlvbiI6ICJxdWljLWRyYWZ0MTciLCAidmVyc2lvbnMiOiAiMDAwMDAwNjUsMkFFQUVBMkEiLCAi c3VjY2VzcyI6IDEgfQ0KeyAiaW5mbyI6ICJWZXJzaW9uIG5lZ290aWF0aW9uIiwgInNhZGRyIjog IjE1My4xMjAuMTgwLjIzMCIsICJjbGFzc2lmaWNhdGlvbiI6ICJxdWljLWRyYWZ0MTciLCAidmVy c2lvbnMiOiAiOEE0QUNBQ0EsMDAwMDAwNjUiLCAic3VjY2VzcyI6IDEgfQ0KeyAiaW5mbyI6ICJW ZXJzaW9uIG5lZ290aWF0aW9uIiwgInNhZGRyIjogIjE0OS4yOC45My4xMjMiLCAiY2xhc3NpZmlj YXRpb24iOiAicXVpYy1kcmFmdDE3IiwgInZlcnNpb25zIjogIjAwMDAwMDY1LDlBOUExQUZBIiwg InN1Y2Nlc3MiOiAxIH0NCg0KSSB3YXMgd29uZGVyaW5nIGlmIGFueW9uZSBjb3VsZCB0ZWxsIG1l IHdoYXQgdmVyc2lvbiAweDAwMDAwMDY1IChkZWNpbWFsOiAxMDEpIGlzLiBJIHRob3VnaHQgMHgw MDAwMDAwMSB0byAweDAwMDBmZmZmIHdhcyByZXNlcnZlZCBmb3Igc3RhbmRhcmRpemVkIHZlcnNp b25zLg0KQXBhcnQgZnJvbSB0aGlzLCB0aGV5IGFsbCBnZW5lcmF0ZSBhIGRyYWZ0LTE3IGNvbXBs aWFudCB2ZXJzaW9uIG5lZ290aWF0aW9uIHBhY2tldC4NCg0KDQoNCkJlc3QgDQogSmFuDQoNCg0K DQo= From nobody Thu Jan 10 05:56:59 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E042128B14 for ; Thu, 10 Jan 2019 05:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 eJEXrJItbupy for ; Thu, 10 Jan 2019 05:56:56 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 2345F124B0C for ; Thu, 10 Jan 2019 05:56:56 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id r14so12831415qtp.1 for ; Thu, 10 Jan 2019 05:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=xJVYXYHHNwQI4Oo0A2il+qt/9jeYA3Ka3kyxDE9MRO8=; b=QX8O2jtL45b21qvO0lkBSoBP4Wezh1e6uCPS8PBmXO8R5+HnpGUh1ib2EJ+yBHrrIO trsxSGBrKy1AjG3IIO9sOY33EYKk9PIV/dI3MfyWbwGNaZ3OWcET6aIB8+KForVot6vW GYNlJ3pb0rrtJ1jBNV8MlBwzn3Uj+ppXsJeQzv4bee2vdBkaxLPY3BxogtMk0EZataKJ hcJxuu0Q+DcUXsc1FkZF0jnNjsgdRVVYL96QJ+8LUO9gdRJ/bxXs1wdOSI17V8aw5UsI YR8b4DwgFR2kM9bFS4Jw64qgoI1lHokTJBvKGiWJSIBX+4feCHkwEvyyRKO9wToGs46o hkrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=xJVYXYHHNwQI4Oo0A2il+qt/9jeYA3Ka3kyxDE9MRO8=; b=SuPBXIHxDx8ftxXHJIccCnqgHzLVc/SnW4qaXYaTMIu80bvBdx34D0N6obVO2Gp/K1 BnIhVoRYbchCILIzR9tBgNoPiKMQWJu4XEtRIs8RvSfxtGXrrHr7fKQSOm6m/O7Yxylc yiq1JWrQBgsqhhRNt2IxAbrZOeYu2pgy5OEdcTIad9U8fGOM78SeYb5ly6Hudh30wBGc r4WACyZc3usxHqDJrboRUk6KbDCD9v1b9J/jEytwirIxB1HNCu8n+o5eQdAJdxJ/yRan 9VXNHu6jN4iorR+832rrHL8scQIQVszdQmMYFhIQGsgYv0zjF8/c3Noa1wGHHnmTXXPu UydQ== X-Gm-Message-State: AJcUukcdGTdJRTq7OHbw+uaFT2mR3OzFWMtkMeeaa9rWL8MlHRICKKPp /H9bCBvVtVAF6mfuDJ3GKME5oR0kVkc= X-Google-Smtp-Source: ALg8bN6IXXsmLNFOBWQrdHdV4OvvnF2gz5gyQbtOB7UC8cB//4G/dVhhDCSDow6p9il73iDyCu5xVw== X-Received: by 2002:a37:8541:: with SMTP id h62mr9250027qkd.213.1547128615239; Thu, 10 Jan 2019 05:56:55 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id o129sm35176230qke.5.2019.01.10.05.56.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jan 2019 05:56:54 -0800 (PST) Date: Thu, 10 Jan 2019 08:56:45 -0500 From: Dmitri Tikhonov To: Jan =?iso-8859-1?Q?R=FCth?= Cc: IETF QUIC WG Subject: Re: QUIC Version 101? Message-ID: <20190110135644.GA11764@ubuntu-dmitri> Mail-Followup-To: Jan =?iso-8859-1?Q?R=FCth?= , IETF QUIC WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 13:56:58 -0000 I poked a couple of those and indeed, these are the version negotiation packets that come back. One thing I noticed is that the ?A?A?A?A version included in the list of supported version changes on every response. - Dmitri. On Thu, Jan 10, 2019 at 01:33:53PM +0000, Jan Rüth wrote: > Hi, > > > I’m currently running a scan for QUIC draft-17 in IPv4 to see if there is already some -17 out there and what else typically comes back. > > I'm exercise the version negotiation feature by announcing a reserved version (i.e., 0x?A?A?A?A). > > The scan has not finished but I already got something back that looks odd, see: > > { "info": "Version negotiation", "saddr": "52.194.216.43", "classification": "quic-draft17", "versions": "00000065,1A1A3A8A", "success": 1 } > { "info": "Version negotiation", "saddr": "97.64.19.54", "classification": "quic-draft17", "versions": "FA4A7AEA,00000065", "success": 1 } > { "info": "Version negotiation", "saddr": "52.198.3.222", "classification": "quic-draft17", "versions": "00000065,DA7A0AFA", "success": 1 } > { "info": "Version negotiation", "saddr": "37.187.55.144", "classification": "quic-draft17", "versions": "00000065,1AFABA0A", "success": 1 } > { "info": "Version negotiation", "saddr": "203.189.97.66", "classification": "quic-draft17", "versions": "00000065,0AFA9A7A", "success": 1 } > { "info": "Version negotiation", "saddr": "47.74.231.161", "classification": "quic-draft17", "versions": "6A1A0A6A,00000065", "success": 1 } > { "info": "Version negotiation", "saddr": "144.34.160.50", "classification": "quic-draft17", "versions": "00000065,2AEAEA2A", "success": 1 } > { "info": "Version negotiation", "saddr": "153.120.180.230", "classification": "quic-draft17", "versions": "8A4ACACA,00000065", "success": 1 } > { "info": "Version negotiation", "saddr": "149.28.93.123", "classification": "quic-draft17", "versions": "00000065,9A9A1AFA", "success": 1 } > > I was wondering if anyone could tell me what version 0x00000065 (decimal: 101) is. I thought 0x00000001 to 0x0000ffff was reserved for standardized versions. > Apart from this, they all generate a draft-17 compliant version negotiation packet. > > > > Best > Jan > > > From nobody Thu Jan 10 06:01:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D56128B14 for ; Thu, 10 Jan 2019 06:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 01rtYc8nQJwd for ; Thu, 10 Jan 2019 06:01:13 -0800 (PST) Received: from mail-out-2.itc.rwth-aachen.de (mail-out-2.itc.rwth-aachen.de [134.130.5.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBED130DCD for ; Thu, 10 Jan 2019 06:00:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2C6AAASTzdc/xUN4oljHAEBAQQBAQcEA?= =?us-ascii?q?QGBVAQBAQsBgQ0jU4FoJwqDdpQJgg2HfoIXj10NLIRAAheCDSI3Bg0BAwEBAgE?= =?us-ascii?q?BAm0ohUsGI1YQAgEIDjEDAgICMBQRAgQOBYMigR5kAaw4gS+FQoNmgQ6MP4IWg?= =?us-ascii?q?REnH4JMhRiCcjGCJgKPXJIZBwKBF5BoGIoTh2maYYEnNSIogS5xTyoBgkGQXHK?= =?us-ascii?q?BKIgHAYEeAQE?= X-IPAS-Result: =?us-ascii?q?A2C6AAASTzdc/xUN4oljHAEBAQQBAQcEAQGBVAQBAQsBgQ0?= =?us-ascii?q?jU4FoJwqDdpQJgg2HfoIXj10NLIRAAheCDSI3Bg0BAwEBAgEBAm0ohUsGI1YQA?= =?us-ascii?q?gEIDjEDAgICMBQRAgQOBYMigR5kAaw4gS+FQoNmgQ6MP4IWgREnH4JMhRiCcjG?= =?us-ascii?q?CJgKPXJIZBwKBF5BoGIoTh2maYYEnNSIogS5xTyoBgkGQXHKBKIgHAYEeAQE?= X-IronPort-AV: E=Sophos; i="5.56,461,1539640800"; d="scan'208,217"; a="65899960" Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-2.itc.rwth-aachen.de with ESMTP; 10 Jan 2019 15:00:56 +0100 Received: from messenger-mbx.win.comsys.rwth-aachen.de (messenger-mbx.win.comsys.rwth-aachen.de [137.226.13.43]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id D2CAC42279; Thu, 10 Jan 2019 15:00:56 +0100 (CET) Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) by messenger-mbx.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 10 Jan 2019 15:00:56 +0100 Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c]) by messenger-mbx.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c%12]) with mapi id 15.00.1076.000; Thu, 10 Jan 2019 15:00:56 +0100 From: =?utf-8?B?SmFuIFLDvHRo?= To: Dmitri Tikhonov CC: IETF QUIC WG Subject: Re: QUIC Version 101? Thread-Topic: QUIC Version 101? Thread-Index: AQHUqOkhOP8rBfRGDkGQ1H7iG6jfHaWodg+AgAABKoA= Date: Thu, 10 Jan 2019 14:00:55 +0000 Message-ID: <8235B8CB-F934-483C-BCD7-C2FA978BAC14@comsys.rwth-aachen.de> References: <20190110135644.GA11764@ubuntu-dmitri> In-Reply-To: <20190110135644.GA11764@ubuntu-dmitri> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.226.12.26] Content-Type: multipart/alternative; boundary="_000_8235B8CBF934483CBCD7C2FA978BAC14comsysrwthaachende_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 14:01:15 -0000 --_000_8235B8CBF934483CBCD7C2FA978BAC14comsysrwthaachende_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVwLCBpdCBzZWVtcyB0aGF0IHRoZXNlIGFyZSBub3Qgc3RhdGljIHJlcGxpZXMgOikNCg0KDQpP biAxMC4gSmFuIDIwMTksIGF0IDE0OjU2LCBEbWl0cmkgVGlraG9ub3YgPGR0aWtob25vdkBsaXRl c3BlZWR0ZWNoLmNvbTxtYWlsdG86ZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guY29tPj4gd3JvdGU6 DQoNCkkgcG9rZWQgYSBjb3VwbGUgb2YgdGhvc2UgYW5kIGluZGVlZCwgdGhlc2UgYXJlIHRoZSB2 ZXJzaW9uDQpuZWdvdGlhdGlvbiBwYWNrZXRzIHRoYXQgY29tZSBiYWNrLiAgT25lIHRoaW5nIEkg bm90aWNlZCBpcw0KdGhhdCB0aGUgP0E/QT9BP0EgdmVyc2lvbiBpbmNsdWRlZCBpbiB0aGUgbGlz dCBvZiBzdXBwb3J0ZWQNCnZlcnNpb24gY2hhbmdlcyBvbiBldmVyeSByZXNwb25zZS4NCg0KIC0g RG1pdHJpLg0KDQpPbiBUaHUsIEphbiAxMCwgMjAxOSBhdCAwMTozMzo1M1BNICswMDAwLCBKYW4g UsO8dGggd3JvdGU6DQpIaSwNCg0KDQpJ4oCZbSBjdXJyZW50bHkgcnVubmluZyBhIHNjYW4gZm9y IFFVSUMgZHJhZnQtMTcgaW4gSVB2NCB0byBzZWUgaWYgdGhlcmUgaXMgYWxyZWFkeSBzb21lIC0x NyBvdXQgdGhlcmUgYW5kIHdoYXQgZWxzZSB0eXBpY2FsbHkgY29tZXMgYmFjay4NCg0KSSdtIGV4 ZXJjaXNlIHRoZSB2ZXJzaW9uIG5lZ290aWF0aW9uIGZlYXR1cmUgYnkgYW5ub3VuY2luZyBhIHJl c2VydmVkIHZlcnNpb24gKGkuZS4sIDB4P0E/QT9BP0EpLg0KDQpUaGUgc2NhbiBoYXMgbm90IGZp bmlzaGVkIGJ1dCBJIGFscmVhZHkgZ290IHNvbWV0aGluZyBiYWNrIHRoYXQgbG9va3Mgb2RkLCBz ZWU6DQoNCnsgImluZm8iOiAiVmVyc2lvbiBuZWdvdGlhdGlvbiIsICJzYWRkciI6ICI1Mi4xOTQu MjE2LjQzIiwgImNsYXNzaWZpY2F0aW9uIjogInF1aWMtZHJhZnQxNyIsICJ2ZXJzaW9ucyI6ICIw MDAwMDA2NSwxQTFBM0E4QSIsICJzdWNjZXNzIjogMSB9DQp7ICJpbmZvIjogIlZlcnNpb24gbmVn b3RpYXRpb24iLCAic2FkZHIiOiAiOTcuNjQuMTkuNTQiLCAiY2xhc3NpZmljYXRpb24iOiAicXVp Yy1kcmFmdDE3IiwgInZlcnNpb25zIjogIkZBNEE3QUVBLDAwMDAwMDY1IiwgInN1Y2Nlc3MiOiAx IH0NCnsgImluZm8iOiAiVmVyc2lvbiBuZWdvdGlhdGlvbiIsICJzYWRkciI6ICI1Mi4xOTguMy4y MjIiLCAiY2xhc3NpZmljYXRpb24iOiAicXVpYy1kcmFmdDE3IiwgInZlcnNpb25zIjogIjAwMDAw MDY1LERBN0EwQUZBIiwgInN1Y2Nlc3MiOiAxIH0NCnsgImluZm8iOiAiVmVyc2lvbiBuZWdvdGlh dGlvbiIsICJzYWRkciI6ICIzNy4xODcuNTUuMTQ0IiwgImNsYXNzaWZpY2F0aW9uIjogInF1aWMt ZHJhZnQxNyIsICJ2ZXJzaW9ucyI6ICIwMDAwMDA2NSwxQUZBQkEwQSIsICJzdWNjZXNzIjogMSB9 DQp7ICJpbmZvIjogIlZlcnNpb24gbmVnb3RpYXRpb24iLCAic2FkZHIiOiAiMjAzLjE4OS45Ny42 NiIsICJjbGFzc2lmaWNhdGlvbiI6ICJxdWljLWRyYWZ0MTciLCAidmVyc2lvbnMiOiAiMDAwMDAw NjUsMEFGQTlBN0EiLCAic3VjY2VzcyI6IDEgfQ0KeyAiaW5mbyI6ICJWZXJzaW9uIG5lZ290aWF0 aW9uIiwgInNhZGRyIjogIjQ3Ljc0LjIzMS4xNjEiLCAiY2xhc3NpZmljYXRpb24iOiAicXVpYy1k cmFmdDE3IiwgInZlcnNpb25zIjogIjZBMUEwQTZBLDAwMDAwMDY1IiwgInN1Y2Nlc3MiOiAxIH0N CnsgImluZm8iOiAiVmVyc2lvbiBuZWdvdGlhdGlvbiIsICJzYWRkciI6ICIxNDQuMzQuMTYwLjUw IiwgImNsYXNzaWZpY2F0aW9uIjogInF1aWMtZHJhZnQxNyIsICJ2ZXJzaW9ucyI6ICIwMDAwMDA2 NSwyQUVBRUEyQSIsICJzdWNjZXNzIjogMSB9DQp7ICJpbmZvIjogIlZlcnNpb24gbmVnb3RpYXRp b24iLCAic2FkZHIiOiAiMTUzLjEyMC4xODAuMjMwIiwgImNsYXNzaWZpY2F0aW9uIjogInF1aWMt ZHJhZnQxNyIsICJ2ZXJzaW9ucyI6ICI4QTRBQ0FDQSwwMDAwMDA2NSIsICJzdWNjZXNzIjogMSB9 DQp7ICJpbmZvIjogIlZlcnNpb24gbmVnb3RpYXRpb24iLCAic2FkZHIiOiAiMTQ5LjI4LjkzLjEy MyIsICJjbGFzc2lmaWNhdGlvbiI6ICJxdWljLWRyYWZ0MTciLCAidmVyc2lvbnMiOiAiMDAwMDAw NjUsOUE5QTFBRkEiLCAic3VjY2VzcyI6IDEgfQ0KDQpJIHdhcyB3b25kZXJpbmcgaWYgYW55b25l IGNvdWxkIHRlbGwgbWUgd2hhdCB2ZXJzaW9uIDB4MDAwMDAwNjUgKGRlY2ltYWw6IDEwMSkgaXMu IEkgdGhvdWdodCAweDAwMDAwMDAxIHRvIDB4MDAwMGZmZmYgd2FzIHJlc2VydmVkIGZvciBzdGFu ZGFyZGl6ZWQgdmVyc2lvbnMuDQpBcGFydCBmcm9tIHRoaXMsIHRoZXkgYWxsIGdlbmVyYXRlIGEg ZHJhZnQtMTcgY29tcGxpYW50IHZlcnNpb24gbmVnb3RpYXRpb24gcGFja2V0Lg0KDQoNCg0KQmVz dA0KSmFuDQoNCg0KDQoNCg== --_000_8235B8CBF934483CBCD7C2FA978BAC14comsysrwthaachende_ Content-Type: text/html; charset="utf-8" Content-ID: <108879337B498B4FB0860C6427A2A491@win.comsys.rwth-aachen.de> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClllcCwgaXQgc2VlbXMgdGhhdCB0aGVzZSBhcmUg bm90IHN0YXRpYyByZXBsaWVzIDopPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ij48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+T24gMTAuIEphbiAyMDE5LCBhdCAxNDo1NiwgRG1pdHJpIFRpa2hvbm92ICZsdDs8 YSBocmVmPSJtYWlsdG86ZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guY29tIiBjbGFzcz0iIj5kdGlr aG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0i QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5JIHBva2VkIGEgY291cGxlIG9mIHRob3NlIGFuZCBpbmRlZWQsIHRoZXNlIGFyZSB0aGUgdmVy c2lvbjxiciBjbGFzcz0iIj4NCm5lZ290aWF0aW9uIHBhY2tldHMgdGhhdCBjb21lIGJhY2suICZu YnNwO09uZSB0aGluZyBJIG5vdGljZWQgaXM8YnIgY2xhc3M9IiI+DQp0aGF0IHRoZSA/QT9BP0E/ QSB2ZXJzaW9uIGluY2x1ZGVkIGluIHRoZSBsaXN0IG9mIHN1cHBvcnRlZDxiciBjbGFzcz0iIj4N CnZlcnNpb24gY2hhbmdlcyBvbiBldmVyeSByZXNwb25zZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQombmJzcDstIERtaXRyaS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBU aHUsIEphbiAxMCwgMjAxOSBhdCAwMTozMzo1M1BNICYjNDM7MDAwMCwgSmFuIFLDvHRoIHdyb3Rl OjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkhpLDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCknigJltIGN1cnJlbnRseSBy dW5uaW5nIGEgc2NhbiBmb3IgUVVJQyBkcmFmdC0xNyBpbiBJUHY0IHRvIHNlZSBpZiB0aGVyZSBp cyBhbHJlYWR5IHNvbWUgLTE3IG91dCB0aGVyZSBhbmQgd2hhdCBlbHNlIHR5cGljYWxseSBjb21l cyBiYWNrLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkknbSBleGVyY2lzZSB0aGUgdmVy c2lvbiBuZWdvdGlhdGlvbiBmZWF0dXJlIGJ5IGFubm91bmNpbmcgYSByZXNlcnZlZCB2ZXJzaW9u IChpLmUuLCAweD9BP0E/QT9BKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgc2Nh biBoYXMgbm90IGZpbmlzaGVkIGJ1dCBJIGFscmVhZHkgZ290IHNvbWV0aGluZyBiYWNrIHRoYXQg bG9va3Mgb2RkLCBzZWU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KeyAmcXVvdDtpbmZv JnF1b3Q7OiAmcXVvdDtWZXJzaW9uIG5lZ290aWF0aW9uJnF1b3Q7LCAmcXVvdDtzYWRkciZxdW90 OzogJnF1b3Q7NTIuMTk0LjIxNi40MyZxdW90OywgJnF1b3Q7Y2xhc3NpZmljYXRpb24mcXVvdDs6 ICZxdW90O3F1aWMtZHJhZnQxNyZxdW90OywgJnF1b3Q7dmVyc2lvbnMmcXVvdDs6ICZxdW90OzAw MDAwMDY1LDFBMUEzQThBJnF1b3Q7LCAmcXVvdDtzdWNjZXNzJnF1b3Q7OiAxIH08YnIgY2xhc3M9 IiI+DQp7ICZxdW90O2luZm8mcXVvdDs6ICZxdW90O1ZlcnNpb24gbmVnb3RpYXRpb24mcXVvdDss ICZxdW90O3NhZGRyJnF1b3Q7OiAmcXVvdDs5Ny42NC4xOS41NCZxdW90OywgJnF1b3Q7Y2xhc3Np ZmljYXRpb24mcXVvdDs6ICZxdW90O3F1aWMtZHJhZnQxNyZxdW90OywgJnF1b3Q7dmVyc2lvbnMm cXVvdDs6ICZxdW90O0ZBNEE3QUVBLDAwMDAwMDY1JnF1b3Q7LCAmcXVvdDtzdWNjZXNzJnF1b3Q7 OiAxIH08YnIgY2xhc3M9IiI+DQp7ICZxdW90O2luZm8mcXVvdDs6ICZxdW90O1ZlcnNpb24gbmVn b3RpYXRpb24mcXVvdDssICZxdW90O3NhZGRyJnF1b3Q7OiAmcXVvdDs1Mi4xOTguMy4yMjImcXVv dDssICZxdW90O2NsYXNzaWZpY2F0aW9uJnF1b3Q7OiAmcXVvdDtxdWljLWRyYWZ0MTcmcXVvdDss ICZxdW90O3ZlcnNpb25zJnF1b3Q7OiAmcXVvdDswMDAwMDA2NSxEQTdBMEFGQSZxdW90OywgJnF1 b3Q7c3VjY2VzcyZxdW90OzogMSB9PGJyIGNsYXNzPSIiPg0KeyAmcXVvdDtpbmZvJnF1b3Q7OiAm cXVvdDtWZXJzaW9uIG5lZ290aWF0aW9uJnF1b3Q7LCAmcXVvdDtzYWRkciZxdW90OzogJnF1b3Q7 MzcuMTg3LjU1LjE0NCZxdW90OywgJnF1b3Q7Y2xhc3NpZmljYXRpb24mcXVvdDs6ICZxdW90O3F1 aWMtZHJhZnQxNyZxdW90OywgJnF1b3Q7dmVyc2lvbnMmcXVvdDs6ICZxdW90OzAwMDAwMDY1LDFB RkFCQTBBJnF1b3Q7LCAmcXVvdDtzdWNjZXNzJnF1b3Q7OiAxIH08YnIgY2xhc3M9IiI+DQp7ICZx dW90O2luZm8mcXVvdDs6ICZxdW90O1ZlcnNpb24gbmVnb3RpYXRpb24mcXVvdDssICZxdW90O3Nh ZGRyJnF1b3Q7OiAmcXVvdDsyMDMuMTg5Ljk3LjY2JnF1b3Q7LCAmcXVvdDtjbGFzc2lmaWNhdGlv biZxdW90OzogJnF1b3Q7cXVpYy1kcmFmdDE3JnF1b3Q7LCAmcXVvdDt2ZXJzaW9ucyZxdW90Ozog JnF1b3Q7MDAwMDAwNjUsMEFGQTlBN0EmcXVvdDssICZxdW90O3N1Y2Nlc3MmcXVvdDs6IDEgfTxi ciBjbGFzcz0iIj4NCnsgJnF1b3Q7aW5mbyZxdW90OzogJnF1b3Q7VmVyc2lvbiBuZWdvdGlhdGlv biZxdW90OywgJnF1b3Q7c2FkZHImcXVvdDs6ICZxdW90OzQ3Ljc0LjIzMS4xNjEmcXVvdDssICZx dW90O2NsYXNzaWZpY2F0aW9uJnF1b3Q7OiAmcXVvdDtxdWljLWRyYWZ0MTcmcXVvdDssICZxdW90 O3ZlcnNpb25zJnF1b3Q7OiAmcXVvdDs2QTFBMEE2QSwwMDAwMDA2NSZxdW90OywgJnF1b3Q7c3Vj Y2VzcyZxdW90OzogMSB9PGJyIGNsYXNzPSIiPg0KeyAmcXVvdDtpbmZvJnF1b3Q7OiAmcXVvdDtW ZXJzaW9uIG5lZ290aWF0aW9uJnF1b3Q7LCAmcXVvdDtzYWRkciZxdW90OzogJnF1b3Q7MTQ0LjM0 LjE2MC41MCZxdW90OywgJnF1b3Q7Y2xhc3NpZmljYXRpb24mcXVvdDs6ICZxdW90O3F1aWMtZHJh ZnQxNyZxdW90OywgJnF1b3Q7dmVyc2lvbnMmcXVvdDs6ICZxdW90OzAwMDAwMDY1LDJBRUFFQTJB JnF1b3Q7LCAmcXVvdDtzdWNjZXNzJnF1b3Q7OiAxIH08YnIgY2xhc3M9IiI+DQp7ICZxdW90O2lu Zm8mcXVvdDs6ICZxdW90O1ZlcnNpb24gbmVnb3RpYXRpb24mcXVvdDssICZxdW90O3NhZGRyJnF1 b3Q7OiAmcXVvdDsxNTMuMTIwLjE4MC4yMzAmcXVvdDssICZxdW90O2NsYXNzaWZpY2F0aW9uJnF1 b3Q7OiAmcXVvdDtxdWljLWRyYWZ0MTcmcXVvdDssICZxdW90O3ZlcnNpb25zJnF1b3Q7OiAmcXVv dDs4QTRBQ0FDQSwwMDAwMDA2NSZxdW90OywgJnF1b3Q7c3VjY2VzcyZxdW90OzogMSB9PGJyIGNs YXNzPSIiPg0KeyAmcXVvdDtpbmZvJnF1b3Q7OiAmcXVvdDtWZXJzaW9uIG5lZ290aWF0aW9uJnF1 b3Q7LCAmcXVvdDtzYWRkciZxdW90OzogJnF1b3Q7MTQ5LjI4LjkzLjEyMyZxdW90OywgJnF1b3Q7 Y2xhc3NpZmljYXRpb24mcXVvdDs6ICZxdW90O3F1aWMtZHJhZnQxNyZxdW90OywgJnF1b3Q7dmVy c2lvbnMmcXVvdDs6ICZxdW90OzAwMDAwMDY1LDlBOUExQUZBJnF1b3Q7LCAmcXVvdDtzdWNjZXNz JnF1b3Q7OiAxIH08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHdhcyB3b25kZXJpbmcg aWYgYW55b25lIGNvdWxkIHRlbGwgbWUgd2hhdCB2ZXJzaW9uIDB4MDAwMDAwNjUgKGRlY2ltYWw6 IDEwMSkgaXMuIEkgdGhvdWdodCAweDAwMDAwMDAxIHRvIDB4MDAwMGZmZmYgd2FzIHJlc2VydmVk IGZvciBzdGFuZGFyZGl6ZWQgdmVyc2lvbnMuPGJyIGNsYXNzPSIiPg0KQXBhcnQgZnJvbSB0aGlz LCB0aGV5IGFsbCBnZW5lcmF0ZSBhIGRyYWZ0LTE3IGNvbXBsaWFudCB2ZXJzaW9uIG5lZ290aWF0 aW9uIHBhY2tldC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpCZXN0IDxiciBjbGFzcz0iIj4NCkphbjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_8235B8CBF934483CBCD7C2FA978BAC14comsysrwthaachende_-- From nobody Thu Jan 10 17:19:01 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11F812DDA3 for ; Thu, 10 Jan 2019 17:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 AB9WKADMhNwJ for ; Thu, 10 Jan 2019 17:18:57 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 E4EDD123FFD for ; Thu, 10 Jan 2019 17:18:56 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id v15-v6so11438825ljh.13 for ; Thu, 10 Jan 2019 17:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iaEDs72iGrNEyiGtEsWec+s4vfK5W1es4P0UC/qCHI0=; b=JUIq7m+YUWD7fyPSA3k0KLP20vJcHaiW3vzg/eHScVHOUZpU1VkI4c6X5QvoSFpuIr Rc+l2mRa3ZcmiAN9I0/qfRWQBRt7ssfHmVHI+xF7thxnHvhvER2PYeSqX0W0L7KccpRq wP/bdrmvMAJ7rx1ZZBgQ9YEJzORID+bcf129UGoclqSeaBWXI02Tykj9jt03r3QY7Ix3 ZyM+o2mze6KJCTFjXuIUL5O3c7gHnr0oUbs3Dt4svmhxiYxayDk42s5QfXFiBThuHMFr YjVSF0tH5yw3hEI9yLvm3jamgzfZiyIfNXif14DHaWTjZLumSas3D4KiLC8Fvasa6WwD nHqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iaEDs72iGrNEyiGtEsWec+s4vfK5W1es4P0UC/qCHI0=; b=P1hQtb6qK5hyXcaJRoNxTNUo/FHIox3FMd/We0tdKJcDvSD52K2wjHg1DPMh74AlhI Rcvb+1d+bsTdSofmoIvOW5YweXmYhC1d5Bw1FAnT8LBCZ0DNYBkObADeR4GMkhhpopIZ VySnnVHvXxUsfq8mYfmNwZcm3s8e4J5KHlKukSRu2ki1/jekHR6ehwpsKzN1pjHVwUfV KLCIcQZwEVHwTXk/jSuVMUqdJbf60bVDMCsr//EwOp5hvehiZ+w/9vv33bQHaBVGCQ/y K2QN3Qi+U+wf+23Zimo6CiFYqaRAZUt5X+q0fW+2DW8bNSAYjeNfGuE0HcKpopBkq+su EVSA== X-Gm-Message-State: AJcUukfxDEh0LMe/lev2apTgjE6iBzGVDGct06eIVzX38x5dx43CYSwY he7P52Wn9wb5krNxboLmOjgxHQRJiKCUgX7CgfKEom6EN6M= X-Google-Smtp-Source: ALg8bN6F/+h0zd76AJicWFhC457vzXM5BOs6qRGnC02bbiPr+Nc+JSYJdFEU8vNSr6XpwOjZ3R029hc9p9ce4/SA198= X-Received: by 2002:a2e:20f:: with SMTP id 15-v6mr7470215ljc.172.1547169534785; Thu, 10 Jan 2019 17:18:54 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> In-Reply-To: <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> From: Victor Vasiliev Date: Thu, 10 Jan 2019 20:18:42 -0500 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: Christian Huitema , Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000087d51f057f247a66" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 01:19:00 -0000 --00000000000087d51f057f247a66 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 9, 2019 at 5:13 PM Martin Thomson wrote: > On Thu, Jan 10, 2019, at 02:12, Christian Huitema wrote: > > We could use plenty of bits like that: ECN echo comes to mind. We don't. > > We use frames. From that point of view, using ACK as a check is more in > > line with the QUIC design. "Don't roll the key if you have not received > > at least one ACK for the current phase" seems much simpler. Also, it > > uses an honest signal, by opposition to a random bit, and that doesn't > > create an other class of misbehavior. > > If you look at the history of the PR, I initially proposed using ACK in > exactly this way. The feedback I got was that this was difficult for > people to implement, because it more tightly couples two parts of the > processing pipeline than was previously necessary. That is, if you > consider packet protection as a discrete stage in processing, getting > information to and from the ACK frame processing might be difficult, > depending on implementation structure. > > We've been very careful to avoid having protocol behaviour that triggers > on acknowledgment. I don't think that we have any that escape the loss > recovery and CC algorithms. As an architectural principle, I think that is > worth preserving. > I'm not sure I believe this is a useful principle (if you track acknowledgements for stream data, tracking anything else is easier). That said, you can always make a custom ack frame. How about something like this: 1. Peer A sends I_WOULD_LIKE_TO_ADVANCE_THE_KEY_PHASE frame with the number of next phase. 2. Peer B replies with YES_PLEASE_DO_ADVANCE_THE_KEY_PHASE frame as soon as it receives Peer A's request. 3. Peer A can advance the key phase as soon as it gets permission from Peer A. Note that since here you ask for permission and list the phase explicitly, there is less potential for things changing to fast or peers being confused. > > > If that doesn't convince you, then please add a specification on how to > > react to reneging the enable bit, and also how to react to peers > > ignoring it. > > That I have done. Of course, as Ian points out, if the bit is never set, > there isn't really any recourse, and that might be valuable enough to be > considered a feature. > > --00000000000087d51f057f247a66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 9, 2019 at 5:13 PM Martin Tho= mson <mt@lowentropy.net> wro= te:
On Thu, Jan 10, 2019, at 02:12, Christian Huitema wrote:
> We could use plenty of bits like that: ECN echo comes to mind. We don&= #39;t.
> We use frames. From that point of view, using ACK as a check is more i= n
> line with the QUIC design. "Don't roll the key if you have no= t received
> at least one ACK for the current phase" seems much simpler. Also,= it
> uses an honest signal, by opposition to a random bit, and that doesn&#= 39;t
> create an other class of misbehavior.

If you look at the history of the PR, I initially proposed using ACK in exa= ctly this way.=C2=A0 The feedback I got was that this was difficult for peo= ple to implement, because it more tightly couples two parts of the processi= ng pipeline than was previously necessary.=C2=A0 That is, if you consider p= acket protection as a discrete stage in processing, getting information to = and from the ACK frame processing might be difficult, depending on implemen= tation structure.

We've been very careful to avoid having protocol behaviour that trigger= s on acknowledgment.=C2=A0 I don't think that we have any that escape t= he loss recovery and CC algorithms.=C2=A0 As an architectural principle, I = think that is worth preserving.

I'm= not sure I believe this is a useful principle (if you track acknowledgemen= ts for stream data, tracking anything else is easier).=C2=A0 That said, you= can always make a custom ack frame.

How about som= ething like this:
  1. Peer A sends I_WOULD_LIKE_TO_ADVANCE_TH= E_KEY_PHASE frame with the number of next phase.
  2. Peer B replies wit= h YES_PLEASE_DO_ADVANCE_THE_KEY_PHASE frame as soon as it receives Peer A&#= 39;s request.
  3. Peer A can advance the key phase as soon as it gets p= ermission from Peer A.
Note that since here you ask for permi= ssion and list the phase explicitly, there is less potential for things cha= nging to fast or peers being confused.

> If that doesn't convince you, then please add a specification on h= ow to
> react to reneging the enable bit, and also how to react to peers
> ignoring it.

That I have done.=C2=A0 Of course, as Ian points out, if the bit is never s= et, there isn't really any recourse, and that might be valuable enough = to be considered a feature.

--00000000000087d51f057f247a66-- From nobody Fri Jan 11 10:26:59 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E2A127AC2 for ; Fri, 11 Jan 2019 10:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 HsHoDkFCcifa for ; Fri, 11 Jan 2019 10:26:55 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179111286D9 for ; Fri, 11 Jan 2019 10:26:55 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx62.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gi1W8-0003SS-5d for quic@ietf.org; Fri, 11 Jan 2019 19:26:53 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gi1W3-0000YF-FV for quic@ietf.org; Fri, 11 Jan 2019 13:26:48 -0500 Received: (qmail 19218 invoked from network); 11 Jan 2019 18:26:44 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Jan 2019 18:26:44 -0000 To: Kazuho Oku Cc: Ryan Hamilton , IETF QUIC WG , Martin Thomson , Ian Swett References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Fri, 11 Jan 2019 10:26:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Key updates X-Originating-IP: 168.144.250.232 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.16) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5k5ADpkEpqc4F43rUS7bHeB602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi4VPxLB4nysUG5Bzennj44c7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBCnY1T4UEFfy74vbELeG6IB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaIKaP92kYvCAgLvXDsJxwwjF3caxSXu1fnKF+gYehEmkFn8OZ+PmZLd rP8bCe7alXeAImxrekFydH4DojSCKJXVXfdz0+Q1eHsqtFQKXUaZ+h596SWGosiQ15/fAFUBngWU swziTuoonQBgr0dS5AZLiwQzKw+6v3CaIMG6s7LqJFA2+ajytfCzORPDOH6X2/5SyaRgIwuFZktu hI3SFVknBkKPq85GTAoevRdQp2ru+VVlz1LLZaeBtGOQ+cW//ETtOuTWXXIj0TpQpfUxR/zGwBdV FCAdssvNXtvdLBNmqz5Gegm2Di+XkC+U0gjMGGKSn11dj1tX732somwMviE4rNLMkKiSx4DbX99P +gh4iWPT5m4OdqWMdE0b4Joz08+J+cv73CChOPjKA0/DVd830vHLIFSGGMV7x6CHvZpJG/9P/4OG qJ5dkO1xTEy0joEwyGTHIAoNFX+jcW7DGmdEezpuI9IICsCKA/p66v7fhw== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 18:26:57 -0000 On 1/9/2019 5:36 PM, Kazuho Oku wrote: > ... > The problem of using ACK as a signal is that it could provide a false > illusion that a sender is permitted to update the traffic key whenever > it sees an ACK for a new generation. If the sender falsely assumes > that, it would emit packets that cannot be decrypted by the receiver > that tries to retain minimum number of keys (i.e. 2). > > My preference goes to having a design that guarantees the > communication to succeed without requiring the receiver to retain a > greater number of keys than necessary. I think we all agree that after draft 17, any change to packet format should clear a very high bar. The PR proposes to add a bit in the header bit, and is just one such change. I understand it is just one bit, but then I have some experience when asked to change just one bit in code that is almost ready to ship. And I would rather not do it, because I do not believe the change is necessary. I read the thread, and I can count three issues. I am not convinced that either of those clears the bar. The first issue is that if peers rotate the key too often, and especially if they rotate the key often and simultaneously, they could end up breaking the connection. Well, don't do that. The second issue is that if a peer rotates keys too quickly, it forces the other peer to maintain multiple encryption contexts. Key rotation requires maintaining at least two contexts: old and current, or current and new. The old context can be disposed of as soon as packets are not expected from the peer, which is currently defined as 3 RTO. If a rotation occurs with these 3 RTO, the node may need to keep 3 contexts: old, current and new. Again, the solution is simple: don't do that. We could add text to that effect, such as "at least 6 RTO between key rotations". Or we could simply state that if a peer engages in rotation N+1, it is effectively discarding all packets still in transit from rotation N-1, effectively limiting the number of keys to be maintained to= 2. The third issue is not really a protocol issue, but rather a new functionality. Can nodes limit how often their peers engage in key rotation? Or, pushed to the max, can an implementation just not support key rotation at all. My take is that this kind of feature negotiation is better handled with transport parameters than by adding bits in the header. I am also very concerned that if an application supports key rotation there should be an easy way to test it. -- Christian Huitema From nobody Fri Jan 11 20:55:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00ED130F1C for ; Fri, 11 Jan 2019 20:55:43 -0800 (PST) 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=unavailable 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 KwQJ1EdWivOf for ; Fri, 11 Jan 2019 20:55:41 -0800 (PST) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 C60B1130F6F for ; Fri, 11 Jan 2019 20:55:40 -0800 (PST) Received: by mail-lj1-x241.google.com with SMTP id l15-v6so14681772lja.9 for ; Fri, 11 Jan 2019 20:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SL8ImSFaB+NBFsr+WMLrybOx71oIeF98oiNxFMa4clY=; b=pBH/yj+NdO3Ovu9tt5S6s7ulXCRT6wOstI3jhHAJV9x9vFq0IUcpyiyDrRAS4SiV4S OYIyovbXH673sD9fJxJeiSUFasL0TRwcJ0Uc8A5NM0PCiaQAaOFNFeXJ8XKpdZTjtQji 8PVxA3YBEJev0USjr3o/8pKTHA6Mwt/dbsdhyOEX3LyLDQWdy+53uXsbRPKwkF3L4pxX 4Ar+IEiW7QRy38WkhkhczeLbpt/MH2Apj0ddZQJUAEc9YDgLaPObaeMP1BPlAoJ0roN9 aXOiQo9rBD8kgrplK3ActuD5ugPD+MiEeHbsy027t/i6M/vU56fLz8oLocjQVlYuptAB Yiag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SL8ImSFaB+NBFsr+WMLrybOx71oIeF98oiNxFMa4clY=; b=kAQLqP7PQfCWixkctcb+/3OSYTSBdXoGwUA+gal52Pjy+HlqY37mB4ac0dbDONyYUj ti/LmA/Q4F9uyOJG7HEqokYWhKnRH/x/UvRMY7oEhvQG0TEgLFuZrz5Oy4N6tI0X8s6h qDroD8Em6H4ZnhelntNSGjULGMdMbCv4+b+mQ4hz90lWxnSinZLM0/R3XSvqZmIr7UFX qXPDee95cG0GNPIg+Ag9883f4iBBvhHh6FfcimDtJQ6He7uBMrru1BN9z4hd/g/dfOjr yfKS7kBr0HXiz5w+oyrDfnJUeGFFO+wfG5/UlRuGworsEOTNFl3JsZVK19BoZMxjA4VQ sumQ== X-Gm-Message-State: AJcUukcPBh9pqs0hhDeMVWY6ws2PtqoF0n4Ba32rFhLJZ4Wutoxg699i UTg01o0lo57JtiYYvgxFFodicXQO+FR2r2p31VRe/Q== X-Google-Smtp-Source: ALg8bN5G5bZ20uCPEY3R8werd3mAXP6PzV8ow38RDWayj/B42Ohd3Innqpxe0l3cqxRJx6mygYmfJCY8T7OFgO25rgg= X-Received: by 2002:a2e:81a:: with SMTP id 26-v6mr10897942lji.14.1547268938920; Fri, 11 Jan 2019 20:55:38 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> In-Reply-To: From: Kazuho Oku Date: Sat, 12 Jan 2019 13:55:27 +0900 Message-ID: Subject: Re: Key updates To: Christian Huitema Cc: Ryan Hamilton , IETF QUIC WG , Martin Thomson , Ian Swett Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 04:55:44 -0000 2019=E5=B9=B41=E6=9C=8812=E6=97=A5(=E5=9C=9F) 3:26 Christian Huitema : > > > On 1/9/2019 5:36 PM, Kazuho Oku wrote: > > ... > > The problem of using ACK as a signal is that it could provide a false > > illusion that a sender is permitted to update the traffic key whenever > > it sees an ACK for a new generation. If the sender falsely assumes > > that, it would emit packets that cannot be decrypted by the receiver > > that tries to retain minimum number of keys (i.e. 2). > > > > My preference goes to having a design that guarantees the > > communication to succeed without requiring the receiver to retain a > > greater number of keys than necessary. > > I think we all agree that after draft 17, any change to packet format > should clear a very high bar. My understanding is that it is not only the packet format. Any change to the protocol needs to clear the high bar. The flip side is that we are free to choose the most appropriate way _if_ we agree that there is a reason to change. In this particular case, the new information we have is that the key update mechanism that we currently have has an issue that the keys might become out-of-sync. I think we should fix the issue, and assuming that the WG agrees to fix the issue, my preferred way of fixing the issue is to introduce the Key Update Permitted bit, because it is simple and hard to mis-implement on both the sender and the receiver side, as well as having the other benefits that we have discussed. Using the key phase bit "and ACK" to see if the sender can issue another update is complicated. > The PR proposes to add a bit in the header > bit, and is just one such change. I understand it is just one bit, but > then I have some experience when asked to change just one bit in code > that is almost ready to ship. And I would rather not do it, because I do > not believe the change is necessary. I read the thread, and I can count > three issues. I am not convinced that either of those clears the bar. > > The first issue is that if peers rotate the key too often, and > especially if they rotate the key often and simultaneously, they could > end up breaking the connection. Well, don't do that. > > The second issue is that if a peer rotates keys too quickly, it forces > the other peer to maintain multiple encryption contexts. Key rotation > requires maintaining at least two contexts: old and current, or current > and new. The old context can be disposed of as soon as packets are not > expected from the peer, which is currently defined as 3 RTO. If a > rotation occurs with these 3 RTO, the node may need to keep 3 contexts: > old, current and new. Again, the solution is simple: don't do that. We > could add text to that effect, such as "at least 6 RTO between key > rotations". Or we could simply state that if a peer engages in rotation > N+1, it is effectively discarding all packets still in transit from > rotation N-1, effectively limiting the number of keys to be maintained to= 2. > > The third issue is not really a protocol issue, but rather a new > functionality. Can nodes limit how often their peers engage in key > rotation? Or, pushed to the max, can an implementation just not support > key rotation at all. My take is that this kind of feature negotiation is > better handled with transport parameters than by adding bits in the > header. I am also very concerned that if an application supports key > rotation there should be an easy way to test it. > > -- Christian Huitema > > --=20 Kazuho Oku From nobody Sat Jan 12 16:45:29 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07BF130E62 for ; Sat, 12 Jan 2019 16:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=K/4EkU+E; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uh4HgA02 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 cRg0fHpdkL-c for ; Sat, 12 Jan 2019 16:45:24 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93537130DE3 for ; Sat, 12 Jan 2019 16:45:24 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 89FDF2182 for ; Sat, 12 Jan 2019 19:45:23 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 12 Jan 2019 19:45:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=WjofpXyf/cqUbnSboaT5IXtny6w8mlSGeqQzEeZrFEg=; b=K/4EkU+E fbvlBExxOHz00yaDrLN4fKXX4T3SifnVDeSvHuk9Bz4KzFGneO54tQfaniqP4YTM eRFWxYvyvYVi4Y4GAW+qq5q5GGJhLz4SFviILQfKnE/qVCiHJGdmj7ip43S4U7Vw C+g34heY+pNODNYH7pG2a5qz7jIrETIBd6b69XDD405aj2bNWhrtnAoWSC/+WKAh DsDR6oeU2LPWgRakdcbJghMaKdAjQ72emf1U8XWr4OU07ozoI6PXz3MWmL4zfQZ1 JUCziO6lh9cpQ0sktV1fyYhKqTL0DzRYJxd6KHupJPPOhvRdTsi1nKQIw7sh8zdP f5Alzn+qzaWxpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=WjofpXyf/cqUbnSboaT5IXtny6w8m lSGeqQzEeZrFEg=; b=uh4HgA02yvFchWHDpIHA54zpEabXwZanTHuR9VDhEa40A gVlkNiBuUTTsuYoeeT6jWK0DiDe/ih1RNUWk9XzLsUJqMEEFP9wmCav5y6GFeTlw /J7ePE4j2u2iAG9Dt7vjg1/ZLDSEjva/uN7lCNlYZUNMnzds8EuVux823iL5L80x THKEcqV6UgNjxjcY53bypGnzGrXvf8xdO8IBYTjxRypDLIT21sX2PCbQ9fKtqAXx EIaQZFkprzJphDV8grusxWfA6GgorMovOdgUythTIeAF8w9zp3ipvkH/db2ZDUEL QhxBYRWC7nHAJ7H1NOJJhT/nGNDlNdgvwA9Xj85mQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeejgdduleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomhepifhithhhuh gspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghrvghplhihsehmnhhothdr nhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepudduledrledrge efrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhies mhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id A7BECE4043 for ; Sat, 12 Jan 2019 19:45:20 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id CD547C03B9 for ; Sun, 13 Jan 2019 00:45:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============1906857456580895429==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190113004517.CD547C03B9@cloud.mnot.net> Date: Sun, 13 Jan 2019 00:45:17 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 00:45:28 -0000 --===============1906857456580895429== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+5/-4/=F0=9F=92=AC53) 5 issues created: - What should the receiver do when the peer closes a unidirectional strea= m before providing the stream type? (by kazuho) https://github.com/quicwg/base-drafts/issues/2331 = - Actions to take when Reserved Bits are not Zero (by martinduke) https://github.com/quicwg/base-drafts/issues/2329 = - client's Handshake write key needs to be exported early (by marten-seem= ann) https://github.com/quicwg/base-drafts/issues/2328 = - "PRIORITY frame expresses priority of a stream" (by LPardue) https://github.com/quicwg/base-drafts/issues/2321 = - introduce an error code for loss recovery-related errors (by marten-see= mann) https://github.com/quicwg/base-drafts/issues/2319 = 16 issues received 53 new comments: - #2319 introduce an error code for loss recovery-related errors (12 by k= azuho, marten-seemann, mikkelfj, ianswett) https://github.com/quicwg/base-drafts/issues/2319 [-recovery] [-transpo= rt] [design] = - #2331 What should the receiver do when the peer closes a unidirectional= stream before providing the stream type? (12 by siyengar, kazuho, LPardue,= mikkelfj) https://github.com/quicwg/base-drafts/issues/2331 = - #2321 "PRIORITY frame expresses priority of a stream" (11 by kazuho, dt= ikhonov, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2321 = - #2329 Actions to take when Reserved Bits are not Zero (2 by kazuho, mar= tinthomson) https://github.com/quicwg/base-drafts/issues/2329 [-tls] [-transport] [= design] = - #311 GREASE the packet type octet (2 by martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/311 [-transport] [design] = [parked] = - #1724 Recovery "what to send section"? / Pseudo code issue (2 by mart= inthomson, ianswett) https://github.com/quicwg/base-drafts/issues/1724 [-recovery] = - #2276 Disallow changes of table size after 0-RTT (2 by martinthomson, a= frind) https://github.com/quicwg/base-drafts/issues/2276 [-http] [-qpack] [des= ign] = - #2299 consider making the varint encoding unique (2 by siyengar, ianswe= tt) https://github.com/quicwg/base-drafts/issues/2299 [-transport] [design] = - #2308 handling of coalesced packets with decryption errors creates DoS = opportunity (1 by igorlord) https://github.com/quicwg/base-drafts/issues/2308 [-transport] [design] = - #1678 Does the first byte of stateless reset include random bits? (1 by= martinthomson) https://github.com/quicwg/base-drafts/issues/1678 [-transport] [design]= [parked] = - #2103 Guidelines for Retransmitting Lost Data (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2103 [-recovery] = - #1989 frame type field of CONNECTION_CLOSE provides little value (1 by = ianswett) https://github.com/quicwg/base-drafts/issues/1989 [-transport] [design] = - #2253 Consider making h3 frame types varint (1 by kazuho) https://github.com/quicwg/base-drafts/issues/2253 [-http] [design] = - #2258 Initial maximum table size needs clarification. (1 by bencebeky) https://github.com/quicwg/base-drafts/issues/2258 [-http] [design] = - #2259 amplification attack using Retry and VN triggered by coalesced In= itial packets (1 by mikkelfj) https://github.com/quicwg/base-drafts/issues/2259 [-transport] [design] = - #377 ICMP and ICMPv6 (Type: DestinationUnreachable) (1 by igorlord) https://github.com/quicwg/base-drafts/issues/377 [-transport] [design] = 4 issues closed: - GREASE the packet type octet https://github.com/quicwg/base-drafts/issu= es/311 [-transport] [design] [parked] = - Does the first byte of stateless reset include random bits? https://git= hub.com/quicwg/base-drafts/issues/1678 [-transport] [design] [parked] = - Recovery "what to send section"? / Pseudo code issue https://github.c= om/quicwg/base-drafts/issues/1724 [-recovery] = - transport: dangling references to recovery https://github.com/quicwg/ba= se-drafts/issues/2318 = Pull requests ------------- * quicwg/base-drafts (+5/-3/=F0=9F=92=AC17) 5 pull requests submitted: - extended unidirectional streams can be closed or reset (by kazuho) https://github.com/quicwg/base-drafts/pull/2332 = - QPACK: Clarify how maximum dynamic table capacity can be set (by afrind) https://github.com/quicwg/base-drafts/pull/2330 = - Update draft-ietf-quic-recovery.md (by ianswett) https://github.com/quicwg/base-drafts/pull/2327 = - Prioritization edits (by LPardue) https://github.com/quicwg/base-drafts/pull/2322 = - update short header illustration to sync with #2203 (by britram) https://github.com/quicwg/base-drafts/pull/2320 = 7 pull requests received 17 new comments: - #2280 Clarify Actions on nonzero Reserved Bits (10 by DavidSchinazi, ka= zuho, marten-seemann, martinduke, ianswett) https://github.com/quicwg/base-drafts/pull/2280 [-tls] [-transport] [de= sign] = - #2325 Introduce HTTP_REQUEST_REJECTED (2 by DavidSchinazi, MikeBishop) https://github.com/quicwg/base-drafts/pull/2325 [-http] [design] [yaec!= ] = - #2251 Explicitly talk about Largest Reference zero. (1 by afrind) https://github.com/quicwg/base-drafts/pull/2251 [-qpack] = - #2256 Initial maximum table size is zero. (1 by afrind) https://github.com/quicwg/base-drafts/pull/2256 [-qpack] [design] = - #2281 Include handshake anti-deadlock logic in pseudocode (1 by Ralith) https://github.com/quicwg/base-drafts/pull/2281 [-recovery] = - #2028 Ignore loss of undecryptable packets (1 by ianswett) https://github.com/quicwg/base-drafts/pull/2028 [-recovery] [design] = - #2025 Send a few immediate ACKs (1 by ianswett) https://github.com/quicwg/base-drafts/pull/2025 [-recovery] = 3 pull requests merged: - Prioritization edits https://github.com/quicwg/base-drafts/pull/2322 = - update spin-exp short header to sync with #2203 https://github.com/quicwg/base-drafts/pull/2320 [-spin-exp] = - Allow discarding bad, unauthenticated packets https://github.com/quicwg/base-drafts/pull/2141 [-transport] [design] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============1906857456580895429== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday January 13, 2019

Events without label "editorial"

Issues

quicwg/base-drafts (+5/-4/=F0=9F=92=AC53)

5 issues created:

16 issues received 53 new comments:

4 issues closed:

Pull requests

quicwg/base-drafts (+5/-3/=F0=9F=92=AC17)

5 pull requests submitted:

7 pull requests received 17 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============1906857456580895429==-- From nobody Wed Jan 16 13:28:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9B1131196 for ; Wed, 16 Jan 2019 13:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, 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=EhiP9szq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j16SiYNX 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 nh71ysPjW3c5 for ; Wed, 16 Jan 2019 13:28:38 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052D513119F for ; Wed, 16 Jan 2019 13:28:36 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A905C2811A; Wed, 16 Jan 2019 16:28:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 16 Jan 2019 16:28:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm1; bh=nHmBRp6YbBS2cPdm+c1CLwvO6jApMm BVauGlhmK1d9I=; b=EhiP9szq0EulzyZRkqfYkCci3z/tfmMBKHUTEq2Zs9KO+L XSMQZoHc2pzH9k7WoGjbNLgzesdCY8+H3TPZTu2wNb0oJ51y2Ch/hZtGg97tNgo+ IoU8RkKLqPgBfAHiOGijDkL7tsAW/yWQOUIw2ISA+3MpWUuI7O+npjjhH/mIX6vY Mohpd305bY5KGB+payYPS7RnWDFKGeqnqyXruLNLZ9iXzhiiJ23LrN7f7SIeoL9C fO1g9L460TcMCs/3/JShatp7gMzop9o+Z4vlAxbyuR0XJX5a2yLSXs3svBvNMX5h knV9BE4lmQj0TruSGENDvOQJI5w2ZLg9dfrToLYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nHmBRp 6YbBS2cPdm+c1CLwvO6jApMmBVauGlhmK1d9I=; b=j16SiYNXcvbVIuWcovXxdv To8Tp+KfqNdLBkW8kE8ZmoXcFBzUuf4LCHkeUt/KLpQyOa36L1O6nr3gBc4qrQbw dHQS8w3gIbCOiM025wDXoy/s1gK86I4oKw/ZNMCUyTxnE32dMQ0veNVFsxmyuyxh Z6zlTG70sa75Plgagh5YHWqShaNJcCTE1k0TAdlEW4x9cdk3kU8aM+4syvlXVIGf GQIdGe319a2nGxvfOeA+4FoOhskzXruybOC3liY829pHJZft+PzLq4my+zDUu8hx 62/3SyaND0qlThN4beC3OHmWcCXF+GixON300vTq2DQIdccwJtzzpQkuMSo+6Miw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeehgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhtgfgggfukf ffvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceo mhhnohhtsehmnhhothdrnhgvtheqnecukfhppeefkedrleejrddvvdekrddvfeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghr ufhiiigvpedt X-ME-Proxy: Received: from [172.20.2.196] (unknown [38.97.228.23]) by mail.messagingengine.com (Postfix) with ESMTPA id 48F4D10085; Wed, 16 Jan 2019 16:28:33 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Raising the Bar / Our Work Mode Message-Id: Date: Wed, 16 Jan 2019 14:28:14 -0700 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 21:28:42 -0000 Everyone, We've previously talked about "raising the bar" for changes to the = protocol; i.e., reflecting the group's desire for shipping a viable = product in a reasonable timeframe by agreeing not to accept changes that = don't have broad support as technically necessary, and not spending = significant resources on issues that are not likely to meet that = requirement. To be clear, this is a Working Group decision, not something imposed by = the IETF or the chairs. Effectively, it's forming consensus that = shipping a viable protocol in a reasonable amount of time is itself a = feature -- one that's more important than satisfying every itch that = people have when minting a new protocol. The chairs and the editors believe that we are now approaching that = point for the Transport, Recovery and TLS drafts. In Tokyo, one of our = agenda items will be a discussion and calls for consensus on: * The -17 drafts of transport, recovery and TLS, delta the current = issues list, reflecting working group consensus so far * Raising the bar for changes to these drafts shortly after the meeting. That brings up a discussion of work mode. Since we started QUIC, we've = allowed the editors a significant amount of leeway in assessing our = discussions, formulating their proposals and incorporating them into the = published drafts; the presumption has been that it represents informal = (i.e., non-called) consensus unless there's an objection (on-list or in = the issues list). This has helped us to move at a reasonable pace; while = we've already adjusted our timeline, we wouldn't be as far along if we = hadn't taken that approach. However, once we do "raise the bar", this presumption is no longer = workable; it isn't fair to the editors. Therefore, afterwards we'll need = change our work mode.=20 What we'd like to see is having changes canvassed in GitHub issues *and* = the mailing list to assure consensus (as judged by the chairs), only = being incorporated into the drafts afterwards. That will mean that each = draft after we adopt this change will effectively reflect working group = consensus at that time.=20 It also means that the chairs will become more active in managing the = state of the issues; e.g., flagging those that have explicit consensus, = and closing those which don't achieve it (including a review of the = 'parked' issues). It doesn't mean raising new issues is not possible -- we can always = change based upon new information. However, the presumption will be that = changes to the design need broad support within the working group to go = forward. We'll have more details and discussions at the meeting, but we wanted to = get initial feedback and questions on the list; please have a think and = reply with any concerns you have. Cheers, - Mark and Lars From nobody Wed Jan 16 19:42:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA28D130F4D for ; Wed, 16 Jan 2019 19:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 W-nArz91WAzs for ; Wed, 16 Jan 2019 19:42:40 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 F2701130F3A for ; Wed, 16 Jan 2019 19:42:39 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id g11-v6so7332809ljk.3 for ; Wed, 16 Jan 2019 19:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QXl90swir/Ccb0ArypyvIYAh5mJhxr9IgYl4dSsD5ys=; b=bCCWOAPFsRCoG+M6KyDNuwJpK8KOnbmMCDqZnWMeiXgQIiLWojzN2j/g19Qh8fANXD Iii/XWbmwF325k2yUwJJlh/3t24gCruX4kydLma5wQP2r2cUNqnxGgJDOq/UOCnaLQOX DWwE9cG3ti95RCeq5GaU/UXxWvhUYGShTZ7MY4lNfob5PSRiVFwV6rE0HUdIu3zEn7jh 5ZNkK2h3s8zUrqaKgeybxOkv1aSdoR69mmxe24JiRqqI1b2hMjX/SmSTtPMv3piXr9H5 mXbiVdcIqdN0cSfUhGKMWurPkYcJd2+16LBZ4+jPwZHYACFT2pq0s4mgmnZOulJqqQio Kgww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QXl90swir/Ccb0ArypyvIYAh5mJhxr9IgYl4dSsD5ys=; b=iP0ee9LJikQZS+Y+HhXYJzv+6Y0GxrRxtYlusJa4GtYKU7aKKo0cuTUWk7ShU0hcIc nxPeq+e/yFz7hxIG7u/9+5vwFW9ji5gXL0Y16x3NkNRubfQKMzEi4dEX/5ipio+fJI4o bZhf6kMYKR/nKpFX2GJVNjZtqJU2ApNB0LAOmz8wCZpsjeWe9wbFcr2sb/uYbSk+JrlI SR7vi2jZjxSDR1deGQsTnSTtW/FP25JDJPu+zekErqXTGOB+hVYegEsqxGs1SMKCdUBt vdGcLujNY/tz6nuJl8axBpqO89CG041D+b6QW7du0kyEz2DeF8IrCW/2OygK4KICjCvv fdsA== X-Gm-Message-State: AJcUukdXMBWM9nUJE77OZ8KHVmYNy6vK4iseDcGWr7QIr8oBeep5AyU9 IAegwXxBPqS1xWNbhdU13KmjPYcEfJngut/TM3r4Hg== X-Google-Smtp-Source: ALg8bN4Ur6/HtLSYPRaODXwx/uLLXOQfie32fnf3FHTt5puqerTDWNWI1W3861Z6cam7zcLJbmBe4rUnlt697L1Pnk0= X-Received: by 2002:a2e:7f04:: with SMTP id a4-v6mr9172938ljd.156.1547696558078; Wed, 16 Jan 2019 19:42:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Thu, 17 Jan 2019 12:42:25 +0900 Message-ID: Subject: Re: Raising the Bar / Our Work Mode To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 03:42:42 -0000 2019=E5=B9=B41=E6=9C=8817=E6=97=A5(=E6=9C=A8) 6:28 Mark Nottingham : > > Everyone, > > We've previously talked about "raising the bar" for changes to the protoc= ol; i.e., reflecting the group's desire for shipping a viable product in a = reasonable timeframe by agreeing not to accept changes that don't have broa= d support as technically necessary, and not spending significant resources = on issues that are not likely to meet that requirement. > > To be clear, this is a Working Group decision, not something imposed by t= he IETF or the chairs. Effectively, it's forming consensus that shipping a = viable protocol in a reasonable amount of time is itself a feature -- one t= hat's more important than satisfying every itch that people have when minti= ng a new protocol. > > The chairs and the editors believe that we are now approaching that point= for the Transport, Recovery and TLS drafts. In Tokyo, one of our agenda it= ems will be a discussion and calls for consensus on: > > * The -17 drafts of transport, recovery and TLS, delta the current issues= list, reflecting working group consensus so far > * Raising the bar for changes to these drafts shortly after the meeting. > > That brings up a discussion of work mode. Since we started QUIC, we've al= lowed the editors a significant amount of leeway in assessing our discussio= ns, formulating their proposals and incorporating them into the published d= rafts; the presumption has been that it represents informal (i.e., non-call= ed) consensus unless there's an objection (on-list or in the issues list). = This has helped us to move at a reasonable pace; while we've already adjust= ed our timeline, we wouldn't be as far along if we hadn't taken that approa= ch. > > However, once we do "raise the bar", this presumption is no longer workab= le; it isn't fair to the editors. Therefore, afterwards we'll need change o= ur work mode. > > What we'd like to see is having changes canvassed in GitHub issues *and* = the mailing list to assure consensus (as judged by the chairs), only being = incorporated into the drafts afterwards. That will mean that each draft aft= er we adopt this change will effectively reflect working group consensus at= that time. > > It also means that the chairs will become more active in managing the sta= te of the issues; e.g., flagging those that have explicit consensus, and cl= osing those which don't achieve it (including a review of the 'parked' issu= es). > > It doesn't mean raising new issues is not possible -- we can always chang= e based upon new information. However, the presumption will be that changes= to the design need broad support within the working group to go forward. > > We'll have more details and discussions at the meeting, but we wanted to = get initial feedback and questions on the list; please have a think and rep= ly with any concerns you have. Chairs, editors, Thank you for all your work. It's great to know that we have finally reached the point where we are "raising the bar." I am looking forward to seeing that becoming real in Tokyo. OTOH, I would like to ask how editorial issues or clarifications should be handled when we "raise the bar." When opening a GitHub issue or PR that tries to address an editorial issue, are we expected to also notify the mailing list? Or if we feel uncertain in what the draft is saying, what is the expected action for us to take: 1) open a GitHub issue, 2) open a GitHub issue and send that to the mailing list, 3) send the question to the mailing list? Thank you in advance. > Cheers, > > - Mark and Lars > > --=20 Kazuho Oku From nobody Thu Jan 17 03:02:54 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C88D130DEC for ; Thu, 17 Jan 2019 03:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 CUmwSfDEMEUt for ; Thu, 17 Jan 2019 03:02:49 -0800 (PST) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A23F130E0A for ; Thu, 17 Jan 2019 03:02:49 -0800 (PST) Received: from eggert.org (unknown [62.248.255.8]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id C2DA830067; Thu, 17 Jan 2019 13:02:44 +0200 (EET) Received: from slate.eggert.org (pf.eggert.org [172.16.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 82A6B61BC2A; Thu, 17 Jan 2019 13:02:39 +0200 (EET) From: Lars Eggert Message-Id: <417BEB18-E41B-4BE6-BDFA-17A9A0C07E1C@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_29DC01A6-746A-4F03-8E9C-2F5DA9F8D157"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Raising the Bar / Our Work Mode Date: Thu, 17 Jan 2019 13:02:38 +0200 In-Reply-To: Cc: Mark Nottingham , IETF QUIC WG To: Kazuho Oku References: X-MailScanner-ID: 82A6B61BC2A.A5A26 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 11:02:52 -0000 --Apple-Mail=_29DC01A6-746A-4F03-8E9C-2F5DA9F8D157 Content-Type: multipart/alternative; boundary="Apple-Mail=_2C02F062-4053-4347-82A6-FCCA257E08AA" --Apple-Mail=_2C02F062-4053-4347-82A6-FCCA257E08AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2019-1-17, at 5:42, Kazuho Oku wrote: > OTOH, I would like to ask how editorial issues or clarifications > should be handled when we "raise the bar." without having had a chance to discuss this with Mark, my proposal would = be to keep editorial issues on GitHub only, in order to not swamp the = list. If an editor determines that such an issue is in fact not just = editorial, it jumps tracks to what Mark has outlined in his email. Does that make sense? Lars --Apple-Mail=_2C02F062-4053-4347-82A6-FCCA257E08AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On = 2019-1-17, at 5:42, Kazuho Oku <kazuhooku@gmail.com> wrote:
OTOH, I would like to ask how editorial issues or = clarifications
should be = handled when we "raise the bar."

without having had a chance to discuss this with = Mark, my proposal would be to keep editorial issues on GitHub only, in = order to not swamp the list.

If an editor determines that such an = issue is in fact not just editorial, it jumps tracks to what Mark has = outlined in his email.

Does that make sense?

Lars
= --Apple-Mail=_2C02F062-4053-4347-82A6-FCCA257E08AA-- --Apple-Mail=_29DC01A6-746A-4F03-8E9C-2F5DA9F8D157 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlxAYM4ACgkQVLXDCb9w wVchURAA3R0PIROhs0e8yPzVayj1JXb+GG1zbpsE/XRE5Hbt1KffBXC7EJYSrrhq NHugpqnnH+5TFpHl7fxm6UoBEy3/s2PAoqxTK5Do81jNAm9XHjpBTryX/RZKtTJ7 YPNuVfuFlKvKcptEjVLhxZTNc19PJC1tt3uXCqEAZ2Zy2PZuRpcTE3LhpBjdiWCT wj4CjVubR3UpRa74ZJtVezsLmPvHeKnzmkaPko7CrsEAnkao9voRkNbmlaQiS0Fx enaTOrogk6eETcqfEqij94xMC7IeptO4+zA9j/HORKQTSBY88xSAmfr3dNN1pAO8 Q7Ce7QSGLvkVMdyuRPYE3/vLcIGrTMFHVoCmIkMntE6hSWlXdomdnNVXpHUFwde+ kylASMMJmS2h/cPkIp117PzDdnW1HCrM/J5y7o6ywUfh4PzdEu8/iDM9ItumhEBA 1plNZs2b08jUWE9BYK45+QBxhkA1qrRuz0DcuAaskfuMXvSaWkQpaSrGFKMFEdkB IOQLCWUIMIV1ZmdOmqyPoSCqLtraceojOBxXvbhtYRrRP+32F+pPh0JQkg6D++38 bF70RuLaQOThJpqtmeiw62vTVXjzHs4PziJkCJJ27ZZrogk9WjxjHQ62E+8YcBmh 0LWa54DhU2Zh5KuC91qy6XhetdI7PCCK8LRzLkIKx9CqGfnv9Qg= =zcx5 -----END PGP SIGNATURE----- --Apple-Mail=_29DC01A6-746A-4F03-8E9C-2F5DA9F8D157-- From nobody Thu Jan 17 09:49:59 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78F2130F8B for ; Thu, 17 Jan 2019 09:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 dkeeZQ-50HXs for ; Thu, 17 Jan 2019 09:49:50 -0800 (PST) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720090.outbound.protection.outlook.com [40.107.72.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3214A130F65 for ; Thu, 17 Jan 2019 09:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7++HLIXrczxj8vqPv58VxCEtdIiMYRn4+cNGpwQduP0=; b=TBmbRLROs6xpo4LYqpk70kTTSKnA1ksQMyuVuUoZBegvxfGIfmYQYm2hAWBnrPCUd8qO2q2E75bVHXgWNP4hYnPwiqQpWxsD5WRFose2u8s+UtYFI3gX9Nk1GsIoeRSnAl/wSx11VgBgZOJh5XxwEqQNlIs92Dvuu/yZKAzsm84= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0325.namprd22.prod.outlook.com (10.173.194.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Thu, 17 Jan 2019 17:49:47 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::bdbf:c963:ee05:6255]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::bdbf:c963:ee05:6255%8]) with mapi id 15.20.1516.019; Thu, 17 Jan 2019 17:49:47 +0000 From: Mike Bishop To: Lars Eggert , Kazuho Oku CC: Mark Nottingham , IETF QUIC WG Subject: RE: Raising the Bar / Our Work Mode Thread-Topic: Raising the Bar / Our Work Mode Thread-Index: AQHUreJ828h/LignyE6gGOt8Dt6r+qWy0Y2AgAB6/gCAAG4qIA== Date: Thu, 17 Jan 2019 17:49:47 +0000 Message-ID: References: <417BEB18-E41B-4BE6-BDFA-17A9A0C07E1C@eggert.org> In-Reply-To: <417BEB18-E41B-4BE6-BDFA-17A9A0C07E1C@eggert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR22MB0325; 6:+QfCFf6IVWzvpELN473l48SP3lGOElzAw6G2jeb5z/OFk1gwNdY6mV8WZtBgLRXIy4Auojtb6EHp/iIzk4FSxz2nfXCNAuFpxPEOtuhEJ+B0chpCmOi9JDDj1nXWTiAEjTBKufciVMIdqe+po311SufVRm1I/3kCtFNyi3wx9YTIV4/UHWtBCS1y+ECaX1NtfYiXNfaOFzBIg6p/j1i4xlDUSyTeBud+FKbvP338YEzJct1e8Syq1YvbGNdelu/Bn+PjHPE/CvZB4Mn0E+dfpp0o9rC2+fAhdEXoOW2nqjx+aWa/fJknqjUJ1lkN0KwdBo4H42rrERgcN74ySqxHRaz8hBtyiKYcHDPKd7JnLAySZXR/0zQdjatVhOgxrx8CKKsXbAbYkHuXKHMgAbDS9FivtPzkDRwyEhhLb123NUvEyzH8jOcjVK5ReJBqoBmk5tOCjrBMPq9CDTR7qWjnMg==; 5:QMN0ByBAG+8BgZGVSJZEO4R6COzQwN5myfmbL8dd8iMHgkXQrDCi30Dhcq8aviY5HHu7zO9kbkqyzlLVpjuUlkNg1/CjsiUQaEqhkxhvp9xG7uFA9Obwu07ixLOPUYrymuAzHNrJOhw3glllFnCTzgrUm+It5SqouTp/Qq51CTJ02q5OFxRweXPoK6nAReFK9cWVgo9Be06Ife6CJKGdpg==; 7:U7tZjPbFXiJknsy1Kq5B8qj/R65VQm61xvlkly+vPYe7BaqejkeU8UalWc9lO65E0qCYOTDrR7arY0atk/x6SNDnwVc+JIzHFsjCkxsQEy0+1ZCcDt4h6GQKwlN1YAvhr9rpzuAIZkbK0d3XJSjKLA== x-ms-office365-filtering-correlation-id: 96a6ef50-72f2-41cd-56a7-08d67ca42bf4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0325; x-ms-traffictypediagnostic: CY4PR22MB0325: x-microsoft-antispam-prvs: x-forefront-prvs: 0920602B08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(366004)(396003)(39830400003)(376002)(199004)(189003)(14454004)(2906002)(6306002)(508600001)(5660300001)(74316002)(790700001)(6116002)(3846002)(68736007)(81156014)(8676002)(81166006)(33656002)(7736002)(561944003)(106356001)(54906003)(86362001)(105586002)(39060400002)(316002)(236005)(71190400001)(4326008)(99286004)(110136005)(6246003)(14444005)(9686003)(74482002)(71200400001)(4001150100001)(8936002)(229853002)(186003)(97736004)(486006)(102836004)(476003)(7696005)(25786009)(76176011)(256004)(446003)(6436002)(53936002)(54896002)(11346002)(26005)(55016002)(66066001)(53546011)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0325; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mPB7AST9/EmMuV82YjowI+e4Ra7l+Id421edgKHo2ADp+4sYmLNuXN4s9hHjOwwrpm0mldj1mr/JPbPnNTl5QN9Df6ZZLZc1uI1yxEY6rs2vxGJiVKpc+LXJ+RlFcetzCtdcx2kX49XPLiLCE36YWskzyPjX4afcD9nJ0fxzMZjmFc0Z6bqEt1SSJcagMC+7KKHCJ5RFrxILiGmHktZz8Bq4s97KZ0oZ3NymSRn2yLlggt5ILKZ5ELGT7KDE+7aXSOC2EOU6bcC0asdVbkta8X7+H9HbXiyajaBQvmYVSLX0bCFWEKrsYOPmtrbzQVfC+UQ0v9cfxNvG7j83Sg7aUPB9XPZmjmjX3A2ig3Wx01n/wzTdHGvHmqwa3orMPPUqh0j5N7vAQXTYqMjsVfp5AVaCTUFkWtRzxX9f36RRnic= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983A155811A142027B272F8DA830CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 96a6ef50-72f2-41cd-56a7-08d67ca42bf4 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2019 17:49:47.1356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0325 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 17:49:57 -0000 --_000_CY4PR22MB0983A155811A142027B272F8DA830CY4PR22MB0983namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My understanding of the new work process is that editors can still merge ed= itorial PRs without chair approval, so it would make sense to keep these on= GitHub. Just so we're on the same page, my definition of "editorial" woul= d be that it does not: * change bits on the wire * add new mandatory behavior * prohibit previously-permitted behavior * permit previously-prohibited behavior More controversially, I would consider converting a textual recommendation = to a SHOULD or MAY as editorial, since the permission level of following or= ignoring the behavior is the same. Clarifying something that was previous= ly ambiguous might need the design path just in case. From: QUIC On Behalf Of Lars Eggert Sent: Thursday, January 17, 2019 3:03 AM To: Kazuho Oku Cc: Mark Nottingham ; IETF QUIC WG Subject: Re: Raising the Bar / Our Work Mode Hi, On 2019-1-17, at 5:42, Kazuho Oku > wrote: OTOH, I would like to ask how editorial issues or clarifications should be handled when we "raise the bar." without having had a chance to discuss this with Mark, my proposal would be= to keep editorial issues on GitHub only, in order to not swamp the list. If an editor determines that such an issue is in fact not just editorial, i= t jumps tracks to what Mark has outlined in his email. Does that make sense? Lars --_000_CY4PR22MB0983A155811A142027B272F8DA830CY4PR22MB0983namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My understanding of the new work process is that edi= tors can still merge editorial PRs without chair approval, so it would make= sense to keep these on GitHub.  Just so we’re on the same page,= my definition of “editorial” would be that it does not:

  • change bits on the wire
  • add new mandatory behavi= or
  • prohibit previously-permitted behavior
  • permit previously-prohibited behavior

 

More controversially, I would consider converting a = textual recommendation to a SHOULD or MAY as editorial, since the permissio= n level of following or ignoring the behavior is the same.  Clarifying= something that was previously ambiguous might need the design path just in case.

 

From: QUIC <quic-bounces@ietf.org> O= n Behalf Of Lars Eggert
Sent: Thursday, January 17, 2019 3:03 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>; IETF QUIC WG <quic@iet= f.org>
Subject: Re: Raising the Bar / Our Work Mode

 

Hi,

 

On 2019-1-17, at 5:42, Kazuho Oku <kazuhooku@gmail.com> wrote:

OTOH, I would like to ask how editorial issues or clarifications

should be handled when we "raise the bar."= ;

 

without having had a chance to discuss this with Mar= k, my proposal would be to keep editorial issues on GitHub only, in order t= o not swamp the list.

 

If an editor determines that such an issue is in fac= t not just editorial, it jumps tracks to what Mark has outlined in his emai= l.

 

Does that make sense?

 

Lars

--_000_CY4PR22MB0983A155811A142027B272F8DA830CY4PR22MB0983namp_-- From nobody Thu Jan 17 11:36:31 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32606130F66 for ; Thu, 17 Jan 2019 11:36:30 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 jxFtoKekS0RL for ; Thu, 17 Jan 2019 11:36:27 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 A818B130EC8 for ; Thu, 17 Jan 2019 11:36:26 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id l15-v6so9569647lja.9 for ; Thu, 17 Jan 2019 11:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=llzUAHfnF1yD91YOHY69We79Jxd0zeGPZ+tMjWrUUwU=; b=uzQDuqMXJ0+avFmAAWLbpZUZSVJcsACnSkASbswz/qwxSlrOfbDYVvlpQQubgy+Q+a BsHt31Gyks3I31dZSQ+USFQnqy8wmTffNfg3nglhXrGtVAgG5UTB9XqCeQp3TlUtHZh7 I++K8dNXpmQn6EYPiYkXJ5hlAw/IHKUrKW4J5I2qtQ9XQlu57eVICeoRHitTSO9/OE9P Z0mAknf/DuTy+/TUqgxKNCOX4HFtAZGYruiH9/rSwKtegH6p+C4Mo9Btxcz6HiJTJA0q xPNVlbD/huz7eS3NnCjZuPRGTnnk1UR9eozXJeGLTmJM4nEPcIPlPbFOCru/+OWu8k01 LFpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=llzUAHfnF1yD91YOHY69We79Jxd0zeGPZ+tMjWrUUwU=; b=jtTOkHVJJYH67aV2H+TTvl0u9YJR6D5uK3EMzb8R7TLVYB+tuP236NgheNGwzH6zGC yV2HgwDK0VEz49FLff4xL/1j7pqLp0laGSsSSiQoxm5dB57Tqu6lFIaizG2b8UxPK7ic ucR1qvXUgD3MBgiX4MuiPT7Fcl3U6RYP2Dh1x7EyT2K0RN1ExIpnHrFptgyH3mwETmIh rgT6fbnQRTZmyHPHP4zIiZuMmNONt9rEyN3xLk70bOOtIIOFps2vyxG7YYN2c8SooXIw rA6epKzuRLPUzyOZvzAYyEpiWK8YdyGE7BlgE0G8cRFG9dGspW1+cgL5fxGrWts4FEuw wI8Q== X-Gm-Message-State: AJcUukdIM6QnXvgFErHdqkl18NAi8dVMfdSquPShpUtcRfA9gM2GwhD9 3fkugmJwt6dj93PAbDGRtW/NySvfvebNylRItT4= X-Google-Smtp-Source: ALg8bN4MqVeAxFqWfUm9yrTC46IuzIwS7A8+JPJrJfh/qySLTDf8yZ+tOu6loTV5FPzwfsA3Sn0NBDBOOHdTClpJWQM= X-Received: by 2002:a2e:145a:: with SMTP id 26-v6mr10495407lju.116.1547753784590; Thu, 17 Jan 2019 11:36:24 -0800 (PST) MIME-Version: 1.0 References: <417BEB18-E41B-4BE6-BDFA-17A9A0C07E1C@eggert.org> In-Reply-To: From: Jana Iyengar Date: Thu, 17 Jan 2019 11:36:13 -0800 Message-ID: Subject: Re: Raising the Bar / Our Work Mode To: Mike Bishop Cc: Lars Eggert , Kazuho Oku , Mark Nottingham , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000087c999057fac8293" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 19:36:30 -0000 --00000000000087c999057fac8293 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Lars and Mike -- editorial issues and PRs stay on github and can be merged without going through the chairs. Editors and the wg needs to be careful in recognizing behavior changes as such and move them to the mailing list. My understanding of what editorial is exactly matches Mike's description of it, including the controversial bit. On Thu, Jan 17, 2019 at 9:50 AM Mike Bishop wrote: > My understanding of the new work process is that editors can still merge > editorial PRs without chair approval, so it would make sense to keep thes= e > on GitHub. Just so we=E2=80=99re on the same page, my definition of =E2= =80=9Ceditorial=E2=80=9D > would be that it does not: > > - change bits on the wire > - add new mandatory behavior > - prohibit previously-permitted behavior > - permit previously-prohibited behavior > > > > More controversially, I would consider converting a textual recommendatio= n > to a SHOULD or MAY as editorial, since the permission level of following = or > ignoring the behavior is the same. Clarifying something that was > previously ambiguous might need the design path just in case. > > > > *From:* QUIC *On Behalf Of * Lars Eggert > *Sent:* Thursday, January 17, 2019 3:03 AM > *To:* Kazuho Oku > *Cc:* Mark Nottingham ; IETF QUIC WG > *Subject:* Re: Raising the Bar / Our Work Mode > > > > Hi, > > > > On 2019-1-17, at 5:42, Kazuho Oku wrote: > > OTOH, I would like to ask how editorial issues or clarifications > > should be handled when we "raise the bar." > > > > without having had a chance to discuss this with Mark, my proposal would > be to keep editorial issues on GitHub only, in order to not swamp the lis= t. > > > > If an editor determines that such an issue is in fact not just editorial, > it jumps tracks to what Mark has outlined in his email. > > > > Does that make sense? > > > > Lars > --00000000000087c999057fac8293 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Lars and Mike -- editorial issues and PRs sta= y on github and can be merged without going through the chairs. Editors and= the wg needs to be careful in recognizing behavior changes as such and mov= e them to the mailing list.

My understanding of what edi= torial is exactly matches Mike's description of it, including the contr= oversial bit.

On Thu, Jan 17, 2019 at 9:50 AM Mike Bishop <mbishop@evequefou.be> wrote:

My understanding of the new work process is that edi= tors can still merge editorial PRs without chair approval, so it would make= sense to keep these on GitHub.=C2=A0 Just so we=E2=80=99re on the same pag= e, my definition of =E2=80=9Ceditorial=E2=80=9D would be that it does not:

  • change bits on the wire
  • add new mandatory= behavior
  • prohibit previously-permitted behavior<= u>
  • permit previously-prohibited behavior

=C2=A0

More controversially, I would consider converting a = textual recommendation to a SHOULD or MAY as editorial, since the permissio= n level of following or ignoring the behavior is the same.=C2=A0 Clarifying= something that was previously ambiguous might need the design path just in case.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Lars Eggert
Sent: Thursday, January 17, 2019 3:03 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Raising the Bar / Our Work Mode

=C2=A0

Hi,

=C2=A0

On 2019-1-17, at 5:42, Kazuho Oku <kazuhooku@gmail.com> wrot= e:

OTOH= , I would like to ask how editorial issues or clarifications<= u>

should be handled when we "raise the bar."

=C2=A0

without having had a chance to discuss this with Mar= k, my proposal would be to keep editorial issues on GitHub only, in order t= o not swamp the list.

=C2=A0

If an editor determines that such an issue is in fac= t not just editorial, it jumps tracks to what Mark has outlined in his emai= l.

=C2=A0

Does that make sense?

=C2=A0

Lars

--00000000000087c999057fac8293-- From nobody Thu Jan 17 11:39:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAD8130F73 for ; Thu, 17 Jan 2019 11:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, 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=m8qWwKUu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bFSM7Hca 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 2KLLKsZGHKyO for ; Thu, 17 Jan 2019 11:39:30 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818A4130EC8 for ; Thu, 17 Jan 2019 11:39:29 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7769228C9E; Thu, 17 Jan 2019 14:39:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 17 Jan 2019 14:39:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=+ kmYdUa9YSU4XlNG5S7b8vliZ9rm8AaMG3OSiRWPIDM=; b=m8qWwKUuQa0FSQAB9 Cu76tNslNsAQfGQOGqmg110S7D7/WJ8WfTW1wGy72Gn4sB3XQJ4Xh0kpFUAh2lVQ qKUZgw0iB43MwLPzjsm3bYjMHkMiPO25vKFQn5VtmLLKQDQaRQljVg+szEgABlxf tuMdilOwLxZqy3fYAlV3WJxpPqjJ5qcrB1VZGWWlqWiyY7THd+VnvnMmIBSTG6NM DScDS9TtUaSXFcP5aHDcr+YHJwyhEaEdVdzIovtSe6Tv0oXbul3PjzES5w47/TNR 91hC8/RTn0P3vqJhRWHbuk6apDj7czMBytyxCdVr0HTH2Tb2D0hFrjAGcNavYBfy OIrqQ== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=+kmYdUa9YSU4XlNG5S7b8vliZ9rm8AaMG3OSiRWPI DM=; b=bFSM7HcakUNg2IOiolIbijJwVI5FDt9AGKCvs1C2iUNyrf/SNW1315eJE ZV3WNLRNBzTQ0O7Rs8lULQVZPiQTdTriPfyb+TopIkt4rT8K9t3P2TxMn+PSXR88 y9m/Ii4CX7XNvkDETizTzeZ0mcmuKZBe7Ndo3o6qHPqO5VQHgsDp9WJZI0vi6mH2 S01GkJnb4EtnCvt6L9ytKPG3cHjmgDgR6HZs80ziIvAbVn+BkLQwyHBu5p7b5FGw GNQYU4FmNjfkxw0ij4Ph2oLRRiv1I7Yxl+KB8Aadw09Ax7bxobh4i0oP8Sk0IWhF jwjtlfYk1RUjW5p7PGhtPDPcuY8tA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeekgdduvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghm uceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehmnhhothdrnhgvthenuc fkphepieekrdeigedrvddujedrheeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhho thesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [10.114.21.149] (68-64-217-58.static.forethought.net [68.64.217.58]) by mail.messagingengine.com (Postfix) with ESMTPA id E80B8100E5; Thu, 17 Jan 2019 14:39:24 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Raising the Bar / Our Work Mode From: Mark Nottingham In-Reply-To: Date: Thu, 17 Jan 2019 12:39:23 -0700 Cc: Mike Bishop , Lars Eggert , Kazuho Oku , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <417BEB18-E41B-4BE6-BDFA-17A9A0C07E1C@eggert.org> To: Jana Iyengar X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 19:39:33 -0000 Yes. The only thing I'd ask is that there always be an accompanying = issue marked 'editorial', so that people have some visibility and can = contest whether it *is* editorial (PRs often fall through the cracks). Cheers, > On 17 Jan 2019, at 12:36 pm, Jana Iyengar wrote: >=20 > I agree with Lars and Mike -- editorial issues and PRs stay on github = and can be merged without going through the chairs. Editors and the wg = needs to be careful in recognizing behavior changes as such and move = them to the mailing list. >=20 > My understanding of what editorial is exactly matches Mike's = description of it, including the controversial bit. >=20 > On Thu, Jan 17, 2019 at 9:50 AM Mike Bishop = wrote: > My understanding of the new work process is that editors can still = merge editorial PRs without chair approval, so it would make sense to = keep these on GitHub. Just so we=E2=80=99re on the same page, my = definition of =E2=80=9Ceditorial=E2=80=9D would be that it does not: >=20 > =E2=80=A2 change bits on the wire > =E2=80=A2 add new mandatory behavior > =E2=80=A2 prohibit previously-permitted behavior > =E2=80=A2 permit previously-prohibited behavior > =20 >=20 > More controversially, I would consider converting a textual = recommendation to a SHOULD or MAY as editorial, since the permission = level of following or ignoring the behavior is the same. Clarifying = something that was previously ambiguous might need the design path just = in case. >=20 > =20 >=20 > From: QUIC On Behalf Of Lars Eggert > Sent: Thursday, January 17, 2019 3:03 AM > To: Kazuho Oku > Cc: Mark Nottingham ; IETF QUIC WG > Subject: Re: Raising the Bar / Our Work Mode >=20 > =20 >=20 > Hi, >=20 > =20 >=20 > On 2019-1-17, at 5:42, Kazuho Oku wrote: >=20 >=20 > OTOH, I would like to ask how editorial issues or clarifications >=20 > should be handled when we "raise the bar." >=20 > =20 >=20 > without having had a chance to discuss this with Mark, my proposal = would be to keep editorial issues on GitHub only, in order to not swamp = the list. >=20 > =20 >=20 > If an editor determines that such an issue is in fact not just = editorial, it jumps tracks to what Mark has outlined in his email. >=20 > =20 >=20 > Does that make sense? >=20 > =20 >=20 > Lars >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jan 17 11:58:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042B0130F7E for ; Thu, 17 Jan 2019 11:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 PT7icDU2ELZk for ; Thu, 17 Jan 2019 11:58:41 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FA9128CF2 for ; Thu, 17 Jan 2019 11:58:41 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x0HJqSAu004352; Thu, 17 Jan 2019 19:58:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=m6rTy1OFvbpfsQ0b1XDEamINM03NmHFwVh2IFvyt3v0=; b=cq70OsdZw57M8ABujDbAHJ5bqRAUXSH6Z69dRzx4FZ0MhFXYXfzRRHiR+YqXfkexoy/2 vyyNYbuF1ezS5bcO47QUIgjgtoGkwTeV4T7AHpg08VRhElPWff7Ahl42x4d5XAL70Q/8 Sd3IgvrKmLokhcao25l/WppxgthG0/Or3YMuiaA7V977JzOSL6tch7Jm2ZGG7xQfBDfU H01LQoyA6QhIcpuv9NnQ6XPSAYS6ZsPwHB2KFGRLjs+S2fs/f95sca6/XRX4QC7Za95S 5jCJqhF8nJROM0Scsk5dpKURyvsL3pQwXOGLZ0xhi2C/p9OkzvCWh2q89NV5LDngnP1z XA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2q2wf2gg9h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Jan 2019 19:58:32 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x0HJl3Pi014419; Thu, 17 Jan 2019 14:58:31 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2pycf15h0a-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 17 Jan 2019 14:58:30 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 17 Jan 2019 11:57:50 -0800 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Thu, 17 Jan 2019 13:57:50 -0600 From: "Salz, Rich" To: Mark Nottingham , Jana Iyengar CC: Lars Eggert , IETF QUIC WG , Mike Bishop , Kazuho Oku Subject: Re: Raising the Bar / Our Work Mode Thread-Topic: Raising the Bar / Our Work Mode Thread-Index: AQHUreJ+rfi2aEqHZkCFT/W/Sq15vqWzNiKAgAB6/wCAAHHBgIAAHb2AgAAA4oD//7FWAA== Date: Thu, 17 Jan 2019 19:57:50 +0000 Message-ID: <49F26B3D-FAE4-4A57-BC14-1FB56B931FEC@akamai.com> References: <417BEB18-E41B-4BE6-BDFA-17A9A0C07E1C@eggert.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190115 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.104] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-17_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=841 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901170137 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-17_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=831 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901170138 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 19:58:43 -0000 PiAgICBZZXMuIFRoZSBvbmx5IHRoaW5nIEknZCBhc2sgaXMgdGhhdCB0aGVyZSBhbHdheXMgYmUg YW4gYWNjb21wYW55aW5nIGlzc3VlIG1hcmtlZCAnZWRpdG9yaWFsJywgc28gdGhhdCBwZW9wbGUg aGF2ZSBzb21lIHZpc2liaWxpdHkgYW5kIGNhbiBjb250ZXN0IHdoZXRoZXIgaXQgKmlzKiBlZGl0 b3JpYWwgKFBScyBvZnRlbiBmYWxsIHRocm91Z2ggdGhlIGNyYWNrcykuDQogIA0KKzENCg0KQW5k IGNvbnNpZGVyIGFkZGluZyBlZGl0b3JpYWwgaXNzdWVzIHRvIHRoZSBzdW1tYXJ5IGVtYWlscyBu b3cuDQoNCg== From nobody Thu Jan 17 12:16:31 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450A0130E63 for ; Thu, 17 Jan 2019 12:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, 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=hJjW4Ry3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WNtHZy8g 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 0NkQlYXen4Ip for ; Thu, 17 Jan 2019 12:16:28 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBF0127B4C for ; Thu, 17 Jan 2019 12:16:28 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1B72A29103; Thu, 17 Jan 2019 15:16:27 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 17 Jan 2019 15:16:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=J a2DuegOBbYUrqjaixV06D+VCm3D1tGLd3ckTZA+lSI=; b=hJjW4Ry34kpqnp4Ah DQ3gwlVWrQdVJOY+Iu6Js3Kz0eP4675mPOiF0PRb7v09rPRpx6JSeALpZ8/twDZM 3Cv4BJyV48nESVUhVhcgrQoHtzrz6EpPGi3ZqSg9ZayQJvQj0Sgwm0hkk+bryPE/ oe6Z1mdxf/fUvKInp1dIrXUSzOJo8pcxCuXURreZ0Vfms7mQoSw3dfVL0TnfMf5T yv7YFDuzUpp9pYb7B0XF9ownNA/P57f0GS2H6uYmGgtgmY3Y5b7vgp3gFRK9T1bl zf9OTxagh0eAyNUxHOf/nrsMsdhG5OmO8p7FZJzNSzAvuLfuTdW6CMvziDmHGNsO vRWBQ== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Ja2DuegOBbYUrqjaixV06D+VCm3D1tGLd3ckTZA+l SI=; b=WNtHZy8gAnhukI/1AZRCSGVK8IkxicWTQzVkUffp0Ftdh9AHtojgV9viY dSRKiBWlBL3tL3vXYdYSqypXT/mewPgw1Cwvp/uU3ej+UfSyJOYS8aJHUT2678Rd 62wfDZ1nZEjepqsyKiCkmJfUNWgDoi9H7eVSeXBCIdw/QY/VTbdcRCSI7WnQ7XVl cn7D4PLvIiwzXF/aZv9jGNwVkGQsLC0+A/0ey8EWzyxjkm3d0euifITkcPjoJda6 Reef58tIjWYVXHmTOoLWKmzxho8/cM45N0IUwbP5RULi7PK/yhXQgpblK2Fr5EA5 Bwfc8iu9KghpwggiBjen3zjO4Ojeg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeekgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghm uceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehmnhhothdrnhgvthenuc fkphepieekrdeigedrvddujedrheeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhho thesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [10.114.21.149] (68-64-217-58.static.forethought.net [68.64.217.58]) by mail.messagingengine.com (Postfix) with ESMTPA id 38366E4046; Thu, 17 Jan 2019 15:16:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Raising the Bar / Our Work Mode From: Mark Nottingham In-Reply-To: <49F26B3D-FAE4-4A57-BC14-1FB56B931FEC@akamai.com> Date: Thu, 17 Jan 2019 13:16:23 -0700 Cc: Jana Iyengar , Lars Eggert , IETF QUIC WG , Mike Bishop , Kazuho Oku Content-Transfer-Encoding: quoted-printable Message-Id: <06F58561-7778-4F52-9889-F46AFC0B4A3C@mnot.net> References: <417BEB18-E41B-4BE6-BDFA-17A9A0C07E1C@eggert.org> <49F26B3D-FAE4-4A57-BC14-1FB56B931FEC@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 20:16:30 -0000 You mean the weekly summaries? I can do that. > On 17 Jan 2019, at 12:57 pm, Salz, Rich wrote: >=20 >> Yes. The only thing I'd ask is that there always be an accompanying = issue marked 'editorial', so that people have some visibility and can = contest whether it *is* editorial (PRs often fall through the cracks). >=20 > +1 >=20 > And consider adding editorial issues to the summary emails now. >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jan 17 13:00:08 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE25F130E63 for ; Thu, 17 Jan 2019 13:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=G6xZPYZq; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=QW5YmDxW 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 ZuV4NpRvRDBZ for ; Thu, 17 Jan 2019 13:00:04 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50961271FF for ; Thu, 17 Jan 2019 13:00:04 -0800 (PST) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0HJxguI009338; Thu, 17 Jan 2019 12:07:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=1jnanRAasT/5AJos3DWwsHjpP3/XQgVYFgGnq7zDdBU=; b=G6xZPYZqA3SwjFp08vx7JvK04jO23OM6wU7ou/X/4OojkMwUmkLMdwd6mBLQW7NQE3Iv 0WNizRyM1br7xw2E6QgdrFyOhOKyc1+Ke3gaO5aLA4q4H4UmwJG7ErEHP83Mh/cGGEhX 3UyJuEz6wCBsJRAYAGvhR3+JamBUrGNUXhQ= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2q2xks8gxv-10 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 17 Jan 2019 12:07:42 -0800 Received: from prn-hub03.TheFacebook.com (2620:10d:c081:35::127) by prn-hub02.TheFacebook.com (2620:10d:c081:35::126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Thu, 17 Jan 2019 12:06:52 -0800 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Thu, 17 Jan 2019 12:06:52 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1jnanRAasT/5AJos3DWwsHjpP3/XQgVYFgGnq7zDdBU=; b=QW5YmDxWT6zS5hSWOesbl6j7OSMwfcIrFRh1m8Aka/w2WW2RSaXnTKWbJvDZqaHmNsoNS2ueKT8gdeU8lYBnf1fkgG4zM+bTTvbsO4ax6MRSdRDFkOAv0kbpzW/wBNSf9tMpUIJ3rePt3t7cbnWVMzm1wXsaQbXAgM7L8sHHFAs= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2629.namprd15.prod.outlook.com (20.179.156.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.27; Thu, 17 Jan 2019 20:06:40 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::5c98:14c1:4aeb:cfe0]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::5c98:14c1:4aeb:cfe0%4]) with mapi id 15.20.1516.019; Thu, 17 Jan 2019 20:06:40 +0000 From: Roberto Peon To: Mark Nottingham , IETF QUIC WG CC: Lars Eggert Subject: Re: Raising the Bar / Our Work Mode Thread-Topic: Raising the Bar / Our Work Mode Thread-Index: AQHUreKEDYwGCYETx02qUk53y46HdKWzXm6A Date: Thu, 17 Jan 2019 20:06:39 +0000 Message-ID: <8DADE58C-80BB-461E-8433-ECF8909D3A47@fb.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 x-originating-ip: [2620:10d:c090:200::5:80b9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2629; 20:Qxb//cUXuj/BJHsf9HzKultivTlg0duZfx9KyVMVGW0ObbyOh1Iw4Hkob+HbMUjkHNnip5T3GLn7dhccVRQTdDmpDF6FHdcnUGyrgKOAIZpIBQ+xYp1Ud9wVQw/rymKrLjNMGLhz8Jl1PsUt3swRvMLN2u22mGYKGVFGuC1pdmM= x-ms-office365-filtering-correlation-id: a43c5d42-804c-4b73-498b-08d67cb74b47 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2629; x-ms-traffictypediagnostic: BYAPR15MB2629: x-microsoft-antispam-prvs: x-forefront-prvs: 0920602B08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(376002)(39860400002)(136003)(199004)(189003)(97736004)(6246003)(76176011)(33656002)(478600001)(6436002)(229853002)(6486002)(305945005)(476003)(2616005)(68736007)(446003)(36756003)(11346002)(82746002)(8936002)(81166006)(8676002)(81156014)(106356001)(105586002)(14454004)(186003)(102836004)(6506007)(7736002)(46003)(5660300001)(2906002)(110136005)(53936002)(486006)(83716004)(316002)(4326008)(86362001)(58126008)(256004)(6116002)(6512007)(14444005)(99286004)(25786009)(71200400001)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2629; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xMEkmpqftidU8UuzyMuBq7TjFUHMs1xRJvlVOoT2WJ0l0x7OtdMRTL6JtpIv2Mcjvgf12PH5EeWuGJ/m2VUbPnLW+c5kGolg583JOxh3JsImicYmNYo61313H4q1GinWC5v93cNOkLCJG4Q9lpOmJ9SAu+WO97J2bs+b9zFz7FpEWAqUS7Grohfx290/xb9sWdJkChbZ7RF4mMfm0RlIAfLTvcKSoefllDatDsiy2JWHBMOwcUpIUNbfG/Npd+2nTXEC6WPekeZM5zDXwSC3j7SmQ3ZADlc0uz2QjtNCV0rfoosbBgcLmptmdc160YN8Vx3ZrcQ27WLWCjCV2JXz8tEADSXMmOeRt8c3ltdnYZc1GYD0DWrQEuNiHw3NbMLFby8OACrtPnhBxoGCoH/OkOIdX8HBLgS1BYc1a/UCYMw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a43c5d42-804c-4b73-498b-08d67cb74b47 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2019 20:06:40.1104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2629 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-17_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 21:00:07 -0000 U291bmRzIGVtaW5lbnRseSBzYW5lLg0KLT1SDQoNCu+7v09uIDEvMTYvMTksIDE6MjkgUE0sICJR VUlDIG9uIGJlaGFsZiBvZiBNYXJrIE5vdHRpbmdoYW0iIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIG1ub3RAbW5vdC5uZXQ+IHdyb3RlOg0KDQogICAgRXZlcnlvbmUsDQogICAg DQogICAgV2UndmUgcHJldmlvdXNseSB0YWxrZWQgYWJvdXQgInJhaXNpbmcgdGhlIGJhciIgZm9y IGNoYW5nZXMgdG8gdGhlIHByb3RvY29sOyBpLmUuLCByZWZsZWN0aW5nIHRoZSBncm91cCdzIGRl c2lyZSBmb3Igc2hpcHBpbmcgYSB2aWFibGUgcHJvZHVjdCBpbiBhIHJlYXNvbmFibGUgdGltZWZy YW1lIGJ5IGFncmVlaW5nIG5vdCB0byBhY2NlcHQgY2hhbmdlcyB0aGF0IGRvbid0IGhhdmUgYnJv YWQgc3VwcG9ydCBhcyB0ZWNobmljYWxseSBuZWNlc3NhcnksIGFuZCBub3Qgc3BlbmRpbmcgc2ln bmlmaWNhbnQgcmVzb3VyY2VzIG9uIGlzc3VlcyB0aGF0IGFyZSBub3QgbGlrZWx5IHRvIG1lZXQg dGhhdCByZXF1aXJlbWVudC4NCiAgICANCiAgICBUbyBiZSBjbGVhciwgdGhpcyBpcyBhIFdvcmtp bmcgR3JvdXAgZGVjaXNpb24sIG5vdCBzb21ldGhpbmcgaW1wb3NlZCBieSB0aGUgSUVURiBvciB0 aGUgY2hhaXJzLiBFZmZlY3RpdmVseSwgaXQncyBmb3JtaW5nIGNvbnNlbnN1cyB0aGF0IHNoaXBw aW5nIGEgdmlhYmxlIHByb3RvY29sIGluIGEgcmVhc29uYWJsZSBhbW91bnQgb2YgdGltZSBpcyBp dHNlbGYgYSBmZWF0dXJlIC0tIG9uZSB0aGF0J3MgbW9yZSBpbXBvcnRhbnQgdGhhbiBzYXRpc2Z5 aW5nIGV2ZXJ5IGl0Y2ggdGhhdCBwZW9wbGUgaGF2ZSB3aGVuIG1pbnRpbmcgYSBuZXcgcHJvdG9j b2wuDQogICAgDQogICAgVGhlIGNoYWlycyBhbmQgdGhlIGVkaXRvcnMgYmVsaWV2ZSB0aGF0IHdl IGFyZSBub3cgYXBwcm9hY2hpbmcgdGhhdCBwb2ludCBmb3IgdGhlIFRyYW5zcG9ydCwgUmVjb3Zl cnkgYW5kIFRMUyBkcmFmdHMuIEluIFRva3lvLCBvbmUgb2Ygb3VyIGFnZW5kYSBpdGVtcyB3aWxs IGJlIGEgZGlzY3Vzc2lvbiBhbmQgY2FsbHMgZm9yIGNvbnNlbnN1cyBvbjoNCiAgICANCiAgICAq IFRoZSAtMTcgZHJhZnRzIG9mIHRyYW5zcG9ydCwgcmVjb3ZlcnkgYW5kIFRMUywgZGVsdGEgdGhl IGN1cnJlbnQgaXNzdWVzIGxpc3QsIHJlZmxlY3Rpbmcgd29ya2luZyBncm91cCBjb25zZW5zdXMg c28gZmFyDQogICAgKiBSYWlzaW5nIHRoZSBiYXIgZm9yIGNoYW5nZXMgdG8gdGhlc2UgZHJhZnRz IHNob3J0bHkgYWZ0ZXIgdGhlIG1lZXRpbmcuDQogICAgDQogICAgVGhhdCBicmluZ3MgdXAgYSBk aXNjdXNzaW9uIG9mIHdvcmsgbW9kZS4gU2luY2Ugd2Ugc3RhcnRlZCBRVUlDLCB3ZSd2ZSBhbGxv d2VkIHRoZSBlZGl0b3JzIGEgc2lnbmlmaWNhbnQgYW1vdW50IG9mIGxlZXdheSBpbiBhc3Nlc3Np bmcgb3VyIGRpc2N1c3Npb25zLCBmb3JtdWxhdGluZyB0aGVpciBwcm9wb3NhbHMgYW5kIGluY29y cG9yYXRpbmcgdGhlbSBpbnRvIHRoZSBwdWJsaXNoZWQgZHJhZnRzOyB0aGUgcHJlc3VtcHRpb24g aGFzIGJlZW4gdGhhdCBpdCByZXByZXNlbnRzIGluZm9ybWFsIChpLmUuLCBub24tY2FsbGVkKSBj b25zZW5zdXMgdW5sZXNzIHRoZXJlJ3MgYW4gb2JqZWN0aW9uIChvbi1saXN0IG9yIGluIHRoZSBp c3N1ZXMgbGlzdCkuIFRoaXMgaGFzIGhlbHBlZCB1cyB0byBtb3ZlIGF0IGEgcmVhc29uYWJsZSBw YWNlOyB3aGlsZSB3ZSd2ZSBhbHJlYWR5IGFkanVzdGVkIG91ciB0aW1lbGluZSwgd2Ugd291bGRu J3QgYmUgYXMgZmFyIGFsb25nIGlmIHdlIGhhZG4ndCB0YWtlbiB0aGF0IGFwcHJvYWNoLg0KICAg IA0KICAgIEhvd2V2ZXIsIG9uY2Ugd2UgZG8gInJhaXNlIHRoZSBiYXIiLCB0aGlzIHByZXN1bXB0 aW9uIGlzIG5vIGxvbmdlciB3b3JrYWJsZTsgaXQgaXNuJ3QgZmFpciB0byB0aGUgZWRpdG9ycy4g VGhlcmVmb3JlLCBhZnRlcndhcmRzIHdlJ2xsIG5lZWQgY2hhbmdlIG91ciB3b3JrIG1vZGUuIA0K ICAgIA0KICAgIFdoYXQgd2UnZCBsaWtlIHRvIHNlZSBpcyBoYXZpbmcgY2hhbmdlcyBjYW52YXNz ZWQgaW4gR2l0SHViIGlzc3VlcyAqYW5kKiB0aGUgbWFpbGluZyBsaXN0IHRvIGFzc3VyZSBjb25z ZW5zdXMgKGFzIGp1ZGdlZCBieSB0aGUgY2hhaXJzKSwgb25seSBiZWluZyBpbmNvcnBvcmF0ZWQg aW50byB0aGUgZHJhZnRzIGFmdGVyd2FyZHMuIFRoYXQgd2lsbCBtZWFuIHRoYXQgZWFjaCBkcmFm dCBhZnRlciB3ZSBhZG9wdCB0aGlzIGNoYW5nZSB3aWxsIGVmZmVjdGl2ZWx5IHJlZmxlY3Qgd29y a2luZyBncm91cCBjb25zZW5zdXMgYXQgdGhhdCB0aW1lLiANCiAgICANCiAgICBJdCBhbHNvIG1l YW5zIHRoYXQgdGhlIGNoYWlycyB3aWxsIGJlY29tZSBtb3JlIGFjdGl2ZSBpbiBtYW5hZ2luZyB0 aGUgc3RhdGUgb2YgdGhlIGlzc3VlczsgZS5nLiwgZmxhZ2dpbmcgdGhvc2UgdGhhdCBoYXZlIGV4 cGxpY2l0IGNvbnNlbnN1cywgYW5kIGNsb3NpbmcgdGhvc2Ugd2hpY2ggZG9uJ3QgYWNoaWV2ZSBp dCAoaW5jbHVkaW5nIGEgcmV2aWV3IG9mIHRoZSAncGFya2VkJyBpc3N1ZXMpLg0KICAgIA0KICAg IEl0IGRvZXNuJ3QgbWVhbiByYWlzaW5nIG5ldyBpc3N1ZXMgaXMgbm90IHBvc3NpYmxlIC0tIHdl IGNhbiBhbHdheXMgY2hhbmdlIGJhc2VkIHVwb24gbmV3IGluZm9ybWF0aW9uLiBIb3dldmVyLCB0 aGUgcHJlc3VtcHRpb24gd2lsbCBiZSB0aGF0IGNoYW5nZXMgdG8gdGhlIGRlc2lnbiBuZWVkIGJy b2FkIHN1cHBvcnQgd2l0aGluIHRoZSB3b3JraW5nIGdyb3VwIHRvIGdvIGZvcndhcmQuDQogICAg DQogICAgV2UnbGwgaGF2ZSBtb3JlIGRldGFpbHMgYW5kIGRpc2N1c3Npb25zIGF0IHRoZSBtZWV0 aW5nLCBidXQgd2Ugd2FudGVkIHRvIGdldCBpbml0aWFsIGZlZWRiYWNrIGFuZCBxdWVzdGlvbnMg b24gdGhlIGxpc3Q7IHBsZWFzZSBoYXZlIGEgdGhpbmsgYW5kIHJlcGx5IHdpdGggYW55IGNvbmNl cm5zIHlvdSBoYXZlLg0KICAgIA0KICAgIENoZWVycywNCiAgICANCiAgICAtIE1hcmsgYW5kIExh cnMNCiAgICANCiAgICANCiAgICANCg0K From nobody Thu Jan 17 18:06:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18E912DF71 for ; Thu, 17 Jan 2019 18:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 jTF9GE_fKtXG for ; Thu, 17 Jan 2019 18:06:33 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 0FB58126C01 for ; Thu, 17 Jan 2019 18:06:32 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id b20so9313001lfa.12 for ; Thu, 17 Jan 2019 18:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xYN2OG03QYebnvF7CT0habCpROamDNcuI1rWtejuN3I=; b=Gp3T3rhvk3WCdhQ/lrHOlJCfym2lviczedMhQAZ6aCL+393VTOaw4eMff/7ugxCwQE s7HxNhP9QvCeh3D2aeKhRUEIclClJn/TWXQgmUPvFkQn+NS21AhltR+rBoyP/T2vSzdh QVXqS91AGgEcicI4Xbz10SSohhQbQWVS/sg2fjY59W/7AcebUVcQ69nE8T9C+NDmQAZZ yQwhR3O8mVlgWtsK4VbBPEMbCAnS0actZ72TSUZdOnpU2bPB7wt9V/hESnlJO1wa36+C vtUfgwVYRql+gsyjfAcUfXnybdzBulC/CZIRwtW4HoZZ8yEnmv61hgmg9VJVIf6N2Dnm vyOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xYN2OG03QYebnvF7CT0habCpROamDNcuI1rWtejuN3I=; b=pPvDs/WXqtRSQS438HOTWWBev/vSKjTvDOXBigvwsnUB3a+RLZmfbGZ/eHuwx2Lc7Q mstUSPN71HQ55xDfF6Fsvz8ukiP63vR4B2Co95NaL4PVLhGCoHCRAMUsuaAnkKFfcd7R EuSf3ew3xV4rLZwAPZDJeLVMSh1Vs6tMSpDeEA731MsXeIgY3TxSN4+/6vjD/j80kyRc D+EmCT/wG9cN3Z2FnFuFylx6skh7b8y2flNQ6NqYqOzbooteEm+gY3OBe9E8QZug8yim OvhHTBWR3vsl2wRzMGChAA7csBh9cFH8B1tHQhTxwdbvt45nULdV8xGwX70HaJjNg13l BvrQ== X-Gm-Message-State: AJcUukeZPEx/mRI5xaDnxdwWDv85MsQW2Tu8usgAaDQnt4jiX8kK7YtX YMf+VJGzuGhhYlbAVKxaIXclFQ9o/pEAY1WLiP4= X-Google-Smtp-Source: ALg8bN4EFw3UUAtjnrrQiDFxyq4YOCftey03T88am1exZ/DJgsLGYlyG2bHp0DxcXQ4jwAvnO7nI6upbyi9nExHVOEE= X-Received: by 2002:a19:5394:: with SMTP id h20mr11818133lfl.75.1547777190892; Thu, 17 Jan 2019 18:06:30 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> In-Reply-To: From: Jana Iyengar Date: Thu, 17 Jan 2019 18:06:19 -0800 Message-ID: Subject: Re: Key updates To: Kazuho Oku Cc: Christian Huitema , IETF QUIC WG , Ian Swett , Martin Thomson , Ryan Hamilton Content-Type: multipart/alternative; boundary="000000000000a79b9b057fb1f5f8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 02:06:36 -0000 --000000000000a79b9b057fb1f5f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems to me that the issues, while real, are corner cases, since they require (very) frequent key rotation. As such, I'm tempted to avoid these corner cases rather than provide protocol behaviors to allow them. Are there good reasons why key rotation might happen very frequently? On Fri, Jan 11, 2019 at 8:55 PM Kazuho Oku wrote: > 2019=E5=B9=B41=E6=9C=8812=E6=97=A5(=E5=9C=9F) 3:26 Christian Huitema : > > > > > > On 1/9/2019 5:36 PM, Kazuho Oku wrote: > > > ... > > > The problem of using ACK as a signal is that it could provide a false > > > illusion that a sender is permitted to update the traffic key wheneve= r > > > it sees an ACK for a new generation. If the sender falsely assumes > > > that, it would emit packets that cannot be decrypted by the receiver > > > that tries to retain minimum number of keys (i.e. 2). > > > > > > My preference goes to having a design that guarantees the > > > communication to succeed without requiring the receiver to retain a > > > greater number of keys than necessary. > > > > I think we all agree that after draft 17, any change to packet format > > should clear a very high bar. > > My understanding is that it is not only the packet format. Any change > to the protocol needs to clear the high bar. The flip side is that we > are free to choose the most appropriate way _if_ we agree that there > is a reason to change. > > In this particular case, the new information we have is that the key > update mechanism that we currently have has an issue that the keys > might become out-of-sync. > > I think we should fix the issue, and assuming that the WG agrees to > fix the issue, my preferred way of fixing the issue is to introduce > the Key Update Permitted bit, because it is simple and hard to > mis-implement on both the sender and the receiver side, as well as > having the other benefits that we have discussed. Using the key phase > bit "and ACK" to see if the sender can issue another update is > complicated. > > > The PR proposes to add a bit in the header > > bit, and is just one such change. I understand it is just one bit, but > > then I have some experience when asked to change just one bit in code > > that is almost ready to ship. And I would rather not do it, because I d= o > > not believe the change is necessary. I read the thread, and I can count > > three issues. I am not convinced that either of those clears the bar. > > > > The first issue is that if peers rotate the key too often, and > > especially if they rotate the key often and simultaneously, they could > > end up breaking the connection. Well, don't do that. > > > > The second issue is that if a peer rotates keys too quickly, it forces > > the other peer to maintain multiple encryption contexts. Key rotation > > requires maintaining at least two contexts: old and current, or current > > and new. The old context can be disposed of as soon as packets are not > > expected from the peer, which is currently defined as 3 RTO. If a > > rotation occurs with these 3 RTO, the node may need to keep 3 contexts: > > old, current and new. Again, the solution is simple: don't do that. We > > could add text to that effect, such as "at least 6 RTO between key > > rotations". Or we could simply state that if a peer engages in rotation > > N+1, it is effectively discarding all packets still in transit from > > rotation N-1, effectively limiting the number of keys to be maintained > to 2. > > > > The third issue is not really a protocol issue, but rather a new > > functionality. Can nodes limit how often their peers engage in key > > rotation? Or, pushed to the max, can an implementation just not support > > key rotation at all. My take is that this kind of feature negotiation i= s > > better handled with transport parameters than by adding bits in the > > header. I am also very concerned that if an application supports key > > rotation there should be an easy way to test it. > > > > -- Christian Huitema > > > > > > > -- > Kazuho Oku > > --000000000000a79b9b057fb1f5f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems to me that the issues, while real, are corner cas= es, since they require (very) frequent key rotation. As such, I'm tempt= ed to avoid these corner cases rather than provide protocol behaviors to al= low them.

Are there good reasons why key rotation might = happen very frequently?

On Fri, Jan 11, 2019 at 8:55 PM Kazuho Oku &l= t;kazuhooku@gmail.com> wrote:=
2019=E5=B9=B41= =E6=9C=8812=E6=97=A5(=E5=9C=9F) 3:26 Christian Huitema <huitema@huitema.net>:
>
>
> On 1/9/2019 5:36 PM, Kazuho Oku wrote:
> > ...
> > The problem of using ACK as a signal is that it could provide a f= alse
> > illusion that a sender is permitted to update the traffic key whe= never
> > it sees an ACK for a new generation. If the sender falsely assume= s
> > that, it would emit packets that cannot be decrypted by the recei= ver
> > that tries to retain minimum number of keys (i.e. 2).
> >
> > My preference goes to having a design that guarantees the
> > communication to succeed without requiring the receiver to retain= a
> > greater number of keys than necessary.
>
> I think we all agree that after draft 17, any change to packet format<= br> > should clear a very high bar.

My understanding is that it is not only the packet format. Any change
to the protocol needs to clear the high bar. The flip side is that we
are free to choose the most appropriate way _if_ we agree that there
is a reason to change.

In this particular case, the new information we have is that the key
update mechanism that we currently have has an issue that the keys
might become out-of-sync.

I think we should fix the issue, and assuming that the WG agrees to
fix the issue, my preferred way of fixing the issue is to introduce
the Key Update Permitted bit, because it is simple and hard to
mis-implement on both the sender and the receiver side, as well as
having the other benefits that we have discussed. Using the key phase
bit "and ACK" to see if the sender can issue another update is complicated.

> The PR proposes to add a bit in the header
> bit, and is just one such change. I understand it is just one bit, but=
> then I have some experience when asked to change just one bit in code<= br> > that is almost ready to ship. And I would rather not do it, because I = do
> not believe the change is necessary. I read the thread, and I can coun= t
> three issues. I am not convinced that either of those clears the bar.<= br> >
> The first issue is that if peers rotate the key too often, and
> especially if they rotate the key often and simultaneously, they could=
> end up breaking the connection. Well, don't do that.
>
> The second issue is that if a peer rotates keys too quickly, it forces=
> the other peer to maintain multiple encryption contexts. Key rotation<= br> > requires maintaining at least two contexts: old and current, or curren= t
> and new. The old context can be disposed of as soon as packets are not=
> expected from the peer, which is currently defined as 3 RTO. If a
> rotation occurs with these 3 RTO, the node may need to keep 3 contexts= :
> old, current and new. Again, the solution is simple: don't do that= . We
> could add text to that effect, such as "at least 6 RTO between ke= y
> rotations". Or we could simply state that if a peer engages in ro= tation
> N+1, it is effectively discarding all packets still in transit from > rotation N-1, effectively limiting the number of keys to be maintained= to 2.
>
> The third issue is not really a protocol issue, but rather a new
> functionality. Can nodes limit how often their peers engage in key
> rotation? Or, pushed to the max, can an implementation just not suppor= t
> key rotation at all. My take is that this kind of feature negotiation = is
> better handled with transport parameters than by adding bits in the > header. I am also very concerned that if an application supports key > rotation there should be an easy way to test it.
>
> -- Christian Huitema
>
>


--
Kazuho Oku

--000000000000a79b9b057fb1f5f8-- From nobody Thu Jan 17 19:31:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E491310D5 for ; Thu, 17 Jan 2019 19:31:35 -0800 (PST) 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=unavailable 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 I4lcKbCfBORh for ; Thu, 17 Jan 2019 19:31:33 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 7DE981310D4 for ; Thu, 17 Jan 2019 19:31:33 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id l10so9425907lfh.9 for ; Thu, 17 Jan 2019 19:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=I9HazoWnx7sSxvU7YLNRowvDkVwU9gnwb1gNjeCN6wI=; b=ojzzAY7T9iIFslvsRbgLwy9tFQoraGKFs+4eLYLM/QEZy5JrEAKCCdw8BxUt6zlgcI 8wz460L3IoFjJgHxrg7Tqb+Le9JXGEUi4933VyV5r5gb32GxL2rSlXbB1sV2QqHyvdAr bECqjWwNcRGnIKVyRMqIGQzcIAMoTkhV9zBvIqkIq6ukfTYbpfdNKg+zDiGyQfR4UBNZ SfzeSTdvgevV5XoECnsPfUgipQBjHt7ryZlneegqIkMXkQ1ajl9yiBFrXS7oRpxmsB/Z Mgs7s3vWvBVH4QGO2UcAoXFZZfR9aZD79u+SOhtG8dCQN3gYMTVZK0hnmOkv57wYIjoP 1rOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=I9HazoWnx7sSxvU7YLNRowvDkVwU9gnwb1gNjeCN6wI=; b=ghzveDfkRiWtMyeL4FeabGoYTqAxDbclKymUr+dOvY0zMUIow9OYiZnmZp+FnXlp3w m0R8RSQJ/HYCIhnGYjyr4gP+6B53+sqEfD10IP9o6z1MsNfM8wnBVbKkodCq1q+U+ruG WMdxDZZbFf5T1/or9rSHMtBZzorBmDE7lLIrC9CTkTGcGF/9j/JF/er6oupViyc112zP 9fpvr3CkH8H/u1H1U8xnU2RF6uZHtvx+y0vdrMbFNVv1C1yg5Rab56X88Obk8D+0Q9EF lCBbS4jniMaigQ3n6wwcTSZDe/7ZJtcR6NQHvd5ajAVQGcvM1YCK6yXAMJGGtE84AiOI zFUg== X-Gm-Message-State: AJcUukd2jikZ8hobjyd86E/4mKrzg/YDRO6rioPoYDTCXjxFO+jNcv0U BDHBQxF1WHAQFrazW4gqzc0utGvEnMUwI8npxLo= X-Google-Smtp-Source: ALg8bN7asTRJEUeqvGU9iyFS5RMX6b0Rcyu5zfBwNt9bwbcab7+LS02YSsA/GcQs+juod1+Bs0qrOTFJj2AptzlvadA= X-Received: by 2002:a19:1994:: with SMTP id 142mr12129857lfz.134.1547782291573; Thu, 17 Jan 2019 19:31:31 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> In-Reply-To: From: Kazuho Oku Date: Fri, 18 Jan 2019 12:31:20 +0900 Message-ID: Subject: Re: Key updates To: Jana Iyengar Cc: Christian Huitema , IETF QUIC WG , Ian Swett , Martin Thomson , Ryan Hamilton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 03:31:36 -0000 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 11:06 Jana Iyengar : > > It seems to me that the issues, while real, are corner cases, since they = require (very) frequent key rotation. As such, I'm tempted to avoid these c= orner cases rather than provide protocol behaviors to allow them. > > Are there good reasons why key rotation might happen very frequently? I think that is a good question. I might be concerned about an endpoint that tries to update the key whenever it tries to use a new network. An endpoint running on a mobile device (that has a Wifi hardware with support for encryption offload) might try to install a new key every time the Wifi network comes up. Under such a design, when a Wifi network comes up (triggering a key update) and then immediately becomes unreachable, then if another Wifi network becomes reachable, the endpoint might try to install different key twice, if that is permitted by the state of the QUIC connection. > On Fri, Jan 11, 2019 at 8:55 PM Kazuho Oku wrote: >> >> 2019=E5=B9=B41=E6=9C=8812=E6=97=A5(=E5=9C=9F) 3:26 Christian Huitema : >> > >> > >> > On 1/9/2019 5:36 PM, Kazuho Oku wrote: >> > > ... >> > > The problem of using ACK as a signal is that it could provide a fals= e >> > > illusion that a sender is permitted to update the traffic key whenev= er >> > > it sees an ACK for a new generation. If the sender falsely assumes >> > > that, it would emit packets that cannot be decrypted by the receiver >> > > that tries to retain minimum number of keys (i.e. 2). >> > > >> > > My preference goes to having a design that guarantees the >> > > communication to succeed without requiring the receiver to retain a >> > > greater number of keys than necessary. >> > >> > I think we all agree that after draft 17, any change to packet format >> > should clear a very high bar. >> >> My understanding is that it is not only the packet format. Any change >> to the protocol needs to clear the high bar. The flip side is that we >> are free to choose the most appropriate way _if_ we agree that there >> is a reason to change. >> >> In this particular case, the new information we have is that the key >> update mechanism that we currently have has an issue that the keys >> might become out-of-sync. >> >> I think we should fix the issue, and assuming that the WG agrees to >> fix the issue, my preferred way of fixing the issue is to introduce >> the Key Update Permitted bit, because it is simple and hard to >> mis-implement on both the sender and the receiver side, as well as >> having the other benefits that we have discussed. Using the key phase >> bit "and ACK" to see if the sender can issue another update is >> complicated. >> >> > The PR proposes to add a bit in the header >> > bit, and is just one such change. I understand it is just one bit, but >> > then I have some experience when asked to change just one bit in code >> > that is almost ready to ship. And I would rather not do it, because I = do >> > not believe the change is necessary. I read the thread, and I can coun= t >> > three issues. I am not convinced that either of those clears the bar. >> > >> > The first issue is that if peers rotate the key too often, and >> > especially if they rotate the key often and simultaneously, they could >> > end up breaking the connection. Well, don't do that. >> > >> > The second issue is that if a peer rotates keys too quickly, it forces >> > the other peer to maintain multiple encryption contexts. Key rotation >> > requires maintaining at least two contexts: old and current, or curren= t >> > and new. The old context can be disposed of as soon as packets are not >> > expected from the peer, which is currently defined as 3 RTO. If a >> > rotation occurs with these 3 RTO, the node may need to keep 3 contexts= : >> > old, current and new. Again, the solution is simple: don't do that. We >> > could add text to that effect, such as "at least 6 RTO between key >> > rotations". Or we could simply state that if a peer engages in rotatio= n >> > N+1, it is effectively discarding all packets still in transit from >> > rotation N-1, effectively limiting the number of keys to be maintained= to 2. >> > >> > The third issue is not really a protocol issue, but rather a new >> > functionality. Can nodes limit how often their peers engage in key >> > rotation? Or, pushed to the max, can an implementation just not suppor= t >> > key rotation at all. My take is that this kind of feature negotiation = is >> > better handled with transport parameters than by adding bits in the >> > header. I am also very concerned that if an application supports key >> > rotation there should be an easy way to test it. >> > >> > -- Christian Huitema >> > >> > >> >> >> -- >> Kazuho Oku >> --=20 Kazuho Oku From nobody Thu Jan 17 20:07:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC38130FB8 for ; Thu, 17 Jan 2019 20:07:16 -0800 (PST) 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 q3tSSqbj2OAJ for ; Thu, 17 Jan 2019 20:07:14 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 613B3130F12 for ; Thu, 17 Jan 2019 20:07:14 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id n18so9476336lfh.6 for ; Thu, 17 Jan 2019 20:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=b8XcfmdjVoRYKt4fccm6GTH48SAlb9e5qHSY0z6EgbM=; b=WkBPKQelqMMLIZs+n1DLbY7wFiq2AHlj0JgIoAenLsjri/YPgrsadWQBgcxgDN5EF5 icCA8R3+Rn6BwGiHOX0NzT+G328B40RWeHuWBP/iuSIDUFogA52GCR4/pDwOSB72MRvc krJvXhj/rZ0G8/sALWK3juw56vv9qLPetFfjydMgZpBXiQtcyA0eD0Z6Jd+KYhfGbh2P D/VK4DMPN/vHRwSrcN2DFcx4dggN939TorRIvDNKOQWqgCWo9DSNbfTr3B1Uz39A4P5J qZaPVUTZlowio7jh/qESj1IYJ7gpk9SH95vcEHXMBqqtgIuE5AcwjEazicszStAMV/In 623A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=b8XcfmdjVoRYKt4fccm6GTH48SAlb9e5qHSY0z6EgbM=; b=hDAzKYeTCbkbfzOi5QpaiG5co9YxWP1+VqeaNs2Co8gXtJkzTe7bXfNNVTzcIJUE0S mV6kpssMAr9qM7mqjRgIm2KGBG2yzzlsqGgOKxrO/CZnoQYIoHErRoLBQe/BX2CZJNdu o7T77sdoEjuKiRfuqSWVWLt3EuVWB5oFCOIdNvEY2haJy77Ag7WKfXkQSw9WTdauQ4cT QpjNeSHC+4FqzXXJ5Wt0VnnrvT0GOeaxa8Kb0TPimHvFwKZ/Lvk/fpKcyjggS33h8rwt HZ8WxSprBe2ikm8L4Rk6DSBm8MG+n8fW8iyXbYRzvV6RLixciRCwkjENN+wGyUaCOZMX +GiQ== X-Gm-Message-State: AJcUukdGzTb0P7HX2mP1++A4JE2LrGcZPo0omEGvmFg6sg3ImeJcVVRC Kthvq3qXi3R44RZMI8CIyiC6R92QXuz9pKN03XbI+A== X-Google-Smtp-Source: ALg8bN6cgJUPnLdYpuJ2jarm74OSoMeXSF/yoDcZYvmuDJ3aPaNQpp+CS6B05JftZbJUZ41TTravP4F6shKdAFItsfQ= X-Received: by 2002:a19:ced3:: with SMTP id e202mr11589186lfg.13.1547784432511; Thu, 17 Jan 2019 20:07:12 -0800 (PST) MIME-Version: 1.0 References: <417BEB18-E41B-4BE6-BDFA-17A9A0C07E1C@eggert.org> In-Reply-To: From: Kazuho Oku Date: Fri, 18 Jan 2019 13:07:01 +0900 Message-ID: Subject: Re: Raising the Bar / Our Work Mode To: Mark Nottingham Cc: Jana Iyengar , Mike Bishop , Lars Eggert , IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 04:07:17 -0000 Thank you all for the clarifications. All your comments make sense to me. 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 4:39 Mark Nottingham : > > Yes. The only thing I'd ask is that there always be an accompanying issue= marked 'editorial', so that people have some visibility and can contest wh= ether it *is* editorial (PRs often fall through the cracks). > > Cheers, > > > > On 17 Jan 2019, at 12:36 pm, Jana Iyengar wrote: > > > > I agree with Lars and Mike -- editorial issues and PRs stay on github a= nd can be merged without going through the chairs. Editors and the wg needs= to be careful in recognizing behavior changes as such and move them to the= mailing list. > > > > My understanding of what editorial is exactly matches Mike's descriptio= n of it, including the controversial bit. > > > > On Thu, Jan 17, 2019 at 9:50 AM Mike Bishop wrot= e: > > My understanding of the new work process is that editors can still merg= e editorial PRs without chair approval, so it would make sense to keep thes= e on GitHub. Just so we=E2=80=99re on the same page, my definition of =E2= =80=9Ceditorial=E2=80=9D would be that it does not: > > > > =E2=80=A2 change bits on the wire > > =E2=80=A2 add new mandatory behavior > > =E2=80=A2 prohibit previously-permitted behavior > > =E2=80=A2 permit previously-prohibited behavior > > > > > > More controversially, I would consider converting a textual recommendat= ion to a SHOULD or MAY as editorial, since the permission level of followin= g or ignoring the behavior is the same. Clarifying something that was prev= iously ambiguous might need the design path just in case. > > > > > > > > From: QUIC On Behalf Of Lars Eggert > > Sent: Thursday, January 17, 2019 3:03 AM > > To: Kazuho Oku > > Cc: Mark Nottingham ; IETF QUIC WG > > Subject: Re: Raising the Bar / Our Work Mode > > > > > > > > Hi, > > > > > > > > On 2019-1-17, at 5:42, Kazuho Oku wrote: > > > > > > OTOH, I would like to ask how editorial issues or clarifications > > > > should be handled when we "raise the bar." > > > > > > > > without having had a chance to discuss this with Mark, my proposal woul= d be to keep editorial issues on GitHub only, in order to not swamp the lis= t. > > > > > > > > If an editor determines that such an issue is in fact not just editoria= l, it jumps tracks to what Mark has outlined in his email. > > > > > > > > Does that make sense? > > > > > > > > Lars > > > > -- > Mark Nottingham https://www.mnot.net/ > --=20 Kazuho Oku From nobody Thu Jan 17 20:33:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFB1131112 for ; Thu, 17 Jan 2019 20:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 eIPGdkun8n4J for ; Thu, 17 Jan 2019 20:33:39 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46D2131110 for ; Thu, 17 Jan 2019 20:33:38 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gkLqX-00051K-UO for quic@ietf.org; Fri, 18 Jan 2019 05:33:35 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gkLqV-0001TF-S2 for quic@ietf.org; Thu, 17 Jan 2019 23:33:32 -0500 Received: (qmail 21349 invoked from network); 18 Jan 2019 04:33:29 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Jan 2019 04:33:28 -0000 To: Kazuho Oku , Jana Iyengar Cc: Ryan Hamilton , IETF QUIC WG , Martin Thomson , Ian Swett References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Thu, 17 Jan 2019 18:33:27 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F9B9FAFC809757CA1A04B914" Content-Language: en-US Subject: Re: Key updates X-Originating-IP: 168.144.250.223 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.37) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5sGbTX0wi0RgMCLy9U9tYh9602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVir81dqGAnULsmgVLNZY9CPM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1VzUjpi3KNxdQZ39cmOPHk5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMSvBkSqQUHV5hMinZNqXMuOqpzxuZ/FKz4x4mg8I92kbtmbpi9bZHgn p6sbAhOVJz1k354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAliU20wPuSTm+IJBmdo0FC1ZZYSpQQtCkh8qZ SV0LCxteeHQly8mIr+HZljTqMN4f2c8lFWHlU+2c9cXtB/Zh+ekhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uKxlHEurUN5OnjeiFCqHX+Ta9UshveVgoiypAicYsWUtd8y9Ga5iCmdJFIvDE Jb+pKY4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 04:33:42 -0000 This is a multi-part message in MIME format. --------------F9B9FAFC809757CA1A04B914 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/17/2019 5:31 PM, Kazuho Oku wrote: > 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 11:06 Jana Iyengar : >> It seems to me that the issues, while real, are corner cases, since th= ey require (very) frequent key rotation. As such, I'm tempted to avoid th= ese corner cases rather than provide protocol behaviors to allow them. >> >> Are there good reasons why key rotation might happen very frequently? > I think that is a good question. > > I might be concerned about an endpoint that tries to update the key > whenever it tries to use a new network. An endpoint running on a > mobile device (that has a Wifi hardware with support for encryption > offload) might try to install a new key every time the Wifi network > comes up. > > Under such a design, when a Wifi network comes up (triggering a key > update) and then immediately becomes unreachable, then if another Wifi > network becomes reachable, the endpoint might try to install different > key twice, if that is permitted by the state of the QUIC connection. Fine. So maybe we should just say, "don't do that". There is no functional requirement to change the key when the network changes. If the endpoints are doing migration, it seems like a really bad idea to try rotate the keys at the same time. The other plausible corner case is a very high speed connection, over which so many packets are sent so quickly that using the same key might be risky. Section 5.5 of RFC 8446 states that the 64 bit Record Sequence Number would wrap before that becomes a problem with ChaCha20/Poly1305, but that after sending more than=C2=A0 2^24.5 full-size records (about 24= million) the safety margin of AES-GCM would drop to 2^-57. QUIC is never sending full size records, but the most conservative reading of this paragraph is that keys should be rotated after sending at most 2^24 packets when using AES-GCM. On a 10 Gbps link, that would last 30 seconds, and that's too long to create risks of getting out of sync. It could only be an issue if the peers were running on a terabit link with a long RTT. Well, if they do that, the obvious fix is to use ChaCha20/Poly1305 instead of AES GCM. -- Christian Huitema --------------F9B9FAFC809757CA1A04B914 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 1/17/2019 5:31 PM, Kazuho Oku wrote:

2019年1月18日(金) 11:06 Jana Iyengar <jri.ietf@gmail.com>:

It seems to me that the issues, while real, are corner cases, since they require (very) frequent key rotation. As such, I'm tempted to avoid these corner cases rather than provide protocol behaviors to allow them.

Are there good reasons why key rotation might happen very frequently?

I think that is a good question.

I might be concerned about an endpoint that tries to update the key
whenever it tries to use a new network. An endpoint running on a
mobile device (that has a Wifi hardware with support for encryption
offload) might try to install a new key every time the Wifi network
comes up.

Under such a design, when a Wifi network comes up (triggering a key
update) and then immediately becomes unreachable, then if another Wifi
network becomes reachable, the endpoint might try to install different
key twice, if that is permitted by the state of the QUIC connection.

Fine. So maybe we should just say, "don't do that". There is no functional requirement to change the key when the network changes. If the endpoints are doing migration, it seems like a really bad idea to try rotate the keys at the same time.

The other plausible corner case is a very high speed connection, over which so many packets are sent so quickly that using the same key might be risky. Section 5.5 of RFC 8446 states that the 64 bit Record Sequence Number would wrap before that becomes a problem with ChaCha20/Poly1305, but that after sending more than  2^24.5 full-size records (about 24 million) the safety margin of AES-GCM would drop to 2^-57. QUIC is never sending full size records, but the most conservative reading of this paragraph is that keys should be rotated after sending at most 2^24 packets when using AES-GCM. On a 10 Gbps link, that would last 30 seconds, and that's too long to create risks of getting out of sync. It could only be an issue if the peers were running on a terabit link with a long RTT. Well, if they do that, the obvious fix is to use ChaCha20/Poly1305 instead of AES GCM.

-- Christian Huitema

--------------F9B9FAFC809757CA1A04B914-- From nobody Thu Jan 17 21:39:12 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE49F12E7C1 for ; Thu, 17 Jan 2019 21:39:10 -0800 (PST) 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=unavailable 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 wA4JWYuth1hE for ; Thu, 17 Jan 2019 21:39:08 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 23A7D127AC2 for ; Thu, 17 Jan 2019 21:39:08 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id l10so9577255lfh.9 for ; Thu, 17 Jan 2019 21:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MB0wlElgAkGxJyQ+G/Yaj6UsGfFMRj8VqwucgONEQa4=; b=RmHzCnzwYgnZhIGklbiMoFTg68ok5YPz8KVcFmMMZg2k9+nKx/LvTVQF+V4sdcdPhm Zt6LlHXYxU5Sa/ogxtPI3Rte2qq6eS3erVubGA6uFxMgVzMGpKD/DnRmuFGmXwWDP+yh +XrSA2oet/csMF2OUbmhoN1wPdEgqwYWLtoFGyReKE60JtNaIxRA8jz4En/CF0yo9n8o mS04JHEnGsnF4NcDdI+wyvPcKTipIEqBL/U07gEKz6cVGcQvh7pklq95zoR0zGGUlR9F k6v4zUCiILD00HINIkLt8zqxdGYmTxTsLwRpkYYVdgBmnJNt11U7FSm7qi4RY1Uf7AEQ zKLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MB0wlElgAkGxJyQ+G/Yaj6UsGfFMRj8VqwucgONEQa4=; b=BFQMQ8yMVgyJodG8ey7G8feio2Luo3wMHzD1CXw550gP0dwoS4dkH4ZY0D7tdSMIUy ehdaluHsLWwAcqXrAHaPv43dHsRPv4Q5qhfiLDq20XgJWk+VwJmIPSC92lNcoE2rPYMN HqfbzOGc0Ion1AIdVbBRFSc8kQnzkftd60AxVEojwI0z+uEWPhb5n/SZcF9gpz0KpG91 rTO9A1aCpEhLTShu2MCSI2Ohr9uLx8P4/hJLtsrP0XMu+nmW/oifOb9u8/dN+JdZqLlY jgPk5OcQIf7qzhKGy9Db3E48I0deprYqXYFI/YTlj60zPo/5PaUDucPx5J9BAwz/Vt4f R85Q== X-Gm-Message-State: AJcUukc/5RDo6VxutrT8SpauGVuOWcz1Jymi6K/sLYt36UJExdxppLlc Yvk2ybYP264rTY+qJhz9xdFuUISW1dRff796L60= X-Google-Smtp-Source: ALg8bN6fcynOhyBKeOJNsQ4n48Lxp+GT0tSwYrz9gxt244OFKLWRxes+DFtour26czlKlzxAlq0JcP6kRcBZ5B/colQ= X-Received: by 2002:a19:d5:: with SMTP id 204mr11277267lfa.116.1547789946218; Thu, 17 Jan 2019 21:39:06 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> In-Reply-To: From: Kazuho Oku Date: Fri, 18 Jan 2019 14:38:54 +0900 Message-ID: Subject: Re: Key updates To: Christian Huitema Cc: Jana Iyengar , Ryan Hamilton , IETF QUIC WG , Martin Thomson , Ian Swett Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 05:39:11 -0000 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 13:33 Christian Huitema : > > On 1/17/2019 5:31 PM, Kazuho Oku wrote: > > 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 11:06 Jana Iyengar : > > It seems to me that the issues, while real, are corner cases, since they = require (very) frequent key rotation. As such, I'm tempted to avoid these c= orner cases rather than provide protocol behaviors to allow them. > > Are there good reasons why key rotation might happen very frequently? > > I think that is a good question. > > I might be concerned about an endpoint that tries to update the key > whenever it tries to use a new network. An endpoint running on a > mobile device (that has a Wifi hardware with support for encryption > offload) might try to install a new key every time the Wifi network > comes up. > > Under such a design, when a Wifi network comes up (triggering a key > update) and then immediately becomes unreachable, then if another Wifi > network becomes reachable, the endpoint might try to install different > key twice, if that is permitted by the state of the QUIC connection. > > Fine. So maybe we should just say, "don't do that". There is no functiona= l requirement to change the key when the network changes. If the endpoints = are doing migration, it seems like a really bad idea to try rotate the keys= at the same time. > > The other plausible corner case is a very high speed connection, over whi= ch so many packets are sent so quickly that using the same key might be ris= ky. Section 5.5 of RFC 8446 states that the 64 bit Record Sequence Number w= ould wrap before that becomes a problem with ChaCha20/Poly1305, but that af= ter sending more than 2^24.5 full-size records (about 24 million) the safe= ty margin of AES-GCM would drop to 2^-57. QUIC is never sending full size r= ecords, but the most conservative reading of this paragraph is that keys sh= ould be rotated after sending at most 2^24 packets when using AES-GCM. On a= 10 Gbps link, that would last 30 seconds, and that's too long to create ri= sks of getting out of sync. It could only be an issue if the peers were run= ning on a terabit link with a long RTT. Well, if they do that, the obvious = fix is to use ChaCha20/Poly1305 instead of AES GCM. Yeah. Practically speaking, I'd assume that you'd need to spend multiple round-trips to send 2^24 packets due to the size of the congestion window. It might also be worth pointing out that an endpoint cannot send more than 2^pn_bits packets before seeing an acknowledgement from the peer. My understanding is that most if not all of the QUIC stacks will use a 16-bit packet number, and that means that updating the key less frequently than every 2^16 packets is guaranteed to be safe. The issue with the current text is that it incorrectly suggests that the peer updating the key is a signal that it is ready to accept another key update. If we are going to fix the issue without changing the wire format, I think we need to state the overarching rule (that an endpoint MUST NOT initiate a Key Update unless it knows that the peer has received a packet protected by the current key) as well as how to determine that. For example, something like: * A sender MUST NOT initiate a Key Update unless it is certain that the peer has accepted a packet that was encrypted by the current key. * One way of testing the condition is to examine the ACK frames sent by the peer; a packet encrypted using the current key being acknowledged by the peer can be used as the signal. * The other way is to not instantiate a key update until the previous update until emitting at least 2^pn_bits packets. * A sender SHOULD NOT initiate a Key Update earlier than 3-PTO after the previous switch of application traffic key. > -- Christian Huitema --=20 Kazuho Oku From nobody Thu Jan 17 23:44:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C05131151 for ; Thu, 17 Jan 2019 23:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VqsGSy7sYrYz for ; Thu, 17 Jan 2019 23:44:53 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332EE131150 for ; Thu, 17 Jan 2019 23:44:52 -0800 (PST) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4C012278315 for ; Fri, 18 Jan 2019 16:44:50 +0900 (JST) Received: by mail-wm1-f52.google.com with SMTP id y8so3493373wmi.4 for ; Thu, 17 Jan 2019 23:44:50 -0800 (PST) X-Gm-Message-State: AJcUukfn7f+sHkpzbeRQ5ndtOu/Qb8s/+IQhva3PiNgX9t2FH/6HFFpD +aRjq3+5dwD2ZGdZ8Td2rhZI0x5grWL73U4uaxc= X-Google-Smtp-Source: ALg8bN66r+4Lf5bHTtSiWFLOtg73t8Vi2ap1FF6arOisgRO8kM7jWv+p3RKbACcFWraaplDQpj39Xx32K06oR2amdXE= X-Received: by 2002:a1c:5656:: with SMTP id k83mr14784729wmb.125.1547797488035; Thu, 17 Jan 2019 23:44:48 -0800 (PST) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Thu, 17 Jan 2019 23:44:37 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: TLP in recovery-17 draft To: quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000756d78057fb6afdb" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 07:44:55 -0000 --000000000000756d78057fb6afdb Content-Type: text/plain; charset="UTF-8" Hello, I might overlook something, but I cannot find TLP logic in the pseudo codes in the draft. I mean timeout seems to be determined by conventional way. Is this intentional or am I missing something? Thanks, -- Yoshi --000000000000756d78057fb6afdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I might overlook something, but I cannot find T= LP logic in the pseudo codes in the draft. I mean timeout seems to be deter= mined by conventional way.
Is this intentional or am I missing so= mething?

Thanks,
--
Yoshi<= /div>
--000000000000756d78057fb6afdb-- From nobody Thu Jan 17 23:55:58 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78163131159 for ; Thu, 17 Jan 2019 23:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=AYhCu+N2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=s2mL70cE 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 BXRBOlvNZDRL for ; Thu, 17 Jan 2019 23:55:53 -0800 (PST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20395131155 for ; Thu, 17 Jan 2019 23:55:53 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 0789F257FC for ; Fri, 18 Jan 2019 02:55:52 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Fri, 18 Jan 2019 02:55:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=9rUDbwPy5BEK5rDNU6wOCg1rMnGFSFkU6q03zg5 6fdc=; b=AYhCu+N282zeBk2JQESjFPmTgMNXaNOorfj2dsDajCHFRzNqnswh29i baFsRljvctrcEklm+r1Bs64ravqSxAHdxW8kSMF8MajbkYNv7PoN8vqyLt7BvKTh Yxg+7QIHjffQ/+kto+B4Z+n9Cyvgj/o+SB7FNd4MrKRlATBJynRsefD3QVWpYUoS 4xQzu9ZTqORooU8ZPIPJG2sOFdiueaXIN+GabZ7hdP2WaJrI+VFn1QSDbUdFveu6 gZy3d5r8bIpP1EOCHmqw+WohrDOyzcHZIWo6E6vpCd3dKJaIhGJMfR4F6RlekwgU rRqjj57LVYiZGYAqumd20Jkt98JZsZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9rUDbwPy5BEK5rDNU 6wOCg1rMnGFSFkU6q03zg56fdc=; b=s2mL70cEfZdXaRQ1nS5Cqe3vY9VLjOGwY ZCdcRrz05Li0gqgaylGU+7L6rhE8fRYKRfPy1YTJBnbgsdql3htz2lfodRXN2l+R F9kk1rFrfrJ7OAfbiGrX5UqOvx6167j0wSMvskAxvcJD8NiA1Bq+zuFqwm7NG5pO v+BgPEkIrcNgmGSRd6ZhtL/s6gziCo0Tp9OBkO7f3M/R99xXqqS+GKd+FqMPGBjn Fexpmke0aSQ4CM60nhUPvN7Fav9d1wp/hBaEJQPG4xOANK1bAff/RWN+2r1RRfwf Ax2WZguE5QNeFTf+xRkmjq26lNNMPm0+vQH05la+Hni8+DqnSMKeQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeelgdduuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpe dfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvght qeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth enucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A33617C1BA; Fri, 18 Jan 2019 02:55:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-761-gc103c9b-fmstable-20190103v1bis X-Me-Personality: 92534000 Message-Id: <62e20afc-975a-4cae-9cb3-98c557e62b6c@www.fastmail.com> In-Reply-To: References: Date: Fri, 18 Jan 2019 02:55:49 -0500 From: "Martin Thomson" To: quic@ietf.org Subject: Re: TLP in recovery-17 draft Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 07:55:56 -0000 Look for PTO. RTO and TLP were merged into the one concept. Jana can provide all the nasty details. On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote: > Hello, > I might overlook something, but I cannot find TLP logic in the pseudo > codes in the draft. I mean timeout seems to be determined by > conventional way. > Is this intentional or am I missing something? > > Thanks, > -- > Yoshi > From nobody Fri Jan 18 00:19:01 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8F813115C for ; Fri, 18 Jan 2019 00:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 5UFUlXphITfv for ; Fri, 18 Jan 2019 00:18:58 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354A8130F7B for ; Fri, 18 Jan 2019 00:18:58 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gkPMU-00049N-7D for quic@ietf.org; Fri, 18 Jan 2019 09:18:53 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gkPML-0001Uh-Pr for quic@ietf.org; Fri, 18 Jan 2019 03:18:41 -0500 Received: (qmail 4542 invoked from network); 18 Jan 2019 08:18:35 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Jan 2019 08:18:34 -0000 To: Kazuho Oku Cc: Jana Iyengar , Ryan Hamilton , IETF QUIC WG , Martin Thomson , Ian Swett References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <60aaac69-b97d-607d-424f-380fd771ddfb@huitema.net> Date: Thu, 17 Jan 2019 22:18:32 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Key updates X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.30) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5q34xwUQjaD0Y+3aIHD6POt602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViANqZsVrDTpkZPxkj0Z+EWs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBVJlvs1RB82smE8/eMfkvDvvRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFt8i77Wu2Jb/TI0CxS53moc/SlgXpNwUDmiieE9G+9VqfZ1kay mqFCHRp6u+mIhIXg5jssJAnfERZ2C5vj1sOdsnQOD0r6/AaHZiEtdTMtMljoSvSqrGwueTSCQFid cy15jQ4HwbF4aWaRl0axA525ouWBOXp8nHKe0R+FkIqN7hkgzj0zEmu34GPXR572RNl5VgW9/bkt U41htiJ8fk7NkHmplbyYh4+w03es32OzjfSo5Jhwk+hMTKYppuA2BaWeipTPWMHGUquOFNpW9R6n Md9TLrF9l3ItGfA/WrnALV5eJze/hsKQqfFwmUA5avNuZqY0WkD+XXhBRGrlXn3JpbgckPN4/mc8 S7qCNAmuyrlG047RODDSOAU8VRBdjarRhquvBzKEzdsRbaiLpp7t82t4C4SlaCuF6Oqyplz7a94E pv+Z3RfD+aRmwAVlEJHcERWeKKG4PAQYNyavp7c49PtQCCvS5iqCeDclJoZQdZjSGe3okMCcn14J 4XO+5ud/24gMdrp6kF/buZkB2dwY/NZNsli3owudfZOn7yS1D4fRZ4YizZEe9VMcrJA1TtxdruwC 6/RsMQ4p0WvdrKbTQllLoJ8vFTyP4lRS3VvTONeAZkI5yLvz5UdVqJF3okPR15Q6CZxYjafGpi3c b03a4ZFy04e73oo5Jp1iUunX3+VlFawbDxpzYifNwA/+CbHA2fz9gpiGyR7D15JIzS+z7i8K8WY4 szo4Gwow0vwlYMfpTQuMHNi5DO10BOGC1ZJT0NaIcaHtK0XZjSPnTTBX4w== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 08:19:00 -0000 On 1/17/2019 7:38 PM, Kazuho Oku wrote: > 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 13:33 Christian Huitema <= huitema@huitema.net>: >> On 1/17/2019 5:31 PM, Kazuho Oku wrote: >> >> 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 11:06 Jana Iyengar : >> >> It seems to me that the issues, while real, are corner cases, since th= ey require (very) frequent key rotation. As such, I'm tempted to avoid th= ese corner cases rather than provide protocol behaviors to allow them. >> >> Are there good reasons why key rotation might happen very frequently? >> >> I think that is a good question. >> >> I might be concerned about an endpoint that tries to update the key >> whenever it tries to use a new network. An endpoint running on a >> mobile device (that has a Wifi hardware with support for encryption >> offload) might try to install a new key every time the Wifi network >> comes up. >> >> Under such a design, when a Wifi network comes up (triggering a key >> update) and then immediately becomes unreachable, then if another Wifi= >> network becomes reachable, the endpoint might try to install different= >> key twice, if that is permitted by the state of the QUIC connection. >> >> Fine. So maybe we should just say, "don't do that". There is no functi= onal requirement to change the key when the network changes. If the endpo= ints are doing migration, it seems like a really bad idea to try rotate t= he keys at the same time. >> >> The other plausible corner case is a very high speed connection, over = which so many packets are sent so quickly that using the same key might b= e risky. Section 5.5 of RFC 8446 states that the 64 bit Record Sequence N= umber would wrap before that becomes a problem with ChaCha20/Poly1305, bu= t that after sending more than 2^24.5 full-size records (about 24 millio= n) the safety margin of AES-GCM would drop to 2^-57. QUIC is never sendin= g full size records, but the most conservative reading of this paragraph = is that keys should be rotated after sending at most 2^24 packets when us= ing AES-GCM. On a 10 Gbps link, that would last 30 seconds, and that's to= o long to create risks of getting out of sync. It could only be an issue = if the peers were running on a terabit link with a long RTT. Well, if the= y do that, the obvious fix is to use ChaCha20/Poly1305 instead of AES GCM= =2E > Yeah. Practically speaking, I'd assume that you'd need to spend > multiple round-trips to send 2^24 packets due to the size of the > congestion window. > > It might also be worth pointing out that an endpoint cannot send more > than 2^pn_bits packets before seeing an acknowledgement from the peer. > My understanding is that most if not all of the QUIC stacks will use a > 16-bit packet number, and that means that updating the key less > frequently than every 2^16 packets is guaranteed to be safe. I would rather not make any assumption like that. It is fairly simple to use variable length PN encoding. If you have a 19Gbps connection with even moderate latency, you will need more than 16 bits. > > The issue with the current text is that it incorrectly suggests that > the peer updating the key is a signal that it is ready to accept > another key update. If we are going to fix the issue without changing > the wire format, I think we need to state the overarching rule (that > an endpoint MUST NOT initiate a Key Update unless it knows that the > peer has received a packet protected by the current key) as well as > how to determine that. Yes. Tightening the text makes sense. > > For example, something like: > * A sender MUST NOT initiate a Key Update unless it is certain that > the peer has accepted a packet that was encrypted by the current key. Yes. > * One way of testing the condition is to examine the ACK frames sent > by the peer; a packet encrypted using the current key being > acknowledged by the peer can be used as the signal. Yes. > * The other way is to not instantiate a key update until the previous > update until emitting at least 2^pn_bits packets. > * A sender SHOULD NOT initiate a Key Update earlier than 3-PTO after > the previous switch of application traffic key. I would rather have something simpler than these two clauses. Something like: * another way is to not initiate a key update earlier than 3-PTO after the first packet with the new application traffic key was sent. -- Christian Huitema From nobody Fri Jan 18 00:29:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F8F13116B for ; Fri, 18 Jan 2019 00:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qNpQAm3hJ9cw for ; Fri, 18 Jan 2019 00:29:13 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 162B6131168 for ; Fri, 18 Jan 2019 00:29:13 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id k2so10064196iog.7 for ; Fri, 18 Jan 2019 00:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=xn4qf2T6RcEein6BOCYcML56trUwg7mFxR+bNDTpesI=; b=dk5eJIYkbV6mFkY8AccnvoOJk/AG2hPWmjuRUnFV2dBO7mLctv4TOkaJEvL4AQIVJe 6Z6ETJxcAlSi0iZ5+Laz1RRCGhU0JiozsXActgq4frBOQ2KXX3Sophar1WwctpyJDXoa TuAIdGUwyNbHQxjC/YgxlI4ta0C3FeAo4uZ/03mH+LPgY5k+5kYocC7IbLafKFKnr7oG hjhMfN1Q6zbE8EXDAlNfRI20iG2yhH679KPCHz5vuWw35hbF+yFdncdiyA+CUd6OGBpA jcEN/57j8cpmPLe8naIVpRuYJSY2LBmvzeAFRTC0naNGkX8HSa2w0E+JC/6OAQ4wb/d6 w91Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=xn4qf2T6RcEein6BOCYcML56trUwg7mFxR+bNDTpesI=; b=crxlOo6mfuem1Vy8kgVbW+S8cP4aiZdJ0i/G7gNCXdj/YKpGpHEz80vZJsaJD6Yd0m 1t0PFbVDJnnjyh34KSyE4EL1B53u++bImhlFh9uBU94bJVkIpFjfdmmTiZaYlrQ5hdXU k1fhkwXY5rlAxkGDZlJiWAHu6tLCFvR5Q+VEvoVD0D0Up35f+Owe/aWwfyp3PY+/k0JV OVrdf7V8NxAnKjDe8t809MBypMSpJAP7NaHDVeAKcJ2Aqm2wWFZMosvshfNlb4PDvzc2 AZGtEQYWMFEJH6V/BPmJfLTCRxqfPFSkTcy4G01FDHtsG7yrgze/F5DhJgDJbjbWlY+d mUHw== X-Gm-Message-State: AJcUukfkKwMtdkPz53WLLVf8AzGaqUt+rMnmb2+dMMDX2Enld13eA3Kn saP+xSplZFDVGwmnNoE03yZ6F4a2frJAzsaTKf0= X-Google-Smtp-Source: ALg8bN7QI+gtO0rgXBJRDWVhoY0MTx0XL2WRw82JWtm0Vgh1xo3scyHEs+niIZzzubxFYDgPbTX9uUnf+8xEK1CTQco= X-Received: by 2002:a6b:f017:: with SMTP id w23mr9000637ioc.12.1547800152375; Fri, 18 Jan 2019 00:29:12 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 18 Jan 2019 00:29:11 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <60aaac69-b97d-607d-424f-380fd771ddfb@huitema.net> References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> <60aaac69-b97d-607d-424f-380fd771ddfb@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 18 Jan 2019 00:29:11 -0800 Message-ID: Subject: Re: Key updates To: Christian Huitema , Kazuho Oku Cc: Jana Iyengar , IETF QUIC WG , Martin Thomson , Ian Swett , Ryan Hamilton Content-Type: multipart/alternative; boundary="000000000000440657057fb74e52" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 08:29:15 -0000 --000000000000440657057fb74e52 Content-Type: text/plain; charset="UTF-8" On 18 January 2019 at 09.19.17, Christian Huitema (huitema@huitema.net) wrote: I would rather have something simpler than these two clauses. Something like: * another way is to not initiate a key update earlier than 3-PTO after the first packet with the new application traffic key was sent. How about just requiring an acknowledgment received for at least one packet with a given key phase before allowing a new key update. And just a single key phase bit. Yes, it requires some coordination between crypto layer and ACK processor, but can anyone seriously argue that would be difficult, especially compared to all the other complexity, including timer estimates. The information only transferred asynchronously, so the coordination is quite loose. --000000000000440657057fb74e52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 18 January 2019 a= t 09.19.17, Christian Huitema (huite= ma@huitema.net) wrote:
I would rather have something simpler than these= two clauses. Something=C2=A0<= /span>
like:=C2=A0

* another way is to not initiate a key update earlier than 3-PTO af= ter=C2=A0
the first packet with the new applicati= on traffic key was sent.=C2=A0=


How about just requiri= ng an acknowledgment received for at least one packet with a given key phas= e before allowing a new key update.

And just a single key phase bit.<= /p>

Yes, it requires some coordination between crypto layer and ACK proce= ssor, but can anyone seriously argue that would be difficult, especially co= mpared to all the other complexity, including timer estimates. The informat= ion only transferred asynchronously, so the coordination is quite loose. --000000000000440657057fb74e52-- From nobody Fri Jan 18 03:21:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B251A131196 for ; Fri, 18 Jan 2019 03:21:36 -0800 (PST) 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=unavailable 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 fGdeg7A0LXRd for ; Fri, 18 Jan 2019 03:21:34 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 E3A32131184 for ; Fri, 18 Jan 2019 03:21:33 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id l10so10205065lfh.9 for ; Fri, 18 Jan 2019 03:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rDMHOlRSYVt4+flGv45BpFEByENJDnMJ0cKybUogKMw=; b=LzsaBFW1HVd8l47LrnIkiHvj8GijnrDQUYhBdca6vKI1iYSFE57ASHRri/vr6ChOTw guI6enOHIbXA7wmxWJ58gN+vEewROqvAaItVWv+QLk8vQCpA/HLo13xSnDrXk83bHutx YWniaG7LjdGcwGdDN/cZDbiLf5AvUkIbBUrUSiFPwy75GMSf7SAT2e92z9RIN4CDmhb0 jMpzx/XGchq84dI/bGbzYo66Mz+UFEr7VrJbZ3Zxhnp65ndY/L1TVXb5FxdMzV2MXEDO EwiI3HTzFVZyEQHSdV/Euez9PNM5tiNeE4HDeg/nHRN4r9zx0MWSsfSU9BCCgFrWhbNy FP7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rDMHOlRSYVt4+flGv45BpFEByENJDnMJ0cKybUogKMw=; b=Ce7ptu35017T+ws8xl3laOnKja3UBwcfH1wMnX+R2hC7AT9SYgl+i5MSwfS4g30kwX o+/xze86+erzIjQXD1AVW3tXTZvulRpeaKTdajAqQJUwGNgRzqI6/e3yejqozR/UeXZO CVU0Oc/jfrVzahUg1wPHCWHH1dhRXZAPJPyVQ3TIJ4hZv92dxOwpp73IW4bgm/tiBZeI QCzzGIFNHAVGWpAQ5dj+Q6BB7egLJS5tLFd0zC3dbz72tztlNAyEFfIM0F+uzpBwEDYd 752XRn2uUVJiXoBBe8F6aITTrVKVFF+8G581/6gfde/XZMHJWdaO5h6McD1llPhwgvU+ ZnBQ== X-Gm-Message-State: AJcUukeRGN/vaf4uRl+VUENYUJuTVS0f4BfD4SMXYadmsuEu01qtVt+r 3cR+2X7YrOW2JMCXc0L5obD8JhvmmQuxwE2Ss5w= X-Google-Smtp-Source: ALg8bN5Wo5gWYN2C3T2C7p3q7YwAduiZS6/12qFUXx1JdbEPjjdFYq8y0ymYobnuSXUeYnF1qYE5IjoawS4YtSpX/NQ= X-Received: by 2002:a19:ced3:: with SMTP id e202mr12339068lfg.13.1547810492005; Fri, 18 Jan 2019 03:21:32 -0800 (PST) MIME-Version: 1.0 References: <1546999594.830451.1629402512.3F3144A0@webmail.messagingengine.com> <9D2F8E4C-9C9E-43B5-8FB6-D34ACD46D03E@huitema.net> <1547072001.3791147.1630300096.224D142E@webmail.messagingengine.com> <1547075808.435595.1630360600.27FFE6F1@webmail.messagingengine.com> <60aaac69-b97d-607d-424f-380fd771ddfb@huitema.net> In-Reply-To: <60aaac69-b97d-607d-424f-380fd771ddfb@huitema.net> From: Kazuho Oku Date: Fri, 18 Jan 2019 20:21:21 +0900 Message-ID: Subject: Re: Key updates To: Christian Huitema Cc: Jana Iyengar , IETF QUIC WG , Ian Swett , Martin Thomson , Ryan Hamilton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 11:21:37 -0000 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 17:19 Christian Huitema : > > > On 1/17/2019 7:38 PM, Kazuho Oku wrote: > > 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 13:33 Christian Huitema <= huitema@huitema.net>: > >> On 1/17/2019 5:31 PM, Kazuho Oku wrote: > >> > >> 2019=E5=B9=B41=E6=9C=8818=E6=97=A5(=E9=87=91) 11:06 Jana Iyengar : > >> > >> It seems to me that the issues, while real, are corner cases, since th= ey require (very) frequent key rotation. As such, I'm tempted to avoid thes= e corner cases rather than provide protocol behaviors to allow them. > >> > >> Are there good reasons why key rotation might happen very frequently? > >> > >> I think that is a good question. > >> > >> I might be concerned about an endpoint that tries to update the key > >> whenever it tries to use a new network. An endpoint running on a > >> mobile device (that has a Wifi hardware with support for encryption > >> offload) might try to install a new key every time the Wifi network > >> comes up. > >> > >> Under such a design, when a Wifi network comes up (triggering a key > >> update) and then immediately becomes unreachable, then if another Wifi > >> network becomes reachable, the endpoint might try to install different > >> key twice, if that is permitted by the state of the QUIC connection. > >> > >> Fine. So maybe we should just say, "don't do that". There is no functi= onal requirement to change the key when the network changes. If the endpoin= ts are doing migration, it seems like a really bad idea to try rotate the k= eys at the same time. > >> > >> The other plausible corner case is a very high speed connection, over = which so many packets are sent so quickly that using the same key might be = risky. Section 5.5 of RFC 8446 states that the 64 bit Record Sequence Numbe= r would wrap before that becomes a problem with ChaCha20/Poly1305, but that= after sending more than 2^24.5 full-size records (about 24 million) the s= afety margin of AES-GCM would drop to 2^-57. QUIC is never sending full siz= e records, but the most conservative reading of this paragraph is that keys= should be rotated after sending at most 2^24 packets when using AES-GCM. O= n a 10 Gbps link, that would last 30 seconds, and that's too long to create= risks of getting out of sync. It could only be an issue if the peers were = running on a terabit link with a long RTT. Well, if they do that, the obvio= us fix is to use ChaCha20/Poly1305 instead of AES GCM. > > Yeah. Practically speaking, I'd assume that you'd need to spend > > multiple round-trips to send 2^24 packets due to the size of the > > congestion window. > > > > It might also be worth pointing out that an endpoint cannot send more > > than 2^pn_bits packets before seeing an acknowledgement from the peer. > > My understanding is that most if not all of the QUIC stacks will use a > > 16-bit packet number, and that means that updating the key less > > frequently than every 2^16 packets is guaranteed to be safe. > > I would rather not make any assumption like that. It is fairly simple to > use variable length PN encoding. If you have a 19Gbps connection with > even moderate latency, you will need more than 16 bits. > > > > > The issue with the current text is that it incorrectly suggests that > > the peer updating the key is a signal that it is ready to accept > > another key update. If we are going to fix the issue without changing > > the wire format, I think we need to state the overarching rule (that > > an endpoint MUST NOT initiate a Key Update unless it knows that the > > peer has received a packet protected by the current key) as well as > > how to determine that. > > Yes. Tightening the text makes sense. > > > > > > For example, something like: > > * A sender MUST NOT initiate a Key Update unless it is certain that > > the peer has accepted a packet that was encrypted by the current key. > Yes. > > * One way of testing the condition is to examine the ACK frames sent > > by the peer; a packet encrypted using the current key being > > acknowledged by the peer can be used as the signal. > Yes. > > * The other way is to not instantiate a key update until the previous > > update until emitting at least 2^pn_bits packets. > > * A sender SHOULD NOT initiate a Key Update earlier than 3-PTO after > > the previous switch of application traffic key. > > I would rather have something simpler than these two clauses. Something > like: > > * another way is to not initiate a key update earlier than 3-PTO after > the first packet with the new application traffic key was sent. I'm not sure if just having the 3-PTO rule is a good way, because it is possible to have an interval more than 3-PTO between packet emissions when network change is involved, an event that might coincide with key updates. Consider the following example: a client receives a key update, responds to it with it's key update as it loses the connectivity to the mobile network. Because the network condition was bad, the responding packet never reaches the network (and the server). After a small amount of time (but longer than 3-PTO), the client reconnects to Wifi, and sends a new packet. Because it offloads encryption to hardware, it tries to use a new encryption key whenever possible. In this example, 3-PTO rule does not prevent the client doing another key update. I share the view with Martin that we have so far avoided using ACK as way of signaling a change of state of an endpoint. Assuming that we need to retain the design pattern, we need to describe a method other than that uses an ACK. The reason I suggested using of number of packets (being greater than 2^pn_bits) is because it can be used as such a signal, at least for certain endpoints. If we are unhappy with that, we need to look for a different method, however as I have stated, I do not think a time-based approach works. PS. OTOH, I think having a 3-PTO rule is good for forbidding too-frequent updates that lead to loss of packets (because the receiver might have a limit on the number of decryption keys being active). > > -- Christian Huitema > > > > --=20 Kazuho Oku From nobody Sat Jan 19 04:13:29 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D4812F19D for ; Sat, 19 Jan 2019 04:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 nWIV-WaGJWzB for ; Sat, 19 Jan 2019 04:13:26 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AEF2128CF3 for ; Sat, 19 Jan 2019 04:13:25 -0800 (PST) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2FA92278388 for ; Sat, 19 Jan 2019 21:13:23 +0900 (JST) Received: by mail-wr1-f54.google.com with SMTP id r10so18097826wrs.10 for ; Sat, 19 Jan 2019 04:13:23 -0800 (PST) X-Gm-Message-State: AJcUukf69m0qjauH5qSgjeHLWu10iVDs382J4pKNp91j533Yc+AY/qe8 8nAGYLTbrukcBJ0s/pOQV/LQQpEpilekD/q+J3E= X-Google-Smtp-Source: ALg8bN6ULyRSJB2S/1hTBZj9fFcNcOwH/+udhEwCRfJesTy+3x8d3HqAoyOJalat11RvZqSfcbSI0t46rGO8yrmlbx0= X-Received: by 2002:a5d:45d0:: with SMTP id b16mr6665637wrs.86.1547899999864; Sat, 19 Jan 2019 04:13:19 -0800 (PST) MIME-Version: 1.0 References: <62e20afc-975a-4cae-9cb3-98c557e62b6c@www.fastmail.com> In-Reply-To: <62e20afc-975a-4cae-9cb3-98c557e62b6c@www.fastmail.com> From: Yoshifumi Nishida Date: Sat, 19 Jan 2019 04:13:08 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: TLP in recovery-17 draft To: Martin Thomson Cc: quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000a3d694057fce8dca" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 12:13:28 -0000 --000000000000a3d694057fce8dca Content-Type: text/plain; charset="UTF-8" Yep, I think I'm aware of the merging. The code looks cleaner and simpler. But, it seems to me that this code will react slowly in tail loss situations.. It would be great if someone could clarify. -- Yoshi On Thu, Jan 17, 2019 at 11:55 PM Martin Thomson wrote: > Look for PTO. RTO and TLP were merged into the one concept. Jana can > provide all the nasty details. > > On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote: > > Hello, > > I might overlook something, but I cannot find TLP logic in the pseudo > > codes in the draft. I mean timeout seems to be determined by > > conventional way. > > Is this intentional or am I missing something? > > > > Thanks, > > -- > > Yoshi > > > > --000000000000a3d694057fce8dca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Yep, I think I'm aware= of the merging. The code looks cleaner and simpler.
But, it seem= s to me that this code will react slowly in tail loss situations.. It would= be great if someone could clarify.
--
Yoshi

<= div class=3D"gmail_quote">
On Thu, Jan 17, 2019 at 11:55 PM= Martin Thomson <= mt@lowentropy.net> wrote:
Look for PTO. RTO and TLP were merged into the one concept= . Jana can provide all the nasty details.

On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote:
> Hello,
> I might overlook something, but I cannot find TLP logic in the pseudo =
> codes in the draft. I mean timeout seems to be determined by
> conventional way.
> Is this intentional or am I missing something?
>
> Thanks,
> --
> Yoshi
>

--000000000000a3d694057fce8dca-- From nobody Sat Jan 19 05:57:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1451274D0 for ; Sat, 19 Jan 2019 05:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 DvopLM_gAVlf for ; Sat, 19 Jan 2019 05:57:17 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 F2A7A1200B3 for ; Sat, 19 Jan 2019 05:57:16 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id r24so2922405wmh.0 for ; Sat, 19 Jan 2019 05:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TWNjAi9uU1mWpl4bqiWwFm8m07CUt1gmA/4KMAPFpZw=; b=W9Y/S83wbbNYFE23lppLeRUpiz4jBxLSYgML7RJ8m8bdvKeuFGogMiYcWmZvqVkr7h kw84/1hbkdCrvGIWj47fBP0xhcmScW6pvXAwlw/BrNV0nilIKF6vELvmjMfYSVvcp8mv 5wX8mpso04TYteFP2zz+mpaoWatah3+7NS0au/H+00beZ+9Xzb1V5sP5eecpPb/qhHQf OjNUgMC2redCORDVez2ybizBXEloc6YUiRHQSCg+C17Wnkbsn5HN29V1kQAJqB1/I56T CwdGlHyN7MQ6OE6CarhF8OO4p4VWbQcsoSjPi78aB59HYeSEnzHi+Pqzsiaqkw3FrrlO RgWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TWNjAi9uU1mWpl4bqiWwFm8m07CUt1gmA/4KMAPFpZw=; b=ILeX1NUyB+WGOWNkr14Yno/Tw4gCJvlXp2NSwLCPQEXKEd+hOWKTW5/27BnOmzXPbZ KcxrjnghvrOJ1xnQV1PZ73yrVV2PArR/Ze/xSs2MCPsSNqDMNFdoZQZhNsCodBlNRjxn A5sczwuQVQad8RjTs6fPYCsW8mxX4f/h7ZUbG2p/sQPv+4G689kTPuaAwrJeMM6R2TlF x08JM5uNztMsdYOMg0UNghNrduIpzbuy2xk1T1KesFNp9lAQmWmCT/tyi7M45h4YQ6Wt hFFYlYmU2xi84o3wuyVacXLxJp0CrFdepAK60sTVsaraXWbaHCsqldROlX8Bu9wNTkHQ N5Ow== X-Gm-Message-State: AJcUukfHrZbLWFFV0mVtw13uk+UttgQW2glMNbMPlit5prhmHPJ4oh0W aj9ZK8Q/Jxs941CrJniGi5Gvc1pcL0GtKIRwX35SL26KRtrfSQ== X-Google-Smtp-Source: ALg8bN6Wzd1aLCwm3Cc4sCxX1PR3tTfIKR/cuBHofSg4dW+s3YRKP6Rf7ii79Eq1IAuFIz4Cy+W0W0+qYSaIkQGv4+s= X-Received: by 2002:a1c:7d54:: with SMTP id y81mr18784596wmc.106.1547906234913; Sat, 19 Jan 2019 05:57:14 -0800 (PST) MIME-Version: 1.0 References: <62e20afc-975a-4cae-9cb3-98c557e62b6c@www.fastmail.com> In-Reply-To: From: Ian Swett Date: Sat, 19 Jan 2019 08:57:01 -0500 Message-ID: Subject: Re: TLP in recovery-17 draft To: Yoshifumi Nishida Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000047b0b1057fd00118" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 13:57:20 -0000 --00000000000047b0b1057fd00118 Content-Type: text/plain; charset="UTF-8" Can you clarify what you mean by slowly? Are you concerned the first PTO timeout will be substantially longer than what the first TLP was? If so, I believe that should be mostly mitigated by moving from a fixed min RTO to one that includes the explicitly communicated max ack delay, along the lines of the TCP MAD proposal( https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00). In cases when the rtt variance is large, PTO will definitely be longer than TLP was, but I think that's a feature, since it recognizes that sometimes TLP is too aggressive in those cases. On Sat, Jan 19, 2019 at 7:13 AM Yoshifumi Nishida wrote: > > Yep, I think I'm aware of the merging. The code looks cleaner and simpler. > But, it seems to me that this code will react slowly in tail loss > situations.. It would be great if someone could clarify. > -- > Yoshi > > On Thu, Jan 17, 2019 at 11:55 PM Martin Thomson wrote: > >> Look for PTO. RTO and TLP were merged into the one concept.. Jana can >> provide all the nasty details. >> >> On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote: >> > Hello, >> > I might overlook something, but I cannot find TLP logic in the pseudo >> > codes in the draft. I mean timeout seems to be determined by >> > conventional way. >> > Is this intentional or am I missing something? >> > >> > Thanks, >> > -- >> > Yoshi >> > >> >> --00000000000047b0b1057fd00118 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you clarify what you mean by slowly?<= /div>

Are you concerned the firs= t PTO timeout will be substantially longer than what the first TLP was?=C2= =A0 If so, I believe that should be mostly mitigated by moving from a fixed= min RTO to one that includes the explicitly communicated max ack delay, al= ong the lines of the TCP MAD proposal(https://tools.ietf.org/html/draft-wan= g-tcpm-low-latency-opt-00).

In cas= es when the rtt variance is large, PTO will definitely be longer than TLP w= as, but I think that's a feature, since it recognizes that sometimes TL= P is too aggressive in those cases.

On Sat, Jan 19, 2019 at 7:13 AM Yo= shifumi Nishida <nishida@sfc.w= ide.ad.jp> wrote:

Yep, I think I&= #39;m aware of the merging. The code looks cleaner and simpler.
B= ut, it seems to me that this code will react slowly in tail loss situations= .. It would be great if someone could clarify.
--
Yoshi=

On Thu, Jan 17, 2019 = at 11:55 PM Martin Thomson <mt@lowentropy.net> wrote:
Look for PTO. RTO and TLP were merged into the= one concept.. Jana can provide all the nasty details.

On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote:
> Hello,
> I might overlook something, but I cannot find TLP logic in the pseudo =
> codes in the draft. I mean timeout seems to be determined by
> conventional way.
> Is this intentional or am I missing something?
>
> Thanks,
> --
> Yoshi
>

--00000000000047b0b1057fd00118-- From nobody Sat Jan 19 14:02:05 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E09C130E97 for ; Sat, 19 Jan 2019 14:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4fIU42vvhnTB for ; Sat, 19 Jan 2019 14:02:02 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A43130E67 for ; Sat, 19 Jan 2019 14:02:01 -0800 (PST) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9575B278315 for ; Sun, 20 Jan 2019 07:01:59 +0900 (JST) Received: by mail-wm1-f51.google.com with SMTP id p6so7560370wmc.1 for ; Sat, 19 Jan 2019 14:01:59 -0800 (PST) X-Gm-Message-State: AJcUukfZESTxhhI0jE5B/hwjj9Vr2BxjiHygV8TNKiYA6EJm5cb597Lq mGqQVoLgREjKUfmCDmvSZTsQRnl1ZEiH9eHqRto= X-Google-Smtp-Source: ALg8bN6TYKLYFJd+PS6VdU7W741/QLWdSg/KUEPef9UO8kQLkLsuPPAUsOW4A/tgbWKMPGwjfRvwOpaOXxKy4kxoN68= X-Received: by 2002:a1c:dc86:: with SMTP id t128mr20909497wmg.42.1547935317530; Sat, 19 Jan 2019 14:01:57 -0800 (PST) MIME-Version: 1.0 References: <62e20afc-975a-4cae-9cb3-98c557e62b6c@www.fastmail.com> In-Reply-To: From: Yoshifumi Nishida Date: Sat, 19 Jan 2019 14:01:46 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: TLP in recovery-17 draft To: Ian Swett Cc: Yoshifumi Nishida , Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000bc9e4d057fd6c61b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 22:02:04 -0000 --000000000000bc9e4d057fd6c61b Content-Type: text/plain; charset="UTF-8" Hi Ian, Thanks for the response. Yes, that was my point. But, I think I got it now. In the previous draft, kMinRTOTimeout was 200ms and kMinTLPTimeout was 10ms, but now only lower bound is kGgranularity and it's 1ms. So, new PTO can be smaller than the previous version of RTO unless there's no large variation in RTT samplings. -- Yoshi On Sat, Jan 19, 2019 at 5:57 AM Ian Swett wrote: > Can you clarify what you mean by slowly? > > Are you concerned the first PTO timeout will be substantially longer than > what the first TLP was? If so, I believe that should be mostly mitigated > by moving from a fixed min RTO to one that includes the explicitly > communicated max ack delay, along the lines of the TCP MAD proposal( > https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00). > > In cases when the rtt variance is large, PTO will definitely be longer > than TLP was, but I think that's a feature, since it recognizes that > sometimes TLP is too aggressive in those cases. > > On Sat, Jan 19, 2019 at 7:13 AM Yoshifumi Nishida > wrote: > >> >> Yep, I think I'm aware of the merging. The code looks cleaner and simpler. >> But, it seems to me that this code will react slowly in tail loss >> situations.. It would be great if someone could clarify. >> -- >> Yoshi >> >> On Thu, Jan 17, 2019 at 11:55 PM Martin Thomson >> wrote: >> >>> Look for PTO. RTO and TLP were merged into the one concept.. Jana can >>> provide all the nasty details. >>> >>> On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote: >>> > Hello, >>> > I might overlook something, but I cannot find TLP logic in the pseudo >>> > codes in the draft. I mean timeout seems to be determined by >>> > conventional way. >>> > Is this intentional or am I missing something? >>> > >>> > Thanks, >>> > -- >>> > Yoshi >>> > >>> >>> --000000000000bc9e4d057fd6c61b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi= Ian,

Thanks for the response. Yes, that was my po= int.
But, I think I got it now.
In the p= revious draft, kMinRTOTimeout was 200ms and kMinTLPTimeout was 10ms, but no= w only lower bound is kGgranularity and it's 1ms.
So, new PTO= can be smaller than the previous version of RTO unless there's no larg= e variation in RTT samplings.
--
Yoshi

On Sat, Jan 19, 2019 at 5:57 AM Ian Swett <ianswett@google.com> wrote:
Can yo= u clarify what you mean by slowly?

Are you concerned the first PTO timeout will be substantially long= er than what the first TLP was?=C2=A0 If so, I believe that should be mostl= y mitigated by moving from a fixed min RTO to one that includes the explici= tly communicated max ack delay, along the lines of the TCP MAD proposal(https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-= 00).

In cases when the rtt varianc= e is large, PTO will definitely be longer than TLP was, but I think that= 9;s a feature, since it recognizes that sometimes TLP is too aggressive in = those cases.

On Sat, Jan 19, 2019 at 7:13 = AM Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:

Yep, I think I'm aware of the merging. The code looks cleaner a= nd simpler.
But, it seems to me that this code will react slowly = in tail loss situations.. It would be great if someone could clarify.
=
--
Yoshi

On Thu, Jan 17, 2019 at 11:55 PM Martin Thomson <mt@lowentropy.net> wrote:
Look for PTO. RTO and TL= P were merged into the one concept.. Jana can provide all the nasty details= .

On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote:
> Hello,
> I might overlook something, but I cannot find TLP logic in the pseudo =
> codes in the draft. I mean timeout seems to be determined by
> conventional way.
> Is this intentional or am I missing something?
>
> Thanks,
> --
> Yoshi
>

--000000000000bc9e4d057fd6c61b-- From nobody Sat Jan 19 16:45:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B4C130EBA for ; Sat, 19 Jan 2019 16:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=1DLgfR1/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SX+3hz5l 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 ID6wgUw7QtIV for ; Sat, 19 Jan 2019 16:45:24 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522C8130EB9 for ; Sat, 19 Jan 2019 16:45:24 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0347527CF3 for ; Sat, 19 Jan 2019 19:45:22 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 19 Jan 2019 19:45:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=smq4g2EF2mTgum5i3Q1WIKYBRkpm/NX5jB7XQ/6smAw=; b=1DLgfR1/ zKkBwsyt0uiRWhCZBW6xB+UPfpF06yQK/x/dh3kroEW69/r7Y0DOT8NTZr/Lo1Wx SD5eSvfk5ENb3JU+HiyWV6RkbzM9aZBeizBfm7qY7LoYmMRtqmIlyJhOtRuc/RrN XAsft0Dklzzm00usL+EgR9xL2JPpWX5phrMqlwAn+qDnYyKtuHl/kcBu0mB+YfEX 00I5R/Dg9ouomoE1KKj1T4WGwhqNo4Sp7GbQxTG75Vt3ob5Ly3RnPBox4flOedp3 JBEREtBrue/lmVOeCNjAC6605oAkUHTVSgDk/vWvOwPVYKhvVcxgC0r4tcXnisxr F5LZij30aiGekA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=smq4g2EF2mTgum5i3Q1WIKYBRkpm/ NX5jB7XQ/6smAw=; b=SX+3hz5lbU1OJ/C5jX/bqseSPAH8RH+7dQPhd22/bfzYW yB17V6lig2V3F76BH/aTtQ2uwHwJcrchJKddsVsDMPvMgVg2qNNnATU6EKFapk41 8l5GPXgFUcS0rtOJV4BBqwXYyEJcVNpDKQVumrYXcXEySe5xpXtzSlS3kg7tnrKf LNzRY3A1xK2A5CkYCRW5/E6AfaWmqqPPCO3g2xlVp3aZ092+CoBj3rWJEtfNx5Ll n3zfbhGthW0k9F8uOFdSwV7PEWUbfXCU383BVURKxJQ97mHIM5y9otKIZs4ZbqPN NApEQkOegRf6s2cVN9Zm9NHozNLCdsrYApsAx3Iow== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrheefgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpefiihhthhhusg gppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhn vghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeduudelrdelrdegfe drvdegudenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehm nhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id AFE12100BA for ; Sat, 19 Jan 2019 19:45:19 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 9B46DC02BF for ; Sun, 20 Jan 2019 00:45:16 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============7125053395669228573==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190120004516.9B46DC02BF@cloud.mnot.net> Date: Sun, 20 Jan 2019 00:45:16 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2019 00:45:29 -0000 --===============7125053395669228573== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+11/-7/=F0=9F=92=AC90) 11 issues created: - MAX_STREAM_DATA risk unbounded state (by mikkelfj) https://github.com/quicwg/base-drafts/issues/2353 = - Indicate which frames go on which stream types (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2351 [-http] [editorial] = - Specify IPv6 flow label for QUIC (by huitema) https://github.com/quicwg/base-drafts/issues/2348 = - nothing can be sent when receiving a packet just after the idle close t= imer expires (by kazuho) https://github.com/quicwg/base-drafts/issues/2347 = - STOP_SENDING on implicitly opened streams is error-prone (by Ralith) https://github.com/quicwg/base-drafts/issues/2345 = - RESET_STREAM should be allowed in 0-RTT packets (by kazuho) https://github.com/quicwg/base-drafts/issues/2344 = - Spoofed connection migration as a DoS vector (by igorlord) https://github.com/quicwg/base-drafts/issues/2342 = - QPACK: instructions and stream description is suboptimal (by LPardue) https://github.com/quicwg/base-drafts/issues/2339 = - HTTP/3: Push stream description diagram is ambiguous (by LPardue) https://github.com/quicwg/base-drafts/issues/2338 = - HTTP/3: is the recommended size of max bidi streams normative? (by LPar= due) https://github.com/quicwg/base-drafts/issues/2337 = - Invariants: Unclarity in short headers (by gloinul) https://github.com/quicwg/base-drafts/issues/2335 = 22 issues received 90 new comments: - #2299 consider making the varint encoding unique (15 by marten-seemann,= janaiyengar, mikkelfj, nibanks, larseggert, DavidSchinazi, martinthomson, = ianswett) https://github.com/quicwg/base-drafts/issues/2299 [-transport] [design] = - #2344 RESET_STREAM should be allowed in 0-RTT packets (14 by kazuho, ma= rten-seemann, mikkelfj, Ralith, siyengar, nibanks, MikeBishop) https://github.com/quicwg/base-drafts/issues/2344 = - #2345 STOP_SENDING on implicitly opened streams is error-prone (10 by R= alith, kazuho, MikeBishop, marten-seemann, mikkelfj) https://github.com/quicwg/base-drafts/issues/2345 = - #2135 How many datagrams can a client send prior to validating the path= ? (9 by kazuho, mikkelfj, ianswett) https://github.com/quicwg/base-drafts/issues/2135 [-transport] [design] = - #2267 loss of only two packets can lead to an unrecoverable situation (= 8 by DavidSchinazi, kazuho, huitema, ianswett) https://github.com/quicwg/base-drafts/issues/2267 [-transport] [design] = - #2335 Invariants: Unclarity in short headers (4 by gloinul, martinthoms= on, mikkelfj) https://github.com/quicwg/base-drafts/issues/2335 [-invariants] [editor= ial] = - #2255 persistent congestion is more aggressive than RTO verified (4 by = martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/2255 [-recovery] = - #2339 QPACK: instructions and stream description is suboptimal (3 by LP= ardue, afrind) https://github.com/quicwg/base-drafts/issues/2339 = - #2103 Guidelines for Retransmitting Lost Data (3 by martinduke, ianswet= t) https://github.com/quicwg/base-drafts/issues/2103 [-recovery] = - #2067 Samples for RTT estimation (2 by goelvidhi, martinthomson) https://github.com/quicwg/base-drafts/issues/2067 [-recovery] [design] = - #1966 Spurious RTO detection (2 by janaiyengar, ianswett) https://github.com/quicwg/base-drafts/issues/1966 [-recovery] [design] = - #2348 Specify IPv6 flow label for QUIC (2 by becarpenter, britram) https://github.com/quicwg/base-drafts/issues/2348 = - #2351 Indicate which frames go on which stream types (2 by LPardue, Mik= eBishop) https://github.com/quicwg/base-drafts/issues/2351 [-http] [editorial] = - #2353 MAX_STREAM_DATA risk unbounded state (2 by marten-seemann, mikkel= fj) https://github.com/quicwg/base-drafts/issues/2353 = - #1986 Consider dynamic hybrid between time-based and packet-based loss = detection (2 by janaiyengar, ianswett) https://github.com/quicwg/base-drafts/issues/1986 [-recovery] [design] = - #2149 What resets idle timeout? (2 by Ralith, martinthomson) https://github.com/quicwg/base-drafts/issues/2149 [-transport] [editori= al] = - #1940 Why are error codes not a varint? (1 by nibanks) https://github.com/quicwg/base-drafts/issues/1940 [-transport] [design] = - #2337 HTTP/3: is the recommended size of max bidi streams normative? (1= by MikeBishop) https://github.com/quicwg/base-drafts/issues/2337 [-http] [editorial] = - #2338 HTTP/3: Push stream description diagram is ambiguous (1 by MikeBi= shop) https://github.com/quicwg/base-drafts/issues/2338 [-http] [editorial] = - #1987 Clarify 1200 bytes Initial packet rule (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1987 [-transport] [editori= al] = - #2259 amplification attack using Retry and VN triggered by coalesced In= itial packets (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2259 [-transport] [design] = - #1904 Alternative largest reference algorithm (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1904 [-qpack] [editorial] = 7 issues closed: - Complete version negotiation failure https://github.com/quicwg/base-dra= fts/issues/1917 [-transport] [editorial] = - Clarify 1200 bytes Initial packet rule https://github.com/quicwg/base-d= rafts/issues/1987 [-transport] [editorial] = - HTTP Errors aren't consistent https://github.com/quicwg/base-drafts/iss= ues/2231 [-http] [design] = - What should the receiver do when the peer closes a unidirectional strea= m before providing the stream type? https://github.com/quicwg/base-drafts/i= ssues/2331 [-http] [editorial] = - amplification attack using Retry and VN triggered by coalesced Initial = packets https://github.com/quicwg/base-drafts/issues/2259 [-transport] [des= ign] = - Echoing HTTP_REQUEST_CANCELLED from STOP_SENDING has unintended semanti= cs https://github.com/quicwg/base-drafts/issues/2106 [-http] [design] [yaec= !] = - Section 4.2.6 PUSH_PROMISE does not indicate on which stream type this = frame is allowed https://github.com/quicwg/base-drafts/issues/1920 [-http] = [editorial] = Pull requests ------------- * quicwg/base-drafts (+8/-7/=F0=9F=92=AC32) 8 pull requests submitted: - allow STOP_SENDING on implicitly opened streams (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2352 = - No common versions means fail (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2350 [-transport] [editorial= ] = - Correcting polarity of SPA language (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2349 [-transport] [design] [= editorial] = - Rework idle timeout definition (by martinthomson) https://github.com/quicwg/base-drafts/pull/2346 = - GOAWAY on wrong stream is WRONG_STREAM (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2343 [-http] [design] = - clarify that INITCWND caps amount of data sent to a client before addre= ss validation (by kazuho) https://github.com/quicwg/base-drafts/pull/2341 = - Add note about frequent RTT estimates (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2340 = - editorial: make the frame type example consistent (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2336 = 10 pull requests received 32 new comments: - #2352 allow STOP_SENDING on implicitly opened streams (14 by Ralith, ma= rten-seemann, mikkelfj) https://github.com/quicwg/base-drafts/pull/2352 = - #2341 clarify that INITCWND caps amount of data sent to a server before= address validation (5 by kazuho, marten-seemann, martinthomson) https://github.com/quicwg/base-drafts/pull/2341 = - #2025 Send an immediate ACK (3 by martinduke, ianswett) https://github.com/quicwg/base-drafts/pull/2025 [-recovery] = - #2307 allow PING frames in Initial and Handshake packets (2 by martinth= omson, mikkelfj) https://github.com/quicwg/base-drafts/pull/2307 = - #2296 Allow servers to send a preferred address of each address family = (2 by DavidSchinazi, janaiyengar) https://github.com/quicwg/base-drafts/pull/2296 [-transport] [design] = - #2303 One Retry/VN per UDP datagram (2 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2303 [-transport] [design] = - #2313 Proposal to make Version Negotiation more like Retry to punt VN t= o QUICv2 (1 by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/2313 [-invariants] [-transpo= rt] [design] = - #2340 Add note about frequent RTT estimates (1 by erickinnear) https://github.com/quicwg/base-drafts/pull/2340 [-recovery] [editorial] = - #2350 No common versions means fail (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/2350 [-transport] [editorial= ] = - #2281 Include handshake anti-deadlock logic in pseudocode (1 by Ralith) https://github.com/quicwg/base-drafts/pull/2281 [-recovery] = 7 pull requests merged: - No common versions means fail https://github.com/quicwg/base-drafts/pull/2350 [-transport] [editorial= ] = - GOAWAY on wrong stream is WRONG_STREAM https://github.com/quicwg/base-drafts/pull/2343 [-http] [design] = - extended unidirectional streams can be closed or reset https://github.com/quicwg/base-drafts/pull/2332 [-http] [editorial] = - editorial: make the frame type example consistent https://github.com/quicwg/base-drafts/pull/2336 [-transport] [editorial= ] = - One Retry/VN per UDP datagram https://github.com/quicwg/base-drafts/pull/2303 [-transport] [design] = - Introduce HTTP_REQUEST_REJECTED https://github.com/quicwg/base-drafts/pull/2325 [-http] [design] [yaec!= ] = - Restrict PUSH_PROMISE to request streams https://github.com/quicwg/base-drafts/pull/2323 [-http] [editorial] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============7125053395669228573== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday January 20, 2019

Issues

quicwg/base-drafts (+11/-7/=F0=9F=92=AC90)

11 issues created:

22 issues received 90 new comments:

7 issues closed:

Pull requests

quicwg/base-drafts (+8/-7/=F0=9F=92=AC32)

8 pull requests submitted:

10 pull requests received 32 new comments:

7 pull requests merged:

Repositories tracked by this digest:

--===============7125053395669228573==-- From nobody Mon Jan 21 19:38:15 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FED3131048 for ; Mon, 21 Jan 2019 19:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 UqMG7t2BQBHz for ; Mon, 21 Jan 2019 19:38:11 -0800 (PST) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5585813104A for ; Mon, 21 Jan 2019 19:38:10 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x0M3W8sx048305 for ; Mon, 21 Jan 2019 19:38:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : content-transfer-encoding : subject : message-id : date : to; s=20180706; bh=ZKP8s5LQuawzZqyLnFNn5IyFAbpui8YwGXe2YoWwthA=; b=LQXaKBnyrxO1Oi8C8q234ljyeERMPsd6gHxvw9vPybjGHINasCY9aZaexVfV0/RfKke0 tW/whvnKXKdixEt7S/5LKRG0Yc2fHRdCx21iO0+4R5Tc07Tx2nbxn2uCoeSTcBKEKHHB twEPB722QOfpIHry3IwX4q1dUlowv5ZM9ho+hEyYjJgL+pdM55cj7WMAsvXo9bo6NwTE qukXn165kJIayBFmIHEa9OWtAx4xT+3K2n2nGkpzgUFBX3hmk+vJlTyGsZOLXq0F4KQr PFHYFD3p6dlPOiXGhx/CR1QIfLL31C0XRbIPr7CCeWw7Ze3yEWiKj2Hg85rqGEW4RaxP eg== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2q43qd3q12-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 21 Jan 2019 19:38:08 -0800 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PLP00H4HRFIUA60@ma1-mtap-s02.corp.apple.com> for quic@ietf.org; Mon, 21 Jan 2019 19:38:08 -0800 (PST) Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PLP00400QX0LG00@nwk-mmpp-sz11.apple.com> for quic@ietf.org; Mon, 21 Jan 2019 19:38:06 -0800 (PST) X-Va-A: X-Va-T-CD: 12e6c357abb05abc41315428df79067e X-Va-E-CD: 7bf815171121a84e61e91e32290d6a37 X-Va-R-CD: 5aa1ad3cb546089efe556dda5bc868f9 X-Va-CD: 0 X-Va-ID: 1bc35eb8-60ba-4eb1-b6d0-c6ee1231cc8e X-V-A: X-V-T-CD: 12e6c357abb05abc41315428df79067e X-V-E-CD: 7bf815171121a84e61e91e32290d6a37 X-V-R-CD: 5aa1ad3cb546089efe556dda5bc868f9 X-V-CD: 0 X-V-ID: 8880f54e-e80a-464a-a594-cfffe2e4be6b Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PLP00300QU3KM00@nwk-mmpp-sz11.apple.com> for quic@ietf.org; Mon, 21 Jan 2019 19:38:06 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-22_02:,, signatures=0 Received: from [17.234.42.41] (unknown [17.234.42.41]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PLP00M71RFIXQ50@nwk-mmpp-sz11.apple.com> for quic@ietf.org; Mon, 21 Jan 2019 19:38:06 -0800 (PST) Sender: cheshire@apple.com From: Stuart Cheshire Content-transfer-encoding: quoted-printable Subject: United Airlines upgrades for QUIC Working Group Interim Meeting Message-id: Date: Mon, 21 Jan 2019 19:38:05 -0800 To: quic@ietf.org X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-22_02:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 03:38:14 -0000 Dear hard-working QUIC designers, I have two United Airlines international upgrades expiring at the end of = January, and it occurs to me that they might help make the journey more = comfortable for engineers traveling to the Interim Meeting in Tokyo next = week. The upgrades are valid for economy fares Y, B, M, E, U, H, Q, V, W on = international flights. If you=E2=80=99re traveling (a) on United Airlines, (b) before the end = of January, (c) with an upgradeable economy class fare, and you=E2=80=99d = like me to put in an upgrade request for you, I will need two pieces of = information from you. Send me (i) your six-character confirmation number = and (ii) the last name on the reservation. (If you reply, please keep =E2=80=9CUnited Airlines upgrades=E2=80=9D in = the subject line so that I don=E2=80=99t miss your email in the ocean of = spam.) Stuart Cheshire= From nobody Tue Jan 22 04:47:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30BF130F62 for ; Tue, 22 Jan 2019 04:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 6lPV-TtSAg7T for ; Tue, 22 Jan 2019 04:47:15 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 B8A5D130F53 for ; Tue, 22 Jan 2019 04:47:14 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id t18-v6so20493097ljd.4 for ; Tue, 22 Jan 2019 04:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FzcvYWu7S9IQ5NxqE+52w6XQIPgYmTOFiqSS+Q1oBlM=; b=hgy24u6YhAp+rTcUCKhqYa7eiUPk8jIhMnj2Ln+yc601DGs3rWxM5fiqj/loS8Vk62 fZ0mO6buGO3W3ac6il2DAjh94aCcm9QE8lfw+PLNhU/w5YkShYjviHeYWzxQF7IQ7lBD drgiBJZdSrwasnjWoRuOpUCg5XmBhGo9M6XPdkStINaIGOxkAavDPq+gm4GmLRv3jqCy Z0hWl5QHEtedfsqyX7sZ1ZPvtKoCtZa0WWFbVlYTSMiLXl89tAHCopB7unAzN02ERevw wQ7hiVmuNTLvAZDk59n83wfjnt88RjpbnPBoyYN3uzZtpKCm9lh5irg/jDQ0U71LvSHh VOVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FzcvYWu7S9IQ5NxqE+52w6XQIPgYmTOFiqSS+Q1oBlM=; b=nYIfiOaVnLtW0VE445mQw3NfbNoBgE3g2tPowEuBlMyDbV31e99bGzNVwN2O0xtVrS mEj5bCgC5AS+uHvP3oln4ZzOy5XEmQvCV2lYR/G9o99ExYAdqMjgFry3QrVfd8bjamy7 7f+LHNxG54AFR/5t//keg1W/zTMD1vcVUl9t3PYbBK8DONuJz9Skz0wkchx8ASHXmbeT U/Ny4bICbRDEKzfcsDSnO41I8mfzfFT5Y+RckwYb1B26yMo7oFeghVDbrRFjFXGwZuSi G6YJYmOVmDsKnW44SKXzs7tazIxVCeFEZ0VJZCDINu0qEq8dfSj89yappDwHrrI2rovj Nupw== X-Gm-Message-State: AJcUukd2fYoMvaI8xvu8Dw7QXHBs9PpR3YozFy6EuD2vxO5Vbgn7BZdy 06HCZ2fSXaio3VTVfwR1jVpbDegcOP2aTGRhJvRUzA== X-Google-Smtp-Source: ALg8bN5QN0pLH2lD06o10Hw/fmMie/F1iEirvd5XipdaVIY2Nqa8KSo5XZ/UTpioVZmIM0cLXf+qYDK/gLaGEs9RN0E= X-Received: by 2002:a2e:5b93:: with SMTP id m19-v6mr17801486lje.115.1548161232792; Tue, 22 Jan 2019 04:47:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 22 Jan 2019 06:47:02 -0600 Message-ID: Subject: Re: United Airlines upgrades for QUIC Working Group Interim Meeting To: Stuart Cheshire Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000055f2e305800b60a0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 12:47:17 -0000 --00000000000055f2e305800b60a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stuart, On Mon, Jan 21, 2019, 21:38 Stuart Cheshire Dear hard-working QUIC designers, > > I have two United Airlines international upgrades expiring at the end of > January, and it occurs to me that they might help make the journey more > comfortable for engineers traveling to the Interim Meeting in Tokyo next > week. > > The upgrades are valid for economy fares Y, B, M, E, U, H, Q, V, W on > international flights. > > If you=E2=80=99re traveling (a) on United Airlines, (b) before the end of= January, > (c) with an upgradeable economy class fare, and you=E2=80=99d like me to = put in an > upgrade request for you, I will need two pieces of information from you. > Send me (i) your six-character confirmation number and (ii) the last name > on the reservation. > > (If you reply, please keep =E2=80=9CUnited Airlines upgrades=E2=80=9D in = the subject line > so that I don=E2=80=99t miss your email in the ocean of spam.) > > Stuart Cheshire > You're a good man. (I'm attending remotely, but wanted to thank you for thinking of QUIC) Spencer > --00000000000055f2e305800b60a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stuart,

On Mon, Jan 21, 2019, 21:38 Stuart Cheshire <cheshire=3D40apple.com@dmarc.ietf.org wrote= :
Dear hard-working QUIC designers,=

I have two United Airlines international upgrades expiring at the end of Ja= nuary, and it occurs to me that they might help make the journey more comfo= rtable for engineers traveling to the Interim Meeting in Tokyo next week.
The upgrades are valid for economy fares Y, B, M, E, U, H, Q, V, W on inter= national flights.

If you=E2=80=99re traveling (a) on United Airlines, (b) before the end of J= anuary, (c) with an upgradeable economy class fare, and you=E2=80=99d like = me to put in an upgrade request for you, I will need two pieces of informat= ion from you. Send me (i) your six-character confirmation number and (ii) t= he last name on the reservation.

(If you reply, please keep =E2=80=9CUnited Airlines upgrades=E2=80=9D in th= e subject line so that I don=E2=80=99t miss your email in the ocean of spam= .)

Stuart Cheshire

You're a good man.

(I'm attending remotely, but wanted to thank you for thin= king of QUIC)

Spencer
--00000000000055f2e305800b60a0-- From nobody Tue Jan 22 12:42:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654181310EB for ; Tue, 22 Jan 2019 12:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ACnATX7pKSva for ; Tue, 22 Jan 2019 12:42:33 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8433F124BE5 for ; Tue, 22 Jan 2019 12:42:32 -0800 (PST) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6F3F62783C9 for ; Wed, 23 Jan 2019 05:42:30 +0900 (JST) Received: by mail-wm1-f50.google.com with SMTP id b11so15571433wmj.1 for ; Tue, 22 Jan 2019 12:42:30 -0800 (PST) X-Gm-Message-State: AJcUuke6TofTIOe+fTPC4ACjpV9VMT+YC4hzBDtTuxkf3QkqDeVblQJO Su+gy52C0KtkxFzOopemTkbgremPcQuwViYnX6c= X-Google-Smtp-Source: ALg8bN79CPmzBWTv8hq/nGdGNkqYi1uDmjkLANNIsj/sDGmJZc1elZZs27pgze3XIjbVTBFW3LBcgUg5Hx86U2RxszU= X-Received: by 2002:a1c:1b8d:: with SMTP id b135mr13565wmb.115.1548189747850; Tue, 22 Jan 2019 12:42:27 -0800 (PST) MIME-Version: 1.0 References: <62e20afc-975a-4cae-9cb3-98c557e62b6c@www.fastmail.com> In-Reply-To: From: Yoshifumi Nishida Date: Tue, 22 Jan 2019 12:42:16 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Setting lower boundary in timeouts (Re: TLP in recovery-17 draft) To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000f736a2058012034a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 20:42:36 -0000 --000000000000f736a2058012034a Content-Type: text/plain; charset="UTF-8" Hi, Please allow me to continue this a bit more. I am thinking that we might need a certain lower boundary for the timeouts in 17 draft. It uses exponential backoff algorithms, but I think it won't be very conservative in case the timeout value is small. This is just an idea, but to be clear, belows are what I am thinking. In case of crypto timeout: timeout = crypto_count > 0 ? max(timeout, kMinCryptoRTO) * (2 ^ crypto_count) : timeout kMinCryptoRTO ... 100ms? In case of PTO: timeout = pto_count > 0 ? max(timeout, kMinPTO) * (2 ^ pto_count) : timeout kMinPTO ... 200ms? BTW, I would like to clarify the behavior of loss_detection_timer. When set() is called while the timer is running, the current timer value is replaced with the new value or else? -- Yoshi On Sat, Jan 19, 2019 at 2:01 PM Yoshifumi Nishida wrote: > Hi Ian, > > Thanks for the response. Yes, that was my point. > But, I think I got it now. > In the previous draft, kMinRTOTimeout was 200ms and kMinTLPTimeout was > 10ms, but now only lower bound is kGgranularity and it's 1ms. > So, new PTO can be smaller than the previous version of RTO unless there's > no large variation in RTT samplings. > -- > Yoshi > > On Sat, Jan 19, 2019 at 5:57 AM Ian Swett wrote: > >> Can you clarify what you mean by slowly? >> >> Are you concerned the first PTO timeout will be substantially longer than >> what the first TLP was? If so, I believe that should be mostly mitigated >> by moving from a fixed min RTO to one that includes the explicitly >> communicated max ack delay, along the lines of the TCP MAD proposal( >> https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00). >> >> In cases when the rtt variance is large, PTO will definitely be longer >> than TLP was, but I think that's a feature, since it recognizes that >> sometimes TLP is too aggressive in those cases. >> >> On Sat, Jan 19, 2019 at 7:13 AM Yoshifumi Nishida >> wrote: >> >>> >>> Yep, I think I'm aware of the merging. The code looks cleaner and >>> simpler. >>> But, it seems to me that this code will react slowly in tail loss >>> situations.. It would be great if someone could clarify. >>> -- >>> Yoshi >>> >>> On Thu, Jan 17, 2019 at 11:55 PM Martin Thomson >>> wrote: >>> >>>> Look for PTO. RTO and TLP were merged into the one concept.. Jana can >>>> provide all the nasty details. >>>> >>>> On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote: >>>> > Hello, >>>> > I might overlook something, but I cannot find TLP logic in the pseudo >>>> > codes in the draft. I mean timeout seems to be determined by >>>> > conventional way. >>>> > Is this intentional or am I missing something? >>>> > >>>> > Thanks, >>>> > -- >>>> > Yoshi >>>> > >>>> >>>> --000000000000f736a2058012034a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Please allow me to continue this a bit = more.
I am thinking that we might need a certain lower boundary f= or the timeouts in 17 draft.
It uses exponential backoff algorith= ms, but I think it won't be very conservative in case the timeout value= is small.=C2=A0

This is just an idea, but to be c= lear, belows are what I am thinking.

In case o= f crypto timeout:

=C2=A0 timeout =3D crypto_count = > 0 ? max(timeout, kMinCryptoRTO) * (2 ^ crypto_count) : timeout
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0kMinCryptoRTO ... 100ms?<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
In case of PTO:
=C2=A0=C2=A0
=C2=A0 timeout =3D pto_count > 0 ? max= (timeout, kMinPTO) * (2 ^ pto_count) : timeout

=C2=A0 =C2=A0kMinPTO =
... 200ms?

BTW, I would like to clarify the behavior of loss_=
detection_timer.
When set() is calle=
d while the timer is running, the current timer value is replaced with the =
new value or else?
--
Yoshi=C2=A0 =C2=A0
On = Sat, Jan 19, 2019 at 2:01 PM Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
<= div dir=3D"ltr">
Hi Ian,

Than= ks for the response. Yes, that was my point.
But, I thin= k I got it now.
In the previous draft, kMinRTOTimeout was 2= 00ms and kMinTLPTimeout was 10ms, but now only lower bound is kGgranularity= and it's 1ms.
So, new PTO can be smaller than the previous v= ersion of RTO unless there's no large variation in RTT samplings.
=
--
Yoshi

On= Sat, Jan 19, 2019 at 5:57 AM Ian Swett <ianswett@google.com> wrote:
Can you clarify what you mean by slowly?

Are you concerned the first PTO timeout will be substant= ially longer than what the first TLP was?=C2=A0 If so, I believe that shoul= d be mostly mitigated by moving from a fixed min RTO to one that includes t= he explicitly communicated max ack delay, along the lines of the TCP MAD pr= oposal(https://tools.ietf.org/html/draft-wang-tcpm-low-la= tency-opt-00).

In cases when the r= tt variance is large, PTO will definitely be longer than TLP was, but I thi= nk that's a feature, since it recognizes that sometimes TLP is too aggr= essive in those cases.

On Sat, Jan 19, 2019 at 7:13 AM Yoshifumi Nishida <nishida@sfc.wide.ad.jp= > wrote:

Yep, I think I'm aware of = the merging. The code looks cleaner and simpler.
But, it seems to= me that this code will react slowly in tail loss situations.. It would be = great if someone could clarify.
--
Yoshi

On Thu, Jan 17, 2019 at 11:55 PM Mar= tin Thomson <mt@l= owentropy.net> wrote:
Look for PTO. RTO and TLP were merged into the one concept.. J= ana can provide all the nasty details.

On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote:
> Hello,
> I might overlook something, but I cannot find TLP logic in the pseudo =
> codes in the draft. I mean timeout seems to be determined by
> conventional way.
> Is this intentional or am I missing something?
>
> Thanks,
> --
> Yoshi
>

--000000000000f736a2058012034a-- From nobody Tue Jan 22 14:03:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E271D129AB8 for ; Tue, 22 Jan 2019 14:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rAMk8CR--JoM for ; Tue, 22 Jan 2019 14:03:13 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 0892A129A87 for ; Tue, 22 Jan 2019 14:03:13 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id b11so117165wmj.1 for ; Tue, 22 Jan 2019 14:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TnGh20lZ5jhJRB6i1mVeehaDccsBqhNg8WzitryxnF4=; b=Z5DByWkAUJFmrUebhO+Tpv59omXS46YY3VAiwcEmUm4JS7xLLMMug2wn27rw/+zOFu h/Y8CqJy2fytUiiS91PV+968a3HohjlmWWUeQX3JLnlceevRSyiKxSTpzYZJRqmPZ3i7 ZgRXCsmfvLpRXL1dp3BRaYDTWeMSvmlMHiH0oN0S7fbo0Qk6Tk6EGAU5iEILqCN4wktP Pb8IZV2iRZhgrax8p2p63DOiH15GfrSVmQGLxI66R8uKQEuJhVUVkMOkv0GeMALtJ+om 8YvGovna64SQfRf/g062IHYReioY1YQu/ydaNku8sQzx3eMkmXywGI0WNm2RuhODsRP1 0OEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TnGh20lZ5jhJRB6i1mVeehaDccsBqhNg8WzitryxnF4=; b=qVLhKh14kVbOvrT9Qedh+/fPTJEN6X4nnN8I/4tOXqxy/dlkmFwnPb/dvsW9TnUwOU Ekk6y5oMsXTGp6cTSVWffuOsV8QiUinG43gzc34eUls5dqrcr38m6kT/qcZ9V7CyveuZ 0nubIZYiVdhjUB18yA5x+l6RAfOMSXLVN2HQXYCgA09Pnwq1mvSyzQmHTgMF5Ok8zX5C I6k54OriUx5Yfgu0kcM+x3ZKS/PSTOKyog5ozgC9gt1Ed4BIYFs7l+6bczOh1zzjPZB7 UBBwr/lvyscPwNu+x+KuYzrUgCFbyAdWYA50Y2+nOl6fXiZ00mj0skopnKe6AnMx6nG0 WLDw== X-Gm-Message-State: AJcUukc2PBheOwcXdHvWDJIcmg4RE7o8ifp2ZFz2NnNJ9MU+6JVBkNXQ u0bcphq72CdGxLbp7Ho+jQYuNcWWymFJmtYoMui6TXXvnPY= X-Google-Smtp-Source: ALg8bN4P8ZKO+H7oPMuyvqTBL8DnkUIjxWLgeiEvDbC+RW632hndblaFaDlGSfGhAUhNM95cXUaIB+6vUtL3cPR68/M= X-Received: by 2002:a1c:578e:: with SMTP id l136mr209923wmb.124.1548194591138; Tue, 22 Jan 2019 14:03:11 -0800 (PST) MIME-Version: 1.0 References: <62e20afc-975a-4cae-9cb3-98c557e62b6c@www.fastmail.com> In-Reply-To: From: Ian Swett Date: Tue, 22 Jan 2019 17:02:59 -0500 Message-ID: Subject: Re: Setting lower boundary in timeouts (Re: TLP in recovery-17 draft) To: Yoshifumi Nishida Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000a6634205801324aa" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 22:03:16 -0000 --000000000000a6634205801324aa Content-Type: text/plain; charset="UTF-8" On Tue, Jan 22, 2019 at 3:42 PM Yoshifumi Nishida wrote: > Hi, > Please allow me to continue this a bit more. > I am thinking that we might need a certain lower boundary for the timeouts > in 17 draft. > It uses exponential backoff algorithms, but I think it won't be very > conservative in case the timeout value is small. > > This is just an idea, but to be clear, belows are what I am thinking. > > In case of crypto timeout: > > timeout = crypto_count > 0 ? max(timeout, kMinCryptoRTO) * (2 ^ > crypto_count) : timeout > > kMinCryptoRTO ... 100ms? > > In case of PTO: > > timeout = pto_count > 0 ? max(timeout, kMinPTO) * (2 ^ pto_count) : > timeout > > kMinPTO .... 200ms? > > Personally, I'd prefer to not add more minimums to these calculations, because I've seen cases when minimums, especially the rather conservative values you're proposing, cause large performance regressions in TCP, particularly in datacenter environments. > > BTW, I would like to clarify the behavior of loss_detection_timer. > When set() is called while the timer is running, the current timer value is replaced with the new value or else? > > Yes, would it be more intuitive if we used update() instead of set()? > -- > Yoshi > > On Sat, Jan 19, 2019 at 2:01 PM Yoshifumi Nishida > wrote: > >> Hi Ian, >> >> Thanks for the response. Yes, that was my point. >> But, I think I got it now. >> In the previous draft, kMinRTOTimeout was 200ms and kMinTLPTimeout was >> 10ms, but now only lower bound is kGgranularity and it's 1ms. >> So, new PTO can be smaller than the previous version of RTO unless >> there's no large variation in RTT samplings. >> -- >> Yoshi >> >> On Sat, Jan 19, 2019 at 5:57 AM Ian Swett wrote: >> >>> Can you clarify what you mean by slowly? >>> >>> Are you concerned the first PTO timeout will be substantially longer >>> than what the first TLP was? If so, I believe that should be mostly >>> mitigated by moving from a fixed min RTO to one that includes the >>> explicitly communicated max ack delay, along the lines of the TCP MAD >>> proposal(https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00 >>> ). >>> >>> In cases when the rtt variance is large, PTO will definitely be longer >>> than TLP was, but I think that's a feature, since it recognizes that >>> sometimes TLP is too aggressive in those cases. >>> >>> On Sat, Jan 19, 2019 at 7:13 AM Yoshifumi Nishida < >>> nishida@sfc.wide.ad.jp> wrote: >>> >>>> >>>> Yep, I think I'm aware of the merging. The code looks cleaner and >>>> simpler. >>>> But, it seems to me that this code will react slowly in tail loss >>>> situations.. It would be great if someone could clarify. >>>> -- >>>> Yoshi >>>> >>>> On Thu, Jan 17, 2019 at 11:55 PM Martin Thomson >>>> wrote: >>>> >>>>> Look for PTO. RTO and TLP were merged into the one concept.. Jana can >>>>> provide all the nasty details. >>>>> >>>>> On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote: >>>>> > Hello, >>>>> > I might overlook something, but I cannot find TLP logic in the >>>>> pseudo >>>>> > codes in the draft. I mean timeout seems to be determined by >>>>> > conventional way. >>>>> > Is this intentional or am I missing something? >>>>> > >>>>> > Thanks, >>>>> > -- >>>>> > Yoshi >>>>> > >>>>> >>>>> --000000000000a6634205801324aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Jan 22, 2019 at 3:42 PM Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hi,
Please allow me to co= ntinue this a bit more.
I am thinking that we might need a certai= n lower boundary for the timeouts in 17 draft.
It uses exponentia= l backoff algorithms, but I think it won't be very conservative in case= the timeout value is small.=C2=A0

This is just an= idea, but to be clear, belows are what I am thinking.

In case of crypto timeout:

=C2=A0 timeout= =3D crypto_count > 0 ? max(timeout, kMinCryptoRTO) * (2 ^ crypto_count)= : timeout
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0kMinCry= ptoRTO ... 100ms?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
In= case of PTO:
=C2=A0=C2=A0
=C2=A0 timeout =3D pto_= count > 0 ? max(timeout, kMinPTO) * (2 ^ pto_count) : timeout
<= br class=3D"m_4202522067285093345gmail-Apple-interchange-newline">
=

=C2=A0 =C2=A0kMinPTO .... 200ms?

Personally, I= 9;d prefer to not add more minimums to these calculations, because I've= seen cases when minimums, especially the rather conservative values you= 9;re proposing, cause large performance regressions in TCP, particularly in= datacenter environments.
=C2=A0

BTW, I would like to clarify the behavior of los=
s_detection_timer.
When set() is cal=
led while the timer is running, the current timer value is replaced with th=
e new value or else?

Yes, would it be more intuitive if we used update() instead of set()?=C2= =A0
--
= Yoshi=C2=A0 =C2=A0

On Sat, Jan 19, 2019 at 2:01 PM Yosh= ifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hi Ian,

Thanks for the resp= onse. Yes, that was my point.
But, I think I got it now.=
In the previous draft, kMinRTOTimeout was 200ms and kMinTL= PTimeout was 10ms, but now only lower bound is kGgranularity and it's 1= ms.
So, new PTO can be smaller than the previous version of RTO u= nless there's no large variation in RTT samplings.
--
Yoshi

On Sat, Jan 19, 2019 at 5:57 AM Ian Swett <ianswett@google.com> wrote:
Can you clarify what you mean by slowly?
Are you concerned the first PTO timeout will be su= bstantially longer than what the first TLP was?=C2=A0 If so, I believe that= should be mostly mitigated by moving from a fixed min RTO to one that incl= udes the explicitly communicated max ack delay, along the lines of the TCP = MAD proposal(https://tools.ietf.org/html/draft-wang-tcpm-= low-latency-opt-00).

In cases when= the rtt variance is large, PTO will definitely be longer than TLP was, but= I think that's a feature, since it recognizes that sometimes TLP is to= o aggressive in those cases.

On Sat, Jan 19, 2019 at 7:13 AM Yoshifum= i Nishida <n= ishida@sfc.wide.ad.jp> wrote:

Yep, = I think I'm aware of the merging. The code looks cleaner and simpler.
But, it seems to me that this code will react slowly in tail loss = situations.. It would be great if someone could clarify.
--
=
Yoshi

On Thu, Jan= 17, 2019 at 11:55 PM Martin Thomson <mt@lowentropy.net> wrote:
Look for PTO. RTO and TLP were merged= into the one concept.. Jana can provide all the nasty details.

On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote:
> Hello,
> I might overlook something, but I cannot find TLP logic in the pseudo =
> codes in the draft. I mean timeout seems to be determined by
> conventional way.
> Is this intentional or am I missing something?
>
> Thanks,
> --
> Yoshi
>

--000000000000a6634205801324aa-- From nobody Tue Jan 22 16:44:22 2019 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C258B1311CE; Tue, 22 Jan 2019 16:44:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-recovery-18.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <154820425473.13239.288382071591485470@ietfa.amsl.com> Date: Tue, 22 Jan 2019 16:44:14 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 00:44:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-18.txt Pages : 36 Date : 2019-01-22 Abstract: This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-recovery [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-18 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 22 16:46:06 2019 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B895130F5B; Tue, 22 Jan 2019 16:45:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-transport-18.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <154820435659.13324.7949709640386649308@ietfa.amsl.com> Date: Tue, 22 Jan 2019 16:45:56 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 00:45:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-18.txt Pages : 141 Date : 2019-01-22 Abstract: This document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at . Working Group information can be found at ; source code and issues list for this draft can be found at . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-transport-18 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 22 16:50:09 2019 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 448A1130E70; Tue, 22 Jan 2019 16:50:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-18.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <154820460120.13231.16150122014848980135@ietfa.amsl.com> Date: Tue, 22 Jan 2019 16:50:01 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 00:50:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Hypertext Transfer Protocol Version 3 (HTTP/3) Author : Mike Bishop Filename : draft-ietf-quic-http-18.txt Pages : 51 Date : 2019-01-22 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-18 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 22 16:58:59 2019 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BC0128D0C; Tue, 22 Jan 2019 16:58:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-tls-18.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <154820513050.13243.9962393117014039388@ietfa.amsl.com> Date: Tue, 22 Jan 2019 16:58:50 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 00:58:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Using TLS to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-18.txt Pages : 41 Date : 2019-01-22 Abstract: This document describes how Transport Layer Security (TLS) is used to secure QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-tls [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-18 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 22 22:22:41 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD0612D4EF for ; Tue, 22 Jan 2019 22:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 AsWjt0Mt8ZcN for ; Tue, 22 Jan 2019 22:22:37 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD8512D7EA for ; Tue, 22 Jan 2019 22:22:36 -0800 (PST) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CD7D3278436 for ; Wed, 23 Jan 2019 15:22:33 +0900 (JST) Received: by mail-wm1-f41.google.com with SMTP id y8so781367wmi.4 for ; Tue, 22 Jan 2019 22:22:33 -0800 (PST) X-Gm-Message-State: AJcUukdlKHWQXLOejbRDDHFqTkeV/Gz/PB2KSDEvM2AsBLo8BAUri8Fc YhaPulUxA9s0w1Jpjx0tIVSvwdD+JmMqe7fXa7A= X-Google-Smtp-Source: ALg8bN4rjCAfTtzVO/8Ct91dnhhYwtw45Rh8Kw/FpQM1HfGaW5kMW2AP2Sx1bS697IZjb9Ai75ycvqa7XUiioGzyF3E= X-Received: by 2002:a1c:dc86:: with SMTP id t128mr1421400wmg.42.1548224551469; Tue, 22 Jan 2019 22:22:31 -0800 (PST) MIME-Version: 1.0 References: <62e20afc-975a-4cae-9cb3-98c557e62b6c@www.fastmail.com> In-Reply-To: From: Yoshifumi Nishida Date: Tue, 22 Jan 2019 22:22:20 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Setting lower boundary in timeouts (Re: TLP in recovery-17 draft) To: Ian Swett Cc: Yoshifumi Nishida , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000006c4a1d05801a1eb1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 06:22:39 -0000 --0000000000006c4a1d05801a1eb1 Content-Type: text/plain; charset="UTF-8" Hi Ian, On Tue, Jan 22, 2019 at 2:02 PM Ian Swett wrote: > > > On Tue, Jan 22, 2019 at 3:42 PM Yoshifumi Nishida > wrote: > >> Hi, >> Please allow me to continue this a bit more. >> I am thinking that we might need a certain lower boundary for the >> timeouts in 17 draft. >> It uses exponential backoff algorithms, but I think it won't be very >> conservative in case the timeout value is small. >> >> This is just an idea, but to be clear, belows are what I am thinking. >> >> In case of crypto timeout: >> >> timeout = crypto_count > 0 ? max(timeout, kMinCryptoRTO) * (2 ^ >> crypto_count) : timeout >> >> kMinCryptoRTO ... 100ms? >> >> In case of PTO: >> >> timeout = pto_count > 0 ? max(timeout, kMinPTO) * (2 ^ pto_count) : >> timeout >> >> kMinPTO .... 200ms? >> >> > Personally, I'd prefer to not add more minimums to these calculations, > because I've seen cases when minimums, especially the rather conservative > values you're proposing, cause large performance regressions in TCP, > particularly in datacenter environments. > Right.. I agree that this is too conservative for data center environments. I feel a bit guilty and feel like being a villain. But, I'm totally fine that people don't use these boundaries inside data centers or some companies try more aggressive settings on their own. Because in this case, people there should understand exactly what they are doing in controlled environments. What I'm wondering is whether if we should write down this logic in a standard track RFC or not. Because I feel this may mean IETF will endorse these settings over various network environments. Anyway, this is just my personal preference. But, I might want to see some discussions on this point. > > >> >> BTW, I would like to clarify the behavior of loss_detection_timer. >> When set() is called while the timer is running, the current timer value is replaced with the new value or else? >> >> > Yes, would it be more intuitive if we used update() instead of set()? > Yes, update() looks good to me. Thanks! -- Yoshi --0000000000006c4a1d05801a1eb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ian,

On Tue, Jan 22, 2019 at 2:02 PM Ian Swett <= ;ianswett=3D40google.com@dma= rc.ietf.org> wrote:


On Tue, Jan 22, 2019 at 3:42 PM Yoshifumi Nishida <nishida@sfc.wide.ad.jp> = wrote:
Hi,
Please allow me to continue this a bit more.
I am thinking that we might need a certain lower boundary for the t= imeouts in 17 draft.
It uses exponential backoff algorithms, but = I think it won't be very conservative in case the timeout value is smal= l.=C2=A0

This is just an idea, but to be clear, be= lows are what I am thinking.

In case of crypto= timeout:

=C2=A0 timeout =3D crypto_count > 0 ?= max(timeout, kMinCryptoRTO) * (2 ^ crypto_count) : timeout
= =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0kMinCryptoRTO ... 100ms?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
In case of PTO:
= =C2=A0=C2=A0
=C2=A0 timeout =3D pto_count > 0 ? max(timeo= ut, kMinPTO) * (2 ^ pto_count) : timeout

=C2=
=A0 =C2=A0kMinPTO .... 200ms?

Personally, I'd prefer to not add more minimums to the= se calculations, because I've seen cases when minimums, especially the = rather conservative values you're proposing, cause large performance re= gressions in TCP, particularly in datacenter environments.
=

Right.. I agree that this is t= oo conservative for data center environments. I feel a bit guilty and feel = like being a villain.
But, I'm totally fine that people don&#= 39;t use these boundaries inside data centers or some companies try more ag= gressive settings on their own. Because in this case, people there should u= nderstand exactly what they are doing in controlled environments.

What I'm wondering is whether if we should write down t= his logic in a standard track RFC or not.=C2=A0
Because I feel th= is may mean IETF will endorse these settings over various network environme= nts.

Anyway, this is just my personal preference. = But, I might want to see some discussions on this point.
=C2=A0

BTW, I would like to clari=
fy the behavior of loss_detection_timer.
When set() is called while the timer is running, the current timer val=
ue is replaced with the new value or else?

Yes, would it be more intuitive if we used update()= instead of set()?=C2=A0

= Yes, update() looks good to me. Thanks!
--
Yoshi
<= div>
--0000000000006c4a1d05801a1eb1-- From nobody Wed Jan 23 09:33:34 2019 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8638130EDB; Wed, 23 Jan 2019 09:33:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-qpack-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <154826480777.7485.17506024935734449753@ietfa.amsl.com> Date: Wed, 23 Jan 2019 09:33:27 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 17:33:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QPACK: Header Compression for HTTP over QUIC Authors : Charles 'Buck' Krasic Mike Bishop Alan Frindell Filename : draft-ietf-quic-qpack-06.txt Pages : 36 Date : 2019-01-22 Abstract: This specification defines QPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/3. This is a variation of HPACK header compression that seeks to reduce head-of-line blocking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-qpack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-qpack-06 https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-qpack-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 26 16:45:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB84E12872C for ; Sat, 26 Jan 2019 16:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=iQQWW1oN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JBug4dGi 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 fQQY12AcXAlf for ; Sat, 26 Jan 2019 16:45:21 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93D812426A for ; Sat, 26 Jan 2019 16:45:20 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id EB25E21AAD for ; Sat, 26 Jan 2019 19:45:19 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 26 Jan 2019 19:45:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=XpxHeKIMcKUdUIgmqMKtibZ09OtWfC4YrM2QHA9Y1KY=; b=iQQWW1oN omrfQ50yhf0BP7DYRkxnLDTxwJPc9hK7uNqv/opldXq/eOY+2245K/QUgn5aiRQN uh/r4nLIJ6q37WHD1YA3V+5t4Op67YRVhJx2urTqmXZJPtBWZWaY7hlA5Jx5Lj2a /4hC6KXuqKFetUW6HMq8OdiTsCcaQFjWkrD6L8btcF/iVovxuQf76333dUMAQlWd LyoEks9/wz6ODu2TqZH8InM0lZGvfBYpBqLvpRtIsXhlZHOdpDZffRZl8PZrD5sB tPxNwn70ebSZnCIM4gHucUZqqTihV0cnQD9sJ8f8vjEWjWOj2NoUYUsGyd6QfS5Y seqWbAn1IfYkoA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=XpxHeKIMcKUdUIgmqMKtibZ09OtWf C4YrM2QHA9Y1KY=; b=JBug4dGioJHHIYlC/oa69viH7seYZwW7uZFjAFscGBxlc gBAxZinfQ6veN3lbjhhPreYPSje6eQh4As7r97979eYUHOjCueGeVoIFsCH43AJV 78vI6L4XNIEkGmFJmf4pmSnQ3sj+8iyDfhZD47ogdzItM04gnw4R80HMFj4zt4XW +zMMbEzvmIDxHDH9A2IyKGemCvHKNkNfRaBmkSKNj6aQ7dx4Nzvs9fWOgkVOOtBf nU3FkT0+8tfKngaj1nClHhK/0mfUW0Yc8eIhWrnhI/CNCj+gdmDiBT7sga3cxKjr 0uoU+9uQm24jtLds4RaET1zIue5yQusG6y2sddBaQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrieejgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpefiihhthhhusg gppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhn vghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeduudelrdelrdegfe drvdegudenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehm nhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 02A8C10086 for ; Sat, 26 Jan 2019 19:45:18 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 26A45C5402 for ; Sun, 27 Jan 2019 00:45:15 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============7288889283307285568==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190127004515.26A45C5402@cloud.mnot.net> Date: Sun, 27 Jan 2019 00:45:15 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2019 00:45:25 -0000 --===============7288889283307285568== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+7/-8/=F0=9F=92=AC40) 7 issues created: - Merge normative -spin-exp text into -transport (by britram) https://github.com/quicwg/base-drafts/issues/2369 = - Text banning post-handshake client auth is unclear (by DavidSchinazi) https://github.com/quicwg/base-drafts/issues/2367 = - The initial table capacity is zero (by martinthomson) https://github.com/quicwg/base-drafts/issues/2363 [-qpack] [editorial] = - 0-RTT flow control lmits can't be increased (by martinthomson) https://github.com/quicwg/base-drafts/issues/2360 [-transport] [design] = - Are Separate Uni and Bidi Stream Limits Meaningful? (by martinduke) https://github.com/quicwg/base-drafts/issues/2358 = - Stream Send State Machine is Confusing (by martinduke) https://github.com/quicwg/base-drafts/issues/2357 = - Persistent Congestion Requires Probes to be Sent (by nibanks) https://github.com/quicwg/base-drafts/issues/2356 = 11 issues received 40 new comments: - #2344 RESET_STREAM should be allowed in 0-RTT packets (11 by martinthom= son, marten-seemann, kazuho, MikeBishop) https://github.com/quicwg/base-drafts/issues/2344 [-transport] [design] = - #2369 Merge normative -spin-exp text into -transport (11 by kazuho, mar= ten-seemann, janaiyengar, britram, ihlar, loganaden, mirjak, hardie) https://github.com/quicwg/base-drafts/issues/2369 [-spin-exp] [-transpo= rt] [editorial] = - #2367 Text banning post-handshake client auth is unclear (5 by DavidSch= inazi, martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/issues/2367 = - #2358 Are Separate Uni and Bidi Stream Limits Meaningful? (3 by martint= homson, LPardue, ianswett) https://github.com/quicwg/base-drafts/issues/2358 [-transport] [design] = - #2356 Persistent Congestion Requires Probes to be Sent (2 by ianswett, = nibanks) https://github.com/quicwg/base-drafts/issues/2356 [-recovery] [design] = - #2357 Stream Send State Machine is Confusing (2 by martinthomson, marti= nduke) https://github.com/quicwg/base-drafts/issues/2357 [-transport] [editori= al] = - #2294 Why must we not use post-handshake client auth? (2 by DavidSchina= zi, martinthomson) https://github.com/quicwg/base-drafts/issues/2294 [-tls] [editorial] = - #2207 Time based loss recommendation not sensitive to paths with high R= TT variability (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2207 [-recovery] [editoria= l] = - #2353 MAX_STREAM_DATA risk unbounded state (1 by mikkelfj) https://github.com/quicwg/base-drafts/issues/2353 [-transport] [design] = - #2360 0-RTT flow control limits can't be increased (1 by kazuho) https://github.com/quicwg/base-drafts/issues/2360 [-transport] [design] = - #2158 Why is ipAddress variable length (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2158 [-transport] [editori= al] = 8 issues closed: - Loss events for reordered 0- and 0.5-RTT data https://github.com/quicwg= /base-drafts/issues/1967 [-recovery] [design] = - Preferred address text is confusing https://github.com/quicwg/base-draf= ts/issues/2146 [-transport] [editorial] = - Samples for RTT estimation https://github.com/quicwg/base-drafts/issues= /2067 [-recovery] [design] = - Why must we not use post-handshake client auth? https://github.com/quic= wg/base-drafts/issues/2294 [-tls] [editorial] = - Why is ipAddress variable length https://github.com/quicwg/base-drafts/= issues/2158 [-transport] [editorial] = - MAX_STREAM_DATA risk unbounded state https://github.com/quicwg/base-dra= fts/issues/2353 [-transport] [design] = - STOP_SENDING on implicitly opened streams is error-prone https://github= .com/quicwg/base-drafts/issues/2345 = - What resets idle timeout? https://github.com/quicwg/base-drafts/issues/= 2149 [-transport] [editorial] = Pull requests ------------- * quicwg/base-drafts (+6/-8/=F0=9F=92=AC31) 6 pull requests submitted: - Clarify when to signal error on incorrect Required Insert Count. (by be= ncebeky) https://github.com/quicwg/base-drafts/pull/2368 = - Bikeshed Required Insert Count encoding. (by bencebeky) https://github.com/quicwg/base-drafts/pull/2366 = - Persistent Congestion Time Threshold (by nibanks) https://github.com/quicwg/base-drafts/pull/2365 = - Moving text on spinbit into transport (by ihlar) https://github.com/quicwg/base-drafts/pull/2364 = - Define RTT (by ianswett) https://github.com/quicwg/base-drafts/pull/2362 [-recovery] [editorial] = - Refine STOP_SENDING reaction text (by martinthomson) https://github.com/quicwg/base-drafts/pull/2361 [-transport] [editorial= ] = 15 pull requests received 31 new comments: - #2364 Moving text on spinbit into transport (14 by ihlar, ronieven, lar= seggert, britram, martinthomson) https://github.com/quicwg/base-drafts/pull/2364 = - #2330 QPACK: Clarify how maximum dynamic table capacity can be set (2 b= y bencebeky, martinthomson) https://github.com/quicwg/base-drafts/pull/2330 [-qpack] [design] = - #2250 Call Largest Reference on the wire something else. (2 by bencebek= y, martinthomson) https://github.com/quicwg/base-drafts/pull/2250 [-qpack] [editorial] = - #2261 Clarify when a dynamic table entry can be evicted. (2 by bencebek= y) https://github.com/quicwg/base-drafts/pull/2261 [-qpack] [editorial] = - #2327 Ignore packet loss when the keys are not available (1 by janaiyen= gar) https://github.com/quicwg/base-drafts/pull/2327 [-recovery] [design] = - #2340 Add note about frequent RTT estimates (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2340 [-recovery] [editorial] = - #2352 allow STOP_SENDING on implicitly opened streams (1 by martinthoms= on) https://github.com/quicwg/base-drafts/pull/2352 = - #2354 STOP_SENDING is permitted for Ready streams (1 by martinduke) https://github.com/quicwg/base-drafts/pull/2354 [-transport] [editorial= ] = - #2355 Allow stream-related frames in 0-RTT (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2355 [-http] [-tls] [-transp= ort] [design] = - #2365 Persistent Congestion Time Threshold (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/2365 = - #2248 Alternative Largest Reference Decoding algorithm. (1 by bencebeky) https://github.com/quicwg/base-drafts/pull/2248 [-qpack] [editorial] = - #2249 Invalid Largest Reference is a stream error. (1 by bencebeky) https://github.com/quicwg/base-drafts/pull/2249 [-qpack] [editorial] = - #2256 Initial maximum table size is zero. (1 by bencebeky) https://github.com/quicwg/base-drafts/pull/2256 [-qpack] [design] = - #2257 Initial maximum table size is SETTINGS_HEADER_TABLE_SIZE. (1 by b= encebeky) https://github.com/quicwg/base-drafts/pull/2257 [-http] [-qpack] [desig= n] = - #2212 Proposed change to #1965 (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2212 [-recovery] [design] = 8 pull requests merged: - Define RTT https://github.com/quicwg/base-drafts/pull/2362 [-recovery] [editorial] = - Ignore packet loss when the keys are not available https://github.com/quicwg/base-drafts/pull/2327 [-recovery] [design] = - Changelog for -18 https://github.com/quicwg/base-drafts/pull/2359 [editorial] = - Correcting polarity of SPA language https://github.com/quicwg/base-drafts/pull/2349 [-transport] [design] [= editorial] = - Add note about frequent RTT estimates https://github.com/quicwg/base-drafts/pull/2340 [-recovery] [editorial] = - Refine STOP_SENDING reaction text https://github.com/quicwg/base-drafts/pull/2361 [-transport] [editorial= ] = - STOP_SENDING is permitted for Ready streams https://github.com/quicwg/base-drafts/pull/2354 [-transport] [editorial= ] = - Rework idle timeout definition https://github.com/quicwg/base-drafts/pull/2346 [-transport] [editorial= ] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============7288889283307285568== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday January 27, 2019

Issues

quicwg/base-drafts (+7/-8/=F0=9F=92=AC40)

7 issues created:

11 issues received 40 new comments:

8 issues closed:

Pull requests

quicwg/base-drafts (+6/-8/=F0=9F=92=AC31)

6 pull requests submitted:

15 pull requests received 31 new comments:

8 pull requests merged:

Repositories tracked by this digest:

--===============7288889283307285568==-- From nobody Tue Jan 29 20:53:11 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B698127B4C for ; Tue, 29 Jan 2019 20:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZCstu0XcnzPG for ; Tue, 29 Jan 2019 20:53:07 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1E4124BF6 for ; Tue, 29 Jan 2019 20:53:07 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gohrz-0000zU-LO for quic@ietf.org; Wed, 30 Jan 2019 05:53:05 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gohru-0007W8-Qc for quic@ietf.org; Tue, 29 Jan 2019 23:52:59 -0500 Received: (qmail 1524 invoked from network); 30 Jan 2019 04:52:55 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Jan 2019 04:52:55 -0000 To: 'Eric Rescorla' , IETF QUIC WG From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <5800091e-0748-d576-360e-218b47ab7b03@huitema.net> Date: Tue, 29 Jan 2019 18:52:52 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: On path attack by address rewriting X-Originating-IP: 168.144.250.232 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.41) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5lKHXVbMRooalZHdOF8HGL1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViEocER6XSl1gwfGSPoyWOPM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBiuj1YIZWyGteeTEbAD/lb/vRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFt8i77Wu2Jb/TI0CxS53moc/SlgXpNwUDmiieE9G+9VqfZ1kay mqFCHRp6u+mIhIXg5jssJAnfERZ2C5vj1sOdsnQOD0r6/AaHZiEtdTMtMljoSvSqrGwueTSCQFid cy15jQ4HwbF4aWaRl0axA525ouWBOXp8nHKe0R+FkIqN7hkgzj0zEmu34GPXR572RNl5VgW9/bkt U41htiJ8fk7NkHmplbyYh4+w03es32OzjfSo5Jhwk+hMTKYppuA2BaWeipTPWMHGUquOFNpW9R6n Md9TLrF9l3ItGfA/WrnALV6y4t4La5KOjBsoSy5ilx7fZqY0WkD+XXhBRGrlXn3JpaFMs2Yk/J72 gsCrWoyV4LhG047RODDSOAU8VRBdjarRhquvBzKEzdsRbaiLpp7t82t4C4SlaCuF6Oqyplz7a94E pv+Z3RfD+aRmwAVlEJHcERWeKKG4PAQYNyavp7c49DAEvpIaNkKSV1tec9N13onSGe3okMCcn14J 4XO+5ud/PKbBnFv4ONEUYSVU08t6uJiB0rZAaGh4Dknw14pmicXRZ4YizZEe9VMcrJA1TtxdruwC 6/RsMQ4p0WvdrKbTQoB/UI/NE7xpYDG18t7tofGRr49oDQgKmE4jKFK1fXvB15Q6CZxYjafGpi3c b03a4ZFy04e73oo5Jp1iUunX3+VlFawbDxpzYifNwA/+CbHA2fz9gpiGyR7D15JIzS+z7i8K8WY4 szo4Gwow0vwlYMfpTQuMHNi5DO10BOGC1ZJT0NaIcaHtK0XZjSPnTTBX4w== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 04:53:09 -0000 EKR, During the interim session this morning we had a discussion of issue #2143. The concern is that either man-on-the-side or man-on-the-middle can rewrite the IP headers and play games with the address. This is possible because the IP header is outside the encryption and authentication envelope, yet we play games with it. It is very hard to get a full defense against such attacks, as they are very close to the "NAT rebinding" scenario that we actually want to support. We actually discussed this attack before, and that's the reason why the spec ask for servers to probe both the old and the new address. I verified that defense by adding a test in the Picoquic test suite. It works like that: 1) Client and server are connected by a simulated 10 Mbps link. 2) Client starts a long download. 3) After the handshake, the simulation mimics an attack. 75% the packet headers are rewritten, 25% of them pointing to an attacker controlled address, 50% pointing to random addresses that go nowhere. The packets sent to the attacker address are relayed to the actual source. 4) After some time, the attacker stops relaying packets to the source, in an attempt to break the connection. 5) After some more time, the attack ceases. The test verifies that the connection completes in a reasonable time, without breaking. The test was failing with the original spec, but with the new requirement to "probe both paths" the test passes. This makes me believe that the spec is doing something right. -- Christian Huitema