From nobody Mon Apr 3 13:09:04 2017 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 00AB01293D6 for ; Mon, 3 Apr 2017 13:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-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 vjVoDgYi90Tp for ; Mon, 3 Apr 2017 13:09:00 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 6F7C2128990 for ; Mon, 3 Apr 2017 13:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491250140; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l5HnzSgNvVS10s9aENOeOhCQ4A8a9p6NeUHfshDjFHU=; b=aHGLbqJfL/dolSh8A4vXpsEJdC9OKFHUjHB3iidJOyz1TDtjfE8tekLtZZ0DflLp np6QCuSIVNr4TntehlWNX7AJANU7uyUvZ9a27GEjgaldT50mh/MUBnxOEwNml6zU VKOjXYzod53BA1D/eLToXjcY87oPPlcLkA/sQPJ4Tz8rJhmXggI53sUTJkb9KQ1c IJ4dTuv2IC4UQONVsOLvZih1gswNTs7Ajq0Z/fy2YH9jIFJMqFsi1WFi2iqAFC4p Ky+e7m32MlE67UaBX+rh8QDucMxwXTpMwr3HnrjPq3w7ZJeJTSCntJpe6tLxEwbs p7nPmNydlmpt++Bm/j8xbQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 17.ED.29388.CDBA2E85; Mon, 3 Apr 2017 13:09:00 -0700 (PDT) X-AuditID: 11973e11-822329a0000072cc-db-58e2abdc8451 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay3.apple.com (Apple SCV relay) with SMTP id EB.BB.03951.BDBA2E85; Mon, 3 Apr 2017 13:09:00 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from rui-imac.apple.com ([17.226.22.1]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONU00LB7NYZC180@nwk-mmpp-sz09.apple.com>; Mon, 03 Apr 2017 13:08:59 -0700 (PDT) Sender: rpaulo@apple.com Subject: Re: Reminder: QUIC WG meeting today, March 30, 14:00 UTC From: Rui Paulo In-reply-to: Date: Mon, 03 Apr 2017 13:08:59 -0700 Cc: IETF QUIC WG Content-transfer-encoding: quoted-printable Message-id: <194D0D22-AE79-430D-BE66-042B7A16D7E5@apple.com> References: To: Julian Reschke X-Mailer: Apple Mail (2.3421) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FAYrHtn9aMIg6YmYYvND9+wWvQs4HZg 8vjwMc5jyZKfTAFMUVw2Kak5mWWpRfp2CVwZH06uYC2YyFSxYM551gbGB4xdjJwcEgImEouO rWXpYuTiEBLYyygx9fgsJpjErZt32CASBxkl9k58xQyS4BUQlPgx+R5QBwcHs4C6xJQpuRA1 HUwSv08tYAOpERaQkNh/8iE7hO0osfftQ7A4m4CSxLO+E2BxTgEriebu62BxFgFVib7eVWCL mQUUJHZvhLiOWUBb4sm7C6wQe20k5n9+BtYrJGAp8fzqbbB6EQEtidv39kJ9IyvRuOUmM8hB EgIL2CQ2rNrKOIFReBaSu2ch3D0LyYoFjMyrGIVyEzNzdDPzjPQSCwpyUvWS83M3MYLCerqd 4A7G46usDjEKcDAq8fAucHoUIcSaWFZcmXuIUZqDRUmc1+fOvQghgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjC/Eg4IfrliiVD/T/mNeT03rCU/15ecZXZ0tgr6+WNrgcu+C2I7IWOXrm6fU 1b+b+sJEz9H+c2tWwZRDVzoDM3aF9PJyy2z6HdavesVn66utIeXXF/09HdAr2pX1sONz+rWj aeU1F1s/T532dVnolKJP/1fpTi9b+a1H6thO+ZqLzUwfk46kRSuxFGckGmoxFxUnAgBkAJkm TAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42IRbCgO0L2z+lGEwbvf7BabH75htehZwO3A 5PHhY5zHkiU/mQKYorhsUlJzMstSi/TtErgyPpxcwVowkaliwZzzrA2MDxi7GDk5JARMJG7d vMPWxcjFISRwkFFi78RXzCAJXgFBiR+T77F0MXJwMAuoS0yZkgtR08Ek8fvUAjaQGmEBCYn9 Jx+yQ9iOEnvfPgSLswkoSTzrOwEW5xSwkmjuvg4WZxFQlejrXcUEYjMLKEjs3ghxBLOAtsST dxdYIfbaSMz//AysV0jAUuL51dtg9SICWhK37+2FOlpWonHLTeYJjAKzkJw6C+HUWUimLmBk XsUoUJSak1hprJdYUJCTqpecn7uJERyGhcE7GP8sszrEKMDBqMTDu8DpUYQQa2JZcWXuIUYJ DmYlEd4rE4FCvCmJlVWpRfnxRaU5qcWHGKuAfpnILCWanA+MkbySeEMTEwMTY2MzY2NzE3Oq CCuJ82aV34sQEkhPLEnNTk0tSC2CWc7EwSnVwLj+jvKXpuVMfyO3r9JVU1aNE24SXhv3ckPZ /936ixzcDjY0ftOo5dxl7zovsJ856srjNwcWNjte7T0/5WfQQWm+hoD9iTbb24tSOngXXjlw sWJaH1vsbs+Ad2lPz2Yqfphx+UKLY6S8rPtLlkRWAwm9d0nOu15+aUiw/C8QaGaRpmXf+H/T CiWW4oxEQy3mouJEAJ1bCmieAgAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2017 20:09:02 -0000 On Mar 30, 2017, at 05:31, Julian Reschke wrote: >=20 > Agenda and remote participation details: >=20 > https://www.ietf.org/proceedings/98/agenda/agenda-98-quic-03 Some of these presentation links return 404. =E2=80=94 Rui Paulo From nobody Mon Apr 3 15:44:45 2017 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 0A1D71294AF for ; Mon, 3 Apr 2017 15:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 F5BkYf7520ua for ; Mon, 3 Apr 2017 15:44:42 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 DE3A7129450 for ; Mon, 3 Apr 2017 15:44:41 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id a140so19483853ita.0 for ; Mon, 03 Apr 2017 15:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iBxJhWelsGQyPzMamJfTHV89KCjsb2CJpA0yQTgkSYc=; b=isG34xi9rHn3nPPBvGOKsQj1LMuvxfafdfBERazarkUntXMoFTgS67ScDzhdLqfaL4 lZvTvmbjx6IlQHiMXH4g/KOtLSyObGC4/6TZq+bV9PS2P0hUCfGz9MvpPGRaC5aleDUN UjrMJ1sqGs7ul2qZymHSvzio3HOlhLk0XNCZSUOa0vKgSDt8B7w+Y7zh6qKG46JWOkFG iaWEZV1D/9Dp+Z6G2K6AGQTpXCTkAV0azLWWM3hwm1UIgjFXi/Ej1cm0UP65LHh3s2yn Lr5TF+rCzusMEqJwyiOzhdTeqd3xW5fHTHXzOge9cxdeAD88qhwtN9eQERTuXVgkzkhk Mveg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iBxJhWelsGQyPzMamJfTHV89KCjsb2CJpA0yQTgkSYc=; b=lQKsPZQ9eVEcRmzTuR7mCTomr9KZ3ACJxS4czbpu6aSIwLrVyHZO+BgZzTB6fG7PyT d40ac+YCCOdqyQLk+7jAETGJWQFjxPXnkCg2bD1TkCNhme2q/PP6wzInOUVnPPQNP2rc Pie63GR7Qtc3l6RUZVwEwiS+Cgn+a1Bt7BLeYrTH9Ccb9p4FLCafoChZ/sJRt98N6qsS 2rYNvpzg7JJC60WKzHo/Kmw2h/vFRivu6/MwxfKXFTkwzizd/JSsByu2r0SGBsza/7mY GLOdt9MrQs0QPAUaR/CxOVawErmqcjQ7OqWCmb+R/MYtc1gGqp3Q043Dcm+gTBtw58HF UH1A== X-Gm-Message-State: AFeK/H3g5HqqienojcaYizjJwENak1fb65C69jd4nnbH9vuQEiQUEs31rYgT7Cl1if8LF49JP71MYaeKIJKlfBJM X-Received: by 10.36.53.7 with SMTP id k7mr8904976ita.65.1491259481177; Mon, 03 Apr 2017 15:44:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.200.4 with HTTP; Mon, 3 Apr 2017 15:44:20 -0700 (PDT) In-Reply-To: <194D0D22-AE79-430D-BE66-042B7A16D7E5@apple.com> References: <194D0D22-AE79-430D-BE66-042B7A16D7E5@apple.com> From: "Charles 'Buck' Krasic" Date: Mon, 3 Apr 2017 15:44:20 -0700 Message-ID: Subject: Re: Reminder: QUIC WG meeting today, March 30, 14:00 UTC To: Rui Paulo Cc: Julian Reschke , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114accc6a5318b054c4ae789 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2017 22:44:44 -0000 --001a114accc6a5318b054c4ae789 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This might be better: https://github.com/quicwg/wg-materials/tree/master/ietf98 On Mon, Apr 3, 2017 at 1:08 PM, Rui Paulo wrote: > On Mar 30, 2017, at 05:31, Julian Reschke wrote: > > > > Agenda and remote participation details: > > > > https://www.ietf.org/proceedings/98/agenda/agenda-98-quic-03 > > Some of these presentation links return 404. > > =E2=80=94 > Rui Paulo > > > > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a114accc6a5318b054c4ae789 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 3, 2017 at 1:08 PM, Rui Paulo &= lt;rpaulo@apple.com> wrote:
On = Mar 30, 2017, at 05:31, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> Agenda and remote participation details:
>
>=C2=A0 https://www.ietf.org/pro= ceedings/98/agenda/agenda-98-quic-03

Some of these presentation links return 404.

=E2=80=94
Rui Paulo






--
= Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-114= 1

--001a114accc6a5318b054c4ae789-- From nobody Mon Apr 3 22:38:27 2017 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 1DC83127071 for ; Mon, 3 Apr 2017 22:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 e6bYkdHfGF1l for ; Mon, 3 Apr 2017 22:38:23 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 8773B124D37 for ; Mon, 3 Apr 2017 22:38:23 -0700 (PDT) X-AuditID: c1b4fb3a-7cfff70000005492-37-58e3314b54f9 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id FC.B6.21650.B4133E85; Tue, 4 Apr 2017 07:38:21 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 4 Apr 2017 07:38:19 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5UA9DlBaL0lPUlOou8B8Am4VsmIxjlpCag5f9FmIEi4=; b=S6n36B0KSkHZL240yN2UwdLPSgI2P6IRfZPovA4zDewsRjIS2v/oOkWLEXAnvnK9jl5CjDm4K4vxANR2P6Jp/0ITXdwbq7DZU+ZyOC83qZnUzopMk7aQXea5oOliBbmsTC1RRvs1Wd8oeATTpEmGnUoj5dfri7KF23umK1AiSj4= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 4 Apr 2017 05:38:18 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.1005.019; Tue, 4 Apr 2017 05:38:18 +0000 From: Ingemar Johansson S To: Ian Swett , "Jana Iyengar (jri@google.com)" CC: "quic@ietf.org" Subject: Question on sent_bytes in draft-ietf-quic-recovery Thread-Topic: Question on sent_bytes in draft-ietf-quic-recovery Thread-Index: AdKtBLwejiWQRsSLTG6s8+JuF1aGbA== Date: Tue, 4 Apr 2017 05:38:18 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [213.113.27.92] x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 7:G3L9jCrb5nShuKCgrHBfJM8nkOaozPHMiEbYOk32LN3AZo4jqY+AA0H+IU1ipHwv0yQs9QcqyiEc5WycTY8jTP4UB6aXvd1wxGHZwwm933y9SfoapBJFLmfcxnNJbEb5mWaLjN+d8FhGxqw4kWue9HAl7SWUYCN+TKtCuB3cp0Ya1B0dSPoyD4E0R2AiDvrRqTgXaC/wOchiNvvA8GpZuo/mS+zE7ZnPDG4JjesS+QgWvtuHHh+UglpzGCGmXa+ZBfARz/0HwclbtOFkoNqe3I1n0KgTJL87JBxxgrAMxpEfj6FBkbbL0FYLe7ENWzZQcU3welFrECjOi+i/Jro+Dg== x-ms-office365-filtering-correlation-id: 6a3367d6-35d8-4181-90b5-08d47b1ccc4d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB346; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39450400003)(39860400002)(39400400002)(39850400002)(39840400002)(74316002)(25786009)(53936002)(2906002)(230783001)(122556002)(50986999)(33656002)(54356999)(9326002)(3280700002)(3660700001)(7696004)(81166006)(99286003)(8676002)(6436002)(9686003)(236005)(8936002)(55016002)(54896002)(6306002)(2900100001)(5660300001)(7736002)(3846002)(66066001)(102836003)(6116002)(790700001)(38730400002)(189998001)(86362001)(6506006)(19609705001)(4326008)(77096006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3483C8A8ADB8FA9304F31F6C20B0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 05:38:18.0836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGOffebXfm4LQU3/z4w1lJfmwpYqYrDREtUgSJzP7IoZc50im7 aikYMpBQ+5Ca4Jahk6FotsBqFmToUiOkFLIvNQ0nWVkqSTO1tG2nwP9+53me8/I+h8PS0k6B P6vRlnI6rapQJvRijNm9wZHpUY7sA/p1Rdza9CNB3PUhMxN3uXVHEp3W2lOWZrGsUZlUjpcy nyvUlHM6xZFcr4KXy6OCErvygt6YWo3extYhMQs4Br7WTwjrkBcrxXcRbJinaXJ4hsBY0+Jx GHyFBsePagFxGimYs95C7vtSPITA8jHLzUKshE77qkf3wadgbOAG7WYah4BhxH1ZzO7CCbB4 p9mls65MEowtMSQuh/5Lg5RbZvAeaNvc7ZYlOAem/1iFbkY4CGZWpxky0Q8m5loo0gCD5fEo TdgXvjg2PWsifA3Bq4VJz0zAwTBoOE8y9a4uv0MIp4PTOoUIV8FsvUNEWAOmxqV/88+AYbjO 8w6ARylYaeoXEiMQprr1ImKsMDDZ1U2Rjv7wYbwWEQ6Ez1N9ArJ1MfQtXhWSZjvhuXGOaUD7 TNsKmbbFTNtiRJfDu0aDkHA4tJsXaMKR0LRpZ7brrUjUhXx5jueL1NHRck6nyeP5Yq1cy5X2 INcHGri/Ef8QDcwftSPMIpm3JPfkbLZUoCrnK4rsCFha5iNpyHBJknxVRSWnKz6rKyvkeDsK YBmZnyTpyVi2FKtVpdw5jivhdP9dihX7V6O9QZ3D4eURnxa9UzoOb/3qiywKiXnR1PTzdOw9 Z0DMzVDdeG/Y2reC+e+qGsXtCr+BE2q7rUvqXM/Vz2RVHlO0acQZ0U/zRqwzyW8OvreZQ49T 2q1MW0q8MfFiSs1rWy2d+iARG6T7c2yHRFWTzavrHeJkZ4Sf2lye0K5YVobLGL5AFRVG63jV X+juQmE8AwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 05:38:26 -0000 --_000_DB4PR07MB3483C8A8ADB8FA9304F31F6C20B0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Working on an update of the QUIC ECN draft. Stumbled on the sent_bytes metric (which will be complemented with ECN mark= ed bytes et.c ) Which layers does the sent_bytes metric include ? I would assume that the IP layer is included ? and that would of course be = useful for instance if ConEx ever happens (RFC6789). On the other hand I wonder how straightforward it is to get the IP header s= ize form the application layer, it may be easy, and it may be tricky. In any case this needs clarification. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB3483C8A8ADB8FA9304F31F6C20B0DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Working on an update of the QUIC ECN draft.

Stumbled on the sent_bytes metric (which will be com= plemented with ECN marked bytes et.c )

 

Which layers does the sent_bytes metric include ?

I would assume that the IP layer is included ? and t= hat would of course be useful for instance if ConEx ever happens (RFC6789).

On the other hand I wonder how straightforward it is= to get the IP header size form the application layer, it may be easy, and = it may be tricky.

In any case this needs clarification.

 

/Ingemar

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB3483C8A8ADB8FA9304F31F6C20B0DB4PR07MB348eurprd_-- From nobody Wed Apr 5 01:04:43 2017 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 A9C161243F6 for ; Wed, 5 Apr 2017 01:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 4pEaGP4mbNKl for ; Wed, 5 Apr 2017 01:04:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 65B1D126579 for ; Wed, 5 Apr 2017 01:04:39 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-3c-58e4a5153ffe Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 5D.C7.21650.515A4E85; Wed, 5 Apr 2017 10:04:37 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 5 Apr 2017 10:04:34 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T01Cwx94EGe43CdLHwRzoIYWrZnSKLLV6XexzAcELzc=; b=JbelmVsb5nzI9J408aV1QNdP6STgy6dPV3xZ5T1PA+DfIWCDigQTTkvrAAVufo3g4mLLXiBZP7d65FwYFqm+5Uw4PoixBjI49ElhVfBim2v00unKhp2so/grVL1n9/wYrg2rL2Ny0YjvZD3hbeP1VIqjCBBBRVNiyMyit+r93ZE= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Wed, 5 Apr 2017 08:04:34 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.1005.020; Wed, 5 Apr 2017 08:04:33 +0000 From: Ingemar Johansson S To: "quic@ietf.org" CC: "De Schepper, Koen (Nokia - BE/Antwerp)" , "'mirja.kuehlewind@tik.ee.ethz.ch'" , Praveen Balasubramanian , "Bob Briscoe (ietf@bobbriscoe.net)" , marcelo bagnulo braun , "Piers O'Hanlon" , Ingemar Johansson S Subject: FW: New Version Notification for draft-johansson-quic-ecn-02.txt Thread-Topic: New Version Notification for draft-johansson-quic-ecn-02.txt Thread-Index: AQHSreJMjEBaVvoF4E2LNsloIdEQAaG2aOMw Date: Wed, 5 Apr 2017 08:04:33 +0000 Message-ID: References: <149137901909.1128.8119024167653153243.idtracker@ietfa.amsl.com> In-Reply-To: <149137901909.1128.8119024167653153243.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.82] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:8EhfY8N5rAzA9l0XRKNnsdBUT5xXnANVx5dJzFZb7P84wiEgYUzyum2vylgTH/kZlY4bIs5FCV1uWMuZCKSWqJ6T0OMWclT5OL4/wattA5OxURNCAoVy8ehtna/U04u6/1Z7tbtFIe+ziEZMJDv0n7Q76uVwfqHThGrm4a8dkofUqNVwBiJagybi/s6gt8bZua18gdQITQ3F0eWKas4VC5U3vMrGYjDCn6BtRaNrEbn46BKv2zAT4kTHeikWdbS2kRirBNOV8CE8ojPInYS/kas7DeVdvyuYmbxW7tAwcj0iX/z0Jt8cvtjImqmYsl7lFUb6TUwSD7s44kh5tuYwoQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39840400002)(39860400002)(39410400002)(39850400002)(39450400003)(377424004)(13464003)(2501003)(3660700001)(2900100001)(230783001)(4326008)(8936002)(8676002)(1730700003)(81166006)(6306002)(122556002)(2351001)(3280700002)(74316002)(54906002)(6436002)(6506006)(2473003)(99286003)(5640700003)(9686003)(8666007)(66066001)(2906002)(189998001)(33656002)(7736002)(305945005)(229853002)(77096006)(55016002)(110136004)(15650500001)(25786009)(53546009)(7696004)(54356999)(3846002)(102836003)(6116002)(50986999)(76176999)(2950100002)(86362001)(107886003)(6916009)(38730400002)(53936002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 819a7f4f-62cf-4f36-c58e-08d47bfa6545 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB345; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(72170088055959)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 0268246AE7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 08:04:33.5372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTURzn3Neu2uI0tf4sBVsvtLKSiBUS2hdXNHpQJFbU0IvOdNmujjQi C610ClaL0sTU1HAmmolaaNrMxz5UAx/JyqZomUomlZsVVt7dBX37vf7n/P6Hw5KyZlrOanWp nF6nSVIw3lRhdPP2Tf6V49FbalsDlV2jpbSy21lJKLM/mBllfY2JUjZceUwrp/PGkDKv1CdC oppy2GjVwrUmSlVR8YNQOd88olXZLQsS1WVnOaPqnp1jDkhivMPjuCStgdNv3nXKO6F+oIxJ GVp+7qrxkiQT5S3PRV4s4G0wP2FncpE3K8N1CJpaZz2kB8GL6VFCIBTOJ+H2xLTHuUVA7Vw1 EkkXAsudHCQcxuBwqLa43NgPr4biyvsSIUTichJs7XZCMHzxHijIK6RyEbsY2gtWx1kxHwbT 1h5SwBReA0NznyUCluIYsDlL3KMyvA/KsgYZAXthNbx0PXRjhAPB4XpPCZjEK8A+fo8Ql8NQ 0fqaFLE/TI79poU+CBsRzJYMEkIHwEHQOSUVdMBGEnpriimRmBho7Gn3TKvhZ0EfI+ILMJKT 6blBC23DTZ7MMegoMxPi8GsCvncuSEQjAD71PqDF7eUw3C8+l6+gv2ujC1Bw0X/NixZLkTgY 6p5uFuVVYDKOSorcj7EMrIXjVCmizMif53g+OT4sLJTTa2N5/owuVMelNqDF7/S88dfOFvR8 ItKCMIsUS6QjVWPRMlpj4NOTLQhYUuEnPV6+KEnjNOkZnP7MSX1aEsdb0EqWUqyQRjyzRctw vCaVO81xKZz+n0uwXvJMlBg3sN+VZAv6WjBf3rtW27/DnvGq0Xq4uuPt+kM519fZqmBmZCi0 I7E+FxX+tp4wb1zfXeyajPqi3n334gZDYNfCPt/svqz+hJz4G7cNG7sMASHHm7LCl+7ykdf+ SQuZcX27mfWh773THFFyVH0+Kj/zwLvIiCMfh02xN9MOnn2yxaGg+ATN1hBSz2v+AmOxIgpK AwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2017 08:04:42 -0000 SGkNCkkganVzdCB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBFQ04gUVVJQyBkcmFmdC4g VGhlIG1haW4gY2hhbmdlcyBhcmUgOg0KMSkgYWRkZWQgYSBtb3JlIGRlc2NyaXB0aXZlIHRleHQg d2hhdCBFQ04gaXMgYWJvdXQNCjIpIEFuIGltcHJvdmVkIGRlc2NyaXB0aW9uIG9mIHRoZSBFQ04g bmVnb3RpYXRpb24NCjMpIHJlbW92ZWQgdHdvIG9mIHRoZSBhbHRlcm5hdGl2ZXMgZm9yIHRoZSBF Q04gZWNobywgZ2l2ZW4gYSBkaXNjdXNzaW9uIHdpdGggS29lbiwgTWlyamEgYW5kIFByYXZlZW4g d2UgZGVjaWRlZCB0aGF0IGl0IHNob3VsZCBiZSBzdWZmaWNpZW50IHRvIGluZGljYXRlIG51bWJl ciBvZiBieXRlcyBtYXJrZWQuDQoNClJlZ2FyZHMNCkluZ2VtYXINCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IGRlbiA1IGFwcmlsIDIwMTcgMDk6NTcNClRv OiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4N ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtam9oYW5zc29uLXF1 aWMtZWNuLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qb2hhbnNzb24t cXVpYy1lY24tMDIudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSW5nZW1h ciBKb2hhbnNzb24gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJRUNOIHN1cHBv cnQgaW4gUVVJQw0KRG9jdW1lbnQgZGF0ZToJMjAxNy0wNC0wNA0KR3JvdXA6CQlJbmRpdmlkdWFs IFN1Ym1pc3Npb24NClBhZ2VzOgkJMTINClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAyLnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvaGFu c3Nvbi1xdWljLWVjbi8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAyDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDIN CkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt am9oYW5zc29uLXF1aWMtZWNuLTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIG91dGxpbmVz IHRoZSBFQ04gKEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uKSBzdXBwb3J0DQogICBp biBRVUlDLiAgVGhlIGRyYWZ0IHNwZWNpZmllcyB0aGUgRUNOIG5lZ290aWF0aW9uIGFuZCB0aGUg RUNOIGVjaG8NCiAgIGFuZCBpbiBhZGRpdGlvbiwgZGlmZmVyZW50IGFzcGVjdHMgb2YgZmFsbGJh Y2sgaW4gY2FzZSBvZiBFQ04gZmFpbHVyZQ0KICAgYXMgd2VsbCBhcyBPUyBzcGVjaWZpYyBpc3N1 ZXMgd2l0aCBFQ04gYW5kIG1vbml0b3JpbmcgZm9yIEVDTg0KICAgY2FwYWJpbGl0eS4gIFRoZSBp bnRlbnRpb24gaXMgdGhhdCBtb3N0IG9mIHRoZSBtYXRlcmlhbCBlbmRzIHVwDQogICB1cGRhdGlu ZyBvdGhlciBuZXcgb3IgZXhpc3RpbmcgUVVJQyBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucywgdGh1 cyBpdA0KICAgbWF5IGJlIHBvc3NpYmxlIHRoYXQgdGhpcyBkcmFmdCBkb2VzIG5vdCB3YXJyYW50 IGEgd29ya2luZyBncm91cA0KICAgc3RhdHVzLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From nobody Fri Apr 7 11:58:15 2017 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 35FFB129531 for ; Fri, 7 Apr 2017 11:58:14 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 kaoK9jrJ0rvx for ; Fri, 7 Apr 2017 11:58:11 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 7250112949B for ; Fri, 7 Apr 2017 11:58:11 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id p68so45217592qke.1 for ; Fri, 07 Apr 2017 11:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qHf131CsQFgctXgrN8p3QZvWHGA4GQVyqoGG7ecHPeE=; b=ZJuafi1FDhHYgbu6cNoiCVP6xWQP/oSrWhnyQw9jBEiqggEVH1A5ZeBRt4gC8mPeHp pX6D5ABUiAOXHfETVYrmx2FV4HTe9U2AoCOfirkcH/Blbzk2uJ+RAU2k/rZ+CdAwxHKZ WwiuiLPlLHXSr68GEKvy9mV9rjSmEa7YG4sMh68zDJRdJbz8T9Cb4bwtVHzWtPIP1QtL iVVs0/LjgloLNOrg1CpymVkgZMCqa+DqFCrRY/qU5eD+I2T5VxByZxjOFnGFAtFfXHeM epy9qT4e2O+0c7XlOOhDkk/vcvsgZGaLEPzvRfVLMdvm3VclWcseVrFkLWsww4InOdSg OuVA== 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=qHf131CsQFgctXgrN8p3QZvWHGA4GQVyqoGG7ecHPeE=; b=FloJzD/l+ovKJ40aLZMXozpvdMZ3NEs5hrjjHy46weXq7kKa6DXKgLKHQ+mH0UuOqg 1L0Vx32HJPRDxjTRLQZKWPucASujzbYjdaF7FcQq9nxKWkmnS2OAH/LyAUn7RydArvOX PscScAaNB7bNhGn6x5gAE1AjYUWYcXq33rONHAeYw96puQ0B3UtYjQD55lI+fQyMdj+d 0ftvxOBsGvuI7RggVVzuuaQZzoIPgQff4TwZfBCKCPjoMr3ODGbHgzTwiB46VdC5IcwM IxoFfzmCP8bFL+yWpWvkWAKgy3Ix4psEOj9hUsNsKhJ7orlLAriaAxDKkH7d9LWl09KW EoUA== X-Gm-Message-State: AN3rC/4/HVqevqa2DUrbGV1z1EY7HIUpZU+SGqza/99ae27K9AKK5gApvdvPftRDwBoHXfYYR6ls2K6UoBUVhDjV X-Received: by 10.55.93.193 with SMTP id r184mr3085665qkb.221.1491591490361; Fri, 07 Apr 2017 11:58:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.76.7 with HTTP; Fri, 7 Apr 2017 11:58:10 -0700 (PDT) From: Victor Vasiliev Date: Fri, 7 Apr 2017 14:58:10 -0400 Message-ID: Subject: Revisiting 0-RTT transport parameter negotiation To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114ed8eeef6381054c983496 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Apr 2017 18:58:14 -0000 --001a114ed8eeef6381054c983496 Content-Type: text/plain; charset=UTF-8 There was a question of what should the client assume about the server's transport parameters in 0-RTT case. As a result of the discussion at the interim, we arrived to the state where client is allowed to assume either the parameters from the previous session, or the default values. Server may choose whatever parameters it wants, and if that's incompatible with client's assumption of server's 0-RTT parameters, the server may reply with an appropriate error or RST_STREAM, after which the client is supposed to retry the connection. I personally find that this solution has "too many joints", as in, it allows implementations a wide variety of behaviors, which in turn requires their peers to accommodate those scenarios. The situation with the initial flow control window is especially awkward. Server might choose to excuse flow control violations until the 1-RTT phase is reached, which requires client to accommodate possible flow control window decrease upon receiving server hello; or it might choose not to excuse them, which requires client to retry by special-casing QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA shortly after 0-RTT as a retry signal. All of this adds a complexity burden onto implementations, and makes comprehensive interop testing very hard. Instead of the current negotiation scheme outlined in the draft, I propose that we adapt a simple scheme similar to what TLS does with cryptographic parameters and 0-RTT: 1) Client sends its vision of server's assumed parameters in the ClientHello, and is expected to follow them in 0-RTT packets. 2) Server either accepts those parameters, or declines 0-RTT altogether, by discarding the 0-RTT data and following up with a full 1-RTT handshake. If server accepts 0-RTT, its parameters in the 1-RTT server hello cannot be more limited than what it accepted from the client. In this scenario, both the client and the server can use their regular connection handling logic for 0-RTT data, since both the client and the server have a consistent view of server's parameters. This works well when the parameters match expectations (most of the time), it's simple to implement, and it's simple to test. -- Victor. --001a114ed8eeef6381054c983496 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There was a question of what should the client assume abou= t the server's
transport parameters in 0-RTT case.=C2=A0 As a= result of the discussion at the
interim, we arrived to the state= where client is allowed to assume either the
parameters from the= previous session, or the default values.=C2=A0 Server may choose
whatever parameters it wants, and if that's incompatible with client&#= 39;s
assumption of server's 0-RTT parameters, the server may = reply with an
appropriate error or RST_STREAM, after which the cl= ient is supposed to retry
the connection.

I personally find that this solution has "too many joints"= , as in, it allows
implementations a wide variety of behaviors, w= hich in turn requires their peers
to accommodate those scenarios.= =C2=A0 The situation with the initial flow control
window is espe= cially awkward.=C2=A0 Server might choose to excuse flow control
= violations until the 1-RTT phase is reached, which requires client to
=
accommodate possible flow control window decrease upon receiving serve= r hello;
or it might choose not to excuse them, which requires cl= ient to retry by
special-casing QUIC_FLOW_CONTROL_RECEIVED_TOO_MU= CH_DATA shortly after 0-RTT as
a retry signal.=C2=A0 All of this = adds a complexity burden onto implementations, and
makes comprehe= nsive interop testing very hard.

Instead of = the current negotiation scheme outlined in the draft, I propose that
<= div>we adapt a simple scheme similar to what TLS does with cryptographic pa= rameters
and 0-RTT:
=C2=A0 1) Client sends its vision o= f server's assumed parameters in the ClientHello,
=C2=A0 =C2= =A0 =C2=A0and is expected to follow them in 0-RTT packets.
=C2=A0= 2) Server either accepts those parameters, or declines 0-RTT altogether,
=C2=A0 =C2=A0 =C2=A0by discarding the 0-RTT data and following up = with a full 1-RTT handshake.
If server accepts 0-RTT, its paramet= ers in the 1-RTT server hello cannot be
more limited than what it= accepted from the client.

In this scenario, both = the client and the server can use their regular
connection handli= ng logic for 0-RTT data, since both the client and the server
hav= e a consistent view of server's parameters.=C2=A0 This works well when = the
parameters match expectations (most of the time), it's si= mple to implement, and
it's simple to test.
<= br>
=C2=A0 -- Victor.
--001a114ed8eeef6381054c983496-- From nobody Fri Apr 7 12:16:07 2017 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 EAB4212422F for ; Fri, 7 Apr 2017 12:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 F8dFOdOZEdnC for ; Fri, 7 Apr 2017 12:16:03 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 6B58612420B for ; Fri, 7 Apr 2017 12:16:03 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id c45so26861569qtb.1 for ; Fri, 07 Apr 2017 12:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HXTGmpC58danKOUsXbxIqE0E34CaKpxFWmJsyeJ+D2U=; b=llyArMtDKQIV1nQVShLdOoOC7s5U4WDkiEpxVVO8wXRqv4I3B4G7OXw9CiJ9uc0gqK a7jnch3Bn6aAhb6nx0kZL2I+x//hhKTqnG3gg1jb2CccHuJXu60dvlk+cFSj3DXW+D8u +Wpq/Ch1q39K7FOV3XgDnOLKkxRPbUXjSxEYoyBUJpvqpxV9YctM+BOCREbwPkaw4OiF 0zbc5NIDcgOUvnyhHVjBRm6TDAufXbaz2yk9PHQNIZOoWQiRQx38pfApXIKSXf0B5YGB pUKft3u3REgmHmOXOzQ3cm2K2hlMztEpUo13AieoUdl3kX5DYNhx28naDqoemCWW6Khm sUQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HXTGmpC58danKOUsXbxIqE0E34CaKpxFWmJsyeJ+D2U=; b=H0NxaSxHVFEgN9nzcJC4aFUeHJCRIg5kjt/a5IKqU2TVkgwToIafTA107BRJwA8dap hS4igj+NiRrSp3JvbGpw66Ri2/DkQV3/t9dM6mq1kj3lO7kzePsQu1AnNBq4tU/r/qC6 xoxsqgztCNWoDDoTJq+alhWuqPSmQaXogBqPVhVyCYp3cvlDT2gN+5C+Pp0oPZFsT0lr 098CvJMKI71j3e7QLlndbuORSsqanb+HlvDNIlRnUaa7JRi+CiwsBFCAesaNrDdDiOz/ wjA8LNHAyAyjdHq/Ca10vywmeV3CZslNizted7wwv85KJgbEck2iI91XgQwUrNCzWFEt DsVA== X-Gm-Message-State: AFeK/H2QZw0uLP5OyfRzuYAjYdZNpDbY4wCaIfN6XLtOuAC5CmDJfLJOLFsjT12LT46okH9DLbj8SH/Sfw6FLA== X-Received: by 10.237.45.198 with SMTP id i64mr45807110qtd.238.1491592562426; Fri, 07 Apr 2017 12:16:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.41 with HTTP; Fri, 7 Apr 2017 12:16:02 -0700 (PDT) In-Reply-To: References: From: "Aron ." Date: Fri, 7 Apr 2017 15:16:02 -0400 Message-ID: Subject: Re: Revisiting 0-RTT transport parameter negotiation To: Victor Vasiliev Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c124b7ad54c0c054c9874d0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Apr 2017 19:16:06 -0000 --94eb2c124b7ad54c0c054c9874d0 Content-Type: text/plain; charset=UTF-8 +1, FWIW --94eb2c124b7ad54c0c054c9874d0 Content-Type: text/html; charset=UTF-8
+1, FWIW
--94eb2c124b7ad54c0c054c9874d0-- From nobody Fri Apr 7 12:57:58 2017 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 CC88D1267BB for ; Fri, 7 Apr 2017 12:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 nSj9B8to_Fjl for ; Fri, 7 Apr 2017 12:57:45 -0700 (PDT) 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 B92DF129457 for ; Fri, 7 Apr 2017 12:57:39 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v37Jv8iC024579; Fri, 7 Apr 2017 20:57:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Eujbc+DgvL0VU1cYhiHRsPatmUf2zXkyJ4rtCFniYBM=; b=YiLmZDbYakwUaANoI9zVgnwaEYm5qkSv6heDMEPZbX83AwxFjspwGdRuvAPoPchKr001 1543uBdJNvxAoRbeb00LjxZtAaGx0ym6yi7qGIY+EK1SPgLhBKqCjJ9mghq0xmtN6L0Y 3+hG3IJJcRfuAaXZkKbHn2pDUiAPTAsRSpFkaP1Qahy1g+B8a9XHSRSonsMfaR5T/ZY2 O5/tIdF7Lba9GV0xrHJXATfK4TrxlIzdYL/c5bkXz+hpy0MAh2Qm3l95L5KlLE5I4sHu Jw43MjK7oWvyetnH0ONpbOYJWkz0vPm+yWeTQuhdS9ElTh02wn/d8pU3VgNsc8+XSayA 5Q== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 29p3rm4bvj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Apr 2017 20:57:37 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v37Ju62e007722; Fri, 7 Apr 2017 15:57:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint3.akamai.com with ESMTP id 29j7hv9mdv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Apr 2017 15:57:36 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 7 Apr 2017 15:57:34 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Fri, 7 Apr 2017 15:57:34 -0400 From: "Lubashev, Igor" To: Victor Vasiliev , IETF QUIC WG Subject: RE: Revisiting 0-RTT transport parameter negotiation Thread-Topic: Revisiting 0-RTT transport parameter negotiation Thread-Index: AQHSr9Dtu8SN8g35nkqK7tpxVLp2vqG6UnvA Date: Fri, 7 Apr 2017 19:57:34 +0000 Message-ID: <0248e010b13d47a8ab8bc86f9b42970e@usma1ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.240] Content-Type: multipart/alternative; boundary="_000_0248e010b13d47a8ab8bc86f9b42970eusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-07_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704070163 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-07_17:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704070163 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Apr 2017 19:57:48 -0000 --_000_0248e010b13d47a8ab8bc86f9b42970eusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGlzIHNlZW1zIHRvIHdvcmsgYW5kIGlzIHNpbXBsZSBlbm91Z2guICBJdCB3b3VsZCBh bHNvIGNsb3NlIGlzc3VlIDQyNTxodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRz L2lzc3Vlcy80MjU+Lg0KDQoNCi0gICAgICAgICAgSWdvcg0KDQpGcm9tOiBWaWN0b3IgVmFzaWxp ZXYgW21haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb21dDQpTZW50OiBGcmlkYXksIEFwcmlsIDA3LCAy MDE3IDI6NTggUE0NClRvOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZXZpc2l0aW5nIDAtUlRUIHRyYW5zcG9ydCBwYXJhbWV0ZXIgbmVnb3RpYXRpb24NCg0KVGhlcmUg d2FzIGEgcXVlc3Rpb248aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lzc3Vlc18xMjYmZD1E d01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0 emNJeHlqVVpkbl9tNTVLUG1sbyZtPXJTdWhfS3B3aUZXS2cyMzYwNE0yaXo4VEV0SDNaMEhCQTha R1pVMS1ra1Emcz1HaHhWTXdGdFkySzlYaTNTZm5LdEMyUnJDQlFLNUNvMFhSWHk5c2o5TmlZJmU9 PiBvZiB3aGF0IHNob3VsZCB0aGUgY2xpZW50IGFzc3VtZSBhYm91dCB0aGUgc2VydmVyJ3MNCnRy YW5zcG9ydCBwYXJhbWV0ZXJzIGluIDAtUlRUIGNhc2UuICBBcyBhIHJlc3VsdCBvZiB0aGUgZGlz Y3Vzc2lvbiBhdCB0aGUNCmludGVyaW0sIHdlIGFycml2ZWQgdG8gdGhlIHN0YXRlIHdoZXJlIGNs aWVudCBpcyBhbGxvd2VkIHRvIGFzc3VtZSBlaXRoZXIgdGhlDQpwYXJhbWV0ZXJzIGZyb20gdGhl IHByZXZpb3VzIHNlc3Npb24sIG9yIHRoZSBkZWZhdWx0IHZhbHVlcy4gIFNlcnZlciBtYXkgY2hv b3NlDQp3aGF0ZXZlciBwYXJhbWV0ZXJzIGl0IHdhbnRzLCBhbmQgaWYgdGhhdCdzIGluY29tcGF0 aWJsZSB3aXRoIGNsaWVudCdzDQphc3N1bXB0aW9uIG9mIHNlcnZlcidzIDAtUlRUIHBhcmFtZXRl cnMsIHRoZSBzZXJ2ZXIgbWF5IHJlcGx5IHdpdGggYW4NCmFwcHJvcHJpYXRlIGVycm9yIG9yIFJT VF9TVFJFQU0sIGFmdGVyIHdoaWNoIHRoZSBjbGllbnQgaXMgc3VwcG9zZWQgdG8gcmV0cnkNCnRo ZSBjb25uZWN0aW9uLg0KDQpJIHBlcnNvbmFsbHkgZmluZCB0aGF0IHRoaXMgc29sdXRpb24gaGFz ICJ0b28gbWFueSBqb2ludHMiLCBhcyBpbiwgaXQgYWxsb3dzDQppbXBsZW1lbnRhdGlvbnMgYSB3 aWRlIHZhcmlldHkgb2YgYmVoYXZpb3JzLCB3aGljaCBpbiB0dXJuIHJlcXVpcmVzIHRoZWlyIHBl ZXJzDQp0byBhY2NvbW1vZGF0ZSB0aG9zZSBzY2VuYXJpb3MuICBUaGUgc2l0dWF0aW9uIHdpdGgg dGhlIGluaXRpYWwgZmxvdyBjb250cm9sDQp3aW5kb3cgaXMgZXNwZWNpYWxseSBhd2t3YXJkLiAg U2VydmVyIG1pZ2h0IGNob29zZSB0byBleGN1c2UgZmxvdyBjb250cm9sDQp2aW9sYXRpb25zIHVu dGlsIHRoZSAxLVJUVCBwaGFzZSBpcyByZWFjaGVkLCB3aGljaCByZXF1aXJlcyBjbGllbnQgdG8N CmFjY29tbW9kYXRlIHBvc3NpYmxlIGZsb3cgY29udHJvbCB3aW5kb3cgZGVjcmVhc2UgdXBvbiBy ZWNlaXZpbmcgc2VydmVyIGhlbGxvOw0Kb3IgaXQgbWlnaHQgY2hvb3NlIG5vdCB0byBleGN1c2Ug dGhlbSwgd2hpY2ggcmVxdWlyZXMgY2xpZW50IHRvIHJldHJ5IGJ5DQpzcGVjaWFsLWNhc2luZyBR VUlDX0ZMT1dfQ09OVFJPTF9SRUNFSVZFRF9UT09fTVVDSF9EQVRBIHNob3J0bHkgYWZ0ZXIgMC1S VFQgYXMNCmEgcmV0cnkgc2lnbmFsLiAgQWxsIG9mIHRoaXMgYWRkcyBhIGNvbXBsZXhpdHkgYnVy ZGVuIG9udG8gaW1wbGVtZW50YXRpb25zLCBhbmQNCm1ha2VzIGNvbXByZWhlbnNpdmUgaW50ZXJv cCB0ZXN0aW5nIHZlcnkgaGFyZC4NCg0KSW5zdGVhZCBvZiB0aGUgY3VycmVudCBuZWdvdGlhdGlv biBzY2hlbWUgb3V0bGluZWQgaW4gdGhlIGRyYWZ0LCBJIHByb3Bvc2UgdGhhdA0Kd2UgYWRhcHQg YSBzaW1wbGUgc2NoZW1lIHNpbWlsYXIgdG8gd2hhdCBUTFMgZG9lcyB3aXRoIGNyeXB0b2dyYXBo aWMgcGFyYW1ldGVycw0KYW5kIDAtUlRUOg0KICAxKSBDbGllbnQgc2VuZHMgaXRzIHZpc2lvbiBv ZiBzZXJ2ZXIncyBhc3N1bWVkIHBhcmFtZXRlcnMgaW4gdGhlIENsaWVudEhlbGxvLA0KICAgICBh bmQgaXMgZXhwZWN0ZWQgdG8gZm9sbG93IHRoZW0gaW4gMC1SVFQgcGFja2V0cy4NCiAgMikgU2Vy dmVyIGVpdGhlciBhY2NlcHRzIHRob3NlIHBhcmFtZXRlcnMsIG9yIGRlY2xpbmVzIDAtUlRUIGFs dG9nZXRoZXIsDQogICAgIGJ5IGRpc2NhcmRpbmcgdGhlIDAtUlRUIGRhdGEgYW5kIGZvbGxvd2lu ZyB1cCB3aXRoIGEgZnVsbCAxLVJUVCBoYW5kc2hha2UuDQpJZiBzZXJ2ZXIgYWNjZXB0cyAwLVJU VCwgaXRzIHBhcmFtZXRlcnMgaW4gdGhlIDEtUlRUIHNlcnZlciBoZWxsbyBjYW5ub3QgYmUNCm1v cmUgbGltaXRlZCB0aGFuIHdoYXQgaXQgYWNjZXB0ZWQgZnJvbSB0aGUgY2xpZW50Lg0KDQpJbiB0 aGlzIHNjZW5hcmlvLCBib3RoIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXIgY2FuIHVzZSB0aGVp ciByZWd1bGFyDQpjb25uZWN0aW9uIGhhbmRsaW5nIGxvZ2ljIGZvciAwLVJUVCBkYXRhLCBzaW5j ZSBib3RoIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXINCmhhdmUgYSBjb25zaXN0ZW50IHZpZXcg b2Ygc2VydmVyJ3MgcGFyYW1ldGVycy4gIFRoaXMgd29ya3Mgd2VsbCB3aGVuIHRoZQ0KcGFyYW1l dGVycyBtYXRjaCBleHBlY3RhdGlvbnMgKG1vc3Qgb2YgdGhlIHRpbWUpLCBpdCdzIHNpbXBsZSB0 byBpbXBsZW1lbnQsIGFuZA0KaXQncyBzaW1wbGUgdG8gdGVzdC4NCg0KICAtLSBWaWN0b3IuDQo= --_000_0248e010b13d47a8ab8bc86f9b42970eusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1NjM0NDg5MDI7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwMTIxMDc5MzQgMjA3 Mzg1MDc3MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywgdGhpcyBzZWVtcyB0byB3b3JrIGFuZCBpcyBz aW1wbGUgZW5vdWdoLiZuYnNwOyBJdCB3b3VsZCBhbHNvIGNsb3NlDQo8YSBocmVmPSJodHRwczov L2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy80MjUiPmlzc3VlIDQyNTwvYT4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkln b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFZp Y3RvciBWYXNpbGlldiBbbWFpbHRvOnZhc2lsdnZAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEFwcmlsIDA3LCAyMDE3IDI6NTggUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYg UVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmV2aXNp dGluZyAwLVJUVCB0cmFuc3BvcnQgcGFyYW1ldGVyIG5lZ290aWF0aW9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSB3YXMgPGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRo dWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lzc3Vlc18xMjYmYW1wO2Q9RHdNRmFRJmFtcDtj PTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJ eHlqVVpkbl9tNTVLUG1sbyZhbXA7bT1yU3VoX0twd2lGV0tnMjM2MDRNMml6OFRFdEgzWjBIQkE4 WkdaVTEta2tRJmFtcDtzPUdoeFZNd0Z0WTJLOVhpM1Nmbkt0QzJSckNCUUs1Q28wWFJYeTlzajlO aVkmYW1wO2U9Ij4NCmEgcXVlc3Rpb248L2E+IG9mIHdoYXQgc2hvdWxkIHRoZSBjbGllbnQgYXNz dW1lIGFib3V0IHRoZSBzZXJ2ZXInczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+dHJhbnNwb3J0IHBhcmFtZXRlcnMgaW4gMC1SVFQgY2FzZS4mbmJz cDsgQXMgYSByZXN1bHQgb2YgdGhlIGRpc2N1c3Npb24gYXQgdGhlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbnRlcmltLCB3ZSBhcnJpdmVkIHRv IHRoZSBzdGF0ZSB3aGVyZSBjbGllbnQgaXMgYWxsb3dlZCB0byBhc3N1bWUgZWl0aGVyIHRoZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGFyYW1l dGVycyBmcm9tIHRoZSBwcmV2aW91cyBzZXNzaW9uLCBvciB0aGUgZGVmYXVsdCB2YWx1ZXMuJm5i c3A7IFNlcnZlciBtYXkgY2hvb3NlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj53aGF0ZXZlciBwYXJhbWV0ZXJzIGl0IHdhbnRzLCBhbmQgaWYgdGhh dCdzIGluY29tcGF0aWJsZSB3aXRoIGNsaWVudCdzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hc3N1bXB0aW9uIG9mIHNlcnZlcidzIDAtUlRUIHBh cmFtZXRlcnMsIHRoZSBzZXJ2ZXIgbWF5IHJlcGx5IHdpdGggYW48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFwcHJvcHJpYXRlIGVycm9yIG9yIFJT VF9TVFJFQU0sIGFmdGVyIHdoaWNoIHRoZSBjbGllbnQgaXMgc3VwcG9zZWQgdG8gcmV0cnk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBjb25u ZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBwZXJzb25hbGx5IGZpbmQgdGhhdCB0aGlzIHNvbHV0aW9uIGhhcyAmcXVv dDt0b28gbWFueSBqb2ludHMmcXVvdDssIGFzIGluLCBpdCBhbGxvd3M8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmltcGxlbWVudGF0aW9ucyBhIHdp ZGUgdmFyaWV0eSBvZiBiZWhhdmlvcnMsIHdoaWNoIGluIHR1cm4gcmVxdWlyZXMgdGhlaXIgcGVl cnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRv IGFjY29tbW9kYXRlIHRob3NlIHNjZW5hcmlvcy4mbmJzcDsgVGhlIHNpdHVhdGlvbiB3aXRoIHRo ZSBpbml0aWFsIGZsb3cgY29udHJvbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+d2luZG93IGlzIGVzcGVjaWFsbHkgYXdrd2FyZC4mbmJzcDsgU2Vy dmVyIG1pZ2h0IGNob29zZSB0byBleGN1c2UgZmxvdyBjb250cm9sPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj52aW9sYXRpb25zIHVudGlsIHRoZSAx LVJUVCBwaGFzZSBpcyByZWFjaGVkLCB3aGljaCByZXF1aXJlcyBjbGllbnQgdG88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFjY29tbW9kYXRlIHBv c3NpYmxlIGZsb3cgY29udHJvbCB3aW5kb3cgZGVjcmVhc2UgdXBvbiByZWNlaXZpbmcgc2VydmVy IGhlbGxvOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+b3IgaXQgbWlnaHQgY2hvb3NlIG5vdCB0byBleGN1c2UgdGhlbSwgd2hpY2ggcmVxdWlyZXMg Y2xpZW50IHRvIHJldHJ5IGJ5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5zcGVjaWFsLWNhc2luZyBRVUlDX0ZMT1dfQ09OVFJPTF9SRUNFSVZFRF9U T09fTVVDSF9EQVRBIHNob3J0bHkgYWZ0ZXIgMC1SVFQgYXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEgcmV0cnkgc2lnbmFsLiZuYnNwOyBBbGwg b2YgdGhpcyBhZGRzIGEgY29tcGxleGl0eSBidXJkZW4gb250byBpbXBsZW1lbnRhdGlvbnMsIGFu ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWFr ZXMgY29tcHJlaGVuc2l2ZSBpbnRlcm9wIHRlc3RpbmcgdmVyeSBoYXJkLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluc3RlYWQg b2YgdGhlIGN1cnJlbnQgbmVnb3RpYXRpb24gc2NoZW1lIG91dGxpbmVkIGluIHRoZSBkcmFmdCwg SSBwcm9wb3NlIHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPndlIGFkYXB0IGEgc2ltcGxlIHNjaGVtZSBzaW1pbGFyIHRvIHdoYXQgVExTIGRv ZXMgd2l0aCBjcnlwdG9ncmFwaGljIHBhcmFtZXRlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCAwLVJUVDo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAxKSBDbGllbnQgc2VuZHMg aXRzIHZpc2lvbiBvZiBzZXJ2ZXIncyBhc3N1bWVkIHBhcmFtZXRlcnMgaW4gdGhlIENsaWVudEhl bGxvLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDthbmQgaXMgZXhwZWN0ZWQgdG8gZm9sbG93IHRoZW0gaW4gMC1S VFQgcGFja2V0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAyKSBTZXJ2ZXIgZWl0aGVyIGFjY2VwdHMgdGhvc2UgcGFyYW1ldGVycywg b3IgZGVjbGluZXMgMC1SVFQgYWx0b2dldGhlciw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7YnkgZGlzY2FyZGlu ZyB0aGUgMC1SVFQgZGF0YSBhbmQgZm9sbG93aW5nIHVwIHdpdGggYSBmdWxsIDEtUlRUIGhhbmRz aGFrZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIHNlcnZlciBhY2NlcHRzIDAtUlRULCBpdHMgcGFyYW1ldGVycyBpbiB0aGUgMS1SVFQgc2Vy dmVyIGhlbGxvIGNhbm5vdCBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+bW9yZSBsaW1pdGVkIHRoYW4gd2hhdCBpdCBhY2NlcHRlZCBmcm9tIHRo ZSBjbGllbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkluIHRoaXMgc2NlbmFyaW8sIGJvdGggdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBj YW4gdXNlIHRoZWlyIHJlZ3VsYXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmNvbm5lY3Rpb24gaGFuZGxpbmcgbG9naWMgZm9yIDAtUlRUIGRhdGEs IHNpbmNlIGJvdGggdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aGF2ZSBhIGNvbnNpc3RlbnQgdmlldyBv ZiBzZXJ2ZXIncyBwYXJhbWV0ZXJzLiZuYnNwOyBUaGlzIHdvcmtzIHdlbGwgd2hlbiB0aGU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBhcmFtZXRl cnMgbWF0Y2ggZXhwZWN0YXRpb25zIChtb3N0IG9mIHRoZSB0aW1lKSwgaXQncyBzaW1wbGUgdG8g aW1wbGVtZW50LCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPml0J3Mgc2ltcGxlIHRvIHRlc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0tIFZpY3Rvci48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0248e010b13d47a8ab8bc86f9b42970eusma1exdag1mb5msgcorpak_-- From nobody Sat Apr 8 21:34:52 2017 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 00F9C1292F4 for ; Sat, 8 Apr 2017 21:34:51 -0700 (PDT) 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_HELO_PASS=-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 dQ729D4futZE for ; Sat, 8 Apr 2017 21:34:47 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 B174F124BFA for ; Sat, 8 Apr 2017 21:34:47 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F1C0822E257; Sun, 9 Apr 2017 00:34:40 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Consensus Call on issues closed by the -02 drafts From: Mark Nottingham In-Reply-To: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> Date: Sun, 9 Apr 2017 14:34:38 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2017 04:34:51 -0000 Reminder: there is a consensus call for these issues outstanding, and we = haven't had any discussion since the call, leading us to believe that = everyone understands and agrees with the proposed resolutions.=20 If you need clarification, to ask questions, or more time, please say so = soon, otherwise we'll declare consensus. Regards, > On 17 Mar 2017, at 8:22 pm, Mark Nottingham wrote: >=20 > Everyone, >=20 > The -02 drafts incorporate the proposed resolutions to a number of = issues that have been discussed.=20 >=20 > Those issues are listed below. Please have a look through them, and if = there are any resolutions that you feel need more discussion, please = bring it up, either here on the mailing list or in the issue itself. >=20 > Issues that we need to discuss more will be reopened. The remaining = ones will be flagged as `has-consensus`. >=20 > There are a lot of them, so we're not going to do this until after the = Chicago meeting (at the earliest) to give people a chance to discuss on = the list as well as in the meeting. >=20 > See = for a reminder about the process we're using here. Even when = we have consensus, we can reopen an issue if new information emerges = (and that can take a variety of forms). >=20 > This list is also available at = . >=20 > Cheers, >=20 > ## Transport >=20 > #35 - Starting packet number > #40 - Variable-length fields > #49 - Transport parameter advertisements > #50 - Updating Transport parameters > #51 - QUIC version number scheme > #52 - Source address validation > #55 - What can change in a different version > #56 - Extending flags > #57 - Advice on STOP_WAITING > #59 - Define ICSL parameter > #62 - Finding frame lengths > #63 - ACK retransmission > #64 - Path MTU Discovery > #66 - Remove STOP_WAITING > #67 - Picking packet number length > #69 - Minimum packet size > #70 - Move ACK/STOP_WAITING into the packet header > #74 - Application-defined error codes > #104 - Priority in QUIC Transport > #108 - Maximum stream number > #112 - Greasing version negotiation > #114 - STREAM retransmission priority > #116 - COPTs as empty transport parameters > #117 - SCUP > #118 - Source Address Token encoding > #119 - Server-proposed connection ID > #124 - Alt-Svc quic version hint > #126 - Separate transport parameters for 0-RTT > #133 - Connection ID in version negotiation > #135 - DoS using Version Negotiation Packets > #136 - First client packet size > #139 - Minimum MTU > #147 - Reflection Attack Resistance > #148 - QUIC packet header complexity > #157 - Updated information in retransmitted frames > #158 - Padding between frames > #159 - Time format > #162 - RST_STREAM and flow control > #163 - RST_STREAM and connection-level flow control > #164 - Padding handshake packets > #168 - Ordering of ACK Frame fields > #174 - Stream Reservation > #181 - Remove SETTINGS[_ACK] > #185 - Reliable identification of the initial packet for a connection > #201 - Do streams 0 and 1 count towards MSPC? > #204 - Streams not contributing to connection-level flow control > #243 - AEAD Associated Data > #244 - Need a NONCE in version negotiation packets > #262 - Don't encrypt client handshake with 1-RTT keys > #285 - Policing packet number size > #286 - Outstanding packets and packet number size > #289 - Avoid using Public Reset where possible > #291 - ACKing ACK > #292 - Does any portion of the QUIC framing require 4 byte alignment? > #293 - Does the connection id need to be in a consistent location? > #295 - Connection ID on a version negotiation packet > #308 - "retransmitting" old timestamps in ACK frames > #323 - Smaller packet number representations > #340 - Scale flow control offsets > #341 - What does it mean to acknowledge something? > #347 - Clarify meaning/definition of GOAWAY > #349 - When should server-chosen connection IDs be sent and how are = they indicated? > #352 - Does GOAWAY need an error code >=20 >=20 > ## Recovery >=20 > #63 - ACK retransmission > #169 - Response to lost handshake packets >=20 >=20 > ## TLS >=20 > #12 - Decouple QUIC version and ALPN=20 > #25 - Key update forward secrecy > #26 - Which bit can KEY_PHASE use? > #27 - Fix KEY_PHASE for early data > #34 - ACK rules and packet protection > #87 - QUIC advertisement description > #97 - Version Negotiation + TLS > #226 - Authenticating public parts of the packet header > #243 - AEAD Associated Data > #262 - Don't encrypt client handshake with 1-RTT keys > #272 - Signaling TLS handshake failure >=20 >=20 > ## HTTP >=20 > 75 - SETTING syncronization > 87 - QUIC advertisement description > 95 - CONNECT > 104 - Priority in QUIC Transport > 124 - Alt-Svc quic version hint > 127 - Frame header reserved bits > 154 - HTTP Stream ID Size > 173 - Size of HTTP Header Sequence Numbers > 176 - RST_STREAM breaks HPACK > 181 - Remove SETTINGS[_ACK] > 202 - HTTP: Why are we defining CONNECT? > 204 - Streams not contributing to connection-level flow control > 229 - Use a quic=3D parameter for Alt-Svc rather than collide with = existing use of v=3D > 242 - HTTP extension mechanisms > 297 - Remove the quic parameter from Alt-Svc > 364 - Mid-frame close >=20 >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Apr 10 10:22:55 2017 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 0AB66129571 for ; Mon, 10 Apr 2017 10:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 0AMuJzsPA5xW for ; Mon, 10 Apr 2017 10:22:49 -0700 (PDT) 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 2589C129533 for ; Mon, 10 Apr 2017 10:22:49 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cxd1Z-0006FE-6f for quic@ietf.org; Mon, 10 Apr 2017 19:22:47 +0200 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cxd1T-0004Ry-9B for quic@ietf.org; Mon, 10 Apr 2017 13:22:43 -0400 Received: (qmail 14489 invoked from network); 10 Apr 2017 17:22:37 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.160]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Apr 2017 17:22:36 -0000 References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> To: "quic@ietf.org" , dns-privacy@ietf.org From: Christian Huitema X-Forwarded-Message-Id: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> Message-ID: Date: Mon, 10 Apr 2017 10:22:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> Content-Type: multipart/alternative; boundary="------------B344745BA762707BB596142A" Subject: Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49EdlGitVsfXsrKty9N3esIJTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoD9etOLFuxRstVec1GYHCwRcOb18WfxGyg6Om6u4YYm6B3Wil7FvVSKgrQ lPQKAM45hjoyEb9Oq0NWpyO3vrfYy2h1mQR50Wwo5hSyeApVLD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB0ktSrwQbrgk6jfwMHIN4qnTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0ku8/jzjD iAQGCIYr5JfL5LbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWJKyg1OJH8aak+/hDMnS4uzLQQGIH13szEQZ25LjADnOjMCwLPrvetbgI 5bnJXn1ucqiSoo7BxyxRryqmiHuCdUetTZ/25DKDZC7RirBgbePcy8BFh+JufJrwsKmKW6bHd9QD sMspn/O/edVkHySM+CDVwFjZwEavmmk7Tr9uJ5mso9iv7kZ9azJt3DY/E7nm X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2017 17:22:51 -0000 This is a multi-part message in MIME format. --------------B344745BA762707BB596142A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit FYI: Just published this draft describing transport of DNS over a dedicated QUIC connection. -- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-huitema-quic-dnsoquic-00.txt Date: Mon, 10 Apr 2017 09:45:37 -0700 From: internet-drafts@ietf.org To: Melinda Shore , Sara Dickinson , Christian Huitema , Allison Mankin , Janardhan Iyengar , Jana Iyengar A new version of I-D, draft-huitema-quic-dnsoquic-00.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-quic-dnsoquic Revision: 00 Title: Specification of DNS over QUIC Document date: 2017-04-10 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-dnsoquic-00.txt Status: https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/ Htmlized: https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-dnsoquic-00 Abstract: This document describes the use of QUIC to provide transport privacy for DNS. The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of- line blocking issues inherent with TCP and provides more efficient error corrections than UDP. DNS over QUIC has privacy properties similar to DNS over TLS specified in RFC7858, and performance similar to classic DNS over UDP. 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. The IETF Secretariat --------------B344745BA762707BB596142A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
FYI: Just published this draft describing transport of DNS over a dedicated QUIC connection.
-- Christian Huitema

-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-quic-dnsoquic-00.txt
Date: Mon, 10 Apr 2017 09:45:37 -0700
From: internet-drafts@ietf.org
To: Melinda Shore <mshore@fastly.com>, Sara Dickinson <sara@sinodun.com>, Christian Huitema <huitema@huitema.net>, Allison Mankin <amankin@salesforce.com>, Janardhan Iyengar <jri@google.com>, Jana Iyengar <jri@google.com> 


A new version of I-D, draft-huitema-quic-dnsoquic-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-huitema-quic-dnsoquic
Revision:	00
Title:		Specification of DNS over QUIC
Document date:	2017-04-10
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-huitema-quic-dnsoquic-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/
Htmlized:       https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-huitema-quic-dnsoquic-00


Abstract:
   This document describes the use of QUIC to provide transport privacy
   for DNS.  The encryption provided by QUIC has similar properties to
   that provided by TLS, while QUIC transport eliminates the head-of-
   line blocking issues inherent with TCP and provides more efficient
   error corrections than UDP.  DNS over QUIC has privacy properties
   similar to DNS over TLS specified in RFC7858, and performance similar
   to classic DNS over UDP.

                                                                                  


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.

The IETF Secretariat
--------------B344745BA762707BB596142A-- From nobody Mon Apr 10 11:03:44 2017 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 2AF0E129A9D for ; Mon, 10 Apr 2017 11:03:42 -0700 (PDT) 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] 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 NAYRVXSLV9lZ for ; Mon, 10 Apr 2017 11:03:40 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 AF2FC1296B0 for ; Mon, 10 Apr 2017 11:03:34 -0700 (PDT) Received: from [169.254.150.39] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v3AI3Ikt029792 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 10 Apr 2017 11:03:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.150.39] From: "Paul Hoffman" To: quic@ietf.org Subject: Additional DNS-over-QUIC draft with a different use case Date: Mon, 10 Apr 2017 11:03:32 -0700 Message-ID: <1B9BE361-E54D-4CBB-92B6-290B7FB4D30E@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2017 18:03:42 -0000 Related to Christian's recent announcement of draft-huitema-quic-dnsoquic, here a different draft that also are of interest to the QUIC WG. The drafts have different use cases. The solutions spaces for the use cases are different (reusing an existing connection instead of starting a new one). We think that both might be of interest to the IETF given that both should help make DNS traffic private. I also created a parallel draft about DNS in existing HTTP/2 streams, but will send that to the HTTPBIS WG. --Paul Hoffman Name: draft-hoffman-dns-in-existing-quic Revision: 00 Title: Running DNS in Existing QUIC Connections Document date: 2017-04-10 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-hoffman-dns-in-existing-quic-00.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-in-existing-quic/ Htmlized: https://tools.ietf.org/html/draft-hoffman-dns-in-existing-quic-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoffman-dns-in-existing-quic-00 Abstract: Intermediaries such as governments and ISPs spoof DNS responses, and block DNS requests to particular recursive resolvers, for a variety of reasons. They spoof by capturing traffic on port 53, or by redirecting port 853 traffic in the hopes that the client is using opportunistic encryption. They block if they know the address of a resolver that they don't like, such as public resolvers that give honest answers. This document describes how to run DNS service over existing QUIC connections, such as those being used for HTTP for basic web service. This design prevents intermediaries from spoofing DNS responses, and makes it impossible for intermediaries to block the use of those recursive resolvers without blocking the desired HTTP connections. It also prevents intermediaries or passive observers from seeing the DNS traffic. This design is meant for communication between a DNS stub resolver and a DNS recursive resolver. From nobody Mon Apr 10 13:18:52 2017 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 18BF4126D73; Mon, 10 Apr 2017 13:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 hJT2CCf-CMKB; Mon, 10 Apr 2017 13:18:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18407124234; Mon, 10 Apr 2017 13:18:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F800BE73; Mon, 10 Apr 2017 21:18:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7ooQiCmiFML; Mon, 10 Apr 2017 21:18:29 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 70995BE5B; Mon, 10 Apr 2017 21:18:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1491855506; bh=VOLdDCdIv0qUku8v1KuWuOaPOLMHJ0HfIt5B2Th/TI0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gotk0OzE+M5GVy2tVea1kwPaA3H6nLop2h4RzL4EsWgrTwR3qeVnO2wlaTjGLizXH hGqunRU2p4GJcRCYrS8iv0Du2MHrzTMHi1fbyvWB8Tqh3KTi0KGLCrYZ2ycxCgUo3C gQXIw0A0+ReCSsQi7gW4HWQpJopun67IUJki5Bdw= Subject: Re: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt To: Christian Huitema , "quic@ietf.org" , dns-privacy@ietf.org References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9c04d3fc-dc76-cbdc-32a2-618289e91254@cs.tcd.ie> Date: Mon, 10 Apr 2017 21:18:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FXpiClvO6FDcdO81AeOiLgP8XIAVlcWFs" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2017 20:18:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FXpiClvO6FDcdO81AeOiLgP8XIAVlcWFs Content-Type: multipart/mixed; boundary="NIMkHQBeRQrtkR06hAAxmlRDKPDKS203U"; protected-headers="v1" From: Stephen Farrell To: Christian Huitema , "quic@ietf.org" , dns-privacy@ietf.org Message-ID: <9c04d3fc-dc76-cbdc-32a2-618289e91254@cs.tcd.ie> Subject: Re: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> In-Reply-To: --NIMkHQBeRQrtkR06hAAxmlRDKPDKS203U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Great to see this. I hope it gets traction and am willing to read comment etc if this gets adopted somewhere. Cheers, S. On 10/04/17 18:22, Christian Huitema wrote: >=20 > FYI: Just published this draft describing transport of DNS over a > dedicated QUIC connection. > -- Christian Huitema >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for draft-huitema-quic-dnsoquic-00.t= xt > Date: Mon, 10 Apr 2017 09:45:37 -0700 > From: internet-drafts@ietf.org > To: Melinda Shore , Sara Dickinson > , Christian Huitema , Allison > Mankin , Janardhan Iyengar , > Jana Iyengar >=20 >=20 >=20 > A new version of I-D, draft-huitema-quic-dnsoquic-00.txt > has been successfully submitted by Christian Huitema and posted to the > IETF repository. >=20 > Name: draft-huitema-quic-dnsoquic > Revision: 00 > Title: Specification of DNS over QUIC > Document date: 2017-04-10 > Group: Individual Submission > Pages: 18 > URL: https://www.ietf.org/internet-drafts/draft-huitema-quic= -dnsoquic-00.txt > Status: https://datatracker.ietf.org/doc/draft-huitema-quic-dns= oquic/ > Htmlized: https://tools.ietf.org/html/draft-huitema-quic-dnsoquic= -00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-qui= c-dnsoquic-00 >=20 >=20 > Abstract: > This document describes the use of QUIC to provide transport privacy= > for DNS. The encryption provided by QUIC has similar properties to > that provided by TLS, while QUIC transport eliminates the head-of- > line blocking issues inherent with TCP and provides more efficient > error corrections than UDP. DNS over QUIC has privacy properties > similar to DNS over TLS specified in RFC7858, and performance simila= r > to classic DNS over UDP. >=20 > = =20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy >=20 --NIMkHQBeRQrtkR06hAAxmlRDKPDKS203U-- --FXpiClvO6FDcdO81AeOiLgP8XIAVlcWFs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY6+iQAAoJEC88hzaAX42iNR8H/2lIMXxPCfZz4wdUjvOr2KER wI7ck0L9IRMDe8930tNtH7xU2cFfAjmqzWNMQFInwrFakX2TPbJWLzC8L/AStPIU Xc7SD+9NA7x4adoQIhq8x4/PXJcMOTiSgWz60S9yXG9ZTMWZ0hBE0ewabMN/2uFG mRyZGW2epF/d++HabcuUbmj/lcxYjpTe13POQSv6XwRBPcfwTt/JrgLIAiRRvQKI 9EHNjmg5AzOCY8amExyclza+Y58V6o4m0BJR4LO0N0FLZeeYA+kvhPPxBtdAkEYz wCIzKzyH/FIzL1myQkyLlRFQqIg4MotI8p5LZ8vWYL9b0GoYxvpSaYfam6jGthk= =d+fq -----END PGP SIGNATURE----- --FXpiClvO6FDcdO81AeOiLgP8XIAVlcWFs-- From nobody Mon Apr 10 23:43:40 2017 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 BFE341287A3; Mon, 10 Apr 2017 23:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.889 X-Spam-Level: X-Spam-Status: No, score=-6.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Umrf5BCdN7ij; Mon, 10 Apr 2017 23:43:29 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 EBCE0128B8D; Mon, 10 Apr 2017 23:43:27 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.52f ; Tue, 11 Apr 2017 08:43:21 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 08:43:20 +0200 From: Alexander Mayrhofer To: Christian Huitema , "quic@ietf.org" , "dns-privacy@ietf.org" Thread-Index: AQHSsh8cNI/htzqFBkW5pWYvd2Daa6G/thFg Date: Tue, 11 Apr 2017 06:43:19 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07598F48DC7@NICS-EXCH2.sbg.nic.at> References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.13] Content-Type: multipart/alternative; boundary="_000_19F54F2956911544A32543B8A9BDE07598F48DC7NICSEXCH2sbgnic_" MIME-Version: 1.0 Subject: AW: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-XWALL-BCKS: auto Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 06:43:33 -0000 --_000_19F54F2956911544A32543B8A9BDE07598F48DC7NICSEXCH2sbgnic_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQ2hyaXN0aWFuLA0KDQpncmVhdCB0byBzZWUgdGhpcyDigJMgaSByZW1lbWJlciB3aGVu IGkgbWVudGlvbmVkIFFVSUMgYXMgYW4gb3B0aW9uIGR1cmluZyB0aGUgRE5TLW92ZXItSFRUUCBC YXIgQm9GIGluIFNlb3VsIGkgZ290IHF1aXRlIGEgZmV3IHdlaXJkIGxvb2tzIDopLiBJIGxpa2Ug dGhpcy4gSXQgbG9va3MgbGlrZSBhIGxvZ2ljYWwgY2hvaWNlIHNvbWV3aGVyZSDigJ5iZXR3ZWVu 4oCcIFRMUyBhbmQgRFRMUy4NCg0KSSBoYXZlIHNvbWUgYmFja2dyb3VuZCBvbiBTZWN0aW9uIDYu NSAoUGFkZGluZykg4oCTIGJhY2sgd2hlbiB3ZSBzcGVjaWZpZWQgRE5TIG92ZXIgVExTLCB3ZSBo YWQgYSBzaW1pbGFyIGRpc2N1c3Npb24gd2hldGhlciB0byBwYWQgb24gdGhlIEROUyBvciB0aGUg dHJhbnNwb3J0IChUTFMsIGluIHRoYXQgY2FzZSkgbGF5ZXIuIFdlIGRlY2lkZWQgaW4gdGhhdCBj YXNlIHRoYXQgcGFkZGluZyBvbiB0aGUgRE5TIGxheWVyIGlzIHByZWZlcnJlZCwgc2luY2UgaXQg YWxsb3dzIGZvciBncmVhdGVyIGNvbnRyb2wgYnkgdGhlIGFwcGxpY2F0aW9uLiBUaGlzIHdhcyBh Y3R1YWxseSB0aGUgcmVhc29uIFJGQyA3ODMwIHdhcyBjcmVhdGVkIGluIHRoZSBmaXJzdCBwbGFj ZS4NCg0KVGhlIHNpdHVhdGlvbiBtaWdodCBiZSBkaWZmZXJlbnQgZm9yIFFVSUMgYXMgdGhlcmXi gJlzIGEgdGlnaHRlciBjb3VwbGluZyBiZXR3ZWVuIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24s IHRob3VnaCBwYWRkaW5nIG9uIHRoZSBETlMgbGF5ZXIgd291bGQgYWxsb3cgcmUtdXNpbmcgdGhl IG9uZ29pbmcgcmVzZWFyY2ggYW5kIHNwZWNpZmljYXRpb24gd29yayBpbiBEUFJJVkUuIChEaXNj bGFpbWVyOiBJIGtub3cgbGl0dGxlIGFib3V0IHRoZSBjdXJyZW50IHN0YXRlIG9mIHN1Y2ggcmVz ZWFyY2ggZm9yIFFVSUMpLg0KDQpiZXN0LA0KQWxleA0KDQpWb246IGRucy1wcml2YWN5IFttYWls dG86ZG5zLXByaXZhY3ktYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQ2hyaXN0aWFu IEh1aXRlbWENCkdlc2VuZGV0OiBNb250YWcsIDEwLiBBcHJpbCAyMDE3IDE5OjIzDQpBbjogcXVp Y0BpZXRmLm9yZzsgZG5zLXByaXZhY3lAaWV0Zi5vcmcNCkJldHJlZmY6IFtkbnMtcHJpdmFjeV0g RndkOiBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVpdGVtYS1xdWlj LWRuc29xdWljLTAwLnR4dCBbeF9waGlzaGluZ10NCg0KDQpGWUk6IEp1c3QgcHVibGlzaGVkIHRo aXMgZHJhZnQgZGVzY3JpYmluZyB0cmFuc3BvcnQgb2YgRE5TIG92ZXIgYSBkZWRpY2F0ZWQgUVVJ QyBjb25uZWN0aW9uLg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0KLS0tLS0tLS0gRm9yd2FyZGVk IE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAwLnR4dA0KDQpEYXRlOg0KDQpNb24sIDEw IEFwciAyMDE3IDA5OjQ1OjM3IC0wNzAwDQoNCkZyb206DQoNCmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KDQpUbzoNCg0KTWVsaW5kYSBT aG9yZSA8bXNob3JlQGZhc3RseS5jb20+PG1haWx0bzptc2hvcmVAZmFzdGx5LmNvbT4sIFNhcmEg RGlja2luc29uIDxzYXJhQHNpbm9kdW4uY29tPjxtYWlsdG86c2FyYUBzaW5vZHVuLmNvbT4sIENo cmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjxtYWlsdG86aHVpdGVtYUBodWl0 ZW1hLm5ldD4sIEFsbGlzb24gTWFua2luIDxhbWFua2luQHNhbGVzZm9yY2UuY29tPjxtYWlsdG86 YW1hbmtpbkBzYWxlc2ZvcmNlLmNvbT4sIEphbmFyZGhhbiBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNv bT48bWFpbHRvOmpyaUBnb29nbGUuY29tPiwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT48 bWFpbHRvOmpyaUBnb29nbGUuY29tPg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy0wMC50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBDaHJpc3RpYW4gSHVpdGVtYSBhbmQgcG9zdGVkIHRvIHRoZQ0KDQpJRVRGIHJl cG9zaXRvcnkuDQoNCg0KDQpOYW1lOiAgICAgICAgIGRyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVp Yw0KDQpSZXZpc2lvbjogICAgIDAwDQoNClRpdGxlOiAgICAgICAgU3BlY2lmaWNhdGlvbiBvZiBE TlMgb3ZlciBRVUlDDQoNCkRvY3VtZW50IGRhdGU6IDIwMTctMDQtMTANCg0KR3JvdXA6ICAgICAg ICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KUGFnZXM6ICAgICAgICAxOA0KDQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1aXRlbWEt cXVpYy1kbnNvcXVpYy0wMC50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy8NCg0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWl0ZW1hLXF1aWMtZG5z b3F1aWMtMDANCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAwDQoNCg0KDQoNCg0KQWJzdHJh Y3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB1c2Ugb2YgUVVJQyB0byBwcm92 aWRlIHRyYW5zcG9ydCBwcml2YWN5DQoNCiAgIGZvciBETlMuICBUaGUgZW5jcnlwdGlvbiBwcm92 aWRlZCBieSBRVUlDIGhhcyBzaW1pbGFyIHByb3BlcnRpZXMgdG8NCg0KICAgdGhhdCBwcm92aWRl ZCBieSBUTFMsIHdoaWxlIFFVSUMgdHJhbnNwb3J0IGVsaW1pbmF0ZXMgdGhlIGhlYWQtb2YtDQoN CiAgIGxpbmUgYmxvY2tpbmcgaXNzdWVzIGluaGVyZW50IHdpdGggVENQIGFuZCBwcm92aWRlcyBt b3JlIGVmZmljaWVudA0KDQogICBlcnJvciBjb3JyZWN0aW9ucyB0aGFuIFVEUC4gIEROUyBvdmVy IFFVSUMgaGFzIHByaXZhY3kgcHJvcGVydGllcw0KDQogICBzaW1pbGFyIHRvIEROUyBvdmVyIFRM UyBzcGVjaWZpZWQgaW4gUkZDNzg1OCwgYW5kIHBlcmZvcm1hbmNlIHNpbWlsYXINCg0KICAgdG8g Y2xhc3NpYyBETlMgb3ZlciBVRFAuDQoNCg0KDQoNCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_19F54F2956911544A32543B8A9BDE07598F48DC7NICSEXCH2sbgnic_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MVm9yZm9ybWF0aWVydFpjaG4NCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCI7DQoJZm9udC1mYW1pbHk6Q29u c29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkUtTWFpbEZvcm1h dHZvcmxhZ2UyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJERSIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkhlbGxvIENocmlzdGlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPmdyZWF0IHRvIHNlZSB0aGlzIOKAkyBpIHJlbWVtYmVyIHdoZW4g aSBtZW50aW9uZWQgUVVJQyBhcyBhbiBvcHRpb24gZHVyaW5nIHRoZSBETlMtb3Zlci1IVFRQIEJh ciBCb0YgaW4gU2VvdWwgaSBnb3QgcXVpdGUgYSBmZXcgd2VpcmQNCiBsb29rcyA6KS4gSSBsaWtl IHRoaXMuIEl0IGxvb2tzIGxpa2UgYSBsb2dpY2FsIGNob2ljZSBzb21ld2hlcmUg4oCeYmV0d2Vl buKAnCBUTFMgYW5kIERUTFMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5JIGhhdmUgc29tZSBiYWNrZ3JvdW5kIG9uIFNlY3Rpb24gNi41IChQYWRkaW5nKSDigJMgYmFj ayB3aGVuIHdlIHNwZWNpZmllZCBETlMgb3ZlciBUTFMsIHdlIGhhZCBhIHNpbWlsYXIgZGlzY3Vz c2lvbiB3aGV0aGVyIHRvIHBhZCBvbg0KIHRoZSBETlMgb3IgdGhlIHRyYW5zcG9ydCAoVExTLCBp biB0aGF0IGNhc2UpIGxheWVyLiBXZSBkZWNpZGVkIGluIHRoYXQgY2FzZSB0aGF0IHBhZGRpbmcg b24gdGhlIEROUyBsYXllciBpcyBwcmVmZXJyZWQsIHNpbmNlIGl0IGFsbG93cyBmb3IgZ3JlYXRl ciBjb250cm9sIGJ5IHRoZSBhcHBsaWNhdGlvbi4gVGhpcyB3YXMgYWN0dWFsbHkgdGhlIHJlYXNv biBSRkMgNzgzMCB3YXMgY3JlYXRlZCBpbiB0aGUgZmlyc3QgcGxhY2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgc2l0dWF0aW9uIG1pZ2h0IGJlIGRpZmZlcmVu dCBmb3IgUVVJQyBhcyB0aGVyZeKAmXMgYSB0aWdodGVyIGNvdXBsaW5nIGJldHdlZW4gdHJhbnNw b3J0IGFuZCBhcHBsaWNhdGlvbiwgdGhvdWdoIHBhZGRpbmcgb24gdGhlIEROUw0KIGxheWVyIHdv dWxkIGFsbG93IHJlLXVzaW5nIHRoZSBvbmdvaW5nIHJlc2VhcmNoIGFuZCBzcGVjaWZpY2F0aW9u IHdvcmsgaW4gRFBSSVZFLiAoRGlzY2xhaW1lcjogSSBrbm93IGxpdHRsZSBhYm91dCB0aGUgY3Vy cmVudCBzdGF0ZSBvZiBzdWNoIHJlc2VhcmNoIGZvciBRVUlDKS4NCjxhIG5hbWU9Il9NYWlsRW5k Q29tcG9zZSI+PG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+YmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5BbGV4PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Wb246PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IGRucy1wcml2YWN5IFttYWlsdG86ZG5z LXByaXZhY3ktYm91bmNlc0BpZXRmLm9yZ10NCjxiPkltIEF1ZnRyYWcgdm9uIDwvYj5DaHJpc3Rp YW4gSHVpdGVtYTxicj4NCjxiPkdlc2VuZGV0OjwvYj4gTW9udGFnLCAxMC4gQXByaWwgMjAxNyAx OToyMzxicj4NCjxiPkFuOjwvYj4gcXVpY0BpZXRmLm9yZzsgZG5zLXByaXZhY3lAaWV0Zi5vcmc8 YnI+DQo8Yj5CZXRyZWZmOjwvYj4gW2Rucy1wcml2YWN5XSBGd2Q6IEZ3ZDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0IFt4X3Bo aXNoaW5nXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZZSTogSnVz dCBwdWJsaXNoZWQgdGhpcyBkcmFmdCBkZXNjcmliaW5nIHRyYW5zcG9ydCBvZiBETlMgb3ZlciBh IGRlZGljYXRlZCBRVUlDIGNvbm5lY3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLSBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxicj4NCi0tLS0tLS0t IEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9 IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdo dCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlN1YmplY3Q6IDxvOnA+PC9vOnA+PC9iPjwv cD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVpdGVtYS1x dWljLWRuc29xdWljLTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpy aWdodCI+PGI+RGF0ZTogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TW9uLCAxMCBBcHIg MjAxNyAwOTo0NTozNyAtMDcwMDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpy aWdodCI+PGI+RnJvbTogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+VG86IDxvOnA+ PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1lbGluZGEgU2hvcmUgPGEgaHJlZj0ibWFpbHRvOm1z aG9yZUBmYXN0bHkuY29tIj4mbHQ7bXNob3JlQGZhc3RseS5jb20mZ3Q7PC9hPiwgU2FyYSBEaWNr aW5zb24NCjxhIGhyZWY9Im1haWx0bzpzYXJhQHNpbm9kdW4uY29tIj4mbHQ7c2FyYUBzaW5vZHVu LmNvbSZndDs8L2E+LCBDaHJpc3RpYW4gSHVpdGVtYSA8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBo dWl0ZW1hLm5ldCI+DQombHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8L2E+LCBBbGxpc29uIE1h bmtpbiA8YSBocmVmPSJtYWlsdG86YW1hbmtpbkBzYWxlc2ZvcmNlLmNvbSI+DQombHQ7YW1hbmtp bkBzYWxlc2ZvcmNlLmNvbSZndDs8L2E+LCBKYW5hcmRoYW4gSXllbmdhciA8YSBocmVmPSJtYWls dG86anJpQGdvb2dsZS5jb20iPiZsdDtqcmlAZ29vZ2xlLmNvbSZndDs8L2E+LCBKYW5hIEl5ZW5n YXINCjxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+Jmx0O2pyaUBnb29nbGUuY29tJmd0 OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHByZT5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHVpdGVtYS1x dWljLWRuc29xdWljLTAwLnR4dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2hyaXN0aWFuIEh1aXRlbWEgYW5kIHBvc3RlZCB0byB0aGU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TmFtZTombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaHVpdGVtYS1xdWljLWRuc29x dWljPG86cD48L286cD48L3ByZT4NCjxwcmU+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDAwPG86cD48L286cD48L3ByZT4NCjxwcmU+VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNwZWNpZmljYXRpb24gb2YgRE5TIG92ZXIgUVVJQzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPkRvY3VtZW50IGRhdGU6IDIwMTctMDQtMTA8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+UGFnZXM6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4PG86cD48L286cD48L3By ZT4NCjxwcmU+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAwLnR4dCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy0w MC50eHQ8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMvIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMvPC9hPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVp dGVtYS1xdWljLWRuc29xdWljLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aHVpdGVtYS1xdWljLWRuc29xdWljLTAwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkh0bWxp emVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVp Yy0wMCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1odWl0ZW1h LXF1aWMtZG5zb3F1aWMtMDA8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QWJzdHJhY3Q6 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSB1c2Ugb2YgUVVJQyB0byBwcm92aWRlIHRyYW5zcG9ydCBwcml2YWN5PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZvciBETlMuJm5ic3A7IFRoZSBlbmNyeXB0aW9u IHByb3ZpZGVkIGJ5IFFVSUMgaGFzIHNpbWlsYXIgcHJvcGVydGllcyB0bzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGF0IHByb3ZpZGVkIGJ5IFRMUywgd2hpbGUgUVVJQyB0 cmFuc3BvcnQgZWxpbWluYXRlcyB0aGUgaGVhZC1vZi08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgbGluZSBibG9ja2luZyBpc3N1ZXMgaW5oZXJlbnQgd2l0aCBUQ1AgYW5kIHBy b3ZpZGVzIG1vcmUgZWZmaWNpZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGVycm9yIGNvcnJlY3Rpb25zIHRoYW4gVURQLiZuYnNwOyBETlMgb3ZlciBRVUlDIGhhcyBwcml2 YWN5IHByb3BlcnRpZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc2ltaWxh ciB0byBETlMgb3ZlciBUTFMgc3BlY2lmaWVkIGluIFJGQzc4NTgsIGFuZCBwZXJmb3JtYW5jZSBz aW1pbGFyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRvIGNsYXNzaWMgRE5T IG92ZXIgVURQLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+dW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT5UaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_19F54F2956911544A32543B8A9BDE07598F48DC7NICSEXCH2sbgnic_-- From nobody Tue Apr 11 01:52:51 2017 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 0D8551279EB for ; Tue, 11 Apr 2017 01:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 uZredmBfSLiU for ; Tue, 11 Apr 2017 01:52:48 -0700 (PDT) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475631200F1 for ; Tue, 11 Apr 2017 01:52:48 -0700 (PDT) Received: from BGB01XI1007.national.core.bbc.co.uk (bgb01xi1007.national.core.bbc.co.uk [10.161.14.21]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v3B8qjLp003915; Tue, 11 Apr 2017 09:52:45 +0100 (BST) Received: from BGB01XI1015.national.core.bbc.co.uk (10.161.14.78) by BGB01XI1007.national.core.bbc.co.uk (10.161.14.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 11 Apr 2017 09:52:45 +0100 Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1015.national.core.bbc.co.uk ([10.161.14.78]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 09:52:45 +0100 From: Lucas Pardue To: Paul Hoffman , "quic@ietf.org" Subject: RE: Additional DNS-over-QUIC draft with a different use case Thread-Topic: Additional DNS-over-QUIC draft with a different use case Thread-Index: AQHSsiTPS2JUSY55AkKoP5fhAA+MzaG/1xgz Date: Tue, 11 Apr 2017 08:52:44 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3770C0BA@bgb01xud1012> References: <1B9BE361-E54D-4CBB-92B6-290B7FB4D30E@vpnc.org> In-Reply-To: <1B9BE361-E54D-4CBB-92B6-290B7FB4D30E@vpnc.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.100.1062-22998.005 X-TM-AS-Result: No--4.778300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 08:52:50 -0000 Hi Paul, Interesting read thanks.=20 I wonder how common the scenario is where a h2 or QUIC endpoint can also se= rvice DNS. Do you have any concrete examples? In the context of h2, how do you think this proposal compares to say perfor= ming DNS-over-HTTP? My gut feel is that the proposed DNS frame is a semanti= c change because it changes the stream life cycle i.e. stream open and clos= e are controlled by sending/receiving DNS frames. Such semantic changes req= uire negotiation, for example by exchanging SETTINGS frames. This could be = done on connection initiation and may solve your service discovery in a dif= ferent way.=20 In the context of QUIC, I'm not aware of any text (yet) that specifies how = to extend the transport. Is the use of the DNS frame restricted to only HTT= P/QUIC connections or could it be used on all types, e.g. DNS/QUIC. It seem= s a bit strange to be able to express DNS in two different formats on the s= ame connection. Regards Lucas ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Paul Hoffman [paul.hoffman@= vpnc.org] Sent: 10 April 2017 19:03 To: quic@ietf.org Subject: Additional DNS-over-QUIC draft with a different use case Related to Christian's recent announcement of draft-huitema-quic-dnsoquic, here a different draft that also are of interest to the QUIC WG. The drafts have different use cases. The solutions spaces for the use cases are different (reusing an existing connection instead of starting a new one). We think that both might be of interest to the IETF given that both should help make DNS traffic private. I also created a parallel draft about DNS in existing HTTP/2 streams, but will send that to the HTTPBIS WG. --Paul Hoffman Name: draft-hoffman-dns-in-existing-quic Revision: 00 Title: Running DNS in Existing QUIC Connections Document date: 2017-04-10 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-hoffman-dns-in-existing-quic-00.= txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-in-existing-quic/ Htmlized: https://tools.ietf.org/html/draft-hoffman-dns-in-existing-quic-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoffman-dns-in-existing-quic-00 Abstract: Intermediaries such as governments and ISPs spoof DNS responses, and block DNS requests to particular recursive resolvers, for a variety of reasons. They spoof by capturing traffic on port 53, or by redirecting port 853 traffic in the hopes that the client is using opportunistic encryption. They block if they know the address of a resolver that they don't like, such as public resolvers that give honest answers. This document describes how to run DNS service over existing QUIC connections, such as those being used for HTTP for basic web service. This design prevents intermediaries from spoofing DNS responses, and makes it impossible for intermediaries to block the use of those recursive resolvers without blocking the desired HTTP connections. It also prevents intermediaries or passive observers from seeing the DNS traffic. This design is meant for communication between a DNS stub resolver and a DNS recursive resolver. From nobody Tue Apr 11 07:55:00 2017 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 08F1A12E858 for ; Tue, 11 Apr 2017 07:54:54 -0700 (PDT) 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] 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 h-dvvWz_PRJq for ; Tue, 11 Apr 2017 07:54:52 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 C759E129C52 for ; Tue, 11 Apr 2017 07:54:52 -0700 (PDT) Received: from [10.32.60.97] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v3BEsX9r097820 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Apr 2017 07:54:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.97] From: "Paul Hoffman" To: "Lucas Pardue" Cc: "quic@ietf.org" Subject: Re: Additional DNS-over-QUIC draft with a different use case Date: Tue, 11 Apr 2017 07:54:48 -0700 Message-ID: <65DF7C8C-4E55-4E26-995E-FDAAACD6173E@vpnc.org> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3770C0BA@bgb01xud1012> References: <1B9BE361-E54D-4CBB-92B6-290B7FB4D30E@vpnc.org> <7CF7F94CB496BF4FAB1676F375F9666A3770C0BA@bgb01xud1012> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 14:54:54 -0000 On 11 Apr 2017, at 1:52, Lucas Pardue wrote: > Interesting read thanks. > > I wonder how common the scenario is where a h2 or QUIC endpoint can > also service DNS. Do you have any concrete examples? Any h2 or QUIC endpoint "can" service DNS. Of course, none of them do so today because there is no protocol support for it. Having said that, we know that the operators of some large web sites also want to give their customers the best DNS they can because doing so protects their customers and because the cost of doing so is small in terms of bandwidth and CPU. Google and Yandex are current examples of these. > In the context of h2, how do you think this proposal compares to say > performing DNS-over-HTTP? Much cleaner, if done correctly. > My gut feel is that the proposed DNS frame is a semantic change > because it changes the stream life cycle i.e. stream open and close > are controlled by sending/receiving DNS frames. The draft doesn't suggest closing the stream after the response frame, at least not intentionally. > Such semantic changes require negotiation, for example by exchanging > SETTINGS frames. This could be done on connection initiation and may > solve your service discovery in a different way. Or, a better solution for DNS-over-h2 could be made. This was just a stake in the ground with a first guess. Other folks have suggested reserving stream numbers for DNS, for example; that might be better than DNS frames. > In the context of QUIC, I'm not aware of any text (yet) that specifies > how to extend the transport. Is the use of the DNS frame restricted to > only HTTP/QUIC connections or could it be used on all types, e.g. > DNS/QUIC. It seems a bit strange to be able to express DNS in two > different formats on the same connection. Agree. If there is a clean way to do DNS-over-h2, and that can then be done directly in QUIC, there is no reason to have two mechanisms. --Paul Hoffman From nobody Tue Apr 11 09:01:54 2017 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 402B112EAED for ; Tue, 11 Apr 2017 09:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 jCu4iXfP9WZb for ; Tue, 11 Apr 2017 09:01:50 -0700 (PDT) Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C8812EAD4 for ; Tue, 11 Apr 2017 09:01:50 -0700 (PDT) Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v3BG1mBv016290; Tue, 11 Apr 2017 17:01:48 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1008.national.core.bbc.co.uk ([10.161.14.22]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 17:01:48 +0100 From: Lucas Pardue To: Paul Hoffman CC: "quic@ietf.org" Subject: RE: Additional DNS-over-QUIC draft with a different use case Thread-Topic: Additional DNS-over-QUIC draft with a different use case Thread-Index: AQHSsiTPS2JUSY55AkKoP5fhAA+MzaG/1xgzgABa+wCAABYBYA== Date: Tue, 11 Apr 2017 16:01:47 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3770C19D@bgb01xud1012> References: <1B9BE361-E54D-4CBB-92B6-290B7FB4D30E@vpnc.org> <7CF7F94CB496BF4FAB1676F375F9666A3770C0BA@bgb01xud1012> <65DF7C8C-4E55-4E26-995E-FDAAACD6173E@vpnc.org> In-Reply-To: <65DF7C8C-4E55-4E26-995E-FDAAACD6173E@vpnc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.213] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-23000.000 x-tm-as-result: No--19.997100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 16:01:53 -0000 Paul Hoffman wrote: =20 > > My gut feel is that the proposed DNS frame is a semantic change > > because it changes the stream life cycle i.e. stream open and close > > are controlled by sending/receiving DNS frames. >=20 > The draft doesn't suggest closing the stream after the response frame, at > least not intentionally. My language was a bit unclear. From the I-D, the definition of DNS frame is= stated as using the END_STREAM flag identically to the DATA frame. So, rec= eption of the DNS frame with the flag set (for either request or response) = could cause the stream to enter half-closed or closed.=20 On further thought, since END_STREAM is being reused, the semantic change w= ould come from defining a mechanism to transition a stream from idle to ope= n state. One way around this is to reserve a stream(s) as you've mentioned.= However, I'd argue that this is also a semantic change, since endpoints ex= pect stream ID usage to follow RFC 7540. QUIC usage could be simpler I think, if this is pitched as a HTTP extension= , which possibly avoids the topic of QUIC extensions. If streams are reserv= ed, the DNS request/response could be carried as a QUIC STREAM frame (in a = similar way to how HTTP/QUIC DATA frames are). If the DNS frame concept is = to remain, it would itself be carried inside the QUIC STREAM frame. > > Such semantic changes require negotiation, for example by exchanging > > SETTINGS frames. This could be done on connection initiation and may > > solve your service discovery in a different way. >=20 > Or, a better solution for DNS-over-h2 could be made. This was just a stak= e in > the ground with a first guess. Other folks have suggested reserving strea= m > numbers for DNS, for example; that might be better than DNS frames. >=20 Stakes in the ground are helpful, so thanks for taking the time to write up= your ideas. Here's a stupid idea, how about hanging the DNS-inside-HTTP interactions of= f of a well-known URI? This solves some of the problems around stream initi= ation (using existing h2 semantics for lifecycle management or reservation)= . The DNS requests/responses are then carried as application payload in DAT= A frames. Apologies if this echoes other ideas thrown about for DNS-over-HT= TP that I am unfamiliar with. Regards Lucas From nobody Tue Apr 11 10:52:12 2017 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 9CC2512EB59 for ; Tue, 11 Apr 2017 10:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ynx19l_sQeW4 for ; Tue, 11 Apr 2017 10:52:09 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 2E2331294F4 for ; Tue, 11 Apr 2017 10:51:57 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cxzxK-0006t3-VR for quic@ietf.org; Tue, 11 Apr 2017 19:51:56 +0200 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 1cxzxH-0001w9-TA for quic@ietf.org; Tue, 11 Apr 2017 13:51:54 -0400 Received: (qmail 20926 invoked from network); 11 Apr 2017 17:51:50 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.160]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Apr 2017 17:51:49 -0000 To: Alexander Mayrhofer , "quic@ietf.org" , "dns-privacy@ietf.org" References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> <19F54F2956911544A32543B8A9BDE07598F48DC7@NICS-EXCH2.sbg.nic.at> From: Christian Huitema Message-ID: <39db2dc5-bc88-4d65-afff-bacc97402fb9@huitema.net> Date: Tue, 11 Apr 2017 10:51:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <19F54F2956911544A32543B8A9BDE07598F48DC7@NICS-EXCH2.sbg.nic.at> Content-Type: multipart/alternative; boundary="------------D776AC8F48E84B34AD3A6136" Subject: Re: AW: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.32) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrJGz50+ywp265ltAD5W329RcOb18WfxGyg6Om6u4YYm0obqRq73sdvAKRF SDe14485hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKXTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0gJNDFTTl q37emiIUthx/fbbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/g29p+HFVB92Ee/eBNmks60tPja4KzzyCWIS d9EAZBLgGyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+YzaHXGDtmr6LoB+LyIJrZ6Ke72V7y3QDXL8JTpxprEN X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 17:52:11 -0000 This is a multi-part message in MIME format. --------------D776AC8F48E84B34AD3A6136 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/10/2017 11:43 PM, Alexander Mayrhofer wrote: > > Hello Christian, > > =20 > > great to see this =E2=80=93 i remember when i mentioned QUIC as an opti= on > during the DNS-over-HTTP Bar BoF in Seoul i got quite a few weird > looks :). I like this. It looks like a logical choice somewhere > =E2=80=9Ebetween=E2=80=9C TLS and DTLS. > > =20 > > I have some background on Section 6.5 (Padding) =E2=80=93 back when we > specified DNS over TLS, we had a similar discussion whether to pad on > the DNS or the transport (TLS, in that case) layer. We decided in that > case that padding on the DNS layer is preferred, since it allows for > greater control by the application. This was actually the reason RFC > 7830 was created in the first place. > > =20 > > The situation might be different for QUIC as there=E2=80=99s a tighter > coupling between transport and application, though padding on the DNS > layer would allow re-using the ongoing research and specification work > in DPRIVE. (Disclaimer: I know little about the current state of such > research for QUIC). > > =20 > The situation is different in QUIC, because a single QUIC packet may carry several DNS packets, using separate STREAM-DATA frames to carry the content of different streams. Of course, the DNS application does not know whether the QUIC transport will in fact pack data from several streams in a single packet, so what we need here is some kind of API contract. The efficient solution would be to instruct the transport to perform a particular padding strategy, similar to the padding strategies developed for DNS. This would cover many applications, not just DNS. Failing that, padding at the DNS layer has the advantage of being easy to implement. -- Christian Huitema --------------D776AC8F48E84B34AD3A6136 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/10/2017 11:43 PM, Alexander Mayrhofer wrote:

Hello Christian,

 

great to see this – i remember when i mentioned QUIC as an option during the DNS-over-HTTP Bar BoF in Seoul i got quite a few weird looks :). I like this. It looks like a logical choice somewhere „between“ TLS and DTLS.

 

I have some background on Section 6.5 (Padding) – back when we specified DNS over TLS, we had a similar discussion whether to pad on the DNS or the transport (TLS, in that case) layer. We decided in that case that padding on the DNS layer is preferred, since it allows for greater control by the application. This was actually the reason RFC 7830 was created in the first place.

 

The situation might be different for QUIC as there’s a tighter coupling between transport and application, though padding on the DNS layer would allow re-using the ongoing research and specification work in DPRIVE. (Disclaimer: I know little about the current state of such research for QUIC).

 

The situation is different in QUIC, because a single QUIC packet may carry several DNS packets, using separate STREAM-DATA frames to carry the content of different streams. Of course, the DNS application does not know whether the QUIC transport will in fact pack data from several streams in a single packet, so what we need here is some kind of API contract.

The efficient solution would be to instruct the transport to perform a particular padding strategy, similar to the padding strategies developed for DNS. This would cover many applications, not just DNS. Failing that, padding at the DNS layer has the advantage of being easy to implement.

-- Christian Huitema
--------------D776AC8F48E84B34AD3A6136-- From nobody Tue Apr 11 11:12:39 2017 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 6719312EB76 for ; Tue, 11 Apr 2017 11:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.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 CmDnbbRaj9HI for ; Tue, 11 Apr 2017 11:12:35 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E6D12955F for ; Tue, 11 Apr 2017 11:12:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.37,186,1488873600"; d="asc'?scan'208";a="182109685" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx142-out.netapp.com with ESMTP; 11 Apr 2017 10:58:44 -0700 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 11:11:15 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 11 Apr 2017 11:11:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BDOWSPQZBpvX43BErmn9rte+ljsDrpkDzdvB2Hsk5Cc=; b=QGwbsCx5v5u4nUhqCDWhDoARMj31MSunjKuJTUDBi1Dy5NQU92Ueu+2zTzdlx3aXUK3QxpJgTNuAFmcRQCtZR8VVUs/qGLK8KgXxb0kab3n3peiBet85qGUREr4MQb8ltuTTBpQpE7I4RcBHC9POtC+9AwwtkoHvnM0sp7ePitM= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Tue, 11 Apr 2017 18:11:12 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.1019.025; Tue, 11 Apr 2017 18:11:12 +0000 From: "Eggert, Lars" To: "quic@ietf.org" Subject: Please review IETF-98 minutes Thread-Topic: Please review IETF-98 minutes Thread-Index: AQHSsu8A6js8sOHMHUSFYQ1KHra4YA== Date: Tue, 11 Apr 2017 18:11:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [216.240.19.104] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:+WDqajYAOBbLMg5N2uA8B2eoRY9ZU74fnIUpV1CYZIlFcjvxyiUJrSeAwBDUImBazaT3t0FMe4931TUpz/dIJyk9t7II3YiN+B0092634JE26zafVAdO6pwBtnFmHn3oFT/WaT7T3IS/rxTib31oBaDG9ySXHwHum77fTjXNf3ifAxb+5LO9GYDMZTMwtUjAlPRUkojW8qp5B/3c9Y6puxVsHVdKJ2dGyC9v32eeYy/9GDn4UG6+PtqrBRv5xGbe76n2sQAB3BEnZD6vAwnoCeJKB+OhNvlnm5Mkr2SrH3A1M+KmiqWwp7nqTrm3EdgIFLrNLmrYDguIxoacMv5fbQ== x-ms-office365-filtering-correlation-id: 43241a5e-701c-4672-fead-08d48106232d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN3PR0601MB1153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39850400002)(39840400002)(39450400003)(39400400002)(86362001)(81166006)(2351001)(3280700002)(8676002)(33656002)(1730700003)(83716003)(6512007)(2906002)(3660700001)(50226002)(8936002)(25786009)(189998001)(82746002)(5660300001)(36756003)(6436002)(2501003)(2900100001)(57306001)(38730400002)(99936001)(122556002)(110136004)(6116002)(3846002)(102836003)(6916009)(6506006)(6486002)(77096006)(66066001)(5640700003)(99286003)(53936002)(6306002)(50986999)(7736002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_0D1A6A59-0C2D-487A-9B2B-7AB80E78976D"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2017 18:11:12.3033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:12:37 -0000 --Apple-Mail=_0D1A6A59-0C2D-487A-9B2B-7AB80E78976D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, please take a minute to review (and correct, where needed) our minutes = from the IETF-98 meeting. Doubly so if you spoke at a microphone. = https://etherpad.tools.ietf.org/p/notes-ietf-98-quic?useMonospaceFont=3Dtr= ue We'll turn the contents of the Etherpad into the final minutes in a few = days. Lars PS: Magnus, I still owe you that beer for capturing all of that! --Apple-Mail=_0D1A6A59-0C2D-487A-9B2B-7AB80E78976D 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAljtHD0ACgkQVLXDCb9w wVc2IRAAqZQvsZka0CJ5n8ty+4kZ22oyVuzKbjRJlcCTfmWmR8NP+s4qhNpDK3ez RjB9816qpVf62PXW3RXwA2tnwOwyQfQEN0qkTLs0w2D+WTrv3N2qwMQtwyNBW1xl y42O4F9d3N5Rl+r/QpQq2JGPFq6Hm3hYYvbHTLaLclFGudI5IsCVaH3hOm4svqnb 8VM6h3BPBPqsndCuX9u2TF4ZpCOwWoQxirV2vvnPUHsw+IzXWC27WmgH6z5CXorY Tq0AdKYIS6lrN5B9rvcdT6+pjdmaF5SDJxoVJokWhbLe6HYwBaFlelkz5y7PZJI3 YsXhc3vr6tG3K50r712UOT/WG492NTPjEi165j64XgdE6RcE2pYKm8LBQQn/Boh4 tO6EdPscQ50DbYn7/lAUiN4Fe4AHCBJJPlp79MssmPkM8+B9sLRVhRpxLtBEaKod xB0nGxOJ/4/LFhYIdGZJJt/TWVRCD8djAD8lt+Je8Zjac18ysED0W/hoT678f10v WCW+eYHsE+JruZQfGV24C3x8BY0N7isAnc1QZ42wR95XPqmYdY86QHiTsP9Tf89t 1O22C0MBQvJYTw4zcLYtjuCR5ZaNGzBhTqm3oLYMIUzeNRbs+7GgYDldxapubm5G a4cIcdUmT10Jhkbrfs6vOCFPGjeZNAfzKmmogG4kR76MeViHltw= =56bq -----END PGP SIGNATURE----- --Apple-Mail=_0D1A6A59-0C2D-487A-9B2B-7AB80E78976D-- From nobody Tue Apr 11 11:18:47 2017 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 3DE1D12EBAE for ; Tue, 11 Apr 2017 11:18:46 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 7vaIgFYToN7n for ; Tue, 11 Apr 2017 11:18:44 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF9512EBB2 for ; Tue, 11 Apr 2017 11:18:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3w2Zzj51rpzMmp1; Tue, 11 Apr 2017 20:18:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghJS5_6sXNCl; Tue, 11 Apr 2017 20:18:08 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC2907.dip0.t-ipconnect.de [93.236.41.7]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 11 Apr 2017 20:18:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Please review IETF-98 minutes From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 11 Apr 2017 20:18:08 +0200 Cc: "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <27BBC67B-AFDD-4B67-9D59-9F6049E36B93@tik.ee.ethz.ch> References: To: "Eggert, Lars" X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:18:46 -0000 Did two small edits=E2=80=A6 thanks Magnus! Great job! > Am 11.04.2017 um 20:11 schrieb Eggert, Lars : >=20 > Hi, >=20 > please take a minute to review (and correct, where needed) our minutes = from the IETF-98 meeting. Doubly so if you spoke at a microphone. >=20 > = https://etherpad.tools.ietf.org/p/notes-ietf-98-quic?useMonospaceFont=3Dtr= ue >=20 > We'll turn the contents of the Etherpad into the final minutes in a = few days. >=20 > Lars >=20 > PS: Magnus, I still owe you that beer for capturing all of that! From nobody Tue Apr 11 11:24:58 2017 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 6A33012EC28 for ; Tue, 11 Apr 2017 11:24:52 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bZ3tlowco8Ds for ; Tue, 11 Apr 2017 11:24:50 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 3C21312EC2D for ; Tue, 11 Apr 2017 11:23:39 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id v3so4705318qtd.3 for ; Tue, 11 Apr 2017 11:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UXdC974F80oGDTfzhlG3n4Bzq0J8fBw3ejMlQ1vkcDE=; b=ooAa7pUVJVv6iIf2f9E9OvnVQhKaNIo0tkBNe2mfjrh8KYlv4ofa0B41ZEWwU05K// CZnHy4KsW0fJQ0p9M8nNBTE3Xdg2szw2TmjnCqjvomVWMoNSN02b5HXqfRuRdiVYh/u/ AzTvsTB1OPOs+316V/F8pvzytCP6vWe6YAx+fo53VOm9KSQxqh3vN7vR/VASFS3BQON1 oTiePUmEPGx90z8uzVlvYdejkFZT3izcARI/KwFfYS5uDagnGKHjlxtM6GBZ3qBe5UUG Typq85F2H7lu/9DnCBxIm0X+h52nZSWjVU2k4Mc5J2HEk1XcdAfBPmAqtj8Z+N7ccBLh /FFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UXdC974F80oGDTfzhlG3n4Bzq0J8fBw3ejMlQ1vkcDE=; b=ClrdRiaqtTSa1qsh889aamfAaUwTcUZK0rO9keRqnoTDb/RBr4czBfiAd8qdQ/mU8w oEo8cZ1/JiixwIhaOwVO1hfGGkGu59GP1HMwkJvXAd3SXa18P1juy9XPtpfCyPUuKXbN d7pArmEEuBIb44zQxyoHvuJVt/cD7JH4gRi+pz9bQfJDBh8JAcEfMMMpJTsqDrAp5WHP WjkGcDo8xbLTvNj/I7twboyQltd5kqpfCfkjua22ZMzjQA/rasxVDQZgS4DDK6/nOfPZ iNYkCC/iM9tjDkx03Es6lYjeZI3uD9mAN0oTREfrCGCzcbog0lH0ozxpNq9SJ3jMQQ3e KkWA== X-Gm-Message-State: AFeK/H2TGSlcIcH2d+r5KJXK2Ff570X5w4hbnreLRFaUAy3syLB0PSzL2HOfjLdw+xU/uCmnNRKDJCRHw1n4nF/T X-Received: by 10.237.40.66 with SMTP id r60mr63745771qtd.42.1491935018294; Tue, 11 Apr 2017 11:23:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.76.81 with HTTP; Tue, 11 Apr 2017 11:23:37 -0700 (PDT) In-Reply-To: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> From: Victor Vasiliev Date: Tue, 11 Apr 2017 14:23:37 -0400 Message-ID: Subject: Re: Consensus Call on issues closed by the -02 drafts To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary=001a1148755acb8efb054ce8303e Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:24:53 -0000 --001a1148755acb8efb054ce8303e Content-Type: text/plain; charset=UTF-8 On Fri, Mar 17, 2017 at 5:22 AM, Mark Nottingham wrote: > #126 - Separate transport parameters for 0-RTT > I am not certain we are ready to fully close #126. I have expressed some concerns about the complexity of the current approach on the list some time before, and proposed a simplified scheme (). -- Victor. --001a1148755acb8efb054ce8303e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 17, 2017 at 5:22 AM, Mark Nottingham <mnot@mnot.net> wr= ote:
#126 - Separate t= ransport parameters for 0-RTT

I am= not certain we are ready to fully close #126.=C2=A0 I have expressed some<= /div>
concerns about the complexity of the current approach on the list= some time
before, and proposed a simplified scheme

=C2=A0 -- Victor.
<= /div> --001a1148755acb8efb054ce8303e-- From nobody Tue Apr 11 11:39:56 2017 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 9774812EBFF; Tue, 11 Apr 2017 11:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 9CMT48ObGhKN; Tue, 11 Apr 2017 11:39:44 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC62A12EC0A; Tue, 11 Apr 2017 11:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wp4IyPCfB3nzTk2HxI8QMxpc3/LAqybgADDs1JHDQpI=; b=QSBCphzt5Ky2rjiNj/LSdbXGywmY4RVi2NRwX3IrxKpH77Hwsq9wuzRo5tBRZdpys3zp7mgQxyWsmKA+TFmKSpeGA+cfNgrp45org4Vv6IvrQPJj7XI+lZJcLLrT8puQGmit7Z1z864M0uzKAZbtMXyWf6DPw+mdsGjvTZtaqpc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Tue, 11 Apr 2017 18:39:36 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1019.025; Tue, 11 Apr 2017 18:39:36 +0000 From: Mike Bishop To: huitema , "quic@ietf.org" , "dns-privacy@ietf.org" Subject: RE: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt Thread-Topic: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt Thread-Index: AQHSsh8Zi+JVfi/DOEOY9pX/8e8kBKHAfzMA Date: Tue, 11 Apr 2017 18:39:36 +0000 Message-ID: References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huitema.net; dkim=none (message not signed) header.d=none;huitema.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::51f] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:AjVtyhmG4GMJpDFGRD4RDxtRiM84FDJz/2O6ScDNFWx2/fPIERrcctuJZQskjXv/xPeKGMQ6cE1Z8Jer4H7iWi67sbAxly05KZZjs4CHve4efsjOWqI4RBZtiUOJi4gDMI2gAWj/pQ+2ruvt/unDc2q1czu7VGepYSeJ3Aku40UleDIqIZHpMHemS+1aMuSV3zuo/2jg+Wyya/++5k4LTPHEQHsXs9JCIH0tfjc9pfIMirqIRS+cpkI8ZhO0Z5Znb7GxqKrpXxbOyFQu14DWMvH/8M+sPIlRearogMaTqFUMsa7f4cAbQsOa4M1tQkw1EnxxAt6U4738pJl1Ws7/Vj/Ri6ywN4PHzhoURLbsxzg= x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: dfda9b37-821e-4cdb-fc0f-08d4810a1b0c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN6PR03MB2708; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(189930954265078)(788757137089)(211936372134217)(206333022235701)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39850400002)(39860400002)(39400400002)(39410400002)(39450400003)(377454003)(377424004)(6506006)(53936002)(54896002)(99286003)(606005)(9686003)(55016002)(77096006)(236005)(6436002)(6306002)(230783001)(2906002)(102836003)(790700001)(122556002)(6116002)(25786009)(76176999)(6246003)(8936002)(50986999)(5005710100001)(10290500002)(15650500001)(2950100002)(2420400007)(3280700002)(3660700001)(54356999)(10710500007)(10090500001)(86362001)(189998001)(2900100001)(33656002)(2501003)(81166006)(38730400002)(7110500001)(8676002)(229853002)(8990500004)(5660300001)(53546009)(7736002)(2201001)(7906003)(7696004)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708062197E49BF2F98402B487000BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2017 18:39:36.8333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:39:47 -0000 --_000_BN6PR03MB2708062197E49BF2F98402B487000BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ3JlYXQg4oCTIEnigJltIGV4Y2l0ZWQgdG8gaGF2ZSBhbm90aGVyIGNvbmNyZXRlIGFw cGxpY2F0aW9uIHByb2ZpbGUgd2UgY2FuIGxvb2sgYXQuDQoNCkFzIGEgc2lkZSBub3RlLCBJIHRo aW5rIDQuNCBtaXNjaGFyYWN0ZXJpemVzIGFueSByZWNlbnQgZHJhZnQgb2YgSFRUUC9RVUlDLiAg QW4gSFRUUCBzZXJ2ZXIgZG9lcyBleHBsaWNpdGx5IG5lZWQgdG8gbGlzdGVuIGZvciBjbGllbnQt aW5pdGlhdGVkIHN0cmVhbXMgb3BlbmluZzsgdGhlcmXigJlzIG5vIGFubm91bmNlbWVudCBvZiB0 aGlzIGhhcHBlbmluZyBvbiBTdHJlYW0gMyBhcyB5b3UgZGVzY3JpYmUuICBUaGUgbWFpbiBlZmZl Y3Qgb2YgY2hvb3NpbmcgdG8gaGF2ZSBubyBjb250cm9sIHN0cmVhbSBpcyB0aGF0IHRoZXJlIGNh biBiZSBubyByZWxpYWJsZSBzZXNzaW9uLWxldmVsIGFwcGxpY2F0aW9uIGNvbnRleHQsIHNpbmNl IGRhdGEgb24gYW55IHN0cmVhbSBjYW4gYmUgbG9zdCB2aWEgYSBzdHJlYW0gcmVzZXQgYXQgdGhl IHdyb25nIHRpbWUuDQoNCjUuMi4yIGlzIGFuIGV4YW1wbGUgb2YgdGhpcyBpc3N1ZSDigJMgaG93 IHdpbGwgdGhlIFNFUlZGQUlMIGJlIHJlbGlhYmx5IGRlbGl2ZXJlZCBpZiB0aGUgc3RyZWFtIGlz IHJlc2V0PyAgWW91IHByb2JhYmx5IG5lZWQgdG8gZWl0aGVyIGRlZmluZSBlcnJvciBjb2RlcyBm b3IgRE5TL1FVSUMgYW5kIHJlcGxhY2UgU0VSVkZBSUwgd2l0aCB0aG9zZSwgb3IgcmVsaWFibHkg ZGVsaXZlciB0aGUgU0VSVkZBSUwgKHNvbWVob3cg4oCTIGJ5IG5ldmVyIHJlc2V0dGluZyBzdHJl YW1zPykuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxMCwgMjAxNyAx MDoyMyBBTQ0KVG86IHF1aWNAaWV0Zi5vcmc7IGRucy1wcml2YWN5QGlldGYub3JnDQpTdWJqZWN0 OiBGd2Q6IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWl0ZW1hLXF1 aWMtZG5zb3F1aWMtMDAudHh0DQoNCg0KRllJOiBKdXN0IHB1Ymxpc2hlZCB0aGlzIGRyYWZ0IGRl c2NyaWJpbmcgdHJhbnNwb3J0IG9mIEROUyBvdmVyIGEgZGVkaWNhdGVkIFFVSUMgY29ubmVjdGlv bi4NCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0t LS0tLS0tDQpTdWJqZWN0Og0KDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1 aXRlbWEtcXVpYy1kbnNvcXVpYy0wMC50eHQNCg0KRGF0ZToNCg0KTW9uLCAxMCBBcHIgMjAxNyAw OTo0NTozNyAtMDcwMA0KDQpGcm9tOg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KVG86DQoNCk1lbGluZGEgU2hvcmUgPG1zaG9y ZUBmYXN0bHkuY29tPjxtYWlsdG86bXNob3JlQGZhc3RseS5jb20+LCBTYXJhIERpY2tpbnNvbiA8 c2FyYUBzaW5vZHVuLmNvbT48bWFpbHRvOnNhcmFAc2lub2R1bi5jb20+LCBDaHJpc3RpYW4gSHVp dGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD48bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+LCBB bGxpc29uIE1hbmtpbiA8YW1hbmtpbkBzYWxlc2ZvcmNlLmNvbT48bWFpbHRvOmFtYW5raW5Ac2Fs ZXNmb3JjZS5jb20+LCBKYW5hcmRoYW4gSXllbmdhciA8anJpQGdvb2dsZS5jb20+PG1haWx0bzpq cmlAZ29vZ2xlLmNvbT4sIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+PG1haWx0bzpqcmlA Z29vZ2xlLmNvbT4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odWl0ZW1hLXF1 aWMtZG5zb3F1aWMtMDAudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg Q2hyaXN0aWFuIEh1aXRlbWEgYW5kIHBvc3RlZCB0byB0aGUNCg0KSUVURiByZXBvc2l0b3J5Lg0K DQoNCg0KTmFtZTogICAgICAgICAgZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljDQoNClJldmlz aW9uOiAgICAgIDAwDQoNClRpdGxlOiAgICAgICAgIFNwZWNpZmljYXRpb24gb2YgRE5TIG92ZXIg UVVJQw0KDQpEb2N1bWVudCBkYXRlOiAyMDE3LTA0LTEwDQoNCkdyb3VwOiAgICAgICAgIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KDQpQYWdlczogICAgICAgICAxOA0KDQpVUkw6ICAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1aXRlbWEtcXVpYy1k bnNvcXVpYy0wMC50eHQ8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpbnRlcm5ldC1kcmFmdHMlMkZk cmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0JmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwu YmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3QzVkZjAwYTUxYmZlNjRiMTZjYTRiMDhkNDgwMzYzYWIz JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI3NDQxNzc4 MjMzMjIyMiZzZGF0YT1ReERnZVlqNk5NSHNlVktjZ1klMkZ2OHBnTHFqMDlhdlYxUG5HYU9Kdjcl MkIzYyUzRCZyZXNlcnZlZD0wPg0KDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLzxodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0 cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljJTJGJmRh dGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3QzVkZjAwYTUxYmZl NjRiMTZjYTRiMDhkNDgwMzYzYWIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjI3NDQxNzc4MjMzMjIyMiZzZGF0YT1jN011T3hxMnczTDJqejNNV2N3QTk2 Z0NKcThsM2NrR2puQ0Y2ZkhKZk5rJTNEJnJlc2VydmVkPTA+DQoNCkh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAw PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29x dWljLTAwJmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3QzVk ZjAwYTUxYmZlNjRiMTZjYTRiMDhkNDgwMzYzYWIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI3NDQxNzc4MjMzMjIyMiZzZGF0YT1pNG5CSm1zMVdad1Jv Nzh2QVpXRlNBbGZ1SDQ5SDh6RDJXalFJdTJHcXdjJTNEJnJlc2VydmVkPTA+DQoNCkh0bWxpemVk OiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWh1aXRl bWEtcXVpYy1kbnNvcXVpYy0wMDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJG aHRtbCUyRmRyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy0wMCZkYXRhPTAyJTdDMDElN0NtaWNo YWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0M1ZGYwMGE1MWJmZTY0YjE2Y2E0YjA4ZDQ4MDM2 M2FiMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzQ0 MTc3ODIzMzIyMjImc2RhdGE9Snl3WlllaHkzQXhjN3NEWHNrTTJtR2VXNGtkaWlQQlNNWmxiaWNE MU41OCUzRCZyZXNlcnZlZD0wPg0KDQoNCg0KDQoNCkFic3RyYWN0Og0KDQogICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9mIFFVSUMgdG8gcHJvdmlkZSB0cmFuc3BvcnQgcHJpdmFj eQ0KDQogICBmb3IgRE5TLiAgVGhlIGVuY3J5cHRpb24gcHJvdmlkZWQgYnkgUVVJQyBoYXMgc2lt aWxhciBwcm9wZXJ0aWVzIHRvDQoNCiAgIHRoYXQgcHJvdmlkZWQgYnkgVExTLCB3aGlsZSBRVUlD IHRyYW5zcG9ydCBlbGltaW5hdGVzIHRoZSBoZWFkLW9mLQ0KDQogICBsaW5lIGJsb2NraW5nIGlz c3VlcyBpbmhlcmVudCB3aXRoIFRDUCBhbmQgcHJvdmlkZXMgbW9yZSBlZmZpY2llbnQNCg0KICAg ZXJyb3IgY29ycmVjdGlvbnMgdGhhbiBVRFAuICBETlMgb3ZlciBRVUlDIGhhcyBwcml2YWN5IHBy b3BlcnRpZXMNCg0KICAgc2ltaWxhciB0byBETlMgb3ZlciBUTFMgc3BlY2lmaWVkIGluIFJGQzc4 NTgsIGFuZCBwZXJmb3JtYW5jZSBzaW1pbGFyDQoNCiAgIHRvIGNsYXNzaWMgRE5TIG92ZXIgVURQ Lg0KDQoNCg0KDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --_000_BN6PR03MB2708062197E49BF2F98402B487000BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+TG9va3MgZ3JlYXQg4oCTIEnigJltIGV4Y2l0ZWQg dG8gaGF2ZSBhbm90aGVyIGNvbmNyZXRlIGFwcGxpY2F0aW9uIHByb2ZpbGUgd2UgY2FuIGxvb2sg YXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5BcyBhIHNpZGUg bm90ZSwgSSB0aGluayA0LjQgbWlzY2hhcmFjdGVyaXplcyBhbnkgcmVjZW50IGRyYWZ0IG9mIEhU VFAvUVVJQy4mbmJzcDsgQW4gSFRUUCBzZXJ2ZXIgZG9lcyBleHBsaWNpdGx5IG5lZWQgdG8gbGlz dGVuIGZvciBjbGllbnQtaW5pdGlhdGVkIHN0cmVhbXMgb3BlbmluZzsgdGhlcmXigJlzIG5vIGFu bm91bmNlbWVudCBvZiB0aGlzIGhhcHBlbmluZyBvbg0KIFN0cmVhbSAzIGFzIHlvdSBkZXNjcmli ZS4mbmJzcDsgVGhlIG1haW4gZWZmZWN0IG9mIGNob29zaW5nIHRvIGhhdmUgbm8gY29udHJvbCBz dHJlYW0gaXMgdGhhdCB0aGVyZSBjYW4gYmUgbm8gcmVsaWFibGUgc2Vzc2lvbi1sZXZlbCBhcHBs aWNhdGlvbiBjb250ZXh0LCBzaW5jZSBkYXRhIG9uIGFueSBzdHJlYW0gY2FuIGJlIGxvc3Qgdmlh IGEgc3RyZWFtIHJlc2V0IGF0IHRoZSB3cm9uZyB0aW1lLiZuYnNwOw0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij41LjIuMiBpcyBhbiBleGFtcGxlIG9mIHRoaXMg aXNzdWUg4oCTIGhvdyB3aWxsIHRoZSBTRVJWRkFJTCBiZSByZWxpYWJseSBkZWxpdmVyZWQgaWYg dGhlIHN0cmVhbSBpcyByZXNldD8mbmJzcDsgWW91IHByb2JhYmx5IG5lZWQgdG8gZWl0aGVyIGRl ZmluZSBlcnJvciBjb2RlcyBmb3IgRE5TL1FVSUMgYW5kIHJlcGxhY2UgU0VSVkZBSUwgd2l0aCB0 aG9zZSwgb3IgcmVsaWFibHkNCiBkZWxpdmVyIHRoZSBTRVJWRkFJTCAoc29tZWhvdyDigJMgYnkg bmV2ZXIgcmVzZXR0aW5nIHN0cmVhbXM/KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBRVUlDIFttYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RpYW4gSHVpdGVt YTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDEwLCAyMDE3IDEwOjIzIEFNPGJyPg0K PGI+VG86PC9iPiBxdWljQGlldGYub3JnOyBkbnMtcHJpdmFjeUBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBGd2Q6IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1o dWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RllJOiBKdXN0IHB1Ymxpc2hlZCB0aGlzIGRyYWZ0IGRlc2NyaWJpbmcgdHJh bnNwb3J0IG9mIEROUyBvdmVyIGEgZGVkaWNhdGVkIFFVSUMgY29ubmVjdGlvbi4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIENocmlzdGlhbiBIdWl0ZW1h PGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0gPG86cD48L286 cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFj aW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZh bGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+U3ViamVj dDogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5EYXRlOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Nb24sIDEwIEFwciAyMDE3IDA5OjQ1OjM3IC0wNzAwPG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Gcm9tOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N Cjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWdu OnJpZ2h0Ij48Yj5UbzogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWVsaW5kYSBTaG9y ZSA8YSBocmVmPSJtYWlsdG86bXNob3JlQGZhc3RseS5jb20iPiZsdDttc2hvcmVAZmFzdGx5LmNv bSZndDs8L2E+LCBTYXJhIERpY2tpbnNvbg0KPGEgaHJlZj0ibWFpbHRvOnNhcmFAc2lub2R1bi5j b20iPiZsdDtzYXJhQHNpbm9kdW4uY29tJmd0OzwvYT4sIENocmlzdGlhbiBIdWl0ZW1hIDxhIGhy ZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij4NCiZsdDtodWl0ZW1hQGh1aXRlbWEubmV0 Jmd0OzwvYT4sIEFsbGlzb24gTWFua2luIDxhIGhyZWY9Im1haWx0bzphbWFua2luQHNhbGVzZm9y Y2UuY29tIj4NCiZsdDthbWFua2luQHNhbGVzZm9yY2UuY29tJmd0OzwvYT4sIEphbmFyZGhhbiBJ eWVuZ2FyIDxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+Jmx0O2pyaUBnb29nbGUuY29t Jmd0OzwvYT4sIEphbmEgSXllbmdhcg0KPGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIj4m bHQ7anJpQGdvb2dsZS5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0PG86cD48L286cD48L3ByZT4N CjxwcmU+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaHJpc3RpYW4gSHVpdGVt YSBhbmQgcG9zdGVkIHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklFVEYgcmVwb3NpdG9y eS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5O YW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZXZp c2lvbjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgU3BlY2lmaWNhdGlvbiBvZiBETlMgb3ZlciBRVUlDPG86cD48L286cD48L3ByZT4NCjxwcmU+ RG9jdW1lbnQgZGF0ZTogMjAxNy0wNC0xMDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkdyb3VwOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFs IFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5QYWdlczombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTg8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGaW50ZXJuZXQt ZHJhZnRzJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAwLnR4dCZhbXA7ZGF0YT0wMiU3 QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDNWRmMDBhNTFiZmU2NGIxNmNh NGIwOGQ0ODAzNjNhYjMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM2Mjc0NDE3NzgyMzMyMjIyJmFtcDtzZGF0YT1ReERnZVlqNk5NSHNlVktjZ1klMkZ2OHBn THFqMDlhdlYxUG5HYU9KdjclMkIzYyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy0wMC50eHQ8 L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmll dGYub3JnJTJGZG9jJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljJTJGJmFtcDtkYXRhPTAy JTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0M1ZGYwMGE1MWJmZTY0YjE2 Y2E0YjA4ZDQ4MDM2M2FiMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3 QzAlN0M2MzYyNzQ0MTc3ODIzMzIyMjImYW1wO3NkYXRhPWM3TXVPeHEydzNMMmp6M01XY3dBOTZn Q0pxOGwzY2tHam5DRjZmSEpmTmslM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy88L2E+PG86cD48L286 cD48L3ByZT4NCjxwcmU+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaHVpdGVt YS1xdWljLWRuc29xdWljLTAwJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1p Y3Jvc29mdC5jb20lN0M1ZGYwMGE1MWJmZTY0YjE2Y2E0YjA4ZDQ4MDM2M2FiMyU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzQ0MTc3ODIzMzIyMjImYW1w O3NkYXRhPWk0bkJKbXMxV1p3Um83OHZBWldGU0FsZnVINDlIOHpEMldqUUl1Mkdxd2MlM0QmYW1w O3Jlc2VydmVkPTAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWl0ZW1hLXF1 aWMtZG5zb3F1aWMtMDA8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+SHRtbGl6ZWQ6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNr ZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAw JmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0M1ZGYw MGE1MWJmZTY0YjE2Y2E0YjA4ZDQ4MDM2M2FiMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzQ0MTc3ODIzMzIyMjImYW1wO3NkYXRhPUp5d1pZZWh5M0F4 YzdzRFhza00ybUdlVzRrZGlpUEJTTVpsYmljRDFONTglM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29x dWljLTAwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFic3RyYWN0OjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNl IG9mIFFVSUMgdG8gcHJvdmlkZSB0cmFuc3BvcnQgcHJpdmFjeTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBmb3IgRE5TLiZuYnNwOyBUaGUgZW5jcnlwdGlvbiBwcm92aWRlZCBi eSBRVUlDIGhhcyBzaW1pbGFyIHByb3BlcnRpZXMgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgdGhhdCBwcm92aWRlZCBieSBUTFMsIHdoaWxlIFFVSUMgdHJhbnNwb3J0IGVs aW1pbmF0ZXMgdGhlIGhlYWQtb2YtPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGxpbmUgYmxvY2tpbmcgaXNzdWVzIGluaGVyZW50IHdpdGggVENQIGFuZCBwcm92aWRlcyBtb3Jl IGVmZmljaWVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBlcnJvciBjb3Jy ZWN0aW9ucyB0aGFuIFVEUC4mbmJzcDsgRE5TIG92ZXIgUVVJQyBoYXMgcHJpdmFjeSBwcm9wZXJ0 aWVzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNpbWlsYXIgdG8gRE5TIG92 ZXIgVExTIHNwZWNpZmllZCBpbiBSRkM3ODU4LCBhbmQgcGVyZm9ybWFuY2Ugc2ltaWxhcjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0byBjbGFzc2ljIEROUyBvdmVyIFVEUC48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIElFVEYg U2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708062197E49BF2F98402B487000BN6PR03MB2708namp_-- From nobody Tue Apr 11 11:44:40 2017 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 9187B129666 for ; Tue, 11 Apr 2017 11:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 rLQ-aebvFo3g for ; Tue, 11 Apr 2017 11:44:37 -0700 (PDT) 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 253F3126557 for ; Tue, 11 Apr 2017 11:44:37 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1cy0mI-0000Y2-UK for quic@ietf.org; Tue, 11 Apr 2017 20:44:35 +0200 Received: from internal.xmail05.myhosting.com ([10.5.2.15] helo=xmail05.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cy0mF-0007ch-Te for quic@ietf.org; Tue, 11 Apr 2017 14:44:33 -0400 Received: (qmail 21661 invoked from network); 11 Apr 2017 18:44:29 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.160]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Apr 2017 18:44:29 -0000 To: "quic@ietf.org" From: Christian Huitema Message-ID: Date: Tue, 11 Apr 2017 11:44:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Security considerations in quic-transport X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.32) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpFecTGP9CXAcOkTqvyaKMGRcOb18WfxGyg6Om6u4YYm4PvKV0M80QaKZBW KmvezcI5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQ3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0oWv9YjF5 UZ6Npj938pvFGbbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa6vHnVUqJLghgshblzhtFXwZHvOQHxWHf0ql zmk851EbxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+3pSiCKkaAoX/nv7Y+HHGvPcu6wTHpnlfUs9BUPj1rZ3 X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:44:38 -0000 I am looking at the security considerations in the transport draft. There is a section describing the ACK spoofing attack, which is good, but there are quite a few other things that come to mind, which would mimic attacks that we have seen on TCP in the past. An example: 1) Stream smurfing attack. Client (or server) opens a large number of streams by sending stream data frames with new stream number and minimal content. 2) Stream choke attack. Client sends request on a stream, then use stream level flow control to choke the transmission by the server. Apply to many parallel streams for bonus effect. 3) Silly stream number attack. Client opens stream 2*N+1 for some outlandish version of N. Might play havoc with server management of incoming streams. 4) Stream drop by drop attack. Client sends data on a stream extremely slowly, maybe 1 byte at a time. Server spin its wheels waiting for data. There are probably some more. Should these be documented? -- Christian Huitema From nobody Tue Apr 11 11:48:25 2017 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 304F812EBF7 for ; Tue, 11 Apr 2017 11:48:24 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 B96_xKfIeklf for ; Tue, 11 Apr 2017 11:48:22 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 74EC712EC12 for ; Tue, 11 Apr 2017 11:48:22 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id 21so2704593pgg.1 for ; Tue, 11 Apr 2017 11:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qVAUZaU3aYgWTxwhQ1QVONoyADs7FHd/gPnOG8ohs8k=; b=i7H1xDkCZj4+S+R8zFvMEUH0MLnJs9lOftADGjrHbBkdCyhUIHmpT1W8rzvI4TMiXS A9Ce5RWgXpiyug9WtBOSCp77bvNnaPKlFxbbLuVC6AYgiUSy5cJf2fpP/D6t2EfcyFpD 78lPOzLFIn22TGeenK4liI3lifUYhK3T/DNAFaZQ8fqm/2oVBVCbyLj1NAuRyKFaKan/ aKbScEEx49ge4JmPdTbe5mQLB3B7HqcJc44OS9yvdIatkeFrkgcW/t1gR2iZXUU0OA54 PArkmfp/fcmmd54mZ5hTERF7UTU/K/X02guhhPoM4uaE1S6+Xdx7KFa05YrqTd6TzYGc rcaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qVAUZaU3aYgWTxwhQ1QVONoyADs7FHd/gPnOG8ohs8k=; b=YqOd4B4Fw6IK6gP2PG0COkkYqO/VsZIX80MeXu7v89YqRv98lz2nIktgIQy9lsdrIM FX4iWAjufIKJmZmAGnPACVAMK61h3nfv8gLhEOkL4ufbDp1oRszBRvIKXHxIRPLC75ZD J/Cgl19jq2QKkhuLt8A7NJ+ndyIQ9gXSANZnmjsxKH4FlbL5yfr55p9pdDSwvQyyAxem SRyy3pIlTKuvMp7xb1g3h//Y/7w408SbatZUVhefCJuDEGvn8El2qw49AB2js+bDj237 dTjyBG4B9Chs7PiCUobKFNNLmuZ9rE+Q6htZzaB8NaaiN/ggCEZ+3RM5ryAXN47b34iL qscQ== X-Gm-Message-State: AN3rC/6RRlgcCZDV30fVmofuOtuJ0nMZesXiQ2mRoW1A0U3U7zn4LYpV37qHEb5u+bcO5gRPFH96ufqbmmb89Va1 X-Received: by 10.98.139.208 with SMTP id e77mr13919832pfl.64.1491936501739; Tue, 11 Apr 2017 11:48:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.161.208 with HTTP; Tue, 11 Apr 2017 11:48:21 -0700 (PDT) In-Reply-To: <27BBC67B-AFDD-4B67-9D59-9F6049E36B93@tik.ee.ethz.ch> References: <27BBC67B-AFDD-4B67-9D59-9F6049E36B93@tik.ee.ethz.ch> From: Jana Iyengar Date: Tue, 11 Apr 2017 11:48:21 -0700 Message-ID: Subject: Re: Please review IETF-98 minutes To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "Eggert, Lars" , "quic@ietf.org" Content-Type: multipart/alternative; boundary=f403045ccbb83720ef054ce8894d Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:48:24 -0000 --f403045ccbb83720ef054ce8894d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable LGTM -- thanks, Magnus! On Tue, Apr 11, 2017 at 11:18 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Did two small edits=E2=80=A6 thanks Magnus! Great job! > > > Am 11.04.2017 um 20:11 schrieb Eggert, Lars : > > > > Hi, > > > > please take a minute to review (and correct, where needed) our minutes > from the IETF-98 meeting. Doubly so if you spoke at a microphone. > > > > https://etherpad.tools.ietf.org/p/notes-ietf-98-quic? > useMonospaceFont=3Dtrue > > > > We'll turn the contents of the Etherpad into the final minutes in a few > days. > > > > Lars > > > > PS: Magnus, I still owe you that beer for capturing all of that! > > --f403045ccbb83720ef054ce8894d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
LGTM -- thanks, Magnus!
On Tue, Apr 11, 2017 at 11:18 AM, Mirja K=C3= =BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> w= rote:
Did two small edits=E2=80=A6 thanks= Magnus! Great job!

> Am 11.04.2017 um 20:11 schrieb Eggert, Lars <lars@netapp.com>:
>
> Hi,
>
> please take a minute to review (and correct, where needed) our minutes= from the IETF-98 meeting. Doubly so if you spoke at a microphone.
>
> https://etherpad.to= ols.ietf.org/p/notes-ietf-98-quic?useMonospaceFont=3Dtrue
>
> We'll turn the contents of the Etherpad into the final minutes in = a few days.
>
> Lars
>
> PS: Magnus, I still owe you that beer for capturing all of that!


--f403045ccbb83720ef054ce8894d-- From nobody Thu Apr 13 10:53:46 2017 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 5F3E312EC8E for ; Thu, 13 Apr 2017 10:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 toZHzBPZdthJ for ; Thu, 13 Apr 2017 10:53:41 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (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 989B212EB07 for ; Thu, 13 Apr 2017 10:53:40 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id l201so15268569ybf.0 for ; Thu, 13 Apr 2017 10:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hurBFfDk5ifs3ezRsc6iXy5SC1fsZhXUw/JhE9OoXkc=; b=qatvRyVCaw6L61cCIZ21+pjLpxYP/3HF8n3LBKAEbKl4Q1oZvq3ttDb4QlTIoR6ApJ 8xtpaBJXRM52ABPU9iwvCwLo4sv62lFVIFQfbUzJrnGQbt+gnVItf8jpofpjs7WfBzzZ SYtH9ZJOOYQCQe9d9mI77SXpvR3pHJ5imxtmcdk7krIddpnQPQzf+eS310Z3uNtCbzD3 fx5XRU50A0+fN/uaarkGxuKlce9uKDXqwoZgLXupdRDde8CX59zCejhQDk0ov+3RIr+U zHh1FEWYLeMrVR9j40MQoY7YVblYclHMmlBGacYIEcUXzcBKBtf9RVXjvFueTaFdTNG0 H+Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hurBFfDk5ifs3ezRsc6iXy5SC1fsZhXUw/JhE9OoXkc=; b=JgthJq3GKeM+J3AcDDJ8om1pLU8Nm4t+nefCTi2ExBBfP0YB5Bm8VbxVbEXGNmvtRv Wvtme8temlExc3mth7qYNPDk1SRJDitkN5R8k2R/m16vaMY+6844XMZ3d3WJQwq4/2b9 J1bZQmUMlSvA9RkKyV1y44KeJbUBUfqmTLWOH45WZOfVGAMeoHV2J5nc+xY3upU3qtTg Ag9slCwS8trX+qp8U+nvDTzZd3GUdOUTVk4+RkItj0y2rbZuTEfjZTroDZJ+lep+p7+2 +pTJu/kEleIpEIhshVORfJ1l5Mit4XJxQiBKuvEGuTLplO0ZrzFSa4bmB2KDXHiExHcb W8pg== X-Gm-Message-State: AN3rC/6CclqmXCiNTzB+fOmDloC/AT8VtP+VTVzRFNO6MRYtGR/h7krw uqoXWlllptkqugUy3VgAhCr/ON2U5g== X-Received: by 10.37.172.100 with SMTP id r36mr3351991ybd.107.1492106019901; Thu, 13 Apr 2017 10:53:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 13 Apr 2017 10:52:59 -0700 (PDT) In-Reply-To: References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> From: Eric Rescorla Date: Thu, 13 Apr 2017 10:52:59 -0700 Message-ID: Subject: Re: Consensus Call on issues closed by the -02 drafts To: Victor Vasiliev Cc: Mark Nottingham , IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary=f403045eb69a48ad13054d100153 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 17:53:44 -0000 --f403045eb69a48ad13054d100153 Content-Type: text/plain; charset=UTF-8 I concur with Victor that this could use additional discussion, though I would want to consider yet another pattern, in which the client always gets its params from the server and in 0-RTT tells the server "this is what you said last time" as we do with ALPN. In any case, needs more discussion. -Ekr On Tue, Apr 11, 2017 at 11:23 AM, Victor Vasiliev wrote: > On Fri, Mar 17, 2017 at 5:22 AM, Mark Nottingham wrote: > >> #126 - Separate transport parameters for 0-RTT >> > > I am not certain we are ready to fully close #126. I have expressed some > concerns about the complexity of the current approach on the list some time > before, and proposed a simplified scheme > (). > > -- Victor. > --f403045eb69a48ad13054d100153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I concur with Victor that this could use additional discus= sion, though I would
want to consider yet another pattern, in which the= client always gets its
params from the server and in 0-RTT tells= the server "this is what you
said last time" as we do = with ALPN. In any case, needs more discussion.

<= /div>
-Ekr


On Tue, Apr 11, 2017 at 11:= 23 AM, Victor Vasiliev <vasilvv@google.com> wrote:
On Fri, Mar 17, 2017 at 5:22 AM, Mar= k Nottingham <mnot@mnot.net> wrote:
#126 - Separate transport parameters for 0-RTT

I am not certain we are ready= to fully close #126.=C2=A0 I have expressed some
concerns about = the complexity of the current approach on the list some time
befo= re, and proposed a simplified scheme

<= /div>
=C2=A0 -- Victor.

--f403045eb69a48ad13054d100153-- From nobody Thu Apr 13 11:10:28 2017 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 531FA13153E for ; Thu, 13 Apr 2017 11:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 Hv50VtwJ8se5 for ; Thu, 13 Apr 2017 11:10:24 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E3813151D for ; Thu, 13 Apr 2017 11:10:23 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l189so28238666ywb.0 for ; Thu, 13 Apr 2017 11:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4FuVnzFmPO8UHB+AadogAql20tjqJqF2FqTF8pLIw68=; b=KhWCad9t26a1gVFXcpvt6QeuTxSZCcwoOVpGO5g11hstAEjy+f+WfmrXcbavwMW6ID QfbhrS/n56yD/x28cJu52k7WcZ1Dzu6hV/YZRVPAcSQB7Ss47HeO5R5D+3+RUs+lEBrJ 0G6fcli7naJd48+Nw4HoT/srvxckl/xJ4AUwfGCENK/F54E+3xF2E78FsMtoHF+lOPxM /bhDQGq9id7JDm2tQfAhdnnuWqptxhzEfNUO52Q4qGPfhCa3MF9dwZSe7ZKIIDH/lFo0 zyE1e5Ov45vibw+DIk3ZVHJHz75fecMT6bp/lWVmol2mktlZQq+/ChsuEoghflQk6PQV Nbdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4FuVnzFmPO8UHB+AadogAql20tjqJqF2FqTF8pLIw68=; b=mW7Uz702w+2YaMNXnR/fBDnWdVZ244cZC9i4Dl9SC1xnVsRm2xsepKlHDC3OjGZDni Itx0S3vRixasy18QTQFEiET3ng2Fqp/VtC+I8cIIzoGqtxwCjXbTRr6mG8jOhcF7MQ4U b6VeyMQ5Ez6gOrVFtfXEwevB+zrXZmV+Ltt5I4mf7D4Knv8rKsXv4rwGSYhJnJcPZ0I+ xWzhnraP14gyiK62JvzVuyxZ0jH43K9/pQyzPQSlwG5gyBoJ4YqnEWpCRKLB9+cZi5Ip ZqXXp7GOOw6CMOASvvWUW6xHXwbe5fAo5soC9KMqRZt2jvvIOxSvfaZUh3I2Xycgmq7K zmPQ== X-Gm-Message-State: AN3rC/5bJcDqIebVOqxCWcEfOML8eEInzdt8BNDuz8wtQMu5oA4+mGqQ IBoYkOeodjed8p7014Fz4gsAoPhUkw== X-Received: by 10.13.203.73 with SMTP id n70mr3350941ywd.71.1492107022936; Thu, 13 Apr 2017 11:10:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 13 Apr 2017 11:09:42 -0700 (PDT) In-Reply-To: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> From: Eric Rescorla Date: Thu, 13 Apr 2017 11:09:42 -0700 Message-ID: Subject: Re: Consensus Call on issues closed by the -02 drafts To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary=001a114fd3d611d475054d103dd4 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 18:10:26 -0000 --001a114fd3d611d475054d103dd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have reviewed all the transport issues. I believe that nearly all of them can be marked closed, modulo the ones noted below. I am still reviewing the issues for the other drafts, but there is a lot of duplication, so I expect to get to them today. #51 - QUIC version number scheme I had requested that this document the existing Google version numbers, but this does not seem to have happened, and it should. #55 - What can change in a different version I am fine with closing this for now, but it is tied directly to the question of packet format and in particular how to handle packet number and connection ID, so it will need revision if we decide to adopt an encrypted packet number/conn-id proposal (which I intend to make in Paris if not before). #158 - Padding between frames As I noted previously, it seems like it would be be better to make padding a security layer function. We could then use the TLS-style padding (or whatever). I'm not sure we have consensus on this point yet. #181 - Remove SETTINGS[_ACK] Why don't we put the SETTINGS frame in a TLS extension. That would remove a bunch of race conditions. I have filed an issue for this. https://github.com/quicwg/base-drafts/issues/436 -Ekr On Fri, Mar 17, 2017 at 2:22 AM, Mark Nottingham wrote: > Everyone, > > The -02 drafts incorporate the proposed resolutions to a number of issues > that have been discussed. > > Those issues are listed below. Please have a look through them, and if > there are any resolutions that you feel need more discussion, please brin= g > it up, either here on the mailing list or in the issue itself. > > Issues that we need to discuss more will be reopened. The remaining ones > will be flagged as `has-consensus`. > > There are a lot of them, so we're not going to do this until after the > Chicago meeting (at the earliest) to give people a chance to discuss on t= he > list as well as in the meeting. > > See CONTRIBUTING.md#resolving-issues> for a reminder about the process we're > using here. Even when we have consensus, we can reopen an issue if new > information emerges (and that can take a variety of forms). > > This list is also available at base-drafts/issues?utf8=3D=E2=9C=93&q=3Dis%3Aissue%20is%3Aclosed% > 20label%3Adesign%20-label%3Ahas-consensus > > >. > > Cheers, > > ## Transport > > #35 - Starting packet number > #40 - Variable-length fields > #49 - Transport parameter advertisements > #50 - Updating Transport parameters > #51 - QUIC version number scheme > #52 - Source address validation > #55 - What can change in a different version > #56 - Extending flags > #57 - Advice on STOP_WAITING > #59 - Define ICSL parameter > #62 - Finding frame lengths > #63 - ACK retransmission > #64 - Path MTU Discovery > #66 - Remove STOP_WAITING > #67 - Picking packet number length > #69 - Minimum packet size > #70 - Move ACK/STOP_WAITING into the packet header > #74 - Application-defined error codes > #104 - Priority in QUIC Transport > #108 - Maximum stream number > #112 - Greasing version negotiation > #114 - STREAM retransmission priority > #116 - COPTs as empty transport parameters > #117 - SCUP > #118 - Source Address Token encoding > #119 - Server-proposed connection ID > #124 - Alt-Svc quic version hint > #126 - Separate transport parameters for 0-RTT > #133 - Connection ID in version negotiation > #135 - DoS using Version Negotiation Packets > #136 - First client packet size > #139 - Minimum MTU > #147 - Reflection Attack Resistance > #148 - QUIC packet header complexity > #157 - Updated information in retransmitted frames > #158 - Padding between frames > #159 - Time format > #162 - RST_STREAM and flow control > #163 - RST_STREAM and connection-level flow control > #164 - Padding handshake packets > #168 - Ordering of ACK Frame fields > #174 - Stream Reservation > #181 - Remove SETTINGS[_ACK] > #185 - Reliable identification of the initial packet for a connection > #201 - Do streams 0 and 1 count towards MSPC? > #204 - Streams not contributing to connection-level flow control > #243 - AEAD Associated Data > #244 - Need a NONCE in version negotiation packets > #262 - Don't encrypt client handshake with 1-RTT keys > #285 - Policing packet number size > #286 - Outstanding packets and packet number size > #289 - Avoid using Public Reset where possible > #291 - ACKing ACK > #292 - Does any portion of the QUIC framing require 4 byte alignment? > #293 - Does the connection id need to be in a consistent location? > #295 - Connection ID on a version negotiation packet > #308 - "retransmitting" old timestamps in ACK frames > #323 - Smaller packet number representations > #340 - Scale flow control offsets > #341 - What does it mean to acknowledge something? > #347 - Clarify meaning/definition of GOAWAY > #349 - When should server-chosen connection IDs be sent and how are they > indicated? > #352 - Does GOAWAY need an error code > > > ## Recovery > > #63 - ACK retransmission > #169 - Response to lost handshake packets > > > ## TLS > > #12 - Decouple QUIC version and ALPN > #25 - Key update forward secrecy > #26 - Which bit can KEY_PHASE use? > #27 - Fix KEY_PHASE for early data > #34 - ACK rules and packet protection > #87 - QUIC advertisement description > #97 - Version Negotiation + TLS > #226 - Authenticating public parts of the packet header > #243 - AEAD Associated Data > #262 - Don't encrypt client handshake with 1-RTT keys > #272 - Signaling TLS handshake failure > > > ## HTTP > > 75 - SETTING syncronization > 87 - QUIC advertisement description > 95 - CONNECT > 104 - Priority in QUIC Transport > 124 - Alt-Svc quic version hint > 127 - Frame header reserved bits > 154 - HTTP Stream ID Size > 173 - Size of HTTP Header Sequence Numbers > 176 - RST_STREAM breaks HPACK > 181 - Remove SETTINGS[_ACK] > 202 - HTTP: Why are we defining CONNECT? > 204 - Streams not contributing to connection-level flow control > 229 - Use a quic=3D parameter for Alt-Svc rather than collide with existi= ng > use of v=3D > 242 - HTTP extension mechanisms > 297 - Remove the quic parameter from Alt-Svc > 364 - Mid-frame close > > > > -- > Mark Nottingham https://www.mnot.net/ > > --001a114fd3d611d475054d103dd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed all the transport issues. I believe t= hat nearly all
of them can be marked closed, modulo the ones note= d below. I am still
reviewing the issues for the other drafts, bu= t there is a lot of
duplication, so I expect to get to them today= .


#51 =C2=A0- QUIC version number s= cheme

I had requested that this document the exist= ing Google version numbers,
but this does not seem to have happen= ed, and it should.


#55 =C2=A0- What= can change in a different version

I am fine with = closing this for now, but it is tied directly to the
question of = packet format and in particular how to handle packet
number and c= onnection ID, so it will need revision if we decide
to adopt an e= ncrypted packet number/conn-id proposal (which I
intend to make i= n Paris if not before).


#158 - Padd= ing between frames

As I noted previously, it seems= like it would be be better to make
padding a security layer func= tion. We could then use the TLS-style
padding (or whatever). I= 9;m not sure we have consensus on this point
yet.

<= /div>

#181 - Remove SETTINGS[_ACK]

<= div>Why don't we put the SETTINGS frame in a TLS extension. That would<= /div>
remove a bunch of race conditions. I have filed an issue for this= .


-Ekr

<= br>
On Fri, Mar 17, 2017 at 2:22 AM, Mark Notting= ham <mnot@mnot.net> wrote:
Eve= ryone,

The -02 drafts incorporate the proposed resolutions to a number of issues t= hat have been discussed.

Those issues are listed below. Please have a look through them, and if ther= e are any resolutions that you feel need more discussion, please bring it u= p, either here on the mailing list or in the issue itself.

Issues that we need to discuss more will be reopened. The remaining ones wi= ll be flagged as `has-consensus`.

There are a lot of them, so we're not going to do this until after the = Chicago meeting (at the earliest) to give people a chance to discuss on the= list as well as in the meeting.

See <https://gi= thub.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#resolving= -issues> for a reminder about the process we're using here.= Even when we have consensus, we can reopen an issue if new information eme= rges (and that can take a variety of forms).

This list is also available at <http= s://github.com/quicwg/base-drafts/issues?utf8=3D=E2=9C=93&q=3Dis%3Aissue%20is%3Aclosed%20label%3Adesign%20-label%3Ahas-consens= us>.

Cheers,

## Transport

#35=C2=A0 - Starting packet number
#40=C2=A0 - Variable-length fields
#49=C2=A0 - Transport parameter advertisements
#50=C2=A0 - Updating Transport parameters
#51=C2=A0 - QUIC version number scheme
#52=C2=A0 - Source address validation
#55=C2=A0 - What can change in a different version
#56=C2=A0 - Extending flags
#57=C2=A0 - Advice on STOP_WAITING
#59=C2=A0 - Define ICSL parameter
#62=C2=A0 - Finding frame lengths
#63=C2=A0 - ACK retransmission
#64=C2=A0 - Path MTU Discovery
#66=C2=A0 - Remove STOP_WAITING
#67=C2=A0 - Picking packet number length
#69=C2=A0 - Minimum packet size
#70=C2=A0 - Move ACK/STOP_WAITING into the packet header
#74=C2=A0 - Application-defined error codes
#104 - Priority in QUIC Transport
#108 - Maximum stream number
#112 - Greasing version negotiation
#114 - STREAM retransmission priority
#116 - COPTs as empty transport parameters
#117 - SCUP
#118 - Source Address Token encoding
#119 - Server-proposed connection ID
#124 - Alt-Svc quic version hint
#126 - Separate transport parameters for 0-RTT
#133 - Connection ID in version negotiation
#135 - DoS using Version Negotiation Packets
#136 - First client packet size
#139 - Minimum MTU
#147 - Reflection Attack Resistance
#148 - QUIC packet header complexity
#157 - Updated information in retransmitted frames
#158 - Padding between frames
#159 - Time format
#162 - RST_STREAM and flow control
#163 - RST_STREAM and connection-level flow control
#164 - Padding handshake packets
#168 - Ordering of ACK Frame fields
#174 - Stream Reservation
#181 - Remove SETTINGS[_ACK]
#185 - Reliable identification of the initial packet for a connection
#201 - Do streams 0 and 1 count towards MSPC?
#204 - Streams not contributing to connection-level flow control
#243 - AEAD Associated Data
#244 - Need a NONCE in version negotiation packets
#262 - Don't encrypt client handshake with 1-RTT keys
#285 - Policing packet number size
#286 - Outstanding packets and packet number size
#289 - Avoid using Public Reset where possible
#291 - ACKing ACK
#292 - Does any portion of the QUIC framing require 4 byte alignment?
#293 - Does the connection id need to be in a consistent location?
#295 - Connection ID on a version negotiation packet
#308 - "retransmitting" old timestamps in ACK frames
#323 - Smaller packet number representations
#340 - Scale flow control offsets
#341 - What does it mean to acknowledge something?
#347 - Clarify meaning/definition of GOAWAY
#349 - When should server-chosen connection IDs be sent and how are they in= dicated?
#352 - Does GOAWAY need an error code


## Recovery

#63=C2=A0 - ACK retransmission
#169 - Response to lost handshake packets


## TLS

#12=C2=A0 - Decouple QUIC version and ALPN
#25=C2=A0 - Key update forward secrecy
#26=C2=A0 - Which bit can KEY_PHASE use?
#27=C2=A0 - Fix KEY_PHASE for early data
#34=C2=A0 - ACK rules and packet protection
#87=C2=A0 - QUIC advertisement description
#97=C2=A0 - Version Negotiation + TLS
#226 - Authenticating public parts of the packet header
#243 - AEAD Associated Data
#262 - Don't encrypt client handshake with 1-RTT keys
#272 - Signaling TLS handshake failure


## HTTP

75=C2=A0 - SETTING syncronization
87=C2=A0 - QUIC advertisement description
95=C2=A0 - CONNECT
104 - Priority in QUIC Transport
124 - Alt-Svc quic version hint
127 - Frame header reserved bits
154 - HTTP Stream ID Size
173 - Size of HTTP Header Sequence Numbers
176 - RST_STREAM breaks HPACK
181 - Remove SETTINGS[_ACK]
202 - HTTP: Why are we defining CONNECT?
204 - Streams not contributing to connection-level flow control
229 - Use a quic=3D parameter for Alt-Svc rather than collide with existing= use of v=3D
242 - HTTP extension mechanisms
297 - Remove the quic parameter from Alt-Svc
364 - Mid-frame close



--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/


--001a114fd3d611d475054d103dd4-- From nobody Thu Apr 13 12:56:26 2017 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 C4AF812EB29 for ; Thu, 13 Apr 2017 12:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 jhQ_noVFpYpZ for ; Thu, 13 Apr 2017 12:56:21 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0131.outbound.protection.outlook.com [104.47.32.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D984129566 for ; Thu, 13 Apr 2017 12:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j9hJ4LZEFFsDGtMLxr20J3yyOjisX592kgwXdLX+WWo=; b=G+KhVuifUWO2b1LN9GIVChfAdcr5r+a1yQL+qP9KpA+7rPzcKwCUzBa2u7YtIFVgHCI93Z8hedR1MWetK5Gu5tVJgjQXaKB6PNi/CyGnqUeu5K6oWkklf3yGS290VazldJInLNmDuLejzLlhqoup2Ar/0TFWGeq2Tuxfg8eEXN0= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Thu, 13 Apr 2017 19:56:19 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1019.026; Thu, 13 Apr 2017 19:56:19 +0000 From: Mike Bishop To: Eric Rescorla , Mark Nottingham CC: IETF QUIC WG , Lars Eggert Subject: RE: Consensus Call on issues closed by the -02 drafts Thread-Topic: Consensus Call on issues closed by the -02 drafts Thread-Index: AQHSnwAMVPmKxQtcPUe4u7P0iaz7iqHDxD4AgAAdH/A= Date: Thu, 13 Apr 2017 19:56:19 +0000 Message-ID: References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::51f] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:T0QtF0MhVRiDEfO4chdD/2L0Agav/boCndlPjAT/NchWREHe5TFanJjMBrwqr01jDOato0vqzm4Al5hmDpAPviEQu4KKLeDBpu/mEOYA2dUVEQGUYs8V7RK4MdB0LY2LOSySvu84OXIQAtCdf6jZ7Du4JuEe9FTgK60acgHRr1zbsuAHrckNnItP1ZkKiIRb/oNdJ7BhKvypIvtPAIox8nN05CLcF8V6x7hF6Zm9TfweKaJ0v3cyEYUCGeAOx8WfV1+89ehZ+YVQytQ828Uqn+6qdzx8ikl7O92b2vibWHU0IlKGDnvn6zeH8XLV3QCsOs2inmSWIGGpHjTfGPtEwyp3FHRrIk5mssdCZ3MVhNY= x-ms-office365-filtering-correlation-id: 299b03e3-7c58-466c-91f5-08d482a72742 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2706; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(189930954265078)(100405760836317)(219752817060721)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39860400002)(39840400002)(39410400002)(39450400003)(42174003)(377454003)(24454002)(7736002)(561944003)(81166006)(86612001)(189998001)(77096006)(86362001)(7906003)(8676002)(74316002)(2950100002)(4326008)(5660300001)(33656002)(38730400002)(76176999)(54356999)(53546009)(25786009)(122556002)(8936002)(50986999)(6116002)(790700001)(102836003)(2906002)(6246003)(6436002)(3280700002)(54906002)(10090500001)(606005)(54896002)(6306002)(9686003)(236005)(99286003)(55016002)(8990500004)(53936002)(10290500002)(229853002)(2900100001)(5005710100001)(3660700001)(7696004)(6506006)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27085814F6237EA7D679575C87020BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2017 19:56:19.4264 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 19:56:25 -0000 --_000_BN6PR03MB27085814F6237EA7D679575C87020BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmU6IFNFVFRJTkdTIGluIFRMUywgcmF0aGVyIHRoYW4gcHV0dGluZyBhbm90aGVyIG5ldyBleHRl bnNpb24sIHRoZSBtb3JlIGdlbmVyYWwgZm9ybSBvZiB0aGlzIHdvdWxkIGJlIHRvIHNheSB0aGF0 LCBqdXN0IGFzIHRoZSBUTFMgZXh0ZW5zaW9uIGNhcnJpZXMgYW4gb3BhcXVlIGJsb2IgdGhhdCBR VUlDIHVzZXMgZm9yIHNldHRpbmdzLCB0aGUgUVVJQyBibG9iIGFsc28gY29udGFpbnMgYW4gYXBw bGljYXRpb24tc3BlY2lmaWVkIGJsb2IuICBSZXNlcnZlIGEgUVVJQyBzZXR0aW5ncyB2YWx1ZSBm b3Ig4oCcYXBwbGljYXRpb24tc3BlY2lmaWVkIGRhdGHigJ0gYW5kIGxldCBlYWNoIGFwcGxpY2F0 aW9uIGRlZmluZSB0aGUgbGF5b3V0IGFzIHRoZXkgZGVzaXJlZC4NCg0KRnJvbTogUVVJQyBbbWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNl bnQ6IFRodXJzZGF5LCBBcHJpbCAxMywgMjAxNyAxMToxMCBBTQ0KVG86IE1hcmsgTm90dGluZ2hh bSA8bW5vdEBtbm90Lm5ldD4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBMYXJz IEVnZ2VydCA8bGFyc0BuZXRhcHAuY29tPg0KU3ViamVjdDogUmU6IENvbnNlbnN1cyBDYWxsIG9u IGlzc3VlcyBjbG9zZWQgYnkgdGhlIC0wMiBkcmFmdHMNCg0KSSBoYXZlIHJldmlld2VkIGFsbCB0 aGUgdHJhbnNwb3J0IGlzc3Vlcy4gSSBiZWxpZXZlIHRoYXQgbmVhcmx5IGFsbA0Kb2YgdGhlbSBj YW4gYmUgbWFya2VkIGNsb3NlZCwgbW9kdWxvIHRoZSBvbmVzIG5vdGVkIGJlbG93LiBJIGFtIHN0 aWxsDQpyZXZpZXdpbmcgdGhlIGlzc3VlcyBmb3IgdGhlIG90aGVyIGRyYWZ0cywgYnV0IHRoZXJl IGlzIGEgbG90IG9mDQpkdXBsaWNhdGlvbiwgc28gSSBleHBlY3QgdG8gZ2V0IHRvIHRoZW0gdG9k YXkuDQoNCg0KIzUxICAtIFFVSUMgdmVyc2lvbiBudW1iZXIgc2NoZW1lDQoNCkkgaGFkIHJlcXVl c3RlZCB0aGF0IHRoaXMgZG9jdW1lbnQgdGhlIGV4aXN0aW5nIEdvb2dsZSB2ZXJzaW9uIG51bWJl cnMsDQpidXQgdGhpcyBkb2VzIG5vdCBzZWVtIHRvIGhhdmUgaGFwcGVuZWQsIGFuZCBpdCBzaG91 bGQuDQoNCg0KIzU1ICAtIFdoYXQgY2FuIGNoYW5nZSBpbiBhIGRpZmZlcmVudCB2ZXJzaW9uDQoN CkkgYW0gZmluZSB3aXRoIGNsb3NpbmcgdGhpcyBmb3Igbm93LCBidXQgaXQgaXMgdGllZCBkaXJl Y3RseSB0byB0aGUNCnF1ZXN0aW9uIG9mIHBhY2tldCBmb3JtYXQgYW5kIGluIHBhcnRpY3VsYXIg aG93IHRvIGhhbmRsZSBwYWNrZXQNCm51bWJlciBhbmQgY29ubmVjdGlvbiBJRCwgc28gaXQgd2ls bCBuZWVkIHJldmlzaW9uIGlmIHdlIGRlY2lkZQ0KdG8gYWRvcHQgYW4gZW5jcnlwdGVkIHBhY2tl dCBudW1iZXIvY29ubi1pZCBwcm9wb3NhbCAod2hpY2ggSQ0KaW50ZW5kIHRvIG1ha2UgaW4gUGFy aXMgaWYgbm90IGJlZm9yZSkuDQoNCg0KIzE1OCAtIFBhZGRpbmcgYmV0d2VlbiBmcmFtZXMNCg0K QXMgSSBub3RlZCBwcmV2aW91c2x5LCBpdCBzZWVtcyBsaWtlIGl0IHdvdWxkIGJlIGJlIGJldHRl ciB0byBtYWtlDQpwYWRkaW5nIGEgc2VjdXJpdHkgbGF5ZXIgZnVuY3Rpb24uIFdlIGNvdWxkIHRo ZW4gdXNlIHRoZSBUTFMtc3R5bGUNCnBhZGRpbmcgKG9yIHdoYXRldmVyKS4gSSdtIG5vdCBzdXJl IHdlIGhhdmUgY29uc2Vuc3VzIG9uIHRoaXMgcG9pbnQNCnlldC4NCg0KDQojMTgxIC0gUmVtb3Zl IFNFVFRJTkdTW19BQ0tdDQoNCldoeSBkb24ndCB3ZSBwdXQgdGhlIFNFVFRJTkdTIGZyYW1lIGlu IGEgVExTIGV4dGVuc2lvbi4gVGhhdCB3b3VsZA0KcmVtb3ZlIGEgYnVuY2ggb2YgcmFjZSBjb25k aXRpb25zLiBJIGhhdmUgZmlsZWQgYW4gaXNzdWUgZm9yIHRoaXMuDQoNCmh0dHBzOi8vZ2l0aHVi LmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzQzNjxodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZx dWljd2clMkZiYXNlLWRyYWZ0cyUyRmlzc3VlcyUyRjQzNiZkYXRhPTAyJTdDMDElN0NtaWNoYWVs LmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NiNTUyN2Y0NjM2NTc0OWFhMWIxYzA4ZDQ4Mjk4NWY1 MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzcwMzg1 ODcxODg0NjUmc2RhdGE9SVdINHFkOFElMkJwRnRmJTJGMTJXQjlCZEpNd0N5QTRFeEJFN2N5OExK R0hEbUklM0QmcmVzZXJ2ZWQ9MD4NCg0KLUVrcg0KDQoNCk9uIEZyaSwgTWFyIDE3LCAyMDE3IGF0 IDI6MjIgQU0sIE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldDxtYWlsdG86bW5vdEBtbm90 Lm5ldD4+IHdyb3RlOg0KRXZlcnlvbmUsDQoNClRoZSAtMDIgZHJhZnRzIGluY29ycG9yYXRlIHRo ZSBwcm9wb3NlZCByZXNvbHV0aW9ucyB0byBhIG51bWJlciBvZiBpc3N1ZXMgdGhhdCBoYXZlIGJl ZW4gZGlzY3Vzc2VkLg0KDQpUaG9zZSBpc3N1ZXMgYXJlIGxpc3RlZCBiZWxvdy4gUGxlYXNlIGhh dmUgYSBsb29rIHRocm91Z2ggdGhlbSwgYW5kIGlmIHRoZXJlIGFyZSBhbnkgcmVzb2x1dGlvbnMg dGhhdCB5b3UgZmVlbCBuZWVkIG1vcmUgZGlzY3Vzc2lvbiwgcGxlYXNlIGJyaW5nIGl0IHVwLCBl aXRoZXIgaGVyZSBvbiB0aGUgbWFpbGluZyBsaXN0IG9yIGluIHRoZSBpc3N1ZSBpdHNlbGYuDQoN Cklzc3VlcyB0aGF0IHdlIG5lZWQgdG8gZGlzY3VzcyBtb3JlIHdpbGwgYmUgcmVvcGVuZWQuIFRo ZSByZW1haW5pbmcgb25lcyB3aWxsIGJlIGZsYWdnZWQgYXMgYGhhcy1jb25zZW5zdXNgLg0KDQpU aGVyZSBhcmUgYSBsb3Qgb2YgdGhlbSwgc28gd2UncmUgbm90IGdvaW5nIHRvIGRvIHRoaXMgdW50 aWwgYWZ0ZXIgdGhlIENoaWNhZ28gbWVldGluZyAoYXQgdGhlIGVhcmxpZXN0KSB0byBnaXZlIHBl b3BsZSBhIGNoYW5jZSB0byBkaXNjdXNzIG9uIHRoZSBsaXN0IGFzIHdlbGwgYXMgaW4gdGhlIG1l ZXRpbmcuDQoNClNlZSA8aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9ibG9i L21hc3Rlci9DT05UUklCVVRJTkcubWQjcmVzb2x2aW5nLWlzc3VlczxodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5j b20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRmJsb2IlMkZtYXN0ZXIlMkZDT05UUklCVVRJTkcu bWQlMjNyZXNvbHZpbmctaXNzdWVzJmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWlj cm9zb2Z0LmNvbSU3Q2I1NTI3ZjQ2MzY1NzQ5YWExYjFjMDhkNDgyOTg1ZjUxJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI3NzAzODU4NzE4ODQ2NSZzZGF0 YT0lMkJEUFBVVjBIY3FvNkhKNnJ2NlU1c2MlMkYlMkIzJTJCMFhBcTQ2VmdBWTlXV0Q5STQlM0Qm cmVzZXJ2ZWQ9MD4+IGZvciBhIHJlbWluZGVyIGFib3V0IHRoZSBwcm9jZXNzIHdlJ3JlIHVzaW5n IGhlcmUuIEV2ZW4gd2hlbiB3ZSBoYXZlIGNvbnNlbnN1cywgd2UgY2FuIHJlb3BlbiBhbiBpc3N1 ZSBpZiBuZXcgaW5mb3JtYXRpb24gZW1lcmdlcyAoYW5kIHRoYXQgY2FuIHRha2UgYSB2YXJpZXR5 IG9mIGZvcm1zKS4NCg0KVGhpcyBsaXN0IGlzIGFsc28gYXZhaWxhYmxlIGF0IDxodHRwczovL2dp dGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcz91dGY4PeKckyZxPWlzJTNBaXNzdWUl MjBpcyUzQWNsb3NlZCUyMGxhYmVsJTNBZGVzaWduJTIwLWxhYmVsJTNBaGFzLWNvbnNlbnN1czxo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRmdpdGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRmlzc3VlcyUzRnV0Zjgl M0QlMjVFMiUyNTlDJTI1OTMlMjZxJTNEaXMlMjUzQWlzc3VlJTI1MjBpcyUyNTNBY2xvc2VkJTI1 MjBsYWJlbCUyNTNBZGVzaWduJTI1MjAtbGFiZWwlMjUzQWhhcy1jb25zZW5zdXMmZGF0YT0wMiU3 QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDYjU1MjdmNDYzNjU3NDlhYTFi MWMwOGQ0ODI5ODVmNTElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM2Mjc3MDM4NTg3MTg4NDY1JnNkYXRhPTQ2VjNxekgxcDI5SSUyQjdtQnRVMjNPVlAlMkJz eVMyVklUcnZ1dVhDbVJhVmxzJTNEJnJlc2VydmVkPTA+Pi4NCg0KQ2hlZXJzLA0KDQojIyBUcmFu c3BvcnQNCg0KIzM1ICAtIFN0YXJ0aW5nIHBhY2tldCBudW1iZXINCiM0MCAgLSBWYXJpYWJsZS1s ZW5ndGggZmllbGRzDQojNDkgIC0gVHJhbnNwb3J0IHBhcmFtZXRlciBhZHZlcnRpc2VtZW50cw0K IzUwICAtIFVwZGF0aW5nIFRyYW5zcG9ydCBwYXJhbWV0ZXJzDQojNTEgIC0gUVVJQyB2ZXJzaW9u IG51bWJlciBzY2hlbWUNCiM1MiAgLSBTb3VyY2UgYWRkcmVzcyB2YWxpZGF0aW9uDQojNTUgIC0g V2hhdCBjYW4gY2hhbmdlIGluIGEgZGlmZmVyZW50IHZlcnNpb24NCiM1NiAgLSBFeHRlbmRpbmcg ZmxhZ3MNCiM1NyAgLSBBZHZpY2Ugb24gU1RPUF9XQUlUSU5HDQojNTkgIC0gRGVmaW5lIElDU0wg cGFyYW1ldGVyDQojNjIgIC0gRmluZGluZyBmcmFtZSBsZW5ndGhzDQojNjMgIC0gQUNLIHJldHJh bnNtaXNzaW9uDQojNjQgIC0gUGF0aCBNVFUgRGlzY292ZXJ5DQojNjYgIC0gUmVtb3ZlIFNUT1Bf V0FJVElORw0KIzY3ICAtIFBpY2tpbmcgcGFja2V0IG51bWJlciBsZW5ndGgNCiM2OSAgLSBNaW5p bXVtIHBhY2tldCBzaXplDQojNzAgIC0gTW92ZSBBQ0svU1RPUF9XQUlUSU5HIGludG8gdGhlIHBh Y2tldCBoZWFkZXINCiM3NCAgLSBBcHBsaWNhdGlvbi1kZWZpbmVkIGVycm9yIGNvZGVzDQojMTA0 IC0gUHJpb3JpdHkgaW4gUVVJQyBUcmFuc3BvcnQNCiMxMDggLSBNYXhpbXVtIHN0cmVhbSBudW1i ZXINCiMxMTIgLSBHcmVhc2luZyB2ZXJzaW9uIG5lZ290aWF0aW9uDQojMTE0IC0gU1RSRUFNIHJl dHJhbnNtaXNzaW9uIHByaW9yaXR5DQojMTE2IC0gQ09QVHMgYXMgZW1wdHkgdHJhbnNwb3J0IHBh cmFtZXRlcnMNCiMxMTcgLSBTQ1VQDQojMTE4IC0gU291cmNlIEFkZHJlc3MgVG9rZW4gZW5jb2Rp bmcNCiMxMTkgLSBTZXJ2ZXItcHJvcG9zZWQgY29ubmVjdGlvbiBJRA0KIzEyNCAtIEFsdC1TdmMg cXVpYyB2ZXJzaW9uIGhpbnQNCiMxMjYgLSBTZXBhcmF0ZSB0cmFuc3BvcnQgcGFyYW1ldGVycyBm b3IgMC1SVFQNCiMxMzMgLSBDb25uZWN0aW9uIElEIGluIHZlcnNpb24gbmVnb3RpYXRpb24NCiMx MzUgLSBEb1MgdXNpbmcgVmVyc2lvbiBOZWdvdGlhdGlvbiBQYWNrZXRzDQojMTM2IC0gRmlyc3Qg Y2xpZW50IHBhY2tldCBzaXplDQojMTM5IC0gTWluaW11bSBNVFUNCiMxNDcgLSBSZWZsZWN0aW9u IEF0dGFjayBSZXNpc3RhbmNlDQojMTQ4IC0gUVVJQyBwYWNrZXQgaGVhZGVyIGNvbXBsZXhpdHkN CiMxNTcgLSBVcGRhdGVkIGluZm9ybWF0aW9uIGluIHJldHJhbnNtaXR0ZWQgZnJhbWVzDQojMTU4 IC0gUGFkZGluZyBiZXR3ZWVuIGZyYW1lcw0KIzE1OSAtIFRpbWUgZm9ybWF0DQojMTYyIC0gUlNU X1NUUkVBTSBhbmQgZmxvdyBjb250cm9sDQojMTYzIC0gUlNUX1NUUkVBTSBhbmQgY29ubmVjdGlv bi1sZXZlbCBmbG93IGNvbnRyb2wNCiMxNjQgLSBQYWRkaW5nIGhhbmRzaGFrZSBwYWNrZXRzDQoj MTY4IC0gT3JkZXJpbmcgb2YgQUNLIEZyYW1lIGZpZWxkcw0KIzE3NCAtIFN0cmVhbSBSZXNlcnZh dGlvbg0KIzE4MSAtIFJlbW92ZSBTRVRUSU5HU1tfQUNLXQ0KIzE4NSAtIFJlbGlhYmxlIGlkZW50 aWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsIHBhY2tldCBmb3IgYSBjb25uZWN0aW9uDQojMjAxIC0g RG8gc3RyZWFtcyAwIGFuZCAxIGNvdW50IHRvd2FyZHMgTVNQQz8NCiMyMDQgLSBTdHJlYW1zIG5v dCBjb250cmlidXRpbmcgdG8gY29ubmVjdGlvbi1sZXZlbCBmbG93IGNvbnRyb2wNCiMyNDMgLSBB RUFEIEFzc29jaWF0ZWQgRGF0YQ0KIzI0NCAtIE5lZWQgYSBOT05DRSBpbiB2ZXJzaW9uIG5lZ290 aWF0aW9uIHBhY2tldHMNCiMyNjIgLSBEb24ndCBlbmNyeXB0IGNsaWVudCBoYW5kc2hha2Ugd2l0 aCAxLVJUVCBrZXlzDQojMjg1IC0gUG9saWNpbmcgcGFja2V0IG51bWJlciBzaXplDQojMjg2IC0g T3V0c3RhbmRpbmcgcGFja2V0cyBhbmQgcGFja2V0IG51bWJlciBzaXplDQojMjg5IC0gQXZvaWQg dXNpbmcgUHVibGljIFJlc2V0IHdoZXJlIHBvc3NpYmxlDQojMjkxIC0gQUNLaW5nIEFDSw0KIzI5 MiAtIERvZXMgYW55IHBvcnRpb24gb2YgdGhlIFFVSUMgZnJhbWluZyByZXF1aXJlIDQgYnl0ZSBh bGlnbm1lbnQ/DQojMjkzIC0gRG9lcyB0aGUgY29ubmVjdGlvbiBpZCBuZWVkIHRvIGJlIGluIGEg Y29uc2lzdGVudCBsb2NhdGlvbj8NCiMyOTUgLSBDb25uZWN0aW9uIElEIG9uIGEgdmVyc2lvbiBu ZWdvdGlhdGlvbiBwYWNrZXQNCiMzMDggLSAicmV0cmFuc21pdHRpbmciIG9sZCB0aW1lc3RhbXBz IGluIEFDSyBmcmFtZXMNCiMzMjMgLSBTbWFsbGVyIHBhY2tldCBudW1iZXIgcmVwcmVzZW50YXRp b25zDQojMzQwIC0gU2NhbGUgZmxvdyBjb250cm9sIG9mZnNldHMNCiMzNDEgLSBXaGF0IGRvZXMg aXQgbWVhbiB0byBhY2tub3dsZWRnZSBzb21ldGhpbmc/DQojMzQ3IC0gQ2xhcmlmeSBtZWFuaW5n L2RlZmluaXRpb24gb2YgR09BV0FZDQojMzQ5IC0gV2hlbiBzaG91bGQgc2VydmVyLWNob3NlbiBj b25uZWN0aW9uIElEcyBiZSBzZW50IGFuZCBob3cgYXJlIHRoZXkgaW5kaWNhdGVkPw0KIzM1MiAt IERvZXMgR09BV0FZIG5lZWQgYW4gZXJyb3IgY29kZQ0KDQoNCiMjIFJlY292ZXJ5DQoNCiM2MyAg LSBBQ0sgcmV0cmFuc21pc3Npb24NCiMxNjkgLSBSZXNwb25zZSB0byBsb3N0IGhhbmRzaGFrZSBw YWNrZXRzDQoNCg0KIyMgVExTDQoNCiMxMiAgLSBEZWNvdXBsZSBRVUlDIHZlcnNpb24gYW5kIEFM UE4NCiMyNSAgLSBLZXkgdXBkYXRlIGZvcndhcmQgc2VjcmVjeQ0KIzI2ICAtIFdoaWNoIGJpdCBj YW4gS0VZX1BIQVNFIHVzZT8NCiMyNyAgLSBGaXggS0VZX1BIQVNFIGZvciBlYXJseSBkYXRhDQoj MzQgIC0gQUNLIHJ1bGVzIGFuZCBwYWNrZXQgcHJvdGVjdGlvbg0KIzg3ICAtIFFVSUMgYWR2ZXJ0 aXNlbWVudCBkZXNjcmlwdGlvbg0KIzk3ICAtIFZlcnNpb24gTmVnb3RpYXRpb24gKyBUTFMNCiMy MjYgLSBBdXRoZW50aWNhdGluZyBwdWJsaWMgcGFydHMgb2YgdGhlIHBhY2tldCBoZWFkZXINCiMy NDMgLSBBRUFEIEFzc29jaWF0ZWQgRGF0YQ0KIzI2MiAtIERvbid0IGVuY3J5cHQgY2xpZW50IGhh bmRzaGFrZSB3aXRoIDEtUlRUIGtleXMNCiMyNzIgLSBTaWduYWxpbmcgVExTIGhhbmRzaGFrZSBm YWlsdXJlDQoNCg0KIyMgSFRUUA0KDQo3NSAgLSBTRVRUSU5HIHN5bmNyb25pemF0aW9uDQo4NyAg LSBRVUlDIGFkdmVydGlzZW1lbnQgZGVzY3JpcHRpb24NCjk1ICAtIENPTk5FQ1QNCjEwNCAtIFBy aW9yaXR5IGluIFFVSUMgVHJhbnNwb3J0DQoxMjQgLSBBbHQtU3ZjIHF1aWMgdmVyc2lvbiBoaW50 DQoxMjcgLSBGcmFtZSBoZWFkZXIgcmVzZXJ2ZWQgYml0cw0KMTU0IC0gSFRUUCBTdHJlYW0gSUQg U2l6ZQ0KMTczIC0gU2l6ZSBvZiBIVFRQIEhlYWRlciBTZXF1ZW5jZSBOdW1iZXJzDQoxNzYgLSBS U1RfU1RSRUFNIGJyZWFrcyBIUEFDSw0KMTgxIC0gUmVtb3ZlIFNFVFRJTkdTW19BQ0tdDQoyMDIg LSBIVFRQOiBXaHkgYXJlIHdlIGRlZmluaW5nIENPTk5FQ1Q/DQoyMDQgLSBTdHJlYW1zIG5vdCBj b250cmlidXRpbmcgdG8gY29ubmVjdGlvbi1sZXZlbCBmbG93IGNvbnRyb2wNCjIyOSAtIFVzZSBh IHF1aWM9IHBhcmFtZXRlciBmb3IgQWx0LVN2YyByYXRoZXIgdGhhbiBjb2xsaWRlIHdpdGggZXhp c3RpbmcgdXNlIG9mIHY9DQoyNDIgLSBIVFRQIGV4dGVuc2lvbiBtZWNoYW5pc21zDQoyOTcgLSBS ZW1vdmUgdGhlIHF1aWMgcGFyYW1ldGVyIGZyb20gQWx0LVN2Yw0KMzY0IC0gTWlkLWZyYW1lIGNs b3NlDQoNCg0KDQotLQ0KTWFyayBOb3R0aW5naGFtICAgaHR0cHM6Ly93d3cubW5vdC5uZXQvPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGd3d3Lm1ub3QubmV0JTJGJmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWlj cm9zb2Z0LmNvbSU3Q2I1NTI3ZjQ2MzY1NzQ5YWExYjFjMDhkNDgyOTg1ZjUxJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI3NzAzODU4NzE4ODQ2NSZzZGF0 YT1FTmM1NDRRZyUyRnFVZG4wSmRnbEs5NExqRGJ2M0o1c0t4aTd0RWpoN0NDM2slM0QmcmVzZXJ2 ZWQ9MD4NCg0K --_000_BN6PR03MB27085814F6237EA7D679575C87020BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5v c2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlOiBTRVRUSU5HUyBpbiBUTFMsIHJhdGhlciB0aGFuIHB1 dHRpbmcgYW5vdGhlciBuZXcgZXh0ZW5zaW9uLCB0aGUgbW9yZSBnZW5lcmFsIGZvcm0gb2YgdGhp cyB3b3VsZCBiZSB0byBzYXkgdGhhdCwganVzdCBhcyB0aGUgVExTIGV4dGVuc2lvbiBjYXJyaWVz IGFuIG9wYXF1ZSBibG9iIHRoYXQgUVVJQyB1c2VzIGZvciBzZXR0aW5ncywgdGhlIFFVSUMgYmxv YiBhbHNvIGNvbnRhaW5zIGFuIGFwcGxpY2F0aW9uLXNwZWNpZmllZA0KIGJsb2IuJm5ic3A7IFJl c2VydmUgYSBRVUlDIHNldHRpbmdzIHZhbHVlIGZvciDigJxhcHBsaWNhdGlvbi1zcGVjaWZpZWQg ZGF0YeKAnSBhbmQgbGV0IGVhY2ggYXBwbGljYXRpb24gZGVmaW5lIHRoZSBsYXlvdXQgYXMgdGhl eSBkZXNpcmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+RXJpYyBSZXNj b3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTMsIDIwMTcgMTE6MTAgQU08 YnI+DQo8Yj5Ubzo8L2I+IE1hcmsgTm90dGluZ2hhbSAmbHQ7bW5vdEBtbm90Lm5ldCZndDs8YnI+ DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IExhcnMgRWdn ZXJ0ICZsdDtsYXJzQG5ldGFwcC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBDb25z ZW5zdXMgQ2FsbCBvbiBpc3N1ZXMgY2xvc2VkIGJ5IHRoZSAtMDIgZHJhZnRzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHJldmlld2VkIGFsbCB0aGUgdHJhbnNw b3J0IGlzc3Vlcy4gSSBiZWxpZXZlIHRoYXQgbmVhcmx5IGFsbDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b2YgdGhlbSBjYW4gYmUgbWFya2VkIGNs b3NlZCwgbW9kdWxvIHRoZSBvbmVzIG5vdGVkIGJlbG93LiBJIGFtIHN0aWxsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZXZpZXdpbmcgdGhlIGlz c3VlcyBmb3IgdGhlIG90aGVyIGRyYWZ0cywgYnV0IHRoZXJlIGlzIGEgbG90IG9mPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kdXBsaWNhdGlvbiwg c28gSSBleHBlY3QgdG8gZ2V0IHRvIHRoZW0gdG9kYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IzUxICZuYnNwOy0gUVVJQyB2ZXJzaW9u IG51bWJlciBzY2hlbWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBoYWQgcmVxdWVzdGVkIHRoYXQgdGhpcyBkb2N1bWVudCB0aGUgZXhpc3Rp bmcgR29vZ2xlIHZlcnNpb24gbnVtYmVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCB0aGlzIGRvZXMgbm90IHNlZW0gdG8gaGF2ZSBoYXBw ZW5lZCwgYW5kIGl0IHNob3VsZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4jNTUgJm5ic3A7LSBXaGF0IGNhbiBjaGFuZ2UgaW4gYSBkaWZm ZXJlbnQgdmVyc2lvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGFtIGZpbmUgd2l0aCBjbG9zaW5nIHRoaXMgZm9yIG5vdywgYnV0IGl0IGlz IHRpZWQgZGlyZWN0bHkgdG8gdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5xdWVzdGlvbiBvZiBwYWNrZXQgZm9ybWF0IGFuZCBpbiBwYXJ0aWN1 bGFyIGhvdyB0byBoYW5kbGUgcGFja2V0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5udW1iZXIgYW5kIGNvbm5lY3Rpb24gSUQsIHNvIGl0IHdpbGwg bmVlZCByZXZpc2lvbiBpZiB3ZSBkZWNpZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIGFkb3B0IGFuIGVuY3J5cHRlZCBwYWNrZXQgbnVtYmVy L2Nvbm4taWQgcHJvcG9zYWwgKHdoaWNoIEk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludGVuZCB0byBtYWtlIGluIFBhcmlzIGlmIG5vdCBiZWZv cmUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiMxNTggLSBQYWRkaW5nIGJldHdlZW4gZnJhbWVzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIEkgbm90ZWQgcHJldmlvdXNseSwgaXQg c2VlbXMgbGlrZSBpdCB3b3VsZCBiZSBiZSBiZXR0ZXIgdG8gbWFrZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGFkZGluZyBhIHNlY3VyaXR5IGxh eWVyIGZ1bmN0aW9uLiBXZSBjb3VsZCB0aGVuIHVzZSB0aGUgVExTLXN0eWxlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wYWRkaW5nIChvciB3aGF0 ZXZlcikuIEknbSBub3Qgc3VyZSB3ZSBoYXZlIGNvbnNlbnN1cyBvbiB0aGlzIHBvaW50PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj55ZXQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IzE4MSAt IFJlbW92ZSBTRVRUSU5HU1tfQUNLXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkgZG9uJ3Qgd2UgcHV0IHRoZSBTRVRUSU5HUyBmcmFtZSBp biBhIFRMUyBleHRlbnNpb24uIFRoYXQgd291bGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlbW92ZSBhIGJ1bmNoIG9mIHJhY2UgY29uZGl0aW9u cy4gSSBoYXZlIGZpbGVkIGFuIGlzc3VlIGZvciB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5j b20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRmlzc3VlcyUyRjQzNiZhbXA7ZGF0YT0wMiU3QzAx JTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDYjU1MjdmNDYzNjU3NDlhYTFiMWMw OGQ0ODI5ODVmNTElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2Mjc3MDM4NTg3MTg4NDY1JmFtcDtzZGF0YT1JV0g0cWQ4USUyQnBGdGYlMkYxMldCOUJkSk13 Q3lBNEV4QkU3Y3k4TEpHSERtSSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9naXRodWIuY29t L3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvNDM2PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBNYXIgMTcsIDIwMTcg YXQgMjoyMiBBTSwgTWFyayBOb3R0aW5naGFtICZsdDs8YSBocmVmPSJtYWlsdG86bW5vdEBtbm90 Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm1ub3RAbW5vdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkV2ZXJ5b25lLDxicj4NCjxicj4NClRoZSAtMDIgZHJhZnRzIGluY29y cG9yYXRlIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9ucyB0byBhIG51bWJlciBvZiBpc3N1ZXMgdGhh dCBoYXZlIGJlZW4gZGlzY3Vzc2VkLjxicj4NCjxicj4NClRob3NlIGlzc3VlcyBhcmUgbGlzdGVk IGJlbG93LiBQbGVhc2UgaGF2ZSBhIGxvb2sgdGhyb3VnaCB0aGVtLCBhbmQgaWYgdGhlcmUgYXJl IGFueSByZXNvbHV0aW9ucyB0aGF0IHlvdSBmZWVsIG5lZWQgbW9yZSBkaXNjdXNzaW9uLCBwbGVh c2UgYnJpbmcgaXQgdXAsIGVpdGhlciBoZXJlIG9uIHRoZSBtYWlsaW5nIGxpc3Qgb3IgaW4gdGhl IGlzc3VlIGl0c2VsZi48YnI+DQo8YnI+DQpJc3N1ZXMgdGhhdCB3ZSBuZWVkIHRvIGRpc2N1c3Mg bW9yZSB3aWxsIGJlIHJlb3BlbmVkLiBUaGUgcmVtYWluaW5nIG9uZXMgd2lsbCBiZSBmbGFnZ2Vk IGFzIGBoYXMtY29uc2Vuc3VzYC48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYSBsb3Qgb2YgdGhlbSwg c28gd2UncmUgbm90IGdvaW5nIHRvIGRvIHRoaXMgdW50aWwgYWZ0ZXIgdGhlIENoaWNhZ28gbWVl dGluZyAoYXQgdGhlIGVhcmxpZXN0KSB0byBnaXZlIHBlb3BsZSBhIGNoYW5jZSB0byBkaXNjdXNz IG9uIHRoZSBsaXN0IGFzIHdlbGwgYXMgaW4gdGhlIG1lZXRpbmcuPGJyPg0KPGJyPg0KU2VlICZs dDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRmJs b2IlMkZtYXN0ZXIlMkZDT05UUklCVVRJTkcubWQlMjNyZXNvbHZpbmctaXNzdWVzJmFtcDtkYXRh PTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NiNTUyN2Y0NjM2NTc0 OWFhMWIxYzA4ZDQ4Mjk4NWY1MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdD MSU3QzAlN0M2MzYyNzcwMzg1ODcxODg0NjUmYW1wO3NkYXRhPSUyQkRQUFVWMEhjcW82SEo2cnY2 VTVzYyUyRiUyQjMlMkIwWEFxNDZWZ0FZOVdXRDlJNCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvYmxvYi9tYXN0 ZXIvQ09OVFJJQlVUSU5HLm1kI3Jlc29sdmluZy1pc3N1ZXM8L2E+Jmd0Ow0KIGZvciBhIHJlbWlu ZGVyIGFib3V0IHRoZSBwcm9jZXNzIHdlJ3JlIHVzaW5nIGhlcmUuIEV2ZW4gd2hlbiB3ZSBoYXZl IGNvbnNlbnN1cywgd2UgY2FuIHJlb3BlbiBhbiBpc3N1ZSBpZiBuZXcgaW5mb3JtYXRpb24gZW1l cmdlcyAoYW5kIHRoYXQgY2FuIHRha2UgYSB2YXJpZXR5IG9mIGZvcm1zKS48YnI+DQo8YnI+DQpU aGlzIGxpc3QgaXMgYWxzbyBhdmFpbGFibGUgYXQgJmx0OzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHVi LmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGaXNzdWVzJTNGdXRmOCUzRCUyNUUyJTI1OUMl MjU5MyUyNnElM0RpcyUyNTNBaXNzdWUlMjUyMGlzJTI1M0FjbG9zZWQlMjUyMGxhYmVsJTI1M0Fk ZXNpZ24lMjUyMC1sYWJlbCUyNTNBaGFzLWNvbnNlbnN1cyZhbXA7ZGF0YT0wMiU3QzAxJTdDbWlj aGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDYjU1MjdmNDYzNjU3NDlhYTFiMWMwOGQ0ODI5 ODVmNTElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Mjc3 MDM4NTg3MTg4NDY1JmFtcDtzZGF0YT00NlYzcXpIMXAyOUklMkI3bUJ0VTIzT1ZQJTJCc3lTMlZJ VHJ2dXVYQ21SYVZscyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v Z2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzP3V0Zjg9PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90OyxzYW5zLXNlcmlmIj7inJM8L3Nw YW4+JmFtcDtxPWlzJTNBaXNzdWUlMjBpcyUzQWNsb3NlZCUyMGxhYmVsJTNBZGVzaWduJTIwLWxh YmVsJTNBaGFzLWNvbnNlbnN1czwvYT4mZ3Q7Ljxicj4NCjxicj4NCkNoZWVycyw8YnI+DQo8YnI+ DQojIyBUcmFuc3BvcnQ8YnI+DQo8YnI+DQojMzUmbmJzcDsgLSBTdGFydGluZyBwYWNrZXQgbnVt YmVyPGJyPg0KIzQwJm5ic3A7IC0gVmFyaWFibGUtbGVuZ3RoIGZpZWxkczxicj4NCiM0OSZuYnNw OyAtIFRyYW5zcG9ydCBwYXJhbWV0ZXIgYWR2ZXJ0aXNlbWVudHM8YnI+DQojNTAmbmJzcDsgLSBV cGRhdGluZyBUcmFuc3BvcnQgcGFyYW1ldGVyczxicj4NCiM1MSZuYnNwOyAtIFFVSUMgdmVyc2lv biBudW1iZXIgc2NoZW1lPGJyPg0KIzUyJm5ic3A7IC0gU291cmNlIGFkZHJlc3MgdmFsaWRhdGlv bjxicj4NCiM1NSZuYnNwOyAtIFdoYXQgY2FuIGNoYW5nZSBpbiBhIGRpZmZlcmVudCB2ZXJzaW9u PGJyPg0KIzU2Jm5ic3A7IC0gRXh0ZW5kaW5nIGZsYWdzPGJyPg0KIzU3Jm5ic3A7IC0gQWR2aWNl IG9uIFNUT1BfV0FJVElORzxicj4NCiM1OSZuYnNwOyAtIERlZmluZSBJQ1NMIHBhcmFtZXRlcjxi cj4NCiM2MiZuYnNwOyAtIEZpbmRpbmcgZnJhbWUgbGVuZ3Roczxicj4NCiM2MyZuYnNwOyAtIEFD SyByZXRyYW5zbWlzc2lvbjxicj4NCiM2NCZuYnNwOyAtIFBhdGggTVRVIERpc2NvdmVyeTxicj4N CiM2NiZuYnNwOyAtIFJlbW92ZSBTVE9QX1dBSVRJTkc8YnI+DQojNjcmbmJzcDsgLSBQaWNraW5n IHBhY2tldCBudW1iZXIgbGVuZ3RoPGJyPg0KIzY5Jm5ic3A7IC0gTWluaW11bSBwYWNrZXQgc2l6 ZTxicj4NCiM3MCZuYnNwOyAtIE1vdmUgQUNLL1NUT1BfV0FJVElORyBpbnRvIHRoZSBwYWNrZXQg aGVhZGVyPGJyPg0KIzc0Jm5ic3A7IC0gQXBwbGljYXRpb24tZGVmaW5lZCBlcnJvciBjb2Rlczxi cj4NCiMxMDQgLSBQcmlvcml0eSBpbiBRVUlDIFRyYW5zcG9ydDxicj4NCiMxMDggLSBNYXhpbXVt IHN0cmVhbSBudW1iZXI8YnI+DQojMTEyIC0gR3JlYXNpbmcgdmVyc2lvbiBuZWdvdGlhdGlvbjxi cj4NCiMxMTQgLSBTVFJFQU0gcmV0cmFuc21pc3Npb24gcHJpb3JpdHk8YnI+DQojMTE2IC0gQ09Q VHMgYXMgZW1wdHkgdHJhbnNwb3J0IHBhcmFtZXRlcnM8YnI+DQojMTE3IC0gU0NVUDxicj4NCiMx MTggLSBTb3VyY2UgQWRkcmVzcyBUb2tlbiBlbmNvZGluZzxicj4NCiMxMTkgLSBTZXJ2ZXItcHJv cG9zZWQgY29ubmVjdGlvbiBJRDxicj4NCiMxMjQgLSBBbHQtU3ZjIHF1aWMgdmVyc2lvbiBoaW50 PGJyPg0KIzEyNiAtIFNlcGFyYXRlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGZvciAwLVJUVDxicj4N CiMxMzMgLSBDb25uZWN0aW9uIElEIGluIHZlcnNpb24gbmVnb3RpYXRpb248YnI+DQojMTM1IC0g RG9TIHVzaW5nIFZlcnNpb24gTmVnb3RpYXRpb24gUGFja2V0czxicj4NCiMxMzYgLSBGaXJzdCBj bGllbnQgcGFja2V0IHNpemU8YnI+DQojMTM5IC0gTWluaW11bSBNVFU8YnI+DQojMTQ3IC0gUmVm bGVjdGlvbiBBdHRhY2sgUmVzaXN0YW5jZTxicj4NCiMxNDggLSBRVUlDIHBhY2tldCBoZWFkZXIg Y29tcGxleGl0eTxicj4NCiMxNTcgLSBVcGRhdGVkIGluZm9ybWF0aW9uIGluIHJldHJhbnNtaXR0 ZWQgZnJhbWVzPGJyPg0KIzE1OCAtIFBhZGRpbmcgYmV0d2VlbiBmcmFtZXM8YnI+DQojMTU5IC0g VGltZSBmb3JtYXQ8YnI+DQojMTYyIC0gUlNUX1NUUkVBTSBhbmQgZmxvdyBjb250cm9sPGJyPg0K IzE2MyAtIFJTVF9TVFJFQU0gYW5kIGNvbm5lY3Rpb24tbGV2ZWwgZmxvdyBjb250cm9sPGJyPg0K IzE2NCAtIFBhZGRpbmcgaGFuZHNoYWtlIHBhY2tldHM8YnI+DQojMTY4IC0gT3JkZXJpbmcgb2Yg QUNLIEZyYW1lIGZpZWxkczxicj4NCiMxNzQgLSBTdHJlYW0gUmVzZXJ2YXRpb248YnI+DQojMTgx IC0gUmVtb3ZlIFNFVFRJTkdTW19BQ0tdPGJyPg0KIzE4NSAtIFJlbGlhYmxlIGlkZW50aWZpY2F0 aW9uIG9mIHRoZSBpbml0aWFsIHBhY2tldCBmb3IgYSBjb25uZWN0aW9uPGJyPg0KIzIwMSAtIERv IHN0cmVhbXMgMCBhbmQgMSBjb3VudCB0b3dhcmRzIE1TUEM/PGJyPg0KIzIwNCAtIFN0cmVhbXMg bm90IGNvbnRyaWJ1dGluZyB0byBjb25uZWN0aW9uLWxldmVsIGZsb3cgY29udHJvbDxicj4NCiMy NDMgLSBBRUFEIEFzc29jaWF0ZWQgRGF0YTxicj4NCiMyNDQgLSBOZWVkIGEgTk9OQ0UgaW4gdmVy c2lvbiBuZWdvdGlhdGlvbiBwYWNrZXRzPGJyPg0KIzI2MiAtIERvbid0IGVuY3J5cHQgY2xpZW50 IGhhbmRzaGFrZSB3aXRoIDEtUlRUIGtleXM8YnI+DQojMjg1IC0gUG9saWNpbmcgcGFja2V0IG51 bWJlciBzaXplPGJyPg0KIzI4NiAtIE91dHN0YW5kaW5nIHBhY2tldHMgYW5kIHBhY2tldCBudW1i ZXIgc2l6ZTxicj4NCiMyODkgLSBBdm9pZCB1c2luZyBQdWJsaWMgUmVzZXQgd2hlcmUgcG9zc2li bGU8YnI+DQojMjkxIC0gQUNLaW5nIEFDSzxicj4NCiMyOTIgLSBEb2VzIGFueSBwb3J0aW9uIG9m IHRoZSBRVUlDIGZyYW1pbmcgcmVxdWlyZSA0IGJ5dGUgYWxpZ25tZW50Pzxicj4NCiMyOTMgLSBE b2VzIHRoZSBjb25uZWN0aW9uIGlkIG5lZWQgdG8gYmUgaW4gYSBjb25zaXN0ZW50IGxvY2F0aW9u Pzxicj4NCiMyOTUgLSBDb25uZWN0aW9uIElEIG9uIGEgdmVyc2lvbiBuZWdvdGlhdGlvbiBwYWNr ZXQ8YnI+DQojMzA4IC0gJnF1b3Q7cmV0cmFuc21pdHRpbmcmcXVvdDsgb2xkIHRpbWVzdGFtcHMg aW4gQUNLIGZyYW1lczxicj4NCiMzMjMgLSBTbWFsbGVyIHBhY2tldCBudW1iZXIgcmVwcmVzZW50 YXRpb25zPGJyPg0KIzM0MCAtIFNjYWxlIGZsb3cgY29udHJvbCBvZmZzZXRzPGJyPg0KIzM0MSAt IFdoYXQgZG9lcyBpdCBtZWFuIHRvIGFja25vd2xlZGdlIHNvbWV0aGluZz88YnI+DQojMzQ3IC0g Q2xhcmlmeSBtZWFuaW5nL2RlZmluaXRpb24gb2YgR09BV0FZPGJyPg0KIzM0OSAtIFdoZW4gc2hv dWxkIHNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRHMgYmUgc2VudCBhbmQgaG93IGFyZSB0aGV5 IGluZGljYXRlZD88YnI+DQojMzUyIC0gRG9lcyBHT0FXQVkgbmVlZCBhbiBlcnJvciBjb2RlPGJy Pg0KPGJyPg0KPGJyPg0KIyMgUmVjb3Zlcnk8YnI+DQo8YnI+DQojNjMmbmJzcDsgLSBBQ0sgcmV0 cmFuc21pc3Npb248YnI+DQojMTY5IC0gUmVzcG9uc2UgdG8gbG9zdCBoYW5kc2hha2UgcGFja2V0 czxicj4NCjxicj4NCjxicj4NCiMjIFRMUzxicj4NCjxicj4NCiMxMiZuYnNwOyAtIERlY291cGxl IFFVSUMgdmVyc2lvbiBhbmQgQUxQTjxicj4NCiMyNSZuYnNwOyAtIEtleSB1cGRhdGUgZm9yd2Fy ZCBzZWNyZWN5PGJyPg0KIzI2Jm5ic3A7IC0gV2hpY2ggYml0IGNhbiBLRVlfUEhBU0UgdXNlPzxi cj4NCiMyNyZuYnNwOyAtIEZpeCBLRVlfUEhBU0UgZm9yIGVhcmx5IGRhdGE8YnI+DQojMzQmbmJz cDsgLSBBQ0sgcnVsZXMgYW5kIHBhY2tldCBwcm90ZWN0aW9uPGJyPg0KIzg3Jm5ic3A7IC0gUVVJ QyBhZHZlcnRpc2VtZW50IGRlc2NyaXB0aW9uPGJyPg0KIzk3Jm5ic3A7IC0gVmVyc2lvbiBOZWdv dGlhdGlvbiAmIzQzOyBUTFM8YnI+DQojMjI2IC0gQXV0aGVudGljYXRpbmcgcHVibGljIHBhcnRz IG9mIHRoZSBwYWNrZXQgaGVhZGVyPGJyPg0KIzI0MyAtIEFFQUQgQXNzb2NpYXRlZCBEYXRhPGJy Pg0KIzI2MiAtIERvbid0IGVuY3J5cHQgY2xpZW50IGhhbmRzaGFrZSB3aXRoIDEtUlRUIGtleXM8 YnI+DQojMjcyIC0gU2lnbmFsaW5nIFRMUyBoYW5kc2hha2UgZmFpbHVyZTxicj4NCjxicj4NCjxi cj4NCiMjIEhUVFA8YnI+DQo8YnI+DQo3NSZuYnNwOyAtIFNFVFRJTkcgc3luY3Jvbml6YXRpb248 YnI+DQo4NyZuYnNwOyAtIFFVSUMgYWR2ZXJ0aXNlbWVudCBkZXNjcmlwdGlvbjxicj4NCjk1Jm5i c3A7IC0gQ09OTkVDVDxicj4NCjEwNCAtIFByaW9yaXR5IGluIFFVSUMgVHJhbnNwb3J0PGJyPg0K MTI0IC0gQWx0LVN2YyBxdWljIHZlcnNpb24gaGludDxicj4NCjEyNyAtIEZyYW1lIGhlYWRlciBy ZXNlcnZlZCBiaXRzPGJyPg0KMTU0IC0gSFRUUCBTdHJlYW0gSUQgU2l6ZTxicj4NCjE3MyAtIFNp emUgb2YgSFRUUCBIZWFkZXIgU2VxdWVuY2UgTnVtYmVyczxicj4NCjE3NiAtIFJTVF9TVFJFQU0g YnJlYWtzIEhQQUNLPGJyPg0KMTgxIC0gUmVtb3ZlIFNFVFRJTkdTW19BQ0tdPGJyPg0KMjAyIC0g SFRUUDogV2h5IGFyZSB3ZSBkZWZpbmluZyBDT05ORUNUPzxicj4NCjIwNCAtIFN0cmVhbXMgbm90 IGNvbnRyaWJ1dGluZyB0byBjb25uZWN0aW9uLWxldmVsIGZsb3cgY29udHJvbDxicj4NCjIyOSAt IFVzZSBhIHF1aWM9IHBhcmFtZXRlciBmb3IgQWx0LVN2YyByYXRoZXIgdGhhbiBjb2xsaWRlIHdp dGggZXhpc3RpbmcgdXNlIG9mIHY9PGJyPg0KMjQyIC0gSFRUUCBleHRlbnNpb24gbWVjaGFuaXNt czxicj4NCjI5NyAtIFJlbW92ZSB0aGUgcXVpYyBwYXJhbWV0ZXIgZnJvbSBBbHQtU3ZjPGJyPg0K MzY0IC0gTWlkLWZyYW1lIGNsb3NlPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+DQpNYXJr IE5vdHRpbmdoYW0mbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYm YW1wO2RhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3Q2I1NTI3 ZjQ2MzY1NzQ5YWExYjFjMDhkNDgyOTg1ZjUxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN0MxJTdDMCU3QzYzNjI3NzAzODU4NzE4ODQ2NSZhbXA7c2RhdGE9RU5jNTQ0UWclMkZx VWRuMEpkZ2xLOTRMakRidjNKNXNLeGk3dEVqaDdDQzNrJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cubW5vdC5uZXQvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR03MB27085814F6237EA7D679575C87020BN6PR03MB2708namp_-- From nobody Thu Apr 13 13:19:48 2017 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 DFC8D124B0A for ; Thu, 13 Apr 2017 13:19:46 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 SINjD4VfHZgJ for ; Thu, 13 Apr 2017 13:19:44 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 EBAD912943E for ; Thu, 13 Apr 2017 13:19:43 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id m133so15988318ybb.1 for ; Thu, 13 Apr 2017 13:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=m+NwBPQz9Bbg/VKHsyv9oRhfgcwjVYzK+N4eVMDcKbk=; b=ERJiU4MwWHHph+UVt9pjIjsOqk8c+fUEjku15pE5kEg2+6zzZkZHffkvVKaoj5uWDZ RmS/S7F/X9bz5ctVsqTM7F9mQwEhoPTdyzMr8poU84pU4YFMWosh3748OqSJpkadn+sE voPvHAHjWSy52N/gNHpwyXIWUQ0G60TqeYHSPxJAUnozIVZDpZm0PYiohUP4W7ciyPRT wrf6/cyTvAgShIK3oPYgHbSkn6ubycpbPlu45lqvmbsXz7q/pAsn26au2jQUi3mm9292 C0Bza0gqXt7Bh37I5sF6Ozgyh9STGdlW43dLfymR6QWb7Kb89zXfydSKafJO9CMLPjU5 2bUQ== 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=m+NwBPQz9Bbg/VKHsyv9oRhfgcwjVYzK+N4eVMDcKbk=; b=LJBWuyVS6tUWmUoeU8MykPmuRfEyUkj9xTpbfbdOsWLyLI1mYJfybnv/IGBpgjQ3gE BTCK0ma8CKXGzzbjSzXlAL4GnUNhn2aGsb1ijPH1DmMfv0jDxBpsddouVXWrypRVvgEx MmxN+WlZAhRCLrHr0dsJEcUQotsAU+ZN9WhC4S6ZqFh+FBY0+ibZNIN07L+LefaKjl6N zM0eCky/YH9ijj1frn5ysmO7OetV8cXKzoshg2KASejndsVNexBkgAUAIgKbRHCACkwn M25BR6mFavo0+cee/YFpYaJmzzzrjQii5S9Gc9rd/wzLxJdmnE5w5pFV8SSO44aSCP+d WkSw== X-Gm-Message-State: AN3rC/6EaCAutViN8KiCMtxNqZRdk5h+YqSBGzTVVYMH6BEaEThEMLxJ GfiA00o7JqtOu70/941fh3DSa7TtXP7xNa0= X-Received: by 10.37.172.100 with SMTP id r36mr3863646ybd.107.1492114783097; Thu, 13 Apr 2017 13:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 13 Apr 2017 13:19:02 -0700 (PDT) From: Eric Rescorla Date: Thu, 13 Apr 2017 13:19:02 -0700 Message-ID: Subject: Sending/Receiving packets before client Finished To: IETF QUIC WG Content-Type: multipart/alternative; boundary=f403045eb69a9c6d45054d120bec Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 20:19:47 -0000 --f403045eb69a9c6d45054d120bec Content-Type: text/plain; charset=UTF-8 Rereading the -tls draft, it's not entirely clear to me what the rules are around the client's Finished. I think the rules you are applying (on the server, because the client has no such issues): - The server can process 0-RTT messages immediately (S 8.2) - The server can process 1-RTT messages upon receiving either the client's Finished or the PSK binder (S 8.3) [0] - The server can send messages with the 1-RTT keys upon sending Finished, either in 0.5 RTT or in 1-RTT. (implied in S 4.2.3) Do I understand this correctly? If so, I may have some proposed changes, but I'd like to understand the intention first. Thanks, -Ekr [0] Though it's actually sort of confusing because the second graf permits the Finished or the PSK binder and the last graf says you can't use packets before Finished if you depend on client auth. --f403045eb69a9c6d45054d120bec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rereading the -tls draft, it's not entirely clear= to me what the
rules are around the client's Finished. I thi= nk the rules you
are applying (on the server, because the client = has no such issues):

- The server can process 0-RT= T messages immediately (S 8.2)
- The server can process 1-RTT mes= sages upon receiving either
=C2=A0 the client's Finished or t= he PSK binder (S 8.3) [0]
- The server can send messages with the= 1-RTT keys upon sending
=C2=A0 Finished, either in 0.5 RTT or in= 1-RTT. (implied in S 4.2.3)

Do I understand this = correctly? If so, I may have some proposed
changes, but I'd l= ike to understand the intention first.

Thanks,
-Ekr


[0] Though it's act= ually sort of confusing because the second
graf permits the Finis= hed or the PSK binder and the last graf
says you can't use pa= ckets before Finished if you depend on
client auth.
--f403045eb69a9c6d45054d120bec-- From nobody Thu Apr 13 13:50:29 2017 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 50007129A9D for ; Thu, 13 Apr 2017 13:50:28 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 1SOCXDlDGyWQ for ; Thu, 13 Apr 2017 13:50:27 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 E28551293FB for ; Thu, 13 Apr 2017 13:50:26 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l189so29835697ywb.0 for ; Thu, 13 Apr 2017 13:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=qZRHnNkAV0ZwQzvmioqQbu/xRTC5AMvqQgSYweT46Xo=; b=hahpslXSdOXpZDSyVHhW4yP0Ft/RCEX3IyqufjvxAI8Gikp4bVhM+pjzx3tt3uDMtw xxhxNz9C+orYuqVk8Jiw822XevOo145x28GaE9yDi+Jey2Syhhxu4jb2tQNkqmD2gF+9 RTdLBW6kJedXq6C25zDoDilvTZp9xm9qjo3u1huxfhB6PmGGCIzh1ERZQSwp1+6CVtuv +WB8IszXy7pWgBEYK765e/3Qc3Rd9zuK625GAk/8DOQv9fFBuDvurCfveoHTdSOfbZQ8 e2jVGIZcXy8QIpdbF7UUbca82kQ/W2UsP89IbqPiTCq/tuSdgmCeQQqgZNlcZ1pTJ8Uo 9Acw== 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=qZRHnNkAV0ZwQzvmioqQbu/xRTC5AMvqQgSYweT46Xo=; b=QbJN3BcnEBznzQ0Ba1pySKaD9xxewGM+DK+F208JJAxiGd5cAX4BwUHNxkNwgWP1iW uIae//7hsmlVCTpiAb4yFlkNzaePHYTJkNXteVD52/kRgyw9+tPmd39FwOb/xRroCTnH zM3dNJMNwR2/n9YcYDFdsYTektBcSR9orxTN1Hs0DBJ8DGxBqJLDjFTDcloTxTArTH4T 8h01vUN5ZFWNdsMUEf4Tg7RqgebNjAAt3wS8yGDSnUYBGUrJlpRtswqcotlcGEB9/nAZ fhWc0yVQzp4AIpkmz2e8zsjTIpzShf/aE3NfqI2RDhj4KUSddX2FZJ51CPbhHjbJJayW I/uA== X-Gm-Message-State: AN3rC/74EBzcm09sUzsY2fYqcFRpYqCquwNtRPjDRGT61mt4uTMvemtZ R9el8A/k5E4RyXsk9XNOQpdG1CoEy4mI X-Received: by 10.129.182.65 with SMTP id h1mr3879473ywk.337.1492116625146; Thu, 13 Apr 2017 13:50:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 13 Apr 2017 13:49:44 -0700 (PDT) From: Eric Rescorla Date: Thu, 13 Apr 2017 13:49:44 -0700 Message-ID: Subject: Key change logic To: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c1bde9c67fb99054d1279f0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 20:50:28 -0000 --94eb2c1bde9c67fb99054d1279f0 Content-Type: text/plain; charset=UTF-8 I'm not sure that the logic around key changes is exactly clear. Case 1: Assume you are in steady state where you have just received a packet with key generation G = 0, key phase bit P = 1, and packet number PN = 10 (i.e., there have been no key changes so far). You now receive a packet with PN = 15, P = 1. Turning to 6.2, we see: A receiving endpoint detects an update when the KEY_PHASE bit doesn't match what it is expecting. It creates a new secret (see Section 5.2) and the corresponding read key and IV. If the packet can be decrypted and authenticated using these values, then the keys it uses for packet protection are also updated. The next packet sent by the endpoint will then use the new keys. An endpoint doesn't need to send packets immediately when it detects that its peer has updated keys. The next packet that it sends will simply use the new keys. If an endpoint detects a second update before it has sent any packets with updated keys it indicates that its peer has updated keys twice without awaiting a reciprocal update. An endpoint MUST treat consecutive key updates as a fatal error and abort the connection. So, we compute generation G=1 and try to decrypt the packet. If it succeeds, we install key G=1 with the knowledge that the transition happens somewhere between 10 and 15. Case 2: The same as Case #1, but I receive PN = 7, P = 1. I think what we do then is just discard the packet immediately because it's impossible, right? Not clear where the text says that. Case 3: Imagine we are in the state right after case #1 (i.e., we have sent no packets) and now we receive a packet PN = 20, P = 0. Now, this looks like a second key change, so what do we do now? It seems like we have three choices: 1. Discard it because it's clearly illegal. 2. Try to decrypt it with key G=2 and process it as a key change (as the first paragraph of the citation above graf tells us to do). 3. Tear down the connection as specified in the second paragraph above tells us to do. #2 seems pretty silly, because only one of two things can happen (a) We can't decrypt it because it's bogus and we discard it. (b) We can decrypt it (because the keys have been compromised or the other side is misbehaving) in which case we tear down the connection. But it's almost certainly (a), so this doesn't seem like a good use of resources. #3 is even worse, because it means that anyone can send us an unauthenticated packet and tear down the connection, so that can't be right. I think that leaves us with #2 as the right answer, but that's the one thing that the spec doesn't tell us to do, and it renders the second paragraph above irrelevant. Case 4: The same as case #1, but next I receive two packets: - PN = 12, P = 1 [which decrypts with key G = 1] - PN = 14, P = 0 Now, this second packet is impossible because we know that that we have: PN = 10 [G = 0] PN = 12 [G = 1] PN = 15 [G = 1] So we can't have a key change between 12 and 15, so here we are. The spec doesn't give guidance on what to do. I think the answer is "discard the packet". I think we need to write these sections a bit more clearly. I'm happy to take a crack at it, but I'd like to make sure that we all agree that the behaviors above are the right ones. -Ekr --94eb2c1bde9c67fb99054d1279f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure that the logic around key changes is= exactly clear.

Case 1:
Assume you are i= n steady state where you have just received a packet
with key gen= eration G =3D 0, key phase bit P =3D 1, and packet number PN =3D
= 10 (i.e., there have been no key changes so far). You now receive a
packet with PN =3D 15, P =3D 1. Turning to 6.2, we see:

=C2=A0 =C2=A0A receiving endpoint detects an update when the KEY_P= HASE bit doesn't
=C2=A0 =C2=A0match what it is expecting.=C2= =A0 It creates a new secret (see
=C2=A0 =C2=A0Section 5.2) and th= e corresponding read key and IV.=C2=A0 If the packet
=C2=A0 =C2= =A0can be decrypted and authenticated using these values, then the keys
=C2=A0 =C2=A0it uses for packet protection are also updated.=C2=A0 T= he next packet sent
=C2=A0 =C2=A0by the endpoint will then use th= e new keys.

=C2=A0 =C2=A0An endpoint doesn't n= eed to send packets immediately when it detects
=C2=A0 =C2=A0that= its peer has updated keys.=C2=A0 The next packet that it sends will
<= div>=C2=A0 =C2=A0simply use the new keys.=C2=A0 If an endpoint detects a se= cond update
=C2=A0 =C2=A0before it has sent any packets with upda= ted keys it indicates that
=C2=A0 =C2=A0its peer has updated keys= twice without awaiting a reciprocal update.
=C2=A0 =C2=A0An endp= oint MUST treat consecutive key updates as a fatal error and
=C2= =A0 =C2=A0abort the connection.

So, we compute gen= eration G=3D1 and try to decrypt the packet. If it
succeeds, we i= nstall key G=3D1 with the knowledge that the transition
happens s= omewhere between 10 and 15.


Case 2:=
The same as Case #1, but I receive PN =3D 7, P =3D 1. I think wh= at we do
then is just discard the packet immediately because it&#= 39;s impossible,
right? Not clear where the text says that.
=


Case 3:
Imagine we are in the = state right after case #1 (i.e., we have sent no
packets) and now= we receive a packet PN =3D 20, P =3D 0. Now, this looks
like a s= econd key change, so what do we do now? It seems like we have
thr= ee choices:

1. Discard it because it's clearly= illegal.
2. Try to decrypt it with key G=3D2 and process it as a= key change (as
=C2=A0 =C2=A0the first paragraph of the citation = above graf tells us to do).
3. Tear down the connection as specif= ied in the second paragraph
=C2=A0 =C2=A0above tells us to do.

#2 seems pretty silly, because only one of two thing= s can happen

(a) We can't decrypt it because i= t's bogus and we discard it.
(b) We can decrypt it (because t= he keys have been compromised
=C2=A0 =C2=A0 or the other side is = misbehaving) in which case we tear
=C2=A0 =C2=A0 down the connect= ion.

But it's almost certainly (a), so this do= esn't seem like a good
use of resources.

=
#3 is even worse, because it means that anyone can send us an
unauthenticated packet and tear down the connection, so that
ca= n't be right.

I think that leaves us with #2 a= s the right answer, but that's
the one thing that the spec do= esn't tell us to do, and it renders
the second paragraph abov= e irrelevant.


Case 4:
The= same as case #1, but next I receive two packets:

= - PN =3D 12, P =3D 1 [which decrypts with key G =3D 1]
- PN =3D 1= 4, P =3D 0

Now, this second packet is impossible b= ecause we know that that
we have:

=C2=A0= PN =3D 10 [G =3D 0]
=C2=A0 PN =3D 12 [G =3D 1]
=C2=A0 = PN =3D 15 [G =3D 1]

So we can't have a key cha= nge between 12 and 15, so here we are. The
spec doesn't give = guidance on what to do. I think the answer is
"discard the p= acket".


I think we need to wri= te these sections a bit more clearly. I'm
happy to take a cra= ck at it, but I'd like to make sure that we all
agree that th= e behaviors above are the right ones.

-Ekr

--94eb2c1bde9c67fb99054d1279f0-- From nobody Thu Apr 13 13:52:31 2017 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 D6D5D1243F3 for ; Thu, 13 Apr 2017 13:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 chtIT3PIG6Qb for ; Thu, 13 Apr 2017 13:52:26 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE2D1200DF for ; Thu, 13 Apr 2017 13:52:26 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id k13so29950853ywk.1 for ; Thu, 13 Apr 2017 13:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9p7lxC3ImtKn9aBY2TiWaO6mzsPmEqnsvq8VMuIHqzo=; b=J0pL2Li1eYKuxbBFjxcmV/8VCJlVl8+clSGd4e3FoLcep5aFNAJu9W3MPBUCuNl3K1 jdiNRiFJ0estatZIUKaliqn/+E+ouGRsAei0ysmpU0FrNGim10W12+Xk2onIgPShdTW/ FcUNIsg7xdghsIQ8TmNnpZxbvQqQFjOIODzAt6Vp4gQt1Vyk6iPEWp5U7v72/wW45gEL 2KjHjyF/05URwqp5pcB88ZM3v7x72uD301a+IDqJUY8w1iJq+730FSzJ9J0Sn8yG9XzC Tg3gHAvPeoj8WKF/pShVY848/DVGilYDPc9CKWvXi1L5A+1r63JPdNonLTHOclWGV9hz HUHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9p7lxC3ImtKn9aBY2TiWaO6mzsPmEqnsvq8VMuIHqzo=; b=CQiFjdO9uiEYcNYvtpUcAfQAx6OxABoI8VRxH7zMXSc67JfKw4EOf/RTVk8NS9z/ww zH5bZrK/bSAYI/2doC9ydpUDVfxHA5UA1VjjuwdQit6HNhv2PeCgVeo9JNgn9dfvYJKa 75RZ1B2C4+sY9T1ZYgKnSN0EFI9JO8pwnASvUS2a7g2xojXN1XwVh14lGAICsjyoaKTm lPu/TJqh3CKFILdbKTjSiw1TM8X8u/sCZXaI65cZwMFlJ2JdeySNWTRxYp966zAkmj/a v3ZJxo08LyZuA12YHv45Eiv3F61rpPgfAeIS1D6gJqRv8PW8xVaGqq/kNmZbC1rOls2J SgrQ== X-Gm-Message-State: AN3rC/4gOjadZzL77iN+ttUhS/2J6BQSB6jFot6gACXHptvyJWuXG75Q NDzLCjV6Y2mdmTOpsgImfNDy/7kPgg== X-Received: by 10.129.177.8 with SMTP id p8mr4170964ywh.327.1492116745696; Thu, 13 Apr 2017 13:52:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 13 Apr 2017 13:51:45 -0700 (PDT) In-Reply-To: References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> From: Eric Rescorla Date: Thu, 13 Apr 2017 13:51:45 -0700 Message-ID: Subject: Re: Consensus Call on issues closed by the -02 drafts To: Mike Bishop Cc: Mark Nottingham , IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary=94eb2c13ce3897572d054d1280c1 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 20:52:30 -0000 --94eb2c13ce3897572d054d1280c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 13, 2017 at 12:56 PM, Mike Bishop wrote: > Re: SETTINGS in TLS, rather than putting another new extension, the more > general form of this would be to say that, just as the TLS extension > carries an opaque blob that QUIC uses for settings, the QUIC blob also > contains an application-specified blob. Reserve a QUIC settings value fo= r > =E2=80=9Capplication-specified data=E2=80=9D and let each application def= ine the layout as > they desired. > Yes, this would be a reasonable design. An alternative would be simply to allocate both sets of settings out of the same code point space. -Ekr > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Thursday, April 13, 2017 11:10 AM > *To:* Mark Nottingham > *Cc:* IETF QUIC WG ; Lars Eggert > *Subject:* Re: Consensus Call on issues closed by the -02 drafts > > > > I have reviewed all the transport issues. I believe that nearly all > > of them can be marked closed, modulo the ones noted below. I am still > > reviewing the issues for the other drafts, but there is a lot of > > duplication, so I expect to get to them today. > > > > > > #51 - QUIC version number scheme > > > > I had requested that this document the existing Google version numbers, > > but this does not seem to have happened, and it should. > > > > > > #55 - What can change in a different version > > > > I am fine with closing this for now, but it is tied directly to the > > question of packet format and in particular how to handle packet > > number and connection ID, so it will need revision if we decide > > to adopt an encrypted packet number/conn-id proposal (which I > > intend to make in Paris if not before). > > > > > > #158 - Padding between frames > > > > As I noted previously, it seems like it would be be better to make > > padding a security layer function. We could then use the TLS-style > > padding (or whatever). I'm not sure we have consensus on this point > > yet. > > > > > > #181 - Remove SETTINGS[_ACK] > > > > Why don't we put the SETTINGS frame in a TLS extension. That would > > remove a bunch of race conditions. I have filed an issue for this. > > > > https://github.com/quicwg/base-drafts/issues/436 > > > > > -Ekr > > > > > > On Fri, Mar 17, 2017 at 2:22 AM, Mark Nottingham wrote: > > Everyone, > > The -02 drafts incorporate the proposed resolutions to a number of issues > that have been discussed. > > Those issues are listed below. Please have a look through them, and if > there are any resolutions that you feel need more discussion, please brin= g > it up, either here on the mailing list or in the issue itself. > > Issues that we need to discuss more will be reopened. The remaining ones > will be flagged as `has-consensus`. > > There are a lot of them, so we're not going to do this until after the > Chicago meeting (at the earliest) to give people a chance to discuss on t= he > list as well as in the meeting. > > See CONTRIBUTING.md#resolving-issues > > > for a reminder about the process we're using here. Even when we have > consensus, we can reopen an issue if new information emerges (and that ca= n > take a variety of forms). > > This list is also available at base-drafts/issues?utf8=3D=E2=9C=93&q=3Dis%3Aissue%20is%3Aclosed% > 20label%3Adesign%20-label%3Ahas-consensus > > >. > > Cheers, > > ## Transport > > #35 - Starting packet number > #40 - Variable-length fields > #49 - Transport parameter advertisements > #50 - Updating Transport parameters > #51 - QUIC version number scheme > #52 - Source address validation > #55 - What can change in a different version > #56 - Extending flags > #57 - Advice on STOP_WAITING > #59 - Define ICSL parameter > #62 - Finding frame lengths > #63 - ACK retransmission > #64 - Path MTU Discovery > #66 - Remove STOP_WAITING > #67 - Picking packet number length > #69 - Minimum packet size > #70 - Move ACK/STOP_WAITING into the packet header > #74 - Application-defined error codes > #104 - Priority in QUIC Transport > #108 - Maximum stream number > #112 - Greasing version negotiation > #114 - STREAM retransmission priority > #116 - COPTs as empty transport parameters > #117 - SCUP > #118 - Source Address Token encoding > #119 - Server-proposed connection ID > #124 - Alt-Svc quic version hint > #126 - Separate transport parameters for 0-RTT > #133 - Connection ID in version negotiation > #135 - DoS using Version Negotiation Packets > #136 - First client packet size > #139 - Minimum MTU > #147 - Reflection Attack Resistance > #148 - QUIC packet header complexity > #157 - Updated information in retransmitted frames > #158 - Padding between frames > #159 - Time format > #162 - RST_STREAM and flow control > #163 - RST_STREAM and connection-level flow control > #164 - Padding handshake packets > #168 - Ordering of ACK Frame fields > #174 - Stream Reservation > #181 - Remove SETTINGS[_ACK] > #185 - Reliable identification of the initial packet for a connection > #201 - Do streams 0 and 1 count towards MSPC? > #204 - Streams not contributing to connection-level flow control > #243 - AEAD Associated Data > #244 - Need a NONCE in version negotiation packets > #262 - Don't encrypt client handshake with 1-RTT keys > #285 - Policing packet number size > #286 - Outstanding packets and packet number size > #289 - Avoid using Public Reset where possible > #291 - ACKing ACK > #292 - Does any portion of the QUIC framing require 4 byte alignment? > #293 - Does the connection id need to be in a consistent location? > #295 - Connection ID on a version negotiation packet > #308 - "retransmitting" old timestamps in ACK frames > #323 - Smaller packet number representations > #340 - Scale flow control offsets > #341 - What does it mean to acknowledge something? > #347 - Clarify meaning/definition of GOAWAY > #349 - When should server-chosen connection IDs be sent and how are they > indicated? > #352 - Does GOAWAY need an error code > > > ## Recovery > > #63 - ACK retransmission > #169 - Response to lost handshake packets > > > ## TLS > > #12 - Decouple QUIC version and ALPN > #25 - Key update forward secrecy > #26 - Which bit can KEY_PHASE use? > #27 - Fix KEY_PHASE for early data > #34 - ACK rules and packet protection > #87 - QUIC advertisement description > #97 - Version Negotiation + TLS > #226 - Authenticating public parts of the packet header > #243 - AEAD Associated Data > #262 - Don't encrypt client handshake with 1-RTT keys > #272 - Signaling TLS handshake failure > > > ## HTTP > > 75 - SETTING syncronization > 87 - QUIC advertisement description > 95 - CONNECT > 104 - Priority in QUIC Transport > 124 - Alt-Svc quic version hint > 127 - Frame header reserved bits > 154 - HTTP Stream ID Size > 173 - Size of HTTP Header Sequence Numbers > 176 - RST_STREAM breaks HPACK > 181 - Remove SETTINGS[_ACK] > 202 - HTTP: Why are we defining CONNECT? > 204 - Streams not contributing to connection-level flow control > 229 - Use a quic=3D parameter for Alt-Svc rather than collide with existi= ng > use of v=3D > 242 - HTTP extension mechanisms > 297 - Remove the quic parameter from Alt-Svc > 364 - Mid-frame close > > > > -- > Mark Nottingham https://www.mnot.net/ > > > > --94eb2c13ce3897572d054d1280c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Apr 13, 2017 at 12:56 PM, Mike Bishop <Michael.Bishop@m= icrosoft.com> wrote:

Re: SETTINGS in TLS, rather than putting another new= extension, the more general form of this would be to say that, just as the= TLS extension carries an opaque blob that QUIC uses for settings, the QUIC= blob also contains an application-specified blob.=C2=A0 Reserve a QUIC settings value for =E2=80=9Capplication-specifi= ed data=E2=80=9D and let each application define the layout as they desired= .


Yes, this would be a reas= onable design.

An alternative would be simply to a= llocate both sets of settings out of the
same code point space.

-Ekr
=C2=A0

<= /p>

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Thursday, April 13, 2017 11:10 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: IETF QUIC WG <quic@ietf.org>; Lars Eggert <lars@netapp.com>
Subject: Re: Consensus Call on issues closed by the -02 drafts

=C2=A0

I have reviewed all the transport issues. I believe = that nearly all

of them can be marked closed, modulo the ones noted = below. I am still

reviewing the issues for the other drafts, but there= is a lot of

duplication, so I expect to get to them today.

=C2=A0

=C2=A0

#51 =C2=A0- QUIC version number scheme=

=C2=A0

I had requested that this document the existing Goog= le version numbers,

but this does not seem to have happened, and it shou= ld.

=C2=A0

=C2=A0

#55 =C2=A0- What can change in a different version

=C2=A0

I am fine with closing this for now, but it is tied = directly to the

question of packet format and in particular how to h= andle packet

number and connection ID, so it will need revision i= f we decide

to adopt an encrypted packet number/conn-id proposal= (which I

intend to make in Paris if not before).

=C2=A0

=C2=A0

#158 - Padding between frames

=C2=A0

As I noted previously, it seems like it would be be = better to make

padding a security layer function. We could then use= the TLS-style

padding (or whatever). I'm not sure we have cons= ensus on this point

yet.

=C2=A0

=C2=A0

#181 - Remove SETTINGS[_ACK]

=C2=A0

Why don't we put the SETTINGS frame in a TLS ext= ension. That would

remove a bunch of race conditions. I have filed an i= ssue for this.

=C2=A0

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Fri, Mar 17, 2017 at 2:22 AM, Mark Nottingham <= ;mnot@mnot.net> w= rote:

Everyone,

The -02 drafts incorporate the proposed resolutions to a number of issues t= hat have been discussed.

Those issues are listed below. Please have a look through them, and if ther= e are any resolutions that you feel need more discussion, please bring it u= p, either here on the mailing list or in the issue itself.

Issues that we need to discuss more will be reopened. The remaining ones wi= ll be flagged as `has-consensus`.

There are a lot of them, so we're not going to do this until after the = Chicago meeting (at the earliest) to give people a chance to discuss on the= list as well as in the meeting.

See <https://github.com/quic= wg/base-drafts/blob/master/CONTRIBUTING.md#resolving-issues<= /a>> for a reminder about the process we're using here. Even when we have c= onsensus, we can reopen an issue if new information emerges (and that can t= ake a variety of forms).

This list is also available at <https:/= /github.com/quicwg/base-drafts/issues?utf8=3D=E2=9C=93&q=3Dis%= 3Aissue%20is%3Aclosed%20label%3Adesign%20-label%3Ahas-consensus>.

Cheers,

## Transport

#35=C2=A0 - Starting packet number
#40=C2=A0 - Variable-length fields
#49=C2=A0 - Transport parameter advertisements
#50=C2=A0 - Updating Transport parameters
#51=C2=A0 - QUIC version number scheme
#52=C2=A0 - Source address validation
#55=C2=A0 - What can change in a different version
#56=C2=A0 - Extending flags
#57=C2=A0 - Advice on STOP_WAITING
#59=C2=A0 - Define ICSL parameter
#62=C2=A0 - Finding frame lengths
#63=C2=A0 - ACK retransmission
#64=C2=A0 - Path MTU Discovery
#66=C2=A0 - Remove STOP_WAITING
#67=C2=A0 - Picking packet number length
#69=C2=A0 - Minimum packet size
#70=C2=A0 - Move ACK/STOP_WAITING into the packet header
#74=C2=A0 - Application-defined error codes
#104 - Priority in QUIC Transport
#108 - Maximum stream number
#112 - Greasing version negotiation
#114 - STREAM retransmission priority
#116 - COPTs as empty transport parameters
#117 - SCUP
#118 - Source Address Token encoding
#119 - Server-proposed connection ID
#124 - Alt-Svc quic version hint
#126 - Separate transport parameters for 0-RTT
#133 - Connection ID in version negotiation
#135 - DoS using Version Negotiation Packets
#136 - First client packet size
#139 - Minimum MTU
#147 - Reflection Attack Resistance
#148 - QUIC packet header complexity
#157 - Updated information in retransmitted frames
#158 - Padding between frames
#159 - Time format
#162 - RST_STREAM and flow control
#163 - RST_STREAM and connection-level flow control
#164 - Padding handshake packets
#168 - Ordering of ACK Frame fields
#174 - Stream Reservation
#181 - Remove SETTINGS[_ACK]
#185 - Reliable identification of the initial packet for a connection
#201 - Do streams 0 and 1 count towards MSPC?
#204 - Streams not contributing to connection-level flow control
#243 - AEAD Associated Data
#244 - Need a NONCE in version negotiation packets
#262 - Don't encrypt client handshake with 1-RTT keys
#285 - Policing packet number size
#286 - Outstanding packets and packet number size
#289 - Avoid using Public Reset where possible
#291 - ACKing ACK
#292 - Does any portion of the QUIC framing require 4 byte alignment?
#293 - Does the connection id need to be in a consistent location?
#295 - Connection ID on a version negotiation packet
#308 - "retransmitting" old timestamps in ACK frames
#323 - Smaller packet number representations
#340 - Scale flow control offsets
#341 - What does it mean to acknowledge something?
#347 - Clarify meaning/definition of GOAWAY
#349 - When should server-chosen connection IDs be sent and how are they in= dicated?
#352 - Does GOAWAY need an error code


## Recovery

#63=C2=A0 - ACK retransmission
#169 - Response to lost handshake packets


## TLS

#12=C2=A0 - Decouple QUIC version and ALPN
#25=C2=A0 - Key update forward secrecy
#26=C2=A0 - Which bit can KEY_PHASE use?
#27=C2=A0 - Fix KEY_PHASE for early data
#34=C2=A0 - ACK rules and packet protection
#87=C2=A0 - QUIC advertisement description
#97=C2=A0 - Version Negotiation + TLS
#226 - Authenticating public parts of the packet header
#243 - AEAD Associated Data
#262 - Don't encrypt client handshake with 1-RTT keys
#272 - Signaling TLS handshake failure


## HTTP

75=C2=A0 - SETTING syncronization
87=C2=A0 - QUIC advertisement description
95=C2=A0 - CONNECT
104 - Priority in QUIC Transport
124 - Alt-Svc quic version hint
127 - Frame header reserved bits
154 - HTTP Stream ID Size
173 - Size of HTTP Header Sequence Numbers
176 - RST_STREAM breaks HPACK
181 - Remove SETTINGS[_ACK]
202 - HTTP: Why are we defining CONNECT?
204 - Streams not contributing to connection-level flow control
229 - Use a quic=3D parameter for Alt-Svc rather than collide with existing= use of v=3D
242 - HTTP extension mechanisms
297 - Remove the quic parameter from Alt-Svc
364 - Mid-frame close



--
Mark Nottingham=C2=A0 =C2=A0https= ://www.mnot.net/

=C2=A0


--94eb2c13ce3897572d054d1280c1-- From nobody Thu Apr 13 13:57:31 2017 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 D11761243F3 for ; Thu, 13 Apr 2017 13:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 9WnPW58w-whK for ; Thu, 13 Apr 2017 13:57:26 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998FA1200DF for ; Thu, 13 Apr 2017 13:57:26 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id j9so29932457ywj.3 for ; Thu, 13 Apr 2017 13:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8ED5mZQtiNw+rhgya276+s2YKjvfVPAmW/KXYq2pFqU=; b=MXnpRQeROQ7a9ijUjSYI12cVyvBBwrdRwi1bVPLkqT6gLMfFOnMcLYfzT5m0D6fbhb iTtfCVxNsFwNTOW5ZmQFs5UqxUtt+L/CLjU6y6EaeDd2ig8OadgTd7mqaWVHoXpK1AnF qOEZc1YPURyjkhFSBh2K96OQ5MnbKkYQCs7ZyJGrto9ym64yXlSlKmtSPJe65Wfuw4Da Uryg2e6tbtq6wJC5JjT0ZdBsx/frBg2o33PtfNeH7o4eJAQ4rZ4UL7ao1zILd4gN6hmS JWax1LfyciKmVn2FGE5gs9JAorKtDZ751W3SGwVR9tlUJB9igIFxs1zTAGGJEy5n1swB cTfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8ED5mZQtiNw+rhgya276+s2YKjvfVPAmW/KXYq2pFqU=; b=InYaBWdNjR+s/EXKybzpfJeUBU0XkPB3+RUh6SExX7/OTlAyH/xtKqhw/5e0eBb69x CyYKy3co1jGx1JvJunSjyLRY01nFdlkjAfBPll7M5p5r+UmZgGSEg2DP4LCt7RK+cC5U L5POdh3yvJBI9SHf4lXZf7F0o74W0QN67hj12wuhuPkvIezlrwAh3bcggE9RcdBozA4k bMPS5Tr1POR8d9w7B9BPyO8OABHq+WAWxCEUJrm2E2zE1bYyZee+bnEOXmLZAOiS8aHE reKkA/nJHwv/MwCnfio6e+CAy91JO2ARYbSTzBSfIgjWgbq0BzGzGZGruGo71BCqEhg8 9LvA== X-Gm-Message-State: AN3rC/49lPvcdVNN14WMn5Cl3a7AM0IZ/unp6gVrMWpLwILz/lCZm8Q7 MkC2qs7MZdoSSnw4IK/ImbEg+N/bGg== X-Received: by 10.129.177.8 with SMTP id p8mr4184912ywh.327.1492117045869; Thu, 13 Apr 2017 13:57:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 13 Apr 2017 13:56:45 -0700 (PDT) In-Reply-To: References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> From: Eric Rescorla Date: Thu, 13 Apr 2017 13:56:45 -0700 Message-ID: Subject: Re: Consensus Call on issues closed by the -02 drafts To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary=94eb2c13ce387b82d5054d1292c6 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 20:57:30 -0000 --94eb2c13ce387b82d5054d1292c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Replying to myself... I have gone through all the issues and I believe that aside from the issues listed above and the emails I just sent to the list, I believe we can provisionally close the issues you list. -Ekr On Thu, Apr 13, 2017 at 11:09 AM, Eric Rescorla wrote: > I have reviewed all the transport issues. I believe that nearly all > of them can be marked closed, modulo the ones noted below. I am still > reviewing the issues for the other drafts, but there is a lot of > duplication, so I expect to get to them today. > > > #51 - QUIC version number scheme > > I had requested that this document the existing Google version numbers, > but this does not seem to have happened, and it should. > > > #55 - What can change in a different version > > I am fine with closing this for now, but it is tied directly to the > question of packet format and in particular how to handle packet > number and connection ID, so it will need revision if we decide > to adopt an encrypted packet number/conn-id proposal (which I > intend to make in Paris if not before). > > > #158 - Padding between frames > > As I noted previously, it seems like it would be be better to make > padding a security layer function. We could then use the TLS-style > padding (or whatever). I'm not sure we have consensus on this point > yet. > > > #181 - Remove SETTINGS[_ACK] > > Why don't we put the SETTINGS frame in a TLS extension. That would > remove a bunch of race conditions. I have filed an issue for this. > > https://github.com/quicwg/base-drafts/issues/436 > > -Ekr > > > On Fri, Mar 17, 2017 at 2:22 AM, Mark Nottingham wrote: > >> Everyone, >> >> The -02 drafts incorporate the proposed resolutions to a number of issue= s >> that have been discussed. >> >> Those issues are listed below. Please have a look through them, and if >> there are any resolutions that you feel need more discussion, please bri= ng >> it up, either here on the mailing list or in the issue itself. >> >> Issues that we need to discuss more will be reopened. The remaining ones >> will be flagged as `has-consensus`. >> >> There are a lot of them, so we're not going to do this until after the >> Chicago meeting (at the earliest) to give people a chance to discuss on = the >> list as well as in the meeting. >> >> See > ING.md#resolving-issues> for a reminder about the process we're using >> here. Even when we have consensus, we can reopen an issue if new >> information emerges (and that can take a variety of forms). >> >> This list is also available at > e-drafts/issues?utf8=3D=E2=9C=93&q=3Dis%3Aissue%20is%3Aclosed%20label%3A >> design%20-label%3Ahas-consensus >> >> >. >> >> Cheers, >> >> ## Transport >> >> #35 - Starting packet number >> #40 - Variable-length fields >> #49 - Transport parameter advertisements >> #50 - Updating Transport parameters >> #51 - QUIC version number scheme >> #52 - Source address validation >> #55 - What can change in a different version >> #56 - Extending flags >> #57 - Advice on STOP_WAITING >> #59 - Define ICSL parameter >> #62 - Finding frame lengths >> #63 - ACK retransmission >> #64 - Path MTU Discovery >> #66 - Remove STOP_WAITING >> #67 - Picking packet number length >> #69 - Minimum packet size >> #70 - Move ACK/STOP_WAITING into the packet header >> #74 - Application-defined error codes >> #104 - Priority in QUIC Transport >> #108 - Maximum stream number >> #112 - Greasing version negotiation >> #114 - STREAM retransmission priority >> #116 - COPTs as empty transport parameters >> #117 - SCUP >> #118 - Source Address Token encoding >> #119 - Server-proposed connection ID >> #124 - Alt-Svc quic version hint >> #126 - Separate transport parameters for 0-RTT >> #133 - Connection ID in version negotiation >> #135 - DoS using Version Negotiation Packets >> #136 - First client packet size >> #139 - Minimum MTU >> #147 - Reflection Attack Resistance >> #148 - QUIC packet header complexity >> #157 - Updated information in retransmitted frames >> #158 - Padding between frames >> #159 - Time format >> #162 - RST_STREAM and flow control >> #163 - RST_STREAM and connection-level flow control >> #164 - Padding handshake packets >> #168 - Ordering of ACK Frame fields >> #174 - Stream Reservation >> #181 - Remove SETTINGS[_ACK] >> #185 - Reliable identification of the initial packet for a connection >> #201 - Do streams 0 and 1 count towards MSPC? >> #204 - Streams not contributing to connection-level flow control >> #243 - AEAD Associated Data >> #244 - Need a NONCE in version negotiation packets >> #262 - Don't encrypt client handshake with 1-RTT keys >> #285 - Policing packet number size >> #286 - Outstanding packets and packet number size >> #289 - Avoid using Public Reset where possible >> #291 - ACKing ACK >> #292 - Does any portion of the QUIC framing require 4 byte alignment? >> #293 - Does the connection id need to be in a consistent location? >> #295 - Connection ID on a version negotiation packet >> #308 - "retransmitting" old timestamps in ACK frames >> #323 - Smaller packet number representations >> #340 - Scale flow control offsets >> #341 - What does it mean to acknowledge something? >> #347 - Clarify meaning/definition of GOAWAY >> #349 - When should server-chosen connection IDs be sent and how are they >> indicated? >> #352 - Does GOAWAY need an error code >> >> >> ## Recovery >> >> #63 - ACK retransmission >> #169 - Response to lost handshake packets >> >> >> ## TLS >> >> #12 - Decouple QUIC version and ALPN >> #25 - Key update forward secrecy >> #26 - Which bit can KEY_PHASE use? >> #27 - Fix KEY_PHASE for early data >> #34 - ACK rules and packet protection >> #87 - QUIC advertisement description >> #97 - Version Negotiation + TLS >> #226 - Authenticating public parts of the packet header >> #243 - AEAD Associated Data >> #262 - Don't encrypt client handshake with 1-RTT keys >> #272 - Signaling TLS handshake failure >> >> >> ## HTTP >> >> 75 - SETTING syncronization >> 87 - QUIC advertisement description >> 95 - CONNECT >> 104 - Priority in QUIC Transport >> 124 - Alt-Svc quic version hint >> 127 - Frame header reserved bits >> 154 - HTTP Stream ID Size >> 173 - Size of HTTP Header Sequence Numbers >> 176 - RST_STREAM breaks HPACK >> 181 - Remove SETTINGS[_ACK] >> 202 - HTTP: Why are we defining CONNECT? >> 204 - Streams not contributing to connection-level flow control >> 229 - Use a quic=3D parameter for Alt-Svc rather than collide with exist= ing >> use of v=3D >> 242 - HTTP extension mechanisms >> 297 - Remove the quic parameter from Alt-Svc >> 364 - Mid-frame close >> >> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> > --94eb2c13ce387b82d5054d1292c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Replying to myself...
I have gone through all the issu= es and I believe that aside from the issues
listed above and the = emails I just sent to the list, I believe we can provisionally
cl= ose the issues you list.

-Ekr

=

On Thu, Apr 13, 2= 017 at 11:09 AM, Eric Rescorla <ekr@rtfm.com> wrote:
I have reviewed all the transpo= rt issues. I believe that nearly all
of them can be marked closed= , modulo the ones noted below. I am still
reviewing the issues fo= r the other drafts, but there is a lot of
duplication, so I expec= t to get to them today.


#51 = =C2=A0- QUIC version number scheme

I had re= quested that this document the existing Google version numbers,
b= ut this does not seem to have happened, and it should.

=

#55 =C2=A0- What can change in a different versio= n

I am fine with closing this for now, but = it is tied directly to the
question of packet format and in parti= cular how to handle packet
number and connection ID, so it will n= eed revision if we decide
to adopt an encrypted packet number/con= n-id proposal (which I
intend to make in Paris if not before).


#158 - Padding between frames

As I noted previously, it seems like it woul= d be be better to make
padding a security layer function. We coul= d then use the TLS-style
padding (or whatever). I'm not sure = we have consensus on this point
yet.


#181 - Remove SETTINGS[_ACK]

<= div>Why don't we put the SETTINGS frame in a TLS extension. That would<= /div>
remove a bunch of race conditions. I have filed an issue for this= .


-Ekr


On Fri, Mar 17,= 2017 at 2:22 AM, Mark Nottingham <mnot@mnot.net> wrote:
Everyone,

The -02 drafts incorporate the proposed resolutions to a number of issues t= hat have been discussed.

Those issues are listed below. Please have a look through them, and if ther= e are any resolutions that you feel need more discussion, please bring it u= p, either here on the mailing list or in the issue itself.

Issues that we need to discuss more will be reopened. The remaining ones wi= ll be flagged as `has-consensus`.

There are a lot of them, so we're not going to do this until after the = Chicago meeting (at the earliest) to give people a chance to discuss on the= list as well as in the meeting.

See <https://gi= thub.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#resolving= -issues> for a reminder about the process we're using here. Even= when we have consensus, we can reopen an issue if new information emerges = (and that can take a variety of forms).

This list is also available at <http= s://github.com/quicwg/base-drafts/issues?utf8=3D=E2=9C=93&q=3Dis%3= Aissue%20is%3Aclosed%20label%3Adesign%20-label%3Ahas-consensus>.

Cheers,

## Transport

#35=C2=A0 - Starting packet number
#40=C2=A0 - Variable-length fields
#49=C2=A0 - Transport parameter advertisements
#50=C2=A0 - Updating Transport parameters
#51=C2=A0 - QUIC version number scheme
#52=C2=A0 - Source address validation
#55=C2=A0 - What can change in a different version
#56=C2=A0 - Extending flags
#57=C2=A0 - Advice on STOP_WAITING
#59=C2=A0 - Define ICSL parameter
#62=C2=A0 - Finding frame lengths
#63=C2=A0 - ACK retransmission
#64=C2=A0 - Path MTU Discovery
#66=C2=A0 - Remove STOP_WAITING
#67=C2=A0 - Picking packet number length
#69=C2=A0 - Minimum packet size
#70=C2=A0 - Move ACK/STOP_WAITING into the packet header
#74=C2=A0 - Application-defined error codes
#104 - Priority in QUIC Transport
#108 - Maximum stream number
#112 - Greasing version negotiation
#114 - STREAM retransmission priority
#116 - COPTs as empty transport parameters
#117 - SCUP
#118 - Source Address Token encoding
#119 - Server-proposed connection ID
#124 - Alt-Svc quic version hint
#126 - Separate transport parameters for 0-RTT
#133 - Connection ID in version negotiation
#135 - DoS using Version Negotiation Packets
#136 - First client packet size
#139 - Minimum MTU
#147 - Reflection Attack Resistance
#148 - QUIC packet header complexity
#157 - Updated information in retransmitted frames
#158 - Padding between frames
#159 - Time format
#162 - RST_STREAM and flow control
#163 - RST_STREAM and connection-level flow control
#164 - Padding handshake packets
#168 - Ordering of ACK Frame fields
#174 - Stream Reservation
#181 - Remove SETTINGS[_ACK]
#185 - Reliable identification of the initial packet for a connection
#201 - Do streams 0 and 1 count towards MSPC?
#204 - Streams not contributing to connection-level flow control
#243 - AEAD Associated Data
#244 - Need a NONCE in version negotiation packets
#262 - Don't encrypt client handshake with 1-RTT keys
#285 - Policing packet number size
#286 - Outstanding packets and packet number size
#289 - Avoid using Public Reset where possible
#291 - ACKing ACK
#292 - Does any portion of the QUIC framing require 4 byte alignment?
#293 - Does the connection id need to be in a consistent location?
#295 - Connection ID on a version negotiation packet
#308 - "retransmitting" old timestamps in ACK frames
#323 - Smaller packet number representations
#340 - Scale flow control offsets
#341 - What does it mean to acknowledge something?
#347 - Clarify meaning/definition of GOAWAY
#349 - When should server-chosen connection IDs be sent and how are they in= dicated?
#352 - Does GOAWAY need an error code


## Recovery

#63=C2=A0 - ACK retransmission
#169 - Response to lost handshake packets


## TLS

#12=C2=A0 - Decouple QUIC version and ALPN
#25=C2=A0 - Key update forward secrecy
#26=C2=A0 - Which bit can KEY_PHASE use?
#27=C2=A0 - Fix KEY_PHASE for early data
#34=C2=A0 - ACK rules and packet protection
#87=C2=A0 - QUIC advertisement description
#97=C2=A0 - Version Negotiation + TLS
#226 - Authenticating public parts of the packet header
#243 - AEAD Associated Data
#262 - Don't encrypt client handshake with 1-RTT keys
#272 - Signaling TLS handshake failure


## HTTP

75=C2=A0 - SETTING syncronization
87=C2=A0 - QUIC advertisement description
95=C2=A0 - CONNECT
104 - Priority in QUIC Transport
124 - Alt-Svc quic version hint
127 - Frame header reserved bits
154 - HTTP Stream ID Size
173 - Size of HTTP Header Sequence Numbers
176 - RST_STREAM breaks HPACK
181 - Remove SETTINGS[_ACK]
202 - HTTP: Why are we defining CONNECT?
204 - Streams not contributing to connection-level flow control
229 - Use a quic=3D parameter for Alt-Svc rather than collide with existing= use of v=3D
242 - HTTP extension mechanisms
297 - Remove the quic parameter from Alt-Svc
364 - Mid-frame close



--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/



--94eb2c13ce387b82d5054d1292c6-- From nobody Thu Apr 13 14:23:33 2017 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 B48D1129666 for ; Thu, 13 Apr 2017 14:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 y4zm8Gs_fkdt for ; Thu, 13 Apr 2017 14:23:28 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0117.outbound.protection.outlook.com [104.47.37.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7C0127843 for ; Thu, 13 Apr 2017 14:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hzrLfkhudx9NjZIjVrmGxZKXJM/WMjdIzgzVwUmTGYA=; b=Wlp01aBoNRlOkRwcGkibhGHG7O+4bfEk1g1hy0mUGSsW4wPFoade2ic3nfpGfsrl0WekqNJLXfC31PMLXP9zI7OfgLMbS1ZEloepmnlOjcH5QvTxx8j4W6+ZRCQgH5qdpvdwXeEFNF3VGMMdrBP0sfn8xs4IsXnLKx8rhpLABfc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Thu, 13 Apr 2017 21:23:25 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1019.026; Thu, 13 Apr 2017 21:23:25 +0000 From: Mike Bishop To: Eric Rescorla CC: Mark Nottingham , IETF QUIC WG , Lars Eggert Subject: RE: Consensus Call on issues closed by the -02 drafts Thread-Topic: Consensus Call on issues closed by the -02 drafts Thread-Index: AQHSnwAMVPmKxQtcPUe4u7P0iaz7iqHDxD4AgAAdH/CAABAogIAAB/eQ Date: Thu, 13 Apr 2017 21:23:24 +0000 Message-ID: References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::51f] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:f7PD9JHYdsejOv6r3jk9zAAwJptmVDZ9PJXCiKd828+gxgiTtc1o/X+HIxArkhpqFG+s4DEoaKQdRw2ENsiZg3L3bN9YNhqHUdOJNHylyM+brNkN4FHj3OQ0RxJ9NNMqLmE4ru1j35xir3/ey0tDabH7WATmPZmFKcQgvJzGAK7nn5cDAVASBis4Dc5apFIjPE9ZDzzyUij9fE8zGWYHBOJezPSEoSGYTOCNthUz1igWt1d1Pi5239/jLowv7lJmilg+iMq5r2PukMEYIRsH+YXvY108eeUYV0oez9Ts0y9YcfcNOl1nYhS8iSr4LtNU44aJ6o83Ccax4KM3Ke4N8HQ8pY/165dyn9LdN5mUQ4k= x-ms-office365-filtering-correlation-id: f43a1b08-1a2c-441e-1916-08d482b35207 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2708; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(189930954265078)(100405760836317)(219752817060721)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39450400003)(39840400002)(39400400002)(39410400002)(39850400002)(42174003)(24454002)(377454003)(5005710100001)(8990500004)(19609705001)(4326008)(6246003)(10290500002)(38730400002)(189998001)(10090500001)(561944003)(50986999)(54356999)(110136004)(76176999)(6506006)(3280700002)(102836003)(6116002)(5660300001)(790700001)(2906002)(7906003)(7736002)(74316002)(53546009)(86612001)(86362001)(93886004)(25786009)(2900100001)(54906002)(229853002)(6306002)(236005)(606005)(54896002)(9686003)(3660700001)(99286003)(77096006)(8676002)(53936002)(6436002)(122556002)(55016002)(7696004)(8936002)(33656002)(81166006)(6916009)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270849E2F5FA54B94FCDB15587020BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2017 21:23:24.9153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 21:23:32 -0000 --_000_BN6PR03MB270849E2F5FA54B94FCDB15587020BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TW1tLCBwZXJoYXBzLiAgQnV0IHJlbWVtYmVyIHlvdSBuZWVkIHRvIGFjY29tbW9kYXRlIG11bHRp cGxlIGFwcGxpY2F0aW9ucy4gIFdlIGNvdWxkIGNhcnZlIG9mZiBwYXJ0IG9mIHRoZSBzcGFjZSB0 byBiZSBhcHAtY29udHJvbGxlZCBhbmQgZWFjaCBhcHAgZGVmaW5lIGl0cyBvd24gbWVhbmluZ3Mg Zm9yIHZhbHVlcyBpbiB0aGF0IHJhbmdlLCBhcyB3ZeKAmXZlIGRvbmUgZm9yIGVycm9yIGNvZGVz LCBJIHN1cHBvc2UuDQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21d DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTMsIDIwMTcgMTo1MiBQTQ0KVG86IE1pa2UgQmlzaG9w IDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPg0KQ2M6IE1hcmsgTm90dGluZ2hhbSA8bW5v dEBtbm90Lm5ldD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IExhcnMgRWdnZXJ0IDxs YXJzQG5ldGFwcC5jb20+DQpTdWJqZWN0OiBSZTogQ29uc2Vuc3VzIENhbGwgb24gaXNzdWVzIGNs b3NlZCBieSB0aGUgLTAyIGRyYWZ0cw0KDQoNCk9uIFRodSwgQXByIDEzLCAyMDE3IGF0IDEyOjU2 IFBNLCBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KUmU6IFNFVFRJTkdTIGluIFRMUywg cmF0aGVyIHRoYW4gcHV0dGluZyBhbm90aGVyIG5ldyBleHRlbnNpb24sIHRoZSBtb3JlIGdlbmVy YWwgZm9ybSBvZiB0aGlzIHdvdWxkIGJlIHRvIHNheSB0aGF0LCBqdXN0IGFzIHRoZSBUTFMgZXh0 ZW5zaW9uIGNhcnJpZXMgYW4gb3BhcXVlIGJsb2IgdGhhdCBRVUlDIHVzZXMgZm9yIHNldHRpbmdz LCB0aGUgUVVJQyBibG9iIGFsc28gY29udGFpbnMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWVkIGJs b2IuICBSZXNlcnZlIGEgUVVJQyBzZXR0aW5ncyB2YWx1ZSBmb3Ig4oCcYXBwbGljYXRpb24tc3Bl Y2lmaWVkIGRhdGHigJ0gYW5kIGxldCBlYWNoIGFwcGxpY2F0aW9uIGRlZmluZSB0aGUgbGF5b3V0 IGFzIHRoZXkgZGVzaXJlZC4NCg0KWWVzLCB0aGlzIHdvdWxkIGJlIGEgcmVhc29uYWJsZSBkZXNp Z24uDQoNCkFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHNpbXBseSB0byBhbGxvY2F0ZSBib3RoIHNl dHMgb2Ygc2V0dGluZ3Mgb3V0IG9mIHRoZQ0Kc2FtZSBjb2RlIHBvaW50IHNwYWNlLg0KDQotRWty DQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAxMywgMjAxNyAxMToxMCBBTQ0KVG86IE1hcmsgTm90dGluZ2hhbSA8bW5v dEBtbm90Lm5ldDxtYWlsdG86bW5vdEBtbm90Lm5ldD4+DQpDYzogSUVURiBRVUlDIFdHIDxxdWlj QGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IExhcnMgRWdnZXJ0IDxsYXJzQG5ldGFw cC5jb208bWFpbHRvOmxhcnNAbmV0YXBwLmNvbT4+DQpTdWJqZWN0OiBSZTogQ29uc2Vuc3VzIENh bGwgb24gaXNzdWVzIGNsb3NlZCBieSB0aGUgLTAyIGRyYWZ0cw0KDQpJIGhhdmUgcmV2aWV3ZWQg YWxsIHRoZSB0cmFuc3BvcnQgaXNzdWVzLiBJIGJlbGlldmUgdGhhdCBuZWFybHkgYWxsDQpvZiB0 aGVtIGNhbiBiZSBtYXJrZWQgY2xvc2VkLCBtb2R1bG8gdGhlIG9uZXMgbm90ZWQgYmVsb3cuIEkg YW0gc3RpbGwNCnJldmlld2luZyB0aGUgaXNzdWVzIGZvciB0aGUgb3RoZXIgZHJhZnRzLCBidXQg dGhlcmUgaXMgYSBsb3Qgb2YNCmR1cGxpY2F0aW9uLCBzbyBJIGV4cGVjdCB0byBnZXQgdG8gdGhl bSB0b2RheS4NCg0KDQojNTEgIC0gUVVJQyB2ZXJzaW9uIG51bWJlciBzY2hlbWUNCg0KSSBoYWQg cmVxdWVzdGVkIHRoYXQgdGhpcyBkb2N1bWVudCB0aGUgZXhpc3RpbmcgR29vZ2xlIHZlcnNpb24g bnVtYmVycywNCmJ1dCB0aGlzIGRvZXMgbm90IHNlZW0gdG8gaGF2ZSBoYXBwZW5lZCwgYW5kIGl0 IHNob3VsZC4NCg0KDQojNTUgIC0gV2hhdCBjYW4gY2hhbmdlIGluIGEgZGlmZmVyZW50IHZlcnNp b24NCg0KSSBhbSBmaW5lIHdpdGggY2xvc2luZyB0aGlzIGZvciBub3csIGJ1dCBpdCBpcyB0aWVk IGRpcmVjdGx5IHRvIHRoZQ0KcXVlc3Rpb24gb2YgcGFja2V0IGZvcm1hdCBhbmQgaW4gcGFydGlj dWxhciBob3cgdG8gaGFuZGxlIHBhY2tldA0KbnVtYmVyIGFuZCBjb25uZWN0aW9uIElELCBzbyBp dCB3aWxsIG5lZWQgcmV2aXNpb24gaWYgd2UgZGVjaWRlDQp0byBhZG9wdCBhbiBlbmNyeXB0ZWQg cGFja2V0IG51bWJlci9jb25uLWlkIHByb3Bvc2FsICh3aGljaCBJDQppbnRlbmQgdG8gbWFrZSBp biBQYXJpcyBpZiBub3QgYmVmb3JlKS4NCg0KDQojMTU4IC0gUGFkZGluZyBiZXR3ZWVuIGZyYW1l cw0KDQpBcyBJIG5vdGVkIHByZXZpb3VzbHksIGl0IHNlZW1zIGxpa2UgaXQgd291bGQgYmUgYmUg YmV0dGVyIHRvIG1ha2UNCnBhZGRpbmcgYSBzZWN1cml0eSBsYXllciBmdW5jdGlvbi4gV2UgY291 bGQgdGhlbiB1c2UgdGhlIFRMUy1zdHlsZQ0KcGFkZGluZyAob3Igd2hhdGV2ZXIpLiBJJ20gbm90 IHN1cmUgd2UgaGF2ZSBjb25zZW5zdXMgb24gdGhpcyBwb2ludA0KeWV0Lg0KDQoNCiMxODEgLSBS ZW1vdmUgU0VUVElOR1NbX0FDS10NCg0KV2h5IGRvbid0IHdlIHB1dCB0aGUgU0VUVElOR1MgZnJh bWUgaW4gYSBUTFMgZXh0ZW5zaW9uLiBUaGF0IHdvdWxkDQpyZW1vdmUgYSBidW5jaCBvZiByYWNl IGNvbmRpdGlvbnMuIEkgaGF2ZSBmaWxlZCBhbiBpc3N1ZSBmb3IgdGhpcy4NCg0KaHR0cHM6Ly9n aXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvNDM2PGh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNv bSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGaXNzdWVzJTJGNDM2JmRhdGE9MDIlN0MwMSU3Q21p Y2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3Q2I1NTI3ZjQ2MzY1NzQ5YWExYjFjMDhkNDgy OTg1ZjUxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI3 NzAzODU4NzE4ODQ2NSZzZGF0YT1JV0g0cWQ4USUyQnBGdGYlMkYxMldCOUJkSk13Q3lBNEV4QkU3 Y3k4TEpHSERtSSUzRCZyZXNlcnZlZD0wPg0KDQotRWtyDQoNCg0KT24gRnJpLCBNYXIgMTcsIDIw MTcgYXQgMjoyMiBBTSwgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PG1haWx0bzptbm90 QG1ub3QubmV0Pj4gd3JvdGU6DQpFdmVyeW9uZSwNCg0KVGhlIC0wMiBkcmFmdHMgaW5jb3Jwb3Jh dGUgdGhlIHByb3Bvc2VkIHJlc29sdXRpb25zIHRvIGEgbnVtYmVyIG9mIGlzc3VlcyB0aGF0IGhh dmUgYmVlbiBkaXNjdXNzZWQuDQoNClRob3NlIGlzc3VlcyBhcmUgbGlzdGVkIGJlbG93LiBQbGVh c2UgaGF2ZSBhIGxvb2sgdGhyb3VnaCB0aGVtLCBhbmQgaWYgdGhlcmUgYXJlIGFueSByZXNvbHV0 aW9ucyB0aGF0IHlvdSBmZWVsIG5lZWQgbW9yZSBkaXNjdXNzaW9uLCBwbGVhc2UgYnJpbmcgaXQg dXAsIGVpdGhlciBoZXJlIG9uIHRoZSBtYWlsaW5nIGxpc3Qgb3IgaW4gdGhlIGlzc3VlIGl0c2Vs Zi4NCg0KSXNzdWVzIHRoYXQgd2UgbmVlZCB0byBkaXNjdXNzIG1vcmUgd2lsbCBiZSByZW9wZW5l ZC4gVGhlIHJlbWFpbmluZyBvbmVzIHdpbGwgYmUgZmxhZ2dlZCBhcyBgaGFzLWNvbnNlbnN1c2Au DQoNClRoZXJlIGFyZSBhIGxvdCBvZiB0aGVtLCBzbyB3ZSdyZSBub3QgZ29pbmcgdG8gZG8gdGhp cyB1bnRpbCBhZnRlciB0aGUgQ2hpY2FnbyBtZWV0aW5nIChhdCB0aGUgZWFybGllc3QpIHRvIGdp dmUgcGVvcGxlIGEgY2hhbmNlIHRvIGRpc2N1c3Mgb24gdGhlIGxpc3QgYXMgd2VsbCBhcyBpbiB0 aGUgbWVldGluZy4NCg0KU2VlIDxodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRz L2Jsb2IvbWFzdGVyL0NPTlRSSUJVVElORy5tZCNyZXNvbHZpbmctaXNzdWVzPGh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0 aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGYmxvYiUyRm1hc3RlciUyRkNPTlRSSUJV VElORy5tZCUyM3Jlc29sdmluZy1pc3N1ZXMmZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3Al NDBtaWNyb3NvZnQuY29tJTdDYjU1MjdmNDYzNjU3NDlhYTFiMWMwOGQ0ODI5ODVmNTElN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Mjc3MDM4NTg3MTg4NDY1 JnNkYXRhPSUyQkRQUFVWMEhjcW82SEo2cnY2VTVzYyUyRiUyQjMlMkIwWEFxNDZWZ0FZOVdXRDlJ NCUzRCZyZXNlcnZlZD0wPj4gZm9yIGEgcmVtaW5kZXIgYWJvdXQgdGhlIHByb2Nlc3Mgd2UncmUg dXNpbmcgaGVyZS4gRXZlbiB3aGVuIHdlIGhhdmUgY29uc2Vuc3VzLCB3ZSBjYW4gcmVvcGVuIGFu IGlzc3VlIGlmIG5ldyBpbmZvcm1hdGlvbiBlbWVyZ2VzIChhbmQgdGhhdCBjYW4gdGFrZSBhIHZh cmlldHkgb2YgZm9ybXMpLg0KDQpUaGlzIGxpc3QgaXMgYWxzbyBhdmFpbGFibGUgYXQgPGh0dHBz Oi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzP3V0Zjg94pyTJnE9aXMlM0Fp c3N1ZSUyMGlzJTNBY2xvc2VkJTIwbGFiZWwlM0FkZXNpZ24lMjAtbGFiZWwlM0FoYXMtY29uc2Vu c3VzPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGaXNzdWVzJTNG dXRmOCUzRCUyNUUyJTI1OUMlMjU5MyUyNnElM0RpcyUyNTNBaXNzdWUlMjUyMGlzJTI1M0FjbG9z ZWQlMjUyMGxhYmVsJTI1M0FkZXNpZ24lMjUyMC1sYWJlbCUyNTNBaGFzLWNvbnNlbnN1cyZkYXRh PTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NiNTUyN2Y0NjM2NTc0 OWFhMWIxYzA4ZDQ4Mjk4NWY1MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdD MSU3QzAlN0M2MzYyNzcwMzg1ODcxODg0NjUmc2RhdGE9NDZWM3F6SDFwMjlJJTJCN21CdFUyM09W UCUyQnN5UzJWSVRydnV1WENtUmFWbHMlM0QmcmVzZXJ2ZWQ9MD4+Lg0KDQpDaGVlcnMsDQoNCiMj IFRyYW5zcG9ydA0KDQojMzUgIC0gU3RhcnRpbmcgcGFja2V0IG51bWJlcg0KIzQwICAtIFZhcmlh YmxlLWxlbmd0aCBmaWVsZHMNCiM0OSAgLSBUcmFuc3BvcnQgcGFyYW1ldGVyIGFkdmVydGlzZW1l bnRzDQojNTAgIC0gVXBkYXRpbmcgVHJhbnNwb3J0IHBhcmFtZXRlcnMNCiM1MSAgLSBRVUlDIHZl cnNpb24gbnVtYmVyIHNjaGVtZQ0KIzUyICAtIFNvdXJjZSBhZGRyZXNzIHZhbGlkYXRpb24NCiM1 NSAgLSBXaGF0IGNhbiBjaGFuZ2UgaW4gYSBkaWZmZXJlbnQgdmVyc2lvbg0KIzU2ICAtIEV4dGVu ZGluZyBmbGFncw0KIzU3ICAtIEFkdmljZSBvbiBTVE9QX1dBSVRJTkcNCiM1OSAgLSBEZWZpbmUg SUNTTCBwYXJhbWV0ZXINCiM2MiAgLSBGaW5kaW5nIGZyYW1lIGxlbmd0aHMNCiM2MyAgLSBBQ0sg cmV0cmFuc21pc3Npb24NCiM2NCAgLSBQYXRoIE1UVSBEaXNjb3ZlcnkNCiM2NiAgLSBSZW1vdmUg U1RPUF9XQUlUSU5HDQojNjcgIC0gUGlja2luZyBwYWNrZXQgbnVtYmVyIGxlbmd0aA0KIzY5ICAt IE1pbmltdW0gcGFja2V0IHNpemUNCiM3MCAgLSBNb3ZlIEFDSy9TVE9QX1dBSVRJTkcgaW50byB0 aGUgcGFja2V0IGhlYWRlcg0KIzc0ICAtIEFwcGxpY2F0aW9uLWRlZmluZWQgZXJyb3IgY29kZXMN CiMxMDQgLSBQcmlvcml0eSBpbiBRVUlDIFRyYW5zcG9ydA0KIzEwOCAtIE1heGltdW0gc3RyZWFt IG51bWJlcg0KIzExMiAtIEdyZWFzaW5nIHZlcnNpb24gbmVnb3RpYXRpb24NCiMxMTQgLSBTVFJF QU0gcmV0cmFuc21pc3Npb24gcHJpb3JpdHkNCiMxMTYgLSBDT1BUcyBhcyBlbXB0eSB0cmFuc3Bv cnQgcGFyYW1ldGVycw0KIzExNyAtIFNDVVANCiMxMTggLSBTb3VyY2UgQWRkcmVzcyBUb2tlbiBl bmNvZGluZw0KIzExOSAtIFNlcnZlci1wcm9wb3NlZCBjb25uZWN0aW9uIElEDQojMTI0IC0gQWx0 LVN2YyBxdWljIHZlcnNpb24gaGludA0KIzEyNiAtIFNlcGFyYXRlIHRyYW5zcG9ydCBwYXJhbWV0 ZXJzIGZvciAwLVJUVA0KIzEzMyAtIENvbm5lY3Rpb24gSUQgaW4gdmVyc2lvbiBuZWdvdGlhdGlv bg0KIzEzNSAtIERvUyB1c2luZyBWZXJzaW9uIE5lZ290aWF0aW9uIFBhY2tldHMNCiMxMzYgLSBG aXJzdCBjbGllbnQgcGFja2V0IHNpemUNCiMxMzkgLSBNaW5pbXVtIE1UVQ0KIzE0NyAtIFJlZmxl Y3Rpb24gQXR0YWNrIFJlc2lzdGFuY2UNCiMxNDggLSBRVUlDIHBhY2tldCBoZWFkZXIgY29tcGxl eGl0eQ0KIzE1NyAtIFVwZGF0ZWQgaW5mb3JtYXRpb24gaW4gcmV0cmFuc21pdHRlZCBmcmFtZXMN CiMxNTggLSBQYWRkaW5nIGJldHdlZW4gZnJhbWVzDQojMTU5IC0gVGltZSBmb3JtYXQNCiMxNjIg LSBSU1RfU1RSRUFNIGFuZCBmbG93IGNvbnRyb2wNCiMxNjMgLSBSU1RfU1RSRUFNIGFuZCBjb25u ZWN0aW9uLWxldmVsIGZsb3cgY29udHJvbA0KIzE2NCAtIFBhZGRpbmcgaGFuZHNoYWtlIHBhY2tl dHMNCiMxNjggLSBPcmRlcmluZyBvZiBBQ0sgRnJhbWUgZmllbGRzDQojMTc0IC0gU3RyZWFtIFJl c2VydmF0aW9uDQojMTgxIC0gUmVtb3ZlIFNFVFRJTkdTW19BQ0tdDQojMTg1IC0gUmVsaWFibGUg aWRlbnRpZmljYXRpb24gb2YgdGhlIGluaXRpYWwgcGFja2V0IGZvciBhIGNvbm5lY3Rpb24NCiMy MDEgLSBEbyBzdHJlYW1zIDAgYW5kIDEgY291bnQgdG93YXJkcyBNU1BDPw0KIzIwNCAtIFN0cmVh bXMgbm90IGNvbnRyaWJ1dGluZyB0byBjb25uZWN0aW9uLWxldmVsIGZsb3cgY29udHJvbA0KIzI0 MyAtIEFFQUQgQXNzb2NpYXRlZCBEYXRhDQojMjQ0IC0gTmVlZCBhIE5PTkNFIGluIHZlcnNpb24g bmVnb3RpYXRpb24gcGFja2V0cw0KIzI2MiAtIERvbid0IGVuY3J5cHQgY2xpZW50IGhhbmRzaGFr ZSB3aXRoIDEtUlRUIGtleXMNCiMyODUgLSBQb2xpY2luZyBwYWNrZXQgbnVtYmVyIHNpemUNCiMy ODYgLSBPdXRzdGFuZGluZyBwYWNrZXRzIGFuZCBwYWNrZXQgbnVtYmVyIHNpemUNCiMyODkgLSBB dm9pZCB1c2luZyBQdWJsaWMgUmVzZXQgd2hlcmUgcG9zc2libGUNCiMyOTEgLSBBQ0tpbmcgQUNL DQojMjkyIC0gRG9lcyBhbnkgcG9ydGlvbiBvZiB0aGUgUVVJQyBmcmFtaW5nIHJlcXVpcmUgNCBi eXRlIGFsaWdubWVudD8NCiMyOTMgLSBEb2VzIHRoZSBjb25uZWN0aW9uIGlkIG5lZWQgdG8gYmUg aW4gYSBjb25zaXN0ZW50IGxvY2F0aW9uPw0KIzI5NSAtIENvbm5lY3Rpb24gSUQgb24gYSB2ZXJz aW9uIG5lZ290aWF0aW9uIHBhY2tldA0KIzMwOCAtICJyZXRyYW5zbWl0dGluZyIgb2xkIHRpbWVz dGFtcHMgaW4gQUNLIGZyYW1lcw0KIzMyMyAtIFNtYWxsZXIgcGFja2V0IG51bWJlciByZXByZXNl bnRhdGlvbnMNCiMzNDAgLSBTY2FsZSBmbG93IGNvbnRyb2wgb2Zmc2V0cw0KIzM0MSAtIFdoYXQg ZG9lcyBpdCBtZWFuIHRvIGFja25vd2xlZGdlIHNvbWV0aGluZz8NCiMzNDcgLSBDbGFyaWZ5IG1l YW5pbmcvZGVmaW5pdGlvbiBvZiBHT0FXQVkNCiMzNDkgLSBXaGVuIHNob3VsZCBzZXJ2ZXItY2hv c2VuIGNvbm5lY3Rpb24gSURzIGJlIHNlbnQgYW5kIGhvdyBhcmUgdGhleSBpbmRpY2F0ZWQ/DQoj MzUyIC0gRG9lcyBHT0FXQVkgbmVlZCBhbiBlcnJvciBjb2RlDQoNCg0KIyMgUmVjb3ZlcnkNCg0K IzYzICAtIEFDSyByZXRyYW5zbWlzc2lvbg0KIzE2OSAtIFJlc3BvbnNlIHRvIGxvc3QgaGFuZHNo YWtlIHBhY2tldHMNCg0KDQojIyBUTFMNCg0KIzEyICAtIERlY291cGxlIFFVSUMgdmVyc2lvbiBh bmQgQUxQTg0KIzI1ICAtIEtleSB1cGRhdGUgZm9yd2FyZCBzZWNyZWN5DQojMjYgIC0gV2hpY2gg Yml0IGNhbiBLRVlfUEhBU0UgdXNlPw0KIzI3ICAtIEZpeCBLRVlfUEhBU0UgZm9yIGVhcmx5IGRh dGENCiMzNCAgLSBBQ0sgcnVsZXMgYW5kIHBhY2tldCBwcm90ZWN0aW9uDQojODcgIC0gUVVJQyBh ZHZlcnRpc2VtZW50IGRlc2NyaXB0aW9uDQojOTcgIC0gVmVyc2lvbiBOZWdvdGlhdGlvbiArIFRM Uw0KIzIyNiAtIEF1dGhlbnRpY2F0aW5nIHB1YmxpYyBwYXJ0cyBvZiB0aGUgcGFja2V0IGhlYWRl cg0KIzI0MyAtIEFFQUQgQXNzb2NpYXRlZCBEYXRhDQojMjYyIC0gRG9uJ3QgZW5jcnlwdCBjbGll bnQgaGFuZHNoYWtlIHdpdGggMS1SVFQga2V5cw0KIzI3MiAtIFNpZ25hbGluZyBUTFMgaGFuZHNo YWtlIGZhaWx1cmUNCg0KDQojIyBIVFRQDQoNCjc1ICAtIFNFVFRJTkcgc3luY3Jvbml6YXRpb24N Cjg3ICAtIFFVSUMgYWR2ZXJ0aXNlbWVudCBkZXNjcmlwdGlvbg0KOTUgIC0gQ09OTkVDVA0KMTA0 IC0gUHJpb3JpdHkgaW4gUVVJQyBUcmFuc3BvcnQNCjEyNCAtIEFsdC1TdmMgcXVpYyB2ZXJzaW9u IGhpbnQNCjEyNyAtIEZyYW1lIGhlYWRlciByZXNlcnZlZCBiaXRzDQoxNTQgLSBIVFRQIFN0cmVh bSBJRCBTaXplDQoxNzMgLSBTaXplIG9mIEhUVFAgSGVhZGVyIFNlcXVlbmNlIE51bWJlcnMNCjE3 NiAtIFJTVF9TVFJFQU0gYnJlYWtzIEhQQUNLDQoxODEgLSBSZW1vdmUgU0VUVElOR1NbX0FDS10N CjIwMiAtIEhUVFA6IFdoeSBhcmUgd2UgZGVmaW5pbmcgQ09OTkVDVD8NCjIwNCAtIFN0cmVhbXMg bm90IGNvbnRyaWJ1dGluZyB0byBjb25uZWN0aW9uLWxldmVsIGZsb3cgY29udHJvbA0KMjI5IC0g VXNlIGEgcXVpYz0gcGFyYW1ldGVyIGZvciBBbHQtU3ZjIHJhdGhlciB0aGFuIGNvbGxpZGUgd2l0 aCBleGlzdGluZyB1c2Ugb2Ygdj0NCjI0MiAtIEhUVFAgZXh0ZW5zaW9uIG1lY2hhbmlzbXMNCjI5 NyAtIFJlbW92ZSB0aGUgcXVpYyBwYXJhbWV0ZXIgZnJvbSBBbHQtU3ZjDQozNjQgLSBNaWQtZnJh bWUgY2xvc2UNCg0KDQoNCi0tDQpNYXJrIE5vdHRpbmdoYW0gICBodHRwczovL3d3dy5tbm90Lm5l dC88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYmZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3Al NDBtaWNyb3NvZnQuY29tJTdDYjU1MjdmNDYzNjU3NDlhYTFiMWMwOGQ0ODI5ODVmNTElN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Mjc3MDM4NTg3MTg4NDY1 JnNkYXRhPUVOYzU0NFFnJTJGcVVkbjBKZGdsSzk0TGpEYnYzSjVzS3hpN3RFamg3Q0MzayUzRCZy ZXNlcnZlZD0wPg0KDQoNCg== --_000_BN6PR03MB270849E2F5FA54B94FCDB15587020BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5v c2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1tbSwgcGVyaGFwcy4mbmJzcDsgQnV0IHJlbWVtYmVyIHlv dSBuZWVkIHRvIGFjY29tbW9kYXRlIG11bHRpcGxlIGFwcGxpY2F0aW9ucy4mbmJzcDsgV2UgY291 bGQgY2FydmUgb2ZmIHBhcnQgb2YgdGhlIHNwYWNlIHRvIGJlIGFwcC1jb250cm9sbGVkIGFuZCBl YWNoIGFwcCBkZWZpbmUgaXRzIG93biBtZWFuaW5ncyBmb3IgdmFsdWVzIGluIHRoYXQgcmFuZ2Us IGFzIHdl4oCZdmUgZG9uZSBmb3IgZXJyb3IgY29kZXMsIEkgc3VwcG9zZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5j b21dIDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTMsIDIwMTcgMTo1MiBQTTxi cj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJrIE5vdHRpbmdoYW0gJmx0O21ub3RAbW5vdC5uZXQm Z3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBMYXJzIEVnZ2VydCAmbHQ7 bGFyc0BuZXRhcHAuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQ29uc2Vuc3VzIENh bGwgb24gaXNzdWVzIGNsb3NlZCBieSB0aGUgLTAyIGRyYWZ0czxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFRodSwgQXByIDEzLCAyMDE3IGF0IDEyOjU2IFBNLCBNaWtlIEJpc2hv cCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlJlOiBTRVRUSU5HUyBpbiBUTFMsIHJhdGhlciB0aGFuIHB1dHRpbmcgYW5vdGhlciBu ZXcgZXh0ZW5zaW9uLCB0aGUgbW9yZSBnZW5lcmFsIGZvcm0gb2YgdGhpcyB3b3VsZCBiZSB0byBz YXkgdGhhdCwganVzdCBhcyB0aGUgVExTIGV4dGVuc2lvbiBjYXJyaWVzIGFuIG9wYXF1ZSBibG9i IHRoYXQgUVVJQyB1c2VzDQogZm9yIHNldHRpbmdzLCB0aGUgUVVJQyBibG9iIGFsc28gY29udGFp bnMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWVkIGJsb2IuJm5ic3A7IFJlc2VydmUgYSBRVUlDIHNl dHRpbmdzIHZhbHVlIGZvciDigJxhcHBsaWNhdGlvbi1zcGVjaWZpZWQgZGF0YeKAnSBhbmQgbGV0 IGVhY2ggYXBwbGljYXRpb24gZGVmaW5lIHRoZSBsYXlvdXQgYXMgdGhleSBkZXNpcmVkLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlllcywgdGhpcyB3b3VsZCBiZSBhIHJlYXNvbmFibGUgZGVzaWduLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbiBh bHRlcm5hdGl2ZSB3b3VsZCBiZSBzaW1wbHkgdG8gYWxsb2NhdGUgYm90aCBzZXRzIG9mIHNldHRp bmdzIG91dCBvZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnNhbWUgY29kZSBwb2ludCBzcGFjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBR VUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDEzLCAyMDE3 IDExOjEwIEFNPGJyPg0KPGI+VG86PC9iPiBNYXJrIE5vdHRpbmdoYW0gJmx0OzxhIGhyZWY9Im1h aWx0bzptbm90QG1ub3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+bW5vdEBtbm90Lm5ldDwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBMYXJzIEVnZ2Vy dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAbmV0YXBwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxh cnNAbmV0YXBwLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBDb25zZW5zdXMg Q2FsbCBvbiBpc3N1ZXMgY2xvc2VkIGJ5IHRoZSAtMDIgZHJhZnRzPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZlIHJldmlld2VkIGFs bCB0aGUgdHJhbnNwb3J0IGlzc3Vlcy4gSSBiZWxpZXZlIHRoYXQgbmVhcmx5IGFsbDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vZiB0aGVtIGNh biBiZSBtYXJrZWQgY2xvc2VkLCBtb2R1bG8gdGhlIG9uZXMgbm90ZWQgYmVsb3cuIEkgYW0gc3Rp bGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ cmV2aWV3aW5nIHRoZSBpc3N1ZXMgZm9yIHRoZSBvdGhlciBkcmFmdHMsIGJ1dCB0aGVyZSBpcyBh IGxvdCBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5kdXBsaWNhdGlvbiwgc28gSSBleHBlY3QgdG8gZ2V0IHRvIHRoZW0gdG9kYXkuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ IzUxICZuYnNwOy0gUVVJQyB2ZXJzaW9uIG51bWJlciBzY2hlbWU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGFkIHJlcXVlc3RlZCB0 aGF0IHRoaXMgZG9jdW1lbnQgdGhlIGV4aXN0aW5nIEdvb2dsZSB2ZXJzaW9uIG51bWJlcnMsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJ1dCB0 aGlzIGRvZXMgbm90IHNlZW0gdG8gaGF2ZSBoYXBwZW5lZCwgYW5kIGl0IHNob3VsZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4j NTUgJm5ic3A7LSBXaGF0IGNhbiBjaGFuZ2UgaW4gYSBkaWZmZXJlbnQgdmVyc2lvbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhbSBm aW5lIHdpdGggY2xvc2luZyB0aGlzIGZvciBub3csIGJ1dCBpdCBpcyB0aWVkIGRpcmVjdGx5IHRv IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5xdWVzdGlvbiBvZiBwYWNrZXQgZm9ybWF0IGFuZCBpbiBwYXJ0aWN1bGFyIGhvdyB0byBoYW5k bGUgcGFja2V0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPm51bWJlciBhbmQgY29ubmVjdGlvbiBJRCwgc28gaXQgd2lsbCBuZWVkIHJldmlzaW9u IGlmIHdlIGRlY2lkZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj50byBhZG9wdCBhbiBlbmNyeXB0ZWQgcGFja2V0IG51bWJlci9jb25uLWlkIHBy b3Bvc2FsICh3aGljaCBJPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPmludGVuZCB0byBtYWtlIGluIFBhcmlzIGlmIG5vdCBiZWZvcmUpLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiMxNTggLSBQYWRkaW5nIGJldHdlZW4gZnJhbWVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBJIG5vdGVkIHByZXZpb3VzbHksIGl0 IHNlZW1zIGxpa2UgaXQgd291bGQgYmUgYmUgYmV0dGVyIHRvIG1ha2U8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cGFkZGluZyBhIHNlY3VyaXR5 IGxheWVyIGZ1bmN0aW9uLiBXZSBjb3VsZCB0aGVuIHVzZSB0aGUgVExTLXN0eWxlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnBhZGRpbmcgKG9y IHdoYXRldmVyKS4gSSdtIG5vdCBzdXJlIHdlIGhhdmUgY29uc2Vuc3VzIG9uIHRoaXMgcG9pbnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+eWV0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiMxODEgLSBSZW1vdmUgU0VUVElOR1NbX0FDS108bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoeSBkb24ndCB3ZSBwdXQgdGhl IFNFVFRJTkdTIGZyYW1lIGluIGEgVExTIGV4dGVuc2lvbi4gVGhhdCB3b3VsZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5yZW1vdmUgYSBidW5j aCBvZiByYWNlIGNvbmRpdGlvbnMuIEkgaGF2ZSBmaWxlZCBhbiBpc3N1ZSBmb3IgdGhpcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxh IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGaXNzdWVz JTJGNDM2JmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20l N0NiNTUyN2Y0NjM2NTc0OWFhMWIxYzA4ZDQ4Mjk4NWY1MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzcwMzg1ODcxODg0NjUmYW1wO3NkYXRhPUlXSDRx ZDhRJTJCcEZ0ZiUyRjEyV0I5QmRKTXdDeUE0RXhCRTdjeThMSkdIRG1JJTNEJmFtcDtyZXNlcnZl ZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0 cy9pc3N1ZXMvNDM2PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgTWFyIDE3LCAyMDE3IGF0IDI6MjIg QU0sIE1hcmsgTm90dGluZ2hhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1ub3RAbW5vdC5uZXQiIHRh cmdldD0iX2JsYW5rIj5tbm90QG1ub3QubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+RXZlcnlvbmUsPGJyPg0KPGJyPg0KVGhlIC0wMiBkcmFmdHMgaW5jb3Jwb3Jh dGUgdGhlIHByb3Bvc2VkIHJlc29sdXRpb25zIHRvIGEgbnVtYmVyIG9mIGlzc3VlcyB0aGF0IGhh dmUgYmVlbiBkaXNjdXNzZWQuPGJyPg0KPGJyPg0KVGhvc2UgaXNzdWVzIGFyZSBsaXN0ZWQgYmVs b3cuIFBsZWFzZSBoYXZlIGEgbG9vayB0aHJvdWdoIHRoZW0sIGFuZCBpZiB0aGVyZSBhcmUgYW55 IHJlc29sdXRpb25zIHRoYXQgeW91IGZlZWwgbmVlZCBtb3JlIGRpc2N1c3Npb24sIHBsZWFzZSBi cmluZyBpdCB1cCwgZWl0aGVyIGhlcmUgb24gdGhlIG1haWxpbmcgbGlzdCBvciBpbiB0aGUgaXNz dWUgaXRzZWxmLjxicj4NCjxicj4NCklzc3VlcyB0aGF0IHdlIG5lZWQgdG8gZGlzY3VzcyBtb3Jl IHdpbGwgYmUgcmVvcGVuZWQuIFRoZSByZW1haW5pbmcgb25lcyB3aWxsIGJlIGZsYWdnZWQgYXMg YGhhcy1jb25zZW5zdXNgLjxicj4NCjxicj4NClRoZXJlIGFyZSBhIGxvdCBvZiB0aGVtLCBzbyB3 ZSdyZSBub3QgZ29pbmcgdG8gZG8gdGhpcyB1bnRpbCBhZnRlciB0aGUgQ2hpY2FnbyBtZWV0aW5n IChhdCB0aGUgZWFybGllc3QpIHRvIGdpdmUgcGVvcGxlIGEgY2hhbmNlIHRvIGRpc2N1c3Mgb24g dGhlIGxpc3QgYXMgd2VsbCBhcyBpbiB0aGUgbWVldGluZy48YnI+DQo8YnI+DQpTZWUgJmx0Ozxh IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGYmxvYiUy Rm1hc3RlciUyRkNPTlRSSUJVVElORy5tZCUyM3Jlc29sdmluZy1pc3N1ZXMmYW1wO2RhdGE9MDIl N0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3Q2I1NTI3ZjQ2MzY1NzQ5YWEx YjFjMDhkNDgyOTg1ZjUxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdD MCU3QzYzNjI3NzAzODU4NzE4ODQ2NSZhbXA7c2RhdGE9JTJCRFBQVVYwSGNxbzZISjZydjZVNXNj JTJGJTJCMyUyQjBYQXE0NlZnQVk5V1dEOUk0JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9ibG9iL21hc3Rlci9D T05UUklCVVRJTkcubWQjcmVzb2x2aW5nLWlzc3VlczwvYT4mZ3Q7DQogZm9yIGEgcmVtaW5kZXIg YWJvdXQgdGhlIHByb2Nlc3Mgd2UncmUgdXNpbmcgaGVyZS4gRXZlbiB3aGVuIHdlIGhhdmUgY29u c2Vuc3VzLCB3ZSBjYW4gcmVvcGVuIGFuIGlzc3VlIGlmIG5ldyBpbmZvcm1hdGlvbiBlbWVyZ2Vz IChhbmQgdGhhdCBjYW4gdGFrZSBhIHZhcmlldHkgb2YgZm9ybXMpLjxicj4NCjxicj4NClRoaXMg bGlzdCBpcyBhbHNvIGF2YWlsYWJsZSBhdCAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29t JTJGcXVpY3dnJTJGYmFzZS1kcmFmdHMlMkZpc3N1ZXMlM0Z1dGY4JTNEJTI1RTIlMjU5QyUyNTkz JTI2cSUzRGlzJTI1M0Fpc3N1ZSUyNTIwaXMlMjUzQWNsb3NlZCUyNTIwbGFiZWwlMjUzQWRlc2ln biUyNTIwLWxhYmVsJTI1M0FoYXMtY29uc2Vuc3VzJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVs LmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NiNTUyN2Y0NjM2NTc0OWFhMWIxYzA4ZDQ4Mjk4NWY1 MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzcwMzg1 ODcxODg0NjUmYW1wO3NkYXRhPTQ2VjNxekgxcDI5SSUyQjdtQnRVMjNPVlAlMkJzeVMyVklUcnZ1 dVhDbVJhVmxzJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRo dWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXM/dXRmOD08c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7LHNhbnMtc2VyaWYiPuKckzwvc3Bhbj4m YW1wO3E9aXMlM0Fpc3N1ZSUyMGlzJTNBY2xvc2VkJTIwbGFiZWwlM0FkZXNpZ24lMjAtbGFiZWwl M0FoYXMtY29uc2Vuc3VzPC9hPiZndDsuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCiMj IFRyYW5zcG9ydDxicj4NCjxicj4NCiMzNSZuYnNwOyAtIFN0YXJ0aW5nIHBhY2tldCBudW1iZXI8 YnI+DQojNDAmbmJzcDsgLSBWYXJpYWJsZS1sZW5ndGggZmllbGRzPGJyPg0KIzQ5Jm5ic3A7IC0g VHJhbnNwb3J0IHBhcmFtZXRlciBhZHZlcnRpc2VtZW50czxicj4NCiM1MCZuYnNwOyAtIFVwZGF0 aW5nIFRyYW5zcG9ydCBwYXJhbWV0ZXJzPGJyPg0KIzUxJm5ic3A7IC0gUVVJQyB2ZXJzaW9uIG51 bWJlciBzY2hlbWU8YnI+DQojNTImbmJzcDsgLSBTb3VyY2UgYWRkcmVzcyB2YWxpZGF0aW9uPGJy Pg0KIzU1Jm5ic3A7IC0gV2hhdCBjYW4gY2hhbmdlIGluIGEgZGlmZmVyZW50IHZlcnNpb248YnI+ DQojNTYmbmJzcDsgLSBFeHRlbmRpbmcgZmxhZ3M8YnI+DQojNTcmbmJzcDsgLSBBZHZpY2Ugb24g U1RPUF9XQUlUSU5HPGJyPg0KIzU5Jm5ic3A7IC0gRGVmaW5lIElDU0wgcGFyYW1ldGVyPGJyPg0K IzYyJm5ic3A7IC0gRmluZGluZyBmcmFtZSBsZW5ndGhzPGJyPg0KIzYzJm5ic3A7IC0gQUNLIHJl dHJhbnNtaXNzaW9uPGJyPg0KIzY0Jm5ic3A7IC0gUGF0aCBNVFUgRGlzY292ZXJ5PGJyPg0KIzY2 Jm5ic3A7IC0gUmVtb3ZlIFNUT1BfV0FJVElORzxicj4NCiM2NyZuYnNwOyAtIFBpY2tpbmcgcGFj a2V0IG51bWJlciBsZW5ndGg8YnI+DQojNjkmbmJzcDsgLSBNaW5pbXVtIHBhY2tldCBzaXplPGJy Pg0KIzcwJm5ic3A7IC0gTW92ZSBBQ0svU1RPUF9XQUlUSU5HIGludG8gdGhlIHBhY2tldCBoZWFk ZXI8YnI+DQojNzQmbmJzcDsgLSBBcHBsaWNhdGlvbi1kZWZpbmVkIGVycm9yIGNvZGVzPGJyPg0K IzEwNCAtIFByaW9yaXR5IGluIFFVSUMgVHJhbnNwb3J0PGJyPg0KIzEwOCAtIE1heGltdW0gc3Ry ZWFtIG51bWJlcjxicj4NCiMxMTIgLSBHcmVhc2luZyB2ZXJzaW9uIG5lZ290aWF0aW9uPGJyPg0K IzExNCAtIFNUUkVBTSByZXRyYW5zbWlzc2lvbiBwcmlvcml0eTxicj4NCiMxMTYgLSBDT1BUcyBh cyBlbXB0eSB0cmFuc3BvcnQgcGFyYW1ldGVyczxicj4NCiMxMTcgLSBTQ1VQPGJyPg0KIzExOCAt IFNvdXJjZSBBZGRyZXNzIFRva2VuIGVuY29kaW5nPGJyPg0KIzExOSAtIFNlcnZlci1wcm9wb3Nl ZCBjb25uZWN0aW9uIElEPGJyPg0KIzEyNCAtIEFsdC1TdmMgcXVpYyB2ZXJzaW9uIGhpbnQ8YnI+ DQojMTI2IC0gU2VwYXJhdGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMgZm9yIDAtUlRUPGJyPg0KIzEz MyAtIENvbm5lY3Rpb24gSUQgaW4gdmVyc2lvbiBuZWdvdGlhdGlvbjxicj4NCiMxMzUgLSBEb1Mg dXNpbmcgVmVyc2lvbiBOZWdvdGlhdGlvbiBQYWNrZXRzPGJyPg0KIzEzNiAtIEZpcnN0IGNsaWVu dCBwYWNrZXQgc2l6ZTxicj4NCiMxMzkgLSBNaW5pbXVtIE1UVTxicj4NCiMxNDcgLSBSZWZsZWN0 aW9uIEF0dGFjayBSZXNpc3RhbmNlPGJyPg0KIzE0OCAtIFFVSUMgcGFja2V0IGhlYWRlciBjb21w bGV4aXR5PGJyPg0KIzE1NyAtIFVwZGF0ZWQgaW5mb3JtYXRpb24gaW4gcmV0cmFuc21pdHRlZCBm cmFtZXM8YnI+DQojMTU4IC0gUGFkZGluZyBiZXR3ZWVuIGZyYW1lczxicj4NCiMxNTkgLSBUaW1l IGZvcm1hdDxicj4NCiMxNjIgLSBSU1RfU1RSRUFNIGFuZCBmbG93IGNvbnRyb2w8YnI+DQojMTYz IC0gUlNUX1NUUkVBTSBhbmQgY29ubmVjdGlvbi1sZXZlbCBmbG93IGNvbnRyb2w8YnI+DQojMTY0 IC0gUGFkZGluZyBoYW5kc2hha2UgcGFja2V0czxicj4NCiMxNjggLSBPcmRlcmluZyBvZiBBQ0sg RnJhbWUgZmllbGRzPGJyPg0KIzE3NCAtIFN0cmVhbSBSZXNlcnZhdGlvbjxicj4NCiMxODEgLSBS ZW1vdmUgU0VUVElOR1NbX0FDS108YnI+DQojMTg1IC0gUmVsaWFibGUgaWRlbnRpZmljYXRpb24g b2YgdGhlIGluaXRpYWwgcGFja2V0IGZvciBhIGNvbm5lY3Rpb248YnI+DQojMjAxIC0gRG8gc3Ry ZWFtcyAwIGFuZCAxIGNvdW50IHRvd2FyZHMgTVNQQz88YnI+DQojMjA0IC0gU3RyZWFtcyBub3Qg Y29udHJpYnV0aW5nIHRvIGNvbm5lY3Rpb24tbGV2ZWwgZmxvdyBjb250cm9sPGJyPg0KIzI0MyAt IEFFQUQgQXNzb2NpYXRlZCBEYXRhPGJyPg0KIzI0NCAtIE5lZWQgYSBOT05DRSBpbiB2ZXJzaW9u IG5lZ290aWF0aW9uIHBhY2tldHM8YnI+DQojMjYyIC0gRG9uJ3QgZW5jcnlwdCBjbGllbnQgaGFu ZHNoYWtlIHdpdGggMS1SVFQga2V5czxicj4NCiMyODUgLSBQb2xpY2luZyBwYWNrZXQgbnVtYmVy IHNpemU8YnI+DQojMjg2IC0gT3V0c3RhbmRpbmcgcGFja2V0cyBhbmQgcGFja2V0IG51bWJlciBz aXplPGJyPg0KIzI4OSAtIEF2b2lkIHVzaW5nIFB1YmxpYyBSZXNldCB3aGVyZSBwb3NzaWJsZTxi cj4NCiMyOTEgLSBBQ0tpbmcgQUNLPGJyPg0KIzI5MiAtIERvZXMgYW55IHBvcnRpb24gb2YgdGhl IFFVSUMgZnJhbWluZyByZXF1aXJlIDQgYnl0ZSBhbGlnbm1lbnQ/PGJyPg0KIzI5MyAtIERvZXMg dGhlIGNvbm5lY3Rpb24gaWQgbmVlZCB0byBiZSBpbiBhIGNvbnNpc3RlbnQgbG9jYXRpb24/PGJy Pg0KIzI5NSAtIENvbm5lY3Rpb24gSUQgb24gYSB2ZXJzaW9uIG5lZ290aWF0aW9uIHBhY2tldDxi cj4NCiMzMDggLSAmcXVvdDtyZXRyYW5zbWl0dGluZyZxdW90OyBvbGQgdGltZXN0YW1wcyBpbiBB Q0sgZnJhbWVzPGJyPg0KIzMyMyAtIFNtYWxsZXIgcGFja2V0IG51bWJlciByZXByZXNlbnRhdGlv bnM8YnI+DQojMzQwIC0gU2NhbGUgZmxvdyBjb250cm9sIG9mZnNldHM8YnI+DQojMzQxIC0gV2hh dCBkb2VzIGl0IG1lYW4gdG8gYWNrbm93bGVkZ2Ugc29tZXRoaW5nPzxicj4NCiMzNDcgLSBDbGFy aWZ5IG1lYW5pbmcvZGVmaW5pdGlvbiBvZiBHT0FXQVk8YnI+DQojMzQ5IC0gV2hlbiBzaG91bGQg c2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElEcyBiZSBzZW50IGFuZCBob3cgYXJlIHRoZXkgaW5k aWNhdGVkPzxicj4NCiMzNTIgLSBEb2VzIEdPQVdBWSBuZWVkIGFuIGVycm9yIGNvZGU8YnI+DQo8 YnI+DQo8YnI+DQojIyBSZWNvdmVyeTxicj4NCjxicj4NCiM2MyZuYnNwOyAtIEFDSyByZXRyYW5z bWlzc2lvbjxicj4NCiMxNjkgLSBSZXNwb25zZSB0byBsb3N0IGhhbmRzaGFrZSBwYWNrZXRzPGJy Pg0KPGJyPg0KPGJyPg0KIyMgVExTPGJyPg0KPGJyPg0KIzEyJm5ic3A7IC0gRGVjb3VwbGUgUVVJ QyB2ZXJzaW9uIGFuZCBBTFBOPGJyPg0KIzI1Jm5ic3A7IC0gS2V5IHVwZGF0ZSBmb3J3YXJkIHNl Y3JlY3k8YnI+DQojMjYmbmJzcDsgLSBXaGljaCBiaXQgY2FuIEtFWV9QSEFTRSB1c2U/PGJyPg0K IzI3Jm5ic3A7IC0gRml4IEtFWV9QSEFTRSBmb3IgZWFybHkgZGF0YTxicj4NCiMzNCZuYnNwOyAt IEFDSyBydWxlcyBhbmQgcGFja2V0IHByb3RlY3Rpb248YnI+DQojODcmbmJzcDsgLSBRVUlDIGFk dmVydGlzZW1lbnQgZGVzY3JpcHRpb248YnI+DQojOTcmbmJzcDsgLSBWZXJzaW9uIE5lZ290aWF0 aW9uICYjNDM7IFRMUzxicj4NCiMyMjYgLSBBdXRoZW50aWNhdGluZyBwdWJsaWMgcGFydHMgb2Yg dGhlIHBhY2tldCBoZWFkZXI8YnI+DQojMjQzIC0gQUVBRCBBc3NvY2lhdGVkIERhdGE8YnI+DQoj MjYyIC0gRG9uJ3QgZW5jcnlwdCBjbGllbnQgaGFuZHNoYWtlIHdpdGggMS1SVFQga2V5czxicj4N CiMyNzIgLSBTaWduYWxpbmcgVExTIGhhbmRzaGFrZSBmYWlsdXJlPGJyPg0KPGJyPg0KPGJyPg0K IyMgSFRUUDxicj4NCjxicj4NCjc1Jm5ic3A7IC0gU0VUVElORyBzeW5jcm9uaXphdGlvbjxicj4N Cjg3Jm5ic3A7IC0gUVVJQyBhZHZlcnRpc2VtZW50IGRlc2NyaXB0aW9uPGJyPg0KOTUmbmJzcDsg LSBDT05ORUNUPGJyPg0KMTA0IC0gUHJpb3JpdHkgaW4gUVVJQyBUcmFuc3BvcnQ8YnI+DQoxMjQg LSBBbHQtU3ZjIHF1aWMgdmVyc2lvbiBoaW50PGJyPg0KMTI3IC0gRnJhbWUgaGVhZGVyIHJlc2Vy dmVkIGJpdHM8YnI+DQoxNTQgLSBIVFRQIFN0cmVhbSBJRCBTaXplPGJyPg0KMTczIC0gU2l6ZSBv ZiBIVFRQIEhlYWRlciBTZXF1ZW5jZSBOdW1iZXJzPGJyPg0KMTc2IC0gUlNUX1NUUkVBTSBicmVh a3MgSFBBQ0s8YnI+DQoxODEgLSBSZW1vdmUgU0VUVElOR1NbX0FDS108YnI+DQoyMDIgLSBIVFRQ OiBXaHkgYXJlIHdlIGRlZmluaW5nIENPTk5FQ1Q/PGJyPg0KMjA0IC0gU3RyZWFtcyBub3QgY29u dHJpYnV0aW5nIHRvIGNvbm5lY3Rpb24tbGV2ZWwgZmxvdyBjb250cm9sPGJyPg0KMjI5IC0gVXNl IGEgcXVpYz0gcGFyYW1ldGVyIGZvciBBbHQtU3ZjIHJhdGhlciB0aGFuIGNvbGxpZGUgd2l0aCBl eGlzdGluZyB1c2Ugb2Ygdj08YnI+DQoyNDIgLSBIVFRQIGV4dGVuc2lvbiBtZWNoYW5pc21zPGJy Pg0KMjk3IC0gUmVtb3ZlIHRoZSBxdWljIHBhcmFtZXRlciBmcm9tIEFsdC1TdmM8YnI+DQozNjQg LSBNaWQtZnJhbWUgY2xvc2U8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLTxicj4NCk1hcmsgTm90 dGluZ2hhbSZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5tbm90Lm5ldCUyRiZhbXA7 ZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDYjU1MjdmNDYz NjU3NDlhYTFiMWMwOGQ0ODI5ODVmNTElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2Mjc3MDM4NTg3MTg4NDY1JmFtcDtzZGF0YT1FTmM1NDRRZyUyRnFVZG4w SmRnbEs5NExqRGJ2M0o1c0t4aTd0RWpoN0NDM2slM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5tbm90Lm5ldC88L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB270849E2F5FA54B94FCDB15587020BN6PR03MB2708namp_-- From nobody Thu Apr 13 14:24:50 2017 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 4CFCE1200DF for ; Thu, 13 Apr 2017 14:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 jmQIbajfVPsN for ; Thu, 13 Apr 2017 14:24:45 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 099AA127843 for ; Thu, 13 Apr 2017 14:24:44 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id i124so16290387ybc.3 for ; Thu, 13 Apr 2017 14:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m/2g/nsBPfnheOP4tBRhhoWTjM6JDKkc7riUV85USBg=; b=MmRxTcylKA0Af9mns3VZT0sJJQgsJsNC61/kheg9Ui5Q1s3TwGG/fxlDlGTcxlv5SF svWvc/lqdLK8kb6Pt4VLumMY8K3WLKN981Khhk9wXUgRRIrDb6s8N3jbLAghZ+rnXBXH v0aSgmp5m5ftPnwnV30Xb55ycnFcxoCt3F2xY4NUU4prCgEE6jNMVOvmlHO/k64fGNrw zxK0Uc+nLqX3q/8l7srWL6Ers531tpW71mCgtOylEOZ/nXW7XNjYu80AdFGKBwN0qoLO jeZUMLvBOFz3Gv/nzR9Q1kGYV0kHkydZ5OSC0AABxzyzkc5Erdm2pOoBZJ1f2fgDXChL Q2MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m/2g/nsBPfnheOP4tBRhhoWTjM6JDKkc7riUV85USBg=; b=I61VXySM7ySXCHhRzePQI/1ZBy1Eq1HuDaxGvqv3lk/EJIvXzvePCISl3G/wsGlFu0 cNiwVU5SvKaPTMi1w1qpV+KZP7Rgw4fkxeI6S5KsMz55Ww2v70SxS2vRyrbK+kSC23ll yH+ekclG6B8SJJRGZw0MGDZxvkKVyp2C7qrXAHTn5uIzispIfqhAUcrpLsUGlxnWkPyb kzDwBaGuLNa0osjAHQlyJKg0WHbmV8a09t9nWU8QX/uSb8WwMgsxT9cB2tk9N6JG713I i3END6JjsP0WwvAfBUZ7kkXvFoCjtQLGt9hDqRE2dIhqJB76ICQiUAYqVfrQgvqZ24kD WfOA== X-Gm-Message-State: AN3rC/7/O3oqo7DtprYrurA1Q3GrJApm/lHB/ZYooF05pKY1aY3eKBJ7 Y24XZAs03H5cQKZ55MEFhMQsWbiVDA== X-Received: by 10.37.81.129 with SMTP id f123mr3999678ybb.161.1492118683149; Thu, 13 Apr 2017 14:24:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 13 Apr 2017 14:24:02 -0700 (PDT) In-Reply-To: References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> From: Eric Rescorla Date: Thu, 13 Apr 2017 14:24:02 -0700 Message-ID: Subject: Re: Consensus Call on issues closed by the -02 drafts To: Mike Bishop Cc: Mark Nottingham , IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary=001a113db1f412df4e054d12f434 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 21:24:48 -0000 --001a113db1f412df4e054d12f434 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 13, 2017 at 2:23 PM, Mike Bishop wrote: > Mmm, perhaps. But remember you need to accommodate multiple > applications. We could carve off part of the space to be app-controlled > and each app define its own meanings for values in that range, as we=E2= =80=99ve > done for error codes, I suppose. > Correct. That's what I had in mind, but I'm not picky about the encoding. -Ekr > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Thursday, April 13, 2017 1:52 PM > *To:* Mike Bishop > *Cc:* Mark Nottingham ; IETF QUIC WG ; Lars > Eggert > > *Subject:* Re: Consensus Call on issues closed by the -02 drafts > > > > > > On Thu, Apr 13, 2017 at 12:56 PM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > > Re: SETTINGS in TLS, rather than putting another new extension, the more > general form of this would be to say that, just as the TLS extension > carries an opaque blob that QUIC uses for settings, the QUIC blob also > contains an application-specified blob. Reserve a QUIC settings value fo= r > =E2=80=9Capplication-specified data=E2=80=9D and let each application def= ine the layout as > they desired. > > > > Yes, this would be a reasonable design. > > > > An alternative would be simply to allocate both sets of settings out of t= he > > same code point space. > > > > -Ekr > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Thursday, April 13, 2017 11:10 AM > *To:* Mark Nottingham > *Cc:* IETF QUIC WG ; Lars Eggert > *Subject:* Re: Consensus Call on issues closed by the -02 drafts > > > > I have reviewed all the transport issues. I believe that nearly all > > of them can be marked closed, modulo the ones noted below. I am still > > reviewing the issues for the other drafts, but there is a lot of > > duplication, so I expect to get to them today. > > > > > > #51 - QUIC version number scheme > > > > I had requested that this document the existing Google version numbers, > > but this does not seem to have happened, and it should. > > > > > > #55 - What can change in a different version > > > > I am fine with closing this for now, but it is tied directly to the > > question of packet format and in particular how to handle packet > > number and connection ID, so it will need revision if we decide > > to adopt an encrypted packet number/conn-id proposal (which I > > intend to make in Paris if not before). > > > > > > #158 - Padding between frames > > > > As I noted previously, it seems like it would be be better to make > > padding a security layer function. We could then use the TLS-style > > padding (or whatever). I'm not sure we have consensus on this point > > yet. > > > > > > #181 - Remove SETTINGS[_ACK] > > > > Why don't we put the SETTINGS frame in a TLS extension. That would > > remove a bunch of race conditions. I have filed an issue for this. > > > > https://github.com/quicwg/base-drafts/issues/436 > > > > > -Ekr > > > > > > On Fri, Mar 17, 2017 at 2:22 AM, Mark Nottingham wrote: > > Everyone, > > The -02 drafts incorporate the proposed resolutions to a number of issues > that have been discussed. > > Those issues are listed below. Please have a look through them, and if > there are any resolutions that you feel need more discussion, please brin= g > it up, either here on the mailing list or in the issue itself. > > Issues that we need to discuss more will be reopened. The remaining ones > will be flagged as `has-consensus`. > > There are a lot of them, so we're not going to do this until after the > Chicago meeting (at the earliest) to give people a chance to discuss on t= he > list as well as in the meeting. > > See CONTRIBUTING.md#resolving-issues > > > for a reminder about the process we're using here. Even when we have > consensus, we can reopen an issue if new information emerges (and that ca= n > take a variety of forms). > > This list is also available at base-drafts/issues?utf8=3D=E2=9C=93&q=3Dis%3Aissue%20is%3Aclosed% > 20label%3Adesign%20-label%3Ahas-consensus > > >. > > Cheers, > > ## Transport > > #35 - Starting packet number > #40 - Variable-length fields > #49 - Transport parameter advertisements > #50 - Updating Transport parameters > #51 - QUIC version number scheme > #52 - Source address validation > #55 - What can change in a different version > #56 - Extending flags > #57 - Advice on STOP_WAITING > #59 - Define ICSL parameter > #62 - Finding frame lengths > #63 - ACK retransmission > #64 - Path MTU Discovery > #66 - Remove STOP_WAITING > #67 - Picking packet number length > #69 - Minimum packet size > #70 - Move ACK/STOP_WAITING into the packet header > #74 - Application-defined error codes > #104 - Priority in QUIC Transport > #108 - Maximum stream number > #112 - Greasing version negotiation > #114 - STREAM retransmission priority > #116 - COPTs as empty transport parameters > #117 - SCUP > #118 - Source Address Token encoding > #119 - Server-proposed connection ID > #124 - Alt-Svc quic version hint > #126 - Separate transport parameters for 0-RTT > #133 - Connection ID in version negotiation > #135 - DoS using Version Negotiation Packets > #136 - First client packet size > #139 - Minimum MTU > #147 - Reflection Attack Resistance > #148 - QUIC packet header complexity > #157 - Updated information in retransmitted frames > #158 - Padding between frames > #159 - Time format > #162 - RST_STREAM and flow control > #163 - RST_STREAM and connection-level flow control > #164 - Padding handshake packets > #168 - Ordering of ACK Frame fields > #174 - Stream Reservation > #181 - Remove SETTINGS[_ACK] > #185 - Reliable identification of the initial packet for a connection > #201 - Do streams 0 and 1 count towards MSPC? > #204 - Streams not contributing to connection-level flow control > #243 - AEAD Associated Data > #244 - Need a NONCE in version negotiation packets > #262 - Don't encrypt client handshake with 1-RTT keys > #285 - Policing packet number size > #286 - Outstanding packets and packet number size > #289 - Avoid using Public Reset where possible > #291 - ACKing ACK > #292 - Does any portion of the QUIC framing require 4 byte alignment? > #293 - Does the connection id need to be in a consistent location? > #295 - Connection ID on a version negotiation packet > #308 - "retransmitting" old timestamps in ACK frames > #323 - Smaller packet number representations > #340 - Scale flow control offsets > #341 - What does it mean to acknowledge something? > #347 - Clarify meaning/definition of GOAWAY > #349 - When should server-chosen connection IDs be sent and how are they > indicated? > #352 - Does GOAWAY need an error code > > > ## Recovery > > #63 - ACK retransmission > #169 - Response to lost handshake packets > > > ## TLS > > #12 - Decouple QUIC version and ALPN > #25 - Key update forward secrecy > #26 - Which bit can KEY_PHASE use? > #27 - Fix KEY_PHASE for early data > #34 - ACK rules and packet protection > #87 - QUIC advertisement description > #97 - Version Negotiation + TLS > #226 - Authenticating public parts of the packet header > #243 - AEAD Associated Data > #262 - Don't encrypt client handshake with 1-RTT keys > #272 - Signaling TLS handshake failure > > > ## HTTP > > 75 - SETTING syncronization > 87 - QUIC advertisement description > 95 - CONNECT > 104 - Priority in QUIC Transport > 124 - Alt-Svc quic version hint > 127 - Frame header reserved bits > 154 - HTTP Stream ID Size > 173 - Size of HTTP Header Sequence Numbers > 176 - RST_STREAM breaks HPACK > 181 - Remove SETTINGS[_ACK] > 202 - HTTP: Why are we defining CONNECT? > 204 - Streams not contributing to connection-level flow control > 229 - Use a quic=3D parameter for Alt-Svc rather than collide with existi= ng > use of v=3D > 242 - HTTP extension mechanisms > 297 - Remove the quic parameter from Alt-Svc > 364 - Mid-frame close > > > > -- > Mark Nottingham https://www.mnot.net/ > > > > > > --001a113db1f412df4e054d12f434 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Apr 13, 2017 at 2:23 PM, Mike Bishop <Michael.Bishop@m= icrosoft.com> wrote:

Mmm, perhaps.=C2=A0 But remember you need to accommo= date multiple applications.=C2=A0 We could carve off part of the space to b= e app-controlled and each app define its own meanings for values in that ra= nge, as we=E2=80=99ve done for error codes, I suppose.


Correct.

That's wh= at I had in mind, but I'm not picky about the encoding.

<= /div>
-Ekr
=C2=A0

=C2=A0

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Thursday, April 13, 2017 1:52 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Mark Nottingham <mnot@mnot.net>; IETF QUIC WG <quic@ietf.org>; Lars Eggert <lars@netapp.com>


Subject: Re: Consensus Call on issues closed by the -02 drafts

=C2=A0

=C2=A0

On Thu, Apr 13, 2017 at 12:56 PM, Mike Bishop <Michael.Bis= hop@microsoft.com> wrote:

Re: SETTINGS in TLS, rather than putting another new= extension, the more general form of this would be to say that, just as the= TLS extension carries an opaque blob that QUIC uses for settings, the QUIC blob also contains an application-specified blob.= =C2=A0 Reserve a QUIC settings value for =E2=80=9Capplication-specified dat= a=E2=80=9D and let each application define the layout as they desired.

=C2=A0

Yes, this would be a reasonable design.

=C2=A0

An alternative would be simply to allocate both sets= of settings out of the

same code point space.

=C2=A0

-Ekr

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Thursday, April 13, 2017 11:10 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: IETF QUIC WG <quic@ietf.org>; Lars Eggert <lars@netapp.com>
Subject: Re: Consensus Call on issues closed by the -02 drafts

=C2=A0

I have reviewed all the transport issues. I believe = that nearly all

of them can be marked closed, modulo the ones noted = below. I am still

reviewing the issues for the other drafts, but there= is a lot of

duplication, so I expect to get to them today.

=C2=A0

=C2=A0

#51 =C2=A0- QUIC version number scheme=

=C2=A0

I had requested that this document the existing Goog= le version numbers,

but this does not seem to have happened, and it shou= ld.

=C2=A0

=C2=A0

#55 =C2=A0- What can change in a different version

=C2=A0

I am fine with closing this for now, but it is tied = directly to the

question of packet format and in particular how to h= andle packet

number and connection ID, so it will need revision i= f we decide

to adopt an encrypted packet number/conn-id proposal= (which I

intend to make in Paris if not before).

=C2=A0

=C2=A0

#158 - Padding between frames

=C2=A0

As I noted previously, it seems like it would be be = better to make

padding a security layer function. We could then use= the TLS-style

padding (or whatever). I'm not sure we have cons= ensus on this point

yet.

=C2=A0

=C2=A0

#181 - Remove SETTINGS[_ACK]

=C2=A0

Why don't we put the SETTINGS frame in a TLS ext= ension. That would

remove a bunch of race conditions. I have filed an i= ssue for this.

=C2=A0

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Fri, Mar 17, 2017 at 2:22 AM, Mark Nottingham <= ;mnot@mnot.net> w= rote:

Everyone,

The -02 drafts incorporate the proposed resolutions to a number of issues t= hat have been discussed.

Those issues are listed below. Please have a look through them, and if ther= e are any resolutions that you feel need more discussion, please bring it u= p, either here on the mailing list or in the issue itself.

Issues that we need to discuss more will be reopened. The remaining ones wi= ll be flagged as `has-consensus`.

There are a lot of them, so we're not going to do this until after the = Chicago meeting (at the earliest) to give people a chance to discuss on the= list as well as in the meeting.

See <https://github.com/quic= wg/base-drafts/blob/master/CONTRIBUTING.md#resolving-issues<= /a>> for a reminder about the process we're using here. Even when we have c= onsensus, we can reopen an issue if new information emerges (and that can t= ake a variety of forms).

This list is also available at <https:/= /github.com/quicwg/base-drafts/issues?utf8=3D=E2=9C=93&q=3Dis%= 3Aissue%20is%3Aclosed%20label%3Adesign%20-label%3Ahas-consensus>.

Cheers,

## Transport

#35=C2=A0 - Starting packet number
#40=C2=A0 - Variable-length fields
#49=C2=A0 - Transport parameter advertisements
#50=C2=A0 - Updating Transport parameters
#51=C2=A0 - QUIC version number scheme
#52=C2=A0 - Source address validation
#55=C2=A0 - What can change in a different version
#56=C2=A0 - Extending flags
#57=C2=A0 - Advice on STOP_WAITING
#59=C2=A0 - Define ICSL parameter
#62=C2=A0 - Finding frame lengths
#63=C2=A0 - ACK retransmission
#64=C2=A0 - Path MTU Discovery
#66=C2=A0 - Remove STOP_WAITING
#67=C2=A0 - Picking packet number length
#69=C2=A0 - Minimum packet size
#70=C2=A0 - Move ACK/STOP_WAITING into the packet header
#74=C2=A0 - Application-defined error codes
#104 - Priority in QUIC Transport
#108 - Maximum stream number
#112 - Greasing version negotiation
#114 - STREAM retransmission priority
#116 - COPTs as empty transport parameters
#117 - SCUP
#118 - Source Address Token encoding
#119 - Server-proposed connection ID
#124 - Alt-Svc quic version hint
#126 - Separate transport parameters for 0-RTT
#133 - Connection ID in version negotiation
#135 - DoS using Version Negotiation Packets
#136 - First client packet size
#139 - Minimum MTU
#147 - Reflection Attack Resistance
#148 - QUIC packet header complexity
#157 - Updated information in retransmitted frames
#158 - Padding between frames
#159 - Time format
#162 - RST_STREAM and flow control
#163 - RST_STREAM and connection-level flow control
#164 - Padding handshake packets
#168 - Ordering of ACK Frame fields
#174 - Stream Reservation
#181 - Remove SETTINGS[_ACK]
#185 - Reliable identification of the initial packet for a connection
#201 - Do streams 0 and 1 count towards MSPC?
#204 - Streams not contributing to connection-level flow control
#243 - AEAD Associated Data
#244 - Need a NONCE in version negotiation packets
#262 - Don't encrypt client handshake with 1-RTT keys
#285 - Policing packet number size
#286 - Outstanding packets and packet number size
#289 - Avoid using Public Reset where possible
#291 - ACKing ACK
#292 - Does any portion of the QUIC framing require 4 byte alignment?
#293 - Does the connection id need to be in a consistent location?
#295 - Connection ID on a version negotiation packet
#308 - "retransmitting" old timestamps in ACK frames
#323 - Smaller packet number representations
#340 - Scale flow control offsets
#341 - What does it mean to acknowledge something?
#347 - Clarify meaning/definition of GOAWAY
#349 - When should server-chosen connection IDs be sent and how are they in= dicated?
#352 - Does GOAWAY need an error code


## Recovery

#63=C2=A0 - ACK retransmission
#169 - Response to lost handshake packets


## TLS

#12=C2=A0 - Decouple QUIC version and ALPN
#25=C2=A0 - Key update forward secrecy
#26=C2=A0 - Which bit can KEY_PHASE use?
#27=C2=A0 - Fix KEY_PHASE for early data
#34=C2=A0 - ACK rules and packet protection
#87=C2=A0 - QUIC advertisement description
#97=C2=A0 - Version Negotiation + TLS
#226 - Authenticating public parts of the packet header
#243 - AEAD Associated Data
#262 - Don't encrypt client handshake with 1-RTT keys
#272 - Signaling TLS handshake failure


## HTTP

75=C2=A0 - SETTING syncronization
87=C2=A0 - QUIC advertisement description
95=C2=A0 - CONNECT
104 - Priority in QUIC Transport
124 - Alt-Svc quic version hint
127 - Frame header reserved bits
154 - HTTP Stream ID Size
173 - Size of HTTP Header Sequence Numbers
176 - RST_STREAM breaks HPACK
181 - Remove SETTINGS[_ACK]
202 - HTTP: Why are we defining CONNECT?
204 - Streams not contributing to connection-level flow control
229 - Use a quic=3D parameter for Alt-Svc rather than collide with existing= use of v=3D
242 - HTTP extension mechanisms
297 - Remove the quic parameter from Alt-Svc
364 - Mid-frame close



--
Mark Nottingham=C2=A0 =C2=A0https= ://www.mnot.net/

=C2=A0

=C2=A0


--001a113db1f412df4e054d12f434-- From nobody Fri Apr 14 15:03:44 2017 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 09538129AE7; Fri, 14 Apr 2017 15:03:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: quic@ietf.org Subject: QUIC (quic) WG Interim Meeting: 2017-06-06 X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149220741600.15871.10826096559794605465@ietfa.amsl.com> Date: Fri, 14 Apr 2017 15:03:36 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 14 Apr 2017 22:03:36 -0000 The QUIC (quic) Working Group will hold a multi-day interim meeting. Session 1: 2017-06-06 09:30 to 17:00 Europe/Paris Session 2: 2017-06-07 09:30 to 17:00 Europe/Paris Session 3: 2017-06-08 09:30 to 17:00 Europe/Paris Meeting Location: Paris, FR Agenda: TBD Information about remote participation: Webex and Jabber; register for full details https://github.com/quicwg/wg-materials/blob/master/interim-17-06/arrangements.md From nobody Mon Apr 17 09:32:21 2017 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 949801315E5 for ; Mon, 17 Apr 2017 09:32:19 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 CH-vd3TvEw4J for ; Mon, 17 Apr 2017 09:32:17 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD6D131609 for ; Mon, 17 Apr 2017 09:32:13 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id z127so10610931pgb.1 for ; Mon, 17 Apr 2017 09:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wRJVuyeG9KideOXQbI/JBwMIhwIPtljY57ww1x7in9s=; b=d99VjQcmYUPRMxQjtbdr+YhmbjONqed+GtgkmW9m7SLtIdzxWp181EqIKywqkbLc3y VQbR0G6GV6MuSgTQbd1QeiW7jbZp+kZVSic15wzRTnEOgabiyjLDIfb9WB1qpvRjRqM+ HZ7FFifCiOSRsxsHyWQT4VkuMQUyjBtgJssA7hYxGxltJ3CiBYy6lmCnOClnUaH83hKU JtYgsq/JDExfYklIHtyhBCrOWL7mVcc2jQvTXx2ZQCbImw0lV8KH7+lMM85yhle/kYqA gllfH7ehg0O7hdKpCxzNVWYkE9hlrU8JgsiF8L0oSgL/TcRIBgnhypEe+mRuZNmsHwmK /cHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wRJVuyeG9KideOXQbI/JBwMIhwIPtljY57ww1x7in9s=; b=ryBUBpaZctGZWPshJ2+9Mv6CcLw/qPPq+w5UrtctAWnxSJLafH+daCzELR58e8WPPK FQcQmtuTkHeRoZXwAKib6lh8Fn43ECgecUTCTj+v//AYrFkocVvsoou+QzkcSLLgdizu qcJKSGkisLRgipo59FtHsEXLaKfuxQMC7AlYcNQjDuPCssQqDNumxLNk4VnMiiwLhoUV XdmWH3WAuT+znJruEtl1kkk7HimmCsAOxjw4WVAMRVS/YPKpGfUZ4LPbgd+XOJWCvpU1 U+kfS5vlgKxJaqmWHq2NFMdOwLjUOTNQfWrZ9qQVUmivsjkumoZbb8MMCLVcse0mCES5 J4ow== X-Gm-Message-State: AN3rC/47OeRaqNpeicPMQnBGmuOwhUJK9gkSUCH3wcv7BAKPMePwwgQJ XR+kX/UPtQAzCUM8INDaIpVgBcT2r/9n X-Received: by 10.84.222.139 with SMTP id x11mr17279268pls.112.1492446732947; Mon, 17 Apr 2017 09:32:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.74 with HTTP; Mon, 17 Apr 2017 09:32:12 -0700 (PDT) In-Reply-To: <0248e010b13d47a8ab8bc86f9b42970e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <0248e010b13d47a8ab8bc86f9b42970e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Jana Iyengar Date: Mon, 17 Apr 2017 09:32:12 -0700 Message-ID: Subject: Re: Revisiting 0-RTT transport parameter negotiation To: "Lubashev, Igor" Cc: Victor Vasiliev , IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c1d4c7c5d541f054d5f55f1 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 17 Apr 2017 16:32:19 -0000 --94eb2c1d4c7c5d541f054d5f55f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I like this idea, and I support it. Victor -- do you want to generate a PR for this or would you like me to? On Fri, Apr 7, 2017 at 12:57 PM, Lubashev, Igor wrote= : > Yes, this seems to work and is simple enough. It would also close issue > 425 . > > > > - Igor > > > > *From:* Victor Vasiliev [mailto:vasilvv@google.com] > *Sent:* Friday, April 07, 2017 2:58 PM > *To:* IETF QUIC WG > *Subject:* Revisiting 0-RTT transport parameter negotiation > > > > There was a question > > of what should the client assume about the server's > > transport parameters in 0-RTT case. As a result of the discussion at the > > interim, we arrived to the state where client is allowed to assume either > the > > parameters from the previous session, or the default values. Server may > choose > > whatever parameters it wants, and if that's incompatible with client's > > assumption of server's 0-RTT parameters, the server may reply with an > > appropriate error or RST_STREAM, after which the client is supposed to > retry > > the connection. > > > > I personally find that this solution has "too many joints", as in, it > allows > > implementations a wide variety of behaviors, which in turn requires their > peers > > to accommodate those scenarios. The situation with the initial flow > control > > window is especially awkward. Server might choose to excuse flow control > > violations until the 1-RTT phase is reached, which requires client to > > accommodate possible flow control window decrease upon receiving server > hello; > > or it might choose not to excuse them, which requires client to retry by > > special-casing QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA shortly after > 0-RTT as > > a retry signal. All of this adds a complexity burden onto > implementations, and > > makes comprehensive interop testing very hard. > > > > Instead of the current negotiation scheme outlined in the draft, I propos= e > that > > we adapt a simple scheme similar to what TLS does with cryptographic > parameters > > and 0-RTT: > > 1) Client sends its vision of server's assumed parameters in the > ClientHello, > > and is expected to follow them in 0-RTT packets. > > 2) Server either accepts those parameters, or declines 0-RTT altogether= , > > by discarding the 0-RTT data and following up with a full 1-RTT > handshake. > > If server accepts 0-RTT, its parameters in the 1-RTT server hello cannot = be > > more limited than what it accepted from the client. > > > > In this scenario, both the client and the server can use their regular > > connection handling logic for 0-RTT data, since both the client and the > server > > have a consistent view of server's parameters. This works well when the > > parameters match expectations (most of the time), it's simple to > implement, and > > it's simple to test. > > > > -- Victor. > --94eb2c1d4c7c5d541f054d5f55f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like this idea, and I support it. Victor -- do you want = to generate a PR for this or would you like me to?

On Fri, Apr 7, 2017 at 12:57 PM, Lub= ashev, Igor <ilubashe@akamai.com> wrote:

Yes, this seems to work and is simple enough.=C2=A0= It would also close issue 425.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Igor

=C2=A0

From: Victor Vasiliev [mailto:vasilvv@google.com]
Sent: Friday, April 07, 2017 2:58 PM
To: IETF QUIC WG <quic@ietf.org>
Subject: Revisiting 0-RTT transport parameter negotiation<= /u>

=C2=A0

There was a question of what should the client assume about the server's

transport parameters in 0-RTT case.=C2=A0 As a resul= t of the discussion at the

interim, we arrived to the state where client is all= owed to assume either the

parameters from the previous session, or the default= values.=C2=A0 Server may choose

whatever parameters it wants, and if that's inco= mpatible with client's

assumption of server's 0-RTT parameters, the ser= ver may reply with an

appropriate error or RST_STREAM, after which the cli= ent is supposed to retry

the connection.

=C2=A0

I personally find that this solution has "too m= any joints", as in, it allows

implementations a wide variety of behaviors, which i= n turn requires their peers

to accommodate those scenarios.=C2=A0 The situation = with the initial flow control

window is especially awkward.=C2=A0 Server might cho= ose to excuse flow control

violations until the 1-RTT phase is reached, which r= equires client to

accommodate possible flow control window decrease up= on receiving server hello;

or it might choose not to excuse them, which require= s client to retry by

special-casing QUIC_FLOW_CONTROL_RECEIVED_TOO_M= UCH_DATA shortly after 0-RTT as

a retry signal.=C2=A0 All of this adds a complexity = burden onto implementations, and

makes comprehensive interop testing very hard.

=C2=A0

Instead of the current negotiation scheme outlined i= n the draft, I propose that

we adapt a simple scheme similar to what TLS does wi= th cryptographic parameters

and 0-RTT:

=C2=A0 1) Client sends its vision of server's as= sumed parameters in the ClientHello,

=C2=A0 =C2=A0 =C2=A0and is expected to follow them i= n 0-RTT packets.

=C2=A0 2) Server either accepts those parameters, or= declines 0-RTT altogether,

=C2=A0 =C2=A0 =C2=A0by discarding the 0-RTT data and= following up with a full 1-RTT handshake.

If server accepts 0-RTT, its parameters in the 1-RTT= server hello cannot be

more limited than what it accepted from the client.<= u>

=C2=A0

In this scenario, both the client and the server can= use their regular

connection handling logic for 0-RTT data, since both= the client and the server

have a consistent view of server's parameters.= =C2=A0 This works well when the

parameters match expectations (most of the time), it= 's simple to implement, and

it's simple to test.

=C2=A0

=C2=A0 -- Victor.


--94eb2c1d4c7c5d541f054d5f55f1-- From nobody Mon Apr 17 22:29:46 2017 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 53A20129438 for ; Mon, 17 Apr 2017 22:29:44 -0700 (PDT) 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, FREEMAIL_FROM=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=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 MyLX4TFg-YN3 for ; Mon, 17 Apr 2017 22:29:42 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 131FB129415 for ; Mon, 17 Apr 2017 22:29:42 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id 88so27845327lfr.0 for ; Mon, 17 Apr 2017 22:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tdgjFZuOLElnO3hoOqWxtRdNI0ka2Lk18XaJntxEAsE=; b=FJmGgt1ZtT9Y57KvGru7+SrjW/1C55EOnnSrF0h+1YXJphRTPf5XuNF5bGN71GUkiQ fzeeULwSsclSPp4N44k/kJr/VhmdK9q1b/w2WrEdJMz6ptWHeooylW1rOI5Urp1P95uV h+otPv1hMjt8Jp7irk9PMpMMhNTc8SLZNbGPaSeM0Ub4McnkSvSBcRqcsid50a+rgMgx YiWrR2tz0btdsP3rozfJpAoIgkjpdyeGrwsCmegsdOY3hqSTu8qcnuCQlEbAp/GOxdsX n6/Zla7b2eDqySyuLFaq5xpx6LDsSM27KWuI84q08hvZeS7imiCQ10Z+eiPs8kNBKsA1 Zqig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tdgjFZuOLElnO3hoOqWxtRdNI0ka2Lk18XaJntxEAsE=; b=OPebnbXyCFsMuddBQHrUNwtG4XfxoO3GR9Ok1031HFNDCCMrVhMKItWM4mzwp+lNxu cEW+UDQsyYkwA17FJ6l+6iebpBeJK114ytt+rVAhsB9hCBh51JjQyZbZIzg7nRgQJaB9 RYrEdyXoRkQrUcr6RmM7RknP/FDkhAypFYJO9LKEhs2F7pX6emClEbG+DRIe4Rw5nVL7 m2TQIwvKOPEV2l1RtVXAVMNnLp8gsNs7iLNoEJwNPkH3pyPpTHp6OElYbEHhTNZAC3p5 66KUa2O8kI9uLIKf475UubDhiphufShq2iitAfo7MT6KvtZiySaPff96Mn5e6CS5kUnW 3KVA== X-Gm-Message-State: AN3rC/5MeugUAS+yiqcOxv4KRburq/MMdxdWLaNOQIXbAleCP5pj37Ku 6I6QF0Jj35MEChZxJ4GQ4cV20xgvyuqzTR4= X-Received: by 10.25.76.193 with SMTP id z184mr3800464lfa.43.1492493380361; Mon, 17 Apr 2017 22:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Mon, 17 Apr 2017 22:29:39 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 18 Apr 2017 15:29:39 +1000 Message-ID: Subject: Re: Security considerations in quic-transport To: Christian Huitema Cc: "quic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 05:29:44 -0000 On 12 April 2017 at 04:44, Christian Huitema wrote: > Should these be documented? Yes. Text would be welcome :) I've opened an issue so that we don't forget: https://github.com/quicwg/base-drafts/issues/440 From nobody Mon Apr 17 22:37:11 2017 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 55A0C129423 for ; Mon, 17 Apr 2017 22:37:10 -0700 (PDT) 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, FREEMAIL_FROM=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=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 ErOyI61bvek6 for ; Mon, 17 Apr 2017 22:37:08 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 6F00C124217 for ; Mon, 17 Apr 2017 22:37:07 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id 75so74877289lfs.2 for ; Mon, 17 Apr 2017 22:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=stsdJVjT8U1me0aNWpKD/q3bpivQPPq6w/wgYceoJpY=; b=ShzMxXzQU8DfWJoQucK7bZ+pxd4k+nYxLpBPhybb0KjU3qV8yNjBLG67A31TUtMNYh u9gkEw4vhIMNxuDeayrjmUkEgl123sWi75FC9GQoBbPgevSA7wLT+/VgJ/Ezi0nCYZ6Z bg6X4QEx7k8XtbAjzQcINvS7829mxhyiATSkGRR8iApQ6Ndx6g4WWhdLlgpnGwyN2g/X hGpeaGMmvArjDaBs2Y4XlkxMTTIgOVloAF1FZSg8kfhaIBJJk1TFfr06t9tHbw14KyqD ur4shT7QTgLJeyjsjjxso4m58plqqTr2bga8HxilEeeKTgb7Z4EVMQ/18Rv4gdIw0l6C yLhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=stsdJVjT8U1me0aNWpKD/q3bpivQPPq6w/wgYceoJpY=; b=JJKYHy170PHrXZm3IGFuCVHpfIAgFTkW/r7oTt1Y5yeN4jx+sdismkdzpMScuJ+86b qM/hHNcJnyAexSmb5cx1AR/GdgUH+Nq1rD/R/iciEg/ivrZN5kTrTPjgnL64/o0PDhaX uDsCZqFB6hq63Qu2z7ES8GhUQVOOUVRUmWtVhWLZCXknmAh8fkDHha/4CNW6hN4I1HQm Xe+UWN1x9sbeFmBiQx0V5hk/t63Subz9lkRblLiQEQwIgrWdpljK52NhyMVmEAq9pAlC HgiRvLvx8SlW6shp05BYHxgwwZPLV2hosCft+lk/fkwFQuNQ/Msj6VOy7SlnlxmA85Ps u9EQ== X-Gm-Message-State: AN3rC/76GzE5fXp6DmosIauWHAWmCQPMNe4yraThMuinqW83OeCrRi2T aN5YSgNIyw7A5+rDr8BJamUiWUykyFrP X-Received: by 10.25.160.147 with SMTP id j141mr3813869lfe.19.1492493825646; Mon, 17 Apr 2017 22:37:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Mon, 17 Apr 2017 22:37:04 -0700 (PDT) In-Reply-To: References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> From: Martin Thomson Date: Tue, 18 Apr 2017 15:37:04 +1000 Message-ID: Subject: Re: Consensus Call on issues closed by the -02 drafts To: Eric Rescorla Cc: Victor Vasiliev , Mark Nottingham , IETF QUIC WG , Lars Eggert Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 05:37:10 -0000 On 14 April 2017 at 03:52, Eric Rescorla wrote: > I concur with Victor that this could use additional discussion, though I > would > want to consider yet another pattern, in which the client always gets its > params from the server and in 0-RTT tells the server "this is what you > said last time" as we do with ALPN. In any case, needs more discussion. I don't think that this is exactly how TLS works. In TLS, the client sends its usual ALPN list and the server is expected to remember from last time which it chose. The server negotiates ALPN as normal - though this might be biased by the possibility of 0-RTT - and it only accepts 0-RTT if the ALPN choice is the same. Note that the client has to include ALPN as normal in case the server decides differently this time (for instance, maybe it supports h2 over http/1.1). In any case, I agree that this model is a better design. I see two options that vary only slightly and are superior to both Victor's proposed design and the current one (which I agree is broken): 1. the client remembers from last time 2. the server sends new 0-RTT-specific parameters with its session ticket and the client remembers these instead In both cases, both client and server are required to remember. If the server is unhappy with the choices that it remembers, then it rejects 0-RTT. From nobody Mon Apr 17 22:41:53 2017 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 23A36129438 for ; Mon, 17 Apr 2017 22:41:52 -0700 (PDT) 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, FREEMAIL_FROM=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=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 yqx9aRtrYvbS for ; Mon, 17 Apr 2017 22:41:50 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 805C112704A for ; Mon, 17 Apr 2017 22:41:50 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id t144so75101999lff.1 for ; Mon, 17 Apr 2017 22:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bLY/Osz0mNJ/ZhGsushjVV/WIdSeLjajfquiRanzu/g=; b=STz4W2SMi8AglOf+U1IlI9epNScR2jqHeeM/+9pBW4DTMLRtb4z5sbwnHIAKfDKH0h K0h9Rt58UxGy6JWnNl3p9wY7QtHACIqxFXezhssVSIourmc+CXSKp7CCixbwE3+sq+mp qw5C7ND3OWGANwotWSBRlBigENlElmYheunbqRqj6jlPiGzpGycBHBIgwULlga4SeX9Y UYvBjrn8QowT5LH10RYNUcSFKC3yXWgqqnc571x3ZX0SL6W8tNImBMfw+oXMkIY8C8P0 yEFStPOjzPOaC4w5iasiW464+meU9vhizn2y2vyJRsqa60uUrM9WaSadbU3Na0krNjuC b6Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bLY/Osz0mNJ/ZhGsushjVV/WIdSeLjajfquiRanzu/g=; b=iKiuXvripyHxWiKNW+RPL7VHcSkK0HNpwzFq7jMlkInExk0Z/LzljZ/rIgIDMmQKya UBz81vtOj1ozWTyFD0qTtEl1yIkaguHylYDOY7ZcVpdSjmBxvYu2+ItbgRlH+Y8yG7Ra TqOsg1Yi4G12TmZwUo5tVURXRXtK2wHSklTDt3sw/7qMFTBplQklwg9tZ4vuBu+lj7XI aiNh33eXDtSLYsZd1jpR61w3UhyPezLDjuSWBTOjqS4wUWDdtdprGeOaXcT5TQgs2hJK g3qX85BYGQG2IGit1oIRCWrq5620x4IGqb+i32Lx/qFk7MFbFiXvcrGw7vfbrsnGVNxF /m5A== X-Gm-Message-State: AN3rC/47gm2f58HqtxSAJskN5Y95vKFRW2BxIYZJhyPRlylQu4z5Gjt1 m3dyTaJ1Jj/t0bxfMaG5mbivRxcwFA== X-Received: by 10.46.69.133 with SMTP id s127mr3627489lja.44.1492494108711; Mon, 17 Apr 2017 22:41:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Mon, 17 Apr 2017 22:41:48 -0700 (PDT) In-Reply-To: References: <0248e010b13d47a8ab8bc86f9b42970e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Tue, 18 Apr 2017 15:41:48 +1000 Message-ID: Subject: Re: Revisiting 0-RTT transport parameter negotiation To: Jana Iyengar Cc: "Lubashev, Igor" , Victor Vasiliev , IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 05:41:52 -0000 As I said on the other thread, I think that this design isn't quite right, though the problem is certainly real. The TLS design doesn't rely on the client sending the server what it thinks the values are, it relies on the server remembering. That has better confidentiality properties, and it is isomorphic with other TLS 0-RTT behaviour. Note that remembering isn't a chore: the client has to remember the ticket anyway. Now it has to remember the ticket and the server transport parameters. The server has a choice: it can remember them or stuff them in the session ticket (or it could decide never to change them). The difference being that remembering means that you don't spend critical early bytes on stuff that you know both sides already know. On 18 April 2017 at 02:32, Jana Iyengar wrote: > I like this idea, and I support it. Victor -- do you want to generate a PR > for this or would you like me to? > > On Fri, Apr 7, 2017 at 12:57 PM, Lubashev, Igor wrote: >> >> Yes, this seems to work and is simple enough. It would also close issue >> 425. >> >> >> >> - Igor >> >> >> >> From: Victor Vasiliev [mailto:vasilvv@google.com] >> Sent: Friday, April 07, 2017 2:58 PM >> To: IETF QUIC WG >> Subject: Revisiting 0-RTT transport parameter negotiation >> >> >> >> There was a question of what should the client assume about the server's >> >> transport parameters in 0-RTT case. As a result of the discussion at the >> >> interim, we arrived to the state where client is allowed to assume either >> the >> >> parameters from the previous session, or the default values. Server may >> choose >> >> whatever parameters it wants, and if that's incompatible with client's >> >> assumption of server's 0-RTT parameters, the server may reply with an >> >> appropriate error or RST_STREAM, after which the client is supposed to >> retry >> >> the connection. >> >> >> >> I personally find that this solution has "too many joints", as in, it >> allows >> >> implementations a wide variety of behaviors, which in turn requires their >> peers >> >> to accommodate those scenarios. The situation with the initial flow >> control >> >> window is especially awkward. Server might choose to excuse flow control >> >> violations until the 1-RTT phase is reached, which requires client to >> >> accommodate possible flow control window decrease upon receiving server >> hello; >> >> or it might choose not to excuse them, which requires client to retry by >> >> special-casing QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA shortly after >> 0-RTT as >> >> a retry signal. All of this adds a complexity burden onto >> implementations, and >> >> makes comprehensive interop testing very hard. >> >> >> >> Instead of the current negotiation scheme outlined in the draft, I propose >> that >> >> we adapt a simple scheme similar to what TLS does with cryptographic >> parameters >> >> and 0-RTT: >> >> 1) Client sends its vision of server's assumed parameters in the >> ClientHello, >> >> and is expected to follow them in 0-RTT packets. >> >> 2) Server either accepts those parameters, or declines 0-RTT altogether, >> >> by discarding the 0-RTT data and following up with a full 1-RTT >> handshake. >> >> If server accepts 0-RTT, its parameters in the 1-RTT server hello cannot >> be >> >> more limited than what it accepted from the client. >> >> >> >> In this scenario, both the client and the server can use their regular >> >> connection handling logic for 0-RTT data, since both the client and the >> server >> >> have a consistent view of server's parameters. This works well when the >> >> parameters match expectations (most of the time), it's simple to >> implement, and >> >> it's simple to test. >> >> >> >> -- Victor. > > From nobody Tue Apr 18 01:53:34 2017 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 AF2A4131831 for ; Tue, 18 Apr 2017 01:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.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 4uaVlKA2iMxS for ; Tue, 18 Apr 2017 01:53:31 -0700 (PDT) Received: from mx61.netapp.com (mx61.netapp.com [216.240.31.181]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6FE131823 for ; Tue, 18 Apr 2017 01:53:29 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.37,218,1488873600"; d="asc'?scan'208"; a="9983527" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx61-out.netapp.com with ESMTP; 18 Apr 2017 01:21:51 -0700 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Apr 2017 01:52:22 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 18 Apr 2017 01:52:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8lZ1sva3ZUP3gIEmGHvGdtIsJA51q5Nmetl6GdwmBsI=; b=BhPIVyRuHBay+GXCgqp5H274UFJb4+a0bizDSY7aIOruFITFza52S/R3KTNMchn85L8/DohEGuH2SnRjPdI2/YHl0Sh2kFSc9s29OIbkq1c+ombjJicRUN32LuIGbfCeYy8YjdTfctW572u1dg5b5rcjNuOWxgbfmd4P9gV+pxk= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1156.namprd06.prod.outlook.com (10.160.157.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Tue, 18 Apr 2017 08:52:24 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.1034.013; Tue, 18 Apr 2017 08:52:23 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Questions regarding fall interim location Thread-Topic: Questions regarding fall interim location Thread-Index: AQHSuCEYu43+pxIH+EW5QK9AkiGJig== Date: Tue, 18 Apr 2017 08:52:23 +0000 Message-ID: <5F031C14-1296-4B2F-B0FB-CC6DAB046BC1@netapp.com> Reply-To: "Eggert, Lars" , Mark Nottingham Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1156; 7:j8pphCNX9FuNXt3DWwnv9grby7U5mXzZQM5rsNzvLxYel5+rTCcKRREym4XEsA33W+zmAQmi1PzYYzXadisFsBmMeKD/m7OkvdK/NV9xr2vfByOHlJx3hmWsb7oJDgYDKZUNSVhzUJ7ysnioRGIZwKOO/JjEsYyW7nfi7NPeNtuissXv/FnTtB9wmhFZ63egPbRnHGr1l+xEbFLi7eh2/2ZHmIshLfF5+TCyLsB7E40O8L/efca8H75tawEPT8wctLgLRh7RtOerduQdL9gvRCZMeZgfcdClCqNIfoXB9UYjDZ1EVRasbsRih1oR4tYo6Mb8img7sun9Q+4kCgvBhw== x-ms-office365-filtering-correlation-id: 5b8e7a96-6b6f-4b34-e605-08d486383b18 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0601MB1156; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(6072148); SRVR:BN3PR0601MB1156; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1156; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39840400002)(39850400002)(39450400003)(3660700001)(110136004)(86362001)(5660300001)(99286003)(122556002)(2900100001)(53936002)(38730400002)(82746002)(83716003)(7736002)(6506006)(6512007)(6436002)(189998001)(305945005)(25786009)(6486002)(77096006)(50986999)(99936001)(3846002)(50226002)(8936002)(33656002)(8676002)(6916009)(66066001)(57306001)(36756003)(81166006)(43066003)(6116002)(3280700002)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1156; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_25178D5D-88F8-4C73-AD6E-F90A1C968C88"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2017 08:52:23.1188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1156 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 08:53:33 -0000 --Apple-Mail=_25178D5D-88F8-4C73-AD6E-F90A1C968C88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, with our Paris interim around the corner, Mark and I are discussing = options for the fall interim. In the interest of spreading around travel time, we're looking at a = North American destination, likely in the last two weeks of September or = the first two weeks of October. Two asks: (1) People who are willing to host such a meeting, please contact the = chairs. We do have some requirements (major intl. airport, close = distances between hotel/venue/restaurants =3D no rental car needed, room = for ~50 with U-shape setup & tables, good WLAN, etc.). And we would like = to avoid the Bay Area, because that might blow up attendance numbers = past what is manageable. (2) If your in-person participation would become very difficult if the = meeting were to take place in the US, please also let Mark and me know. Thanks, Lars --Apple-Mail=_25178D5D-88F8-4C73-AD6E-F90A1C968C88 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlj108UACgkQVLXDCb9w wVc0GBAAsav5jg4QBj/BYo270IuALNR/VJNsCvm9/EsJPA7PplYYixVwzCHzaBmq mwuzOwpPrjxNLYIRWzn3RLrEwO0omn142k3W5AlJ05yNrfg+1KdBG+S4W0h79yGx rWwSHvnKv2eWw5zoQtH01DxRVokIvAAlUBlu/tetV+12oNhHhjg3FfkO0oVVgTro w2rzHzgz8IbGhpY7GlG2TSUm63STCP0HKL5ZknJgW840r4JWEKEhTXtoB6vvlUHC hAtFeADRn0GoyoinSsWHNxHqFWL8S1ea8FucDkX2UQuDGqScUfG/dzLbM+/kLsWK FufUN0dl0aTVL/ztZK9NcALuIEr0olCl6p/JJE7wwtWajsNdlft1kMsezn7BZADk dRcnClx6jJbbL4UG3S+Ah1v4sQ+JCJnuKHQE8PI6m7oPK0kX6WRib0PS+WCVthTh gQ5SnaQcqNHvMwoY2g7797s60QIhGt48RNHa187ZHKsRnwsgXgXS3s+xi4kg3b+y JdnloblOV4jazCD1yQ/hWoAbKJPl6AggqJc9pxh4rfgtkNgeiCMDUhLIPT56NWu8 2ojVLdhc4DhODXrtmWUAeGS2Vl4s/1vmHYSGvo3JTgC233WYMDRrlzfckgwxRB/g sbvfG4sEIqsr2gQl3w4/q0LY/zCE3Br2LTd2jNeWfoR17zRtyBg= =zKTZ -----END PGP SIGNATURE----- --Apple-Mail=_25178D5D-88F8-4C73-AD6E-F90A1C968C88-- From nobody Tue Apr 18 12:04:24 2017 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 486C113146F for ; Tue, 18 Apr 2017 12:04:23 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=simula-no.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 FDnUb4lFL9mc for ; Tue, 18 Apr 2017 12:04:21 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 003A01293D9 for ; Tue, 18 Apr 2017 12:04:20 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id c80so1084737lfh.3 for ; Tue, 18 Apr 2017 12:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=simula-no.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=I00lSoqjp9SyVfC5UhdRUYIt75xm8NgDdAnPcbE1fS8=; b=kNdSgVxEQgbS3F8L4J4G5p3imMj23Bk/ju1R2khNYwgnehWarLsW4fVsNjKDSUi9nq zvWYrBHH1UqJa/8K1kYU7jSPjBVn9J4KgLDH6hCwTr85TrmE/RIKDKhl5ofrltODfWLs oLjkMuKvlyTGnu4Gdi94tEeLzRaIGsecVLPesCuX/9HcFz0wqoiPZRHVBx+odXofALXL q/57CB2uR0InyvRNusl7ZhXWdqzNnZAzqBjXWKrwZoRNeizqiwwAaTzShUYjO0GUVaxW vb92sAA8frZdd+4QFPDHb5+QWtTcRUd3D/wYuIIcdRubrGBuoipb9SbaquDwy+Cuxz5E C+4g== 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=I00lSoqjp9SyVfC5UhdRUYIt75xm8NgDdAnPcbE1fS8=; b=DV44dZwg39K1x/+RqdHkPzOoz3smvtEkhOWFCvQYqgQrfgSXOTjbFa5A5UGX/aqtd2 Z4uPIPQcQekO7OZxyM13aK7RasC6qD5GhBy78KjB19qrfZ4SjELk02KXPdWUXgRNk4BZ iD43eCJPI/t42ldoI+dTAm0YBvyUbwIe5PObZrxOmG5AMo06hBSBMRO34QZ7Ch92GUrr 9ZfYZ9oryZBWgFpoUvrCqVSLBlD9Y3tvebxtl09wD5l2dEjCJN/ZxbujF/6LwJPlw6Oz S2j7CWa5RBgX3qmfoy3o1mXYGlrCjhbqA/SrJxnWp17SfbT5yNcG2TeerDQYzYhq5/fo bS1Q== X-Gm-Message-State: AN3rC/78Zry614KbjHK5ZjuMgB20gq55Hm256YgtWN2cZA3YaQuiMZgw n/8rJNx2B++/Q1UF0Y2CPcm/9kTTY79FrcxWjw== X-Received: by 10.25.16.93 with SMTP id f90mr6084963lfi.91.1492542259061; Tue, 18 Apr 2017 12:04:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.163.74 with HTTP; Tue, 18 Apr 2017 12:04:18 -0700 (PDT) From: Simone Ferlin-Oliveira Date: Tue, 18 Apr 2017 21:04:18 +0200 Message-ID: Subject: QUIC experiments with forward error correction To: quic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 19:04:23 -0000 Dear all, I have been following QUIC's implementation for some time, and in an old thread of earlier experiments (~IETF'88) [1,2], J. Roskind mentioned some experiments with XOR-FEC that resulted in bad performance with YouTube traffic. I went through the current repo, and couldn't find much about it - it looks there is some dead code with some FEC definitions, or are there any plans to revive the topic [3,4]? If there are no plans to revive it, does anybody remember anything about it from the tsvarea? I would be interested in the implementation of the XOR-FEC, how it was experimented inside QUIC. [1]: https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/Z5qKkk2XZe0 [2]: https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf [3]: https://tools.ietf.org/html/draft-hamilton-early-deployment-quic-00 [4]: https://github.com/google/proto-quic/search?utf8=%E2%9C%93&q=FEC&type= Cheers, Simone From nobody Tue Apr 18 16:46:56 2017 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 EB676126B6D for ; Tue, 18 Apr 2017 16:46:55 -0700 (PDT) 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, FREEMAIL_FROM=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=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 0Hz2C1Gr117B for ; Tue, 18 Apr 2017 16:46:54 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 E46781293F8 for ; Tue, 18 Apr 2017 16:46:53 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id c80so3978379lfh.3 for ; Tue, 18 Apr 2017 16:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c344fF2O9EPn5DaaVR4fjWhTRLcdhgOkSDOor/6lEwM=; b=H2Z1SPZT7dhBtwpcEYo2uOIcdgFxSIHMLubt93f+hPzbRCfnwZG0ajJk8xgmPXxuLO P7XCy7D7CS5UWOQTUt/2GExhAXPyGFOZ2N6Bthnpnf6P/fHoFOh+AkfegwvrrhqQHrYG Gg0nWGAQXmgQocEMTHV3fLHlrd9cBu0K1QqtB7/RVRRBVZyFKT6krYc9PtT4P+gFyTOE gGjMahZmtDzX2j8DSMp1Ew4SiLS5W+IW1XM+QeTmFaKpUK3yOKiXQSNNkkXNa2IjvgcA 24uDsUDyVhkU5d9Gh0b2pJIC9VzCleQBR4ywypgACRIZOFqbeGxiU5N+dk6Dvsufs6Qh Ed5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c344fF2O9EPn5DaaVR4fjWhTRLcdhgOkSDOor/6lEwM=; b=ckEAeW7DUMUW3+HA0RHYjtAYKFWHXjo+UyNDnl8l2xhiipebA/ire27rTBDDacgVkO gj3KDRqj8gDK7suGirfNbZIcV+WxCUPazAc/6KUYFb/F/6Dsg54VlWffSgPEyM2Q6ewV lwjLgRoPAHZhbeit8XjcIyVk1Xb6UUW+XpCYV4oeUGzJfCzAw+5EoF/XnCjlXn4q00Xi URms4YwrEZBxCEvxRhliWq84dzrFNmV7kphT3dkIZN18Z81xpOudB0cYzdZZIUwU+rDX GvVyjKBoGFq/FtYfpUiuBiLPjXKvD4G6TlPj1tsw3aUl9yci9tdmN3kkaMnb9ChZfUCV CeIA== X-Gm-Message-State: AN3rC/4XeDSJLUwTGzv+mvGyHhS6YDG3DtPDkb+TM7Dz4Cvv7od9UYm7 3rGzX14AbIS2+NP/o47ntpsZi7NaD74L X-Received: by 10.25.76.6 with SMTP id z6mr5233lfa.172.1492559212209; Tue, 18 Apr 2017 16:46:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Tue, 18 Apr 2017 16:46:51 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 19 Apr 2017 09:46:51 +1000 Message-ID: Subject: Re: Key change logic To: Eric Rescorla Cc: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 23:46:56 -0000 Yep, I followed your logic here and you are right: Anything that doesn't decrypt has to be thrown away (no connection closes on unauthenticated rubbish) For the sequence P=1,N=15; P=0;N=20 without ever sending with P=1, the second packet should be discarded rather than trying with G=2. (The awkward thing is that you probably need to have more than two generations of receive keys in play in the case you DO send with P=1 here.) For the sequence P=1,N=15; P=1,N=12; P=0,N=14 the third packet should be discarded. On 14 April 2017 at 06:49, Eric Rescorla wrote: > I'm not sure that the logic around key changes is exactly clear. > > Case 1: > Assume you are in steady state where you have just received a packet > with key generation G = 0, key phase bit P = 1, and packet number PN = > 10 (i.e., there have been no key changes so far). You now receive a > packet with PN = 15, P = 1. Turning to 6.2, we see: > > A receiving endpoint detects an update when the KEY_PHASE bit doesn't > match what it is expecting. It creates a new secret (see > Section 5.2) and the corresponding read key and IV. If the packet > can be decrypted and authenticated using these values, then the keys > it uses for packet protection are also updated. The next packet sent > by the endpoint will then use the new keys. > > An endpoint doesn't need to send packets immediately when it detects > that its peer has updated keys. The next packet that it sends will > simply use the new keys. If an endpoint detects a second update > before it has sent any packets with updated keys it indicates that > its peer has updated keys twice without awaiting a reciprocal update. > An endpoint MUST treat consecutive key updates as a fatal error and > abort the connection. > > So, we compute generation G=1 and try to decrypt the packet. If it > succeeds, we install key G=1 with the knowledge that the transition > happens somewhere between 10 and 15. > > > Case 2: > The same as Case #1, but I receive PN = 7, P = 1. I think what we do > then is just discard the packet immediately because it's impossible, > right? Not clear where the text says that. > > > Case 3: > Imagine we are in the state right after case #1 (i.e., we have sent no > packets) and now we receive a packet PN = 20, P = 0. Now, this looks > like a second key change, so what do we do now? It seems like we have > three choices: > > 1. Discard it because it's clearly illegal. > 2. Try to decrypt it with key G=2 and process it as a key change (as > the first paragraph of the citation above graf tells us to do). > 3. Tear down the connection as specified in the second paragraph > above tells us to do. > > #2 seems pretty silly, because only one of two things can happen > > (a) We can't decrypt it because it's bogus and we discard it. > (b) We can decrypt it (because the keys have been compromised > or the other side is misbehaving) in which case we tear > down the connection. > > But it's almost certainly (a), so this doesn't seem like a good > use of resources. > > #3 is even worse, because it means that anyone can send us an > unauthenticated packet and tear down the connection, so that > can't be right. > > I think that leaves us with #2 as the right answer, but that's > the one thing that the spec doesn't tell us to do, and it renders > the second paragraph above irrelevant. > > > Case 4: > The same as case #1, but next I receive two packets: > > - PN = 12, P = 1 [which decrypts with key G = 1] > - PN = 14, P = 0 > > Now, this second packet is impossible because we know that that > we have: > > PN = 10 [G = 0] > PN = 12 [G = 1] > PN = 15 [G = 1] > > So we can't have a key change between 12 and 15, so here we are. The > spec doesn't give guidance on what to do. I think the answer is > "discard the packet". > > > I think we need to write these sections a bit more clearly. I'm > happy to take a crack at it, but I'd like to make sure that we all > agree that the behaviors above are the right ones. > > -Ekr > From nobody Tue Apr 18 16:48:23 2017 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 E116A1286AB for ; Tue, 18 Apr 2017 16:48:21 -0700 (PDT) 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, FREEMAIL_FROM=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=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 x43IeJUWzyox for ; Tue, 18 Apr 2017 16:48:20 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 727431293F8 for ; Tue, 18 Apr 2017 16:48:20 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id 75so4007200lfs.2 for ; Tue, 18 Apr 2017 16:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2GsTHbm1Wy060qHtQSFn9CJOhkYk7uzAGtGCxFSn7pY=; b=tdF+KOrQ6lAOaCIBmI5wMt1LXMR3GS+boQ2M/msRYNhKtn0TymP3La46dY9cTiE/hS jZxsovmETD6sxtev1rtiNrL7SoYjCknKEODs1MFc3Aktowl/VVzH5SI2GxFxN7GQffp0 AJaqJMmbBptglx64fwQ6Ebde7wc3DNw2gil9QOcILG79Qyb4tjhQEy0uwHEjryrIcdvH ltI1KlDiWwc7aNOe0U8M4H/mx7P2rJX8L/8hpHLJcacrT1hhFhh3J1lYX+d4PJLq2B2q L+kEdYUnFaK3BVHkLwJZQ6iOB/SFzaFPSoVSWSsIHMVmc/81gHsnSKURnqLGkKB2V/fM 3HXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2GsTHbm1Wy060qHtQSFn9CJOhkYk7uzAGtGCxFSn7pY=; b=o+NuaAUr0CXamxBXtvX+Sua/hxzByPqJT6qHnMzcYh6F8Jfc1BCcl8MZp9kOJQF5qj GK/Rw9ro40LCUv8OBqZl3qNm0y0cqRwkruv5/L7oqAcs7VE43LQR8FYuyYJ4wf/DbNR+ KRGpXLTh+OqMn8Do9Ltr7LdJj/lz7ojJt54Ys3VG3SSyNj4UP85YomT0x5vMKqEfHUgL 5J9Ynw37SINeaqZzIR6H2UghJj0WByQr5F0iCoU0YxNZLucwTGxGW32VmoVlqnvQyNlB BVNYzaSxOvANqhZnl+7n21zyYZ8QohxqtmVv6PkT/abPVsLdzNZVvYhmf3qHeMiekFIS 9nhg== X-Gm-Message-State: AN3rC/7xtMpwIWyaJx6cZIooq8DLXUZTQ82WcMbi9qhI5cM1jV8C02HU /Q8NkEHkf5K23P9h2QwQb9jyG/X1hipA X-Received: by 10.46.97.26 with SMTP id v26mr3271ljb.33.1492559298843; Tue, 18 Apr 2017 16:48:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Tue, 18 Apr 2017 16:48:18 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 19 Apr 2017 09:48:18 +1000 Message-ID: Subject: Re: Sending/Receiving packets before client Finished To: Eric Rescorla Cc: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 23:48:22 -0000 That sounds right. The change to allow receipt after validating the PSK binder is new, so there are almost certainly some editing errors. On 14 April 2017 at 06:19, Eric Rescorla wrote: > Rereading the -tls draft, it's not entirely clear to me what the > rules are around the client's Finished. I think the rules you > are applying (on the server, because the client has no such issues): > > - The server can process 0-RTT messages immediately (S 8.2) > - The server can process 1-RTT messages upon receiving either > the client's Finished or the PSK binder (S 8.3) [0] > - The server can send messages with the 1-RTT keys upon sending > Finished, either in 0.5 RTT or in 1-RTT. (implied in S 4.2.3) > > Do I understand this correctly? If so, I may have some proposed > changes, but I'd like to understand the intention first. > > Thanks, > -Ekr > > > [0] Though it's actually sort of confusing because the second > graf permits the Finished or the PSK binder and the last graf > says you can't use packets before Finished if you depend on > client auth. > From nobody Tue Apr 18 19:58:26 2017 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 01C4F12945A for ; Tue, 18 Apr 2017 19:58:25 -0700 (PDT) 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_HELO_PASS=-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 xFtSorK29sEz for ; Tue, 18 Apr 2017 19:58:22 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 B60D81314B0 for ; Tue, 18 Apr 2017 19:58:22 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 55A1422E255; Tue, 18 Apr 2017 22:58:09 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Please review IETF-98 minutes From: Mark Nottingham In-Reply-To: Date: Wed, 19 Apr 2017 12:58:06 +1000 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , "quic@ietf.org" , Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <7012D827-3A02-4397-81DC-3A5A8EF1F8F0@mnot.net> References: <27BBC67B-AFDD-4B67-9D59-9F6049E36B93@tik.ee.ethz.ch> To: Jana Iyengar X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 02:58:25 -0000 I've posted a cleaned-up version at: https://github.com/quicwg/wg-materials/blob/master/ietf98/minutes.md ... and will upload to the Secretariat in the next day or so. Cheers, > On 12 Apr 2017, at 4:48 am, Jana Iyengar wrote: >=20 > LGTM -- thanks, Magnus! >=20 > On Tue, Apr 11, 2017 at 11:18 AM, Mirja K=C3=BChlewind = wrote: > Did two small edits=E2=80=A6 thanks Magnus! Great job! >=20 > > Am 11.04.2017 um 20:11 schrieb Eggert, Lars : > > > > Hi, > > > > please take a minute to review (and correct, where needed) our = minutes from the IETF-98 meeting. Doubly so if you spoke at a = microphone. > > > > = https://etherpad.tools.ietf.org/p/notes-ietf-98-quic?useMonospaceFont=3Dtr= ue > > > > We'll turn the contents of the Etherpad into the final minutes in a = few days. > > > > Lars > > > > PS: Magnus, I still owe you that beer for capturing all of that! >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 18 22:52:39 2017 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 98E9E131519 for ; Tue, 18 Apr 2017 22:52:37 -0700 (PDT) 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_HELO_PASS=-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 ZVUDACLeO52H for ; Tue, 18 Apr 2017 22:52:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 B3BE9131514 for ; Tue, 18 Apr 2017 22:52:34 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0EC9322E1F3; Wed, 19 Apr 2017 01:52:23 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Consensus Call on issues closed by the -02 drafts From: Mark Nottingham In-Reply-To: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> Date: Wed, 19 Apr 2017 15:52:21 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <3D126D14-1EF4-4B21-B6D7-E6804417E76D@mnot.net> References: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 05:52:38 -0000 Based upon feedback, I've reopened the following issues: #51, #55, #126, #158, #181 The remaining issues listed below have been marked `has-consensus`. Going through the issues list, I see we missed a handful of issues = (mostly early ones). I'll send out a separate call for them shortly, = just to close the loop. Cheers, > On 17 Mar 2017, at 8:22 pm, Mark Nottingham wrote: >=20 > Everyone, >=20 > The -02 drafts incorporate the proposed resolutions to a number of = issues that have been discussed.=20 >=20 > Those issues are listed below. Please have a look through them, and if = there are any resolutions that you feel need more discussion, please = bring it up, either here on the mailing list or in the issue itself. >=20 > Issues that we need to discuss more will be reopened. The remaining = ones will be flagged as `has-consensus`. >=20 > There are a lot of them, so we're not going to do this until after the = Chicago meeting (at the earliest) to give people a chance to discuss on = the list as well as in the meeting. >=20 > See = for a reminder about the process we're using here. Even when = we have consensus, we can reopen an issue if new information emerges = (and that can take a variety of forms). >=20 > This list is also available at = . >=20 > Cheers, >=20 > ## Transport >=20 > #35 - Starting packet number > #40 - Variable-length fields > #49 - Transport parameter advertisements > #50 - Updating Transport parameters > #51 - QUIC version number scheme > #52 - Source address validation > #55 - What can change in a different version > #56 - Extending flags > #57 - Advice on STOP_WAITING > #59 - Define ICSL parameter > #62 - Finding frame lengths > #63 - ACK retransmission > #64 - Path MTU Discovery > #66 - Remove STOP_WAITING > #67 - Picking packet number length > #69 - Minimum packet size > #70 - Move ACK/STOP_WAITING into the packet header > #74 - Application-defined error codes > #104 - Priority in QUIC Transport > #108 - Maximum stream number > #112 - Greasing version negotiation > #114 - STREAM retransmission priority > #116 - COPTs as empty transport parameters > #117 - SCUP > #118 - Source Address Token encoding > #119 - Server-proposed connection ID > #124 - Alt-Svc quic version hint > #126 - Separate transport parameters for 0-RTT > #133 - Connection ID in version negotiation > #135 - DoS using Version Negotiation Packets > #136 - First client packet size > #139 - Minimum MTU > #147 - Reflection Attack Resistance > #148 - QUIC packet header complexity > #157 - Updated information in retransmitted frames > #158 - Padding between frames > #159 - Time format > #162 - RST_STREAM and flow control > #163 - RST_STREAM and connection-level flow control > #164 - Padding handshake packets > #168 - Ordering of ACK Frame fields > #174 - Stream Reservation > #181 - Remove SETTINGS[_ACK] > #185 - Reliable identification of the initial packet for a connection > #201 - Do streams 0 and 1 count towards MSPC? > #204 - Streams not contributing to connection-level flow control > #243 - AEAD Associated Data > #244 - Need a NONCE in version negotiation packets > #262 - Don't encrypt client handshake with 1-RTT keys > #285 - Policing packet number size > #286 - Outstanding packets and packet number size > #289 - Avoid using Public Reset where possible > #291 - ACKing ACK > #292 - Does any portion of the QUIC framing require 4 byte alignment? > #293 - Does the connection id need to be in a consistent location? > #295 - Connection ID on a version negotiation packet > #308 - "retransmitting" old timestamps in ACK frames > #323 - Smaller packet number representations > #340 - Scale flow control offsets > #341 - What does it mean to acknowledge something? > #347 - Clarify meaning/definition of GOAWAY > #349 - When should server-chosen connection IDs be sent and how are = they indicated? > #352 - Does GOAWAY need an error code >=20 >=20 > ## Recovery >=20 > #63 - ACK retransmission > #169 - Response to lost handshake packets >=20 >=20 > ## TLS >=20 > #12 - Decouple QUIC version and ALPN=20 > #25 - Key update forward secrecy > #26 - Which bit can KEY_PHASE use? > #27 - Fix KEY_PHASE for early data > #34 - ACK rules and packet protection > #87 - QUIC advertisement description > #97 - Version Negotiation + TLS > #226 - Authenticating public parts of the packet header > #243 - AEAD Associated Data > #262 - Don't encrypt client handshake with 1-RTT keys > #272 - Signaling TLS handshake failure >=20 >=20 > ## HTTP >=20 > 75 - SETTING syncronization > 87 - QUIC advertisement description > 95 - CONNECT > 104 - Priority in QUIC Transport > 124 - Alt-Svc quic version hint > 127 - Frame header reserved bits > 154 - HTTP Stream ID Size > 173 - Size of HTTP Header Sequence Numbers > 176 - RST_STREAM breaks HPACK > 181 - Remove SETTINGS[_ACK] > 202 - HTTP: Why are we defining CONNECT? > 204 - Streams not contributing to connection-level flow control > 229 - Use a quic=3D parameter for Alt-Svc rather than collide with = existing use of v=3D > 242 - HTTP extension mechanisms > 297 - Remove the quic parameter from Alt-Svc > 364 - Mid-frame close >=20 >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 18 23:09:04 2017 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 ED4D8131519 for ; Tue, 18 Apr 2017 23:09:02 -0700 (PDT) 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_HELO_PASS=-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 sHrWtyYjDw1O for ; Tue, 18 Apr 2017 23:09:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 54EA113151C for ; Tue, 18 Apr 2017 23:09:01 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BA4F422E1F3; Wed, 19 Apr 2017 02:08:59 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Consensus Call: A Few More Issues Message-Id: <02E96EDA-53F7-427F-B65E-835E713331B1@mnot.net> Date: Wed, 19 Apr 2017 16:08:57 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 06:09:03 -0000 Hello, The editors believe that the issues below have been closed by the -02 = drafts (or previous ones); these are the ones that I mentioned as being = missed in the previous round. I *think* they should be = non-controversial, since they're so old. Please have a look through them; if there are any resolutions you feel = need more discussion, please request that the issue be reopened. Issues that we need to discuss more will be reopened. The remaining ones = will be flagged as `has-consensus.` See = for a reminder about the process we're using here. Even when = we have consensus, we can reopen an issue if new information emerges = (and that can take a variety of forms). These issues (and a few more recent ones that we won't call consensus on = just yet) can be found at: = Cheers, #72: Consider eliminating PRIORITY region from HEADERS #73: PRIORITY and Stream ID space #146: STREAM frame boundaries #206: Mismatch between version negotiation in TLS layer and in QUIC = layer -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 18 23:42:38 2017 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 EC11A12704A; Tue, 18 Apr 2017 23:42:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: mnot@mnot.net, quic@ietf.org, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: quic - New Meeting Session Request for IETF 99 X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149258415687.29127.17485183167021125819.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 23:42:36 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 06:42:37 -0000 A new meeting session request has just been submitted by Mark Nottingham, a Chair of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Mark Nottingham Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: httpbis tsvarea tsvwg tls Second Priority: opsawg opsarea mptcp Third Priority: maprg People who must be present: Mark Nottingham Janardhan Iyengar Martin Thomson Spencer Dawkins Lars Eggert Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: --------------------------------------------------------- From nobody Wed Apr 19 00:10:37 2017 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 D6377131530 for ; Wed, 19 Apr 2017 00:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 QtqbKDvJvygy for ; Wed, 19 Apr 2017 00:10:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADFF131535 for ; Wed, 19 Apr 2017 00:10:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFC73174; Wed, 19 Apr 2017 07:10:30 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 19 Apr 2017 08:10:18 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.133]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 19 Apr 2017 15:10:13 +0800 From: Roni Even To: "quic@ietf.org" Subject: Experimental Room Setup (U-Shape and classroom, subject to availability) Thread-Topic: Experimental Room Setup (U-Shape and classroom, subject to availability) Thread-Index: AdK42LYzcgHRAteeSc+wTZzcVrVtIw== Date: Wed, 19 Apr 2017 07:10:13 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7AFCD9@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.202] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD7AFCD9DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.58F70D67.0020, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 966eede31100b2ee5db0b9a57d89db11 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 07:10:36 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD7AFCD9DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I noticed that the WG chairs asked for a U-shape room similar to the experi= ment in Chicago I am sorry for not providing feedback before but I found that arrangement v= ery difficult from my perspective, I was sitting on the side not facing the= screen and the room was very packed. I had the following observations: 1. It was difficult to understand who is speaking. People sitting at = the table started speaking without stating their name. It is much simpler w= hen they have to go to the microphone and stand at least you can see who is= speaking. 2. It was inconvenient to look at the presentation screen when you ar= e not facing the screen. Sitting on a chair with a laptop on your knees an= d looking sideways to the screen was challenging for my neck. It is simple= r if you sit by a table. 3. There was no easy path to go to the microphone for people who were= not sitting at the table. Again, since the room was very packed there wer= e no path from the side to the middle where the microphone was. 4. When choosing a sit, the screen facing sites where far from the sc= reen. I think that having this long table is part of the problem. Maybe you= need a smaller table for less people who really actively participate in th= e discussion (this was not the case in Chicago). 5. My feeling was that if you are not sitting at the table then you a= re just an observer and not a participant. What made this feeling stronger= were the side conversations taking place at the table. My conclusion was that this arrangement may work for a small WG but not for= QUIC Thanks Roni Even --_000_6E58094ECC8D8344914996DAD28F1CCD7AFCD9DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I noticed that the WG chairs asked for a U-shape roo= m similar to the experiment in Chicago

 

I am sorry for not providing feedback before but I f= ound that arrangement very difficult from my perspective, I was sitting on = the side not facing the screen and the room was very packed.

I had the following observations:

 

1.     &= nbsp; It was difficult to unders= tand who is speaking. People sitting at the table started speaking without = stating their name. It is much simpler when they have to go to the micropho= ne and stand at least you can see who is speaking.

2.     &= nbsp; It was inconvenient to loo= k at the presentation screen when you are not facing the screen.  Sitt= ing on a chair with a laptop on your knees and looking sideways to the scre= en was challenging for  my neck. It is simpler if you sit by a table.

3.     &= nbsp; There was no easy path to = go to the microphone for people who were not sitting at the table.  Ag= ain, since the room was very packed there were no path from the side to the= middle where the microphone was.

4.     &= nbsp; When choosing a sit, the s= creen facing sites where far from the screen. I think that having this long= table is part of the problem. Maybe you need a smaller table for less peop= le who really actively participate in the discussion (this was not the case in Chicago).

5.     &= nbsp; My feeling was that if you= are not sitting at the table then you are just an observer and not a parti= cipant.  What made this feeling stronger were the side conversations t= aking place at the table.

 

My conclusion was that this arrangement may work for= a small WG but not for QUIC

 

Thanks

Roni Even

 

 

 

--_000_6E58094ECC8D8344914996DAD28F1CCD7AFCD9DGGEMM506MBXchina_-- From nobody Wed Apr 19 00:33:46 2017 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 A807C131537 for ; Wed, 19 Apr 2017 00:33:44 -0700 (PDT) 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_HELO_PASS=-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 cWuUhKTZExoU for ; Wed, 19 Apr 2017 00:33:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 63F0A131532 for ; Wed, 19 Apr 2017 00:33:42 -0700 (PDT) Received: from [192.168.3.100] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5C9D822E1F3; Wed, 19 Apr 2017 03:33:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Experimental Room Setup (U-Shape and classroom, subject to availability) From: Mark Nottingham In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7AFCD9@DGGEMM506-MBX.china.huawei.com> Date: Wed, 19 Apr 2017 17:33:30 +1000 Cc: "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E58094ECC8D8344914996DAD28F1CCD7AFCD9@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 07:33:45 -0000 Hi Roni, Thanks for the feedback. For what it's worth, we got a lot of other = feedback privately, mostly positive. However, people did point out = issues similar to yours, and we're going to be working with the = Secretariat as well as thinking more carefully about how the meeting is = run to try to improve things in the future.=20 Regards, > On 19 Apr 2017, at 5:10 pm, Roni Even wrote: >=20 > Hi, > I noticed that the WG chairs asked for a U-shape room similar to the = experiment in Chicago > =20 > I am sorry for not providing feedback before but I found that = arrangement very difficult from my perspective, I was sitting on the = side not facing the screen and the room was very packed. > I had the following observations: > =20 > 1. It was difficult to understand who is speaking. People = sitting at the table started speaking without stating their name. It is = much simpler when they have to go to the microphone and stand at least = you can see who is speaking. > 2. It was inconvenient to look at the presentation screen when = you are not facing the screen. Sitting on a chair with a laptop on your = knees and looking sideways to the screen was challenging for my neck. = It is simpler if you sit by a table. > 3. There was no easy path to go to the microphone for people who = were not sitting at the table. Again, since the room was very packed = there were no path from the side to the middle where the microphone was. > 4. When choosing a sit, the screen facing sites where far from = the screen. I think that having this long table is part of the problem. = Maybe you need a smaller table for less people who really actively = participate in the discussion (this was not the case in Chicago). > 5. My feeling was that if you are not sitting at the table then = you are just an observer and not a participant. What made this feeling = stronger were the side conversations taking place at the table. > =20 > My conclusion was that this arrangement may work for a small WG but = not for QUIC > =20 > Thanks > Roni Even -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 19 01:06:55 2017 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 EDE33131559 for ; Wed, 19 Apr 2017 01:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 Gia6TKGzXLbL for ; Wed, 19 Apr 2017 01:06:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1931C131540 for ; Wed, 19 Apr 2017 01:06:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFC83179; Wed, 19 Apr 2017 08:06:49 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 19 Apr 2017 09:06:34 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.133]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 19 Apr 2017 16:06:30 +0800 From: Roni Even To: Mark Nottingham CC: "quic@ietf.org" Subject: RE: Experimental Room Setup (U-Shape and classroom, subject to availability) Thread-Topic: Experimental Room Setup (U-Shape and classroom, subject to availability) Thread-Index: AdK42LYzcgHRAteeSc+wTZzcVrVtI///hvIA//9xZkA= Date: Wed, 19 Apr 2017 08:06:30 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7AFD22@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD7AFCD9@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.202] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58F71A99.0059, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e936541d5262f08b3be9eea08f7c2e33 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 08:06:54 -0000 Hi, I only hope that when considering the feedback, you factored whether the pe= rson was sitting at the table or in the room. I can understand positive fee= dback from people at the table. Roni > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: =E9=E5=ED=A0=E3 19 =E0=F4=F8=E9=EC 2017 10:34 > To: Roni Even > Cc: quic@ietf.org > Subject: Re: Experimental Room Setup (U-Shape and classroom, subject to > availability) >=20 > Hi Roni, >=20 > Thanks for the feedback. For what it's worth, we got a lot of other feedb= ack > privately, mostly positive. However, people did point out issues similar = to > yours, and we're going to be working with the Secretariat as well as thin= king > more carefully about how the meeting is run to try to improve things in t= he > future. >=20 > Regards, >=20 >=20 > > On 19 Apr 2017, at 5:10 pm, Roni Even wrote: > > > > Hi, > > I noticed that the WG chairs asked for a U-shape room similar to the > experiment in Chicago > > > > I am sorry for not providing feedback before but I found that arrangeme= nt > very difficult from my perspective, I was sitting on the side not facing = the > screen and the room was very packed. > > I had the following observations: > > > > 1. It was difficult to understand who is speaking. People sitting= at the > table started speaking without stating their name. It is much simpler whe= n > they have to go to the microphone and stand at least you can see who is > speaking. > > 2. It was inconvenient to look at the presentation screen when yo= u are > not facing the screen. Sitting on a chair with a laptop on your knees an= d > looking sideways to the screen was challenging for my neck. It is simple= r if > you sit by a table. > > 3. There was no easy path to go to the microphone for people who = were > not sitting at the table. Again, since the room was very packed there we= re > no path from the side to the middle where the microphone was. > > 4. When choosing a sit, the screen facing sites where far from th= e > screen. I think that having this long table is part of the problem. Maybe= you > need a smaller table for less people who really actively participate in t= he > discussion (this was not the case in Chicago). > > 5. My feeling was that if you are not sitting at the table then y= ou are just > an observer and not a participant. What made this feeling stronger were = the > side conversations taking place at the table. > > > > My conclusion was that this arrangement may work for a small WG but not > for QUIC > > > > Thanks > > Roni Even >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 From nobody Wed Apr 19 01:41:46 2017 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 B943B131576 for ; Wed, 19 Apr 2017 01:41:44 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 p9tkEfQKbuMJ for ; Wed, 19 Apr 2017 01:41:41 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA5C129493 for ; Wed, 19 Apr 2017 01:41:41 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id C53461B0161A; Wed, 19 Apr 2017 11:36:45 +0100 (BST) Message-ID: <58F722A2.8030600@erg.abdn.ac.uk> Date: Wed, 19 Apr 2017 09:41:06 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roni Even CC: Mark Nottingham , "quic@ietf.org" Subject: Re: Experimental Room Setup (U-Shape and classroom, subject to availability) References: <6E58094ECC8D8344914996DAD28F1CCD7AFCD9@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD7AFD22@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7AFD22@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 08:41:45 -0000 I'm glad this was raised. I found this meeting a really unhelpful one - and the following meeting I attended for HTTPbis was only slightly better. I discovered I had written notes, and they largely echo what Roni said, and since it seems theer was not much critical feedback, I include them below: The whole way a “U” meeting played out had the feeling of remote observation of a panel discussion - an exeperience like watching remotely on meetecho - which is quite good, but I'd hope we could do much better. Many of us follow work across a number of working groups, tracking specific aspects of protocols or interested in how specific IDs relate to the wider working group. I came to the QUIC meeting to find out who the document authors were, and what they and other people thought about the issues that the WG was addressing. This room format worked against this. I really disliked the ways the Chairs had their backs to the room. To me, an important role of the Chairs is to include others and judge the sense of the room. In this setup, the Chairs could not monitor the room. The rest of the room were clearly observors to the discussion around the table. In the case of the meetings I attended the rooms were pretty packed, this was bad. I tried several seating positions before selecting the side area - that presented challenges seeing the screen, but at least you could see some of the people seated at tables and also the presenter. The floor mic was hard to get access to and appeared like you were standing outside the speaker zone. Even from the "floor Mic", I had to speak to the back of some people's heads. It was really hard to see the faces of people and to know who is speaking. Sitting speakers are much more difficult to identify: the plea from the Chairs to raise hands when talking at the tables did (thanks for doing this) at least let me see who was asking a question or addressing a comment, but it was frustrating not to be able to see these people's faces. For me, this is a real down-side. I can see the value for smaller working groups where you can get most people round a table, and the rest of the room really are only observers. If we do repeat this again, can I suggest we completely eliminate the central part of the "U" and set this up as two rows of desks angled slightly towards the rest of the room. That way people can see who is speaking and those speaking can see the rest of the room? Please also place the working group chairs where they can see the entire room (at least for any meeting I will chair). Gorry On 19/04/2017, 09:06, Roni Even wrote: > Hi, > I only hope that when considering the feedback, you factored whether the person was sitting at the table or in the room. I can understand positive feedback from people at the table. > > Roni > >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: éåí ã 19 àôøéì 2017 10:34 >> To: Roni Even >> Cc: quic@ietf.org >> Subject: Re: Experimental Room Setup (U-Shape and classroom, subject to >> availability) >> >> Hi Roni, >> >> Thanks for the feedback. For what it's worth, we got a lot of other feedback >> privately, mostly positive. However, people did point out issues similar to >> yours, and we're going to be working with the Secretariat as well as thinking >> more carefully about how the meeting is run to try to improve things in the >> future. >> >> Regards, >> >> >>> On 19 Apr 2017, at 5:10 pm, Roni Even wrote: >>> >>> Hi, >>> I noticed that the WG chairs asked for a U-shape room similar to the >> experiment in Chicago >>> I am sorry for not providing feedback before but I found that arrangement >> very difficult from my perspective, I was sitting on the side not facing the >> screen and the room was very packed. >>> I had the following observations: >>> >>> 1. It was difficult to understand who is speaking. People sitting at the >> table started speaking without stating their name. It is much simpler when >> they have to go to the microphone and stand at least you can see who is >> speaking. >>> 2. It was inconvenient to look at the presentation screen when you are >> not facing the screen. Sitting on a chair with a laptop on your knees and >> looking sideways to the screen was challenging for my neck. It is simpler if >> you sit by a table. >>> 3. There was no easy path to go to the microphone for people who were >> not sitting at the table. Again, since the room was very packed there were >> no path from the side to the middle where the microphone was. >>> 4. When choosing a sit, the screen facing sites where far from the >> screen. I think that having this long table is part of the problem. Maybe you >> need a smaller table for less people who really actively participate in the >> discussion (this was not the case in Chicago). >>> 5. My feeling was that if you are not sitting at the table then you are just >> an observer and not a participant. What made this feeling stronger were the >> side conversations taking place at the table. >>> My conclusion was that this arrangement may work for a small WG but not >> for QUIC >>> Thanks >>> Roni Even >> -- >> Mark Nottingham https://www.mnot.net/ >> >> >> From nobody Wed Apr 19 01:51:37 2017 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 1037313158E for ; Wed, 19 Apr 2017 01:51:36 -0700 (PDT) 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_HELO_PASS=-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 HCYi9gXllfVK for ; Wed, 19 Apr 2017 01:51:33 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 BBB44131585 for ; Wed, 19 Apr 2017 01:51:32 -0700 (PDT) Received: from [192.168.3.100] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 32B9B22E255; Wed, 19 Apr 2017 04:51:18 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Experimental Room Setup (U-Shape and classroom, subject to availability) From: Mark Nottingham In-Reply-To: <58F722A2.8030600@erg.abdn.ac.uk> Date: Wed, 19 Apr 2017 18:51:15 +1000 Cc: Roni Even , "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2D0676E1-23C6-455D-8A3F-71736AA58D4B@mnot.net> References: <6E58094ECC8D8344914996DAD28F1CCD7AFCD9@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD7AFD22@DGGEMM506-MBX.china.huawei.com> <58F722A2.8030600@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 08:51:36 -0000 Gorry, For what it's worth, your comments mirror much of what we heard, and = what we observed ourselves. We've given feedback along these lines to = the Secretariat, and will be working with them in Prague to make sure = the room is more suited to the work. For those who attended the Interim in Tokyo, that's the sort of layout = we're shooting for. Regards, > On 19 Apr 2017, at 6:41 pm, Gorry Fairhurst = wrote: >=20 > I'm glad this was raised. I found this meeting a really unhelpful one = - and the following meeting I attended for HTTPbis was only slightly = better. >=20 > I discovered I had written notes, and they largely echo what Roni = said, and since it seems theer was not much critical feedback, I include = them below: >=20 > The whole way a =E2=80=9CU=E2=80=9D meeting played out had the = feeling of remote observation of a panel discussion - an exeperience = like watching remotely on meetecho - which is quite good, but I'd hope = we could do much better. Many of us follow work across a number of = working groups, tracking specific aspects of protocols or interested in = how specific IDs relate to the wider working group. I came to the QUIC = meeting to find out who the document authors were, and what they and = other people thought about the issues that the WG was addressing. This = room format worked against this. >=20 > I really disliked the ways the Chairs had their backs to the room. To = me, an important role of the Chairs is to include others and judge the = sense of the room. In this setup, the Chairs could not monitor the room. = The rest of the room were clearly observors to the discussion around the = table. In the case of the meetings I attended the rooms were pretty = packed, this was bad. >=20 > I tried several seating positions before selecting the side area - = that presented challenges seeing the screen, but at least you could see = some of the people seated at tables and also the presenter. >=20 > The floor mic was hard to get access to and appeared like you were = standing outside the speaker zone. Even from the "floor Mic", I had to = speak to the back of some people's heads. >=20 > It was really hard to see the faces of people and to know who is = speaking. Sitting speakers are much more difficult to identify: the plea = from the Chairs to raise hands when talking at the tables did (thanks = for doing this) at least let me see who was asking a question or = addressing a comment, but it was frustrating not to be able to see these = people's faces. For me, this is a real down-side. >=20 > I can see the value for smaller working groups where you can get most = people round a table, and the rest of the room really are only = observers. >=20 > If we do repeat this again, can I suggest we completely eliminate the = central part of the "U" and set this up as two rows of desks angled = slightly towards the rest of the room. That way people can see who is = speaking and those speaking can see the rest of the room? Please also = place the working group chairs where they can see the entire room (at = least for any meeting I will chair). >=20 > Gorry >=20 > On 19/04/2017, 09:06, Roni Even wrote: >> Hi, >> I only hope that when considering the feedback, you factored whether = the person was sitting at the table or in the room. I can understand = positive feedback from people at the table. >>=20 >> Roni >>=20 >>> -----Original Message----- >>> From: Mark Nottingham [mailto:mnot@mnot.net] >>> Sent: =D7=99=D7=95=D7=9D =D7=93 19 =D7=90=D7=A4=D7=A8=D7=99=D7=9C = 2017 10:34 >>> To: Roni Even >>> Cc: quic@ietf.org >>> Subject: Re: Experimental Room Setup (U-Shape and classroom, subject = to >>> availability) >>>=20 >>> Hi Roni, >>>=20 >>> Thanks for the feedback. For what it's worth, we got a lot of other = feedback >>> privately, mostly positive. However, people did point out issues = similar to >>> yours, and we're going to be working with the Secretariat as well as = thinking >>> more carefully about how the meeting is run to try to improve things = in the >>> future. >>>=20 >>> Regards, >>>=20 >>>=20 >>>> On 19 Apr 2017, at 5:10 pm, Roni Even wrote: >>>>=20 >>>> Hi, >>>> I noticed that the WG chairs asked for a U-shape room similar to = the >>> experiment in Chicago >>>> I am sorry for not providing feedback before but I found that = arrangement >>> very difficult from my perspective, I was sitting on the side not = facing the >>> screen and the room was very packed. >>>> I had the following observations: >>>>=20 >>>> 1. It was difficult to understand who is speaking. People = sitting at the >>> table started speaking without stating their name. It is much = simpler when >>> they have to go to the microphone and stand at least you can see who = is >>> speaking. >>>> 2. It was inconvenient to look at the presentation screen = when you are >>> not facing the screen. Sitting on a chair with a laptop on your = knees and >>> looking sideways to the screen was challenging for my neck. It is = simpler if >>> you sit by a table. >>>> 3. There was no easy path to go to the microphone for people = who were >>> not sitting at the table. Again, since the room was very packed = there were >>> no path from the side to the middle where the microphone was. >>>> 4. When choosing a sit, the screen facing sites where far = from the >>> screen. I think that having this long table is part of the problem. = Maybe you >>> need a smaller table for less people who really actively participate = in the >>> discussion (this was not the case in Chicago). >>>> 5. My feeling was that if you are not sitting at the table = then you are just >>> an observer and not a participant. What made this feeling stronger = were the >>> side conversations taking place at the table. >>>> My conclusion was that this arrangement may work for a small WG but = not >>> for QUIC >>>> Thanks >>>> Roni Even >>> -- >>> Mark Nottingham https://www.mnot.net/ >>>=20 >>>=20 >>>=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 19 03:33:54 2017 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 BBBAE129489 for ; Wed, 19 Apr 2017 03:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.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 ZWZerC1voGFj for ; Wed, 19 Apr 2017 03:33:51 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88EE129487 for ; Wed, 19 Apr 2017 03:33:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.37,220,1488873600"; d="scan'208";a="188326973" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 19 Apr 2017 03:20:14 -0700 Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 03:33:31 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 19 Apr 2017 03:33:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eFx4XD6EDIRAaj3qaT+soLUs/+md3rpoH4tMwsjzl8k=; b=CoYkLPNuxV7lOEajqIupyTsdrCVedk7gaSd0eNdYiZY/nLVqaR7ruNyjUbT/f3h5ldapYZF2YikK4C1BkcOdnLwGthouWH2ZHkJ9mCF51LMPFWyKcDPhAwr9OwCc1TF4MP4QaJxhMy4tIm/ylG/yI9s9FPmkP7I41yZqrrENV6M= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 10:33:29 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.1034.018; Wed, 19 Apr 2017 10:33:29 +0000 From: "Eggert, Lars" To: Mark Nottingham CC: "gorry@erg.abdn.ac.uk" , Roni Even , "quic@ietf.org" Subject: Re: Experimental Room Setup (U-Shape and classroom, subject to availability) Thread-Topic: Experimental Room Setup (U-Shape and classroom, subject to availability) Thread-Index: AdK42LYzcgHRAteeSc+wTZzcVrVtIwABoeEAAAEnCwAAATVZAAAAWsCAAAOSAq0= Date: Wed, 19 Apr 2017 10:33:28 +0000 Message-ID: <88B1FBEF-DD50-4024-A727-30BE4C82DA17@netapp.com> References: <6E58094ECC8D8344914996DAD28F1CCD7AFCD9@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD7AFD22@DGGEMM506-MBX.china.huawei.com> <58F722A2.8030600@erg.abdn.ac.uk>, <2D0676E1-23C6-455D-8A3F-71736AA58D4B@mnot.net> In-Reply-To: <2D0676E1-23C6-455D-8A3F-71736AA58D4B@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mnot.net; dkim=none (message not signed) header.d=none;mnot.net; dmarc=none action=none header.from=netapp.com; x-originating-ip: [109.43.3.145] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:8Uug9OGG0x7sWZUUdzl3I2zDZIJkFe/I8+8HYEinc5ZhXL8O/0L5iZA2mrQR0VLLhuiUlflJTMOIwn1FC5WltgG6RaM2ocZLlkbKF8nkgo6MLSfUv6wqxaHCsB+uJzeGbcYCbu50o/A/YaBEtpmM/AwdkSGiVAxgIigdZ9sqfO+bt2B7PeMwIaXtrarDF/8s6s8zA1VABueOz0DOy67dHnwvVlo9LoAsnYE/B3H8EAJQ/sLrZIs5hbd+Lv1ek7lc6IzoeScYyOvdPi2aJX+gk6vpA0U/vur1qKEu9OPy3bX0zEK4P7vPU/aTJecTC9Brpfm+BqwX6g7qp43QsElgvw== x-ms-office365-filtering-correlation-id: 97505b4a-c98c-4a93-29eb-08d4870f850d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0601MB1154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39850400002)(39400400002)(39450400003)(39410400002)(13464003)(51914003)(24454002)(377454003)(51444003)(3846002)(86362001)(36756003)(102836003)(38730400002)(6116002)(25786009)(50986999)(110136004)(53546009)(122556002)(4326008)(66066001)(2906002)(33656002)(189998001)(3280700002)(82746002)(54356999)(76176999)(93886004)(3660700001)(83716003)(8676002)(7736002)(81166006)(305945005)(8936002)(5660300001)(6916009)(229853002)(2950100002)(77096006)(6506006)(6486002)(53936002)(54906002)(6512007)(6306002)(99286003)(2900100001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 10:33:28.9731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 10:33:54 -0000 QW5kIGV2ZXJ5b25lIHNob3VsZCBmZWVsIGZyZWUgdG8gc2VuZCB0aGVpciBmZWVkYmFjayB0byB0 aGUgSUVTRyBkaXJlY3RseSwgYXMgdGhleSB0byBhIGxhcmdlIGRlZ3JlZSBhcmUgaW4gY29udHJv bCBvZiBob3cgdGhpcyBleHBlcmltZW50IGdvZXMgZm9yd2FyZC4NCg0KTGFycw0KDQotLSANClNl bnQgZnJvbSBhIG1vYmlsZSBkZXZpY2U7IHBsZWFzZSBleGN1c2UgdHlwb3MuDQorNDkgMTUxIDEy MCA1NTc5MQ0KDQo+IE9uIEFwciAxOSwgMjAxNywgYXQgMTA6NTIsIE1hcmsgTm90dGluZ2hhbSA8 bW5vdEBtbm90Lm5ldD4gd3JvdGU6DQo+IA0KPiBHb3JyeSwNCj4gDQo+IEZvciB3aGF0IGl0J3Mg d29ydGgsIHlvdXIgY29tbWVudHMgbWlycm9yIG11Y2ggb2Ygd2hhdCB3ZSBoZWFyZCwgYW5kIHdo YXQgd2Ugb2JzZXJ2ZWQgb3Vyc2VsdmVzLiBXZSd2ZSBnaXZlbiBmZWVkYmFjayBhbG9uZyB0aGVz ZSBsaW5lcyB0byB0aGUgU2VjcmV0YXJpYXQsIGFuZCB3aWxsIGJlIHdvcmtpbmcgd2l0aCB0aGVt IGluIFByYWd1ZSB0byBtYWtlIHN1cmUgdGhlIHJvb20gaXMgbW9yZSBzdWl0ZWQgdG8gdGhlIHdv cmsuDQo+IA0KPiBGb3IgdGhvc2Ugd2hvIGF0dGVuZGVkIHRoZSBJbnRlcmltIGluIFRva3lvLCB0 aGF0J3MgdGhlIHNvcnQgb2YgbGF5b3V0IHdlJ3JlIHNob290aW5nIGZvci4NCj4gDQo+IFJlZ2Fy ZHMsDQo+IA0KPiANCj4+IE9uIDE5IEFwciAyMDE3LCBhdCA2OjQxIHBtLCBHb3JyeSBGYWlyaHVy c3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPiB3cm90ZToNCj4+IA0KPj4gSSdtIGdsYWQgdGhpcyB3 YXMgcmFpc2VkLiBJIGZvdW5kIHRoaXMgbWVldGluZyBhIHJlYWxseSB1bmhlbHBmdWwgb25lIC0g YW5kIHRoZSBmb2xsb3dpbmcgbWVldGluZyBJIGF0dGVuZGVkIGZvciBIVFRQYmlzIHdhcyBvbmx5 IHNsaWdodGx5IGJldHRlci4NCj4+IA0KPj4gSSBkaXNjb3ZlcmVkIEkgaGFkIHdyaXR0ZW4gbm90 ZXMsIGFuZCB0aGV5IGxhcmdlbHkgZWNobyB3aGF0IFJvbmkgc2FpZCwgYW5kIHNpbmNlIGl0IHNl ZW1zIHRoZWVyIHdhcyBub3QgbXVjaCBjcml0aWNhbCBmZWVkYmFjaywgSSBpbmNsdWRlIHRoZW0g YmVsb3c6DQo+PiANCj4+IFRoZSB3aG9sZSB3YXkgYSAg4oCcVeKAnSBtZWV0aW5nIHBsYXllZCBv dXQgaGFkIHRoZSBmZWVsaW5nIG9mIHJlbW90ZSBvYnNlcnZhdGlvbiBvZiBhIHBhbmVsIGRpc2N1 c3Npb24gLSBhbiBleGVwZXJpZW5jZSBsaWtlIHdhdGNoaW5nIHJlbW90ZWx5IG9uIG1lZXRlY2hv IC0gd2hpY2ggaXMgcXVpdGUgZ29vZCwgYnV0IEknZCBob3BlIHdlIGNvdWxkIGRvIG11Y2ggYmV0 dGVyLiBNYW55IG9mIHVzIGZvbGxvdyB3b3JrIGFjcm9zcyBhIG51bWJlciBvZiB3b3JraW5nIGdy b3VwcywgdHJhY2tpbmcgc3BlY2lmaWMgYXNwZWN0cyBvZiBwcm90b2NvbHMgb3IgaW50ZXJlc3Rl ZCBpbiBob3cgc3BlY2lmaWMgSURzIHJlbGF0ZSB0byB0aGUgd2lkZXIgd29ya2luZyBncm91cC4g SSBjYW1lIHRvIHRoZSBRVUlDIG1lZXRpbmcgdG8gZmluZCBvdXQgd2hvIHRoZSBkb2N1bWVudCBh dXRob3JzIHdlcmUsIGFuZCB3aGF0IHRoZXkgYW5kIG90aGVyIHBlb3BsZSB0aG91Z2h0IGFib3V0 IHRoZSBpc3N1ZXMgdGhhdCB0aGUgV0cgd2FzIGFkZHJlc3NpbmcuIFRoaXMgcm9vbSBmb3JtYXQg d29ya2VkIGFnYWluc3QgdGhpcy4NCj4+IA0KPj4gSSByZWFsbHkgZGlzbGlrZWQgdGhlIHdheXMg dGhlIENoYWlycyBoYWQgdGhlaXIgYmFja3MgdG8gdGhlIHJvb20uIFRvIG1lLCBhbiBpbXBvcnRh bnQgcm9sZSBvZiB0aGUgQ2hhaXJzIGlzIHRvIGluY2x1ZGUgb3RoZXJzIGFuZCBqdWRnZSB0aGUg c2Vuc2Ugb2YgdGhlIHJvb20uIEluIHRoaXMgc2V0dXAsIHRoZSBDaGFpcnMgY291bGQgbm90IG1v bml0b3IgdGhlIHJvb20uIFRoZSByZXN0IG9mIHRoZSByb29tIHdlcmUgY2xlYXJseSBvYnNlcnZv cnMgdG8gdGhlIGRpc2N1c3Npb24gYXJvdW5kIHRoZSB0YWJsZS4gSW4gdGhlIGNhc2Ugb2YgdGhl IG1lZXRpbmdzIEkgYXR0ZW5kZWQgdGhlIHJvb21zIHdlcmUgcHJldHR5IHBhY2tlZCwgdGhpcyB3 YXMgYmFkLg0KPj4gDQo+PiBJIHRyaWVkIHNldmVyYWwgc2VhdGluZyBwb3NpdGlvbnMgYmVmb3Jl IHNlbGVjdGluZyB0aGUgc2lkZSBhcmVhIC0gdGhhdCBwcmVzZW50ZWQgY2hhbGxlbmdlcyBzZWVp bmcgdGhlIHNjcmVlbiwgYnV0IGF0IGxlYXN0IHlvdSBjb3VsZCBzZWUgc29tZSBvZiB0aGUgcGVv cGxlIHNlYXRlZCBhdCB0YWJsZXMgYW5kIGFsc28gdGhlIHByZXNlbnRlci4NCj4+IA0KPj4gVGhl IGZsb29yIG1pYyB3YXMgaGFyZCB0byBnZXQgYWNjZXNzIHRvIGFuZCBhcHBlYXJlZCBsaWtlIHlv dSB3ZXJlIHN0YW5kaW5nIG91dHNpZGUgdGhlIHNwZWFrZXIgem9uZS4gRXZlbiBmcm9tIHRoZSAi Zmxvb3IgTWljIiwgSSBoYWQgdG8gc3BlYWsgdG8gdGhlIGJhY2sgb2Ygc29tZSBwZW9wbGUncyBo ZWFkcy4NCj4+IA0KPj4gSXQgd2FzIHJlYWxseSBoYXJkIHRvIHNlZSB0aGUgZmFjZXMgb2YgcGVv cGxlIGFuZCB0byBrbm93IHdobyBpcyBzcGVha2luZy4gU2l0dGluZyBzcGVha2VycyBhcmUgbXVj aCBtb3JlIGRpZmZpY3VsdCB0byBpZGVudGlmeTogdGhlIHBsZWEgZnJvbSB0aGUgQ2hhaXJzIHRv IHJhaXNlIGhhbmRzIHdoZW4gdGFsa2luZyBhdCB0aGUgdGFibGVzIGRpZCAodGhhbmtzIGZvciBk b2luZyB0aGlzKSBhdCBsZWFzdCBsZXQgbWUgc2VlIHdobyB3YXMgYXNraW5nIGEgcXVlc3Rpb24g b3IgYWRkcmVzc2luZyBhIGNvbW1lbnQsIGJ1dCBpdCB3YXMgZnJ1c3RyYXRpbmcgbm90IHRvIGJl IGFibGUgdG8gc2VlIHRoZXNlIHBlb3BsZSdzIGZhY2VzLiBGb3IgbWUsIHRoaXMgaXMgYSByZWFs IGRvd24tc2lkZS4NCj4+IA0KPj4gSSBjYW4gc2VlIHRoZSB2YWx1ZSBmb3Igc21hbGxlciB3b3Jr aW5nIGdyb3VwcyB3aGVyZSB5b3UgY2FuIGdldCBtb3N0IHBlb3BsZSByb3VuZCBhIHRhYmxlLCBh bmQgdGhlIHJlc3Qgb2YgdGhlIHJvb20gcmVhbGx5IGFyZSBvbmx5IG9ic2VydmVycy4NCj4+IA0K Pj4gSWYgd2UgZG8gcmVwZWF0IHRoaXMgYWdhaW4sIGNhbiBJIHN1Z2dlc3Qgd2UgY29tcGxldGVs eSBlbGltaW5hdGUgdGhlIGNlbnRyYWwgcGFydCBvZiB0aGUgIlUiIGFuZCBzZXQgdGhpcyB1cCBh cyB0d28gcm93cyBvZiBkZXNrcyBhbmdsZWQgc2xpZ2h0bHkgdG93YXJkcyB0aGUgcmVzdCAgb2Yg dGhlIHJvb20uIFRoYXQgd2F5IHBlb3BsZSBjYW4gc2VlIHdobyBpcyBzcGVha2luZyBhbmQgdGhv c2Ugc3BlYWtpbmcgY2FuIHNlZSB0aGUgcmVzdCBvZiB0aGUgcm9vbT8gUGxlYXNlIGFsc28gcGxh Y2UgdGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIHdoZXJlIHRoZXkgY2FuIHNlZSB0aGUgZW50aXJl IHJvb20gKGF0IGxlYXN0IGZvciBhbnkgbWVldGluZyBJIHdpbGwgY2hhaXIpLg0KPj4gDQo+PiBH b3JyeQ0KPj4gDQo+Pj4gT24gMTkvMDQvMjAxNywgMDk6MDYsIFJvbmkgRXZlbiB3cm90ZToNCj4+ PiBIaSwNCj4+PiBJIG9ubHkgaG9wZSB0aGF0IHdoZW4gY29uc2lkZXJpbmcgdGhlIGZlZWRiYWNr LCB5b3UgZmFjdG9yZWQgd2hldGhlciB0aGUgcGVyc29uIHdhcyBzaXR0aW5nIGF0IHRoZSB0YWJs ZSBvciBpbiB0aGUgcm9vbS4gSSBjYW4gdW5kZXJzdGFuZCBwb3NpdGl2ZSBmZWVkYmFjayBmcm9t IHBlb3BsZSBhdCB0aGUgdGFibGUuDQo+Pj4gDQo+Pj4gUm9uaQ0KPj4+IA0KPj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBNYXJrIE5vdHRpbmdoYW0gW21haWx0bzpt bm90QG1ub3QubmV0XQ0KPj4+PiBTZW50OiDXmdeV150g15MgMTkg15DXpNeo15nXnCAyMDE3IDEw OjM0DQo+Pj4+IFRvOiBSb25pIEV2ZW4NCj4+Pj4gQ2M6IHF1aWNAaWV0Zi5vcmcNCj4+Pj4gU3Vi amVjdDogUmU6IEV4cGVyaW1lbnRhbCBSb29tIFNldHVwIChVLVNoYXBlIGFuZCBjbGFzc3Jvb20s IHN1YmplY3QgdG8NCj4+Pj4gYXZhaWxhYmlsaXR5KQ0KPj4+PiANCj4+Pj4gSGkgUm9uaSwNCj4+ Pj4gDQo+Pj4+IFRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBGb3Igd2hhdCBpdCdzIHdvcnRoLCB3 ZSBnb3QgYSBsb3Qgb2Ygb3RoZXIgZmVlZGJhY2sNCj4+Pj4gcHJpdmF0ZWx5LCBtb3N0bHkgcG9z aXRpdmUuIEhvd2V2ZXIsIHBlb3BsZSBkaWQgcG9pbnQgb3V0IGlzc3VlcyBzaW1pbGFyIHRvDQo+ Pj4+IHlvdXJzLCBhbmQgd2UncmUgZ29pbmcgdG8gYmUgd29ya2luZyB3aXRoIHRoZSBTZWNyZXRh cmlhdCBhcyB3ZWxsIGFzIHRoaW5raW5nDQo+Pj4+IG1vcmUgY2FyZWZ1bGx5IGFib3V0IGhvdyB0 aGUgbWVldGluZyBpcyBydW4gdG8gdHJ5IHRvIGltcHJvdmUgdGhpbmdzIGluIHRoZQ0KPj4+PiBm dXR1cmUuDQo+Pj4+IA0KPj4+PiBSZWdhcmRzLA0KPj4+PiANCj4+Pj4gDQo+Pj4+PiBPbiAxOSBB cHIgMjAxNywgYXQgNToxMCBwbSwgUm9uaSBFdmVuPHJvbmkuZXZlbkBodWF3ZWkuY29tPiAgd3Jv dGU6DQo+Pj4+PiANCj4+Pj4+IEhpLA0KPj4+Pj4gSSBub3RpY2VkIHRoYXQgdGhlIFdHIGNoYWly cyBhc2tlZCBmb3IgYSBVLXNoYXBlIHJvb20gc2ltaWxhciB0byB0aGUNCj4+Pj4gZXhwZXJpbWVu dCBpbiBDaGljYWdvDQo+Pj4+PiBJIGFtIHNvcnJ5IGZvciBub3QgcHJvdmlkaW5nIGZlZWRiYWNr IGJlZm9yZSBidXQgSSBmb3VuZCB0aGF0IGFycmFuZ2VtZW50DQo+Pj4+IHZlcnkgZGlmZmljdWx0 IGZyb20gbXkgcGVyc3BlY3RpdmUsIEkgd2FzIHNpdHRpbmcgb24gdGhlIHNpZGUgbm90IGZhY2lu ZyB0aGUNCj4+Pj4gc2NyZWVuIGFuZCB0aGUgcm9vbSB3YXMgdmVyeSBwYWNrZWQuDQo+Pj4+PiBJ IGhhZCB0aGUgZm9sbG93aW5nIG9ic2VydmF0aW9uczoNCj4+Pj4+IA0KPj4+Pj4gMS4gICAgICAg SXQgd2FzIGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kIHdobyBpcyBzcGVha2luZy4gUGVvcGxlIHNp dHRpbmcgYXQgdGhlDQo+Pj4+IHRhYmxlIHN0YXJ0ZWQgc3BlYWtpbmcgd2l0aG91dCBzdGF0aW5n IHRoZWlyIG5hbWUuIEl0IGlzIG11Y2ggc2ltcGxlciB3aGVuDQo+Pj4+IHRoZXkgaGF2ZSB0byBn byB0byB0aGUgbWljcm9waG9uZSBhbmQgc3RhbmQgYXQgbGVhc3QgeW91IGNhbiBzZWUgd2hvIGlz DQo+Pj4+IHNwZWFraW5nLg0KPj4+Pj4gMi4gICAgICAgSXQgd2FzIGluY29udmVuaWVudCB0byBs b29rIGF0IHRoZSBwcmVzZW50YXRpb24gc2NyZWVuIHdoZW4geW91IGFyZQ0KPj4+PiBub3QgZmFj aW5nIHRoZSBzY3JlZW4uICBTaXR0aW5nIG9uIGEgY2hhaXIgd2l0aCBhIGxhcHRvcCBvbiB5b3Vy IGtuZWVzIGFuZA0KPj4+PiBsb29raW5nIHNpZGV3YXlzIHRvIHRoZSBzY3JlZW4gd2FzIGNoYWxs ZW5naW5nIGZvciAgbXkgbmVjay4gSXQgaXMgc2ltcGxlciBpZg0KPj4+PiB5b3Ugc2l0IGJ5IGEg dGFibGUuDQo+Pj4+PiAzLiAgICAgICBUaGVyZSB3YXMgbm8gZWFzeSBwYXRoIHRvIGdvIHRvIHRo ZSBtaWNyb3Bob25lIGZvciBwZW9wbGUgd2hvIHdlcmUNCj4+Pj4gbm90IHNpdHRpbmcgYXQgdGhl IHRhYmxlLiAgQWdhaW4sIHNpbmNlIHRoZSByb29tIHdhcyB2ZXJ5IHBhY2tlZCB0aGVyZSB3ZXJl DQo+Pj4+IG5vIHBhdGggZnJvbSB0aGUgc2lkZSB0byB0aGUgbWlkZGxlIHdoZXJlIHRoZSBtaWNy b3Bob25lIHdhcy4NCj4+Pj4+IDQuICAgICAgIFdoZW4gY2hvb3NpbmcgYSBzaXQsIHRoZSBzY3Jl ZW4gZmFjaW5nIHNpdGVzIHdoZXJlIGZhciBmcm9tIHRoZQ0KPj4+PiBzY3JlZW4uIEkgdGhpbmsg dGhhdCBoYXZpbmcgdGhpcyBsb25nIHRhYmxlIGlzIHBhcnQgb2YgdGhlIHByb2JsZW0uIE1heWJl IHlvdQ0KPj4+PiBuZWVkIGEgc21hbGxlciB0YWJsZSBmb3IgbGVzcyBwZW9wbGUgd2hvIHJlYWxs eSBhY3RpdmVseSBwYXJ0aWNpcGF0ZSBpbiB0aGUNCj4+Pj4gZGlzY3Vzc2lvbiAodGhpcyB3YXMg bm90IHRoZSBjYXNlIGluIENoaWNhZ28pLg0KPj4+Pj4gNS4gICAgICAgTXkgZmVlbGluZyB3YXMg dGhhdCBpZiB5b3UgYXJlIG5vdCBzaXR0aW5nIGF0IHRoZSB0YWJsZSB0aGVuIHlvdSBhcmUganVz dA0KPj4+PiBhbiBvYnNlcnZlciBhbmQgbm90IGEgcGFydGljaXBhbnQuICBXaGF0IG1hZGUgdGhp cyBmZWVsaW5nIHN0cm9uZ2VyIHdlcmUgdGhlDQo+Pj4+IHNpZGUgY29udmVyc2F0aW9ucyB0YWtp bmcgcGxhY2UgYXQgdGhlIHRhYmxlLg0KPj4+Pj4gTXkgY29uY2x1c2lvbiB3YXMgdGhhdCB0aGlz IGFycmFuZ2VtZW50IG1heSB3b3JrIGZvciBhIHNtYWxsIFdHIGJ1dCBub3QNCj4+Pj4gZm9yIFFV SUMNCj4+Pj4+IFRoYW5rcw0KPj4+Pj4gUm9uaSBFdmVuDQo+Pj4+IC0tDQo+Pj4+IE1hcmsgTm90 dGluZ2hhbSAgIGh0dHBzOi8vd3d3Lm1ub3QubmV0Lw0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4g DQo+IA0KPiAtLQ0KPiBNYXJrIE5vdHRpbmdoYW0gICBodHRwczovL3d3dy5tbm90Lm5ldC8NCj4g DQo+IA0KPiANCj4gDQo= From nobody Wed Apr 19 04:29:45 2017 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 54AAE1294B7 for ; Wed, 19 Apr 2017 04:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 b7V6xJ86RPSn for ; Wed, 19 Apr 2017 04:29:40 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 36D791294C0 for ; Wed, 19 Apr 2017 04:29:40 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j9so8974847ywj.3 for ; Wed, 19 Apr 2017 04:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qnnr19q4I89UB7KEpYpSk9BWfHXEIDS3sZ/g+Kn1T4Q=; b=Eoy/BQvfKhhwBYdtqUs9u1A6Zuv+O0tEP1QQiCbyNJP+gMlo9OhzSYk0UJuLlyvY2w 0MFta+foS5iWMRlwhdEb/1cv8STl60xeoJQ7vkS895B3G2tlI9HmFpIYt/xRCqa3f4FP 8Z6ognwbE+f19GQj2cGvr0GV5iSrWw4WLpHfPNoxploJIn+slCgDr9OzUjfnXI5DX26u 5DUppKTv/dA/ltwaTA+V29Sx71tA3OrRX3Mn/8qdZMxsqYyKixQhHeIeAJklvA1ENnxq R86dRiourgzc5I0Fw3xg0KaAbZ9lgjCJvGZOcAXLJYP/b2r2f5kuBkF77CJAPm8xv002 UluA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qnnr19q4I89UB7KEpYpSk9BWfHXEIDS3sZ/g+Kn1T4Q=; b=Dl0zujuGAMpEo/CS00dvz/F/QP4ll449L6EFj7f00fwE1pIbwdV2dL4o0vGKlZzW4i jaF65xMPCuFc8hprWwo0KmlBqCLNRYm9X7p1wWbnbhOdg/UyzdEDgerph8mu3ZPb2mOj 5Zba1Zv14yhjDtI+U3vLQChyXi1EJ37OluUe2FWXGB0mZ5gSzXgDsLF1XrJQ58mGN84A sz3VaffJlLVoVNQSig1iCLMirpbaWEK8UlqVYPE9fS9vHJmTmbNwcFuXakn+KmEa/yC5 KZCvJg/VI7Q7fusZb8IdSv7Xt0GIRcyQrs2PlQHigrVyHOZPTHxgE9o5dRMCHr2pnj3q 2g6w== X-Gm-Message-State: AN3rC/46C9kyvyY80Xa0SiTGETi96r2/lOaR+V4l1OVoHJJM8/X444Xm 3HUnE8/xzQ6kz5a5PAm7uH4qlYQDVw== X-Received: by 10.13.203.73 with SMTP id n70mr1640561ywd.71.1492601379070; Wed, 19 Apr 2017 04:29:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 19 Apr 2017 04:28:58 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 19 Apr 2017 07:28:58 -0400 Message-ID: Subject: Re: Key change logic To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114fd3d6fdc1f7054d8356bf Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 11:29:42 -0000 --001a114fd3d6fdc1f7054d8356bf Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 7:46 PM, Martin Thomson wrote: > Yep, I followed your logic here and you are right: > > Anything that doesn't decrypt has to be thrown away (no connection > closes on unauthenticated rubbish) > > For the sequence P=1,N=15; P=0;N=20 without ever sending with P=1, the > second packet should be discarded rather than trying with G=2. > > (The awkward thing is that you probably need to have more than two > generations of receive keys in play in the case you DO send with P=1 > here.) > As far as I can tell, this only happens if someone changes keys really often, and that seems like "it hurts when I do that". I mean, yeah, you could compensate for this, but I think better to give guidance not to change keys more than once in MSL. -Ekr > For the sequence P=1,N=15; P=1,N=12; P=0,N=14 the third packet should > be discarded. > > > > On 14 April 2017 at 06:49, Eric Rescorla wrote: > > I'm not sure that the logic around key changes is exactly clear. > > > > Case 1: > > Assume you are in steady state where you have just received a packet > > with key generation G = 0, key phase bit P = 1, and packet number PN = > > 10 (i.e., there have been no key changes so far). You now receive a > > packet with PN = 15, P = 1. Turning to 6.2, we see: > > > > A receiving endpoint detects an update when the KEY_PHASE bit doesn't > > match what it is expecting. It creates a new secret (see > > Section 5.2) and the corresponding read key and IV. If the packet > > can be decrypted and authenticated using these values, then the keys > > it uses for packet protection are also updated. The next packet sent > > by the endpoint will then use the new keys. > > > > An endpoint doesn't need to send packets immediately when it detects > > that its peer has updated keys. The next packet that it sends will > > simply use the new keys. If an endpoint detects a second update > > before it has sent any packets with updated keys it indicates that > > its peer has updated keys twice without awaiting a reciprocal update. > > An endpoint MUST treat consecutive key updates as a fatal error and > > abort the connection. > > > > So, we compute generation G=1 and try to decrypt the packet. If it > > succeeds, we install key G=1 with the knowledge that the transition > > happens somewhere between 10 and 15. > > > > > > Case 2: > > The same as Case #1, but I receive PN = 7, P = 1. I think what we do > > then is just discard the packet immediately because it's impossible, > > right? Not clear where the text says that. > > > > > > Case 3: > > Imagine we are in the state right after case #1 (i.e., we have sent no > > packets) and now we receive a packet PN = 20, P = 0. Now, this looks > > like a second key change, so what do we do now? It seems like we have > > three choices: > > > > 1. Discard it because it's clearly illegal. > > 2. Try to decrypt it with key G=2 and process it as a key change (as > > the first paragraph of the citation above graf tells us to do). > > 3. Tear down the connection as specified in the second paragraph > > above tells us to do. > > > > #2 seems pretty silly, because only one of two things can happen > > > > (a) We can't decrypt it because it's bogus and we discard it. > > (b) We can decrypt it (because the keys have been compromised > > or the other side is misbehaving) in which case we tear > > down the connection. > > > > But it's almost certainly (a), so this doesn't seem like a good > > use of resources. > > > > #3 is even worse, because it means that anyone can send us an > > unauthenticated packet and tear down the connection, so that > > can't be right. > > > > I think that leaves us with #2 as the right answer, but that's > > the one thing that the spec doesn't tell us to do, and it renders > > the second paragraph above irrelevant. > > > > > > Case 4: > > The same as case #1, but next I receive two packets: > > > > - PN = 12, P = 1 [which decrypts with key G = 1] > > - PN = 14, P = 0 > > > > Now, this second packet is impossible because we know that that > > we have: > > > > PN = 10 [G = 0] > > PN = 12 [G = 1] > > PN = 15 [G = 1] > > > > So we can't have a key change between 12 and 15, so here we are. The > > spec doesn't give guidance on what to do. I think the answer is > > "discard the packet". > > > > > > I think we need to write these sections a bit more clearly. I'm > > happy to take a crack at it, but I'd like to make sure that we all > > agree that the behaviors above are the right ones. > > > > -Ekr > > > --001a114fd3d6fdc1f7054d8356bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 18, 2017 at 7:46 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
Yep, I f= ollowed your logic here and you are right:

Anything that doesn't decrypt has to be thrown away (no connection
closes on unauthenticated rubbish)

For the sequence P=3D1,N=3D15; P=3D0;N=3D20 without ever sending with P=3D1= , the
second packet should be discarded rather than trying with G=3D2.

(The awkward thing is that you probably need to have more than two
generations of receive keys in play in the case you DO send with P=3D1
here.)

As far as I can tell, this only = happens if someone changes keys really often, and
that seems like= "it hurts when I do that". I mean, yeah, you could compensate
for this, but I think better to give guidance not to change keys mo= re than once
in MSL.

-Ekr

=

For the sequence P=3D1,N=3D15; P=3D1,N=3D12; P=3D0,N=3D14 the third packet = should
be discarded.



On 14 April 2017 at 06:49, Eric Rescorla <ekr@rtfm.com> wrote:
> I'm not sure that the logic around key changes is exactly clear. >
> Case 1:
> Assume you are in steady state where you have just received a packet > with key generation G =3D 0, key phase bit P =3D 1, and packet number = PN =3D
> 10 (i.e., there have been no key changes so far). You now receive a > packet with PN =3D 15, P =3D 1. Turning to 6.2, we see:
>
>=C2=A0 =C2=A0 A receiving endpoint detects an update when the KEY_PHASE= bit doesn't
>=C2=A0 =C2=A0 match what it is expecting.=C2=A0 It creates a new secret= (see
>=C2=A0 =C2=A0 Section 5.2) and the corresponding read key and IV.=C2=A0= If the packet
>=C2=A0 =C2=A0 can be decrypted and authenticated using these values, th= en the keys
>=C2=A0 =C2=A0 it uses for packet protection are also updated.=C2=A0 The= next packet sent
>=C2=A0 =C2=A0 by the endpoint will then use the new keys.
>
>=C2=A0 =C2=A0 An endpoint doesn't need to send packets immediately = when it detects
>=C2=A0 =C2=A0 that its peer has updated keys.=C2=A0 The next packet tha= t it sends will
>=C2=A0 =C2=A0 simply use the new keys.=C2=A0 If an endpoint detects a s= econd update
>=C2=A0 =C2=A0 before it has sent any packets with updated keys it indic= ates that
>=C2=A0 =C2=A0 its peer has updated keys twice without awaiting a recipr= ocal update.
>=C2=A0 =C2=A0 An endpoint MUST treat consecutive key updates as a fatal= error and
>=C2=A0 =C2=A0 abort the connection.
>
> So, we compute generation G=3D1 and try to decrypt the packet. If it > succeeds, we install key G=3D1 with the knowledge that the transition<= br> > happens somewhere between 10 and 15.
>
>
> Case 2:
> The same as Case #1, but I receive PN =3D 7, P =3D 1. I think what we = do
> then is just discard the packet immediately because it's impossibl= e,
> right? Not clear where the text says that.
>
>
> Case 3:
> Imagine we are in the state right after case #1 (i.e., we have sent no=
> packets) and now we receive a packet PN =3D 20, P =3D 0. Now, this loo= ks
> like a second key change, so what do we do now? It seems like we have<= br> > three choices:
>
> 1. Discard it because it's clearly illegal.
> 2. Try to decrypt it with key G=3D2 and process it as a key change (as=
>=C2=A0 =C2=A0 the first paragraph of the citation above graf tells us t= o do).
> 3. Tear down the connection as specified in the second paragraph
>=C2=A0 =C2=A0 above tells us to do.
>
> #2 seems pretty silly, because only one of two things can happen
>
> (a) We can't decrypt it because it's bogus and we discard it.<= br> > (b) We can decrypt it (because the keys have been compromised
>=C2=A0 =C2=A0 =C2=A0or the other side is misbehaving) in which case we = tear
>=C2=A0 =C2=A0 =C2=A0down the connection.
>
> But it's almost certainly (a), so this doesn't seem like a goo= d
> use of resources.
>
> #3 is even worse, because it means that anyone can send us an
> unauthenticated packet and tear down the connection, so that
> can't be right.
>
> I think that leaves us with #2 as the right answer, but that's
> the one thing that the spec doesn't tell us to do, and it renders<= br> > the second paragraph above irrelevant.
>
>
> Case 4:
> The same as case #1, but next I receive two packets:
>
> - PN =3D 12, P =3D 1 [which decrypts with key G =3D 1]
> - PN =3D 14, P =3D 0
>
> Now, this second packet is impossible because we know that that
> we have:
>
>=C2=A0 =C2=A0PN =3D 10 [G =3D 0]
>=C2=A0 =C2=A0PN =3D 12 [G =3D 1]
>=C2=A0 =C2=A0PN =3D 15 [G =3D 1]
>
> So we can't have a key change between 12 and 15, so here we are. T= he
> spec doesn't give guidance on what to do. I think the answer is > "discard the packet".
>
>
> I think we need to write these sections a bit more clearly. I'm > happy to take a crack at it, but I'd like to make sure that we all=
> agree that the behaviors above are the right ones.
>
> -Ekr
>

--001a114fd3d6fdc1f7054d8356bf-- From nobody Wed Apr 19 04:33:04 2017 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 32C581294C3 for ; Wed, 19 Apr 2017 04:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 P-UOmBr25QM5 for ; Wed, 19 Apr 2017 04:33:01 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98B31294AB for ; Wed, 19 Apr 2017 04:33:01 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id j9so9008236ywj.3 for ; Wed, 19 Apr 2017 04:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NU76jOYAQGZ8PJNjXpsj9d7j6eLkaIoJe9dmeyYuzME=; b=yShW8Kno8qCax3LwYwELsjUIREy+j8Nrrpz9zT0kcolXMjNPV9vCPts4TVWq4Uqpc6 W4K4pqSO6WNF64MIhBctyPKUukKafrS4wdOSTHPpWQr4qhIhrwElVYFjGzudtWsXk9Wh k1uHXt6rWCpouaEkB692ikJ7X6+OJrWXIFAYhVKQ2pGRaFx4cv6ST/joYvb9RmGTreIX xeXWY3D5koGL8aKexpxtgNMV7EJIAI+OH5eIR6R8xfKVPuZL6WYj6qs9hxzds1gNmgYA iqtLjh5YyhXqEHZMPM/NcaQgqHXSOcmMh8JJYveyl8guaciRG6yOoHYyMNN1ABeq4xTZ +41Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NU76jOYAQGZ8PJNjXpsj9d7j6eLkaIoJe9dmeyYuzME=; b=bWUqae/rfX7XxGHxv8Hn1pgGJGuv6kCHlutaLzd4YE+Fcrm07LvKRPfdtNFz0uorgN hgokb0FrVcqr10ZNzpzXFU1T6S+5FLjEzdrI8t37olw3wHdPNimZ8scSiEMhg9z+9iVJ 8PsiCyyEWydhdtW6o91PcEDw472RMeuGoRcss8pu8yN3Xv3U/Rb732hQRERd3otKBlls nrhv5ezPrzgxN6fbzrw6VoK2lB2CecqA810AuTXGywynyMoLsd2g9t9/WV/203hZaHQf /FMCBpVGTcE99ENWeJDs1NLWg3mRYlJdE+GGBoSWII/uTSfIE4K/0QncWrC6v3Y7TSzm MXfA== X-Gm-Message-State: AN3rC/7vhB9Rxv8/lVsHUJd10XUQnqF4gwl6MMsHmB2OzFNr5vo2lIKT wTTkaRgW46V+lUl5Tj1NoAOHSQ5TPg== X-Received: by 10.129.51.131 with SMTP id z125mr1725908ywz.87.1492601581023; Wed, 19 Apr 2017 04:33:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 19 Apr 2017 04:32:20 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 19 Apr 2017 07:32:20 -0400 Message-ID: Subject: Re: Sending/Receiving packets before client Finished To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1142165c074e69054d836358 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 11:33:03 -0000 --001a1142165c074e69054d836358 Content-Type: text/plain; charset=UTF-8 OK. If so, I think we should probably do something about the HOL blocking on FInished. This draft proposes one approach, which is send Finished a lot. I am aware of at least two others: 1. Add a length field to the long header and stuff Finished and app data in the same UDP datagram (probably my preferred approach) 2. Do what TLS does not do (though DTLS will have to confront) and allow application data to be received prior to Finished (the analysis in OPTLS suggests that if you are willing to sacrifice key confirmation this is okish, but would need a lot more thought). -Ekr On Tue, Apr 18, 2017 at 7:48 PM, Martin Thomson wrote: > That sounds right. The change to allow receipt after validating the > PSK binder is new, so there are almost certainly some editing errors. > > On 14 April 2017 at 06:19, Eric Rescorla wrote: > > Rereading the -tls draft, it's not entirely clear to me what the > > rules are around the client's Finished. I think the rules you > > are applying (on the server, because the client has no such issues): > > > > - The server can process 0-RTT messages immediately (S 8.2) > > - The server can process 1-RTT messages upon receiving either > > the client's Finished or the PSK binder (S 8.3) [0] > > - The server can send messages with the 1-RTT keys upon sending > > Finished, either in 0.5 RTT or in 1-RTT. (implied in S 4.2.3) > > > > Do I understand this correctly? If so, I may have some proposed > > changes, but I'd like to understand the intention first. > > > > Thanks, > > -Ekr > > > > > > [0] Though it's actually sort of confusing because the second > > graf permits the Finished or the PSK binder and the last graf > > says you can't use packets before Finished if you depend on > > client auth. > > > --001a1142165c074e69054d836358 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK. = If so, I think we should probably do something about the HOL blocking
=
on FInished. This draft proposes one approach, w= hich is send Finished a lot.
I am aware of = at least two others:

1. Add a length field to the long header and stuff Finishe= d and app data in the same UDP datagram (probably my preferred approach)
2. Do what TLS does not do (though DTLS will = have to confront) and allow application data to be received prior to Finish= ed (the analysis in OPTLS suggests that if you are willing to sacrifice key= confirmation this is okish, but would need a lot more thought).

-Ekr


On Tue, Apr 18, 2017 at 7:48 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
That sounds right.=C2=A0 The change to allow receipt after validati= ng the
PSK binder is new, so there are almost certainly some editing errors.

On 14 April 2017 at 06:19, Eric Rescorla <ekr@rtfm.com> wrote:
> Rereading the -tls draft, it's not entirely clear to me what the > rules are around the client's Finished. I think the rules you
> are applying (on the server, because the client has no such issues): >
> - The server can process 0-RTT messages immediately (S 8.2)
> - The server can process 1-RTT messages upon receiving either
>=C2=A0 =C2=A0the client's Finished or the PSK binder (S 8.3) [0] > - The server can send messages with the 1-RTT keys upon sending
>=C2=A0 =C2=A0Finished, either in 0.5 RTT or in 1-RTT. (implied in S 4.2= .3)
>
> Do I understand this correctly? If so, I may have some proposed
> changes, but I'd like to understand the intention first.
>
> Thanks,
> -Ekr
>
>
> [0] Though it's actually sort of confusing because the second
> graf permits the Finished or the PSK binder and the last graf
> says you can't use packets before Finished if you depend on
> client auth.
>

--001a1142165c074e69054d836358-- From nobody Wed Apr 19 08:56:43 2017 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 19D83128854 for ; Wed, 19 Apr 2017 08:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 3q9jANIB2oTh for ; Wed, 19 Apr 2017 08:56:39 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 C6ADB128CDB for ; Wed, 19 Apr 2017 08:56:38 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u70so13850342ywe.2 for ; Wed, 19 Apr 2017 08:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QJiK8jAx0l+biM4+3lSOLro9c8ICNSX4FLWmqkqRjDg=; b=IexJoVkZPFPp8H8w9Eamd0xxkaxPNT089ums1XEOw/9QXxopD/04aK/tBWDszu69sv R4e1r/3+GJCKeY9qHZ/Stl4LhkfAX/BFTlP7cT726G9bUU22GJTO5Kg058+GCFUu97lq qS4qYQWGtFij5KT1yLgKfx5EmJmc8mVPtk008oHszPNlcmWyqo2sXs++LCS+yOVsabZR nFm1spNyQmj0MwoAgY4uaAy5l++bTvrxF+Ohuv50lUOG8imk6JA1Qy/Du+180Nrzx/tI e3ENWfDyaEHxQgW3WzZCTjswSP4uAj0SS1pgKz6TIjw78sX1MYBUwGLyuViNWhJvJ22A EZUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QJiK8jAx0l+biM4+3lSOLro9c8ICNSX4FLWmqkqRjDg=; b=OuXBpOnb6WJxx922jurT8RMeHj7rrzxmxd2zAfQndPJjv2kzLkGBhMPHubT3hSfgBo Zk69pdjZDuL4vhFH2qh+s4OX3o7jiXow6ywisXd+L9uRREMwM3iJ6YY9uNTkjP2Uy4T1 ZbXN+/t+j7V1UgVGN8rx4uWPG3lcokrBVwrpHnc2hrlAbMRYs8c8/R7HH0oHZIp1kJFF wYRgzjjJOML/71sJCOT6qvLvdZQlH5yi0CEXIpzXLJb7rv+rDGHpmVxNoPzNpAInBVc7 XoN6167otTGGqb34/xjea+Pe5mOUNeWK4owwcOUtuLh4ty4nnGxLITUHkwBto7u6WC4n wgbA== X-Gm-Message-State: AN3rC/6DmrOKuN06TISQpxSUMct4YHGPXTUMBbYyYS9tp76sm5F47cJH xfHsGN3xxKP+07qEh/+Z/azDwWjnLw== X-Received: by 10.129.91.87 with SMTP id p84mr2620786ywb.347.1492617398017; Wed, 19 Apr 2017 08:56:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Wed, 19 Apr 2017 08:56:37 -0700 (PDT) Received: by 10.37.73.129 with HTTP; Wed, 19 Apr 2017 08:56:37 -0700 (PDT) In-Reply-To: <88B1FBEF-DD50-4024-A727-30BE4C82DA17@netapp.com> References: <6E58094ECC8D8344914996DAD28F1CCD7AFCD9@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD7AFD22@DGGEMM506-MBX.china.huawei.com> <58F722A2.8030600@erg.abdn.ac.uk> <2D0676E1-23C6-455D-8A3F-71736AA58D4B@mnot.net> <88B1FBEF-DD50-4024-A727-30BE4C82DA17@netapp.com> From: Spencer Dawkins at IETF Date: Wed, 19 Apr 2017 10:56:37 -0500 Message-ID: Subject: Re: Experimental Room Setup (U-Shape and classroom, subject to availability) To: Lars Eggert Cc: IETF QUIC WG , Roni Even , Mark Nottingham , "gorry@erg.abdn.ac.uk" Content-Type: multipart/alternative; boundary=001a114c7192cb694f054d87118c Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 15:56:42 -0000 --001a114c7192cb694f054d87118c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If I might inject here ... On Apr 19, 2017 05:33, "Eggert, Lars" wrote: And everyone should feel free to send their feedback to the IESG directly, as they to a large degree are in control of how this experiment goes forward. I'm absolutely watching the discussion on this subject, here and elsewhere. Lars is correct to encourage people to send feedback to the IESG. One thing I haven't seen much feedback about, was the experience for remote participants with this room layout, compared to other meeting sessions. If you participated remotely and can provide feedback, I'd find that especially useful. Thanks, Spencer, as responsible AD Lars -- Sent from a mobile device; please excuse typos. +49 151 120 55791 > On Apr 19, 2017, at 10:52, Mark Nottingham wrote: > > Gorry, > > For what it's worth, your comments mirror much of what we heard, and what we observed ourselves. We've given feedback along these lines to the Secretariat, and will be working with them in Prague to make sure the room is more suited to the work. > > For those who attended the Interim in Tokyo, that's the sort of layout we're shooting for. > > Regards, > > >> On 19 Apr 2017, at 6:41 pm, Gorry Fairhurst wrote= : >> >> I'm glad this was raised. I found this meeting a really unhelpful one - and the following meeting I attended for HTTPbis was only slightly better. >> >> I discovered I had written notes, and they largely echo what Roni said, and since it seems theer was not much critical feedback, I include them below: >> >> The whole way a =E2=80=9CU=E2=80=9D meeting played out had the feeling = of remote observation of a panel discussion - an exeperience like watching remotely on meetecho - which is quite good, but I'd hope we could do much better. Many of us follow work across a number of working groups, tracking specific aspects of protocols or interested in how specific IDs relate to the wider working group. I came to the QUIC meeting to find out who the document authors were, and what they and other people thought about the issues that the WG was addressing. This room format worked against this. >> >> I really disliked the ways the Chairs had their backs to the room. To me, an important role of the Chairs is to include others and judge the sense of the room. In this setup, the Chairs could not monitor the room. The rest of the room were clearly observors to the discussion around the table. In the case of the meetings I attended the rooms were pretty packed, this was bad. >> >> I tried several seating positions before selecting the side area - that presented challenges seeing the screen, but at least you could see some of the people seated at tables and also the presenter. >> >> The floor mic was hard to get access to and appeared like you were standing outside the speaker zone. Even from the "floor Mic", I had to speak to the back of some people's heads. >> >> It was really hard to see the faces of people and to know who is speaking. Sitting speakers are much more difficult to identify: the plea from the Chairs to raise hands when talking at the tables did (thanks for doing this) at least let me see who was asking a question or addressing a comment, but it was frustrating not to be able to see these people's faces. For me, this is a real down-side. >> >> I can see the value for smaller working groups where you can get most people round a table, and the rest of the room really are only observers. >> >> If we do repeat this again, can I suggest we completely eliminate the central part of the "U" and set this up as two rows of desks angled slightly towards the rest of the room. That way people can see who is speaking and those speaking can see the rest of the room? Please also place the working group chairs where they can see the entire room (at least for any meeting I will chair). >> >> Gorry >> >>> On 19/04/2017, 09:06, Roni Even wrote: >>> Hi, >>> I only hope that when considering the feedback, you factored whether the person was sitting at the table or in the room. I can understand positive feedback from people at the table. >>> >>> Roni >>> >>>> -----Original Message----- >>>> From: Mark Nottingham [mailto:mnot@mnot.net] >>>> Sent: =D7=99=D7=95=D7=9D =D7=93 19 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 2017= 10:34 >>>> To: Roni Even >>>> Cc: quic@ietf.org >>>> Subject: Re: Experimental Room Setup (U-Shape and classroom, subject t= o >>>> availability) >>>> >>>> Hi Roni, >>>> >>>> Thanks for the feedback. For what it's worth, we got a lot of other feedback >>>> privately, mostly positive. However, people did point out issues similar to >>>> yours, and we're going to be working with the Secretariat as well as thinking >>>> more carefully about how the meeting is run to try to improve things in the >>>> future. >>>> >>>> Regards, >>>> >>>> >>>>> On 19 Apr 2017, at 5:10 pm, Roni Even wrote: >>>>> >>>>> Hi, >>>>> I noticed that the WG chairs asked for a U-shape room similar to the >>>> experiment in Chicago >>>>> I am sorry for not providing feedback before but I found that arrangement >>>> very difficult from my perspective, I was sitting on the side not facing the >>>> screen and the room was very packed. >>>>> I had the following observations: >>>>> >>>>> 1. It was difficult to understand who is speaking. People sitting at the >>>> table started speaking without stating their name. It is much simpler when >>>> they have to go to the microphone and stand at least you can see who i= s >>>> speaking. >>>>> 2. It was inconvenient to look at the presentation screen when you are >>>> not facing the screen. Sitting on a chair with a laptop on your knees and >>>> looking sideways to the screen was challenging for my neck. It is simpler if >>>> you sit by a table. >>>>> 3. There was no easy path to go to the microphone for people who were >>>> not sitting at the table. Again, since the room was very packed there were >>>> no path from the side to the middle where the microphone was. >>>>> 4. When choosing a sit, the screen facing sites where far from the >>>> screen. I think that having this long table is part of the problem. Maybe you >>>> need a smaller table for less people who really actively participate in the >>>> discussion (this was not the case in Chicago). >>>>> 5. My feeling was that if you are not sitting at the table then you are just >>>> an observer and not a participant. What made this feeling stronger were the >>>> side conversations taking place at the table. >>>>> My conclusion was that this arrangement may work for a small WG but not >>>> for QUIC >>>>> Thanks >>>>> Roni Even >>>> -- >>>> Mark Nottingham https://www.mnot.net/ >>>> >>>> >>>> >> > > -- > Mark Nottingham https://www.mnot.net/ > > > > --001a114c7192cb694f054d87118c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If I might inject here ...

On Apr 19, 2017 05:33, "Eggert, La= rs" <lars@netapp.com> wro= te:
And everyone should fe= el free to send their feedback to the IESG directly, as they to a large deg= ree are in control of how this experiment goes forward.

I'm absolutely watching the discussion= on this subject, here and elsewhere.

Lars is correct to encourage people to send feedback to the I= ESG.=C2=A0

One thing I h= aven't seen much feedback about, was the experience for remote particip= ants with this room layout, compared to other meeting sessions.

If you participated remotely and ca= n provide feedback, I'd find that especially useful.

Thanks,

<= div dir=3D"auto">Spencer, as responsible AD

<= blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex">
Lars

--
Sent from a mobile device; please excuse typos.
+49 151 = 120 55791

> On Apr 19, 2017, at 10:52, Mark Nottingham <mnot@mnot.net> wrote:
>
> Gorry,
>
> For what it's worth, your comments mirror much of what we heard, a= nd what we observed ourselves. We've given feedback along these lines t= o the Secretariat, and will be working with them in Prague to make sure the= room is more suited to the work.
>
> For those who attended the Interim in Tokyo, that's the sort of la= yout we're shooting for.
>
> Regards,
>
>
>> On 19 Apr 2017, at 6:41 pm, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>>
>> I'm glad this was raised. I found this meeting a really unhelp= ful one - and the following meeting I attended for HTTPbis was only slightl= y better.
>>
>> I discovered I had written notes, and they largely echo what Roni = said, and since it seems theer was not much critical feedback, I include th= em below:
>>
>> The whole way a=C2=A0 =E2=80=9CU=E2=80=9D meeting played out had t= he feeling of remote observation of a panel discussion - an exeperience lik= e watching remotely on meetecho - which is quite good, but I'd hope we = could do much better. Many of us follow work across a number of working gro= ups, tracking specific aspects of protocols or interested in how specific I= Ds relate to the wider working group. I came to the QUIC meeting to find ou= t who the document authors were, and what they and other people thought abo= ut the issues that the WG was addressing. This room format worked against t= his.
>>
>> I really disliked the ways the Chairs had their backs to the room.= To me, an important role of the Chairs is to include others and judge the = sense of the room. In this setup, the Chairs could not monitor the room. Th= e rest of the room were clearly observors to the discussion around the tabl= e. In the case of the meetings I attended the rooms were pretty packed, thi= s was bad.
>>
>> I tried several seating positions before selecting the side area -= that presented challenges seeing the screen, but at least you could see so= me of the people seated at tables and also the presenter.
>>
>> The floor mic was hard to get access to and appeared like you were= standing outside the speaker zone. Even from the "floor Mic", I = had to speak to the back of some people's heads.
>>
>> It was really hard to see the faces of people and to know who is s= peaking. Sitting speakers are much more difficult to identify: the plea fro= m the Chairs to raise hands when talking at the tables did (thanks for doin= g this) at least let me see who was asking a question or addressing a comme= nt, but it was frustrating not to be able to see these people's faces. = For me, this is a real down-side.
>>
>> I can see the value for smaller working groups where you can get m= ost people round a table, and the rest of the room really are only observer= s.
>>
>> If we do repeat this again, can I suggest we completely eliminate = the central part of the "U" and set this up as two rows of desks = angled slightly towards the rest=C2=A0 of the room. That way people can see= who is speaking and those speaking can see the rest of the room? Please al= so place the working group chairs where they can see the entire room (at le= ast for any meeting I will chair).
>>
>> Gorry
>>
>>> On 19/04/2017, 09:06, Roni Even wrote:
>>> Hi,
>>> I only hope that when considering the feedback, you factored w= hether the person was sitting at the table or in the room. I can understand= positive feedback from people at the table.
>>>
>>> Roni
>>>
>>>> -----Original Message-----
>>>> From: Mark Nottingham [mailto:mnot@mnot.net]
>>>> Sent: =D7=99=D7=95=D7=9D =D7=93 19 =D7=90=D7=A4=D7=A8=D7= =99=D7=9C 2017 10:34
>>>> To: Roni Even
>>>> Cc: quic@ietf.org
>>>> Subject: Re: Experimental Room Setup (U-Shape and classroo= m, subject to
>>>> availability)
>>>>
>>>> Hi Roni,
>>>>
>>>> Thanks for the feedback. For what it's worth, we got a= lot of other feedback
>>>> privately, mostly positive. However, people did point out = issues similar to
>>>> yours, and we're going to be working with the Secretar= iat as well as thinking
>>>> more carefully about how the meeting is run to try to impr= ove things in the
>>>> future.
>>>>
>>>> Regards,
>>>>
>>>>
>>>>> On 19 Apr 2017, at 5:10 pm, Roni Even<roni.even@huawei.com>=C2=A0 wrote:
>>>>>
>>>>> Hi,
>>>>> I noticed that the WG chairs asked for a U-shape room = similar to the
>>>> experiment in Chicago
>>>>> I am sorry for not providing feedback before but I fou= nd that arrangement
>>>> very difficult from my perspective, I was sitting on the s= ide not facing the
>>>> screen and the room was very packed.
>>>>> I had the following observations:
>>>>>
>>>>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0It was difficult to under= stand who is speaking. People sitting at the
>>>> table started speaking without stating their name. It is m= uch simpler when
>>>> they have to go to the microphone and stand at least you c= an see who is
>>>> speaking.
>>>>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0It was inconvenient to lo= ok at the presentation screen when you are
>>>> not facing the screen.=C2=A0 Sitting on a chair with a lap= top on your knees and
>>>> looking sideways to the screen was challenging for=C2=A0 m= y neck. It is simpler if
>>>> you sit by a table.
>>>>> 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0There was no easy path to= go to the microphone for people who were
>>>> not sitting at the table.=C2=A0 Again, since the room was = very packed there were
>>>> no path from the side to the middle where the microphone w= as.
>>>>> 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0When choosing a sit, the = screen facing sites where far from the
>>>> screen. I think that having this long table is part of the= problem. Maybe you
>>>> need a smaller table for less people who really actively p= articipate in the
>>>> discussion (this was not the case in Chicago).
>>>>> 5.=C2=A0 =C2=A0 =C2=A0 =C2=A0My feeling was that if yo= u are not sitting at the table then you are just
>>>> an observer and not a participant.=C2=A0 What made this fe= eling stronger were the
>>>> side conversations taking place at the table.
>>>>> My conclusion was that this arrangement may work for a= small WG but not
>>>> for QUIC
>>>>> Thanks
>>>>> Roni Even
>>>> --
>>>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>>>>
>>>>
>>>>
>>
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>
>
>
>

--001a114c7192cb694f054d87118c-- From nobody Wed Apr 19 12:24:07 2017 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 F3373129C27 for ; Wed, 19 Apr 2017 12:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 2XbPG8fNj570 for ; Wed, 19 Apr 2017 12:24:03 -0700 (PDT) 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 02734129C1A for ; Wed, 19 Apr 2017 12:24:03 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d0vCq-0007ez-LN for quic@ietf.org; Wed, 19 Apr 2017 21:24:01 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d0vCj-0002Mv-Ja for quic@ietf.org; Wed, 19 Apr 2017 15:23:57 -0400 Received: (qmail 17907 invoked from network); 19 Apr 2017 19:23:53 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.222]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Apr 2017 19:23:52 -0000 To: Martin Thomson References: Cc: "quic@ietf.org" From: Christian Huitema Message-ID: Date: Wed, 19 Apr 2017 12:23:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Security considerations in quic-transport X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXp0p7mxQS78hfTfbb8wpjPcRcOb18WfxGyg6Om6u4YYm/+tN2jyJqdVASHZ OISfM905hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKXTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0RlbnYuTa KI3YHAuJTBfNaLbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWJKyg1OJH8aak+/hDMnS4uzLQQGIH13szEQZ25LjADnMx+n6NkwIj2Owl 8spPn7QVcqiSoo7BxyxRryqmiHuCdUetTZ/25DKDZC7RirBgbePcy8BFh+JufJrwsKmKW6bHd9QD sMspn/O/edVkHySM+CDVwFjZwEavmmk7Tr9uJ5mso9iv7kZ9azJt3DY/E7nm X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 19:24:05 -0000 Hello Martin, I heeded your advice and proposed some text in PR 444. But I am puzzled by the Verifier tests in the PR log. It complains that "All checks have failed (1 failing check)". I tried looking at the "details" output there. The first time, I saw a complain that an input line was larger than 80 chars. 80 chars, really, are we still using punch cards somewhere? In any case, I fixed that, the checks still fail, and the "detail" link won't display anything, even after waiting for an hour or so. This seems really weird. Any idea what is happening? -- Christian Huitema On 4/17/2017 10:29 PM, Martin Thomson wrote: > On 12 April 2017 at 04:44, Christian Huitema wrot= e: >> Should these be documented? > > Yes. Text would be welcome :) > > I've opened an issue so that we don't forget: > https://github.com/quicwg/base-drafts/issues/440 > --=20 -- Christian Huitema From nobody Wed Apr 19 12:50:56 2017 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 DF090129534 for ; Wed, 19 Apr 2017 12:50:54 -0700 (PDT) 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 ZRDkiyDn1p8c for ; Wed, 19 Apr 2017 12:50:53 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 A576E129526 for ; Wed, 19 Apr 2017 12:50:53 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d0vcq-0002Ro-5V for quic@ietf.org; Wed, 19 Apr 2017 21:50:53 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d0vco-0001SP-Nw for quic@ietf.org; Wed, 19 Apr 2017 15:50:51 -0400 Received: (qmail 26997 invoked from network); 19 Apr 2017 19:50:50 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.222]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Apr 2017 19:50:49 -0000 To: Martin Thomson References: Cc: "quic@ietf.org" From: Christian Huitema Message-ID: <9894f8b4-f724-599b-f8fc-810e412b2652@huitema.net> Date: Wed, 19 Apr 2017 12:50:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: Security considerations in quic-transport X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49I98TYJ6ZsqWtR/HDmWTg9dTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoUVuRP257oU8iUWQQAdblzRcOb18WfxGyg6Om6u4YYm1scJscWJx8MB12q HwPviCE5hjoyEb9Oq0NWpyO3vrfYJa7GnXDffeBY//TcvM3Flj3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBqW+JovcC0XtHTtanzqbG/HTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK04QD6r8T3 Za4oc9nmoF0V/7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWHxcEeYXaEh7Ip8nBmIzXZwpqT8auRNlXQctohljUCg+4XLNcKQtVqZBI 5mIdirfSKhBaevb8pkwVq3+XN9bPyjRMyLUEno1frs9vZR0iI5iTGneI1cCMIcE6R6jtJ8btb7sy ltanepIHrA9+HqSAze9Tb/EzRc4KszwGAkbj6j0QxK4Q6pnz1PG2i0Jcu7De X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2017 19:50:55 -0000 On 4/19/2017 12:23 PM, Christian Huitema wrote: > Hello Martin, > > I heeded your advice and proposed some text in PR 444. But I am puzzled > by the Verifier tests in the PR log. It complains that "All checks have > failed (1 failing check)". I tried looking at the "details" output > there. The first time, I saw a complain that an input line was larger > than 80 chars. 80 chars, really, are we still using punch cards > somewhere? In any case, I fixed that, the checks still fail, and the > "detail" link won't display anything, even after waiting for an hour or > so. This seems really weird. Any idea what is happening? > OK, I finally figured out that a space at the end of a line breaks the markdown conversion. Puzzling, but, whatever... -- Christian Huitema From nobody Wed Apr 19 17:17:05 2017 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 6C5DE12EAD4 for ; Wed, 19 Apr 2017 17:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 ju9EBnMWr2od for ; Wed, 19 Apr 2017 17:17:02 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 A0623129410 for ; Wed, 19 Apr 2017 17:17:01 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id 75so20593470lfs.2 for ; Wed, 19 Apr 2017 17:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cxAeVZYJQGMHiWYdBOuEstZ5po2CvlhcTBxJHrKxEa0=; b=uI+Hv7A0DgMe4kVVCxHAGxmtPuAgmyFltHQny1dGHj4hmLUnCnEcTuvMHUVcSmoV1b w6llVTzk3zREHK4yKOipxwvo5P6LcXiXxFVFRaGDtOZlf7as884ptb0EbDWI8g9BsHy6 MmYcLrNY/Zb9DJIIB3GewmTo6lGQ1EZUluLVI80vaUR6kfhdzNGdCFkDWAQtH4kBgiS/ K8X+Cl6fQt91k7g2gPjIguzdENudmruqblvoX1yVpDA1vHUAV0cix7sWGeZ3nbthpRyJ L7vuNA7hNoYxWlEA8kGkc+KbaSLgfc4Iagf4CscCUkX2hOiotfeM2vHY8nGGSH5l5goe A7nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cxAeVZYJQGMHiWYdBOuEstZ5po2CvlhcTBxJHrKxEa0=; b=YbtetWTUgvm0uLzre4vEPeB88xKZuHe28LwlgQkfVu4SM0WLNARGLSIcRkFmsPhZ1l zjc+Zchw3njUdT8l/io94zeq1er17k7eLPJl8FBfoRioLsOIH0v1h6oc+tCM1WwTWWDu GWeiOW8f5pt2K4VaqLr8TJuWi3U9PWcoH0NYTN9Wy+28aa4BRyANoXYkx6R4cUCE4CxL bEz0LJRH/mARGCI+bI/u/Bzb4ghsUCQ0HNpE+kI1Hu1/tzh9bhGROIFdaSG52YXDy0Pt Oyrr+2mGfHqq598XktvMrxj+87qekkQW8oyK2tAATqS9blmpdH5Wh9zvSceECQG2zT1P DK3Q== X-Gm-Message-State: AN3rC/4//wmgeNCnsOpYwIGtQrlEE0YV2ALtT7xYnT1/UrA+VWi4284R brEGGENzpxSrMXopD9hWnf9pMo+cYu9O X-Received: by 10.46.75.2 with SMTP id y2mr1826261lja.103.1492647419997; Wed, 19 Apr 2017 17:16:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Wed, 19 Apr 2017 17:16:59 -0700 (PDT) In-Reply-To: <9894f8b4-f724-599b-f8fc-810e412b2652@huitema.net> References: <9894f8b4-f724-599b-f8fc-810e412b2652@huitema.net> From: Martin Thomson Date: Thu, 20 Apr 2017 10:16:59 +1000 Message-ID: Subject: Re: Security considerations in quic-transport To: Christian Huitema Cc: "quic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2017 00:17:04 -0000 On 20 April 2017 at 05:50, Christian Huitema wrote: > OK, I finally figured out that a space at the end of a line breaks the > markdown conversion. Puzzling, but, whatever... There are some basic linting hacks in the build to ensure that trailing whitespace and other formatting things don't get out of hand. It's easier to stay on top of these things; it keeps the blame clean for one. From nobody Wed Apr 19 17:25:22 2017 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 93E0D12EADD for ; Wed, 19 Apr 2017 17:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 AmBqy56z3eIu for ; Wed, 19 Apr 2017 17:25:19 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 99ED312EAE9 for ; Wed, 19 Apr 2017 17:25:18 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id c80so20581702lfh.3 for ; Wed, 19 Apr 2017 17:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dCBhMaMj1+wORErSc/BpHI7LoNiPLOIRsdHcbb7ZnP0=; b=jUHBrwelEQVyvY64WXK1+3ADfZ6ZqXPfnvp0u5l7ufaXMGOZNiJaQ47EPfgdLYPW0p NLuejsAuNUrLbArNjE/4vKQfesNNT5vAPK2hXcJwNpxTA8bzWbIs0/jL+3U/L0wt32uF +eERHZdsbtQd+Z5NkmCTFwD53DU2oPinNabg7iAKRdkSJdwot3nFtf26id+xeDSZt5OL JyKA0mFSjCyyOaA5QZ9+1VG0SQoYl4INfxznTOD0dFFisM8fspzxwBIriSBohk33IOj+ sB3mrDRQXuKQF4TRqlPxYDClnX0UksS8o67OaUROk8tgqLmQa049Skc+ekE6pg2rMcLn aC9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dCBhMaMj1+wORErSc/BpHI7LoNiPLOIRsdHcbb7ZnP0=; b=qUIStUiFhVPRly0px+BVYChAO+Ik1siC3SPub3N2vFsQ0K2KmBw630Cdlm1uVK4TLY f2d1aeKm7dA6yBXrTT/pa8S+w6jxbO2pXuA86GxxTRi5Vg4gmz3wbHUc9rwLhGo/7f1m dsVdtdH499mk33NWvj3JLRF7aEkDysHPjQdxNkkGcU/+OOaG13ZD8kqsHq9Z4WZExCz2 ciID7sHeipWAYP3/bEcH5dx/oIVvKKKmL82Gb8rxPuda7HMbB83CW4JdCdXZ+hO1h/ja aZshKeckczxbKoslPD8p5hbDlXaNWEt1+eb2IoWQu8qU67sKcIVW6HfGrAILqJFbmt7f 8RqA== X-Gm-Message-State: AN3rC/5CJoIwoGLOVb5+HVntSwBiegL5im0ZaK0DaBKQcmDZ4oj8Zgb+ zljBtRvpONL+ylt313UniIFIea56sn1Cx+w= X-Received: by 10.25.160.147 with SMTP id j141mr1664132lfe.19.1492647916949; Wed, 19 Apr 2017 17:25:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Wed, 19 Apr 2017 17:25:16 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 20 Apr 2017 10:25:16 +1000 Message-ID: Subject: Re: Sending/Receiving packets before client Finished To: Eric Rescorla Cc: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2017 00:25:21 -0000 On 19 April 2017 at 21:32, Eric Rescorla wrote: > OK. If so, I think we should probably do something about the HOL blocking > on FInished. This draft proposes one approach, which is send Finished a lot. > I am aware of at least two others: > > 1. Add a length field to the long header and stuff Finished and app data in > the same UDP datagram (probably my preferred approach) Yeah, you still need to send Finished lots for this to work. It's rare that the flight of application data with Finished is just one packet (and if it is, the HOL blocking isn't that interesting). > 2. Do what TLS does not do (though DTLS will have to confront) and allow > application data to be received prior to Finished (the analysis in OPTLS > suggests that if you are willing to sacrifice key confirmation this is > okish, but would need a lot more thought). Yep, absent client authentication, that *might* be ok. Though, I confess to not understanding all of the implications of that choice and would want more confidence. Thinking really hard sounds like it could be unpleasant, but if someone else can do that thinking for me, that would be grand. I've opened an issue on this: https://github.com/quicwg/base-drafts/issues/446 From nobody Wed Apr 19 17:51:00 2017 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 788671293EC for ; Wed, 19 Apr 2017 17:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 FEIl0y_tL0Bb for ; Wed, 19 Apr 2017 17:50:57 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 127A412025C for ; Wed, 19 Apr 2017 17:50:57 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id t144so20867922lff.1 for ; Wed, 19 Apr 2017 17:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R+qqBllcLbhuy1OCNc6p9KCt35mHWGslXZ0akrPM95g=; b=t6jrVNBpjsR43519vHCcYBvg4l28QycOe+m4IiDLHGtTWk93fPRjaB0NPr9XGM8RkG /cNw7mmWieMaJx338DhlM3etHMdaVTwTiT6EQZrflqQzzJFok4f416LLQbJpN66h3ATU GfvdRA8I1LugcH28IM/AMcozbkETiQZNlK9OnY0aMZbKFfWhjy3ZyZL1RRFjBwLPNKbh /M1xNYsh+WB8qeg737bwAsew16w9NAnUVh6RmLw9xLHDp/ED5uEgTbPctizbVtoMIrDv n0F0ODmpWEIv3YcK0dHNyvjj5N2+8rzNV6oHdTpFUlbK6pgFTenIdk5ZIDdHj8DgqKyD zFRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R+qqBllcLbhuy1OCNc6p9KCt35mHWGslXZ0akrPM95g=; b=qwDHLq1YU2KOJAmZSewbT36nCO9b64rF7bRCDSLGRY+4ppG+/r05F4yoilY7bpQNEv Slj/pjGoh1LEXzvnEyl5ODFQirfd6Xlz2C/tzKyDYElhDS9qO1yxLeiexgl9OQmzsCOI XaxNqe/lElumIFJyiAOPGq4GagBxL3pCG/bYkK/kQppP2txrEkj7UkLVoa6N91g4/6BJ 99OjyHKPeKdkbuyeyn0IwsZOAzBicdH7XRz98dq/6gkKMnmnMEf7kkSc7iz8zy+eCdB+ W9YfrqtXkBjaDzkUbJ9MBCyOv/HoVeFLizyCm1mRBs/+sqJtcpTIeDZ4cEdPr9Zzo9y7 GRUg== X-Gm-Message-State: AN3rC/4oMsuoU6+SesPFePM0IJbXGBYJckVJT6Pkhr2bKDMHZ6TEPQ/Q bmoX7Cfy/r1zZiqdB/Rn2WJV7NUHs553 X-Received: by 10.25.213.130 with SMTP id m124mr1929754lfg.50.1492649455463; Wed, 19 Apr 2017 17:50:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Wed, 19 Apr 2017 17:50:54 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 20 Apr 2017 10:50:54 +1000 Message-ID: Subject: Re: Security considerations in quic-transport To: Christian Huitema Cc: "quic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2017 00:50:58 -0000 On 20 April 2017 at 05:23, Christian Huitema wrote: > I heeded your advice and proposed some text in PR 444. Thanks for doing that Christian. I have a few comments on your text. I'm happy to look at making a few changes if you'd prefer, but I thought that I'd give you the first opportunity. From nobody Wed Apr 19 21:33:53 2017 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 27E1C127B52 for ; Wed, 19 Apr 2017 21:33:52 -0700 (PDT) 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, FREEMAIL_FROM=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=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 dK-GNoJIjAVK for ; Wed, 19 Apr 2017 21:33:50 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 5806A126DDF for ; Wed, 19 Apr 2017 21:33:50 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id 88so22402811lfr.0 for ; Wed, 19 Apr 2017 21:33:50 -0700 (PDT) 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=U32bi4GGxZNcpw+/mWy/Th8QOGKVilawwSyckI6tjxg=; b=sPtci1jLI5USGzpAdM/YNggqi0ArMMn9I0epx6bK5+yd//wJMrCUHzkgBZZDMFPxDL n4y91QwpkkXghwSZ/a4QNZArRESUgVs/rQagqGyVqM5MC0IZSH9+d/DSBreuVKi4zd++ PCXdFj6inC4Ki07GMPJ2xX2mi6q2KC1yAVvM0iCgFTRVAqgRoi0w4sEQ9dwmv5Me63xS Qm4hvTowQ9E8Mc2c8lWCx72O1Zjk0X9pQCo9U0G5msJqQ8NX/dS0D+GAEYtY2A+XD8BM /Y3aqohKxMJozu9ilZADNHxKMeDW+jZnZFWA2NpVC17QfqMy473rlMZA6RVepNj/naZW duuw== 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=U32bi4GGxZNcpw+/mWy/Th8QOGKVilawwSyckI6tjxg=; b=YmKJXAhgW5mxcRHqhjoWYKgmDdh5/WpHjm7qh/poS1cyUKRrGgG5kP/hmgiLrpH793 KDtNL8n77N/VtGHydd7t+xxJxeDnLp0fXzQLMnm/jTxP7JuKFNAgJUj06vxCOnTi+5IE SWdQejjh4qQiBEi6j1mndWai+wqXSbmNIKli5Hd/58l7/rGsGRCR2B9qktQOAfE9b4xC aQBU1PyyUo/Na42a9gM8xG+8dj5SfjFWDrxFV7BthDhSyclorC1HLkFP1brhdszlwIdV wvjwjzFRq5fFhSpFWg4W3gWaUVa7MpQIl0g4uC9x6gBpUlRnB8uWVBkrN2JYGYsII3D0 Ijsw== X-Gm-Message-State: AN3rC/6slfPsjyQ4m/RMSuatNyipHKxXAWoJXX66nhDtrkQ7TROkTL9y t0pkUnMQ0JqzfBRODGJHir3SitwdxBAfFEA= X-Received: by 10.46.87.80 with SMTP id r16mr2047063ljd.50.1492662828301; Wed, 19 Apr 2017 21:33:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Wed, 19 Apr 2017 21:33:47 -0700 (PDT) From: Martin Thomson Date: Thu, 20 Apr 2017 14:33:47 +1000 Message-ID: Subject: Splitting WINDOW_UPDATE To: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2017 04:33:52 -0000 In practice WINDOW_UPDATE is two different messages. This makes the split clearer. https://github.com/quicwg/base-drafts/pull/450 Splitting has several advantages, the most obvious being that it shaves 4 bytes of a very common frame (the connection-level update). The less obvious one is that stream 0 no longer needs to be considered as special (yeah BLOCKED would need fixing), which opens up the possibility of removing some long-standing annoyances. As part of this, I've made the description and handling of our three limits a little better aligned by renaming the frames: connection data, stream data, and stream IDs. From nobody Wed Apr 19 22:38:51 2017 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 65FB012EAFE for ; Wed, 19 Apr 2017 22:38:50 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 OPLOIAdQGmeV for ; Wed, 19 Apr 2017 22:38:48 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 8F07D126DED for ; Wed, 19 Apr 2017 22:38:48 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id y11so2998195oie.0 for ; Wed, 19 Apr 2017 22:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FHvdPT+itxaDAG6hRy+cBkC4C4tJQ8vlCDfaI02l01o=; b=jC7MwIFrDFFRKJfk8VTZtXt2IrHdj2EZkbU0lMPAY1DcvwBxKmjJAjDJqM8smaCTta uxNz2Pm2KJjFujMmcbCmjZt8yMFB0Mcp1eMsmB93AZ/HTMdT7VsGrhBtv/ScMAFYmNLF ChOESAGbZcQuCdozFE0Tf5UaLGGFupaUG8+mo2C6XDJaToCerPHJWDD81VKDy+JAv7MM zz2NhqOP3QqZ/OnmIBqRMenBiTVOeQ2JMk1jXnpzZUw81T8aZtdcM80K554v6BXJfrMg 0gXDKBtbCurB6B96pfJXa/6FXeKTbi7Jckua7jDQnSD3z3HVI45YeSSDDKw/sLmBjgWo 8xjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FHvdPT+itxaDAG6hRy+cBkC4C4tJQ8vlCDfaI02l01o=; b=hCmLFV0HQux/RKfjmsso9nDciVn53ZLXSB3WRQW3hccynid6igfDIWRO6Ymna/abeb 9VAAo5ytf1J/zCYqPBD1PN7U5dCVH292XtiRoXlwX6/bZOZZO3qlUtsvy+9Z0N0/yPs6 qviegPiuOiCimDM/hnSulsMyqOKRMQTmqpHfTt829LwjkDRn2A+gy6TuDx84bbWy4bE7 tlD653bXWqctIkSNG3fhnVCY5H1x8m9qD41RGqi33KczM70NNiBjbqhwsrGFpBIfseEm zqMHUF1/VNZZKhC8Egoi3TL1lZ4cblumagIaN/9T2htUXUmVw1Zo/vsCP8N8nP8UCPlm Kjnw== X-Gm-Message-State: AN3rC/4N/yZLFlIMw+3tm7XgFMMfWSEwZwZKq4k+FF9uAnMIUGhxAnl+ UpQTbgFxGvVwTsxDkwZXDy30lbEEVDXz X-Received: by 10.84.224.73 with SMTP id a9mr8346412plt.38.1492666727499; Wed, 19 Apr 2017 22:38:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.74 with HTTP; Wed, 19 Apr 2017 22:38:47 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 19 Apr 2017 22:38:47 -0700 Message-ID: Subject: Re: Splitting WINDOW_UPDATE To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary=f40304374f6c0fdf10054d928e9d Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2017 05:38:50 -0000 --f40304374f6c0fdf10054d928e9d Content-Type: text/plain; charset=UTF-8 I like this set of changes -- it cleans up things. I've left some comments on the PR. Thanks for writing this up. On Wed, Apr 19, 2017 at 9:33 PM, Martin Thomson wrote: > In practice WINDOW_UPDATE is two different messages. This makes the > split clearer. > > https://github.com/quicwg/base-drafts/pull/450 > > Splitting has several advantages, the most obvious being that it > shaves 4 bytes of a very common frame (the connection-level update). > The less obvious one is that stream 0 no longer needs to be considered > as special (yeah BLOCKED would need fixing), which opens up the > possibility of removing some long-standing annoyances. > > As part of this, I've made the description and handling of our three > limits a little better aligned by renaming the frames: connection > data, stream data, and stream IDs. > > --f40304374f6c0fdf10054d928e9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like this set of changes -- it cleans up things. I'v= e left some comments on the PR. Thanks for writing this up.

On Wed, Apr 19, 2017 at 9:3= 3 PM, Martin Thomson <martin.thomson@gmail.com> wrote= :
In practice WINDOW_UPDATE is two differ= ent messages.=C2=A0 This makes the
split clearer.

https://github.com/quicwg/base-drafts/pull/450

Splitting has several advantages, the most obvious being that it
shaves 4 bytes of a very common frame (the connection-level update).
The less obvious one is that stream 0 no longer needs to be considered
as special (yeah BLOCKED would need fixing), which opens up the
possibility of removing some long-standing annoyances.

As part of this, I've made the description and handling of our three limits a little better aligned by renaming the frames: connection
data, stream data, and stream IDs.


--f40304374f6c0fdf10054d928e9d-- From nobody Wed Apr 19 23:08:27 2017 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 F2C9912EAFC for ; Wed, 19 Apr 2017 23:08:25 -0700 (PDT) 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, FREEMAIL_FROM=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=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 U607DDBwYPqJ for ; Wed, 19 Apr 2017 23:08:24 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 BA003129B44 for ; Wed, 19 Apr 2017 23:08:21 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id c80so23083231lfh.3 for ; Wed, 19 Apr 2017 23:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IPBl6xv/G1V78ub9lDvAxo4W8rOJlx320PuF37CdI9g=; b=OLLqOt7A1xeie5jlR8DGd+GTf67NNgX2YPvdf8pZrFFd+6hC6Udr1ZGKa/jWQ0D6vg 23Zj7gRzZUdh14ptj/pPgvV1yeruLwY+1+kU9Le7pntHs0C6iW4N9McdimU2kxTqTIC7 uZZCfcJm9F3q2E0uoK0NHDKKkrgymWSDGhc3YMGMysonvf56e0PE0wpHjvP/f/JKIBh7 rDIN9HqWk30vqsqUn6Uk5UrbrKazfH+sNyqZINw4hY7rijng3RXDJg2e4Rj9/KxPFxbq AiS8enLTJKv75uKCaOLBQlwRek8Y0NVhfJuBmrCdAhswVxNynkLPbN+RLXsOQbIa4UP0 j1uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IPBl6xv/G1V78ub9lDvAxo4W8rOJlx320PuF37CdI9g=; b=Dvr8s132LLCb4BKQGykGekqxEUoyPHDpeSNdieE98wIR0CNlbm5KE9QORNHI4XuGzE f+Cfh17nFmSvRb4AtrT01rNs3qthaX9EgxpaEWEK1E7tpF9OlSTcg8H0kQQmE4YEGYJd 9S9fx2q8yzublxZ3nSml3P78zzLT2xluDyZWmAe6jcqatFCiayWjnyHk/F5p4vfgAdAH 2M/euGHRzvnplOI7xQxTlapgoduqhVDSQTh/CNOzZqC+osmzaC6IWRvPi5GwMPsWX1L4 fgWEqKZk7SdYDLW4N4/9eF8EGr23tScro+yv9vM8gJXGJUyHJml8K6nuztWEXbMy6fde qvbg== X-Gm-Message-State: AN3rC/62h/5N6Yg5qhgRyyzxLAh/RtChzJacwF0drM9j2YyJXadeq8hX HWTxEfr3S+muDcOuLTTN4sSKy35d4w== X-Received: by 10.46.69.133 with SMTP id s127mr2159172lja.44.1492668500031; Wed, 19 Apr 2017 23:08:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Wed, 19 Apr 2017 23:08:19 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 20 Apr 2017 16:08:19 +1000 Message-ID: Subject: Re: Splitting WINDOW_UPDATE To: Jana Iyengar Cc: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2017 06:08:26 -0000 Given favourable feedback thus far, I have a few follow-on changes: This splits BLOCKED in the same way: https://github.com/quicwg/base-drafts/pull/454 Splitting these frames allows us to move crypto to stream 0 and the HTTP control stream to stream 1. That doesn't sound like much, but it removes a few surprising and unnecessary corner cases: https://github.com/quicwg/base-drafts/pull/456 I'm much less certain about adding more BLOCKED-like functionality for the new MAX_STREAM_ID frame type (aka LIMIT_UPDATE), but it was easy. So I have a PR for that too: https://github.com/quicwg/base-drafts/pull/455 On 20 April 2017 at 15:38, Jana Iyengar wrote: > I like this set of changes -- it cleans up things. I've left some comments > on the PR. Thanks for writing this up. > > On Wed, Apr 19, 2017 at 9:33 PM, Martin Thomson > wrote: >> >> In practice WINDOW_UPDATE is two different messages. This makes the >> split clearer. >> >> https://github.com/quicwg/base-drafts/pull/450 >> >> Splitting has several advantages, the most obvious being that it >> shaves 4 bytes of a very common frame (the connection-level update). >> The less obvious one is that stream 0 no longer needs to be considered >> as special (yeah BLOCKED would need fixing), which opens up the >> possibility of removing some long-standing annoyances. >> >> As part of this, I've made the description and handling of our three >> limits a little better aligned by renaming the frames: connection >> data, stream data, and stream IDs. >> > From nobody Thu Apr 20 11:53:31 2017 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 07C2B128954 for ; Thu, 20 Apr 2017 11:53:31 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 dWqKeHYYmxNh for ; Thu, 20 Apr 2017 11:53:29 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 B6ABD1314F7 for ; Thu, 20 Apr 2017 11:53:26 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id h67so54750346qke.0 for ; Thu, 20 Apr 2017 11:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CE7EyfZ/OG4reqilWbi7xuUu2wkhvK1FsibqGf8lPPg=; b=bxM5LicVhJAgASdTDxqvdeLlr21tmLkEd+XDEM3QHUn2VQYOzeUGf420dgQHHn1Qq+ qoYAMzb5ws3ST6IRcDj65c5mTo0DwIeHklypHTgtWvS9G7hen2equlQH7n8P5JVOs3s4 2tWI806eJFaUWPxIUlttJofxdZ+KOd7jmD9ylPPH2Mn8w+hgcxboUz6NYHyj8NocwoOH tsmX/yg+CZrcQ/wmnQ+Axz+pGQjtWlxAZv2f/ajSKd0PfMmp2RsfuRefF4/F4nok2amp TOGCjxRj0ExayRfLn7u1U3XGaidJ5ruEuZvqIaABx6b/RiyL2HUDfUy7mp3a8f3cnykM loig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CE7EyfZ/OG4reqilWbi7xuUu2wkhvK1FsibqGf8lPPg=; b=bRz7ELrL0Fnh97Q/zIM0t8NIRRZoxFYWKEYEmwh4OIyLZ7xyEOU1TAMEQjTHbcux2W D77I+h6dRa1eQeUn8TIOAidtDau/cA5w6OsWY9c9SZdfsebmOu+nwrVrxY0Imx3NE5bY OUyDoQgEqR59XT3+0qGdxgsOTBv9kXoUp3pruOwRpSN/fW5A7EkcZmBDBl87cQj0KPxP /ePjLUTjkyl5AV8NiuCPY2/FgsP3qBL4AeHYy91euZNsQFULJqslHB6kcL3u/P8L30ij NvEPVfen2f+bJ0m0SkRvr+IzvdnkSbhoBYBYTTMnkfLxSzzjxM67huHfrqck9rDe3ayp 70Kg== X-Gm-Message-State: AN3rC/4DM99J3tDRnpSYETioaoliUFKmnlYyLn4VmzLDjsH8bTIElGWO HmRNB1p5a+QaBm23LFGNUHgDynpw3Bo/ X-Received: by 10.55.78.201 with SMTP id c192mr10041425qkb.81.1492714405716; Thu, 20 Apr 2017 11:53:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.76.81 with HTTP; Thu, 20 Apr 2017 11:53:25 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Thu, 20 Apr 2017 14:53:25 -0400 Message-ID: Subject: Re: Key change logic To: Eric Rescorla Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114a882ee7ef56054d9da7fd Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2017 18:53:31 -0000 --001a114a882ee7ef56054d9da7fd Content-Type: text/plain; charset=UTF-8 On Wed, Apr 19, 2017 at 7:28 AM, Eric Rescorla wrote: > On Tue, Apr 18, 2017 at 7:46 PM, Martin Thomson > wrote: > >> Yep, I followed your logic here and you are right: >> >> Anything that doesn't decrypt has to be thrown away (no connection >> closes on unauthenticated rubbish) >> >> For the sequence P=1,N=15; P=0;N=20 without ever sending with P=1, the >> second packet should be discarded rather than trying with G=2. >> >> (The awkward thing is that you probably need to have more than two >> generations of receive keys in play in the case you DO send with P=1 >> here.) >> > > As far as I can tell, this only happens if someone changes keys really > often, and > that seems like "it hurts when I do that". I mean, yeah, you could > compensate > for this, but I think better to give guidance not to change keys more than > once > in MSL. > > -Ekr > > I would also add a requirement that if the sender is currently using phase P, it must not switch to phase !P until at least one packet with phase P is acknowledged and none of the packets of previous phase !P are considered in-flight. -- Victor. --001a114a882ee7ef56054d9da7fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 19, 2017 at 7:28 AM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
On Tue, Apr 18, 2017 at 7:46 PM, Martin= Thomson <martin.thomson@gmail.com> wrote:
Yep, I followed your logic here and you are right:<= br>
Anything that doesn't decrypt has to be thrown away (no connection
closes on unauthenticated rubbish)

For the sequence P=3D1,N=3D15; P=3D0;N=3D20 without ever sending with P=3D1= , the
second packet should be discarded rather than trying with G=3D2.

(The awkward thing is that you probably need to have more than two
generations of receive keys in play in the case you DO send with P=3D1
here.)

As far as I can tell, thi= s only happens if someone changes keys really often, and
that see= ms like "it hurts when I do that". I mean, yeah, you could compen= sate
for this, but I think better to give guidance not to change = keys more than once
in MSL.

-Ekr


I would a= lso add a requirement that if the sender is currently using phase P, it mus= t not
switch to phase !P until at least one packet with phase P i= s acknowledged and none of
the packets of previous phase !P are c= onsidered in-flight.

=C2=A0 -- Victor.
=
--001a114a882ee7ef56054d9da7fd-- From nobody Thu Apr 20 16:29:45 2017 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 18372129C13 for ; Thu, 20 Apr 2017 16:29:44 -0700 (PDT) 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, FREEMAIL_FROM=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=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 5-M4huxNhRFX for ; Thu, 20 Apr 2017 16:29:42 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 66FFA129BCE for ; Thu, 20 Apr 2017 16:29:42 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id 88so36823241lfr.0 for ; Thu, 20 Apr 2017 16:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DC6AZpFe+AJmQlX/pUKCfREUXlHZyC4sm10ePVUGGuk=; b=CSQy+T6L3tWwCgiOxu2x7DZkZajA6KljR3GghiR1ev7WqBDyqjCFlJ69E6F+qfsww6 wGsatJQQYkBw6704ZfuXvXg5Reejl1/FzjJtNZS5x2LtIQ32VVA08kKHN1ryMsaHQhvZ HTP03zt2K1xjXXAF0cRlbgQol33GNVfwY3xX/My/9EoxRZyutg/4BkMI2/OIptFf01zi TQPCsHI3/NJM+buEL+5gt8r3XzIDIna3Vp3NxGBGd+j0LiYe39pYgl8BARxOKyjc8o5E CFr9p2shelt7w+pFjsMxi7/O3/j9PN+pS6w36q3yLJCNVItmgOS13RIpZjDWDjDeZ1s7 1jYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DC6AZpFe+AJmQlX/pUKCfREUXlHZyC4sm10ePVUGGuk=; b=elw/cOtlNcHUsIf/QVc1QldNcnNJqaLTEXBWRtCPMr5rTFIwTbP4vYjT4uKyX0g+me 66Y1y3NgSq1Fy08TTj/szwQN1in0pk8YaWDEK+QzL2gZXoGhMZdZ1IYCYtxDgjb6OSWA YJ3Dai3gWdVB5gNCPfQRnpXU5tw3B+6EaATtC6C6eqc1jvVx2Y7I2qiNZ0X9MNTZpXYC G/8P0Ju0rN+CTbVwMjBZ9GQFY3Th7AjVFp6LORzEvTbvcxB3szjL4BP188Wnh6loCMIn /+rQhIKefcIEpTZ4aqjMlNR3mtdeiKPVPcByvymAp4NudDEychdjE59mOCT0XqZcIDmZ eaFQ== X-Gm-Message-State: AN3rC/4FE3fYf7KSVUR7jWe1omoD9R9LQUtloBEjKb26SRi1MnPX4KM2 5c1pCB96uKLuoxe6NShlRJSJoCy+cg== X-Received: by 10.25.76.193 with SMTP id z184mr3253369lfa.43.1492730980676; Thu, 20 Apr 2017 16:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 20 Apr 2017 16:29:40 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 21 Apr 2017 09:29:40 +1000 Message-ID: Subject: Re: Key change logic To: Victor Vasiliev Cc: Eric Rescorla , IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2017 23:29:44 -0000 On 21 April 2017 at 04:53, Victor Vasiliev wrote: > I would also add a requirement that if the sender is currently using phase > P, it must not > switch to phase !P until at least one packet with phase P is acknowledged > and none of > the packets of previous phase !P are considered in-flight. Determining that packets are still in flight is hard. It is sufficient to know that the other side has moved up to the same key, for which you don't need an ACK because use of the key implies acknowledgment. With huge delays on random packets being a thing, there is always the chance that two fast changes lead to packets with the same phase and different keys arriving at the same time. Maybe a better bit of guidance would be to avoid changing keys within an RTO of the last change. Maybe that is what you had in mind. From nobody Thu Apr 20 16:59:40 2017 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 2C1381293D9 for ; Thu, 20 Apr 2017 16:59:39 -0700 (PDT) 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, FREEMAIL_FROM=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=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 RCHWs8wZp2tB for ; Thu, 20 Apr 2017 16:59:36 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 77B4C120326 for ; Thu, 20 Apr 2017 16:59:36 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id c80so36940050lfh.3 for ; Thu, 20 Apr 2017 16:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=chqyDxkVoPoHw+1tm7Yhxc4aD9Njk/tU58j24Bi9IVA=; b=nvcMxu1jIgz0hQTr/M8vtIHzYpyR2Zwc6CPjmVNx7MqsELptLVFLK1LLeutFco7m1M 1wxi4NVYybtkCbMeY+5Rd9TAvKdpsRmSoEZCQPEDuvgqbIMX3QqrcOl1h0Gxdk0LkGY9 OPH0gUvmQj8nGBNp95OI3IkpWtb4gQP50BaFYmmfhBduyKqe2BQqheM5m8xMxWU0DQGb ds9K1mmRnpDUhK1Tx5N278HFd5BwPc+YiTUkCZbSn+9MJ2h5ntvzdfpBYetykM3c2ZM5 kr2V/zM7zcSMERJ1ECH9/jY8OUYOdkPwoR4L7FbTjBTMJFvOpY5zCvXcZiLUt9EajCW4 5LAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=chqyDxkVoPoHw+1tm7Yhxc4aD9Njk/tU58j24Bi9IVA=; b=AKAH9pONbCYDXkreDRnp/fsROfrwlR2Lb0LBxUVIJdzVtNmSbcwnSF2VODvqIrcU2r dojLZo6wxnKNMYspdBLklDeLqQdkrnp+79oZ0AeZP/5HOK89MaGScR2tGWzeUD/eMCzW /O+D9cGhbg2qqYDXP6Weu6rgR4NC/DfK8045me3fwbkJXHNbF/alZ2M4KF00t2UYFeSc 4B30DkXhHBkS2FVZJ2aBr3rp7ZkHlAWSzp6askgMO+xukqKoJDB+fddtQCBfYQ6XhW1e mXBEV1+rHiyUZYxDSexn6mYIEZ6fD2o4oJpVe7bOmXaSLKkBeLm9M6Lf076LOu9atpBL Q3XQ== X-Gm-Message-State: AN3rC/67YWTw8qYaeR2zR9m4+NK4cU4wi9ds4Az5qyVAYaCY0YL7PNHE JPE/z7LSf2vyXiu758hb7V62ChmHmMgLaE4= X-Received: by 10.46.75.2 with SMTP id y2mr3854787lja.103.1492732774517; Thu, 20 Apr 2017 16:59:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 20 Apr 2017 16:59:33 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 21 Apr 2017 09:59:33 +1000 Message-ID: Subject: Re: Splitting WINDOW_UPDATE To: Jana Iyengar Cc: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2017 23:59:39 -0000 Mike suggested a hack that seems quite elegant. Rather than defining a new frame for expressing frustration over being unable to open a new stream, just use STREAM_BLOCKED: https://github.com/quicwg/base-drafts/pull/457 On 20 April 2017 at 16:08, Martin Thomson wrote: > Given favourable feedback thus far, I have a few follow-on changes: > > This splits BLOCKED in the same way: > https://github.com/quicwg/base-drafts/pull/454 > > Splitting these frames allows us to move crypto to stream 0 and the > HTTP control stream to stream 1. That doesn't sound like much, but it > removes a few surprising and unnecessary corner cases: > https://github.com/quicwg/base-drafts/pull/456 > > I'm much less certain about adding more BLOCKED-like functionality for > the new MAX_STREAM_ID frame type (aka LIMIT_UPDATE), but it was easy. > So I have a PR for that too: > https://github.com/quicwg/base-drafts/pull/455 > > > On 20 April 2017 at 15:38, Jana Iyengar wrote: >> I like this set of changes -- it cleans up things. I've left some comments >> on the PR. Thanks for writing this up. >> >> On Wed, Apr 19, 2017 at 9:33 PM, Martin Thomson >> wrote: >>> >>> In practice WINDOW_UPDATE is two different messages. This makes the >>> split clearer. >>> >>> https://github.com/quicwg/base-drafts/pull/450 >>> >>> Splitting has several advantages, the most obvious being that it >>> shaves 4 bytes of a very common frame (the connection-level update). >>> The less obvious one is that stream 0 no longer needs to be considered >>> as special (yeah BLOCKED would need fixing), which opens up the >>> possibility of removing some long-standing annoyances. >>> >>> As part of this, I've made the description and handling of our three >>> limits a little better aligned by renaming the frames: connection >>> data, stream data, and stream IDs. >>> >> From nobody Thu Apr 20 18:12:07 2017 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 0D22112EAB1 for ; Thu, 20 Apr 2017 18:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 LwaOMvmhKbKD for ; Thu, 20 Apr 2017 18:12:05 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 19171128D69 for ; Thu, 20 Apr 2017 18:12:05 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id 75so37483179lfs.2 for ; Thu, 20 Apr 2017 18:12:05 -0700 (PDT) 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=SYIQPEbrI/N9mFSDWQ+qfVRfYADLVBfjQIKUmznfc5U=; b=kjjwTwPykOD67wCvS8KDdfAMnFfT9IavN3xhQ3d9UZI23jT+Dqxc+5h4eQ0SberXVz zjlcDHrHuZ6Z+SnxRDmcV1IYrogLbpPe/4j7ZYmQWEAHR//fctaQe4+0Sr6FLWbXuxex X4zOImYoHB4wbbXcXLTcTKnTQMtVSA7XOvuEYLn6msK2xKMhHBjtbD9TgcRY/3hL4U2w Gwu0GSw1e3wkc0/KV3tIlZrWsKqx5abSpNCDfNikMyEJoNnG7v5qwC7lSDNosqtwB8uF s5At67UUEEV08MzQ66gCd1zZ5pH7/E54++Cl6jTxrBHT8OcSnW8oR3hoC96vW9X4ARl3 0qSA== 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=SYIQPEbrI/N9mFSDWQ+qfVRfYADLVBfjQIKUmznfc5U=; b=C8FmNE47o+WgcyS/dpP0we17NAQmIJLGKKMGqqA0N+oa9dctUt+jY+cno7WnNUHLTu T6bPTkVlzsZSgsg8QWXrEIhuTHr5BoS2LhaO9St9dDAY4HRT0SnLRD6+fClFODIIviyL UUGy44T9AHK1icRPs9imMzoXKo4EChSWgIYt+Mx4QbNyl0Wyjo0PHxgjPP1azLCRvPvf tr0rnBlaTmnJjvZoX5EHbXigZ0sInjbyxh5izQE/o3NQujXQAjw3npvwZ878MN35saCz VsPsYdrwLhON+VwLTlUqCifudZFJ7nyZ8lter5kPCuwzSqLkBdnHWZMo8IEPvd8R+izc sDPw== X-Gm-Message-State: AN3rC/4vOktoQz+b0h+pnXkKs6YDSrjMw+z5HaLS5yKz1Q/h3hjVMgJg oW4bgxXbqNg7bGqz58NkI8eCFsm0UsGOsq8= X-Received: by 10.25.213.130 with SMTP id m124mr3780537lfg.50.1492737123154; Thu, 20 Apr 2017 18:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 20 Apr 2017 18:12:02 -0700 (PDT) From: Martin Thomson Date: Fri, 21 Apr 2017 11:12:02 +1000 Message-ID: Subject: Changing effect RST_STREAM has on stream state To: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Apr 2017 01:12:07 -0000 The current draft contains a bug where it does not permit the use of RST_STREAM on an idle stream. Given our design for push promise, this is a feature that we absolutely need. The only mention of this currently is text that allows RST_STREAM to be received on an idle stream, it says nothing about what to do with it. The fix that I'd like to make to here is bigger than a small patch. I'm proposing that we change the way we are describing RST_STREAM. It doesn't change the semantics at all, but merely recognizes that the protocol depends on having a stream close in both directions: either RST_STREAM or FIN. RST_STREAM no longer causes the state to go straight to closed without collecting 200 in your preferred currency, it only half-closes the stream. The PR contains more info, including nice ASCII art: https://github.com/quicwg/base-drafts/pull/459 I have marked the PR editorial. It doesn't change what happens on the wire, but this is a pretty big change in the way we describe things, so I wanted to float the change here. From brett@brettjackson.org Thu Apr 20 18:58:08 2017 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 994B0129B9E for ; Thu, 20 Apr 2017 18:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, MIME_QP_LONG_LINE=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=brettjackson.org 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 B80Ryp35j2_h for ; Thu, 20 Apr 2017 18:58:07 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 0349D129B04 for ; Thu, 20 Apr 2017 18:58:07 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id k87so97390313ioi.0 for ; Thu, 20 Apr 2017 18:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brettjackson.org; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=AGA38BN2jbGRlzoIoDD4P4SAsO64yUR38i/Q7U0SDJU=; b=bZFqgPj4ePDHKMqeR7wTaIci3xhcl5T3Q+QCSRp3xflfyjhRX9kheIEwDrdYKlGEmR 4328Ae4hXZyh/pa4Ehbwgr+vU4BeL2lOfVc6U3kkLoTEAplc2TyJgNGkQvsFvZp64p+Q iSG03Xj8z4CXPs9yvg1C8OZR6Zvm+y7PhknNqNDZTDs6GUrXO2DEFLMl5XU4/KM87OKm DM5wO1yKJCYAl/VQiyHOiGUkFXAM1Ex/ggl2JBw1etPesiCJCRZ8n6Uu6l41pzXEoQTp 6l/q8DgIMTGylKE0H0lz4Vc+unmBZZ5AEkCWpD+WSAkKXne5Lc4dQbZQQqMAJ7jvFtwb M76Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=AGA38BN2jbGRlzoIoDD4P4SAsO64yUR38i/Q7U0SDJU=; b=A6b62ZHg8kMT+HDLrneGimuNMeV0BJ3yuCNm385NHhocQAbxbhV43+POAFU8+rei+9 EDn2yo69nxcFStgxUyrOxL5KUCE+1yQPhAarK2FE0r51Qag3cMlTnUFXK6fRwEVE9hov b8kd1OUsR+QH76bsS0DigM6GmeSmNm5JLw41m4Z0fwkVLL8wcz1lsmyEwe5Oej60zQd1 L01iE8Sbjq3EEM9+IGQago7KY+6QRZdHyEGgWs7Cr381Zme1KdV9D3ET34gNaYmweW+w x1TE7g2TaXuZzz49Qi+rLdIL+vQLeA6KcQ349F3jlRdm6FqLh+SMpktAoV8U42wDSDmI n7ng== X-Gm-Message-State: AN3rC/5rfS2WlVREYeEu3gfn5MfRCYiUSxU0fTHQiB6XeF+AlLBVwEYO lIEJULTZSU2f0ALSVOA= X-Received: by 10.107.51.136 with SMTP id z130mr12817770ioz.132.1492739884393; Thu, 20 Apr 2017 18:58:04 -0700 (PDT) Received: from [192.168.0.107] (mr-urb-180-138.dmisinetworks.net. [66.253.180.138]) by smtp.gmail.com with ESMTPSA id s40sm161878ite.18.2017.04.20.18.58.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 18:58:03 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 20 Apr 2017 20:58:03 -0500 Subject: Reference Implementation From: Brett Jackson To: Message-ID: <5162675A-A5FE-4900-A091-302C03346CBB@brettjackson.org> Thread-Topic: Reference Implementation Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3575566684_116388648" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Apr 2017 01:59:33 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3575566684_116388648 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Are there currently any reference implementations in progress? --B_3575566684_116388648 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Are there currently any reference implementations in progress?=

--B_3575566684_116388648-- From nobody Thu Apr 20 19:04:16 2017 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 B9645129B04 for ; Thu, 20 Apr 2017 19:04:14 -0700 (PDT) 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_HELO_PASS=-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 SHV6JolwfZyg for ; Thu, 20 Apr 2017 19:04:12 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 44DFA129B66 for ; Thu, 20 Apr 2017 19:04:12 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 38DE922E256; Thu, 20 Apr 2017 22:04:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Reference Implementation From: Mark Nottingham In-Reply-To: <5162675A-A5FE-4900-A091-302C03346CBB@brettjackson.org> Date: Fri, 21 Apr 2017 12:04:02 +1000 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5162675A-A5FE-4900-A091-302C03346CBB@brettjackson.org> To: Brett Jackson X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Apr 2017 02:04:14 -0000 Hi Brett, > On 21 Apr 2017, at 11:58 am, Brett Jackson = wrote: >=20 > Are there currently any reference implementations in progress? We haven't yet nominated a draft to implement; people have done some = informal coding, and of course there's the gQUIC implementation, but = nothing more. Additionally, the IETF doesn't generally nominate = "reference" implementations, since that implies that a failure to = interoperate with one implementation is a failure to conform to the = specification. We hope to designate a first draft for implementation after our next = Interim meeting in early June; early implementations should start to = emerge after that. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Apr 21 00:36:14 2017 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 3E655129494 for ; Fri, 21 Apr 2017 00:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 CcKsBRDk1F7Z for ; Fri, 21 Apr 2017 00:36:11 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 3E077120724 for ; Fri, 21 Apr 2017 00:36:11 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id t144so40531605lff.1 for ; Fri, 21 Apr 2017 00:36:11 -0700 (PDT) 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=hDFfnNlI4B1J55fSnwu0/vJ0aZ4Xf9pjUoJi8trO4Q8=; b=AJuxBpn3jWUEfw5hraWMRu4RzG+CIaD/3gR3Ia869cn3aoH8r4SIRguqfFD2UWl0Fd 952IPqViMbSBBgjPNE5sNFr3dg2cGGJ4MNxFJxbL4dJ3oRrm7NIJ5vXpJM+48Uz/+N3Y kBLVcSqg2loG61u+kr+cmrNDdAXWZ7peJiAtPPlzEfwWzvTyOpG2AfCs03QUBFeIidwu jT90SWxVZtHkL+POJWbVrnox6I0PgyWuFFEZs3bb1frROrMILEVIne8S959YPJx5IVkD 0KrMN/IKp4bijW2DL1X1npAx4zPuJyAuOhLxlyzycX0T+cf8EFIiJgVLHeUJ2IFYRQXN 6slQ== 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=hDFfnNlI4B1J55fSnwu0/vJ0aZ4Xf9pjUoJi8trO4Q8=; b=ZM2J3ZMv2ExWRxAkExe7iTrYpxBUBb61ujm2hSdbr3VCVNXZjzdsEKeqwdg1xHQtll KhFp9wpITim/IT2yaS2FOzlSCtOeN3yTrklVCVxopLiqC1ytW2mW4CgvVSQ/OiCOoHg0 38JZmVft47IQQduhfdnfE0VtzNQogqDTLjq/eNjMxe2PsyIHCpj7di+G2gDXKw20iehT gHypZR3oxhqVRG8JhdkLA5XDfESvyCjWPe/AtTLpHB7LOA7J9pe+RWcYtrD1jhlshKrm nvoGr+esIBhf4PucNV7V9peQQNqA6phnaa1Is98vWAbzfm+/+G7VlBWUZKL/UtlorzPq om8w== X-Gm-Message-State: AN3rC/4PSyIbL5YTSsZRYTV2DBLUK+sY4FylK4ifaf0OUv40rL2hdrO8 d7tANj5CwSxmEGyvs5cxx9f0QjomBRwPVAo= X-Received: by 10.25.76.6 with SMTP id z6mr4187636lfa.172.1492760169287; Fri, 21 Apr 2017 00:36:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Fri, 21 Apr 2017 00:36:08 -0700 (PDT) From: Martin Thomson Date: Fri, 21 Apr 2017 17:36:08 +1000 Message-ID: Subject: Updated Public Reset authentication patch To: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Apr 2017 07:36:13 -0000 Back at the very start of this process, ekr proposed a design for public reset [1] that was quite popular, but we never got round to closing on the issue, or landing the change. Since then everything changed. I just spent a bit of time with this and I have a shiny new PR for this. I've convinced myself that the design is sound, simple, and quite workable. https://github.com/quicwg/base-drafts/pull/460 There are a couple of wrinkles we should discuss a little here: * This uses transport parameters for the verifier and these are encrypted. The original design called for the verifier to appear in the clear so that intermediaries can validate the reset. Moving the verifier into clear is tricky. It would require either moving all transport parameters out from under encryption or splitting transport parameters into encrypted and not-encrypted. Neither option is particularly appealing to me. I don't think that we need the verifier in the clear. An on-path intermediary can be reasonably assured that the generator of the packet was on path based on the 12 octets that are copied from the packet that triggered the reset. I would argue that that signal is enough to know that data on the path is going to cease. The intermediary doesn't need to know that the *connection* is going away, which is what the proof would provide them, they only need to concern themselves with the data that flows on the *path*. * There's a little bit of a challenge in ensuring that the combination of connection ID, server ID and key aren't reused. I think that the way you do this is split the portion of the connection ID space allocated to a server into two and use which half you are in to signal which of two keys you are using, then slowly rotate the keys (you can use alt-svc to accelerate this). This isn't in the write-up, because it's just one potential design in this space. I mostly just want to make sure that this level of extra complexity is justified/manageable for those that need to use the basic stateless design that is suggested in the PR. [1] https://github.com/quicwg/base-drafts/pull/20 From nobody Fri Apr 21 03:09:25 2017 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 63CEE129B6A for ; Fri, 21 Apr 2017 03:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 rwM19dJxwJZj for ; Fri, 21 Apr 2017 03:09:21 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 318EC129B52 for ; Fri, 21 Apr 2017 03:09:21 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u70so50849721ywe.2 for ; Fri, 21 Apr 2017 03:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZrFxvJlYqvvJecj/1+Ju7jHfcMpcTg866WiGRzBTieM=; b=1i7us/eU5vGHrNCqEDpPEjyz22VVVu64pIHERJw98A+KqvJsYy3kAI1CstehE2gLK4 CtE7V7QRdVqz/MiDarzVPHrm8dXXdfhy/yjBj6T4fdpfj1hxQM3YvVdzRT93C23pklp7 ifladzOI6+XESq3UwAQQnVFIcN4dArIpWleVOljwfYmFmnZ2Yrt1Zlam5wtxpiI1FJ4d V6FwOzBbnkqR7fvOMUQ3nGp9Vesj27pyBJLK4eh8oRMOPtT0LNPJHGzVv6gqWbah8D1S fw4kbBvQ/aV3XLyvk8IVkIg8Wwh+I6VJM85sqW+N8EmdrHJYXi8PNj6c1P+sWJ7NtSPx ggsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZrFxvJlYqvvJecj/1+Ju7jHfcMpcTg866WiGRzBTieM=; b=hPKfPpl5nF8kpnJePL5nG5sRrCoHsSLZ5ipz4WZbjxBdq3+n2FUpZtSQ6C+RozF/nA QJ8zWlpnnkFkoduEdZX59uxKUAOi1GhmeCJ4FNY+2cz7IYs+rC+Me+g+LyeZ0YefIknZ sqLGhLQCa8ueLzSRbffjwoitP8UdM10fiiVCtF9rh7KsxcaHBCqdMTVvsyPUaBDR0NVI ju+fv4KfFhawmpRMd2Z9m8z+D53Z8M0Unqok7dK8qAvBoaTBccRJ+HEizZfPdxNnVFcE yy6rZvZ9Ij9V9oLGK2s/qNvYfp03/iKd3bpSjJjf9yPai89PmPD4H8LoQwSHruWU4dX3 PChw== X-Gm-Message-State: AN3rC/59dCO1ruRrsO3+vKX1oscXoMakndl1QF5xMO+5XD++YnTdgY3A 5Zg32M++7okIYI8Qwcmw6jV537x5rA== X-Received: by 10.129.182.65 with SMTP id h1mr10679283ywk.337.1492769360501; Fri, 21 Apr 2017 03:09:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Fri, 21 Apr 2017 03:08:39 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 21 Apr 2017 06:08:39 -0400 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary=94eb2c1bde9c76f4b9054daa7341 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Apr 2017 10:09:23 -0000 --94eb2c1bde9c76f4b9054daa7341 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 21, 2017 at 3:36 AM, Martin Thomson wrote: > Back at the very start of this process, ekr proposed a design for > public reset [1] that was quite popular, but we never got round to > closing on the issue, or landing the change. Since then everything > changed. > > I just spent a bit of time with this and I have a shiny new PR for > this. I've convinced myself that the design is sound, simple, and > quite workable. > > https://github.com/quicwg/base-drafts/pull/460 > > There are a couple of wrinkles we should discuss a little here: > > * This uses transport parameters for the verifier and these are encrypted. > > The original design called for the verifier to appear in the clear so > that intermediaries can validate the reset. > > Moving the verifier into clear is tricky. It would require either > moving all transport parameters out from under encryption or splitting > transport parameters into encrypted and not-encrypted. Neither option > is particularly appealing to me. > > I don't think that we need the verifier in the clear. An on-path > intermediary can be reasonably assured that the generator of the > packet was on path based on the 12 octets that are copied from the > packet that triggered the reset. I would argue that that signal is > enough to know that data on the path is going to cease. The > intermediary doesn't need to know that the *connection* is going away, > which is what the proof would provide them, they only need to concern > themselves with the data that flows on the *path*. > This seems like the key point in this PR. I don't think it's an unreasonable design, but I'm not sure it's the right one either. The situation I am concerned with is one in which the middlebox uses the public reset to garbage collect some hard state. In that case, a man-on-the-side attacker can inject a public reset and block the connection. We do know that this form of attack on endpoints happens (TCP RST injection), so it seems like we might want to defend against it here. I'm not sure what the right answer is, but I think we probably ought to decide it from general principles about how we want the protocol to behave rather than what's convenient to encode on the wire. With that said, I'm also not too worried about encoding it on the wire. Public reset isn't really a parameter, but rather part of the connection crypto state, so it wouldn't be unreasonable to shove it in a ServerHello extension. I could even imagine this as a non-QUIC TLS extension, as you might imagine using it in DTLS. -Ekr * There's a little bit of a challenge in ensuring that the combination > of connection ID, server ID and key aren't reused. > > I think that the way you do this is split the portion of the > connection ID space allocated to a server into two and use which half > you are in to signal which of two keys you are using, then slowly > rotate the keys (you can use alt-svc to accelerate this). This isn't > in the write-up, because it's just one potential design in this space. > I mostly just want to make sure that this level of extra complexity is > justified/manageable for those that need to use the basic stateless > design that is suggested in the PR. > > > [1] https://github.com/quicwg/base-drafts/pull/20 > > --94eb2c1bde9c76f4b9054daa7341 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 21, 2017 at 3:36 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
Back at the very start of this process, ekr proposed a design for
public reset [1] that was quite popular, but we never got round to
closing on the issue, or landing the change.=C2=A0 Since then everything changed.

I just spent a bit of time with this and I have a shiny new PR for
this.=C2=A0 I've convinced myself that the design is sound, simple, and=
quite workable.

https://github.com/quicwg/base-drafts/pull/460

There are a couple of wrinkles we should discuss a little here:

* This uses transport parameters for the verifier and these are encrypted.<= br>
The original design called for the verifier to appear in the clear so
that intermediaries can validate the reset.

Moving the verifier into clear is tricky.=C2=A0 It would require either
moving all transport parameters out from under encryption or splitting
transport parameters into encrypted and not-encrypted.=C2=A0 Neither option=
is particularly appealing to me.

I don't think that we need the verifier in the clear.=C2=A0 An on-path<= br> intermediary can be reasonably assured that the generator of the
packet was on path based on the 12 octets that are copied from the
packet that triggered the reset.=C2=A0 I would argue that that signal is enough to know that data on the path is going to cease.=C2=A0 The
intermediary doesn't need to know that the *connection* is going away,<= br> which is what the proof would provide them, they only need to concern
themselves with the data that flows on the *path*.

<= div>I don't think it's an unreasonable design, but I'm not sure= it's the right one

I'm not sure what the right answer is, but I think we probably = ought to
decide it from general principles about how we want the = protocol to
behave rather than what's convenient to encode on= the wire. With that
said, I'm also not too worried about enc= oding it on the wire. Public reset
isn't really a parameter, = but rather part of the connection crypto state,
so it wouldn'= t be unreasonable to shove it in a ServerHello extension.
I could= even imagine this as a non-QUIC TLS extension, as you might
imag= ine using it in DTLS.

-Ekr

--94eb2c1bde9c76f4b9054daa7341-- From nobody Fri Apr 21 04:28:38 2017 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 9B5E5129461 for ; Fri, 21 Apr 2017 04:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de 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 VE67yQ-G8KQT for ; Fri, 21 Apr 2017 04:28:34 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (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 8774B129AD5 for ; Fri, 21 Apr 2017 04:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1492774111; l=2711; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=gYWsNSSWjJhf+fdoSyKIl560xJEZof9HV6sBu46umPM=; b=WtI61hw3/JvAKkuEnvRZrcshGORL/PizGf5BxlkXPX/uBdYxUo8LiughHsM7Dsjjfh OiXpv8dvMSzX2g9pg2Hq59jfVgmYmC38x3pXKC3sDx45bkywYgXAxAH3HU8r1Bes+MnG JQMQBRb7w7n6Z/8eiSwrfBnjfUFV2gotUwzo4= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzTv5AXpfVAjjl5+LxoV/FFYw/iSA== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:b460:abca:c974:72cd] ([2001:4dd0:ff67:0:b460:abca:c974:72cd]) by smtp.strato.de (RZmta 40.6 AUTH) with ESMTPSA id 001f4dt3LBSUK25 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 21 Apr 2017 13:28:30 +0200 (CEST) Subject: Re: Updated Public Reset authentication patch To: quic@ietf.org References: From: Roland Zink Message-ID: <0f4c4072-488c-d658-8485-7cedd9f03fa0@zinks.de> Date: Fri, 21 Apr 2017 13:28:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Apr 2017 11:28:37 -0000 Am 21.04.2017 um 09:36 schrieb Martin Thomson: > Back at the very start of this process, ekr proposed a design for > public reset [1] that was quite popular, but we never got round to > closing on the issue, or landing the change. Since then everything > changed. > > I just spent a bit of time with this and I have a shiny new PR for > this. I've convinced myself that the design is sound, simple, and > quite workable. > > https://github.com/quicwg/base-drafts/pull/460 > > There are a couple of wrinkles we should discuss a little here: > > * This uses transport parameters for the verifier and these are encrypted. > > The original design called for the verifier to appear in the clear so > that intermediaries can validate the reset. > > Moving the verifier into clear is tricky. It would require either > moving all transport parameters out from under encryption or splitting > transport parameters into encrypted and not-encrypted. Neither option > is particularly appealing to me. > > I don't think that we need the verifier in the clear. An on-path > intermediary can be reasonably assured that the generator of the > packet was on path based on the 12 octets that are copied from the > packet that triggered the reset. I would argue that that signal is > enough to know that data on the path is going to cease. The > intermediary doesn't need to know that the *connection* is going away, > which is what the proof would provide them, they only need to concern > themselves with the data that flows on the *path*. Assuming a DDOS attack which is answered with public resets then middleboxes knowing the connection is going away can throw away further packets, e.g. prevent the DDOS near the sources. The connection id is in the copied octets so a middlebox may attempt this with the proposed solution. However in this case connections may be broken by sending public resets which couldn't be verified by the middlebox. Roland > * There's a little bit of a challenge in ensuring that the combination > of connection ID, server ID and key aren't reused. > > I think that the way you do this is split the portion of the > connection ID space allocated to a server into two and use which half > you are in to signal which of two keys you are using, then slowly > rotate the keys (you can use alt-svc to accelerate this). This isn't > in the write-up, because it's just one potential design in this space. > I mostly just want to make sure that this level of extra complexity is > justified/manageable for those that need to use the basic stateless > design that is suggested in the PR. > > > [1] https://github.com/quicwg/base-drafts/pull/20 > From nobody Fri Apr 21 09:34:59 2017 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 55D1B12EAA9 for ; Fri, 21 Apr 2017 09:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 o-PgdwEHjNGD for ; Fri, 21 Apr 2017 09:34:55 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0127.outbound.protection.outlook.com [104.47.36.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029AF127735 for ; Fri, 21 Apr 2017 09:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pyDaJfDYt5E1cVmW/a4QR8UEPcapbND0VHf87gjc8Vo=; b=ekfXerxpowiLQMvhKVEt3wIp+afzQNGH/3PWY42Xbu78QEO8m2QD54F6OBGFrtCLSQrPAZzqq8SirMmlnxaXsVDdG45xYEG1hqOnIy7Cz8sxDQ7r+GVWRkUppV7Z692kVZFJqZTIW7Et1t+2Ea6PGyZfRx+2IuVp8idHg6XPjmM= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Fri, 21 Apr 2017 16:34:50 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1034.015; Fri, 21 Apr 2017 16:34:50 +0000 From: Mike Bishop To: Martin Thomson , Jana Iyengar CC: QUIC WG Subject: RE: Splitting WINDOW_UPDATE Thread-Topic: Splitting WINDOW_UPDATE Thread-Index: AQHSuY9VlvMSNIlPZEW/QS1k/+7fCKHNvaSAgAAIQICAAStNgIABFbZw Date: Fri, 21 Apr 2017 16:34:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:2::51f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:/FsEGszQI7gQgAkh9Eg1YfiNLt9glFzsZ3k00skV/D+DOcDx72q0yvqionoCyy8H5J/KTym2mb2Ivm26bDYe4fRv9FhiInLjd6BMFR2QHQeh8kh258NGptv01BN7cEHoFy85CQhCFijv6n/N6UtlR6LvFbs4Ue6kDr9nsKp2h/Lua9J/mdezjY6gp8eqprISeqZIQuH2Ge+OZHeyuD2oY8nH4C7+k3uK4yTiag9Rdzdu+v9nDeqKf1cCkzEaJ4rVCfCL7LOcneQW/HPu+4voyvvkdyvbQ08SRIy+b5qEXbJbHJhh8GoaXwMU31OEZmrluo/hxN8TPOD/Jd9rcXPgyt5bRX7mdLa4ieWwdw1reG8= x-ms-office365-filtering-correlation-id: 20517a3b-ff28-441e-ec24-08d488d4550b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2708; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(211936372134217)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39400400002)(39450400003)(39840400002)(39860400002)(377454003)(13464003)(24454002)(93886004)(76176999)(8990500004)(33656002)(3660700001)(74316002)(3280700002)(6436002)(4326008)(2950100002)(6506006)(55016002)(102836003)(6306002)(6246003)(305945005)(25786009)(6116002)(229853002)(38730400002)(189998001)(7696004)(53546009)(99286003)(7736002)(9686003)(77096006)(39060400002)(53936002)(575784001)(2900100001)(5005710100001)(7116003)(122556002)(8676002)(97736004)(81156014)(2906002)(10290500002)(5660300001)(81166006)(8936002)(86362001)(86612001)(50986999)(54356999)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 16:34:50.5630 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Apr 2017 16:34:57 -0000 VGhhdCBhbHNvIG1lYW5zIHlvdSBjYW4gc2ltcGxpZnkgYXdheSB0aGUgbWF4IHN0cmVhbSBJRCBl dmVuIGZ1cnRoZXIgLS0gSURzIHVwIHRvIHRoZSBzdGF0ZWQgbWF4IGhhdmUgYSBtYXhpbXVtIG9m ZnNldCBhcyBuZWdvdGlhdGVkLCBhbmQgSURzIGJleW9uZCB0aGF0IHZhbHVlIGhhdmUgYSBtYXhp bXVtIG9mZnNldCBvZiB6ZXJvLiAgVGhlbiB0aGVyZSBpcyBubyAibWF4IGNvbmN1cnJlbnQgc3Ry ZWFtcywiIG9ubHkgc3RyZWFtcyB0aGF0IGFyZSBibG9ja2VkIGJ5IGZsb3cgY29udHJvbC4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KU2VudDogVGh1cnNkYXks IEFwcmlsIDIwLCAyMDE3IDU6MDAgUE0NClRvOiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29t Pg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU3BsaXR0aW5nIFdJ TkRPV19VUERBVEUNCg0KTWlrZSBzdWdnZXN0ZWQgYSBoYWNrIHRoYXQgc2VlbXMgcXVpdGUgZWxl Z2FudC4gIFJhdGhlciB0aGFuIGRlZmluaW5nIGEgbmV3IGZyYW1lIGZvciBleHByZXNzaW5nIGZy dXN0cmF0aW9uIG92ZXIgYmVpbmcgdW5hYmxlIHRvIG9wZW4gYSBuZXcgc3RyZWFtLCBqdXN0IHVz ZSBTVFJFQU1fQkxPQ0tFRDoNCmh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJh ZnRzJTJGcHVsbCUyRjQ1NyZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29m dC5jb20lN0NmZWM1NjcwYWQzYzk0NjQ5OGIyNDA4ZDQ4ODQ5NTBlMSU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyODMyOTU4NTMyMzc4MDYmc2RhdGE9bHVW UUV4UlBLckZtZm1UOG16USUyRlJuNSUyQkpuR1NLQzY0eWg5eEJNczYwSGMlM0QmcmVzZXJ2ZWQ9 MA0KDQpPbiAyMCBBcHJpbCAyMDE3IGF0IDE2OjA4LCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRo b21zb25AZ21haWwuY29tPiB3cm90ZToNCj4gR2l2ZW4gZmF2b3VyYWJsZSBmZWVkYmFjayB0aHVz IGZhciwgSSBoYXZlIGEgZmV3IGZvbGxvdy1vbiBjaGFuZ2VzOg0KPg0KPiBUaGlzIHNwbGl0cyBC TE9DS0VEIGluIHRoZSBzYW1lIHdheToNCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodQ0KPiBiLmNvbSUyRnF1aWN3 ZyUyRmJhc2UtZHJhZnRzJTJGcHVsbCUyRjQ1NCZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hv DQo+IHAlNDBtaWNyb3NvZnQuY29tJTdDZmVjNTY3MGFkM2M5NDY0OThiMjQwOGQ0ODg0OTUwZTEl N0M3MmY5ODhiZjg2ZjE0MWENCj4gZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI4MzI5 NTg1MzIzNzgwNiZzZGF0YT1jc1hYTE5hYWZOUSUyQm5XWA0KPiBwNnFQdGJROXBTUVdLJTJCZXE2 bE9wSnNYQ3RSSnMlM0QmcmVzZXJ2ZWQ9MA0KPg0KPiBTcGxpdHRpbmcgdGhlc2UgZnJhbWVzIGFs bG93cyB1cyB0byBtb3ZlIGNyeXB0byB0byBzdHJlYW0gMCBhbmQgdGhlIA0KPiBIVFRQIGNvbnRy b2wgc3RyZWFtIHRvIHN0cmVhbSAxLiAgVGhhdCBkb2Vzbid0IHNvdW5kIGxpa2UgbXVjaCwgYnV0 IGl0IA0KPiByZW1vdmVzIGEgZmV3IHN1cnByaXNpbmcgYW5kIHVubmVjZXNzYXJ5IGNvcm5lciBj YXNlczoNCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZnaXRodQ0KPiBiLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJG cHVsbCUyRjQ1NiZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvDQo+IHAlNDBtaWNyb3NvZnQu Y29tJTdDZmVjNTY3MGFkM2M5NDY0OThiMjQwOGQ0ODg0OTUwZTElN0M3MmY5ODhiZjg2ZjE0MWEN Cj4gZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI4MzI5NTg1MzIzNzgwNiZzZGF0YT1H ZVc3dEk5NVlocTBWODNURg0KPiBISDdoRlVlazBDbXdyQmxhVFRNWElrWUpBNCUzRCZyZXNlcnZl ZD0wDQo+DQo+IEknbSBtdWNoIGxlc3MgY2VydGFpbiBhYm91dCBhZGRpbmcgbW9yZSBCTE9DS0VE LWxpa2UgZnVuY3Rpb25hbGl0eSBmb3IgDQo+IHRoZSBuZXcgTUFYX1NUUkVBTV9JRCBmcmFtZSB0 eXBlIChha2EgTElNSVRfVVBEQVRFKSwgYnV0IGl0IHdhcyBlYXN5Lg0KPiBTbyBJIGhhdmUgYSBQ UiBmb3IgdGhhdCB0b286DQo+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHUNCj4gYi5jb20lMkZxdWljd2clMkZiYXNl LWRyYWZ0cyUyRnB1bGwlMkY0NTUmZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNobw0KPiBwJTQw bWljcm9zb2Z0LmNvbSU3Q2ZlYzU2NzBhZDNjOTQ2NDk4YjI0MDhkNDg4NDk1MGUxJTdDNzJmOTg4 YmY4NmYxNDFhDQo+IGY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyODMyOTU4NTMyMzc4 MDYmc2RhdGE9WDlQR29keWtnWU10JTJGck4NCj4gUTQyNlBaYXdsV0tKdXBzdUx1aU56QzhGUVh1 SSUzRCZyZXNlcnZlZD0wDQo+DQo+DQo+IE9uIDIwIEFwcmlsIDIwMTcgYXQgMTU6MzgsIEphbmEg SXllbmdhciA8anJpQGdvb2dsZS5jb20+IHdyb3RlOg0KPj4gSSBsaWtlIHRoaXMgc2V0IG9mIGNo YW5nZXMgLS0gaXQgY2xlYW5zIHVwIHRoaW5ncy4gSSd2ZSBsZWZ0IHNvbWUgDQo+PiBjb21tZW50 cyBvbiB0aGUgUFIuIFRoYW5rcyBmb3Igd3JpdGluZyB0aGlzIHVwLg0KPj4NCj4+IE9uIFdlZCwg QXByIDE5LCAyMDE3IGF0IDk6MzMgUE0sIE1hcnRpbiBUaG9tc29uIA0KPj4gPG1hcnRpbi50aG9t c29uQGdtYWlsLmNvbT4NCj4+IHdyb3RlOg0KPj4+DQo+Pj4gSW4gcHJhY3RpY2UgV0lORE9XX1VQ REFURSBpcyB0d28gZGlmZmVyZW50IG1lc3NhZ2VzLiAgVGhpcyBtYWtlcyB0aGUgDQo+Pj4gc3Bs aXQgY2xlYXJlci4NCj4+Pg0KPj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0DQo+Pj4gaHViLmNvbSUyRnF1aWN3ZyUy RmJhc2UtZHJhZnRzJTJGcHVsbCUyRjQ1MCZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmINCj4+PiBp c2hvcCU0MG1pY3Jvc29mdC5jb20lN0NmZWM1NjcwYWQzYzk0NjQ5OGIyNDA4ZDQ4ODQ5NTBlMSU3 QzcyZjk4OGJmOA0KPj4+IDZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyODMy OTU4NTMyMzc4MDYmc2RhdGE9ZzA5VnVkaGt6DQo+Pj4gNUxYV3VNVGRLTTBhdHZkTHBCa21rdkhH a2pLdldLbDlCTSUzRCZyZXNlcnZlZD0wDQo+Pj4NCj4+PiBTcGxpdHRpbmcgaGFzIHNldmVyYWwg YWR2YW50YWdlcywgdGhlIG1vc3Qgb2J2aW91cyBiZWluZyB0aGF0IGl0IA0KPj4+IHNoYXZlcyA0 IGJ5dGVzIG9mIGEgdmVyeSBjb21tb24gZnJhbWUgKHRoZSBjb25uZWN0aW9uLWxldmVsIHVwZGF0 ZSkuDQo+Pj4gVGhlIGxlc3Mgb2J2aW91cyBvbmUgaXMgdGhhdCBzdHJlYW0gMCBubyBsb25nZXIg bmVlZHMgdG8gYmUgDQo+Pj4gY29uc2lkZXJlZCBhcyBzcGVjaWFsICh5ZWFoIEJMT0NLRUQgd291 bGQgbmVlZCBmaXhpbmcpLCB3aGljaCBvcGVucyANCj4+PiB1cCB0aGUgcG9zc2liaWxpdHkgb2Yg cmVtb3Zpbmcgc29tZSBsb25nLXN0YW5kaW5nIGFubm95YW5jZXMuDQo+Pj4NCj4+PiBBcyBwYXJ0 IG9mIHRoaXMsIEkndmUgbWFkZSB0aGUgZGVzY3JpcHRpb24gYW5kIGhhbmRsaW5nIG9mIG91ciB0 aHJlZSANCj4+PiBsaW1pdHMgYSBsaXR0bGUgYmV0dGVyIGFsaWduZWQgYnkgcmVuYW1pbmcgdGhl IGZyYW1lczogY29ubmVjdGlvbiANCj4+PiBkYXRhLCBzdHJlYW0gZGF0YSwgYW5kIHN0cmVhbSBJ RHMuDQo+Pj4NCj4+DQoNCg== From nobody Fri Apr 21 21:19:18 2017 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 2CAC1129400 for ; Fri, 21 Apr 2017 21:19:17 -0700 (PDT) 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, FREEMAIL_FROM=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=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 IVWKyqP0YXLS for ; Fri, 21 Apr 2017 21:19:16 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 8F3E21201FA for ; Fri, 21 Apr 2017 21:19:15 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id 88so52977381lfr.0 for ; Fri, 21 Apr 2017 21:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fy0W6hrpdRYBCLJ56jD9BE3dERxEqAEGSewgDZv6DhU=; b=Qyg+PNrQBnFx5038H4pie5JAP2JzeJyXJ4OcRR5DwDVvI/ujryNWT/BrbHrrnhjFtv At+zJpJIey9K7h4wsYDuBrAtvoUppYWbMGdujnfg4qpebSMHWktpFeTDUlduQ211MwYV ODbnTS0YhPj+s6xgndovG4szhgSKeCPutQ30mWnYwzDv/jsiuw1lxStCDN5d3hNKTq+0 oUmooPoBWo6tliKnmbVM3tMK7bVlF44qXS2C6Uozkke8p5jsxIEkHeyS+5YVb7jTvevM bZVvzo/XOxb/+n8Zn233n8ChBx5Pyn9Ej44GC0DsE+aJ2HVCKW/8ZL/jWCr9jAuujUMI kFgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fy0W6hrpdRYBCLJ56jD9BE3dERxEqAEGSewgDZv6DhU=; b=DhHIfnM1RbWsw44jvzlLyFzeFDvkRnRK65MpXo8dkqSgLqX2qV2CE0FsVVR+0KaZgD YUv4PXGQNkoAIRKeThYFJU1NWEMk7C5ZDEx29D5dY+qcxK79i4xUxdojPxXJ6pd0pIJP izxlEp0lqKsP09n9zzWVGAmjKvyTyr3wX2Gr01CVWXUDYYAVf44uAaFy5lXnGtJqBFiq jqex+rq+Rj3axTUBDBRF6DwjeKUagpfW0E9E3ygocJvqTdjxn4mW8NwSPHWIDE6kj65a teCh1FLYJZlLcYm73vwSOq+mcTmrFmPSM+lr3NhJEbF2yZGxmtE3Bxb9j8yRRUbZpECV Cc6Q== X-Gm-Message-State: AN3rC/4PrI8OWtu4IpFD5NaaqaOsCZ93GG2mjK1tghUwvuhh4nI6JM3X Y/ZiPZzQVmxX6hKOyLxUg/yw60mYo9JZ X-Received: by 10.46.87.80 with SMTP id r16mr5924445ljd.50.1492834753950; Fri, 21 Apr 2017 21:19:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Fri, 21 Apr 2017 21:19:13 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Sat, 22 Apr 2017 14:19:13 +1000 Message-ID: Subject: Re: Splitting WINDOW_UPDATE To: Mike Bishop Cc: Jana Iyengar , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 22 Apr 2017 04:19:17 -0000 On 22 April 2017 at 02:34, Mike Bishop wrote: > Mike suggested a hack that seems quite elegant. Rather than defining a new frame for expressing frustration over being unable to open a new stream, just use STREAM_BLOCKED: Nice thought, but it doesn't help because you could still send an empty STREAM with a FIN flag on those streams without violating the limit. From nobody Sat Apr 22 10:29:25 2017 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 5C8B11294B7 for ; Sat, 22 Apr 2017 10:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 4SIet3Hyxo77 for ; Sat, 22 Apr 2017 10:29:22 -0700 (PDT) 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 5D4FE127871 for ; Sat, 22 Apr 2017 10:29:22 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d1yqW-0007Zm-1Y for quic@ietf.org; Sat, 22 Apr 2017 19:29:20 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d1yqT-0001FI-JM for quic@ietf.org; Sat, 22 Apr 2017 13:29:18 -0400 Received: (qmail 5539 invoked from network); 22 Apr 2017 17:29:17 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.199]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Apr 2017 17:29:16 -0000 To: Eric Rescorla , Martin Thomson References: Cc: QUIC WG From: Christian Huitema Message-ID: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> Date: Sat, 22 Apr 2017 10:29:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9521B7DBF976891B245268BC" Subject: Re: Updated Public Reset authentication patch X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49EdlGitVsfXsrKty9N3esIJTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoaUIrz8mxJ52R5/VAonJUqRcOb18WfxGyg6Om6u4YYm5SZZ1fv/zAImnvY r7lYbRs5hjoyEb9Oq0NWpyO3vrfYy2h1mQR50Wwo5hSyeApVLD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB0ktSrwQbrgk6jfwMHIN4qnTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0jWoHf0HV xWOykqLmhYgpD7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWJKyg1OJH8aak+/hDMnS4uzLQQGIH13szEQZ25LjADnMHWdT0yZebgwW1 UGRDwd1ncqiSoo7BxyxRryqmiHuCdUetTZ/25DKDZC7RirBgbePcy8BFh+JufJrwsKmKW6bHd9QD sMspn/O/edVkHySM+CDVwFjZwEavmmk7Tr9uJ5mso9iv7kZ9azJt3DY/E7nm X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 22 Apr 2017 17:29:24 -0000 This is a multi-part message in MIME format. --------------9521B7DBF976891B245268BC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/21/2017 3:08 AM, Eric Rescorla wrote: > > I don't think it's an unreasonable design, but I'm not sure it's the > right one > either. The situation I am concerned with is one in which the middlebox= > uses the public reset to garbage collect some hard state. In that case,= a > man-on-the-side attacker can inject a public reset and block the > connection. > We do know that this form of attack on endpoints happens (TCP RST > injection), so it seems like we might want to defend against it here. > Yes, "Public Reset Injection" is a problem. It is inherent to the Public Reset functionality. And it has to be mitigated. If I remember correctly the previous debates, the simplest mitigation for middleboxes is to handle the Public Reset as a soft signal. Do not destroy the state immediately, only do that after a timer. Cancel the Public Reset if a "regular" QUIC packet comes from the server before the timer. Or, to not be server specific, "comes from the end point that sent the Public Reset". Probably worth documenting in the Security Considerations. -- Christian Huitema --------------9521B7DBF976891B245268BC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/21/2017 3:08 AM, Eric Rescorla wrote:

I don't think it's an unreasonable design, but I'm not sure it's the right one
either. The situation I am concerned with is one in which the middlebox
uses the public reset to garbage collect some hard state. In that case, a
man-on-the-side attacker can inject a public reset and block the connection.
We do know that this form of attack on endpoints happens (TCP RST
injection), so it seems like we might want to defend against it here.


Yes, "Public Reset Injection" is a problem. It is inherent to the Public Reset functionality. And it has to be mitigated.

If I remember correctly the previous debates, the simplest mitigation for middleboxes is to handle the Public Reset as a soft signal. Do not destroy the state immediately, only do that after a timer. Cancel the Public Reset if a "regular" QUIC packet comes from the server before the timer. Or, to not be server specific, "comes from the end point that sent the Public Reset".

Probably worth documenting in the Security Considerations.

-- Christian Huitema
--------------9521B7DBF976891B245268BC-- From nobody Sat Apr 22 10:46:10 2017 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 DEC2512950B for ; Sat, 22 Apr 2017 10:46:09 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 S4RsSvnn-_jf for ; Sat, 22 Apr 2017 10:46:08 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 EEE10129510 for ; Sat, 22 Apr 2017 10:46:07 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id 6so51186867ybq.2 for ; Sat, 22 Apr 2017 10:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tHZIRrOKKnMt0FnL6SfZCvr8L63XWnlpY1cbFxIWqgo=; b=CZ8N6QvF1gqoNLXCNphfA2ESe9zBXpNEloYryhUvfDGXDKNIep36LD0w0mK9CcvDwc U8Delo0BVs/zsv/P2WiLLdb/amdIkQA300USL3oiSHkKItBJPc5CvfB9LhZ1qc5W56pJ +OnIX0gHV703RROdUx6oPC504z5aHF/8IDqSi0Tx2pSfdcQvOCUVl3GEEDKGxbXn4Jgb rQ6dZmfWFGMdnwJIWm1HE9nzzh9Tzt7lYABQsnsgbhVvR3bqTUGFpXrjNNUwHi3wtadR X7Vw3MO7sqRH8xHnWF4OG5BqULZ6smbbe3ELnpVELVBEOQ91myDmGoksMyXnR11c7/NV kEzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tHZIRrOKKnMt0FnL6SfZCvr8L63XWnlpY1cbFxIWqgo=; b=HqbpH2VYCJgRZj9cPSLEpPHaz1sRD8yDEKwQz+ElRfSDF1iHf8sxOeg234OhgbIcs6 JpfZNbYAWCG7K6MHx8xF8sIQ+sRRXXeN50blkOxNdAIabqpYn/1BRVnde3q7JYj3HcE2 MVFezNyaQkCol4Ppof79fDyCj+zu812AtxU/6uAZ4Ftey/RXNkVBQyr5b817+mJ9ciu7 A0Q/ggW8R1MyPDs7qb6fYvruelOE2iw1Sh24fV38nEi/0dFPk8KH4dl10ewXg9Hax+bs W9Tp1n5iHCSPFygeSgOGYhTL2zv+KSp31Hf822I0vTuVkt38oCytEzSMhTj0zocPNvbj NHug== X-Gm-Message-State: AN3rC/6tNM2FaYhpQyBz3MZ/+SlqfL1QlHyKLZIFFEt+wcKK/Kl+tRWM b3tueYoPh5mhjvbXWh3ljbQw/xPtkw== X-Received: by 10.37.217.10 with SMTP id q10mr1752720ybg.80.1492883167210; Sat, 22 Apr 2017 10:46:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Sat, 22 Apr 2017 10:45:26 -0700 (PDT) In-Reply-To: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> From: Eric Rescorla Date: Sat, 22 Apr 2017 13:45:26 -0400 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Christian Huitema Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary=94eb2c06c93adf88b6054dc4f24e Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 22 Apr 2017 17:46:10 -0000 --94eb2c06c93adf88b6054dc4f24e Content-Type: text/plain; charset=UTF-8 On Sat, Apr 22, 2017 at 1:29 PM, Christian Huitema wrote: > > > On 4/21/2017 3:08 AM, Eric Rescorla wrote: > > > I don't think it's an unreasonable design, but I'm not sure it's the right > one > either. The situation I am concerned with is one in which the middlebox > uses the public reset to garbage collect some hard state. In that case, a > man-on-the-side attacker can inject a public reset and block the > connection. > We do know that this form of attack on endpoints happens (TCP RST > injection), so it seems like we might want to defend against it here. > > > Yes, "Public Reset Injection" is a problem. It is inherent to the Public > Reset functionality. And it has to be mitigated. > Well, the design in my original PR has much less exposure to this for any middlebox which observes the handshake, because such middleboxes can validate the PR. -Ekr If I remember correctly the previous debates, the simplest mitigation for > middleboxes is to handle the Public Reset as a soft signal. Do not destroy > the state immediately, only do that after a timer. Cancel the Public Reset > if a "regular" QUIC packet comes from the server before the timer. Or, to > not be server specific, "comes from the end point that sent the Public > Reset". > > Probably worth documenting in the Security Considerations. > > -- Christian Huitema > --94eb2c06c93adf88b6054dc4f24e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Apr 22, 2017 at 1:29 PM, Christian Huitema &l= t;huitema@huitema.= net> wrote:
=20 =20 =20



On 4/21/2017 3:08 A= M, Eric Rescorla wrote:

I don't think it's an unreasonable design, but I&#= 39;m not sure it's the right one
either. The situation I am concerned with is one in which the middlebox
uses the public reset to garbage collect some hard state. In that case, a
man-on-the-side attacker can inject a public reset and block the connection.
We do know that this form of attack on endpoints happens (TCP RST
injection), so it seems like we might want to defend against it here.


 Yes, "Public Reset Injection" is a problem. It is inherent to= the Public Reset functionality. And it has to be mitigated.

Well, the design in my original PR has much less= exposure to this for any middlebox which observes the handshake, because s= uch middleboxes can validate the PR.

-Ekr


If I remember correctly the previous debates, the simplest mitigation for middleboxes is to handle the Public Reset as a soft signal. Do not destroy the state immediately, only do that after a timer. Cancel the Public Reset if a "regular" QUIC packet com= es from the server before the timer. Or, to not be server specific, "comes from the end point that sent the Public Reset".

Probably worth documenting in the Security Considerations.

-- Christian Huitema

--94eb2c06c93adf88b6054dc4f24e-- From nobody Sat Apr 22 18:38:46 2017 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 0EF67126DFB for ; Sat, 22 Apr 2017 18:38:44 -0700 (PDT) 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, 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 nu_O8GCwq-iM for ; Sat, 22 Apr 2017 18:38:42 -0700 (PDT) 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 409A1120326 for ; Sat, 22 Apr 2017 18:38:42 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d26U4-0001Ne-47 for quic@ietf.org; Sun, 23 Apr 2017 03:38:40 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d26TS-0001Rn-8c for quic@ietf.org; Sat, 22 Apr 2017 21:38:38 -0400 Received: (qmail 3196 invoked from network); 23 Apr 2017 01:38:00 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.199]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Apr 2017 01:38:00 -0000 To: Eric Rescorla References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> Cc: Martin Thomson , QUIC WG From: Christian Huitema Message-ID: <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> Date: Sat, 22 Apr 2017 18:37:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4D858B883D0B3279598F0A34" Subject: Re: Updated Public Reset authentication patch X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.03) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49LCP7NcwZmTrFhTWonoFoqtTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXq6YrSJOFS4fPk2wQREtK9YRcOb18WfxGyg6Om6u4YYmwdNTKnuSSU9dfKy F7MxrWA5hjoyEb9Oq0NWpyO3vrfYoocEfHwV+0ePfQGXOSgIJz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB9a2LHJVD1n7GG0fP4s+aInTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0pMVbaYfW V1NrYw1xjApnq7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWJKyg1OJH8aak+/hDMnS4uzLQQGIH13szEQZ25LjADnMNE1mpbdpLS3b/ Ec1vFDFYcqiSoo7BxyxRryqmiHuCdUetTZ/25DKDZC7RirBgbePcy8BFh+JufJrwsKmKW6bHd9QD sMspn/O/edVkHySM+CDVwFjZwEavmmk7Tr9uJ5mso9iv7kZ9azJt3DY/E7nm X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 23 Apr 2017 01:38:44 -0000 This is a multi-part message in MIME format. --------------4D858B883D0B3279598F0A34 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/22/2017 10:45 AM, Eric Rescorla wrote: > > > On Sat, Apr 22, 2017 at 1:29 PM, Christian Huitema > > wrote: > > > > On 4/21/2017 3:08 AM, Eric Rescorla wrote: >> >> I don't think it's an unreasonable design, but I'm not sure it's >> the right one >> either. The situation I am concerned with is one in which the >> middlebox >> uses the public reset to garbage collect some hard state. In that >> case, a >> man-on-the-side attacker can inject a public reset and block the >> connection. >> We do know that this form of attack on endpoints happens (TCP RST >> injection), so it seems like we might want to defend against it he= re. >> > > Yes, "Public Reset Injection" is a problem. It is inherent to the > Public Reset functionality. And it has to be mitigated. > > > Well, the design in my original PR has much less exposure to this for > any middlebox which observes the handshake, because such middleboxes > can validate the PR. Yes, that does work if the middlebox observes and parse the handshake, and then remembers the proof. But can we really believe that all middleboxes will do that? What if they don't bother, because they know they can just observe the Public Reset anyhow? What if they do bother, but fail to see the PR for whatever reason. Do they hold the memory forever? -- Christian Huitema --------------4D858B883D0B3279598F0A34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/22/2017 10:45 AM, Eric Rescorla wrote:


On Sat, Apr 22, 2017 at 1:29 PM, Christian Huitema <huitema@huitema.net> wrote:



On 4/21/2017 3:08 AM, Eric Rescorla wrote:

I don't think it's an unreasonable design, but I'm not sure it's the right one
either. The situation I am concerned with is one in which the middlebox
uses the public reset to garbage collect some hard state. In that case, a
man-on-the-side attacker can inject a public reset and block the connection.
We do know that this form of attack on endpoints happens (TCP RST
injection), so it seems like we might want to defend against it here.


 Yes, "Public Reset Injection" is a problem. It is inherent to the Public Reset functionality. And it has to be mitigated.

Well, the design in my original PR has much less exposure to this for any middlebox which observes the handshake, because such middleboxes can validate the PR.

Yes, that does work if the middlebox observes and parse the handshake, and then remembers the proof. But can we really believe that all middleboxes will do that? What if they don't bother, because they know they can just observe the Public Reset anyhow?

What if they do bother, but fail to see the PR for whatever reason. Do they hold the memory forever?

-- Christian Huitema


--------------4D858B883D0B3279598F0A34-- From nobody Sat Apr 22 19:02:08 2017 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 B8BCC126C89 for ; Sat, 22 Apr 2017 19:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 QhWosela5sqN for ; Sat, 22 Apr 2017 19:02:05 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 266A3129AB5 for ; Sat, 22 Apr 2017 19:02:05 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l18so6464030ywh.3 for ; Sat, 22 Apr 2017 19:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D+I6VTfsXw1nYeBXsnc54Y8A1JrLzu615vN2fEyomwk=; b=KPv2oXoJ/VLuy8jX6r6YiJ3huGfsS5sXbB9bZgAjO3jlH6yrzb9ubp5CyFo9l1wOZt jtvA9ZKrwVpNNn/82fAdSTtcS7Qnmbc8kgd3b40LLV1HK9mcvZ6qiSbi75aTk3FmY4A7 b0vqgqOLYdWCZHAR+ob3q2NE98CKAbyiXDtm7VDPUP/pyhy1LhVRSioo70eDShY1HjT5 Qsnhq4v55/BNFZ98lvo+Q+TSsBlCXxqj/O2QiuQ8fv80P5bkV0iIE5upIVYDfaun41cB 8rQTE3fWgMaW+W57Y4Wtn9y+90VyWp2FVKW+xlQqQVMJoYHIBITOuXzGAGy05yi6YyVq Jn5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D+I6VTfsXw1nYeBXsnc54Y8A1JrLzu615vN2fEyomwk=; b=fUQP1odFrZWYcZjqi8Udoh6LIN6wEPqJuDJ1SPMirrKRAKIq24xP+RiU3v9+DLLKGX ldmc7PbYAWglFNJQ0PlXoBBJnOpcxMnSPVOr7/0/5olpvzARxo10auLiN708eR2A8M8D /lMa2lVSvxqLl5v7QM2iO7M9AlwwkJKx/cxVupqNw9qaSdCI5wSX8IaQKYRbQvjgCTJB kaFmYVQC/3A5r3P+85EmmR88MJlaOlt5qBXXWg6/o0kjpjfilmtlcbLQIAXKDVxXTrJp 4b84/gwiOLC801/Rf+86/KiGHKetAOksDOiQxqcdBSC754bH5mFZAxBeYJPkuUAgACB3 Jzbw== X-Gm-Message-State: AN3rC/6DALPvpnC5IVuzsZSAG5/5SFvW7Hh9i5XesL0HEViPriKVLxvV i0zw8GEhupIjus37Z+0aFl6R8t2EsQ== X-Received: by 10.129.51.131 with SMTP id z125mr15853ywz.87.1492912924390; Sat, 22 Apr 2017 19:02:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Sat, 22 Apr 2017 19:01:23 -0700 (PDT) In-Reply-To: <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Eric Rescorla Date: Sat, 22 Apr 2017 22:01:23 -0400 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Christian Huitema Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary=001a1142165c8a5c33054dcbe0c8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 23 Apr 2017 02:02:07 -0000 --001a1142165c8a5c33054dcbe0c8 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 22, 2017 at 9:37 PM, Christian Huitema wrote: > > > On 4/22/2017 10:45 AM, Eric Rescorla wrote: > > > > On Sat, Apr 22, 2017 at 1:29 PM, Christian Huitema > wrote: > >> >> >> On 4/21/2017 3:08 AM, Eric Rescorla wrote: >> >> >> I don't think it's an unreasonable design, but I'm not sure it's the >> right one >> either. The situation I am concerned with is one in which the middlebox >> uses the public reset to garbage collect some hard state. In that case, a >> man-on-the-side attacker can inject a public reset and block the >> connection. >> We do know that this form of attack on endpoints happens (TCP RST >> injection), so it seems like we might want to defend against it here. >> >> >> Yes, "Public Reset Injection" is a problem. It is inherent to the Public >> Reset functionality. And it has to be mitigated. >> > > Well, the design in my original PR has much less exposure to this for any > middlebox which observes the handshake, because such middleboxes can > validate the PR. > > > Yes, that does work if the middlebox observes and parse the handshake, and > then remembers the proof. But can we really believe that all middleboxes > will do that? What if they don't bother, because they know they can just > observe the Public Reset anyhow? > Well, if we take that reasoning to its logical conclusion, we need to worry about them taking anything marked as a public reset and terminating the connection without bothering to validate the packet fragment that's supposed to indicate on-pathness. This seems like an argument for having a *private* reset (e.g., an apparently encrypted packet with a specific pattern in the first N bits of the payloard). You can still make this stateless using the same techniques as we are using here. What if they do bother, but fail to see the PR for whatever reason. Do they > hold the memory forever? > I assume they will do timeouts. -Ekr > -- Christian Huitema > > > --001a1142165c8a5c33054dcbe0c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Apr 22, 2017 at 9:37 PM, Christian Huitema &l= t;huitema@huitema.= net> wrote:
=20 =20 =20



On 4/22/2017 10:45 = AM, Eric Rescorla wrote:


On Sat, Apr 22, 2017 at 1:29 PM, Christian Huitema <huitema@huitema.net> wrote:



On 4/21/2017 3:08 AM, Eric Rescorla wrote:

I don't think it's an unreasonable design, but I'm not sure it's the right= one
either. The situation I am concerned with is one in which the middlebox
uses the public reset to garbage collect some hard state. In that case, a
man-on-the-side attacker can inject a public reset and block the connection.
We do know that this form of attack on endpoints happens (TCP RST
injection), so it seems like we might want to defend against it here.


 Yes, "Public Reset Injection" is a proble= m. It is inherent to the Public Reset functionality. And it has to be mitigated.

Well, the design in my original PR has much less exposure to this for any middlebox which observes the handshake, because such middleboxes can validate the PR.

Yes, that does work if the middlebox observes and parse the handshake, and then remembers the proof. But can we really believe that all middleboxes will do that? What if they don't bother, because they know they can just observe the Public Reset anyhow?

Well, if we take that reasoning to its= logical conclusion, we need to worry about them taking anything marked as = a public reset and terminating the connection without bothering to validate= the packet fragment that's supposed to indicate on-pathness. This seem= s like an argument for having a *private* reset (e.g., an apparently encryp= ted packet with a specific pattern in the first N bits of the payloard). Yo= u can still make this stateless using the same techniques as we are using h= ere.

What if they do bother, but fail to see the PR for whatever reason. Do they hold the memory forever?

= I assume they will do timeouts.

-Ekr
=C2= =A0

=C2=A0
-- Christian Huitema



--001a1142165c8a5c33054dcbe0c8-- From nobody Sun Apr 23 16:12:42 2017 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 CF7F112441E for ; Sun, 23 Apr 2017 16:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 xxMxqGoBYYcG for ; Sun, 23 Apr 2017 16:12:37 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 645A91201F2 for ; Sun, 23 Apr 2017 16:12:37 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id a103so168336990ioj.1 for ; Sun, 23 Apr 2017 16:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mmmgp9RE4R7KHPGB6sALYTIASYgZv4/NIQ+wTg2WDtM=; b=VIj9QHwmWEFwb5U+m8gm8a7Nqb4PGclTs9eOGhWGSCXZVd6GSgETy14tz/P3pV3OMk 9pDppkAOKJ9Xh8mj2m0Z6KqTElmeQGiY8zAjch1rwUQqjSO4hvW5quUmW4Nmyvt0NkOO q2zggyKKJNcOdpABtsY6nONFaAUWFvmoEhQTICSi5zJBsmv8Ck++wmhuocLITIyeWpRE q+ah+ny9WlJJu2FooaEEDEsXXo4Vz0ZhTOROt+e8TX6ibwqGwbasHRBTTSOrHm7jPf0d 83Gpe7EfSnHR4MieoPfFinYD1je2+SAIX288Qd7ZM04fr8q/EIfvif+8rHu03vIe+Oue TIWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mmmgp9RE4R7KHPGB6sALYTIASYgZv4/NIQ+wTg2WDtM=; b=ao40naa5FJuOg+1ksWSJeb5vQjOw+XWGhudNcElUok6ocLfCi9oR+Exh+dI5tU8FKV iaOHM0N7SYvRGBBn2cKNT683u+zfXEhTjjtCMg1lgUyPPJXju6EQgAc1T/UVjqovdN7m 0AH4hTDnGdEYEF2AQA5Fk+6DpX+tXvhZOT83RcdHN10Ww1Nmu2APWHySLvsAtpwp4uqc 7M1pKzR7rfHee4m45Sh0z9gOMGyC0YA93tY4fySNldxAQ6rp8CixbBcpDzfQEul8JjE5 GQtAUNBnEiCFf7GB9Dh9zkTSI84X/xvxzojBuq7XKbR+SmQ+I6m7fQMPBgXVsh6Ayp4j rkpA== X-Gm-Message-State: AN3rC/7UxFkP0Y5H1bhvLGfgRKtjKTfG1qoymFzXGJ823sBZ9EVxUbnS Q3RB1JfP/tRJrWbh43+mFT+sBvzxnQ== X-Received: by 10.202.52.214 with SMTP id b205mr3214028oia.208.1492989156668; Sun, 23 Apr 2017 16:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.35.196 with HTTP; Sun, 23 Apr 2017 16:12:36 -0700 (PDT) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD7AFCD9@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD7AFD22@DGGEMM506-MBX.china.huawei.com> <58F722A2.8030600@erg.abdn.ac.uk> <2D0676E1-23C6-455D-8A3F-71736AA58D4B@mnot.net> <88B1FBEF-DD50-4024-A727-30BE4C82DA17@netapp.com> From: Martin Duke Date: Sun, 23 Apr 2017 16:12:36 -0700 Message-ID: Subject: Re: Experimental Room Setup (U-Shape and classroom, subject to availability) To: Spencer Dawkins at IETF Cc: Lars Eggert , "gorry@erg.abdn.ac.uk" , Roni Even , IETF QUIC WG , Mark Nottingham Content-Type: multipart/alternative; boundary=001a113cbd3a563f0c054ddda00b Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 23 Apr 2017 23:12:41 -0000 --001a113cbd3a563f0c054ddda00b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was remote, and it worked pretty well, probably for the same reason it wasn't great for attendees: the key people were front and center, facing the cameras, and you could keep up with what was going on quite easily. On Wed, Apr 19, 2017 at 8:56 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > If I might inject here ... > > On Apr 19, 2017 05:33, "Eggert, Lars" wrote: > > And everyone should feel free to send their feedback to the IESG directly= , > as they to a large degree are in control of how this experiment goes > forward. > > > I'm absolutely watching the discussion on this subject, here and elsewher= e. > > Lars is correct to encourage people to send feedback to the IESG. > > One thing I haven't seen much feedback about, was the experience for > remote participants with this room layout, compared to other meeting > sessions. > > If you participated remotely and can provide feedback, I'd find that > especially useful. > > Thanks, > > Spencer, as responsible AD > > > Lars > > -- > Sent from a mobile device; please excuse typos. > +49 151 120 55791 > > > On Apr 19, 2017, at 10:52, Mark Nottingham wrote: > > > > Gorry, > > > > For what it's worth, your comments mirror much of what we heard, and > what we observed ourselves. We've given feedback along these lines to the > Secretariat, and will be working with them in Prague to make sure the roo= m > is more suited to the work. > > > > For those who attended the Interim in Tokyo, that's the sort of layout > we're shooting for. > > > > Regards, > > > > > >> On 19 Apr 2017, at 6:41 pm, Gorry Fairhurst > wrote: > >> > >> I'm glad this was raised. I found this meeting a really unhelpful one = - > and the following meeting I attended for HTTPbis was only slightly better= . > >> > >> I discovered I had written notes, and they largely echo what Roni said= , > and since it seems theer was not much critical feedback, I include them > below: > >> > >> The whole way a =E2=80=9CU=E2=80=9D meeting played out had the feelin= g of remote > observation of a panel discussion - an exeperience like watching remotely > on meetecho - which is quite good, but I'd hope we could do much better. > Many of us follow work across a number of working groups, tracking specif= ic > aspects of protocols or interested in how specific IDs relate to the wide= r > working group. I came to the QUIC meeting to find out who the document > authors were, and what they and other people thought about the issues tha= t > the WG was addressing. This room format worked against this. > >> > >> I really disliked the ways the Chairs had their backs to the room. To > me, an important role of the Chairs is to include others and judge the > sense of the room. In this setup, the Chairs could not monitor the room. > The rest of the room were clearly observors to the discussion around the > table. In the case of the meetings I attended the rooms were pretty packe= d, > this was bad. > >> > >> I tried several seating positions before selecting the side area - tha= t > presented challenges seeing the screen, but at least you could see some o= f > the people seated at tables and also the presenter. > >> > >> The floor mic was hard to get access to and appeared like you were > standing outside the speaker zone. Even from the "floor Mic", I had to > speak to the back of some people's heads. > >> > >> It was really hard to see the faces of people and to know who is > speaking. Sitting speakers are much more difficult to identify: the plea > from the Chairs to raise hands when talking at the tables did (thanks for > doing this) at least let me see who was asking a question or addressing a > comment, but it was frustrating not to be able to see these people's face= s. > For me, this is a real down-side. > >> > >> I can see the value for smaller working groups where you can get most > people round a table, and the rest of the room really are only observers. > >> > >> If we do repeat this again, can I suggest we completely eliminate the > central part of the "U" and set this up as two rows of desks angled > slightly towards the rest of the room. That way people can see who is > speaking and those speaking can see the rest of the room? Please also pla= ce > the working group chairs where they can see the entire room (at least for > any meeting I will chair). > >> > >> Gorry > >> > >>> On 19/04/2017, 09:06, Roni Even wrote: > >>> Hi, > >>> I only hope that when considering the feedback, you factored whether > the person was sitting at the table or in the room. I can understand > positive feedback from people at the table. > >>> > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: Mark Nottingham [mailto:mnot@mnot.net] > >>>> Sent: =D7=99=D7=95=D7=9D =D7=93 19 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 20= 17 10:34 > >>>> To: Roni Even > >>>> Cc: quic@ietf.org > >>>> Subject: Re: Experimental Room Setup (U-Shape and classroom, subject > to > >>>> availability) > >>>> > >>>> Hi Roni, > >>>> > >>>> Thanks for the feedback. For what it's worth, we got a lot of other > feedback > >>>> privately, mostly positive. However, people did point out issues > similar to > >>>> yours, and we're going to be working with the Secretariat as well as > thinking > >>>> more carefully about how the meeting is run to try to improve things > in the > >>>> future. > >>>> > >>>> Regards, > >>>> > >>>> > >>>>> On 19 Apr 2017, at 5:10 pm, Roni Even wrote: > >>>>> > >>>>> Hi, > >>>>> I noticed that the WG chairs asked for a U-shape room similar to th= e > >>>> experiment in Chicago > >>>>> I am sorry for not providing feedback before but I found that > arrangement > >>>> very difficult from my perspective, I was sitting on the side not > facing the > >>>> screen and the room was very packed. > >>>>> I had the following observations: > >>>>> > >>>>> 1. It was difficult to understand who is speaking. People > sitting at the > >>>> table started speaking without stating their name. It is much simple= r > when > >>>> they have to go to the microphone and stand at least you can see who > is > >>>> speaking. > >>>>> 2. It was inconvenient to look at the presentation screen whe= n > you are > >>>> not facing the screen. Sitting on a chair with a laptop on your > knees and > >>>> looking sideways to the screen was challenging for my neck. It is > simpler if > >>>> you sit by a table. > >>>>> 3. There was no easy path to go to the microphone for people > who were > >>>> not sitting at the table. Again, since the room was very packed > there were > >>>> no path from the side to the middle where the microphone was. > >>>>> 4. When choosing a sit, the screen facing sites where far fro= m > the > >>>> screen. I think that having this long table is part of the problem. > Maybe you > >>>> need a smaller table for less people who really actively participate > in the > >>>> discussion (this was not the case in Chicago). > >>>>> 5. My feeling was that if you are not sitting at the table > then you are just > >>>> an observer and not a participant. What made this feeling stronger > were the > >>>> side conversations taking place at the table. > >>>>> My conclusion was that this arrangement may work for a small WG but > not > >>>> for QUIC > >>>>> Thanks > >>>>> Roni Even > >>>> -- > >>>> Mark Nottingham https://www.mnot.net/ > >>>> > >>>> > >>>> > >> > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > > > > > > > > --001a113cbd3a563f0c054ddda00b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was remote, and it worked pretty well, probably for the = same reason it wasn't great for attendees: the key people were front an= d center, facing the cameras, and you could keep up with what was going on = quite easily.

On Wed, Apr 19, 2017 at 8:56 AM, Spencer Dawkins at IETF <sp= encerdawkins.ietf@gmail.com> wrote:
If I might inject here ...=

On Apr 19, 20= 17 05:33, "Eggert, Lars" <lars@netapp.com> wrote:
And everyone should feel free to = send their feedback to the IESG directly, as they to a large degree are in = control of how this experiment goes forward.

I'm absolutely watching the dis= cussion on this subject, here and elsewhere.

Lars is correct to encourage people to send feedback t= o the IESG.=C2=A0

One th= ing I haven't seen much feedback about, was the experience for remote p= articipants with this room layout, compared to other meeting sessions.

If you participated remotely= and can provide feedback, I'd find that especially useful.

Thanks,

=
Spencer, as responsible AD

<= font color=3D"#888888">
Lars

--
Sent from a mobile device; please excuse typos.
+49 151 120 55791

> On Apr 19, 2017, at 10:52, Mark Nottingham <mnot@mnot.net> wrote:
>
> Gorry,
>
> For what it's worth, your comments mirror much of what we heard, a= nd what we observed ourselves. We've given feedback along these lines t= o the Secretariat, and will be working with them in Prague to make sure the= room is more suited to the work.
>
> For those who attended the Interim in Tokyo, that's the sort of la= yout we're shooting for.
>
> Regards,
>
>
>> On 19 Apr 2017, at 6:41 pm, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:=
>>
>> I'm glad this was raised. I found this meeting a really unhelp= ful one - and the following meeting I attended for HTTPbis was only slightl= y better.
>>
>> I discovered I had written notes, and they largely echo what Roni = said, and since it seems theer was not much critical feedback, I include th= em below:
>>
>> The whole way a=C2=A0 =E2=80=9CU=E2=80=9D meeting played out had t= he feeling of remote observation of a panel discussion - an exeperience lik= e watching remotely on meetecho - which is quite good, but I'd hope we = could do much better. Many of us follow work across a number of working gro= ups, tracking specific aspects of protocols or interested in how specific I= Ds relate to the wider working group. I came to the QUIC meeting to find ou= t who the document authors were, and what they and other people thought abo= ut the issues that the WG was addressing. This room format worked against t= his.
>>
>> I really disliked the ways the Chairs had their backs to the room.= To me, an important role of the Chairs is to include others and judge the = sense of the room. In this setup, the Chairs could not monitor the room. Th= e rest of the room were clearly observors to the discussion around the tabl= e. In the case of the meetings I attended the rooms were pretty packed, thi= s was bad.
>>
>> I tried several seating positions before selecting the side area -= that presented challenges seeing the screen, but at least you could see so= me of the people seated at tables and also the presenter.
>>
>> The floor mic was hard to get access to and appeared like you were= standing outside the speaker zone. Even from the "floor Mic", I = had to speak to the back of some people's heads.
>>
>> It was really hard to see the faces of people and to know who is s= peaking. Sitting speakers are much more difficult to identify: the plea fro= m the Chairs to raise hands when talking at the tables did (thanks for doin= g this) at least let me see who was asking a question or addressing a comme= nt, but it was frustrating not to be able to see these people's faces. = For me, this is a real down-side.
>>
>> I can see the value for smaller working groups where you can get m= ost people round a table, and the rest of the room really are only observer= s.
>>
>> If we do repeat this again, can I suggest we completely eliminate = the central part of the "U" and set this up as two rows of desks = angled slightly towards the rest=C2=A0 of the room. That way people can see= who is speaking and those speaking can see the rest of the room? Please al= so place the working group chairs where they can see the entire room (at le= ast for any meeting I will chair).
>>
>> Gorry
>>
>>> On 19/04/2017, 09:06, Roni Even wrote:
>>> Hi,
>>> I only hope that when considering the feedback, you factored w= hether the person was sitting at the table or in the room. I can understand= positive feedback from people at the table.
>>>
>>> Roni
>>>
>>>> -----Original Message-----
>>>> From: Mark Nottingham [mailto:mnot@mnot.net]
>>>> Sent: =D7=99=D7=95=D7=9D =D7=93 19 =D7=90=D7=A4=D7=A8=D7= =99=D7=9C 2017 10:34
>>>> To: Roni Even
>>>> Cc: qui= c@ietf.org
>>>> Subject: Re: Experimental Room Setup (U-Shape and classroo= m, subject to
>>>> availability)
>>>>
>>>> Hi Roni,
>>>>
>>>> Thanks for the feedback. For what it's worth, we got a= lot of other feedback
>>>> privately, mostly positive. However, people did point out = issues similar to
>>>> yours, and we're going to be working with the Secretar= iat as well as thinking
>>>> more carefully about how the meeting is run to try to impr= ove things in the
>>>> future.
>>>>
>>>> Regards,
>>>>
>>>>
>>>>> On 19 Apr 2017, at 5:10 pm, Roni Even<roni.even@huawei.com>= =C2=A0 wrote:
>>>>>
>>>>> Hi,
>>>>> I noticed that the WG chairs asked for a U-shape room = similar to the
>>>> experiment in Chicago
>>>>> I am sorry for not providing feedback before but I fou= nd that arrangement
>>>> very difficult from my perspective, I was sitting on the s= ide not facing the
>>>> screen and the room was very packed.
>>>>> I had the following observations:
>>>>>
>>>>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0It was difficult to under= stand who is speaking. People sitting at the
>>>> table started speaking without stating their name. It is m= uch simpler when
>>>> they have to go to the microphone and stand at least you c= an see who is
>>>> speaking.
>>>>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0It was inconvenient to lo= ok at the presentation screen when you are
>>>> not facing the screen.=C2=A0 Sitting on a chair with a lap= top on your knees and
>>>> looking sideways to the screen was challenging for=C2=A0 m= y neck. It is simpler if
>>>> you sit by a table.
>>>>> 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0There was no easy path to= go to the microphone for people who were
>>>> not sitting at the table.=C2=A0 Again, since the room was = very packed there were
>>>> no path from the side to the middle where the microphone w= as.
>>>>> 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0When choosing a sit, the = screen facing sites where far from the
>>>> screen. I think that having this long table is part of the= problem. Maybe you
>>>> need a smaller table for less people who really actively p= articipate in the
>>>> discussion (this was not the case in Chicago).
>>>>> 5.=C2=A0 =C2=A0 =C2=A0 =C2=A0My feeling was that if yo= u are not sitting at the table then you are just
>>>> an observer and not a participant.=C2=A0 What made this fe= eling stronger were the
>>>> side conversations taking place at the table.
>>>>> My conclusion was that this arrangement may work for a= small WG but not
>>>> for QUIC
>>>>> Thanks
>>>>> Roni Even
>>>> --
>>>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>>>>
>>>>
>>>>
>>
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>
>
>
>


--001a113cbd3a563f0c054ddda00b-- From nobody Sun Apr 23 17:32:47 2017 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 1FA54120726 for ; Sun, 23 Apr 2017 17:32:45 -0700 (PDT) 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, FREEMAIL_FROM=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=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 ZdZJbqesRiYw for ; Sun, 23 Apr 2017 17:32:43 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 785CF1204DA for ; Sun, 23 Apr 2017 17:32:43 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id t144so65908075lff.1 for ; Sun, 23 Apr 2017 17:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jg3xi8ND1i6vQdqyHgGo2Ej+la49OE7JG7y/XOf9AKQ=; b=i1JO8ITE9qSo4pXc/YwzJX5Zm7TqtjYeOU9hgqrkdPJAnO8O+AgkAgPg4WDh1na0dg AuGAr0ZS1HutnVgaKO87GKGcYpPfeJtnkSw++PmFQzr7JwLzaoFZaSCPdZRK7lXUP3bv 0FdBktjXETbcFUhDv0T4oYZOigaESsxBw0Q9aLiOClcu/xZ7jKnG+Kpv9sNPPVepu0Eo cXfF7KdLLBPXV4xHUWW9YKuxyZPAVGyJ2XQeosDvKtLsuyldXMXEpQcgqDcaONUDpJv2 blS9005WYjbStpcmK8GFMty7+cG1qvnnQ9fj2hj8yayw0om2nATlWv7gY0lXdX9FFYhJ rdRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jg3xi8ND1i6vQdqyHgGo2Ej+la49OE7JG7y/XOf9AKQ=; b=kLwXS4vsSxHTyE887PjyNwB0O1mvcJUdWorj0UOcWVhJctihKsa2ye4cICkhRG98qm Eea2vBWxSlTzpgPWkRC8yQ8xanOfz1/Rqp7Xh9WCEe3vxG1uOPRxYkv7CGRfce8NzDmF dVq/ay4w+johaNblEc/O7wIPzaljGCasF7aZXP848t93keqk3XTz465+vVtkKu8CJVcU ZI9dcSDMZtBfVhMim6NrRX2P0xIx1IghmprGT5J2Qn2AM1At+c1rb+7BPft6A1sST3LV rA5I5GZoutZDNDBLhlj0/ksuEpQsxzXgVQuRiwVMwUUj1qhfnUbssunOnvUppOnVGOXu z92A== X-Gm-Message-State: AN3rC/7iPJhCti/+qUYfrK04RBHaOeEWJgrhDogM1GFdMfA6R4jENxlw sYbbXHLuYr2FChcPlCi7x1uBm6fJCpl2+8Y= X-Received: by 10.46.69.133 with SMTP id s127mr8270453lja.44.1492993961712; Sun, 23 Apr 2017 17:32:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Sun, 23 Apr 2017 17:32:41 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Martin Thomson Date: Mon, 24 Apr 2017 10:32:41 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Eric Rescorla Cc: Christian Huitema , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2017 00:32:45 -0000 On 23 April 2017 at 12:01, Eric Rescorla wrote: > Well, if we take that reasoning to its logical conclusion, we need to worry > about them taking anything marked as a public reset and terminating the > connection without bothering to validate the packet fragment that's supposed > to indicate on-pathness. This seems like an argument for having a *private* > reset (e.g., an apparently encrypted packet with a specific pattern in the > first N bits of the payloard). You can still make this stateless using the > same techniques as we are using here. I don't see that working unless we also encrypt the packet number. A server that just rebooting isn't going to know what packet number is expected to come next. On that basis, a middlebox could look for a discontinuity in packet numbers and treat that as a public reset. Stepping back here, this comes back to how much information we want to give the middlebox. With the added observation that when you give a middlebox information you have to trust them to do the right thing with it. Christian's view might seem pessimistic, but middlebox state is precious. In designing for this new protocol, a middlebox designer has to account for the possibility that this flow was migrated from some other network path. A migrated flow won't include a handshake. That suggests to me that we need to treat end-to-end and path signals differently as much as we can. # End-to-End Signals about the state of the connection need to go end-to-end. Public reset is fundamentally a signal about the entire connection. If we accept that the protocol inherently goes over multiple paths, then we can say that there is no need to privilege just one path with knowledge of a connection termination signal. The challenge - if any - with the design we have is that there is an inadvertent signal to the path when endpoints lose state. We can work around that, but it either requires removing packet numbers completely, or greatly enhancing the information exposed to the path. For instance, if we had a packet number echo the server would be able to pick a plausible packet number for its reset. I'm inclined to say that there is no reason to specially fix the problem Christian raises. If the path can't be trusted not to act on this information, we can grease and send a continuous stream of spurious Public Reset packets. For this discussion, I'd like to keep things concentrated on the end-to-end part as much as possible. Thus the remaining sections are .. --- out of scope stuff # Middle-to-End Signals from path elements about the state of the path require separate design. We currently don't have a principled way of approaching this, but we're not cutting entirely new ground. We already accepted a middle-to-end signal with PMTUD. The approach for that was for endpoints to treat the signal with suspicion. I like that approach. One nice property of these signals is that the sender can't know the session keys, so it's very easy to identify these and throw them out if you don't trust them. # End-to-Middle With Public Reset we're really talking about a signal from endpoints *to* the path. In the case of the silent close discussion we had, we mistakenly conflated that with the end-to-end signal. If we want anything, we should be taking Brian's work on the states and signals more seriously. For me, I'd like to see more thought about on how a path element determines that the signal is truly from the end, and not another middle. From nobody Sun Apr 23 18:48:57 2017 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 753E4127058 for ; Sun, 23 Apr 2017 18:48:55 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 YvCQuryV6fup for ; Sun, 23 Apr 2017 18:48:53 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 8B248120046 for ; Sun, 23 Apr 2017 18:48:53 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id 203so68564520ywe.0 for ; Sun, 23 Apr 2017 18:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9dfMIipvJA3+cgxmGysfBWROwCKMeR/580pklFe/vDw=; b=NVb49LA2d3VGjCtnm2eq4nRZHFoFB4BJnzh9/qxLE6ydkc9XdYlmbIkPyEwMEMqgfK xNCq7XoN1C6OWz1g5LymgrYDfNrpyqjeyuPxqXI+Lr15VwIG2KuKez1vkKOeXs/aI6Fr D/NHh8o5Io8JUycitlTk5u+GqDfiIdCCdDbxxrnjHsipKAlutk9oTyBFfrZJvvTy1c6N YlS0RAYKhdfRIuR8LlKJKhJzULP+uSIPrhrCfXLXL1+UOqA0jlk3vgqWx3tvAmEFZbVC eUcNH3/douIO+WW8VlzKzCgEBI4gAT+UVWITVHmLk+aTn8o9ZALu/A+KDd2sl7Wts/Ee feIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9dfMIipvJA3+cgxmGysfBWROwCKMeR/580pklFe/vDw=; b=MxC9dsRp9o4P811Dr48hVu6kx5ikUl47ZvUrvg7XskvuyKkAVHAvySeaJmJ3jA0vda uJlz72tiMLJy/D9xpgYrPIrifqImFjxlPw/mA9p1FjeZu8t/pqaekxmS/pIijtU1oB/q 2gUrnQHTki7Jb8CRoP8DqrfG4Xs8wIUd0JZ6fbUTAYGS+Ub5dy/Cpbx8FtOzrV6KgfLx Zf1eGEo3VoZy3YeAQk9m5ZsrMHnSfZnY6UOpkv7pS0pDIvVEJg4Lxz0Urd+dmMb+jNa3 YUflJ84KhJRY1twjD7u2svmvRStT8UTrE5lWwNUzlz6+ZTbg31JbePVm3g9DHQnzSV36 Fyew== X-Gm-Message-State: AN3rC/6apb0sK1LpDfrWXbMnyrduEgZo7bQ5GZ3k+GbOpd/EJPxbo6RS 72HNShP+SSx5tTCKyl5jWOFkoLyqcQ== X-Received: by 10.129.51.131 with SMTP id z125mr3196681ywz.87.1492998532814; Sun, 23 Apr 2017 18:48:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Sun, 23 Apr 2017 18:48:11 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Eric Rescorla Date: Sun, 23 Apr 2017 21:48:11 -0400 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Martin Thomson Cc: Christian Huitema , QUIC WG Content-Type: multipart/alternative; boundary=001a1142165c32f913054ddfcf4e Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2017 01:48:55 -0000 --001a1142165c32f913054ddfcf4e Content-Type: text/plain; charset=UTF-8 On Sun, Apr 23, 2017 at 8:32 PM, Martin Thomson wrote: > On 23 April 2017 at 12:01, Eric Rescorla wrote: > > Well, if we take that reasoning to its logical conclusion, we need to > worry > > about them taking anything marked as a public reset and terminating the > > connection without bothering to validate the packet fragment that's > supposed > > to indicate on-pathness. This seems like an argument for having a > *private* > > reset (e.g., an apparently encrypted packet with a specific pattern in > the > > first N bits of the payloard). You can still make this stateless using > the > > same techniques as we are using here. > > I don't see that working unless we also encrypt the packet number. A server that just rebooting isn't going to know what packet number is > expected to come next. On that basis, a middlebox could look for a > discontinuity in packet numbers and treat that as a public reset. Well, as you know, I want to encrypt the packet number, but I think you could make it more trouble than it was worth for the middlebox. Stepping back here, this comes back to how much information we want to > give the middlebox. With the added observation that when you give a > middlebox information you have to trust them to do the right thing > with it. > Christian's view might seem pessimistic, but middlebox state is > precious. In designing for this new protocol, a middlebox designer > has to account for the possibility that this flow was migrated from > some other network path. A migrated flow won't include a handshake. > Well, those middleboxes can use timeouts. Remember that ordinary resets aren't public, so unless we make them so middleboxes will have that problem in any case. -Ekr That suggests to me that we need to treat end-to-end and path signals > differently as much as we can. > > # End-to-End > > Signals about the state of the connection need to go end-to-end. > Public reset is fundamentally a signal about the entire connection. > If we accept that the protocol inherently goes over multiple paths, > then we can say that there is no need to privilege just one path with > knowledge of a connection termination signal. The challenge - if any > - with the design we have is that there is an inadvertent signal to > the path when endpoints lose state. > > We can work around that, but it either requires removing packet > numbers completely, or greatly enhancing the information exposed to > the path. For instance, if we had a packet number echo the server > would be able to pick a plausible packet number for its reset. > > I'm inclined to say that there is no reason to specially fix the > problem Christian raises. If the path can't be trusted not to act on > this information, we can grease and send a continuous stream of > spurious Public Reset packets. > > For this discussion, I'd like to keep things concentrated on the > end-to-end part as much as possible. Thus the remaining sections are > .. > > --- out of scope stuff > > # Middle-to-End > > Signals from path elements about the state of the path require > separate design. We currently don't have a principled way of > approaching this, but we're not cutting entirely new ground. We > already accepted a middle-to-end signal with PMTUD. > > The approach for that was for endpoints to treat the signal with > suspicion. I like that approach. One nice property of these signals > is that the sender can't know the session keys, so it's very easy to > identify these and throw them out if you don't trust them. > > # End-to-Middle > > With Public Reset we're really talking about a signal from endpoints > *to* the path. In the case of the silent close discussion we had, we > mistakenly conflated that with the end-to-end signal. > > If we want anything, we should be taking Brian's work on the states > and signals more seriously. For me, I'd like to see more thought > about on how a path element determines that the signal is truly from > the end, and not another middle. > --001a1142165c32f913054ddfcf4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 23, 2017 at 8:32 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On= 23 April 2017 at 12:01, Eric Rescorla <ekr@rtfm.com> wrote:
> Well, if we take that reasoning to its logical conclusion, we need to = worry
> about them taking anything marked as a public reset and terminating th= e
> connection without bothering to validate the packet fragment that'= s supposed
> to indicate on-pathness. This seems like an argument for having a *pri= vate*
> reset (e.g., an apparently encrypted packet with a specific pattern in= the
> first N bits of the payloard). You can still make this stateless using= the
> same techniques as we are using here.

I don't see that working unless we also encrypt the packet numbe= r. A
server that just rebooting isn't going to know what packet number is expected to come next.=C2=A0 On that basis, a middlebox could look for a discontinuity in packet numbers and treat that as a public reset.

Well, as you know, I want to encrypt the packet numb= er, but I think you
could make it more trouble than it was worth = for the middlebox.


Stepping back here, this comes back to how much information we want to
give the middlebox.=C2=A0 With the added observation that when you give a middlebox information you have to trust them to do the right thing
with it.

Christian's view might seem pessimistic, but middlebox state is
precious.=C2=A0 In designing for this new protocol, a middlebox designer has to account for the possibility that this flow was migrated from
some other network path.=C2=A0 A migrated flow won't include a handshak= e.

Well, those middleboxes can use time= outs. Remember that ordinary resets
aren't public, so unless = we make them so middleboxes will have that problem
in any case.

-Ekr



That suggests to me that we need to treat end-to-end and path signals
differently as much as we can.

# End-to-End

Signals about the state of the connection need to go end-to-end.
Public reset is fundamentally a signal about the entire connection.
If we accept that the protocol inherently goes over multiple paths,
then we can say that there is no need to privilege just one path with
knowledge of a connection termination signal.=C2=A0 The challenge - if any<= br> - with the design we have is that there is an inadvertent signal to
the path when endpoints lose state.

We can work around that, but it either requires removing packet
numbers completely, or greatly enhancing the information exposed to
the path.=C2=A0 For instance, if we had a packet number echo the server
would be able to pick a plausible packet number for its reset.

I'm inclined to say that there is no reason to specially fix the
problem Christian raises.=C2=A0 If the path can't be trusted not to act= on
this information, we can grease and send a continuous stream of
spurious Public Reset packets.

For this discussion, I'd like to keep things concentrated on the
end-to-end part as much as possible.=C2=A0 Thus the remaining sections are<= br> ..

--- out of scope stuff

# Middle-to-End

Signals from path elements about the state of the path require
separate design.=C2=A0 We currently don't have a principled way of
approaching this, but we're not cutting entirely new ground.=C2=A0 We already accepted a middle-to-end signal with PMTUD.

The approach for that was for endpoints to treat the signal with
suspicion.=C2=A0 I like that approach.=C2=A0 One nice property of these sig= nals
is that the sender can't know the session keys, so it's very easy t= o
identify these and throw them out if you don't trust them.

# End-to-Middle

With Public Reset we're really talking about a signal from endpoints *to* the path.=C2=A0 In the case of the silent close discussion we had, we<= br> mistakenly conflated that with the end-to-end signal.

If we want anything, we should be taking Brian's work on the states
and signals more seriously.=C2=A0 For me, I'd like to see more thought<= br> about on how a path element determines that the signal is truly from
the end, and not another middle.

--001a1142165c32f913054ddfcf4e-- From nobody Sun Apr 23 19:02:11 2017 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 94FAF126C2F for ; Sun, 23 Apr 2017 19:02:09 -0700 (PDT) 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 WyT3XUcs9fYn for ; Sun, 23 Apr 2017 19:02:08 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 020CE120046 for ; Sun, 23 Apr 2017 19:02:08 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d2TKI-0007dv-BN for quic@ietf.org; Mon, 24 Apr 2017 04:02:07 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d2TKD-0003mP-D7 for quic@ietf.org; Sun, 23 Apr 2017 22:02:05 -0400 Received: (qmail 28934 invoked from network); 24 Apr 2017 02:01:59 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.199]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Apr 2017 02:01:58 -0000 To: Eric Rescorla , Martin Thomson References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> Cc: QUIC WG From: Christian Huitema Message-ID: Date: Sun, 23 Apr 2017 19:01:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------10D2E7A5F682E5A26B952DDC" Subject: Re: Updated Public Reset authentication patch X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqb9+S63jJSX31jdMi0wcLiRcOb18WfxGyg6Om6u4YYm51Y+bwTiob6s+Jr lCByRFw5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+g3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0LL0ExebT XcB9wwI6iVhydLbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWHxcEeYXaEh7Ip8nBmIzXZwpqT8auRNlXQctohljUCg8b9VxCV5S50P9H WChtigBtKhBaevb8pkwVq3+XN9bPyjRMyLUEno1frs9vZR0iI5iTGneI1cCMIcE6R6jtJ8btb7sy ltanepIHrA9+HqSAze9Tb/EzRc4KszwGAkbj6j0QxK4Q6pnz1PG2i0Jcu7De X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2017 02:02:09 -0000 This is a multi-part message in MIME format. --------------10D2E7A5F682E5A26B952DDC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/23/2017 6:48 PM, Eric Rescorla wrote: > > > On Sun, Apr 23, 2017 at 8:32 PM, Martin Thomson > > wrote: > ... > > Christian's view might seem pessimistic, but middlebox state is > precious. In designing for this new protocol, a middlebox designer > has to account for the possibility that this flow was migrated from > some other network path. A migrated flow won't include a handshake. > > > Well, those middleboxes can use timeouts. Remember that ordinary resets > aren't public, so unless we make them so middleboxes will have that > problem > in any case. So, specifically, middle boxes should either fully implement the proof/hash test of the public reset, or ignore the public reset and rely on presence/absence of UDP traffic to determine whether a connection is still ongoing. That sounds good, but it relies on middleboxes not implementing just one half of the spec, which is where I am pessimistic. I like Martin's idea of greasing that, but I observe that grease for now is mostly end-to-end. Greasing the middle opens interesting problems. -- Christian Huitema --------------10D2E7A5F682E5A26B952DDC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/23/2017 6:48 PM, Eric Rescorla wrote:


On Sun, Apr 23, 2017 at 8:32 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
...

Christian's view might seem pessimistic, but middlebox state is
precious.  In designing for this new protocol, a middlebox designer
has to account for the possibility that this flow was migrated from
some other network path.  A migrated flow won't include a handshake.

Well, those middleboxes can use timeouts. Remember that ordinary resets
aren't public, so unless we make them so middleboxes will have that problem
in any case.

So, specifically, middle boxes should either fully implement the proof/hash test of the public reset, or ignore the public reset and rely on presence/absence of UDP traffic to determine whether a connection is still ongoing.

That sounds good, but it relies on middleboxes not implementing just one half of the spec, which is where I am pessimistic. I like Martin's idea of greasing that, but I observe that grease for now is mostly end-to-end. Greasing the middle opens interesting problems.

-- Christian Huitema
--------------10D2E7A5F682E5A26B952DDC-- From nobody Sun Apr 23 21:41:36 2017 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 2B13E126CF6 for ; Sun, 23 Apr 2017 21:41:35 -0700 (PDT) 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, FREEMAIL_FROM=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=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 33yHGa7rXowg for ; Sun, 23 Apr 2017 21:41:33 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 509EA126BF0 for ; Sun, 23 Apr 2017 21:41:33 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id c80so67287209lfh.3 for ; Sun, 23 Apr 2017 21:41:33 -0700 (PDT) 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=rrCRAtC/+6bi3BpxaZ6x9f+swNq5wQuTFU2SYBeFU3s=; b=lpiLVSk9LbYUMAgTNApJjRlDD2hbcrQP3HkVc4ohBTz45G/pXV4SdCg/pZqUqTJq/N 2iRlbe78oQsSqjDtKcVqeN4+uu77QBZ5CifmSIXfwN0qgSWPsZGSCa8EtKyMwPB05FbC K7OECM7SWujDllrKyfu9FFFbzqXlqtH0lJodZP2BnCiQI+2HgpDyEb8IVn9+6KiVWJcb 5a8anP4rY9y1bVk/pQeos54MfAh7cr59eUNY8wPDrHop3/KyjWHmnfNfh40DfyEXDGpD 7D2Fvyb/bmXqiwO/EsZ/ME+fG+U7qnlCdLYGUja8rXf5YB1CVthmUsNRVIss6dzsrkeE iHYQ== 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=rrCRAtC/+6bi3BpxaZ6x9f+swNq5wQuTFU2SYBeFU3s=; b=anrr6E9TRg35OyvVrIhHDYYLT3w32sL3nq95pZdnSeSdfrv+oUQJjOtBooSwuwGRP2 bWXDxtan6O9JWTFbcQ0kErZ57Oh3VjHu4tfHtls/Uhmt+hNOi2qQmjTIiDkIuQuVJqHr 9URkBwiYxfY6oiaAbl3zmLRX+JEJakUaETZmJH+2GZ0WXZOF/wwXn1xvhzPkLNX3EAmp o0dCfkqses2nHFFr9MyXT0k4x6MAbsufJ4JkoruLE6SW21ubtsbbapcpp/EaEGjQZ7Cy VFcojKoHU0S47OOHt2JZRpgBVKxd1bBELooYEoZKhoXioLT22Rn6K3Jb03Zdz6yywWEd C/iQ== X-Gm-Message-State: AN3rC/7S8Y8nXlpdX2MkPbuFm36iYOjJRzRJZSM2ZWlFNQfCbtOckI8u oDg3PlJRso0iLerIa64gZqduC7/JMBHq+Yk= X-Received: by 10.46.75.2 with SMTP id y2mr8736740lja.103.1493008891252; Sun, 23 Apr 2017 21:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Sun, 23 Apr 2017 21:41:30 -0700 (PDT) From: Martin Thomson Date: Mon, 24 Apr 2017 14:41:30 +1000 Message-ID: Subject: Error code cleanup To: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2017 04:41:35 -0000 The TLS and HTTP drafts now have some nice error code lists. And by nice I mean short and precise. Each error code is justified and most either point to a distinct reaction or a distinct cause (the latter I'm less enthusiastic about with HTTP, but that is just a quibble). I've been working on fixing error codes for the transport. Here's what I'm going to propose for the breakdown of error codes in the transport piece. I won't name these yet, there are reasons to parallel codes in the HTTP spec. Some of these might be broken down finer into codes that identify specific causes, but I might push back on doing that too aggressively. I have 13 codes here. TLS has 3, HTTP has 17 (which I think is too high, but what do I know). We might want to discuss reducing the size of the error code space a little at some point. I went through the existing codes and all are either invalid or covered here - as far as I can see. Clearly, this is still early enough that there might be new codes added, but I think that the above list is close enough. I plan to write this up during this week. I'm sharing this in the hopes that someone might help by correcting any mistakes that I've made. # internal errors * this error was my fault, probably a bug or resource issue on my end that means I can't continue I don't think that we want to highlight the difference between different internal errors here lest we provide instructions on how to trigger DoS or bugs. Having just one code in this category seems right. # errors that aren't errors * this isn't an error (in case we use one of the error messages to signal close) * this isn't an error, you asked me to generate this error (for the case where RST_STREAM causes RST_STREAM to be sent, or for the proposed DISINTEREST frame) * this isn't an error, I just don't want this stream any more (the general form of the cancellation request) # errors that are protocol violations * you did something wrong, but nothing specific was appropriate (this is a general catch-all error code for use when other protocol violations aren't appropriate) * you send me more data than I allowed (flow control) * you opened a stream before I said you could use it (streams) * you sent a frame on a stream that was in a state that doesn't allow that * you sent data on a stream past the final data offset, or you seem to have moved the final offset * you sent a badly-formatted frame (this includes things that have bad lengths primarily; I think that includes an empty STREAM with no FIN flag; the range of errors here doesn't really seem to justify an error code per frame type) * your transport parameters were invalid * the version negotiation fields in your transport parameters don't match with my understanding of what we did during version negotiation, IT'S AN ATTACK! (this could have been part of transport parameter validation, but the fact that this is an attack rather than just a screwup is a good reason to use a different code) # errors that aren't protocol issues violations, but they need a signal anyway * enhance your calm (this is the name we used in h2 to signal all sorts of cases where an endpoint could tell the other side to cool off a little, this usually includes activity that might look like a DoS attack, but it might also be sent to clients who are behaving themselves if the server is feeling under the weather) # errors that I don't think need codes (yet) * receiving a packet that contains no payload, even if it can be authenticated (implementations should just discard these without even trying to decrypt them) * an attempt to close stream 0 (use the generic code) * receiving a packet that is too big (we haven't actually got any text imposing limits on packet size; in theory the maximum size remains at the UDP maximum; we do have issue #383 which we to add a code if we decide to do anything) From nobody Mon Apr 24 00:50:10 2017 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 484B1128D6F for ; Mon, 24 Apr 2017 00:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de 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 16OcSzgb5zWg for ; Mon, 24 Apr 2017 00:50:06 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (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 3A6A9128C83 for ; Mon, 24 Apr 2017 00:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1493020204; l=3262; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=YsVP6M17nIo6osSpxWdE9+5uqXEJCdG/D4RNlr3RVs8=; b=rJwDgC2FB2C1P9oU6rLhTuuHgT94KJS5CH956gACetDnMBc3g5ieorQbQaj6m71OaF U9nSkFVTMUt8roDCCscXM0L73pcun32lMmtvdOJVrBNEGly/pETWOEdwC6REVnl6irag p/yZQ+wSyzNAYDYviO9FlI4LhlRzLE4DrrkTU= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzVikk7X61xbDMB3MPL45hBUKApHQ== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:d8b9:78b1:9c90:375c] ([2001:4dd0:ff67:0:d8b9:78b1:9c90:375c]) by smtp.strato.de (RZmta 40.6 AUTH) with ESMTPSA id L0a6f6t3O7o3YZe (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Mon, 24 Apr 2017 09:50:03 +0200 (CEST) Subject: Re: Updated Public Reset authentication patch To: quic@ietf.org References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Roland Zink Message-ID: <6d02d303-8dd5-707b-7bb0-14c6baf51302@zinks.de> Date: Mon, 24 Apr 2017 09:50:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AE8D9A162A3427C2E41748B7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2017 07:50:08 -0000 This is a multi-part message in MIME format. --------------AE8D9A162A3427C2E41748B7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Am 24.04.2017 um 03:48 schrieb Eric Rescorla: > > Stepping back here, this comes back to how much information we want to > > give the middlebox. With the added observation that when you give a > middlebox information you have to trust them to do the right thing > with it. > > > Christian's view might seem pessimistic, but middlebox state is > precious. In designing for this new protocol, a middlebox designer > has to account for the possibility that this flow was migrated from > some other network path. A migrated flow won't include a handshake. > > > Well, those middleboxes can use timeouts. Remember that ordinary resets > aren't public, so unless we make them so middleboxes will have that > problem > in any case. > > -Ekr > > This is already happening, e.g. middleboxes give shorter timeouts to UDP to protect their precious memory. When middleboxes can easily be flooded with state information you probably will get shorter timeouts or even observe some breakages. Regards, Roland --------------AE8D9A162A3427C2E41748B7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 24.04.2017 um 03:48 schrieb Eric Rescorla:

Stepping back here, this comes back to how much information we want to
give the middlebox.  With the added observation that when you give a
middlebox information you have to trust them to do the right thing
with it.

Christian's view might seem pessimistic, but middlebox state is
precious.  In designing for this new protocol, a middlebox designer
has to account for the possibility that this flow was migrated from
some other network path.  A migrated flow won't include a handshake.

Well, those middleboxes can use timeouts. Remember that ordinary resets
aren't public, so unless we make them so middleboxes will have that problem
in any case.

-Ekr



This is already happening, e.g. middleboxes give shorter timeouts to UDP to protect their precious memory. When middleboxes can easily be flooded with state information you probably will get shorter timeouts or even observe some breakages.

Regards,
Roland

--------------AE8D9A162A3427C2E41748B7-- From nobody Mon Apr 24 11:05:49 2017 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 99B5A131901 for ; Mon, 24 Apr 2017 11:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.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 I6dPZIeSapCk for ; Mon, 24 Apr 2017 11:05:46 -0700 (PDT) Received: from homiemail-a116.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2819E131916 for ; Mon, 24 Apr 2017 11:05:36 -0700 (PDT) Received: from homiemail-a116.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a116.g.dreamhost.com (Postfix) with ESMTP id 327E960001344; Mon, 24 Apr 2017 11:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=b1H6RDy6xqknIn0cDcJYaH8rCQQ=; b=AjCvekwKfmtrgXpH94nMpeFlvZz9 v8UYbUNbI43LQczQGC5DmsQDEraJWdHxueSMGXFZKu3qDhiAnt7eurE3v3za630P MS/JISGfGqbzDpk7ZWRyMae4PKNmnYtgnPp6uFpTg4XUhwfEtidUYiUbaxD73yzk OHhG65OiraVW2DE= Received: from [192.168.1.8] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a116.g.dreamhost.com (Postfix) with ESMTPSA id 0A44A60001342; Mon, 24 Apr 2017 11:05:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Error code cleanup From: "Roy T. Fielding" In-Reply-To: Date: Mon, 24 Apr 2017 11:05:32 -0700 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2017 18:05:48 -0000 > On Apr 23, 2017, at 9:41 PM, Martin Thomson = wrote: >=20 > The TLS and HTTP drafts now have some nice error code lists. And by > nice I mean short and precise. Each error code is justified and most > either point to a distinct reaction or a distinct cause (the latter > I'm less enthusiastic about with HTTP, but that is just a quibble). >=20 > I've been working on fixing error codes for the transport. >=20 > Here's what I'm going to propose for the breakdown of error codes in > the transport piece. I won't name these yet, there are reasons to > parallel codes in the HTTP spec. Some of these might be broken down > finer into codes that identify specific causes, but I might push back > on doing that too aggressively. >=20 > I have 13 codes here. TLS has 3, HTTP has 17 (which I think is too > high, but what do I know). We might want to discuss reducing the size > of the error code space a little at some point. >=20 > I went through the existing codes and all are either invalid or > covered here - as far as I can see. Clearly, this is still early > enough that there might be new codes added, but I think that the above > list is close enough. >=20 > I plan to write this up during this week. I'm sharing this in the > hopes that someone might help by correcting any mistakes that I've > made. >=20 >=20 > # internal errors >=20 > * this error was my fault, probably a bug or resource issue on my end > that means I can't continue >=20 > I don't think that we want to highlight the difference between > different internal errors here lest we provide instructions on how to > trigger DoS or bugs. Having just one code in this category seems > right. >=20 > # errors that aren't errors >=20 > * this isn't an error (in case we use one of the error messages to = signal close) >=20 > * this isn't an error, you asked me to generate this error (for the > case where RST_STREAM causes RST_STREAM to be sent, or for the > proposed DISINTEREST frame) >=20 > * this isn't an error, I just don't want this stream any more (the > general form of the cancellation request) >=20 > # errors that are protocol violations >=20 > * you did something wrong, but nothing specific was appropriate (this > is a general catch-all error code for use when other protocol > violations aren't appropriate) >=20 > * you send me more data than I allowed (flow control) >=20 > * you opened a stream before I said you could use it (streams) >=20 > * you sent a frame on a stream that was in a state that doesn't allow = that >=20 > * you sent data on a stream past the final data offset, or you seem to > have moved the final offset >=20 > * you sent a badly-formatted frame (this includes things that have bad > lengths primarily; I think that includes an empty STREAM with no FIN > flag; the range of errors here doesn't really seem to justify an error > code per frame type) >=20 > * your transport parameters were invalid >=20 > * the version negotiation fields in your transport parameters don't > match with my understanding of what we did during version negotiation, > IT'S AN ATTACK! (this could have been part of transport parameter > validation, but the fact that this is an attack rather than just a > screwup is a good reason to use a different code) >=20 > # errors that aren't protocol issues violations, but they need a = signal anyway >=20 > * enhance your calm (this is the name we used in h2 to signal all > sorts of cases where an endpoint could tell the other side to cool off > a little, this usually includes activity that might look like a DoS > attack, but it might also be sent to clients who are behaving > themselves if the server is feeling under the weather) >=20 > # errors that I don't think need codes (yet) >=20 > * receiving a packet that contains no payload, even if it can be > authenticated (implementations should just discard these without even > trying to decrypt them) >=20 > * an attempt to close stream 0 (use the generic code) >=20 > * receiving a packet that is too big (we haven't actually got any text > imposing limits on packet size; in theory the maximum size remains at > the UDP maximum; we do have issue #383 which we to add a code if we > decide to do anything) Assuming we are only talking about transport codes, I would expect * parameter too long for any length-delimited parameter; * unrecognized application for quic recipients that might detect multiple app protocols; * timeout before application-level for the rare case where the transport is unable to continue before it can invoke anything that might respond with application-level = semantics; and * timeout while decrypting because that can happen and is near impossible to determine = otherwise. ....Roy From nobody Tue Apr 25 14:15:39 2017 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 23D301294C5 for ; Tue, 25 Apr 2017 14:15:38 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 YihV-Bo0XH6h for ; Tue, 25 Apr 2017 14:15:36 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 CF0C41252BA for ; Tue, 25 Apr 2017 14:15:35 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id y63so127185468qkd.1 for ; Tue, 25 Apr 2017 14:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZDjeGNMCBBmUEMaDgjrmS0LUiD6Y1VjjFphNNAVeejU=; b=sZINCGKouv4g0Oe/UC7tCiERAL7ZyKUUJDdEF/gO6Z40pprvNVLwugcKi9fANhToBJ AsDQO0Faa/dYDkt11l6+Vd/vSiSbovZs3HW9ooKuWPISSLoLKGe9TVZFRX12hFXWcwte uhCT4L4jHeM18PWKvJz8jQpGpWyuPcz3sfxbjMPiFOU+f0Ksa3vktSkSDy7kIX24kH1v XO4pc70tsn9xY6Cd3VwhOqrAEUEgd/Mz5R+qxRuwDekItVRvLJQA3T5ukdqnNvF+UtsJ 86s6OCFO/GGUB9EAD90JFBet8cHW9h1AWwygmMhWkcC0LabozAIp/8Ye3MRiHvkBIYLt nSNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZDjeGNMCBBmUEMaDgjrmS0LUiD6Y1VjjFphNNAVeejU=; b=Gc61bPBaxKfFzJXtMB5yWCUqCVvCs+JiuaQ/rT5zvbno7XtdckzrZKR3M1+9juWrCI 8GQNXAqvHddtjOFR5bFTCW2VRGaHndkk5FP0Biuy46oVYPiWlBD0AV6N7cGHm9p8do7v xhqG/kydH5S/xeYA3TcRrK6yb8rZHmnsnHuTMObbw04FMJqeQwno88W9vftqnAgQnSDx G4nsPIN4al0QOXD9W8UR95o64OB5srcDEsWQDW1iGyT30tG2UikNBbeaZtgdtyBzK6zT 6wkNzHV+emPLh/yizTV17OM8Ie3xJ2HhbGVjbWA+52Kp/3I8Oyv5koach8NNPmiaonBz eKMA== X-Gm-Message-State: AN3rC/4s7mxhM/f1K0BtMP1QWvukhCl7rHTNiE1/YyoH8/DiHcXvQv74 a5+ne94pwW2233yKvmSflvRWfGAr5vM9vV/Z9A== X-Received: by 10.55.23.84 with SMTP id i81mr12977297qkh.153.1493154934754; Tue, 25 Apr 2017 14:15:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.76.70 with HTTP; Tue, 25 Apr 2017 14:15:33 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Tue, 25 Apr 2017 17:15:33 -0400 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary=001a1146fe627b7689054e04397c Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 21:15:38 -0000 --001a1146fe627b7689054e04397c Content-Type: text/plain; charset=UTF-8 I have a few questions with regard to the thread model. Do I understand correctly that the thread model is to allow connections to be only reset by passive observers on the path? If so, why is connection ID not sufficient? Why can't an attacker just send ICMP port unreachable? I am also not sure we should be prescribing a specific construction of the verifier in the spec, rather than just specifying requirements for such and leaving this up to implementation. -- Victor. On Fri, Apr 21, 2017 at 3:36 AM, Martin Thomson wrote: > Back at the very start of this process, ekr proposed a design for > public reset [1] that was quite popular, but we never got round to > closing on the issue, or landing the change. Since then everything > changed. > > I just spent a bit of time with this and I have a shiny new PR for > this. I've convinced myself that the design is sound, simple, and > quite workable. > > https://github.com/quicwg/base-drafts/pull/460 > > There are a couple of wrinkles we should discuss a little here: > > * This uses transport parameters for the verifier and these are encrypted. > > The original design called for the verifier to appear in the clear so > that intermediaries can validate the reset. > > Moving the verifier into clear is tricky. It would require either > moving all transport parameters out from under encryption or splitting > transport parameters into encrypted and not-encrypted. Neither option > is particularly appealing to me. > > I don't think that we need the verifier in the clear. An on-path > intermediary can be reasonably assured that the generator of the > packet was on path based on the 12 octets that are copied from the > packet that triggered the reset. I would argue that that signal is > enough to know that data on the path is going to cease. The > intermediary doesn't need to know that the *connection* is going away, > which is what the proof would provide them, they only need to concern > themselves with the data that flows on the *path*. > > * There's a little bit of a challenge in ensuring that the combination > of connection ID, server ID and key aren't reused. > > I think that the way you do this is split the portion of the > connection ID space allocated to a server into two and use which half > you are in to signal which of two keys you are using, then slowly > rotate the keys (you can use alt-svc to accelerate this). This isn't > in the write-up, because it's just one potential design in this space. > I mostly just want to make sure that this level of extra complexity is > justified/manageable for those that need to use the basic stateless > design that is suggested in the PR. > > > [1] https://github.com/quicwg/base-drafts/pull/20 > > --001a1146fe627b7689054e04397c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have a few questions with regard to the thread mode= l.

Do I understand correctly that the thread model= is to allow connections to be
only reset by passive observers on= the path?=C2=A0 If so, why is connection ID not
sufficient?

Why can't an attacker just send ICMP port unreacha= ble?

I am also not sure we should be prescribing a= specific construction of the
verifier in the spec, rather than j= ust specifying requirements for such and
leaving this up to imple= mentation.

=C2=A0 -- Victor.

<= /div>

On Fri, Apr = 21, 2017 at 3:36 AM, Martin Thomson <martin.thomson@gmail.com&g= t; wrote:
Back at the very start o= f this process, ekr proposed a design for
public reset [1] that was quite popular, but we never got round to
closing on the issue, or landing the change.=C2=A0 Since then everything changed.

I just spent a bit of time with this and I have a shiny new PR for
this.=C2=A0 I've convinced myself that the design is sound, simple, and=
quite workable.

https://github.com/quicwg/base-drafts/pull/460

There are a couple of wrinkles we should discuss a little here:

* This uses transport parameters for the verifier and these are encrypted.<= br>
The original design called for the verifier to appear in the clear so
that intermediaries can validate the reset.

Moving the verifier into clear is tricky.=C2=A0 It would require either
moving all transport parameters out from under encryption or splitting
transport parameters into encrypted and not-encrypted.=C2=A0 Neither option=
is particularly appealing to me.

I don't think that we need the verifier in the clear.=C2=A0 An on-path<= br> intermediary can be reasonably assured that the generator of the
packet was on path based on the 12 octets that are copied from the
packet that triggered the reset.=C2=A0 I would argue that that signal is enough to know that data on the path is going to cease.=C2=A0 The
intermediary doesn't need to know that the *connection* is going away,<= br> which is what the proof would provide them, they only need to concern
themselves with the data that flows on the *path*.

* There's a little bit of a challenge in ensuring that the combination<= br> of connection ID, server ID and key aren't reused.

I think that the way you do this is split the portion of the
connection ID space allocated to a server into two and use which half
you are in to signal which of two keys you are using, then slowly
rotate the keys (you can use alt-svc to accelerate this).=C2=A0 This isn= 9;t
in the write-up, because it's just one potential design in this space.<= br> I mostly just want to make sure that this level of extra complexity is
justified/manageable for those that need to use the basic stateless
design that is suggested in the PR.


[1] https://github.com/quicwg/base-drafts/pull/20<= /a>


--001a1146fe627b7689054e04397c-- From nobody Tue Apr 25 22:28:17 2017 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 52003126D74 for ; Tue, 25 Apr 2017 22:28:16 -0700 (PDT) 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, FREEMAIL_FROM=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=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 UNlkjY7DfaKg for ; Tue, 25 Apr 2017 22:28:15 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 9633A120046 for ; Tue, 25 Apr 2017 22:28:14 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id 88so101648800lfr.0 for ; Tue, 25 Apr 2017 22:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Jkv1ew+pM9kTmvrwDwiMc2r7zJbsQ80s3X+6i2773E=; b=nWmY6kGVvudHoD7PqccIHZZLdi1qDs2NRfwsEpsfb9HRry4JTKUuKVvX+ZOLMsADzs IFz/2/qbK6bgTBa89+cStPZxA6frBg1cTHEKjM+pYwYPi9RcglyM5rl21bi3PfleFM4S xeCxNdDu9ZtNpEg8sxQ1PagFdj7lUoP73bH77F0OixNeowH1yI9qkeEaEKh7dE49DJf6 2NLYQX+zblYcvx4yrikCsQFKf4V6af9UafcYTRl2H3zyyR5xiUexYITVdR8K/2jDuGbo qTFQf86DRLBwx8z0vFbmF+zuaNLUEuInxBplh85jmyrLsz4zLBwUug0+jz1NvTg2qDm4 8dZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Jkv1ew+pM9kTmvrwDwiMc2r7zJbsQ80s3X+6i2773E=; b=tgfB0oOuNllASxj0VkcLx7qsiUVp+Mo4KNmbzmi7DtzZ4Wn7SLMokGHZGk+XUykwmx 3B81woG8zQUZS/x13HHSuBqdIrp6/hCVDLM3yqeVxNYnUUR32eqXHz4ZUW1vnObdm9WI sxtCEYb1HG10P4t78Kh6TIjDpQzDuDY00edc4reyPDVP9hpJ6NlU/kLJw8/F5ZPrP8Fx iZ2x1pW2JBtrESzCCZQpbW9v0FTkxXdVt3jB7CDO1MQnLdR6Bhem67XOXLFthIJ+wFOe Ih6EzAWzP6hDx1kJ9/eHmMiXxW8by0TSCiPVWTKiYrQlzW7Ke8Zz7zDmLX0ytH1gsNof vpow== X-Gm-Message-State: AN3rC/760Y7eU7cN3JVlD3TS7JrWZgMKFhQHwH23kjADFynQnpFn3nMg 33sjUrBa1iOruzANTJC1p8U0xBS9vQ== X-Received: by 10.46.19.18 with SMTP id 18mr3047172ljt.103.1493184492637; Tue, 25 Apr 2017 22:28:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 25 Apr 2017 22:28:11 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 26 Apr 2017 15:28:11 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Victor Vasiliev Cc: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 26 Apr 2017 05:28:16 -0000 On 26 April 2017 at 07:15, Victor Vasiliev wrote: > I have a few questions with regard to the thread model. > > Do I understand correctly that the thread model is to allow connections to > be > only reset by passive observers on the path? If so, why is connection ID > not > sufficient? You mean threat model? The threat model that *this* proposal assumes (we've been discussing many other things in this thread), is that there are entities that can observe traffic and inject traffic and we don't want them to be able to cause a connection to be closed ***. That is, the opposite of what you suggest in that we want to ensure that only endpoints can cause the connection to be terminated. *** Christian points out that we might need to consider the possibility of part of the signal leaking to the path and the path acting on that, hence the suggestion to send out chaff. > Why can't an attacker just send ICMP port unreachable? An ICMP unreachable might work if endpoints (or middleboxes) ignored ample evidence that suggests that the destination address is actually reachable (like the packets that are flowing...). The problem with ICMP unreachable is that it tends to take out the entire peer service, so it's not exactly a precise way to take out a unwanted flow. In addition, for PMTUD, we've adopted the approach that ICMP is treated with suspicion. Also, ICMP doesn't always reach the endpoint because it gets swallowed by the OS (which might have the desired effect today, but maybe we should consider that to be a bug rather than a feature). Finally, ICMP might be a signal that the *path* is dead, but it won't stop an endpoint from using (or attempting to use) other paths to reach the same destination. > I am also not sure we should be prescribing a specific construction of the > verifier in the spec, rather than just specifying requirements for such and > leaving this up to implementation. The PR has to define the mapping between verifier and proof. It doesn't have to define a form for proof, and it doesn't, but it does suggest how that it could be implemented. I find that for tricky things like this documenting at least one workable solution helps a great deal. From nobody Wed Apr 26 12:03:20 2017 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 887EB1314CD for ; Wed, 26 Apr 2017 12:03:19 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 ZcuDGJY_qoLc for ; Wed, 26 Apr 2017 12:03:18 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 D7CE6128C84 for ; Wed, 26 Apr 2017 12:03:17 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id f76so9335766qke.2 for ; Wed, 26 Apr 2017 12:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6N8MuXguYt60NZlRjOS5WS/ntUmZdpYqM6+Ssx2nhdA=; b=JFSYgGQFvNFCrug+JU5eEMa8Q43y/75qnVk3amH4qRAL9/9Bv3y1HNOW9hsZmYNLam LJs0/4EaR5wuNradqVkKU0YLkwOg7nwSM3UoPcisjCEFOVUtWqtK9P4rdxmN5qiqW7dx 7N32k77QO8wTen2XKwLXbVZzBPzTJFcxBwWF6mqUD6YhQf2O25OFZn0bAuWLPBu7fEtx Vm8m1XnRIXMrECTyLHCYcVX4VmMBkg+dNqAXp7tq1MX7heiP6Dylqtt0y/IR/4Qm26rM PJqTdA1nA1KTDmcQ49ZUXEdx5WL7Dtlxw4dJk+Fo9mz5h5G6hLWNBOwfaFQs6dEzb28r JlHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6N8MuXguYt60NZlRjOS5WS/ntUmZdpYqM6+Ssx2nhdA=; b=LoGB1vwFYq2XTGqIj/WwxLNn/PFG7ocfmDk5qpOOl1bGWrwtqswRz46jGpya86sozo mZK/UpK6JayAGWYqsAo6olIb0l48yll35/ms2QaNVTbgSwQMArLYvRoAFF6uyZ1VFk2D EP+eyifz3fI+owIeIznR00juARWIBk9hfXIoSQv3YeNxv5nInUUmFUidaz6WIcCHgf78 FFL8HJudoV3IEuOLPH7vvZXMHvvEboBifnZg58Y0aVhFmqUBGahzi+4CZT63NQaHjiSD 410rmWlanO62cn3jMbZYCEZ9aIzEYJa6fQrR7doqcopsg3xzsOWsa3h2uKJy/Qw06uly bkQA== X-Gm-Message-State: AN3rC/4j4Z4sKu1mNnC+ttZKHezDgPa6ItgLhxBCMJJD8LGq27Cv3x8d 06WBxy1yH3/hgJMqLRGDeKORoXxzw4ia X-Received: by 10.55.78.201 with SMTP id c192mr1413566qkb.81.1493233396818; Wed, 26 Apr 2017 12:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.76.70 with HTTP; Wed, 26 Apr 2017 12:03:15 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Wed, 26 Apr 2017 15:03:15 -0400 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary=001a114a882e2fc13d054e167e6c Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 26 Apr 2017 19:03:19 -0000 --001a114a882e2fc13d054e167e6c Content-Type: text/plain; charset=UTF-8 On Wed, Apr 26, 2017 at 1:28 AM, Martin Thomson wrote: > On 26 April 2017 at 07:15, Victor Vasiliev wrote: > > I have a few questions with regard to the thread model. > > > > Do I understand correctly that the thread model is to allow connections > to > > be > > only reset by passive observers on the path? If so, why is connection ID > > not > > sufficient? > > You mean threat model? > > The threat model that *this* proposal assumes (we've been discussing > many other things in this thread), is that there are entities that can > observe traffic and inject traffic and we don't want them to be able > to cause a connection to be closed ***. > > That is, the opposite of what you suggest in that we want to ensure > that only endpoints can cause the connection to be terminated. > > *** Christian points out that we might need to consider the > possibility of part of the signal leaking to the path and the path > acting on that, hence the suggestion to send out chaff. > I see. I assume that means that any middlebox on the path would have to rely on timeouts for both itself closing the connection, and for learning that the connection was closed? This kind of works, but I can see it leading to quite negative user experience in certain cases, where users would have to wait 15+ seconds to learn their connections is being firewalled off. > > Why can't an attacker just send ICMP port unreachable? > > An ICMP unreachable might work if endpoints (or middleboxes) ignored > ample evidence that suggests that the destination address is actually > reachable (like the packets that are flowing...). The problem with > ICMP unreachable is that it tends to take out the entire peer service, > so it's not exactly a precise way to take out a unwanted flow. > > In addition, for PMTUD, we've adopted the approach that ICMP is > treated with suspicion. Also, ICMP doesn't always reach the endpoint > because it gets swallowed by the OS (which might have the desired > effect today, but maybe we should consider that to be a bug rather > than a feature). > ICMP Port Unreachable (type 3, code 3) will take out a specific port. In practice all OSes I've observed react to it by closing the relevant UDP socket with either "connection reset" or "connection refused" error, since it's typically used as a public reset for arbitrary UDP based protocols (in particular, it's sent when the port in question is closed). > Finally, ICMP might be a signal that the *path* is dead, but it won't > stop an endpoint from using (or attempting to use) other paths to > reach the same destination. > > > I am also not sure we should be prescribing a specific construction of > the > > verifier in the spec, rather than just specifying requirements for such > and > > leaving this up to implementation. > > The PR has to define the mapping between verifier and proof. It > doesn't have to define a form for proof, and it doesn't, but it does > suggest how that it could be implemented. I find that for tricky > things like this documenting at least one workable solution helps a > great deal. > That is in fact helpful, I am mostly worried that this part might be interpreted as normative by accident. --001a114a882e2fc13d054e167e6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 26, 2017 at 1:28 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 26 April 2017 at 07:15, Victor Vasiliev <= vasilvv@google.com> wrote:
> I have a few questions with regard to the thread model.
>
> Do I understand correctly that the thread model is to allow connection= s to
> be
> only reset by passive observers on the path?=C2=A0 If so, why is conne= ction ID
> not
> sufficient?

You mean threat model?

The threat model that *this* proposal assumes (we've been discussing many other things in this thread), is that there are entities that can
observe traffic and inject traffic and we don't want them to be able to cause a connection to be closed ***.

That is, the opposite of what you suggest in that we want to ensure
that only endpoints can cause the connection to be terminated.

*** Christian points out that we might need to consider the
possibility of part of the signal leaking to the path and the path
acting on that, hence the suggestion to send out chaff.

I see.=C2=A0 I assume t= hat means that any middlebox on the path would have to rely
on ti= meouts for both itself closing the connection, and for learning that the
connection was closed?=C2=A0 This kind of works, but I can see it l= eading to quite
negative user experience in certain cases, where = users would have to wait 15+
seconds to learn their connections i= s being firewalled off.
=C2=A0
> Why can't an attacker just send ICMP port unreachable?

An ICMP unreachable might work if endpoints (or middleboxes) ignored=
ample evidence that suggests that the destination address is actually
reachable (like the packets that are flowing...).=C2=A0 The problem with ICMP unreachable is that it tends to take out the entire peer service,
so it's not exactly a precise way to take out a unwanted flow.

In addition, for PMTUD, we've adopted the approach that ICMP is
treated with suspicion.=C2=A0 Also, ICMP doesn't always reach the endpo= int
because it gets swallowed by the OS (which might have the desired
effect today, but maybe we should consider that to be a bug rather
than a feature).

ICMP Port Unreach= able (type 3, code 3) will take out a specific port.=C2=A0 In
pra= ctice all OSes I've observed react to it by closing the relevant UDP so= cket
with either "connection reset" or "connection= refused" error, since it's
typically used as a public r= eset for arbitrary UDP based protocols (in
particular, it's s= ent when the port in question is closed).

= =C2=A0
Finally, ICMP might be a signal that the *path* is dead, but it won't stop an endpoint from using (or attempting to use) other paths to
reach the same destination.

> I am also not sure we should be prescribing a specific construction of= the
> verifier in the spec, rather than just specifying requirements for suc= h and
> leaving this up to implementation.

The PR has to define the mapping between verifier and proof.=C2=A0 I= t
doesn't have to define a form for proof, and it doesn't, but it doe= s
suggest how that it could be implemented.=C2=A0 I find that for tricky
things like this documenting at least one workable solution helps a
great deal.

That is in fact helpful, I am mostly worried that this part might b= e
interpreted as normative by accident.
--001a114a882e2fc13d054e167e6c-- From nobody Wed Apr 26 12:35:37 2017 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 DFDE91293F4 for ; Wed, 26 Apr 2017 12:35:35 -0700 (PDT) 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 ogpgrE4a7Pek for ; Wed, 26 Apr 2017 12:35:34 -0700 (PDT) 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 05FB7126C26 for ; Wed, 26 Apr 2017 12:35:34 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d3Sig-0001gQ-Tw for quic@ietf.org; Wed, 26 Apr 2017 21:35:31 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d3Sic-0008HK-NQ for quic@ietf.org; Wed, 26 Apr 2017 15:35:20 -0400 Received: (qmail 7524 invoked from network); 26 Apr 2017 19:35:18 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.199]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Apr 2017 19:35:17 -0000 To: Victor Vasiliev , Martin Thomson References: Cc: QUIC WG From: Christian Huitema Message-ID: Date: Wed, 26 Apr 2017 12:35:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4F2CC77010218D34E584B848" Subject: Re: Updated Public Reset authentication patch X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.23) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXq24tbr0sOxIQUQ20fxhSccRcOb18WfxGyg6Om6u4YYm5I2qDaYv2oVIJ/y 1yDtmCY5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKXTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0e1QDQS3E FBkZtf3zHJERVLbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa1VNh3t6tesmDTH5LdJATIYSDqsuDW2Gm7SC dGSqnlpmxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+3pSiCKkaAoX/nv7Y+HHGvPcu6wTHpnlfUs9BUPj1rZ3 X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 26 Apr 2017 19:35:36 -0000 This is a multi-part message in MIME format. --------------4F2CC77010218D34E584B848 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/26/2017 12:03 PM, Victor Vasiliev wrote: > On Wed, Apr 26, 2017 at 1:28 AM, Martin Thomson > > wrote: > > ... > > That is, the opposite of what you suggest in that we want to ensure= > that only endpoints can cause the connection to be terminated. > > *** Christian points out that we might need to consider the > possibility of part of the signal leaking to the path and the path > acting on that, hence the suggestion to send out chaff. > > > I see. I assume that means that any middlebox on the path would have > to rely > on timeouts for both itself closing the connection, and for learning > that the > connection was closed? This kind of works, but I can see it leading > to quite > negative user experience in certain cases, where users would have to > wait 15+ > seconds to learn their connections is being firewalled off. Actually, the design would allow the middleboxes to act on the public reset, but only if they could verify the reset's authenticity. That would require middleboxes to watch the initial exchange, capture the public reset verifier, memorize it in the state associated with the five tuple, and then when seeing a public reset testing whether the proof hashes to the public reset verifier. If the hash and verifier match, the reset is genuine and the middlebox can act on it. If it is not, or if the middlebox did not capture and memorize the verifier, then the middlebox should do nothing and leave the five tuple state unchanged. Of course, middlebox developers might be tempted to take short cuts. The proposal is to "grease" the path. Some implementation would occasionally send public reset packets with an invalid proof. The incorrectly implemented middleboxes would incorrectly drop the connection, and their users would complain of the resulting poor service. -- Christian Huitema --------------4F2CC77010218D34E584B848 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/26/2017 12:03 PM, Victor Vasiliev wrote:
On Wed, Apr 26, 2017 at 1:28 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
...

That is, the opposite of what you suggest in that we want to ensure
that only endpoints can cause the connection to be terminated.

*** Christian points out that we might need to consider the
possibility of part of the signal leaking to the path and the path
acting on that, hence the suggestion to send out chaff.

I see.  I assume that means that any middlebox on the path would have to rely
on timeouts for both itself closing the connection, and for learning that the
connection was closed?  This kind of works, but I can see it leading to quite
negative user experience in certain cases, where users would have to wait 15+
seconds to learn their connections is being firewalled off.

Actually, the design would allow the middleboxes to act on the public reset, but only if they could verify the reset's authenticity. That would require middleboxes to watch the initial exchange, capture the public reset verifier, memorize it in the state associated with the five tuple, and then when seeing a public reset testing whether the proof hashes to the public reset verifier. If the hash and verifier match, the reset is genuine and the middlebox can act on it. If it is not, or if the middlebox did not capture and memorize the verifier, then the middlebox should do nothing and leave the five tuple state unchanged.

Of course, middlebox developers might be tempted to take short cuts. The proposal is to "grease" the path. Some implementation would occasionally send public reset packets with an invalid proof. The incorrectly implemented middleboxes would incorrectly drop the connection, and their users would complain of the resulting poor service.

-- Christian Huitema

--------------4F2CC77010218D34E584B848-- From nobody Wed Apr 26 13:06:58 2017 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 9849512EB55 for ; Wed, 26 Apr 2017 13:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.791 X-Spam-Level: X-Spam-Status: No, score=-4.791 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 Lc8pW1_hR4Gt for ; Wed, 26 Apr 2017 13:06:55 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0114.outbound.protection.outlook.com [104.47.37.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3141294A9 for ; Wed, 26 Apr 2017 13:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W6Ef29B0by2cMZYOt87pwCaxqwM+I7QmH4bhmoEEQv0=; b=o9P2hgUUob5iOU21voJpb5iWXlN0VIjGCVdeCeRE+iLpylQdl755bX/tcishFTxK895oay0h+pj9jNzW5bjUpJn97/6xvvBqYJEmQ5uQnhWdz/edsOE1h4Oq2ljuLrNRNpMb3iR6g+gblROEQQ+yuShpOhvLlzRsfaGwOgrYuMY= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Wed, 26 Apr 2017 20:06:51 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1061.011; Wed, 26 Apr 2017 20:06:51 +0000 From: Mike Bishop To: huitema , Victor Vasiliev , Martin Thomson CC: QUIC WG Subject: RE: Updated Public Reset authentication patch Thread-Topic: Updated Public Reset authentication patch Thread-Index: AQHSunH5TV1Lg57zJkSGGTavMHpZ4aHWnUKAgACJo4CAAOO7gIAACO8AgAAIv1A= Date: Wed, 26 Apr 2017 20:06:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huitema.net; dkim=none (message not signed) header.d=none;huitema.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::ad] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:WXQJXOmS+EK1zV57zcTN6MgudoHPrBhJZpINmLzL5yoMFPQiqqQcG+Fcfh8G+Whhcm0sTQVxgcoXOsQhFL48/n2oC+h4vS+7X5lsL6rI3us/G9z+RxAq9qQd67GYNx46pmAZF7hg5yEqVGImUU4GuUE6J62/diXrcKPfPKXtl+k/ttwrb0Z6SCCKgGi8s0m/jHHcJ9TMz/A/QBuC/xWDj8zJEkBIOguMmUOfjaMZ3ZgWYARn+/KleyQ9C8oqHvz3irtBG7C97bxMCJsmgUjPFha+rsu80fNNNvppGw5c+S1v2iA7FyxKtkhSpq3YEYab9jkvkg2M2tMWYvT9IPdoTBIBLZLuRrXw03Bs7cLwcPM= x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: 7d540bad-c814-40ad-47ea-08d48cdfc704 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2705; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39850400002)(39840400002)(39450400003)(39860400002)(377454003)(24454002)(8676002)(2906002)(8936002)(53546009)(6116002)(10090500001)(102836003)(790700001)(3660700001)(15650500001)(2420400007)(86362001)(229853002)(93886004)(3280700002)(2950100002)(8990500004)(5005710100001)(86612001)(5660300001)(74316002)(33656002)(10710500007)(7696004)(7736002)(561944003)(81166006)(6506006)(4326008)(25786009)(2900100001)(39060400002)(122556002)(38730400002)(6246003)(6436002)(99286003)(7110500001)(189998001)(53936002)(54896002)(236005)(6306002)(55016002)(9686003)(54356999)(76176999)(50986999)(10290500003)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708BB25912856C162025A4987110BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 20:06:50.8252 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 26 Apr 2017 20:06:57 -0000 --_000_BN6PR03MB2708BB25912856C162025A4987110BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Li4udG8gdGhhdCBpbXBsZW1lbnRhdGlvbi4gIPCfmIoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGlhbiBIdWl0ZW1hDQpTZW50 OiBXZWRuZXNkYXksIEFwcmlsIDI2LCAyMDE3IDEyOjM1IFBNDQpUbzogVmljdG9yIFZhc2lsaWV2 IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21h aWwuY29tPg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogVXBkYXRl ZCBQdWJsaWMgUmVzZXQgYXV0aGVudGljYXRpb24gcGF0Y2gNCg0KDQoNCg0KT24gNC8yNi8yMDE3 IDEyOjAzIFBNLCBWaWN0b3IgVmFzaWxpZXYgd3JvdGU6DQpPbiBXZWQsIEFwciAyNiwgMjAxNyBh dCAxOjI4IEFNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCi4uLg0KDQpUaGF0IGlzLCB0aGUg b3Bwb3NpdGUgb2Ygd2hhdCB5b3Ugc3VnZ2VzdCBpbiB0aGF0IHdlIHdhbnQgdG8gZW5zdXJlDQp0 aGF0IG9ubHkgZW5kcG9pbnRzIGNhbiBjYXVzZSB0aGUgY29ubmVjdGlvbiB0byBiZSB0ZXJtaW5h dGVkLg0KDQoqKiogQ2hyaXN0aWFuIHBvaW50cyBvdXQgdGhhdCB3ZSBtaWdodCBuZWVkIHRvIGNv bnNpZGVyIHRoZQ0KcG9zc2liaWxpdHkgb2YgcGFydCBvZiB0aGUgc2lnbmFsIGxlYWtpbmcgdG8g dGhlIHBhdGggYW5kIHRoZSBwYXRoDQphY3Rpbmcgb24gdGhhdCwgaGVuY2UgdGhlIHN1Z2dlc3Rp b24gdG8gc2VuZCBvdXQgY2hhZmYuDQoNCkkgc2VlLiAgSSBhc3N1bWUgdGhhdCBtZWFucyB0aGF0 IGFueSBtaWRkbGVib3ggb24gdGhlIHBhdGggd291bGQgaGF2ZSB0byByZWx5DQpvbiB0aW1lb3V0 cyBmb3IgYm90aCBpdHNlbGYgY2xvc2luZyB0aGUgY29ubmVjdGlvbiwgYW5kIGZvciBsZWFybmlu ZyB0aGF0IHRoZQ0KY29ubmVjdGlvbiB3YXMgY2xvc2VkPyAgVGhpcyBraW5kIG9mIHdvcmtzLCBi dXQgSSBjYW4gc2VlIGl0IGxlYWRpbmcgdG8gcXVpdGUNCm5lZ2F0aXZlIHVzZXIgZXhwZXJpZW5j ZSBpbiBjZXJ0YWluIGNhc2VzLCB3aGVyZSB1c2VycyB3b3VsZCBoYXZlIHRvIHdhaXQgMTUrDQpz ZWNvbmRzIHRvIGxlYXJuIHRoZWlyIGNvbm5lY3Rpb25zIGlzIGJlaW5nIGZpcmV3YWxsZWQgb2Zm Lg0KDQpBY3R1YWxseSwgdGhlIGRlc2lnbiB3b3VsZCBhbGxvdyB0aGUgbWlkZGxlYm94ZXMgdG8g YWN0IG9uIHRoZSBwdWJsaWMgcmVzZXQsIGJ1dCBvbmx5IGlmIHRoZXkgY291bGQgdmVyaWZ5IHRo ZSByZXNldCdzIGF1dGhlbnRpY2l0eS4gVGhhdCB3b3VsZCByZXF1aXJlIG1pZGRsZWJveGVzIHRv IHdhdGNoIHRoZSBpbml0aWFsIGV4Y2hhbmdlLCBjYXB0dXJlIHRoZSBwdWJsaWMgcmVzZXQgdmVy aWZpZXIsIG1lbW9yaXplIGl0IGluIHRoZSBzdGF0ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGZpdmUg dHVwbGUsIGFuZCB0aGVuIHdoZW4gc2VlaW5nIGEgcHVibGljIHJlc2V0IHRlc3Rpbmcgd2hldGhl ciB0aGUgcHJvb2YgaGFzaGVzIHRvIHRoZSBwdWJsaWMgcmVzZXQgdmVyaWZpZXIuIElmIHRoZSBo YXNoIGFuZCB2ZXJpZmllciBtYXRjaCwgdGhlIHJlc2V0IGlzIGdlbnVpbmUgYW5kIHRoZSBtaWRk bGVib3ggY2FuIGFjdCBvbiBpdC4gSWYgaXQgaXMgbm90LCBvciBpZiB0aGUgbWlkZGxlYm94IGRp ZCBub3QgY2FwdHVyZSBhbmQgbWVtb3JpemUgdGhlIHZlcmlmaWVyLCB0aGVuIHRoZSBtaWRkbGVi b3ggc2hvdWxkIGRvIG5vdGhpbmcgYW5kIGxlYXZlIHRoZSBmaXZlIHR1cGxlIHN0YXRlIHVuY2hh bmdlZC4NCg0KT2YgY291cnNlLCBtaWRkbGVib3ggZGV2ZWxvcGVycyBtaWdodCBiZSB0ZW1wdGVk IHRvIHRha2Ugc2hvcnQgY3V0cy4gVGhlIHByb3Bvc2FsIGlzIHRvICJncmVhc2UiIHRoZSBwYXRo LiBTb21lIGltcGxlbWVudGF0aW9uIHdvdWxkIG9jY2FzaW9uYWxseSBzZW5kIHB1YmxpYyByZXNl dCBwYWNrZXRzIHdpdGggYW4gaW52YWxpZCBwcm9vZi4gVGhlIGluY29ycmVjdGx5IGltcGxlbWVu dGVkIG1pZGRsZWJveGVzIHdvdWxkIGluY29ycmVjdGx5IGRyb3AgdGhlIGNvbm5lY3Rpb24sIGFu ZCB0aGVpciB1c2VycyB3b3VsZCBjb21wbGFpbiBvZiB0aGUgcmVzdWx0aW5nIHBvb3Igc2Vydmlj ZS4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg== --_000_BN6PR03MB2708BB25912856C162025A4987110BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPi4uLnRvIHRoYXQgaW1w bGVtZW50YXRpb24uJm5ic3A7IDwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiYjMTI4 NTIyOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4g UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ Q2hyaXN0aWFuIEh1aXRlbWE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAyNiwg MjAxNyAxMjozNSBQTTxicj4NCjxiPlRvOjwvYj4gVmljdG9yIFZhc2lsaWV2ICZsdDt2YXNpbHZ2 QGdvb2dsZS5jb20mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFVwZGF0ZWQgUHVibGljIFJlc2V0IGF1dGhlbnRpY2F0aW9u IHBhdGNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiA0LzI2LzIwMTcgMTI6MDMgUE0sIFZpY3RvciBWYXNpbGlldiB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEFwciAyNiwgMjAxNyBhdCAxOjI4IEFNLCBNYXJ0aW4g VGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz PSJnbWFpbC0iPi4uLjwvc3Bhbj48YnI+DQo8YnI+DQpUaGF0IGlzLCB0aGUgb3Bwb3NpdGUgb2Yg d2hhdCB5b3Ugc3VnZ2VzdCBpbiB0aGF0IHdlIHdhbnQgdG8gZW5zdXJlPGJyPg0KdGhhdCBvbmx5 IGVuZHBvaW50cyBjYW4gY2F1c2UgdGhlIGNvbm5lY3Rpb24gdG8gYmUgdGVybWluYXRlZC48YnI+ DQo8YnI+DQoqKiogQ2hyaXN0aWFuIHBvaW50cyBvdXQgdGhhdCB3ZSBtaWdodCBuZWVkIHRvIGNv bnNpZGVyIHRoZTxicj4NCnBvc3NpYmlsaXR5IG9mIHBhcnQgb2YgdGhlIHNpZ25hbCBsZWFraW5n IHRvIHRoZSBwYXRoIGFuZCB0aGUgcGF0aDxicj4NCmFjdGluZyBvbiB0aGF0LCBoZW5jZSB0aGUg c3VnZ2VzdGlvbiB0byBzZW5kIG91dCBjaGFmZi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZS4mbmJzcDsgSSBh c3N1bWUgdGhhdCBtZWFucyB0aGF0IGFueSBtaWRkbGVib3ggb24gdGhlIHBhdGggd291bGQgaGF2 ZSB0byByZWx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5vbiB0aW1lb3V0cyBmb3IgYm90aCBpdHNlbGYgY2xvc2luZyB0aGUgY29ubmVjdGlvbiwg YW5kIGZvciBsZWFybmluZyB0aGF0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29ubmVjdGlvbiB3YXMgY2xvc2VkPyZuYnNwOyBUaGlzIGtp bmQgb2Ygd29ya3MsIGJ1dCBJIGNhbiBzZWUgaXQgbGVhZGluZyB0byBxdWl0ZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bmVnYXRpdmUgdXNlciBl eHBlcmllbmNlIGluIGNlcnRhaW4gY2FzZXMsIHdoZXJlIHVzZXJzIHdvdWxkIGhhdmUgdG8gd2Fp dCAxNSYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5zZWNvbmRzIHRvIGxlYXJuIHRoZWlyIGNvbm5lY3Rpb25zIGlzIGJlaW5nIGZpcmV3YWxs ZWQgb2ZmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KQWN0dWFsbHksIHRoZSBkZXNpZ24gd291bGQgYWxsb3cgdGhl IG1pZGRsZWJveGVzIHRvIGFjdCBvbiB0aGUgcHVibGljIHJlc2V0LCBidXQgb25seSBpZiB0aGV5 IGNvdWxkIHZlcmlmeSB0aGUgcmVzZXQncyBhdXRoZW50aWNpdHkuIFRoYXQgd291bGQgcmVxdWly ZSBtaWRkbGVib3hlcyB0byB3YXRjaCB0aGUgaW5pdGlhbCBleGNoYW5nZSwgY2FwdHVyZSB0aGUg cHVibGljIHJlc2V0IHZlcmlmaWVyLCBtZW1vcml6ZSBpdCBpbiB0aGUgc3RhdGUgYXNzb2NpYXRl ZA0KIHdpdGggdGhlIGZpdmUgdHVwbGUsIGFuZCB0aGVuIHdoZW4gc2VlaW5nIGEgcHVibGljIHJl c2V0IHRlc3Rpbmcgd2hldGhlciB0aGUgcHJvb2YgaGFzaGVzIHRvIHRoZSBwdWJsaWMgcmVzZXQg dmVyaWZpZXIuIElmIHRoZSBoYXNoIGFuZCB2ZXJpZmllciBtYXRjaCwgdGhlIHJlc2V0IGlzIGdl bnVpbmUgYW5kIHRoZSBtaWRkbGVib3ggY2FuIGFjdCBvbiBpdC4gSWYgaXQgaXMgbm90LCBvciBp ZiB0aGUgbWlkZGxlYm94IGRpZCBub3QgY2FwdHVyZQ0KIGFuZCBtZW1vcml6ZSB0aGUgdmVyaWZp ZXIsIHRoZW4gdGhlIG1pZGRsZWJveCBzaG91bGQgZG8gbm90aGluZyBhbmQgbGVhdmUgdGhlIGZp dmUgdHVwbGUgc3RhdGUgdW5jaGFuZ2VkLjxicj4NCjxicj4NCk9mIGNvdXJzZSwgbWlkZGxlYm94 IGRldmVsb3BlcnMgbWlnaHQgYmUgdGVtcHRlZCB0byB0YWtlIHNob3J0IGN1dHMuIFRoZSBwcm9w b3NhbCBpcyB0byAmcXVvdDtncmVhc2UmcXVvdDsgdGhlIHBhdGguIFNvbWUgaW1wbGVtZW50YXRp b24gd291bGQgb2NjYXNpb25hbGx5IHNlbmQgcHVibGljIHJlc2V0IHBhY2tldHMgd2l0aCBhbiBp bnZhbGlkIHByb29mLiBUaGUgaW5jb3JyZWN0bHkgaW1wbGVtZW50ZWQgbWlkZGxlYm94ZXMgd291 bGQgaW5jb3JyZWN0bHkgZHJvcA0KIHRoZSBjb25uZWN0aW9uLCBhbmQgdGhlaXIgdXNlcnMgd291 bGQgY29tcGxhaW4gb2YgdGhlIHJlc3VsdGluZyBwb29yIHNlcnZpY2UuPGJyPg0KPGJyPg0KLS0g Q2hyaXN0aWFuIEh1aXRlbWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_BN6PR03MB2708BB25912856C162025A4987110BN6PR03MB2708namp_-- From nobody Wed Apr 26 14:32:53 2017 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 0AFE2128B91 for ; Wed, 26 Apr 2017 14:32:52 -0700 (PDT) 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, FREEMAIL_FROM=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=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 3WG8bDNJAl1i for ; Wed, 26 Apr 2017 14:32:50 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 6213D12709D for ; Wed, 26 Apr 2017 14:32:50 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id 88so7526190lfr.0 for ; Wed, 26 Apr 2017 14:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LppfuW0VAIxkiXCcBaGTvpnQ0ngM0NHnlptWr5NqE8k=; b=iVDUpOQsjVXhHRav4JLaUo1x/Qt+rQJ6n+26Y/I+eK6W4pL0Os4jzteU/21IIuhhAs pg+HU4oKlGXuUc5BqjlAs47k4IRgH9vAOE9hNctd1fX9ylm8PJgsob9snqPSRKH0pkKk eocC0s1ghY5IxMHAhmCm8r0hcwIDdapXiGtv+VEHsPax9x0n+5nfzeXlc8cvOtRt2QRd KRBD987Yd3oVCJStim6FuO9JCT5kz/hzVBD/GlmwIAWFLSNkxnCvECUsUv6B0u3jGYsg ISBfqlJ1Bd2Xvc09RTBrcGyduLxvi4W5lPrWy32H0XHaMlrnPvEAByLlDffJhfFz+5GL XuKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LppfuW0VAIxkiXCcBaGTvpnQ0ngM0NHnlptWr5NqE8k=; b=RcEuFjz0zf5qgEKb9N+5/dNmkSxI2WGwIus39yTXY2qyWmP2sybpwUztVHe2ymlWSq 76ah1E/XnLyHoChaM3cYaxY2IXGYn79PUOPpUX23FkfRqa+WYI4EN/3q7Mc35Ei5sLa7 Mq7psGdghQWccd03VN2j0dEnSG0NHNEcn4lGQ09txlfebjIGoujCjxInmR9sWWvdgdjw 3noPgQrpH77F3uvLbQNubYQBLoEXDpD1P2vJ0ToIKVVHR0cqLH5la9hd3zZhaavz+AFa lEG9VD9BtU4vLXPB20wr9aDDQYNZ/s/u8f6c8Xl25NDZCXANyNFNdfc/eFSRllQl/Zu4 NKgQ== X-Gm-Message-State: AN3rC/7t1tzFKCoRV0g3XCv7Txte46s+Kj7eDR0FWsMacqdFAd4RE2od LCxM95awitA8RbxlsDa1kcTkCxmnHQ== X-Received: by 10.25.158.147 with SMTP id h141mr827494lfe.130.1493242368733; Wed, 26 Apr 2017 14:32:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 14:32:48 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 27 Apr 2017 07:32:48 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Christian Huitema Cc: Victor Vasiliev , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 26 Apr 2017 21:32:52 -0000 On 27 April 2017 at 05:35, Christian Huitema wrote: > Of course, middlebox developers might be tempted to take short cuts. The > proposal is to "grease" the path. Some implementation would occasionally > send public reset packets with an invalid proof. The incorrectly implemented > middleboxes would incorrectly drop the connection, and their users would > complain of the resulting poor service. If we grease hard enough, that middlebox will never ship. We have some time to act. It might not be a problem if we start greasing before the middlebox ships support for detecting public reset. That said, the current proposal does not allow the middlebox to verify the public reset. You are talking about a variation that puts the verifier in the clear. The proposal I wrote up has the timeout properties the Victor was sad about. But I'm not sure this is a problem. That only happens if the middlebox that suddenly terminates flows after letting them get established. That's odd behaviour and I'm OK with that leading to bad results. (That is distinct from the middlebox timing out a short keep-alive timer.) From nobody Wed Apr 26 17:27:38 2017 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 03E65128959 for ; Wed, 26 Apr 2017 17:27:37 -0700 (PDT) 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, 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=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 W--2pst364dU for ; Wed, 26 Apr 2017 17:27:35 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 B69561279E5 for ; Wed, 26 Apr 2017 17:27:35 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3R0RMd5002286; Thu, 27 Apr 2017 01:27:24 +0100 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-transfer-encoding : mime-version; s=jan2016.eng; bh=9P3CouHpHXDPSsWmneP6uSOxkatWKVSe8vWZ3Y7A98A=; b=FPxxpwges/aTjLROqJFdlipCdKr24ZvOTFq0vtqofqTPPHHlGj7wcTKpxZy/AJW+0TMT SATpmDxXQ2vx+Dn+rtQSR7JQK3nG0ENLo+S4Wft9D0A+mRXVjDbO2q/Ce40WgYmjZqL/ ycUZBVxfGMgT39JD9qq1kt8LGDRRNoNPteg7dHuynXP+jAhnsikwikgz6xFQuly5VKuO dqC9eFnwoUKVz189UFOTTjkdBzDRCMflct8UKUTNLIjrj+lx/3hnIbfBVODCBgbKlZzS 9Z54Lixvyd98czKl+64XOdEK57Ek4UjiwjS/J9RtfLBNQSp5X+lpJ2BWRGGJGdugUkfh 6g== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2a2ebeh8ax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Apr 2017 01:27:24 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3R0LQw2012037; Wed, 26 Apr 2017 20:27:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2a02gvbwb4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 26 Apr 2017 20:27:23 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Apr 2017 20:27:20 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 26 Apr 2017 20:27:18 -0400 From: "Lubashev, Igor" To: Martin Thomson , Christian Huitema CC: Victor Vasiliev , QUIC WG Subject: RE: Updated Public Reset authentication patch Thread-Topic: Updated Public Reset authentication patch Thread-Index: AQHSunH3ZgpxYHU/tUq6XsEW0RWWx6HW4FCAgACJpICAAOO6gIAACO8AgAAg2QD//+s0kA== Date: Thu, 27 Apr 2017 00:27:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.59] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-26_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704270003 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-26_17:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704270004 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 00:27:37 -0000 VGhlIGlkZWEgdG8gYnVpbGQgYSAiYmV0dGVyLXRoYW4tb24tcGF0aCIgcHJvb2YgaXMgaW50ZXJl c3RpbmcsIGJ1dCBpcyBpdCByZWFsbHkgd29ydGggdGhlIGNvbXBsZXhpdHk/DQoNClRvIGJlIHVz ZWZ1bCwgdGhlIFZlcmlmaWVyIGJpdHMgY2Fubm90IGJlIGluIGNsZWFyIHRleHQgKG9yIHRoaXMg Y29tcGxleGl0eSBkb2VzIG5vdCBidXkgeW91IGFueSBhZGRpdGlvbmFsIHByb3RlY3Rpb24gYWdh aW5zdCBhbiAib24tcGF0aCIgYWR2ZXJzYXJ5KS4NCg0KV2l0aCB0aGUgVmVyaWZpZXIgZW5jcnlw dGVkLCBtaWRkbGVib3hlcyBjYW5ub3QgdXNlIGl0LCBhbmQgYW55IGNvbm5lY3Rpb24gZ29pbmcg dmlhIGEgTkFUIGdldHMgbm8gYWRkaXRpb25hbCBwcm90ZWN0aW9uIGZyb20gYW4gIm9uLXBhdGgi IGFkdmVyc2FyeS4gIFRoYXQncyBuZWFybHkgMTAwJSBvZiBlbmQgdXNlcnMsIGF0IGxlYXN0IGZv ciBJUHY0LCBJIHRoaW5rLg0KDQpXaGVyZSBhbSBJIHdyb25nPw0KDQotIElnb3INCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNiwgMjAxNyA1 OjMzIFBNDQpUbzogQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQpDYzog VmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBRVUlDIFdHIDxxdWljQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFVwZGF0ZWQgUHVibGljIFJlc2V0IGF1dGhlbnRpY2F0aW9uIHBh dGNoDQoNCk9uIDI3IEFwcmlsIDIwMTcgYXQgMDU6MzUsIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0 ZW1hQGh1aXRlbWEubmV0PiB3cm90ZToNCj4gT2YgY291cnNlLCBtaWRkbGVib3ggZGV2ZWxvcGVy cyBtaWdodCBiZSB0ZW1wdGVkIHRvIHRha2Ugc2hvcnQgY3V0cy4gDQo+IFRoZSBwcm9wb3NhbCBp cyB0byAiZ3JlYXNlIiB0aGUgcGF0aC4gU29tZSBpbXBsZW1lbnRhdGlvbiB3b3VsZCANCj4gb2Nj YXNpb25hbGx5IHNlbmQgcHVibGljIHJlc2V0IHBhY2tldHMgd2l0aCBhbiBpbnZhbGlkIHByb29m LiBUaGUgDQo+IGluY29ycmVjdGx5IGltcGxlbWVudGVkIG1pZGRsZWJveGVzIHdvdWxkIGluY29y cmVjdGx5IGRyb3AgdGhlIA0KPiBjb25uZWN0aW9uLCBhbmQgdGhlaXIgdXNlcnMgd291bGQgY29t cGxhaW4gb2YgdGhlIHJlc3VsdGluZyBwb29yIHNlcnZpY2UuDQoNCklmIHdlIGdyZWFzZSBoYXJk IGVub3VnaCwgdGhhdCBtaWRkbGVib3ggd2lsbCBuZXZlciBzaGlwLiAgV2UgaGF2ZSBzb21lIHRp bWUgdG8gYWN0LiBJdCBtaWdodCBub3QgYmUgYSBwcm9ibGVtIGlmIHdlIHN0YXJ0IGdyZWFzaW5n IGJlZm9yZSB0aGUgbWlkZGxlYm94IHNoaXBzIHN1cHBvcnQgZm9yIGRldGVjdGluZyBwdWJsaWMg cmVzZXQuDQoNClRoYXQgc2FpZCwgdGhlIGN1cnJlbnQgcHJvcG9zYWwgZG9lcyBub3QgYWxsb3cg dGhlIG1pZGRsZWJveCB0byB2ZXJpZnkgdGhlIHB1YmxpYyByZXNldC4gIFlvdSBhcmUgdGFsa2lu ZyBhYm91dCBhIHZhcmlhdGlvbiB0aGF0IHB1dHMgdGhlIHZlcmlmaWVyIGluIHRoZSBjbGVhci4N Cg0KVGhlIHByb3Bvc2FsIEkgd3JvdGUgdXAgaGFzIHRoZSB0aW1lb3V0IHByb3BlcnRpZXMgdGhl IFZpY3RvciB3YXMgc2FkIGFib3V0LiAgQnV0IEknbSBub3Qgc3VyZSB0aGlzIGlzIGEgcHJvYmxl bS4gIFRoYXQgb25seSBoYXBwZW5zIGlmIHRoZSBtaWRkbGVib3ggdGhhdCBzdWRkZW5seSB0ZXJt aW5hdGVzIGZsb3dzIGFmdGVyIGxldHRpbmcgdGhlbSBnZXQgZXN0YWJsaXNoZWQuICBUaGF0J3Mg b2RkIGJlaGF2aW91ciBhbmQgSSdtIE9LIHdpdGggdGhhdCBsZWFkaW5nIHRvIGJhZCByZXN1bHRz LiAgKFRoYXQgaXMgZGlzdGluY3QgZnJvbSB0aGUgbWlkZGxlYm94IHRpbWluZyBvdXQgYSBzaG9y dCBrZWVwLWFsaXZlIHRpbWVyLikNCg0K From nobody Wed Apr 26 17:37:43 2017 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 77CA2129443 for ; Wed, 26 Apr 2017 17:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 7h1lKvGzSf1K for ; Wed, 26 Apr 2017 17:37:39 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 C242A129421 for ; Wed, 26 Apr 2017 17:37:39 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id p143so4406391yba.2 for ; Wed, 26 Apr 2017 17:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r7HfDwL5p03O9rXHETtNer9znUTKF2Dg6aHu5fOGBMw=; b=b69GCMyiPlm35CHqirQICtZm+xnWWLddnMnIarypghkpYv9oGye58XlFyNaJi5ML3N qMg9n4DvjbEcHmRh57qf7fzN2nU7evQ7gRmtjac+pvjWlmzCUShSdL52nfcf5wsqLX6n McjRME5mHC/2Anb6X0HO3VVhbUI5rVq/nCPR6Q/YwhVs1mJhRlxwdUEfBCbA14joWHFa 2sva0vzJjpiXvzkqiYOTXU6cTJFykshbiYPy+GKyWIOVMrDTLkyFOYtBnAKQ8OePxatx mJeZ3ky0bLEsz18YBe7a6Jbw82Lxc+qSppdihr2pcGkUXKXenW4ExI0z6i60NcZ90VUR hQJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r7HfDwL5p03O9rXHETtNer9znUTKF2Dg6aHu5fOGBMw=; b=K+jfV/fwRwk2zJIvDgJ7meycqVfom2oayDxOFSb/uNTv8bBgpG3DM5qQWVuFpJ91de j2/i+o5dOfzdeHtEZNI7DLQZWNVhlhPjSMI5hhp7DcxzBCkyp2hc1t/yo1fUwh4+T6pj /5Dv+YKGaXwC9zlYbnRoDDJCAb1hwj4mMQDN5rP5vkh4YijmjhhwCUALRPOmJsEZ9kIm atbJP9wYw7EFdMhDXZl1MlEtAJussdg+WhSiQbxbZPJ15LusyzqRvrMNDSTDDuLppOrX 9aLgewqM51+62dDdf397gi4NIBrRGPUgOFa8tSFMpPPP7AbSMZVBN8eQyCL9VBHY6V5R 1wKA== X-Gm-Message-State: AN3rC/7urd2Ouoz1ygJw4t5xSg+bME5eTitdCiIGSaQlDtahTMlSIubd vISGPS4eMRJhYDwfmpE0XFUuPwAsmMzN X-Received: by 10.37.161.196 with SMTP id a62mr2337169ybi.9.1493253458999; Wed, 26 Apr 2017 17:37:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 26 Apr 2017 17:36:58 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 26 Apr 2017 17:36:58 -0700 Message-ID: Subject: Re: Updated Public Reset authentication patch To: "Lubashev, Igor" Cc: Martin Thomson , Christian Huitema , Victor Vasiliev , QUIC WG Content-Type: multipart/alternative; boundary=f403045c5632fbf402054e1b2971 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 00:37:41 -0000 --f403045c5632fbf402054e1b2971 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 26, 2017 at 5:27 PM, Lubashev, Igor wrote: > The idea to build a "better-than-on-path" proof is interesting, but is it > really worth the complexity? > > To be useful, the Verifier bits cannot be in clear text (or this > complexity does not buy you any additional protection against an "on-path" > adversary). > > With the Verifier encrypted, middleboxes cannot use it, and any connection > going via a NAT gets no additional protection from an "on-path" adversary. > That's nearly 100% of end users, at least for IPv4, I think. > > Where am I wrong? > The Verifier bits need not be in cleartext. They are the preimage for a hash provided during connection setup and only published when the public reset is sent. -Ekr > > - Igor > > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Wednesday, April 26, 2017 5:33 PM > To: Christian Huitema > Cc: Victor Vasiliev ; QUIC WG > Subject: Re: Updated Public Reset authentication patch > > On 27 April 2017 at 05:35, Christian Huitema wrote: > > Of course, middlebox developers might be tempted to take short cuts. > > The proposal is to "grease" the path. Some implementation would > > occasionally send public reset packets with an invalid proof. The > > incorrectly implemented middleboxes would incorrectly drop the > > connection, and their users would complain of the resulting poor service. > > If we grease hard enough, that middlebox will never ship. We have some > time to act. It might not be a problem if we start greasing before the > middlebox ships support for detecting public reset. > > That said, the current proposal does not allow the middlebox to verify the > public reset. You are talking about a variation that puts the verifier in > the clear. > > The proposal I wrote up has the timeout properties the Victor was sad > about. But I'm not sure this is a problem. That only happens if the > middlebox that suddenly terminates flows after letting them get > established. That's odd behaviour and I'm OK with that leading to bad > results. (That is distinct from the middlebox timing out a short > keep-alive timer.) > > --f403045c5632fbf402054e1b2971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 26, 2017 at 5:27 PM, Lubashev, Igor <<= a href=3D"mailto:ilubashe@akamai.com" target=3D"_blank">ilubashe@akamai.com= > wrote:
The idea to build = a "better-than-on-path" proof is interesting, but is it really wo= rth the complexity?

To be useful, the Verifier bits cannot be in clear text (or this complexity= does not buy you any additional protection against an "on-path" = adversary).

With the Verifier encrypted, middleboxes cannot use it, and any connection = going via a NAT gets no additional protection from an "on-path" a= dversary.=C2=A0 That's nearly 100% of end users, at least for IPv4, I t= hink.

Where am I wrong?

The Verifier bits nee= d not be in cleartext. They are the preimage for a hash provided during
connection setup and only published when the public reset is sent.

-Ekr
=C2=A0

- Igor


-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: Wednesday, April 26, 2017 5:33 PM
To: Christian Huitema <huitema@hu= itema.net>
Cc: Victor Vasiliev <vasilvv@googl= e.com>; QUIC WG <quic@ietf.org>
Subject: Re: Updated Public Reset authentication patch

On 27 April 2017 at 05:35, C= hristian Huitema <huitema@huitema= .net> wrote:
> Of course, middlebox developers might be tempted to take short cuts. > The proposal is to "grease" the path. Some implementation wo= uld
> occasionally send public reset packets with an invalid proof. The
> incorrectly implemented middleboxes would incorrectly drop the
> connection, and their users would complain of the resulting poor servi= ce.

If we grease hard enough, that middlebox will never ship.=C2=A0 We have som= e time to act. It might not be a problem if we start greasing before the mi= ddlebox ships support for detecting public reset.

That said, the current proposal does not allow the middlebox to verify the = public reset.=C2=A0 You are talking about a variation that puts the verifie= r in the clear.

The proposal I wrote up has the timeout properties the Victor was sad about= .=C2=A0 But I'm not sure this is a problem.=C2=A0 That only happens if = the middlebox that suddenly terminates flows after letting them get establi= shed.=C2=A0 That's odd behaviour and I'm OK with that leading to ba= d results.=C2=A0 (That is distinct from the middlebox timing out a short ke= ep-alive timer.)


--f403045c5632fbf402054e1b2971-- From nobody Wed Apr 26 18:01:26 2017 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 C0A94129443 for ; Wed, 26 Apr 2017 18:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 uRkZEhYQJ6qh for ; Wed, 26 Apr 2017 18:01:23 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 045ED12940F for ; Wed, 26 Apr 2017 18:01:22 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id 75so9194224lfs.2 for ; Wed, 26 Apr 2017 18:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QpDsXfAYxlq5SmtDJtJ+BTqDrrf8z/HAQoqIDnBaoJM=; b=qnOsEQ0bns0+2lSkcX+cMPjnTqgMgZeonBm2UBZG6iHIx5ZunsBFfDYIEeQLWBsfAP LTvRKTJEDtjHx/lGi5g55uneIU6hATyDGjHZz6/2fvt78rdfvFyXHlSTABQO6YRPErm1 e++sypilg8nvLLe3hediQMYi7AMDscD1KAHJIRZOKC7s7xTd0k1DOzakT5DMuhRc79BT 4nSk+gc5BNmsDteGmcOGOQ7tHAVa/xts/iKfLfQbHsAvJupbZNPp4uqYoig/1qQpgb0o /7lexWjLdsS4Bnj3bj98bBL08AD/5CFbE4QWYJz1D8VPwYaYJQZ3QaZxi5pxyqvUL/Oe /a8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QpDsXfAYxlq5SmtDJtJ+BTqDrrf8z/HAQoqIDnBaoJM=; b=nzsMQiTIjviD6uW/zB1wIHTAmZCKb15zQbhkBKfZ8/tI0wBVQ312noZfB3JFInwtpd id9YNBRHM4rEZ7w7tnsozlOK8ZkOtNuu27K803hkuCMIpC89t2CcCLOOKbDHHhx09aPa tGNADsRaSoRtsEwU1iaLS2JfzZdNQ/Y4EU3sOXyX54D1y48cqcfNnpnhGWiHluQ5U3iQ hA8+lrPlnxJsxFlh5NvjB2Zheh1I7nA1CVNBdJr7xSitfEHG78xIwGb0GKCWRMluM8AM eNv5EBOUsvUfod84JERoYUzqXGsGxyCRbQYIseo0SKKtm97SKAvEnfMXta38A4HnRuqC sSFQ== X-Gm-Message-State: AN3rC/43HId6W5IaXOXsnOdbKws834duXLezIwTh0kK7GldsF/LL0QxU tI72p9KMNqGbrI73difh12TjCJ7UMvnb X-Received: by 10.46.0.23 with SMTP id 23mr1721lja.33.1493254881335; Wed, 26 Apr 2017 18:01:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 18:01:20 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 27 Apr 2017 11:01:20 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: "Lubashev, Igor" Cc: Christian Huitema , Victor Vasiliev , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 01:01:25 -0000 On 27 April 2017 at 10:27, Lubashev, Igor wrote: > The idea to build a "better-than-on-path" proof is interesting, but is it really worth the complexity? ekr answered the other questions, but I want to use this as an opportunity to raise a point that keeps getting lost. Public reset is a way to kill the connection, not the path. Yes, it's obvious that a valid public reset also means that the path is going away, but conflating the two is a mistake, even in the absence of multipath. When the issue of silent close was raised in Chicago, we collectively made the same category error. The important consideration here is whether we believe that it is necessary for the path to learn that the path will no longer be used. If we believe that this is a necessary signal, then we need to create those signals. I am increasingly of the opinion that overloading public reset is not an appropriate way to signal to the path, but I am willing to entertain the notion that I'm wrong. I'd like to suggest that we adopt the following approach: 1. determine whether we need an end-to-path signal for termination; 2. if needed, design that signal; then 3. if appropriate, merge that signal with public reset. If we don't start disentangling issues, this is going to take a very long time. From nobody Wed Apr 26 19:48:52 2017 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 847E81294E0 for ; Wed, 26 Apr 2017 19:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 Kupgbj6Ku9DJ for ; Wed, 26 Apr 2017 19:48:38 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 CE4F1129577 for ; Wed, 26 Apr 2017 19:48:38 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3R2ghTg022267; Thu, 27 Apr 2017 03:48:30 +0100 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 : mime-version; s=jan2016.eng; bh=LOmT5uRcqQh7T0wSpye3M5PPPx7uJB0QTfB3nDwgG28=; b=gb0MR5oMzMDUVMWgDgWhsGIQLizSyZBEc7r0GXkzyC1zUweiHF4K2E3jxGPtbay4DBu3 Y+Z7YHIQASIw1VDmr4FE3VlUEPFC280AsATJ7+Si5Y8Irway5hPIFH6X+npNjZkwwvlQ JVo3Mip6ubRrLYchdOGanNUtIaAiS29MBuitrRSnCqtfh2UFY1A/UBj8Z+qQy7kU+dNh q2Hy/sLYeLNBqIYPpTBkj193prOdf3Wly28TOl3+r0cpq+PUOLnPaZWRmwF6fTMTjGB6 TqphLeL4feqPnNFpexHZHzTik5SJVqOpjxb20W4CCa76HIAVKqUPGA3zsRwKZ74O2/ti aA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2a2ebghv2n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Apr 2017 03:48:30 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3R2ehtC005726; Wed, 26 Apr 2017 22:48:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a02gw48jg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 26 Apr 2017 22:48:29 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Apr 2017 22:48:27 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Apr 2017 22:48:27 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 26 Apr 2017 22:48:27 -0400 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" CC: "quic@ietf.org" , "huitema@huitema.net" , "vasilvv@google.com" Subject: RE: Updated Public Reset authentication patch Thread-Topic: Updated Public Reset authentication patch Thread-Index: AQHSunH3ZgpxYHU/tUq6XsEW0RWWx6HW4FCAgACJpICAAOO6gIAACO8AgAAg2QD//+s0kIAATxAA///a3ys= Date: Thu, 27 Apr 2017 02:48:26 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_e220d91fe32247c9b7a33c6e30990972usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-27_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704270033 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-27_02:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704270033 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 02:48:40 -0000 --_000_e220d91fe32247c9b7a33c6e30990972usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ekr, thanks for the explanation how the verifier works. I think it is still worthwhile to answer whether the complexity of a 'bette= r-than-on-path' proof for either path-reset or connection-reset signal is w= orth it. An on-path attacker is able to interfere with the connection hands= hake easily, so is it worth it trying to make it that much harder for him t= o force a reset (of a path or a connection)? As for path-reset as separate from connection-reset, it does make a lot of = sense. Moreover, a path element may wish to signal not only that "this path= is dead" but also "this path is about to go dead" to induce it to switch t= o a different path (wifi <-> cell). To make this most general: a) path-reset signal should be public (it is to be generated by on-path ele= ments, not necessarily end points) b) It can be intercepted by other path elements (a tethering middle box can= switch its Internet attachment) c) Upon receipt of a path-reset, a statefull middle box that has no alterna= tive path will reset the connection state and forward the path-reset signal= . d) Upon receipt, an endpoint that has no alternative path available will tr= eat this path-reset signal as connection-reset. - Igor -----Original Message----- From: Martin Thomson [martin.thomson@gmail.com] Received: Wednesday, 26 Apr 2017, 9:01PM To: Lubashev, Igor [ilubashe@akamai.com] CC: Christian Huitema [huitema@huitema.net]; Victor Vasiliev [vasilvv@googl= e.com]; QUIC WG [quic@ietf.org] Subject: Re: Updated Public Reset authentication patch On 27 April 2017 at 10:27, Lubashev, Igor wrote: > The idea to build a "better-than-on-path" proof is interesting, but is it= really worth the complexity? ekr answered the other questions, but I want to use this as an opportunity to raise a point that keeps getting lost. Public reset is a way to kill the connection, not the path. Yes, it's obvious that a valid public reset also means that the path is going away, but conflating the two is a mistake, even in the absence of multipath. When the issue of silent close was raised in Chicago, we collectively made the same category error. The important consideration here is whether we believe that it is necessary for the path to learn that the path will no longer be used. If we believe that this is a necessary signal, then we need to create those signals. I am increasingly of the opinion that overloading public reset is not an appropriate way to signal to the path, but I am willing to entertain the notion that I'm wrong. I'd like to suggest that we adopt the following approach: 1. determine whether we need an end-to-path signal for termination; 2. if needed, design that signal; then 3. if appropriate, merge that signal with public reset. If we don't start disentangling issues, this is going to take a very long t= ime. --_000_e220d91fe32247c9b7a33c6e30990972usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
ekr, thanks for the explanation how the verifier works.
I think it is still worthwhile to answer whether the complexity of a 'bette= r-than-on-path' proof for either path-reset or connection-reset signal is w= orth it. An on-path attacker is able to interfere with the connection hands= hake easily, so is it worth it trying to make it that much harder for him to force a reset (of a path or a conne= ction)?


As for path-reset as separate from connection-reset, it does make a lot of = sense. Moreover, a path element may wish to signal not only that "this= path is dead" but also "this path is about to go dead" to i= nduce it to switch to a different path (wifi <-> cell).

To make this most general:
a) path-reset signal should be public (it is to be generated by on-path ele= ments, not necessarily end points)
b) It can be intercepted by other path elements (a tethering middle box can= switch its Internet attachment)
c) Upon receipt of a path-reset, a statefull middle box that has no alterna= tive path will reset the connection state and forward the path-reset signal= .
d) Upon receipt, an endpoint that has no alternative path available will tr= eat this path-reset signal as connection-reset.

- Igor

-----Original Message-----
From: Martin Thomson [martin.thomson@gmail.com]
Received: Wednesday, 26 Apr 2017, 9:01PM
To: Lubashev, Igor [ilubashe@akamai.com]
CC: Christian Huitema [huitema@huitema.net]; Victor Vasiliev [vasilv= v@google.com]; QUIC WG [quic@ietf.org]
Subject: Re: Updated Public Reset authentication patch

On 27 April 2017 at 10:27, Lubashev, Igor <ilub= ashe@akamai.com> wrote:
> The idea to build a "better-than-on-path" proof is interesti= ng, but is it really worth the complexity?

ekr answered the other questions, but I want to use this as an
opportunity to raise a point that keeps getting lost.

Public reset is a way to kill the connection, not the path.  Yes, it's=
obvious that a valid public reset also means that the path is going
away, but conflating the two is a mistake, even in the absence of
multipath.

When the issue of silent close was raised in Chicago, we collectively
made the same category error.  The important consideration here is
whether we believe that it is necessary for the path to learn that the
path will no longer be used.  If we believe that this is a necessary signal, then we need to create those signals.

I am increasingly of the opinion that overloading public reset is not
an appropriate way to signal to the path, but I am willing to
entertain the notion that I'm wrong.  I'd like to suggest that we
adopt the following approach:

1. determine whether we need an end-to-path signal for termination;
2. if needed, design that signal; then
3. if appropriate, merge that signal with public reset.

If we don't start disentangling issues, this is going to take a very long t= ime.
 --_000_e220d91fe32247c9b7a33c6e30990972usma1exdag1mb5msgcorpak_-- From nobody Wed Apr 26 20:31:43 2017 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 245F912951C for ; Wed, 26 Apr 2017 20:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 MPNUQA8zQQyz for ; Wed, 26 Apr 2017 20:31:40 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 73BCE12950C for ; Wed, 26 Apr 2017 20:31:40 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id 88so10414522lfr.0 for ; Wed, 26 Apr 2017 20:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mBMGXvPBLimCJS2LWntNQpglnQGPWOaodR628uVkh+o=; b=sZpWl2Z8Y/2TWUxl2fx4gzHFiBMqL6RHIa+TDiYF6q3DVZa257jiW8K1LqIZfxZHuS iSs/LS5XOpfoOXft1CjYxBt5/VcPr4mmwwk6h0qi6L8DLstCx3/s0LCp/S/2R08h7B11 N5FAqD89EPvp5cB3oB57DYOMhH1YE1rKGVdyIS/6FbHTfdhq8lhAi3Nw1buHpBwq4xYj myUpKajjKEhM6ZLw86JmzFF5vly7GzkWwCkKgFCej1sjCJ8ZCnqIN6JRi1MT1E8m41j+ qiyxs5qBRNR/5+xJMf5iKYHMT5DqFEWcYeSlRxHuj+kh7Dhk4MsRSp8rNuVLDiVdadH8 Q6aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mBMGXvPBLimCJS2LWntNQpglnQGPWOaodR628uVkh+o=; b=ulPMrcasOvvN+E0v61btHCtIj3mEPXVgsjwsaA0keDom28l1IpOscEy02bf5HqnOpr XvQJ4H+SmkhgzCP3PxzO/hWXx4gdbxJ82ea1tm8Dmm20w+2dS7cyWbuMSCcVfVRoQjy2 ns2W2ZhDd+v1R4aH9zf3dLQhwSY4YVgkLVehNWPfoA9EJ4S4YJM3fDCm2YIdf8EJbi6j az9e2PnSmFuYwoi+YjyOt4jujTFNKS76Lo6gIM0gG8ubcTc1kP1suSvQM/CcRG9MAsGk N6iQzps0xUblOvakSr/BwiagdkWo4Z0aGvStX9Xqitt0iGuQdcCNzJX/kIFEMja7wP1s eUIg== X-Gm-Message-State: AN3rC/6qyYbFUywrheITesraC1kI32bs9UbusspPj897+NKvN5tjmpfp IKbAR68kKmThCVFDMYcMm+wlsGCjVA== X-Received: by 10.46.8.26 with SMTP id 26mr1204490lji.128.1493263898769; Wed, 26 Apr 2017 20:31:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 20:31:38 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 27 Apr 2017 13:31:38 +1000 Message-ID: Subject: Re: Error code cleanup To: "Roy T. Fielding" Cc: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 03:31:42 -0000 On 25 April 2017 at 04:05, Roy T. Fielding wrote: > Assuming we are only talking about transport codes, I would expect > > * parameter too long I've subsumed this in what I'm proposing be called FRAME_FORMAT_ERROR. I don't see a lot of value in being more precise given that the action is the same: the other side is busted somehow. > * unrecognized application > > for quic recipients that might detect multiple app protocols; TLS handles this for us. RFC 7301 defines a no_application_protocol alert, which QUIC will use. > * timeout before application-level > * timeout while decrypting I'm going to argue that these don't need to be signaled over the wire. We expect that applications will have to deal with these annoying error conditions, but the other side doesn't need to be informed about these specific conditions. An endpoint that wants to signal something can use one of the more generic codes. Happy to open issues for those errors on which we don't agree, I'm not militant about any of this stuff, I'm just looking to make a solid start. From nobody Wed Apr 26 20:42:56 2017 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 E1360127735 for ; Wed, 26 Apr 2017 20:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 3BNRJ5QBwtYI for ; Wed, 26 Apr 2017 20:42:53 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 A956F12426E for ; Wed, 26 Apr 2017 20:42:52 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id 75so10387312lfs.2 for ; Wed, 26 Apr 2017 20:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YIJ1zXG3pEmJv+5rvlfmTmFSVpw2cKwMVgK8y07vcQw=; b=uhcEQ+zpvFiUtRgUIUWb7TJ587zjCQndLTaCcAD46d8VuDXEe9WGFPKAbG7if82Xr1 83+TKzNfUqfr3MK0hf7G3qojsZmAYg4gxPZzdfb7ajl6dHJJleyfgO5TUP0bG3l1lpJz hQR1HjV7eaWvcdREr+cMAdkP4F8XJbiZW3D6gVYqfmw8HjqsscV0xKcldC+n/qjbigTn 0HKPamY2EX9Qr4SDnwFaWCIALi3uwJn82Hw6P95q01MO2JSJQrgu6UD2NgjaT3YkhOYU OfGfNslzL2c9peOSmFDKIraSbn/Ufk9MseUS+s823wv21OLKnbTb9vaqJpe7eFwZHDGZ l0qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YIJ1zXG3pEmJv+5rvlfmTmFSVpw2cKwMVgK8y07vcQw=; b=sFonrvKnZT9/wCSjAV5XAcwgBNGqCD+l3UL6/fm+rMH5a3xuGC9cIuJ34UiQzr4tCJ 2PUk4MJplLUD7pJzXBgcLL/GzuEoTephfLulvLyPqyOfvwcsDAhV9viw6BEwDIcemO3o ag8AJxRPVh1IDirYDrZGtDUQI+NyKZBoE1zrP0pAD76PvFUar1pz3uYZD9tU/fmTTegR +9trFnDImpf+7w8jqLUq7pdvRR0bsexdkV6j/Vq57x29vYAjwk5f9NMi/idXHiN627Ke +O7H+6A5WUhGQXXSSxCeB2kErXl/8PGSpSDJNPzgwXl1aB/rwCoftNuyKcuaOo2XTbb0 IcRA== X-Gm-Message-State: AN3rC/65VwbsxOhk7QxRd4YaLjqkui8KTVdbUIz7uMt5okW4m0C3MgLA MjVH4rbI/65Gvr/0Qou4dirATdkbizUXiGU= X-Received: by 10.46.0.23 with SMTP id 23mr131424lja.33.1493264570658; Wed, 26 Apr 2017 20:42:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 20:42:49 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 27 Apr 2017 13:42:49 +1000 Message-ID: Subject: Re: Error code cleanup To: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 03:42:55 -0000 Top posting because I now have the PR: https://github.com/quicwg/base-drafts/pull/467 Please take a look, I don't plan to wait very long before merging this one. On 24 April 2017 at 14:41, Martin Thomson wrote: > The TLS and HTTP drafts now have some nice error code lists. And by > nice I mean short and precise. Each error code is justified and most > either point to a distinct reaction or a distinct cause (the latter > I'm less enthusiastic about with HTTP, but that is just a quibble). > > I've been working on fixing error codes for the transport. > > Here's what I'm going to propose for the breakdown of error codes in > the transport piece. I won't name these yet, there are reasons to > parallel codes in the HTTP spec. Some of these might be broken down > finer into codes that identify specific causes, but I might push back > on doing that too aggressively. > > I have 13 codes here. TLS has 3, HTTP has 17 (which I think is too > high, but what do I know). We might want to discuss reducing the size > of the error code space a little at some point. > > I went through the existing codes and all are either invalid or > covered here - as far as I can see. Clearly, this is still early > enough that there might be new codes added, but I think that the above > list is close enough. > > I plan to write this up during this week. I'm sharing this in the > hopes that someone might help by correcting any mistakes that I've > made. > > > # internal errors > > * this error was my fault, probably a bug or resource issue on my end > that means I can't continue > > I don't think that we want to highlight the difference between > different internal errors here lest we provide instructions on how to > trigger DoS or bugs. Having just one code in this category seems > right. > > # errors that aren't errors > > * this isn't an error (in case we use one of the error messages to signal close) > > * this isn't an error, you asked me to generate this error (for the > case where RST_STREAM causes RST_STREAM to be sent, or for the > proposed DISINTEREST frame) > > * this isn't an error, I just don't want this stream any more (the > general form of the cancellation request) > > # errors that are protocol violations > > * you did something wrong, but nothing specific was appropriate (this > is a general catch-all error code for use when other protocol > violations aren't appropriate) > > * you send me more data than I allowed (flow control) > > * you opened a stream before I said you could use it (streams) > > * you sent a frame on a stream that was in a state that doesn't allow that > > * you sent data on a stream past the final data offset, or you seem to > have moved the final offset > > * you sent a badly-formatted frame (this includes things that have bad > lengths primarily; I think that includes an empty STREAM with no FIN > flag; the range of errors here doesn't really seem to justify an error > code per frame type) > > * your transport parameters were invalid > > * the version negotiation fields in your transport parameters don't > match with my understanding of what we did during version negotiation, > IT'S AN ATTACK! (this could have been part of transport parameter > validation, but the fact that this is an attack rather than just a > screwup is a good reason to use a different code) > > # errors that aren't protocol issues violations, but they need a signal anyway > > * enhance your calm (this is the name we used in h2 to signal all > sorts of cases where an endpoint could tell the other side to cool off > a little, this usually includes activity that might look like a DoS > attack, but it might also be sent to clients who are behaving > themselves if the server is feeling under the weather) > > # errors that I don't think need codes (yet) > > * receiving a packet that contains no payload, even if it can be > authenticated (implementations should just discard these without even > trying to decrypt them) > > * an attempt to close stream 0 (use the generic code) > > * receiving a packet that is too big (we haven't actually got any text > imposing limits on packet size; in theory the maximum size remains at > the UDP maximum; we do have issue #383 which we to add a code if we > decide to do anything) From nobody Wed Apr 26 20:46:44 2017 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 33A7012426E for ; Wed, 26 Apr 2017 20:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 UWyPD8m8iQH3 for ; Wed, 26 Apr 2017 20:46:41 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 6E12A129AD5 for ; Wed, 26 Apr 2017 20:46:41 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id t144so10499501lff.1 for ; Wed, 26 Apr 2017 20:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yypgwl+wyjLd4Er9NfZ3vgEkE3s46AW+GYNmsUG4rz0=; b=iHIZK0RMAf4xbPZX45iW0L6WzOHfzt+BC4icbTOn7OnYMKtcLK2moWZm4ePqvrtRk3 V3jx4/9Nt2fG/VAxzuMkCsj4/z5fLCTT7UEhaQiUocio/+aGfa4YjJeVwqoz/T1hK+iQ n5j4WIyIqSnSmo3uy9gN/ylo68Kn1Mtpn3HjkLvgAclNNTtu/GjYik6IKHSpZiKpiy8l tesvYxKP2LPUj22KuQzmEjShRvzgE81KHVOs7z8Wrh+iCbAUbJ3Ovst6FMpZh4rCDC09 iUJsdxkkXzUjJYRG38xvWBWwwLJGY2ZX70bvJ4RYXuZdDiL7w0/qM4WA5L1lyx0Q1JAB pNCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yypgwl+wyjLd4Er9NfZ3vgEkE3s46AW+GYNmsUG4rz0=; b=p138LHRmWPm6TOq2G83sPBz3doMN0C6zRJfc2amyj5AVmHxz0FxL9L9wmJ1A4XbT6o fVbdHTqACkPWjkhPDu9NgdXSbnO+f6sS3dbqkOSH1cUX84D4mjwJIe0XYarZhnLaKUgs d1WsuK7Y0I4luGosU+5PSA2W3KSvGR5n4vXxGWsUXWoXcDDlT+RuVAc56fIoJPleEkF6 psG8yVt+6ux+Ubk7Lo/vtIAEfxuPI8vwKy04H0p0PK5v5oQlFJjyd/COERk7PnY4/r/H gBHfywZunI/3dy69DcuJcrPjPPv0QZ8AXP05J5YFqt44uOVvKMssLB8i9Ma1uHQWpA3z OAgQ== X-Gm-Message-State: AN3rC/6GRQS6pvsnPdcoHBFi83FM2kSqFTUgjutBD18P539HbWgntpD4 z5aE6MNyFjGONHBubw0YuAFvNrDAOTiF X-Received: by 10.46.14.10 with SMTP id 10mr1234331ljo.22.1493264799699; Wed, 26 Apr 2017 20:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 20:46:38 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 27 Apr 2017 13:46:38 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: "Lubashev, Igor" Cc: "quic@ietf.org" , "huitema@huitema.net" , "vasilvv@google.com" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 03:46:43 -0000 It sounds like you want to generate a proposal for this. ICMP unreachable might work for this purpose (to Victor's earlier point). Which suggests that the same considerations as PMTUD also apply. On 27 April 2017 at 12:48, Lubashev, Igor wrote: > ekr, thanks for the explanation how the verifier works. > > I think it is still worthwhile to answer whether the complexity of a > 'better-than-on-path' proof for either path-reset or connection-reset signal > is worth it. An on-path attacker is able to interfere with the connection > handshake easily, so is it worth it trying to make it that much harder for > him to force a reset (of a path or a connection)? > > > As for path-reset as separate from connection-reset, it does make a lot of > sense. Moreover, a path element may wish to signal not only that "this path > is dead" but also "this path is about to go dead" to induce it to switch to > a different path (wifi <-> cell). > > To make this most general: > a) path-reset signal should be public (it is to be generated by on-path > elements, not necessarily end points) > b) It can be intercepted by other path elements (a tethering middle box can > switch its Internet attachment) > c) Upon receipt of a path-reset, a statefull middle box that has no > alternative path will reset the connection state and forward the path-reset > signal. > d) Upon receipt, an endpoint that has no alternative path available will > treat this path-reset signal as connection-reset. > > - Igor > > -----Original Message----- > From: Martin Thomson [martin.thomson@gmail.com] > Received: Wednesday, 26 Apr 2017, 9:01PM > To: Lubashev, Igor [ilubashe@akamai.com] > CC: Christian Huitema [huitema@huitema.net]; Victor Vasiliev > [vasilvv@google.com]; QUIC WG [quic@ietf.org] > Subject: Re: Updated Public Reset authentication patch > > On 27 April 2017 at 10:27, Lubashev, Igor wrote: >> The idea to build a "better-than-on-path" proof is interesting, but is it >> really worth the complexity? > > ekr answered the other questions, but I want to use this as an > opportunity to raise a point that keeps getting lost. > > Public reset is a way to kill the connection, not the path. Yes, it's > obvious that a valid public reset also means that the path is going > away, but conflating the two is a mistake, even in the absence of > multipath. > > When the issue of silent close was raised in Chicago, we collectively > made the same category error. The important consideration here is > whether we believe that it is necessary for the path to learn that the > path will no longer be used. If we believe that this is a necessary > signal, then we need to create those signals. > > I am increasingly of the opinion that overloading public reset is not > an appropriate way to signal to the path, but I am willing to > entertain the notion that I'm wrong. I'd like to suggest that we > adopt the following approach: > > 1. determine whether we need an end-to-path signal for termination; > 2. if needed, design that signal; then > 3. if appropriate, merge that signal with public reset. > > If we don't start disentangling issues, this is going to take a very long > time. From nobody Wed Apr 26 21:28:13 2017 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 0D63C13148B for ; Wed, 26 Apr 2017 21:28:12 -0700 (PDT) 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 7Pk2c6BsW6ml for ; Wed, 26 Apr 2017 21:28:10 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 B005C12F29A for ; Wed, 26 Apr 2017 21:28:10 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d3b2H-00056g-5H for quic@ietf.org; Thu, 27 Apr 2017 06:28:10 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d3b2C-0008CL-1b for quic@ietf.org; Thu, 27 Apr 2017 00:28:08 -0400 Received: (qmail 7652 invoked from network); 27 Apr 2017 04:28:02 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.199]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Apr 2017 04:28:02 -0000 To: Martin Thomson References: Cc: Victor Vasiliev , QUIC WG From: Christian Huitema Message-ID: Date: Wed, 26 Apr 2017 21:27:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Updated Public Reset authentication patch X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49Nd7AN7sevoJn7jQtAGeOfdTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqPMljrHFxek34XmYC9JRIHRcOb18WfxGyg6Om6u4YYmytIddC7sWmGAs/5 gsIAfmE5hjoyEb9Oq0NWpyO3vrfYvxyiiU8VkSVtodr6VFoM0T3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBCDRZgQnFYkq0SOLrmvxpF3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0cv6wiJXQ R6MCPUI7r7Qk2LbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/sV/ccPPAIzwUs9bYOpC55y/BVfPBiplCJHw ZdNGGoX1GyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+YzaHXGDtmr6LoB+LyIJrZ6Ke72V7y3QDXL8JTpxprEN X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 04:28:12 -0000 On 4/26/2017 2:32 PM, Martin Thomson wrote: > On 27 April 2017 at 05:35, Christian Huitema wrot= e: >> Of course, middlebox developers might be tempted to take short cuts. T= he >> proposal is to "grease" the path. Some implementation would occasional= ly >> send public reset packets with an invalid proof. The incorrectly imple= mented >> middleboxes would incorrectly drop the connection, and their users wou= ld >> complain of the resulting poor service. > If we grease hard enough, that middlebox will never ship. We have > some time to act. It might not be a problem if we start greasing > before the middlebox ships support for detecting public reset. Yes. Whether any middlebox will ship with that design is of course anyone's guess. > That said, the current proposal does not allow the middlebox to verify > the public reset. You are talking about a variation that puts the > verifier in the clear. Yes. I believe that bad behavior is going to happen if middleboxes can observe the public reset but cannot verify it. Some middlebox developer is going to hack some kind of anti-grease, or whatever seems convenient. I think there are two stable designs. One in which middleboxes get to see and verify. Another in which middleboxes don't get to distinguish the PR from other encrypted packets, thus removing the temptation for misbehavior. This would be in line with your later comments about distinction between the end-to-end role of PR and the path signaling role. PR would be strictly designed so that if an endpoint has lost connection state, it can reliably tell the other endpoint to kill the connection. Some TBD on path mechanism would allow for clearing the path. -- Christian Huitema From nobody Wed Apr 26 21:48:58 2017 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 3921313149B for ; Wed, 26 Apr 2017 21:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 UVDdcUY-65jK for ; Wed, 26 Apr 2017 21:48:55 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 A345A129456 for ; Wed, 26 Apr 2017 21:48:54 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id 75so10879473lfs.2 for ; Wed, 26 Apr 2017 21:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3NwefmxikfxoDReICmeBM7nFup3STya/h0JXT5BeLcA=; b=XTT+1tWShLzR0P/bugmf1KR8Mr+ureS+YquEswUtW5KhhkINMLAScQy8tuvpn4V11y bW/pfbJkp7vi4MVueT0xtltJ3BGqcY7maxLMWSndaTmiHnO965qF3mnYzCdG5tM8VOC4 EOQJH3iCpPsdTj9XSbo/XZQh1P5NYAh4xuDad3GDBQcU7aFBucDZ2fVoduwfzcZp3soO Sdcm8dPagwvC89aH897krH51U8prQ9ZFRKeyIk8DBN06EHnaIeiZ783SgLAD+fP+jAr8 gZ23+M8X14VFdpsM942C0x1gn0k0BAbtltJrvmU/C8HSD/jc9PeLiiPLFvPI5Z27oXpR Zgzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3NwefmxikfxoDReICmeBM7nFup3STya/h0JXT5BeLcA=; b=beyyiiSP08eQA9VoMJGp2xoNO7o0DoM5Er2dCzyHmpxt8aXnVtO+w1HPXJfOIr1hvR wkhK9+WheSRz/8AVIdMUi54aQuChIAfmNfIt/hYZpzZqOoMOsq8i66gKOupod5ZrCcFv Y/RIAKFGw+XWs8GEQjAp2e/TRMN7DXNkCZ2jH7mmJy80NlDuhzrjEwzxETU2jrnSVABq qhJqmarCC8jQNKHZGn0eLsWJbCiW98zbPQuejU3bTcRfKUmYbgdJoQNjmGvrkjviDqW7 8duRsN8PtxIwe5AknkTKqy6Q++1stKiZwuTmHbv9RxVk7DTl7CyJi8sq/jxIbryauwbD rTOw== X-Gm-Message-State: AN3rC/7I9cptLgLTDCH/QvjKM3Y8vBAvfdo8ID7D54obmcEBdwoF1zTF IKqChfXRdbofBNvsrogJY6J/o4zXqgKY X-Received: by 10.46.21.2 with SMTP id s2mr1296835ljd.50.1493268532914; Wed, 26 Apr 2017 21:48:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 21:48:52 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 27 Apr 2017 14:48:52 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Christian Huitema Cc: Victor Vasiliev , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 04:48:56 -0000 On 27 April 2017 at 14:27, Christian Huitema wrote: > Yes. I believe that bad behavior is going to happen if middleboxes can > observe the public reset but cannot verify it. Some middlebox developer > is going to hack some kind of anti-grease, or whatever seems convenient. How do you reckon that? The sort of grease I imagine is that you get a packet like this: Occasionally, the random gunk will cause the connection to be properly closed. The middlebox can't tell between random gunk and valid because it never sees the verifier. Greasing that creates a third stable state, or a subset of your second state, except the anonymity set is reduced a little. I don't know how to do full indistinguishability without also doing trial verification, which I suppose would work now that I think about it. I didn't consider it before because of my instinctual reaction to trial decryption in general. It's a little annoying to implement, but feasible. As for being able to verify, the middlebox on the path that is chosen after migration won't be able to verify this unless we send a new message in the clear. That creates a fairly large amount of complexity. From nobody Thu Apr 27 07:44:28 2017 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 AF5D9126D85 for ; Thu, 27 Apr 2017 07:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 w1zEZA2dXAAE for ; Thu, 27 Apr 2017 07:44:25 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 768C51294E6 for ; Thu, 27 Apr 2017 07:44:25 -0700 (PDT) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id E13723A0A9 for ; Thu, 27 Apr 2017 10:44:24 -0400 (EDT) Received: by mail-qk0-f173.google.com with SMTP id u75so29070245qka.3 for ; Thu, 27 Apr 2017 07:44:24 -0700 (PDT) X-Gm-Message-State: AN3rC/6528njQmt7/jVMNY83v5LftweQ99OZgT075oWxg5Ye5wUF4p0n JVBoMoal1cE5QEk3MgBQ8vV8a/TsJA== X-Received: by 10.55.76.140 with SMTP id z134mr3225595qka.35.1493304264581; Thu, 27 Apr 2017 07:44:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.182.31 with HTTP; Thu, 27 Apr 2017 07:44:24 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Thu, 27 Apr 2017 10:44:24 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Updated Public Reset authentication patch To: Christian Huitema Cc: Martin Thomson , Victor Vasiliev , QUIC WG Content-Type: multipart/alternative; boundary=001a114a80fc3b6b86054e26fe16 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Apr 2017 14:44:26 -0000 --001a114a80fc3b6b86054e26fe16 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 27, 2017 at 12:27 AM, Christian Huitema wrote: > Another in which middleboxes don't get to distinguish > the PR from other encrypted packets, thus removing the temptation for > misbehavior. > I am strongly coming around to this view - that PR is not workable as a path signal despite the fun math and therefore it shouldn't be in the clear. Do we have advocates for it in the group who would actually build (or require it to buy) it in on-path device and would be less aggressive with the timeouts as a result of the functionality being there? --001a114a80fc3b6b86054e26fe16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Apr 27, 2017 at 12:27 AM, Christian Huitema <<= a href=3D"mailto:huitema@huitema.net" target=3D"_blank">huitema@huitema.net= > wrote:
Another in which middleboxes don't= get to distinguish
the PR from other encrypted packets, thus removing the temptation for
misbehavior.

I= am strongly coming around to this view - that PR is not workable as a path= signal despite the fun math and therefore it shouldn't be in the clear= . Do we have advocates for it in the group who would actually build (or req= uire it to buy) it in on-path device and would be less aggressive with the = timeouts as a result of the functionality being there?


--001a114a80fc3b6b86054e26fe16-- From nobody Fri Apr 28 02:30:10 2017 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 6C3D51294B2 for ; Fri, 28 Apr 2017 02:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 i4p2Xd3IGjVA for ; Fri, 28 Apr 2017 02:30:05 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0995B129572 for ; Fri, 28 Apr 2017 02:27:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3wDpPP05GBzMn4l; Fri, 28 Apr 2017 11:27:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYDzKEluXsAX; Fri, 28 Apr 2017 11:27:19 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 28 Apr 2017 11:27:19 +0200 (CEST) Subject: Re: Updated Public Reset authentication patch To: Patrick McManus , Christian Huitema References: Cc: Victor Vasiliev , QUIC WG , Martin Thomson From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <44fe02c0-3b90-0357-4169-1aaba890751f@tik.ee.ethz.ch> Date: Fri, 28 Apr 2017 11:27:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 28 Apr 2017 09:30:07 -0000 Hi all, I do have a question on this: The PR assume that there was some previous connection between the client and the server and there is a static key. Isn't there the case where the server lost completely state or receives a packet wrongly without having ever talked to the client before? Don't we still need a non-authenticated reset in this case? The actually point I wanted to make it however is that if a middlebox is able to somehow detect that a reset is a reset the middlebox will use this signal and do random stuff. Therefore I vote for designing a stop signal for middleboxes that is meant to assist them with tearing down state to avoid any implicit unwanted side-effect on other signals we have. Mirja On 27.04.2017 16:44, Patrick McManus wrote: > > On Thu, Apr 27, 2017 at 12:27 AM, Christian Huitema > wrote: > > Another in which middleboxes don't get to distinguish > the PR from other encrypted packets, thus removing the temptation for > misbehavior. > > > I am strongly coming around to this view - that PR is not workable as a path > signal despite the fun math and therefore it shouldn't be in the clear. Do we > have advocates for it in the group who would actually build (or require it to > buy) it in on-path device and would be less aggressive with the timeouts as a > result of the functionality being there? > > From nobody Fri Apr 28 02:30:27 2017 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 A28BE12E856 for ; Fri, 28 Apr 2017 02:30:26 -0700 (PDT) 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] 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 JqLyD_MsmiXV for ; Fri, 28 Apr 2017 02:30:22 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57F0129571 for ; Fri, 28 Apr 2017 02:27:34 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5968A340E8F; Fri, 28 Apr 2017 11:27:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.16347); Fri, 28 Apr 2017 11:27:32 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 28 Apr 2017 11:27:32 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 15906834; Fri, 28 Apr 2017 11:27:32 +0200 Subject: Re: Updated Public Reset authentication patch Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F8FBD511-F650-4307-A9F0-1B87FBF0E00D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell (IETF) In-Reply-To: Date: Fri, 28 Apr 2017 11:27:31 +0200 Cc: QUIC WG Message-Id: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 28 Apr 2017 09:30:26 -0000 --Apple-Mail=_F8FBD511-F650-4307-A9F0-1B87FBF0E00D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, all, Thanks for this patch. Comments and questions, mostly in scope, = inline... > On 24 Apr 2017, at 02:32, Martin Thomson = wrote: >=20 > On 23 April 2017 at 12:01, Eric Rescorla wrote: >> Well, if we take that reasoning to its logical conclusion, we need to = worry >> about them taking anything marked as a public reset and terminating = the >> connection without bothering to validate the packet fragment that's = supposed >> to indicate on-pathness. This seems like an argument for having a = *private* >> reset (e.g., an apparently encrypted packet with a specific pattern = in the >> first N bits of the payloard). You can still make this stateless = using the >> same techniques as we are using here. >=20 > I don't see that working unless we also encrypt the packet number. A > server that just rebooting isn't going to know what packet number is > expected to come next. On that basis, a middlebox could look for a > discontinuity in packet numbers and treat that as a public reset. >=20 > Stepping back here, this comes back to how much information we want to > give the middlebox. With the added observation that when you give a > middlebox information you have to trust them to do the right thing > with it. >=20 > Christian's view might seem pessimistic, but middlebox state is > precious. In designing for this new protocol, a middlebox designer > has to account for the possibility that this flow was migrated from > some other network path. A migrated flow won't include a handshake. >=20 > That suggests to me that we need to treat end-to-end and path signals > differently as much as we can. >=20 > # End-to-End >=20 > Signals about the state of the connection need to go end-to-end. > Public reset is fundamentally a signal about the entire connection. > If we accept that the protocol inherently goes over multiple paths, > then we can say that there is no need to privilege just one path with > knowledge of a connection termination signal. There's an assumption made in pretty much all the work on path signals = that the devices that are keeping state are on a unipath segment between = the endpoints -- they see all the packets in a single direction. Indeed, = in most cases we assume they're on a symmetric unipath segment between = the endpoints, and see all the packets in both directions. The most = ubiquitously deployed classes of stateful devices -- NATs, firewalls -- = cannot function unless they are so deployed. Or, put another way, if you're doing ECMP, and you're doing stateful = things where state is shared across multiple ECMP flows (i.e. multiple = paths) and you haven't solved the state migration problem, then the fact = that things break is pretty much your fault. So unless I'm missing = something here, I'm not sure that "privileging just one path" is a thing = that happens. (I'm ignoring multipath here, because in the multipath case, I suspect = we'll end up with an MPTCP-like design, where a higher-level "multipath = connection" is made up of multiple "simple QUIC connections". Since = connection binding and unbinding can happen with frames inside packet = protection, there is no need at all to expose anything about that = binding to the path, and indeed, I can't think of any benefit an = endpoint might get from doing so.) > The challenge - if any > - with the design we have is that there is an inadvertent signal to > the path when endpoints lose state. Let's step back a little here; at least I'm getting a little confused = about what an exposed (or non-exposed) public reset is supposed to do... There are three ways a connection can cease to be: (1) The endpoints agree, through some form of signaling to each other, = that the connection will cease. This is CONNECTION_CLOSE, TCP FIN, etc. = There is enough state to transmit this agreement confidentially. (2) One of the endpoints silently loses connection state but remains = reachable (the reboot case). It needs to signal this to the other = endpoint on the receipt of a packet, but it doesn't have enough state to = do that confidentially. This is TCP RST, and public reset as initially = conceived. (3) Connectivity between the endpoints is "permanently" disrupted, = because one endpoint went away, the link between them went down, or some = middlebox that needed state to forward packets lost that state. Each = endpoint must independently discover this and tear down its own state = accordingly. What do each of these ways look like from the point of view of an = observer on both the upstream and downstream paths? In case (1), there are packets, then there are no more packets. The only = way to detect connection close is by timeout, unless we add an explicit = signal. In case (2), the public reset packet is discernable, and gets ECMP = hashed as the other packets on the dead flow, so can be used by the = path, unless we go to effort to make it not so. In case (3), there are packets from both sides, then there are packets = from only one side, then there are packets from nowhere, depending on = the relative position of the middlebox and the connection disruption. = Since each side must independently determine that the connection is = dead, emitting a public reset in this case would be a path, non an = end-to-end, signal. Which cases is verifiable public reset attempting to address? There's a design space for explicitly exposing connection close to the = path as best we can, and a design space for keeping information about = connection state as secret as we can. Both probably contain multiple = possible coherent designs. So AFAICT this isn't an engineering question; = it is instead a question about threat models, requirements, and general = philosophy of protocol design. We should have some concrete idea of the = risks of misuse of those signals QUIC sends, explicitly or = inadvertently. And we should come to some sort of consensus on what it = is we want. > We can work around that, but it either requires removing packet > numbers completely, or greatly enhancing the information exposed to > the path. For instance, if we had a packet number echo the server > would be able to pick a plausible packet number for its reset. ...I wouldn't say we need to greatly enhance it; this PR enhances it = enough for the purposes of separating endpoint-generated public resets = from spoofed ones... > I'm inclined to say that there is no reason to specially fix the > problem Christian raises. If the path can't be trusted not to act on > this information, we can grease and send a continuous stream of > spurious Public Reset packets. Indeed, but this is a general issue and it's unfixable in a multihop = packet-switched network: any device on the path (including those that = are completely invisible on the layers the endpoints have access to) can = decide to fail to forward any packet at any time. The more, um, = advertant we are about the information the endpoints expose to the path, = the less surprising the outcomes of those decisions are likely to be to = the endpoints. > For this discussion, I'd like to keep things concentrated on the > end-to-end part as much as possible. Thus the remaining sections are > .. As above, there are two design spaces: one which attempts to signal = shutdown as explicitly as (or more explicitly than) TCP, and one which = attempts to hide everything it reasonably can about connection state = from everything except the endpoints. We should choose a design in the former space if we decide there is = sufficient value in making it possible for middleboxes whose loss of = state might cause connection disruption to separate timeouts into "not = connected" versus "connected", in order to mitigate the disadvantages of = short UDP timeouts on NATs and firewalls, and/or in using TCP-equivalent = state modeling as part of a heuristic approach to separating legitimate = QUIC traffic from probable UDP backscatter, spoofery, or other noise. On the other hand, we should choose a design in the latter space if we = do not believe the short timeout problem has a significant operational = impact, or if we believe that the short UDP timeout problem should = instead be solved by a strategy involving keepalives and 0-RTT = reconnection in the case of state loss. I note that an interesting = criterion for knowing how well a 0-RTT reconnection strategy is the = prevelance of "expensive-state" paths, where the first packet in a 0-RTT = restart on a new five-tuple will be significantly delayed due to the way = the network and/or link layer is implemented. Data, as always, would be = nice here. :) > --- out of scope stuff ...sorry, that last bit probably went over the scope fence... I agree completely that it's desirable to separate the discussions about = end-to-end from end-to-path and path-to-end signaling; but public reset, = in particular, counfounds that desire, since it's an end-to-end signal = that radiates information to the path. We should focus on, and probably = work to minimize, these inseparable effects. > # Middle-to-End >=20 > Signals from path elements about the state of the path require > separate design. We currently don't have a principled way of > approaching this, but we're not cutting entirely new ground. We > already accepted a middle-to-end signal with PMTUD. >=20 > The approach for that was for endpoints to treat the signal with > suspicion. I like that approach. One nice property of these signals > is that the sender can't know the session keys, so it's very easy to > identify these and throw them out if you don't trust them. >=20 > # End-to-Middle >=20 > With Public Reset we're really talking about a signal from endpoints > *to* the path. In the case of the silent close discussion we had, we > mistakenly conflated that with the end-to-end signal. >=20 > If we want anything, we should be taking Brian's work on the states > and signals more seriously. For me, I'd like to see more thought > about on how a path element determines that the signal is truly from > the end, and not another middle. There are, in general, three broad design approaches I can see here. The = first is the one proposed in PLUS: the endpoints verify signal integrity = (by AEAD over the bits in the packet header that carry them), which = allows them to detect signal injection. The guaranteed detectability of = signal injection then acts as an incentive against doing it (at that = layer, anyway). This does not allow a given path element to determine = whether a given signal is endpoint derived, though; it's an economic, = probabilistic defense. The second provides authenticity of signal, as opposed to authenticity = of endpoint, to devices along the path. One way to do this is to = implement signals as verification of a previously exposed proof (as this = PR does). This is more expensive, in that it requires reliable = transmission of both the proof and the verification, as well as storage = of the proof at each verifier. There are memory/bandwidth efficiency = versus proof strength tradeoffs to be explored here. One could combine the first approach with the second, relying on an = endpoint to detect signal injection; and endpoint that detects injection = could send a "path compromise" signal using a revealed verification. = This would, however, not allow a given path element to detect an = injected signal at the time of signal receipt. But the certainty that = every element along the path would be informed of an injection might = provide even more incentive not to try. I don't yet see a way to get better-than-economic defense without = allowing a path element to authenticate an endpoint, so that it can = verify that each header bit carrying a signal indeed came from the = endpoint it should have. This is vastly more expencive, and essentially = goes down the path of building QUIC atop a multiparty cryptographic = protocol -- mcTLS occupies a far corner of this design space. I don't = think it's possible to deploy something like this safely in the Internet = with the primitives we have available to us, but IANAC. Cheers, Brian --Apple-Mail=_F8FBD511-F650-4307-A9F0-1B87FBF0E00D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZAwsDAAoJEIoSt78L6kaj0q0P/0oYyHrULhKyrcPmUI8MweNm UQmMye4KdVhwYywXWyJNjgKXNFai3hrQ0nmtU7qMcT9W++ykVBo3tSAaSd1IaZVu EEqiu6MhIbl3NWHMJ9RswlzQnlMPKAX1gjZnyrFk2oTVb7wuxc2hMmvlFW6k3D/r Nys9vGUO5vyHUzfLljcoD9NQLyyU1HmiY+jS8+0DiwfVw5w4unzcJMpUyL/WiEOl 1a8WI7Jc4Jv41IH2l1A8t8KVgqMhEC2xQ5Y9dIL8/PsBaIR8HOUSwEnX36B5bqfQ nGtJEoJ0kcxo/799dtPU7qTLfWJuWUDC8Npa4CagN0iNSKFkPKAO6Mn1f6Tqxb5B KOdUdskZRo5SMd041D8tCIfIzmSpqAGLRze6EaYQDtRk4bdqSMzvxfMi2E1vhcXF UAYwsVjQLbyalQgs2RgPGzLdLeF0rYW2SEe+IeveQgx9cqoYjMKHoSiqaLuZQcGS ekMivoAqIKoYvv8+v9K3zIeWY7VQI2xerDHQbHoUynfzxpM3aDv5iz39M76XJoAW JC6of07Bb+A3H3MmPbMw0s7EAYMs+jFBj50aCuIwVHijxFrNe/YNSkXG7oTs2ntL h1GaHX2W0b3dJwilCjWOjo0cCL4XGLpC3VP/M1+cgtnVlovgKsay9NdWZWRpaXnH +lZG9MBG1wg0TLkHUXdc =ZD8k -----END PGP SIGNATURE----- --Apple-Mail=_F8FBD511-F650-4307-A9F0-1B87FBF0E00D-- From nobody Fri Apr 28 02:41:36 2017 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 4B7CF12E858 for ; Fri, 28 Apr 2017 02:41:35 -0700 (PDT) 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] 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 prl1-tPDB9vF for ; Fri, 28 Apr 2017 02:41:33 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C95129498 for ; Fri, 28 Apr 2017 02:38:23 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 33449340E8C; Fri, 28 Apr 2017 11:38:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.17344); Fri, 28 Apr 2017 11:38:22 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 28 Apr 2017 11:38:22 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 15908648; Fri, 28 Apr 2017 11:38:22 +0200 Subject: Re: Updated Public Reset authentication patch Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_63670BE1-0872-40E0-8EA1-01BF0B8CEC6C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Fri, 28 Apr 2017 11:38:21 +0200 Cc: QUIC WG Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 28 Apr 2017 09:41:35 -0000 --Apple-Mail=_63670BE1-0872-40E0-8EA1-01BF0B8CEC6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, (...note to self, make sure to read thread before sending delayed = draft...) > On 27 Apr 2017, at 03:01, Martin Thomson = wrote: >=20 > On 27 April 2017 at 10:27, Lubashev, Igor wrote: >> The idea to build a "better-than-on-path" proof is interesting, but = is it really worth the complexity? >=20 > ekr answered the other questions, but I want to use this as an > opportunity to raise a point that keeps getting lost. >=20 > Public reset is a way to kill the connection, not the path. Yes, it's > obvious that a valid public reset also means that the path is going > away, but conflating the two is a mistake, even in the absence of > multipath. >=20 > When the issue of silent close was raised in Chicago, we collectively > made the same category error. The important consideration here is > whether we believe that it is necessary for the path to learn that the > path will no longer be used. If we believe that this is a necessary > signal, then we need to create those signals. >=20 > I am increasingly of the opinion that overloading public reset is not > an appropriate way to signal to the path, but I am willing to > entertain the notion that I'm wrong. I'd like to suggest that we > adopt the following approach: >=20 > 1. determine whether we need an end-to-path signal for termination; > 2. if needed, design that signal; then > 3. if appropriate, merge that signal with public reset. I agree completely with this approach; my comments on how to make choice = (1) appear in the other reply I just sent to this tread. > If we don't start disentangling issues, this is going to take a very = long time. Yep. FWIW, apologies for my contribution to the unfortunate conflation = of "public reset" with "explicitly signaled close" that leads to this = tangle. Imprecise terminology begets imprecise engineering... Cheers, Brian --Apple-Mail=_63670BE1-0872-40E0-8EA1-01BF0B8CEC6C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZAw2NAAoJEIoSt78L6kajJHkP/1RL7rC7fthlqXM9ltJ9Gzja ZXnRFwPAdW9B026kBp2b/MAPh1m7BmSXecG5QKXOhBqTiRb5GVMjT4i8vuy/01W9 V8TWYJOqbTrj7/eu7kkhnJ7zVqJzkxIbfBhrOSOS37LmHjDEv5dcvr1EmLN+X+iv CVzamkKXktzO47lYzzuziIbN3YK9q3135XOqm916uciOTU5VqwpC8b3grktcPnPf d77koo1A3+V04zl8oLHD0B5vR4Q+NRJNAq+9pCM1ijrN2rVv/3K0bh5T0T2M8e4F 9KPAzJX/ppyQLl5FpCUHi33Os+it8DINYer0flte1wrTewxaYAVe39v1heJL11Y9 1YvTRv4q9u81OxAM2YZooTkgxJnVk/jSXjIOjghjPbGTbxpmPRBf5iCSDjuse+Fa KMqWllAYuATe76xYHfg4U0WPwCAjAjz98vvylJ5AqA7t/zvKv1EzuTe8UYxyi+bR jhMGUNYNqbinV3Z9xIBWXBNL+3E/KTvreo00Bx41txeiCQyvEc7gpv9spmmx3rZ4 zVLZ+HK43vvY9V1Benm8+3+6QG8cfRX2eUCEf8utLMwhUchtyNsXu9e/f9/uufix 4cZHKbbsOc5OFsO5v5Jza5fb9bXbfl2Q6yj4idqqPJaGT9OJFn6o5dDaSp4ys3IQ xu+a1mCpJF+IFfJWhXeg =rTWg -----END PGP SIGNATURE----- --Apple-Mail=_63670BE1-0872-40E0-8EA1-01BF0B8CEC6C-- From nobody Fri Apr 28 03:31:42 2017 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 837AE12946F for ; Fri, 28 Apr 2017 03:31:40 -0700 (PDT) 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, FREEMAIL_FROM=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=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 wOs0bTcR4nVT for ; Fri, 28 Apr 2017 03:31:39 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 720061294E8 for ; Fri, 28 Apr 2017 03:29:24 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id 75so31452466lfs.2 for ; Fri, 28 Apr 2017 03:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=R8GF/tlq2SSiFFbb6KucXkYG9XWPEMNkRwCIxqd5jyc=; b=ryr9h3FZWyZ9bUZB2zxvIPynTa5hW8yGThiT96vISjF77TEKq8CzyYatCLY0cLdXwj 9wj9FLzX19RKza4Q87lBgrHhuF01Qj/oqvwV6coOAHzC0X7UyZZTks/sRDBePmoD3Q3X ShKY6WY/3USYcY5XP5LXAj0/FGral0RLeB/PhA4E+4ilPoLzFZO8snMBXHa6POXhw7yF LfWI1xAgpH+mokn/3ZrrE527qqlu/f0ahTgNAnfzwx2Zo5yHwpXKoVz31Wa2Cju11Gt4 B4khj2XrQ33CK4ZKm1rtrFT5Uzxw6TGAFbSvKla0qxEFCocoaFszG5bTGwVAEBwk8HoM gY3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=R8GF/tlq2SSiFFbb6KucXkYG9XWPEMNkRwCIxqd5jyc=; b=kd/5VdKo6Thsi8LGbMoaXFz1ftBko21Wn6up0vE6KZZDKBTdncm33tmCeb/EaxmY1a X4KkvQfvzBfhxPAfv0GGatS5lyevrDuR+OWfj0XgYs2qL1I/JnnqdHx33rgEsQkoZLPq UsGhjluTKJstFhUN+vfjgeBgdlC95eu1T6ZmC+mt4FzRMbFAyArZtUhueuak/5ilO2G4 c4k/iR60IN5kl2KsRi0EPb+kKXUzx8cwjLUHQulSdLcXC6s07O7c97fnx7+DOz8efqHQ Ki7mVoTldBZzzepGvgMJaKsNUQms7VCrKhmp3cvGnn6k0duN8gzgqCV2ByVu/cA+iXBz NHYQ== X-Gm-Message-State: AN3rC/7ksh/7EZh7yjXNyWqbKvQyTYyXge/ajsolpbCqgiTMGMyNK5rN S8AKkf6chsUSaE0xE/Hrpy6qJIOM6w== X-Received: by 10.25.160.147 with SMTP id j141mr3227257lfe.19.1493375362646; Fri, 28 Apr 2017 03:29:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Fri, 28 Apr 2017 03:29:21 -0700 (PDT) In-Reply-To: <44fe02c0-3b90-0357-4169-1aaba890751f@tik.ee.ethz.ch> References: <44fe02c0-3b90-0357-4169-1aaba890751f@tik.ee.ethz.ch> From: Martin Thomson Date: Fri, 28 Apr 2017 20:29:21 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Patrick McManus , Christian Huitema , Victor Vasiliev , 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.22 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, 28 Apr 2017 10:31:40 -0000 On 28 April 2017 at 19:27, Mirja K=C3=BChlewind wrote: > I do have a question on this: The PR assume that there was some previous > connection between the client and the server and there is a static key. The static key is one that the server knows (all instances of the server need to use the same key). The client gets a verifier H(x) and the server has a process to use the static key and the connection ID to generate x. The client doesn't need to know anything except what the server gives it during connection setup. > The actually point I wanted to make it however is that if a middlebox is > able to somehow detect that a reset is a reset the middlebox will use thi= s > signal and do random stuff. Therefore I vote for designing a stop signal = for > middleboxes that is meant to assist them with tearing down state to avoid > any implicit unwanted side-effect on other signals we have. As I suggested upthread, I think that we can avoid middleboxes doing anything with this particular signal. If you want to separately construct an end-to-path stop signal, then I'd suggest doing that. If it ends up looking like public reset (it may, though the requirements are quite different) then we can discuss merging the two mechanisms. I just want to avoid trying to hit two different birds with this stone. They might be sitting next to each other, but my experience is that you miss both when you try to do that.