From nobody Sat Feb 2 16:45:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74534130EBE for ; Sat, 2 Feb 2019 16:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=yfAFe+7p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hU/DFSpi 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 GLorZX1oPJRl for ; Sat, 2 Feb 2019 16:45:22 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E105130EB2 for ; Sat, 2 Feb 2019 16:45:22 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A256421990 for ; Sat, 2 Feb 2019 19:45:20 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 02 Feb 2019 19:45:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=4yFby07lKhgeZFZKK/eUtg7JMpmfZ6uACaQX8w+tvJg=; b=yfAFe+7p uOqQFBmC/3Nw2ahFiZkYEHewD3Nco6ELZQ66Pf0OBum5EJ7o3T3a3HhnUb1slzCL yFQlkEikT/Cjyl1Zlh2RAdx0Ga/5fwcFhphrQqSuTXVD8BrmRuaOm2okScMmSfw7 N+hF1kVdcpEhIfkTH4z1rDIVnqYpH/Ebx/eAikneY4IDI8T+aORNQNFRRcdpBk9r 8a7B8XLworqQDY+lZlN0kbIFRiSlbT30bnIiOazAjFWn6bU8iDJt2QeexDtgjHMm +9DtTFQ4eNXKdpBqJ4q+g2UmCkglySd/GqOVY5onwZ0vHnGZH3aFS37Ub8n7O/nb pvAeZoBRrYwxlA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=4yFby07lKhgeZFZKK/eUtg7JMpmfZ 6uACaQX8w+tvJg=; b=hU/DFSpi6oknFbT1DXckcLI4Gu6VlccympFi+rBtBTjDZ MBp2TQJOPp/E4tWyXM2Gh/P1zTaUP3eDdMbBoYJPlIZOIcjqEuF+LLM6sosJBk1z zpNy06QiFkLxYjkw1+n90kN6NKTxVfTlBRDnl4m0FCiLW0CRo3zHM9e3YARqUExo tPA/BZq7sq06/nRjgwCffKhcE9Ix+ccoq2MwWP5oyP+fT/UXwMAglLZ5dfQoblhG xQCYy8KPduc4m5KRHt5QjAYMqGdFxX2l6AFleFPBHWXdmzbW637Bb36wjDxOwOSv z8+SAQXWbMnt3rsrYJjjL+I/uGxRvoDeY4lqNV2xw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkedugddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpefiihhthhhusg gppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhn vghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeduudelrdelrdegfe drvdegudenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehm nhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 0765110311 for ; Sat, 2 Feb 2019 19:45:18 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 638ADC03FB for ; Sun, 3 Feb 2019 00:45:15 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============2831666685510456790==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190203004515.638ADC03FB@cloud.mnot.net> Date: Sun, 3 Feb 2019 00:45:15 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 00:45:28 -0000 --===============2831666685510456790== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+8/-23/=F0=9F=92=AC156) 8 issues created: - VN packets may be dropped more often when the QUIC bit is 0 (by ianswet= t) https://github.com/quicwg/base-drafts/issues/2400 = - Specify DCID of 0-RTT packets (by mikkelfj) https://github.com/quicwg/base-drafts/issues/2398 = - Version field in Retry packets (by larseggert) https://github.com/quicwg/base-drafts/issues/2397 [-transport] = - HTTP/3 frame encodings are unnecessarily difficult to serialize and par= se (by ianswett) https://github.com/quicwg/base-drafts/issues/2396 = - HTTP/3 should use TLV (by ianswett) https://github.com/quicwg/base-drafts/issues/2395 [-http] [design] = - Spoofed retry token attack on IP authentication (by mikkelfj) https://github.com/quicwg/base-drafts/issues/2394 = - kGranularity and max_ack_delay possibly should be added after exponenti= al backoff (by ianswett) https://github.com/quicwg/base-drafts/issues/2393 [-recovery] [design] = - Write up our security target against on-path attack (by ekr) https://github.com/quicwg/base-drafts/issues/2387 = 69 issues received 156 new comments: - #253 HTTP/QUIC without Alt-Svc? (17 by ExE-Boss, mikkelfj, philsbln, ka= zuho, martinthomson, tfpauly, MikeBishop, LPardue) https://github.com/quicwg/base-drafts/issues/253 [-http] [design] = - #2394 Spoofed retry token attack on IP authentication (12 by kazuho, mi= kkelfj) https://github.com/quicwg/base-drafts/issues/2394 = - #2308 handling of coalesced packets with decryption errors creates DoS = opportunity (8 by kazuho, ianswett, igorlord, martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/issues/2308 [-transport] [design] = - #2101 Should retiring all CIDs be an error? (8 by martinthomson, marten= -seemann, dtikhonov, ianswett, MikeBishop) https://github.com/quicwg/base-drafts/issues/2101 [-transport] [design] = - #2275 Varint h3 unidirectional stream types (7 by martinthomson, LPardu= e, MikeBishop) https://github.com/quicwg/base-drafts/issues/2275 [-http] [design] = - #1810 Timing issues in version downgrade attack prevention (6 by kazuho= , martinthomson, martinduke) https://github.com/quicwg/base-drafts/issues/1810 [-transport] [design] = - #2180 Is Retry a new connection or what? (5 by kazuho, martinthomson, m= ikkelfj) https://github.com/quicwg/base-drafts/issues/2180 [-transport] [design] = - #2397 "Invariant check" for any inbound LH packet (5 by martinthomson, = MikeBishop, larseggert, mikkelfj) https://github.com/quicwg/base-drafts/issues/2397 [-transport] [design] = - #2396 HTTP/3 frame encodings are unnecessarily difficult to serialize a= nd parse (5 by DavidSchinazi, ianswett, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2396 [-http] [design] = - #2344 Frames that are allowed in 0-RTT packets (4 by martinthomson, hui= tema, MikeBishop) https://github.com/quicwg/base-drafts/issues/2344 [-transport] [design] = - #2233 Why are setting identifiers not varints? (4 by martinthomson, Mik= eBishop, mikkelfj) https://github.com/quicwg/base-drafts/issues/2233 [-http] [design] = - #1885 DATA frame encoding is inefficient for long dynamically generated= bodies (4 by lnicco, ianswett, MikeBishop) https://github.com/quicwg/base-drafts/issues/1885 [-http] [design] = - #2143 Be more conservative about migration? (4 by martinthomson, martin= duke, ianswett) https://github.com/quicwg/base-drafts/issues/2143 [-transport] [design] = - #2347 nothing can be sent when receiving a packet just after the idle c= lose timer expires (3 by martinthomson, huitema) https://github.com/quicwg/base-drafts/issues/2347 [-transport] [design] = - #2311 Connection migration attacks may have other side effects (2 by rp= aulo, ianswett) https://github.com/quicwg/base-drafts/issues/2311 [-transport] [editori= al] = - #655 1-RTT stateless rejects (2 by martinthomson, kazuho) https://github.com/quicwg/base-drafts/issues/655 [-tls] [design] [parke= d] = - #2267 loss of only two packets can lead to an unrecoverable situation (= 2 by martinthomson, nibanks) https://github.com/quicwg/base-drafts/issues/2267 [-transport] [design] = - #2100 Avoid creating QPACK codec streams when unnecessary (2 by MikeBis= hop, mikkelfj) https://github.com/quicwg/base-drafts/issues/2100 [-qpack] [design] = - #2230 What indicates the end of a message? (2 by huitema, MikeBishop) https://github.com/quicwg/base-drafts/issues/2230 [-http] [design] = - #2372 PATH_* frames should not be ACK-eliciting (2 by martinthomson, mi= kkelfj) https://github.com/quicwg/base-drafts/issues/2372 [-recovery] [design] = - #1482 Extension poster-child (2 by DavidSchinazi, martinthomson) https://github.com/quicwg/base-drafts/issues/1482 [-transport] [design]= [parked] = - #219 Increasing initial flow control window for streams (2 by martintho= mson, huitema) https://github.com/quicwg/base-drafts/issues/219 [-transport] [design] = [parked] = - #2151 Where can you send CONNECTION_CLOSE (2 by martinthomson, huitema) https://github.com/quicwg/base-drafts/issues/2151 [-transport] [design] = - #2049 minimum payload size requirement creates awkward special case (1 = by martinthomson) https://github.com/quicwg/base-drafts/issues/2049 [-transport] [editori= al] = - #2309 Migration before handshake completed is very messy (1 by martinth= omson) https://github.com/quicwg/base-drafts/issues/2309 [-transport] [design] = - #2319 Error code for acknowledgment of a packet that was never sent (1 = by huitema) https://github.com/quicwg/base-drafts/issues/2319 [-transport] [design]= [yaec!] = - #279 Public Troubleshooting Flags (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/279 [-transport] [design] = [parked] = - #602 End-to-Path Close Signal (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/602 [-transport] [design] = [parked] = - #1951 Disconnect with Initial Injection (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1951 [-transport] [design] = - #2084 Discuss requirement that connection IDs not be correlatable (1 by= martinthomson) https://github.com/quicwg/base-drafts/issues/2084 [-transport] [design] = - #1990 encoding of CONNECTION_CLOSE reason phrases (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1990 [-transport] [design] = - #2342 Spoofed connection migration as a DoS vector (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2342 [-transport] [design] = - #1834 Flow control for post-handshake CRYPTO messages (1 by martinthoms= on) https://github.com/quicwg/base-drafts/issues/1834 [-tls] [design] = - #2348 Specify IPv6 flow label for QUIC (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2348 [-transport] [design] = - #1243 ICMP and ICMPv6 PMTUD with asymmetric connection-ids (1 by martin= thomson) https://github.com/quicwg/base-drafts/issues/1243 [-transport] [editori= al] = - #2226 Why do I have to explicitly cancel after GOAWAY (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2226 [-http] [editorial] = - #2291 Allow extra data after self-terminating h3 frames (1 by MikeBisho= p) https://github.com/quicwg/base-drafts/issues/2291 [-http] [design] = - #2229 Can I send non-data frames on CONNECT streams? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2229 [-http] [editorial] = - #969 ACK Frames should be in Increasing Packet Number Order (1 by marti= nthomson) https://github.com/quicwg/base-drafts/issues/969 [-transport] [design] = [parked] = - #2232 Should receipt of multiple promises really be an error? (1 by Mik= eBishop) https://github.com/quicwg/base-drafts/issues/2232 [-http] [design] = - #2329 Actions to take when Reserved Bits are not Zero (1 by martinthoms= on) https://github.com/quicwg/base-drafts/issues/2329 [-tls] [-transport] [= design] = - #1994 endpoints don't know how many connection IDs the peer is willing = to store (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1994 [-transport] [design] = - #2377 Crypto Frames/Packets Aren't Blocked by CC (1 by siyengar) https://github.com/quicwg/base-drafts/issues/2377 [-recovery] [design] = - #2112 Largest Reference algorithm can produce invalid values (1 by afri= nd) https://github.com/quicwg/base-drafts/issues/2112 [-qpack] [design] [ha= s-proposal] = - #2371 Assign QPACK error codes? (1 by afrind) https://github.com/quicwg/base-drafts/issues/2371 [-qpack] [design] = - #1989 frame type field of CONNECTION_CLOSE provides little value (1 by = martinthomson) https://github.com/quicwg/base-drafts/issues/1989 [-transport] [design] = - #2118 Allow PMTU probing of a path suspected of not supporting PMTU of = 1280 (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2118 [-transport] [design] = - #1993 Introduce a bit to indicate the server doesn't do IP-based authen= tication (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1993 [-transport] [design]= [parked] = - #2253 Consider making h3 frame types varint (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2253 [-http] [design] = - #718 Retain use of SETTINGS_ENABLE_PUSH (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/718 [-http] [design] [park= ed] = - #2384 What scheme should be used for HTTP/3? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2384 [-http] [design] = - #2360 0-RTT flow control limits can't be increased (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2360 [-transport] [design] = - #1874 Formal analysis of the protocol (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1874 [-tls] [parked] = - #2388 Articulate principles for definition of error codes (1 by ianswet= t) https://github.com/quicwg/base-drafts/issues/2388 [-transport] [design] = - #2393 kGranularity and max_ack_delay possibly should be added after exp= onential backoff (1 by nibanks) https://github.com/quicwg/base-drafts/issues/2393 [-recovery] [design] = - #2395 HTTP/3 uses LTV unlike TLS or QUIC transport (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2395 [-http] [design] = - #2398 Specify DCID of 0-RTT packets (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2398 [-transport] [editori= al] = - #2276 Disallow changes of table size after 0-RTT (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2276 [-http] [-qpack] [des= ign] [has-proposal] = - #2214 simultaneous key update can lead to deadlock (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2214 [-tls] [design] = - #1638 Dead path timeout (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1638 [-transport] [design] = - #2026 Can Initial/0-RTT CIDs safely be used for routing? (1 by MikeBish= op) https://github.com/quicwg/base-drafts/issues/2026 [-transport] [editori= al] = - #203 Connection migration should be indistinguishable from a new connec= tion (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/203 [-transport] [design] = [parked] = - #1773 Build a version negotiation mechanism that mostly doesn't add rou= nd trips (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1773 [-transport] [design] = - #2159 Why are we bothering to number CIDs? (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2159 [-transport] [design] = - #2228 How do I generate an RST? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2228 [-http] = - #371 ALTSVC Frame (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/371 [-http] [design] [park= ed] = - #632 On-path calculation of loss and congestion (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/632 [-transport] [design] = [parked] = - #2170 Embed QUIC version in expansion (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2170 [-tls] [design] = - #2299 consider making the varint encoding unique (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2299 [-transport] [design] = 23 issues closed: - Should receipt of multiple promises really be an error? https://github.= com/quicwg/base-drafts/issues/2232 [-http] [design] = - Retain use of SETTINGS_ENABLE_PUSH https://github.com/quicwg/base-draft= s/issues/718 [-http] [design] [parked] = - ALTSVC Frame https://github.com/quicwg/base-drafts/issues/371 [-http] [= design] [parked] = - What scheme should be used for HTTP/3? https://github.com/quicwg/base-d= rafts/issues/2384 [-http] [design] = - Why do control streams need to be typed? https://github.com/quicwg/base= -drafts/issues/2224 [-http] [design] = - DATA frame encoding is inefficient for long dynamically generated bodie= s https://github.com/quicwg/base-drafts/issues/1885 [-http] [design] = - Allow extra data after self-terminating h3 frames https://github.com/qu= icwg/base-drafts/issues/2291 [-http] [design] = - HTTP/3 frame encodings are unnecessarily difficult to serialize and par= se https://github.com/quicwg/base-drafts/issues/2396 [-http] [design] = - Introduce a bit to indicate the server doesn't do IP-based authenticati= on https://github.com/quicwg/base-drafts/issues/1993 [-transport] [design] = [parked] = - Extension poster-child https://github.com/quicwg/base-drafts/issues/148= 2 [-transport] [design] [parked] = - ACK Frames should be in Increasing Packet Number Order https://github.c= om/quicwg/base-drafts/issues/969 [-transport] [design] [parked] = - consider making the varint encoding unique https://github.com/quicwg/ba= se-drafts/issues/2299 [-transport] [design] = - End-to-Path Close Signal https://github.com/quicwg/base-drafts/issues/6= 02 [-transport] [design] [parked] = - On-path calculation of loss and congestion https://github.com/quicwg/ba= se-drafts/issues/632 [-transport] [design] [parked] = - Allow PMTU probing of a path suspected of not supporting PMTU of 1280 h= ttps://github.com/quicwg/base-drafts/issues/2118 [-transport] [design] = - encoding of CONNECTION_CLOSE reason phrases https://github.com/quicwg/b= ase-drafts/issues/1990 [-transport] [design] = - frame type field of CONNECTION_CLOSE provides little value https://gith= ub.com/quicwg/base-drafts/issues/1989 [-transport] [design] = - Connection migration should be indistinguishable from a new connection = https://github.com/quicwg/base-drafts/issues/203 [-transport] [design] [par= ked] = - PATH_* frames should not be ACK-eliciting https://github.com/quicwg/bas= e-drafts/issues/2372 [-recovery] [design] = - Why are we bothering to number CIDs? https://github.com/quicwg/base-dra= fts/issues/2159 [-transport] [design] = - Formal analysis of the protocol https://github.com/quicwg/base-drafts/i= ssues/1874 [-tls] [parked] = - Actions to take when Reserved Bits are not Zero https://github.com/quic= wg/base-drafts/issues/2329 [-tls] [-transport] [design] = - Are Separate Uni and Bidi Stream Limits Meaningful? https://github.com/= quicwg/base-drafts/issues/2358 [-transport] [design] = Pull requests ------------- * quicwg/base-drafts (+6/-5/=F0=9F=92=AC8) 6 pull requests submitted: - Describe PMTU probing that includes source connection ID for routing = =E2=80=A6 (by igorlord) https://github.com/quicwg/base-drafts/pull/2402 = - Remove duplicated 'an' (by ghedo) https://github.com/quicwg/base-drafts/pull/2401 = - Ipv6 flow label (by huitema) https://github.com/quicwg/base-drafts/pull/2399 = - capitalizing destination connection ID (by seanturner) https://github.com/quicwg/base-drafts/pull/2392 [-tls] [editorial] = - removing stray ) (by seanturner) https://github.com/quicwg/base-drafts/pull/2391 [-tls] [editorial] = - Remove requirement for reciprocal connection ID change (by martinthomso= n) https://github.com/quicwg/base-drafts/pull/2386 [-transport] [design] = 4 pull requests received 8 new comments: - #2379 Replace the RequireInsertCount decoding algorithm (4 by bencebeky= , afrind) https://github.com/quicwg/base-drafts/pull/2379 [-qpack] [editorial] = - #2402 Describe PMTU probing that includes source connection ID for rout= ing =E2=80=A6 (2 by igorlord, mikkelfj) https://github.com/quicwg/base-drafts/pull/2402 = - #2390 removing stray ) (1 by seanturner) https://github.com/quicwg/base-drafts/pull/2390 [-tls] [editorial] = - #2025 Send an immediate ACK (1 by ianswett) https://github.com/quicwg/base-drafts/pull/2025 [-recovery] = 5 pull requests merged: - Change loss_detection_alarm.set() to update() https://github.com/quicwg/base-drafts/pull/2383 [-recovery] [editorial] = - Recovery editorial pass https://github.com/quicwg/base-drafts/pull/2381 = - Send an immediate ACK https://github.com/quicwg/base-drafts/pull/2025 [-recovery] [design] = - capitalizing destination connection ID https://github.com/quicwg/base-drafts/pull/2392 [-tls] [editorial] = - removing stray ) https://github.com/quicwg/base-drafts/pull/2391 [-tls] [editorial] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============2831666685510456790== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday February 03, 2019

Issues

quicwg/base-drafts (+8/-23/=F0=9F=92=AC156)

8 issues created:

69 issues received 156 new comments:

23 issues closed:

Pull requests

quicwg/base-drafts (+6/-5/=F0=9F=92=AC8)

6 pull requests submitted:

4 pull requests received 8 new comments:

5 pull requests merged:

Repositories tracked by this digest:

--===============2831666685510456790==-- From nobody Sun Feb 3 16:26:29 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E2E130DDA for ; Sun, 3 Feb 2019 16:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=WL9f2+ou; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pmBeD4Bu 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 Vy1NMsNDi6IZ for ; Sun, 3 Feb 2019 16:26:24 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECAD126F72 for ; Sun, 3 Feb 2019 16:26:24 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 48E7D1716; Sun, 3 Feb 2019 19:26:23 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 03 Feb 2019 19:26:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm1; bh=SlGNvxWIW+2448Pc/vAgGk5y5kW8lV QCLXbdPNZ+HLc=; b=WL9f2+ouT+QVySaMS+LoxG2eUO4rP5CsavnZ7jInCtAAxx ERiHnKhx6vBuSP/gKekocq+/coJYL6KMOHKBl1D7lmV1DtoYRULx2Wlcl4Xa6DBk l4oNKeLytJ06rkl/ChbmU1gdSPRS5wRgvzABCjehwfs3Tigmpig8sio/JFgRzXTu 1ak2NvqtPtVAY2mXuGTSkRp2S8pXMhz3kbj+F7mVzH7O9r5tvAVQDnTZBwXdHrb+ XV/6/8L4DPebbQzJI5xhkU/h9xUbGr3UxruT25TbuQJOG02GYnNZ0MBNTsqH8Wyt +75yp+rI5qiBIQTF50E+djCX+uvoo/IOb2hFfLSA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SlGNvx WIW+2448Pc/vAgGk5y5kW8lVQCLXbdPNZ+HLc=; b=pmBeD4Bu0uqcbIm8/1Koz0 wyZeTe0BqviAdbHZgHEbewqWOluOx+hF3S0bQnR1vCyQ9Q44UGVcOVE3FFNupH0i HZY+d0gP5i5aT/MjYtNBQhyzWH8zX9o21fy99VqnwScveTtqm0z+KZVsnsDzUPN3 UmAl0srW25B82+jotwWfhOa6jIpCGG0j9tGj0Gvon31hmY2ACIEHTbUZM9AHd1wp CyPwGG0aq9jmJBZA5YFJ1oBnDCBqsIjDFNSsllm4a2EdQrCzrYeWWWtyG3QAmh+H UB/0/SvxnrZDHzbBMelaYsRZXZPCzHFaUyQIxtjhEydjijP7eYPZ/88BufaFPM9A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeefgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephfgtgfgguffkff fvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehm nhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhmnh hothdrnhgvthenucfkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 70792E44F4; Sun, 3 Feb 2019 19:26:20 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: DRAFT minutes from the Tokyo interim Message-Id: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> Date: Mon, 4 Feb 2019 11:26:15 +1100 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 00:26:28 -0000 ... are up at: = https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minutes.m= d They still need some cleanup, but as always suggestions / corrections = welcome (ideally as a pull request, but e-mail also acceptable). Special thanks again to our scribes: Ted, Alex, Eric and Sean. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Feb 4 08:50:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC5E130E9B for ; Mon, 4 Feb 2019 08:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 stCIoy5o3-2K for ; Mon, 4 Feb 2019 08:50:52 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 74BC5130E86 for ; Mon, 4 Feb 2019 08:50:52 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id k19-v6so414282lji.11 for ; Mon, 04 Feb 2019 08:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc :content-transfer-encoding; bh=H6hklMydbDouFt+Yg3Fy6bvLEn47q68+TWHuUoQVK9E=; b=N9gm0H65FB2KTs5K3fTPwh9k7B4nLXP5szu2gfO6JFVVDAaNXYzGSeIgZDBQ0t0Z8e MG5BVIF7sPcyp0vdvP6zZWYsOvFum/FgO4SzPtwBj0THs5Y19W9CMvquwTsVkYeIo116 ctbUtzYk9yL7FVycmQrxU4iBu1MUDuOo+BCfjS3W7Q45mlNaGfMO04MIYMGG1sBg9Uj7 S7Fx2RYZmw0vCharDjeB3Tm2CLdjB2qLGuaFHjCVOpLF6HMDjVFLE1EMniFDLAH7T9K9 hEOLJYFjBecZ2eSdCEjQOW+Rcpk4QibrSEjASv+3p3rkcjnbzcXnm7Suokg/QZulp04+ 99Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc:content-transfer-encoding; bh=H6hklMydbDouFt+Yg3Fy6bvLEn47q68+TWHuUoQVK9E=; b=LekXEG3oPuAx/cpGi+t9HRK2qjzHy2/dvTUdkuqjijsrcULeN6sHRahz6OJKOR20MX 7Wo2mpjGmhntRIrZQ2gWJn/B1z5pfuBM4R7+/MuTjDkKIaNvtMXFcJJ5EMlnkXQrCAdQ xkgUadF3Aqh28aAcksntKf0YKmTMVLmt1cAWurS6v/cuBDv10MLjHLqyEj7Fw4pIEiO0 cuJ7LldES46QRCon1YaCZwjQq6JIl6TwlVq7iWsjznt9nSTVvykCHco/V3zraobtDCKv ABBm6FFDk1coQfys6Qt7gvB5hPYY4NOYInXLWiRn4iIUlEru5UMmiAhGdI2U0APHavq1 Z4kQ== X-Gm-Message-State: AHQUAuZgwcAKMGwEnjQcUY+6gyuveyqKKp48nzLpRt7iAy5F9KllOfeA H39XvH162U2WlQ6u6Cjq+OufwXg+sW2HEn7jvxZpqvYW X-Google-Smtp-Source: AHgI3IbsGS3w84LSlw5bC01uFIglfvlBrQoOXuOqOhuBraW7kFOmlj/BkUzHJCYnzdh486jQKu3Rk5WQSFdUe4s/PdA= X-Received: by 2002:a2e:9655:: with SMTP id z21-v6mr201446ljh.136.1549299050032; Mon, 04 Feb 2019 08:50:50 -0800 (PST) MIME-Version: 1.0 References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> In-Reply-To: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> From: Kazuho Oku Date: Tue, 5 Feb 2019 01:50:39 +0900 Message-ID: Subject: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 16:50:55 -0000 At Tokyo Interim, we concluded that reciprocal CID change was unnecessary [= 1]. However, during the discussion, I think we might have missed one important use-case of the feature; that is, enforce the peer to retire CIDs that were generated by an older generation of CID encryption key. We expect servers to rotate the CID encryption key periodically, or when the number space of CID gets exhausted. For a server to be able to rotate, it needs to be capable of either closing all the connections that use CIDs generated using an older generation of CID encryption key, or to ask the peer to start using a different CID that is generated using a newer generation of CID encryption key. By removing the feature that allows the server to request the peer to update the CID, the only capable way of a server retiring an CID encryption key would be to close the connections that either uses or might use CIDs generated by the older key. We might be fine with that, considering the fact that our target application is HTTP which has GOAWAY, a feature that can be used to gracefully shutdown a connection. However, I think we might consider otherwise, hence asking if we are fine with the decision we made in Tokyo. [1] https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minute= s.md#dont-change-cid-on-peer-cid-change 2019=E5=B9=B42=E6=9C=884=E6=97=A5(=E6=9C=88) 9:26 Mark Nottingham : > > .... are up at: > https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minute= s.md > > They still need some cleanup, but as always suggestions / corrections wel= come (ideally as a pull request, but e-mail also acceptable). > > Special thanks again to our scribes: Ted, Alex, Eric and Sean. > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > --=20 Kazuho Oku From nobody Mon Feb 4 14:51:47 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862DB1277D2 for ; Mon, 4 Feb 2019 14:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXbfp8R9Ib0i for ; Mon, 4 Feb 2019 14:51:42 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740134.outbound.protection.outlook.com [40.107.74.134]) (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 27547127598 for ; Mon, 4 Feb 2019 14:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gf4RDUFDmBoPt2efBf45BDjAC/YtMZg2eSwRqKmKGio=; b=XGqLAk42brGSHmerGMpc2pYYwUnQ8zuS7HEJzLzj375Bc6OFzn0VFIYYvuRGbKpAH1iBKicy9maPnLxu3plXTlraEIoqLaRZPoNa3d3R4p1+s+3sycn3m/ymLKrSpUsbbTa7y61V7yzQCZVDOhFfUlRnYl+vdLRy9SjioY0VT4k= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0760.namprd22.prod.outlook.com (10.171.170.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Mon, 4 Feb 2019 22:51:39 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2%4]) with mapi id 15.20.1558.021; Mon, 4 Feb 2019 22:51:39 +0000 From: Mike Bishop To: Kazuho Oku CC: IETF QUIC WG Subject: RE: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim Thread-Topic: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim Thread-Index: AQHUvCBNKAP+bFFRckKoGUKc9fhOIaXP20OAgABN6LA= Date: Mon, 4 Feb 2019 22:51:38 +0000 Message-ID: References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:20c5:f9da:44f2:b8c3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR22MB0760; 6:KXCOXN2hvKe9rsV356a0BjcTY/7t/WBmqqGSVYmhJHgt+19bWIv0H2QzT04UAHSO+lwV2goJ1JPV1VRb9Co1SUb+lg1b25m+TVNn7prnWJNl35MSYqsKh7cO2/Jqr1B4Ko9Sv1xs/M0WF4E/LIB3pBnHP3SHhTnW7IjMHUl4Wworh3rYThU/NNmmdYFkho91LR5eTL8dUZgYQYr8i5UIBrJd08ayeS+Up2kQUCQyJgkoSNfyLpcHwbb+l11IS1t6F8HsjMKC7Htn3d9HZGfxXgOj/SAaIypUZyELv+cZ3y0ni1fX1JWbv8zjihynUOKTgz1VOwNoPbFHkLcT9PIuGlwX1CqYj2RbRS8zhmGD36jEq3lr4vAglAlvvRuBpkchQVEyWfHpKRu9s73clh5JRYrIub6BAvsvZJ9LiXl9tJz/3DXvPqCUIntGtHMih5GQZW7dsoCnOaXUqEQS1kdWIg==; 5:/sAcnpwBY3uaTScg/yO/ie+U9LcB+uhXxPx1dA6pOkkmFxNPNh2U+WRJMMw9LpQulv5acRjulMS6e4jqOhJhRHZoo9RcB2IIAf6jKjIvpaiGQv2UOJIRnq2BF9zMjoim9Kdb+3SxQMA1v3Q9OMa9t5GUpznY0b6sf0bv6DA1mj/qsCYbvTSAlBb470LXx5FIc1yrEnuPIuXzePxAuK/h3Q==; 7:iaRBGBgwU1K0OClWIFu/VXzw2WC3J3O4YTyLEKBupM20YYSJTLgMSY9+1y+di43a/7pR8zQY2fY0CSSOo9D8rkqGH6QILDFOjesckOS7JqddlU7HJ1tI5yyf1cpmEAM2asMr0OKpZf6WjccLxMaM5Q== x-ms-office365-filtering-correlation-id: 98550d2c-caa9-4110-f57d-08d68af352ce x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0760; x-ms-traffictypediagnostic: CY4PR22MB0760: x-microsoft-antispam-prvs: x-forefront-prvs: 0938781D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(396003)(39830400003)(346002)(376002)(189003)(199004)(13464003)(106356001)(53936002)(508600001)(486006)(81166006)(7696005)(81156014)(105586002)(11346002)(446003)(8676002)(476003)(966005)(8936002)(6116002)(4326008)(790700001)(74482002)(76176011)(256004)(25786009)(14444005)(6506007)(6246003)(102836004)(74316002)(6436002)(2906002)(6916009)(71190400001)(71200400001)(229853002)(316002)(68736007)(186003)(99286004)(55016002)(46003)(236005)(14454004)(9686003)(33656002)(97736004)(7736002)(606006)(86362001)(54896002)(1411001)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0760; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: FMV02FWsCp3JBtx5UM3evErElYvECG0srelHKRMW+UizQAXdJMe41JBS3qTRgJdx7d7u1dlNV1Bwk8Nr6vxuXEjmJ7BfrdgQB3QqZcXOrf0WKDTwVKQ1OlfrPKvhClL5vojvilpuVsQqXzxzhCxPf4GyqJVddoeZpsxOSMPLm8FuCUYu9TohG9GBt/gEzfNCr7rzoJWr1dpFZ/+UrGsSeuLISMKlBGvhk4ojrkfMmNJvPnXEq31yLJYmt0PtSUSTU5lQiBBF8iDH9azhuXzfCzBNJS5OSCTKfi4qoeOqpdouPEVxq0jw/CtKYf5RnMuXpUP3gkmxNtllpG7PdVAKAjvKef6fmZ3J+SOB2KO6bSwiRv0GcptktExz6DDuegMRAK/9l5HBA4i4+PqFXMBIvn1mX3cWXDs1ZVzwMnjHBLM= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983047DFB2479E50A4B4F1CDA6D0CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 98550d2c-caa9-4110-f57d-08d68af352ce X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2019 22:51:38.7512 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0760 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 22:51:46 -0000 --_000_CY4PR22MB0983047DFB2479E50A4B4F1CDA6D0CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVhcmluZyBpbiBtaW5kIHRoYXQ6DQoNCiAgKiAgIHRoaXMgcm90YXRpb24gd2lsbCBob3BlZnVs bHkgYmUgaW5mcmVxdWVudA0KICAqICAgb25lIG9yIG1vcmUgQ0lEIGJpdHMgY2FuIGJlIHJlc2Vy dmVkIHRvIGluZGljYXRlIHRoZSBrZXkgZ2VuZXJhdGlvbiB1c2VkDQogICogICBjb25uZWN0aW9u cyBvbmx5IG5lZWQgdG8gYmUga2lsbGVkIHdoZW4gdGhleSB1c2Ugc29tZXRoaW5nIGZyb20gdGhl IG9sZGVzdCBnZW5lcmF0aW9uIHdoaWNoIGlzIG5vdyBiZWluZyByZXBsYWNlZA0KDQoNCg0KU2Vy dmVycyBjYW4gbWFuYWdlIHRoaXMgYnkga2VlcGluZyB0d28ga2V5cyAob25lIGJpdCksIG9yIGZv dXIgKHR3byBiaXRzKS4gIFRoYXQgc2hvdWxkIG1ha2UgaXQgcmVsYXRpdmVseSBpbmZyZXF1ZW50 IHRoYXQgYSBjb25uZWN0aW9uIGlzIHN0aWxsIGhvbGRpbmcgb24gdG8gYSBDSUQgZnJvbSB0aGUg b2xkZXN0IGdlbmVyYXRpb24gYWZ0ZXIgdGhleeKAmXZlIGFsbCBiZWVuIHJlcGxhY2VkLg0KDQoN Cg0KV29yc3QgY2FzZSwgdGhpcyBtaWdodCBiZSBhIHVzZSBjYXNlIGZvciB0aGUgUExFQVNFX1JF VElSRV9DSUQgZXh0ZW5zaW9uIHdlIGFsc28gdGFsa2VkIGFib3V0Lg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIEthenVobyBPa3UNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgNCwgMjAxOSA4OjUx IEFNDQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogIkRvbid0IGNo YW5nZSBDSUQgb24gcGVlciBDSUQgY2hhbmdlIiBSZTogRFJBRlQgbWludXRlcyBmcm9tIHRoZSBU b2t5byBpbnRlcmltDQoNCg0KDQpBdCBUb2t5byBJbnRlcmltLCB3ZSBjb25jbHVkZWQgdGhhdCBy ZWNpcHJvY2FsIENJRCBjaGFuZ2Ugd2FzIHVubmVjZXNzYXJ5IFsxXS4NCg0KDQoNCkhvd2V2ZXIs IGR1cmluZyB0aGUgZGlzY3Vzc2lvbiwgSSB0aGluayB3ZSBtaWdodCBoYXZlIG1pc3NlZCBvbmUg aW1wb3J0YW50IHVzZS1jYXNlIG9mIHRoZSBmZWF0dXJlOyB0aGF0IGlzLCBlbmZvcmNlIHRoZSBw ZWVyIHRvIHJldGlyZSBDSURzIHRoYXQgd2VyZSBnZW5lcmF0ZWQgYnkgYW4gb2xkZXIgZ2VuZXJh dGlvbiBvZiBDSUQgZW5jcnlwdGlvbiBrZXkuDQoNCg0KDQpXZSBleHBlY3Qgc2VydmVycyB0byBy b3RhdGUgdGhlIENJRCBlbmNyeXB0aW9uIGtleSBwZXJpb2RpY2FsbHksIG9yIHdoZW4gdGhlIG51 bWJlciBzcGFjZSBvZiBDSUQgZ2V0cyBleGhhdXN0ZWQuIEZvciBhIHNlcnZlciB0byBiZSBhYmxl IHRvIHJvdGF0ZSwgaXQgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiBlaXRoZXIgY2xvc2luZyBhbGwg dGhlIGNvbm5lY3Rpb25zIHRoYXQgdXNlIENJRHMgZ2VuZXJhdGVkIHVzaW5nIGFuIG9sZGVyIGdl bmVyYXRpb24gb2YgQ0lEIGVuY3J5cHRpb24ga2V5LCBvciB0byBhc2sgdGhlIHBlZXIgdG8gc3Rh cnQgdXNpbmcgYSBkaWZmZXJlbnQgQ0lEIHRoYXQgaXMgZ2VuZXJhdGVkIHVzaW5nIGEgbmV3ZXIg Z2VuZXJhdGlvbiBvZiBDSUQgZW5jcnlwdGlvbiBrZXkuDQoNCg0KDQpCeSByZW1vdmluZyB0aGUg ZmVhdHVyZSB0aGF0IGFsbG93cyB0aGUgc2VydmVyIHRvIHJlcXVlc3QgdGhlIHBlZXIgdG8gdXBk YXRlIHRoZSBDSUQsIHRoZSBvbmx5IGNhcGFibGUgd2F5IG9mIGEgc2VydmVyIHJldGlyaW5nIGFu IENJRCBlbmNyeXB0aW9uIGtleSB3b3VsZCBiZSB0byBjbG9zZSB0aGUgY29ubmVjdGlvbnMgdGhh dCBlaXRoZXIgdXNlcyBvciBtaWdodCB1c2UgQ0lEcyBnZW5lcmF0ZWQgYnkgdGhlIG9sZGVyIGtl eS4NCg0KDQoNCldlIG1pZ2h0IGJlIGZpbmUgd2l0aCB0aGF0LCBjb25zaWRlcmluZyB0aGUgZmFj dCB0aGF0IG91ciB0YXJnZXQgYXBwbGljYXRpb24gaXMgSFRUUCB3aGljaCBoYXMgR09BV0FZLCBh IGZlYXR1cmUgdGhhdCBjYW4gYmUgdXNlZCB0byBncmFjZWZ1bGx5IHNodXRkb3duIGEgY29ubmVj dGlvbi4NCg0KDQoNCkhvd2V2ZXIsIEkgdGhpbmsgd2UgbWlnaHQgY29uc2lkZXIgb3RoZXJ3aXNl LCBoZW5jZSBhc2tpbmcgaWYgd2UgYXJlIGZpbmUgd2l0aCB0aGUgZGVjaXNpb24gd2UgbWFkZSBp biBUb2t5by4NCg0KDQoNCg0KDQpbMV0gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy93Zy1tYXRl cmlhbHMvYmxvYi9tYXN0ZXIvaW50ZXJpbS0xOS0wMS9taW51dGVzLm1kI2RvbnQtY2hhbmdlLWNp ZC1vbi1wZWVyLWNpZC1jaGFuZ2UNCg0KDQoNCjIwMTnlubQy5pyINOaXpSjmnIgpIDk6MjYgTWFy ayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PG1haWx0bzptbm90QG1ub3QubmV0Pj46DQoNCj4N Cg0KPiAuLi4uIGFyZSB1cCBhdDoNCg0KPg0KDQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cv d2ctbWF0ZXJpYWxzL2Jsb2IvbWFzdGVyL2ludGVyaW0tMTktMDEvbWludXQNCg0KPiBlcy5tZA0K DQo+DQoNCj4gVGhleSBzdGlsbCBuZWVkIHNvbWUgY2xlYW51cCwgYnV0IGFzIGFsd2F5cyBzdWdn ZXN0aW9ucyAvIGNvcnJlY3Rpb25zIHdlbGNvbWUgKGlkZWFsbHkgYXMgYSBwdWxsIHJlcXVlc3Qs IGJ1dCBlLW1haWwgYWxzbyBhY2NlcHRhYmxlKS4NCg0KPg0KDQo+IFNwZWNpYWwgdGhhbmtzIGFn YWluIHRvIG91ciBzY3JpYmVzOiBUZWQsIEFsZXgsIEVyaWMgYW5kIFNlYW4uDQoNCj4NCg0KPiBD aGVlcnMsDQoNCj4NCg0KPg0KDQo+IC0tDQoNCj4gTWFyayBOb3R0aW5naGFtICAgaHR0cHM6Ly93 d3cubW5vdC5uZXQvDQoNCj4NCg0KDQoNCg0KDQotLQ0KDQpLYXp1aG8gT2t1DQoNCg0K --_000_CY4PR22MB0983047DFB2479E50A4B4F1CDA6D0CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYz QzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo1OTM1NjA5MzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE4MzM0ODU0NTAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZWFyaW5nIGluIG1p bmQgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+dGhpcyByb3RhdGlvbiB3aWxsIGhvcGVmdWxseSBiZSBpbmZyZXF1ZW50PG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPm9uZSBvciBtb3JlIENJRCBiaXRzIGNhbiBiZSByZXNlcnZlZCB0byBpbmRpY2F0 ZSB0aGUga2V5IGdlbmVyYXRpb24gdXNlZDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj5jb25uZWN0aW9ucyBvbmx5 IG5lZWQgdG8gYmUga2lsbGVkIHdoZW4gdGhleSB1c2Ugc29tZXRoaW5nIGZyb20gdGhlIG9sZGVz dCBnZW5lcmF0aW9uIHdoaWNoIGlzIG5vdyBiZWluZyByZXBsYWNlZDxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5TZXJ2ZXJzIGNhbiBtYW5hZ2UgdGhpcyBieSBrZWVwaW5nIHR3 byBrZXlzIChvbmUgYml0KSwgb3IgZm91ciAodHdvIGJpdHMpLiZuYnNwOyBUaGF0IHNob3VsZCBt YWtlIGl0IHJlbGF0aXZlbHkgaW5mcmVxdWVudCB0aGF0IGEgY29ubmVjdGlvbiBpcyBzdGlsbCBo b2xkaW5nIG9uIHRvIGEgQ0lEIGZyb20gdGhlIG9sZGVzdCBnZW5lcmF0aW9uIGFmdGVyIHRoZXni gJl2ZSBhbGwgYmVlbiByZXBsYWNlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V29y c3QgY2FzZSwgdGhpcyBtaWdodCBiZSBhIHVzZSBjYXNlIGZvciB0aGUgUExFQVNFX1JFVElSRV9D SUQgZXh0ZW5zaW9uIHdlIGFsc28gdGFsa2VkIGFib3V0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFFVSUMgJmx0O3F1 aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgT24gQmVoYWxmIE9mIEthenVobyBPa3U8YnI+DQpTZW50 OiBNb25kYXksIEZlYnJ1YXJ5IDQsIDIwMTkgODo1MSBBTTxicj4NCkNjOiBJRVRGIFFVSUMgV0cg Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVjdDogJnF1b3Q7RG9uJ3QgY2hhbmdlIENJ RCBvbiBwZWVyIENJRCBjaGFuZ2UmcXVvdDsgUmU6IERSQUZUIG1pbnV0ZXMgZnJvbSB0aGUgVG9r eW8gaW50ZXJpbTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QXQgVG9reW8gSW50ZXJpbSwgd2UgY29uY2x1 ZGVkIHRoYXQgcmVjaXByb2NhbCBDSUQgY2hhbmdlIHdhcyB1bm5lY2Vzc2FyeSBbMV0uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhvd2V2ZXIsIGR1cmluZyB0aGUgZGlzY3Vzc2lvbiwg SSB0aGluayB3ZSBtaWdodCBoYXZlIG1pc3NlZCBvbmUgaW1wb3J0YW50IHVzZS1jYXNlIG9mIHRo ZSBmZWF0dXJlOyB0aGF0IGlzLCBlbmZvcmNlIHRoZSBwZWVyIHRvIHJldGlyZSBDSURzIHRoYXQg d2VyZSBnZW5lcmF0ZWQgYnkgYW4gb2xkZXIgZ2VuZXJhdGlvbiBvZiBDSUQgZW5jcnlwdGlvbiBr ZXkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldlIGV4cGVjdCBzZXJ2ZXJzIHRvIHJv dGF0ZSB0aGUgQ0lEIGVuY3J5cHRpb24ga2V5IHBlcmlvZGljYWxseSwgb3Igd2hlbiB0aGUgbnVt YmVyIHNwYWNlIG9mIENJRCBnZXRzIGV4aGF1c3RlZC4gRm9yIGEgc2VydmVyIHRvIGJlIGFibGUg dG8gcm90YXRlLCBpdCBuZWVkcyB0byBiZSBjYXBhYmxlIG9mIGVpdGhlciBjbG9zaW5nIGFsbCB0 aGUgY29ubmVjdGlvbnMgdGhhdCB1c2UgQ0lEcyBnZW5lcmF0ZWQNCiB1c2luZyBhbiBvbGRlciBn ZW5lcmF0aW9uIG9mIENJRCBlbmNyeXB0aW9uIGtleSwgb3IgdG8gYXNrIHRoZSBwZWVyIHRvIHN0 YXJ0IHVzaW5nIGEgZGlmZmVyZW50IENJRCB0aGF0IGlzIGdlbmVyYXRlZCB1c2luZyBhIG5ld2Vy IGdlbmVyYXRpb24gb2YgQ0lEIGVuY3J5cHRpb24ga2V5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5CeSByZW1vdmluZyB0aGUgZmVhdHVyZSB0aGF0IGFsbG93cyB0aGUgc2VydmVyIHRv IHJlcXVlc3QgdGhlIHBlZXIgdG8gdXBkYXRlIHRoZSBDSUQsIHRoZSBvbmx5IGNhcGFibGUgd2F5 IG9mIGEgc2VydmVyIHJldGlyaW5nIGFuIENJRCBlbmNyeXB0aW9uIGtleSB3b3VsZCBiZSB0byBj bG9zZSB0aGUgY29ubmVjdGlvbnMgdGhhdCBlaXRoZXIgdXNlcyBvciBtaWdodCB1c2UgQ0lEcyBn ZW5lcmF0ZWQgYnkgdGhlDQogb2xkZXIga2V5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5XZSBtaWdodCBiZSBmaW5lIHdpdGggdGhhdCwgY29uc2lkZXJpbmcgdGhlIGZhY3QgdGhhdCBv dXIgdGFyZ2V0IGFwcGxpY2F0aW9uIGlzIEhUVFAgd2hpY2ggaGFzIEdPQVdBWSwgYSBmZWF0dXJl IHRoYXQgY2FuIGJlIHVzZWQgdG8gZ3JhY2VmdWxseSBzaHV0ZG93biBhIGNvbm5lY3Rpb24uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhvd2V2ZXIsIEkgdGhpbmsgd2UgbWlnaHQgY29u c2lkZXIgb3RoZXJ3aXNlLCBoZW5jZSBhc2tpbmcgaWYgd2UgYXJlIGZpbmUgd2l0aCB0aGUgZGVj aXNpb24gd2UgbWFkZSBpbiBUb2t5by48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bMV0gPGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy93Zy1tYXRlcmlhbHMvYmxvYi9tYXN0ZXIvaW50ZXJp bS0xOS0wMS9taW51dGVzLm1kI2RvbnQtY2hhbmdlLWNpZC1vbi1wZWVyLWNpZC1jaGFuZ2UiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBz Oi8vZ2l0aHViLmNvbS9xdWljd2cvd2ctbWF0ZXJpYWxzL2Jsb2IvbWFzdGVyL2ludGVyaW0tMTkt MDEvbWludXRlcy5tZCNkb250LWNoYW5nZS1jaWQtb24tcGVlci1jaWQtY2hhbmdlPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MjAxOTxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuW5tDwvc3Bhbj4yPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPjQ8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj4pIDk6MjYgTWFyayBO b3R0aW5naGFtICZsdDs8YSBocmVmPSJtYWlsdG86bW5vdEBtbm90Lm5ldCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1ub3RAbW5vdC5uZXQ8L3Nw YW4+PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IC4uLi4g YXJlIHVwIGF0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZu YnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy93Zy1tYXRlcmlhbHMvYmxvYi9tYXN0 ZXIvaW50ZXJpbS0xOS0wMS9taW51dCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy93Zy1tYXRlcmlh bHMvYmxvYi9tYXN0ZXIvaW50ZXJpbS0xOS0wMS9taW51dDwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGVzLm1kPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZXkgc3RpbGwgbmVlZCBzb21lIGNsZWFudXAsIGJ1dCBh cyBhbHdheXMgc3VnZ2VzdGlvbnMgLyBjb3JyZWN0aW9ucyB3ZWxjb21lIChpZGVhbGx5IGFzIGEg cHVsbCByZXF1ZXN0LCBidXQgZS1tYWlsIGFsc28gYWNjZXB0YWJsZSkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNwZWNpYWwgdGhhbmtzIGFnYWluIHRvIG91ciBzY3Jp YmVzOiBUZWQsIEFsZXgsIEVyaWMgYW5kIFNlYW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IENoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgLS08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgTWFyayBOb3R0aW5n aGFtJm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lm1ub3QubmV0LyI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3Lm1u b3QubmV0Lzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkthenVobyBPa3U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CY4PR22MB0983047DFB2479E50A4B4F1CDA6D0CY4PR22MB0983namp_-- From nobody Mon Feb 4 15:15:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABDC12870E for ; Mon, 4 Feb 2019 15:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=htEat23Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G8BRThLF 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 ZjnvBvN2yzBX for ; Mon, 4 Feb 2019 15:15:15 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB5A12426E for ; Mon, 4 Feb 2019 15:15:15 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 508DA221EE for ; Mon, 4 Feb 2019 18:15:14 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Mon, 04 Feb 2019 18:15:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:date:subject; s=fm1; bh=30QyO8VpnmGd8D72ymjHxTyds5 GvTA8zmAsa2Z9sIyc=; b=htEat23Y4U0DPAA9wfMw40ZCgQcE4b1wY4G7E1QGTl GqSOcCwelDIRKTwnK5Ukyd0Z0Xs5GrkjqG3vob002eU8d0k3yF9K0miA1I7dNQFl 4+tseNQgA/1BLalVS9fXChFPk0fGSrvmVQc+qtAlL4bn6Dy6P1s24OXIHPbDjILa 9RMZFi92WA9dJZngWi85WEiTNBSk7+nT9V9D5ViZR0KOIj4XNoXn66g4PMTuJoCk bp1Gx/yi86ngAiIUkj6PxZgKYPnTZXeT7sJooEke4mTud/UR0Fxl7YXS3ih5Txdo j/+6AQWHyJ4AeSK+mT56OxL++ZupUoneleV9oses3WGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=30QyO8 VpnmGd8D72ymjHxTyds5GvTA8zmAsa2Z9sIyc=; b=G8BRThLFRn1+K0ppjQjsq0 dPt2KVNsXdkTn/FHbmFc9qZWSBedBltEsNuX2lRxBybDdQZxPtn8kmAsh2p1D9PS yUiw4JPgj9VDIBaegiYvhk5s2iralBklDEWuLwDQJI8xojRhLRAVwdX4UVxuVUc2 AzToqIu+S8IrUixoO6+Pf7aZTg+e2e9ojUQJkxjWN104QHN9Xu2+XH6imOvn1qyR 93g829uohKzg4DN+jhF1q2iRsIskwqWa6oiZUevYObT9rwhjrx20yxIcPztabXIC /e2qrgmbDhiawWllFEmXKEnCy3Z+3qaQ99LCiVihaB5Kt0y7mmYhC2vdK5/I/osA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeehgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucgoteefjeefqddtgeculdehtddmnecujfgurhepkffhvfgggfgtofffufesthejre dtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D6C2A9E539; Mon, 4 Feb 2019 18:15:13 -0500 (EST) Message-Id: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ec01da05 Date: Tue, 05 Feb 2019 10:15:13 +1100 Subject: New path => new connection ID, right? Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 23:15:17 -0000 I thought that we had agreed that an endpoint that intentionally migrates has to use a new connection ID on the new path. But I couldn't find any "MUST" in the spec that said that. On the off chance that this wasn't just a mistake and there was some good reason not to mandate this, I'm bringing the discussion here. I've opened a design issue: https://github.com/quicwg/base-drafts/issues/2413 The change I'm proposing is here: https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995236dda960b4cdff49e36f From nobody Mon Feb 4 16:18:12 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBBD129B88 for ; Mon, 4 Feb 2019 16:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=lt+TxCke; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z3FtkmDE 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 cV0qzJgiwdDR for ; Mon, 4 Feb 2019 16:18:08 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2D31294FA for ; Mon, 4 Feb 2019 16:18:08 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5ACF421BE2 for ; Mon, 4 Feb 2019 19:18:07 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Mon, 04 Feb 2019 19:18:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=+VQ uN8LVtGG9ZMCkxPXb78V2zDc+pFp076/fgW+HkhY=; b=lt+TxCkekwWjqt29kBV STmInTvqSKHQXsht85jKOKTul5qvAZFAC+BB5bMJfFzmIV3a81aozLGbVh/UTPBK 8jC/YFEKQCPJ5ikQcqmqRjnKh2tx1LFea0rUxD+GqKlbuI4GoNoTNq1nq2TRTH7e bw3ds8MgEoYPlxC39QhOg6aTWs8mCgs2NvQz5iQKQY7DXf4TrSsidZltqwiGTEb0 wHCeRNkMO3ioE4jN75t2CSU1hDRO1XFSrITAChq4C5YSHrhmf9qks+Ymm8h75vAE jm7WZOsNe2yfliq30J3cl1kTU1AwlzI+QHTQMFMzXOYSpFeLmTn+B8VPbH/FLmpy kSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=+VQuN8LVtGG9ZMCkxPXb78V2zDc+pFp076/fgW+Hk hY=; b=Z3FtkmDEm+MNC380xSPT2iuKxsSUmSVumba23/8dYeFt2ognTsgfdT3ef cV4SL5Yph5xVmtdhg6QNqAVsqjYXbNRZY1h/S7pTeG79e+8LaXSYnlw0Orc9+Tpj /yNeeRfsnqpM3YIBPY3YFih/s5pX3g1ChwCKAy3ZRfgIxo32zEj4xFswmSIpssJC N8hFddEc0rQG51wLFd/aXFTlHwwMLZ3S1aHek7Kpo4oju5Ja4QdENgQAHdoPC4Qv 0+cIi4VGgJitVPWd3PNZ9cPKsdx/k3sxMV+LbhimFxEzUKEIHz8OWUvp2yUqB8lU rheSR/zbv2r9sIjnwTtXwMt3mxXlQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeehgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfofhfujgffsehtqhertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 740DE9E539; Mon, 4 Feb 2019 19:18:06 -0500 (EST) Message-Id: <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ec01da05 References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> Subject: Re: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim In-Reply-To: Date: Tue, 05 Feb 2019 11:18:06 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 00:18:10 -0000 On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote: > Bearing in mind that: >=20 > * this rotation will hopefully be infrequent > * one or more CID bits can be reserved to indicate the key=20 > generation used > * connections only need to be killed when they use something from=20 > the oldest generation which is now being replaced >=20 > Servers can manage this by keeping two keys (one bit), or four (two=20 > bits). That should make it relatively infrequent that a connection is=20 > still holding on to a CID from the oldest generation after they=E2=80=99v= e all=20 > been replaced. >=20 > Worst case, this might be a use case for the PLEASE_RETIRE_CID extension= =20 > we also talked about. Mike's analysis is correct. I would prefer not to do anything about this c= ase. For now, that means that if servers rotate keys, that will set an upper bou= nd on the lifetime of a connection. I think that's tolerable. From nobody Mon Feb 4 16:56:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E07130EE7 for ; Mon, 4 Feb 2019 16:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTzraHPSbvAz for ; Mon, 4 Feb 2019 16:56:22 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680133.outbound.protection.outlook.com [40.107.68.133]) (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 DFCD8130DD3 for ; Mon, 4 Feb 2019 16:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=paBLWlLajzrKktyhsMJpIce+9c6HGb8BBrGPDR4y2CM=; b=icU3hNQTC7MgC2Bex8q+29uhcuJHpjl6DrkZnKAJLQ5LujL80NbjuGuYasKHYnuemQmDGu0T57wvDfcL0/Dua/V1h25U0K2tr/VZT3DqmIDBo9nUYTBrl3VhV338Mo1KFOZ0YDJZQbpQCHoD7fYleLJUOU9yvMG9vxomTFysow8= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB1000.namprd22.prod.outlook.com (10.172.142.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.20; Tue, 5 Feb 2019 00:56:17 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2%4]) with mapi id 15.20.1558.021; Tue, 5 Feb 2019 00:56:17 +0000 From: Mike Bishop To: Martin Thomson , "quic@ietf.org" Subject: RE: New path => new connection ID, right? Thread-Topic: New path => new connection ID, right? Thread-Index: AQHUvN+Hdo9IVj+onk2j/wqF4V0HsaXQYHNg Date: Tue, 5 Feb 2019 00:56:16 +0000 Message-ID: References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> In-Reply-To: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:20c5:f9da:44f2:b8c3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR22MB1000; 6:5Adx5tOalNMECvLAgUprva1X93ejqMMjKSOMEsgLligD9lBUt+keJieGRY46kw6mEdcsZiRQNMKLTBRID9peSWFWCwWsJCDF+MAi0Jm2YPhNuTtiCZ09rs5LvSOziQm9x2jnyt0qJy3ovXOsNfUuZ7BjoacuSKSNLW/rhk7RPjfdunVgF1cQEIBBasM/wQIFy0oqcclmgyWQ33L4hj+PB6kIk6Olom0V8DNUnPXMw83SmKV5G/GoYjXEwgd9le1RD02JWO/AfwOXZXdurLv+yCYHEXICVwB0etRCO9CnswdorPIk+JCKyXORNX60ZVyyvmeQ4A270iaCIvATMFSyUwE581eQuBr/a9XNCTk8bTSOG/JtPhleXPj09kiakPhj0aJ2lnnXnmVqyupl9WDL/Oqh6pTdMEtHYz/5jo9NOXlufG49x+0NgnVwr3tID8UBDQKfvYkhJEi5+UiJmsio3w==; 5:iDLbZTZSC8lDnM3vSHKx48U6Ry8a/H4hfHWcaUEzb0fJ/cKbgJfsoCB6b3mvtrnIP+5+bcWO7aH68463OE734V/7JktreS/xqsrI+j9mhzG2NsKes+vvfuyXRrxSO6nG6baClPL25E7YpA70x7YxBBIpvfUSFPK7ziMlHgOGemPV+IWj2UnC0xqcwNE1Gb0zPUhB1nSjSzv8G6s5biAm0Q==; 7:YogwUuhxklj0GEHqvtVggwfymfhzG8+XmLrhX3BhAlHoXmYWKEZZUSXpVov7wrNxbKXq+8p8VwRIO1DiPK2Uw/Hd31D/ggDG/2ECKAeCb6jXUyPz0BIY3IUFbi9t8L+atanKQ2DG12bQp7Z6gvO+dw== x-ms-office365-filtering-correlation-id: 2f8f9d84-0ea6-4733-46a8-08d68b04bc49 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB1000; x-ms-traffictypediagnostic: CY4PR22MB1000: x-microsoft-antispam-prvs: x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(396003)(376002)(366004)(39830400003)(13464003)(199004)(189003)(25786009)(508600001)(14454004)(2906002)(966005)(256004)(229853002)(105586002)(106356001)(446003)(55016002)(7736002)(236005)(9686003)(54896002)(6306002)(8676002)(74482002)(6246003)(11346002)(53546011)(53936002)(81156014)(97736004)(68736007)(8936002)(6436002)(33656002)(81166006)(2501003)(7696005)(186003)(6506007)(102836004)(76176011)(110136005)(86362001)(486006)(606006)(99286004)(71200400001)(74316002)(71190400001)(316002)(46003)(6116002)(476003)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB1000; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: qqHdubUTIqDJd7fHPOBaoeI4JPsYbswjwq8qfRl7c6Ijtu43mDUdneESTVNAK7I1TB+egmd6YhPR2D0X2kwh1yp3hYa4tyaMzJAd3pk3iJg58k+KlGdioZbX7QZokmblIYY3rzAouhqrygNVXo63eNWng2UvTEH/l3UL929hoiWTqUGodoubvqB4ORNED/iYQUlx6vb3OUNkDFySTgnFtKbPvuaQDGU2CHed8vH/x1l4yHEyqfg+EmEiwk6NRgUr9LgdgTDDrVZ+0lNTGR5BYfCgl8I7jnS+V6XcPsFg676goJ0oP9+CiZyOvCjDjuMm5Bbc57MucMgbpK2PUcI4LusFQFh7JEOkT0dEFo1oE+AaMr63zeZ6IL5Cop4G4wz+45KDbMz3lnASBBM0A9Rz63HgdLRjKXt7asDCEz0zXdU= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB098312FC5A79F522B2A8CC74DA6E0CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 2f8f9d84-0ea6-4733-46a8-08d68b04bc49 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2019 00:56:16.8988 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB1000 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 00:56:25 -0000 --_000_CY4PR22MB098312FC5A79F522B2A8CC74DA6E0CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHRleHQgaXMgdGhlcmUsIGJ1dCBpdCdzIHBlcmhhcHMgbm90IGNvbXBsZXRlOg0KDQpBcyBk aXNjdXNzZWQgaW4gU2VjdGlvbiA5LjUsIGVhY2ggY29ubmVjdGlvbiBJRCBNVVNUIGJlIHVzZWQg b24gcGFja2V0cyBzZW50IGZyb20gb25seSBvbmUgbG9jYWwgYWRkcmVzcy4gQW4gZW5kcG9pbnQg dGhhdCBtaWdyYXRlcyBhd2F5IGZyb20gYSBsb2NhbCBhZGRyZXNzIFNIT1VMRCByZXRpcmUgYWxs IGNvbm5lY3Rpb24gSURzIHVzZWQgb24gdGhhdCBhZGRyZXNzIG9uY2UgaXQgbm8gbG9uZ2VyIHBs YW5zIHRvIHVzZSB0aGF0IGFkZHJlc3MuDQoNCg0KDQpUaGUgZ2FwIHNlZW1zIHRvIGJlIHRoYXQg d2hlbiB5b3VyIHBlZXIgbW92ZXMgdG8gYSBuZXcgYWRkcmVzcywgdGhlcmXigJlzIG5vIHJlcXVp cmVtZW50IHRoYXQgeW91IG5vdCBzZW5kIHRoZSBzYW1lIENJRCB0byB0aGVpciBuZXcgYWRkcmVz cyB0aGF0IHlvdSB1c2VkIHRvd2FyZCB0aGVpciBvbGQgYWRkcmVzcy4NCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA0LCAyMDE5 IDM6MTUgUE0NClRvOiBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBOZXcgcGF0aCA9PiBuZXcgY29u bmVjdGlvbiBJRCwgcmlnaHQ/DQoNCg0KDQpJIHRob3VnaHQgdGhhdCB3ZSBoYWQgYWdyZWVkIHRo YXQgYW4gZW5kcG9pbnQgdGhhdCBpbnRlbnRpb25hbGx5IG1pZ3JhdGVzIGhhcyB0byB1c2UgYSBu ZXcgY29ubmVjdGlvbiBJRCBvbiB0aGUgbmV3IHBhdGguICBCdXQgSSBjb3VsZG4ndCBmaW5kIGFu eSAiTVVTVCIgaW4gdGhlIHNwZWMgdGhhdCBzYWlkIHRoYXQuDQoNCg0KDQpPbiB0aGUgb2ZmIGNo YW5jZSB0aGF0IHRoaXMgd2Fzbid0IGp1c3QgYSBtaXN0YWtlIGFuZCB0aGVyZSB3YXMgc29tZSBn b29kIHJlYXNvbiBub3QgdG8gbWFuZGF0ZSB0aGlzLCBJJ20gYnJpbmdpbmcgdGhlIGRpc2N1c3Np b24gaGVyZS4NCg0KDQoNCkkndmUgb3BlbmVkIGEgZGVzaWduIGlzc3VlOg0KDQpodHRwczovL2dp dGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8yNDEzDQoNCg0KDQpUaGUgY2hhbmdl IEknbSBwcm9wb3NpbmcgaXMgaGVyZToNCg0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNl LWRyYWZ0cy9wdWxsLzI0MTQvY29tbWl0cy8xMzY5OGNiZTMxMTkyMmEzOTk1MjM2ZGRhOTYwYjRj ZGZmNDllMzZmDQoNCg0K --_000_CY4PR22MB098312FC5A79F522B2A8CC74DA6E0CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgdGV4dCBpcyB0aGVyZSwgYnV0IGl0 J3MgcGVyaGFwcyBub3QgY29tcGxldGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24g OS41LCBlYWNoIGNvbm5lY3Rpb24gSUQgTVVTVCBiZSB1c2VkIG9uIHBhY2tldHMgc2VudCBmcm9t IG9ubHkgb25lIGxvY2FsIGFkZHJlc3MuIEFuIGVuZHBvaW50IHRoYXQgbWlncmF0ZXMgYXdheSBm cm9tIGEgbG9jYWwgYWRkcmVzcyBTSE9VTEQgcmV0aXJlIGFsbCBjb25uZWN0aW9uIElEcyB1c2Vk IG9uIHRoYXQgYWRkcmVzcw0KIG9uY2UgaXQgbm8gbG9uZ2VyIHBsYW5zIHRvIHVzZSB0aGF0IGFk ZHJlc3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBnYXAgc2VlbXMgdG8gYmUg dGhhdCB3aGVuIHlvdXIgcGVlciBtb3ZlcyB0byBhIG5ldyBhZGRyZXNzLCB0aGVyZeKAmXMgbm8g cmVxdWlyZW1lbnQgdGhhdCB5b3Ugbm90IHNlbmQgdGhlIHNhbWUgQ0lEIHRvIHRoZWlyIG5ldyBh ZGRyZXNzIHRoYXQgeW91IHVzZWQgdG93YXJkIHRoZWlyIG9sZCBhZGRyZXNzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IFFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgT24gQmVoYWxmIE9mIE1hcnRpbiBU aG9tc29uPGJyPg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA0LCAyMDE5IDM6MTUgUE08YnI+DQpU bzogcXVpY0BpZXRmLm9yZzxicj4NClN1YmplY3Q6IE5ldyBwYXRoID0mZ3Q7IG5ldyBjb25uZWN0 aW9uIElELCByaWdodD88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgdGhvdWdodCB0aGF0IHdlIGhhZCBh Z3JlZWQgdGhhdCBhbiBlbmRwb2ludCB0aGF0IGludGVudGlvbmFsbHkgbWlncmF0ZXMgaGFzIHRv IHVzZSBhIG5ldyBjb25uZWN0aW9uIElEIG9uIHRoZSBuZXcgcGF0aC4mbmJzcDsgQnV0IEkgY291 bGRuJ3QgZmluZCBhbnkgJnF1b3Q7TVVTVCZxdW90OyBpbiB0aGUgc3BlYyB0aGF0IHNhaWQgdGhh dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gdGhlIG9mZiBjaGFuY2UgdGhhdCB0 aGlzIHdhc24ndCBqdXN0IGEgbWlzdGFrZSBhbmQgdGhlcmUgd2FzIHNvbWUgZ29vZCByZWFzb24g bm90IHRvIG1hbmRhdGUgdGhpcywgSSdtIGJyaW5naW5nIHRoZSBkaXNjdXNzaW9uIGhlcmUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkndmUgb3BlbmVkIGEgZGVzaWduIGlzc3VlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjQxMyI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZ2l0aHViLmNvbS9x dWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzI0MTM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5UaGUgY2hhbmdlIEknbSBwcm9wb3NpbmcgaXMgaGVyZTo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8yNDE0L2NvbW1pdHMvMTM2OThjYmUzMTE5MjJhMzk5 NTIzNmRkYTk2MGI0Y2RmZjQ5ZTM2ZiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMv cHVsbC8yNDE0L2NvbW1pdHMvMTM2OThjYmUzMTE5MjJhMzk5NTIzNmRkYTk2MGI0Y2RmZjQ5ZTM2 Zjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR22MB098312FC5A79F522B2A8CC74DA6E0CY4PR22MB0983namp_-- From nobody Mon Feb 4 17:08:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F9F130DDA for ; Mon, 4 Feb 2019 17:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, 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 (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 eeiPgZDErJL4 for ; Mon, 4 Feb 2019 17:08:21 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 48B27130DD3 for ; Mon, 4 Feb 2019 17:08:21 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id r136so750268pfc.6 for ; Mon, 04 Feb 2019 17:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CaUeB1EUjUcJImoFAQy0jrz2l/ST7Ynn/2dzMzhXUqM=; b=tvVjwV+xCcNnpTKsrCqQ1pZYT9TYo4nVJGHo2Onm5d3WekFhUbHB801UXfkg2NOjPE 4Zs2UTvoxDhE5ITCvnk+kXCqX+IbPdhESPgrX34uAgyCv+ftl6uxUAsCSyDbFpk1F1ke taLCZ0n1R2cRVesuxlgiTr88FpP66uqoYcT447UOzPBOWHIsnYP/w58J77mJ3rX4+ChB QgxkIJfnS+yPzwKDezs+Z7HutgwTVLpvdgnm6CpxqHrJR0x1YZT2NQneanH0Wsq2jcbP FOGYzOpy2/BF9gwXJZbiA4CsIOZUBQbpaU5CXYJMU/mXbNzGxH/N/3QeqCJz9WOAbuH8 bCew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CaUeB1EUjUcJImoFAQy0jrz2l/ST7Ynn/2dzMzhXUqM=; b=MQWZ3YCuN2kMGkaHke7B+aBxRKyDbzdxNa+VUIJVsinC2f4lBmqksFxoyrD2JlJgzz lNjAVIUEwdW5yRC9mL6f53fLVOmssso/cz+9ojnqHgW8bt25dYEIqJC3K6brHTigLf5j qcG7aUxDRX0GYxBv1SEk0O5XboDHmbriA5pNeZRzsSmF+hfLdO57LT1X7zftKYfSwg3T 8pt+T5OIHBbD3xCE1rnX84SWJDMDCaDXkA2Cwi+9fTib01RNfr2RBZLTzNUy7iv17KBp pQ2acG4Is4f77ZOD5XcL81DCPmyBLKQQdkjiJEcp1SgN4jEA/dZmtHFhQHo6+1JwWY/A Hnsw== X-Gm-Message-State: AHQUAuYnY/DkrtnmJSLOmf5yS2r7apQX6QpjF/r/w+TZ0luSvnwuS615 H1nJ/pv7nqOBktR2HKwEj+yt0Ba1ivJ06Ib0+5HcPUPh X-Google-Smtp-Source: AHgI3IYc0ijt3hZfXhVB2rGp0Fg8Cz3Wjhv+ksEM+gfGGZLCiAfclqypRwYmwyr6xXSbIo5Mj2i3iY1tvj06gMEv8s4= X-Received: by 2002:a63:4f20:: with SMTP id d32mr2065084pgb.47.1549328900746; Mon, 04 Feb 2019 17:08:20 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> In-Reply-To: From: David Schinazi Date: Mon, 4 Feb 2019 17:08:09 -0800 Message-ID: Subject: Re: New path => new connection ID, right? To: Mike Bishop Cc: Martin Thomson , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c4f19605811b3eb5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 01:08:24 -0000 --000000000000c4f19605811b3eb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If an endpoint intentionally migrates and it has unused connection IDs to use, it makes sense to mandate it MUST switch to one of the unused connection IDs. However, if it has run out of unused connection IDs then I would let the endpoint decide if it wants to close the connection or migrate with a previously used connection IDs, as there are use-cases that value performance over non-linkability. Finally, this cannot be enforced by the peer since it cannot distinguish intentional migration and unintentional migration (NAT rebinding), and we discussed in Tokyo that we wanted to avoid non-enforceable MUSTs. David On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop wrote: > The text is there, but it's perhaps not complete: > > As discussed in Section 9.5, each connection ID MUST be used on packets > sent from only one local address. An endpoint that migrates away from a > local address SHOULD retire all connection IDs used on that address once = it > no longer plans to use that address. > > > > The gap seems to be that when your peer moves to a new address, there=E2= =80=99s no > requirement that you not send the same CID to their new address that you > used toward their old address. > > > > -----Original Message----- > From: QUIC On Behalf Of Martin Thomson > Sent: Monday, February 4, 2019 3:15 PM > To: quic@ietf.org > Subject: New path =3D> new connection ID, right? > > > > I thought that we had agreed that an endpoint that intentionally migrates > has to use a new connection ID on the new path. But I couldn't find any > "MUST" in the spec that said that. > > > > On the off chance that this wasn't just a mistake and there was some good > reason not to mandate this, I'm bringing the discussion here. > > > > I've opened a design issue: > > https://github.com/quicwg/base-drafts/issues/2413 > > > > The change I'm proposing is here: > > > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a39= 95236dda960b4cdff49e36f > > > --000000000000c4f19605811b3eb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If an endpoint intentionally migrates and it has unused co= nnection IDs to use, it makes sense to mandate it MUST switch to one of the= unused connection IDs.
However, if it has run out of unused connection= IDs then I would let the endpoint decide if it wants to close the connecti= on or migrate with a previously used connection IDs, as there are use-cases= that value performance over non-linkability. Finally, this cannot be enfor= ced by the peer since it cannot distinguish intentional migration and unint= entional migration (NAT rebinding), and we discussed in Tokyo that we wante= d to avoid non-enforceable MUSTs.

David

On Mo= n, Feb 4, 2019 at 4:56 PM Mike Bishop <mbishop@evequefou.be> wrote:

The text is there, but= it's perhaps not complete:

As discussed in Section 9.5, each connection ID MUST be used on packe= ts sent from only one local address. An endpoint that migrates away from a = local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address.

=C2=A0

The gap seems to be th= at when your peer moves to a new address, there=E2=80=99s no requirement th= at you not send the same CID to their new address that you used toward thei= r old address.

=C2=A0

-----Original Message-= ----
From: QUIC <q= uic-bounces@ietf.org> On Behalf Of Martin Thomson
Sent: Monday, February 4, 2019 3:15 PM
To: quic@ietf.org Subject: New path =3D> new connection ID, right?

=C2=A0

I thought that we had = agreed that an endpoint that intentionally migrates has to use a new connec= tion ID on the new path.=C2=A0 But I couldn't find any "MUST"= in the spec that said that.

=C2=A0

On the off chance that= this wasn't just a mistake and there was some good reason not to manda= te this, I'm bringing the discussion here.

=C2=A0

I've opened a desi= gn issue:

https://github.com/quicwg/base-drafts/= issues/2413

=C2=A0

The change I'm pro= posing is here:

https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe31= 1922a3995236dda960b4cdff49e36f

=C2=A0

--000000000000c4f19605811b3eb5-- From nobody Mon Feb 4 17:30:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C117B130E00 for ; Mon, 4 Feb 2019 17:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38v_GBKBYkq2 for ; Mon, 4 Feb 2019 17:30:23 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C328F130DF6 for ; Mon, 4 Feb 2019 17:30:22 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id l142so1462107lfe.2 for ; Mon, 04 Feb 2019 17:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n9gEcIxsHm4yiN2rmGcgHlHRl3KONj/pAPsCrlevsxA=; b=hi01nyizcXB3EGp290E3ev1N4S7uTf045K+OjSZ7uHnXpH3UKjiCzcPCM9F59pNNal +UUZAtE+/RiiV0y8+rJ9jsCqtQjO3AlgzS1Nk/F4olXUg7JJyo8bMpiWHtgWyaS2qZn4 SbRN6hUHzL7lesOJ+ROpiS4wOgUEoM+DBZWEIJTv0nW9bAsr9CFGOQFdaZUlZVshEtbs LgpuqkPpvumSUrcnVcwthhkNKv6WHJLvK9MhGapOtqtVfBuB7ySv0393OVQH1p66gS+n ts8uaTPN+vmglgmK+vQGkHZdJRURZUeueFSUBUFz8ctm7Wv5BAyLGggjvrQsFteuIzH7 5cIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n9gEcIxsHm4yiN2rmGcgHlHRl3KONj/pAPsCrlevsxA=; b=fatKT6JVXWaFZr5wmj6ZOvKeCuo+nc8tyfdUos4OFXOMSBCOWKfYH3BFK4MWRYkAGF Nu2AYmyeGhrwTNJi5T0ONR0DY3Sog17FQAUs+yrl149jDZaJiOljsgFJp+j/E+huCQDI eHbJ2bYvBg1evDguRmlncxDsTaTkMgAZJ7yn9BeRHKbAq0NGlfwVSNCqLrxtXHbYtA/Q yoY5RKlYJx3mfAsIIn0VFZ1nvMGuhl791hLr8rWfekhEzMLk9lK9+QfqalYnUxdztXye q4BNtVxe/72G3P7K7n5+NXCnv6Ffc0zcQjJT3HHtGW84payUu3q2P7+U6+6Az9xVNkr3 6IzA== X-Gm-Message-State: AHQUAuYWii/HQ/CL36mtTQ7Bm3eiEBPK9OIOESut913y+r46zS+nUQRX TljUL8/1fLzbYxu8e+E+OHeQJQ9v2FNJD8//kzhfVrdj X-Google-Smtp-Source: AHgI3IZPZGZ+THe7GlbRu2Ro/k2WnpCgHJabfamTIr/ulvoBHI2PukkFLnDOO+FlDXxhfgnGFhSHurkrTnYv1wGtcAQ= X-Received: by 2002:a19:9a08:: with SMTP id c8mr1405681lfe.8.1549330220919; Mon, 04 Feb 2019 17:30:20 -0800 (PST) MIME-Version: 1.0 References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> In-Reply-To: <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> From: Kazuho Oku Date: Tue, 5 Feb 2019 10:30:08 +0900 Message-ID: Subject: Re: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim To: Martin Thomson Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 01:30:25 -0000 Mike, Martin, Thank you for the responses. Because CID encryption key is a master key, I think it's beneficial to rotate it rather frequently. The precedent that the servers have is the TLS session ticket encryption key (STEK). My understanding is that people generally try to generate a new STEK every day or so [1]. Considering the fact that the maximum permitted lifetime of a TLS session ticket is 7 days, generating a new STEK once a day is fine, because by retaining 8 keys it would be possible decrypt TLS session ticket that was issued 7 days earlier. My preference would be to reuse the synchronization mechanism of STEKs for sharing the CID encryption key among the server cluster. That would mean that typically you would not be able to sustain a QUIC connection for mere than a week. That would be fine for HTTP/3, but maybe not for things like remote shell over QUIC. Having that said, I do agree that we can introduce a QUIC extension if the concern becomes real. Considering that, I think I share the view that we do not need to fix the issue now. [1] https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-tw= itter.html 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson : > > On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote: > > Bearing in mind that: > > > > * this rotation will hopefully be infrequent > > * one or more CID bits can be reserved to indicate the key > > generation used > > * connections only need to be killed when they use something from > > the oldest generation which is now being replaced > > > > Servers can manage this by keeping two keys (one bit), or four (two > > bits). That should make it relatively infrequent that a connection is > > still holding on to a CID from the oldest generation after they=E2=80= =99ve all > > been replaced. > > > > Worst case, this might be a use case for the PLEASE_RETIRE_CID extensio= n > > we also talked about. > > Mike's analysis is correct. I would prefer not to do anything about this= case. > > For now, that means that if servers rotate keys, that will set an upper b= ound on the lifetime of a connection. I think that's tolerable. > --=20 Kazuho Oku From nobody Mon Feb 4 17:34:52 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E68B12F1A2 for ; Mon, 4 Feb 2019 17:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=FkdMtKws; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qZQ/KwMf 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 4FV5oRYyOG-h for ; Mon, 4 Feb 2019 17:34:49 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14EC129BBF for ; Mon, 4 Feb 2019 17:34:48 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F0F4F21EAD for ; Mon, 4 Feb 2019 20:34:47 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Mon, 04 Feb 2019 20:34:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:date:in-reply-to:subject:references; s=fm1; bh=xvn X84Fn8p0GSsfYTnVm/g0lvmEh3/5iLGtpU0EKe2w=; b=FkdMtKwslNQFkNEq/Sd Fc2yOzugigiSobNOFxU5bEKT0TU1dNi+JZeP4kwon9Xp4hppAYQ0shWzx5CFLoOq /x1a0CIVbzhozf/tXqbZOS60TYIHgdku0kU+iw2B0OrVRzyvodpw4eT1u9ahcx2X 0FrTSF4OXMVYE9tdfGWSmvfxGxhoxcf2s8Tu785oAr8VuxVV5hnpne48stEnADVG qOr9kE38Nvj5NGgTynC9BFDK3eBUVlXB0/ZueHN23w+nUJRu9dWEOkAirqGdGbr/ kxBd/IwipB7WM4pp3MS4YQUCUnJ6jIJXhqfnaBzdG3Rz48cOUNY9ga6s34a5a+2h KUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=xvnX84Fn8p0GSsfYTnVm/g0lvmEh3/5iLGtpU0EKe 2w=; b=qZQ/KwMfCVgK+Ss1ityOek291MTrrzREhfv3WCBFzph49l1IwPRmFougj IBgCmMQqanYxbk7HYBNJP0tapcEm8vUcNxSeyGdDl85SRpJ4McM1ZcON5IpJ192F p2uUN6XikzjGE8yP/KzznQT85nfJC4v9muoIiT39UCOYOMjIlV/Uhs+DzRXBfyFo 69FoIg70ksNAklS5j/W3uKgXJlLH4f/SFDSs5x5BNHtLTi+/IQ+9OKZddsKfmRrp bFuIQ+kmN+mrtVkWOXghDkzy/I+Q079l2K3ERI2VRuRMas2NdgerL7uT4/1mBcSZ uW4ahakLH8ubcjlPCbK3JD33pu3Cg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeehgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfoffgjufhfsehtqhertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 364F79E539; Mon, 4 Feb 2019 20:34:47 -0500 (EST) Message-Id: <1549330487.811964.1650920424.1DB8DF4F@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ec01da05 Date: Tue, 05 Feb 2019 12:34:47 +1100 In-Reply-To: Subject: Re: New path => new connection ID, right? References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 01:34:51 -0000 Based on the feedback from Eric K and Mike, I think that this was just a fa= iling. I'd rather not re-run the discussion. This was an argument that was presented last time. We've heard similar arg= uments about "not caring" about various privacy properties over time, and i= t's been very difficult to know who is making the "I don't care" decision. = For that reason, mandating privacy has tended to carry the day. Given tha= t this is a situation that should not occur, what is the problem with makin= g a new connection? On Tue, Feb 5, 2019, at 12:08, David Schinazi wrote: > If an endpoint intentionally migrates and it has unused connection IDs to > use, it makes sense to mandate it MUST switch to one of the unused > connection IDs. > However, if it has run out of unused connection IDs then I would let the > endpoint decide if it wants to close the connection or migrate with a > previously used connection IDs, as there are use-cases that value > performance over non-linkability. Finally, this cannot be enforced by the > peer since it cannot distinguish intentional migration and unintentional > migration (NAT rebinding), and we discussed in Tokyo that we wanted to > avoid non-enforceable MUSTs. >=20 > David >=20 > On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop wrote: >=20 > > The text is there, but it's perhaps not complete: > > > > As discussed in Section 9.5, each connection ID MUST be used on packets > > sent from only one local address. An endpoint that migrates away from a > > local address SHOULD retire all connection IDs used on that address onc= e it > > no longer plans to use that address. > > > > > > > > The gap seems to be that when your peer moves to a new address, there= =E2=80=99s no > > requirement that you not send the same CID to their new address that you > > used toward their old address. > > > > > > > > -----Original Message----- > > From: QUIC On Behalf Of Martin Thomson > > Sent: Monday, February 4, 2019 3:15 PM > > To: quic@ietf.org > > Subject: New path =3D> new connection ID, right? > > > > > > > > I thought that we had agreed that an endpoint that intentionally migrat= es > > has to use a new connection ID on the new path. But I couldn't find any > > "MUST" in the spec that said that. > > > > > > > > On the off chance that this wasn't just a mistake and there was some go= od > > reason not to mandate this, I'm bringing the discussion here. > > > > > > > > I've opened a design issue: > > > > https://github.com/quicwg/base-drafts/issues/2413 > > > > > > > > The change I'm proposing is here: > > > > > > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a= 3995236dda960b4cdff49e36f > > > > > > From nobody Mon Feb 4 17:37:15 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2DC126DBF for ; Mon, 4 Feb 2019 17:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WunOxVUe2_zs for ; Mon, 4 Feb 2019 17:37:11 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 E564312F1A2 for ; Mon, 4 Feb 2019 17:37:10 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id l15-v6so1546216lja.9 for ; Mon, 04 Feb 2019 17:37:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ua4gycPmyBcikq4tIl9Mw+s7EPCR+f52x6ug5MSo43Y=; b=f/loAkcqnowT3HWXjovdqmPj5Q7ZoBDokriP+q86MGJgn12pleUUpnOCY5McSZmuyu X2zchW5zCT8PgMMFtfeE8m9m77dS4McYlm9ZczU/x8JDpiUotccDghEDyxnMniRgwjUJ eHkRwxy9vKyD3EhXdsjC0BxozOsbnW31y4YrmxXvQSDHSfMtOvZfnyesXLq9jYEtzCv6 JVSTFEWgjAN6qztkDPuPOk5nxmj4mUofcn+bg9URo8tKI5R+LqhkbGf99HelbMR8OU1e ZhUzKiISDdYQHRhV9YXoLW/yExPKW5aufro7olmLj1V0P6LOiQXBK4h8QCvqM1YkzE9y J5TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ua4gycPmyBcikq4tIl9Mw+s7EPCR+f52x6ug5MSo43Y=; b=FfS32lyCpQtOZ3yZSW5boJeuU1+eiYVi1VdIe5NMhwF6ZKYenNWO6OjHnro6Iq6MmO cpPlc7G8V0PSFd0Tua9FUtCEPgc9InaW1IKPQLli9N49J51HxdC2usnK+Ce4qcOMuzQW ec2a927QvmgK+EjwKi8LHglt/X2u+cfgaEDfE8VsDDUinj3fAV/2MzRKphpdWkWsO0Xc 1sYgHw4i37dhJxUQv8L0hI7tG2r620JAaM5QKsi+udtuMEhazjb1qvAwyK77g7OngnLi ADPBFr/LMgFc01QEgPegnfdddfp5x7iaIau238kSHH6I7RF3VlQh+A7Ux4mrYUt0KFhb 1yTQ== X-Gm-Message-State: AHQUAub5VPcT3qfA1xwqnzyXynjLxUIZ+5nGut6yI8ivwSsEGbhx5mYS VEtOtECJBgO8gvA8ejKaAmg69cEbO8deu/fKCOc= X-Google-Smtp-Source: AHgI3IZt7RxoKYkZ+QjJCar8vtsKiCStQl+ZWRv/FBd9oNR6HWSbKKr6dYDkj+FvB02mcOkh5NwZO7eB9J0r8SCGPtA= X-Received: by 2002:a2e:9694:: with SMTP id q20-v6mr1292017lji.173.1549330628953; Mon, 04 Feb 2019 17:37:08 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> In-Reply-To: From: Kazuho Oku Date: Tue, 5 Feb 2019 10:36:56 +0900 Message-ID: Subject: Re: New path => new connection ID, right? To: David Schinazi Cc: Mike Bishop , "quic@ietf.org" , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 01:37:13 -0000 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi : > > If an endpoint intentionally migrates and it has unused connection IDs to= use, it makes sense to mandate it MUST switch to one of the unused connect= ion IDs. > However, if it has run out of unused connection IDs then I would let the = endpoint decide if it wants to close the connection or migrate with a previ= ously used connection IDs, as there are use-cases that value performance ov= er non-linkability. I think I might prefer encouraging endpoints to gracefully close the connection before it faces a trade-off between performance and linkability. Therefore, assuming that we adopt Martin's proposal, I think it would make sense to recommend an endpoint to send GOAWAY when if it can no longer issue a new CID for that QUIC connection. > Finally, this cannot be enforced by the peer since it cannot distinguish = intentional migration and unintentional migration (NAT rebinding), and we d= iscussed in Tokyo that we wanted to avoid non-enforceable MUSTs. > > David > > On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop wrote: >> >> The text is there, but it's perhaps not complete: >> >> As discussed in Section 9.5, each connection ID MUST be used on packets = sent from only one local address. An endpoint that migrates away from a loc= al address SHOULD retire all connection IDs used on that address once it no= longer plans to use that address. >> >> >> >> The gap seems to be that when your peer moves to a new address, there=E2= =80=99s no requirement that you not send the same CID to their new address = that you used toward their old address. >> >> >> >> -----Original Message----- >> From: QUIC On Behalf Of Martin Thomson >> Sent: Monday, February 4, 2019 3:15 PM >> To: quic@ietf.org >> Subject: New path =3D> new connection ID, right? >> >> >> >> I thought that we had agreed that an endpoint that intentionally migrate= s has to use a new connection ID on the new path. But I couldn't find any = "MUST" in the spec that said that. >> >> >> >> On the off chance that this wasn't just a mistake and there was some goo= d reason not to mandate this, I'm bringing the discussion here. >> >> >> >> I've opened a design issue: >> >> https://github.com/quicwg/base-drafts/issues/2413 >> >> >> >> The change I'm proposing is here: >> >> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3= 995236dda960b4cdff49e36f >> >> --=20 Kazuho Oku From nobody Mon Feb 4 18:43:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EDD130F8B for ; Mon, 4 Feb 2019 18:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKz0Vyi18iiX for ; Mon, 4 Feb 2019 18:43:24 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 752DF130F63 for ; Mon, 4 Feb 2019 18:43:24 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id i12so834237pfo.7 for ; Mon, 04 Feb 2019 18:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qnpCEvebtx8/PxnpRtyAcvuibDOGtNM+511tHOYmWck=; b=K2cXYza+LFOvyTU2dEDXjdra0Kc1Tj1My/zW+44kKQMTbr0QTVzJ9c++Pa42Woeh/0 LEOvSeD9PSSEwPl0h7xUTamzQgCICwwq3G5VXNllEtfIopnm4dSJAVGVxdwh8sZeZBsw U4HgLEgHQt/YiFemjbEHr/z1q9IJVhmGSXp7HH2QKIfDXJgOJ77pQxrCQWQSd1+JHRWE T6tqQbxVY0Tr+yWIN9BmMngJTWm/mCzbzBW10YUyVnBa592UrxRrF7fvCQPTlYiO0HTz B3VvqJIyh6gQM6sY5lAPHZg85q+tFQnqPVW6vWyyIDglTZe652K/TApOFccSiXh+/ynC YkFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qnpCEvebtx8/PxnpRtyAcvuibDOGtNM+511tHOYmWck=; b=Nsm4JITgEfXoYzr+kR7Fd4+HOeaGKcYUTnTDVEtPx7oMYhhUaF8uWpKIANrfYt6sJh skC5TLolMJV1QenDvTGYw1EiZOExzW6o8EaQh1g5qI3HGy3iif2DI8Sq8jNVzKNkVP1E axIFEUtSH9pL7w9jtAMcKNIiSJbM4gkHy1d8l6A+N6U4xWvCf28s9ZojRj7Iis+ofku5 DE3WoCdC3msL8aqypwNu5QIf1g0fkSwLI7aQC9r9YSBEshvQVX75y8DWuSx8qdDAeBRD 93KMCLIqd7cp0ABd5KOULr+ZnkAT2h+jSl1vUTP1e/UxNO6hfBSRCUhhsS6DTi+9QL93 FRwQ== X-Gm-Message-State: AHQUAuYPDuS/Mvd/ukXG39M2syZMnQTY3XFRP7aJ7E5IULqz7oIRP5yW fTCzun1Ju0rZ6DsVEWAV8faVsOjFYDlo9/FpjZswBea1 X-Google-Smtp-Source: AHgI3Iad59+Dcx2WWdN7B4JksHFscN9FK7bWEnlkM27RvoEdX047CsAaeVdgcAl2x3iuBBXnS5jmcTdBtOuQy5N0/tg= X-Received: by 2002:a62:1e87:: with SMTP id e129mr2532866pfe.221.1549334603952; Mon, 04 Feb 2019 18:43:23 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> In-Reply-To: From: David Schinazi Date: Mon, 4 Feb 2019 18:43:12 -0800 Message-ID: Subject: Re: New path => new connection ID, right? To: Kazuho Oku Cc: Mike Bishop , "quic@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000b4f5b805811c92c8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 02:43:27 -0000 --000000000000b4f5b805811c92c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At the end of the day, you can make it a MUST, but clients will do what they please because servers can't enforce it. But I won't die on this hill, I can live with being declared in the rough on this one. David On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku wrote: > 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi : > > > > If an endpoint intentionally migrates and it has unused connection IDs > to use, it makes sense to mandate it MUST switch to one of the unused > connection IDs. > > However, if it has run out of unused connection IDs then I would let th= e > endpoint decide if it wants to close the connection or migrate with a > previously used connection IDs, as there are use-cases that value > performance over non-linkability. > > I think I might prefer encouraging endpoints to gracefully close the > connection before it faces a trade-off between performance and > linkability. > > Therefore, assuming that we adopt Martin's proposal, I think it would > make sense to recommend an endpoint to send GOAWAY when if it can no > longer issue a new CID for that QUIC connection. > > > Finally, this cannot be enforced by the peer since it cannot distinguis= h > intentional migration and unintentional migration (NAT rebinding), and we > discussed in Tokyo that we wanted to avoid non-enforceable MUSTs. > > > > David > > > > On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop wrote= : > >> > >> The text is there, but it's perhaps not complete: > >> > >> As discussed in Section 9.5, each connection ID MUST be used on packet= s > sent from only one local address. An endpoint that migrates away from a > local address SHOULD retire all connection IDs used on that address once = it > no longer plans to use that address. > >> > >> > >> > >> The gap seems to be that when your peer moves to a new address, there= =E2=80=99s > no requirement that you not send the same CID to their new address that y= ou > used toward their old address. > >> > >> > >> > >> -----Original Message----- > >> From: QUIC On Behalf Of Martin Thomson > >> Sent: Monday, February 4, 2019 3:15 PM > >> To: quic@ietf.org > >> Subject: New path =3D> new connection ID, right? > >> > >> > >> > >> I thought that we had agreed that an endpoint that intentionally > migrates has to use a new connection ID on the new path. But I couldn't > find any "MUST" in the spec that said that. > >> > >> > >> > >> On the off chance that this wasn't just a mistake and there was some > good reason not to mandate this, I'm bringing the discussion here. > >> > >> > >> > >> I've opened a design issue: > >> > >> https://github.com/quicwg/base-drafts/issues/2413 > >> > >> > >> > >> The change I'm proposing is here: > >> > >> > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a39= 95236dda960b4cdff49e36f > >> > >> > > > > -- > Kazuho Oku > --000000000000b4f5b805811c92c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the end of the day, you can make it a MUST, but clients= will do what they please because servers can't enforce it.
But I w= on't die on this hill, I can live with being declared in the rough on t= his one.

David

On Mon, Feb 4, 2019 at 5:3= 7 PM Kazuho Oku <kazuhooku@gmail.= com> wrote:
2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi <dschinazi.ietf@= gmail.com>:
>
> If an endpoint intentionally migrates and it has unused connection IDs= to use, it makes sense to mandate it MUST switch to one of the unused conn= ection IDs.
> However, if it has run out of unused connection IDs then I would let t= he endpoint decide if it wants to close the connection or migrate with a pr= eviously used connection IDs, as there are use-cases that value performance= over non-linkability.

I think I might prefer encouraging endpoints to gracefully close the
connection before it faces a trade-off between performance and
linkability.

Therefore, assuming that we adopt Martin's proposal, I think it would make sense to recommend an endpoint to send GOAWAY when if it can no
longer issue a new CID for that QUIC connection.

> Finally, this cannot be enforced by the peer since it cannot distingui= sh intentional migration and unintentional migration (NAT rebinding), and w= e discussed in Tokyo that we wanted to avoid non-enforceable MUSTs.
>
> David
>
> On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop <mbishop@evequefou.be> wrote:
>>
>> The text is there, but it's perhaps not complete:
>>
>> As discussed in Section 9.5, each connection ID MUST be used on pa= ckets sent from only one local address. An endpoint that migrates away from= a local address SHOULD retire all connection IDs used on that address once= it no longer plans to use that address.
>>
>>
>>
>> The gap seems to be that when your peer moves to a new address, th= ere=E2=80=99s no requirement that you not send the same CID to their new ad= dress that you used toward their old address.
>>
>>
>>
>> -----Original Message-----
>> From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Thomson
>> Sent: Monday, February 4, 2019 3:15 PM
>> To: quic@ietf.o= rg
>> Subject: New path =3D> new connection ID, right?
>>
>>
>>
>> I thought that we had agreed that an endpoint that intentionally m= igrates has to use a new connection ID on the new path.=C2=A0 But I couldn&= #39;t find any "MUST" in the spec that said that.
>>
>>
>>
>> On the off chance that this wasn't just a mistake and there wa= s some good reason not to mandate this, I'm bringing the discussion her= e.
>>
>>
>>
>> I've opened a design issue:
>>
>> https://github.com/quicwg/base-drafts/iss= ues/2413
>>
>>
>>
>> The change I'm proposing is here:
>>
>> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922= a3995236dda960b4cdff49e36f
>>
>>



--
Kazuho Oku
--000000000000b4f5b805811c92c8-- From nobody Tue Feb 5 03:22:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87672130E46 for ; Tue, 5 Feb 2019 03:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64IDk_xX83yV for ; Tue, 5 Feb 2019 03:22:24 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 E942E12958B for ; Tue, 5 Feb 2019 03:22:23 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id n23so2348857lfl.4 for ; Tue, 05 Feb 2019 03:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kIljbeSwbdcXLZbTHQx192SKD65NRgFBPnQJQc/xlpY=; b=Gx5L9flpJk2QNUWiDASrRaO9uJWyurl0JnYPtALFkiIZrFPz9rqQYzYFFJTEjk7XMh nIzGet2wKIeQ5Uda5fx92RVvWpvadm7qDa6XnOQsbZjJokMqTPEn2G0CEt248CLl4HqJ A61akOZC5Tz4Ar+gb96qPZ99/Tf3XABtc/r+svnWtHZuSn7Oy4jtDay6Ty7OA5X2k0SA 14Xci+6ByUPjS3cy1me5AccpLwW87sf6KWsHHpo8tlBE4PtmpHj2qnSyi/n7nsBK8S+f bUNHXV+oNfndwluZzSZ5Z1GWLqVTXr428LBn3UzH1i0xs9E4f2e92lRDaD370tXy6gVE duxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kIljbeSwbdcXLZbTHQx192SKD65NRgFBPnQJQc/xlpY=; b=KpJaz6yph+1Z4fBGuYtDj6YsExTD6/NKQvALO17F5ROeJCmh/zf2c+Zwgj6CWxbaJr ir9oDnC1vdTaG06qRQ5bOMPzKzGQObGjtMQ/a96906m218324ThaEuuOWA20ukLYRyqn 7KcE3ek6EFHqfQnO5peSmm0rAVksxqPvYSmkKk2t1oNqSZQf05V+SIUy3nf0ZTj4xB/N 3LeM+DVMgog0N9drmhHClrtY9wFXpicNmIS8DrrKQb1SNw8hJ40AuFdGp9HCqcVdNRl7 kqreIX+63OczK5Grs+PoM1ABt9IaOq41b3MWQ2gYiV1Q+R/G6rAcTogAQFCo+nVkNguU 0Whg== X-Gm-Message-State: AHQUAuapWqrUlxi7HBFUYcIZ5OoSe/3Thkzx9W2vOAh8PYRDl+0q4cef mGrNt3E0NkvPNUCf1zVsepYzhwTtpfTRH+dfpWI= X-Google-Smtp-Source: AHgI3IaWPJuhtSwaiNP53Z5bgUlcMMEl4vn2PaD8QCZg4i/i9HrsvyjVUpym4A4ehH/q/mdDSnSgAy4TLi/GSjd8CaM= X-Received: by 2002:a19:ee04:: with SMTP id g4mr2779524lfb.145.1549365742030; Tue, 05 Feb 2019 03:22:22 -0800 (PST) MIME-Version: 1.0 References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> In-Reply-To: From: Jana Iyengar Date: Tue, 5 Feb 2019 16:52:11 +0530 Message-ID: Subject: Re: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim To: Kazuho Oku Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000ae5262058123d2c3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 11:22:26 -0000 --000000000000ae5262058123d2c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm in agreement. FWIW, I don't think that a remote shell session should need to keep the transport connection around for as long as the session is around, but that's not a discussion we need to have yet. On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku wrote: > Mike, Martin, > > Thank you for the responses. > > Because CID encryption key is a master key, I think it's beneficial to > rotate it rather frequently. The precedent that the servers have is > the TLS session ticket encryption key (STEK). My understanding is that > people generally try to generate a new STEK every day or so [1]. > Considering the fact that the maximum permitted lifetime of a TLS > session ticket is 7 days, generating a new STEK once a day is fine, > because by retaining 8 keys it would be possible decrypt TLS session > ticket that was issued 7 days earlier. > > My preference would be to reuse the synchronization mechanism of STEKs > for sharing the CID encryption key among the server cluster. That > would mean that typically you would not be able to sustain a QUIC > connection for mere than a week. > > That would be fine for HTTP/3, but maybe not for things like remote > shell over QUIC. > > Having that said, I do agree that we can introduce a QUIC extension if > the concern becomes real. Considering that, I think I share the view > that we do not need to fix the issue now. > > [1] > https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twit= ter.html > > 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson : > > > > On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote: > > > Bearing in mind that: > > > > > > * this rotation will hopefully be infrequent > > > * one or more CID bits can be reserved to indicate the key > > > generation used > > > * connections only need to be killed when they use something from > > > the oldest generation which is now being replaced > > > > > > Servers can manage this by keeping two keys (one bit), or four (two > > > bits). That should make it relatively infrequent that a connection i= s > > > still holding on to a CID from the oldest generation after they=E2=80= =99ve all > > > been replaced. > > > > > > Worst case, this might be a use case for the PLEASE_RETIRE_CID > extension > > > we also talked about. > > > > Mike's analysis is correct. I would prefer not to do anything about > this case. > > > > For now, that means that if servers rotate keys, that will set an upper > bound on the lifetime of a connection. I think that's tolerable. > > > > > -- > Kazuho Oku > > --000000000000ae5262058123d2c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in agreement.=C2=A0

FWIW, I don= 't think that a remote shell session should need to keep the transport = connection around for as long as the session is around, but that's not = a discussion we need to have yet.

On Tue, Feb 5, 2019 at 7:00 AM Kazuh= o Oku <kazuhooku@gmail.com>= ; wrote:
Mike, M= artin,

Thank you for the responses.

Because CID encryption key is a master key, I think it's beneficial to<= br> rotate it rather frequently. The precedent that the servers have is
the TLS session ticket encryption key (STEK). My understanding is that
people generally try to generate a new STEK every day or so [1].
Considering the fact that the maximum permitted lifetime of a TLS
session ticket is 7 days, generating a new STEK once a day is fine,
because by retaining 8 keys it would be possible decrypt TLS session
ticket that was issued 7 days earlier.

My preference would be to reuse the synchronization mechanism of STEKs
for sharing the CID encryption key among the server cluster. That
would mean that typically you would not be able to sustain a QUIC
connection for mere than a week.

That would be fine for HTTP/3, but maybe not for things like remote
shell over QUIC.

Having that said, I do agree that we can introduce a QUIC extension if
the concern becomes real. Considering that, I think I share the view
that we do not need to fix the issue now.

[1] https://blog.tw= itter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html

2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson <mt@lowentropy.net>:=
>
> On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote:
> > Bearing in mind that:
> >
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0this rotation will hopefully be infrequ= ent
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0one or more CID bits can be reserved to= indicate the key
> > generation used
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0connections only need to be killed when= they use something from
> > the oldest generation which is now being replaced
> >
> > Servers can manage this by keeping two keys (one bit), or four (t= wo
> > bits).=C2=A0 That should make it relatively infrequent that a con= nection is
> > still holding on to a CID from the oldest generation after they= =E2=80=99ve all
> > been replaced.
> >
> > Worst case, this might be a use case for the PLEASE_RETIRE_CID ex= tension
> > we also talked about.
>
> Mike's analysis is correct.=C2=A0 I would prefer not to do anythin= g about this case.
>
> For now, that means that if servers rotate keys, that will set an uppe= r bound on the lifetime of a connection.=C2=A0 I think that's tolerable= .
>


--
Kazuho Oku

--000000000000ae5262058123d2c3-- From nobody Tue Feb 5 03:42:09 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474EC12958B for ; Tue, 5 Feb 2019 03:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Fj2cKjLGBd for ; Tue, 5 Feb 2019 03:42:04 -0800 (PST) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 CEE8D130DE7 for ; Tue, 5 Feb 2019 03:42:03 -0800 (PST) Received: by mail-lj1-x242.google.com with SMTP id v1-v6so2630236ljd.0 for ; Tue, 05 Feb 2019 03:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oHmrILO9RLbhbut/zklDl/n3yj02bfb3Z/PxttBhopM=; b=jSI2sYMV0vJ/9O/JFczWAo/UfHFPfaIeS6cQOeMzVC2zuhghTpy5gd6VEy72Xg4F7S VDuU1nbEvgIklxHGg+FU+bHFPlHwLUSbwSmIqcLEGJVhiMztVnZUOEbFTJvtBK99tZrh qRaEuKkhZXtASMm9xElbjNkWY32ssfCPl+2yUtngoB4kW7Rid92TsniqUFHG8ewUjjsM m9i7KkB4M0LsLWAxOwEcShzrC4xW4raZZvRV32mjL2R8+1IXTeBVbWIyJhIxATlIshhF MO8rM+O3pGWEcqpGcoUyJneAWXdYjcjmfEBeABAExMrY9wClgT+HM0bPRRta4x/ruF8/ kwVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oHmrILO9RLbhbut/zklDl/n3yj02bfb3Z/PxttBhopM=; b=tmaVNgml0uKzE2d3eOTOSjpRmSGBzFXHWPiioBn2FPzA31pEw4l9LRbO7nLEpSHhyM qC9nE8rTB9CxUnxHch/dnqaPAqSfCXRinptlvG9HM7rOC6ct0JQpCmxiU6MJdnCAMEE1 Mp0odwwAt7k6fcJKTBKkt8FvTOXwGvB11dySM8dIxJFba9+rkvo24NL+grLMP+R2cflf 3fjxtg3dBSI0VJokIx30c8EE2tWpXLvhuMZZqhBtihgdlNbSw771hSynGGQx1TgcsXlu WFGJXtvBrsH6YelQQy4AWoJSKYSl6T5x+k5M0hSB+CfzJ6UQFWF2cZTWI2TxQWwTVB/c dM/g== X-Gm-Message-State: AHQUAuaLz4T+HWqIGcpjQTQsaxZZmgiaOWngJXFEzZ4m0mUgaaLOUP2w sXs5b0THkHTb7m0w/AA3bgxKJXQqI9pqCyCBJGo= X-Google-Smtp-Source: AHgI3IaVlqRCh7AlWwTi6CESogrukqJ0vTIA1Ttu8eAbVaL1jMo0lJ5auaGVnvoHEeDDdQqJmwpJD4CDKC1+rHpMFi4= X-Received: by 2002:a2e:8256:: with SMTP id j22-v6mr2727390ljh.40.1549366921972; Tue, 05 Feb 2019 03:42:01 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> In-Reply-To: From: Jana Iyengar Date: Tue, 5 Feb 2019 17:11:50 +0530 Message-ID: Subject: Re: New path => new connection ID, right? To: David Schinazi Cc: Kazuho Oku , "quic@ietf.org" , Mike Bishop , Martin Thomson Content-Type: multipart/alternative; boundary="00000000000002d1450581241920" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 11:42:07 -0000 --00000000000002d1450581241920 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that want to have MUST for changing CID and MUST NOT for sending packets with the same CID on multiple paths. I thought we had agreed on this in the past, but I could be misremembering. I understand that the server cannot necessarily tell this from NAT rebinding, but it is up to the server what it does if it sees an IP/port change with no accompanying CID change. Egregious changes in IP might be a signature for network change (change in /16 address, for instance) and a server could terminate the connection and respond with a stateless reset if this happens. A client that ignores the MUST and uses the same CID across networks would then risk getting the connection terminated. I suggest that we add some discussion about potential server responses to clients that violate normative expectations. On Tue, Feb 5, 2019 at 8:13 AM David Schinazi wrote: > At the end of the day, you can make it a MUST, but clients will do what > they please because servers can't enforce it. > But I won't die on this hill, I can live with being declared in the rough > on this one. > > David > > On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku wrote: > >> 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi : >> > >> > If an endpoint intentionally migrates and it has unused connection IDs >> to use, it makes sense to mandate it MUST switch to one of the unused >> connection IDs. >> > However, if it has run out of unused connection IDs then I would let >> the endpoint decide if it wants to close the connection or migrate with = a >> previously used connection IDs, as there are use-cases that value >> performance over non-linkability. >> >> I think I might prefer encouraging endpoints to gracefully close the >> connection before it faces a trade-off between performance and >> linkability. >> >> Therefore, assuming that we adopt Martin's proposal, I think it would >> make sense to recommend an endpoint to send GOAWAY when if it can no >> longer issue a new CID for that QUIC connection. >> >> > Finally, this cannot be enforced by the peer since it cannot >> distinguish intentional migration and unintentional migration (NAT >> rebinding), and we discussed in Tokyo that we wanted to avoid >> non-enforceable MUSTs. >> > >> > David >> > >> > On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop >> wrote: >> >> >> >> The text is there, but it's perhaps not complete: >> >> >> >> As discussed in Section 9.5, each connection ID MUST be used on >> packets sent from only one local address. An endpoint that migrates away >> from a local address SHOULD retire all connection IDs used on that addre= ss >> once it no longer plans to use that address. >> >> >> >> >> >> >> >> The gap seems to be that when your peer moves to a new address, >> there=E2=80=99s no requirement that you not send the same CID to their n= ew address >> that you used toward their old address. >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: QUIC On Behalf Of Martin Thomson >> >> Sent: Monday, February 4, 2019 3:15 PM >> >> To: quic@ietf.org >> >> Subject: New path =3D> new connection ID, right? >> >> >> >> >> >> >> >> I thought that we had agreed that an endpoint that intentionally >> migrates has to use a new connection ID on the new path. But I couldn't >> find any "MUST" in the spec that said that. >> >> >> >> >> >> >> >> On the off chance that this wasn't just a mistake and there was some >> good reason not to mandate this, I'm bringing the discussion here. >> >> >> >> >> >> >> >> I've opened a design issue: >> >> >> >> https://github.com/quicwg/base-drafts/issues/2413 >> >> >> >> >> >> >> >> The change I'm proposing is here: >> >> >> >> >> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3= 995236dda960b4cdff49e36f >> >> >> >> >> >> >> >> -- >> Kazuho Oku >> > --00000000000002d1450581241920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that want to have MUST for changing CID and MUST N= OT for sending packets with the same CID on multiple paths.=C2=A0 I thought= we had agreed on this in the past, but I could be misremembering.

=
I understand that the server cannot necessarily tell this from N= AT rebinding, but it is up to the server what it does if it sees an IP/port= change with no accompanying CID change.=C2=A0 Egregious changes in IP migh= t be a signature for network change (change in /16 address, for instance) a= nd a server could terminate the connection and respond with a stateless res= et if this happens.=C2=A0 A client that ignores the MUST and uses the same = CID across networks would then risk getting the connection terminated.=C2= =A0 I suggest that we add some discussion about potential server responses = to clients that violate normative expectations.

On Tue, Feb 5, 2019 = at 8:13 AM David Schinazi <d= schinazi.ietf@gmail.com> wrote:
At the end of the day, you can make= it a MUST, but clients will do what they please because servers can't = enforce it.
But I won't die on this hill, I can live with being dec= lared in the rough on this one.

David

On = Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
2019=E5=B9=B42=E6=9C=885=E6=97= =A5(=E7=81=AB) 10:08 David Schinazi <dschinazi.ietf@gmail.com>:
>
> If an endpoint intentionally migrates and it has unused connection IDs= to use, it makes sense to mandate it MUST switch to one of the unused conn= ection IDs.
> However, if it has run out of unused connection IDs then I would let t= he endpoint decide if it wants to close the connection or migrate with a pr= eviously used connection IDs, as there are use-cases that value performance= over non-linkability.

I think I might prefer encouraging endpoints to gracefully close the
connection before it faces a trade-off between performance and
linkability.

Therefore, assuming that we adopt Martin's proposal, I think it would make sense to recommend an endpoint to send GOAWAY when if it can no
longer issue a new CID for that QUIC connection.

> Finally, this cannot be enforced by the peer since it cannot distingui= sh intentional migration and unintentional migration (NAT rebinding), and w= e discussed in Tokyo that we wanted to avoid non-enforceable MUSTs.
>
> David
>
> On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop <mbishop@evequefou.be> wrote:
>>
>> The text is there, but it's perhaps not complete:
>>
>> As discussed in Section 9.5, each connection ID MUST be used on pa= ckets sent from only one local address. An endpoint that migrates away from= a local address SHOULD retire all connection IDs used on that address once= it no longer plans to use that address.
>>
>>
>>
>> The gap seems to be that when your peer moves to a new address, th= ere=E2=80=99s no requirement that you not send the same CID to their new ad= dress that you used toward their old address.
>>
>>
>>
>> -----Original Message-----
>> From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Thomson
>> Sent: Monday, February 4, 2019 3:15 PM
>> To: quic@ietf.o= rg
>> Subject: New path =3D> new connection ID, right?
>>
>>
>>
>> I thought that we had agreed that an endpoint that intentionally m= igrates has to use a new connection ID on the new path.=C2=A0 But I couldn&= #39;t find any "MUST" in the spec that said that.
>>
>>
>>
>> On the off chance that this wasn't just a mistake and there wa= s some good reason not to mandate this, I'm bringing the discussion her= e.
>>
>>
>>
>> I've opened a design issue:
>>
>> https://github.com/quicwg/base-drafts/iss= ues/2413
>>
>>
>>
>> The change I'm proposing is here:
>>
>> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922= a3995236dda960b4cdff49e36f
>>
>>



--
Kazuho Oku
--00000000000002d1450581241920-- From nobody Tue Feb 5 04:29:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B80130E0E for ; Tue, 5 Feb 2019 04:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 DfSogEbSo48e for ; Tue, 5 Feb 2019 04:29:04 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222C0126CB6 for ; Tue, 5 Feb 2019 04:29:04 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id z20so7711298itc.3 for ; Tue, 05 Feb 2019 04:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=yXumd4z10KMuGqe4T5J0WD9yZBHTVEYmq6z8Yt75nRk=; b=fhbZckJqs7CiNhLgzGdY91onid6eoHQvu2UH4zcX0u68/cc4LIJ54OHngqaoWfOiDD zPAElY89phlGEw6f/C3a8nMb5H3Qv1Mi8QkV348OheZ39lIWRNDBorekRErhgEWpDF2Y 8//CMawmgjgb2fT6015ACYICGJVdhLYYHEtR50h+T+RrJRaVYGXeC3D1uFZeVH8EbQ0x fXAt4C2FmXwV9H1md11mbmSiMoeJbLs4wdLpoZGgyrsSohSWkViq62xGQpjy9gm3JH1t MY54oUP2QyYKdBKpfhvc/7exoWF+LWXtbqYEjA8U3SNp5CN0snwFJ3ta0bhj7oWc2x28 ImxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=yXumd4z10KMuGqe4T5J0WD9yZBHTVEYmq6z8Yt75nRk=; b=d+wti4q912GJ79h0nzI2kGDcKm6oPZv/SBDpju2gWH/6Dcl3pk7XhvqJvW+4XBWF3K +bvm0Lj8HFVsJrkZRvl+EpiW84+fsYoHYOUhvOSpNB0JXZZ6ZPBhDgn8FmKiKZXl1hmk XhFmGv+g0sadU3gKWy47DM4qRlobQuSNi+mUMGkrxRlEkqHrH50D+QEcLalIo7xA3Lm4 wnnS9TFqy2AnmLMbTP4fj7oj5pFTCfJXNu+tYIJRATen6yu87lon/MqXW3ylZ3CxAYz3 FJKa08g5KkPdgAvaJAH/3fLsppXzwGGFg1YLHQHJJ5+guKFKmShnvAv5Fwi1NrR8d3F9 CImg== X-Gm-Message-State: AHQUAuaztqE0f5azSQGirAqDqChVW3lg5/GzK5BnxZFUaNytBksYZmdw bPevOhiXzRq/V6lp3OGmIi+sJ1vEZez6DrNQmyE= X-Google-Smtp-Source: AHgI3IYIIonACpp1wTXMfqghU4wSm8O4FgB5BcRM0EGI0TsJ8ghxcIwtCIgqnOxqtxLTHemM0G/BO4L7D13H2/YZpcc= X-Received: by 2002:a05:660c:12c7:: with SMTP id k7mr2207540itd.148.1549369743383; Tue, 05 Feb 2019 04:29:03 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 5 Feb 2019 04:29:02 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 5 Feb 2019 04:29:02 -0800 Message-ID: Subject: Re: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim To: Jana Iyengar , Kazuho Oku Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000002e2568058124c128" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 12:29:06 -0000 --0000000000002e2568058124c128 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, I don't think that a remote shell session should need to keep the transport connection around for as long as the session is around, but that's not a discussion we need to have yet. Well, I do. If you tunnel data, you cannot just switch to a new connection without a lot of disruption. Why create this problem in the first place? We (eventually) got varint stream ID=E2=80=99s that made it feasible to hav= e long lived connections. I=E2=80=99d be sad to see that go down on connection ID rotations. Especially if these are only done for the single reason of avoiding linkability. My only (other) concern is loss of packet number space, but I hope that changes with multi-path v2, and 62 bit is still something. I do agree that opt-in security does not work, but for a lot of cases it really isn=E2=80=99t the key concern. And for other cases, linkability is s= o easy to achieve anyway via other techniques, that I don=E2=80=99t think it can = compare to the problem of TLS tokens. If the concern is cracking SHA256 via master key, well, I think there are bigger issues to consider, including why a master key is not rotated. Another concern though, is the ability to track users via tokens, but that is a cross connection concern, since clearly and endpoint can track the peer for as the connection is open and the longer it is open, the easier it is to track for external observers. An endpoint can and should close a connection if long-lived tracking is a concern. It just should be imposed on innocent shell pipes. Mikkel On 5 February 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) wrote: I'm in agreement. FWIW, I don't think that a remote shell session should need to keep the transport connection around for as long as the session is around, but that's not a discussion we need to have yet. On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku wrote: > Mike, Martin, > > Thank you for the responses. > > Because CID encryption key is a master key, I think it's beneficial to > rotate it rather frequently. The precedent that the servers have is > the TLS session ticket encryption key (STEK). My understanding is that > people generally try to generate a new STEK every day or so [1]. > Considering the fact that the maximum permitted lifetime of a TLS > session ticket is 7 days, generating a new STEK once a day is fine, > because by retaining 8 keys it would be possible decrypt TLS session > ticket that was issued 7 days earlier. > > My preference would be to reuse the synchronization mechanism of STEKs > for sharing the CID encryption key among the server cluster. That > would mean that typically you would not be able to sustain a QUIC > connection for mere than a week. > > That would be fine for HTTP/3, but maybe not for things like remote > shell over QUIC. > > Having that said, I do agree that we can introduce a QUIC extension if > the concern becomes real. Considering that, I think I share the view > that we do not need to fix the issue now. > > [1] > https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twit= ter.html > > 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson : > > > > On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote: > > > Bearing in mind that: > > > > > > * this rotation will hopefully be infrequent > > > * one or more CID bits can be reserved to indicate the key > > > generation used > > > * connections only need to be killed when they use something from > > > the oldest generation which is now being replaced > > > > > > Servers can manage this by keeping two keys (one bit), or four (two > > > bits). That should make it relatively infrequent that a connection i= s > > > still holding on to a CID from the oldest generation after they=E2=80= =99ve all > > > been replaced. > > > > > > Worst case, this might be a use case for the PLEASE_RETIRE_CID > extension > > > we also talked about. > > > > Mike's analysis is correct. I would prefer not to do anything about > this case. > > > > For now, that means that if servers rotate keys, that will set an upper > bound on the lifetime of a connection. I think that's tolerable.. > > > > > -- > Kazuho Oku > > --0000000000002e2568058124c128 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
FWIW, I don't think that a remote she= ll session should need to keep the transport connection around for as long = as the session is around, but that's not a discussion we need to have y= et.

Well, I do. If you tunnel data, you cannot just switch to a new connectio= n without a lot of disruption. Why create this problem in the first place?<= /div>
We (eventually) got varint stream ID=E2=80=99s that m= ade it feasible to have long lived connections. I=E2=80=99d be sad to see t= hat go down on connection ID rotations. Especially if these are only done f= or the single reason of avoiding linkability. My only (other) concern is lo= ss of packet number space, but I hope that changes with multi-path v2, and = 62 bit is still something.

I do agree that opt-in security does not work, but for a lot of cases it r= eally isn=E2=80=99t the key concern. And for other cases, linkability is so= easy to achieve anyway via =C2=A0other techniques, that I don=E2=80=99t th= ink it can compare to the problem of TLS tokens. If the concern is cracking= SHA256 via master key, well, I think there are bigger issues to consider, = including why a master key is not rotated.

=
Another concern though, is the ability to track users via = tokens, but that is a cross connection concern, since clearly and endpoint = can track the peer for as the connection is open and the longer it is open,= the easier it is to track for external observers. An endpoint can and shou= ld close a connection if long-lived tracking is a concern. It just should b= e imposed on innocent shell pipes.

Mikkel
<= br>

On 5 February 2019 at 12.22.38,= Jana Iyengar (jri.ietf@gmail.com= ) wrote:

<= /div>
I'm in agreement.=C2=A0

FWIW, I don't think that a remote shell session should need to keep the transport connection around for as long as the session is around, but that's not a discussion we need to have yet.

On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku <kazuhooku@gmail.com> wrote:
Mike, Martin,

Thank you for the responses.

Because CID encryption key is a master key, I think it's beneficial to
rotate it rather frequently. The precedent that the servers have is
the TLS session ticket encryption key (STEK). My understanding is that
people generally try to generate a new STEK every day or so [1].
Considering the fact that the maximum permitted lifetime of a TLS
session ticket is 7 days, generating a new STEK once a day is fine,
because by retaining 8 keys it would be possible decrypt TLS session
ticket that was issued 7 days earlier.

My preference would be to reuse the synchronization mechanism of STEKs
for sharing the CID encryption key among the server cluster. That
would mean that typically you would not be able to sustain a QUIC
connection for mere than a week.

That would be fine for HTTP/3, but maybe not for things like remote
shell over QUIC.

Having that said, I do agree that we can introduce a QUIC extension if
the concern becomes real. Considering that, I think I share the view
that we do not need to fix the issue now.

[1] https://blog.tw= itter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html

2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson <mt@lowentropy.net>:=
>
> On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote:
> > Bearing in mind that:
> >
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0this rotation will hopefully be infrequent
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0one or more CID bits can be reserved to indicate the key
> > generation used
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0connections only need to be killed when they use something from
> > the oldest generation which is now being replaced
> >
> > Servers can manage this by keeping two keys (one bit), or four (two
> > bits).=C2=A0 That should make it relatively infrequent that a connection is
> > still holding on to a CID from the oldest generation after they=E2=80=99ve all
> > been replaced.
> >
> > Worst case, this might be a use case for the PLEASE_RETIRE_CID extension
> > we also talked about.
>
> Mike's analysis is correct.=C2=A0 I would prefer not to do anything about this case.
>
> For now, that means that if servers rotate keys, that will set an upper bound on the lifetime of a connection.=C2=A0 I think that's tolerable..
>


--
Kazuho Oku

--0000000000002e2568058124c128-- From nobody Tue Feb 5 05:42:47 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02CA1310B9 for ; Tue, 5 Feb 2019 05:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUfDHmd2k62M for ; Tue, 5 Feb 2019 05:42:44 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 6957F1294D0 for ; Tue, 5 Feb 2019 05:42:43 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id q2-v6so2885947lji.10 for ; Tue, 05 Feb 2019 05:42:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C27yLHRZYRwc0D6WbubhIyg5INFuXmGlqSuSeegp2Cw=; b=Xj+2BmCz3Bv4/9czXqBDIL74S/C2KBa3Go7GILFTjWGa5nqkNBBLzuFnhqsXZ+rTvr yBcQ0Jl8JkcTVqgddyIQB7VE95RIiLAxr6uMqZ/il1l1R7ORWkS6cGtak+2n0fOxQt8n TxUKw7uXcbU+tAI46A/TUsHAl6whRpdnPMe+Fdme/YjnWNhQG+iV3jnfeQIUn0uXPneD wW87pibB++u/0TfQg1PX1MujoEFpIEbzD0/lBP2B1OFU8OleZa/PWw3YMztf5mfZ5qut AGwPhHohGQd7gKjyuIdCXTNlO1TWzTRHJTU+iMVUvH03Qf9Sr3t6a2gELT+vkXGSRiKX yhSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C27yLHRZYRwc0D6WbubhIyg5INFuXmGlqSuSeegp2Cw=; b=aL28yhUa9JE7y6Hfj/neGWf8ZD+TwI+FuPHIRJft3vpHAkzhqfi/3jS5bA054y794U 7bRGVACE8zFn+bb0rGnP6o6vDCfxa2+lhlPOezuBlUZ0P3FFrDEXDGPn/0zlZnGAVzVS zRPXuKVRI12rrjWT/6RicU26cPRwHukIYWgBG3YJg1gDn+U/Aft2pkghycD5bhD2zIEv Ic4cMsei+2ix+prKVzRzI81RgvWZSnGmFacMDlmgmhR32xWSRlTHrXuwllVa4DFwu6wd yzKcVKd6WAO5sjnc7wx/4BIHNGKBqFTAo7pq3vxLFgmPxpeGXh75rkbqM0vVE5G9ow/T QEqQ== X-Gm-Message-State: AHQUAuYZURIpiexfuFHwyv+jZv5QY4qLj9FLFRrp4UYFv1bDa4e0BrwR 9iZ/lJLNUZvBbwqp892Zzu/y6klFzPASt2bWjsM= X-Google-Smtp-Source: AHgI3IbH7dDPoE2Y19zKKb/bTv+cPfP8I3yLzoYssvpnw7+hfdZA9fkBlcfHnztO/tcuhcCueukdqcHQ5GX4cOUotGQ= X-Received: by 2002:a2e:8256:: with SMTP id j22-v6mr3069580ljh.40.1549374161504; Tue, 05 Feb 2019 05:42:41 -0800 (PST) MIME-Version: 1.0 References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> In-Reply-To: From: Jana Iyengar Date: Tue, 5 Feb 2019 19:12:30 +0530 Message-ID: Subject: Re: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Kazuho Oku , Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000855098058125c886" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 13:42:46 -0000 --000000000000855098058125c886 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We're going to be well out of scope here quickly, so I'm not going to design for a hypothetical use case that we don't yet understand well. I definitely don't want to make a design decision now based on such a use case. On Tue, Feb 5, 2019 at 5:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > FWIW, I don't think that a remote shell session should need to keep the > transport connection around for as long as the session is around, but > that's not a discussion we need to have yet. > > > Well, I do. If you tunnel data, you cannot just switch to a new connectio= n > without a lot of disruption. Why create this problem in the first place? > We (eventually) got varint stream ID=E2=80=99s that made it feasible to h= ave long > lived connections. I=E2=80=99d be sad to see that go down on connection I= D > rotations. Especially if these are only done for the single reason of > avoiding linkability. My only (other) concern is loss of packet number > space, but I hope that changes with multi-path v2, and 62 bit is still > something. > > I do agree that opt-in security does not work, but for a lot of cases it > really isn=E2=80=99t the key concern. And for other cases, linkability is= so easy > to achieve anyway via other techniques, that I don=E2=80=99t think it ca= n compare > to the problem of TLS tokens. If the concern is cracking SHA256 via maste= r > key, well, I think there are bigger issues to consider, including why a > master key is not rotated. > > Another concern though, is the ability to track users via tokens, but tha= t > is a cross connection concern, since clearly and endpoint can track the > peer for as the connection is open and the longer it is open, the easier = it > is to track for external observers. An endpoint can and should close a > connection if long-lived tracking is a concern. It just should be imposed > on innocent shell pipes. > > Mikkel > > > On 5 February 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) wrote: > > I'm in agreement. > > FWIW, I don't think that a remote shell session should need to keep the > transport connection around for as long as the session is around, but > that's not a discussion we need to have yet. > > On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku wrote: > >> Mike, Martin, >> >> Thank you for the responses. >> >> Because CID encryption key is a master key, I think it's beneficial to >> rotate it rather frequently. The precedent that the servers have is >> the TLS session ticket encryption key (STEK). My understanding is that >> people generally try to generate a new STEK every day or so [1]. >> Considering the fact that the maximum permitted lifetime of a TLS >> session ticket is 7 days, generating a new STEK once a day is fine, >> because by retaining 8 keys it would be possible decrypt TLS session >> ticket that was issued 7 days earlier. >> >> My preference would be to reuse the synchronization mechanism of STEKs >> for sharing the CID encryption key among the server cluster. That >> would mean that typically you would not be able to sustain a QUIC >> connection for mere than a week. >> >> That would be fine for HTTP/3, but maybe not for things like remote >> shell over QUIC. >> >> Having that said, I do agree that we can introduce a QUIC extension if >> the concern becomes real. Considering that, I think I share the view >> that we do not need to fix the issue now. >> >> [1] >> https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twi= tter.html >> >> 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson : >> > >> > On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote: >> > > Bearing in mind that: >> > > >> > > * this rotation will hopefully be infrequent >> > > * one or more CID bits can be reserved to indicate the key >> > > generation used >> > > * connections only need to be killed when they use something fro= m >> > > the oldest generation which is now being replaced >> > > >> > > Servers can manage this by keeping two keys (one bit), or four (two >> > > bits). That should make it relatively infrequent that a connection = is >> > > still holding on to a CID from the oldest generation after they=E2= =80=99ve all >> > > been replaced. >> > > >> > > Worst case, this might be a use case for the PLEASE_RETIRE_CID >> extension >> > > we also talked about. >> > >> > Mike's analysis is correct. I would prefer not to do anything about >> this case. >> > >> > For now, that means that if servers rotate keys, that will set an uppe= r >> bound on the lifetime of a connection. I think that's tolerable.. >> > >> >> >> -- >> Kazuho Oku >> >> --000000000000855098058125c886 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We're going to be well out of scope here quickly, so I= 'm not going to design for a hypothetical use case that we don't ye= t understand well. I definitely don't want to make a design decision no= w based on such a use case.

On Tue, Feb 5, 2019 at 5:59 PM Mikkel Fahn=C3=B8= e J=C3=B8rgensen <mikkelfj@gmail.c= om> wrote:

FWIW, I don't think that a= remote shell session should need to keep the transport connection around f= or as long as the session is around, but that's not a discussion we nee= d to have yet.

Well, I do. If you tunnel data, you cannot just switch to a ne= w connection without a lot of disruption. Why create this problem in the fi= rst place?
We (eventually) got varint stream ID=E2=80= =99s that made it feasible to have long lived connections. I=E2=80=99d be s= ad to see that go down on connection ID rotations. Especially if these are = only done for the single reason of avoiding linkability. My only (other) co= ncern is loss of packet number space, but I hope that changes with multi-pa= th v2, and 62 bit is still something.

I do agree that opt-in security does not work, but for a lot of= cases it really isn=E2=80=99t the key concern. And for other cases, linkab= ility is so easy to achieve anyway via =C2=A0other techniques, that I don= =E2=80=99t think it can compare to the problem of TLS tokens. If the concer= n is cracking SHA256 via master key, well, I think there are bigger issues = to consider, including why a master key is not rotated.

Another concern though, is the ability to tra= ck users via tokens, but that is a cross connection concern, since clearly = and endpoint can track the peer for as the connection is open and the longe= r it is open, the easier it is to track for external observers. An endpoint= can and should close a connection if long-lived tracking is a concern. It = just should be imposed on innocent shell pipes.

<= /div>
Mikkel


On 5 Febr= uary 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) wrote:

I'm in agreement.=C2=A0

FWIW, I don't think that a remote shell session should need to keep the transport connection around for as long as the session is around, but that's not a discussion we need to have yet.

On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku <kaz= uhooku@gmail.com> wrote:
Mike, Martin,

Thank you for the responses.

Because CID encryption key is a master key, I think it's beneficial to
rotate it rather frequently. The precedent that the servers have is
the TLS session ticket encryption key (STEK). My understanding is that
people generally try to generate a new STEK every day or so [1].
Considering the fact that the maximum permitted lifetime of a TLS
session ticket is 7 days, generating a new STEK once a day is fine,
because by retaining 8 keys it would be possible decrypt TLS session
ticket that was issued 7 days earlier.

My preference would be to reuse the synchronization mechanism of STEKs
for sharing the CID encryption key among the server cluster. That
would mean that typically you would not be able to sustain a QUIC
connection for mere than a week.

That would be fine for HTTP/3, but maybe not for things like remote
shell over QUIC.

Having that said, I do agree that we can introduce a QUIC extension if
the concern becomes real. Considering that, I think I share the view
that we do not need to fix the issue now.

[1] https://blog.tw= itter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html

2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson <mt@lowentropy.net>:=
>
> On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote:
> > Bearing in mind that:
> >
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0this rotation will hopefully be infrequent
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0one or more CID bits can be reserved to indicate the key
> > generation used
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0connections only need to be killed when they use something from
> > the oldest generation which is now being replaced
> >
> > Servers can manage this by keeping two keys (one bit), or four (two
> > bits).=C2=A0 That should make it relatively infrequent that a connection is
> > still holding on to a CID from the oldest generation after they=E2=80=99ve all
> > been replaced.
> >
> > Worst case, this might be a use case for the PLEASE_RETIRE_CID extension
> > we also talked about.
>
> Mike's analysis is correct.=C2=A0 I would prefer not to do anything about this case.
>
> For now, that means that if servers rotate keys, that will set an upper bound on the lifetime of a connection.=C2=A0 I think that's tolerable..
>


--
Kazuho Oku

--000000000000855098058125c886-- From nobody Tue Feb 5 05:51:25 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D684F1310B9 for ; Tue, 5 Feb 2019 05:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 eaHegASkbUAq for ; Tue, 5 Feb 2019 05:51:22 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 1DC201310C5 for ; Tue, 5 Feb 2019 05:51:22 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id z7so8522511iti.0 for ; Tue, 05 Feb 2019 05:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=0WZRgU/6fSDFaCYap+jGQVr7c6rnHGsu0loyXtEs6/I=; b=uyH+9dRQH/xvNXyRtNFNq0KSUYMWuMSga6DvOVS+ZP9wQM4Dpj0YtzBv7N05cYU+tX eVZ38OE8G2L389Sh6znRHQ7PV5rjAoHx0xQOQZ9kzra/h7oK/tiMBNxkjazlrYXpg4Qj pXoJGgSkVU7h9214ojrbIc0sDUa/d2l1qqJBKs7gyHPd6pJGbas7dH22cQ/P4D+KdPN4 R282LI7yIjH3m5WxcKxbrCwvme8EzzGG+ecRyYJ4nSbqvPLSBIhekiQYWthb8O5RGwoL XFiR30XGzIxCWkI0vQtkSGz7PpuHAuHUgpJxi6zCxmheUxlw5HFvWfhj/Fdkta+ePXQP ZRFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=0WZRgU/6fSDFaCYap+jGQVr7c6rnHGsu0loyXtEs6/I=; b=bO3z0ubiu6Lwspc3NYzdgLnJtR93jUhhuHVQOu7UHr8kInIIWAay8ZGCeOkNgk6BQa FY8vn/fbNMI7CYPIiotQQ0gdUZM/FSrSXfyft8JasSrlSvFWVErmfz587dZt6Op9Xwnw NdOGDlnRMbFo+ekdP5Eh0fdUa2HZyLXL0UPXTj/PGpLoqmHRkCykYHK6eajGcGaSyWz1 N6cwioQaLQPTMDGMO4BgixdhfgBUX3EEovqO0qxmvLROQes4dWdKAdgCN9bSXZi3ulKB TPVkvdOcCJ5gscHwikfocLmAqCyNkQlx1vnRF5Xg1+ptWI3Pf/sFPDJm62t+9ao+RXHA p8lA== X-Gm-Message-State: AHQUAubH3WdwXelLgBuNG1yrkKEGZMdDyfStqYDJpUeRWs5DIIO0L5IH JyLmz6VWDPt/N+pCsMh3vzGQQR2HzaAH2DUdd6E= X-Google-Smtp-Source: AHgI3Ib880l/sYwplhr1OSHusV773FMDnV3uWquNxxkUq9C88tQktX0YrUMSOc8EL3MZXDejlLJ5nlctpGa0EtTzXw8= X-Received: by 2002:a05:660c:12c7:: with SMTP id k7mr2374918itd.148.1549374681435; Tue, 05 Feb 2019 05:51:21 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 5 Feb 2019 05:51:20 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 5 Feb 2019 05:51:20 -0800 Message-ID: Subject: Re: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim To: Jana Iyengar Cc: Martin Thomson , IETF QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="00000000000082d2f2058125e79b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 13:51:24 -0000 --00000000000082d2f2058125e79b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It=E2=80=99s not really hypothetical. For long lived peer to peer server connections, every time a connection goes down you can have a database query transaction rollback, which could have been running for hours on end, or loose a multiple gigabytes of data transfer if you use a simpler approach of error handling. On 5 February 2019 at 14.42.42, Jana Iyengar (jri.ietf@gmail.com) wrote: We're going to be well out of scope here quickly, so I'm not going to design for a hypothetical use case that we don't yet understand well. I definitely don't want to make a design decision now based on such a use case. On Tue, Feb 5, 2019 at 5:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > FWIW, I don't think that a remote shell session should need to keep the > transport connection around for as long as the session is around, but > that's not a discussion we need to have yet. > > > Well, I do. If you tunnel data, you cannot just switch to a new connectio= n > without a lot of disruption. Why create this problem in the first place? > We (eventually) got varint stream ID=E2=80=99s that made it feasible to h= ave long > lived connections. I=E2=80=99d be sad to see that go down on connection I= D > rotations. Especially if these are only done for the single reason of > avoiding linkability. My only (other) concern is loss of packet number > space, but I hope that changes with multi-path v2, and 62 bit is still > something. > > I do agree that opt-in security does not work, but for a lot of cases it > really isn=E2=80=99t the key concern. And for other cases, linkability is= so easy > to achieve anyway via other techniques, that I don=E2=80=99t think it ca= n compare > to the problem of TLS tokens. If the concern is cracking SHA256 via maste= r > key, well, I think there are bigger issues to consider, including why a > master key is not rotated. > > Another concern though, is the ability to track users via tokens, but tha= t > is a cross connection concern, since clearly and endpoint can track the > peer for as the connection is open and the longer it is open, the easier = it > is to track for external observers. An endpoint can and should close a > connection if long-lived tracking is a concern. It just should be imposed > on innocent shell pipes. > > Mikkel > > > On 5 February 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) wrote: > > I'm in agreement. > > FWIW, I don't think that a remote shell session should need to keep the > transport connection around for as long as the session is around, but > that's not a discussion we need to have yet. > > On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku wrote: > >> Mike, Martin, >> >> Thank you for the responses. >> >> Because CID encryption key is a master key, I think it's beneficial to >> rotate it rather frequently. The precedent that the servers have is >> the TLS session ticket encryption key (STEK). My understanding is that >> people generally try to generate a new STEK every day or so [1]. >> Considering the fact that the maximum permitted lifetime of a TLS >> session ticket is 7 days, generating a new STEK once a day is fine, >> because by retaining 8 keys it would be possible decrypt TLS session >> ticket that was issued 7 days earlier. >> >> My preference would be to reuse the synchronization mechanism of STEKs >> for sharing the CID encryption key among the server cluster. That >> would mean that typically you would not be able to sustain a QUIC >> connection for mere than a week. >> >> That would be fine for HTTP/3, but maybe not for things like remote >> shell over QUIC. >> >> Having that said, I do agree that we can introduce a QUIC extension if >> the concern becomes real. Considering that, I think I share the view >> that we do not need to fix the issue now. >> >> [1] >> https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twi= tter.html >> >> 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson : >> > >> > On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote: >> > > Bearing in mind that: >> > > >> > > * this rotation will hopefully be infrequent >> > > * one or more CID bits can be reserved to indicate the key >> > > generation used >> > > * connections only need to be killed when they use something fro= m >> > > the oldest generation which is now being replaced >> > > >> > > Servers can manage this by keeping two keys (one bit), or four (two >> > > bits). That should make it relatively infrequent that a connection = is >> > > still holding on to a CID from the oldest generation after they=E2= =80=99ve all >> > > been replaced. >> > > >> > > Worst case, this might be a use case for the PLEASE_RETIRE_CID >> extension >> > > we also talked about. >> > >> > Mike's analysis is correct. I would prefer not to do anything about >> this case. >> > >> > For now, that means that if servers rotate keys, that will set an uppe= r >> bound on the lifetime of a connection. I think that's tolerable.. >> > >> >> >> -- >> Kazuho Oku >> >> --00000000000082d2f2058125e79b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = It=E2=80=99s not rea= lly hypothetical. For long lived peer to peer server connections, every tim= e a connection goes down you can have a database query transaction rollback= , which could have been running for hours on end, or loose a multiple gigab= ytes of data transfer if you use a simpler approach of error handling.


On 5 February 2019 at 14.42.42, Jana Iyengar (jri.ietf@gmail.com) wrote:

We're going to be well out of scope here quickly, so I'm not going to design for a hypothetical use case that we don't yet understand well. I definitely don't want to make a design decision now based on such a use case.

On Tue, Feb 5, 2019 at 5:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

FWIW, I don't think that a remote shell session should need to keep the transport connection around for as long as the session is around, but that's not a discussion we need to have yet.

Well, I do. If you tunnel data, you cannot just switch to a new connection without a lot of disruption. Why create this problem in the first place?
We (eventually) got varint stream ID=E2=80=99s that made i= t feasible to have long lived connections. I=E2=80=99d be sad to see that go down on connection ID rotations. Especially if these are only done for the single reason of avoiding linkability. My only (other) concern is loss of packet number space, but I hope that changes with multi-path v2, and 62 bit is still something.

I do agree that opt-in security does not work, but for a lot of cases it really isn=E2=80=99t the key concern. And for other cases, linkability is so easy to achieve anyway via =C2=A0other techniques, that I don=E2=80=99t think it can compare to the problem of TLS tokens. If the concern is cracking SHA256 via master key, well, I think there are bigger issues to consider, including why a master key is not rotated.

Another concern though, is the ability to track users via tokens, but that is a cross connection concern, since clearly and endpoint can track the peer for as the connection is open and the longer it is open, the easier it is to track for external observers. An endpoint can and should close a connection if long-lived tracking is a concern. It just should be imposed on innocent shell pipes.

Mikkel


On 5 February 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) wrote:

I'm in agreement.=C2=A0

FWIW, I don't think that a remote shell session should need to keep the transport connection around for as long as the session is around, but that's not a discussion we need to have yet.
On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku <= kazuhooku@gmail.com> wrote:
Mike, Martin,

Thank you for the responses.

Because CID encryption key is a master key, I think it's beneficial to
rotate it rather frequently. The precedent that the servers have is
the TLS session ticket encryption key (STEK). My understanding is that
people generally try to generate a new STEK every day or so [1].
Considering the fact that the maximum permitted lifetime of a TLS
session ticket is 7 days, generating a new STEK once a day is fine,
because by retaining 8 keys it would be possible decrypt TLS session
ticket that was issued 7 days earlier.

My preference would be to reuse the synchronization mechanism of STEKs
for sharing the CID encryption key among the server cluster. That
would mean that typically you would not be able to sustain a QUIC
connection for mere than a week.

That would be fine for HTTP/3, but maybe not for things like remote
shell over QUIC.

Having that said, I do agree that we can introduce a QUIC extension if
the concern becomes real. Considering that, I think I share the view
that we do not need to fix the issue now.

[1] https://blog.tw= itter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html

2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson <mt@lowentropy.net>:=
>
> On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote:
> > Bearing in mind that:
> >
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0this rotation will hopefully be infrequent
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0one or more CID bits can be reserved to indicate the key
> > generation used
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0connections only need to be killed when they use something from
> > the oldest generation which is now being replaced
> >
> > Servers can manage this by keeping two keys (one bit), or four (two
> > bits).=C2=A0 That should make it relatively infrequent that a connection is
> > still holding on to a CID from the oldest generation after they=E2=80=99ve all
> > been replaced.
> >
> > Worst case, this might be a use case for the PLEASE_RETIRE_CID extension
> > we also talked about.
>
> Mike's analysis is correct.=C2=A0 I would prefer not to do anything about this case.
>
> For now, that means that if servers rotate keys, that will set an upper bound on the lifetime of a connection.=C2=A0 I think that's tolerable..
>


--
Kazuho Oku

 --00000000000082d2f2058125e79b-- From nobody Tue Feb 5 05:57:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1772E1310C3 for ; Tue, 5 Feb 2019 05:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 jkcAq5_6WXgZ for ; Tue, 5 Feb 2019 05:57:39 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA871310C1 for ; Tue, 5 Feb 2019 05:57:39 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id h193so8309041ita.5 for ; Tue, 05 Feb 2019 05:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=N3cKFhaV4BFyXpXafP0I587oMJ7AjiD0L9t82rz804Y=; b=NOkVu7pO5FzNL54xPjWomDo+FAUoRTi1lJTiyG6HnOojclDBoPKCfsBAX+4sUrHKnI ipOmVypRY/axgnn1RuYIqIMlQyMsdcxpAgLCbwtDq5Qk6HyKoedN/0873H0EV/rX1Gn8 sbELY13bXrd/PtbFV54ABFchNQEdsJRj7TK/zrokxjrlTPLcksSNwkzPeXT3D6QkVCsM yHvfSoHO+ckYLjv+1u3T9+vbcUgf2pNapilXHZT+KAZHA5IM0hkKrI3H8hq8mK1vw4lb JxY0ISxvEllg6+FNDKXjlJV9Kgi+YQuaEPvYguzyP0gFGUq8cjungqCLG9u7WfhhlXzD xLQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=N3cKFhaV4BFyXpXafP0I587oMJ7AjiD0L9t82rz804Y=; b=UCPUuFtFb+VZ3HYK+t+VkoIa92yEig9CXmQYyq+YoDD4+xlm6K/6MjYLHTqcALSs4V kDFtnMwL7Lr60BtWy5sLhZzRvyfqAOBmmJFgIAIA3xyW1JQdGrIMdMGsXZhOmzCzP52p A6L4LcY9XFu3UuiWAm22bh5rEsQbfYAD7I6gwtyhKRPbCYZb0vVqwVAL6rJMLPdbQWY3 wTHxnEGDZZA66y7MpgQSa0EtyCNtZhEmSEQ4ID1IuVZWrSwTumKiY0Ol44bUu3iSa4ZI jdxU70xajIUIo6UwmWaX5NMW8tJdmLiqSO5GhFXfzV/Zpk8oIpOKnnZyeeC4i7IMwB8y XMwQ== X-Gm-Message-State: AHQUAuZqXpznnoVYfLXcC6Y76U3cGP/FPAfWgbOQE9nD/CudD03k17oc I05oL8GUZSm/uy0nlF0N8xZnm1osDF0rIx2nvz0= X-Google-Smtp-Source: AHgI3IbMBQqWrtJ1uF8+GlKZT25NiGyuhhJgtw7N0eXQ761we8TAhjJeh2zO7vdD/+5CNXAtd38UFP/rUFgE/fMK/28= X-Received: by 2002:a6b:f206:: with SMTP id q6mr3040887ioh.166.1549375058983; Tue, 05 Feb 2019 05:57:38 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 5 Feb 2019 05:57:38 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 5 Feb 2019 05:57:38 -0800 Message-ID: Subject: Re: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim To: Jana Iyengar Cc: Martin Thomson , Kazuho Oku , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000003c426058125fe5d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 13:57:42 -0000 --00000000000003c426058125fe5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Put in another way. If connections starts dropping randomly just because of a perceived linkability issue, it would take me not very long to go non-standard and create my own QUIC version. While I could do connection failover without loosing a session, it is a lot simpler to fix QUIC in this regard. On 5 February 2019 at 14.51.20, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: It=E2=80=99s not really hypothetical. For long lived peer to peer server connections, every time a connection goes down you can have a database query transaction rollback, which could have been running for hours on end, or loose a multiple gigabytes of data transfer if you use a simpler approach of error handling. On 5 February 2019 at 14.42.42, Jana Iyengar (jri.ietf@gmail.com) wrote: We're going to be well out of scope here quickly, so I'm not going to design for a hypothetical use case that we don't yet understand well. I definitely don't want to make a design decision now based on such a use case. On Tue, Feb 5, 2019 at 5:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > FWIW, I don't think that a remote shell session should need to keep the > transport connection around for as long as the session is around, but > that's not a discussion we need to have yet. > > > Well, I do. If you tunnel data, you cannot just switch to a new connectio= n > without a lot of disruption. Why create this problem in the first place? > We (eventually) got varint stream ID=E2=80=99s that made it feasible to h= ave long > lived connections. I=E2=80=99d be sad to see that go down on connection I= D > rotations. Especially if these are only done for the single reason of > avoiding linkability. My only (other) concern is loss of packet number > space, but I hope that changes with multi-path v2, and 62 bit is still > something. > > I do agree that opt-in security does not work, but for a lot of cases it > really isn=E2=80=99t the key concern. And for other cases, linkability is= so easy > to achieve anyway via other techniques, that I don=E2=80=99t think it ca= n compare > to the problem of TLS tokens. If the concern is cracking SHA256 via maste= r > key, well, I think there are bigger issues to consider, including why a > master key is not rotated. > > Another concern though, is the ability to track users via tokens, but tha= t > is a cross connection concern, since clearly and endpoint can track the > peer for as the connection is open and the longer it is open, the easier = it > is to track for external observers. An endpoint can and should close a > connection if long-lived tracking is a concern. It just should be imposed > on innocent shell pipes. > > Mikkel > > > On 5 February 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) wrote: > > I'm in agreement. > > FWIW, I don't think that a remote shell session should need to keep the > transport connection around for as long as the session is around, but > that's not a discussion we need to have yet. > > On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku wrote: > >> Mike, Martin, >> >> Thank you for the responses. >> >> Because CID encryption key is a master key, I think it's beneficial to >> rotate it rather frequently. The precedent that the servers have is >> the TLS session ticket encryption key (STEK). My understanding is that >> people generally try to generate a new STEK every day or so [1]. >> Considering the fact that the maximum permitted lifetime of a TLS >> session ticket is 7 days, generating a new STEK once a day is fine, >> because by retaining 8 keys it would be possible decrypt TLS session >> ticket that was issued 7 days earlier. >> >> My preference would be to reuse the synchronization mechanism of STEKs >> for sharing the CID encryption key among the server cluster. That >> would mean that typically you would not be able to sustain a QUIC >> connection for mere than a week. >> >> That would be fine for HTTP/3, but maybe not for things like remote >> shell over QUIC. >> >> Having that said, I do agree that we can introduce a QUIC extension if >> the concern becomes real. Considering that, I think I share the view >> that we do not need to fix the issue now. >> >> [1] >> https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twi= tter.html >> >> 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson : >> > >> > On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote: >> > > Bearing in mind that: >> > > >> > > * this rotation will hopefully be infrequent >> > > * one or more CID bits can be reserved to indicate the key >> > > generation used >> > > * connections only need to be killed when they use something fro= m >> > > the oldest generation which is now being replaced >> > > >> > > Servers can manage this by keeping two keys (one bit), or four (two >> > > bits). That should make it relatively infrequent that a connection = is >> > > still holding on to a CID from the oldest generation after they=E2= =80=99ve all >> > > been replaced. >> > > >> > > Worst case, this might be a use case for the PLEASE_RETIRE_CID >> extension >> > > we also talked about. >> > >> > Mike's analysis is correct. I would prefer not to do anything about >> this case. >> > >> > For now, that means that if servers rotate keys, that will set an uppe= r >> bound on the lifetime of a connection. I think that's tolerable.. >> > >> >> >> -- >> Kazuho Oku >> >> --00000000000003c426058125fe5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Put in another way.<= /div>

If connections starts= dropping randomly just because of a perceived linkability issue, it would = take me not very long to go non-standard and create my own QUIC version. Wh= ile I could do connection failover without loosing a session, it is a lot s= impler to fix QUIC in this regard.


On 5 February 201= 9 at 14.51.20, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

It=E2=80=99s not really hypothetical. For long lived peer to peer server connections, every time a connection goes down you can have a database query transaction rollback, which could have been running for hours on end, or loose a multiple gigabytes of data transfer if you use a simpler approach of error handling.


On 5 February 2019 at 14.42.42, Jana Iyengar (jri.ietf@gmail.com) wrote:

We're going to be well out of scope here quickly, so I'm not going to design for a hypothetical use case that we don't yet understand well. I definitely don't want to make a design decision now based on such a use case.
On Tue, Feb 5, 2019 at 5:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

FWIW, I don't think that a remote shell session should need to keep the transport connection around for as long as the session is around, but that's not a discussion we need to have yet.

Well, I do. If you tunnel data, you cannot just switch to a new connection without a lot of disruption. Why create this problem in the first place?
We (eventually) got varint stream ID=E2=80=99s that made it feasible to have long lived connections. I=E2=80=99d be sad to see that go down on connection ID rotations. Especially if these are only done for the single reason of avoiding linkability. My only (other) concern is loss of packet number space, but I hope that changes with multi-path v2, and 62 bit is still something.

I do agree that opt-in security does not work, but for a lot of cases it really isn=E2=80=99t the key concern. And for other cases, linkability is so easy to achieve anyway via =C2=A0other techniques, that I don=E2=80=99t think it can compare to the problem of TLS tokens. If the concern is cracking SHA256 via master key, well, I think there are bigger issues to consider, including why a master key is not rotated.

Another concern though, is the ability to track users via tokens, but that is a cross connection concern, since clearly and endpoint can track the peer for as the connection is open and the longer it is open, the easier it is to track for external observers. An endpoint can and should close a connection if long-lived tracking is a concern. It just should be imposed on innocent shell pipes.

Mikkel

On 5 February 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) wrote:

I'm in agreement.=C2=A0

FWIW, I don't think that a remote shell session should need to keep the transport connection around for as long as the session is around, but that's not a discussion we need to have yet.
On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku <= kazuhooku@gmail.com> wrote:
Mike, Martin,

Thank you for the responses.

Because CID encryption key is a master key, I think it's beneficial to
rotate it rather frequently. The precedent that the servers have is
the TLS session ticket encryption key (STEK). My understanding is that
people generally try to generate a new STEK every day or so [1].
Considering the fact that the maximum permitted lifetime of a TLS
session ticket is 7 days, generating a new STEK once a day is fine,
because by retaining 8 keys it would be possible decrypt TLS session
ticket that was issued 7 days earlier.

My preference would be to reuse the synchronization mechanism of STEKs
for sharing the CID encryption key among the server cluster. That
would mean that typically you would not be able to sustain a QUIC
connection for mere than a week.

That would be fine for HTTP/3, but maybe not for things like remote
shell over QUIC.

Having that said, I do agree that we can introduce a QUIC extension if
the concern becomes real. Considering that, I think I share the view
that we do not need to fix the issue now.

[1] https://blog.tw= itter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html

2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson <mt@lowentropy.net>:=
>
> On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote:
> > Bearing in mind that:
> >
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0this rotation will hopefully be infrequent
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0one or more CID bits can be reserved to indicate the key
> > generation used
> >=C2=A0 =C2=A0*=C2=A0 =C2=A0connections only need to be killed when they use something from
> > the oldest generation which is now being replaced
> >
> > Servers can manage this by keeping two keys (one bit), or four (two
> > bits).=C2=A0 That should make it relatively infrequent that a connection is
> > still holding on to a CID from the oldest generation after they=E2=80=99ve all
> > been replaced.
> >
> > Worst case, this might be a use case for the PLEASE_RETIRE_CID extension
> > we also talked about.
>
> Mike's analysis is correct.=C2=A0 I would prefer not to do anything about this case.
>
> For now, that means that if servers rotate keys, that will set an upper bound on the lifetime of a connection.=C2=A0 I think that's tolerable..
>


--
Kazuho Oku

--00000000000003c426058125fe5d-- From nobody Tue Feb 5 10:28:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC2A130EB0 for ; Tue, 5 Feb 2019 10:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CvNMx0zU9clI for ; Tue, 5 Feb 2019 10:28:36 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 DF113131193 for ; Tue, 5 Feb 2019 10:28:35 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x15IMWAW019480; Tue, 5 Feb 2019 18:26:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=pT0xAeO2SgktW6+PrtnM1snzr9Je/E7DUFbyajD4kA0=; b=T7645/503qcF1W5DLspLZkBUZgdVWo5dYfXgK9Qp33QHfdtzq6ymN+rbYoYugvANtZWr OsMdyy0YzL8BRRonB2CvLjNb0baNO9+h7iEV8kkc1M4vKqv6M+E/MjqOFs1IzjNm8qVF xhDxmYPZ9d+OzuQExh9EaeGBg4oL7hUDLx30GEm3GS51lehc14ox8NWdM30MRRnJgLfk 8WMvLpb7Bk2MKhwKFExUeb/K93XjEv1j0q5Xiptxns3opXKO825iM3a1FL0c/EusZTGM RZtBh/CFNKxwWzmej8lOnSrk13jIQdp7+Qvp84UaOTxKbqQC3YoEimiF8hcv351TebQv pA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2qfbc3s34x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Feb 2019 18:26:32 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x15IHHVp004264; Tue, 5 Feb 2019 13:26:31 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2qd7e1p68m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Feb 2019 13:26:31 -0500 Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Feb 2019 13:26:30 -0500 Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1395.000; Tue, 5 Feb 2019 13:26:30 -0500 From: "Lubashev, Igor" To: Jana Iyengar , David Schinazi CC: "quic@ietf.org" , Mike Bishop , Martin Thomson , Kazuho Oku Subject: RE: New path => new connection ID, right? Thread-Topic: New path => new connection ID, right? Thread-Index: AQHUvN+JAcoGcAxPckuEc4gGUySdeKXQtUQAgAADUoCAAAgLAIAAEoMAgACWfwCAABtfQA== Date: Tue, 5 Feb 2019 18:26:30 +0000 Message-ID: References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> 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.33.69] Content-Type: multipart/alternative; boundary="_000_cb64f11d6e464d9c8f9c615be3310e4busma1exdag1mb6msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902050139 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902050140 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 18:28:39 -0000 --_000_cb64f11d6e464d9c8f9c615be3310e4busma1exdag1mb6msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgRWdyZWdpb3VzIGNoYW5nZXMgaW4gSVAgbWlnaHQgYmUgYSBzaWduYXR1cmUgZm9yIG5l dHdvcmsgY2hhbmdlIChjaGFuZ2UgaW4gLzE2IGFkZHJlc3MsIGZvciBpbnN0YW5jZSkgYW5kIGEg c2VydmVyIGNvdWxkIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiBhbmQgcmVzcG9uZCB3aXRoIGEg c3RhdGVsZXNzIHJlc2V0IGlmIHRoaXMgaGFwcGVucy4NCg0KVGhlIGNsaWVudCBjb3VsZCBiZSBh IGxhcHRvcCB0aGF0IGlzIHRldGhlcmVkIHZpYSBhIHBob25lIHRoYXQgaXMgY2hhbmdpbmcgcHJv dmlkZXJzLiAgVGhlIGRpc2Nvbm5lY3Qgd291bGQgYmUgY29tcGxldGVseSDigJxwdW5pdGl2ZeKA nSAodGhlIG9sZCBwYXRo4oCZcyBDSUQgaGFzIGFscmVhZHkgYmVlbiBzZW50IG92ZXIgdGhlIG5l dyBwYXRoKSBhbmQgYmUgcHVuaXNoaW5nIHRoZSBjbGllbnQgZm9yIHNvbWV0aGluZyBpdCBoYWQg bm8gY29udHJvbCBvdmVyIHdoYXRzb2V2ZXIuDQoNCg0KICAqICAgSWdvcg0KDQpGcm9tOiBKYW5h IEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA1 LCAyMDE5IDY6NDIgQU0NClRvOiBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwu Y29tPg0KQ2M6IHF1aWNAaWV0Zi5vcmc7IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5i ZT47IE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD47IEthenVobyBPa3UgPGthenVo b29rdUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogTmV3IHBhdGggPT4gbmV3IGNvbm5lY3Rpb24g SUQsIHJpZ2h0Pw0KDQpJIGFncmVlIHRoYXQgd2FudCB0byBoYXZlIE1VU1QgZm9yIGNoYW5naW5n IENJRCBhbmQgTVVTVCBOT1QgZm9yIHNlbmRpbmcgcGFja2V0cyB3aXRoIHRoZSBzYW1lIENJRCBv biBtdWx0aXBsZSBwYXRocy4gIEkgdGhvdWdodCB3ZSBoYWQgYWdyZWVkIG9uIHRoaXMgaW4gdGhl IHBhc3QsIGJ1dCBJIGNvdWxkIGJlIG1pc3JlbWVtYmVyaW5nLg0KDQpJIHVuZGVyc3RhbmQgdGhh dCB0aGUgc2VydmVyIGNhbm5vdCBuZWNlc3NhcmlseSB0ZWxsIHRoaXMgZnJvbSBOQVQgcmViaW5k aW5nLCBidXQgaXQgaXMgdXAgdG8gdGhlIHNlcnZlciB3aGF0IGl0IGRvZXMgaWYgaXQgc2VlcyBh biBJUC9wb3J0IGNoYW5nZSB3aXRoIG5vIGFjY29tcGFueWluZyBDSUQgY2hhbmdlLiAgRWdyZWdp b3VzIGNoYW5nZXMgaW4gSVAgbWlnaHQgYmUgYSBzaWduYXR1cmUgZm9yIG5ldHdvcmsgY2hhbmdl IChjaGFuZ2UgaW4gLzE2IGFkZHJlc3MsIGZvciBpbnN0YW5jZSkgYW5kIGEgc2VydmVyIGNvdWxk IHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiBhbmQgcmVzcG9uZCB3aXRoIGEgc3RhdGVsZXNzIHJl c2V0IGlmIHRoaXMgaGFwcGVucy4gIEEgY2xpZW50IHRoYXQgaWdub3JlcyB0aGUgTVVTVCBhbmQg dXNlcyB0aGUgc2FtZSBDSUQgYWNyb3NzIG5ldHdvcmtzIHdvdWxkIHRoZW4gcmlzayBnZXR0aW5n IHRoZSBjb25uZWN0aW9uIHRlcm1pbmF0ZWQuICBJIHN1Z2dlc3QgdGhhdCB3ZSBhZGQgc29tZSBk aXNjdXNzaW9uIGFib3V0IHBvdGVudGlhbCBzZXJ2ZXIgcmVzcG9uc2VzIHRvIGNsaWVudHMgdGhh dCB2aW9sYXRlIG5vcm1hdGl2ZSBleHBlY3RhdGlvbnMuDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkg YXQgODoxMyBBTSBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0 bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkF0IHRoZSBlbmQgb2YgdGhlIGRh eSwgeW91IGNhbiBtYWtlIGl0IGEgTVVTVCwgYnV0IGNsaWVudHMgd2lsbCBkbyB3aGF0IHRoZXkg cGxlYXNlIGJlY2F1c2Ugc2VydmVycyBjYW4ndCBlbmZvcmNlIGl0Lg0KQnV0IEkgd29uJ3QgZGll IG9uIHRoaXMgaGlsbCwgSSBjYW4gbGl2ZSB3aXRoIGJlaW5nIGRlY2xhcmVkIGluIHRoZSByb3Vn aCBvbiB0aGlzIG9uZS4NCg0KRGF2aWQNCg0KT24gTW9uLCBGZWIgNCwgMjAxOSBhdCA1OjM3IFBN IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5j b20+PiB3cm90ZToNCjIwMTnlubQy5pyINeaXpSjngaspIDEwOjA4IERhdmlkIFNjaGluYXppIDxk c2NoaW5hemkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4+ Og0KPg0KPiBJZiBhbiBlbmRwb2ludCBpbnRlbnRpb25hbGx5IG1pZ3JhdGVzIGFuZCBpdCBoYXMg dW51c2VkIGNvbm5lY3Rpb24gSURzIHRvIHVzZSwgaXQgbWFrZXMgc2Vuc2UgdG8gbWFuZGF0ZSBp dCBNVVNUIHN3aXRjaCB0byBvbmUgb2YgdGhlIHVudXNlZCBjb25uZWN0aW9uIElEcy4NCj4gSG93 ZXZlciwgaWYgaXQgaGFzIHJ1biBvdXQgb2YgdW51c2VkIGNvbm5lY3Rpb24gSURzIHRoZW4gSSB3 b3VsZCBsZXQgdGhlIGVuZHBvaW50IGRlY2lkZSBpZiBpdCB3YW50cyB0byBjbG9zZSB0aGUgY29u bmVjdGlvbiBvciBtaWdyYXRlIHdpdGggYSBwcmV2aW91c2x5IHVzZWQgY29ubmVjdGlvbiBJRHMs IGFzIHRoZXJlIGFyZSB1c2UtY2FzZXMgdGhhdCB2YWx1ZSBwZXJmb3JtYW5jZSBvdmVyIG5vbi1s aW5rYWJpbGl0eS4NCg0KSSB0aGluayBJIG1pZ2h0IHByZWZlciBlbmNvdXJhZ2luZyBlbmRwb2lu dHMgdG8gZ3JhY2VmdWxseSBjbG9zZSB0aGUNCmNvbm5lY3Rpb24gYmVmb3JlIGl0IGZhY2VzIGEg dHJhZGUtb2ZmIGJldHdlZW4gcGVyZm9ybWFuY2UgYW5kDQpsaW5rYWJpbGl0eS4NCg0KVGhlcmVm b3JlLCBhc3N1bWluZyB0aGF0IHdlIGFkb3B0IE1hcnRpbidzIHByb3Bvc2FsLCBJIHRoaW5rIGl0 IHdvdWxkDQptYWtlIHNlbnNlIHRvIHJlY29tbWVuZCBhbiBlbmRwb2ludCB0byBzZW5kIEdPQVdB WSB3aGVuIGlmIGl0IGNhbiBubw0KbG9uZ2VyIGlzc3VlIGEgbmV3IENJRCBmb3IgdGhhdCBRVUlD IGNvbm5lY3Rpb24uDQoNCj4gRmluYWxseSwgdGhpcyBjYW5ub3QgYmUgZW5mb3JjZWQgYnkgdGhl IHBlZXIgc2luY2UgaXQgY2Fubm90IGRpc3Rpbmd1aXNoIGludGVudGlvbmFsIG1pZ3JhdGlvbiBh bmQgdW5pbnRlbnRpb25hbCBtaWdyYXRpb24gKE5BVCByZWJpbmRpbmcpLCBhbmQgd2UgZGlzY3Vz c2VkIGluIFRva3lvIHRoYXQgd2Ugd2FudGVkIHRvIGF2b2lkIG5vbi1lbmZvcmNlYWJsZSBNVVNU cy4NCj4NCj4gRGF2aWQNCj4NCj4gT24gTW9uLCBGZWIgNCwgMjAxOSBhdCA0OjU2IFBNIE1pa2Ug QmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+ PiB3cm90ZToNCj4+DQo+PiBUaGUgdGV4dCBpcyB0aGVyZSwgYnV0IGl0J3MgcGVyaGFwcyBub3Qg Y29tcGxldGU6DQo+Pg0KPj4gQXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gOS41LCBlYWNoIGNvbm5l Y3Rpb24gSUQgTVVTVCBiZSB1c2VkIG9uIHBhY2tldHMgc2VudCBmcm9tIG9ubHkgb25lIGxvY2Fs IGFkZHJlc3MuIEFuIGVuZHBvaW50IHRoYXQgbWlncmF0ZXMgYXdheSBmcm9tIGEgbG9jYWwgYWRk cmVzcyBTSE9VTEQgcmV0aXJlIGFsbCBjb25uZWN0aW9uIElEcyB1c2VkIG9uIHRoYXQgYWRkcmVz cyBvbmNlIGl0IG5vIGxvbmdlciBwbGFucyB0byB1c2UgdGhhdCBhZGRyZXNzLg0KPj4NCj4+DQo+ Pg0KPj4gVGhlIGdhcCBzZWVtcyB0byBiZSB0aGF0IHdoZW4geW91ciBwZWVyIG1vdmVzIHRvIGEg bmV3IGFkZHJlc3MsIHRoZXJl4oCZcyBubyByZXF1aXJlbWVudCB0aGF0IHlvdSBub3Qgc2VuZCB0 aGUgc2FtZSBDSUQgdG8gdGhlaXIgbmV3IGFkZHJlc3MgdGhhdCB5b3UgdXNlZCB0b3dhcmQgdGhl aXIgb2xkIGFkZHJlc3MuDQo+Pg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NCj4+IFNlbnQ6IE1vbmRh eSwgRmVicnVhcnkgNCwgMjAxOSAzOjE1IFBNDQo+PiBUbzogcXVpY0BpZXRmLm9yZzxtYWlsdG86 cXVpY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IE5ldyBwYXRoID0+IG5ldyBjb25uZWN0aW9uIElE LCByaWdodD8NCj4+DQo+Pg0KPj4NCj4+IEkgdGhvdWdodCB0aGF0IHdlIGhhZCBhZ3JlZWQgdGhh dCBhbiBlbmRwb2ludCB0aGF0IGludGVudGlvbmFsbHkgbWlncmF0ZXMgaGFzIHRvIHVzZSBhIG5l dyBjb25uZWN0aW9uIElEIG9uIHRoZSBuZXcgcGF0aC4gIEJ1dCBJIGNvdWxkbid0IGZpbmQgYW55 ICJNVVNUIiBpbiB0aGUgc3BlYyB0aGF0IHNhaWQgdGhhdC4NCj4+DQo+Pg0KPj4NCj4+IE9uIHRo ZSBvZmYgY2hhbmNlIHRoYXQgdGhpcyB3YXNuJ3QganVzdCBhIG1pc3Rha2UgYW5kIHRoZXJlIHdh cyBzb21lIGdvb2QgcmVhc29uIG5vdCB0byBtYW5kYXRlIHRoaXMsIEknbSBicmluZ2luZyB0aGUg ZGlzY3Vzc2lvbiBoZXJlLg0KPj4NCj4+DQo+Pg0KPj4gSSd2ZSBvcGVuZWQgYSBkZXNpZ24gaXNz dWU6DQo+Pg0KPj4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMv MjQxMzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X2dpdGh1Yi5jb21fcXVpY3dnX2Jhc2UtMkRkcmFmdHNfaXNzdWVzXzI0MTMmZD1Ed01GYVEmYz05 NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpk bl9tNTVLUG1sbyZtPTRCOGkzTzJRNmI2TmZaZE1JRmRzQjBTbHJjbUQ1MFRjMjRVRm80eENHaVkm cz01bHI4Y3ppWmZYMkE5QldEM0w4WnY4aTFSM3p5SllDaXpxdkJqY09tdXlzJmU9Pg0KPj4NCj4+ DQo+Pg0KPj4gVGhlIGNoYW5nZSBJJ20gcHJvcG9zaW5nIGlzIGhlcmU6DQo+Pg0KPj4gaHR0cHM6 Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzI0MTQvY29tbWl0cy8xMzY5OGNi ZTMxMTkyMmEzOTk1MjM2ZGRhOTYwYjRjZGZmNDllMzZmPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9xdWljd2dfYmFzZS0yRGRy YWZ0c19wdWxsXzI0MTRfY29tbWl0c18xMzY5OGNiZTMxMTkyMmEzOTk1MjM2ZGRhOTYwYjRjZGZm NDllMzZmJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1f MnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT00QjhpM08yUTZiNk5mWmRNSUZkc0IwU2xy Y21ENTBUYzI0VUZvNHhDR2lZJnM9UjAtanVlV2dhdFQ1V0RrZFlRaV9KVlpGYWNneS1jQUFBNFAy dW9zdDNqdyZlPT4NCj4+DQo+Pg0KDQoNCg0KLS0NCkthenVobyBPa3UNCg== --_000_cb64f11d6e464d9c8f9c615be3310e4busma1exdag1mb6msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjM3MTE1NzAxMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6ODM2MDMyODcyIC0xMDM5Nzg5OTI2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NDsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNv LWxpc3QtaWQ6MTM3OTkzNDU5MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTY2NDM1OTEzMCAtNTAwNDE4NDM2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NDsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVs MSBsZm8xIj5FZ3JlZ2lvdXMgY2hhbmdlcyBpbiBJUCBtaWdodCBiZSBhIHNpZ25hdHVyZSBmb3Ig bmV0d29yayBjaGFuZ2UgKGNoYW5nZSBpbiAvMTYgYWRkcmVzcywgZm9yIGluc3RhbmNlKSBhbmQg YSBzZXJ2ZXIgY291bGQgdGVybWluYXRlIHRoZSBjb25uZWN0aW9uIGFuZCByZXNwb25kIHdpdGgg YSBzdGF0ZWxlc3MgcmVzZXQNCiBpZiB0aGlzIGhhcHBlbnMuPG86cD48L286cD48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBjbGllbnQgY291bGQgYmUgYSBsYXB0b3AgdGhhdCBpcyB0ZXRoZXJlZCB2 aWEgYSBwaG9uZSB0aGF0IGlzIGNoYW5naW5nIHByb3ZpZGVycy4mbmJzcDsgVGhlIGRpc2Nvbm5l Y3Qgd291bGQgYmUgY29tcGxldGVseSDigJxwdW5pdGl2ZeKAnSAodGhlIG9sZCBwYXRo4oCZcyBD SUQgaGFzIGFscmVhZHkgYmVlbiBzZW50IG92ZXIgdGhlIG5ldyBwYXRoKSBhbmQgYmUgcHVuaXNo aW5nIHRoZSBjbGllbnQgZm9yIHNvbWV0aGluZw0KIGl0IGhhZCBubyBjb250cm9sIG92ZXIgd2hh dHNvZXZlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gSmFuYSBJeWVuZ2FyICZsdDtqcmkuaWV0ZkBnbWFpbC5jb20mZ3Q7IDxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAwNSwgMjAxOSA2OjQyIEFNPGJyPg0KPGI+VG86 PC9iPiBEYXZpZCBTY2hpbmF6aSAmbHQ7ZHNjaGluYXppLmlldGZAZ21haWwuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gcXVpY0BpZXRmLm9yZzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVl Zm91LmJlJmd0OzsgTWFydGluIFRob21zb24gJmx0O210QGxvd2VudHJvcHkubmV0Jmd0OzsgS2F6 dWhvIE9rdSAmbHQ7a2F6dWhvb2t1QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IE5ldyBwYXRoID0mZ3Q7IG5ldyBjb25uZWN0aW9uIElELCByaWdodD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgd2FudCB0byBo YXZlIE1VU1QgZm9yIGNoYW5naW5nIENJRCBhbmQgTVVTVCBOT1QgZm9yIHNlbmRpbmcgcGFja2V0 cyB3aXRoIHRoZSBzYW1lIENJRCBvbiBtdWx0aXBsZSBwYXRocy4mbmJzcDsgSSB0aG91Z2h0IHdl IGhhZCBhZ3JlZWQgb24gdGhpcyBpbiB0aGUgcGFzdCwgYnV0IEkgY291bGQgYmUgbWlzcmVtZW1i ZXJpbmcuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVu ZGVyc3RhbmQgdGhhdCB0aGUgc2VydmVyIGNhbm5vdCBuZWNlc3NhcmlseSB0ZWxsIHRoaXMgZnJv bSBOQVQgcmViaW5kaW5nLCBidXQgaXQgaXMgdXAgdG8gdGhlIHNlcnZlciB3aGF0IGl0IGRvZXMg aWYgaXQgc2VlcyBhbiBJUC9wb3J0IGNoYW5nZSB3aXRoIG5vIGFjY29tcGFueWluZyBDSUQgY2hh bmdlLiZuYnNwOyBFZ3JlZ2lvdXMgY2hhbmdlcyBpbiBJUCBtaWdodCBiZSBhIHNpZ25hdHVyZSBm b3IgbmV0d29yaw0KIGNoYW5nZSAoY2hhbmdlIGluIC8xNiBhZGRyZXNzLCBmb3IgaW5zdGFuY2Up IGFuZCBhIHNlcnZlciBjb3VsZCB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24gYW5kIHJlc3BvbmQg d2l0aCBhIHN0YXRlbGVzcyByZXNldCBpZiB0aGlzIGhhcHBlbnMuJm5ic3A7IEEgY2xpZW50IHRo YXQgaWdub3JlcyB0aGUgTVVTVCBhbmQgdXNlcyB0aGUgc2FtZSBDSUQgYWNyb3NzIG5ldHdvcmtz IHdvdWxkIHRoZW4gcmlzayBnZXR0aW5nIHRoZSBjb25uZWN0aW9uIHRlcm1pbmF0ZWQuJm5ic3A7 DQogSSBzdWdnZXN0IHRoYXQgd2UgYWRkIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCBwb3RlbnRpYWwg c2VydmVyIHJlc3BvbnNlcyB0byBjbGllbnRzIHRoYXQgdmlvbGF0ZSBub3JtYXRpdmUgZXhwZWN0 YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEZlYiA1LCAyMDE5IGF0IDg6MTMgQU0gRGF2aWQgU2NoaW5hemkgJmx0Ozxh IGhyZWY9Im1haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20iPmRzY2hpbmF6aS5pZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoZSBlbmQgb2YgdGhlIGRheSwgeW91 IGNhbiBtYWtlIGl0IGEgTVVTVCwgYnV0IGNsaWVudHMgd2lsbCBkbyB3aGF0IHRoZXkgcGxlYXNl IGJlY2F1c2Ugc2VydmVycyBjYW4ndCBlbmZvcmNlIGl0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBJIHdvbid0IGRpZSBvbiB0aGlzIGhpbGwsIEkgY2Fu IGxpdmUgd2l0aCBiZWluZyBkZWNsYXJlZCBpbiB0aGUgcm91Z2ggb24gdGhpcyBvbmUuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1v biwgRmViIDQsIDIwMTkgYXQgNTozNyBQTSBLYXp1aG8gT2t1ICZsdDs8YSBocmVmPSJtYWlsdG86 a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjIwMTk8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290 aGljJnF1b3Q7Ij7lubQ8L3NwYW4+MjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBH b3RoaWMmcXVvdDsiPuaciDwvc3Bhbj41PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01T IEdvdGhpYyZxdW90OyI+5pelPC9zcGFuPig8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 TVMgR290aGljJnF1b3Q7Ij7ngas8L3NwYW4+KSAxMDowOCBEYXZpZCBTY2hpbmF6aSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRz Y2hpbmF6aS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IElmIGFu IGVuZHBvaW50IGludGVudGlvbmFsbHkgbWlncmF0ZXMgYW5kIGl0IGhhcyB1bnVzZWQgY29ubmVj dGlvbiBJRHMgdG8gdXNlLCBpdCBtYWtlcyBzZW5zZSB0byBtYW5kYXRlIGl0IE1VU1Qgc3dpdGNo IHRvIG9uZSBvZiB0aGUgdW51c2VkIGNvbm5lY3Rpb24gSURzLjxicj4NCiZndDsgSG93ZXZlciwg aWYgaXQgaGFzIHJ1biBvdXQgb2YgdW51c2VkIGNvbm5lY3Rpb24gSURzIHRoZW4gSSB3b3VsZCBs ZXQgdGhlIGVuZHBvaW50IGRlY2lkZSBpZiBpdCB3YW50cyB0byBjbG9zZSB0aGUgY29ubmVjdGlv biBvciBtaWdyYXRlIHdpdGggYSBwcmV2aW91c2x5IHVzZWQgY29ubmVjdGlvbiBJRHMsIGFzIHRo ZXJlIGFyZSB1c2UtY2FzZXMgdGhhdCB2YWx1ZSBwZXJmb3JtYW5jZSBvdmVyIG5vbi1saW5rYWJp bGl0eS48YnI+DQo8YnI+DQpJIHRoaW5rIEkgbWlnaHQgcHJlZmVyIGVuY291cmFnaW5nIGVuZHBv aW50cyB0byBncmFjZWZ1bGx5IGNsb3NlIHRoZTxicj4NCmNvbm5lY3Rpb24gYmVmb3JlIGl0IGZh Y2VzIGEgdHJhZGUtb2ZmIGJldHdlZW4gcGVyZm9ybWFuY2UgYW5kPGJyPg0KbGlua2FiaWxpdHku PGJyPg0KPGJyPg0KVGhlcmVmb3JlLCBhc3N1bWluZyB0aGF0IHdlIGFkb3B0IE1hcnRpbidzIHBy b3Bvc2FsLCBJIHRoaW5rIGl0IHdvdWxkPGJyPg0KbWFrZSBzZW5zZSB0byByZWNvbW1lbmQgYW4g ZW5kcG9pbnQgdG8gc2VuZCBHT0FXQVkgd2hlbiBpZiBpdCBjYW4gbm88YnI+DQpsb25nZXIgaXNz dWUgYSBuZXcgQ0lEIGZvciB0aGF0IFFVSUMgY29ubmVjdGlvbi48YnI+DQo8YnI+DQomZ3Q7IEZp bmFsbHksIHRoaXMgY2Fubm90IGJlIGVuZm9yY2VkIGJ5IHRoZSBwZWVyIHNpbmNlIGl0IGNhbm5v dCBkaXN0aW5ndWlzaCBpbnRlbnRpb25hbCBtaWdyYXRpb24gYW5kIHVuaW50ZW50aW9uYWwgbWln cmF0aW9uIChOQVQgcmViaW5kaW5nKSwgYW5kIHdlIGRpc2N1c3NlZCBpbiBUb2t5byB0aGF0IHdl IHdhbnRlZCB0byBhdm9pZCBub24tZW5mb3JjZWFibGUgTVVTVHMuPGJyPg0KJmd0Ozxicj4NCiZn dDsgRGF2aWQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBNb24sIEZlYiA0LCAyMDE5IGF0IDQ6NTYg UE0gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIg dGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgdGV4dCBpcyB0aGVyZSwgYnV0IGl0J3MgcGVyaGFw cyBub3QgY29tcGxldGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBcyBkaXNjdXNzZWQg aW4gU2VjdGlvbiA5LjUsIGVhY2ggY29ubmVjdGlvbiBJRCBNVVNUIGJlIHVzZWQgb24gcGFja2V0 cyBzZW50IGZyb20gb25seSBvbmUgbG9jYWwgYWRkcmVzcy4gQW4gZW5kcG9pbnQgdGhhdCBtaWdy YXRlcyBhd2F5IGZyb20gYSBsb2NhbCBhZGRyZXNzIFNIT1VMRCByZXRpcmUgYWxsIGNvbm5lY3Rp b24gSURzIHVzZWQgb24gdGhhdCBhZGRyZXNzIG9uY2UgaXQgbm8gbG9uZ2VyIHBsYW5zIHRvIHVz ZSB0aGF0IGFkZHJlc3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgVGhlIGdhcCBzZWVtcyB0byBiZSB0aGF0IHdoZW4geW91ciBwZWVyIG1v dmVzIHRvIGEgbmV3IGFkZHJlc3MsIHRoZXJl4oCZcyBubyByZXF1aXJlbWVudCB0aGF0IHlvdSBu b3Qgc2VuZCB0aGUgc2FtZSBDSUQgdG8gdGhlaXIgbmV3IGFkZHJlc3MgdGhhdCB5b3UgdXNlZCB0 b3dhcmQgdGhlaXIgb2xkIGFkZHJlc3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7Jmd0OyBGcm9tOiBRVUlDICZsdDs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24gQmVo YWxmIE9mIE1hcnRpbiBUaG9tc29uPGJyPg0KJmd0OyZndDsgU2VudDogTW9uZGF5LCBGZWJydWFy eSA0LCAyMDE5IDM6MTUgUE08YnI+DQomZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOnF1aWNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7 IFN1YmplY3Q6IE5ldyBwYXRoID0mZ3Q7IG5ldyBjb25uZWN0aW9uIElELCByaWdodD88YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHRob3Vn aHQgdGhhdCB3ZSBoYWQgYWdyZWVkIHRoYXQgYW4gZW5kcG9pbnQgdGhhdCBpbnRlbnRpb25hbGx5 IG1pZ3JhdGVzIGhhcyB0byB1c2UgYSBuZXcgY29ubmVjdGlvbiBJRCBvbiB0aGUgbmV3IHBhdGgu Jm5ic3A7IEJ1dCBJIGNvdWxkbid0IGZpbmQgYW55ICZxdW90O01VU1QmcXVvdDsgaW4gdGhlIHNw ZWMgdGhhdCBzYWlkIHRoYXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgT24gdGhlIG9mZiBjaGFuY2UgdGhhdCB0aGlzIHdhc24ndCBqdXN0 IGEgbWlzdGFrZSBhbmQgdGhlcmUgd2FzIHNvbWUgZ29vZCByZWFzb24gbm90IHRvIG1hbmRhdGUg dGhpcywgSSdtIGJyaW5naW5nIHRoZSBkaXNjdXNzaW9uIGhlcmUuPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSd2ZSBvcGVuZWQgYSBkZXNp Z24gaXNzdWU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fcXVp Y3dnX2Jhc2UtMkRkcmFmdHNfaXNzdWVzXzI0MTMmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNh TUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9t NTVLUG1sbyZhbXA7bT00QjhpM08yUTZiNk5mWmRNSUZkc0IwU2xyY21ENTBUYzI0VUZvNHhDR2lZ JmFtcDtzPTVscjhjemlaZlgyQTlCV0QzTDhadjhpMVIzenlKWUNpenF2QmpjT211eXMmYW1wO2U9 IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRz L2lzc3Vlcy8yNDEzPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IFRoZSBjaGFuZ2UgSSdtIHByb3Bvc2luZyBpcyBoZXJlOjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRz X3B1bGxfMjQxNF9jb21taXRzXzEzNjk4Y2JlMzExOTIyYTM5OTUyMzZkZGE5NjBiNGNkZmY0OWUz NmYmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpuM2JR NXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT00QjhpM08yUTZiNk5m WmRNSUZkc0IwU2xyY21ENTBUYzI0VUZvNHhDR2lZJmFtcDtzPVIwLWp1ZVdnYXRUNVdEa2RZUWlf SlZaRmFjZ3ktY0FBQTRQMnVvc3QzancmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjQxNC9jb21taXRzLzEzNjk4Y2Jl MzExOTIyYTM5OTUyMzZkZGE5NjBiNGNkZmY0OWUzNmY8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCkthenVobyBPa3U8bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_cb64f11d6e464d9c8f9c615be3310e4busma1exdag1mb6msgcorpak_-- From nobody Tue Feb 5 11:28:42 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B312F1311DD for ; Tue, 5 Feb 2019 11:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTtNMzJlro_o for ; Tue, 5 Feb 2019 11:28:37 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 659791311D6 for ; Tue, 5 Feb 2019 11:28:37 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id z20so349508itc.3 for ; Tue, 05 Feb 2019 11:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Ento4a3ptxK+/lg4mCRtX4JupTVoMbrn3KXT8Eww34=; b=N/ALOgizal0HG4dh0ScXymSgq9IhAZiOvM2B21I1PHbI/1Pkmfi0q1byF8Taulwm56 Gp2S2fFV8LVSUV2qloX3VZrgjIi1e3X9wHlVSTxtdC/7lX2YD13TgTiAvnIEHggmPN6e jwItIAuj+/NqTxs6pKq9a0NqczwINpgR+DwdEacHt66ArySHO6ChMVhlCAXyLdeKwPWP pdZ7NPJbaujOfYTmU4kUfGCcwgJUorYNjmjkk+KvBmnCZ4iuieA6YcdLzsvrmZVYCb7c J8S8ne4rNDfteM4UMrFkMjOrtvw8Umwmw/zlcmm+Y9O5S35pPUeon15z/Me+oJI4MKXA 0P8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Ento4a3ptxK+/lg4mCRtX4JupTVoMbrn3KXT8Eww34=; b=AdKIDVzpKd2osuIMexOszcfaO36xkDPlxogh+8uAkxnDzz6cVyExIQ/Z4BdG3LJJpy IZ3MtQrBk9ZJ/9FpbdxkGLUyG6j3xrcGeur8Yvw1dcB8VUqPsIBun6V9IioR5hOoqAfB xXQ6eYY6n1rNrkR3lo3n+MES50YsKEEfDCWSrQYZ9SB7UCfe+8HQ2YpF69Pmexfws6pU o79W2YiXLd60dcJOKXEBzrXdHqZ4HGLWetfejE3EbGDa05vmg9z1YG9QxKMFAP9SySoS CXdPXlp7bzPDfKzaqkIgFTpvV4GGyLElEzyHVyMW1ZX8ZkC+4/GZAYfe0l/ICsCjckgT u0Hw== X-Gm-Message-State: AHQUAua5XrAUpvSg0pUsR1TSYi8FLFVp3DQhmC/8L9OUo8FeRqIBfuu/ me7Vnk7bXAbZZYTYgcAqavrDscv2NRY1yAGbLyo= X-Google-Smtp-Source: AHgI3IY4b/pdOEposzl2GF9xy/qKlw5l5r0OXqaqRGKOXUGTFR79/2d78Z/2b6+xrGnvjcpAr2BY9qu5bHbEkjDZeOQ= X-Received: by 2002:a5d:8d90:: with SMTP id b16mr3619660ioj.35.1549394916421; Tue, 05 Feb 2019 11:28:36 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> In-Reply-To: From: Ted Hardie Date: Tue, 5 Feb 2019 11:28:09 -0800 Message-ID: Subject: Re: New path => new connection ID, right? To: "Lubashev, Igor" Cc: Jana Iyengar , David Schinazi , "quic@ietf.org" , Mike Bishop , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000009c349a05812a9da8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 19:28:41 -0000 --0000000000009c349a05812a9da8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Igor, I have a clarifying question on the scenario below. On Tue, Feb 5, 2019 at 10:28 AM Lubashev, Igor wrote: > > - Egregious changes in IP might be a signature for network change > (change in /16 address, for instance) and a server could terminate the > connection and respond with a stateless reset if this happens. > > > > The client could be a laptop that is tethered via a phone that is changin= g > providers. The disconnect would be completely =E2=80=9Cpunitive=E2=80=9D= (the old path=E2=80=99s > CID has already been sent over the new path) and be punishing the client > for something it had no control over whatsoever. > > > In this scenario, what is your view of where the IP address changes are taking place? I agree that the device connected to a phone (e.g. by a mobile hotspot) will not generally have a view of the change in upstream path. If that phone is using something like mobile IP or a VPN to have a consistent external address, then I also don't see why this path change would trigger any change in CID. But if the phone/hotspot's IP address changes during this from one provider's set of addresses to another, this is functionally re-homing. In that case, isn't there already a high risk that the traffic will end up at a different back end because of the IP change? Thanks for sharing your thoughts on this, Ted > > - Igor > > > > *From:* Jana Iyengar > *Sent:* Tuesday, February 05, 2019 6:42 AM > *To:* David Schinazi > *Cc:* quic@ietf.org; Mike Bishop ; Martin Thomson < > mt@lowentropy.net>; Kazuho Oku > *Subject:* Re: New path =3D> new connection ID, right? > > > > I agree that want to have MUST for changing CID and MUST NOT for sending > packets with the same CID on multiple paths. I thought we had agreed on > this in the past, but I could be misremembering. > > > > I understand that the server cannot necessarily tell this from NAT > rebinding, but it is up to the server what it does if it sees an IP/port > change with no accompanying CID change. Egregious changes in IP might be= a > signature for network change (change in /16 address, for instance) and a > server could terminate the connection and respond with a stateless reset = if > this happens. A client that ignores the MUST and uses the same CID acros= s > networks would then risk getting the connection terminated. I suggest th= at > we add some discussion about potential server responses to clients that > violate normative expectations. > > > > On Tue, Feb 5, 2019 at 8:13 AM David Schinazi > wrote: > > At the end of the day, you can make it a MUST, but clients will do what > they please because servers can't enforce it. > > But I won't die on this hill, I can live with being declared in the rough > on this one. > > > > David > > > > On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku wrote: > > 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi : > > > > If an endpoint intentionally migrates and it has unused connection IDs > to use, it makes sense to mandate it MUST switch to one of the unused > connection IDs. > > However, if it has run out of unused connection IDs then I would let th= e > endpoint decide if it wants to close the connection or migrate with a > previously used connection IDs, as there are use-cases that value > performance over non-linkability. > > I think I might prefer encouraging endpoints to gracefully close the > connection before it faces a trade-off between performance and > linkability. > > Therefore, assuming that we adopt Martin's proposal, I think it would > make sense to recommend an endpoint to send GOAWAY when if it can no > longer issue a new CID for that QUIC connection. > > > Finally, this cannot be enforced by the peer since it cannot distinguis= h > intentional migration and unintentional migration (NAT rebinding), and we > discussed in Tokyo that we wanted to avoid non-enforceable MUSTs. > > > > David > > > > On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop wrote= : > >> > >> The text is there, but it's perhaps not complete: > >> > >> As discussed in Section 9.5, each connection ID MUST be used on packet= s > sent from only one local address. An endpoint that migrates away from a > local address SHOULD retire all connection IDs used on that address once = it > no longer plans to use that address. > >> > >> > >> > >> The gap seems to be that when your peer moves to a new address, there= =E2=80=99s > no requirement that you not send the same CID to their new address that y= ou > used toward their old address. > >> > >> > >> > >> -----Original Message----- > >> From: QUIC On Behalf Of Martin Thomson > >> Sent: Monday, February 4, 2019 3:15 PM > >> To: quic@ietf.org > >> Subject: New path =3D> new connection ID, right? > >> > >> > >> > >> I thought that we had agreed that an endpoint that intentionally > migrates has to use a new connection ID on the new path. But I couldn't > find any "MUST" in the spec that said that. > >> > >> > >> > >> On the off chance that this wasn't just a mistake and there was some > good reason not to mandate this, I'm bringing the discussion here. > >> > >> > >> > >> I've opened a design issue: > >> > >> https://github.com/quicwg/base-drafts/issues/2413 > > >> > >> > >> > >> The change I'm proposing is here: > >> > >> > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a39= 95236dda960b4cdff49e36f > > >> > >> > > > > -- > Kazuho Oku > > --0000000000009c349a05812a9da8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Igor,

I have a clarifying= question on the scenario below.

On Tue, Feb 5, 2019 at 10:28 AM Lubashe= v, Igor <ilubashe@akamai.com&= gt; wrote:
  • Egregious changes in IP might be a signature for network change (c= hange in /16 address, for instance) and a server could terminate the connec= tion and respond with a stateless reset if this happens.

=C2=A0

The client could be a laptop that is tethered via a = phone that is changing providers.=C2=A0 The disconnect would be completely = =E2=80=9Cpunitive=E2=80=9D (the old path=E2=80=99s CID has already been sen= t over the new path) and be punishing the client for something it had no control over whatsoever.

=C2=A0


<= /div>
In this scenario, what is your view of where the IP address chang= es are taking place?

I agree that the device = connected to a phone (e.g. by a mobile hotspot) will not generally have a v= iew of the change in upstream path.=C2=A0 If that phone is using something = like mobile IP or a VPN to have a consistent external address, then I also = don't see why this path change would trigger any change in CID.=C2=A0 B= ut if the phone/hotspot's IP address changes during this from one provi= der's set of addresses to another, this is functionally re-homing.=C2= =A0 In that case, isn't there already a high risk that the traffic will= end up at a different back end because of the IP change?

Thanks for sharing your thoughts on this,

<= div>Ted
=C2=A0

  • Igor

=C2=A0

From: Jana Iyengar <jri.ietf@gmail.com>
Sent: Tuesday, February 05, 2019 6:42 AM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: quic@ietf.org= ; Mike Bishop <mbishop@evequefou.be>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <= ;kazuhooku@gmail.c= om>
Subject: Re: New path =3D> new connection ID, right?

=C2=A0

I agree that want to have MUST for changing CID and = MUST NOT for sending packets with the same CID on multiple paths.=C2=A0 I t= hought we had agreed on this in the past, but I could be misremembering.=

=C2=A0

I understand that the server cannot necessarily tell= this from NAT rebinding, but it is up to the server what it does if it see= s an IP/port change with no accompanying CID change.=C2=A0 Egregious change= s in IP might be a signature for network change (change in /16 address, for instance) and a server could terminate = the connection and respond with a stateless reset if this happens.=C2=A0 A = client that ignores the MUST and uses the same CID across networks would th= en risk getting the connection terminated.=C2=A0 I suggest that we add some discussion about potential server responses to = clients that violate normative expectations.

=C2=A0

On Tue, Feb 5, 2019 at 8:13 AM David Schinazi <dschinazi.ietf@= gmail.com> wrote:

At the end of the day, you can make it a MUST, but c= lients will do what they please because servers can't enforce it.

But I won't die on this hill, I can live with be= ing declared in the rough on this one.

=C2=A0

David

=C2=A0

On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku <kazuhooku@gmail.com&= gt; wrote:

2019=E6=9C= =885=E6=97=A5(=E7=81=AB) 10:0= 8 David Schinazi <dschinazi.ietf@gmail.com>:
>
> If an endpoint intentionally migrates and it has unused connection IDs= to use, it makes sense to mandate it MUST switch to one of the unused conn= ection IDs.
> However, if it has run out of unused connection IDs then I would let t= he endpoint decide if it wants to close the connection or migrate with a pr= eviously used connection IDs, as there are use-cases that value performance= over non-linkability.

I think I might prefer encouraging endpoints to gracefully close the
connection before it faces a trade-off between performance and
linkability.

Therefore, assuming that we adopt Martin's proposal, I think it would make sense to recommend an endpoint to send GOAWAY when if it can no
longer issue a new CID for that QUIC connection.

> Finally, this cannot be enforced by the peer since it cannot distingui= sh intentional migration and unintentional migration (NAT rebinding), and w= e discussed in Tokyo that we wanted to avoid non-enforceable MUSTs.
>
> David
>
> On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop <mbishop@evequefou.be> wrote:
>>
>> The text is there, but it's perhaps not complete:
>>
>> As discussed in Section 9.5, each connection ID MUST be used on pa= ckets sent from only one local address. An endpoint that migrates away from= a local address SHOULD retire all connection IDs used on that address once= it no longer plans to use that address.
>>
>>
>>
>> The gap seems to be that when your peer moves to a new address, th= ere=E2=80=99s no requirement that you not send the same CID to their new ad= dress that you used toward their old address.
>>
>>
>>
>> -----Original Message-----
>> From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Thomson
>> Sent: Monday, February 4, 2019 3:15 PM
>> To: quic@ietf.o= rg
>> Subject: New path =3D> new connection ID, right?
>>
>>
>>
>> I thought that we had agreed that an endpoint that intentionally m= igrates has to use a new connection ID on the new path.=C2=A0 But I couldn&= #39;t find any "MUST" in the spec that said that.
>>
>>
>>
>> On the off chance that this wasn't just a mistake and there wa= s some good reason not to mandate this, I'm bringing the discussion her= e.
>>
>>
>>
>> I've opened a design issue:
>>
>> https://github.com/quicwg/base-drafts/issues/2413
>>
>>
>>
>> The change I'm proposing is here:
>>
>> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995= 236dda960b4cdff49e36f
>>
>>



--
Kazuho Oku

--0000000000009c349a05812a9da8-- From nobody Tue Feb 5 13:33:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0B91312E4 for ; Tue, 5 Feb 2019 13:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, 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=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 F-UlmhytLx3N for ; Tue, 5 Feb 2019 13:33:45 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F80F1312E2 for ; Tue, 5 Feb 2019 13:33:44 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x15LWQxe008456; Tue, 5 Feb 2019 21:33:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=lPG6zp6X3xenZWaH6JdP8ZkmLNWwLj0AHU1q5MH9X1I=; b=LFF8S0zYMLAVqSpF0xF+02RWL8VZz4CdSfSBpaXlxfpHuTplRdF2sg2Xu0vdJskeEDru F4df0s/Lu2v8bGP5xHHE2yNnJRlSRzmQNsn5eFqBw9Yfqsq01J49XLzm//lm+9Tvhz0/ tA4iv/aaIsA+jw5EGnI2LOinVF5UOfsQYRXT02lnOKFw8gfHHYSdlJbGw9UkfHUhZtOp yy/wKmIdS0YQFkMP+s6cAikat8rgoEqZZhbBAGPwfw80GgRn+5yAFYfpjPpgIfq26xck 2v0hJN97lIoIjh7ga73KgudTzKYQFJaFONVIJpR9W28VKqZna3+QGQxDdpM9x/fkkApV lA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2qffkqgphg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Feb 2019 21:33:40 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x15LW7eG014096; Tue, 5 Feb 2019 16:33:40 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2qd7e1r5c6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Feb 2019 16:33:39 -0500 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.1395.4; Tue, 5 Feb 2019 16:33:38 -0500 Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Feb 2019 16:33:38 -0500 Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1395.000; Tue, 5 Feb 2019 16:33:38 -0500 From: "Lubashev, Igor" To: Ted Hardie CC: Jana Iyengar , David Schinazi , "quic@ietf.org" , Mike Bishop , Martin Thomson , Kazuho Oku Subject: RE: New path => new connection ID, right? Thread-Topic: New path => new connection ID, right? Thread-Index: AQHUvN+JAcoGcAxPckuEc4gGUySdeKXQtUQAgAADUoCAAAgLAIAAEoMAgACWfwCAABtfQIAAZuqA//+0EYA= Date: Tue, 5 Feb 2019 21:33:38 +0000 Message-ID: <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> 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.33.69] Content-Type: multipart/alternative; boundary="_000_650fd9704aea40edb496a1d3df0b6cdbusma1exdag1mb6msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902050158 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902050159 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 21:33:49 -0000 --_000_650fd9704aea40edb496a1d3df0b6cdbusma1exdag1mb6msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQnV0IGlmIHRoZSBwaG9uZS9ob3RzcG90J3MgSVAgYWRkcmVzcyBjaGFuZ2VzIGR1cmlu ZyB0aGlzIGZyb20gb25lIHByb3ZpZGVyJ3Mgc2V0IG9mIGFkZHJlc3NlcyB0byBhbm90aGVyLCB0 aGlzIGlzIGZ1bmN0aW9uYWxseSByZS1ob21pbmcuICBJbiB0aGF0IGNhc2UsIGlzbid0IHRoZXJl IGFscmVhZHkgYSBoaWdoIHJpc2sgdGhhdCB0aGUgdHJhZmZpYyB3aWxsIGVuZCB1cCBhdCBhIGRp ZmZlcmVudCBiYWNrIGVuZCBiZWNhdXNlIG9mIHRoZSBJUCBjaGFuZ2U/DQoNClllcywgdGhpcyBp cyB0aGUgc2NlbmFyaW8g4oCTIHRoZSBwaG9uZSAob3IgeW91ciBjYXLigJlzIHVwbGluaywgaWYg Y29ubmVjdGVkIHRvIGFuIGluLWNhciB3aWZpKSBoYXMgc3dpdGNoZWQgdG8gYSBkaWZmZXJlbnQg cHJvdmlkZXIuDQoNClRoaXMgaXMgbm8gZGlmZmVyZW50IHRoYW4gYSB1c3VhbCBjZWxsPC0+d2lm aSBtaWdyYXRpb24gY2FzZSBmcm9tIHRoZSByb3V0aW5nIHBlcnNwZWN0aXZlLCBhbmQgdGhlIHB1 cnBvc2Ugb2Ygc2VydmVyLWdlbmVyYXRlZCBjb25uZWN0aW9uIElEIG9uIGNsaWVudC10by1zZXJ2 ZXIgcGFja2V0cyBpcyB0byBmYWNpbGl0YXRlIHJvdXRpbmcgdG8gdGhlIGNvcnJlY3QgYmFja2Vu ZC4gIEZvciBleGFtcGxlLCBpZiB0aGUgcGFja2V0IGFycml2ZXMgYXQgYSBkaWZmZXJlbnQgYW55 Y2FzdCBwb3AsIHRoZSBpZGVudGlmeSBvZiB0aGUgb3JpZ2luYWwgcG9wIGlzIGVuY29kZWQgaW4g dGhlIGNvbm5lY3Rpb24gSUQsIGFuZCB0aGUgcGFja2V0IGNhbiBiZSB0dW5uZWxlZCB0byB0aGF0 IHBvcCAob3IgZGlyZWN0bHkgdG8gdGhlIGNvcnJlY3QgYmFja2VuZCB3aXRoaW4gdGhlIHNhbWUg b3IgYSBkaWZmZXJlbnQgcG9wKS4NCg0KDQogICogICBJZ29yDQoNCkZyb206IFRlZCBIYXJkaWUg PHRlZC5pZXRmQGdtYWlsLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE5IDI6 MjggUE0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4NCkNjOiBKYW5h IEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbT47IERhdmlkIFNjaGluYXppIDxkc2NoaW5hemku aWV0ZkBnbWFpbC5jb20+OyBxdWljQGlldGYub3JnOyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVx dWVmb3UuYmU+OyBNYXJ0aW4gVGhvbXNvbiA8bXRAbG93ZW50cm9weS5uZXQ+OyBLYXp1aG8gT2t1 IDxrYXp1aG9va3VAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IE5ldyBwYXRoID0+IG5ldyBjb25u ZWN0aW9uIElELCByaWdodD8NCg0KSGkgSWdvciwNCg0KSSBoYXZlIGEgY2xhcmlmeWluZyBxdWVz dGlvbiBvbiB0aGUgc2NlbmFyaW8gYmVsb3cuDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQgMTA6 MjggQU0gTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hl QGFrYW1haS5jb20+PiB3cm90ZToNCg0KICAqICAgRWdyZWdpb3VzIGNoYW5nZXMgaW4gSVAgbWln aHQgYmUgYSBzaWduYXR1cmUgZm9yIG5ldHdvcmsgY2hhbmdlIChjaGFuZ2UgaW4gLzE2IGFkZHJl c3MsIGZvciBpbnN0YW5jZSkgYW5kIGEgc2VydmVyIGNvdWxkIHRlcm1pbmF0ZSB0aGUgY29ubmVj dGlvbiBhbmQgcmVzcG9uZCB3aXRoIGEgc3RhdGVsZXNzIHJlc2V0IGlmIHRoaXMgaGFwcGVucy4N Cg0KVGhlIGNsaWVudCBjb3VsZCBiZSBhIGxhcHRvcCB0aGF0IGlzIHRldGhlcmVkIHZpYSBhIHBo b25lIHRoYXQgaXMgY2hhbmdpbmcgcHJvdmlkZXJzLiAgVGhlIGRpc2Nvbm5lY3Qgd291bGQgYmUg Y29tcGxldGVseSDigJxwdW5pdGl2ZeKAnSAodGhlIG9sZCBwYXRo4oCZcyBDSUQgaGFzIGFscmVh ZHkgYmVlbiBzZW50IG92ZXIgdGhlIG5ldyBwYXRoKSBhbmQgYmUgcHVuaXNoaW5nIHRoZSBjbGll bnQgZm9yIHNvbWV0aGluZyBpdCBoYWQgbm8gY29udHJvbCBvdmVyIHdoYXRzb2V2ZXIuDQoNCg0K SW4gdGhpcyBzY2VuYXJpbywgd2hhdCBpcyB5b3VyIHZpZXcgb2Ygd2hlcmUgdGhlIElQIGFkZHJl c3MgY2hhbmdlcyBhcmUgdGFraW5nIHBsYWNlPw0KDQpJIGFncmVlIHRoYXQgdGhlIGRldmljZSBj b25uZWN0ZWQgdG8gYSBwaG9uZSAoZS5nLiBieSBhIG1vYmlsZSBob3RzcG90KSB3aWxsIG5vdCBn ZW5lcmFsbHkgaGF2ZSBhIHZpZXcgb2YgdGhlIGNoYW5nZSBpbiB1cHN0cmVhbSBwYXRoLiAgSWYg dGhhdCBwaG9uZSBpcyB1c2luZyBzb21ldGhpbmcgbGlrZSBtb2JpbGUgSVAgb3IgYSBWUE4gdG8g aGF2ZSBhIGNvbnNpc3RlbnQgZXh0ZXJuYWwgYWRkcmVzcywgdGhlbiBJIGFsc28gZG9uJ3Qgc2Vl IHdoeSB0aGlzIHBhdGggY2hhbmdlIHdvdWxkIHRyaWdnZXIgYW55IGNoYW5nZSBpbiBDSUQuICBC dXQgaWYgdGhlIHBob25lL2hvdHNwb3QncyBJUCBhZGRyZXNzIGNoYW5nZXMgZHVyaW5nIHRoaXMg ZnJvbSBvbmUgcHJvdmlkZXIncyBzZXQgb2YgYWRkcmVzc2VzIHRvIGFub3RoZXIsIHRoaXMgaXMg ZnVuY3Rpb25hbGx5IHJlLWhvbWluZy4gIEluIHRoYXQgY2FzZSwgaXNuJ3QgdGhlcmUgYWxyZWFk eSBhIGhpZ2ggcmlzayB0aGF0IHRoZSB0cmFmZmljIHdpbGwgZW5kIHVwIGF0IGEgZGlmZmVyZW50 IGJhY2sgZW5kIGJlY2F1c2Ugb2YgdGhlIElQIGNoYW5nZT8NCg0KVGhhbmtzIGZvciBzaGFyaW5n IHlvdXIgdGhvdWdodHMgb24gdGhpcywNCg0KVGVkDQoNCg0KICAqICAgSWdvcg0KDQpGcm9tOiBK YW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86anJpLmlldGZAZ21haWwuY29t Pj4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE5IDY6NDIgQU0NClRvOiBEYXZpZCBT Y2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0bzpkc2NoaW5hemkuaWV0ZkBn bWFpbC5jb20+Pg0KQ2M6IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+OyBNaWtl IEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJl Pj47IE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldDxtYWlsdG86bXRAbG93ZW50cm9w eS5uZXQ+PjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1 QGdtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogTmV3IHBhdGggPT4gbmV3IGNvbm5lY3Rpb24gSUQs IHJpZ2h0Pw0KDQpJIGFncmVlIHRoYXQgd2FudCB0byBoYXZlIE1VU1QgZm9yIGNoYW5naW5nIENJ RCBhbmQgTVVTVCBOT1QgZm9yIHNlbmRpbmcgcGFja2V0cyB3aXRoIHRoZSBzYW1lIENJRCBvbiBt dWx0aXBsZSBwYXRocy4gIEkgdGhvdWdodCB3ZSBoYWQgYWdyZWVkIG9uIHRoaXMgaW4gdGhlIHBh c3QsIGJ1dCBJIGNvdWxkIGJlIG1pc3JlbWVtYmVyaW5nLg0KDQpJIHVuZGVyc3RhbmQgdGhhdCB0 aGUgc2VydmVyIGNhbm5vdCBuZWNlc3NhcmlseSB0ZWxsIHRoaXMgZnJvbSBOQVQgcmViaW5kaW5n LCBidXQgaXQgaXMgdXAgdG8gdGhlIHNlcnZlciB3aGF0IGl0IGRvZXMgaWYgaXQgc2VlcyBhbiBJ UC9wb3J0IGNoYW5nZSB3aXRoIG5vIGFjY29tcGFueWluZyBDSUQgY2hhbmdlLiAgRWdyZWdpb3Vz IGNoYW5nZXMgaW4gSVAgbWlnaHQgYmUgYSBzaWduYXR1cmUgZm9yIG5ldHdvcmsgY2hhbmdlIChj aGFuZ2UgaW4gLzE2IGFkZHJlc3MsIGZvciBpbnN0YW5jZSkgYW5kIGEgc2VydmVyIGNvdWxkIHRl cm1pbmF0ZSB0aGUgY29ubmVjdGlvbiBhbmQgcmVzcG9uZCB3aXRoIGEgc3RhdGVsZXNzIHJlc2V0 IGlmIHRoaXMgaGFwcGVucy4gIEEgY2xpZW50IHRoYXQgaWdub3JlcyB0aGUgTVVTVCBhbmQgdXNl cyB0aGUgc2FtZSBDSUQgYWNyb3NzIG5ldHdvcmtzIHdvdWxkIHRoZW4gcmlzayBnZXR0aW5nIHRo ZSBjb25uZWN0aW9uIHRlcm1pbmF0ZWQuICBJIHN1Z2dlc3QgdGhhdCB3ZSBhZGQgc29tZSBkaXNj dXNzaW9uIGFib3V0IHBvdGVudGlhbCBzZXJ2ZXIgcmVzcG9uc2VzIHRvIGNsaWVudHMgdGhhdCB2 aW9sYXRlIG5vcm1hdGl2ZSBleHBlY3RhdGlvbnMuDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQg ODoxMyBBTSBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0bzpk c2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkF0IHRoZSBlbmQgb2YgdGhlIGRheSwg eW91IGNhbiBtYWtlIGl0IGEgTVVTVCwgYnV0IGNsaWVudHMgd2lsbCBkbyB3aGF0IHRoZXkgcGxl YXNlIGJlY2F1c2Ugc2VydmVycyBjYW4ndCBlbmZvcmNlIGl0Lg0KQnV0IEkgd29uJ3QgZGllIG9u IHRoaXMgaGlsbCwgSSBjYW4gbGl2ZSB3aXRoIGJlaW5nIGRlY2xhcmVkIGluIHRoZSByb3VnaCBv biB0aGlzIG9uZS4NCg0KRGF2aWQNCg0KT24gTW9uLCBGZWIgNCwgMjAxOSBhdCA1OjM3IFBNIEth enVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+ PiB3cm90ZToNCjIwMTnlubQy5pyINeaXpSjngaspIDEwOjA4IERhdmlkIFNjaGluYXppIDxkc2No aW5hemkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4+Og0K Pg0KPiBJZiBhbiBlbmRwb2ludCBpbnRlbnRpb25hbGx5IG1pZ3JhdGVzIGFuZCBpdCBoYXMgdW51 c2VkIGNvbm5lY3Rpb24gSURzIHRvIHVzZSwgaXQgbWFrZXMgc2Vuc2UgdG8gbWFuZGF0ZSBpdCBN VVNUIHN3aXRjaCB0byBvbmUgb2YgdGhlIHVudXNlZCBjb25uZWN0aW9uIElEcy4NCj4gSG93ZXZl ciwgaWYgaXQgaGFzIHJ1biBvdXQgb2YgdW51c2VkIGNvbm5lY3Rpb24gSURzIHRoZW4gSSB3b3Vs ZCBsZXQgdGhlIGVuZHBvaW50IGRlY2lkZSBpZiBpdCB3YW50cyB0byBjbG9zZSB0aGUgY29ubmVj dGlvbiBvciBtaWdyYXRlIHdpdGggYSBwcmV2aW91c2x5IHVzZWQgY29ubmVjdGlvbiBJRHMsIGFz IHRoZXJlIGFyZSB1c2UtY2FzZXMgdGhhdCB2YWx1ZSBwZXJmb3JtYW5jZSBvdmVyIG5vbi1saW5r YWJpbGl0eS4NCg0KSSB0aGluayBJIG1pZ2h0IHByZWZlciBlbmNvdXJhZ2luZyBlbmRwb2ludHMg dG8gZ3JhY2VmdWxseSBjbG9zZSB0aGUNCmNvbm5lY3Rpb24gYmVmb3JlIGl0IGZhY2VzIGEgdHJh ZGUtb2ZmIGJldHdlZW4gcGVyZm9ybWFuY2UgYW5kDQpsaW5rYWJpbGl0eS4NCg0KVGhlcmVmb3Jl LCBhc3N1bWluZyB0aGF0IHdlIGFkb3B0IE1hcnRpbidzIHByb3Bvc2FsLCBJIHRoaW5rIGl0IHdv dWxkDQptYWtlIHNlbnNlIHRvIHJlY29tbWVuZCBhbiBlbmRwb2ludCB0byBzZW5kIEdPQVdBWSB3 aGVuIGlmIGl0IGNhbiBubw0KbG9uZ2VyIGlzc3VlIGEgbmV3IENJRCBmb3IgdGhhdCBRVUlDIGNv bm5lY3Rpb24uDQoNCj4gRmluYWxseSwgdGhpcyBjYW5ub3QgYmUgZW5mb3JjZWQgYnkgdGhlIHBl ZXIgc2luY2UgaXQgY2Fubm90IGRpc3Rpbmd1aXNoIGludGVudGlvbmFsIG1pZ3JhdGlvbiBhbmQg dW5pbnRlbnRpb25hbCBtaWdyYXRpb24gKE5BVCByZWJpbmRpbmcpLCBhbmQgd2UgZGlzY3Vzc2Vk IGluIFRva3lvIHRoYXQgd2Ugd2FudGVkIHRvIGF2b2lkIG5vbi1lbmZvcmNlYWJsZSBNVVNUcy4N Cj4NCj4gRGF2aWQNCj4NCj4gT24gTW9uLCBGZWIgNCwgMjAxOSBhdCA0OjU2IFBNIE1pa2UgQmlz aG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3 cm90ZToNCj4+DQo+PiBUaGUgdGV4dCBpcyB0aGVyZSwgYnV0IGl0J3MgcGVyaGFwcyBub3QgY29t cGxldGU6DQo+Pg0KPj4gQXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gOS41LCBlYWNoIGNvbm5lY3Rp b24gSUQgTVVTVCBiZSB1c2VkIG9uIHBhY2tldHMgc2VudCBmcm9tIG9ubHkgb25lIGxvY2FsIGFk ZHJlc3MuIEFuIGVuZHBvaW50IHRoYXQgbWlncmF0ZXMgYXdheSBmcm9tIGEgbG9jYWwgYWRkcmVz cyBTSE9VTEQgcmV0aXJlIGFsbCBjb25uZWN0aW9uIElEcyB1c2VkIG9uIHRoYXQgYWRkcmVzcyBv bmNlIGl0IG5vIGxvbmdlciBwbGFucyB0byB1c2UgdGhhdCBhZGRyZXNzLg0KPj4NCj4+DQo+Pg0K Pj4gVGhlIGdhcCBzZWVtcyB0byBiZSB0aGF0IHdoZW4geW91ciBwZWVyIG1vdmVzIHRvIGEgbmV3 IGFkZHJlc3MsIHRoZXJl4oCZcyBubyByZXF1aXJlbWVudCB0aGF0IHlvdSBub3Qgc2VuZCB0aGUg c2FtZSBDSUQgdG8gdGhlaXIgbmV3IGFkZHJlc3MgdGhhdCB5b3UgdXNlZCB0b3dhcmQgdGhlaXIg b2xkIGFkZHJlc3MuDQo+Pg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNA aWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NCj4+IFNlbnQ6IE1vbmRheSwg RmVicnVhcnkgNCwgMjAxOSAzOjE1IFBNDQo+PiBUbzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVp Y0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IE5ldyBwYXRoID0+IG5ldyBjb25uZWN0aW9uIElELCBy aWdodD8NCj4+DQo+Pg0KPj4NCj4+IEkgdGhvdWdodCB0aGF0IHdlIGhhZCBhZ3JlZWQgdGhhdCBh biBlbmRwb2ludCB0aGF0IGludGVudGlvbmFsbHkgbWlncmF0ZXMgaGFzIHRvIHVzZSBhIG5ldyBj b25uZWN0aW9uIElEIG9uIHRoZSBuZXcgcGF0aC4gIEJ1dCBJIGNvdWxkbid0IGZpbmQgYW55ICJN VVNUIiBpbiB0aGUgc3BlYyB0aGF0IHNhaWQgdGhhdC4NCj4+DQo+Pg0KPj4NCj4+IE9uIHRoZSBv ZmYgY2hhbmNlIHRoYXQgdGhpcyB3YXNuJ3QganVzdCBhIG1pc3Rha2UgYW5kIHRoZXJlIHdhcyBz b21lIGdvb2QgcmVhc29uIG5vdCB0byBtYW5kYXRlIHRoaXMsIEknbSBicmluZ2luZyB0aGUgZGlz Y3Vzc2lvbiBoZXJlLg0KPj4NCj4+DQo+Pg0KPj4gSSd2ZSBvcGVuZWQgYSBkZXNpZ24gaXNzdWU6 DQo+Pg0KPj4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjQx MzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dp dGh1Yi5jb21fcXVpY3dnX2Jhc2UtMkRkcmFmdHNfaXNzdWVzXzI0MTMmZD1Ed01GYVEmYz05Nlpi WlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9t NTVLUG1sbyZtPTRCOGkzTzJRNmI2TmZaZE1JRmRzQjBTbHJjbUQ1MFRjMjRVRm80eENHaVkmcz01 bHI4Y3ppWmZYMkE5QldEM0w4WnY4aTFSM3p5SllDaXpxdkJqY09tdXlzJmU9Pg0KPj4NCj4+DQo+ Pg0KPj4gVGhlIGNoYW5nZSBJJ20gcHJvcG9zaW5nIGlzIGhlcmU6DQo+Pg0KPj4gaHR0cHM6Ly9n aXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzI0MTQvY29tbWl0cy8xMzY5OGNiZTMx MTkyMmEzOTk1MjM2ZGRhOTYwYjRjZGZmNDllMzZmPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9xdWljd2dfYmFzZS0yRGRyYWZ0 c19wdWxsXzI0MTRfY29tbWl0c18xMzY5OGNiZTMxMTkyMmEzOTk1MjM2ZGRhOTYwYjRjZGZmNDll MzZmJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1fMnNr ZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT00QjhpM08yUTZiNk5mWmRNSUZkc0IwU2xyY21E NTBUYzI0VUZvNHhDR2lZJnM9UjAtanVlV2dhdFQ1V0RrZFlRaV9KVlpGYWNneS1jQUFBNFAydW9z dDNqdyZlPT4NCj4+DQo+Pg0KDQoNCg0KLS0NCkthenVobyBPa3UNCg== --_000_650fd9704aea40edb496a1d3df0b6cdbusma1exdag1mb6msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwt bTkxNzUzMjU3MzA1NTY1Njg0NDBtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tOTE3NTMyNTcz MDU1NjU2ODQ0MG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tOTE3NTMyNTczMDU1NjU2ODQ0 MG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV85MTc1MzI1NzMwNTU2 NTY4NDQwbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDo2MTk2NTM1MDc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi00NzIzNDc2NDAgMTU2NDM4NDU0MCA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ7DQoJbXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx DQoJe21zby1saXN0LWlkOjk5MDEzODU0MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6NTAyODU1MTkyIDE3NDE0NTYxNTQgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0Ow0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlz dC1pZDoxMjU4MTAxMDczOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDYzMDMwNTYwO30NCkBs aXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTcyOTg0MDM3NTsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTU4NDA1Njc1NDt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEg bGZvMyI+QnV0IGlmIHRoZSBwaG9uZS9ob3RzcG90J3MgSVAgYWRkcmVzcyBjaGFuZ2VzIGR1cmlu ZyB0aGlzIGZyb20gb25lIHByb3ZpZGVyJ3Mgc2V0IG9mIGFkZHJlc3NlcyB0byBhbm90aGVyLCB0 aGlzIGlzIGZ1bmN0aW9uYWxseSByZS1ob21pbmcuJm5ic3A7IEluIHRoYXQgY2FzZSwgaXNuJ3Qg dGhlcmUgYWxyZWFkeSBhIGhpZ2gNCiByaXNrIHRoYXQgdGhlIHRyYWZmaWMgd2lsbCBlbmQgdXAg YXQgYSBkaWZmZXJlbnQgYmFjayBlbmQgYmVjYXVzZSBvZiB0aGUgSVAgY2hhbmdlPzxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoaXMgaXMgdGhlIHNjZW5hcmlvIOKAkyB0aGUg cGhvbmUgKG9yIHlvdXIgY2Fy4oCZcyB1cGxpbmssIGlmIGNvbm5lY3RlZCB0byBhbiBpbi1jYXIg d2lmaSkgaGFzIHN3aXRjaGVkIHRvIGEgZGlmZmVyZW50IHByb3ZpZGVyLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGlzIG5vIGRpZmZlcmVudCB0aGFuIGEgdXN1YWwgY2VsbCZsdDstJmd0 O3dpZmkgbWlncmF0aW9uIGNhc2UgZnJvbSB0aGUgcm91dGluZyBwZXJzcGVjdGl2ZSwgYW5kIHRo ZSBwdXJwb3NlIG9mIHNlcnZlci1nZW5lcmF0ZWQgY29ubmVjdGlvbiBJRCBvbiBjbGllbnQtdG8t c2VydmVyIHBhY2tldHMgaXMgdG8gZmFjaWxpdGF0ZSByb3V0aW5nIHRvIHRoZSBjb3JyZWN0IGJh Y2tlbmQuICZuYnNwO0ZvciBleGFtcGxlLCBpZiB0aGUNCiBwYWNrZXQgYXJyaXZlcyBhdCBhIGRp ZmZlcmVudCBhbnljYXN0IHBvcCwgdGhlIGlkZW50aWZ5IG9mIHRoZSBvcmlnaW5hbCBwb3AgaXMg ZW5jb2RlZCBpbiB0aGUgY29ubmVjdGlvbiBJRCwgYW5kIHRoZSBwYWNrZXQgY2FuIGJlIHR1bm5l bGVkIHRvIHRoYXQgcG9wIChvciBkaXJlY3RseSB0byB0aGUgY29ycmVjdCBiYWNrZW5kIHdpdGhp biB0aGUgc2FtZSBvciBhIGRpZmZlcmVudCBwb3ApLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+SWdvcjxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBn bWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAwNSwgMjAx OSAyOjI4IFBNPGJyPg0KPGI+VG86PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWth bWFpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEphbmEgSXllbmdhciAmbHQ7anJpLmlldGZAZ21h aWwuY29tJmd0OzsgRGF2aWQgU2NoaW5hemkgJmx0O2RzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSZn dDs7IHF1aWNAaWV0Zi5vcmc7IE1pa2UgQmlzaG9wICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZn dDs7IE1hcnRpbiBUaG9tc29uICZsdDttdEBsb3dlbnRyb3B5Lm5ldCZndDs7IEthenVobyBPa3Ug Jmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBOZXcg cGF0aCA9Jmd0OyBuZXcgY29ubmVjdGlvbiBJRCwgcmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIElnb3IsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIGNsYXJpZnlp bmcgcXVlc3Rpb24gb24gdGhlIHNjZW5hcmlvIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgNSwgMjAxOSBhdCAxMDoyOCBBTSBM dWJhc2hldiwgSWdvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iPmls dWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJn bWFpbC1tOTE3NTMyNTczMDU1NjU2ODQ0MG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlz dDpsMiBsZXZlbDEgbGZvMSI+DQpFZ3JlZ2lvdXMgY2hhbmdlcyBpbiBJUCBtaWdodCBiZSBhIHNp Z25hdHVyZSBmb3IgbmV0d29yayBjaGFuZ2UgKGNoYW5nZSBpbiAvMTYgYWRkcmVzcywgZm9yIGlu c3RhbmNlKSBhbmQgYSBzZXJ2ZXIgY291bGQgdGVybWluYXRlIHRoZSBjb25uZWN0aW9uIGFuZCBy ZXNwb25kIHdpdGggYSBzdGF0ZWxlc3MgcmVzZXQgaWYgdGhpcyBoYXBwZW5zLjxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGNsaWVudCBjb3VsZCBiZSBhIGxhcHRvcCB0aGF0 IGlzIHRldGhlcmVkIHZpYSBhIHBob25lIHRoYXQgaXMgY2hhbmdpbmcgcHJvdmlkZXJzLiZuYnNw OyBUaGUgZGlzY29ubmVjdCB3b3VsZCBiZSBjb21wbGV0ZWx5IOKAnHB1bml0aXZl4oCdICh0aGUg b2xkIHBhdGjigJlzIENJRCBoYXMgYWxyZWFkeSBiZWVuIHNlbnQgb3Zlcg0KIHRoZSBuZXcgcGF0 aCkgYW5kIGJlIHB1bmlzaGluZyB0aGUgY2xpZW50IGZvciBzb21ldGhpbmcgaXQgaGFkIG5vIGNv bnRyb2wgb3ZlciB3aGF0c29ldmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGlzIHNjZW5hcmlvLCB3aGF0IGlz IHlvdXIgdmlldyBvZiB3aGVyZSB0aGUgSVAgYWRkcmVzcyBjaGFuZ2VzIGFyZSB0YWtpbmcgcGxh Y2U/DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBhZ3JlZSB0aGF0IHRoZSBkZXZpY2UgY29ubmVjdGVkIHRvIGEgcGhvbmUgKGUuZy4gYnkg YSBtb2JpbGUgaG90c3BvdCkgd2lsbCBub3QgZ2VuZXJhbGx5IGhhdmUgYSB2aWV3IG9mIHRoZSBj aGFuZ2UgaW4gdXBzdHJlYW0gcGF0aC4mbmJzcDsgSWYgdGhhdCBwaG9uZSBpcyB1c2luZyBzb21l dGhpbmcgbGlrZSBtb2JpbGUgSVAgb3IgYSBWUE4gdG8gaGF2ZSBhIGNvbnNpc3RlbnQgZXh0ZXJu YWwgYWRkcmVzcywgdGhlbg0KIEkgYWxzbyBkb24ndCBzZWUgd2h5IHRoaXMgcGF0aCBjaGFuZ2Ug d291bGQgdHJpZ2dlciBhbnkgY2hhbmdlIGluIENJRC4mbmJzcDsgQnV0IGlmIHRoZSBwaG9uZS9o b3RzcG90J3MgSVAgYWRkcmVzcyBjaGFuZ2VzIGR1cmluZyB0aGlzIGZyb20gb25lIHByb3ZpZGVy J3Mgc2V0IG9mIGFkZHJlc3NlcyB0byBhbm90aGVyLCB0aGlzIGlzIGZ1bmN0aW9uYWxseSByZS1o b21pbmcuJm5ic3A7IEluIHRoYXQgY2FzZSwgaXNuJ3QgdGhlcmUgYWxyZWFkeSBhIGhpZ2ggcmlz aw0KIHRoYXQgdGhlIHRyYWZmaWMgd2lsbCBlbmQgdXAgYXQgYSBkaWZmZXJlbnQgYmFjayBlbmQg YmVjYXVzZSBvZiB0aGUgSVAgY2hhbmdlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHNoYXJpbmcgeW91ciB0aG91Z2h0cyBv biB0aGlzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9ImdtYWlsLW05MTc1MzI1NzMwNTU2NTY4 NDQwbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwzIGxldmVsMSBsZm8yIj4NCkln b3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3 aW5kb3d0ZXh0IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7Ym9yZGVyLWNvbG9yOmN1 cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGJsdWUiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNv bG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IEphbmEgSXllbmdhciAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpy aS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVi cnVhcnkgMDUsIDIwMTkgNjo0MiBBTTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgU2NoaW5hemkgJmx0 OzxhIGhyZWY9Im1haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5kc2NoaW5hemkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9h PjsgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIg dGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDs7IE1hcnRpbiBUaG9t c29uICZsdDs8YSBocmVmPSJtYWlsdG86bXRAbG93ZW50cm9weS5uZXQiIHRhcmdldD0iX2JsYW5r Ij5tdEBsb3dlbnRyb3B5Lm5ldDwvYT4mZ3Q7Ow0KIEthenVobyBPa3UgJmx0OzxhIGhyZWY9Im1h aWx0bzprYXp1aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhvb2t1QGdtYWls LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBOZXcgcGF0aCA9Jmd0OyBuZXcg Y29ubmVjdGlvbiBJRCwgcmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgYWdyZWUgdGhhdCB3YW50IHRvIGhhdmUgTVVTVCBmb3IgY2hhbmdp bmcgQ0lEIGFuZCBNVVNUIE5PVCBmb3Igc2VuZGluZyBwYWNrZXRzIHdpdGggdGhlIHNhbWUgQ0lE IG9uIG11bHRpcGxlIHBhdGhzLiZuYnNwOyBJIHRob3VnaHQgd2UgaGFkIGFncmVlZCBvbiB0aGlz IGluIHRoZSBwYXN0LCBidXQgSSBjb3VsZCBiZQ0KIG1pc3JlbWVtYmVyaW5nLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdW5kZXJzdGFuZCB0aGF0 IHRoZSBzZXJ2ZXIgY2Fubm90IG5lY2Vzc2FyaWx5IHRlbGwgdGhpcyBmcm9tIE5BVCByZWJpbmRp bmcsIGJ1dCBpdCBpcyB1cCB0byB0aGUgc2VydmVyIHdoYXQgaXQgZG9lcyBpZiBpdCBzZWVzIGFu IElQL3BvcnQgY2hhbmdlIHdpdGggbm8gYWNjb21wYW55aW5nIENJRCBjaGFuZ2UuJm5ic3A7DQog RWdyZWdpb3VzIGNoYW5nZXMgaW4gSVAgbWlnaHQgYmUgYSBzaWduYXR1cmUgZm9yIG5ldHdvcmsg Y2hhbmdlIChjaGFuZ2UgaW4gLzE2IGFkZHJlc3MsIGZvciBpbnN0YW5jZSkgYW5kIGEgc2VydmVy IGNvdWxkIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiBhbmQgcmVzcG9uZCB3aXRoIGEgc3RhdGVs ZXNzIHJlc2V0IGlmIHRoaXMgaGFwcGVucy4mbmJzcDsgQSBjbGllbnQgdGhhdCBpZ25vcmVzIHRo ZSBNVVNUIGFuZCB1c2VzIHRoZSBzYW1lIENJRCBhY3Jvc3MNCiBuZXR3b3JrcyB3b3VsZCB0aGVu IHJpc2sgZ2V0dGluZyB0aGUgY29ubmVjdGlvbiB0ZXJtaW5hdGVkLiZuYnNwOyBJIHN1Z2dlc3Qg dGhhdCB3ZSBhZGQgc29tZSBkaXNjdXNzaW9uIGFib3V0IHBvdGVudGlhbCBzZXJ2ZXIgcmVzcG9u c2VzIHRvIGNsaWVudHMgdGhhdCB2aW9sYXRlIG5vcm1hdGl2ZSBleHBlY3RhdGlvbnMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBU dWUsIEZlYiA1LCAyMDE5IGF0IDg6MTMgQU0gRGF2aWQgU2NoaW5hemkgJmx0OzxhIGhyZWY9Im1h aWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kc2NoaW5hemku aWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29s b3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0 KSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BdCB0aGUgZW5kIG9mIHRoZSBkYXks IHlvdSBjYW4gbWFrZSBpdCBhIE1VU1QsIGJ1dCBjbGllbnRzIHdpbGwgZG8gd2hhdCB0aGV5IHBs ZWFzZSBiZWNhdXNlIHNlcnZlcnMgY2FuJ3QgZW5mb3JjZSBpdC48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJ1dCBJIHdvbid0IGRpZSBvbiB0aGlzIGhpbGws IEkgY2FuIGxpdmUgd2l0aCBiZWluZyBkZWNsYXJlZCBpbiB0aGUgcm91Z2ggb24gdGhpcyBvbmUu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RGF2aWQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gTW9uLCBGZWIgNCwgMjAxOSBhdCA1OjM3IFBNIEthenVobyBPa3UgJmx0Ozxh IGhyZWY9Im1haWx0bzprYXp1aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhv b2t1QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xv cjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQp Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxOTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuW5tDwvc3Bhbj4yPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPjU8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPueBqzwvc3Bhbj4pDQogMTA6MDggRGF2aWQgU2No aW5hemkgJmx0OzxhIGhyZWY9Im1haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5kc2NoaW5hemkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJZiBhbiBlbmRwb2ludCBpbnRlbnRpb25hbGx5IG1pZ3JhdGVzIGFuZCBpdCBoYXMg dW51c2VkIGNvbm5lY3Rpb24gSURzIHRvIHVzZSwgaXQgbWFrZXMgc2Vuc2UgdG8gbWFuZGF0ZSBp dCBNVVNUIHN3aXRjaCB0byBvbmUgb2YgdGhlIHVudXNlZCBjb25uZWN0aW9uIElEcy48YnI+DQom Z3Q7IEhvd2V2ZXIsIGlmIGl0IGhhcyBydW4gb3V0IG9mIHVudXNlZCBjb25uZWN0aW9uIElEcyB0 aGVuIEkgd291bGQgbGV0IHRoZSBlbmRwb2ludCBkZWNpZGUgaWYgaXQgd2FudHMgdG8gY2xvc2Ug dGhlIGNvbm5lY3Rpb24gb3IgbWlncmF0ZSB3aXRoIGEgcHJldmlvdXNseSB1c2VkIGNvbm5lY3Rp b24gSURzLCBhcyB0aGVyZSBhcmUgdXNlLWNhc2VzIHRoYXQgdmFsdWUgcGVyZm9ybWFuY2Ugb3Zl ciBub24tbGlua2FiaWxpdHkuPGJyPg0KPGJyPg0KSSB0aGluayBJIG1pZ2h0IHByZWZlciBlbmNv dXJhZ2luZyBlbmRwb2ludHMgdG8gZ3JhY2VmdWxseSBjbG9zZSB0aGU8YnI+DQpjb25uZWN0aW9u IGJlZm9yZSBpdCBmYWNlcyBhIHRyYWRlLW9mZiBiZXR3ZWVuIHBlcmZvcm1hbmNlIGFuZDxicj4N CmxpbmthYmlsaXR5Ljxicj4NCjxicj4NClRoZXJlZm9yZSwgYXNzdW1pbmcgdGhhdCB3ZSBhZG9w dCBNYXJ0aW4ncyBwcm9wb3NhbCwgSSB0aGluayBpdCB3b3VsZDxicj4NCm1ha2Ugc2Vuc2UgdG8g cmVjb21tZW5kIGFuIGVuZHBvaW50IHRvIHNlbmQgR09BV0FZIHdoZW4gaWYgaXQgY2FuIG5vPGJy Pg0KbG9uZ2VyIGlzc3VlIGEgbmV3IENJRCBmb3IgdGhhdCBRVUlDIGNvbm5lY3Rpb24uPGJyPg0K PGJyPg0KJmd0OyBGaW5hbGx5LCB0aGlzIGNhbm5vdCBiZSBlbmZvcmNlZCBieSB0aGUgcGVlciBz aW5jZSBpdCBjYW5ub3QgZGlzdGluZ3Vpc2ggaW50ZW50aW9uYWwgbWlncmF0aW9uIGFuZCB1bmlu dGVudGlvbmFsIG1pZ3JhdGlvbiAoTkFUIHJlYmluZGluZyksIGFuZCB3ZSBkaXNjdXNzZWQgaW4g VG9reW8gdGhhdCB3ZSB3YW50ZWQgdG8gYXZvaWQgbm9uLWVuZm9yY2VhYmxlIE1VU1RzLjxicj4N CiZndDs8YnI+DQomZ3Q7IERhdmlkPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gTW9uLCBGZWIgNCwg MjAxOSBhdCA0OjU2IFBNIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBl dmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIHRleHQgaXMgdGhlcmUsIGJ1 dCBpdCdzIHBlcmhhcHMgbm90IGNvbXBsZXRlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg QXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gOS41LCBlYWNoIGNvbm5lY3Rpb24gSUQgTVVTVCBiZSB1 c2VkIG9uIHBhY2tldHMgc2VudCBmcm9tIG9ubHkgb25lIGxvY2FsIGFkZHJlc3MuIEFuIGVuZHBv aW50IHRoYXQgbWlncmF0ZXMgYXdheSBmcm9tIGEgbG9jYWwgYWRkcmVzcyBTSE9VTEQgcmV0aXJl IGFsbCBjb25uZWN0aW9uIElEcyB1c2VkIG9uIHRoYXQgYWRkcmVzcyBvbmNlIGl0IG5vIGxvbmdl ciBwbGFucyB0byB1c2UgdGhhdCBhZGRyZXNzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBnYXAgc2VlbXMgdG8gYmUgdGhhdCB3aGVu IHlvdXIgcGVlciBtb3ZlcyB0byBhIG5ldyBhZGRyZXNzLCB0aGVyZeKAmXMgbm8gcmVxdWlyZW1l bnQgdGhhdCB5b3Ugbm90IHNlbmQgdGhlIHNhbWUgQ0lEIHRvIHRoZWlyIG5ldyBhZGRyZXNzIHRo YXQgeW91IHVzZWQgdG93YXJkIHRoZWlyIG9sZCBhZGRyZXNzLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogUVVJQyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbjxicj4NCiZndDsmZ3Q7IFNlbnQ6IE1v bmRheSwgRmVicnVhcnkgNCwgMjAxOSAzOjE1IFBNPGJyPg0KJmd0OyZndDsgVG86IDxhIGhyZWY9 Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBOZXcgcGF0aCA9Jmd0OyBuZXcgY29ubmVjdGlvbiBJRCwg cmlnaHQ/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgSSB0aG91Z2h0IHRoYXQgd2UgaGFkIGFncmVlZCB0aGF0IGFuIGVuZHBvaW50IHRoYXQg aW50ZW50aW9uYWxseSBtaWdyYXRlcyBoYXMgdG8gdXNlIGEgbmV3IGNvbm5lY3Rpb24gSUQgb24g dGhlIG5ldyBwYXRoLiZuYnNwOyBCdXQgSSBjb3VsZG4ndCBmaW5kIGFueSAmcXVvdDtNVVNUJnF1 b3Q7IGluIHRoZSBzcGVjIHRoYXQgc2FpZCB0aGF0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIHRoZSBvZmYgY2hhbmNlIHRoYXQgdGhp cyB3YXNuJ3QganVzdCBhIG1pc3Rha2UgYW5kIHRoZXJlIHdhcyBzb21lIGdvb2QgcmVhc29uIG5v dCB0byBtYW5kYXRlIHRoaXMsIEknbSBicmluZ2luZyB0aGUgZGlzY3Vzc2lvbiBoZXJlLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkndmUg b3BlbmVkIGEgZGVzaWduIGlzc3VlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19n aXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lzc3Vlc18yNDEzJmFtcDtkPUR3TUZhUSZh bXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcx dHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209NEI4aTNPMlE2YjZOZlpkTUlGZHNCMFNscmNtRDUw VGMyNFVGbzR4Q0dpWSZhbXA7cz01bHI4Y3ppWmZYMkE5QldEM0w4WnY4aTFSM3p5SllDaXpxdkJq Y09tdXlzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3 Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjQxMzwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgY2hhbmdlIEknbSBwcm9wb3NpbmcgaXMg aGVyZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9xdWljd2df YmFzZS0yRGRyYWZ0c19wdWxsXzI0MTRfY29tbWl0c18xMzY5OGNiZTMxMTkyMmEzOTk1MjM2ZGRh OTYwYjRjZGZmNDllMzZmJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpn JmFtcDtyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209 NEI4aTNPMlE2YjZOZlpkTUlGZHNCMFNscmNtRDUwVGMyNFVGbzR4Q0dpWSZhbXA7cz1SMC1qdWVX Z2F0VDVXRGtkWVFpX0pWWkZhY2d5LWNBQUE0UDJ1b3N0M2p3JmFtcDtlPSIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzI0MTQvY29t bWl0cy8xMzY5OGNiZTMxMTkyMmEzOTk1MjM2ZGRhOTYwYjRjZGZmNDllMzZmPC9hPjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQpLYXp1 aG8gT2t1PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_650fd9704aea40edb496a1d3df0b6cdbusma1exdag1mb6msgcorpak_-- From nobody Tue Feb 5 13:56:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37892131301 for ; Tue, 5 Feb 2019 13:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KPuNDhdD4_-v for ; Tue, 5 Feb 2019 13:56:34 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2271312FC for ; Tue, 5 Feb 2019 13:56:32 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx128.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gr8hM-000JoS-Em for quic@ietf.org; Tue, 05 Feb 2019 22:56:28 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gr8hJ-0003OW-4s for quic@ietf.org; Tue, 05 Feb 2019 16:56:05 -0500 Received: (qmail 7902 invoked from network); 5 Feb 2019 21:55:51 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Feb 2019 21:55:51 -0000 To: "Lubashev, Igor" , Ted Hardie Cc: Jana Iyengar , Mike Bishop , David Schinazi , "quic@ietf.org" , Martin Thomson , Kazuho Oku References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <236292a7-c426-ae35-e8ae-43a61f59bbb7@huitema.net> Date: Tue, 5 Feb 2019 11:55:49 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------66E778353C53EBB20A9B8809" Content-Language: en-US Subject: Re: New path => new connection ID, right? X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.18) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5mYtpFhlLdDSt+Yltedb0Uh602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViZHi/RitSd7KVWTcdmwvv8c7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBMtTRquENyRIJu/sK6SVySE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMQxbKobwRbLtrs+GXph9QXjbBF60t09JPqYDV9lpEWTlgsAq4+i3mVp sXck914tAghk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlsfj3cQFz5QBYZW/yDwrWuVZYSpQQtCkh8qZ SV0LCxtec+P6A87Leizl3ra0f9DKImkgqSCc59carlBOd3bufRUhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK//KzSfzfwEldM3jWkCPmDu9UshveVgoiypAicYsWUtd9a2LHJVD1n7GG0fP 4s+aIo4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 21:56:37 -0000 This is a multi-part message in MIME format. --------------66E778353C53EBB20A9B8809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/5/2019 11:33 AM, Lubashev, Igor wrote: > > * But if the phone/hotspot's IP address changes during this from one > provider's set of addresses to another, this is functionally > re-homing.=C2=A0 In that case, isn't there already a high risk that= the > traffic will end up at a different back end because of the IP chang= e? > > =C2=A0 > > Yes, this is the scenario =E2=80=93 the phone (or your car=E2=80=99s up= link, if > connected to an in-car wifi) has switched to a different provider. > > =C2=A0 > > This is no different than a usual cell<->wifi migration case from the > routing perspective, and the purpose of server-generated connection ID > on client-to-server packets is to facilitate routing to the correct > backend. =C2=A0For example, if the packet arrives at a different anycas= t > pop, the identify of the original pop is encoded in the connection ID, > and the packet can be tunneled to that pop (or directly to the correct > backend within the same or a different pop). > > =C2=A0 > > * Igor > Igor, in the scenario that you describe, a TCP connection would break -- since TCP connections are identified by the 5-tuple. So I don't think users would be surprised if a QUIC connection broke too. But at least for IPv6, there is a simple fix. The phone typically sends router advertisements for the new prefix when it gets a new IPv6 connection. The laptop will notice that and configure a new IPv6 address. If the QUIC stack subscribes to the system's "change of address" event, it can initiate a voluntary migration. -- Christian Huitema --------------66E778353C53EBB20A9B8809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/5/2019 11:33 AM, Lubashev, Igor wrote:
  • But if the phone/hotspot's IP address changes during this from one provider's set of addresses to another, this is functionally re-homing.  In that case, isn't there already a high risk that the traffic will end up at a different back end because of the IP change?

 

Yes, this is the scenario – the phone (or your car’s uplink, if connected to an in-car wifi) has switched to a different provider.

 

This is no different than a usual cell<->wifi migration case from the routing perspective, and the purpose of server-generated connection ID on client-to-server packets is to facilitate routing to the correct backend.  For example, if the packet arrives at a different anycast pop, the identify of the original pop is encoded in the connection ID, and the packet can be tunneled to that pop (or directly to the correct backend within the same or a different pop).

 

  • Igor


Igor, in the scenario that you describe, a TCP connection would break -- since TCP connections are identified by the 5-tuple. So I don't think users would be surprised if a QUIC connection broke too. But at least for IPv6, there is a simple fix. The phone typically sends router advertisements for the new prefix when it gets a new IPv6 connection. The laptop will notice that and configure a new IPv6 address. If the QUIC stack subscribes to the system's "change of address" event, it can initiate a voluntary migration.

-- Christian Huitema

--------------66E778353C53EBB20A9B8809-- From nobody Tue Feb 5 14:41:32 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C254131327 for ; Tue, 5 Feb 2019 14:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yde16CMB-y9g for ; Tue, 5 Feb 2019 14:41:27 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 A71FF131326 for ; Tue, 5 Feb 2019 14:41:27 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id i145so1702951ita.4 for ; Tue, 05 Feb 2019 14:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cLY27s7WZrdxQ6RX5xWtuithQXvp6d6RtKqaSFPgsUw=; b=QdFhuQdyqjvS6qwPw0JS299R99q67voU98CU4d9Q2nyoC5V2XU8JxZdKhEEr5tx50Y 0aWzlHgGBpjEAvAYKnsLoLG//OlYxdqUjijW5GnfJPKSMuuG9siRe7DkuuumH2S7aKj0 Wwt9+df2+RjvCOOZ5o+3LgUz4U0wsVQnuI0DL5rhviLckSKYiFDr5A4OvFoxGpCFiqiM WENzx2/ZkhNjEnIpikawUB6X80lY20Kfsd7N/duEyAycTADSfU0Iwh9cI12l4ShE/6xy t3ijHmcJyVLyzpeGyAx/ZsaHzswuFkHHzRYeuHV6yZRxHK4aTFNjBThtUH7MkcD26q5h trcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cLY27s7WZrdxQ6RX5xWtuithQXvp6d6RtKqaSFPgsUw=; b=XmR+Qq7eKx8dx594r3Ep4IHEzRon/MujvHMsZRFLaFQxc4TI8ZHnJcOblrWPgRIUhI WoZYftb1+sNS23hInwSBM1gHvTOH3Mu4gdvkruQ+ZnpEZg/jFqK7+eWWnWEP5iT3cD+P FUirfiCBon3oM8xs5lFmy9SW22S/a4BFChrw5sjcMmnArivmhsNHasbY/VFvWC1xAn+L VFWZvG0sojMf50F/1VpT7lmOe5p41Yj088pohsy8l3SXq0aC7qvqaf7orEyfXDiPKMX1 zzuVONhQ5QjjXpHu4IWUPet/hbDx3goDC92zzHhby9RsSkFAi7a5Tl/lxVbNz128CDKh qThw== X-Gm-Message-State: AHQUAuY0pSSA4RenykmJC9UHjMtCsw5pOywSbbh5w/KZpKgWwrXqutYF VEMy0l8UaprWdBN8GuFqnM9RuCKKIhP6EVnAT9Q= X-Google-Smtp-Source: AHgI3IbVR3XGXq1ahUntgdCCZ7aXmYeGtXKzgA80wrqV59zXUtJryZZJQqawiVDeSkp9aUZKOVhX+9PaDUx8c9sqqT8= X-Received: by 2002:a02:9f95:: with SMTP id a21mr3700123jam.140.1549406486711; Tue, 05 Feb 2019 14:41:26 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> In-Reply-To: <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> From: Ted Hardie Date: Tue, 5 Feb 2019 14:41:00 -0800 Message-ID: Subject: Re: New path => new connection ID, right? To: "Lubashev, Igor" Cc: Jana Iyengar , David Schinazi , "quic@ietf.org" , Mike Bishop , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="00000000000040d4a105812d4fa2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 22:41:31 -0000 --00000000000040d4a105812d4fa2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 5, 2019 at 1:33 PM Lubashev, Igor wrote: > > - But if the phone/hotspot's IP address changes during this from one > provider's set of addresses to another, this is functionally re-homing= . In > that case, isn't there already a high risk that the traffic will end u= p at > a different back end because of the IP change? > > > > Yes, this is the scenario =E2=80=93 the phone (or your car=E2=80=99s upli= nk, if connected > to an in-car wifi) has switched to a different provider. > > > > This is no different than a usual cell<->wifi migration case from the > routing perspective, and the purpose of server-generated connection ID on > client-to-server packets is to facilitate routing to the correct backend. > I disagree that these are the same. In the common case for cell<-->wifi migration the connected device is aware of the interface change. Because the connected device is now serving as a forwarder for the packets of others, the tethered device cannot detect the sort of interface change. It's a path change to the tethered device, not an interface change. Christian has pointed out a way to use v6 RA to indicate that rehoming has occurred and to signal that to the tethered device. This isn't as straightforward in a v4 NAT situation, unfortunately. For example, if the packet arrives at a different anycast pop, the identify > of the original pop is encoded in the connection ID, and the packet can b= e > tunneled to that pop (or directly to the correct backend within the same = or > a different pop). > > This will still work if it uses a previous assigned but unused CID, if it has detected migration. And I think that's the key issue here; the tethered device has no way to detect migration, and so no local trigger for a CID change. That means that there is no way to truly prevent CID migration here within QUIC, only to limit the time it is in place. Having the server terminate and firing off 0-RTT is one way to limit that timing, but we have to acknowledge that it is at best a mitigation. The only other option I see offhand would be to suggest that the connected forwarder terminate the links to induce something like a DHCPRELEASE and RENEW, but this seems slow, fragile, and unlikely to deploy. Ted > > > - Igor > > > > *From:* Ted Hardie > *Sent:* Tuesday, February 05, 2019 2:28 PM > *To:* Lubashev, Igor > *Cc:* Jana Iyengar ; David Schinazi < > dschinazi.ietf@gmail.com>; quic@ietf.org; Mike Bishop < > mbishop@evequefou.be>; Martin Thomson ; Kazuho Oku < > kazuhooku@gmail.com> > *Subject:* Re: New path =3D> new connection ID, right? > > > > Hi Igor, > > > > I have a clarifying question on the scenario below. > > > > On Tue, Feb 5, 2019 at 10:28 AM Lubashev, Igor > wrote: > > > - Egregious changes in IP might be a signature for network change > (change in /16 address, for instance) and a server could terminate the > connection and respond with a stateless reset if this happens. > > > > The client could be a laptop that is tethered via a phone that is changin= g > providers. The disconnect would be completely =E2=80=9Cpunitive=E2=80=9D= (the old path=E2=80=99s > CID has already been sent over the new path) and be punishing the client > for something it had no control over whatsoever. > > > > > > In this scenario, what is your view of where the IP address changes are > taking place? > > > > I agree that the device connected to a phone (e.g. by a mobile hotspot) > will not generally have a view of the change in upstream path. If that > phone is using something like mobile IP or a VPN to have a consistent > external address, then I also don't see why this path change would trigge= r > any change in CID. But if the phone/hotspot's IP address changes during > this from one provider's set of addresses to another, this is functionall= y > re-homing. In that case, isn't there already a high risk that the traffi= c > will end up at a different back end because of the IP change? > > > > Thanks for sharing your thoughts on this, > > > > Ted > > > > > - Igor > > > > *From:* Jana Iyengar > *Sent:* Tuesday, February 05, 2019 6:42 AM > *To:* David Schinazi > *Cc:* quic@ietf.org; Mike Bishop ; Martin Thomson < > mt@lowentropy.net>; Kazuho Oku > *Subject:* Re: New path =3D> new connection ID, right? > > > > I agree that want to have MUST for changing CID and MUST NOT for sending > packets with the same CID on multiple paths. I thought we had agreed on > this in the past, but I could be misremembering. > > > > I understand that the server cannot necessarily tell this from NAT > rebinding, but it is up to the server what it does if it sees an IP/port > change with no accompanying CID change. Egregious changes in IP might be= a > signature for network change (change in /16 address, for instance) and a > server could terminate the connection and respond with a stateless reset = if > this happens. A client that ignores the MUST and uses the same CID acros= s > networks would then risk getting the connection terminated. I suggest th= at > we add some discussion about potential server responses to clients that > violate normative expectations. > > > > On Tue, Feb 5, 2019 at 8:13 AM David Schinazi > wrote: > > At the end of the day, you can make it a MUST, but clients will do what > they please because servers can't enforce it. > > But I won't die on this hill, I can live with being declared in the rough > on this one. > > > > David > > > > On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku wrote: > > 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi : > > > > If an endpoint intentionally migrates and it has unused connection IDs > to use, it makes sense to mandate it MUST switch to one of the unused > connection IDs. > > However, if it has run out of unused connection IDs then I would let th= e > endpoint decide if it wants to close the connection or migrate with a > previously used connection IDs, as there are use-cases that value > performance over non-linkability. > > I think I might prefer encouraging endpoints to gracefully close the > connection before it faces a trade-off between performance and > linkability. > > Therefore, assuming that we adopt Martin's proposal, I think it would > make sense to recommend an endpoint to send GOAWAY when if it can no > longer issue a new CID for that QUIC connection. > > > Finally, this cannot be enforced by the peer since it cannot distinguis= h > intentional migration and unintentional migration (NAT rebinding), and we > discussed in Tokyo that we wanted to avoid non-enforceable MUSTs. > > > > David > > > > On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop wrote= : > >> > >> The text is there, but it's perhaps not complete: > >> > >> As discussed in Section 9.5, each connection ID MUST be used on packet= s > sent from only one local address. An endpoint that migrates away from a > local address SHOULD retire all connection IDs used on that address once = it > no longer plans to use that address. > >> > >> > >> > >> The gap seems to be that when your peer moves to a new address, there= =E2=80=99s > no requirement that you not send the same CID to their new address that y= ou > used toward their old address. > >> > >> > >> > >> -----Original Message----- > >> From: QUIC On Behalf Of Martin Thomson > >> Sent: Monday, February 4, 2019 3:15 PM > >> To: quic@ietf.org > >> Subject: New path =3D> new connection ID, right? > >> > >> > >> > >> I thought that we had agreed that an endpoint that intentionally > migrates has to use a new connection ID on the new path. But I couldn't > find any "MUST" in the spec that said that. > >> > >> > >> > >> On the off chance that this wasn't just a mistake and there was some > good reason not to mandate this, I'm bringing the discussion here. > >> > >> > >> > >> I've opened a design issue: > >> > >> https://github.com/quicwg/base-drafts/issues/2413 > > >> > >> > >> > >> The change I'm proposing is here: > >> > >> > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a39= 95236dda960b4cdff49e36f > > >> > >> > > > > -- > Kazuho Oku > > --00000000000040d4a105812d4fa2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 5, 2019 at 1:33 PM Lubashev, = Igor <ilubashe@akamai.com>= wrote:
  • But if the phone/hotspot's IP address changes during this fro= m one provider's set of addresses to another, this is functionally re-h= oming.=C2=A0 In that case, isn't there already a high risk that the traffic will end up at a different back end because of the I= P change?

=C2=A0

Yes, this is the scenario =E2=80=93 the phone (or yo= ur car=E2=80=99s uplink, if connected to an in-car wifi) has switched to a = different provider.

=C2=A0

This is no different than a usual cell<->wifi = migration case from the routing perspective, and the purpose of server-gene= rated connection ID on client-to-server packets is to facilitate routing to= the correct backend. =C2=A0


I disagree that these are the same.=C2=A0 In the common case for cell<= -->wifi migration the connected device is aware of the interface change.= =C2=A0 Because the connected device is now serving as a forwarder for the p= ackets of others, the tethered device cannot detect the sort of interface c= hange.=C2=A0 It's a path change to the tethered device, not an interfac= e change.=C2=A0 Christian has pointed out a way to use v6 RA to indicate th= at rehoming has occurred and to signal that to the tethered device.=C2=A0 T= his isn't as straightforward in a v4 NAT situation, unfortunately.
<= /div>

For example, if the packet arrives at a different anycast pop, the identify of the original po= p is encoded in the connection ID, and the packet can be tunneled to that p= op (or directly to the correct backend within the same or a different pop).=


<= div>This will still work if it uses a previous assigned but unused CID, if = it has detected migration.=C2=A0

And I think = that's the key issue here; the tethered device has no way to detect mig= ration, and so no local trigger for a CID change.=C2=A0 That means that the= re is no way to truly prevent CID migration here within QUIC,=C2=A0 only to= limit the time it is in place.=C2=A0 Having the server terminate and firin= g off 0-RTT is one way to limit that timing, but we have to acknowledge tha= t it is at best a mitigation.=C2=A0 The only other option I see offhand wou= ld be to suggest that the connected forwarder terminate the links to induce= something like a DHCPRELEASE and RENEW, but this seems slow,=C2=A0 fragile= , and unlikely to deploy.

Ted


=C2=A0

=C2=A0

  • Igor

=C2=A0

From: Ted Hardie <ted.ietf@gmail.com>
Sent: Tuesday, February 05, 2019 2:28 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>; David Schinazi <dschinazi.ietf@gmail.com>= ; quic@ietf.org; Mik= e Bishop <mbis= hop@evequefou.be>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <kazuhooku@gmail.com&g= t;
Subject: Re: New path =3D> new connection ID, right?

=C2=A0

Hi Igor,

=C2=A0

I have a clarifying question on the scenario below.<= u>

=C2=A0

On Tue, Feb 5, 2019 at 10:28 AM Lubashev, Igor <<= a href=3D"mailto:ilubashe@akamai.com" target=3D"_blank">ilubashe@akamai.com= > wrote:

  • Egregious changes in IP might be a signature for network change (change in = /16 address, for instance) and a server could terminate the connection and = respond with a stateless reset if this happens.

=C2=A0

The client could be a laptop that is tethered via a = phone that is changing providers.=C2=A0 The disconnect would be completely = =E2=80=9Cpunitive=E2=80=9D (the old path=E2=80=99s CID has already been sen= t over the new path) and be punishing the client for something it had no control = over whatsoever.

=C2=A0

=C2=A0

In this scenario, what is your view of where the IP = address changes are taking place?

=C2=A0

I agree that the device connected to a phone (e.g. b= y a mobile hotspot) will not generally have a view of the change in upstrea= m path.=C2=A0 If that phone is using something like mobile IP or a VPN to h= ave a consistent external address, then I also don't see why this path change would trigger any change in CID.= =C2=A0 But if the phone/hotspot's IP address changes during this from o= ne provider's set of addresses to another, this is functionally re-homi= ng.=C2=A0 In that case, isn't there already a high risk that the traffic will end up at a different back end because of the IP cha= nge?

=C2=A0

Thanks for sharing your thoughts on this,<= /u>

=C2=A0

Ted

=C2=A0

  • Igor

=C2=A0

From: Jana Iyengar <jri.ietf@gmail.com>
Sent: Tuesday, February 05, 2019 6:42 AM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: quic@ietf.org= ; Mike Bishop <mbishop@evequefou.be>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <ka= zuhooku@gmail.com>
Subject: Re: New path =3D> new connection ID, right?

=C2=A0

I agree that want to have MUST for changing CID and = MUST NOT for sending packets with the same CID on multiple paths.=C2=A0 I t= hought we had agreed on this in the past, but I could be misremembering.

=C2=A0

I understand that the server cannot necessarily tell= this from NAT rebinding, but it is up to the server what it does if it see= s an IP/port change with no accompanying CID change.=C2=A0 Egregious changes in IP might be a signature for network change (change in= /16 address, for instance) and a server could terminate the connection and= respond with a stateless reset if this happens.=C2=A0 A client that ignore= s the MUST and uses the same CID across networks would then risk getting the connection terminated.=C2=A0 I sugges= t that we add some discussion about potential server responses to clients t= hat violate normative expectations.

=C2=A0

On Tue, Feb 5, 2019 at 8:13 AM David Schinazi <dschinazi.ietf@= gmail.com> wrote:

At the end of the day, you can make it a MUST, but c= lients will do what they please because servers can't enforce it.

But I won't die on this hill, I can live with be= ing declared in the rough on this one.

=C2=A0

David

=C2=A0

On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku <kazuhooku@gmail.com&= gt; wrote:

2019=E6=9C= =885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi <dschinazi.ietf@gmail.com>:
>
> If an endpoint intentionally migrates and it has unused connection IDs= to use, it makes sense to mandate it MUST switch to one of the unused conn= ection IDs.
> However, if it has run out of unused connection IDs then I would let t= he endpoint decide if it wants to close the connection or migrate with a pr= eviously used connection IDs, as there are use-cases that value performance= over non-linkability.

I think I might prefer encouraging endpoints to gracefully close the
connection before it faces a trade-off between performance and
linkability.

Therefore, assuming that we adopt Martin's proposal, I think it would make sense to recommend an endpoint to send GOAWAY when if it can no
longer issue a new CID for that QUIC connection.

> Finally, this cannot be enforced by the peer since it cannot distingui= sh intentional migration and unintentional migration (NAT rebinding), and w= e discussed in Tokyo that we wanted to avoid non-enforceable MUSTs.
>
> David
>
> On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop <mbishop@evequefou.be> wrote:
>>
>> The text is there, but it's perhaps not complete:
>>
>> As discussed in Section 9.5, each connection ID MUST be used on pa= ckets sent from only one local address. An endpoint that migrates away from= a local address SHOULD retire all connection IDs used on that address once= it no longer plans to use that address.
>>
>>
>>
>> The gap seems to be that when your peer moves to a new address, th= ere=E2=80=99s no requirement that you not send the same CID to their new ad= dress that you used toward their old address.
>>
>>
>>
>> -----Original Message-----
>> From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Thomson
>> Sent: Monday, February 4, 2019 3:15 PM
>> To: quic@ietf.o= rg
>> Subject: New path =3D> new connection ID, right?
>>
>>
>>
>> I thought that we had agreed that an endpoint that intentionally m= igrates has to use a new connection ID on the new path.=C2=A0 But I couldn&= #39;t find any "MUST" in the spec that said that.
>>
>>
>>
>> On the off chance that this wasn't just a mistake and there wa= s some good reason not to mandate this, I'm bringing the discussion her= e.
>>
>>
>>
>> I've opened a design issue:
>>
>> https://github.com/quicwg/base-drafts/issues/2413
>>
>>
>>
>> The change I'm proposing is here:
>>
>> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995= 236dda960b4cdff49e36f
>>
>>



--
Kazuho Oku

--00000000000040d4a105812d4fa2-- From nobody Tue Feb 5 14:46:04 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12BA1274D0 for ; Tue, 5 Feb 2019 14:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=ATY8QIS4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dMC2jp33 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 cTRgM9V_l6jD for ; Tue, 5 Feb 2019 14:45:59 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C10F131326 for ; Tue, 5 Feb 2019 14:45:59 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 748D022071 for ; Tue, 5 Feb 2019 17:45:58 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Tue, 05 Feb 2019 17:45:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:in-reply-to:subject:date; s=fm1; bh=HqW 9x7ljADqRaKpKyPkqoKP+4Nt25De2Eqq1lpS1ZmM=; b=ATY8QIS49ZXl6o+rJ+S 0bg6wEzCTlY8bU2cq+DvxfraKPQjTa9Kt3LuazU4h4c86bKFc9ja0w3JlBPJUa5l lOTstJRG34xp8h/VdcyflWaGDB2w3r7iWE716QESGl/khcTToiTxry0XMtNYwq6K Zqq7P3CrTxsDzhKIcYvdqXJzHhTPWOf5TUHs+Yk6h7GNkbuHv4I5lpjEHHdvc8bB zApUDanDo7IsjDdtQV473tSQmXjrWKdzakZquJlllaCOPdcmjOX1Bn6+D01B0rhI 8AmGeDrO6C2xSfurYZ14pkgYw/j8vp0ZLKEjbGsLqkBNoNCu2SfBeEAZphYvXM8g jhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=HqW9x7ljADqRaKpKyPkqoKP+4Nt25De2Eqq1lpS1Z mM=; b=dMC2jp33JXjYzWnCEdAzZxE6oUkwMgiDzpmt1rw5oN55PP5XkFSa+t9Yt JXawQqBIS5Xkh98zD7ZjORQ1LonxFzcnUAgKWemvKqg0f3b36AY7P7yViamzlcvE LIc6DK8KMpbRoPqP8xGiDvlmOZM5ZxR/hMKtI5P8vMAlHZEfeQAwK6KYlerUuVyF qSWNK4emTe+vcngBe3uH+E9ivXZxooCN+6Ydbi25OJXbx5sj3P9EeoW1fmFWfPz/ vvr8jeITIDjQcCm+5/QYPcX6Vxsf+8aTr3Zhz0lciYtaVmuMQaza12nNIy/BsIMB ajMMCcT9CKCEHrpWswf1qHI9QUISw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeejgddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfofhgjufffsehtqhertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucffohhmrghinhepthifihhtthgvrhdrtghomhenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F05A59E59A; Tue, 5 Feb 2019 17:45:57 -0500 (EST) Message-Id: <1549406757.2592380.1651659816.0410E083@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ec01da05 References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> In-Reply-To: Subject: Re: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim Date: Wed, 06 Feb 2019 09:45:57 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 22:46:03 -0000 We're talking about an endpoint that refuses to use new connection IDs for = an extended period. The solution is to occasionally (say once per day) shi= ft to a new connection ID. That gives you infinite connection lifetime, as= suming that you also keep up with key updates. But Jana's original point was a stronger one: don't stack so much state on = something as fragile and ephemeral as a network connection. That's somethi= ng I agree with, though I acknowledge that some applications don't work tha= t way (yet). On Wed, Feb 6, 2019, at 00:57, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Put in another way. >=20 > If connections starts dropping randomly just because of a perceived > linkability issue, it would take me not very long to go non-standard and > create my own QUIC version. While I could do connection failover without > loosing a session, it is a lot simpler to fix QUIC in this regard. >=20 >=20 > On 5 February 2019 at 14.51.20, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkel= fj@gmail.com) > wrote: >=20 > It=E2=80=99s not really hypothetical. For long lived peer to peer server > connections, every time a connection goes down you can have a database > query transaction rollback, which could have been running for hours on en= d, > or loose a multiple gigabytes of data transfer if you use a simpler > approach of error handling. >=20 >=20 > On 5 February 2019 at 14.42.42, Jana Iyengar (jri.ietf@gmail.com) wrote: >=20 > We're going to be well out of scope here quickly, so I'm not going to > design for a hypothetical use case that we don't yet understand well. I > definitely don't want to make a design decision now based on such a use > case. >=20 > On Tue, Feb 5, 2019 at 5:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: >=20 > > > > FWIW, I don't think that a remote shell session should need to keep the > > transport connection around for as long as the session is around, but > > that's not a discussion we need to have yet. > > > > > > Well, I do. If you tunnel data, you cannot just switch to a new connect= ion > > without a lot of disruption. Why create this problem in the first place? > > We (eventually) got varint stream ID=E2=80=99s that made it feasible to= have long > > lived connections. I=E2=80=99d be sad to see that go down on connection= ID > > rotations. Especially if these are only done for the single reason of > > avoiding linkability. My only (other) concern is loss of packet number > > space, but I hope that changes with multi-path v2, and 62 bit is still > > something. > > > > I do agree that opt-in security does not work, but for a lot of cases it > > really isn=E2=80=99t the key concern. And for other cases, linkability = is so easy > > to achieve anyway via other techniques, that I don=E2=80=99t think it = can compare > > to the problem of TLS tokens. If the concern is cracking SHA256 via mas= ter > > key, well, I think there are bigger issues to consider, including why a > > master key is not rotated. > > > > Another concern though, is the ability to track users via tokens, but t= hat > > is a cross connection concern, since clearly and endpoint can track the > > peer for as the connection is open and the longer it is open, the easie= r it > > is to track for external observers. An endpoint can and should close a > > connection if long-lived tracking is a concern. It just should be impos= ed > > on innocent shell pipes. > > > > Mikkel > > > > > > On 5 February 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) wrote: > > > > I'm in agreement. > > > > FWIW, I don't think that a remote shell session should need to keep the > > transport connection around for as long as the session is around, but > > that's not a discussion we need to have yet. > > > > On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku wrote: > > > >> Mike, Martin, > >> > >> Thank you for the responses. > >> > >> Because CID encryption key is a master key, I think it's beneficial to > >> rotate it rather frequently. The precedent that the servers have is > >> the TLS session ticket encryption key (STEK). My understanding is that > >> people generally try to generate a new STEK every day or so [1]. > >> Considering the fact that the maximum permitted lifetime of a TLS > >> session ticket is 7 days, generating a new STEK once a day is fine, > >> because by retaining 8 keys it would be possible decrypt TLS session > >> ticket that was issued 7 days earlier. > >> > >> My preference would be to reuse the synchronization mechanism of STEKs > >> for sharing the CID encryption key among the server cluster. That > >> would mean that typically you would not be able to sustain a QUIC > >> connection for mere than a week. > >> > >> That would be fine for HTTP/3, but maybe not for things like remote > >> shell over QUIC. > >> > >> Having that said, I do agree that we can introduce a QUIC extension if > >> the concern becomes real. Considering that, I think I share the view > >> that we do not need to fix the issue now. > >> > >> [1] > >> https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-t= witter.html > >> > >> 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson : > >> > > >> > On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote: > >> > > Bearing in mind that: > >> > > > >> > > * this rotation will hopefully be infrequent > >> > > * one or more CID bits can be reserved to indicate the key > >> > > generation used > >> > > * connections only need to be killed when they use something f= rom > >> > > the oldest generation which is now being replaced > >> > > > >> > > Servers can manage this by keeping two keys (one bit), or four (two > >> > > bits). That should make it relatively infrequent that a connectio= n is > >> > > still holding on to a CID from the oldest generation after they=E2= =80=99ve all > >> > > been replaced. > >> > > > >> > > Worst case, this might be a use case for the PLEASE_RETIRE_CID > >> extension > >> > > we also talked about. > >> > > >> > Mike's analysis is correct. I would prefer not to do anything about > >> this case. > >> > > >> > For now, that means that if servers rotate keys, that will set an up= per > >> bound on the lifetime of a connection. I think that's tolerable.. > >> > > >> > >> > >> -- > >> Kazuho Oku > >> > >> From nobody Tue Feb 5 15:12:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07953127133 for ; Tue, 5 Feb 2019 15:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, 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=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 sue1HRzxy_Hz for ; Tue, 5 Feb 2019 15:12:35 -0800 (PST) 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 DEDC912785F for ; Tue, 5 Feb 2019 15:12:34 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x15N6xQX012133; Tue, 5 Feb 2019 23:12:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=+KjSL3sBw22gV3dXiwRrQaV6FCIxknWvrotzkReRyRs=; b=MCEz1nJ9a0IEAIvuq+cYIsAGuDot3CZltXYm5D59ORcqTsn9IebuKymzPzeglycXNHsB hO7eD7lkqhfUwRpQdENZjC7X1JmFWzTbARuKdkgdLyNtecsjXSo5bzQG9MCTPyjw48OC DHjdnEtJ9oUz/jJV0kfeO30zZUDdAeb9HcW2hYXj0Q0Jso9u8SlxG5bqdVPIOOI137IX 9ie3Yj7Fhq79yrPbgH/UTNyi0J0wVmT5RzGCYKHLUJtfl0uc0Jbqk+7assZgosQPnCqV LhBtKsU/W0svSDFqiQw+NgiDc2zpO1s+dyIANJRmvfxlhZDznbroywa1dOSpon+1Oz+r Xw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2qfkjgg3xj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Feb 2019 23:12:31 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x15N2Go4005566; Tue, 5 Feb 2019 18:12:30 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint2.akamai.com with ESMTP id 2qd7e3pupk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Feb 2019 18:12:29 -0500 Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Feb 2019 18:12:24 -0500 Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1395.000; Tue, 5 Feb 2019 18:12:24 -0500 From: "Lubashev, Igor" To: Ted Hardie CC: Jana Iyengar , David Schinazi , "quic@ietf.org" , Mike Bishop , Martin Thomson , Kazuho Oku Subject: RE: New path => new connection ID, right? Thread-Topic: New path => new connection ID, right? Thread-Index: AQHUvN+JAcoGcAxPckuEc4gGUySdeKXQtUQAgAADUoCAAAgLAIAAEoMAgACWfwCAABtfQIAAZuqA//+0EYCAAIHRAP//r8pQ Date: Tue, 5 Feb 2019 23:12:24 +0000 Message-ID: <25ce934955dc4142b5758fc633661744@usma1ex-dag1mb6.msg.corp.akamai.com> References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> 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.33.69] Content-Type: multipart/alternative; boundary="_000_25ce934955dc4142b5758fc633661744usma1exdag1mb6msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902050168 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-05_10:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902050169 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 23:12:38 -0000 --_000_25ce934955dc4142b5758fc633661744usma1exdag1mb6msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBkaXNhZ3JlZSB0aGF0IHRoZXNlIGFyZSB0aGUgc2FtZQ0KDQpJIHVuZGVyc3Rvb2Qg dGhlIHF1ZXN0aW9uIHRvIGJlIGFib3V0IHJvdXRpbmcgcGFja2V0cyBmcm9tIGEgbmV3IElQIGFk ZHJlc3MgdG8gdGhlIG9yaWdpbmFsIGJhY2tlbmQuICBUaGUgbWlncmF0aW9uIG9mIHRoZSB0ZXRo ZXJpbmcgZGV2aWNlIGlzIHRoZSBzYW1lIGFzIHRoZSBtaWdyYXRpb24gb2YgdGhlIGNsaWVudCBm cm9tIHRoZSByb3V0aW5nIHBlcnNwZWN0aXZlIHdpdGhpbiB0aGUgZGVzdGluYXRpb24gbmV0d29y ayAod2hpY2ggbWF5IGJlIGNvbXByaXNlZCBvZiBtdWx0aXBsZSBhbnljYXN0IHBvcHMpLg0KDQoN CiAgKiAgIFRoYXQgbWVhbnMgdGhhdCB0aGVyZSBpcyBubyB3YXkgdG8gdHJ1bHkgcHJldmVudCBD SUQgbWlncmF0aW9uIGhlcmUgd2l0aGluIFFVSUMsICBvbmx5IHRvIGxpbWl0IHRoZSB0aW1lIGl0 IGlzIGluIHBsYWNlLg0KDQpUaGUgcHVycG9zZSBvZiB0aGlzIOKAnE1VU1QgdGVybWluYXRlIHRo ZSBjb25uZWN0aW9u4oCdIHByb3Bvc2FsIHdhcyB0byBpbXByb3ZlIHByaXZhY3kuIFRoZXJlIGlz IGxpdHRsZSB0byBiZSBnYWluZWQgYnkgY3V0dGluZyBvZmYgdGhlIGNvbm5lY3Rpb24sIG9uY2Ug ZXZlbiBhIHNpbmdsZSBwYWNrZXQgaGFzIGV4cG9zZWQgdGhlIG9yaWdpbmFsIENJRCB0byB0aGUg bmV3IHBhdGguICBJdOKAmXMgbm90IGxpa2UgbXVsdGlwbGUgcGFja2V0cyBwcm92aWRlIGEgc3Ry b25nZXIgbGlua2FiaWxpdHkgc2lnbmFsIHRoYW4gYSBqdXN0IG9uZSBwYWNrZXQuICBXZSBtYXkg d2lzaCB0byDigJxwdW5pc2jigJ0gYnVnZ3kgaW1wbGVtZW50YXRpb25zIHRvIGluZHVjZSB0aGVp ciB2ZW5kb3JzIHRvIGRvIGJldHRlciwgYnV0IHRoZSBjbGllbnQgaW1wbGVtZW50YXRpb24gY2Fu bm90IGRvIGFueSBiZXR0ZXIgaW4gdGhpcyBjYXNlLg0KDQoNCiAgKiAgIFRoZSBvbmx5IG90aGVy IG9wdGlvbiBJIHNlZSBvZmZoYW5kIHdvdWxkIGJlIHRvIHN1Z2dlc3QgdGhhdCB0aGUgY29ubmVj dGVkIGZvcndhcmRlciB0ZXJtaW5hdGUgdGhlIGxpbmtzIHRvIGluZHVjZSBzb21ldGhpbmcgbGlr ZSBhIERIQ1BSRUxFQVNFIGFuZCBSRU5FVywgYnV0IHRoaXMgc2VlbXMgc2xvdywgIGZyYWdpbGUs IGFuZCB1bmxpa2VseSB0byBkZXBsb3kuDQoNClJpZ2h0LiAgVGhpcyBuZXR3b3JrIGF0dGFjaG1l bnQgY2hhbmdlIG5vdGlmaWNhdGlvbiB3b3VsZCBiZSBhIHN1YmplY3QgdG8gYSBkaWZmZXJlbnQg ZHJhZnQgaW4gYSBkaWZmZXJlbnQgV0csIGFuZCBpdHMgZGVwbG95bWVudCB3b3VsZCBiZSBzbG93 Lg0KDQoNCiAgKiAgIElnb3INCg0KDQpGcm9tOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5j b20+DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNSwgMjAxOSA1OjQxIFBNDQpUbzogTHViYXNo ZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+DQpDYzogSmFuYSBJeWVuZ2FyIDxqcmkuaWV0 ZkBnbWFpbC5jb20+OyBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPjsg cXVpY0BpZXRmLm9yZzsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgTWFydGlu IFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWls LmNvbT4NClN1YmplY3Q6IFJlOiBOZXcgcGF0aCA9PiBuZXcgY29ubmVjdGlvbiBJRCwgcmlnaHQ/ DQpJbXBvcnRhbmNlOiBIaWdoDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQgMTozMyBQTSBMdWJh c2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNv bT4+IHdyb3RlOg0KDQogICogICBCdXQgaWYgdGhlIHBob25lL2hvdHNwb3QncyBJUCBhZGRyZXNz IGNoYW5nZXMgZHVyaW5nIHRoaXMgZnJvbSBvbmUgcHJvdmlkZXIncyBzZXQgb2YgYWRkcmVzc2Vz IHRvIGFub3RoZXIsIHRoaXMgaXMgZnVuY3Rpb25hbGx5IHJlLWhvbWluZy4gIEluIHRoYXQgY2Fz ZSwgaXNuJ3QgdGhlcmUgYWxyZWFkeSBhIGhpZ2ggcmlzayB0aGF0IHRoZSB0cmFmZmljIHdpbGwg ZW5kIHVwIGF0IGEgZGlmZmVyZW50IGJhY2sgZW5kIGJlY2F1c2Ugb2YgdGhlIElQIGNoYW5nZT8N Cg0KWWVzLCB0aGlzIGlzIHRoZSBzY2VuYXJpbyDigJMgdGhlIHBob25lIChvciB5b3VyIGNhcuKA mXMgdXBsaW5rLCBpZiBjb25uZWN0ZWQgdG8gYW4gaW4tY2FyIHdpZmkpIGhhcyBzd2l0Y2hlZCB0 byBhIGRpZmZlcmVudCBwcm92aWRlci4NCg0KVGhpcyBpcyBubyBkaWZmZXJlbnQgdGhhbiBhIHVz dWFsIGNlbGw8LT53aWZpIG1pZ3JhdGlvbiBjYXNlIGZyb20gdGhlIHJvdXRpbmcgcGVyc3BlY3Rp dmUsIGFuZCB0aGUgcHVycG9zZSBvZiBzZXJ2ZXItZ2VuZXJhdGVkIGNvbm5lY3Rpb24gSUQgb24g Y2xpZW50LXRvLXNlcnZlciBwYWNrZXRzIGlzIHRvIGZhY2lsaXRhdGUgcm91dGluZyB0byB0aGUg Y29ycmVjdCBiYWNrZW5kLg0KDQpJIGRpc2FncmVlIHRoYXQgdGhlc2UgYXJlIHRoZSBzYW1lLiAg SW4gdGhlIGNvbW1vbiBjYXNlIGZvciBjZWxsPC0tPndpZmkgbWlncmF0aW9uIHRoZSBjb25uZWN0 ZWQgZGV2aWNlIGlzIGF3YXJlIG9mIHRoZSBpbnRlcmZhY2UgY2hhbmdlLiAgQmVjYXVzZSB0aGUg Y29ubmVjdGVkIGRldmljZSBpcyBub3cgc2VydmluZyBhcyBhIGZvcndhcmRlciBmb3IgdGhlIHBh Y2tldHMgb2Ygb3RoZXJzLCB0aGUgdGV0aGVyZWQgZGV2aWNlIGNhbm5vdCBkZXRlY3QgdGhlIHNv cnQgb2YgaW50ZXJmYWNlIGNoYW5nZS4gIEl0J3MgYSBwYXRoIGNoYW5nZSB0byB0aGUgdGV0aGVy ZWQgZGV2aWNlLCBub3QgYW4gaW50ZXJmYWNlIGNoYW5nZS4gIENocmlzdGlhbiBoYXMgcG9pbnRl ZCBvdXQgYSB3YXkgdG8gdXNlIHY2IFJBIHRvIGluZGljYXRlIHRoYXQgcmVob21pbmcgaGFzIG9j Y3VycmVkIGFuZCB0byBzaWduYWwgdGhhdCB0byB0aGUgdGV0aGVyZWQgZGV2aWNlLiAgVGhpcyBp c24ndCBhcyBzdHJhaWdodGZvcndhcmQgaW4gYSB2NCBOQVQgc2l0dWF0aW9uLCB1bmZvcnR1bmF0 ZWx5Lg0KDQpGb3IgZXhhbXBsZSwgaWYgdGhlIHBhY2tldCBhcnJpdmVzIGF0IGEgZGlmZmVyZW50 IGFueWNhc3QgcG9wLCB0aGUgaWRlbnRpZnkgb2YgdGhlIG9yaWdpbmFsIHBvcCBpcyBlbmNvZGVk IGluIHRoZSBjb25uZWN0aW9uIElELCBhbmQgdGhlIHBhY2tldCBjYW4gYmUgdHVubmVsZWQgdG8g dGhhdCBwb3AgKG9yIGRpcmVjdGx5IHRvIHRoZSBjb3JyZWN0IGJhY2tlbmQgd2l0aGluIHRoZSBz YW1lIG9yIGEgZGlmZmVyZW50IHBvcCkuDQoNClRoaXMgd2lsbCBzdGlsbCB3b3JrIGlmIGl0IHVz ZXMgYSBwcmV2aW91cyBhc3NpZ25lZCBidXQgdW51c2VkIENJRCwgaWYgaXQgaGFzIGRldGVjdGVk IG1pZ3JhdGlvbi4NCg0KQW5kIEkgdGhpbmsgdGhhdCdzIHRoZSBrZXkgaXNzdWUgaGVyZTsgdGhl IHRldGhlcmVkIGRldmljZSBoYXMgbm8gd2F5IHRvIGRldGVjdCBtaWdyYXRpb24sIGFuZCBzbyBu byBsb2NhbCB0cmlnZ2VyIGZvciBhIENJRCBjaGFuZ2UuICBUaGF0IG1lYW5zIHRoYXQgdGhlcmUg aXMgbm8gd2F5IHRvIHRydWx5IHByZXZlbnQgQ0lEIG1pZ3JhdGlvbiBoZXJlIHdpdGhpbiBRVUlD LCAgb25seSB0byBsaW1pdCB0aGUgdGltZSBpdCBpcyBpbiBwbGFjZS4gIEhhdmluZyB0aGUgc2Vy dmVyIHRlcm1pbmF0ZSBhbmQgZmlyaW5nIG9mZiAwLVJUVCBpcyBvbmUgd2F5IHRvIGxpbWl0IHRo YXQgdGltaW5nLCBidXQgd2UgaGF2ZSB0byBhY2tub3dsZWRnZSB0aGF0IGl0IGlzIGF0IGJlc3Qg YSBtaXRpZ2F0aW9uLiAgVGhlIG9ubHkgb3RoZXIgb3B0aW9uIEkgc2VlIG9mZmhhbmQgd291bGQg YmUgdG8gc3VnZ2VzdCB0aGF0IHRoZSBjb25uZWN0ZWQgZm9yd2FyZGVyIHRlcm1pbmF0ZSB0aGUg bGlua3MgdG8gaW5kdWNlIHNvbWV0aGluZyBsaWtlIGEgREhDUFJFTEVBU0UgYW5kIFJFTkVXLCBi dXQgdGhpcyBzZWVtcyBzbG93LCAgZnJhZ2lsZSwgYW5kIHVubGlrZWx5IHRvIGRlcGxveS4NCg0K VGVkDQoNCg0KDQoNCg0KICAqICAgSWdvcg0KDQpGcm9tOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBn bWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4+DQpTZW50OiBUdWVzZGF5LCBGZWJy dWFyeSAwNSwgMjAxOSAyOjI4IFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1h aS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+Pg0KQ2M6IEphbmEgSXllbmdhciA8anJp LmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+PjsgRGF2aWQgU2NoaW5h emkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwu Y29tPj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+OyBNaWtlIEJpc2hvcCA8 bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj47IE1hcnRp biBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldDxtYWlsdG86bXRAbG93ZW50cm9weS5uZXQ+Pjsg S2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNv bT4+DQpTdWJqZWN0OiBSZTogTmV3IHBhdGggPT4gbmV3IGNvbm5lY3Rpb24gSUQsIHJpZ2h0Pw0K DQpIaSBJZ29yLA0KDQpJIGhhdmUgYSBjbGFyaWZ5aW5nIHF1ZXN0aW9uIG9uIHRoZSBzY2VuYXJp byBiZWxvdy4NCg0KT24gVHVlLCBGZWIgNSwgMjAxOSBhdCAxMDoyOCBBTSBMdWJhc2hldiwgSWdv ciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+IHdyb3Rl Og0KDQogICogICBFZ3JlZ2lvdXMgY2hhbmdlcyBpbiBJUCBtaWdodCBiZSBhIHNpZ25hdHVyZSBm b3IgbmV0d29yayBjaGFuZ2UgKGNoYW5nZSBpbiAvMTYgYWRkcmVzcywgZm9yIGluc3RhbmNlKSBh bmQgYSBzZXJ2ZXIgY291bGQgdGVybWluYXRlIHRoZSBjb25uZWN0aW9uIGFuZCByZXNwb25kIHdp dGggYSBzdGF0ZWxlc3MgcmVzZXQgaWYgdGhpcyBoYXBwZW5zLg0KDQpUaGUgY2xpZW50IGNvdWxk IGJlIGEgbGFwdG9wIHRoYXQgaXMgdGV0aGVyZWQgdmlhIGEgcGhvbmUgdGhhdCBpcyBjaGFuZ2lu ZyBwcm92aWRlcnMuICBUaGUgZGlzY29ubmVjdCB3b3VsZCBiZSBjb21wbGV0ZWx5IOKAnHB1bml0 aXZl4oCdICh0aGUgb2xkIHBhdGjigJlzIENJRCBoYXMgYWxyZWFkeSBiZWVuIHNlbnQgb3ZlciB0 aGUgbmV3IHBhdGgpIGFuZCBiZSBwdW5pc2hpbmcgdGhlIGNsaWVudCBmb3Igc29tZXRoaW5nIGl0 IGhhZCBubyBjb250cm9sIG92ZXIgd2hhdHNvZXZlci4NCg0KDQpJbiB0aGlzIHNjZW5hcmlvLCB3 aGF0IGlzIHlvdXIgdmlldyBvZiB3aGVyZSB0aGUgSVAgYWRkcmVzcyBjaGFuZ2VzIGFyZSB0YWtp bmcgcGxhY2U/DQoNCkkgYWdyZWUgdGhhdCB0aGUgZGV2aWNlIGNvbm5lY3RlZCB0byBhIHBob25l IChlLmcuIGJ5IGEgbW9iaWxlIGhvdHNwb3QpIHdpbGwgbm90IGdlbmVyYWxseSBoYXZlIGEgdmll dyBvZiB0aGUgY2hhbmdlIGluIHVwc3RyZWFtIHBhdGguICBJZiB0aGF0IHBob25lIGlzIHVzaW5n IHNvbWV0aGluZyBsaWtlIG1vYmlsZSBJUCBvciBhIFZQTiB0byBoYXZlIGEgY29uc2lzdGVudCBl eHRlcm5hbCBhZGRyZXNzLCB0aGVuIEkgYWxzbyBkb24ndCBzZWUgd2h5IHRoaXMgcGF0aCBjaGFu Z2Ugd291bGQgdHJpZ2dlciBhbnkgY2hhbmdlIGluIENJRC4gIEJ1dCBpZiB0aGUgcGhvbmUvaG90 c3BvdCdzIElQIGFkZHJlc3MgY2hhbmdlcyBkdXJpbmcgdGhpcyBmcm9tIG9uZSBwcm92aWRlcidz IHNldCBvZiBhZGRyZXNzZXMgdG8gYW5vdGhlciwgdGhpcyBpcyBmdW5jdGlvbmFsbHkgcmUtaG9t aW5nLiAgSW4gdGhhdCBjYXNlLCBpc24ndCB0aGVyZSBhbHJlYWR5IGEgaGlnaCByaXNrIHRoYXQg dGhlIHRyYWZmaWMgd2lsbCBlbmQgdXAgYXQgYSBkaWZmZXJlbnQgYmFjayBlbmQgYmVjYXVzZSBv ZiB0aGUgSVAgY2hhbmdlPw0KDQpUaGFua3MgZm9yIHNoYXJpbmcgeW91ciB0aG91Z2h0cyBvbiB0 aGlzLA0KDQpUZWQNCg0KDQogICogICBJZ29yDQoNCkZyb206IEphbmEgSXllbmdhciA8anJpLmll dGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+Pg0KU2VudDogVHVlc2RheSwg RmVicnVhcnkgMDUsIDIwMTkgNjo0MiBBTQ0KVG86IERhdmlkIFNjaGluYXppIDxkc2NoaW5hemku aWV0ZkBnbWFpbC5jb208bWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4+DQpDYzogcXVp Y0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2 ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PjsgTWFydGluIFRob21zb24g PG10QGxvd2VudHJvcHkubmV0PG1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldD4+OyBLYXp1aG8gT2t1 IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4NClN1Ympl Y3Q6IFJlOiBOZXcgcGF0aCA9PiBuZXcgY29ubmVjdGlvbiBJRCwgcmlnaHQ/DQoNCkkgYWdyZWUg dGhhdCB3YW50IHRvIGhhdmUgTVVTVCBmb3IgY2hhbmdpbmcgQ0lEIGFuZCBNVVNUIE5PVCBmb3Ig c2VuZGluZyBwYWNrZXRzIHdpdGggdGhlIHNhbWUgQ0lEIG9uIG11bHRpcGxlIHBhdGhzLiAgSSB0 aG91Z2h0IHdlIGhhZCBhZ3JlZWQgb24gdGhpcyBpbiB0aGUgcGFzdCwgYnV0IEkgY291bGQgYmUg bWlzcmVtZW1iZXJpbmcuDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSBzZXJ2ZXIgY2Fubm90IG5l Y2Vzc2FyaWx5IHRlbGwgdGhpcyBmcm9tIE5BVCByZWJpbmRpbmcsIGJ1dCBpdCBpcyB1cCB0byB0 aGUgc2VydmVyIHdoYXQgaXQgZG9lcyBpZiBpdCBzZWVzIGFuIElQL3BvcnQgY2hhbmdlIHdpdGgg bm8gYWNjb21wYW55aW5nIENJRCBjaGFuZ2UuICBFZ3JlZ2lvdXMgY2hhbmdlcyBpbiBJUCBtaWdo dCBiZSBhIHNpZ25hdHVyZSBmb3IgbmV0d29yayBjaGFuZ2UgKGNoYW5nZSBpbiAvMTYgYWRkcmVz cywgZm9yIGluc3RhbmNlKSBhbmQgYSBzZXJ2ZXIgY291bGQgdGVybWluYXRlIHRoZSBjb25uZWN0 aW9uIGFuZCByZXNwb25kIHdpdGggYSBzdGF0ZWxlc3MgcmVzZXQgaWYgdGhpcyBoYXBwZW5zLiAg QSBjbGllbnQgdGhhdCBpZ25vcmVzIHRoZSBNVVNUIGFuZCB1c2VzIHRoZSBzYW1lIENJRCBhY3Jv c3MgbmV0d29ya3Mgd291bGQgdGhlbiByaXNrIGdldHRpbmcgdGhlIGNvbm5lY3Rpb24gdGVybWlu YXRlZC4gIEkgc3VnZ2VzdCB0aGF0IHdlIGFkZCBzb21lIGRpc2N1c3Npb24gYWJvdXQgcG90ZW50 aWFsIHNlcnZlciByZXNwb25zZXMgdG8gY2xpZW50cyB0aGF0IHZpb2xhdGUgbm9ybWF0aXZlIGV4 cGVjdGF0aW9ucy4NCg0KT24gVHVlLCBGZWIgNSwgMjAxOSBhdCA4OjEzIEFNIERhdmlkIFNjaGlu YXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWls LmNvbT4+IHdyb3RlOg0KQXQgdGhlIGVuZCBvZiB0aGUgZGF5LCB5b3UgY2FuIG1ha2UgaXQgYSBN VVNULCBidXQgY2xpZW50cyB3aWxsIGRvIHdoYXQgdGhleSBwbGVhc2UgYmVjYXVzZSBzZXJ2ZXJz IGNhbid0IGVuZm9yY2UgaXQuDQpCdXQgSSB3b24ndCBkaWUgb24gdGhpcyBoaWxsLCBJIGNhbiBs aXZlIHdpdGggYmVpbmcgZGVjbGFyZWQgaW4gdGhlIHJvdWdoIG9uIHRoaXMgb25lLg0KDQpEYXZp ZA0KDQpPbiBNb24sIEZlYiA0LCAyMDE5IGF0IDU6MzcgUE0gS2F6dWhvIE9rdSA8a2F6dWhvb2t1 QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+IHdyb3RlOg0KMjAxOeW5tDLm nIg15pelKOeBqykgMTA6MDggRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNv bTxtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tPj46DQo+DQo+IElmIGFuIGVuZHBvaW50 IGludGVudGlvbmFsbHkgbWlncmF0ZXMgYW5kIGl0IGhhcyB1bnVzZWQgY29ubmVjdGlvbiBJRHMg dG8gdXNlLCBpdCBtYWtlcyBzZW5zZSB0byBtYW5kYXRlIGl0IE1VU1Qgc3dpdGNoIHRvIG9uZSBv ZiB0aGUgdW51c2VkIGNvbm5lY3Rpb24gSURzLg0KPiBIb3dldmVyLCBpZiBpdCBoYXMgcnVuIG91 dCBvZiB1bnVzZWQgY29ubmVjdGlvbiBJRHMgdGhlbiBJIHdvdWxkIGxldCB0aGUgZW5kcG9pbnQg ZGVjaWRlIGlmIGl0IHdhbnRzIHRvIGNsb3NlIHRoZSBjb25uZWN0aW9uIG9yIG1pZ3JhdGUgd2l0 aCBhIHByZXZpb3VzbHkgdXNlZCBjb25uZWN0aW9uIElEcywgYXMgdGhlcmUgYXJlIHVzZS1jYXNl cyB0aGF0IHZhbHVlIHBlcmZvcm1hbmNlIG92ZXIgbm9uLWxpbmthYmlsaXR5Lg0KDQpJIHRoaW5r IEkgbWlnaHQgcHJlZmVyIGVuY291cmFnaW5nIGVuZHBvaW50cyB0byBncmFjZWZ1bGx5IGNsb3Nl IHRoZQ0KY29ubmVjdGlvbiBiZWZvcmUgaXQgZmFjZXMgYSB0cmFkZS1vZmYgYmV0d2VlbiBwZXJm b3JtYW5jZSBhbmQNCmxpbmthYmlsaXR5Lg0KDQpUaGVyZWZvcmUsIGFzc3VtaW5nIHRoYXQgd2Ug YWRvcHQgTWFydGluJ3MgcHJvcG9zYWwsIEkgdGhpbmsgaXQgd291bGQNCm1ha2Ugc2Vuc2UgdG8g cmVjb21tZW5kIGFuIGVuZHBvaW50IHRvIHNlbmQgR09BV0FZIHdoZW4gaWYgaXQgY2FuIG5vDQps b25nZXIgaXNzdWUgYSBuZXcgQ0lEIGZvciB0aGF0IFFVSUMgY29ubmVjdGlvbi4NCg0KPiBGaW5h bGx5LCB0aGlzIGNhbm5vdCBiZSBlbmZvcmNlZCBieSB0aGUgcGVlciBzaW5jZSBpdCBjYW5ub3Qg ZGlzdGluZ3Vpc2ggaW50ZW50aW9uYWwgbWlncmF0aW9uIGFuZCB1bmludGVudGlvbmFsIG1pZ3Jh dGlvbiAoTkFUIHJlYmluZGluZyksIGFuZCB3ZSBkaXNjdXNzZWQgaW4gVG9reW8gdGhhdCB3ZSB3 YW50ZWQgdG8gYXZvaWQgbm9uLWVuZm9yY2VhYmxlIE1VU1RzLg0KPg0KPiBEYXZpZA0KPg0KPiBP biBNb24sIEZlYiA0LCAyMDE5IGF0IDQ6NTYgUE0gTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVl Zm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+IHdyb3RlOg0KPj4NCj4+IFRoZSB0 ZXh0IGlzIHRoZXJlLCBidXQgaXQncyBwZXJoYXBzIG5vdCBjb21wbGV0ZToNCj4+DQo+PiBBcyBk aXNjdXNzZWQgaW4gU2VjdGlvbiA5LjUsIGVhY2ggY29ubmVjdGlvbiBJRCBNVVNUIGJlIHVzZWQg b24gcGFja2V0cyBzZW50IGZyb20gb25seSBvbmUgbG9jYWwgYWRkcmVzcy4gQW4gZW5kcG9pbnQg dGhhdCBtaWdyYXRlcyBhd2F5IGZyb20gYSBsb2NhbCBhZGRyZXNzIFNIT1VMRCByZXRpcmUgYWxs IGNvbm5lY3Rpb24gSURzIHVzZWQgb24gdGhhdCBhZGRyZXNzIG9uY2UgaXQgbm8gbG9uZ2VyIHBs YW5zIHRvIHVzZSB0aGF0IGFkZHJlc3MuDQo+Pg0KPj4NCj4+DQo+PiBUaGUgZ2FwIHNlZW1zIHRv IGJlIHRoYXQgd2hlbiB5b3VyIHBlZXIgbW92ZXMgdG8gYSBuZXcgYWRkcmVzcywgdGhlcmXigJlz IG5vIHJlcXVpcmVtZW50IHRoYXQgeW91IG5vdCBzZW5kIHRoZSBzYW1lIENJRCB0byB0aGVpciBu ZXcgYWRkcmVzcyB0aGF0IHlvdSB1c2VkIHRvd2FyZCB0aGVpciBvbGQgYWRkcmVzcy4NCj4+DQo+ Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBRVUlDIDxxdWlj LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFs ZiBPZiBNYXJ0aW4gVGhvbXNvbg0KPj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSA0LCAyMDE5IDM6 MTUgUE0NCj4+IFRvOiBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KPj4gU3Vi amVjdDogTmV3IHBhdGggPT4gbmV3IGNvbm5lY3Rpb24gSUQsIHJpZ2h0Pw0KPj4NCj4+DQo+Pg0K Pj4gSSB0aG91Z2h0IHRoYXQgd2UgaGFkIGFncmVlZCB0aGF0IGFuIGVuZHBvaW50IHRoYXQgaW50 ZW50aW9uYWxseSBtaWdyYXRlcyBoYXMgdG8gdXNlIGEgbmV3IGNvbm5lY3Rpb24gSUQgb24gdGhl IG5ldyBwYXRoLiAgQnV0IEkgY291bGRuJ3QgZmluZCBhbnkgIk1VU1QiIGluIHRoZSBzcGVjIHRo YXQgc2FpZCB0aGF0Lg0KPj4NCj4+DQo+Pg0KPj4gT24gdGhlIG9mZiBjaGFuY2UgdGhhdCB0aGlz IHdhc24ndCBqdXN0IGEgbWlzdGFrZSBhbmQgdGhlcmUgd2FzIHNvbWUgZ29vZCByZWFzb24gbm90 IHRvIG1hbmRhdGUgdGhpcywgSSdtIGJyaW5naW5nIHRoZSBkaXNjdXNzaW9uIGhlcmUuDQo+Pg0K Pj4NCj4+DQo+PiBJJ3ZlIG9wZW5lZCBhIGRlc2lnbiBpc3N1ZToNCj4+DQo+PiBodHRwczovL2dp dGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8yNDEzPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9xdWljd2dfYmFz ZS0yRGRyYWZ0c19pc3N1ZXNfMjQxMyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcm cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJm09NEI4aTNPMlE2 YjZOZlpkTUlGZHNCMFNscmNtRDUwVGMyNFVGbzR4Q0dpWSZzPTVscjhjemlaZlgyQTlCV0QzTDha djhpMVIzenlKWUNpenF2QmpjT211eXMmZT0+DQo+Pg0KPj4NCj4+DQo+PiBUaGUgY2hhbmdlIEkn bSBwcm9wb3NpbmcgaXMgaGVyZToNCj4+DQo+PiBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jh c2UtZHJhZnRzL3B1bGwvMjQxNC9jb21taXRzLzEzNjk4Y2JlMzExOTIyYTM5OTUyMzZkZGE5NjBi NGNkZmY0OWUzNmY8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX3B1bGxfMjQxNF9jb21taXRz XzEzNjk4Y2JlMzExOTIyYTM5OTUyMzZkZGE5NjBiNGNkZmY0OWUzNmYmZD1Ed01GYVEmYz05Nlpi WlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9t NTVLUG1sbyZtPTRCOGkzTzJRNmI2TmZaZE1JRmRzQjBTbHJjbUQ1MFRjMjRVRm80eENHaVkmcz1S MC1qdWVXZ2F0VDVXRGtkWVFpX0pWWkZhY2d5LWNBQUE0UDJ1b3N0M2p3JmU9Pg0KPj4NCj4+DQoN Cg0KDQotLQ0KS2F6dWhvIE9rdQ0K --_000_25ce934955dc4142b5758fc633661744usma1exdag1mb6msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwt bS0zMzg5MDcyMTI3NDMzNzQ5NDIzbXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbS0zMzg5MDcy MTI3NDMzNzQ5NDIzbXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0tMzM4OTA3MjEyNzQzMzc0 OTQyM21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tMzM4OTA3MjEy NzQzMzc0OTQyM21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpwLmdtYWlsLW0tMzM4OTA3MjEyNzQzMzc0OTQyM2dtYWlsLW05MTc1MzI1NzMw NTU2NTY4NDQwbXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbS0zMzg5MDcyMTI3NDMzNzQ5NDIz Z21haWwtbTkxNzUzMjU3MzA1NTY1Njg0NDBtc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbS0z Mzg5MDcyMTI3NDMzNzQ5NDIzZ21haWwtbTkxNzUzMjU3MzA1NTY1Njg0NDBtc29saXN0cGFyYWdy YXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTMzODkwNzIxMjc0MzM3NDk0MjNnbWFpbC1t OTE3NTMyNTczMDU1NjU2ODQ0MG1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MzY1NDU2MjY7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi04NzMzMDE5MjY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlz dC1pZDo3ODA5NTI0MTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI3OTIyODgxNjt9DQpAbGlz dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjgxMDM3MDg2MjsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTc2MTc4NjkwO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTkzNjQw NDI0MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI5 MzU3NDMxNiAyOTU5NzU5ODAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDo0Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwz OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoxOTY2NDIyNDQ1Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotNTgzMjE1NDQ4O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7bXNv LWxpc3QtaWQ6MjAyODAyMDE4MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6NjYzMTQ1Mjg2IDUzNzU1MTA1NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs NTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDU6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDU6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs NTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MyBsZXZlbDEgbGZvNSI+SSBkaXNhZ3JlZSB0aGF0IHRoZXNlIGFyZSB0aGUgc2FtZTxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVyc3Rvb2QgdGhlIHF1ZXN0aW9uIHRvIGJlIGFi b3V0IHJvdXRpbmcgcGFja2V0cyBmcm9tIGEgbmV3IElQIGFkZHJlc3MgdG8gdGhlIG9yaWdpbmFs IGJhY2tlbmQuJm5ic3A7IFRoZSBtaWdyYXRpb24gb2YgdGhlIHRldGhlcmluZyBkZXZpY2UgaXMg dGhlIHNhbWUgYXMgdGhlIG1pZ3JhdGlvbiBvZiB0aGUgY2xpZW50DQo8aT5mcm9tIHRoZSByb3V0 aW5nIHBlcnNwZWN0aXZlPC9pPiB3aXRoaW4gdGhlIGRlc3RpbmF0aW9uIG5ldHdvcmsgKHdoaWNo IG1heSBiZSBjb21wcmlzZWQgb2YgbXVsdGlwbGUgYW55Y2FzdCBwb3BzKS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxl PSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzUiPlRoYXQg bWVhbnMgdGhhdCB0aGVyZSBpcyBubyB3YXkgdG8gdHJ1bHkgcHJldmVudCBDSUQgbWlncmF0aW9u IGhlcmUgd2l0aGluIFFVSUMsJm5ic3A7IG9ubHkgdG8gbGltaXQgdGhlIHRpbWUgaXQgaXMgaW4g cGxhY2UuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwdXJwb3NlIG9mIHRoaXMg 4oCcTVVTVCB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb27igJ0gcHJvcG9zYWwgd2FzIHRvIGltcHJv dmUgcHJpdmFjeS4gVGhlcmUgaXMgbGl0dGxlIHRvIGJlIGdhaW5lZCBieSBjdXR0aW5nIG9mZiB0 aGUgY29ubmVjdGlvbiwgb25jZSBldmVuIGEgc2luZ2xlIHBhY2tldCBoYXMgZXhwb3NlZCB0aGUg b3JpZ2luYWwgQ0lEIHRvIHRoZSBuZXcgcGF0aC4mbmJzcDsgSXTigJlzIG5vdCBsaWtlIG11bHRp cGxlDQogcGFja2V0cyBwcm92aWRlIGEgc3Ryb25nZXIgbGlua2FiaWxpdHkgc2lnbmFsIHRoYW4g YSBqdXN0IG9uZSBwYWNrZXQuJm5ic3A7IFdlIG1heSB3aXNoIHRvIOKAnHB1bmlzaOKAnSBidWdn eSBpbXBsZW1lbnRhdGlvbnMgdG8gaW5kdWNlIHRoZWlyIHZlbmRvcnMgdG8gZG8gYmV0dGVyLCBi dXQgdGhlIGNsaWVudCBpbXBsZW1lbnRhdGlvbiBjYW5ub3QgZG8gYW55IGJldHRlciBpbiB0aGlz IGNhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omwz IGxldmVsMSBsZm81Ij5UaGUgb25seSBvdGhlciBvcHRpb24gSSBzZWUgb2ZmaGFuZCB3b3VsZCBi ZSB0byBzdWdnZXN0IHRoYXQgdGhlIGNvbm5lY3RlZCBmb3J3YXJkZXIgdGVybWluYXRlIHRoZSBs aW5rcyB0byBpbmR1Y2Ugc29tZXRoaW5nIGxpa2UgYSBESENQUkVMRUFTRSBhbmQgUkVORVcsIGJ1 dCB0aGlzIHNlZW1zIHNsb3csJm5ic3A7IGZyYWdpbGUsDQogYW5kIHVubGlrZWx5IHRvIGRlcGxv eS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQuJm5ic3A7IFRoaXMgbmV0d29y ayBhdHRhY2htZW50IGNoYW5nZSBub3RpZmljYXRpb24gd291bGQgYmUgYSBzdWJqZWN0IHRvIGEg ZGlmZmVyZW50IGRyYWZ0IGluIGEgZGlmZmVyZW50IFdHLCBhbmQgaXRzIGRlcGxveW1lbnQgd291 bGQgYmUgc2xvdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDUgbGV2ZWwxIGxmbzYiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBU ZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBGZWJydWFyeSAwNSwgMjAxOSA1OjQxIFBNPGJyPg0KPGI+VG86PC9iPiBMdWJhc2hl diwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEphbmEg SXllbmdhciAmbHQ7anJpLmlldGZAZ21haWwuY29tJmd0OzsgRGF2aWQgU2NoaW5hemkgJmx0O2Rz Y2hpbmF6aS5pZXRmQGdtYWlsLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc7IE1pa2UgQmlzaG9wICZs dDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttdEBsb3dlbnRy b3B5Lm5ldCZndDs7IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBOZXcgcGF0aCA9Jmd0OyBuZXcgY29ubmVjdGlvbiBJRCwgcmln aHQ/PGJyPg0KPGI+SW1wb3J0YW5jZTo8L2I+IEhpZ2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgNSwgMjAxOSBhdCAxOjMz IFBNIEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNv bSI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0K PGxpIGNsYXNzPSJnbWFpbC1tLTMzODkwNzIxMjc0MzM3NDk0MjNtc29saXN0cGFyYWdyYXBoIiBz dHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQnV0IGlmIHRoZSBwaG9uZS9ob3RzcG90 J3MgSVAgYWRkcmVzcyBjaGFuZ2VzIGR1cmluZyB0aGlzIGZyb20gb25lIHByb3ZpZGVyJ3Mgc2V0 IG9mIGFkZHJlc3NlcyB0byBhbm90aGVyLCB0aGlzIGlzIGZ1bmN0aW9uYWxseSByZS1ob21pbmcu Jm5ic3A7IEluIHRoYXQgY2FzZSwgaXNuJ3QgdGhlcmUgYWxyZWFkeSBhIGhpZ2ggcmlzayB0aGF0 IHRoZSB0cmFmZmljIHdpbGwgZW5kIHVwIGF0IGEgZGlmZmVyZW50IGJhY2sgZW5kIGJlY2F1c2Ug b2YgdGhlIElQDQogY2hhbmdlPzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVz LCB0aGlzIGlzIHRoZSBzY2VuYXJpbyDigJMgdGhlIHBob25lIChvciB5b3VyIGNhcuKAmXMgdXBs aW5rLCBpZiBjb25uZWN0ZWQgdG8gYW4gaW4tY2FyIHdpZmkpIGhhcyBzd2l0Y2hlZCB0byBhIGRp ZmZlcmVudCBwcm92aWRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgaXMgbm8g ZGlmZmVyZW50IHRoYW4gYSB1c3VhbCBjZWxsJmx0Oy0mZ3Q7d2lmaSBtaWdyYXRpb24gY2FzZSBm cm9tIHRoZSByb3V0aW5nIHBlcnNwZWN0aXZlLCBhbmQgdGhlIHB1cnBvc2Ugb2Ygc2VydmVyLWdl bmVyYXRlZCBjb25uZWN0aW9uIElEIG9uIGNsaWVudC10by1zZXJ2ZXIgcGFja2V0cyBpcyB0byBm YWNpbGl0YXRlDQogcm91dGluZyB0byB0aGUgY29ycmVjdCBiYWNrZW5kLiAmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGRpc2FncmVlIHRoYXQgdGhlc2UgYXJlIHRoZSBzYW1lLiZuYnNwOyBJ biB0aGUgY29tbW9uIGNhc2UgZm9yIGNlbGwmbHQ7LS0mZ3Q7d2lmaSBtaWdyYXRpb24gdGhlIGNv bm5lY3RlZCBkZXZpY2UgaXMgYXdhcmUgb2YgdGhlIGludGVyZmFjZSBjaGFuZ2UuJm5ic3A7IEJl Y2F1c2UgdGhlIGNvbm5lY3RlZCBkZXZpY2UgaXMgbm93IHNlcnZpbmcgYXMgYSBmb3J3YXJkZXIg Zm9yIHRoZSBwYWNrZXRzIG9mIG90aGVycywgdGhlIHRldGhlcmVkDQogZGV2aWNlIGNhbm5vdCBk ZXRlY3QgdGhlIHNvcnQgb2YgaW50ZXJmYWNlIGNoYW5nZS4mbmJzcDsgSXQncyBhIHBhdGggY2hh bmdlIHRvIHRoZSB0ZXRoZXJlZCBkZXZpY2UsIG5vdCBhbiBpbnRlcmZhY2UgY2hhbmdlLiZuYnNw OyBDaHJpc3RpYW4gaGFzIHBvaW50ZWQgb3V0IGEgd2F5IHRvIHVzZSB2NiBSQSB0byBpbmRpY2F0 ZSB0aGF0IHJlaG9taW5nIGhhcyBvY2N1cnJlZCBhbmQgdG8gc2lnbmFsIHRoYXQgdG8gdGhlIHRl dGhlcmVkIGRldmljZS4mbmJzcDsgVGhpcyBpc24ndA0KIGFzIHN0cmFpZ2h0Zm9yd2FyZCBpbiBh IHY0IE5BVCBzaXR1YXRpb24sIHVuZm9ydHVuYXRlbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3Ig ZXhhbXBsZSwgaWYgdGhlIHBhY2tldCBhcnJpdmVzIGF0IGEgZGlmZmVyZW50IGFueWNhc3QgcG9w LCB0aGUgaWRlbnRpZnkgb2YgdGhlIG9yaWdpbmFsIHBvcCBpcyBlbmNvZGVkIGluIHRoZSBjb25u ZWN0aW9uIElELCBhbmQgdGhlIHBhY2tldCBjYW4gYmUgdHVubmVsZWQgdG8gdGhhdCBwb3AgKG9y IGRpcmVjdGx5DQogdG8gdGhlIGNvcnJlY3QgYmFja2VuZCB3aXRoaW4gdGhlIHNhbWUgb3IgYSBk aWZmZXJlbnQgcG9wKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdpbGwgc3RpbGwgd29yayBp ZiBpdCB1c2VzIGEgcHJldmlvdXMgYXNzaWduZWQgYnV0IHVudXNlZCBDSUQsIGlmIGl0IGhhcyBk ZXRlY3RlZCBtaWdyYXRpb24uJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIEkgdGhpbmsgdGhhdCdzIHRoZSBrZXkgaXNzdWUg aGVyZTsgdGhlIHRldGhlcmVkIGRldmljZSBoYXMgbm8gd2F5IHRvIGRldGVjdCBtaWdyYXRpb24s IGFuZCBzbyBubyBsb2NhbCB0cmlnZ2VyIGZvciBhIENJRCBjaGFuZ2UuJm5ic3A7IFRoYXQgbWVh bnMgdGhhdCB0aGVyZSBpcyBubyB3YXkgdG8gdHJ1bHkgcHJldmVudCBDSUQgbWlncmF0aW9uIGhl cmUgd2l0aGluIFFVSUMsJm5ic3A7IG9ubHkgdG8gbGltaXQgdGhlIHRpbWUNCiBpdCBpcyBpbiBw bGFjZS4mbmJzcDsgSGF2aW5nIHRoZSBzZXJ2ZXIgdGVybWluYXRlIGFuZCBmaXJpbmcgb2ZmIDAt UlRUIGlzIG9uZSB3YXkgdG8gbGltaXQgdGhhdCB0aW1pbmcsIGJ1dCB3ZSBoYXZlIHRvIGFja25v d2xlZGdlIHRoYXQgaXQgaXMgYXQgYmVzdCBhIG1pdGlnYXRpb24uJm5ic3A7IFRoZSBvbmx5IG90 aGVyIG9wdGlvbiBJIHNlZSBvZmZoYW5kIHdvdWxkIGJlIHRvIHN1Z2dlc3QgdGhhdCB0aGUgY29u bmVjdGVkIGZvcndhcmRlciB0ZXJtaW5hdGUgdGhlDQogbGlua3MgdG8gaW5kdWNlIHNvbWV0aGlu ZyBsaWtlIGEgREhDUFJFTEVBU0UgYW5kIFJFTkVXLCBidXQgdGhpcyBzZWVtcyBzbG93LCZuYnNw OyBmcmFnaWxlLCBhbmQgdW5saWtlbHkgdG8gZGVwbG95LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21h aWwtbS0zMzg5MDcyMTI3NDMzNzQ5NDIzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0 Omw0IGxldmVsMSBsZm8yIj4NCklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9y IGJsdWUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpj dXJyZW50Y29sb3IgY3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJv bTo8L2I+IFRlZCBIYXJkaWUgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE5IDI6MjggUE08YnI+DQo8Yj5Ubzo8L2I+ IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpLmlldGZAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+anJpLmlldGZAZ21haWwuY29tPC9hPiZndDs7IERhdmlkIFNjaGluYXpp ICZsdDs8YSBocmVmPSJtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZHNjaGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+OyBNaWtlIEJp c2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9i bGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OzsgTWFydGluIFRob21zb24gJmx0Ozxh IGhyZWY9Im1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm10QGxvd2Vu dHJvcHkubmV0PC9hPiZndDs7IEthenVobw0KIE9rdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVo b29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwuY29tPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE5ldyBwYXRoID0mZ3Q7IG5ldyBjb25uZWN0aW9u IElELCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkhpIElnb3IsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUgYSBjbGFyaWZ5aW5nIHF1ZXN0aW9uIG9uIHRo ZSBzY2VuYXJpbyBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBUdWUsIEZlYiA1LCAyMDE5IGF0IDEwOjI4IEFNIEx1YmFzaGV2LCBJZ29y ICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRv d3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3Jk ZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwy MDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21h aWwtbS0zMzg5MDcyMTI3NDMzNzQ5NDIzZ21haWwtbTkxNzUzMjU3MzA1NTY1Njg0NDBtc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPg0KRWdyZWdpb3VzIGNo YW5nZXMgaW4gSVAgbWlnaHQgYmUgYSBzaWduYXR1cmUgZm9yIG5ldHdvcmsgY2hhbmdlIChjaGFu Z2UgaW4gLzE2IGFkZHJlc3MsIGZvciBpbnN0YW5jZSkgYW5kIGEgc2VydmVyIGNvdWxkIHRlcm1p bmF0ZSB0aGUgY29ubmVjdGlvbiBhbmQgcmVzcG9uZCB3aXRoIGEgc3RhdGVsZXNzIHJlc2V0IGlm IHRoaXMgaGFwcGVucy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBjbGll bnQgY291bGQgYmUgYSBsYXB0b3AgdGhhdCBpcyB0ZXRoZXJlZCB2aWEgYSBwaG9uZSB0aGF0IGlz IGNoYW5naW5nIHByb3ZpZGVycy4mbmJzcDsgVGhlIGRpc2Nvbm5lY3Qgd291bGQgYmUgY29tcGxl dGVseSDigJxwdW5pdGl2ZeKAnSAodGhlIG9sZCBwYXRo4oCZcyBDSUQgaGFzIGFscmVhZHkgYmVl biBzZW50IG92ZXINCiB0aGUgbmV3IHBhdGgpIGFuZCBiZSBwdW5pc2hpbmcgdGhlIGNsaWVudCBm b3Igc29tZXRoaW5nIGl0IGhhZCBubyBjb250cm9sIG92ZXIgd2hhdHNvZXZlci48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkluIHRoaXMgc2NlbmFyaW8sIHdoYXQgaXMgeW91ciB2aWV3IG9mIHdoZXJlIHRoZSBJUCBh ZGRyZXNzIGNoYW5nZXMgYXJlIHRha2luZyBwbGFjZT8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhZ3JlZSB0aGF0IHRoZSBkZXZp Y2UgY29ubmVjdGVkIHRvIGEgcGhvbmUgKGUuZy4gYnkgYSBtb2JpbGUgaG90c3BvdCkgd2lsbCBu b3QgZ2VuZXJhbGx5IGhhdmUgYSB2aWV3IG9mIHRoZSBjaGFuZ2UgaW4gdXBzdHJlYW0gcGF0aC4m bmJzcDsgSWYgdGhhdCBwaG9uZSBpcyB1c2luZyBzb21ldGhpbmcgbGlrZSBtb2JpbGUNCiBJUCBv ciBhIFZQTiB0byBoYXZlIGEgY29uc2lzdGVudCBleHRlcm5hbCBhZGRyZXNzLCB0aGVuIEkgYWxz byBkb24ndCBzZWUgd2h5IHRoaXMgcGF0aCBjaGFuZ2Ugd291bGQgdHJpZ2dlciBhbnkgY2hhbmdl IGluIENJRC4mbmJzcDsgQnV0IGlmIHRoZSBwaG9uZS9ob3RzcG90J3MgSVAgYWRkcmVzcyBjaGFu Z2VzIGR1cmluZyB0aGlzIGZyb20gb25lIHByb3ZpZGVyJ3Mgc2V0IG9mIGFkZHJlc3NlcyB0byBh bm90aGVyLCB0aGlzIGlzIGZ1bmN0aW9uYWxseQ0KIHJlLWhvbWluZy4mbmJzcDsgSW4gdGhhdCBj YXNlLCBpc24ndCB0aGVyZSBhbHJlYWR5IGEgaGlnaCByaXNrIHRoYXQgdGhlIHRyYWZmaWMgd2ls bCBlbmQgdXAgYXQgYSBkaWZmZXJlbnQgYmFjayBlbmQgYmVjYXVzZSBvZiB0aGUgSVAgY2hhbmdl PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+VGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMgb24gdGhpcyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRlZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJy ZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iZ21haWwtbS0zMzg5MDcyMTI3NDMzNzQ5NDIzZ21haWwtbTkxNzUzMjU3 MzA1NTY1Njg0NDBtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzQiPg0KSWdvcjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXIt Y29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBKYW5hIEl5ZW5nYXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmkuaWV0 ZkBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5 IDA1LCAyMDE5IDY6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IERhdmlkIFNjaGluYXppICZsdDs8YSBo cmVmPSJtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHNj aGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT47IE1p a2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdl dD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm10QGxvd2VudHJvcHkubmV0IiB0YXJnZXQ9Il9ibGFuayI+bXRA bG93ZW50cm9weS5uZXQ8L2E+Jmd0OzsNCiBLYXp1aG8gT2t1ICZsdDs8YSBocmVmPSJtYWlsdG86 a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTmV3IHBhdGggPSZndDsgbmV3IGNvbm5l Y3Rpb24gSUQsIHJpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JIGFncmVlIHRoYXQgd2FudCB0byBoYXZlIE1VU1QgZm9yIGNoYW5naW5nIENJ RCBhbmQgTVVTVCBOT1QgZm9yIHNlbmRpbmcgcGFja2V0cyB3aXRoIHRoZSBzYW1lIENJRCBvbiBt dWx0aXBsZSBwYXRocy4mbmJzcDsgSSB0aG91Z2h0IHdlIGhhZCBhZ3JlZWQgb24gdGhpcyBpbiB0 aGUgcGFzdCwgYnV0IEkgY291bGQgYmUNCiBtaXNyZW1lbWJlcmluZy48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHVuZGVyc3RhbmQgdGhhdCB0aGUg c2VydmVyIGNhbm5vdCBuZWNlc3NhcmlseSB0ZWxsIHRoaXMgZnJvbSBOQVQgcmViaW5kaW5nLCBi dXQgaXQgaXMgdXAgdG8gdGhlIHNlcnZlciB3aGF0IGl0IGRvZXMgaWYgaXQgc2VlcyBhbiBJUC9w b3J0IGNoYW5nZSB3aXRoIG5vIGFjY29tcGFueWluZyBDSUQgY2hhbmdlLiZuYnNwOw0KIEVncmVn aW91cyBjaGFuZ2VzIGluIElQIG1pZ2h0IGJlIGEgc2lnbmF0dXJlIGZvciBuZXR3b3JrIGNoYW5n ZSAoY2hhbmdlIGluIC8xNiBhZGRyZXNzLCBmb3IgaW5zdGFuY2UpIGFuZCBhIHNlcnZlciBjb3Vs ZCB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24gYW5kIHJlc3BvbmQgd2l0aCBhIHN0YXRlbGVzcyBy ZXNldCBpZiB0aGlzIGhhcHBlbnMuJm5ic3A7IEEgY2xpZW50IHRoYXQgaWdub3JlcyB0aGUgTVVT VCBhbmQgdXNlcyB0aGUgc2FtZSBDSUQgYWNyb3NzDQogbmV0d29ya3Mgd291bGQgdGhlbiByaXNr IGdldHRpbmcgdGhlIGNvbm5lY3Rpb24gdGVybWluYXRlZC4mbmJzcDsgSSBzdWdnZXN0IHRoYXQg d2UgYWRkIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCBwb3RlbnRpYWwgc2VydmVyIHJlc3BvbnNlcyB0 byBjbGllbnRzIHRoYXQgdmlvbGF0ZSBub3JtYXRpdmUgZXhwZWN0YXRpb25zLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBG ZWIgNSwgMjAxOSBhdCA4OjEzIEFNIERhdmlkIFNjaGluYXppICZsdDs8YSBocmVmPSJtYWlsdG86 ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHNjaGluYXppLmlldGZA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1 cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgdGhlIGVuZCBvZiB0aGUgZGF5LCB5b3Ug Y2FuIG1ha2UgaXQgYSBNVVNULCBidXQgY2xpZW50cyB3aWxsIGRvIHdoYXQgdGhleSBwbGVhc2Ug YmVjYXVzZSBzZXJ2ZXJzIGNhbid0IGVuZm9yY2UgaXQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5CdXQgSSB3b24ndCBkaWUgb24gdGhpcyBoaWxsLCBJIGNh biBsaXZlIHdpdGggYmVpbmcgZGVjbGFyZWQgaW4gdGhlIHJvdWdoIG9uIHRoaXMgb25lLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRhdmlkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIE1vbiwgRmViIDQsIDIwMTkgYXQgNTozNyBQTSBLYXp1aG8gT2t1ICZsdDs8YSBocmVm PSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3Vy cmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwMTk8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 TVMgR290aGljJnF1b3Q7Ij7lubQ8L3NwYW4+MjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj41PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O01TIEdvdGhpYyZxdW90OyI+5pelPC9zcGFuPig8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ngas8L3NwYW4+KQ0KIDEwOjA4IERhdmlkIFNjaGluYXpp ICZsdDs8YSBocmVmPSJtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZHNjaGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDs6PGJyPg0KJmd0Ozxicj4NCiZn dDsgSWYgYW4gZW5kcG9pbnQgaW50ZW50aW9uYWxseSBtaWdyYXRlcyBhbmQgaXQgaGFzIHVudXNl ZCBjb25uZWN0aW9uIElEcyB0byB1c2UsIGl0IG1ha2VzIHNlbnNlIHRvIG1hbmRhdGUgaXQgTVVT VCBzd2l0Y2ggdG8gb25lIG9mIHRoZSB1bnVzZWQgY29ubmVjdGlvbiBJRHMuPGJyPg0KJmd0OyBI b3dldmVyLCBpZiBpdCBoYXMgcnVuIG91dCBvZiB1bnVzZWQgY29ubmVjdGlvbiBJRHMgdGhlbiBJ IHdvdWxkIGxldCB0aGUgZW5kcG9pbnQgZGVjaWRlIGlmIGl0IHdhbnRzIHRvIGNsb3NlIHRoZSBj b25uZWN0aW9uIG9yIG1pZ3JhdGUgd2l0aCBhIHByZXZpb3VzbHkgdXNlZCBjb25uZWN0aW9uIElE cywgYXMgdGhlcmUgYXJlIHVzZS1jYXNlcyB0aGF0IHZhbHVlIHBlcmZvcm1hbmNlIG92ZXIgbm9u LWxpbmthYmlsaXR5Ljxicj4NCjxicj4NCkkgdGhpbmsgSSBtaWdodCBwcmVmZXIgZW5jb3VyYWdp bmcgZW5kcG9pbnRzIHRvIGdyYWNlZnVsbHkgY2xvc2UgdGhlPGJyPg0KY29ubmVjdGlvbiBiZWZv cmUgaXQgZmFjZXMgYSB0cmFkZS1vZmYgYmV0d2VlbiBwZXJmb3JtYW5jZSBhbmQ8YnI+DQpsaW5r YWJpbGl0eS48YnI+DQo8YnI+DQpUaGVyZWZvcmUsIGFzc3VtaW5nIHRoYXQgd2UgYWRvcHQgTWFy dGluJ3MgcHJvcG9zYWwsIEkgdGhpbmsgaXQgd291bGQ8YnI+DQptYWtlIHNlbnNlIHRvIHJlY29t bWVuZCBhbiBlbmRwb2ludCB0byBzZW5kIEdPQVdBWSB3aGVuIGlmIGl0IGNhbiBubzxicj4NCmxv bmdlciBpc3N1ZSBhIG5ldyBDSUQgZm9yIHRoYXQgUVVJQyBjb25uZWN0aW9uLjxicj4NCjxicj4N CiZndDsgRmluYWxseSwgdGhpcyBjYW5ub3QgYmUgZW5mb3JjZWQgYnkgdGhlIHBlZXIgc2luY2Ug aXQgY2Fubm90IGRpc3Rpbmd1aXNoIGludGVudGlvbmFsIG1pZ3JhdGlvbiBhbmQgdW5pbnRlbnRp b25hbCBtaWdyYXRpb24gKE5BVCByZWJpbmRpbmcpLCBhbmQgd2UgZGlzY3Vzc2VkIGluIFRva3lv IHRoYXQgd2Ugd2FudGVkIHRvIGF2b2lkIG5vbi1lbmZvcmNlYWJsZSBNVVNUcy48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBEYXZpZDxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIE1vbiwgRmViIDQsIDIwMTkg YXQgNDo1NiBQTSBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVl Zm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSB0ZXh0IGlzIHRoZXJlLCBidXQgaXQn cyBwZXJoYXBzIG5vdCBjb21wbGV0ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFzIGRp c2N1c3NlZCBpbiBTZWN0aW9uIDkuNSwgZWFjaCBjb25uZWN0aW9uIElEIE1VU1QgYmUgdXNlZCBv biBwYWNrZXRzIHNlbnQgZnJvbSBvbmx5IG9uZSBsb2NhbCBhZGRyZXNzLiBBbiBlbmRwb2ludCB0 aGF0IG1pZ3JhdGVzIGF3YXkgZnJvbSBhIGxvY2FsIGFkZHJlc3MgU0hPVUxEIHJldGlyZSBhbGwg Y29ubmVjdGlvbiBJRHMgdXNlZCBvbiB0aGF0IGFkZHJlc3Mgb25jZSBpdCBubyBsb25nZXIgcGxh bnMgdG8gdXNlIHRoYXQgYWRkcmVzcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgZ2FwIHNlZW1zIHRvIGJlIHRoYXQgd2hlbiB5b3Vy IHBlZXIgbW92ZXMgdG8gYSBuZXcgYWRkcmVzcywgdGhlcmXigJlzIG5vIHJlcXVpcmVtZW50IHRo YXQgeW91IG5vdCBzZW5kIHRoZSBzYW1lIENJRCB0byB0aGVpciBuZXcgYWRkcmVzcyB0aGF0IHlv dSB1c2VkIHRvd2FyZCB0aGVpciBvbGQgYWRkcmVzcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCiZndDsmZ3Q7IEZyb206IFFVSUMgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 OyBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb248YnI+DQomZ3Q7Jmd0OyBTZW50OiBNb25kYXks IEZlYnJ1YXJ5IDQsIDIwMTkgMzoxNSBQTTxicj4NCiZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWls dG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyZndDsgU3ViamVjdDogTmV3IHBhdGggPSZndDsgbmV3IGNvbm5lY3Rpb24gSUQsIHJpZ2h0 Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IEkgdGhvdWdodCB0aGF0IHdlIGhhZCBhZ3JlZWQgdGhhdCBhbiBlbmRwb2ludCB0aGF0IGludGVu dGlvbmFsbHkgbWlncmF0ZXMgaGFzIHRvIHVzZSBhIG5ldyBjb25uZWN0aW9uIElEIG9uIHRoZSBu ZXcgcGF0aC4mbmJzcDsgQnV0IEkgY291bGRuJ3QgZmluZCBhbnkgJnF1b3Q7TVVTVCZxdW90OyBp biB0aGUgc3BlYyB0aGF0IHNhaWQgdGhhdC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiB0aGUgb2ZmIGNoYW5jZSB0aGF0IHRoaXMgd2Fz bid0IGp1c3QgYSBtaXN0YWtlIGFuZCB0aGVyZSB3YXMgc29tZSBnb29kIHJlYXNvbiBub3QgdG8g bWFuZGF0ZSB0aGlzLCBJJ20gYnJpbmdpbmcgdGhlIGRpc2N1c3Npb24gaGVyZS48YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJJ3ZlIG9wZW5l ZCBhIGRlc2lnbiBpc3N1ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHVi LmNvbV9xdWljd2dfYmFzZS0yRGRyYWZ0c19pc3N1ZXNfMjQxMyZhbXA7ZD1Ed01GYVEmYW1wO2M9 OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4 eWpVWmRuX201NUtQbWxvJmFtcDttPTRCOGkzTzJRNmI2TmZaZE1JRmRzQjBTbHJjbUQ1MFRjMjRV Rm80eENHaVkmYW1wO3M9NWxyOGN6aVpmWDJBOUJXRDNMOFp2OGkxUjN6eUpZQ2l6cXZCamNPbXV5 cyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFz ZS1kcmFmdHMvaXNzdWVzLzI0MTM8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGNoYW5nZSBJJ20gcHJvcG9zaW5nIGlzIGhlcmU6 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fcXVpY3dnX2Jhc2Ut MkRkcmFmdHNfcHVsbF8yNDE0X2NvbW1pdHNfMTM2OThjYmUzMTE5MjJhMzk5NTIzNmRkYTk2MGI0 Y2RmZjQ5ZTM2ZiZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7 cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPTRCOGkz TzJRNmI2TmZaZE1JRmRzQjBTbHJjbUQ1MFRjMjRVRm80eENHaVkmYW1wO3M9UjAtanVlV2dhdFQ1 V0RrZFlRaV9KVlpGYWNneS1jQUFBNFAydW9zdDNqdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8yNDE0L2NvbW1pdHMv MTM2OThjYmUzMTE5MjJhMzk5NTIzNmRkYTk2MGI0Y2RmZjQ5ZTM2ZjwvYT48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KS2F6dWhvIE9r dTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_25ce934955dc4142b5758fc633661744usma1exdag1mb6msgcorpak_-- From nobody Tue Feb 5 15:53:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D93913134F for ; Tue, 5 Feb 2019 15:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.405 X-Spam-Level: X-Spam-Status: No, score=-3.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, 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 (1024-bit key) header.d=fb.com header.b=qCeqLSNQ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=iSzdtkbj 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 qf0EvAvP_DEp for ; Tue, 5 Feb 2019 15:53:17 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 EB49B131260 for ; Tue, 5 Feb 2019 15:53:16 -0800 (PST) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x15NqLPA007432; Tue, 5 Feb 2019 15:53:11 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=Z3ij8i5caJr5bgg85RfU0jwEqGb3hm1lfcUqC/rP7tg=; b=qCeqLSNQs9Xs2F3RKzf8qbFexsmw3fMeXzX573gO2U/tGt7aszUy2hJVNYMlhSj06+ZN rEhcIdhCoQnzSuwYOxbDrzCp3fHeejcTrprNKnWKuB7mKYpgzffaK4XW+7Z08kopdFOU yYWtoWIJYu1fNaFKLXDk40xPLjzVptUIQwM= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0b-00082601.pphosted.com with ESMTP id 2qfjse0bfn-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Feb 2019 15:53:11 -0800 Received: from frc-hub01.TheFacebook.com (2620:10d:c021:18::171) by frc-hub05.TheFacebook.com (2620:10d:c021:18::175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 5 Feb 2019 15:53:09 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Tue, 5 Feb 2019 15:53:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z3ij8i5caJr5bgg85RfU0jwEqGb3hm1lfcUqC/rP7tg=; b=iSzdtkbjFB+AhHIuA9M4WmbBtpD4SwXOu03lcVFoQJnxE3YjHNG98KT6XuOG3VXyKmfyL80i2c8W9ByTcmebtfDaNwLW2lMEiC7xlSB+4LyI82gy/sjxGPMpZ7A3NunfgMvZlXmFV36NkOlDWCiA3b9GyJOV8rC9ug/SyX6pDSY= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2760.namprd15.prod.outlook.com (20.179.157.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Tue, 5 Feb 2019 23:52:50 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084%5]) with mapi id 15.20.1580.019; Tue, 5 Feb 2019 23:52:50 +0000 From: Roberto Peon To: "Lubashev, Igor" , Ted Hardie CC: Jana Iyengar , Mike Bishop , David Schinazi , "quic@ietf.org" , Martin Thomson , Kazuho Oku Subject: Re: New path => new connection ID, right? Thread-Topic: New path => new connection ID, right? Thread-Index: AQHUvN+NcueOarMuR0CYh90M6oUeO6XQYXIAgAADUoCAAAgLAIAAEoQAgACWfgCAAHEQAIAAETmAgAAjEACAABLSAIAACMYA//+FL4A= Date: Tue, 5 Feb 2019 23:52:49 +0000 Message-ID: References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> <25ce934955dc4142b5758fc633661744@usma1ex-dag1mb6.msg.corp.akamai.com> In-Reply-To: <25ce934955dc4142b5758fc633661744@usma1ex-dag1mb6.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::7:55b7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2760; 20:PtALKVIrOhJpA4LsSJcuStc9qmsFgAf+iAo3s8+ZuKi1ooC0IcOlaIjjV4hVNeE/dNyeh/SWl/i1vV77x4r2cbsKBSbRAUD/yKYhXsVtlOf4MoLNvJV6ERhbnpt2aThfmCjHHvqU/AA0VEU2c4JWeMbmmx8CTROiz0zfjq46kYA= x-ms-office365-filtering-correlation-id: 49d855be-2b8a-45a6-a115-08d68bc5095b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2760; x-ms-traffictypediagnostic: BYAPR15MB2760: x-microsoft-antispam-prvs: x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(39860400002)(346002)(376002)(189003)(199004)(13464003)(51444003)(316002)(110136005)(33656002)(53936002)(54906003)(6246003)(6116002)(561944003)(105586002)(606006)(68736007)(4326008)(58126008)(36756003)(446003)(486006)(76176011)(966005)(46003)(236005)(6486002)(106356001)(2616005)(476003)(6512007)(6306002)(54896002)(11346002)(229853002)(97736004)(93886005)(6436002)(14454004)(53946003)(99286004)(30864003)(86362001)(478600001)(8936002)(5070765005)(186003)(82746002)(8676002)(81166006)(81156014)(7736002)(71200400001)(83716004)(71190400001)(53546011)(6506007)(256004)(14444005)(102836004)(5024004)(25786009)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2760; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AhmZa9Jfh+6fy3FMoyBqHFsopMy8a8YKYPz6X4za+PSn5/ASyy7rQxQ2ipTI/zlx9zIfgPXr6JVeM/oPU3zhWyLumYGMQx8rtLNWYq/O6cRCzvJimzN2G5m9r8KmflKPn9cvJWgJJ60gyo0Mg0yH/MbfLbNtH2cUym1sltY+b1OOM2+qluFMDNhabYXSMU21zZMBjWmvZN0z5iXbtVULrRCjLOdTRxb3/vM+E+v3roOj18rjRCOo6hMU6zoeKqczKG0j+chxYhgaH0G6678ASPI26xRpHDxbYM89blVoJXVYqab0WaEvd6sUHOINsQZnNvirQPLXmcsVPZd+5WOOeRT9n1V4U14mGWqWCCdpwybwyI9u78QiNhpZxgT0lQhlTC46Kq0XXO/5YbB3Fi6+sqxkpyRbP2qJ/iL8bUhzSNk= Content-Type: multipart/alternative; boundary="_000_B29C670C21EC412B967516164812F014fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 49d855be-2b8a-45a6-a115-08d68bc5095b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2019 23:52:49.9380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2760 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-05_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 23:53:20 -0000 --_000_B29C670C21EC412B967516164812F014fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VHdvIHBvaW50czoNCg0KICAxLiAgQSBwb29ybHkgaW1wbGVtZW50ZWQgY2xpZW50IGNhbiBsZWFr IENJRHMgYWxvbmcgb3RoZXIgcGF0aHMg4oCcaW50ZW50aW9uYWxseeKAnS4gUHJvdmlkaW5nIGEg ZGlyZWN0IHNpZ25hbCBvbiB0aGlzIGlzIGxpa2VseSB0byByYWlzZSBhd2FyZW5lc3MuIFRoYXQg c2FpZCwgSSBkb27igJl0IG11Y2ggY2FyZSBiZWNhdXNlOg0KICAyLiAgSXMgdGhpcyByZWFsbHkg aW1wb3J0YW50PyBXaWxsIHRoZSBwcm90b2NvbCBmYWlsIG91ciB1c2VycyBpbiBzb21lIGludGVy ZXN0aW5nIHdheSB3aXRob3V0IGNoYW5naW5nIHRoaXM/DQoNCi09Ug0KDQpGcm9tOiBRVUlDIDxx dWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiTHViYXNoZXYsIElnb3IiIDxpbHVi YXNoZUBha2FtYWkuY29tPg0KRGF0ZTogVHVlc2RheSwgRmVicnVhcnkgNSwgMjAxOSBhdCAzOjEz IFBNDQpUbzogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPg0KQ2M6IEphbmEgSXllbmdh ciA8anJpLmlldGZAZ21haWwuY29tPiwgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJl PiwgRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4sICJxdWljQGlldGYu b3JnIiA8cXVpY0BpZXRmLm9yZz4sIE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD4s IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSRTogTmV3IHBhdGgg PT4gbmV3IGNvbm5lY3Rpb24gSUQsIHJpZ2h0Pw0KDQoNCiAgKiAgIEkgZGlzYWdyZWUgdGhhdCB0 aGVzZSBhcmUgdGhlIHNhbWUNCg0KSSB1bmRlcnN0b29kIHRoZSBxdWVzdGlvbiB0byBiZSBhYm91 dCByb3V0aW5nIHBhY2tldHMgZnJvbSBhIG5ldyBJUCBhZGRyZXNzIHRvIHRoZSBvcmlnaW5hbCBi YWNrZW5kLiAgVGhlIG1pZ3JhdGlvbiBvZiB0aGUgdGV0aGVyaW5nIGRldmljZSBpcyB0aGUgc2Ft ZSBhcyB0aGUgbWlncmF0aW9uIG9mIHRoZSBjbGllbnQgZnJvbSB0aGUgcm91dGluZyBwZXJzcGVj dGl2ZSB3aXRoaW4gdGhlIGRlc3RpbmF0aW9uIG5ldHdvcmsgKHdoaWNoIG1heSBiZSBjb21wcmlz ZWQgb2YgbXVsdGlwbGUgYW55Y2FzdCBwb3BzKS4NCg0KDQogICogICBUaGF0IG1lYW5zIHRoYXQg dGhlcmUgaXMgbm8gd2F5IHRvIHRydWx5IHByZXZlbnQgQ0lEIG1pZ3JhdGlvbiBoZXJlIHdpdGhp biBRVUlDLCAgb25seSB0byBsaW1pdCB0aGUgdGltZSBpdCBpcyBpbiBwbGFjZS4NCg0KVGhlIHB1 cnBvc2Ugb2YgdGhpcyDigJxNVVNUIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbuKAnSBwcm9wb3Nh bCB3YXMgdG8gaW1wcm92ZSBwcml2YWN5LiBUaGVyZSBpcyBsaXR0bGUgdG8gYmUgZ2FpbmVkIGJ5 IGN1dHRpbmcgb2ZmIHRoZSBjb25uZWN0aW9uLCBvbmNlIGV2ZW4gYSBzaW5nbGUgcGFja2V0IGhh cyBleHBvc2VkIHRoZSBvcmlnaW5hbCBDSUQgdG8gdGhlIG5ldyBwYXRoLiAgSXTigJlzIG5vdCBs aWtlIG11bHRpcGxlIHBhY2tldHMgcHJvdmlkZSBhIHN0cm9uZ2VyIGxpbmthYmlsaXR5IHNpZ25h bCB0aGFuIGEganVzdCBvbmUgcGFja2V0LiAgV2UgbWF5IHdpc2ggdG8g4oCccHVuaXNo4oCdIGJ1 Z2d5IGltcGxlbWVudGF0aW9ucyB0byBpbmR1Y2UgdGhlaXIgdmVuZG9ycyB0byBkbyBiZXR0ZXIs IGJ1dCB0aGUgY2xpZW50IGltcGxlbWVudGF0aW9uIGNhbm5vdCBkbyBhbnkgYmV0dGVyIGluIHRo aXMgY2FzZS4NCg0KDQogICogICBUaGUgb25seSBvdGhlciBvcHRpb24gSSBzZWUgb2ZmaGFuZCB3 b3VsZCBiZSB0byBzdWdnZXN0IHRoYXQgdGhlIGNvbm5lY3RlZCBmb3J3YXJkZXIgdGVybWluYXRl IHRoZSBsaW5rcyB0byBpbmR1Y2Ugc29tZXRoaW5nIGxpa2UgYSBESENQUkVMRUFTRSBhbmQgUkVO RVcsIGJ1dCB0aGlzIHNlZW1zIHNsb3csICBmcmFnaWxlLCBhbmQgdW5saWtlbHkgdG8gZGVwbG95 Lg0KDQpSaWdodC4gIFRoaXMgbmV0d29yayBhdHRhY2htZW50IGNoYW5nZSBub3RpZmljYXRpb24g d291bGQgYmUgYSBzdWJqZWN0IHRvIGEgZGlmZmVyZW50IGRyYWZ0IGluIGEgZGlmZmVyZW50IFdH LCBhbmQgaXRzIGRlcGxveW1lbnQgd291bGQgYmUgc2xvdy4NCg0KDQogICogICBJZ29yDQoNCg0K RnJvbTogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPg0KU2VudDogVHVlc2RheSwgRmVi cnVhcnkgMDUsIDIwMTkgNTo0MSBQTQ0KVG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2Ft YWkuY29tPg0KQ2M6IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPjsgRGF2aWQgU2No aW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT47IHF1aWNAaWV0Zi5vcmc7IE1pa2UgQmlz aG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT47IE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5 Lm5ldD47IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogTmV3 IHBhdGggPT4gbmV3IGNvbm5lY3Rpb24gSUQsIHJpZ2h0Pw0KSW1wb3J0YW5jZTogSGlnaA0KDQpP biBUdWUsIEZlYiA1LCAyMDE5IGF0IDE6MzMgUE0gTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFr YW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PiB3cm90ZToNCg0KICAqICAgQnV0 IGlmIHRoZSBwaG9uZS9ob3RzcG90J3MgSVAgYWRkcmVzcyBjaGFuZ2VzIGR1cmluZyB0aGlzIGZy b20gb25lIHByb3ZpZGVyJ3Mgc2V0IG9mIGFkZHJlc3NlcyB0byBhbm90aGVyLCB0aGlzIGlzIGZ1 bmN0aW9uYWxseSByZS1ob21pbmcuICBJbiB0aGF0IGNhc2UsIGlzbid0IHRoZXJlIGFscmVhZHkg YSBoaWdoIHJpc2sgdGhhdCB0aGUgdHJhZmZpYyB3aWxsIGVuZCB1cCBhdCBhIGRpZmZlcmVudCBi YWNrIGVuZCBiZWNhdXNlIG9mIHRoZSBJUCBjaGFuZ2U/DQoNClllcywgdGhpcyBpcyB0aGUgc2Nl bmFyaW8g4oCTIHRoZSBwaG9uZSAob3IgeW91ciBjYXLigJlzIHVwbGluaywgaWYgY29ubmVjdGVk IHRvIGFuIGluLWNhciB3aWZpKSBoYXMgc3dpdGNoZWQgdG8gYSBkaWZmZXJlbnQgcHJvdmlkZXIu DQoNClRoaXMgaXMgbm8gZGlmZmVyZW50IHRoYW4gYSB1c3VhbCBjZWxsPC0+d2lmaSBtaWdyYXRp b24gY2FzZSBmcm9tIHRoZSByb3V0aW5nIHBlcnNwZWN0aXZlLCBhbmQgdGhlIHB1cnBvc2Ugb2Yg c2VydmVyLWdlbmVyYXRlZCBjb25uZWN0aW9uIElEIG9uIGNsaWVudC10by1zZXJ2ZXIgcGFja2V0 cyBpcyB0byBmYWNpbGl0YXRlIHJvdXRpbmcgdG8gdGhlIGNvcnJlY3QgYmFja2VuZC4NCg0KSSBk aXNhZ3JlZSB0aGF0IHRoZXNlIGFyZSB0aGUgc2FtZS4gIEluIHRoZSBjb21tb24gY2FzZSBmb3Ig Y2VsbDwtLT53aWZpIG1pZ3JhdGlvbiB0aGUgY29ubmVjdGVkIGRldmljZSBpcyBhd2FyZSBvZiB0 aGUgaW50ZXJmYWNlIGNoYW5nZS4gIEJlY2F1c2UgdGhlIGNvbm5lY3RlZCBkZXZpY2UgaXMgbm93 IHNlcnZpbmcgYXMgYSBmb3J3YXJkZXIgZm9yIHRoZSBwYWNrZXRzIG9mIG90aGVycywgdGhlIHRl dGhlcmVkIGRldmljZSBjYW5ub3QgZGV0ZWN0IHRoZSBzb3J0IG9mIGludGVyZmFjZSBjaGFuZ2Uu ICBJdCdzIGEgcGF0aCBjaGFuZ2UgdG8gdGhlIHRldGhlcmVkIGRldmljZSwgbm90IGFuIGludGVy ZmFjZSBjaGFuZ2UuICBDaHJpc3RpYW4gaGFzIHBvaW50ZWQgb3V0IGEgd2F5IHRvIHVzZSB2NiBS QSB0byBpbmRpY2F0ZSB0aGF0IHJlaG9taW5nIGhhcyBvY2N1cnJlZCBhbmQgdG8gc2lnbmFsIHRo YXQgdG8gdGhlIHRldGhlcmVkIGRldmljZS4gIFRoaXMgaXNuJ3QgYXMgc3RyYWlnaHRmb3J3YXJk IGluIGEgdjQgTkFUIHNpdHVhdGlvbiwgdW5mb3J0dW5hdGVseS4NCg0KRm9yIGV4YW1wbGUsIGlm IHRoZSBwYWNrZXQgYXJyaXZlcyBhdCBhIGRpZmZlcmVudCBhbnljYXN0IHBvcCwgdGhlIGlkZW50 aWZ5IG9mIHRoZSBvcmlnaW5hbCBwb3AgaXMgZW5jb2RlZCBpbiB0aGUgY29ubmVjdGlvbiBJRCwg YW5kIHRoZSBwYWNrZXQgY2FuIGJlIHR1bm5lbGVkIHRvIHRoYXQgcG9wIChvciBkaXJlY3RseSB0 byB0aGUgY29ycmVjdCBiYWNrZW5kIHdpdGhpbiB0aGUgc2FtZSBvciBhIGRpZmZlcmVudCBwb3Ap Lg0KDQpUaGlzIHdpbGwgc3RpbGwgd29yayBpZiBpdCB1c2VzIGEgcHJldmlvdXMgYXNzaWduZWQg YnV0IHVudXNlZCBDSUQsIGlmIGl0IGhhcyBkZXRlY3RlZCBtaWdyYXRpb24uDQoNCkFuZCBJIHRo aW5rIHRoYXQncyB0aGUga2V5IGlzc3VlIGhlcmU7IHRoZSB0ZXRoZXJlZCBkZXZpY2UgaGFzIG5v IHdheSB0byBkZXRlY3QgbWlncmF0aW9uLCBhbmQgc28gbm8gbG9jYWwgdHJpZ2dlciBmb3IgYSBD SUQgY2hhbmdlLiAgVGhhdCBtZWFucyB0aGF0IHRoZXJlIGlzIG5vIHdheSB0byB0cnVseSBwcmV2 ZW50IENJRCBtaWdyYXRpb24gaGVyZSB3aXRoaW4gUVVJQywgIG9ubHkgdG8gbGltaXQgdGhlIHRp bWUgaXQgaXMgaW4gcGxhY2UuICBIYXZpbmcgdGhlIHNlcnZlciB0ZXJtaW5hdGUgYW5kIGZpcmlu ZyBvZmYgMC1SVFQgaXMgb25lIHdheSB0byBsaW1pdCB0aGF0IHRpbWluZywgYnV0IHdlIGhhdmUg dG8gYWNrbm93bGVkZ2UgdGhhdCBpdCBpcyBhdCBiZXN0IGEgbWl0aWdhdGlvbi4gIFRoZSBvbmx5 IG90aGVyIG9wdGlvbiBJIHNlZSBvZmZoYW5kIHdvdWxkIGJlIHRvIHN1Z2dlc3QgdGhhdCB0aGUg Y29ubmVjdGVkIGZvcndhcmRlciB0ZXJtaW5hdGUgdGhlIGxpbmtzIHRvIGluZHVjZSBzb21ldGhp bmcgbGlrZSBhIERIQ1BSRUxFQVNFIGFuZCBSRU5FVywgYnV0IHRoaXMgc2VlbXMgc2xvdywgIGZy YWdpbGUsIGFuZCB1bmxpa2VseSB0byBkZXBsb3kuDQoNClRlZA0KDQoNCg0KDQoNCiAgKiAgIEln b3INCg0KRnJvbTogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0bzp0ZWQuaWV0 ZkBnbWFpbC5jb20+Pg0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDUsIDIwMTkgMjoyOCBQTQ0K VG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBh a2FtYWkuY29tPj4NCkNjOiBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 anJpLmlldGZAZ21haWwuY29tPj47IERhdmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFp bC5jb208bWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4+OyBxdWljQGlldGYub3JnPG1h aWx0bzpxdWljQGlldGYub3JnPjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1h aWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+OyBNYXJ0aW4gVGhvbXNvbiA8bXRAbG93ZW50cm9w eS5uZXQ8bWFpbHRvOm10QGxvd2VudHJvcHkubmV0Pj47IEthenVobyBPa3UgPGthenVob29rdUBn bWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IE5ldyBw YXRoID0+IG5ldyBjb25uZWN0aW9uIElELCByaWdodD8NCg0KSGkgSWdvciwNCg0KSSBoYXZlIGEg Y2xhcmlmeWluZyBxdWVzdGlvbiBvbiB0aGUgc2NlbmFyaW8gYmVsb3cuDQoNCk9uIFR1ZSwgRmVi IDUsIDIwMTkgYXQgMTA6MjggQU0gTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208 bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PiB3cm90ZToNCg0KICAqICAgRWdyZWdpb3VzIGNo YW5nZXMgaW4gSVAgbWlnaHQgYmUgYSBzaWduYXR1cmUgZm9yIG5ldHdvcmsgY2hhbmdlIChjaGFu Z2UgaW4gLzE2IGFkZHJlc3MsIGZvciBpbnN0YW5jZSkgYW5kIGEgc2VydmVyIGNvdWxkIHRlcm1p bmF0ZSB0aGUgY29ubmVjdGlvbiBhbmQgcmVzcG9uZCB3aXRoIGEgc3RhdGVsZXNzIHJlc2V0IGlm IHRoaXMgaGFwcGVucy4NCg0KVGhlIGNsaWVudCBjb3VsZCBiZSBhIGxhcHRvcCB0aGF0IGlzIHRl dGhlcmVkIHZpYSBhIHBob25lIHRoYXQgaXMgY2hhbmdpbmcgcHJvdmlkZXJzLiAgVGhlIGRpc2Nv bm5lY3Qgd291bGQgYmUgY29tcGxldGVseSDigJxwdW5pdGl2ZeKAnSAodGhlIG9sZCBwYXRo4oCZ cyBDSUQgaGFzIGFscmVhZHkgYmVlbiBzZW50IG92ZXIgdGhlIG5ldyBwYXRoKSBhbmQgYmUgcHVu aXNoaW5nIHRoZSBjbGllbnQgZm9yIHNvbWV0aGluZyBpdCBoYWQgbm8gY29udHJvbCBvdmVyIHdo YXRzb2V2ZXIuDQoNCg0KSW4gdGhpcyBzY2VuYXJpbywgd2hhdCBpcyB5b3VyIHZpZXcgb2Ygd2hl cmUgdGhlIElQIGFkZHJlc3MgY2hhbmdlcyBhcmUgdGFraW5nIHBsYWNlPw0KDQpJIGFncmVlIHRo YXQgdGhlIGRldmljZSBjb25uZWN0ZWQgdG8gYSBwaG9uZSAoZS5nLiBieSBhIG1vYmlsZSBob3Rz cG90KSB3aWxsIG5vdCBnZW5lcmFsbHkgaGF2ZSBhIHZpZXcgb2YgdGhlIGNoYW5nZSBpbiB1cHN0 cmVhbSBwYXRoLiAgSWYgdGhhdCBwaG9uZSBpcyB1c2luZyBzb21ldGhpbmcgbGlrZSBtb2JpbGUg SVAgb3IgYSBWUE4gdG8gaGF2ZSBhIGNvbnNpc3RlbnQgZXh0ZXJuYWwgYWRkcmVzcywgdGhlbiBJ IGFsc28gZG9uJ3Qgc2VlIHdoeSB0aGlzIHBhdGggY2hhbmdlIHdvdWxkIHRyaWdnZXIgYW55IGNo YW5nZSBpbiBDSUQuICBCdXQgaWYgdGhlIHBob25lL2hvdHNwb3QncyBJUCBhZGRyZXNzIGNoYW5n ZXMgZHVyaW5nIHRoaXMgZnJvbSBvbmUgcHJvdmlkZXIncyBzZXQgb2YgYWRkcmVzc2VzIHRvIGFu b3RoZXIsIHRoaXMgaXMgZnVuY3Rpb25hbGx5IHJlLWhvbWluZy4gIEluIHRoYXQgY2FzZSwgaXNu J3QgdGhlcmUgYWxyZWFkeSBhIGhpZ2ggcmlzayB0aGF0IHRoZSB0cmFmZmljIHdpbGwgZW5kIHVw IGF0IGEgZGlmZmVyZW50IGJhY2sgZW5kIGJlY2F1c2Ugb2YgdGhlIElQIGNoYW5nZT8NCg0KVGhh bmtzIGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMgb24gdGhpcywNCg0KVGVkDQoNCg0KICAqICAg SWdvcg0KDQpGcm9tOiBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86anJp LmlldGZAZ21haWwuY29tPj4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE5IDY6NDIg QU0NClRvOiBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0bzpk c2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+Pg0KQ2M6IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNA aWV0Zi5vcmc+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNo b3BAZXZlcXVlZm91LmJlPj47IE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldDxtYWls dG86bXRAbG93ZW50cm9weS5uZXQ+PjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxt YWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogTmV3IHBhdGggPT4gbmV3 IGNvbm5lY3Rpb24gSUQsIHJpZ2h0Pw0KDQpJIGFncmVlIHRoYXQgd2FudCB0byBoYXZlIE1VU1Qg Zm9yIGNoYW5naW5nIENJRCBhbmQgTVVTVCBOT1QgZm9yIHNlbmRpbmcgcGFja2V0cyB3aXRoIHRo ZSBzYW1lIENJRCBvbiBtdWx0aXBsZSBwYXRocy4gIEkgdGhvdWdodCB3ZSBoYWQgYWdyZWVkIG9u IHRoaXMgaW4gdGhlIHBhc3QsIGJ1dCBJIGNvdWxkIGJlIG1pc3JlbWVtYmVyaW5nLg0KDQpJIHVu ZGVyc3RhbmQgdGhhdCB0aGUgc2VydmVyIGNhbm5vdCBuZWNlc3NhcmlseSB0ZWxsIHRoaXMgZnJv bSBOQVQgcmViaW5kaW5nLCBidXQgaXQgaXMgdXAgdG8gdGhlIHNlcnZlciB3aGF0IGl0IGRvZXMg aWYgaXQgc2VlcyBhbiBJUC9wb3J0IGNoYW5nZSB3aXRoIG5vIGFjY29tcGFueWluZyBDSUQgY2hh bmdlLiAgRWdyZWdpb3VzIGNoYW5nZXMgaW4gSVAgbWlnaHQgYmUgYSBzaWduYXR1cmUgZm9yIG5l dHdvcmsgY2hhbmdlIChjaGFuZ2UgaW4gLzE2IGFkZHJlc3MsIGZvciBpbnN0YW5jZSkgYW5kIGEg c2VydmVyIGNvdWxkIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiBhbmQgcmVzcG9uZCB3aXRoIGEg c3RhdGVsZXNzIHJlc2V0IGlmIHRoaXMgaGFwcGVucy4gIEEgY2xpZW50IHRoYXQgaWdub3JlcyB0 aGUgTVVTVCBhbmQgdXNlcyB0aGUgc2FtZSBDSUQgYWNyb3NzIG5ldHdvcmtzIHdvdWxkIHRoZW4g cmlzayBnZXR0aW5nIHRoZSBjb25uZWN0aW9uIHRlcm1pbmF0ZWQuICBJIHN1Z2dlc3QgdGhhdCB3 ZSBhZGQgc29tZSBkaXNjdXNzaW9uIGFib3V0IHBvdGVudGlhbCBzZXJ2ZXIgcmVzcG9uc2VzIHRv IGNsaWVudHMgdGhhdCB2aW9sYXRlIG5vcm1hdGl2ZSBleHBlY3RhdGlvbnMuDQoNCk9uIFR1ZSwg RmViIDUsIDIwMTkgYXQgODoxMyBBTSBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21h aWwuY29tPG1haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkF0IHRoZSBl bmQgb2YgdGhlIGRheSwgeW91IGNhbiBtYWtlIGl0IGEgTVVTVCwgYnV0IGNsaWVudHMgd2lsbCBk byB3aGF0IHRoZXkgcGxlYXNlIGJlY2F1c2Ugc2VydmVycyBjYW4ndCBlbmZvcmNlIGl0Lg0KQnV0 IEkgd29uJ3QgZGllIG9uIHRoaXMgaGlsbCwgSSBjYW4gbGl2ZSB3aXRoIGJlaW5nIGRlY2xhcmVk IGluIHRoZSByb3VnaCBvbiB0aGlzIG9uZS4NCg0KRGF2aWQNCg0KT24gTW9uLCBGZWIgNCwgMjAx OSBhdCA1OjM3IFBNIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVo b29rdUBnbWFpbC5jb20+PiB3cm90ZToNCjIwMTnlubQy5pyINeaXpSjngaspIDEwOjA4IERhdmlk IFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmRzY2hpbmF6aS5pZXRm QGdtYWlsLmNvbT4+Og0KPg0KPiBJZiBhbiBlbmRwb2ludCBpbnRlbnRpb25hbGx5IG1pZ3JhdGVz IGFuZCBpdCBoYXMgdW51c2VkIGNvbm5lY3Rpb24gSURzIHRvIHVzZSwgaXQgbWFrZXMgc2Vuc2Ug dG8gbWFuZGF0ZSBpdCBNVVNUIHN3aXRjaCB0byBvbmUgb2YgdGhlIHVudXNlZCBjb25uZWN0aW9u IElEcy4NCj4gSG93ZXZlciwgaWYgaXQgaGFzIHJ1biBvdXQgb2YgdW51c2VkIGNvbm5lY3Rpb24g SURzIHRoZW4gSSB3b3VsZCBsZXQgdGhlIGVuZHBvaW50IGRlY2lkZSBpZiBpdCB3YW50cyB0byBj bG9zZSB0aGUgY29ubmVjdGlvbiBvciBtaWdyYXRlIHdpdGggYSBwcmV2aW91c2x5IHVzZWQgY29u bmVjdGlvbiBJRHMsIGFzIHRoZXJlIGFyZSB1c2UtY2FzZXMgdGhhdCB2YWx1ZSBwZXJmb3JtYW5j ZSBvdmVyIG5vbi1saW5rYWJpbGl0eS4NCg0KSSB0aGluayBJIG1pZ2h0IHByZWZlciBlbmNvdXJh Z2luZyBlbmRwb2ludHMgdG8gZ3JhY2VmdWxseSBjbG9zZSB0aGUNCmNvbm5lY3Rpb24gYmVmb3Jl IGl0IGZhY2VzIGEgdHJhZGUtb2ZmIGJldHdlZW4gcGVyZm9ybWFuY2UgYW5kDQpsaW5rYWJpbGl0 eS4NCg0KVGhlcmVmb3JlLCBhc3N1bWluZyB0aGF0IHdlIGFkb3B0IE1hcnRpbidzIHByb3Bvc2Fs LCBJIHRoaW5rIGl0IHdvdWxkDQptYWtlIHNlbnNlIHRvIHJlY29tbWVuZCBhbiBlbmRwb2ludCB0 byBzZW5kIEdPQVdBWSB3aGVuIGlmIGl0IGNhbiBubw0KbG9uZ2VyIGlzc3VlIGEgbmV3IENJRCBm b3IgdGhhdCBRVUlDIGNvbm5lY3Rpb24uDQoNCj4gRmluYWxseSwgdGhpcyBjYW5ub3QgYmUgZW5m b3JjZWQgYnkgdGhlIHBlZXIgc2luY2UgaXQgY2Fubm90IGRpc3Rpbmd1aXNoIGludGVudGlvbmFs IG1pZ3JhdGlvbiBhbmQgdW5pbnRlbnRpb25hbCBtaWdyYXRpb24gKE5BVCByZWJpbmRpbmcpLCBh bmQgd2UgZGlzY3Vzc2VkIGluIFRva3lvIHRoYXQgd2Ugd2FudGVkIHRvIGF2b2lkIG5vbi1lbmZv cmNlYWJsZSBNVVNUcy4NCj4NCj4gRGF2aWQNCj4NCj4gT24gTW9uLCBGZWIgNCwgMjAxOSBhdCA0 OjU2IFBNIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBl dmVxdWVmb3UuYmU+PiB3cm90ZToNCj4+DQo+PiBUaGUgdGV4dCBpcyB0aGVyZSwgYnV0IGl0J3Mg cGVyaGFwcyBub3QgY29tcGxldGU6DQo+Pg0KPj4gQXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gOS41 LCBlYWNoIGNvbm5lY3Rpb24gSUQgTVVTVCBiZSB1c2VkIG9uIHBhY2tldHMgc2VudCBmcm9tIG9u bHkgb25lIGxvY2FsIGFkZHJlc3MuIEFuIGVuZHBvaW50IHRoYXQgbWlncmF0ZXMgYXdheSBmcm9t IGEgbG9jYWwgYWRkcmVzcyBTSE9VTEQgcmV0aXJlIGFsbCBjb25uZWN0aW9uIElEcyB1c2VkIG9u IHRoYXQgYWRkcmVzcyBvbmNlIGl0IG5vIGxvbmdlciBwbGFucyB0byB1c2UgdGhhdCBhZGRyZXNz Lg0KPj4NCj4+DQo+Pg0KPj4gVGhlIGdhcCBzZWVtcyB0byBiZSB0aGF0IHdoZW4geW91ciBwZWVy IG1vdmVzIHRvIGEgbmV3IGFkZHJlc3MsIHRoZXJl4oCZcyBubyByZXF1aXJlbWVudCB0aGF0IHlv dSBub3Qgc2VuZCB0aGUgc2FtZSBDSUQgdG8gdGhlaXIgbmV3IGFkZHJlc3MgdGhhdCB5b3UgdXNl ZCB0b3dhcmQgdGhlaXIgb2xkIGFkZHJlc3MuDQo+Pg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NCj4+ IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgNCwgMjAxOSAzOjE1IFBNDQo+PiBUbzogcXVpY0BpZXRm Lm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IE5ldyBwYXRoID0+IG5ldyBj b25uZWN0aW9uIElELCByaWdodD8NCj4+DQo+Pg0KPj4NCj4+IEkgdGhvdWdodCB0aGF0IHdlIGhh ZCBhZ3JlZWQgdGhhdCBhbiBlbmRwb2ludCB0aGF0IGludGVudGlvbmFsbHkgbWlncmF0ZXMgaGFz IHRvIHVzZSBhIG5ldyBjb25uZWN0aW9uIElEIG9uIHRoZSBuZXcgcGF0aC4gIEJ1dCBJIGNvdWxk bid0IGZpbmQgYW55ICJNVVNUIiBpbiB0aGUgc3BlYyB0aGF0IHNhaWQgdGhhdC4NCj4+DQo+Pg0K Pj4NCj4+IE9uIHRoZSBvZmYgY2hhbmNlIHRoYXQgdGhpcyB3YXNuJ3QganVzdCBhIG1pc3Rha2Ug YW5kIHRoZXJlIHdhcyBzb21lIGdvb2QgcmVhc29uIG5vdCB0byBtYW5kYXRlIHRoaXMsIEknbSBi cmluZ2luZyB0aGUgZGlzY3Vzc2lvbiBoZXJlLg0KPj4NCj4+DQo+Pg0KPj4gSSd2ZSBvcGVuZWQg YSBkZXNpZ24gaXNzdWU6DQo+Pg0KPj4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRy YWZ0cy9pc3N1ZXMvMjQxMzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fcXVpY3dnX2Jhc2UtMkRkcmFmdHNfaXNzdWVzXzI0MTMm ZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNy VzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPTRCOGkzTzJRNmI2TmZaZE1JRmRzQjBTbHJjbUQ1MFRj MjRVRm80eENHaVkmcz01bHI4Y3ppWmZYMkE5QldEM0w4WnY4aTFSM3p5SllDaXpxdkJqY09tdXlz JmU9Pg0KPj4NCj4+DQo+Pg0KPj4gVGhlIGNoYW5nZSBJJ20gcHJvcG9zaW5nIGlzIGhlcmU6DQo+ Pg0KPj4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzI0MTQvY29t bWl0cy8xMzY5OGNiZTMxMTkyMmEzOTk1MjM2ZGRhOTYwYjRjZGZmNDllMzZmPGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9xdWlj d2dfYmFzZS0yRGRyYWZ0c19wdWxsXzI0MTRfY29tbWl0c18xMzY5OGNiZTMxMTkyMmEzOTk1MjM2 ZGRhOTYwYjRjZGZmNDllMzZmJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURq bjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT00QjhpM08yUTZiNk5m WmRNSUZkc0IwU2xyY21ENTBUYzI0VUZvNHhDR2lZJnM9UjAtanVlV2dhdFQ1V0RrZFlRaV9KVlpG YWNneS1jQUFBNFAydW9zdDNqdyZlPT4NCj4+DQo+Pg0KDQoNCg0KLS0NCkthenVobyBPa3UNCg== --_000_B29C670C21EC412B967516164812F014fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <4AEC4D6AD602A04197B6DFA8A87760F5@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWFuZ2FsOw0K CXBhbm9zZS0xOjIgNCA1IDMgNSAyIDMgMyAyIDI7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlh biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206 MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmdtYWls LW0tMzM4OTA3MjEyNzQzMzc0OTQyM21zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0tMzM4OTA3 MjEyNzQzMzc0OTQyM21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tLTMzODkwNzIxMjc0MzM3 NDk0MjNtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTMzODkwNzIx Mjc0MzM3NDk0MjNtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KcC5nbWFpbC1tLTMzODkwNzIxMjc0MzM3NDk0MjNnbWFpbC1tOTE3NTMyNTcz MDU1NjU2ODQ0MG1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0tMzM4OTA3MjEyNzQzMzc0OTQy M2dtYWlsLW05MTc1MzI1NzMwNTU2NTY4NDQwbXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0t MzM4OTA3MjEyNzQzMzc0OTQyM2dtYWlsLW05MTc1MzI1NzMwNTU2NTY4NDQwbXNvbGlzdHBhcmFn cmFwaA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy0zMzg5MDcyMTI3NDMzNzQ5NDIzZ21haWwt bTkxNzUzMjU3MzA1NTY1Njg0NDBtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjUzNjU0NTYyNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg3MzMwMTky Njt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjc4MDk1MjQxNTsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6Mjc5MjI4ODE2O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3Qt aWQ6ODEwMzcwODYyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzYxNzg2OTA7fQ0KQGxpc3Qg bDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxMjg3NTQzODU5Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0OTUwOTU0OTYgNjc2OTg3MDUgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwz OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGw0 DQoJe21zby1saXN0LWlkOjE5MzY0MDQyNDM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0yOTM1NzQzMTYgMjk1OTc1OTgwIDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NDsNCgltc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw0 OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDUNCgl7bXNvLWxp c3QtaWQ6MTk2NjQyMjQ0NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTU4MzIxNTQ0ODt9DQpA bGlzdCBsNTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw2DQoJe21zby1saXN0LWlkOjIwMjgwMjAxODM7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjY2MzE0NTI4NiA1Mzc1NTEwNTQgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDY6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0Ow0K CW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw2OmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2 OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw2OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDY6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs NjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlR3byBwb2ludHM6PG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzciPkEgcG9vcmx5IGlt cGxlbWVudGVkIGNsaWVudCBjYW4gbGVhayBDSURzIGFsb25nIG90aGVyIHBhdGhzIOKAnGludGVu dGlvbmFsbHnigJ0uIFByb3ZpZGluZyBhIGRpcmVjdCBzaWduYWwgb24gdGhpcyBpcyBsaWtlbHkg dG8gcmFpc2UgYXdhcmVuZXNzLiBUaGF0IHNhaWQsIEkgZG9u4oCZdCBtdWNoIGNhcmUgYmVjYXVz ZTo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm83Ij5JcyB0aGlzIHJlYWxseSBpbXBv cnRhbnQ/IFdpbGwgdGhlIHByb3RvY29sIGZhaWwgb3VyIHVzZXJzIGluIHNvbWUgaW50ZXJlc3Rp bmcgd2F5IHdpdGhvdXQgY2hhbmdpbmcgdGhpcz8NCjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tPVI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMg Jmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mICZxdW90O0x1YmFzaGV2 LCBJZ29yJnF1b3Q7ICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UdWVzZGF5LCBGZWJydWFyeSA1LCAyMDE5IGF0IDM6MTMgUE08YnI+DQo8Yj5UbzogPC9iPlRl ZCBIYXJkaWUgJmx0O3RlZC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPkphbmEg SXllbmdhciAmbHQ7anJpLmlldGZAZ21haWwuY29tJmd0OywgTWlrZSBCaXNob3AgJmx0O21iaXNo b3BAZXZlcXVlZm91LmJlJmd0OywgRGF2aWQgU2NoaW5hemkgJmx0O2RzY2hpbmF6aS5pZXRmQGdt YWlsLmNvbSZndDssICZxdW90O3F1aWNAaWV0Zi5vcmcmcXVvdDsgJmx0O3F1aWNAaWV0Zi5vcmcm Z3Q7LCBNYXJ0aW4gVGhvbXNvbiAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7LCBLYXp1aG8gT2t1 ICZsdDtrYXp1aG9va3VAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogTmV3 IHBhdGggPSZndDsgbmV3IGNvbm5lY3Rpb24gSUQsIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsNCBsZXZlbDEgbGZvMSI+SSBkaXNhZ3JlZSB0aGF0IHRoZXNlIGFyZSB0aGUgc2FtZTxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVyc3Rvb2QgdGhlIHF1ZXN0aW9uIHRvIGJl IGFib3V0IHJvdXRpbmcgcGFja2V0cyBmcm9tIGEgbmV3IElQIGFkZHJlc3MgdG8gdGhlIG9yaWdp bmFsIGJhY2tlbmQuJm5ic3A7IFRoZSBtaWdyYXRpb24gb2YgdGhlIHRldGhlcmluZyBkZXZpY2Ug aXMgdGhlIHNhbWUgYXMgdGhlIG1pZ3JhdGlvbiBvZiB0aGUgY2xpZW50DQo8aT5mcm9tIHRoZSBy b3V0aW5nIHBlcnNwZWN0aXZlPC9pPiB3aXRoaW4gdGhlIGRlc3RpbmF0aW9uIG5ldHdvcmsgKHdo aWNoIG1heSBiZSBjb21wcmlzZWQgb2YgbXVsdGlwbGUgYW55Y2FzdCBwb3BzKS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzEiPlRo YXQgbWVhbnMgdGhhdCB0aGVyZSBpcyBubyB3YXkgdG8gdHJ1bHkgcHJldmVudCBDSUQgbWlncmF0 aW9uIGhlcmUgd2l0aGluIFFVSUMsJm5ic3A7IG9ubHkgdG8gbGltaXQgdGhlIHRpbWUgaXQgaXMg aW4gcGxhY2UuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwdXJwb3NlIG9mIHRo aXMg4oCcTVVTVCB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb27igJ0gcHJvcG9zYWwgd2FzIHRvIGlt cHJvdmUgcHJpdmFjeS4gVGhlcmUgaXMgbGl0dGxlIHRvIGJlIGdhaW5lZCBieSBjdXR0aW5nIG9m ZiB0aGUgY29ubmVjdGlvbiwgb25jZSBldmVuIGEgc2luZ2xlIHBhY2tldCBoYXMgZXhwb3NlZCB0 aGUgb3JpZ2luYWwgQ0lEIHRvIHRoZSBuZXcgcGF0aC4mbmJzcDsgSXTigJlzIG5vdCBsaWtlIG11 bHRpcGxlDQogcGFja2V0cyBwcm92aWRlIGEgc3Ryb25nZXIgbGlua2FiaWxpdHkgc2lnbmFsIHRo YW4gYSBqdXN0IG9uZSBwYWNrZXQuJm5ic3A7IFdlIG1heSB3aXNoIHRvIOKAnHB1bmlzaOKAnSBi dWdneSBpbXBsZW1lbnRhdGlvbnMgdG8gaW5kdWNlIHRoZWlyIHZlbmRvcnMgdG8gZG8gYmV0dGVy LCBidXQgdGhlIGNsaWVudCBpbXBsZW1lbnRhdGlvbiBjYW5ub3QgZG8gYW55IGJldHRlciBpbiB0 aGlzIGNhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0 Omw0IGxldmVsMSBsZm8xIj5UaGUgb25seSBvdGhlciBvcHRpb24gSSBzZWUgb2ZmaGFuZCB3b3Vs ZCBiZSB0byBzdWdnZXN0IHRoYXQgdGhlIGNvbm5lY3RlZCBmb3J3YXJkZXIgdGVybWluYXRlIHRo ZSBsaW5rcyB0byBpbmR1Y2Ugc29tZXRoaW5nIGxpa2UgYSBESENQUkVMRUFTRSBhbmQgUkVORVcs IGJ1dCB0aGlzIHNlZW1zIHNsb3csJm5ic3A7IGZyYWdpbGUsDQogYW5kIHVubGlrZWx5IHRvIGRl cGxveS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQuJm5ic3A7IFRoaXMgbmV0 d29yayBhdHRhY2htZW50IGNoYW5nZSBub3RpZmljYXRpb24gd291bGQgYmUgYSBzdWJqZWN0IHRv IGEgZGlmZmVyZW50IGRyYWZ0IGluIGEgZGlmZmVyZW50IFdHLCBhbmQgaXRzIGRlcGxveW1lbnQg d291bGQgYmUgc2xvdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDYgbGV2ZWwxIGxmbzIiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBUZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBGZWJydWFyeSAwNSwgMjAxOSA1OjQxIFBNPGJyPg0KPGI+VG86PC9iPiBMdWJh c2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEph bmEgSXllbmdhciAmbHQ7anJpLmlldGZAZ21haWwuY29tJmd0OzsgRGF2aWQgU2NoaW5hemkgJmx0 O2RzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc7IE1pa2UgQmlzaG9w ICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttdEBsb3dl bnRyb3B5Lm5ldCZndDs7IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBOZXcgcGF0aCA9Jmd0OyBuZXcgY29ubmVjdGlvbiBJRCwg cmlnaHQ/PGJyPg0KPGI+SW1wb3J0YW5jZTo8L2I+IEhpZ2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgNSwgMjAxOSBhdCAx OjMzIFBNIEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFp LmNvbSI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21haWwt bS0zMzg5MDcyMTI3NDMzNzQ5NDIzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0Omww IGxldmVsMSBsZm8zIj4NCkJ1dCBpZiB0aGUgcGhvbmUvaG90c3BvdCdzIElQIGFkZHJlc3MgY2hh bmdlcyBkdXJpbmcgdGhpcyBmcm9tIG9uZSBwcm92aWRlcidzIHNldCBvZiBhZGRyZXNzZXMgdG8g YW5vdGhlciwgdGhpcyBpcyBmdW5jdGlvbmFsbHkgcmUtaG9taW5nLiZuYnNwOyBJbiB0aGF0IGNh c2UsIGlzbid0IHRoZXJlIGFscmVhZHkgYSBoaWdoIHJpc2sgdGhhdCB0aGUgdHJhZmZpYyB3aWxs IGVuZCB1cCBhdCBhIGRpZmZlcmVudCBiYWNrIGVuZCBiZWNhdXNlIG9mIHRoZSBJUA0KIGNoYW5n ZT88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcywgdGhpcyBpcyB0aGUgc2Nl bmFyaW8g4oCTIHRoZSBwaG9uZSAob3IgeW91ciBjYXLigJlzIHVwbGluaywgaWYgY29ubmVjdGVk IHRvIGFuIGluLWNhciB3aWZpKSBoYXMgc3dpdGNoZWQgdG8gYSBkaWZmZXJlbnQgcHJvdmlkZXIu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGlzIG5vIGRpZmZlcmVudCB0aGFuIGEg dXN1YWwgY2VsbCZsdDstJmd0O3dpZmkgbWlncmF0aW9uIGNhc2UgZnJvbSB0aGUgcm91dGluZyBw ZXJzcGVjdGl2ZSwgYW5kIHRoZSBwdXJwb3NlIG9mIHNlcnZlci1nZW5lcmF0ZWQgY29ubmVjdGlv biBJRCBvbiBjbGllbnQtdG8tc2VydmVyIHBhY2tldHMgaXMgdG8gZmFjaWxpdGF0ZQ0KIHJvdXRp bmcgdG8gdGhlIGNvcnJlY3QgYmFja2VuZC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBk aXNhZ3JlZSB0aGF0IHRoZXNlIGFyZSB0aGUgc2FtZS4mbmJzcDsgSW4gdGhlIGNvbW1vbiBjYXNl IGZvciBjZWxsJmx0Oy0tJmd0O3dpZmkgbWlncmF0aW9uIHRoZSBjb25uZWN0ZWQgZGV2aWNlIGlz IGF3YXJlIG9mIHRoZSBpbnRlcmZhY2UgY2hhbmdlLiZuYnNwOyBCZWNhdXNlIHRoZSBjb25uZWN0 ZWQgZGV2aWNlIGlzIG5vdyBzZXJ2aW5nIGFzIGEgZm9yd2FyZGVyIGZvciB0aGUgcGFja2V0cyBv ZiBvdGhlcnMsIHRoZSB0ZXRoZXJlZA0KIGRldmljZSBjYW5ub3QgZGV0ZWN0IHRoZSBzb3J0IG9m IGludGVyZmFjZSBjaGFuZ2UuJm5ic3A7IEl0J3MgYSBwYXRoIGNoYW5nZSB0byB0aGUgdGV0aGVy ZWQgZGV2aWNlLCBub3QgYW4gaW50ZXJmYWNlIGNoYW5nZS4mbmJzcDsgQ2hyaXN0aWFuIGhhcyBw b2ludGVkIG91dCBhIHdheSB0byB1c2UgdjYgUkEgdG8gaW5kaWNhdGUgdGhhdCByZWhvbWluZyBo YXMgb2NjdXJyZWQgYW5kIHRvIHNpZ25hbCB0aGF0IHRvIHRoZSB0ZXRoZXJlZCBkZXZpY2UuJm5i c3A7IFRoaXMgaXNuJ3QNCiBhcyBzdHJhaWdodGZvcndhcmQgaW4gYSB2NCBOQVQgc2l0dWF0aW9u LCB1bmZvcnR1bmF0ZWx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkZvciBleGFtcGxlLCBpZiB0aGUgcGFja2V0IGFycml2ZXMgYXQgYSBk aWZmZXJlbnQgYW55Y2FzdCBwb3AsIHRoZSBpZGVudGlmeSBvZiB0aGUgb3JpZ2luYWwgcG9wIGlz IGVuY29kZWQgaW4gdGhlIGNvbm5lY3Rpb24gSUQsIGFuZCB0aGUgcGFja2V0IGNhbiBiZSB0dW5u ZWxlZCB0byB0aGF0IHBvcCAob3IgZGlyZWN0bHkNCiB0byB0aGUgY29ycmVjdCBiYWNrZW5kIHdp dGhpbiB0aGUgc2FtZSBvciBhIGRpZmZlcmVudCBwb3ApLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgd2lsbCBzdGlsbCB3b3JrIGlmIGl0IHVzZXMgYSBwcmV2aW91cyBhc3NpZ25lZCBidXQgdW51 c2VkIENJRCwgaWYgaXQgaGFzIGRldGVjdGVkIG1pZ3JhdGlvbi4mbmJzcDsNCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgSSB0aGluayB0 aGF0J3MgdGhlIGtleSBpc3N1ZSBoZXJlOyB0aGUgdGV0aGVyZWQgZGV2aWNlIGhhcyBubyB3YXkg dG8gZGV0ZWN0IG1pZ3JhdGlvbiwgYW5kIHNvIG5vIGxvY2FsIHRyaWdnZXIgZm9yIGEgQ0lEIGNo YW5nZS4mbmJzcDsgVGhhdCBtZWFucyB0aGF0IHRoZXJlIGlzIG5vIHdheSB0byB0cnVseSBwcmV2 ZW50IENJRCBtaWdyYXRpb24gaGVyZSB3aXRoaW4gUVVJQywmbmJzcDsgb25seSB0byBsaW1pdCB0 aGUgdGltZQ0KIGl0IGlzIGluIHBsYWNlLiZuYnNwOyBIYXZpbmcgdGhlIHNlcnZlciB0ZXJtaW5h dGUgYW5kIGZpcmluZyBvZmYgMC1SVFQgaXMgb25lIHdheSB0byBsaW1pdCB0aGF0IHRpbWluZywg YnV0IHdlIGhhdmUgdG8gYWNrbm93bGVkZ2UgdGhhdCBpdCBpcyBhdCBiZXN0IGEgbWl0aWdhdGlv bi4mbmJzcDsgVGhlIG9ubHkgb3RoZXIgb3B0aW9uIEkgc2VlIG9mZmhhbmQgd291bGQgYmUgdG8g c3VnZ2VzdCB0aGF0IHRoZSBjb25uZWN0ZWQgZm9yd2FyZGVyIHRlcm1pbmF0ZSB0aGUNCiBsaW5r cyB0byBpbmR1Y2Ugc29tZXRoaW5nIGxpa2UgYSBESENQUkVMRUFTRSBhbmQgUkVORVcsIGJ1dCB0 aGlzIHNlZW1zIHNsb3csJm5ic3A7IGZyYWdpbGUsIGFuZCB1bmxpa2VseSB0byBkZXBsb3kuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21h aWwtbS0zMzg5MDcyMTI3NDMzNzQ5NDIzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0 Omw1IGxldmVsMSBsZm80Ij4NCklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9y IGJsdWUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpj dXJyZW50Y29sb3IgY3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJv bTo8L2I+IFRlZCBIYXJkaWUgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE5IDI6MjggUE08YnI+DQo8Yj5Ubzo8L2I+ IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpLmlldGZAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+anJpLmlldGZAZ21haWwuY29tPC9hPiZndDs7IERhdmlkIFNjaGluYXpp ICZsdDs8YSBocmVmPSJtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZHNjaGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+OyBNaWtlIEJp c2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9i bGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OzsgTWFydGluIFRob21zb24gJmx0Ozxh IGhyZWY9Im1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm10QGxvd2Vu dHJvcHkubmV0PC9hPiZndDs7IEthenVobw0KIE9rdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVo b29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwuY29tPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE5ldyBwYXRoID0mZ3Q7IG5ldyBjb25uZWN0aW9u IElELCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkhpIElnb3IsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUgYSBjbGFyaWZ5aW5nIHF1ZXN0aW9uIG9uIHRo ZSBzY2VuYXJpbyBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBUdWUsIEZlYiA1LCAyMDE5IGF0IDEwOjI4IEFNIEx1YmFzaGV2LCBJZ29y ICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRv d3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3Jk ZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwy MDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21h aWwtbS0zMzg5MDcyMTI3NDMzNzQ5NDIzZ21haWwtbTkxNzUzMjU3MzA1NTY1Njg0NDBtc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzUiPg0KRWdyZWdpb3VzIGNo YW5nZXMgaW4gSVAgbWlnaHQgYmUgYSBzaWduYXR1cmUgZm9yIG5ldHdvcmsgY2hhbmdlIChjaGFu Z2UgaW4gLzE2IGFkZHJlc3MsIGZvciBpbnN0YW5jZSkgYW5kIGEgc2VydmVyIGNvdWxkIHRlcm1p bmF0ZSB0aGUgY29ubmVjdGlvbiBhbmQgcmVzcG9uZCB3aXRoIGEgc3RhdGVsZXNzIHJlc2V0IGlm IHRoaXMgaGFwcGVucy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBjbGll bnQgY291bGQgYmUgYSBsYXB0b3AgdGhhdCBpcyB0ZXRoZXJlZCB2aWEgYSBwaG9uZSB0aGF0IGlz IGNoYW5naW5nIHByb3ZpZGVycy4mbmJzcDsgVGhlIGRpc2Nvbm5lY3Qgd291bGQgYmUgY29tcGxl dGVseSDigJxwdW5pdGl2ZeKAnSAodGhlIG9sZCBwYXRo4oCZcyBDSUQgaGFzIGFscmVhZHkgYmVl biBzZW50IG92ZXINCiB0aGUgbmV3IHBhdGgpIGFuZCBiZSBwdW5pc2hpbmcgdGhlIGNsaWVudCBm b3Igc29tZXRoaW5nIGl0IGhhZCBubyBjb250cm9sIG92ZXIgd2hhdHNvZXZlci48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkluIHRoaXMgc2NlbmFyaW8sIHdoYXQgaXMgeW91ciB2aWV3IG9mIHdoZXJlIHRoZSBJUCBh ZGRyZXNzIGNoYW5nZXMgYXJlIHRha2luZyBwbGFjZT8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhZ3JlZSB0aGF0IHRoZSBkZXZp Y2UgY29ubmVjdGVkIHRvIGEgcGhvbmUgKGUuZy4gYnkgYSBtb2JpbGUgaG90c3BvdCkgd2lsbCBu b3QgZ2VuZXJhbGx5IGhhdmUgYSB2aWV3IG9mIHRoZSBjaGFuZ2UgaW4gdXBzdHJlYW0gcGF0aC4m bmJzcDsgSWYgdGhhdCBwaG9uZSBpcyB1c2luZyBzb21ldGhpbmcgbGlrZSBtb2JpbGUNCiBJUCBv ciBhIFZQTiB0byBoYXZlIGEgY29uc2lzdGVudCBleHRlcm5hbCBhZGRyZXNzLCB0aGVuIEkgYWxz byBkb24ndCBzZWUgd2h5IHRoaXMgcGF0aCBjaGFuZ2Ugd291bGQgdHJpZ2dlciBhbnkgY2hhbmdl IGluIENJRC4mbmJzcDsgQnV0IGlmIHRoZSBwaG9uZS9ob3RzcG90J3MgSVAgYWRkcmVzcyBjaGFu Z2VzIGR1cmluZyB0aGlzIGZyb20gb25lIHByb3ZpZGVyJ3Mgc2V0IG9mIGFkZHJlc3NlcyB0byBh bm90aGVyLCB0aGlzIGlzIGZ1bmN0aW9uYWxseQ0KIHJlLWhvbWluZy4mbmJzcDsgSW4gdGhhdCBj YXNlLCBpc24ndCB0aGVyZSBhbHJlYWR5IGEgaGlnaCByaXNrIHRoYXQgdGhlIHRyYWZmaWMgd2ls bCBlbmQgdXAgYXQgYSBkaWZmZXJlbnQgYmFjayBlbmQgYmVjYXVzZSBvZiB0aGUgSVAgY2hhbmdl PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+VGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMgb24gdGhpcyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRlZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJy ZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iZ21haWwtbS0zMzg5MDcyMTI3NDMzNzQ5NDIzZ21haWwtbTkxNzUzMjU3 MzA1NTY1Njg0NDBtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzYiPg0KSWdvcjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXIt Y29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBKYW5hIEl5ZW5nYXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmkuaWV0 ZkBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5 IDA1LCAyMDE5IDY6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IERhdmlkIFNjaGluYXppICZsdDs8YSBo cmVmPSJtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHNj aGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT47IE1p a2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdl dD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm10QGxvd2VudHJvcHkubmV0IiB0YXJnZXQ9Il9ibGFuayI+bXRA bG93ZW50cm9weS5uZXQ8L2E+Jmd0OzsNCiBLYXp1aG8gT2t1ICZsdDs8YSBocmVmPSJtYWlsdG86 a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTmV3IHBhdGggPSZndDsgbmV3IGNvbm5l Y3Rpb24gSUQsIHJpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JIGFncmVlIHRoYXQgd2FudCB0byBoYXZlIE1VU1QgZm9yIGNoYW5naW5nIENJ RCBhbmQgTVVTVCBOT1QgZm9yIHNlbmRpbmcgcGFja2V0cyB3aXRoIHRoZSBzYW1lIENJRCBvbiBt dWx0aXBsZSBwYXRocy4mbmJzcDsgSSB0aG91Z2h0IHdlIGhhZCBhZ3JlZWQgb24gdGhpcyBpbiB0 aGUgcGFzdCwgYnV0IEkgY291bGQgYmUNCiBtaXNyZW1lbWJlcmluZy48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHVuZGVyc3RhbmQgdGhhdCB0aGUg c2VydmVyIGNhbm5vdCBuZWNlc3NhcmlseSB0ZWxsIHRoaXMgZnJvbSBOQVQgcmViaW5kaW5nLCBi dXQgaXQgaXMgdXAgdG8gdGhlIHNlcnZlciB3aGF0IGl0IGRvZXMgaWYgaXQgc2VlcyBhbiBJUC9w b3J0IGNoYW5nZSB3aXRoIG5vIGFjY29tcGFueWluZyBDSUQgY2hhbmdlLiZuYnNwOw0KIEVncmVn aW91cyBjaGFuZ2VzIGluIElQIG1pZ2h0IGJlIGEgc2lnbmF0dXJlIGZvciBuZXR3b3JrIGNoYW5n ZSAoY2hhbmdlIGluIC8xNiBhZGRyZXNzLCBmb3IgaW5zdGFuY2UpIGFuZCBhIHNlcnZlciBjb3Vs ZCB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24gYW5kIHJlc3BvbmQgd2l0aCBhIHN0YXRlbGVzcyBy ZXNldCBpZiB0aGlzIGhhcHBlbnMuJm5ic3A7IEEgY2xpZW50IHRoYXQgaWdub3JlcyB0aGUgTVVT VCBhbmQgdXNlcyB0aGUgc2FtZSBDSUQgYWNyb3NzDQogbmV0d29ya3Mgd291bGQgdGhlbiByaXNr IGdldHRpbmcgdGhlIGNvbm5lY3Rpb24gdGVybWluYXRlZC4mbmJzcDsgSSBzdWdnZXN0IHRoYXQg d2UgYWRkIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCBwb3RlbnRpYWwgc2VydmVyIHJlc3BvbnNlcyB0 byBjbGllbnRzIHRoYXQgdmlvbGF0ZSBub3JtYXRpdmUgZXhwZWN0YXRpb25zLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBG ZWIgNSwgMjAxOSBhdCA4OjEzIEFNIERhdmlkIFNjaGluYXppICZsdDs8YSBocmVmPSJtYWlsdG86 ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHNjaGluYXppLmlldGZA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1 cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgdGhlIGVuZCBvZiB0aGUgZGF5LCB5b3Ug Y2FuIG1ha2UgaXQgYSBNVVNULCBidXQgY2xpZW50cyB3aWxsIGRvIHdoYXQgdGhleSBwbGVhc2Ug YmVjYXVzZSBzZXJ2ZXJzIGNhbid0IGVuZm9yY2UgaXQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5CdXQgSSB3b24ndCBkaWUgb24gdGhpcyBoaWxsLCBJIGNh biBsaXZlIHdpdGggYmVpbmcgZGVjbGFyZWQgaW4gdGhlIHJvdWdoIG9uIHRoaXMgb25lLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRhdmlkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIE1vbiwgRmViIDQsIDIwMTkgYXQgNTozNyBQTSBLYXp1aG8gT2t1ICZsdDs8YSBocmVm PSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3Vy cmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwMTk8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5bm0PC9zcGFuPjI8c3BhbiBsYW5nPSJaSC1D TiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPjU8 c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 OyI+5pelPC9zcGFuPig8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O01TIEdvdGhpYyZxdW90OyI+54GrPC9zcGFuPikNCiAxMDowOCBEYXZpZCBTY2hpbmF6aSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IElm IGFuIGVuZHBvaW50IGludGVudGlvbmFsbHkgbWlncmF0ZXMgYW5kIGl0IGhhcyB1bnVzZWQgY29u bmVjdGlvbiBJRHMgdG8gdXNlLCBpdCBtYWtlcyBzZW5zZSB0byBtYW5kYXRlIGl0IE1VU1Qgc3dp dGNoIHRvIG9uZSBvZiB0aGUgdW51c2VkIGNvbm5lY3Rpb24gSURzLjxicj4NCiZndDsgSG93ZXZl ciwgaWYgaXQgaGFzIHJ1biBvdXQgb2YgdW51c2VkIGNvbm5lY3Rpb24gSURzIHRoZW4gSSB3b3Vs ZCBsZXQgdGhlIGVuZHBvaW50IGRlY2lkZSBpZiBpdCB3YW50cyB0byBjbG9zZSB0aGUgY29ubmVj dGlvbiBvciBtaWdyYXRlIHdpdGggYSBwcmV2aW91c2x5IHVzZWQgY29ubmVjdGlvbiBJRHMsIGFz IHRoZXJlIGFyZSB1c2UtY2FzZXMgdGhhdCB2YWx1ZSBwZXJmb3JtYW5jZSBvdmVyIG5vbi1saW5r YWJpbGl0eS48YnI+DQo8YnI+DQpJIHRoaW5rIEkgbWlnaHQgcHJlZmVyIGVuY291cmFnaW5nIGVu ZHBvaW50cyB0byBncmFjZWZ1bGx5IGNsb3NlIHRoZTxicj4NCmNvbm5lY3Rpb24gYmVmb3JlIGl0 IGZhY2VzIGEgdHJhZGUtb2ZmIGJldHdlZW4gcGVyZm9ybWFuY2UgYW5kPGJyPg0KbGlua2FiaWxp dHkuPGJyPg0KPGJyPg0KVGhlcmVmb3JlLCBhc3N1bWluZyB0aGF0IHdlIGFkb3B0IE1hcnRpbidz IHByb3Bvc2FsLCBJIHRoaW5rIGl0IHdvdWxkPGJyPg0KbWFrZSBzZW5zZSB0byByZWNvbW1lbmQg YW4gZW5kcG9pbnQgdG8gc2VuZCBHT0FXQVkgd2hlbiBpZiBpdCBjYW4gbm88YnI+DQpsb25nZXIg aXNzdWUgYSBuZXcgQ0lEIGZvciB0aGF0IFFVSUMgY29ubmVjdGlvbi48YnI+DQo8YnI+DQomZ3Q7 IEZpbmFsbHksIHRoaXMgY2Fubm90IGJlIGVuZm9yY2VkIGJ5IHRoZSBwZWVyIHNpbmNlIGl0IGNh bm5vdCBkaXN0aW5ndWlzaCBpbnRlbnRpb25hbCBtaWdyYXRpb24gYW5kIHVuaW50ZW50aW9uYWwg bWlncmF0aW9uIChOQVQgcmViaW5kaW5nKSwgYW5kIHdlIGRpc2N1c3NlZCBpbiBUb2t5byB0aGF0 IHdlIHdhbnRlZCB0byBhdm9pZCBub24tZW5mb3JjZWFibGUgTVVTVHMuPGJyPg0KJmd0Ozxicj4N CiZndDsgRGF2aWQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBNb24sIEZlYiA0LCAyMDE5IGF0IDQ6 NTYgUE0gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5i ZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDsgd3JvdGU6PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgdGV4dCBpcyB0aGVyZSwgYnV0IGl0J3MgcGVy aGFwcyBub3QgY29tcGxldGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBcyBkaXNjdXNz ZWQgaW4gU2VjdGlvbiA5LjUsIGVhY2ggY29ubmVjdGlvbiBJRCBNVVNUIGJlIHVzZWQgb24gcGFj a2V0cyBzZW50IGZyb20gb25seSBvbmUgbG9jYWwgYWRkcmVzcy4gQW4gZW5kcG9pbnQgdGhhdCBt aWdyYXRlcyBhd2F5IGZyb20gYSBsb2NhbCBhZGRyZXNzIFNIT1VMRCByZXRpcmUgYWxsIGNvbm5l Y3Rpb24gSURzIHVzZWQgb24gdGhhdCBhZGRyZXNzIG9uY2UgaXQgbm8gbG9uZ2VyIHBsYW5zIHRv IHVzZSB0aGF0IGFkZHJlc3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgVGhlIGdhcCBzZWVtcyB0byBiZSB0aGF0IHdoZW4geW91ciBwZWVy IG1vdmVzIHRvIGEgbmV3IGFkZHJlc3MsIHRoZXJl4oCZcyBubyByZXF1aXJlbWVudCB0aGF0IHlv dSBub3Qgc2VuZCB0aGUgc2FtZSBDSUQgdG8gdGhlaXIgbmV3IGFkZHJlc3MgdGhhdCB5b3UgdXNl ZCB0b3dhcmQgdGhlaXIgb2xkIGFkZHJlc3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQomZ3Q7Jmd0OyBGcm9tOiBRVUlDICZsdDs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24g QmVoYWxmIE9mIE1hcnRpbiBUaG9tc29uPGJyPg0KJmd0OyZndDsgU2VudDogTW9uZGF5LCBGZWJy dWFyeSA0LCAyMDE5IDM6MTUgUE08YnI+DQomZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOnF1 aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPjxicj4NCiZndDsm Z3Q7IFN1YmplY3Q6IE5ldyBwYXRoID0mZ3Q7IG5ldyBjb25uZWN0aW9uIElELCByaWdodD88YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHRo b3VnaHQgdGhhdCB3ZSBoYWQgYWdyZWVkIHRoYXQgYW4gZW5kcG9pbnQgdGhhdCBpbnRlbnRpb25h bGx5IG1pZ3JhdGVzIGhhcyB0byB1c2UgYSBuZXcgY29ubmVjdGlvbiBJRCBvbiB0aGUgbmV3IHBh dGguJm5ic3A7IEJ1dCBJIGNvdWxkbid0IGZpbmQgYW55ICZxdW90O01VU1QmcXVvdDsgaW4gdGhl IHNwZWMgdGhhdCBzYWlkIHRoYXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gdGhlIG9mZiBjaGFuY2UgdGhhdCB0aGlzIHdhc24ndCBq dXN0IGEgbWlzdGFrZSBhbmQgdGhlcmUgd2FzIHNvbWUgZ29vZCByZWFzb24gbm90IHRvIG1hbmRh dGUgdGhpcywgSSdtIGJyaW5naW5nIHRoZSBkaXNjdXNzaW9uIGhlcmUuPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSd2ZSBvcGVuZWQgYSBk ZXNpZ24gaXNzdWU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21f cXVpY3dnX2Jhc2UtMkRkcmFmdHNfaXNzdWVzXzI0MTMmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJa WmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpk bl9tNTVLUG1sbyZhbXA7bT00QjhpM08yUTZiNk5mWmRNSUZkc0IwU2xyY21ENTBUYzI0VUZvNHhD R2lZJmFtcDtzPTVscjhjemlaZlgyQTlCV0QzTDhadjhpMVIzenlKWUNpenF2QmpjT211eXMmYW1w O2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJh ZnRzL2lzc3Vlcy8yNDEzPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBjaGFuZ2UgSSdtIHByb3Bvc2luZyBpcyBoZXJlOjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJh ZnRzX3B1bGxfMjQxNF9jb21taXRzXzEzNjk4Y2JlMzExOTIyYTM5OTUyMzZkZGE5NjBiNGNkZmY0 OWUzNmYmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpu M2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT00QjhpM08yUTZi Nk5mWmRNSUZkc0IwU2xyY21ENTBUYzI0VUZvNHhDR2lZJmFtcDtzPVIwLWp1ZVdnYXRUNVdEa2RZ UWlfSlZaRmFjZ3ktY0FBQTRQMnVvc3QzancmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjQxNC9jb21taXRzLzEzNjk4 Y2JlMzExOTIyYTM5OTUyMzZkZGE5NjBiNGNkZmY0OWUzNmY8L2E+PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCkthenVobyBPa3U8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B29C670C21EC412B967516164812F014fbcom_-- From nobody Tue Feb 5 20:11:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1E8123FFD for ; Tue, 5 Feb 2019 20:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=pCEnkwI4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IRCATB2p 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 GppIRgXrFZXT for ; Tue, 5 Feb 2019 20:11:53 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2B0126C7E for ; Tue, 5 Feb 2019 20:11:53 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 31C8422238 for ; Tue, 5 Feb 2019 23:11:52 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Tue, 05 Feb 2019 23:11:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:date:subject; s=fm1; bh=5p9S+0kSOiv7dZLngi1c873fXp G3CbTFrYUq1rtnmQw=; b=pCEnkwI4CnHoByzcHap2KrMnFmPjeN8H6yHWbfxSfG 3dTefCMHAG3Ru/dhIwUsf+ZHiOI8aq0K7520s5Dci9FDmXG82+GBixkiFpN6sfB9 CVATt19QDoI2WwSX9lWP0SO+T92myyRnTVz0QMlSOE8tIXqa0A5sN7SPSK/J/yHH 6MmQny9W8qr80K3owzPYnv0yKviu3nihgCpySx+02dbEmBtDbmC1ap+o5kSgQksa nnjSE3Q0dd3NQAyjlBbmSZ0eTZwxsQKfJS1FyCmZElze+/yAQM4tnrEqE6AGgxNN cr2AYBs+gl3uU6tCyM/7KSN3qTTH19NRDkuPjyYiXQDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=5p9S+0 kSOiv7dZLngi1c873fXpG3CbTFrYUq1rtnmQw=; b=IRCATB2ph9HoX3pGCf5B7j Ih4VrA4YsFvLrmuEkWN08nofgBlJ4Qj61B9PfM4cb/HnHt9Ssgjj0BsQc5vm2EO6 Oaw9VCmmCvhL7dhzvads2ofuKbTBgYcfJr5GM2aJbh8IZwrGxIAid3/I7V8vBfgD zloaF1RwQeIGr5ur+O1bPip1iLQI3gumXPJr+fm3TwcxPgmFofcS0rVasaXVZxOZ XU+wvbJ/ZIEXJKE4EYhO08zTZZwOgW+1vCiiQTkjeHWQPcUznpJGtyLioT79FcTC 4/Nsyp41bpf+nZrujJbkw88BqbdBuwugpg9gLuwzWbTEzxOb6NuncYWxH7FfRK1Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeejgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucgoteefjeefqddtgeculdehtddmnecujfgurhepkffhvfgggfgtofffufesthejre dtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8C4499E595; Tue, 5 Feb 2019 23:11:51 -0500 (EST) Message-Id: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ec01da05 Date: Wed, 06 Feb 2019 15:11:51 +1100 Subject: Allowed frames in 0-RTT Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 04:11:56 -0000 We had a rather unfruitful discussion about this subject in Tokyo, and it's one of the few things we didn't come to a conclusion on. I'd like to share my conclusion. Hopefully others agree. # Background Kazuho observed that prohibiting RESET_STREAM from 0-RTT made it awkward to cancel streams. In the ensuing discussion, we identified that there might be use cases for other frame types. https://github.com/quicwg/base-drafts/issues/2344 contains the full discussion. There's some good stuff there if you want to spend some more time reading. I apologize, but this is a difficult topic. It's a long thread but this email might be worse. # Risk Analysis 0-RTT comes with risks, primarily those arising from replay. But those risks are not borne by QUIC they depend on triggering actions in the application that uses QUIC. For instance, HTTP POST requests can have consequences that alter the state of resources and those consequences affect future connections. That is why we have RFC 8470, which describes these risks and mitigation strategies for HTTP. 0-RTT affects the state of a QUIC connection, but the effects don't extend beyond a connection unless the application protocol permits it. Thus, the consequences of replay on QUIC is limited to having more connections created. Any replayed actions will accumulate to those replayed connections. Ultimately however, only one of the connections will be completed. Some people in the discussion were unhappy about this situation. If they are not able to recognize replayed connection attempts using the techniques described in RFC 8446, then they would be obligated to process those connections. I don't see this as changing the overall assessment. When a server accepts a connection attempt, they have to expect to take on the state and processing costs of handling that connection. If that connection turns out to be bogus, then any expended effort is fruitless, but no more than that. Yes, the addition of 0-RTT changes the calculus slightly, because imperfect replay detection can be exploited to more cheaply induce server work related to frame processing. Allow N replays and you can get N times the work without having to redo the heavy crypto (i.e., mostly key exchange, but also packet protection). But that's a risk that servers need to integrate into their assessment about whether to accept 0-RTT. 0-RTT can be accepted only when servers have sufficient spare capacity to cover any costs from replay. There should be a hard upper bound on the number of replays that might be accepted by a server, no matter the size of your deployment, so the costs are finite. The specific concern raised was that the costs of processing overhead frames (flow control updates, PING, etc...) are not limited in any way. However, I would contend that those are cheap and represent a lower cost-per-byte to process than STREAM, and we're not about to ban sending of STREAM frames in 0-RTT. Any server should have defenses against clients that cause useless thrashing by sending pointless or wasteful frames (Section 10.5 of RFC 7540 goes into detail about this style of attack). The combination of that style of defense and limits on replays is sufficient in my view. # Choice of Principles What principle can we use to motivate a decision? It was suggested that we only enable frames for which we have an analysis that supports enabling it in 0-RTT. However, my analysis suggests that this is every frame that does not carry information for an application protocol (i.e., everything except STREAM, and maybe RESET_STREAM and STOP_SENDING). And we want to include frames for the application protocol or there is no point in doing 0-RTT at all. So I don't think that there is a usable principle in that line of reasoning. That leaves the that we find the set of things we know are needed and just enable those. The principle there being YAGNI. This seems like a fine principle. It seems like people were generally OK with STREAM and all related frames. The cost of doing that is that you have to treat 0-RTT specially. This is already somewhat necessary as a receiver, because there are rules about packet processing that apply. As a sender, this constrains behaviour in the same awkward ways that Kazuho originally identified. If you can't update flow control limits, you have to set any increases aside for sending once the handshake completes. It adds unnecessary complexity. So I would instead advocate for a different principle: it would be a mistake to try to make decisions about 0-RTT safety in the transport, when replay risks are an application-layer concern. If the application requests that the transport do something, then the application takes responsibility for any risk of replay. The transport is not constrained in how it operates in 0-RTT. The transport uses 0-RTT packets without regard to the risk of replay. That said, as Roberto is fond of saying, servers will do what they need to do. I have no doubt that all inputs will be subject to more scrutiny and caution before the handshake is complete. But that's on individual implementations, it's not a principled position any more than having to use IP address reputation to manage DoS is. This principle keeps the transport simple. The only affordance needed then is to ensure that the application is aware of when it is at risk of replay. The transport ensures that the application knows when data it sends might be replayed. Once a request is made by the application, the transport sends it. If it wants to send flow control updates, it can. So I think that the two candidates are: * YAGNI, with constraints * 0-RTT is an application concern # Affected Frames If you look at the list of frame types, the interesting thing is that the difference between these positions is in a very small subset of frames. Here's the complete list (including the upcoming, to-be-named KEYS_READY frame): 0x00 PADDING - already allowed 0x01 PING - in question, but harmless; sending a redundant STREAM frame would have the same effect 0x02 - 0x03 ACK - impossible 0x04 RESET_STREAM - the trigger for this mess; but we seem to want it 0x05 STOP_SENDING - more valuable than RESET_STREAM in many ways 0x06 CRYPTO - impossible 0x07 NEW_TOKEN - impossible 0x08 - 0x0f STREAM - very important, the most dangerous, and already allowed 0x10 MAX_DATA - seems useful 0x11 MAX_STREAM_DATA - seems useful 0x12 - 0x13 MAX_STREAMS - seems useful 0x14 DATA_BLOCKED - either redundant - because connection flow control is used to limit 0-RTT - or useful - because knowing when 0-RTT flow control limits are hit is useful information; this might depend on whether you think that the blocked signals are useful in general 0x15 STREAM_DATA_BLOCKED - marginally useful 0x16 - 0x17 STREAMS_BLOCKED - marginally useful 0x18 NEW_CONNECTION_ID - in question 0x19 RETIRE_CONNECTION_ID - impossible 0x1a PATH_CHALLENGE - in question 0x1b PATH_RESPONSE - impossible 0x1c - 0x1d CONNECTION_CLOSE - potentially useful 0x?? KEYS_READY - impossible You can see that many of these frames simply can't be sent. Mostly because they answer something that the server would send in 1-RTT, and the client can't respond in 0-RTT to 1-RTT packets (it has to use 1-RTT for that). We could explicitly prohibit those frames, but it is sufficient in my view to rely on the existing rules. We don't need to go through and piecemeal prohibit frames, though we could point out for each one the impossibility of it being in 0-RTT, it would be redundant to do so. For those that are genuinely in question: PING, NEW_CONNECTION_ID, and PATH_CHALLENGE, this might seem like a waste of time and effort to talk about, but we are talking about establishing guidelines on what can and cannot be sent in 0-RTT. We are deciding what factors need to be considered when new frames are defined. # Conclusion Assigning responsibility for replay defense to application protocols is the clearest principle we can apply. That is, the transport does not have any inherent opinion about replay risk. All frames are for the transport and none of them are specially privileged for use in 0-RTT. What an application protocol endpoint decides to do with the transport in 0-RTT is an application responsibility. An analysis of replay risks is always performed in the context of the application protocol. Based on this, my view is that it would be a mistake to go with YAGNI. Doing that signs us up for a whole bunch of difficult analysis for every frame, having to anticipate the many ways in which it might be abused by applications. Instead, I think that we should articulate the considerations that broadly apply and require that application protocols do the analysis. This is not just because I have a PR mostly ready (absent this last bit about considerations and application responsibility, which I plan to add soon). Though I have no desire to write up the piecemeal allow/deny stuff, I will if I have to, but it will only be because I'm in the rough. https://github.com/quicwg/base-drafts/pull/2355 From nobody Tue Feb 5 21:25:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE4126C7E for ; Tue, 5 Feb 2019 21:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sK_4v2cws4a for ; Tue, 5 Feb 2019 21:24:58 -0800 (PST) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 7B12E12426E for ; Tue, 5 Feb 2019 21:24:57 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id l142so4468976lfe.2 for ; Tue, 05 Feb 2019 21:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n6WimEnQTSp4z+0AAJOxQZ09zhJXWG98yHRTV1D7QF0=; b=u18SfZRv2JleCXsu13GEUL72Y0JGw3VZFic32Pwcy1WWfSIgJB+WXSR4lX3yINIm+W UYbKefc4QdJtgTy3Dns3NVBsTUX1x8DuTHx5FAf+FpXSfQD7JMljudGXBJ4fXKwTQkIO TjkeIvK+RovH1pi1GmJ7oI1bYkxa5BC7zgtopY1QE86YEAVm0OkEfIuILohhwwUnKx2Z ZP0a3UUt9A1gc9Cb8XluxeNDAUv/61u1GguetrcH0B1yINydEht2mIrL2SAl/SshD7eV QmDecMmc5sNJ3hpvl1/ozBSfr9OuWwZKo57vn0NjT08HX60g2zuLS0qNV0hYPmABojQV 0K3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n6WimEnQTSp4z+0AAJOxQZ09zhJXWG98yHRTV1D7QF0=; b=DQqZeJUsDIkBbwnX1Dfa6cD4BW4SVaXFa7sr+lbaA7vYLtS6jVMILqR5C2JlDG55fR 7/M9+v/tf+5RuKGdyqzhOoaF/uK4OYPUGDmFr+DYwRn0LFQx5V08EBNgTuonlYSPh6fa rtXytYkccBVW9RXPyA/XBwW7VtIE0liOav3OQE/XkmfEKl2fVU0tFonvnh5m1tbHEFAv QtxEPSbQ1NHANLouvDNHEEP9wiwvPQMKDaapahZqqLwO8B4j1tUN309ImR4cBck+Q8A3 vR89/KXbh6j0iVU9V841oJ3KbApP3C2efttBB0uROxofDRYYWoWgO4Zhhs+G6YVHXlwx 8vnQ== X-Gm-Message-State: AHQUAuacUn1IKzphoe35HFIijZnO585R/HRkCj/4X9py8w8zFbR0ZOtl qAQt9YwEHoAWCDXfAkhcst97LAJJ1SGl40U9rVuesA== X-Google-Smtp-Source: AHgI3IbpT83qz/ox7QXXGp0hJeeaRHUAgSMdX8LVs8pnmbzHOnLxvOqqDoJ8Va7z7U/Phy4NO9rYnAQNgtkOB7k1DFk= X-Received: by 2002:a19:7018:: with SMTP id h24mr5300277lfc.162.1549430695541; Tue, 05 Feb 2019 21:24:55 -0800 (PST) MIME-Version: 1.0 References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> In-Reply-To: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> From: Kazuho Oku Date: Wed, 6 Feb 2019 14:24:44 +0900 Message-ID: Subject: Re: Allowed frames in 0-RTT To: Martin Thomson Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 05:25:01 -0000 Martin, Thank you for the detailed analysis, and for starting the thread. My response inline. 2019=E5=B9=B42=E6=9C=886=E6=97=A5(=E6=B0=B4) 13:12 Martin Thomson : > > We had a rather unfruitful discussion about this subject in Tokyo, and it= 's one of the few things we didn't come to a conclusion on. I'd like to sh= are my conclusion. Hopefully others agree. > > # Background > > Kazuho observed that prohibiting RESET_STREAM from 0-RTT made it awkward = to cancel streams. In the ensuing discussion, we identified that there mig= ht be use cases for other frame types. > > https://github.com/quicwg/base-drafts/issues/2344 contains the full discu= ssion. There's some good stuff there if you want to spend some more time r= eading. I apologize, but this is a difficult topic. It's a long thread bu= t this email might be worse. > > # Risk Analysis > > 0-RTT comes with risks, primarily those arising from replay. But those r= isks are not borne by QUIC they depend on triggering actions in the applica= tion that uses QUIC. For instance, HTTP POST requests can have consequence= s that alter the state of resources and those consequences affect future co= nnections. That is why we have RFC 8470, which describes these risks and m= itigation strategies for HTTP. > > 0-RTT affects the state of a QUIC connection, but the effects don't exten= d beyond a connection unless the application protocol permits it. Thus, th= e consequences of replay on QUIC is limited to having more connections crea= ted. Any replayed actions will accumulate to those replayed connections. = Ultimately however, only one of the connections will be completed. > > Some people in the discussion were unhappy about this situation. If they= are not able to recognize replayed connection attempts using the technique= s described in RFC 8446, then they would be obligated to process those conn= ections. > > I don't see this as changing the overall assessment. When a server accep= ts a connection attempt, they have to expect to take on the state and proce= ssing costs of handling that connection. If that connection turns out to b= e bogus, then any expended effort is fruitless, but no more than that. > > Yes, the addition of 0-RTT changes the calculus slightly, because imperfe= ct replay detection can be exploited to more cheaply induce server work rel= ated to frame processing. Allow N replays and you can get N times the work= without having to redo the heavy crypto (i.e., mostly key exchange, but al= so packet protection). But that's a risk that servers need to integrate in= to their assessment about whether to accept 0-RTT. 0-RTT can be accepted o= nly when servers have sufficient spare capacity to cover any costs from rep= lay. There should be a hard upper bound on the number of replays that migh= t be accepted by a server, no matter the size of your deployment, so the co= sts are finite. > > The specific concern raised was that the costs of processing overhead fra= mes (flow control updates, PING, etc...) are not limited in any way. Howev= er, I would contend that those are cheap and represent a lower cost-per-byt= e to process than STREAM, and we're not about to ban sending of STREAM fram= es in 0-RTT. Any server should have defenses against clients that cause us= eless thrashing by sending pointless or wasteful frames (Section 10.5 of RF= C 7540 goes into detail about this style of attack). The combination of th= at style of defense and limits on replays is sufficient in my view. > > # Choice of Principles > > What principle can we use to motivate a decision? > > It was suggested that we only enable frames for which we have an analysis= that supports enabling it in 0-RTT. However, my analysis suggests that th= is is every frame that does not carry information for an application protoc= ol (i.e., everything except STREAM, and maybe RESET_STREAM and STOP_SENDING= ). And we want to include frames for the application protocol or there is = no point in doing 0-RTT at all. So I don't think that there is a usable pr= inciple in that line of reasoning. > > That leaves the that we find the set of things we know are needed and jus= t enable those. The principle there being YAGNI. This seems like a fine p= rinciple. It seems like people were generally OK with STREAM and all relat= ed frames. > > The cost of doing that is that you have to treat 0-RTT specially. This i= s already somewhat necessary as a receiver, because there are rules about p= acket processing that apply. As a sender, this constrains behaviour in the= same awkward ways that Kazuho originally identified. If you can't update = flow control limits, you have to set any increases aside for sending once t= he handshake completes. It adds unnecessary complexity. > > So I would instead advocate for a different principle: it would be a mist= ake to try to make decisions about 0-RTT safety in the transport, when repl= ay risks are an application-layer concern. > > If the application requests that the transport do something, then the app= lication takes responsibility for any risk of replay. The transport is not= constrained in how it operates in 0-RTT. The transport uses 0-RTT packets= without regard to the risk of replay. That said, as Roberto is fond of sa= ying, servers will do what they need to do. I have no doubt that all input= s will be subject to more scrutiny and caution before the handshake is comp= lete. But that's on individual implementations, it's not a principled posi= tion any more than having to use IP address reputation to manage DoS is. > > This principle keeps the transport simple. The only affordance needed th= en is to ensure that the application is aware of when it is at risk of repl= ay. The transport ensures that the application knows when data it sends mi= ght be replayed. Once a request is made by the application, the transport = sends it. If it wants to send flow control updates, it can. > > So I think that the two candidates are: > > * YAGNI, with constraints > * 0-RTT is an application concern I am not sure if I agree with the framing. I think we can agree that 0-RTT is a concern for both the application and the transport. For application, the precedence we have in TLS 1.3 is that each application protocol is required to create a profile specifying how 0-RTT data should be handled. My assumption is that we would be following that. With that in mind, I think we agree that all frames related to transmission of data (and streams) should be permitted. The question is what to do with the frame types that control the properties of the transport. We could either go with YAGNI, or allow them assuming that they do not pose a security concerns. > > # Affected Frames > > If you look at the list of frame types, the interesting thing is that the= difference between these positions is in a very small subset of frames. H= ere's the complete list (including the upcoming, to-be-named KEYS_READY fra= me): > > 0x00 PADDING - already allowed > 0x01 PING - in question, but harmless; sending a redundant STREAM fram= e would have the same effect Regarding PING, I think there's a broader discussion about if it the use should be limited to 1-RTT. If we are to continue forbidding use of PING in Initial and Handshake packets, I do not think that there would be a reason for an endpoint to send PING in a 0-RTT packets. OTOH, if we are to allow PING to be sent in Initial and Handshake packets, I think there's no strong reason to forbid that to be sent in a 0-RTT packet. > 0x02 - 0x03 ACK - impossible > 0x04 RESET_STREAM - the trigger for this mess; but we seem to want it > 0x05 STOP_SENDING - more valuable than RESET_STREAM in many ways > 0x06 CRYPTO - impossible > 0x07 NEW_TOKEN - impossible > 0x08 - 0x0f STREAM - very important, the most dangerous, and already = allowed > 0x10 MAX_DATA - seems useful > 0x11 MAX_STREAM_DATA - seems useful > 0x12 - 0x13 MAX_STREAMS - seems useful > 0x14 DATA_BLOCKED - either redundant - because connection flow control= is used to limit 0-RTT - or useful - because knowing when 0-RTT flow contr= ol limits are hit is useful information; this might depend on whether you t= hink that the blocked signals are useful in general > 0x15 STREAM_DATA_BLOCKED - marginally useful > 0x16 - 0x17 STREAMS_BLOCKED - marginally useful > 0x18 NEW_CONNECTION_ID - in question > 0x19 RETIRE_CONNECTION_ID - impossible > 0x1a PATH_CHALLENGE - in question > 0x1b PATH_RESPONSE - impossible > 0x1c - 0x1d CONNECTION_CLOSE - potentially useful I think allowing CONNECTION_CLOSE in 0-RTT just causes confusion, because the client cannot be sure if the peer would be able to process the frame contained in a 0-RTT packet. What a client should do is always send CONNECTION_CLOSE using an Initial packet or a Handshake packet. > 0x?? KEYS_READY - impossible The table tells us that there are 6 frame types that are impossible to be used in a 0-RTT packet. I'd assume that we'd want receivers to detect misuse and call it a protocol violation (for example, I do not think we'd want to accept ACK or CRYPTO frame sent in 0-RTT packet). That means that frame types permitted in 0-RTT is going to be very different from what is permitted in 1-RTT packets, regardless of the outcome of the debate. And there are only two frames that are debatable: NEW_CONNECTION_ID, PATH_CHALLENGE. Do we need to allow them? Does allowing those simplify the specification or the implementations? I am not sure if the answer to either of the two questions are yes. Besides, I have a mild concern about allowing more frames to be sent in 0-RTT, because it requires a server implementation to consider what happens in case of a replay attack (note that because HTTP is capable of mitigating 0-RTT replay attacks thanks to 425 Too Early, it has so far been possible to have a very lax defense against 0-RTT replay in TLS 1.3 stacks). Hence my preference goes to applying YAGNI. I would certainly _not_ lie down on the road on this debate, I prefer making progress rather than being blocked by this issue. But anyways, above is how I think about the issue. > > You can see that many of these frames simply can't be sent. Mostly becau= se they answer something that the server would send in 1-RTT, and the clien= t can't respond in 0-RTT to 1-RTT packets (it has to use 1-RTT for that). = We could explicitly prohibit those frames, but it is sufficient in my view = to rely on the existing rules. We don't need to go through and piecemeal p= rohibit frames, though we could point out for each one the impossibility of= it being in 0-RTT, it would be redundant to do so. > > For those that are genuinely in question: PING, NEW_CONNECTION_ID, and PA= TH_CHALLENGE, this might seem like a waste of time and effort to talk about= , but we are talking about establishing guidelines on what can and cannot b= e sent in 0-RTT. We are deciding what factors need to be considered when n= ew frames are defined. > > # Conclusion > > Assigning responsibility for replay defense to application protocols is t= he clearest principle we can apply. That is, the transport does not have a= ny inherent opinion about replay risk. All frames are for the transport an= d none of them are specially privileged for use in 0-RTT. What an applicat= ion protocol endpoint decides to do with the transport in 0-RTT is an appli= cation responsibility. An analysis of replay risks is always performed in = the context of the application protocol. > > Based on this, my view is that it would be a mistake to go with YAGNI. D= oing that signs us up for a whole bunch of difficult analysis for every fra= me, having to anticipate the many ways in which it might be abused by appli= cations. Instead, I think that we should articulate the considerations tha= t broadly apply and require that application protocols do the analysis. > > This is not just because I have a PR mostly ready (absent this last bit a= bout considerations and application responsibility, which I plan to add soo= n). Though I have no desire to write up the piecemeal allow/deny stuff, I = will if I have to, but it will only be because I'm in the rough. > > https://github.com/quicwg/base-drafts/pull/2355 > --=20 Kazuho Oku From nobody Tue Feb 5 22:01:14 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56B5126F72 for ; Tue, 5 Feb 2019 22:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=A8RlGfhb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VIyTZXuI 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 eQlEWwH6QfY2 for ; Tue, 5 Feb 2019 22:01:10 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6E712426E for ; Tue, 5 Feb 2019 22:01:09 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D0A1D22230; Wed, 6 Feb 2019 01:01:08 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 06 Feb 2019 01:01:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:subject:date:in-reply-to; s=fm1; bh=qPv YEc0B7UOl0owkmRODigMjcLiBfDMKIUaQDcjaPMg=; b=A8RlGfhbwinaikeTX3c 6usVyJeipoiNxkPadiOz2spKNeEKzfdzJR9FuikOyWsQzlefao9AnOtPWM3/z/eA 9n0tqMXKTtYxW4P1uGOfv1ASw4CBfLQLeLWdZbAuMjTMVJew+C+OA6Bl1lihmPqj 5M2o3kePqTcHaAkkX0OWh5lFWm/mSiMfVMuN4ZAtyDZ6w2zkawohFEXxHMyby1DJ 0bxLglMPuldEQyijgqsu8gzWVyg0qMFmTTmHcigQrK2PY1+XTfQLjg4vzrMnXxOi M2sUK+l6ie58yJbA8m1lWBr+9uI769JWT/tvmXLqRvNRzFdtAnx4enY76tK5Mvtu e9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=qPvYEc0B7UOl0owkmRODigMjcLiBfDMKIUaQDcjaP Mg=; b=VIyTZXuIvxXoeBJv8xsPJhrI7fGDD68Z2XG866FGtMij4EU70T/HhZdUi JBmtDAj621H8s6YXxPivvj0OUqt5woBmlqb08p+X5gxiXzu6W9qewRRtPueOTQzG xMs0ANvtqqrsllvZMUHsxy303bawtQFII2oq3vNCyJL+LKqmwY7ixzAfTqqHqt0Z m/5YsFa0+JfQulBCigNskT3t8J2L+MFLE3/QRTTlIMHZXduELwx9Mva2IdwXA2Em CV7aeMRg9y1QrDBi6Elc+7fY7bkEK/cvqfAupgQ5Ro0f+6xAC6CQf1XAXDDzPzP3 9Wex+eNBqYUaI9aO0jl3gWqDqcRVw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeejgdeludcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof hfufffjgesthejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceo mhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D8EB49E595; Wed, 6 Feb 2019 01:01:07 -0500 (EST) Message-Id: <1549432867.3266669.1651848776.0D91782E@webmail.messagingengine.com> From: Martin Thomson To: Kazuho Oku Cc: IETF QUIC WG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ec01da05 References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> Subject: Re: Allowed frames in 0-RTT Date: Wed, 06 Feb 2019 17:01:07 +1100 In-Reply-To: Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 06:01:13 -0000 On Wed, Feb 6, 2019, at 16:24, Kazuho Oku wrote: > I think we can agree that 0-RTT is a concern for both the application > and the transport. My entire thesis here is that replay risks are primarily an application concern, so I can't agree. If you are willing to accept that the risk to transport is the far less severe DoS one, then I'd concede that. My latest update to the PR should address that point. But transient costs, like the amount of CPU you spend on connections is entirely in server control, so I don't think that's the important point here. I'm concerned about things like double-spend, which exist only at the application layer. > For application, the precedence we have in TLS 1.3 is that each > application protocol is required to create a profile specifying how > 0-RTT data should be handled. My assumption is that we would be > following that. Yes, this is exactly the point. TLS 1.3 can't say what the risk of replay is generically, only HTTP can say what the risk is for HTTP. > With that in mind, I think we agree that all frames > related to transmission of data (and streams) should be permitted. Sure, but the principle you are applying is YAGNI. I'm suggesting that there is a better and simpler principle: applications own the responsibility for replay risk. > The question is what to do with the frame types that control the > properties of the transport. We could either go with YAGNI, or allow > them assuming that they do not pose a security concerns. My point is that the frames do not inherently carry a risk - it's the application of the information they carry that carries the real risk. > Regarding PING, I think there's a broader discussion about if it the > use should be limited to 1-RTT. If we are to continue forbidding use > of PING in Initial and Handshake packets, I do not think that there > would be a reason for an endpoint to send PING in a 0-RTT packets. > OTOH, if we are to allow PING to be sent in Initial and Handshake > packets, I think there's no strong reason to forbid that to be sent in > a 0-RTT packet. PING is easy. It is trivially possible to show that a STREAM frame with duplicated data produces the same effect. So the only question is whether to allow people to save a few bytes to use PING instead. Whether it is advisable to send PING is not the question, and nor should it be. > I think allowing CONNECTION_CLOSE in 0-RTT just causes confusion, > because the client cannot be sure if the peer would be able to process > the frame contained in a 0-RTT packet. What a client should do is > always send CONNECTION_CLOSE using an Initial packet or a Handshake > packet. This is a fine argument. And I would be OK with forbidding CONNECTION_CLOSE. CONNECTION_CLOSE is special enough, and the rules for generating it during the handshake are already fraught; I think that forbidding CONNECTION_CLOSE in 0-RTT is a natural consequence of applying the changes we agreed here in Tokyo. > And there are only two frames that are debatable: NEW_CONNECTION_ID, > PATH_CHALLENGE. > > Do we need to allow them? Does allowing those simplify the > specification or the implementations? I think that we do, but only because it would simplify clients. You could say that we know that it's 0-RTT, so we can do anything we like, but that's not principled. Marten had an argument in favour of NEW_CONNECTION_ID. Sending it in 0-RTT could speed up moving to a privately negotiated connection ID (which enables stateless reset). But to my earlier point, if a client wanted to send that frame, having to withhold sending is awkward for the same reason that holding a RESET_STREAM would be. So I'd say yes to NEW_CONNECTION_ID. Having to decide to hold a frame at the client is an unnecessary imposition. Why should the client have to treat 0-RTT specially? Sure, there are things that it shouldn't be sending, but those all come down to stuff that is enforced by the handshake state machine (e.g., you can't send ACK because you can't read anything that could be acknowledged). For that matter, as we discussed for the flow control matter, we don't want to require a server to check that the client didn't comply in all cases like this (though they SHOULD do so, as we agreed in https://github.com/quicwg/base-drafts/issues/2360). Applying that logic, allowing PATH_CHALLENGE is fine, if a little pointless. > Besides, I have a mild concern about allowing more frames to be sent > in 0-RTT, because it requires a server implementation to consider what > happens in case of a replay attack (note that because HTTP is capable > of mitigating 0-RTT replay attacks thanks to 425 Too Early, it has so > far been possible to have a very lax defense against 0-RTT replay in > TLS 1.3 stacks). I don't understand this point. That's an HTTP-layer concern, not a QUIC one. From nobody Tue Feb 5 23:06:32 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C4712867A for ; Tue, 5 Feb 2019 23:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3fE0HZWvl7h for ; Tue, 5 Feb 2019 23:06:28 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0111124B0C for ; Tue, 5 Feb 2019 23:06:27 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id j1so4545420lfb.10 for ; Tue, 05 Feb 2019 23:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=b03xyCpEWTKF4kxoepSzkmYTqwGwKhIYNiODonF/9xA=; b=Ew7PvYGAu0Aq1OQQqCxXMbWzkaRXmib9VatTs1kx0t2TIvyqm3v+VKdLwQSd0vUi2Z scl2MUv0SxJbjrDrCB1Eyt/55Zu3TdMZtFT72CfCN8w8vQU8MchpUlcg8HKY3rKLCFC6 HORlkC7HivZ7K5AsLd2EprQmw2rHizKdVoK17RI39YDwi/x8pQ/5n4aN/IRcgElYFH1Z R3kmxOX+Vi9IDn4tL01ze2FH8ma24c8975jNd9dL9hkSWbkVlhHxBmxCgeWJihEtXZMV +VfsvlH8qi5Yq27T3KaFLxXThEp7pA6xno9arSQaHsgISxfBAZ3XoQRexRNy3LtSb4PG 5Hmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=b03xyCpEWTKF4kxoepSzkmYTqwGwKhIYNiODonF/9xA=; b=aHzH75xe9Q7ReS4BuDDgLoKnUDbrWYB79jzgDW0Qb6eS7IAWEfHneP+ssJTX6y8qf+ Q3bLW6V0ssTT/RpuieTjdu3/+zsb7DCB3RfOknfxXXMOeHowkTVhviH7Fn2asrTrX1Fz Q2GNF1kb/KuuHy3WmOyHgc+MgeepbUzLK36RZAcuFcDd4hM1OiCgVAx9lSrxxE71BtjR 91hY/wDF/fQn17G+TYbD1cXbTeo/Vfd9C6P4h1ji0MwerKP2mapNAaBlAjtopmcB87Ey Wu8hDqX8qkH3WCKMhFgfjiqgkqQjeTIGFx49LzUxg8X35EBQ3CBwy0R0i/54i1sdK2Wq bMYA== X-Gm-Message-State: AHQUAua0zzJ4tX/L0SMC9qXl3WYM3NhmiUqAvQihhwob0OERAT5Ang/x wvZ7Wqueh6acnJtG/wvRJNACxnApdtyqyDHk/q3FhnCV X-Google-Smtp-Source: AHgI3IZZn4tFhgHRKDzkFk1VvqcTCRJ2ylnRLuUGK+iU2N5syGKWg/Pd9mfCsilGLsMUtvt5kkssrWc5W+NTs+p7zkg= X-Received: by 2002:a19:aace:: with SMTP id t197mr5483110lfe.7.1549436785343; Tue, 05 Feb 2019 23:06:25 -0800 (PST) MIME-Version: 1.0 References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <1549432867.3266669.1651848776.0D91782E@webmail.messagingengine.com> In-Reply-To: <1549432867.3266669.1651848776.0D91782E@webmail.messagingengine.com> From: Kazuho Oku Date: Wed, 6 Feb 2019 16:06:14 +0900 Message-ID: Subject: Re: Allowed frames in 0-RTT To: Martin Thomson Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 07:06:31 -0000 2019=E5=B9=B42=E6=9C=886=E6=97=A5(=E6=B0=B4) 15:01 Martin Thomson : > > On Wed, Feb 6, 2019, at 16:24, Kazuho Oku wrote: > > I think we can agree that 0-RTT is a concern for both the application > > and the transport. > > My entire thesis here is that replay risks are primarily an application c= oncern, so I can't agree. If you are willing to accept that the risk to tr= ansport is the far less severe DoS one, then I'd concede that. My latest up= date to the PR should address that point. But transient costs, like the am= ount of CPU you spend on connections is entirely in server control, so I do= n't think that's the important point here. I'm concerned about things like= double-spend, which exist only at the application layer. I agree that the view that the risk to transport is far less severe than the risk to the application, even though there is a risk. I have just read the updated text on the PR. Looks perfect to me. Thank you for writing that down. > > > For application, the precedence we have in TLS 1.3 is that each > > application protocol is required to create a profile specifying how > > 0-RTT data should be handled. My assumption is that we would be > > following that. > > Yes, this is exactly the point. TLS 1.3 can't say what the risk of repla= y is generically, only HTTP can say what the risk is for HTTP. > > > With that in mind, I think we agree that all frames > > related to transmission of data (and streams) should be permitted. > > Sure, but the principle you are applying is YAGNI. I'm suggesting that t= here is a better and simpler principle: applications own the responsibility= for replay risk. Yeah, what I am trying to state here is that we share the view that application should be responsible for handling replay of data. > > > The question is what to do with the frame types that control the > > properties of the transport. We could either go with YAGNI, or allow > > them assuming that they do not pose a security concerns. > > My point is that the frames do not inherently carry a risk - it's the app= lication of the information they carry that carries the real risk. > > > Regarding PING, I think there's a broader discussion about if it the > > use should be limited to 1-RTT. If we are to continue forbidding use > > of PING in Initial and Handshake packets, I do not think that there > > would be a reason for an endpoint to send PING in a 0-RTT packets. > > OTOH, if we are to allow PING to be sent in Initial and Handshake > > packets, I think there's no strong reason to forbid that to be sent in > > a 0-RTT packet. > > PING is easy. It is trivially possible to show that a STREAM frame with = duplicated data produces the same effect. So the only question is whether = to allow people to save a few bytes to use PING instead. > > Whether it is advisable to send PING is not the question, and nor should = it be. > > > I think allowing CONNECTION_CLOSE in 0-RTT just causes confusion, > > because the client cannot be sure if the peer would be able to process > > the frame contained in a 0-RTT packet. What a client should do is > > always send CONNECTION_CLOSE using an Initial packet or a Handshake > > packet. > > This is a fine argument. And I would be OK with forbidding CONNECTION_CL= OSE. CONNECTION_CLOSE is special enough, and the rules for generating it d= uring the handshake are already fraught; I think that forbidding CONNECTION= _CLOSE in 0-RTT is a natural consequence of applying the changes we agreed = here in Tokyo. > > > And there are only two frames that are debatable: NEW_CONNECTION_ID, > > PATH_CHALLENGE. > > > > Do we need to allow them? Does allowing those simplify the > > specification or the implementations? > > I think that we do, but only because it would simplify clients. You coul= d say that we know that it's 0-RTT, so we can do anything we like, but that= 's not principled. > > Marten had an argument in favour of NEW_CONNECTION_ID. Sending it in 0-R= TT could speed up moving to a privately negotiated connection ID (which ena= bles stateless reset). I am not sure if it helps. A client needs to migrate to a different address in order to enforce the peer to switch to a new CID. That cannot happen before the handshake completes (which is going to be signalled using the new frame). That means that there would be at least 1 RTT between when the client obtains the 1-RTT write key and when it can initiate a migration to use a different connection ID. That's why I wonder if sending NEW_CONNECTION_ID in 0-RTT makes things better, even ignoring the potential negative impact on path validation and congestion control when the client migrates the connection. > But to my earlier point, if a client wanted to send that frame, having to= withhold sending is awkward for the same reason that holding a RESET_STREA= M would be. So I'd say yes to NEW_CONNECTION_ID. > > Having to decide to hold a frame at the client is an unnecessary impositi= on. Why should the client have to treat 0-RTT specially? I think that's a fair argument, though I might point out that regardless of the conclusion of this discussion, we'd need to hold things until various events. * Stream data needs to be held until either 0-RTT key or 1-RTT key becomes available. * Transport needs to notify the application when 1-RTT key becomes available, otherwise it cannot support HTTP/3. This is because the client is required to withhold reissuing a HTTP request in response to 425 until it obtains the 1-RTT key. * Migration needs to be held until the handshake is complete. The first two point shows that we need to do things at the moment when 1-RTT write key is obtained. > Sure, there are things that it shouldn't be sending, but those all come d= own to stuff that is enforced by the handshake state machine (e.g., you can= 't send ACK because you can't read anything that could be acknowledged). F= or that matter, as we discussed for the flow control matter, we don't want = to require a server to check that the client didn't comply in all cases lik= e this (though they SHOULD do so, as we agreed in https://github.com/quicwg= /base-drafts/issues/2360). Applying that logic, allowing PATH_CHALLENGE is= fine, if a little pointless. > > > Besides, I have a mild concern about allowing more frames to be sent > > in 0-RTT, because it requires a server implementation to consider what > > happens in case of a replay attack (note that because HTTP is capable > > of mitigating 0-RTT replay attacks thanks to 425 Too Early, it has so > > far been possible to have a very lax defense against 0-RTT replay in > > TLS 1.3 stacks). > > I don't understand this point. That's an HTTP-layer concern, not a QUIC = one. What I am trying to clarify is how you _tune_ your TLS 1.3 stack can depend on how sensitive the application protocol is against replay attacks. It is beneficial to be lax in when you accept 0-RTT, because it improves the chance of reducing an RTT (e.g., should a server accept ticket reuse when the client is doing happy eyeballs?). My view is that minimizing the concerns unique to the transport layer enables us to utilize 0-RTT as much as possible for a replay-resistant protocol like HTTP. --=20 Kazuho Oku From nobody Tue Feb 5 23:53:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6B6126C7E for ; Tue, 5 Feb 2019 23:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 v6ezNordsAQ8 for ; Tue, 5 Feb 2019 23:53:01 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 879FA12426E for ; Tue, 5 Feb 2019 23:53:01 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id w18so4161893ite.1 for ; Tue, 05 Feb 2019 23:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=BEdZeXKMKvcy9cPPcqRfNgTCqq7TSxrUjDsSB61y4QA=; b=TmKwBVSxDUxppwKVmMWMZ8V63rapa12dAwjRWpHyCBJZR/GjSV6XgD9aTQBPA2JL6z xNhtWuoK3BwGlzMvieBTDkVb8yTwv54H6/NVQDEoVDI4MXntoM1NWFuqG1k8lPjXESoM oX57Zlo1ctEk1jnbvxwrdqIE4MTrPKFGoGTqUOMhwEf6DpZ5bQD67KDJLKR4ykcJUTcZ QMz1Ut46R3NyHwnhlCzTFs7Fs/V4i7QTBmCX0DVtshsOzZ3j6aXiUi7OCj9kuMpdyn9X bMTzjQyMIQ1uBot91/oPcok4nQZY/qr/S6LBsEcMhDtuVOdUsHofKF3VK7ONBrn28xX+ k7eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=BEdZeXKMKvcy9cPPcqRfNgTCqq7TSxrUjDsSB61y4QA=; b=MgqkReLplE8ucClZe7Fe4EHBXE0jIKlFBExYr84pvI8qPpBYBqqkOt7nqBz6haYmNt U0b7taGucKh22/orSHvOR1N7ffPh1HUHebCcO7X8p8s4y/PI3GFAeBSHdmj3V7hvGdeN ZQ8hCfKdQevrquyoo8TZtiPS/MwD3AZldAkga1+Lb1h+OwBck4Vn0zOrutEi4aRKpoCw MGX+RBT95n/594jx7UQgXisJP5yo2MC8MyDb+M4c6Yz/EgXxaH5h6GW+8oBYUh862XL5 Mr5/ZBB1+bbW/R6cThXBjhF89QNDF32pxecWnuoLc2YlslS0UtVEadpBLynVwzv+B9qB R02A== X-Gm-Message-State: AHQUAubyOXtqEfb8p3zQIAHdWC/Vh5YMa4hUjb4NZHrdqkTgfMiRj01A DljoTMNl3PkLTEvi2QfOUQFoXZecIpcLwTIiK/Y= X-Google-Smtp-Source: AHgI3IYu37kYLoTFUOkPEtMABebPXFndZ0qhZ0pzWx36ITsvA1Y29Wcz9KBLTPPiPlNWmNZODJm9dQkQRfZRLGtaBE0= X-Received: by 2002:a6b:c889:: with SMTP id y131mr4951764iof.106.1549439580692; Tue, 05 Feb 2019 23:53:00 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 5 Feb 2019 23:52:59 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <1549432867.3266669.1651848776.0D91782E@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 5 Feb 2019 23:52:59 -0800 Message-ID: Subject: Re: Allowed frames in 0-RTT To: Martin Thomson , Kazuho Oku Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000ceee610581350354" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 07:53:05 -0000 --000000000000ceee610581350354 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for making this analysis. As to future frames: it is comforting to know the current token / crypto things are impossible, and that should apply forward. I agree that the application should take control of replay responsibilities, but I have concerns here: 1. the application is lazy and greedy. For example, yes detect 0-RTT, only allow GET, but don=E2=80=99t bother with special flow credits that no-one understands, don=E2=80=99t think too hard, don=E2=80=99t save state, don=E2= =80=99t analyze if GET actually PUT's. Greedy: yes Fast connection is better. We cannot hold hands, but this is the reality. We are not talking about years of web server development, but of http enabled application endpoints with a development cycle of two days. 2. the stream is an attack vector on resources spent. This makes me think that we need some hard defaults on flow credits and perhaps also stream max. Both to protect the transport (and potentially OS kernel), and to simplify life for application developers who do not generally have a clue about these concerns. I can see this being set with configurable defaults, so I=E2=80=99, not sure what the drafts can enforce = or help with here. Mikkel On 6 February 2019 at 08.06.48, Kazuho Oku (kazuhooku@gmail.com) wrote: 2019=E5=B9=B42=E6=9C=886=E6=97=A5(=E6=B0=B4) 15:01 Martin Thomson : > > On Wed, Feb 6, 2019, at 16:24, Kazuho Oku wrote: > > I think we can agree that 0-RTT is a concern for both the application > > and the transport. > > My entire thesis here is that replay risks are primarily an application concern, so I can't agree. If you are willing to accept that the risk to transport is the far less severe DoS one, then I'd concede that. My latest update to the PR should address that point. But transient costs, like the amount of CPU you spend on connections is entirely in server control, so I don't think that's the important point here. I'm concerned about things like double-spend, which exist only at the application layer. I agree that the view that the risk to transport is far less severe than the risk to the application, even though there is a risk. I have just read the updated text on the PR. Looks perfect to me. Thank you for writing that down. > > > For application, the precedence we have in TLS 1.3 is that each > > application protocol is required to create a profile specifying how > > 0-RTT data should be handled. My assumption is that we would be > > following that. > > Yes, this is exactly the point. TLS 1.3 can't say what the risk of replay is generically, only HTTP can say what the risk is for HTTP. > > > With that in mind, I think we agree that all frames > > related to transmission of data (and streams) should be permitted. > > Sure, but the principle you are applying is YAGNI. I'm suggesting that there is a better and simpler principle: applications own the responsibility for replay risk. Yeah, what I am trying to state here is that we share the view that application should be responsible for handling replay of data. > > > The question is what to do with the frame types that control the > > properties of the transport. We could either go with YAGNI, or allow > > them assuming that they do not pose a security concerns. > > My point is that the frames do not inherently carry a risk - it's the application of the information they carry that carries the real risk. > > > Regarding PING, I think there's a broader discussion about if it the > > use should be limited to 1-RTT. If we are to continue forbidding use > > of PING in Initial and Handshake packets, I do not think that there > > would be a reason for an endpoint to send PING in a 0-RTT packets. > > OTOH, if we are to allow PING to be sent in Initial and Handshake > > packets, I think there's no strong reason to forbid that to be sent in > > a 0-RTT packet. > > PING is easy. It is trivially possible to show that a STREAM frame with duplicated data produces the same effect. So the only question is whether to allow people to save a few bytes to use PING instead. > > Whether it is advisable to send PING is not the question, and nor should it be. > > > I think allowing CONNECTION_CLOSE in 0-RTT just causes confusion, > > because the client cannot be sure if the peer would be able to process > > the frame contained in a 0-RTT packet. What a client should do is > > always send CONNECTION_CLOSE using an Initial packet or a Handshake > > packet. > > This is a fine argument. And I would be OK with forbidding CONNECTION_CLOSE. CONNECTION_CLOSE is special enough, and the rules for generating it during the handshake are already fraught; I think that forbidding CONNECTION_CLOSE in 0-RTT is a natural consequence of applying the changes we agreed here in Tokyo. > > > And there are only two frames that are debatable: NEW_CONNECTION_ID, > > PATH_CHALLENGE. > > > > Do we need to allow them? Does allowing those simplify the > > specification or the implementations? > > I think that we do, but only because it would simplify clients. You could say that we know that it's 0-RTT, so we can do anything we like, but that's not principled. > > Marten had an argument in favour of NEW_CONNECTION_ID. Sending it in 0-RTT could speed up moving to a privately negotiated connection ID (which enables stateless reset). I am not sure if it helps. A client needs to migrate to a different address in order to enforce the peer to switch to a new CID. That cannot happen before the handshake completes (which is going to be signalled using the new frame). That means that there would be at least 1 RTT between when the client obtains the 1-RTT write key and when it can initiate a migration to use a different connection ID. That's why I wonder if sending NEW_CONNECTION_ID in 0-RTT makes things better, even ignoring the potential negative impact on path validation and congestion control when the client migrates the connection. > But to my earlier point, if a client wanted to send that frame, having to withhold sending is awkward for the same reason that holding a RESET_STREAM would be. So I'd say yes to NEW_CONNECTION_ID. > > Having to decide to hold a frame at the client is an unnecessary imposition. Why should the client have to treat 0-RTT specially? I think that's a fair argument, though I might point out that regardless of the conclusion of this discussion, we'd need to hold things until various events. * Stream data needs to be held until either 0-RTT key or 1-RTT key becomes available. * Transport needs to notify the application when 1-RTT key becomes available, otherwise it cannot support HTTP/3. This is because the client is required to withhold reissuing a HTTP request in response to 425 until it obtains the 1-RTT key. * Migration needs to be held until the handshake is complete. The first two point shows that we need to do things at the moment when 1-RTT write key is obtained. > Sure, there are things that it shouldn't be sending, but those all come down to stuff that is enforced by the handshake state machine (e.g., you can't send ACK because you can't read anything that could be acknowledged). For that matter, as we discussed for the flow control matter, we don't want to require a server to check that the client didn't comply in all cases like this (though they SHOULD do so, as we agreed in https://github.com/quicwg/base-drafts/issues/2360). Applying that logic, allowing PATH_CHALLENGE is fine, if a little pointless. > > > Besides, I have a mild concern about allowing more frames to be sent > > in 0-RTT, because it requires a server implementation to consider what > > happens in case of a replay attack (note that because HTTP is capable > > of mitigating 0-RTT replay attacks thanks to 425 Too Early, it has so > > far been possible to have a very lax defense against 0-RTT replay in > > TLS 1.3 stacks). > > I don't understand this point. That's an HTTP-layer concern, not a QUIC one. What I am trying to clarify is how you _tune_ your TLS 1.3 stack can depend on how sensitive the application protocol is against replay attacks. It is beneficial to be lax in when you accept 0-RTT, because it improves the chance of reducing an RTT (e.g., should a server accept ticket reuse when the client is doing happy eyeballs?). My view is that minimizing the concerns unique to the transport layer enables us to utilize 0-RTT as much as possible for a replay-resistant protocol like HTTP. --=20 Kazuho Oku --000000000000ceee610581350354 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Thanks for making th= is analysis.
=
As to fu= ture frames: it is comforting to know the current token / crypto things are= impossible, and that should apply forward.

I agree that the application should take control of = replay responsibilities, but I have concerns here:

1. the application is lazy and greedy. For ex= ample, yes detect 0-RTT, only allow GET, but don=E2=80=99t bother with spec= ial flow credits that no-one understands, don=E2=80=99t think too hard, don= =E2=80=99t save state, don=E2=80=99t analyze if GET actually PUT's. Gre= edy: yes Fast connection is better. We cannot hold hands, but this is the r= eality. We are not talking about years of web server development, but of ht= tp enabled application endpoints with a development cycle of two days.

2. the stream is an attac= k vector on resources spent.

This makes me think that we need some hard defaults on flow credits= and perhaps also stream max. Both to protect the transport (and potentiall= y OS kernel), and to simplify life for application developers who do not ge= nerally have a clue about these concerns. I can see this being set with con= figurable defaults, so I=E2=80=99, not sure what the drafts can enforce or = help with here.

Mikke= l

=

On 6 February 2019 at 08.06.48, Kazuho Oku (kazuhooku@gmail.com) wrote:

2019= =E5=B9=B42=E6=9C=886=E6=97=A5(=E6=B0=B4) 15:01 Martin Thomson <mt@lowentropy.net>:
>
> On Wed, Feb 6, 2019, at 16:24, Kazuho Oku wrote:
> > I think we can agree that 0-RTT is a concern for both the app= lication
> > and the transport.
>
> My entire thesis here is that replay risks are primarily an applic= ation concern, so I can't agree. If you are willing to accept that the= risk to transport is the far less severe DoS one, then I'd concede tha= t. My latest update to the PR should address that point. But transient cos= ts, like the amount of CPU you spend on connections is entirely in server c= ontrol, so I don't think that's the important point here. I'm = concerned about things like double-spend, which exist only at the applicati= on layer.

I agree that the view that the risk to transport is far less severe
than the risk to the application, even though there is a risk.

I have just read the updated text on the PR. Looks perfect to me.
Thank you for writing that down.

>
> > For application, the precedence we have in TLS 1.3 is that ea= ch
> > application protocol is required to create a profile specifyi= ng how
> > 0-RTT data should be handled. My assumption is that we would = be
> > following that.
>
> Yes, this is exactly the point. TLS 1.3 can't say what the ri= sk of replay is generically, only HTTP can say what the risk is for HTTP.
>
> > With that in mind, I think we agree that all frames
> > related to transmission of data (and streams) should be permi= tted.
>
> Sure, but the principle you are applying is YAGNI. I'm sugges= ting that there is a better and simpler principle: applications own the res= ponsibility for replay risk.

Yeah, what I am trying to state here is that we share the view that
application should be responsible for handling replay of data.

>
> > The question is what to do with the frame types that control = the
> > properties of the transport. We could either go with YAGNI, o= r allow
> > them assuming that they do not pose a security concerns.
>
> My point is that the frames do not inherently carry a risk - it= 9;s the application of the information they carry that carries the real ris= k.
>
> > Regarding PING, I think there's a broader discussion abou= t if it the
> > use should be limited to 1-RTT. If we are to continue forbidd= ing use
> > of PING in Initial and Handshake packets, I do not think that= there
> > would be a reason for an endpoint to send PING in a 0-RTT pac= kets.
> > OTOH, if we are to allow PING to be sent in Initial and Hands= hake
> > packets, I think there's no strong reason to forbid that = to be sent in
> > a 0-RTT packet.
>
> PING is easy. It is trivially possible to show that a STREAM fram= e with duplicated data produces the same effect. So the only question is w= hether to allow people to save a few bytes to use PING instead.
>
> Whether it is advisable to send PING is not the question, and nor = should it be.
>
> > I think allowing CONNECTION_CLOSE in 0-RTT just causes confus= ion,
> > because the client cannot be sure if the peer would be able t= o process
> > the frame contained in a 0-RTT packet. What a client should d= o is
> > always send CONNECTION_CLOSE using an Initial packet or a Han= dshake
> > packet.
>
> This is a fine argument. And I would be OK with forbidding CONNEC= TION_CLOSE. CONNECTION_CLOSE is special enough, and the rules for generati= ng it during the handshake are already fraught; I think that forbidding CON= NECTION_CLOSE in 0-RTT is a natural consequence of applying the changes we = agreed here in Tokyo.
>
> > And there are only two frames that are debatable: NEW_CONNECT= ION_ID,
> > PATH_CHALLENGE.
> >
> > Do we need to allow them? Does allowing those simplify the
> > specification or the implementations?
>
> I think that we do, but only because it would simplify clients. Y= ou could say that we know that it's 0-RTT, so we can do anything we lik= e, but that's not principled.
>
> Marten had an argument in favour of NEW_CONNECTION_ID. Sending it= in 0-RTT could speed up moving to a privately negotiated connection ID (wh= ich enables stateless reset).

I am not sure if it helps. A client needs to migrate to a different
address in order to enforce the peer to switch to a new CID. That
cannot happen before the handshake completes (which is going to be
signalled using the new frame). That means that there would be at
least 1 RTT between when the client obtains the 1-RTT write key and
when it can initiate a migration to use a different connection ID.
That's why I wonder if sending NEW_CONNECTION_ID in 0-RTT makes thi= ngs
better, even ignoring the potential negative impact on path validation
and congestion control when the client migrates the connection.

> But to my earlier point, if a client wanted to send that frame, ha= ving to withhold sending is awkward for the same reason that holding a RESE= T_STREAM would be. So I'd say yes to NEW_CONNECTION_ID.
>
> Having to decide to hold a frame at the client is an unnecessary i= mposition. Why should the client have to treat 0-RTT specially?

I think that's a fair argument, though I might point out that
regardless of the conclusion of this discussion, we'd need to hold
things until various events.

* Stream data needs to be held until either 0-RTT key or 1-RTT key
becomes available.
* Transport needs to notify the application when 1-RTT key becomes
available, otherwise it cannot support HTTP/3. This is because the
client is required to withhold reissuing a HTTP request in response to
425 until it obtains the 1-RTT key.
* Migration needs to be held until the handshake is complete.

The first two point shows that we need to do things at the moment when
1-RTT write key is obtained.

> Sure, there are things that it shouldn't be sending, but those= all come down to stuff that is enforced by the handshake state machine (e.= g., you can't send ACK because you can't read anything that could b= e acknowledged). For that matter, as we discussed for the flow control mat= ter, we don't want to require a server to check that the client didn= 9;t comply in all cases like this (though they SHOULD do so, as we agreed i= n https://git= hub.com/quicwg/base-drafts/issues/2360). Applying that logic, allowing= PATH_CHALLENGE is fine, if a little pointless.
>
> > Besides, I have a mild concern about allowing more frames to = be sent
> > in 0-RTT, because it requires a server implementation to cons= ider what
> > happens in case of a replay attack (note that because HTTP is= capable
> > of mitigating 0-RTT replay attacks thanks to 425 Too Early, i= t has so
> > far been possible to have a very lax defense against 0-RTT re= play in
> > TLS 1.3 stacks).
>
> I don't understand this point. That's an HTTP-layer conce= rn, not a QUIC one.

What I am trying to clarify is how you _tune_ your TLS 1.3 stack can
depend on how sensitive the application protocol is against replay
attacks. It is beneficial to be lax in when you accept 0-RTT, because
it improves the chance of reducing an RTT (e.g., should a server
accept ticket reuse when the client is doing happy eyeballs?).

My view is that minimizing the concerns unique to the transport layer
enables us to utilize 0-RTT as much as possible for a replay-resistant
protocol like HTTP.

-- =20
Kazuho Oku

--000000000000ceee610581350354-- From nobody Wed Feb 6 00:25:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85822126C7E for ; Wed, 6 Feb 2019 00:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 uuZO7LuZz1Yp for ; Wed, 6 Feb 2019 00:25:44 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 850CD12426E for ; Wed, 6 Feb 2019 00:25:44 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id b5so4370146iti.2 for ; Wed, 06 Feb 2019 00:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UG5f4rkq6wirA3ObPkZww0DdP1LfehJ8F6NRAMIj+Io=; b=Zsob1B2xQM3aavkQbO4vXdZibgQvI470zSe63jC+5dBzt8n31qmOTDOIRJ5euzuf0J Ut+LfOGBr7AHSsoSBAXa3ZRs5J7ooRyqGua1FZaaaed4ib+IqpmLAg0vXih86XIW7k5m SQj4xqGWGvFz7eYKP7/cEuzY7OZcjYRTcmkX3wPvHMo3JFfbCoFGMMMHLQfKveGFp75R apWIc3hIlBDNmEVsMpWNQxzl3JGAtO2ippNgl+J/dMUXhEKNoeaX8HRZAHd7CzZtOeXv xFSx/wRiYj6vTRpfd3IeZoBka9yPY5isuLpcAGXQ3HyiT93+lY/rP2Yl7tVqlBG19FtG gvsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UG5f4rkq6wirA3ObPkZww0DdP1LfehJ8F6NRAMIj+Io=; b=EPsU9NmmdY0blPVX2ohM7fvaRHpZ12cYLn2UlL2VFgtVCZwxbfKIyFhnV2jM2ZHTsw bAcaMo9qHCnJhb0a6vod9zh4dHMkeWa92IzbAcyvIUPXsazzIZH8rW/8ONI+B+oTRbQn v1a/WMhUdr2CMqJ2U9WL6A+UYPPV6jg4fbTnAAfXsRG2AeRWVAkyV9CVVJqsLEBWRb7l TZNviEouy5KoRgj6NzS46L5ydHva3kDh4FZRelhttx9kuczH8OI1WmExkrsaIXJyYlN3 Dpm/izSvlHNQKAmUQgzNfWjIYQv3u7ytTkx6HGJtKLVylkj73WaCl7o18HOaACLQ/OAf e3JQ== X-Gm-Message-State: AHQUAubLJodFADqdK/1M1kyq4FSikaod4o2S4UQfvgI1l2t1I3NbBkNO rLl0XMY+33Tb31ZQaAGPWic= X-Google-Smtp-Source: AHgI3IZ0UERNTE+dRlnrakJyBOM7wyokrBU7uaIAbMsHtz7tHYhXvMIwzUplEgtD2JiWYvZ9kU2BTA== X-Received: by 2002:a24:fe06:: with SMTP id w6mr1619975ith.108.1549441543765; Wed, 06 Feb 2019 00:25:43 -0800 (PST) Received: from ?IPv6:2400:4050:31c0:f200:495b:adca:13b9:14d6? ([2400:4050:31c0:f200:495b:adca:13b9:14d6]) by smtp.gmail.com with ESMTPSA id k1sm1995329iob.2.2019.02.06.00.25.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 00:25:42 -0800 (PST) From: Kazuho Oku X-Google-Original-From: Kazuho Oku Content-Type: multipart/alternative; boundary=Apple-Mail-09DBB8BD-E4B1-4A84-AEFF-4869B9957F18 Mime-Version: 1.0 (1.0) Subject: Re: Allowed frames in 0-RTT X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Wed, 6 Feb 2019 17:25:40 +0900 Cc: Martin Thomson , IETF QUIC WG Content-Transfer-Encoding: 7bit Message-Id: References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <1549432867.3266669.1651848776.0D91782E@webmail.messagingengine.com> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 08:25:49 -0000 --Apple-Mail-09DBB8BD-E4B1-4A84-AEFF-4869B9957F18 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 2019/02/06 16:52=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > Thanks for making this analysis. >=20 > As to future frames: it is comforting to know the current token / crypto t= hings are impossible, and that should apply forward. >=20 > I agree that the application should take control of replay responsibilitie= s, but I have concerns here: >=20 > 1. the application is lazy and greedy. For example, yes detect 0-RTT, only= allow GET, but don=E2=80=99t bother with special flow credits that no-one u= nderstands, don=E2=80=99t think too hard, don=E2=80=99t save state, don=E2=80= =99t analyze if GET actually PUT's. Greedy: yes Fast connection is better. W= e cannot hold hands, but this is the reality. We are not talking about years= of web server development, but of http enabled application endpoints with a= development cycle of two days. >=20 > 2. the stream is an attack vector on resources spent. >=20 > This makes me think that we need some hard defaults on flow credits and pe= rhaps also stream max. Both to protect the transport (and potentially OS ker= nel), and to simplify life for application developers who do not generally h= ave a clue about these concerns. I can see this being set with configurable d= efaults, so I=E2=80=99, not sure what the drafts can enforce or help with he= re. We=E2=80=99ve discussed this in https://github.com/quicwg/base-drafts/issues= /2360 and also in Tokyo. I think the conclusion is essentially what you are s= uggesting. The point we are discussing now is the remainder which is far less concernin= g than the replay concerns at the application level :-) >=20 > Mikkel >=20 >=20 >> On 6 February 2019 at 08.06.48, Kazuho Oku (kazuhooku@gmail.com) wrote: >>=20 >> 2019=E5=B9=B42=E6=9C=886=E6=97=A5(=E6=B0=B4) 15:01 Martin Thomson :=20 >> >=20 >> > On Wed, Feb 6, 2019, at 16:24, Kazuho Oku wrote:=20 >> > > I think we can agree that 0-RTT is a concern for both the application= =20 >> > > and the transport.=20 >> >=20 >> > My entire thesis here is that replay risks are primarily an application= concern, so I can't agree. If you are willing to accept that the risk to tr= ansport is the far less severe DoS one, then I'd concede that. My latest upd= ate to the PR should address that point. But transient costs, like the amoun= t of CPU you spend on connections is entirely in server control, so I don't t= hink that's the important point here. I'm concerned about things like double= -spend, which exist only at the application layer.=20 >>=20 >> I agree that the view that the risk to transport is far less severe=20 >> than the risk to the application, even though there is a risk.=20 >>=20 >> I have just read the updated text on the PR. Looks perfect to me.=20 >> Thank you for writing that down.=20 >>=20 >> >=20 >> > > For application, the precedence we have in TLS 1.3 is that each=20 >> > > application protocol is required to create a profile specifying how=20= >> > > 0-RTT data should be handled. My assumption is that we would be=20 >> > > following that.=20 >> >=20 >> > Yes, this is exactly the point. TLS 1.3 can't say what the risk of repl= ay is generically, only HTTP can say what the risk is for HTTP.=20 >> >=20 >> > > With that in mind, I think we agree that all frames=20 >> > > related to transmission of data (and streams) should be permitted.=20= >> >=20 >> > Sure, but the principle you are applying is YAGNI. I'm suggesting that t= here is a better and simpler principle: applications own the responsibility f= or replay risk.=20 >>=20 >> Yeah, what I am trying to state here is that we share the view that=20 >> application should be responsible for handling replay of data.=20 >>=20 >> >=20 >> > > The question is what to do with the frame types that control the=20 >> > > properties of the transport. We could either go with YAGNI, or allow=20= >> > > them assuming that they do not pose a security concerns.=20 >> >=20 >> > My point is that the frames do not inherently carry a risk - it's the a= pplication of the information they carry that carries the real risk.=20 >> >=20 >> > > Regarding PING, I think there's a broader discussion about if it the=20= >> > > use should be limited to 1-RTT. If we are to continue forbidding use=20= >> > > of PING in Initial and Handshake packets, I do not think that there=20= >> > > would be a reason for an endpoint to send PING in a 0-RTT packets.=20= >> > > OTOH, if we are to allow PING to be sent in Initial and Handshake=20 >> > > packets, I think there's no strong reason to forbid that to be sent i= n=20 >> > > a 0-RTT packet.=20 >> >=20 >> > PING is easy. It is trivially possible to show that a STREAM frame with= duplicated data produces the same effect. So the only question is whether t= o allow people to save a few bytes to use PING instead.=20 >> >=20 >> > Whether it is advisable to send PING is not the question, and nor shoul= d it be.=20 >> >=20 >> > > I think allowing CONNECTION_CLOSE in 0-RTT just causes confusion,=20 >> > > because the client cannot be sure if the peer would be able to proces= s=20 >> > > the frame contained in a 0-RTT packet. What a client should do is=20 >> > > always send CONNECTION_CLOSE using an Initial packet or a Handshake=20= >> > > packet.=20 >> >=20 >> > This is a fine argument. And I would be OK with forbidding CONNECTION_C= LOSE. CONNECTION_CLOSE is special enough, and the rules for generating it du= ring the handshake are already fraught; I think that forbidding CONNECTION_C= LOSE in 0-RTT is a natural consequence of applying the changes we agreed her= e in Tokyo.=20 >> >=20 >> > > And there are only two frames that are debatable: NEW_CONNECTION_ID,=20= >> > > PATH_CHALLENGE.=20 >> > >=20 >> > > Do we need to allow them? Does allowing those simplify the=20 >> > > specification or the implementations?=20 >> >=20 >> > I think that we do, but only because it would simplify clients. You cou= ld say that we know that it's 0-RTT, so we can do anything we like, but that= 's not principled.=20 >> >=20 >> > Marten had an argument in favour of NEW_CONNECTION_ID. Sending it in 0-= RTT could speed up moving to a privately negotiated connection ID (which ena= bles stateless reset).=20 >>=20 >> I am not sure if it helps. A client needs to migrate to a different=20 >> address in order to enforce the peer to switch to a new CID. That=20 >> cannot happen before the handshake completes (which is going to be=20 >> signalled using the new frame). That means that there would be at=20 >> least 1 RTT between when the client obtains the 1-RTT write key and=20 >> when it can initiate a migration to use a different connection ID.=20 >> That's why I wonder if sending NEW_CONNECTION_ID in 0-RTT makes things=20= >> better, even ignoring the potential negative impact on path validation=20= >> and congestion control when the client migrates the connection.=20 >>=20 >> > But to my earlier point, if a client wanted to send that frame, having t= o withhold sending is awkward for the same reason that holding a RESET_STREA= M would be. So I'd say yes to NEW_CONNECTION_ID.=20 >> >=20 >> > Having to decide to hold a frame at the client is an unnecessary imposi= tion. Why should the client have to treat 0-RTT specially?=20 >>=20 >> I think that's a fair argument, though I might point out that=20 >> regardless of the conclusion of this discussion, we'd need to hold=20 >> things until various events.=20 >>=20 >> * Stream data needs to be held until either 0-RTT key or 1-RTT key=20 >> becomes available.=20 >> * Transport needs to notify the application when 1-RTT key becomes=20 >> available, otherwise it cannot support HTTP/3. This is because the=20 >> client is required to withhold reissuing a HTTP request in response to=20= >> 425 until it obtains the 1-RTT key.=20 >> * Migration needs to be held until the handshake is complete.=20 >>=20 >> The first two point shows that we need to do things at the moment when=20= >> 1-RTT write key is obtained.=20 >>=20 >> > Sure, there are things that it shouldn't be sending, but those all come= down to stuff that is enforced by the handshake state machine (e.g., you ca= n't send ACK because you can't read anything that could be acknowledged). Fo= r that matter, as we discussed for the flow control matter, we don't want to= require a server to check that the client didn't comply in all cases like t= his (though they SHOULD do so, as we agreed in https://github.com/quicwg/bas= e-drafts/issues/2360). Applying that logic, allowing PATH_CHALLENGE is fine,= if a little pointless.=20 >> >=20 >> > > Besides, I have a mild concern about allowing more frames to be sent=20= >> > > in 0-RTT, because it requires a server implementation to consider wha= t=20 >> > > happens in case of a replay attack (note that because HTTP is capable= =20 >> > > of mitigating 0-RTT replay attacks thanks to 425 Too Early, it has so= =20 >> > > far been possible to have a very lax defense against 0-RTT replay in=20= >> > > TLS 1.3 stacks).=20 >> >=20 >> > I don't understand this point. That's an HTTP-layer concern, not a QUIC= one.=20 >>=20 >> What I am trying to clarify is how you _tune_ your TLS 1.3 stack can=20 >> depend on how sensitive the application protocol is against replay=20 >> attacks. It is beneficial to be lax in when you accept 0-RTT, because=20 >> it improves the chance of reducing an RTT (e.g., should a server=20 >> accept ticket reuse when the client is doing happy eyeballs?).=20 >>=20 >> My view is that minimizing the concerns unique to the transport layer=20 >> enables us to utilize 0-RTT as much as possible for a replay-resistant=20= >> protocol like HTTP.=20 >>=20 >> --=20 >> Kazuho Oku=20 >>=20 --Apple-Mail-09DBB8BD-E4B1-4A84-AEFF-4869B9957F18 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 2019/02/06 16:52=E3=80=81Mikkel Fahn=C3=B8e= J=C3=B8rgensen <mikkelfj@gmail.com= >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

=
Thanks for making this analysis.

As to future frames: it is comforting to know the current t= oken / crypto things are impossible, and that should apply forward.

I agree that the application shou= ld take control of replay responsibilities, but I have concerns here:
<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:1= 3px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
1. the application is lazy and g= reedy. For example, yes detect 0-RTT, only allow GET, but don=E2=80=99t both= er with special flow credits that no-one understands, don=E2=80=99t think to= o hard, don=E2=80=99t save state, don=E2=80=99t analyze if GET actually PUT'= s. Greedy: yes Fast connection is better. We cannot hold hands, but this is t= he reality. We are not talking about years of web server development, but of= http enabled application endpoints with a development cycle of two days.

2. the stream is an attack v= ector on resources spent.

This makes me think that we need some hard defaults on flow credits and per= haps also stream max. Both to protect the transport (and potentially OS kern= el), and to simplify life for application developers who do not generally ha= ve a clue about these concerns. I can see this being set with configurable d= efaults, so I=E2=80=99, not sure what the drafts can enforce or help with he= re.

We=E2=80=99ve discussed this= in https= ://github.com/quicwg/base-drafts/issues/2360 and also in Tokyo. I t= hink the conclusion is essentially what you are suggesting.

The point we are discussing now is the remainder which is far less c= oncerning than the replay concerns at the application level :-)


Mikkel


On 6 February 2019 at 08.06.48, Kazu= ho Oku (kazuhooku@gmail.com) wrot= e:

2019=E5=B9=B42=E6=9C=886=E6=97=A5(=E6=B0=B4) 15:01 Martin Thomson <mt@lowentropy.net>:
>
> On Wed, Feb 6, 2019, at 16:24, Kazuho Oku wrote:
> > I think we can agree that 0-RTT is a concern for both the appl= ication
> > and the transport.
>
> My entire thesis here is that replay risks are primarily an applica= tion concern, so I can't agree. If you are willing to accept that the risk t= o transport is the far less severe DoS one, then I'd concede that. My latest= update to the PR should address that point. But transient costs, like the a= mount of CPU you spend on connections is entirely in server control, so I do= n't think that's the important point here. I'm concerned about things like d= ouble-spend, which exist only at the application layer.

I agree that the view that the risk to transport is far less severe
than the risk to the application, even though there is a risk.

I have just read the updated text on the PR. Looks perfect to me.
Thank you for writing that down.

>
> > For application, the precedence we have in TLS 1.3 is that eac= h
> > application protocol is required to create a profile specifyin= g how
> > 0-RTT data should be handled. My assumption is that we would b= e
> > following that.
>
> Yes, this is exactly the point. TLS 1.3 can't say what the risk of= replay is generically, only HTTP can say what the risk is for HTTP.
>
> > With that in mind, I think we agree that all frames
> > related to transmission of data (and streams) should be permit= ted.
>
> Sure, but the principle you are applying is YAGNI. I'm suggesting t= hat there is a better and simpler principle: applications own the responsibi= lity for replay risk.

Yeah, what I am trying to state here is that we share the view that
application should be responsible for handling replay of data.

>
> > The question is what to do with the frame types that control t= he
> > properties of the transport. We could either go with YAGNI, or= allow
> > them assuming that they do not pose a security concerns.
>
> My point is that the frames do not inherently carry a risk - it's t= he application of the information they carry that carries the real risk.
>
> > Regarding PING, I think there's a broader discussion about if i= t the
> > use should be limited to 1-RTT. If we are to continue forbiddi= ng use
> > of PING in Initial and Handshake packets, I do not think that t= here
> > would be a reason for an endpoint to send PING in a 0-RTT pack= ets.
> > OTOH, if we are to allow PING to be sent in Initial and Handsh= ake
> > packets, I think there's no strong reason to forbid that to be= sent in
> > a 0-RTT packet.
>
> PING is easy. It is trivially possible to show that a STREAM frame= with duplicated data produces the same effect. So the only question is whe= ther to allow people to save a few bytes to use PING instead.
>
> Whether it is advisable to send PING is not the question, and nor s= hould it be.
>
> > I think allowing CONNECTION_CLOSE in 0-RTT just causes confusi= on,
> > because the client cannot be sure if the peer would be able to= process
> > the frame contained in a 0-RTT packet. What a client should do= is
> > always send CONNECTION_CLOSE using an Initial packet or a Hand= shake
> > packet.
>
> This is a fine argument. And I would be OK with forbidding CONNECT= ION_CLOSE. CONNECTION_CLOSE is special enough, and the rules for generating= it during the handshake are already fraught; I think that forbidding CONNEC= TION_CLOSE in 0-RTT is a natural consequence of applying the changes we agre= ed here in Tokyo.
>
> > And there are only two frames that are debatable: NEW_CONNECTI= ON_ID,
> > PATH_CHALLENGE.
> >
> > Do we need to allow them? Does allowing those simplify the
> > specification or the implementations?
>
> I think that we do, but only because it would simplify clients. Yo= u could say that we know that it's 0-RTT, so we can do anything we like, but= that's not principled.
>
> Marten had an argument in favour of NEW_CONNECTION_ID. Sending it i= n 0-RTT could speed up moving to a privately negotiated connection ID (which= enables stateless reset).

I am not sure if it helps. A client needs to migrate to a different
address in order to enforce the peer to switch to a new CID. That
cannot happen before the handshake completes (which is going to be
signalled using the new frame). That means that there would be at
least 1 RTT between when the client obtains the 1-RTT write key and
when it can initiate a migration to use a different connection ID.
That's why I wonder if sending NEW_CONNECTION_ID in 0-RTT makes things
better, even ignoring the potential negative impact on path validation
and congestion control when the client migrates the connection.

> But to my earlier point, if a client wanted to send that frame, hav= ing to withhold sending is awkward for the same reason that holding a RESET_= STREAM would be. So I'd say yes to NEW_CONNECTION_ID.
>
> Having to decide to hold a frame at the client is an unnecessary im= position. Why should the client have to treat 0-RTT specially?

I think that's a fair argument, though I might point out that
regardless of the conclusion of this discussion, we'd need to hold
things until various events.

* Stream data needs to be held until either 0-RTT key or 1-RTT key
becomes available.
* Transport needs to notify the application when 1-RTT key becomes
available, otherwise it cannot support HTTP/3. This is because the
client is required to withhold reissuing a HTTP request in response to
425 until it obtains the 1-RTT key.
* Migration needs to be held until the handshake is complete.

The first two point shows that we need to do things at the moment when
1-RTT write key is obtained.

> Sure, there are things that it shouldn't be sending, but those all c= ome down to stuff that is enforced by the handshake state machine (e.g., you= can't send ACK because you can't read anything that could be acknowledged).= For that matter, as we discussed for the flow control matter, we don't wan= t to require a server to check that the client didn't comply in all cases li= ke this (though they SHOULD do so, as we agreed in https://github.com/quicwg/base-drafts/i= ssues/2360). Applying that logic, allowing PATH_CHALLENGE is fine, if a= little pointless.
>
> > Besides, I have a mild concern about allowing more frames to b= e sent
> > in 0-RTT, because it requires a server implementation to consi= der what
> > happens in case of a replay attack (note that because HTTP is c= apable
> > of mitigating 0-RTT replay attacks thanks to 425 Too Early, it= has so
> > far been possible to have a very lax defense against 0-RTT rep= lay in
> > TLS 1.3 stacks).
>
> I don't understand this point. That's an HTTP-layer concern, not a= QUIC one.

What I am trying to clarify is how you _tune_ your TLS 1.3 stack can
depend on how sensitive the application protocol is against replay
attacks. It is beneficial to be lax in when you accept 0-RTT, because
it improves the chance of reducing an RTT (e.g., should a server
accept ticket reuse when the client is doing happy eyeballs?).

My view is that minimizing the concerns unique to the transport layer
enables us to utilize 0-RTT as much as possible for a replay-resistant
protocol like HTTP.

-- =20
Kazuho Oku

= --Apple-Mail-09DBB8BD-E4B1-4A84-AEFF-4869B9957F18-- From nobody Wed Feb 6 00:37:31 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30247126C7E for ; Wed, 6 Feb 2019 00:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1y_CCte3BGN for ; Wed, 6 Feb 2019 00:37:25 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 BE09312426E for ; Wed, 6 Feb 2019 00:37:24 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id p197so4481449itp.0 for ; Wed, 06 Feb 2019 00:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=zUON0H6px660uSdmf7Vgn7UCYzojwPOfCbGllA0TFBc=; b=kwa4kr7Sc0cg4oH0PMIJW1h/dKP09ysuhnahY8DSr9j4A3CRZRcXECBjzFDOIshgbW yMpwBF0ymRoGV20+4We0GuoTQFtsARRHA9ngDwjEgml38fgdFospFr1xUg8oRMuOqi7x QoDYyir1WeQ6c3qDOLZGs/uf2ygIH9vGjLCem5VyiBiT1/nLkEVBbgagEeoTZhWmZhqK gZPYv/eQLmYQfIvu+p3/3NmHfuMXviAIow+AGIfgn4PaWF6/muHtevt4ud0mWj7V2auy yQ6lkC4XOBG8FrkvFKg6+0ncg3X6paBlHLuM+nqUUhpoG/Ut4y7xtmU/2cJCzlKpjibN oPqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=zUON0H6px660uSdmf7Vgn7UCYzojwPOfCbGllA0TFBc=; b=Or4nYan3gGbXIF8agDqDeZNjNs5V5ThOxSqyKkPF5+LenYOluT7rkIdui9wpsBLhtv h6Wg3qrbUBhhtxAipRlWeMTT/3SxuHWnK3g+1+kWzKX0BYp9nlbqkIjr5S0e6inkR5fy iOTE8aUpdX4eT6A1lNOeUeF1USCL+weDMgbnlmgZZbOQoWZE0/RO7sx8Z/YzbPy6ATi3 xaQz0rM1vj/8MraiFf3QZ7VkEco9IYSH7YLRMB1479e8aXh8iDvZr5Jt1YeYAxtg7S9w IXKyOgUKDOmRA+1KYiY8YTjtr/2qgPeSAmeLBQps+VnlVGDKkr6RBNnq1c+deMMnjJ52 cecQ== X-Gm-Message-State: AHQUAuaBvcdeRiBpZNKM2RO/dNnq+0QxknRoTV8nLaDGxzl1CjA1e8Rl 0UvBbw+2Uyx+u7tWoy0cktT22/7/4JOex1N9Z7M= X-Google-Smtp-Source: AHgI3IZIaac/5tjze2YERnXeSL888CLLccTCJCxF0uOuvNFZF9gbVdYsv6o9lFnFhdpkaSL3t5DQeo7UEPMW9qhd8Eg= X-Received: by 2002:a05:660c:58a:: with SMTP id g10mr1405306itk.167.1549442243928; Wed, 06 Feb 2019 00:37:23 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Feb 2019 00:37:22 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> <25ce934955dc4142b5758fc633661744@usma1ex-dag1mb6.msg.corp.akamai.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Feb 2019 00:37:22 -0800 Message-ID: Subject: Re: New path => new connection ID, right? To: "Lubashev, Igor" , Roberto Peon , Ted Hardie Cc: David Schinazi , Jana Iyengar , Mike Bishop , "quic@ietf.org" , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000008caa1a058135a2d8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 08:37:29 -0000 --0000000000008caa1a058135a2d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I share these concerns about linkability but the reality is that 1) that in many cases it is not practical to enforce 2) humans have learned to sequence DNA So it is insufficient to change shortly after the fact and it is problematic to kill a connection on a violation. Even if todays mobile network tend to keep a fixed IP address that is a weak assumption. Privacy really needs to be dealt with at the network routing level in a chicken and egg fashion. Consider a network like Tor that will attempt to switch IP address repeatedly if it gets a chance to do so. If QUIC just drops connections this defeats those efforts. OTOH if QUIC just publishes tracking cookies via CID=E2=80=99s this also defeats the purpose. So, for now, I think the best we can do is to encourage to change CID=E2=80= =99s immediately and disallow cases where it is obviously possible to avoid. Then look to the next generation of protocols and a longer timeline. Mikkel On 6 February 2019 at 00.53.36, Roberto Peon (fenix@fb.com) wrote: Two points: 1. A poorly implemented client can leak CIDs along other paths =E2=80=9Cintentionally=E2=80=9D. Providing a direct signal on this is li= kely to raise awareness. That said, I don=E2=80=99t much care because: 2. Is this really important? Will the protocol fail our users in some interesting way without changing this? -=3DR *From: *QUIC on behalf of "Lubashev, Igor" < ilubashe@akamai.com> *Date: *Tuesday, February 5, 2019 at 3:13 PM *To: *Ted Hardie *Cc: *Jana Iyengar , Mike Bishop = , David Schinazi , "quic@ietf.org" , Martin Thomson , Kazuho Oku *Subject: *RE: New path =3D> new connection ID, right? - I disagree that these are the same I understood the question to be about routing packets from a new IP address to the original backend. The migration of the tethering device is the same as the migration of the client *from the routing perspective* within the destination network (which may be comprised of multiple anycast pops). - That means that there is no way to truly prevent CID migration here within QUIC, only to limit the time it is in place. The purpose of this =E2=80=9CMUST terminate the connection=E2=80=9D proposa= l was to improve privacy. There is little to be gained by cutting off the connection, once even a single packet has exposed the original CID to the new path. It=E2= =80=99s not like multiple packets provide a stronger linkability signal than a just one packet. We may wish to =E2=80=9Cpunish=E2=80=9D buggy implementations = to induce their vendors to do better, but the client implementation cannot do any better in this case. - The only other option I see offhand would be to suggest that the connected forwarder terminate the links to induce something like a DHCPRELEASE and RENEW, but this seems slow, fragile, and unlikely to deploy. Right. This network attachment change notification would be a subject to a different draft in a different WG, and its deployment would be slow. - Igor *From:* Ted Hardie *Sent:* Tuesday, February 05, 2019 5:41 PM *To:* Lubashev, Igor *Cc:* Jana Iyengar ; David Schinazi < dschinazi.ietf@gmail.com>; quic@ietf.org; Mike Bishop ; Martin Thomson ; Kazuho Oku *Subject:* Re: New path =3D> new connection ID, right? *Importance:* High On Tue, Feb 5, 2019 at 1:33 PM Lubashev, Igor wrote: - But if the phone/hotspot's IP address changes during this from one provider's set of addresses to another, this is functionally re-homing. = In that case, isn't there already a high risk that the traffic will end up = at a different back end because of the IP change? Yes, this is the scenario =E2=80=93 the phone (or your car=E2=80=99s uplink= , if connected to an in-car wifi) has switched to a different provider. This is no different than a usual cell<->wifi migration case from the routing perspective, and the purpose of server-generated connection ID on client-to-server packets is to facilitate routing to the correct backend. I disagree that these are the same. In the common case for cell<-->wifi migration the connected device is aware of the interface change. Because the connected device is now serving as a forwarder for the packets of others, the tethered device cannot detect the sort of interface change. It's a path change to the tethered device, not an interface change. Christian has pointed out a way to use v6 RA to indicate that rehoming has occurred and to signal that to the tethered device. This isn't as straightforward in a v4 NAT situation, unfortunately. For example, if the packet arrives at a different anycast pop, the identify of the original pop is encoded in the connection ID, and the packet can be tunneled to that pop (or directly to the correct backend within the same or a different pop). This will still work if it uses a previous assigned but unused CID, if it has detected migration. And I think that's the key issue here; the tethered device has no way to detect migration, and so no local trigger for a CID change. That means that there is no way to truly prevent CID migration here within QUIC, only to limit the time it is in place. Having the server terminate and firing off 0-RTT is one way to limit that timing, but we have to acknowledge that it is at best a mitigation. The only other option I see offhand would be to suggest that the connected forwarder terminate the links to induce something like a DHCPRELEASE and RENEW, but this seems slow, fragile, and unlikely to deploy. Ted - Igor *From:* Ted Hardie *Sent:* Tuesday, February 05, 2019 2:28 PM *To:* Lubashev, Igor *Cc:* Jana Iyengar ; David Schinazi < dschinazi.ietf@gmail.com>; quic@ietf.org; Mike Bishop ; Martin Thomson ; Kazuho Oku *Subject:* Re: New path =3D> new connection ID, right? Hi Igor, I have a clarifying question on the scenario below. On Tue, Feb 5, 2019 at 10:28 AM Lubashev, Igor wrote: - Egregious changes in IP might be a signature for network change (change in /16 address, for instance) and a server could terminate the connection and respond with a stateless reset if this happens. The client could be a laptop that is tethered via a phone that is changing providers. The disconnect would be completely =E2=80=9Cpunitive=E2=80=9D (= the old path=E2=80=99s CID has already been sent over the new path) and be punishing the client for something it had no control over whatsoever. In this scenario, what is your view of where the IP address changes are taking place? I agree that the device connected to a phone (e.g. by a mobile hotspot) will not generally have a view of the change in upstream path. If that phone is using something like mobile IP or a VPN to have a consistent external address, then I also don't see why this path change would trigger any change in CID. But if the phone/hotspot's IP address changes during this from one provider's set of addresses to another, this is functionally re-homing. In that case, isn't there already a high risk that the traffic will end up at a different back end because of the IP change? Thanks for sharing your thoughts on this, Ted - Igor *From:* Jana Iyengar *Sent:* Tuesday, February 05, 2019 6:42 AM *To:* David Schinazi *Cc:* quic@ietf.org; Mike Bishop ; Martin Thomson < mt@lowentropy.net>; Kazuho Oku *Subject:* Re: New path =3D> new connection ID, right? I agree that want to have MUST for changing CID and MUST NOT for sending packets with the same CID on multiple paths. I thought we had agreed on this in the past, but I could be misremembering. I understand that the server cannot necessarily tell this from NAT rebinding, but it is up to the server what it does if it sees an IP/port change with no accompanying CID change. Egregious changes in IP might be a signature for network change (change in /16 address, for instance) and a server could terminate the connection and respond with a stateless reset if this happens. A client that ignores the MUST and uses the same CID across networks would then risk getting the connection terminated. I suggest that we add some discussion about potential server responses to clients that violate normative expectations. On Tue, Feb 5, 2019 at 8:13 AM David Schinazi wrote: At the end of the day, you can make it a MUST, but clients will do what they please because servers can't enforce it. But I won't die on this hill, I can live with being declared in the rough on this one. David On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku wrote: 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi : > > If an endpoint intentionally migrates and it has unused connection IDs to use, it makes sense to mandate it MUST switch to one of the unused connection IDs. > However, if it has run out of unused connection IDs then I would let the endpoint decide if it wants to close the connection or migrate with a previously used connection IDs, as there are use-cases that value performance over non-linkability. I think I might prefer encouraging endpoints to gracefully close the connection before it faces a trade-off between performance and linkability. Therefore, assuming that we adopt Martin's proposal, I think it would make sense to recommend an endpoint to send GOAWAY when if it can no longer issue a new CID for that QUIC connection. > Finally, this cannot be enforced by the peer since it cannot distinguish intentional migration and unintentional migration (NAT rebinding), and we discussed in Tokyo that we wanted to avoid non-enforceable MUSTs. > > David > > On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop wrote: >> >> The text is there, but it's perhaps not complete: >> >> As discussed in Section 9.5, each connection ID MUST be used on packets sent from only one local address. An endpoint that migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address. >> >> >> >> The gap seems to be that when your peer moves to a new address, there=E2= =80=99s no requirement that you not send the same CID to their new address that you used toward their old address. >> >> >> >> -----Original Message----- >> From: QUIC On Behalf Of Martin Thomson >> Sent: Monday, February 4, 2019 3:15 PM >> To: quic@ietf.org >> Subject: New path =3D> new connection ID, right? >> >> >> >> I thought that we had agreed that an endpoint that intentionally migrates has to use a new connection ID on the new path. But I couldn't find any "MUST" in the spec that said that. >> >> >> >> On the off chance that this wasn't just a mistake and there was some good reason not to mandate this, I'm bringing the discussion here. >> >> >> >> I've opened a design issue: >> >> https://github.com/quicwg/base-drafts/issues/2413 >> >> >> >> The change I'm proposing is here: >> >> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995= 236dda960b4cdff49e36f >> >> --=20 Kazuho Oku --0000000000008caa1a058135a2d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I share these concer= ns about linkability but the reality is that

1) that in many cases it is not practical to enforc= e
2) humans h= ave learned to sequence DNA

So it is insufficient to change shortly after the fact and it is pro= blematic to kill a connection on a violation.
Even if todays mobile network tend to keep= a fixed IP address that is a weak assumption.

Privacy really needs to be dealt with at the netw= ork routing level in a chicken and egg fashion.
Consider a network like Tor that will at= tempt to switch IP address repeatedly if it gets a chance to do so. If QUIC= just drops connections this defeats those efforts. OTOH if QUIC just publi= shes tracking cookies via CID=E2=80=99s this also defeats the purpose.

So, for now, I think the = best we can do is to encourage to change CID=E2=80=99s immediately and disa= llow cases where it is obviously possible to avoid. Then look to the next g= eneration of protocols and a longer timeline.

Mikkel

On 6 February 2019 at 00.53.36, = Roberto Peon (fenix@fb.com) wrote:

=

Two points:

  1. A poorly implement= ed client can leak CIDs along other paths =E2=80=9Cintentionally=E2=80=9D. = Providing a direct signal on this is likely to raise awareness. That said, = I don=E2=80=99t much care because:
  2. Is this really important? Will the protocol fail our u= sers in some interesting way without changing this?

=C2=A0

-=3DR

=C2=A0

From= : QUIC <quic-bounces@ietf.org> on behalf o= f "Lubashev, Igor" <ilu= bashe@akamai.com>
Date: Tuesday, February 5, 2019 at 3:13 PM
To: Ted Hardie <ted.ietf@gm= ail.com>
Cc: Jana Iyengar <jri.ietf@= gmail.com>, Mike Bishop <= mbishop@evequefou.be>, David Schinazi <dschinazi.ietf@gmail.com>, "quic@ietf.org" <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>, Kazuho Oku <kazuhooku@gmail.com>
Subject: RE: New path =3D> new connection ID, right?

=C2=A0

  • I disagree that th= ese are the same

=C2=A0

I understood the question to be about routing packet= s from a new IP address to the original backend.=C2=A0 The migration of the= tethering device is the same as the migration of the client from the routing perspective within the destination network (which m= ay be comprised of multiple anycast pops).

=C2=A0

  • That means that th= ere is no way to truly prevent CID migration here within QUIC,=C2=A0 only t= o limit the time it is in place.

=C2=A0

The purpose of this =E2=80=9CMUST terminate the conn= ection=E2=80=9D proposal was to improve privacy. There is little to be gain= ed by cutting off the connection, once even a single packet has exposed the= original CID to the new path.=C2=A0 It=E2=80=99s not like multiple packets provide a stronger linkability signal than a just one packet.=C2= =A0 We may wish to =E2=80=9Cpunish=E2=80=9D buggy implementations to induce= their vendors to do better, but the client implementation cannot do any be= tter in this case.

=C2=A0

  • The only other opt= ion I see offhand would be to suggest that the connected forwarder terminat= e the links to induce something like a DHCPRELEASE and RENEW, but this seem= s slow,=C2=A0 fragile, and unlikely to deploy.

=C2=A0

Right.=C2=A0 This network attachment change notifica= tion would be a subject to a different draft in a different WG, and its dep= loyment would be slow.

=C2=A0

  • Igor

=C2=A0

=C2=A0

From: Ted Hardie <ted.ietf@gmail.com>
Sent: Tuesday, February 05, 2019 5:41 PM
To: Lubashev, Igor <ilubas= he@akamai.com>
Cc: Jana Iyengar <jri.ietf@= gmail.com>; David Schinazi <dschinazi.ietf@gmail.com>; q= uic@ietf.org; Mike Bishop <m= bishop@evequefou.be>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: New path =3D> new connection ID, right?
Importance: High

=C2=A0

On Tue, Feb 5, 2019 at 1:33 PM Lubashev, Igor <ilubashe@akamai.com> wrote:

  • But if the phone/hotspot's IP address changes during this from one prov= ider's set of addresses to another, this is functionally re-homing.=C2= =A0 In that case, isn't there already a high risk that the traffic will= end up at a different back end because of the IP change?

=C2=A0

Yes, this is the scenario =E2=80=93 the phone (or your car=E2=80= =99s uplink, if connected to an in-car wifi) has switched to a different pr= ovider.

=C2=A0

This is no different than a usual cell<->wifi migration case= from the routing perspective, and the purpose of server-generated connecti= on ID on client-to-server packets is to facilitate routing to the correct backend. =C2=A0

=C2=A0

I disagree that these are the same.=C2=A0 In the com= mon case for cell<-->wifi migration the connected device is aware of = the interface change.=C2=A0 Because the connected device is now serving as = a forwarder for the packets of others, the tethered device cannot detect the sort of interface change.=C2=A0 It's a path c= hange to the tethered device, not an interface change.=C2=A0 Christian has = pointed out a way to use v6 RA to indicate that rehoming has occurred and t= o signal that to the tethered device.=C2=A0 This isn't as straightforward in a v4 NAT situation, unfortunately.

=C2=A0

For example, if the packet arrives at a different anycast pop, the= identify of the original pop is encoded in the connection ID, and the pack= et can be tunneled to that pop (or directly to the correct backend within the same or a different pop).

=C2=A0

This will still work if it uses a previous assigned = but unused CID, if it has detected migration.=C2=A0

=C2=A0

And I think that's the key issue here; the tethe= red device has no way to detect migration, and so no local trigger for a CI= D change.=C2=A0 That means that there is no way to truly prevent CID migrat= ion here within QUIC,=C2=A0 only to limit the time it is in place.=C2=A0 Having the server terminate and firing off 0-RTT is = one way to limit that timing, but we have to acknowledge that it is at best= a mitigation.=C2=A0 The only other option I see offhand would be to sugges= t that the connected forwarder terminate the links to induce something like a DHCPRELEASE and RENEW, but this seems slo= w,=C2=A0 fragile, and unlikely to deploy.

=C2=A0

Ted

=C2=A0

=C2=A0

=C2=A0

=C2=A0

  • Igor

=C2=A0

From: Ted Hardie <ted.ietf@gmail.com>
Sent: Tuesday, February 05, 2019 2:28 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>; David Schinazi <dschinazi.ietf@gmail.com>= ; quic@ietf.org; Mike = Bishop <mbisho= p@evequefou.be>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <kazuhooku= @gmail.com>
Subject: Re: New path =3D> new connection ID, right?

=C2=A0

Hi Igor,

=C2=A0

I have a clarifying question on the scenario below.

=C2=A0

On Tue, Feb 5, 2019 at 10:28 AM Lubashev, Igor <ilubashe@akamai.com> wrote= :

  • Egregious changes in IP might be a signature for network change (change in = /16 address, for instance) and a server could terminate the connection and = respond with a stateless reset if this happens.

=C2=A0

The client could be a laptop that is tethered via a phone that is = changing providers.=C2=A0 The disconnect would be completely =E2=80=9Cpunit= ive=E2=80=9D (the old path=E2=80=99s CID has already been sent over the new path) and be punishing the client for something it had no control = over whatsoever.

=C2=A0

=C2=A0

In this scenario, what is your view of where the IP address change= s are taking place?

=C2=A0

I agree that the device connected to a phone (e.g. by a mobile hot= spot) will not generally have a view of the change in upstream path.=C2=A0 = If that phone is using something like mobile IP or a VPN to have a consistent external address, then I also don't s= ee why this path change would trigger any change in CID.=C2=A0 But if the p= hone/hotspot's IP address changes during this from one provider's s= et of addresses to another, this is functionally re-homing.=C2=A0 In that case, isn't there already a high risk that th= e traffic will end up at a different back end because of the IP change?

=C2=A0

Thanks for sharing your thoughts on this,

=C2=A0

Ted

=C2=A0

  • Igor

=C2=A0

From: Jana Iyengar <jri.ietf@gmail.com>
Sent: Tuesday, February 05, 2019 6:42 AM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: quic@ietf.org= ; Mike Bishop <mbishop@evequefou.be>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <ka= zuhooku@gmail.com>
Subject: Re: New path =3D> new connection ID, right?

=C2=A0

I agree that want to have MUST for changing CID and MUST NOT for s= ending packets with the same CID on multiple paths.=C2=A0 I thought we had = agreed on this in the past, but I could be misremembering.

=C2=A0

I understand that the server cannot necessarily tell this from NAT= rebinding, but it is up to the server what it does if it sees an IP/port c= hange with no accompanying CID change.=C2=A0 Egregious changes in IP might be a signature for network change (change in= /16 address, for instance) and a server could terminate the connection and= respond with a stateless reset if this happens.=C2=A0 A client that ignore= s the MUST and uses the same CID across networks would then risk getting the connection terminated.=C2=A0 I sugges= t that we add some discussion about potential server responses to clients t= hat violate normative expectations.

=C2=A0

On Tue, Feb 5, 2019 at 8:13 AM David Schinazi <dschinazi.ietf@gmail.com&= gt; wrote:

At the end of the day, you can make it a MUST, but clients will do= what they please because servers can't enforce it.

But I won't die on this hill, I can live with being declared i= n the rough on this one.

=C2=A0

David

=C2=A0

On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku <kazuhooku@gmail.com> wrote:

2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi <dschinazi.ietf@gmail.com>:
>
> If an endpoint intentionally migrates and it has unused connection IDs= to use, it makes sense to mandate it MUST switch to one of the unused conn= ection IDs.
> However, if it has run out of unused connection IDs then I would let t= he endpoint decide if it wants to close the connection or migrate with a pr= eviously used connection IDs, as there are use-cases that value performance= over non-linkability.

I think I might prefer encouraging endpoints to gracefully close the
connection before it faces a trade-off between performance and
linkability.

Therefore, assuming that we adopt Martin's proposal, I think it would make sense to recommend an endpoint to send GOAWAY when if it can no
longer issue a new CID for that QUIC connection.

> Finally, this cannot be enforced by the peer since it cannot distingui= sh intentional migration and unintentional migration (NAT rebinding), and w= e discussed in Tokyo that we wanted to avoid non-enforceable MUSTs.
>
> David
>
> On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop <mbishop@evequefou.be> wrote:
>>
>> The text is there, but it's perhaps not complete:
>>
>> As discussed in Section 9.5, each connection ID MUST be used on pa= ckets sent from only one local address. An endpoint that migrates away from= a local address SHOULD retire all connection IDs used on that address once= it no longer plans to use that address.
>>
>>
>>
>> The gap seems to be that when your peer moves to a new address, th= ere=E2=80=99s no requirement that you not send the same CID to their new ad= dress that you used toward their old address.
>>
>>
>>
>> -----Original Message-----
>> From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Thomson
>> Sent: Monday, February 4, 2019 3:15 PM
>> To: quic@ietf.o= rg
>> Subject: New path =3D> new connection ID, right?
>>
>>
>>
>> I thought that we had agreed that an endpoint that intentionally m= igrates has to use a new connection ID on the new path.=C2=A0 But I couldn&= #39;t find any "MUST" in the spec that said that.
>>
>>
>>
>> On the off chance that this wasn't just a mistake and there wa= s some good reason not to mandate this, I'm bringing the discussion her= e.
>>
>>
>>
>> I've opened a design issue:
>>
>> https://github.com/quicwg/base-drafts/issues/2413
>>
>>
>>
>> The change I'm proposing is here:
>>
>> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995= 236dda960b4cdff49e36f
>>
>>



--
Kazuho Oku

--0000000000008caa1a058135a2d8-- From nobody Wed Feb 6 00:40:53 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9892212867A for ; Wed, 6 Feb 2019 00:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, 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 LhRbrTQChyHl for ; Wed, 6 Feb 2019 00:40:48 -0800 (PST) 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 63E1112426E for ; Wed, 6 Feb 2019 00:40:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EED51BE55; Wed, 6 Feb 2019 08:40:46 +0000 (GMT) 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 3y8zlGCLpEHz; Wed, 6 Feb 2019 08:40:45 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8FE9BBE39; Wed, 6 Feb 2019 08:40:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1549442445; bh=JfpnrfRl964CP050axy4Wzzo3KuB9sJTO5vw3n1Zu00=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iApMqsWy5CbCR11SLMHzZ70c351uqlBvGFMsv6X3cfF6ub+5yDozEEdlUCvHfuKJj waE/hiC2rKCcam5lcjS05sS//cU0P6HLNqBYvV6NxwJkN7cZyCx5O6XyhX0/u77BbR A9DFHM4wlM4sn/UsIwo9GbKTkpyFOtmBCWsgwQTo= Subject: Re: Allowed frames in 0-RTT To: Martin Thomson , quic@ietf.org References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> Date: Wed, 6 Feb 2019 08:40:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OSVqSL1VHuX2QLhM3OZerfTSb92vjlKQa" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 08:40:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OSVqSL1VHuX2QLhM3OZerfTSb92vjlKQa Content-Type: multipart/mixed; boundary="Q8EcbnnNKtX76YwAFn1Zu48hATDYMjoL4"; protected-headers="v1" From: Stephen Farrell To: Martin Thomson , quic@ietf.org Message-ID: <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> Subject: Re: Allowed frames in 0-RTT References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> In-Reply-To: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> --Q8EcbnnNKtX76YwAFn1Zu48hATDYMjoL4 Content-Type: multipart/mixed; boundary="------------2A88C1DFD843CFD0FC7EDBBC" Content-Language: en-GB This is a multi-part message in MIME format. --------------2A88C1DFD843CFD0FC7EDBBC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable piping in from the sidelines so I don't expect this to be found so convincing, however... On 06/02/2019 04:11, Martin Thomson wrote: > it would be a mistake to try to make decisions about 0-RTT safety in > the transport, when replay risks are an application-layer concern. I believe that is not true for some decisions. If the WG decide to disallow something that could cause an application layer concern then that will remove the need to do application layer analyses of replay/0-rtt for those cases. Given application devs will in general not do those analyses, disallowing as much as you can (of the risks arising from 0-rtt) in the transport seems safer to me. If you want to name a principle ISTM that 0-rtt is a quite like a dangerous implement, which seems better avoided as far as possible. One question though - do we have any information about real world 0-rtt issues arising in http/tls1.3 or is it still too early? If we did have such information that may better inform this discussion. Cheers, S. --------------2A88C1DFD843CFD0FC7EDBBC Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------2A88C1DFD843CFD0FC7EDBBC-- --Q8EcbnnNKtX76YwAFn1Zu48hATDYMjoL4-- --OSVqSL1VHuX2QLhM3OZerfTSb92vjlKQa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxanYwACgkQWrL68XsX K+qVgA//YlvwnRhLn91DhMVRzANTMoa7XEPtr1wjwkh+4H9/5raLAdgbknLHMVSD PWTOIHQXOq4tjHsNtcQVeAdO0IW1YxiWiAzRkSaGqetRqzk0HmKUZai/FPfDhnA/ q4QtHXAhO3IjpF2NtEoNprJyKYAySl4FG/ryADPIBu0tyme3V3xOE3O8kU7UKqel VYql3P8jw21e6i3Th0dPTlKCwmiDEuwxB+pzTcQrSDTz9W2ajW9iX46lohck1RoS kEjnqXJ0Ru++/d3yW/iKTG1Mra+zyf8dJTrPqZVgqWt2pkhtizQ9zP6SdfomNDgU aVDgvNnuAgZ0jAQ9Ukg7ho9t5n6U0Zd5XqWmSKm9VudtnfDjdk8lmqTV3ZBkFE9L Qdd9Z3YsjZmW1uH3eqSSFWQZ8fpPVlT3jZfqlQ+tKt4VF1iOvwiowZjtAp+X5kPC N1Xcb/oBCf3D8oWfsg1kiXtvIS5OLl8pj0Ubkydl/6opMhvc9jOBgvJc8tbBTWYm SFb0cUp46vHWdbpHqTy6nDPWsQZZLzhpXeFSLeCEaeZiVVp16G963IDQmvfO9W2l pyj/gZjzxR4kxDckcjZAQgSk8AywvLeJrNlrLk2j2D1vgbpOoWleCuTwHxUGutPn ulFzkf9AfbU73HgEgs4l2acmVDmf6NX5/QAF6ZYRcYH1OTpvSTc= =CxD6 -----END PGP SIGNATURE----- --OSVqSL1VHuX2QLhM3OZerfTSb92vjlKQa-- From nobody Wed Feb 6 00:56:25 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A76126C7E for ; Wed, 6 Feb 2019 00:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsxU8bO-ge2I for ; Wed, 6 Feb 2019 00:56:22 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 0220712426E for ; Wed, 6 Feb 2019 00:56:22 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id h193so4478748ita.5 for ; Wed, 06 Feb 2019 00:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=21gaqt2p9W1JVvUx7i316STxHeNYnxLj3lgdwZtqv6A=; b=IhQRq43DNLUKTEQNxmr2LMJNkd5eW40r6jGpIggCcIC269vtNB6NQ1lZg9jgZwbnVY w+qjOdKRN98bUtnXjB1sPIT0T+0qa/KSd6361L03EXKmojSDE/qY0tTvuSs010CmQITS jtprZk4+NdNODShuLLH414D/iUtrgDufLSvZoEj5ybPO8280s0JvOolLj/W/BPVP1sGE aHuTSEee0Z5h7HWgzSPgpG0GZK07abxGf69ugpmU8iyvx7dnUXefPAA9+q/kJXUpWgVm e0WgARiTKAX2UCvziHJ5CrCMP3Svg6SAhMusJ87RaAb0KCLLK+6Fe+jByyIDA2oevz7W //Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=21gaqt2p9W1JVvUx7i316STxHeNYnxLj3lgdwZtqv6A=; b=bxUrbNTlgRL+6helDqcDTJfwvBnBARgfQiOXB5CdIkUpdtH2RLFaLsIJPbaQNFOexO oUOHgkgCHx/akJQzXTLBgVBEtt0bQAz6E+gdmPsrtDcVVHZhIlYNHddNyTr3z9UVJSmO gQ4DHJaOn2dk457HsetZ+M4vG4Yo/urLJYXrNMQq3cRg8NmKuyfI9Iwbo8j0kbWtGCvV Pj61frn2mHHlrsoWwHQVyW+jHzvVLZQrAyi70F1yefur4kuD5AXbhNjlO5Of7IKr5755 xXCFfns3Q3jljRI1d7koTUmETIJkMROZy3E1ikim6zdFugqX7yN1EpTB8V/q9U/jDIIj QemQ== X-Gm-Message-State: AHQUAuZCOl8nOy1yd08s+PuFfgVI4Tt6cWhf2xUWAR3rGasLk2XhrEGQ 6fNQcUTC8sGKQ3FWWA9c9Llc348QCLPkQdRGqiv2/coD X-Google-Smtp-Source: AHgI3Ibsfbr+TqrvNRVPxSQLe/qb2jr0G1gTlRJJESMv+zGgau0kSwoqqUYb9kloacPkrkEEPBjJHZpLNjHxQV0RNR4= X-Received: by 2002:a02:2303:: with SMTP id u3mr5143339jau.42.1549443381227; Wed, 06 Feb 2019 00:56:21 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Feb 2019 00:56:20 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Feb 2019 00:56:20 -0800 Message-ID: Subject: Re: Allowed frames in 0-RTT To: Stephen Farrell , Martin Thomson , quic@ietf.org Content-Type: multipart/alternative; boundary="0000000000005675bc058135e66a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 08:56:24 -0000 --0000000000005675bc058135e66a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I came to think about the recent discussion about interception of the replay token by a man on the side. Here it was pointed out that it would be practical to enforce single token use because 1. the retry to goes to server designated CID 2. the token can have a timestamp We could do the same with 0-RTT (I think) There has previously been discussions on the CID used in 0-RTT - whether it is the original random CID or a server designated. But if 0-RTT uses the same approach as single use retry tokens, then it should be practical to enforce no replay. Of course data centers can work around this if they care enough with the risks involved and moved to the application layer - so the draft could have an escape hatch for that. Such an enforcement would make the 0-RTT more short lived and at higher risk of being rejected, but I don=E2=80=99t think that is a major concern. Also, 0-RTT tokens can allow servers to track anonymous end users, so limiting their life time is a good thing. Maybe more important than the discussion on migration linkability. Mikkel On 6 February 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.tcd.ie) wrote: piping in from the sidelines so I don't expect this to be found so convincing, however... On 06/02/2019 04:11, Martin Thomson wrote: > it would be a mistake to try to make decisions about 0-RTT safety in > the transport, when replay risks are an application-layer concern. I believe that is not true for some decisions. If the WG decide to disallow something that could cause an application layer concern then that will remove the need to do application layer analyses of replay/0-rtt for those cases. Given application devs will in general not do those analyses, disallowing as much as you can (of the risks arising from 0-rtt) in the transport seems safer to me. If you want to name a principle ISTM that 0-rtt is a quite like a dangerous implement, which seems better avoided as far as possible. One question though - do we have any information about real world 0-rtt issues arising in http/tls1.3 or is it still too early? If we did have such information that may better inform this discussion. Cheers, S. --0000000000005675bc058135e66a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I came to think abou= t the recent discussion about interception of the replay token by a man on = the side.
Her= e it was pointed out that it would be practical to enforce single token use= because

=
1. the retry= to goes to server designated CID
2. the token can have a timestamp

We could do the same with 0-RTT (I thin= k)
There has = previously been discussions on the CID used in 0-RTT - whether it is the or= iginal random CID or a server designated.
But if 0-RTT uses the same approach as single = use retry tokens, then it should be practical to enforce no replay.
Of course data cente= rs can work around this if they care enough with the risks involved and mov= ed to the application layer - so the draft could have an escape hatch for t= hat.

Such an enforcem= ent would make the 0-RTT more short lived and at higher risk of being rejec= ted, but I don=E2=80=99t think that is a major concern.

Also, 0-RTT tokens can allow servers to = track anonymous end users, so limiting their life time is a good thing. May= be more important than the discussion on migration linkability.

Mikkel


On 6 February = 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.tcd.ie) wrote:


piping in from the sidelines so I don't expect this to be found so
convincing, however...

On 06/02/2019 04:11, Martin Thomson wrote:
> it would be a mistake to try to make decisions about 0-RTT safety = in
> the transport, when replay risks are an application-layer concern.
I believe that is not true for some decisions.

If the WG decide to disallow something that could cause an application
layer concern then that will remove the need to do application layer
analyses of replay/0-rtt for those cases. Given application devs will
in general not do those analyses, disallowing as much as you can (of
the risks arising from 0-rtt) in the transport seems safer to me.

If you want to name a principle ISTM that 0-rtt is a quite like a
dangerous implement, which seems better avoided as far as possible.

One question though - do we have any information about real world
0-rtt issues arising in http/tls1.3 or is it still too early? If we
did have such information that may better inform this discussion.

Cheers,
S.
--0000000000005675bc058135e66a-- From nobody Wed Feb 6 01:01:51 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A84F128CF2 for ; Wed, 6 Feb 2019 01:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM5RRYsWCequ for ; Wed, 6 Feb 2019 01:01:47 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 083CB126C7E for ; Wed, 6 Feb 2019 01:01:47 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id p6so1742023wmc.1 for ; Wed, 06 Feb 2019 01:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AuPHauwLzlwh7k8TG5C8267icghjJ7ju3mL2tkzPcBE=; b=TaLGJ1+E27/74WhGgi4n0mT/6DxZ2XF3NaZHAMvhJQqxuJ+Gf3r4HN5o/P+CVJghIn HDihP5NLcNFIs+xlBQxrK+dG0iWPqz3yW+tVwB+3YuNHgS9PqKJ+wuxMMhuU5YK842+Z zbBC8dAyh6cQJaG7DQXsY70vXKZ9msRYj0dx1iTRtcderoOrMm5mZLFn+SASWo06fE09 KYFafviVcSdvAtsmMXeygTL3r3YmpYODcVsLC2vjhV6f9V5YM6wDWnbkFvcxSmyxcuCL IZRkwuBTauR/fnFBEVz7hDAW8dL8Zlk5uIr4RDumeEJ2pXmSBujBk0JNNbLgbCPZ+8n0 q6rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AuPHauwLzlwh7k8TG5C8267icghjJ7ju3mL2tkzPcBE=; b=EIRWf4DKLq2EigT6+eqM2D8d6sT/P4pmGl6/JbehQHFyp6QhwMU7ewtRhuyiWN4f5G CdCrlrmduHS2kOB7U8YHiUaAyo/Qx/l+T7bgFBAKzRUnnRRaiqWB5pNpEcFufirN0T1I 9b0drPvgWDSPCF1Jkmws7mrYndZLmbgy1W7oXh7wl25SLvcLIy9/YDPOLMtL/e9GGi4T 98R6di49jKVP1RprAZr7PEBXjeca887J/XuIqrG0cbgxBuQS5rh44NoLZCWd8T4i12Fo 8D7hdt+Cs+lsHME/cQ25Vm4RdmlRDtYhDIiXgjEL2Ty3lPMvPbtTNXmRRFtQjQmqUxe2 m4Bw== X-Gm-Message-State: AHQUAubNy0/QkBRq0DOYnchheXZ2zDQ78cpdUCa3f+XBp8qIJxslGRUR /UJf2/9f4N5nkbN7D6wiTSK97MtGlwEJvpwvmrRdxg== X-Google-Smtp-Source: AHgI3IauwPp9ob1xPRYawqh6fddZN/GAT/qFczWkqHMFXuEpIS/5QgeQLrUpO3eFppMP+ShRiU4xhMNH9wp4wSdCPvU= X-Received: by 2002:a1c:bd86:: with SMTP id n128mr2219910wmf.22.1549443705084; Wed, 06 Feb 2019 01:01:45 -0800 (PST) MIME-Version: 1.0 References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> In-Reply-To: <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> From: Ian Swett Date: Wed, 6 Feb 2019 04:01:32 -0500 Message-ID: Subject: Re: Allowed frames in 0-RTT To: Stephen Farrell Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000a48de4058135f9ae" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 09:01:49 -0000 --000000000000a48de4058135f9ae Content-Type: text/plain; charset="UTF-8" I agree with Martin's analysis and principles, and I think the PR is good, though I'd prefer to allow CONNECTION_CLOSE in 0-RTT(see below) Frames that are disallowed are already largely disallowed due to other requirements in the transport draft: *CRYPTO* is disallowed because 0-RTT is not used for the handshake *ACK* frames are disallowed because there are no 1-RTT packets to ACK *RETIRE_CONNECTION_ID* is disallowed because the client has received no connection IDs from the peer and they can't retire the CID they're using. *PATH_RESPONSE* - You haven't received a PATH_CHALLENGE yet if you haven't received anything. *NEW_TOKEN* - Only a server can send this and 0-RTT is client-only *CONNECTION_CLOSE*- I don't see a reason to disallow this one, but the text requires sending it at an encryption level the peer can process, so it's also not that useful. In practice, if you disallow it, there's not a large behavior change. Either you close the connection because the peer asked or you close the connection because the frame is invalid in 0-RTT. On Wed, Feb 6, 2019 at 3:41 AM Stephen Farrell wrote: > > piping in from the sidelines so I don't expect this to be found so > convincing, however... > > On 06/02/2019 04:11, Martin Thomson wrote: > > it would be a mistake to try to make decisions about 0-RTT safety in > > the transport, when replay risks are an application-layer concern. > I believe that is not true for some decisions. > > If the WG decide to disallow something that could cause an application > layer concern then that will remove the need to do application layer > analyses of replay/0-rtt for those cases. Given application devs will > in general not do those analyses, disallowing as much as you can (of > the risks arising from 0-rtt) in the transport seems safer to me. > > If you want to name a principle ISTM that 0-rtt is a quite like a > dangerous implement, which seems better avoided as far as possible. > > One question though - do we have any information about real world > 0-rtt issues arising in http/tls1.3 or is it still too early? If we > did have such information that may better inform this discussion. > > Cheers, > S. > --000000000000a48de4058135f9ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Martin's analysis and principles, and I t= hink the PR is good, though I'd prefer to allow CONNECTION_CLOSE in 0-R= TT(see below)

Frames that are disallowed are already lar= gely disallowed due to other requirements in the transport draft:
=C2=A0CRYPTO is disallowed because 0-RTT is not used for the handsh= ake
=C2=A0ACK frames are disallowed because there are no 1= -RTT packets to ACK
=C2=A0RETIRE_CONNECTION_ID is disallow= ed because the client has received no connection IDs from the peer and they= can't retire the CID they're using.
=C2=A0PATH_RESPON= SE - You haven't received a PATH_CHALLENGE yet if you haven't r= eceived anything.
=C2=A0NEW_TOKEN - Only a server can send= this and 0-RTT is client-only
=C2=A0CONNECTION_CLOSE- I d= on't see a reason to disallow this one, but the text requires sending i= t at an encryption level the peer can process, so it's also not that us= eful.=C2=A0 In practice, if you disallow it, there's not a large behavi= or change.=C2=A0 Either you close the connection because the peer asked or = you close the connection because the frame is invalid in 0-RTT.
=
On Wed= , Feb 6, 2019 at 3:41 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

piping in from the sidelines so I don't expect this to be found so
convincing, however...

On 06/02/2019 04:11, Martin Thomson wrote:
> it would be a mistake to try to make decisions about 0-RTT safety in > the transport, when replay risks are an application-layer concern.
I believe that is not true for some decisions.

If the WG decide to disallow something that could cause an application
layer concern then that will remove the need to do application layer
analyses of replay/0-rtt for those cases. Given application devs will
in general not do those analyses, disallowing as much as you can (of
the risks arising from 0-rtt) in the transport seems safer to me.

If you want to name a principle ISTM that 0-rtt is a quite like a
dangerous implement, which seems better avoided as far as possible.

One question though - do we have any information about real world
0-rtt issues arising in http/tls1.3 or is it still too early? If we
did have such information that may better inform this discussion.

Cheers,
S.
--000000000000a48de4058135f9ae-- From nobody Wed Feb 6 01:28:45 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB6712426E for ; Wed, 6 Feb 2019 01:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4H4ERGWJZWU for ; Wed, 6 Feb 2019 01:28:41 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E07128D0C for ; Wed, 6 Feb 2019 01:28:41 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id t200so1843153wmt.0 for ; Wed, 06 Feb 2019 01:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w8hhpL0HNyAZZABT65Yk9r9ElId6pc4PMWlGHI3cDYM=; b=oZYTv4A3uxjt8RpbTyd+hceJQr+yBtZiV52VWGv3YSpva5QvjnkuV1MnMB+aLrKclb xTOg0T4K6ihSLzcK6ZjibmqeKJeAQbB/1Q+/ExfRDbxAj+YruPCW7M9MCs85Xliiz3Oo LnJ85hZSTUAJk5P12+zUaNBHOZk7LS3oVjwQsGpfr19waFs6e46Ckt4qWcfjBuVu3Eki S0hsVeZeP2OUf7iDLnDwD3xoyOIKRl0lWJHn6uYp5CvKwn6oLyBej2TEfVESfnyznH/6 K1AsP4dyBddD5IYgBIMqHwA5Dy4s3diPIHYQvRDW6wdZmkobhdLGtZxYfFikN3NWhzFy DfvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w8hhpL0HNyAZZABT65Yk9r9ElId6pc4PMWlGHI3cDYM=; b=XnL2rAXOxT9hne0J6snN6zgQRCUUBHYIFXNbML8p9fMOS9McOh9FqnZzbVIbnBPwpe fwZD9X/ZSbGFeN7l15D6+8pnCijT+9zNzA9JbRuRDq1Kvy0KwSrAUwKXQPoYgE1pL3ph 0A4tIX1D8NxZZ8dGYkSF4IPAoo1PEkDY3q9XIJP1KHWZzjeuWOxG3RAtzmV6v+ih4x1a aqC2o48sa4QevuPJuL+LA2802Ezb2WanRkT0fcz6xXXbTJw6P+qitWygL7eYsWNVFd1l /BOEoIVudPDoWI1SJnVGfNvsTO6lWfEneyNq2CwfR5FXIEmxIILzsD32kCpE6aaH9LC/ q/cg== X-Gm-Message-State: AHQUAua1ilWJwBh0x88mjaju2VTGwexNewTg6UNJypBB+SI2H3zgloFa AmJvfW2s6Q2aHt3aM6AyWfHmqwqxdgFAFqvy9ijNQS0quPs= X-Google-Smtp-Source: AHgI3IYf/5uuwg9ugvptQbC3D7vO52nKoW07Qx1JDLEB0Ea9k4/2aiJh2KIiEY36eVlbG/WNh7thOxyG7fdcNa0zJSg= X-Received: by 2002:a1c:b455:: with SMTP id d82mr2423025wmf.78.1549445319412; Wed, 06 Feb 2019 01:28:39 -0800 (PST) MIME-Version: 1.0 References: <0D4C5B90-2E16-4A30-A296-7223F1B7421D@mnot.net> <1549325886.386087.1650881304.6A5C6312@webmail.messagingengine.com> <1549406757.2592380.1651659816.0410E083@webmail.messagingengine.com> In-Reply-To: <1549406757.2592380.1651659816.0410E083@webmail.messagingengine.com> From: Ian Swett Date: Wed, 6 Feb 2019 04:28:26 -0500 Message-ID: Subject: Re: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000dd58de05813659c4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 09:28:44 -0000 --000000000000dd58de05813659c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm happy to do nothing here, for the reasons Mike and others cited above. On Tue, Feb 5, 2019 at 5:46 PM Martin Thomson wrote: > We're talking about an endpoint that refuses to use new connection IDs fo= r > an extended period. The solution is to occasionally (say once per day) > shift to a new connection ID. That gives you infinite connection lifetim= e, > assuming that you also keep up with key updates. > > But Jana's original point was a stronger one: don't stack so much state o= n > something as fragile and ephemeral as a network connection. That's > something I agree with, though I acknowledge that some applications don't > work that way (yet). > > On Wed, Feb 6, 2019, at 00:57, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > Put in another way. > > > > If connections starts dropping randomly just because of a perceived > > linkability issue, it would take me not very long to go non-standard an= d > > create my own QUIC version. While I could do connection failover withou= t > > loosing a session, it is a lot simpler to fix QUIC in this regard. > > > > > > On 5 February 2019 at 14.51.20, Mikkel Fahn=C3=B8e J=C3=B8rgensen ( > mikkelfj@gmail.com) > > wrote: > > > > It=E2=80=99s not really hypothetical. For long lived peer to peer serve= r > > connections, every time a connection goes down you can have a database > > query transaction rollback, which could have been running for hours on > end, > > or loose a multiple gigabytes of data transfer if you use a simpler > > approach of error handling. > > > > > > On 5 February 2019 at 14.42.42, Jana Iyengar (jri.ietf@gmail.com) wrote= : > > > > We're going to be well out of scope here quickly, so I'm not going to > > design for a hypothetical use case that we don't yet understand well. I > > definitely don't want to make a design decision now based on such a use > > case. > > > > On Tue, Feb 5, 2019 at 5:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> > > wrote: > > > > > > > > FWIW, I don't think that a remote shell session should need to keep t= he > > > transport connection around for as long as the session is around, but > > > that's not a discussion we need to have yet. > > > > > > > > > Well, I do. If you tunnel data, you cannot just switch to a new > connection > > > without a lot of disruption. Why create this problem in the first > place? > > > We (eventually) got varint stream ID=E2=80=99s that made it feasible = to have > long > > > lived connections. I=E2=80=99d be sad to see that go down on connecti= on ID > > > rotations. Especially if these are only done for the single reason of > > > avoiding linkability. My only (other) concern is loss of packet numbe= r > > > space, but I hope that changes with multi-path v2, and 62 bit is stil= l > > > something. > > > > > > I do agree that opt-in security does not work, but for a lot of cases > it > > > really isn=E2=80=99t the key concern. And for other cases, linkabilit= y is so > easy > > > to achieve anyway via other techniques, that I don=E2=80=99t think i= t can > compare > > > to the problem of TLS tokens. If the concern is cracking SHA256 via > master > > > key, well, I think there are bigger issues to consider, including why= a > > > master key is not rotated. > > > > > > Another concern though, is the ability to track users via tokens, but > that > > > is a cross connection concern, since clearly and endpoint can track t= he > > > peer for as the connection is open and the longer it is open, the > easier it > > > is to track for external observers. An endpoint can and should close = a > > > connection if long-lived tracking is a concern. It just should be > imposed > > > on innocent shell pipes. > > > > > > Mikkel > > > > > > > > > On 5 February 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) > wrote: > > > > > > I'm in agreement. > > > > > > FWIW, I don't think that a remote shell session should need to keep t= he > > > transport connection around for as long as the session is around, but > > > that's not a discussion we need to have yet. > > > > > > On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku wrote= : > > > > > >> Mike, Martin, > > >> > > >> Thank you for the responses. > > >> > > >> Because CID encryption key is a master key, I think it's beneficial = to > > >> rotate it rather frequently. The precedent that the servers have is > > >> the TLS session ticket encryption key (STEK). My understanding is th= at > > >> people generally try to generate a new STEK every day or so [1]. > > >> Considering the fact that the maximum permitted lifetime of a TLS > > >> session ticket is 7 days, generating a new STEK once a day is fine, > > >> because by retaining 8 keys it would be possible decrypt TLS session > > >> ticket that was issued 7 days earlier. > > >> > > >> My preference would be to reuse the synchronization mechanism of STE= Ks > > >> for sharing the CID encryption key among the server cluster. That > > >> would mean that typically you would not be able to sustain a QUIC > > >> connection for mere than a week. > > >> > > >> That would be fine for HTTP/3, but maybe not for things like remote > > >> shell over QUIC. > > >> > > >> Having that said, I do agree that we can introduce a QUIC extension = if > > >> the concern becomes real. Considering that, I think I share the view > > >> that we do not need to fix the issue now. > > >> > > >> [1] > > >> > https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twit= ter.html > > >> > > >> 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thomson : > > >> > > > >> > On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote: > > >> > > Bearing in mind that: > > >> > > > > >> > > * this rotation will hopefully be infrequent > > >> > > * one or more CID bits can be reserved to indicate the key > > >> > > generation used > > >> > > * connections only need to be killed when they use something > from > > >> > > the oldest generation which is now being replaced > > >> > > > > >> > > Servers can manage this by keeping two keys (one bit), or four > (two > > >> > > bits). That should make it relatively infrequent that a > connection is > > >> > > still holding on to a CID from the oldest generation after > they=E2=80=99ve all > > >> > > been replaced. > > >> > > > > >> > > Worst case, this might be a use case for the PLEASE_RETIRE_CID > > >> extension > > >> > > we also talked about. > > >> > > > >> > Mike's analysis is correct. I would prefer not to do anything abo= ut > > >> this case. > > >> > > > >> > For now, that means that if servers rotate keys, that will set an > upper > > >> bound on the lifetime of a connection. I think that's tolerable.. > > >> > > > >> > > >> > > >> -- > > >> Kazuho Oku > > >> > > >> > > --000000000000dd58de05813659c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm happy to do nothing here, for the reasons Mike and= others cited above.

On Tue, Feb 5, 2019 at 5:46 PM Martin Thomson <mt@lowentropy.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">We're talking about an= endpoint that refuses to use new connection IDs for an extended period.=C2= =A0 The solution is to occasionally (say once per day) shift to a new conne= ction ID.=C2=A0 That gives you infinite connection lifetime, assuming that = you also keep up with key updates.

But Jana's original point was a stronger one: don't stack so much s= tate on something as fragile and ephemeral as a network connection.=C2=A0 T= hat's something I agree with, though I acknowledge that some applicatio= ns don't work that way (yet).

On Wed, Feb 6, 2019, at 00:57, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> Put in another way.
>
> If connections starts dropping randomly just because of a perceived > linkability issue, it would take me not very long to go non-standard a= nd
> create my own QUIC version. While I could do connection failover witho= ut
> loosing a session, it is a lot simpler to fix QUIC in this regard.
>
>
> On 5 February 2019 at 14.51.20, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com= )
> wrote:
>
> It=E2=80=99s not really hypothetical. For long lived peer to peer serv= er
> connections, every time a connection goes down you can have a database=
> query transaction rollback, which could have been running for hours on= end,
> or loose a multiple gigabytes of data transfer if you use a simpler > approach of error handling.
>
>
> On 5 February 2019 at 14.42.42, Jana Iyengar (jri.ietf@gmail.com) wrote:
>
> We're going to be well out of scope here quickly, so I'm not g= oing to
> design for a hypothetical use case that we don't yet understand we= ll. I
> definitely don't want to make a design decision now based on such = a use
> case.
>
> On Tue, Feb 5, 2019 at 5:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen <<= a href=3D"mailto:mikkelfj@gmail.com" target=3D"_blank">mikkelfj@gmail.com>
> wrote:
>
> >
> > FWIW, I don't think that a remote shell session should need t= o keep the
> > transport connection around for as long as the session is around,= but
> > that's not a discussion we need to have yet.
> >
> >
> > Well, I do. If you tunnel data, you cannot just switch to a new c= onnection
> > without a lot of disruption. Why create this problem in the first= place?
> > We (eventually) got varint stream ID=E2=80=99s that made it feasi= ble to have long
> > lived connections. I=E2=80=99d be sad to see that go down on conn= ection ID
> > rotations. Especially if these are only done for the single reaso= n of
> > avoiding linkability. My only (other) concern is loss of packet n= umber
> > space, but I hope that changes with multi-path v2, and 62 bit is = still
> > something.
> >
> > I do agree that opt-in security does not work, but for a lot of c= ases it
> > really isn=E2=80=99t the key concern. And for other cases, linkab= ility is so easy
> > to achieve anyway via=C2=A0 other techniques, that I don=E2=80=99= t think it can compare
> > to the problem of TLS tokens. If the concern is cracking SHA256 v= ia master
> > key, well, I think there are bigger issues to consider, including= why a
> > master key is not rotated.
> >
> > Another concern though, is the ability to track users via tokens,= but that
> > is a cross connection concern, since clearly and endpoint can tra= ck the
> > peer for as the connection is open and the longer it is open, the= easier it
> > is to track for external observers. An endpoint can and should cl= ose a
> > connection if long-lived tracking is a concern. It just should be= imposed
> > on innocent shell pipes.
> >
> > Mikkel
> >
> >
> > On 5 February 2019 at 12.22.38, Jana Iyengar (jri.ietf@gmail.com) wrote:
> >
> > I'm in agreement.
> >
> > FWIW, I don't think that a remote shell session should need t= o keep the
> > transport connection around for as long as the session is around,= but
> > that's not a discussion we need to have yet.
> >
> > On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku <kazuhooku@gmail.com> wrote: > >
> >> Mike, Martin,
> >>
> >> Thank you for the responses.
> >>
> >> Because CID encryption key is a master key, I think it's = beneficial to
> >> rotate it rather frequently. The precedent that the servers h= ave is
> >> the TLS session ticket encryption key (STEK). My understandin= g is that
> >> people generally try to generate a new STEK every day or so [= 1].
> >> Considering the fact that the maximum permitted lifetime of a= TLS
> >> session ticket is 7 days, generating a new STEK once a day is= fine,
> >> because by retaining 8 keys it would be possible decrypt TLS = session
> >> ticket that was issued 7 days earlier.
> >>
> >> My preference would be to reuse the synchronization mechanism= of STEKs
> >> for sharing the CID encryption key among the server cluster. = That
> >> would mean that typically you would not be able to sustain a = QUIC
> >> connection for mere than a week.
> >>
> >> That would be fine for HTTP/3, but maybe not for things like = remote
> >> shell over QUIC.
> >>
> >> Having that said, I do agree that we can introduce a QUIC ext= ension if
> >> the concern becomes real. Considering that, I think I share t= he view
> >> that we do not need to fix the issue now.
> >>
> >> [1]
> >> https= ://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.htm= l
> >>
> >> 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 9:18 Martin Thom= son <mt@lowentrop= y.net>:
> >> >
> >> > On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote:
> >> > > Bearing in mind that:
> >> > >
> >> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0this rotation will hopefu= lly be infrequent
> >> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0one or more CID bits can = be reserved to indicate the key
> >> > > generation used
> >> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0connections only need to = be killed when they use something from
> >> > > the oldest generation which is now being replaced > >> > >
> >> > > Servers can manage this by keeping two keys (one bi= t), or four (two
> >> > > bits).=C2=A0 That should make it relatively infrequ= ent that a connection is
> >> > > still holding on to a CID from the oldest generatio= n after they=E2=80=99ve all
> >> > > been replaced.
> >> > >
> >> > > Worst case, this might be a use case for the PLEASE= _RETIRE_CID
> >> extension
> >> > > we also talked about.
> >> >
> >> > Mike's analysis is correct.=C2=A0 I would prefer not= to do anything about
> >> this case.
> >> >
> >> > For now, that means that if servers rotate keys, that wi= ll set an upper
> >> bound on the lifetime of a connection.=C2=A0 I think that'= ;s tolerable..
> >> >
> >>
> >>
> >> --
> >> Kazuho Oku
> >>
> >>

--000000000000dd58de05813659c4-- From nobody Wed Feb 6 03:03:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E88128D0C for ; Wed, 6 Feb 2019 03:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eBkJ_4XNuJ0 for ; Wed, 6 Feb 2019 03:03:16 -0800 (PST) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 18062126C7E for ; Wed, 6 Feb 2019 03:03:16 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id v5so5006954lfe.7 for ; Wed, 06 Feb 2019 03:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2H/fwN2CPtTYNLJ31dkazRKpztajb5V1afbx/EBiusY=; b=Pc5xsPEo8mAqAXswn+rhO0H20BZ+0KUA5LtiN8MCIgL/2zQ2d4/pyyIL+DE89pD2Pq lT5CI2/62K5ZnkIKix+Udz6LaaN+3yIIVky5hZmrtH5GHPx8Sd6C7rogJV9kK3lTFX1G ot5+5jzNR6MguUkGrlkcKmwszrkxKPZXqSLLiIC2XQqL2KQSPwp+/YpnFyVcKYBMCIWv Alfe3bfOQwandK/rSSBunG1F4zs9DCnugRQjOXyDeuE1mS8dtJJkB3b6cI4RReRBF7kV L5UInV9Dt9Vc8QZD5B0A7dYlzJG3zJdGvaRsYsBkofUIWcwgnfQyri8I1G8WLbtwS8xQ SKeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2H/fwN2CPtTYNLJ31dkazRKpztajb5V1afbx/EBiusY=; b=ZWKua1SG68XyEytYbFg0D+1J6uKi/+JbQXvwUc3ktGroRDHW8KerCMitCs4ieazPRy reuv8Ibov2E/rKNWkRdGEbRnDbnNpG+zWj/yVPDJq7/LDDTbtewUeYEDQi83oDmRpkWP Smay78+lWlPw2hggeSlkNsobU85sg+F4X2d595kwv86g4JydmZzGFTPQ6R/eCHE0RJa3 NyTMF6kEK8Lcn5LybR4qmalI5opOMHjbZiCB5IMJ+SdMk6DZKH8eZ6ebcUGoWp4eUkgD dfKXaIBlpzFJDFyEcMGf9KXOVYNlS/JzrV9iSQkWFrV9DyTNe+yVWnBy0wCdzZDqfZeu f/jQ== X-Gm-Message-State: AHQUAuacHU4Wj70/xsNsDCW2DBsgkeLSS34Exc4iiOGKx8n1/rI7hD8V ORcrJTq6O/fs2nN6iV4PD/EIffok+tq9ii3VQXo= X-Google-Smtp-Source: AHgI3Ia5OXxG+ZS0Ef+bFtIkl/80i/+CQbbSO2uo/T71QIwplhRdUF/mB+NPALV57w3G93p+fWd9yiFvQCDQnU19+9g= X-Received: by 2002:a19:f00e:: with SMTP id p14mr6370642lfc.166.1549450994234; Wed, 06 Feb 2019 03:03:14 -0800 (PST) MIME-Version: 1.0 References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> In-Reply-To: From: Kazuho Oku Date: Wed, 6 Feb 2019 20:03:02 +0900 Message-ID: Subject: Re: Allowed frames in 0-RTT To: Ian Swett Cc: Stephen Farrell , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 11:03:18 -0000 2019=E5=B9=B42=E6=9C=886=E6=97=A5(=E6=B0=B4) 18:02 Ian Swett : > > I agree with Martin's analysis and principles, and I think the PR is good= , though I'd prefer to allow CONNECTION_CLOSE in 0-RTT(see below) > > Frames that are disallowed are already largely disallowed due to other re= quirements in the transport draft: > CRYPTO is disallowed because 0-RTT is not used for the handshake > ACK frames are disallowed because there are no 1-RTT packets to ACK > RETIRE_CONNECTION_ID is disallowed because the client has received no co= nnection IDs from the peer and they can't retire the CID they're using. > PATH_RESPONSE - You haven't received a PATH_CHALLENGE yet if you haven't= received anything. I forgot to point out this, but if we are to generally allow transmission of any frame in 0-RTT, I think we should allow RETIRE_CONNECTION_ID and PATH_RESPONSE as well. This is because we do not (cannot) enforce a client to switch to 1-RTT send key when it obtains the 1-RTT write key, and because it makes sense for a client to stick to continue using 0-RTT key until it receives an ACK for all the Handshake packets it has sent, assuming that the client does not get blocked by the maximums advertised by TP. Disposal of the 0-RTT key will be signaled using the new RETIRE_KEY frame. > NEW_TOKEN - Only a server can send this and 0-RTT is client-only > CONNECTION_CLOSE- I don't see a reason to disallow this one, but the tex= t requires sending it at an encryption level the peer can process, so it's = also not that useful. In practice, if you disallow it, there's not a large= behavior change. Either you close the connection because the peer asked o= r you close the connection because the frame is invalid in 0-RTT. > > On Wed, Feb 6, 2019 at 3:41 AM Stephen Farrell wrote: >> >> >> piping in from the sidelines so I don't expect this to be found so >> convincing, however... >> >> On 06/02/2019 04:11, Martin Thomson wrote: >> > it would be a mistake to try to make decisions about 0-RTT safety in >> > the transport, when replay risks are an application-layer concern. >> I believe that is not true for some decisions. >> >> If the WG decide to disallow something that could cause an application >> layer concern then that will remove the need to do application layer >> analyses of replay/0-rtt for those cases. Given application devs will >> in general not do those analyses, disallowing as much as you can (of >> the risks arising from 0-rtt) in the transport seems safer to me. >> >> If you want to name a principle ISTM that 0-rtt is a quite like a >> dangerous implement, which seems better avoided as far as possible. >> >> One question though - do we have any information about real world >> 0-rtt issues arising in http/tls1.3 or is it still too early? If we >> did have such information that may better inform this discussion. >> >> Cheers, >> S. --=20 Kazuho Oku From nobody Wed Feb 6 08:20:48 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967B612DD85 for ; Wed, 6 Feb 2019 08:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, 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 6Wob_fdQ1bia for ; Wed, 6 Feb 2019 08:20:42 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 6A5EA12D4EB for ; Wed, 6 Feb 2019 08:20:41 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id b20so5752516lfa.12 for ; Wed, 06 Feb 2019 08:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fZKQ/30u/pEQJoWXiXujVRu6cMK3HQGc9jeEBMGLZBI=; b=b4dSfJTTUy1uYJrRqET5olYMBZxB59/S+xn103R8JRTBs1eoY2PU1Dip7jNvumYnPM nSvjc6h7RXn8qsy03WUrT68noPD54CWsHjPVSCfVjEbgzFHDz2Nfu8PKBDphFFX/kTK2 uUdVYTJSZdwqbCYxNZwfqhJsvi7SAhH8rJehrgk2TboP9vjZtvGgifps+y4FfpjLbQk2 MXoXf303sfvEhLAssXY45qvouWh04nrH+Wh2DgsAv+Nb1J+7VddzhSGNRTP2zNJiz1u9 naX8fNU+VxYZLDm8vHjFRf/zh5JvT2ahvJ3FaAcgsqUX0ytl5LGrUGc05NuFVKIFmvfm QcJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fZKQ/30u/pEQJoWXiXujVRu6cMK3HQGc9jeEBMGLZBI=; b=ogGvUPn0NoudLTh3WkZ+4qQtf2V1tm1x3+HgfkEnP4h79G8Cf2wB/iebvE1toBUX+O rttS/AOpuOzuWkSJx4aJ8ZJcQ8QtYTadA3eQV9/4CHCi0vqqCGvLwMoc3Qo7bfT/+LOO MbdMLND9Mj3tvx0WSrSBSoXgCFOJlPHQ+WT29S5i1CEF4s1NJqmTomoO6QnUedwwTYZG H/DPhP1KHh9Pja6sODV7IC+g1haxpDmebb0Gt9OcyoF7bLcssf02Elrev/r8SGTFLTND 2gnyV8tkB4irsfHKV3gIp1KmL2oajZeDho8WfZmMF1aJbpS0fmWeEOk60V+GWdVgKoZT nQ8A== X-Gm-Message-State: AHQUAuYTZ1q68ya71SXTKjjM4Xeox0ofX6xKK6Sb9N0CuJ4nwvZZfNK9 6iU/1l8WTguoObFBX2IFz89WjS5ZJ1xRqOruo10= X-Google-Smtp-Source: AHgI3IbElT7PLHhaVY71SFW1nOvNZIikOCo1kYliNEvk1w9NB5vuBJFwt0xjqSrpFC0k1AJ1DXr8w3NZg8EWXbIXlQc= X-Received: by 2002:a19:ab09:: with SMTP id u9mr6910326lfe.149.1549470039119; Wed, 06 Feb 2019 08:20:39 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> <25ce934955dc4142b5758fc633661744@usma1ex-dag1mb6.msg.corp.akamai.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 6 Feb 2019 10:20:26 -0600 Message-ID: Subject: Re: New path => new connection ID, right? To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: "Lubashev, Igor" , Roberto Peon , Ted Hardie , Jana Iyengar , Mike Bishop , David Schinazi , "quic@ietf.org" , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="00000000000045a4bf05813c1b72" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 16:20:47 -0000 --00000000000045a4bf05813c1b72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, just checking, as an individual with no hats ... On Wed, Feb 6, 2019 at 2:37 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I share these concerns about linkability but the reality is that > > 1) that in many cases it is not practical to enforce > 2) humans have learned to sequence DNA > > So it is insufficient to change shortly after the fact and it is > problematic to kill a connection on a violation. > Even if todays mobile network tend to keep a fixed IP address that is a > weak assumption. > > Privacy really needs to be dealt with at the network routing level in a > chicken and egg fashion. > Consider a network like Tor that will attempt to switch IP address > repeatedly if it gets a chance to do so. If QUIC just drops connections > this defeats those efforts. OTOH if QUIC just publishes tracking cookies > via CID=E2=80=99s this also defeats the purpose. > > So, for now, I think the best we can do is to encourage to change CID=E2= =80=99s > immediately and disallow cases where it is obviously possible to avoid. > Then look to the next generation of protocols and a longer timeline. > > Mikkel > I saw Ted's reference to using a new CID that had been assigned on the old connection, but never used on the old connection. Does that still go to the wrong backend (potentially)? Do people agree how perfect non-linkability has to be? I think that translates into "do people agree whether sending at least one packet with the old CID on the new connection is fatal"? (Sliding my outgoing AD hat on for this last part) I am intrigued by the possibility that privacy might start to be as much of a consideration at the network level as it has been for the past few years at the transport level. The BOF request cutoff for IETF 104 is this coming Friday. Is that too little time to request a non-working group forming BOF about this for Prague? If it's too little time, but people would like to spend time talking about that, please let me know while I can still approve room requests for side meetings :-) Thanks, Spencer > On 6 February 2019 at 00.53.36, Roberto Peon (fenix@fb.com) wrote: > > Two points: > > 1. A poorly implemented client can leak CIDs along other paths > =E2=80=9Cintentionally=E2=80=9D. Providing a direct signal on this is = likely to raise > awareness. That said, I don=E2=80=99t much care because: > 2. Is this really important? Will the protocol fail our users in some > interesting way without changing this? > > > > -=3DR > > > > *From: *QUIC on behalf of "Lubashev, Igor" < > ilubashe@akamai.com> > *Date: *Tuesday, February 5, 2019 at 3:13 PM > *To: *Ted Hardie > *Cc: *Jana Iyengar , Mike Bishop , > David Schinazi , "quic@ietf.org" , > Martin Thomson >, Kazuho Oku < > kazuhooku@gmail.com> > *Subject: *RE: New path =3D> new connection ID, right? > > > > - I disagree that these are the same > > > > I understood the question to be about routing packets from a new IP > address to the original backend. The migration of the tethering device i= s > the same as the migration of the client *from the routing perspective* > within the destination network (which may be comprised of multiple anycas= t > pops). > > > > - That means that there is no way to truly prevent CID migration here > within QUIC, only to limit the time it is in place. > > > > The purpose of this =E2=80=9CMUST terminate the connection=E2=80=9D propo= sal was to > improve privacy. There is little to be gained by cutting off the > connection, once even a single packet has exposed the original CID to the > new path. It=E2=80=99s not like multiple packets provide a stronger link= ability > signal than a just one packet. We may wish to =E2=80=9Cpunish=E2=80=9D b= uggy > implementations to induce their vendors to do better, but the client > implementation cannot do any better in this case. > > > > - The only other option I see offhand would be to suggest that the > connected forwarder terminate the links to induce something like a > DHCPRELEASE and RENEW, but this seems slow, fragile, and unlikely to > deploy. > > > > Right. This network attachment change notification would be a subject to > a different draft in a different WG, and its deployment would be slow. > > > > - Igor > > > > > > *From:* Ted Hardie > *Sent:* Tuesday, February 05, 2019 5:41 PM > *To:* Lubashev, Igor > *Cc:* Jana Iyengar ; David Schinazi < > dschinazi.ietf@gmail.com>; quic@ietf.org; Mike Bishop < > mbishop@evequefou.be>; Martin Thomson ; Kazuho Oku < > kazuhooku@gmail.com> > *Subject:* Re: New path =3D> new connection ID, right? > *Importance:* High > > > > On Tue, Feb 5, 2019 at 1:33 PM Lubashev, Igor wrote= : > > > - But if the phone/hotspot's IP address changes during this from one > provider's set of addresses to another, this is functionally re-homing= . In > that case, isn't there already a high risk that the traffic will end u= p at > a different back end because of the IP change? > > > > Yes, this is the scenario =E2=80=93 the phone (or your car=E2=80=99s upli= nk, if connected > to an in-car wifi) has switched to a different provider. > > > > This is no different than a usual cell<->wifi migration case from the > routing perspective, and the purpose of server-generated connection ID on > client-to-server packets is to facilitate routing to the correct backend. > > > > I disagree that these are the same. In the common case for cell<-->wifi > migration the connected device is aware of the interface change. Because > the connected device is now serving as a forwarder for the packets of > others, the tethered device cannot detect the sort of interface change. > It's a path change to the tethered device, not an interface change. > Christian has pointed out a way to use v6 RA to indicate that rehoming ha= s > occurred and to signal that to the tethered device. This isn't as > straightforward in a v4 NAT situation, unfortunately. > > > > For example, if the packet arrives at a different anycast pop, the > identify of the original pop is encoded in the connection ID, and the > packet can be tunneled to that pop (or directly to the correct backend > within the same or a different pop). > > > > This will still work if it uses a previous assigned but unused CID, if it > has detected migration. > > > > And I think that's the key issue here; the tethered device has no way to > detect migration, and so no local trigger for a CID change. That means > that there is no way to truly prevent CID migration here within QUIC, on= ly > to limit the time it is in place. Having the server terminate and firing > off 0-RTT is one way to limit that timing, but we have to acknowledge tha= t > it is at best a mitigation. The only other option I see offhand would be > to suggest that the connected forwarder terminate the links to induce > something like a DHCPRELEASE and RENEW, but this seems slow, fragile, an= d > unlikely to deploy. > > > > Ted > > > > > > > > > > - Igor > > > > *From:* Ted Hardie > *Sent:* Tuesday, February 05, 2019 2:28 PM > *To:* Lubashev, Igor > *Cc:* Jana Iyengar ; David Schinazi < > dschinazi.ietf@gmail.com>; quic@ietf.org; Mike Bishop < > mbishop@evequefou.be>; Martin Thomson ; Kazuho Oku < > kazuhooku@gmail.com> > *Subject:* Re: New path =3D> new connection ID, right? > > > > Hi Igor, > > > > I have a clarifying question on the scenario below. > > > > On Tue, Feb 5, 2019 at 10:28 AM Lubashev, Igor > wrote: > > > - Egregious changes in IP might be a signature for network change > (change in /16 address, for instance) and a server could terminate the > connection and respond with a stateless reset if this happens. > > > > The client could be a laptop that is tethered via a phone that is changin= g > providers. The disconnect would be completely =E2=80=9Cpunitive=E2=80=9D= (the old path=E2=80=99s > CID has already been sent over the new path) and be punishing the client > for something it had no control over whatsoever. > > > > > > In this scenario, what is your view of where the IP address changes are > taking place? > > > > I agree that the device connected to a phone (e.g. by a mobile hotspot) > will not generally have a view of the change in upstream path. If that > phone is using something like mobile IP or a VPN to have a consistent > external address, then I also don't see why this path change would trigge= r > any change in CID. But if the phone/hotspot's IP address changes during > this from one provider's set of addresses to another, this is functionall= y > re-homing. In that case, isn't there already a high risk that the traffi= c > will end up at a different back end because of the IP change? > > > > Thanks for sharing your thoughts on this, > > > > Ted > > > > > - Igor > > > > *From:* Jana Iyengar > *Sent:* Tuesday, February 05, 2019 6:42 AM > *To:* David Schinazi > *Cc:* quic@ietf.org; Mike Bishop ; Martin Thomson < > mt@lowentropy.net>; Kazuho Oku > *Subject:* Re: New path =3D> new connection ID, right? > > > > I agree that want to have MUST for changing CID and MUST NOT for sending > packets with the same CID on multiple paths. I thought we had agreed on > this in the past, but I could be misremembering. > > > > I understand that the server cannot necessarily tell this from NAT > rebinding, but it is up to the server what it does if it sees an IP/port > change with no accompanying CID change. Egregious changes in IP might be= a > signature for network change (change in /16 address, for instance) and a > server could terminate the connection and respond with a stateless reset = if > this happens. A client that ignores the MUST and uses the same CID acros= s > networks would then risk getting the connection terminated. I suggest th= at > we add some discussion about potential server responses to clients that > violate normative expectations. > > > > On Tue, Feb 5, 2019 at 8:13 AM David Schinazi > wrote: > > At the end of the day, you can make it a MUST, but clients will do what > they please because servers can't enforce it. > > But I won't die on this hill, I can live with being declared in the rough > on this one. > > > > David > > > > On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku wrote: > > 2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi : > > > > If an endpoint intentionally migrates and it has unused connection IDs > to use, it makes sense to mandate it MUST switch to one of the unused > connection IDs. > > However, if it has run out of unused connection IDs then I would let th= e > endpoint decide if it wants to close the connection or migrate with a > previously used connection IDs, as there are use-cases that value > performance over non-linkability. > > I think I might prefer encouraging endpoints to gracefully close the > connection before it faces a trade-off between performance and > linkability. > > Therefore, assuming that we adopt Martin's proposal, I think it would > make sense to recommend an endpoint to send GOAWAY when if it can no > longer issue a new CID for that QUIC connection. > > > Finally, this cannot be enforced by the peer since it cannot distinguis= h > intentional migration and unintentional migration (NAT rebinding), and we > discussed in Tokyo that we wanted to avoid non-enforceable MUSTs. > > > > David > > > > On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop wrote= : > >> > >> The text is there, but it's perhaps not complete: > >> > >> As discussed in Section 9.5, each connection ID MUST be used on packet= s > sent from only one local address. An endpoint that migrates away from a > local address SHOULD retire all connection IDs used on that address once = it > no longer plans to use that address. > >> > >> > >> > >> The gap seems to be that when your peer moves to a new address, there= =E2=80=99s > no requirement that you not send the same CID to their new address that y= ou > used toward their old address. > >> > >> > >> > >> -----Original Message----- > >> From: QUIC On Behalf Of Martin Thomson > >> Sent: Monday, February 4, 2019 3:15 PM > >> To: quic@ietf.org > >> Subject: New path =3D> new connection ID, right? > >> > >> > >> > >> I thought that we had agreed that an endpoint that intentionally > migrates has to use a new connection ID on the new path. But I couldn't > find any "MUST" in the spec that said that. > >> > >> > >> > >> On the off chance that this wasn't just a mistake and there was some > good reason not to mandate this, I'm bringing the discussion here. > >> > >> > >> > >> I've opened a design issue: > >> > >> https://github.com/quicwg/base-drafts/issues/2413 > > >> > >> > >> > >> The change I'm proposing is here: > >> > >> > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a39= 95236dda960b4cdff49e36f > > >> > >> > > > > -- > Kazuho Oku > > --00000000000045a4bf05813c1b72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, just checking, as an individual with = no hats ...=C2=A0

On Wed, Feb 6, 2019 at 2:37 AM Mikkel Fahn=C3=B8e J=C3=B8r= gensen <mikkelfj@gmail.com>= wrote:
I share these concerns about linkability but the reali= ty is that

1) that in many cases it is not practical to enforce
2) humans have learned to seq= uence DNA

So it is insufficient to change shortly after the fact and it is problemat= ic to kill a connection on a violation.
Even if todays mobile network tend to keep a fixe= d IP address that is a weak assumption.

Privacy really needs to be dealt with at the n= etwork routing level in a chicken and egg fashion.
Consider a network like Tor that= will attempt to switch IP address repeatedly if it gets a chance to do so.= If QUIC just drops connections this defeats those efforts. OTOH if QUIC ju= st publishes tracking cookies via CID=E2=80=99s this also defeats the purpo= se.

=
So, for= now, I think the best we can do is to encourage to change CID=E2=80=99s im= mediately and disallow cases where it is obviously possible to avoid. Then = look to the next generation of protocols and a longer timeline.

Mikkel
=

I saw Ted's reference to u= sing a new CID that had been assigned on the old connection, but never used= on the old connection. Does that still go to the wrong backend (potentiall= y)?=C2=A0

Do people agree how perfect non-linkabil= ity has to be? I think that translates into "do people agree whether s= ending at least one packet with the old CID on the new connection is fatal&= quot;?=C2=A0

(Sliding my outgoing AD hat on for th= is last part)

I am intrigued by the possibility th= at privacy might start to be as much of a consideration at the network leve= l as it has been for the past few years at the transport level. The BOF req= uest cutoff for IETF 104 is this coming Friday. Is that too little time to = request a non-working group forming BOF about this for Prague? If it's = too little time, but people would like to spend time talking about that, pl= ease let me know while I can still approve room requests for side meetings = :-)

Thanks,=C2=A0

Spencer=
=C2=A0
On 6 = February 2019 at 00.53.36, Roberto Peon (fenix@fb.com) wrote:

Two points:

  1. A poorly implemented client can leak CIDs along other paths =E2=80= =9Cintentionally=E2=80=9D. Providing a direct signal on this is likely to r= aise awareness. That said, I don=E2=80=99t much care because:
  2. = Is this really important? Will the protocol fail our users in some interest= ing way without changing this?

=C2=A0

-=3DR

=C2=A0

From: = QUIC <quic-bounces@ietf.org>= ; on behalf of "Lubashev, Igor" <ilubashe@akamai.com>
Date: Tuesday, February 5, 2019 at 3:13 PM
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>, Mike Bishop <mbishop@evequefou.be>, David Sch= inazi <dsc= hinazi.ietf@gmail.com>, "quic@ietf.org" <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>, Kazuho O= ku <kazuhooku@g= mail.com>
Subject: RE: New path =3D> new connection ID, right?

=C2=A0

  • I disagree that these are the same

=C2=A0

I understood the question to be about routing packet= s from a new IP address to the original backend.=C2=A0 The migration of the= tethering device is the same as the migration of the client from the routing perspective within the destination network (which m= ay be comprised of multiple anycast pops).

=C2=A0

  • That means that there is no way to truly prevent CID migration her= e within QUIC,=C2=A0 only to limit the time it is in place.

=C2=A0

The purpose of this =E2=80=9CMUST terminate the conn= ection=E2=80=9D proposal was to improve privacy. There is little to be gain= ed by cutting off the connection, once even a single packet has exposed the= original CID to the new path.=C2=A0 It=E2=80=99s not like multiple packets provide a stronger linkability signal than a just one packet.=C2= =A0 We may wish to =E2=80=9Cpunish=E2=80=9D buggy implementations to induce= their vendors to do better, but the client implementation cannot do any be= tter in this case.

=C2=A0

  • The only other option I see offhand would be to suggest that the c= onnected forwarder terminate the links to induce something like a DHCPRELEA= SE and RENEW, but this seems slow,=C2=A0 fragile, and unlikely to deploy.

=C2=A0

Right.=C2=A0 This network attachment change notifica= tion would be a subject to a different draft in a different WG, and its dep= loyment would be slow.

=C2=A0

  • Igor

=C2=A0

=C2=A0

From: Ted Hardie <ted.ietf@gmail.com>
Sent: Tuesday, February 05, 2019 5:41 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>; David Schinazi <dschinazi.ietf@gmail.com>= ; quic@ietf.org; Mik= e Bishop <mbis= hop@evequefou.be>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <kazuhooku@gmail.com&g= t;
Subject: Re: New path =3D> new connection ID, right?
Importance: High

=C2=A0

On Tue, Feb 5, 2019 at 1:33 PM Lubashev, Igor <ilubashe@akamai.com<= /a>> wrote:

  • But if the phone/hotspot's IP address changes during this from one prov= ider's set of addresses to another, this is functionally re-homing.=C2= =A0 In that case, isn't there already a high risk that the traffic will= end up at a different back end because of the IP change?

=C2=A0

Yes, this is the scenario =E2=80=93 the phone (or yo= ur car=E2=80=99s uplink, if connected to an in-car wifi) has switched to a = different provider.

=C2=A0

This is no different than a usual cell<->wifi = migration case from the routing perspective, and the purpose of server-gene= rated connection ID on client-to-server packets is to facilitate routing to the correct backend. =C2=A0

=C2=A0

I disagree that these are the same.=C2=A0 In the com= mon case for cell<-->wifi migration the connected device is aware of = the interface change.=C2=A0 Because the connected device is now serving as = a forwarder for the packets of others, the tethered device cannot detect the sort of interface change.=C2=A0 It's a path c= hange to the tethered device, not an interface change.=C2=A0 Christian has = pointed out a way to use v6 RA to indicate that rehoming has occurred and t= o signal that to the tethered device.=C2=A0 This isn't as straightforward in a v4 NAT situation, unfortunately.

=C2=A0

For example, if the packet arrives at a different an= ycast pop, the identify of the original pop is encoded in the connection ID= , and the packet can be tunneled to that pop (or directly to the correct backend within the same or a different pop).

=C2=A0

This will still work if it uses a previous assigned = but unused CID, if it has detected migration.=C2=A0

=C2=A0

And I think that's the key issue here; the tethe= red device has no way to detect migration, and so no local trigger for a CI= D change.=C2=A0 That means that there is no way to truly prevent CID migrat= ion here within QUIC,=C2=A0 only to limit the time it is in place.=C2=A0 Having the server terminate and firing off 0-RTT is = one way to limit that timing, but we have to acknowledge that it is at best= a mitigation.=C2=A0 The only other option I see offhand would be to sugges= t that the connected forwarder terminate the links to induce something like a DHCPRELEASE and RENEW, but this seems slo= w,=C2=A0 fragile, and unlikely to deploy.

=C2=A0

Ted

=C2=A0

=C2=A0

=C2=A0

=C2=A0

  • Igor

=C2=A0

From: Ted Hardie <ted.ietf@gmail.com>
Sent: Tuesday, February 05, 2019 2:28 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>; David Schinazi <dschinazi.ietf@gmail.com>= ; quic@ietf.org; Mike = Bishop <mbisho= p@evequefou.be>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <kazuhooku= @gmail.com>
Subject: Re: New path =3D> new connection ID, right?

=C2=A0

Hi Igor,

=C2=A0

I have a clarifying question on the scenario below.<= /p>

=C2=A0

On Tue, Feb 5, 2019 at 10:28 AM Lubashev, Igor <<= a href=3D"mailto:ilubashe@akamai.com" target=3D"_blank">ilubashe@akamai.com= > wrote:

  • Egregious changes in IP might be a signature for network change (change in = /16 address, for instance) and a server could terminate the connection and = respond with a stateless reset if this happens.

=C2=A0

The client could be a laptop that is tethered via a = phone that is changing providers.=C2=A0 The disconnect would be completely = =E2=80=9Cpunitive=E2=80=9D (the old path=E2=80=99s CID has already been sen= t over the new path) and be punishing the client for something it had no control = over whatsoever.

=C2=A0

=C2=A0

In this scenario, what is your view of where the IP = address changes are taking place?

=C2=A0

I agree that the device connected to a phone (e.g. b= y a mobile hotspot) will not generally have a view of the change in upstrea= m path.=C2=A0 If that phone is using something like mobile IP or a VPN to have a consistent external address, then I also don't s= ee why this path change would trigger any change in CID.=C2=A0 But if the p= hone/hotspot's IP address changes during this from one provider's s= et of addresses to another, this is functionally re-homing.=C2=A0 In that case, isn't there already a high risk that th= e traffic will end up at a different back end because of the IP change?

=C2=A0

Thanks for sharing your thoughts on this,

=C2=A0

Ted

=C2=A0

  • Igor

=C2=A0

From: Jana Iyengar <jri.ietf@gmail.com>
Sent: Tuesday, February 05, 2019 6:42 AM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: quic@ietf.org= ; Mike Bishop <mbishop@evequefou.be>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <ka= zuhooku@gmail.com>
Subject: Re: New path =3D> new connection ID, right?

=C2=A0

I agree that want to have MUST for changing CID and = MUST NOT for sending packets with the same CID on multiple paths.=C2=A0 I t= hought we had agreed on this in the past, but I could be misremembering.

=C2=A0

I understand that the server cannot necessarily tell= this from NAT rebinding, but it is up to the server what it does if it see= s an IP/port change with no accompanying CID change.=C2=A0 Egregious changes in IP might be a signature for network change (change in= /16 address, for instance) and a server could terminate the connection and= respond with a stateless reset if this happens.=C2=A0 A client that ignore= s the MUST and uses the same CID across networks would then risk getting the connection terminated.=C2=A0 I sugges= t that we add some discussion about potential server responses to clients t= hat violate normative expectations.

=C2=A0

On Tue, Feb 5, 2019 at 8:13 AM David Schinazi <dschinazi.ietf@= gmail.com> wrote:

At the end of the day, you can make it a MUST, but c= lients will do what they please because servers can't enforce it.

But I won't die on this hill, I can live with be= ing declared in the rough on this one.

=C2=A0

David

=C2=A0

On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku <kazuhooku@gmail.com&= gt; wrote:

2019=E5=B9=B42=E6=9C=885=E6=97=A5(=E7=81=AB) 10:08 David Schinazi <dschinazi.ietf@gmail.com>:
>
> If an endpoint intentionally migrates and it has unused connection IDs= to use, it makes sense to mandate it MUST switch to one of the unused conn= ection IDs.
> However, if it has run out of unused connection IDs then I would let t= he endpoint decide if it wants to close the connection or migrate with a pr= eviously used connection IDs, as there are use-cases that value performance= over non-linkability.

I think I might prefer encouraging endpoints to gracefully close the
connection before it faces a trade-off between performance and
linkability.

Therefore, assuming that we adopt Martin's proposal, I think it would make sense to recommend an endpoint to send GOAWAY when if it can no
longer issue a new CID for that QUIC connection.

> Finally, this cannot be enforced by the peer since it cannot distingui= sh intentional migration and unintentional migration (NAT rebinding), and w= e discussed in Tokyo that we wanted to avoid non-enforceable MUSTs.
>
> David
>
> On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop <mbishop@evequefou.be> wrote:
>>
>> The text is there, but it's perhaps not complete:
>>
>> As discussed in Section 9.5, each connection ID MUST be used on pa= ckets sent from only one local address. An endpoint that migrates away from= a local address SHOULD retire all connection IDs used on that address once= it no longer plans to use that address.
>>
>>
>>
>> The gap seems to be that when your peer moves to a new address, th= ere=E2=80=99s no requirement that you not send the same CID to their new ad= dress that you used toward their old address.
>>
>>
>>
>> -----Original Message-----
>> From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Thomson
>> Sent: Monday, February 4, 2019 3:15 PM
>> To: quic@ietf.o= rg
>> Subject: New path =3D> new connection ID, right?
>>
>>
>>
>> I thought that we had agreed that an endpoint that intentionally m= igrates has to use a new connection ID on the new path.=C2=A0 But I couldn&= #39;t find any "MUST" in the spec that said that.
>>
>>
>>
>> On the off chance that this wasn't just a mistake and there wa= s some good reason not to mandate this, I'm bringing the discussion her= e.
>>
>>
>>
>> I've opened a design issue:
>>
>> https://github.com/quicwg/base-drafts/issues/2413
>>
>>
>>
>> The change I'm proposing is here:
>>
>> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995= 236dda960b4cdff49e36f
>>
>>



--
Kazuho Oku

--00000000000045a4bf05813c1b72-- From nobody Wed Feb 6 09:44:22 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964AF130E82 for ; Wed, 6 Feb 2019 09:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 HMkDkxCo4TM5 for ; Wed, 6 Feb 2019 09:44:18 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 E1A5B130E98 for ; Wed, 6 Feb 2019 09:44:17 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id t7so1920283vsq.5 for ; Wed, 06 Feb 2019 09:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=eUWtEAV1N5WOKaocalr1wD6JtviMkya5875x8cKnS2w=; b=GO0F2Wj5KH/pWaJhfWPmGzW96ugd8bYTI5zecgbN71CHlHW4TPhosklN/MySedccka juMl6/CPXbjN4XdsdexIb7oA7rbEm2Opb0NtVVFvyzG9zuw3WFskKN6i8NGwROGW1xi4 lm9iBjw5C7OEUxqDyoEQKIiyTHfoKJt+emDdr0gTjSRJ3I5hdC19CpROnrbpq4/fRXv+ /Xb4gBspKZqUdtPp5BHTUgDkf6g2lZrLau74TY/hJTG65pC5V9Hx663v+wsV8ru3tFpG 6p++b1U6auawluewNCXWWfriHLrsHzA0HLWY/JQYLV8iNQPpwByrYzkcNFUrlB/S0ihD Ye+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=eUWtEAV1N5WOKaocalr1wD6JtviMkya5875x8cKnS2w=; b=G94RM/yAGxTDTuhic4izN4ZOq9hnM0rNjpOZZ2Dzw9rzChpY4OEXC9OD2Oqk9YQGsU YJ899+YrujiJTSu28rgqJhDa7a2ATENhMn0bV6I7+E0az0fqGBS4DUKBiSvoEFg2lPYq aGCoFgOZBbT+MmACox+hn79CgfmLa1SMd9BhAYf8RY0TDBm/fuGcmJuectvUFQrj2CTv mQO4WwbxxCSI+sIzMmTf5WgjdJzJ3qys9bE0D6Xe7svU57jnoeBDM+jh4iUzpTfBlsWf itsVPbXSSPe+bveaUkxeAc48iizKK9kESkfwg1uszqndDVXYF+EAhAe0T4QplMOyWANX a/6A== X-Gm-Message-State: AHQUAuaKfRzeM3m0D6j3jAePZboMqL1ty50/uQLTxwaLw95pwtHXZxAk svkzVyAbYJ7GMBtW49N3QDBN9LM5681Fhe6JP40= X-Google-Smtp-Source: AHgI3IaMPoJ/dLz3Pwk4h/HBmgAxJgITScDZhXfUtepxy6rZzjQ4aAJZ2ltuHFxHWIsl89mOJ2EpO4vqNs1zCWHHA7s= X-Received: by 2002:a67:fc85:: with SMTP id x5mr4637340vsp.234.1549475056881; Wed, 06 Feb 2019 09:44:16 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Feb 2019 09:44:16 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> <25ce934955dc4142b5758fc633661744@usma1ex-dag1mb6.msg.corp.akamai.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Feb 2019 09:44:15 -0800 Message-ID: Subject: Re: New path => new connection ID, right? To: Spencer Dawkins at IETF Cc: "quic@ietf.org" , Jana Iyengar , Mike Bishop , Ted Hardie , David Schinazi , Martin Thomson , Kazuho Oku , "Lubashev, Igor" , Roberto Peon Content-Type: multipart/alternative; boundary="0000000000005a953405813d4609" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 17:44:20 -0000 --0000000000005a953405813d4609 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 6 February 2019 at 17.20.40, Spencer Dawkins at IETF ( spencerdawkins.ietf@gmail.com) wrote: I saw Ted's reference to using a new CID that had been assigned on the old connection, but never used on the old connection. Does that still go to the wrong backend (potentially)? If it is not unencrypted on the wire on the old path, it could AFAIK not go wrong wrt. security. If a CID is constructed for a specific path, then routing could go wrong, but should not because we don=E2=80=99t issue CID= =E2=80=99s per path, at least not in V1. This means any route to the endpoint must be able to deal with any CID (I believe I asked the same question a long time ago). I could see this change in a future version with multi-path and/or if enough deployment experience shows that there is a need. It would be much more complex to maintain CID=E2=80=99s then. It already causes some trouble= . Do people agree how perfect non-linkability has to be? I think that translates into "do people agree whether sending at least one packet with the old CID on the new connection is fatal"? I think this depends entirely on the threat model. If someone has limited capacity to sample traffic then on average it may not be a problem. But if you are serious, and you have access, all you need to do is to make a fingerprint of each source and destination connection ID pair and store it in a bucket with some correlation, e.g. everyone accessing example.com. Then you can use techniques similar to DNA sequencing to strand to together all movement, even if you do not store perfect information at full precision. Here data collection needs to be fast small and simple, but sequent mining can be done with massive resources when you know what you are looking for. Such tracking is not just NSA vs. average Joe. It can also be a concern for military personnel in the field. More simplistic, fitness trackers have been used in the past to spot secret deployments via social network maps, and selfies posted on FaceBook with embedded exif GPS coordinates have also not helped. Even without broadcasting GPS coordinates, if communication happens over radio links where the enemy can tap into the core protocol data below the encryption layer, it can start to piece together a picture of deployments. If you look into mesh networks that could be used in disaster areas, you could also have a massive change in routing hops with a network similar to IP, but different. Here same states might be interested in certain dissidents moving with the flow (good/bad depends on the point of view). QUIC could be layered on top of such networks, and here tracking could also be interesting simply by listening in on radio. That said, there are endless other ways to piece together information, not least via timing and traffic patterns, so I am not convinced that the efforts to hide migration are truly worthwhile given how difficult it is to get right, at least not with the current underlying networks. --0000000000005a953405813d4609 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 6 February 2019 a= t 17.20.40, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com) wrote:
I saw Ted's re= ference to using a new CID that had been assigned on the old connection, bu= t never used on the old connection. Does that still go to the wrong backend= (potentially)?=C2=A0

If it is not = unencrypted on the wire on the old path, it could AFAIK not go wrong wrt. s= ecurity. If a CID is constructed for a specific path, then routing could go= wrong, but should not because we don=E2=80=99t issue CID=E2=80=99s per pat= h, at least not in V1. This means any route to the endpoint must be able to= deal with any CID (I believe I asked the same question a long time ago). I= could see this change in a future version with multi-path and/or if enough= deployment experience shows that there is a need. It would be much more co= mplex to maintain CID=E2=80=99s then. It already causes some trouble.

=

Do people agree how perfect non-li= nkability has to be? I think that translates into "do people agree whe= ther sending at least one packet with the old CID on the new connection is = fatal"?=C2=A0

I think this dep= ends entirely on the threat model.

If someone has limited capacity to= sample traffic then on average it may not be a problem. But if you are ser= ious, and you have access, all you need to do is to make a fingerprint of e= ach source and destination connection ID pair and store it in a bucket with= some correlation, e.g. everyone accessing e= xample.com.=C2=A0Then you can use techniques similar to DNA sequencing = to strand to together all movement, even if you do not store perfect inform= ation at full precision. Here data collection needs to be fast small and si= mple, but sequent mining can be done with massive resources when you know w= hat you are looking for.

Such tracking is not just NSA vs. average Jo= e. It can also be a concern for military personnel in the field. More simpl= istic, fitness trackers have been used in the past to spot secret deploymen= ts via social network maps, and selfies posted on FaceBook with embedded ex= if GPS coordinates have also not helped. Even without broadcasting GPS coor= dinates, if communication happens over radio links where the enemy can tap = into the core protocol data below the encryption layer, it can start to pie= ce together a picture of deployments.

If you look into mesh networks = that could be used in disaster areas, you could also have a massive change = in routing hops with a network similar to IP, but different. Here same stat= es might be interested in certain dissidents moving with the flow (good/bad= depends on the point of view). QUIC could be layered on top of such networ= ks, and here tracking could also be interesting simply by listening in on r= adio.

That said, there are endless other ways to piece together infor= mation, not least via timing and traffic patterns, so I am not convinced th= at the efforts to hide migration are truly worthwhile given how difficult i= t is to get right, at least not with the current underlying networks.

--0000000000005a953405813d4609-- From nobody Wed Feb 6 10:07:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458BA130EFE for ; Wed, 6 Feb 2019 10:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAHTBHKcGHer for ; Wed, 6 Feb 2019 10:07:24 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 B2A63130E99 for ; Wed, 6 Feb 2019 10:07:23 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id t9-v6so6921634ljh.6 for ; Wed, 06 Feb 2019 10:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cKcSYAWi7v/H12niltP7uJIBIsEkNoo5DxHfSub8+xE=; b=VHG7BYF26Zl1NnT2cQFaVU8G3N0rD8ZlHNQAoRjaq8FvazyuVAWY5jF6FlSj38P/Oj sBxiBkCFc3RlwPccMiWQBN1nOGsAT08MHJVbIQ750/vo+v2LJwSgt9L1lKsc8yYu7Csi KdlaOvIuOn/hXc7BZNefcfjTbkHGgH+g0lQuoYgn4KIqgxnLlw4ko4tV134wBMqzq1Ds 2+Ri8JzUGGTl8H9OAE3r9EBjVduul5z7+0/2aMldCG1R3QNkaspOoOtyiQphmegjH56J T2jd6yYyx3Li2WujBvzulsWZ607goBvIRTnBClsuVGJh0ln9Ba8q0RJz9Eyh/PiX0pFC /MnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cKcSYAWi7v/H12niltP7uJIBIsEkNoo5DxHfSub8+xE=; b=tP+VdggPJ6xsPzz3G23E/Nm2DWqPtITKuT96n1W0wBMA0n+fRvAS81XMtZXsxQwS1c DAqhCY2pGZf06vxZwWJ2Pdxj46aCTgCl4/jzwDrRqHKGBPCOOFzddw/pVZPL/neOyX83 ovMNP1nFwzBUIThiLydbBNJVKjdO8LpYWbLnnn3J7gpC6axUd7Gf2vvyUL5VXSW97vAM SRSCSW+XtmDe9jSbYwbwMRsY5gB8z387vRhJjVu7GmESfcccWZ2CqHaW9yrXWv7NwzLn BrpNyrrcRnb+7gb6oyeJMFwPWi5zA5gnOro4vZ/9OQVqSyag/mzA902XWagXqgzihbd/ 4tKA== X-Gm-Message-State: AHQUAua1rK/fyI73VnFJQ1knuIpMHHJYOpPiL1A4nK6xU74jnyuKOlyA qpMYZMSLB7li+0oU1qsawM6Xh7Jtf7lvFK/N+MQ= X-Google-Smtp-Source: AHgI3IZBioA4GvboHXayREqaKDzHR5dRStd5mv+wHiu3+MHt6SHNLCXjOodxn/3W/caGSakk5JnlwwiK9V2F6/4T2oU= X-Received: by 2002:a2e:7803:: with SMTP id t3-v6mr387783ljc.115.1549476441820; Wed, 06 Feb 2019 10:07:21 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> <25ce934955dc4142b5758fc633661744@usma1ex-dag1mb6.msg.corp.akamai.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 6 Feb 2019 12:07:08 -0600 Message-ID: Subject: Re: New path => new connection ID, right? To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: "quic@ietf.org" , Jana Iyengar , Mike Bishop , Ted Hardie , David Schinazi , Martin Thomson , Kazuho Oku , "Lubashev, Igor" , Roberto Peon Content-Type: multipart/alternative; boundary="000000000000e72c5005813d98f6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 18:07:26 -0000 --000000000000e72c5005813d98f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Mikkel, Thanks for the speedy reply. A couple of points inline. On Wed, Feb 6, 2019 at 11:44 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > On 6 February 2019 at 17.20.40, Spencer Dawkins at IETF ( > spencerdawkins.ietf@gmail.com) wrote: > > I saw Ted's reference to using a new CID that had been assigned on the ol= d > connection, but never used on the old connection. Does that still go to t= he > wrong backend (potentially)? > > If it is not unencrypted on the wire on the old path, it could AFAIK not > go wrong wrt. security. If a CID is constructed for a specific path, then > routing could go wrong, but should not because we don=E2=80=99t issue CID= =E2=80=99s per > path, at least not in V1. This means any route to the endpoint must be ab= le > to deal with any CID (I believe I asked the same question a long time ago= ). > I could see this change in a future version with multi-path and/or if > enough deployment experience shows that there is a need. It would be much > more complex to maintain CID=E2=80=99s then. It already causes some troub= le. > Thanks - that was my understanding, but I'm not an expert here. > > Do people agree how perfect non-linkability has to be? I think that > translates into "do people agree whether sending at least one packet with > the old CID on the new connection is fatal"? > > I think this depends entirely on the threat model. > Yeah, that's what I'm afraid of. Not surprising. > If someone has limited capacity to sample traffic then on average it may > not be a problem. But if you are serious, and you have access, all you ne= ed > to do is to make a fingerprint of each source and destination connection = ID > pair and store it in a bucket with some correlation, e.g. everyone > accessing example.com. Then you can use techniques similar to DNA > sequencing to strand to together all movement, even if you do not store > perfect information at full precision. Here data collection needs to be > fast small and simple, but sequent mining can be done with massive > resources when you know what you are looking for. > Only because you mentioned DNA sequencing a couple of times, I thought you'd enjoy looking at https://www.theatlantic.com/science/archive/2017/08/these-scientists-took-o= ver-a-computer-by-encoding-malware-in-dna/536361/ ... People ARE creative, aren't we? > Such tracking is not just NSA vs. average Joe. It can also be a concern > for military personnel in the field. More simplistic, fitness trackers ha= ve > been used in the past to spot secret deployments via social network maps, > and selfies posted on FaceBook with embedded exif GPS coordinates have al= so > not helped. Even without broadcasting GPS coordinates, if communication > happens over radio links where the enemy can tap into the core protocol > data below the encryption layer, it can start to piece together a picture > of deployments. > > If you look into mesh networks that could be used in disaster areas, you > could also have a massive change in routing hops with a network similar t= o > IP, but different. Here same states might be interested in certain > dissidents moving with the flow (good/bad depends on the point of view). > QUIC could be layered on top of such networks, and here tracking could al= so > be interesting simply by listening in on radio. > > That said, there are endless other ways to piece together information, no= t > least via timing and traffic patterns, so I am not convinced that the > efforts to hide migration are truly worthwhile given how difficult it is = to > get right, at least not with the current underlying networks. > Right. That's why I'm interested in hearing whether doing something so that the current underlying networks don't have the same helpful-to-monitoring attributes in a decade or two, is interesting to people. :-) Spencer --000000000000e72c5005813d98f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Mikkel,=C2=A0
Thanks for the speedy reply. A couple of points inline.=C2=A0<= /div>

On Wed, Feb 6, 2019 at 11:44 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:
=
On 6 February 2019 at 17.20.40, Spencer Dawkins at IETF (spencerdawkins.= ietf@gmail.com) wrote:
I saw Ted's = reference to using a new CID that had been assigned on the old connection, = but never used on the old connection. Does that still go to the wrong backe= nd (potentially)?=C2=A0

If it is no= t unencrypted on the wire on the old path, it could AFAIK not go wrong wrt.= security. If a CID is constructed for a specific path, then routing could = go wrong, but should not because we don=E2=80=99t issue CID=E2=80=99s per p= ath, at least not in V1. This means any route to the endpoint must be able = to deal with any CID (I believe I asked the same question a long time ago).= I could see this change in a future version with multi-path and/or if enou= gh deployment experience shows that there is a need. It would be much more = complex to maintain CID=E2=80=99s then. It already causes some trouble.

=
Thanks - that was my understanding, but I'm not= an expert here.=C2=A0=C2=A0

Do people agree how perfect non-linkability has to be? I think that trans= lates into "do people agree whether sending at least one packet with t= he old CID on the new connection is fatal"?=C2=A0

I think this depends entirely on the threat model.

<= /div>
Yeah, that's what I'm afraid of. Not s= urprising.=C2=A0=C2=A0

If someone has limited= capacity to sample traffic then on average it may not be a problem. But if= you are serious, and you have access, all you need to do is to make a fing= erprint of each source and destination connection ID pair and store it in a= bucket with some correlation, e.g. everyone accessing example.com.=C2=A0Then you can use techniq= ues similar to DNA sequencing to strand to together all movement, even if y= ou do not store perfect information at full precision. Here data collection= needs to be fast small and simple, but sequent mining can be done with mas= sive resources when you know what you are looking for.

Only because you mentioned DNA sequencing a couple of times, I= thought you'd enjoy looking at=C2=A0https://www.theatlantic.com/science/archive/201= 7/08/these-scientists-took-over-a-computer-by-encoding-malware-in-dna/53636= 1/ ...=C2=A0

People ARE creative, aren't w= e?=C2=A0

Such tracking is not just NSA vs= . average Joe. It can also be a concern for military personnel in the field= . More simplistic, fitness trackers have been used in the past to spot secr= et deployments via social network maps, and selfies posted on FaceBook with= embedded exif GPS coordinates have also not helped. Even without broadcast= ing GPS coordinates, if communication happens over radio links where the en= emy can tap into the core protocol data below the encryption layer, it can = start to piece together a picture of deployments.

If you look into me= sh networks that could be used in disaster areas, you could also have a mas= sive change in routing hops with a network similar to IP, but different. He= re same states might be interested in certain dissidents moving with the fl= ow (good/bad depends on the point of view). QUIC could be layered on top of= such networks, and here tracking could also be interesting simply by liste= ning in on radio.

That said, there are endless other ways to piece to= gether information, not least via timing and traffic patterns, so I am not = convinced that the efforts to hide migration are truly worthwhile given how= difficult it is to get right, at least not with the current underlying net= works.

Right. That's why I'm inter= ested in hearing whether doing something so that the current underlying net= works don't have the same helpful-to-monitoring attributes in a decade = or two, is interesting to people. :-)

Spencer=C2= =A0
--000000000000e72c5005813d98f6-- From nobody Wed Feb 6 10:19:13 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E4C130F25 for ; Wed, 6 Feb 2019 10:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.395 X-Spam-Level: X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=cl4s9FrC; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=THYXd9wL 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 T375qHO7W29p for ; Wed, 6 Feb 2019 10:19:08 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CE8130F20 for ; Wed, 6 Feb 2019 10:19:05 -0800 (PST) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x16IIr6v030473; Wed, 6 Feb 2019 10:18:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=HXHa47gPglUaqoDGm5NR8yYACjKxul/In/m3Yp1+hKo=; b=cl4s9FrCegpHlrT+4a6Q9NtKDc6jmPBpflUGagvPgYEQMC7MTRSvAE2Ho2OyxXZVWFZv neJ9U9/wlcAcOGAMhgLiTOcX9FDxxmKoYd+oNrNRhbptjqAoOE6WRu3IHMFg+KgZXeqD BoRGy12VZzGF1KlGTJqQkOgnAGrz1iXwiPg= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qg3hx8a5s-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Feb 2019 10:18:59 -0800 Received: from frc-mbx06.TheFacebook.com (2620:10d:c0a1:f82::30) by frc-hub03.TheFacebook.com (2620:10d:c021:18::173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 6 Feb 2019 10:18:56 -0800 Received: from frc-hub06.TheFacebook.com (2620:10d:c021:18::176) by frc-mbx06.TheFacebook.com (2620:10d:c0a1:f82::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 6 Feb 2019 10:18:56 -0800 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Wed, 6 Feb 2019 10:18:56 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HXHa47gPglUaqoDGm5NR8yYACjKxul/In/m3Yp1+hKo=; b=THYXd9wL8EdWKttF6YqQc5iTDhsWyZf0wa5ubRtD9N67Rysun4zuTBwhpRKI40IliyGCkonNqVMmJFEHD7dEPbsbZZ2rmjcTKvvxvCPdrSmz0yfFS7JJnEEMAj6GFxcNvH2nh4kF3kl0fRRnBK8mYEebbFYu1Hin5CK9KK5LJEI= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2934.namprd15.prod.outlook.com (20.178.237.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Wed, 6 Feb 2019 18:18:54 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084%5]) with mapi id 15.20.1580.019; Wed, 6 Feb 2019 18:18:54 +0000 From: Roberto Peon To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Spencer Dawkins at IETF CC: "quic@ietf.org" , Jana Iyengar , "Mike Bishop" , Ted Hardie , "David Schinazi" , Martin Thomson , Kazuho Oku , "Lubashev, Igor" Subject: Re: New path => new connection ID, right? Thread-Topic: New path => new connection ID, right? Thread-Index: AQHUvN+NcueOarMuR0CYh90M6oUeO6XQYXIAgAADUoCAAAgLAIAAEoQAgACWfgCAAHEQAIAAETmAgAAjEACAABLSAIAACMYA//+FL4CAARirAIAAgWEAgAAXa4CAAKCMAA== Date: Wed, 6 Feb 2019 18:18:53 +0000 Message-ID: References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <650fd9704aea40edb496a1d3df0b6cdb@usma1ex-dag1mb6.msg.corp.akamai.com> <25ce934955dc4142b5758fc633661744@usma1ex-dag1mb6.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::4:2405] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2934; 20:WuY7TPGNRcCQDVXxYvPze/xtBlPGgKkt5uBiKI0LvEIPPmsbY7OZIv0DEFKXASXpKnY/SuwUqPcTbpK6Tl8k0YJsutGSMM/XTDkiTeM/S+roDAnsNXzVaAg31I2vEU0yRtBvV85x0xMDb74qMdJ0+HrIpywzvUGwZXIl8xPc+c4= x-ms-office365-filtering-correlation-id: d4d2acfb-4cb8-44d1-9881-08d68c5f8d70 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2934; x-ms-traffictypediagnostic: BYAPR15MB2934: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(396003)(136003)(189003)(199004)(51444003)(446003)(8676002)(81156014)(8936002)(81166006)(86362001)(186003)(53936002)(66574012)(82746002)(6512007)(6306002)(54896002)(97736004)(7736002)(6486002)(6436002)(2906002)(606006)(102836004)(316002)(6506007)(478600001)(53546011)(229853002)(54906003)(58126008)(110136005)(6246003)(14454004)(68736007)(486006)(76176011)(46003)(33656002)(106356001)(93886005)(105586002)(2616005)(25786009)(476003)(99286004)(6116002)(7416002)(11346002)(36756003)(256004)(236005)(4326008)(14444005)(83716004)(71200400001)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2934; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DYLbklSwKSdcFCQ0YNSa4UYX6VdAMPlxTyxpGHJBcA1Sa9bfBPkCA6C5gOEEY7aVMI3TR9G3dRl2rb81tvNmlE9lnSp0OXEMcSNy7YW75/dtKJDbgqBR60jUCKFmLNI1G3xH0eeijURQn3hIPbghs+SZYze+JriVcEbGY7OMxqf7g+LRSAYDRgZXcx71JtKWo5NVYDh62l43yAfuelfnqOtqacSh9KKiCcZRiwr0eqVF92H0bLMY+NVfzBDnK9pM1hAddHXTXgyxkZSJliFtFcrgfFG8qwNyWG/5aoVkvEA8eVS0adz1Xr56QNioqpSiZLbQ+PDsvrnf5XeLMSyWOLlQJWAK/N5wvF5SN4t0r1h/pg3WI4QYEO0tH1XlDXezqGCDPa9OzlLsM9lLXjAWv3NRAXjhl9wmMMxSi8paaEI= Content-Type: multipart/alternative; boundary="_000_B86788EEF2EA4DBBAD316FF99A99AAA6fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d4d2acfb-4cb8-44d1-9881-08d68c5f8d70 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2019 18:18:54.1041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2934 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-06_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 18:19:11 -0000 --_000_B86788EEF2EA4DBBAD316FF99A99AAA6fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIGNvdWxkIGltYWdpbmUgKGkuZS4gdGhlb3JpemUpIGEgbmV0d29yayBmYWJyaWMgd2hpY2gg dXNlcyBwb2ludC10by1wb2ludCBmbG93IGNvbnRyb2wgZm9yIGhvcHMgd2hlcmUgY29uZ2VzdGlv biBvY2N1cnMgY291cGxlZCB3aXRoIHBvaW50LXRvLXBvaW50IHJlLXhtaXNzaW9ucyB3aXRoIGZh aXItcXVldWluZyAoYSBob3N0IGNhbiBtb3N0bHkgb25seSBjb25nZXN0IGl0c2VsZikgd2hpY2gg d291bGQgYWxsb3cgZm9yIGRhdGEgdG8gYmUgc2VudCBpbnRvIHRoZSBuZXR3b3JrIGF0IGEgY29u c3RhbnQgcmF0ZSByZWdhcmRsZXNzIG9mIGhvdyBtdWNoIGFwcGxpY2F0aW9uIGRhdGEgb25lIG5l ZWRlZCB0byBzZW5kLg0KDQpJbiBzdWNoIGNhc2VzICh5b3UgY2FuIGZyZWVseSBzZW5kIGJ5dGVz IHdpdGhvdXQgY2F1c2luZyBjb25nZXN0aW9uIHRvIG90aGVycykgeW914oCZZCBlbGltaW5hdGUg dGhlIG5lZWQgZm9yIHRoZSBlbmRwb2ludHMgdG8gY29uc3RyYWluIHRoZSBzZW5kaW5nIHJhdGXi gKYgd2hpY2ggd291bGQgaW1wbHkgcmVkdWNpbmcgb3IgZWxpbWluYXRpbmcgdGhlIGVmZmljYWN5 IG9mIHRyYWZmaWMgYW5hbHlzaXMgYmFzZWQgb24gc2l6ZS90aW1pbmcuDQoNCkFzIGEgcmVtaW5k ZXIsIGFsdGhvdWdoIEkgYmVsaWV2ZSBpdCBpcyBwb3NzaWJsZSBhbmQgZGVzaXJhYmxlLCBzdWNo IG5ldHdvcmtzIGFyZSBub3Qgd2lkZWx5IGRlcGxveWVkIEFGQUlDVCwgYW5kIHNvIHRoaXMgbGlr ZWx5IHJlbWFpbnMgdGhlb3JldGljYWwgKGJ1dCBpdCBpcyBhIHZlcnkgZnVuIHRoaW5nIHRvIHRo aW5rIGFib3V0KS4NCg0KSWYgc3VjaCBuZXR3b3JrcyB3ZXJlIHdpZGVseSBkZXBsb3llZCwgdGhl biBsaW5rYWJpbGl0eSB3b3VsZCBiZWNvbWUgYSBtb3JlIHByZXNzaW5nIHByaXZhY3kgY29uY2Vy biBhcyBpdCB3b3VsZCBiZSB0aGUgIHRoaW5nIHRoYXQgcHJvdmlkZWQgYXR0YWNrZXJzIHdpdGgg dGhlIG1vc3QgaW5mb3JtYXRpb24uDQotPVINCg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4cmdl bnNlbiA8bWlra2VsZmpAZ21haWwuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBGZWJydWFyeSA2LCAy MDE5IGF0IDk6NDQgQU0NClRvOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiA8c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb20+DQpDYzogInF1aWNAaWV0Zi5vcmciIDxxdWljQGlldGYub3JnPiwg SmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb20+LCBNaWtlIEJpc2hvcCA8bWJpc2hvcEBl dmVxdWVmb3UuYmU+LCBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+LCBEYXZpZCBTY2hp bmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPiwgTWFydGluIFRob21zb24gPG10QGxvd2Vu dHJvcHkubmV0PiwgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT4sICJMdWJhc2hldiwg SWdvciIgPGlsdWJhc2hlQGFrYW1haS5jb20+LCBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4N ClN1YmplY3Q6IFJlOiBOZXcgcGF0aCA9PiBuZXcgY29ubmVjdGlvbiBJRCwgcmlnaHQ/DQoNCk9u IDYgRmVicnVhcnkgMjAxOSBhdCAxNy4yMC40MCwgU3BlbmNlciBEYXdraW5zIGF0IElFVEYgKHNw ZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPG1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdt YWlsLmNvbT4pIHdyb3RlOg0KSSBzYXcgVGVkJ3MgcmVmZXJlbmNlIHRvIHVzaW5nIGEgbmV3IENJ RCB0aGF0IGhhZCBiZWVuIGFzc2lnbmVkIG9uIHRoZSBvbGQgY29ubmVjdGlvbiwgYnV0IG5ldmVy IHVzZWQgb24gdGhlIG9sZCBjb25uZWN0aW9uLiBEb2VzIHRoYXQgc3RpbGwgZ28gdG8gdGhlIHdy b25nIGJhY2tlbmQgKHBvdGVudGlhbGx5KT8NCg0KSWYgaXQgaXMgbm90IHVuZW5jcnlwdGVkIG9u IHRoZSB3aXJlIG9uIHRoZSBvbGQgcGF0aCwgaXQgY291bGQgQUZBSUsgbm90IGdvIHdyb25nIHdy dC4gc2VjdXJpdHkuIElmIGEgQ0lEIGlzIGNvbnN0cnVjdGVkIGZvciBhIHNwZWNpZmljIHBhdGgs IHRoZW4gcm91dGluZyBjb3VsZCBnbyB3cm9uZywgYnV0IHNob3VsZCBub3QgYmVjYXVzZSB3ZSBk b27igJl0IGlzc3VlIENJROKAmXMgcGVyIHBhdGgsIGF0IGxlYXN0IG5vdCBpbiBWMS4gVGhpcyBt ZWFucyBhbnkgcm91dGUgdG8gdGhlIGVuZHBvaW50IG11c3QgYmUgYWJsZSB0byBkZWFsIHdpdGgg YW55IENJRCAoSSBiZWxpZXZlIEkgYXNrZWQgdGhlIHNhbWUgcXVlc3Rpb24gYSBsb25nIHRpbWUg YWdvKS4gSSBjb3VsZCBzZWUgdGhpcyBjaGFuZ2UgaW4gYSBmdXR1cmUgdmVyc2lvbiB3aXRoIG11 bHRpLXBhdGggYW5kL29yIGlmIGVub3VnaCBkZXBsb3ltZW50IGV4cGVyaWVuY2Ugc2hvd3MgdGhh dCB0aGVyZSBpcyBhIG5lZWQuIEl0IHdvdWxkIGJlIG11Y2ggbW9yZSBjb21wbGV4IHRvIG1haW50 YWluIENJROKAmXMgdGhlbi4gSXQgYWxyZWFkeSBjYXVzZXMgc29tZSB0cm91YmxlLg0KDQpEbyBw ZW9wbGUgYWdyZWUgaG93IHBlcmZlY3Qgbm9uLWxpbmthYmlsaXR5IGhhcyB0byBiZT8gSSB0aGlu ayB0aGF0IHRyYW5zbGF0ZXMgaW50byAiZG8gcGVvcGxlIGFncmVlIHdoZXRoZXIgc2VuZGluZyBh dCBsZWFzdCBvbmUgcGFja2V0IHdpdGggdGhlIG9sZCBDSUQgb24gdGhlIG5ldyBjb25uZWN0aW9u IGlzIGZhdGFsIj8NCg0KSSB0aGluayB0aGlzIGRlcGVuZHMgZW50aXJlbHkgb24gdGhlIHRocmVh dCBtb2RlbC4NCg0KSWYgc29tZW9uZSBoYXMgbGltaXRlZCBjYXBhY2l0eSB0byBzYW1wbGUgdHJh ZmZpYyB0aGVuIG9uIGF2ZXJhZ2UgaXQgbWF5IG5vdCBiZSBhIHByb2JsZW0uIEJ1dCBpZiB5b3Ug YXJlIHNlcmlvdXMsIGFuZCB5b3UgaGF2ZSBhY2Nlc3MsIGFsbCB5b3UgbmVlZCB0byBkbyBpcyB0 byBtYWtlIGEgZmluZ2VycHJpbnQgb2YgZWFjaCBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGNvbm5l Y3Rpb24gSUQgcGFpciBhbmQgc3RvcmUgaXQgaW4gYSBidWNrZXQgd2l0aCBzb21lIGNvcnJlbGF0 aW9uLCBlLmcuIGV2ZXJ5b25lIGFjY2Vzc2luZyBleGFtcGxlLmNvbTxodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fZXhhbXBsZS5jb20mZD1Ed01GYVEm Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPTVmYTFU cEtpN3d2U2NKX2xPbXRyZE1VUlhYTG5qNnp2dWZqSTdraWEzT0Emcz1jNlQ0bnRRbTNCSU9yREQz MVRMMUF4X1pMZXdHNVN3bDBmUnZiQU53YW9FJmU9Pi4gVGhlbiB5b3UgY2FuIHVzZSB0ZWNobmlx dWVzIHNpbWlsYXIgdG8gRE5BIHNlcXVlbmNpbmcgdG8gc3RyYW5kIHRvIHRvZ2V0aGVyIGFsbCBt b3ZlbWVudCwgZXZlbiBpZiB5b3UgZG8gbm90IHN0b3JlIHBlcmZlY3QgaW5mb3JtYXRpb24gYXQg ZnVsbCBwcmVjaXNpb24uIEhlcmUgZGF0YSBjb2xsZWN0aW9uIG5lZWRzIHRvIGJlIGZhc3Qgc21h bGwgYW5kIHNpbXBsZSwgYnV0IHNlcXVlbnQgbWluaW5nIGNhbiBiZSBkb25lIHdpdGggbWFzc2l2 ZSByZXNvdXJjZXMgd2hlbiB5b3Uga25vdyB3aGF0IHlvdSBhcmUgbG9va2luZyBmb3IuDQoNClN1 Y2ggdHJhY2tpbmcgaXMgbm90IGp1c3QgTlNBIHZzLiBhdmVyYWdlIEpvZS4gSXQgY2FuIGFsc28g YmUgYSBjb25jZXJuIGZvciBtaWxpdGFyeSBwZXJzb25uZWwgaW4gdGhlIGZpZWxkLiBNb3JlIHNp bXBsaXN0aWMsIGZpdG5lc3MgdHJhY2tlcnMgaGF2ZSBiZWVuIHVzZWQgaW4gdGhlIHBhc3QgdG8g c3BvdCBzZWNyZXQgZGVwbG95bWVudHMgdmlhIHNvY2lhbCBuZXR3b3JrIG1hcHMsIGFuZCBzZWxm aWVzIHBvc3RlZCBvbiBGYWNlQm9vayB3aXRoIGVtYmVkZGVkIGV4aWYgR1BTIGNvb3JkaW5hdGVz IGhhdmUgYWxzbyBub3QgaGVscGVkLiBFdmVuIHdpdGhvdXQgYnJvYWRjYXN0aW5nIEdQUyBjb29y ZGluYXRlcywgaWYgY29tbXVuaWNhdGlvbiBoYXBwZW5zIG92ZXIgcmFkaW8gbGlua3Mgd2hlcmUg dGhlIGVuZW15IGNhbiB0YXAgaW50byB0aGUgY29yZSBwcm90b2NvbCBkYXRhIGJlbG93IHRoZSBl bmNyeXB0aW9uIGxheWVyLCBpdCBjYW4gc3RhcnQgdG8gcGllY2UgdG9nZXRoZXIgYSBwaWN0dXJl IG9mIGRlcGxveW1lbnRzLg0KDQpJZiB5b3UgbG9vayBpbnRvIG1lc2ggbmV0d29ya3MgdGhhdCBj b3VsZCBiZSB1c2VkIGluIGRpc2FzdGVyIGFyZWFzLCB5b3UgY291bGQgYWxzbyBoYXZlIGEgbWFz c2l2ZSBjaGFuZ2UgaW4gcm91dGluZyBob3BzIHdpdGggYSBuZXR3b3JrIHNpbWlsYXIgdG8gSVAs IGJ1dCBkaWZmZXJlbnQuIEhlcmUgc2FtZSBzdGF0ZXMgbWlnaHQgYmUgaW50ZXJlc3RlZCBpbiBj ZXJ0YWluIGRpc3NpZGVudHMgbW92aW5nIHdpdGggdGhlIGZsb3cgKGdvb2QvYmFkIGRlcGVuZHMg b24gdGhlIHBvaW50IG9mIHZpZXcpLiBRVUlDIGNvdWxkIGJlIGxheWVyZWQgb24gdG9wIG9mIHN1 Y2ggbmV0d29ya3MsIGFuZCBoZXJlIHRyYWNraW5nIGNvdWxkIGFsc28gYmUgaW50ZXJlc3Rpbmcg c2ltcGx5IGJ5IGxpc3RlbmluZyBpbiBvbiByYWRpby4NCg0KVGhhdCBzYWlkLCB0aGVyZSBhcmUg ZW5kbGVzcyBvdGhlciB3YXlzIHRvIHBpZWNlIHRvZ2V0aGVyIGluZm9ybWF0aW9uLCBub3QgbGVh c3QgdmlhIHRpbWluZyBhbmQgdHJhZmZpYyBwYXR0ZXJucywgc28gSSBhbSBub3QgY29udmluY2Vk IHRoYXQgdGhlIGVmZm9ydHMgdG8gaGlkZSBtaWdyYXRpb24gYXJlIHRydWx5IHdvcnRod2hpbGUg Z2l2ZW4gaG93IGRpZmZpY3VsdCBpdCBpcyB0byBnZXQgcmlnaHQsIGF0IGxlYXN0IG5vdCB3aXRo IHRoZSBjdXJyZW50IHVuZGVybHlpbmcgbmV0d29ya3MuDQo= --_000_B86788EEF2EA4DBBAD316FF99A99AAA6fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <411174BC732652409898E681F54AFB0F@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6ImhlbHZldGljYSBOZXVlIjsNCglwYW5vc2UtMToyIDAgNSAzIDAgMCAwIDIgMCA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIGNvdWxkIGlt YWdpbmUgKGkuZS4gdGhlb3JpemUpIGEgbmV0d29yayBmYWJyaWMgd2hpY2ggdXNlcyBwb2ludC10 by1wb2ludCBmbG93IGNvbnRyb2wgZm9yIGhvcHMgd2hlcmUgY29uZ2VzdGlvbiBvY2N1cnMgY291 cGxlZCB3aXRoIHBvaW50LXRvLXBvaW50IHJlLXhtaXNzaW9ucyB3aXRoIGZhaXItcXVldWluZyAo YSBob3N0IGNhbiBtb3N0bHkgb25seSBjb25nZXN0IGl0c2VsZikgd2hpY2ggd291bGQgYWxsb3cN CiBmb3IgZGF0YSB0byBiZSBzZW50IGludG8gdGhlIG5ldHdvcmsgYXQgYSBjb25zdGFudCByYXRl IHJlZ2FyZGxlc3Mgb2YgaG93IG11Y2ggYXBwbGljYXRpb24gZGF0YSBvbmUgbmVlZGVkIHRvIHNl bmQuPGJyPg0KPGJyPg0KSW4gc3VjaCBjYXNlcyAoeW91IGNhbiBmcmVlbHkgc2VuZCBieXRlcyB3 aXRob3V0IGNhdXNpbmcgY29uZ2VzdGlvbiB0byBvdGhlcnMpIHlvdeKAmWQgZWxpbWluYXRlIHRo ZSBuZWVkIGZvciB0aGUgZW5kcG9pbnRzIHRvIGNvbnN0cmFpbiB0aGUgc2VuZGluZyByYXRl4oCm IHdoaWNoIHdvdWxkIGltcGx5IHJlZHVjaW5nIG9yIGVsaW1pbmF0aW5nIHRoZSBlZmZpY2FjeSBv ZiB0cmFmZmljIGFuYWx5c2lzIGJhc2VkIG9uIHNpemUvdGltaW5nLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQXMgYSByZW1pbmRlciwgYWx0aG91Z2ggSSBiZWxp ZXZlIGl0IGlzIHBvc3NpYmxlIGFuZCBkZXNpcmFibGUsIHN1Y2ggbmV0d29ya3MgYXJlIG5vdCB3 aWRlbHkgZGVwbG95ZWQgQUZBSUNULCBhbmQgc28gdGhpcyBsaWtlbHkgcmVtYWlucyB0aGVvcmV0 aWNhbCAoYnV0IGl0IGlzIGEgdmVyeSBmdW4gdGhpbmcgdG8gdGhpbmsgYWJvdXQpLjxicj4NCjxi cj4NCklmIHN1Y2ggbmV0d29ya3Mgd2VyZSB3aWRlbHkgZGVwbG95ZWQsIHRoZW4gbGlua2FiaWxp dHkgd291bGQgYmVjb21lIGEgbW9yZSBwcmVzc2luZyBwcml2YWN5IGNvbmNlcm4gYXMgaXQgd291 bGQgYmUgdGhlICZuYnNwO3RoaW5nIHRoYXQgcHJvdmlkZWQgYXR0YWNrZXJzIHdpdGggdGhlIG1v c3QgaW5mb3JtYXRpb24uPGJyPg0KLT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5j b20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgRmVicnVhcnkgNiwgMjAxOSBhdCA5 OjQ0IEFNPGJyPg0KPGI+VG86IDwvYj5TcGVuY2VyIERhd2tpbnMgYXQgSUVURiAmbHQ7c3BlbmNl cmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtxdWljQGll dGYub3JnJnF1b3Q7ICZsdDtxdWljQGlldGYub3JnJmd0OywgSmFuYSBJeWVuZ2FyICZsdDtqcmku aWV0ZkBnbWFpbC5jb20mZ3Q7LCBNaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUm Z3Q7LCBUZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFpbC5jb20mZ3Q7LCBEYXZpZCBTY2hpbmF6 aSAmbHQ7ZHNjaGluYXppLmlldGZAZ21haWwuY29tJmd0OywgTWFydGluIFRob21zb24gJmx0O210 QGxvd2VudHJvcHkubmV0Jmd0OywgS2F6dWhvIE9rdSAmbHQ7a2F6dWhvb2t1QGdtYWlsLmNvbSZn dDssDQogJnF1b3Q7THViYXNoZXYsIElnb3ImcXVvdDsgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20m Z3Q7LCBSb2JlcnRvIFBlb24gJmx0O2Zlbml4QGZiLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UmU6IE5ldyBwYXRoID0mZ3Q7IG5ldyBjb25uZWN0aW9uIElELCByaWdodD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2EiPk9uIDYgRmVicnVhcnkgMjAxOSBhdCAxNy4yMC40MCwgU3BlbmNlciBEYXdr aW5zIGF0IElFVEYgKDxhIGhyZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNv bSI+c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDto ZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjpibGFjayI+SSBzYXcgVGVkJ3MgcmVmZXJlbmNlIHRv IHVzaW5nIGEgbmV3IENJRCB0aGF0IGhhZCBiZWVuIGFzc2lnbmVkIG9uIHRoZSBvbGQgY29ubmVj dGlvbiwgYnV0IG5ldmVyIHVzZWQgb24gdGhlIG9sZCBjb25uZWN0aW9uLiBEb2VzIHRoYXQgc3Rp bGwgZ28gdG8gdGhlIHdyb25nIGJhY2tlbmQNCiAocG90ZW50aWFsbHkpPyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw PklmIGl0IGlzIG5vdCB1bmVuY3J5cHRlZCBvbiB0aGUgd2lyZSBvbiB0aGUgb2xkIHBhdGgsIGl0 IGNvdWxkIEFGQUlLIG5vdCBnbyB3cm9uZyB3cnQuIHNlY3VyaXR5LiBJZiBhIENJRCBpcyBjb25z dHJ1Y3RlZCBmb3IgYSBzcGVjaWZpYyBwYXRoLCB0aGVuIHJvdXRpbmcgY291bGQgZ28gd3Jvbmcs IGJ1dCBzaG91bGQgbm90IGJlY2F1c2Ugd2UgZG9u4oCZdCBpc3N1ZSBDSUTigJlzIHBlciBwYXRo LCBhdCBsZWFzdCBub3QgaW4gVjEuIFRoaXMgbWVhbnMNCiBhbnkgcm91dGUgdG8gdGhlIGVuZHBv aW50IG11c3QgYmUgYWJsZSB0byBkZWFsIHdpdGggYW55IENJRCAoSSBiZWxpZXZlIEkgYXNrZWQg dGhlIHNhbWUgcXVlc3Rpb24gYSBsb25nIHRpbWUgYWdvKS4gSSBjb3VsZCBzZWUgdGhpcyBjaGFu Z2UgaW4gYSBmdXR1cmUgdmVyc2lvbiB3aXRoIG11bHRpLXBhdGggYW5kL29yIGlmIGVub3VnaCBk ZXBsb3ltZW50IGV4cGVyaWVuY2Ugc2hvd3MgdGhhdCB0aGVyZSBpcyBhIG5lZWQuIEl0IHdvdWxk IGJlIG11Y2gNCiBtb3JlIGNvbXBsZXggdG8gbWFpbnRhaW4gQ0lE4oCZcyB0aGVuLiBJdCBhbHJl YWR5IGNhdXNlcyBzb21lIHRyb3VibGUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O2hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOmJs YWNrIj48YnI+DQpEbyBwZW9wbGUgYWdyZWUgaG93IHBlcmZlY3Qgbm9uLWxpbmthYmlsaXR5IGhh cyB0byBiZT8gSSB0aGluayB0aGF0IHRyYW5zbGF0ZXMgaW50byAmcXVvdDtkbyBwZW9wbGUgYWdy ZWUgd2hldGhlciBzZW5kaW5nIGF0IGxlYXN0IG9uZSBwYWNrZXQgd2l0aCB0aGUgb2xkIENJRCBv biB0aGUgbmV3IGNvbm5lY3Rpb24gaXMgZmF0YWwmcXVvdDs/Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHA+SSB0aGlu ayB0aGlzIGRlcGVuZHMgZW50aXJlbHkgb24gdGhlIHRocmVhdCBtb2RlbC48bzpwPjwvbzpwPjwv cD4NCjxwPklmIHNvbWVvbmUgaGFzIGxpbWl0ZWQgY2FwYWNpdHkgdG8gc2FtcGxlIHRyYWZmaWMg dGhlbiBvbiBhdmVyYWdlIGl0IG1heSBub3QgYmUgYSBwcm9ibGVtLiBCdXQgaWYgeW91IGFyZSBz ZXJpb3VzLCBhbmQgeW91IGhhdmUgYWNjZXNzLCBhbGwgeW91IG5lZWQgdG8gZG8gaXMgdG8gbWFr ZSBhIGZpbmdlcnByaW50IG9mIGVhY2ggc291cmNlIGFuZCBkZXN0aW5hdGlvbiBjb25uZWN0aW9u IElEIHBhaXIgYW5kIHN0b3JlIGl0IGluIGEgYnVja2V0DQogd2l0aCBzb21lIGNvcnJlbGF0aW9u LCBlLmcuIGV2ZXJ5b25lIGFjY2Vzc2luZyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fZXhhbXBsZS5jb20mYW1wO2Q9RHdNRmFRJmFt cDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZh bXA7bT01ZmExVHBLaTd3dlNjSl9sT210cmRNVVJYWExuajZ6dnVmakk3a2lhM09BJmFtcDtzPWM2 VDRudFFtM0JJT3JERDMxVEwxQXhfWkxld0c1U3dsMGZSdmJBTndhb0UmYW1wO2U9Ij4NCmV4YW1w bGUuY29tPC9hPi4mbmJzcDtUaGVuIHlvdSBjYW4gdXNlIHRlY2huaXF1ZXMgc2ltaWxhciB0byBE TkEgc2VxdWVuY2luZyB0byBzdHJhbmQgdG8gdG9nZXRoZXIgYWxsIG1vdmVtZW50LCBldmVuIGlm IHlvdSBkbyBub3Qgc3RvcmUgcGVyZmVjdCBpbmZvcm1hdGlvbiBhdCBmdWxsIHByZWNpc2lvbi4g SGVyZSBkYXRhIGNvbGxlY3Rpb24gbmVlZHMgdG8gYmUgZmFzdCBzbWFsbCBhbmQgc2ltcGxlLCBi dXQgc2VxdWVudCBtaW5pbmcgY2FuIGJlIGRvbmUNCiB3aXRoIG1hc3NpdmUgcmVzb3VyY2VzIHdo ZW4geW91IGtub3cgd2hhdCB5b3UgYXJlIGxvb2tpbmcgZm9yLjxvOnA+PC9vOnA+PC9wPg0KPHA+ U3VjaCB0cmFja2luZyBpcyBub3QganVzdCBOU0EgdnMuIGF2ZXJhZ2UgSm9lLiBJdCBjYW4gYWxz byBiZSBhIGNvbmNlcm4gZm9yIG1pbGl0YXJ5IHBlcnNvbm5lbCBpbiB0aGUgZmllbGQuIE1vcmUg c2ltcGxpc3RpYywgZml0bmVzcyB0cmFja2VycyBoYXZlIGJlZW4gdXNlZCBpbiB0aGUgcGFzdCB0 byBzcG90IHNlY3JldCBkZXBsb3ltZW50cyB2aWEgc29jaWFsIG5ldHdvcmsgbWFwcywgYW5kIHNl bGZpZXMgcG9zdGVkIG9uIEZhY2VCb29rIHdpdGgNCiBlbWJlZGRlZCBleGlmIEdQUyBjb29yZGlu YXRlcyBoYXZlIGFsc28gbm90IGhlbHBlZC4gRXZlbiB3aXRob3V0IGJyb2FkY2FzdGluZyBHUFMg Y29vcmRpbmF0ZXMsIGlmIGNvbW11bmljYXRpb24gaGFwcGVucyBvdmVyIHJhZGlvIGxpbmtzIHdo ZXJlIHRoZSBlbmVteSBjYW4gdGFwIGludG8gdGhlIGNvcmUgcHJvdG9jb2wgZGF0YSBiZWxvdyB0 aGUgZW5jcnlwdGlvbiBsYXllciwgaXQgY2FuIHN0YXJ0IHRvIHBpZWNlIHRvZ2V0aGVyIGEgcGlj dHVyZQ0KIG9mIGRlcGxveW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHA+SWYgeW91IGxvb2sgaW50 byBtZXNoIG5ldHdvcmtzIHRoYXQgY291bGQgYmUgdXNlZCBpbiBkaXNhc3RlciBhcmVhcywgeW91 IGNvdWxkIGFsc28gaGF2ZSBhIG1hc3NpdmUgY2hhbmdlIGluIHJvdXRpbmcgaG9wcyB3aXRoIGEg bmV0d29yayBzaW1pbGFyIHRvIElQLCBidXQgZGlmZmVyZW50LiBIZXJlIHNhbWUgc3RhdGVzIG1p Z2h0IGJlIGludGVyZXN0ZWQgaW4gY2VydGFpbiBkaXNzaWRlbnRzIG1vdmluZyB3aXRoIHRoZSBm bG93IChnb29kL2JhZA0KIGRlcGVuZHMgb24gdGhlIHBvaW50IG9mIHZpZXcpLiBRVUlDIGNvdWxk IGJlIGxheWVyZWQgb24gdG9wIG9mIHN1Y2ggbmV0d29ya3MsIGFuZCBoZXJlIHRyYWNraW5nIGNv dWxkIGFsc28gYmUgaW50ZXJlc3Rpbmcgc2ltcGx5IGJ5IGxpc3RlbmluZyBpbiBvbiByYWRpby48 bzpwPjwvbzpwPjwvcD4NCjxwPlRoYXQgc2FpZCwgdGhlcmUgYXJlIGVuZGxlc3Mgb3RoZXIgd2F5 cyB0byBwaWVjZSB0b2dldGhlciBpbmZvcm1hdGlvbiwgbm90IGxlYXN0IHZpYSB0aW1pbmcgYW5k IHRyYWZmaWMgcGF0dGVybnMsIHNvIEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IHRoZSBlZmZvcnRz IHRvIGhpZGUgbWlncmF0aW9uIGFyZSB0cnVseSB3b3J0aHdoaWxlIGdpdmVuIGhvdyBkaWZmaWN1 bHQgaXQgaXMgdG8gZ2V0IHJpZ2h0LCBhdCBsZWFzdCBub3Qgd2l0aCB0aGUNCiBjdXJyZW50IHVu ZGVybHlpbmcgbmV0d29ya3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_B86788EEF2EA4DBBAD316FF99A99AAA6fbcom_-- From nobody Wed Feb 6 10:41:39 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545D6130F30 for ; Wed, 6 Feb 2019 10:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7cDJgxdnZ-8 for ; Wed, 6 Feb 2019 10:41:35 -0800 (PST) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730094.outbound.protection.outlook.com [40.107.73.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A1D130F32 for ; Wed, 6 Feb 2019 10:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aIJC4rg+uCv5l9yqolrWvFUev8mITmQ10ibtx+H6JLE=; b=shamSaPo7pO6oopRnnqKN8E8cT9nGNY6k3JLs7DNgBRJpvVNeSFXsQ3dRHmrus8uJe7ySzh9A7bZwbQ5U1wbyNRkbpdlQtMEvTyugnHL5WKRW20JEt2zlThd4ZIkyjqWrgEJ9sk3MRlFkfMWBg6sd0BVn+Fp+aJXqmiKGtT0F1k= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0661.namprd22.prod.outlook.com (10.173.191.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Wed, 6 Feb 2019 18:41:32 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2%4]) with mapi id 15.20.1558.021; Wed, 6 Feb 2019 18:41:32 +0000 From: Mike Bishop To: Stephen Farrell , Martin Thomson , "quic@ietf.org" Subject: RE: Allowed frames in 0-RTT Thread-Topic: Allowed frames in 0-RTT Thread-Index: AQHUvdImkUGGytjjp0y12F2IqxmBpKXSc6cAgACmFDA= Date: Wed, 6 Feb 2019 18:41:32 +0000 Message-ID: References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> In-Reply-To: <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR22MB0661; 6:y8zoP3XaeYX/onVbbmiobR0e/6uBuZ1pFG8tbeOK/DzddeeHs5DjZDiRWMTiM7ZaNTNpmoENWKEIrMJewHl2iJyDZ2CJYQU1Z6i5QxY4dijdIiDpBYqXtOmrG24xyOu/zlRnIqP1qDJXPNamNRbl764vmA3c3PsSHJgx5Cbi9M2BcXvYIq9E5noY8uRg0Mr2fOp6gFt1cyB0JzaZx6ftrO+x+CnxXAlwIz07oqcCo61s/Qeos9FgmLx8L5WYRyHJtY/De6//UKk0n+4+008sReDzdW7m6L9s5Ot1rGZbRXUOICRL+WLbWNcL0iDZHYtnNJGG1+dtYS+7kOcpV4ENvx1DY3xRJMrnbTgp3WmBc+v/4gDl3GKMH92CziEwTEQJkVolITDX2pdRAKQwOULQWd+HCzn7KT1KM12xWr+vj163kshMyrW08q9i8QN2ej1REjbgc4XJ4m7mk1ZDzrN8Sg==; 5:AaaxFYEsYB8xazZMYc/cH7/slKBiBWLFPHzkdTOBD8pTZcvsLYZza8g2vs2gPJAKXHMQiRX2XpczUvgNH0OkrfoQXyf9lPaKDLfm/mtIh/JF3Rpz6o00KCkVkg3PAJP+qwEM7VXzIl8aomNmD86ciJ1GNeWFVrAg/hGAFftNz9M3RGNKWnXFsorwd6dj+h/SyvTw401uZNO148bQxF5r3w==; 7:AmZwVt83NGPg913e4wyrNYSBsHp3oppGJKb6FguKdDP41jEg/Or7aH7bKd53UMxDTvcBClLOeujMazZ2eAv+vcZ25r6nDEPNsJg5K+G1YlR/Os8ycGoMojCGn4klpzgJzTs6hUjBc/kHdMreK9RXyQ== x-ms-office365-filtering-correlation-id: d87a8ec5-2caf-4a3d-d381-08d68c62b6ef x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0661; x-ms-traffictypediagnostic: CY4PR22MB0661: x-microsoft-antispam-prvs: x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39830400003)(346002)(376002)(366004)(136003)(189003)(199004)(13464003)(508600001)(446003)(229853002)(68736007)(2906002)(14454004)(102836004)(9686003)(86362001)(8936002)(55016002)(81156014)(53936002)(25786009)(8676002)(476003)(99286004)(97736004)(11346002)(6116002)(6436002)(76176011)(486006)(105586002)(66066001)(7696005)(81166006)(2501003)(71200400001)(316002)(74482002)(106356001)(6506007)(256004)(7736002)(26005)(110136005)(74316002)(305945005)(33656002)(3846002)(186003)(6246003)(71190400001)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0661; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +NkHJv8FhGW4JMQqkrgMK7nIuPwU82Fy2e2RQCN6hhpzYs0M91mkPO5iP24qIvtHMiKvmWZubDJ/vmdywnFIb5KYNKzg/pNJwEiA/0CanoK52pzMfSIoanG0AJeO50Xp1R9qE6FiS2o2NuuopnHjI3w12NVOp6zBhzp9uUL2z3cfqK7icUE8AWkz3o10h0UKH6lX3KS+2okR/i27+T7sZ3UAnzQ7ymTeAKfrKthslH9sq5Os7j5J8OgKTYdNtZJOoZbf0uBNJIH/1zivDMGVx6hIHirQIa3Rwy2aPoFPMSKNBUI1eoVBVEO5LW0Bxcz4CpA0hNlH7Raki8eD8HgNvSRJT386NtwOLGiEpCkvZpE47AEg7v4geZXUrDRqxGgHJPYgvuadt04gL8CC359vlwbK1Ae+RfjV+tdq7NTelWo= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: d87a8ec5-2caf-4a3d-d381-08d68c62b6ef X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2019 18:41:32.1806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0661 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 18:41:38 -0000 SSdtIG5vdCBhd2FyZSBvZiBhbnksIG1vc3RseSBiZWNhdXNlIHRoZSBwZW9wbGUgd2hvIGFyZSBk ZXBsb3lpbmcgMC1SVFQgYXJlIGFsc28gZGVwbG95aW5nIHRoZSBSRkMgb24gd2hhdCdzIHBlcm1p dHRlZCBpbiBIVFRQIChvciBob21lLWdyb3duIHJ1bGVzIHRoYXQgYXJlIGVxdWl2YWxlbnQpLiAg SSBrbm93IGluIG91ciBkaXNjdXNzaW9ucywgd2UndmUgZm9jdXNlZCBvbiBzaXR1YXRpb25zIHdo ZXJlIEdFVCBoYXMgc2lkZS1lZmZlY3RzLCBiZWNhdXNlIEdFVCBpcyBwZXJtaXR0ZWQgYnkgZGVm YXVsdC4gIElkZWFsbHksIHdlJ2QgYmUgYWJsZSB0byBkZWxheSB0aG9zZSBzaWRlLWVmZmVjdHMg dW50aWwgdGhlIGhhbmRzaGFrZSBjb21wbGV0ZXMsIGJ1dCBhIGZhbGxiYWNrIGlzIHRvIGVpdGhl ciBkaXNhYmxlIDAtUlRUIGZvciBzdWNoIHJlc291cmNlcyBvciAod29yc3QgY2FzZSkgdGVsbCBj dXN0b21lcnMgdGhlcmUgYXJlIG5vIGd1YXJhbnRlZXMgaWYgdGhleSBlbmFibGUgYm90aCBvcHRp b25zLg0KDQpJJ20gb24gYm9hcmQgd2l0aCBNYXJ0aW4ncyBpbml0aWFsIGFuYWx5c2lzLiAgTm90 aGluZyBpbiB0aGUgdHJhbnNwb3J0IGxheWVyIGhhcyBhIGxpZmV0aW1lIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoZSBjb25uZWN0aW9uLCBhbmQgdGhlIGNvbm5lY3Rpb24gd2lsbCBiZSB0b3JuIGRv d24gaWYgdGhlIGhhbmRzaGFrZSBkb2Vzbid0IGNvbXBsZXRlLCBzbyBJJ20gY29tZm9ydGFibGUg d2l0aCBoYXZpbmcgYSBwZXJtaXNzaXZlIDAtUlRUIHBvbGljeSBmb3IgdHJhbnNwb3J0IGZlYXR1 cmVzLiAgVGhlIGFwcGxpY2F0aW9uIGxheWVyIGlzIHJlc3BvbnNpYmxlIGZvciBkZWZpbmluZyB3 aGVuIDAtUlRUIGNhbiBiZSB1c2VkIHNhZmVseTsgaWYgd2UgZG9uJ3QgYWxyZWFkeSBoYXZlIGl0 IChJIGRvbid0IHRoaW5rIHdlIGRvKSwgd2Ugc2hvdWxkIHJlaXRlcmF0ZSBUTFMgMS4zJ3MgcmVx dWlyZW1lbnQgdGhhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgbWFrZSBzdWNoIGRlZmluaXRpb25z LCBhbmQgSSBzaG91bGQgYWRkIGEgcmVmZXJlbmNlIHRvIFJGQyA4NDcwIGluIHRoZSBIVFRQIGRy YWZ0Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyA8cXVpYy1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgU3RlcGhlbiBGYXJyZWxsDQpTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDYsIDIwMTkgMTI6NDEgQU0NClRvOiBNYXJ0aW4gVGhvbXNvbiA8bXRAbG93 ZW50cm9weS5uZXQ+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQWxsb3dlZCBmcmFtZXMg aW4gMC1SVFQNCg0KDQpwaXBpbmcgaW4gZnJvbSB0aGUgc2lkZWxpbmVzIHNvIEkgZG9uJ3QgZXhw ZWN0IHRoaXMgdG8gYmUgZm91bmQgc28gY29udmluY2luZywgaG93ZXZlci4uLg0KDQpPbiAwNi8w Mi8yMDE5IDA0OjExLCBNYXJ0aW4gVGhvbXNvbiB3cm90ZToNCj4gaXQgd291bGQgYmUgYSBtaXN0 YWtlIHRvIHRyeSB0byBtYWtlIGRlY2lzaW9ucyBhYm91dCAwLVJUVCBzYWZldHkgaW4gDQo+IHRo ZSB0cmFuc3BvcnQsIHdoZW4gcmVwbGF5IHJpc2tzIGFyZSBhbiBhcHBsaWNhdGlvbi1sYXllciBj b25jZXJuLg0KSSBiZWxpZXZlIHRoYXQgaXMgbm90IHRydWUgZm9yIHNvbWUgZGVjaXNpb25zLg0K DQpJZiB0aGUgV0cgZGVjaWRlIHRvIGRpc2FsbG93IHNvbWV0aGluZyB0aGF0IGNvdWxkIGNhdXNl IGFuIGFwcGxpY2F0aW9uIGxheWVyIGNvbmNlcm4gdGhlbiB0aGF0IHdpbGwgcmVtb3ZlIHRoZSBu ZWVkIHRvIGRvIGFwcGxpY2F0aW9uIGxheWVyIGFuYWx5c2VzIG9mIHJlcGxheS8wLXJ0dCBmb3Ig dGhvc2UgY2FzZXMuIEdpdmVuIGFwcGxpY2F0aW9uIGRldnMgd2lsbCBpbiBnZW5lcmFsIG5vdCBk byB0aG9zZSBhbmFseXNlcywgZGlzYWxsb3dpbmcgYXMgbXVjaCBhcyB5b3UgY2FuIChvZiB0aGUg cmlza3MgYXJpc2luZyBmcm9tIDAtcnR0KSBpbiB0aGUgdHJhbnNwb3J0IHNlZW1zIHNhZmVyIHRv IG1lLg0KDQpJZiB5b3Ugd2FudCB0byBuYW1lIGEgcHJpbmNpcGxlIElTVE0gdGhhdCAwLXJ0dCBp cyBhIHF1aXRlIGxpa2UgYSBkYW5nZXJvdXMgaW1wbGVtZW50LCB3aGljaCBzZWVtcyBiZXR0ZXIg YXZvaWRlZCBhcyBmYXIgYXMgcG9zc2libGUuDQoNCk9uZSBxdWVzdGlvbiB0aG91Z2ggLSBkbyB3 ZSBoYXZlIGFueSBpbmZvcm1hdGlvbiBhYm91dCByZWFsIHdvcmxkIDAtcnR0IGlzc3VlcyBhcmlz aW5nIGluIGh0dHAvdGxzMS4zIG9yIGlzIGl0IHN0aWxsIHRvbyBlYXJseT8gSWYgd2UgZGlkIGhh dmUgc3VjaCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZXR0ZXIgaW5mb3JtIHRoaXMgZGlzY3Vzc2lv bi4NCg0KQ2hlZXJzLA0KUy4NCg== From nobody Wed Feb 6 11:09:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87915130F29 for ; Wed, 6 Feb 2019 11:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=e/kXwgFl; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=W8zwTKCh 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 e-slJu0cnZhj for ; Wed, 6 Feb 2019 11:09:29 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F7D12426A for ; Wed, 6 Feb 2019 11:09:29 -0800 (PST) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x16J7FNo007211; Wed, 6 Feb 2019 11:09:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=habZVN379PwbdOHSucP80Dflx/1XAwIvBcs5msvqkl8=; b=e/kXwgFl7oZ22vndAg20EHQgbP/jGkx2BmuVa5HLVPaQTZPEua+soPfd4s04XSo8wsrW OWffcCvjrkHHckKhWOKBECoq96QAWYqsyqrUOQSFMCVgAXNKxdOnSUVmm4ZdTG9C3YLg 93W4X4vBQM9gH5nU/HLlM5WiSe92GX9F1+Y= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qg3hx8f7f-16 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Feb 2019 11:09:27 -0800 Received: from frc-hub06.TheFacebook.com (2620:10d:c021:18::176) by frc-hub04.TheFacebook.com (2620:10d:c021:18::174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 6 Feb 2019 11:07:16 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Wed, 6 Feb 2019 11:07:16 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=habZVN379PwbdOHSucP80Dflx/1XAwIvBcs5msvqkl8=; b=W8zwTKCh4JxqyhI7bLWwzyOtSu44hqzoPhGymncXbkkO2Lom7m0tXG1KuB3xfvDrRwWAvsXhQouOClGzk++HkoKM+2yNU196O8KThy09GvCRZyKLu8zp24C8v8z4SAhGrmedqf1nuwQnjtmBdoL2qBFRSDu/3hdS89vS/bOI/pg= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2757.namprd15.prod.outlook.com (20.179.157.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Wed, 6 Feb 2019 19:07:15 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084%5]) with mapi id 15.20.1580.019; Wed, 6 Feb 2019 19:07:15 +0000 From: Roberto Peon To: Martin Thomson , "quic@ietf.org" Subject: Re: Allowed frames in 0-RTT Thread-Topic: Allowed frames in 0-RTT Thread-Index: AQHUvdIitUfN0G/vX0qjykFuBgHad6XSnJYA Date: Wed, 6 Feb 2019 19:07:15 +0000 Message-ID: References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> In-Reply-To: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::7:55b7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2757; 20:x1K8BniNYlX4EeL2g4o35y36qjZ1KgqvPPqkgwThbAl716NGU7jzEwa48s/2dgc/jBrLF7o57xTbV0FSGTlTNxdG+NBKt6qKWje03/KTxiTp2iFBPIGrebfcm7MtzPRfEsGI7ltrC/vTBeUnL72Kvd8Xb7xpCNkY2WqRum48lcg= x-ms-office365-filtering-correlation-id: df88e4f9-2d1f-4bf3-0f19-08d68c664ec1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2757; x-ms-traffictypediagnostic: BYAPR15MB2757: x-microsoft-antispam-prvs: x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(136003)(366004)(39860400002)(51444003)(189003)(199004)(6436002)(6486002)(97736004)(33656002)(105586002)(25786009)(2501003)(106356001)(6306002)(102836004)(83716004)(71190400001)(6512007)(575854001)(86362001)(186003)(6246003)(486006)(68736007)(256004)(14444005)(305945005)(76176011)(36756003)(6506007)(8936002)(476003)(81166006)(2616005)(81156014)(71200400001)(446003)(8676002)(11346002)(99286004)(53936002)(2906002)(14454004)(46003)(229853002)(966005)(7736002)(478600001)(82746002)(58126008)(6116002)(316002)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2757; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CgxJqfKmyUslFZH8OV4Bf0X2QbO8sau+q5Uv356eHb8ebhcaGG2T5zYA5q03vrRSSRgMmDtyC1iVjFz+Jyvf9hOEnhaAr8M8SZF0mAEbLL1qAn75y6ydKsyP1dKq6weA69BmjnF3ySjZ//JOSzPzZtzWaIje+7kF4gWpneyuB0z071LWU91XhN4LF2J0cH0ArK34roOcA2dFtOnm/38nhukyikiD59JhxnQgrRNQYdefzw4VbZzNyGJ5TBy515SjlakvPcvTwCaB71BhP/gjNNqUu40yKfcCF/OKzNYW+Vv18hjvtr52GljEMSGcxPn3eEID9oS9vgLjkeIp78Pmmg3Rfk0+5u70rea0FCt3EpbkkWH+87/L6MnMwR/44NqqkxL8sSwTbv1oekNQD5Do4OMubobVz6TLE8GTTso6sv0= Content-Type: text/plain; charset="utf-8" Content-ID: <3C001D304189F443B5F321E7024E2101@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: df88e4f9-2d1f-4bf3-0f19-08d68c664ec1 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2019 19:07:15.3410 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2757 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-06_13:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 19:09:33 -0000 TWFrZXMgc2Vuc2UgdG8gbWUuDQpSZXBsYXkgaXMgc2VtYW50aWNhbGx5IGRhbmdlcm91cyB0byBh cHBsaWNhdGlvbnMgKGNoYXJnZSB5b3VyIGJhbmsgYWNjb3VudCB0d2ljZT8gQmFkKS4NCg0KUmVw bGF5IGlzIG1lcmVseSBjb21wdXRhdGlvbmFsbHkgZGFuZ2Vyb3VzIHRvIHRyYW5zcG9ydCAoaS5l LiBEb1MpLCB0aHVzIGVudGlyZWx5IGRpZmZlcmVudCBsZXZlbHMgb2YgcmlzayB3aGljaCBhcmUg Zml4ZWQgaW4gZGlmZmVyZW50IHdheXMtLSBpbmRlZWQsIHRoZSBvbmx5IHByb3ZhYmx5IHNhZmUg d2F5IHRvIGZpeCB0aGlzIGlzIHRvIGhhdmUgc2luZ2xlLXVzZSB0b2tlbnMgc3VwcGxpZWQgZnJv bSB0aGUgYXBwbGljYXRpb24gYW5kIChyZSl0cmFuc21pdHRlZCBhdCB0aGUgYXBwbGljYXRpb24t bGF5ZXIuIEFueSBvdGhlciBmaXggaXMgaGV1cmlzdGljL3Byb2JhYmlsaXN0aWMuDQoNCi09Ug0K DQrvu79PbiAyLzUvMTksIDg6MTIgUE0sICJRVUlDIG9uIGJlaGFsZiBvZiBNYXJ0aW4gVGhvbXNv biIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbXRAbG93ZW50cm9weS5uZXQ+ IHdyb3RlOg0KDQogICAgV2UgaGFkIGEgcmF0aGVyIHVuZnJ1aXRmdWwgZGlzY3Vzc2lvbiBhYm91 dCB0aGlzIHN1YmplY3QgaW4gVG9reW8sIGFuZCBpdCdzIG9uZSBvZiB0aGUgZmV3IHRoaW5ncyB3 ZSBkaWRuJ3QgY29tZSB0byBhIGNvbmNsdXNpb24gb24uICBJJ2QgbGlrZSB0byBzaGFyZSBteSBj b25jbHVzaW9uLiAgSG9wZWZ1bGx5IG90aGVycyBhZ3JlZS4NCiAgICANCiAgICAjIEJhY2tncm91 bmQNCiAgICANCiAgICBLYXp1aG8gb2JzZXJ2ZWQgdGhhdCBwcm9oaWJpdGluZyBSRVNFVF9TVFJF QU0gZnJvbSAwLVJUVCBtYWRlIGl0IGF3a3dhcmQgdG8gY2FuY2VsIHN0cmVhbXMuICBJbiB0aGUg ZW5zdWluZyBkaXNjdXNzaW9uLCB3ZSBpZGVudGlmaWVkIHRoYXQgdGhlcmUgbWlnaHQgYmUgdXNl IGNhc2VzIGZvciBvdGhlciBmcmFtZSB0eXBlcy4NCiAgICANCiAgICBodHRwczovL2dpdGh1Yi5j b20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8yMzQ0IGNvbnRhaW5zIHRoZSBmdWxsIGRpc2N1 c3Npb24uICBUaGVyZSdzIHNvbWUgZ29vZCBzdHVmZiB0aGVyZSBpZiB5b3Ugd2FudCB0byBzcGVu ZCBzb21lIG1vcmUgdGltZSByZWFkaW5nLiAgSSBhcG9sb2dpemUsIGJ1dCB0aGlzIGlzIGEgZGlm ZmljdWx0IHRvcGljLiAgSXQncyBhIGxvbmcgdGhyZWFkIGJ1dCB0aGlzIGVtYWlsIG1pZ2h0IGJl IHdvcnNlLg0KICAgIA0KICAgICMgUmlzayBBbmFseXNpcw0KICAgIA0KICAgIDAtUlRUIGNvbWVz IHdpdGggcmlza3MsIHByaW1hcmlseSB0aG9zZSBhcmlzaW5nIGZyb20gcmVwbGF5LiAgQnV0IHRo b3NlIHJpc2tzIGFyZSBub3QgYm9ybmUgYnkgUVVJQyB0aGV5IGRlcGVuZCBvbiB0cmlnZ2VyaW5n IGFjdGlvbnMgaW4gdGhlIGFwcGxpY2F0aW9uIHRoYXQgdXNlcyBRVUlDLiAgRm9yIGluc3RhbmNl LCBIVFRQIFBPU1QgcmVxdWVzdHMgY2FuIGhhdmUgY29uc2VxdWVuY2VzIHRoYXQgYWx0ZXIgdGhl IHN0YXRlIG9mIHJlc291cmNlcyBhbmQgdGhvc2UgY29uc2VxdWVuY2VzIGFmZmVjdCBmdXR1cmUg Y29ubmVjdGlvbnMuICBUaGF0IGlzIHdoeSB3ZSBoYXZlIFJGQyA4NDcwLCB3aGljaCBkZXNjcmli ZXMgdGhlc2Ugcmlza3MgYW5kIG1pdGlnYXRpb24gc3RyYXRlZ2llcyBmb3IgSFRUUC4NCiAgICAN CiAgICAwLVJUVCBhZmZlY3RzIHRoZSBzdGF0ZSBvZiBhIFFVSUMgY29ubmVjdGlvbiwgYnV0IHRo ZSBlZmZlY3RzIGRvbid0IGV4dGVuZCBiZXlvbmQgYSBjb25uZWN0aW9uIHVubGVzcyB0aGUgYXBw bGljYXRpb24gcHJvdG9jb2wgcGVybWl0cyBpdC4gIFRodXMsIHRoZSBjb25zZXF1ZW5jZXMgb2Yg cmVwbGF5IG9uIFFVSUMgaXMgbGltaXRlZCB0byBoYXZpbmcgbW9yZSBjb25uZWN0aW9ucyBjcmVh dGVkLiAgQW55IHJlcGxheWVkIGFjdGlvbnMgd2lsbCBhY2N1bXVsYXRlIHRvIHRob3NlIHJlcGxh eWVkIGNvbm5lY3Rpb25zLiAgVWx0aW1hdGVseSBob3dldmVyLCBvbmx5IG9uZSBvZiB0aGUgY29u bmVjdGlvbnMgd2lsbCBiZSBjb21wbGV0ZWQuDQogICAgDQogICAgU29tZSBwZW9wbGUgaW4gdGhl IGRpc2N1c3Npb24gd2VyZSB1bmhhcHB5IGFib3V0IHRoaXMgc2l0dWF0aW9uLiAgSWYgdGhleSBh cmUgbm90IGFibGUgdG8gcmVjb2duaXplIHJlcGxheWVkIGNvbm5lY3Rpb24gYXR0ZW1wdHMgdXNp bmcgdGhlIHRlY2huaXF1ZXMgZGVzY3JpYmVkIGluIFJGQyA4NDQ2LCB0aGVuIHRoZXkgd291bGQg YmUgb2JsaWdhdGVkIHRvIHByb2Nlc3MgdGhvc2UgY29ubmVjdGlvbnMuDQogICAgDQogICAgSSBk b24ndCBzZWUgdGhpcyBhcyBjaGFuZ2luZyB0aGUgb3ZlcmFsbCBhc3Nlc3NtZW50LiAgV2hlbiBh IHNlcnZlciBhY2NlcHRzIGEgY29ubmVjdGlvbiBhdHRlbXB0LCB0aGV5IGhhdmUgdG8gZXhwZWN0 IHRvIHRha2Ugb24gdGhlIHN0YXRlIGFuZCBwcm9jZXNzaW5nIGNvc3RzIG9mIGhhbmRsaW5nIHRo YXQgY29ubmVjdGlvbi4gIElmIHRoYXQgY29ubmVjdGlvbiB0dXJucyBvdXQgdG8gYmUgYm9ndXMs IHRoZW4gYW55IGV4cGVuZGVkIGVmZm9ydCBpcyBmcnVpdGxlc3MsIGJ1dCBubyBtb3JlIHRoYW4g dGhhdC4NCiAgICANCiAgICBZZXMsIHRoZSBhZGRpdGlvbiBvZiAwLVJUVCBjaGFuZ2VzIHRoZSBj YWxjdWx1cyBzbGlnaHRseSwgYmVjYXVzZSBpbXBlcmZlY3QgcmVwbGF5IGRldGVjdGlvbiBjYW4g YmUgZXhwbG9pdGVkIHRvIG1vcmUgY2hlYXBseSBpbmR1Y2Ugc2VydmVyIHdvcmsgcmVsYXRlZCB0 byBmcmFtZSBwcm9jZXNzaW5nLiAgQWxsb3cgTiByZXBsYXlzIGFuZCB5b3UgY2FuIGdldCBOIHRp bWVzIHRoZSB3b3JrIHdpdGhvdXQgaGF2aW5nIHRvIHJlZG8gdGhlIGhlYXZ5IGNyeXB0byAoaS5l LiwgbW9zdGx5IGtleSBleGNoYW5nZSwgYnV0IGFsc28gcGFja2V0IHByb3RlY3Rpb24pLiAgQnV0 IHRoYXQncyBhIHJpc2sgdGhhdCBzZXJ2ZXJzIG5lZWQgdG8gaW50ZWdyYXRlIGludG8gdGhlaXIg YXNzZXNzbWVudCBhYm91dCB3aGV0aGVyIHRvIGFjY2VwdCAwLVJUVC4gIDAtUlRUIGNhbiBiZSBh Y2NlcHRlZCBvbmx5IHdoZW4gc2VydmVycyBoYXZlIHN1ZmZpY2llbnQgc3BhcmUgY2FwYWNpdHkg dG8gY292ZXIgYW55IGNvc3RzIGZyb20gcmVwbGF5LiAgVGhlcmUgc2hvdWxkIGJlIGEgaGFyZCB1 cHBlciBib3VuZCBvbiB0aGUgbnVtYmVyIG9mIHJlcGxheXMgdGhhdCBtaWdodCBiZSBhY2NlcHRl ZCBieSBhIHNlcnZlciwgbm8gbWF0dGVyIHRoZSBzaXplIG9mIHlvdXIgZGVwbG95bWVudCwgc28g dGhlIGNvc3RzIGFyZSBmaW5pdGUuDQogICAgDQogICAgVGhlIHNwZWNpZmljIGNvbmNlcm4gcmFp c2VkIHdhcyB0aGF0IHRoZSBjb3N0cyBvZiBwcm9jZXNzaW5nIG92ZXJoZWFkIGZyYW1lcyAoZmxv dyBjb250cm9sIHVwZGF0ZXMsIFBJTkcsIGV0Yy4uLikgYXJlIG5vdCBsaW1pdGVkIGluIGFueSB3 YXkuICBIb3dldmVyLCBJIHdvdWxkIGNvbnRlbmQgdGhhdCB0aG9zZSBhcmUgY2hlYXAgYW5kIHJl cHJlc2VudCBhIGxvd2VyIGNvc3QtcGVyLWJ5dGUgdG8gcHJvY2VzcyB0aGFuIFNUUkVBTSwgYW5k IHdlJ3JlIG5vdCBhYm91dCB0byBiYW4gc2VuZGluZyBvZiBTVFJFQU0gZnJhbWVzIGluIDAtUlRU LiAgQW55IHNlcnZlciBzaG91bGQgaGF2ZSBkZWZlbnNlcyBhZ2FpbnN0IGNsaWVudHMgdGhhdCBj YXVzZSB1c2VsZXNzIHRocmFzaGluZyBieSBzZW5kaW5nIHBvaW50bGVzcyBvciB3YXN0ZWZ1bCBm cmFtZXMgKFNlY3Rpb24gMTAuNSBvZiBSRkMgNzU0MCBnb2VzIGludG8gZGV0YWlsIGFib3V0IHRo aXMgc3R5bGUgb2YgYXR0YWNrKS4gIFRoZSBjb21iaW5hdGlvbiBvZiB0aGF0IHN0eWxlIG9mIGRl ZmVuc2UgYW5kIGxpbWl0cyBvbiByZXBsYXlzIGlzIHN1ZmZpY2llbnQgaW4gbXkgdmlldy4NCiAg ICANCiAgICAjIENob2ljZSBvZiBQcmluY2lwbGVzDQogICAgDQogICAgV2hhdCBwcmluY2lwbGUg Y2FuIHdlIHVzZSB0byBtb3RpdmF0ZSBhIGRlY2lzaW9uPw0KICAgIA0KICAgIEl0IHdhcyBzdWdn ZXN0ZWQgdGhhdCB3ZSBvbmx5IGVuYWJsZSBmcmFtZXMgZm9yIHdoaWNoIHdlIGhhdmUgYW4gYW5h bHlzaXMgdGhhdCBzdXBwb3J0cyBlbmFibGluZyBpdCBpbiAwLVJUVC4gIEhvd2V2ZXIsIG15IGFu YWx5c2lzIHN1Z2dlc3RzIHRoYXQgdGhpcyBpcyBldmVyeSBmcmFtZSB0aGF0IGRvZXMgbm90IGNh cnJ5IGluZm9ybWF0aW9uIGZvciBhbiBhcHBsaWNhdGlvbiBwcm90b2NvbCAoaS5lLiwgZXZlcnl0 aGluZyBleGNlcHQgU1RSRUFNLCBhbmQgbWF5YmUgUkVTRVRfU1RSRUFNIGFuZCBTVE9QX1NFTkRJ TkcpLiAgQW5kIHdlIHdhbnQgdG8gaW5jbHVkZSBmcmFtZXMgZm9yIHRoZSBhcHBsaWNhdGlvbiBw cm90b2NvbCBvciB0aGVyZSBpcyBubyBwb2ludCBpbiBkb2luZyAwLVJUVCBhdCBhbGwuICBTbyBJ IGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSB1c2FibGUgcHJpbmNpcGxlIGluIHRoYXQgbGlu ZSBvZiByZWFzb25pbmcuDQogICAgDQogICAgVGhhdCBsZWF2ZXMgdGhlIHRoYXQgd2UgZmluZCB0 aGUgc2V0IG9mIHRoaW5ncyB3ZSBrbm93IGFyZSBuZWVkZWQgYW5kIGp1c3QgZW5hYmxlIHRob3Nl LiAgVGhlIHByaW5jaXBsZSB0aGVyZSBiZWluZyBZQUdOSS4gIFRoaXMgc2VlbXMgbGlrZSBhIGZp bmUgcHJpbmNpcGxlLiAgSXQgc2VlbXMgbGlrZSBwZW9wbGUgd2VyZSBnZW5lcmFsbHkgT0sgd2l0 aCBTVFJFQU0gYW5kIGFsbCByZWxhdGVkIGZyYW1lcy4NCiAgICANCiAgICBUaGUgY29zdCBvZiBk b2luZyB0aGF0IGlzIHRoYXQgeW91IGhhdmUgdG8gdHJlYXQgMC1SVFQgc3BlY2lhbGx5LiAgVGhp cyBpcyBhbHJlYWR5IHNvbWV3aGF0IG5lY2Vzc2FyeSBhcyBhIHJlY2VpdmVyLCBiZWNhdXNlIHRo ZXJlIGFyZSBydWxlcyBhYm91dCBwYWNrZXQgcHJvY2Vzc2luZyB0aGF0IGFwcGx5LiAgQXMgYSBz ZW5kZXIsIHRoaXMgY29uc3RyYWlucyBiZWhhdmlvdXIgaW4gdGhlIHNhbWUgYXdrd2FyZCB3YXlz IHRoYXQgS2F6dWhvIG9yaWdpbmFsbHkgaWRlbnRpZmllZC4gIElmIHlvdSBjYW4ndCB1cGRhdGUg ZmxvdyBjb250cm9sIGxpbWl0cywgeW91IGhhdmUgdG8gc2V0IGFueSBpbmNyZWFzZXMgYXNpZGUg Zm9yIHNlbmRpbmcgb25jZSB0aGUgaGFuZHNoYWtlIGNvbXBsZXRlcy4gIEl0IGFkZHMgdW5uZWNl c3NhcnkgY29tcGxleGl0eS4NCiAgICANCiAgICBTbyBJIHdvdWxkIGluc3RlYWQgYWR2b2NhdGUg Zm9yIGEgZGlmZmVyZW50IHByaW5jaXBsZTogaXQgd291bGQgYmUgYSBtaXN0YWtlIHRvIHRyeSB0 byBtYWtlIGRlY2lzaW9ucyBhYm91dCAwLVJUVCBzYWZldHkgaW4gdGhlIHRyYW5zcG9ydCwgd2hl biByZXBsYXkgcmlza3MgYXJlIGFuIGFwcGxpY2F0aW9uLWxheWVyIGNvbmNlcm4uDQogICAgDQog ICAgSWYgdGhlIGFwcGxpY2F0aW9uIHJlcXVlc3RzIHRoYXQgdGhlIHRyYW5zcG9ydCBkbyBzb21l dGhpbmcsIHRoZW4gdGhlIGFwcGxpY2F0aW9uIHRha2VzIHJlc3BvbnNpYmlsaXR5IGZvciBhbnkg cmlzayBvZiByZXBsYXkuICBUaGUgdHJhbnNwb3J0IGlzIG5vdCBjb25zdHJhaW5lZCBpbiBob3cg aXQgb3BlcmF0ZXMgaW4gMC1SVFQuICBUaGUgdHJhbnNwb3J0IHVzZXMgMC1SVFQgcGFja2V0cyB3 aXRob3V0IHJlZ2FyZCB0byB0aGUgcmlzayBvZiByZXBsYXkuICBUaGF0IHNhaWQsIGFzIFJvYmVy dG8gaXMgZm9uZCBvZiBzYXlpbmcsIHNlcnZlcnMgd2lsbCBkbyB3aGF0IHRoZXkgbmVlZCB0byBk by4gIEkgaGF2ZSBubyBkb3VidCB0aGF0IGFsbCBpbnB1dHMgd2lsbCBiZSBzdWJqZWN0IHRvIG1v cmUgc2NydXRpbnkgYW5kIGNhdXRpb24gYmVmb3JlIHRoZSBoYW5kc2hha2UgaXMgY29tcGxldGUu ICBCdXQgdGhhdCdzIG9uIGluZGl2aWR1YWwgaW1wbGVtZW50YXRpb25zLCBpdCdzIG5vdCBhIHBy aW5jaXBsZWQgcG9zaXRpb24gYW55IG1vcmUgdGhhbiBoYXZpbmcgdG8gdXNlIElQIGFkZHJlc3Mg cmVwdXRhdGlvbiB0byBtYW5hZ2UgRG9TIGlzLg0KICAgIA0KICAgIFRoaXMgcHJpbmNpcGxlIGtl ZXBzIHRoZSB0cmFuc3BvcnQgc2ltcGxlLiAgVGhlIG9ubHkgYWZmb3JkYW5jZSBuZWVkZWQgdGhl biBpcyB0byBlbnN1cmUgdGhhdCB0aGUgYXBwbGljYXRpb24gaXMgYXdhcmUgb2Ygd2hlbiBpdCBp cyBhdCByaXNrIG9mIHJlcGxheS4gIFRoZSB0cmFuc3BvcnQgZW5zdXJlcyB0aGF0IHRoZSBhcHBs aWNhdGlvbiBrbm93cyB3aGVuIGRhdGEgaXQgc2VuZHMgbWlnaHQgYmUgcmVwbGF5ZWQuICBPbmNl IGEgcmVxdWVzdCBpcyBtYWRlIGJ5IHRoZSBhcHBsaWNhdGlvbiwgdGhlIHRyYW5zcG9ydCBzZW5k cyBpdC4gIElmIGl0IHdhbnRzIHRvIHNlbmQgZmxvdyBjb250cm9sIHVwZGF0ZXMsIGl0IGNhbi4N CiAgICANCiAgICBTbyBJIHRoaW5rIHRoYXQgdGhlIHR3byBjYW5kaWRhdGVzIGFyZToNCiAgICAN CiAgICAqIFlBR05JLCB3aXRoIGNvbnN0cmFpbnRzDQogICAgKiAwLVJUVCBpcyBhbiBhcHBsaWNh dGlvbiBjb25jZXJuDQogICAgDQogICAgIyBBZmZlY3RlZCBGcmFtZXMNCiAgICANCiAgICBJZiB5 b3UgbG9vayBhdCB0aGUgbGlzdCBvZiBmcmFtZSB0eXBlcywgdGhlIGludGVyZXN0aW5nIHRoaW5n IGlzIHRoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGVzZSBwb3NpdGlvbnMgaXMgaW4gYSB2 ZXJ5IHNtYWxsIHN1YnNldCBvZiBmcmFtZXMuICBIZXJlJ3MgdGhlIGNvbXBsZXRlIGxpc3QgKGlu Y2x1ZGluZyB0aGUgdXBjb21pbmcsIHRvLWJlLW5hbWVkIEtFWVNfUkVBRFkgZnJhbWUpOg0KICAg IA0KICAgIDB4MDAgICAgICBQQURESU5HIC0gYWxyZWFkeSBhbGxvd2VkDQogICAgMHgwMSAJUElO RyAtIGluIHF1ZXN0aW9uLCBidXQgaGFybWxlc3M7IHNlbmRpbmcgYSByZWR1bmRhbnQgU1RSRUFN IGZyYW1lIHdvdWxkIGhhdmUgdGhlIHNhbWUgZWZmZWN0DQogICAgMHgwMiAtIDB4MDMgCUFDSyAt IGltcG9zc2libGUNCiAgICAweDA0IAlSRVNFVF9TVFJFQU0gLSB0aGUgdHJpZ2dlciBmb3IgdGhp cyBtZXNzOyBidXQgd2Ugc2VlbSB0byB3YW50IGl0DQogICAgMHgwNSAJU1RPUF9TRU5ESU5HIC0g bW9yZSB2YWx1YWJsZSB0aGFuIFJFU0VUX1NUUkVBTSBpbiBtYW55IHdheXMNCiAgICAweDA2IAlD UllQVE8gLSBpbXBvc3NpYmxlDQogICAgMHgwNyAJTkVXX1RPS0VOIC0gaW1wb3NzaWJsZQ0KICAg IDB4MDggLSAweDBmIAlTVFJFQU0gLSB2ZXJ5IGltcG9ydGFudCwgdGhlIG1vc3QgZGFuZ2Vyb3Vz LCBhbmQgYWxyZWFkeSBhbGxvd2VkDQogICAgMHgxMCAJTUFYX0RBVEEgLSBzZWVtcyB1c2VmdWwN CiAgICAweDExIAlNQVhfU1RSRUFNX0RBVEEgLSBzZWVtcyB1c2VmdWwNCiAgICAweDEyIC0gMHgx MyAJTUFYX1NUUkVBTVMgLSBzZWVtcyB1c2VmdWwNCiAgICAweDE0IAlEQVRBX0JMT0NLRUQgLSBl aXRoZXIgcmVkdW5kYW50IC0gYmVjYXVzZSBjb25uZWN0aW9uIGZsb3cgY29udHJvbCBpcyB1c2Vk IHRvIGxpbWl0IDAtUlRUIC0gb3IgdXNlZnVsIC0gYmVjYXVzZSBrbm93aW5nIHdoZW4gMC1SVFQg ZmxvdyBjb250cm9sIGxpbWl0cyBhcmUgaGl0IGlzIHVzZWZ1bCBpbmZvcm1hdGlvbjsgdGhpcyBt aWdodCBkZXBlbmQgb24gd2hldGhlciB5b3UgdGhpbmsgdGhhdCB0aGUgYmxvY2tlZCBzaWduYWxz IGFyZSB1c2VmdWwgaW4gZ2VuZXJhbA0KICAgIDB4MTUgCVNUUkVBTV9EQVRBX0JMT0NLRUQgLSBt YXJnaW5hbGx5IHVzZWZ1bA0KICAgIDB4MTYgLSAweDE3IAlTVFJFQU1TX0JMT0NLRUQgLSBtYXJn aW5hbGx5IHVzZWZ1bA0KICAgIDB4MTggCU5FV19DT05ORUNUSU9OX0lEIC0gaW4gcXVlc3Rpb24N CiAgICAweDE5IAlSRVRJUkVfQ09OTkVDVElPTl9JRCAtIGltcG9zc2libGUNCiAgICAweDFhIAlQ QVRIX0NIQUxMRU5HRSAtIGluIHF1ZXN0aW9uDQogICAgMHgxYiAJUEFUSF9SRVNQT05TRSAtIGlt cG9zc2libGUNCiAgICAweDFjIC0gMHgxZCAJQ09OTkVDVElPTl9DTE9TRSAtIHBvdGVudGlhbGx5 IHVzZWZ1bA0KICAgIDB4Pz8gICAgICAgS0VZU19SRUFEWSAtIGltcG9zc2libGUNCiAgICANCiAg ICBZb3UgY2FuIHNlZSB0aGF0IG1hbnkgb2YgdGhlc2UgZnJhbWVzIHNpbXBseSBjYW4ndCBiZSBz ZW50LiAgTW9zdGx5IGJlY2F1c2UgdGhleSBhbnN3ZXIgc29tZXRoaW5nIHRoYXQgdGhlIHNlcnZl ciB3b3VsZCBzZW5kIGluIDEtUlRULCBhbmQgdGhlIGNsaWVudCBjYW4ndCByZXNwb25kIGluIDAt UlRUIHRvIDEtUlRUIHBhY2tldHMgKGl0IGhhcyB0byB1c2UgMS1SVFQgZm9yIHRoYXQpLiAgV2Ug Y291bGQgZXhwbGljaXRseSBwcm9oaWJpdCB0aG9zZSBmcmFtZXMsIGJ1dCBpdCBpcyBzdWZmaWNp ZW50IGluIG15IHZpZXcgdG8gcmVseSBvbiB0aGUgZXhpc3RpbmcgcnVsZXMuICBXZSBkb24ndCBu ZWVkIHRvIGdvIHRocm91Z2ggYW5kIHBpZWNlbWVhbCBwcm9oaWJpdCBmcmFtZXMsIHRob3VnaCB3 ZSBjb3VsZCBwb2ludCBvdXQgZm9yIGVhY2ggb25lIHRoZSBpbXBvc3NpYmlsaXR5IG9mIGl0IGJl aW5nIGluIDAtUlRULCBpdCB3b3VsZCBiZSByZWR1bmRhbnQgdG8gZG8gc28uDQogICAgDQogICAg Rm9yIHRob3NlIHRoYXQgYXJlIGdlbnVpbmVseSBpbiBxdWVzdGlvbjogUElORywgTkVXX0NPTk5F Q1RJT05fSUQsIGFuZCBQQVRIX0NIQUxMRU5HRSwgdGhpcyBtaWdodCBzZWVtIGxpa2UgYSB3YXN0 ZSBvZiB0aW1lIGFuZCBlZmZvcnQgdG8gdGFsayBhYm91dCwgYnV0IHdlIGFyZSB0YWxraW5nIGFi b3V0IGVzdGFibGlzaGluZyBndWlkZWxpbmVzIG9uIHdoYXQgY2FuIGFuZCBjYW5ub3QgYmUgc2Vu dCBpbiAwLVJUVC4gIFdlIGFyZSBkZWNpZGluZyB3aGF0IGZhY3RvcnMgbmVlZCB0byBiZSBjb25z aWRlcmVkIHdoZW4gbmV3IGZyYW1lcyBhcmUgZGVmaW5lZC4NCiAgICANCiAgICAjIENvbmNsdXNp b24NCiAgICANCiAgICBBc3NpZ25pbmcgcmVzcG9uc2liaWxpdHkgZm9yIHJlcGxheSBkZWZlbnNl IHRvIGFwcGxpY2F0aW9uIHByb3RvY29scyBpcyB0aGUgY2xlYXJlc3QgcHJpbmNpcGxlIHdlIGNh biBhcHBseS4gIFRoYXQgaXMsIHRoZSB0cmFuc3BvcnQgZG9lcyBub3QgaGF2ZSBhbnkgaW5oZXJl bnQgb3BpbmlvbiBhYm91dCByZXBsYXkgcmlzay4gIEFsbCBmcmFtZXMgYXJlIGZvciB0aGUgdHJh bnNwb3J0IGFuZCBub25lIG9mIHRoZW0gYXJlIHNwZWNpYWxseSBwcml2aWxlZ2VkIGZvciB1c2Ug aW4gMC1SVFQuICBXaGF0IGFuIGFwcGxpY2F0aW9uIHByb3RvY29sIGVuZHBvaW50IGRlY2lkZXMg dG8gZG8gd2l0aCB0aGUgdHJhbnNwb3J0IGluIDAtUlRUIGlzIGFuIGFwcGxpY2F0aW9uIHJlc3Bv bnNpYmlsaXR5LiAgQW4gYW5hbHlzaXMgb2YgcmVwbGF5IHJpc2tzIGlzIGFsd2F5cyBwZXJmb3Jt ZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGFwcGxpY2F0aW9uIHByb3RvY29sLg0KICAgIA0KICAg IEJhc2VkIG9uIHRoaXMsIG15IHZpZXcgaXMgdGhhdCBpdCB3b3VsZCBiZSBhIG1pc3Rha2UgdG8g Z28gd2l0aCBZQUdOSS4gIERvaW5nIHRoYXQgc2lnbnMgdXMgdXAgZm9yIGEgd2hvbGUgYnVuY2gg b2YgZGlmZmljdWx0IGFuYWx5c2lzIGZvciBldmVyeSBmcmFtZSwgaGF2aW5nIHRvIGFudGljaXBh dGUgdGhlIG1hbnkgd2F5cyBpbiB3aGljaCBpdCBtaWdodCBiZSBhYnVzZWQgYnkgYXBwbGljYXRp b25zLiAgSW5zdGVhZCwgSSB0aGluayB0aGF0IHdlIHNob3VsZCBhcnRpY3VsYXRlIHRoZSBjb25z aWRlcmF0aW9ucyB0aGF0IGJyb2FkbHkgYXBwbHkgYW5kIHJlcXVpcmUgdGhhdCBhcHBsaWNhdGlv biBwcm90b2NvbHMgZG8gdGhlIGFuYWx5c2lzLg0KICAgIA0KICAgIFRoaXMgaXMgbm90IGp1c3Qg YmVjYXVzZSBJIGhhdmUgYSBQUiBtb3N0bHkgcmVhZHkgKGFic2VudCB0aGlzIGxhc3QgYml0IGFi b3V0IGNvbnNpZGVyYXRpb25zIGFuZCBhcHBsaWNhdGlvbiByZXNwb25zaWJpbGl0eSwgd2hpY2gg SSBwbGFuIHRvIGFkZCBzb29uKS4gIFRob3VnaCBJIGhhdmUgbm8gZGVzaXJlIHRvIHdyaXRlIHVw IHRoZSBwaWVjZW1lYWwgYWxsb3cvZGVueSBzdHVmZiwgSSB3aWxsIGlmIEkgaGF2ZSB0bywgYnV0 IGl0IHdpbGwgb25seSBiZSBiZWNhdXNlIEknbSBpbiB0aGUgcm91Z2guDQogICAgDQogICAgaHR0 cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzIzNTUNCiAgICANCiAgICAN Cg0K From nobody Wed Feb 6 17:59:53 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE26130FB4 for ; Wed, 6 Feb 2019 17:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=R9KNKy0a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Q3Re9U+I 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 L8IwqX4F_FFD for ; Wed, 6 Feb 2019 17:59:50 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2065D130FAB for ; Wed, 6 Feb 2019 17:59:50 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A4D952204E; Wed, 6 Feb 2019 20:59:48 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 06 Feb 2019 20:59:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:date:subject:references:in-reply-to; s=fm1; bh=d1N As1UBKx3ZQrisunpFxzAUQ0W3xg+yoBTccxADYZI=; b=R9KNKy0aJEAlYtoGl4U aZJz2h7axhFiSx5+WejXETwqaMZ0k7/LQVBUJrr3YmRcMbP2pyslOTlIC7lZe3dX H8e40fVem/eHe+rhMuvIsVJEs9YuH2xxPvwOzUG1PH7LG0Q066Fl9GcAdefUxeEt io3TJo6S6f2CIy0DyEsV/zLkRwwjwGXUdp7CPzwzJ4PflqhPrH40CHLezasiHuF+ OrF4mbHGKXGHqUl48Hxs51a9GGttJjqxlcxvWckruzuhroWoksC02wGIrY5l3K+8 ioAsDAxkAZV08Fr/TQKeUxagklrOCRGsdaCWNPBrytGyAZRlhhbRMAGPEMjAxvd+ gzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=d1NAs1UBKx3ZQrisunpFxzAUQ0W3xg+yoBTccxADY ZI=; b=Q3Re9U+IhGfeHC5XjOe0S09fdImiVf7yniUpI71YPyDMih3akgfMB+0em M2+fq0WxqaS5vi0WFLuaUNL4DRstGOZOqCdgC7lKRsMnXpYvk7MYNwMCcg44RA4T BpRD+7+22zp/KadYt0nP9IigJdChDAkhUpgvZBbhYKqJj4fZXfl3vensaN0Ulzcf jEUGaeKiN60tll2dRM9rgr3gTNMUHAU5QQ6ALRZ8K0Gsu4w6ranXlEmmZxD8wWDt h7kVH/2XDjFLpYYiP2fYgceIJLOTS9T+YCThKyGqEHjHZ33YfYbaCa7CiWxYnmTX Scg6J3G69MkontBJ6q8o95tc49PzQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeelgdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof ffufhfjgesthejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceo mhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehsohhrrhihrdhonh gvnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D387C9E5AF; Wed, 6 Feb 2019 20:59:47 -0500 (EST) Message-Id: <1549504787.180756.1652556816.78058E49@webmail.messagingengine.com> From: Martin Thomson To: Stephen Farrell , quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1 Date: Thu, 07 Feb 2019 12:59:47 +1100 Subject: Re: Allowed frames in 0-RTT References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> In-Reply-To: <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 01:59:52 -0000 On Wed, Feb 6, 2019, at 19:40, Stephen Farrell wrote: > If the WG decide to disallow something that could cause an application > layer concern then that will remove the need to do application layer > analyses of replay/0-rtt for those cases. Given application devs will > in general not do those analyses, disallowing as much as you can (of > the risks arising from 0-rtt) in the transport seems safer to me. > > If you want to name a principle ISTM that 0-rtt is a quite like a > dangerous implement, which seems better avoided as far as possible. Yes. In fact, my pull request prominently advises disabling 0-RTT as a defense. However, when the chairs asked in Tokyo, the group was near unanimous in support of 0-RTT for HTTP. Sorry. > One question though - do we have any information about real world > 0-rtt issues arising in http/tls1.3 or is it still too early? If we > did have such information that may better inform this discussion. It's still too early to really tell. All we really know is that 0-RTT usage rates are still very low. (1% of TLS 1.3 connections for us, with TLS 1.3 sitting around 8% of the whole.) From nobody Wed Feb 6 18:06:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12807130FB4 for ; Wed, 6 Feb 2019 18:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=RzxYzdW5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I8Tnbo6h 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_BE-Vn1kOZS for ; Wed, 6 Feb 2019 18:06:37 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0D2130FAB for ; Wed, 6 Feb 2019 18:06:37 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C538D21FEE; Wed, 6 Feb 2019 21:06:36 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 06 Feb 2019 21:06:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:date:subject; s=fm1; bh=0Ez ZsLh4g4A5jXZHK0lNGqg7V+lcoABJT+K+1ebdyOs=; b=RzxYzdW51I9hVx6Vu0Z 6DEG1D8aYtD1XzyvdWUtP0016OcOdvnE1+BZH6fgSb+WJFfgbcJqrwwQFzdWznOJ /5rJCix7IQzZl/otrKnqyFuMBcPrXQAJhsnUrBJlPsTehtSLsZxMry4BI0NGsql8 0GrqLI0724UhA3sUJzCt9V2fokZaIyFLi+tXzAb6h1C3NPLJjrSctXe4hLM6Mv4R tW47feL8H/ZifXXnZ8Bg6abmqK7xED3x2KNW2pqF54FFK4dO8sI1lDM5qnflwNtz 7DuJCkKE0kaehmqL/4yg93tgdc7+QRU7tPt9AbqbhEvF9Sg/ezS0UMFkiEMtfF71 y4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=0EzZsLh4g4A5jXZHK0lNGqg7V+lcoABJT+K+1ebdy Os=; b=I8Tnbo6h8WR8lfj6uGmL5P51qo/Go6De1LSqGbWEmiKNRsw/qHnIMZRtN dCRgvA4k/AXa9CwAvxUjaSUJSb8JVeOdYK+nX4Qkg8vGOk6DGFSjrRgYIGzZmClR Rn+Fosf+EViNnMkGLq1bPwu4+4r1BK8qllkAn+jK2yKHs73NJ33MuEqhV3gsd+JF C20qhbW/U8YBG8mnVimKw+GM/IgFoU4aWqTz0uauCSTOz9+7ZbYg1ZFs13eayIsK B+fmDmVzOm26T+skA1KqktvFlDWWv3UyGtvIRilzR64Jney9FuAQ66JxQn0+88Nu iXOQ7o33uzC0wgNuzlwfMPqYQG3tw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeelgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof gjfhffufesthhqredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceo mhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 443D49E524; Wed, 6 Feb 2019 21:06:36 -0500 (EST) Message-Id: <1549505196.184749.1652574256.566C7304@webmail.messagingengine.com> From: Martin Thomson To: =?utf-8?Q?Mikkel=20Fahn=C3=B8e=20J=C3=B8rgensen?= , quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1 In-Reply-To: References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> Date: Thu, 07 Feb 2019 13:06:36 +1100 Subject: Re: Allowed frames in 0-RTT Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 02:06:39 -0000 Hi Mikkel, are you talking about Retry? The token that is used for 0-RTT (= that is, the session ticket) is encrypted. The (very) short-lived token th= at appears in a Retry packet is the only token-like thing that is exposed t= o the network. The point about servers tracking clients is already well-treated in the lit= erature. (I can't remember if we have text in QUIC specifically, but it sh= ould be in TLS.) As for time-limiting, TLS 1.3 already provides measures that strictly limit= the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be retried= within a week that the token is issued. More importantly, there is a fiel= d in the TLS handshake that limits the time over which the token can be rep= layed. There are some limitations because it relies on clients and servers= having clocks that run at approximately the same speed and we have to make= allowances for retransmissions, but the general guidance we have is that a= 10 second window is what you get for replay. Of course, that is only one = of the defenses. On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I came to think about the recent discussion about interception of the > replay token by a man on the side. > Here it was pointed out that it would be practical to enforce single token > use because >=20 > 1. the retry to goes to server designated CID > 2. the token can have a timestamp >=20 > We could do the same with 0-RTT (I think) > There has previously been discussions on the CID used in 0-RTT - whether = it > is the original random CID or a server designated. > But if 0-RTT uses the same approach as single use retry tokens, then it > should be practical to enforce no replay. > Of course data centers can work around this if they care enough with the > risks involved and moved to the application layer - so the draft could ha= ve > an escape hatch for that. >=20 > Such an enforcement would make the 0-RTT more short lived and at higher > risk of being rejected, but I don=E2=80=99t think that is a major concern. >=20 > Also, 0-RTT tokens can allow servers to track anonymous end users, so > limiting their life time is a good thing. Maybe more important than the > discussion on migration linkability. >=20 > Mikkel >=20 >=20 > On 6 February 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.tcd.i= e) > wrote: >=20 >=20 > piping in from the sidelines so I don't expect this to be found so > convincing, however... >=20 > On 06/02/2019 04:11, Martin Thomson wrote: > > it would be a mistake to try to make decisions about 0-RTT safety in > > the transport, when replay risks are an application-layer concern. > I believe that is not true for some decisions. >=20 > If the WG decide to disallow something that could cause an application > layer concern then that will remove the need to do application layer > analyses of replay/0-rtt for those cases. Given application devs will > in general not do those analyses, disallowing as much as you can (of > the risks arising from 0-rtt) in the transport seems safer to me. >=20 > If you want to name a principle ISTM that 0-rtt is a quite like a > dangerous implement, which seems better avoided as far as possible. >=20 > One question though - do we have any information about real world > 0-rtt issues arising in http/tls1.3 or is it still too early? If we > did have such information that may better inform this discussion. >=20 > Cheers, > S. From nobody Wed Feb 6 22:44:46 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A14126F72 for ; Wed, 6 Feb 2019 22:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=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 voZgnVdcLti9 for ; Wed, 6 Feb 2019 22:44:41 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 08B48130EEB for ; Wed, 6 Feb 2019 22:44:41 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id z7so12156856iti.0 for ; Wed, 06 Feb 2019 22:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=WydfMtteJDgN8cGpbJ8LpktYCCgJrCzKjQLwNriNpak=; b=m4xJcUQeq8u7CRglfjcw3JZoKnFwUGccYyIp2fQOeBEuS6s2dBcQYslcaviG1MQ2vM UdNJ66OFCTwDRxIkB2PSoej06chs5k1IcetPaRbUR3Crn6qrYzV3pmuq04M6BAXE+RpL LGNkjzODsj51EQl5CN9gr1SwU0saJgj+bgCdPhA1XeHrvWAvAhC9i3EgIB8KKVmTBjii RWLVHct6C9I2n9e+17U1Y4wDSogHHs4JtMvHi8qo1/De30DZORRDPnxYGbNQv96oRZSZ SbIlvs6A0zWSvGjx2IxIuJKhwD58ZPMDpWKT9sJihPevg9MhR22etqqtCwwUGQjR2N0O m/FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=WydfMtteJDgN8cGpbJ8LpktYCCgJrCzKjQLwNriNpak=; b=a8l0Wl1nglz7maIntHbgrWf5GvorpLkrxfh7VJysHh5fwg7aDFcPLenAF2rJ3e5SfG ocSUWLpI1v20F/k2t1GesVDr2sGs3ngN16Q+Df9dLCKYCQmjNXB4JnYoKI3mfqn3baMq E7PKo12MNuDhJ/h5DNw1xm9h17i3AdhH33n5rBVIjzwFvw0c66nmfCQ1UP8r3G5RXdV6 q/xAdJjZBbI15/UcZkkxi4VY/D48JyM0jsqBcf8XE2uNqdWfae0DTve7Q0eQoU55w2gR nv4wbrfkEegV3IQbJHvj51cMTa+2l4Y33PPgvaYRvrTpGuJovxmhO1+3uqmN9k4rGnsm 3k9w== X-Gm-Message-State: AHQUAuYuZAMYmLQEQAZj0yhwRvPTiVXDHvnKdcxa93Q1o1+NXJzYM6Yo 0/X3+FGSVJa1Nh1TJKJfwTA5zvAkjr27TvDqW6GqJI28 X-Google-Smtp-Source: AHgI3IZXl1jbiECG3mtrLprJCa4KPs9AnTM1wqhtIuzRBJQat4HE2faHUCcTf9HibQ/Tddz9ZFtt6gKd95yeSlV3xrA= X-Received: by 2002:a05:660c:58a:: with SMTP id g10mr3858351itk.167.1549521880220; Wed, 06 Feb 2019 22:44:40 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Feb 2019 22:44:39 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <1549505196.184749.1652574256.566C7304@webmail.messagingengine.com> References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> <1549505196.184749.1652574256.566C7304@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Feb 2019 22:44:39 -0800 Message-ID: Subject: Re: Allowed frames in 0-RTT To: Martin Thomson , quic@ietf.org Content-Type: multipart/alternative; boundary="0000000000003e0c9b0581482dfb" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 06:44:44 -0000 --0000000000003e0c9b0581482dfb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I forgot the 0-RTT token is called a ticket. The fact that it is encrypted does not change the general similarity to Retry if we assume retry tokens are created in safe manner. Both can be replayed and both can have non-forgeable timestamps. What is different is that TLS 1.3 over TCP does not have a concept of Connection ID that it can use for routing, but Retry does. (Restating that currently Retry is not required, only recommended, to enforce single use, but analysis shows that it is feasible to require). The time limit is, in this context, needed to ensure you do not have to keep infinite state whereas for TLS in general it (I presume) has more to do with tracking, reducing the attack surface, but to an extend also to clean up state. By requiring that the 0-RTT NewSessionTicket is used with a CID that routes to a specific endpoint, or cluster of endpoints, that can synchronously verify non-reuse within the time limit, you can lift a complex burden from the application layer - at the cost of complexity in transport and cluster configuration. One reason not to do this is complexity - but it is still simpler that dumping this on the average application, and you are not forced to to do 0-RTT. Another reason to not do this is that if you can=E2=80=99t control your rou= ting tightly you need an internal lookup which adds latency. The application layer has a few advantages: One is that it might not care about replay (like GET hello/world), or it might have a convenient sync mechanism like a database query. But these are notoriously difficult to get right and fast at the same time. If you place the burden on transport, you loose the ability of cluster wide fast GET, but that might not be a big issue, since routing to a dedicated host will also work and on average it will level out. If the servers QUIC implementation is able and willing to share synchronized state (e.g. via Redis or Zookeeper, etcd, or custom built-in), you can take the complexity hit once and let applications piggyback on that, and if its not, you still have single server guarantees. I believe this is the only sane way to go about it. I really can=E2=80=99t = see 0-RTT being safe left to the average application developer (however smart) when under time pressure to deliver. Regardless of much work the transport does, an application should of course maintain its own integrity, and avoid double bookings etc. which can happy by other means as well, unless, of course, that would be a business strategy to do so. On 7 February 2019 at 03.06.37, Martin Thomson (mt@lowentropy.net) wrote: Hi Mikkel, are you talking about Retry? The token that is used for 0-RTT (that is, the session ticket) is encrypted. The (very) short-lived token that appears in a Retry packet is the only token-like thing that is exposed to the network. The point about servers tracking clients is already well-treated in the literature. (I can't remember if we have text in QUIC specifically, but it should be in TLS.) As for time-limiting, TLS 1.3 already provides measures that strictly limit the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be retried within a week that the token is issued. More importantly, there is a field in the TLS handshake that limits the time over which the token can be replayed. There are some limitations because it relies on clients and servers having clocks that run at approximately the same speed and we have to make allowances for retransmissions, but the general guidance we have is that a 10 second window is what you get for replay. Of course, that is only one of the defenses. On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I came to think about the recent discussion about interception of the > replay token by a man on the side. > Here it was pointed out that it would be practical to enforce single token > use because > > 1. the retry to goes to server designated CID > 2. the token can have a timestamp > > We could do the same with 0-RTT (I think) > There has previously been discussions on the CID used in 0-RTT - whether it > is the original random CID or a server designated. > But if 0-RTT uses the same approach as single use retry tokens, then it > should be practical to enforce no replay. > Of course data centers can work around this if they care enough with the > risks involved and moved to the application layer - so the draft could have > an escape hatch for that. > > Such an enforcement would make the 0-RTT more short lived and at higher > risk of being rejected, but I don=E2=80=99t think that is a major concern= . > > Also, 0-RTT tokens can allow servers to track anonymous end users, so > limiting their life time is a good thing. Maybe more important than the > discussion on migration linkability. > > Mikkel > > > On 6 February 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.tcd.i= e) > wrote: > > > piping in from the sidelines so I don't expect this to be found so > convincing, however... > > On 06/02/2019 04:11, Martin Thomson wrote: > > it would be a mistake to try to make decisions about 0-RTT safety in > > the transport, when replay risks are an application-layer concern. > I believe that is not true for some decisions. > > If the WG decide to disallow something that could cause an application > layer concern then that will remove the need to do application layer > analyses of replay/0-rtt for those cases. Given application devs will > in general not do those analyses, disallowing as much as you can (of > the risks arising from 0-rtt) in the transport seems safer to me. > > If you want to name a principle ISTM that 0-rtt is a quite like a > dangerous implement, which seems better avoided as far as possible. > > One question though - do we have any information about real world > 0-rtt issues arising in http/tls1.3 or is it still too early? If we > did have such information that may better inform this discussion. > > Cheers, > S. --0000000000003e0c9b0581482dfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Yes, I forgot the 0-= RTT token is called a ticket. The fact that it is encrypted does not change= the general similarity to Retry if we assume retry tokens are created in s= afe manner. Both can be replayed and both can have non-forgeable timestamps= .

<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
What is different is that TLS 1.3 over TCP d= oes not have a concept of Connection ID that it can use for routing, but Re= try does.

=
(Restating t= hat currently Retry is not required, only recommended, to enforce single us= e, but analysis shows that it is feasible to require).

The time limit is, in this context, neede= d to ensure you do not have to keep infinite state whereas for TLS in gener= al it (I presume) has more to do with tracking, reducing the attack surface= , but to an extend also to clean up state.

By requiring that the 0-RTT NewSessionTicket is used= with a CID that routes to a specific endpoint, or cluster of endpoints, th= at can synchronously verify non-reuse within the time limit, you can lift a= complex burden from the application layer - at the cost of complexity in t= ransport and cluster configuration.

One reason not to do this is complexity - but it is still si= mpler that dumping this on the average application, and you are not forced = to to do 0-RTT.
Another reason to not do this is that if you can=E2=80=99t control your = routing tightly you need an internal lookup which adds latency.

The application layer has a few = advantages: One is that it might not care about replay (like GET hello/worl= d), or it might have a convenient sync mechanism like a database query. But= these are notoriously difficult to get right and fast at the same time.

If you place the burden= on transport, you loose the ability of cluster wide fast GET, but that mig= ht not be a big issue, since routing to a dedicated host will also work and= on average it will level out.

If the servers QUIC implementation is able and willing to share s= ynchronized state (e.g. via Redis or Zookeeper, etcd, or custom built-in), = you can take the complexity hit once and let applications piggyback on that= , and if its not, you still have single server guarantees.

I believe this is the only sane way t= o go about it. I really can=E2=80=99t see 0-RTT being safe left to the aver= age application developer (however smart) when under time pressure to deliv= er.

Regardless of much work th= e transport does, an application should of course maintain its own integrit= y, and avoid double bookings etc. which can happy by other means as well, u= nless, of course, that would be a business strategy to do so.
<= br>

On 7 February 2019 at 03.06.37, Martin Thomson (= mt@lowentropy.net) wrote:

Hi Mikk= el, are you talking about Retry? The token that is used for 0-RTT (that is= , the session ticket) is encrypted. The (very) short-lived token that appe= ars in a Retry packet is the only token-like thing that is exposed to the n= etwork.

The point about servers tracking clients is already well-treated in the= literature. (I can't remember if we have text in QUIC specifically, b= ut it should be in TLS.)

As for time-limiting, TLS 1.3 already provides measures that strictly l= imit the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be ret= ried within a week that the token is issued. More importantly, there is a = field in the TLS handshake that limits the time over which the token can be= replayed. There are some limitations because it relies on clients and ser= vers having clocks that run at approximately the same speed and we have to = make allowances for retransmissions, but the general guidance we have is th= at a 10 second window is what you get for replay. Of course, that is only = one of the defenses.

On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> I came to think about the recent discussion about interception of = the
> replay token by a man on the side.
> Here it was pointed out that it would be practical to enforce sing= le token
> use because
> =20
> 1. the retry to goes to server designated CID
> 2. the token can have a timestamp
> =20
> We could do the same with 0-RTT (I think)
> There has previously been discussions on the CID used in 0-RTT - w= hether it
> is the original random CID or a server designated.
> But if 0-RTT uses the same approach as single use retry tokens, th= en it
> should be practical to enforce no replay.
> Of course data centers can work around this if they care enough wi= th the
> risks involved and moved to the application layer - so the draft c= ould have
> an escape hatch for that.
> =20
> Such an enforcement would make the 0-RTT more short lived and at h= igher
> risk of being rejected, but I don=E2=80=99t think that is a major = concern.
> =20
> Also, 0-RTT tokens can allow servers to track anonymous end users,= so
> limiting their life time is a good thing. Maybe more important tha= n the
> discussion on migration linkability.
> =20
> Mikkel
> =20
> =20
> On 6 February 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.tcd.ie)
> wrote:
> =20
> =20
> piping in from the sidelines so I don't expect this to be foun= d so
> convincing, however...
> =20
> On 06/02/2019 04:11, Martin Thomson wrote:
> > it would be a mistake to try to make decisions about 0-RTT sa= fety in
> > the transport, when replay risks are an application-layer con= cern.
> I believe that is not true for some decisions.
> =20
> If the WG decide to disallow something that could cause an applica= tion
> layer concern then that will remove the need to do application lay= er
> analyses of replay/0-rtt for those cases. Given application devs w= ill
> in general not do those analyses, disallowing as much as you can (= of
> the risks arising from 0-rtt) in the transport seems safer to me.
> =20
> If you want to name a principle ISTM that 0-rtt is a quite like a
> dangerous implement, which seems better avoided as far as possible= .
> =20
> One question though - do we have any information about real world
> 0-rtt issues arising in http/tls1.3 or is it still too early? If w= e
> did have such information that may better inform this discussion.
> =20
> Cheers,
> S.
--0000000000003e0c9b0581482dfb-- From nobody Thu Feb 7 05:50:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7718D124BE5 for ; Thu, 7 Feb 2019 05:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yghcLVmqNixv for ; Thu, 7 Feb 2019 05:49:57 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 8B84A123FFD for ; Thu, 7 Feb 2019 05:49:56 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id v26so1722146wmh.3 for ; Thu, 07 Feb 2019 05:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RP6okpUtKSJ7wfYvJKuNhmT4bSr+sy+ZG+hJpuEbzIE=; b=p4Wq3y1CUC1DNfS+OnOozrC1OrG+o0xczg3UdbYDWGnNGumWOT8I91P+Gb0YXKFrhv q1Y3qH/tF4oDGgXPM1+XlmSQncLVP2OS5VAqNt1EHm5sw2ypSe4qm6WNQ8in/XAhWPdS ngZVEpGIsiKCoewadin/zyzkvFSy75Hd1jI/yavqIupOx2dACp67vU5qixP9AShnsWf/ ltk4nbcMdA1dXh53/mMi1d27GshxNjs1U3w67yPSJie/w/6q5LHApyZM/8WJO4LUzKVi 2U0UWzhDeLdsKOpU060z+vdgdJPX1BtAZmz2qxJADiITP+Dc5ei99mum+Fqt4CK180Ud 323Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RP6okpUtKSJ7wfYvJKuNhmT4bSr+sy+ZG+hJpuEbzIE=; b=mbRURrZt7dwwVoV7z14VfcY0fbwt3Fk682B8VGLTNYAuUU1+6tBhUXZkeuwOCuWYh1 KOwxB1HF0I8XKJY4Yav+94OTjMGu+SeILy6rif5thJsjpSxYnEuvo9uW1GVk/mgYeICw 09E0aFwyPRNYDVgX8xAmjWW8WRScPJW6Rzx44N0LGBUxdJX/7/fajQXH3mPYla5Qqbey d6PUU/D7w+94hdKxIijdK9BhsgeXuMbs8GBVCzgfxDpqkACmE/4WLLWNz4oBswysv36N sg2YTGPD3dK0ha2W4HL84IMuzePA/cCgBhwtYvI0LxZlZM8Ysw+w4WBAWsqoZDDDxxu0 O2qg== X-Gm-Message-State: AHQUAuZ6JGO9s6aJjgTr3DmAROMBEo1gqTjKoCbLlSH0QGGNY2j3cKJR tslsK6InIWvA5RN0Mq1jCvfbS/pCfD0WD382vlzX+Huh/aQ= X-Google-Smtp-Source: AHgI3Iaa4nKNSac3SgPBrJ06a8wVJOm0Tzroh7hqnNlgELZh8njNcdIOjHJpztG0Z4aCb/ycYS4j7QDigCmQP9V1/yQ= X-Received: by 2002:a05:600c:2192:: with SMTP id e18mr3389866wme.22.1549547394440; Thu, 07 Feb 2019 05:49:54 -0800 (PST) MIME-Version: 1.0 References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> <1549505196.184749.1652574256.566C7304@webmail.messagingengine.com> In-Reply-To: From: Ian Swett Date: Thu, 7 Feb 2019 08:49:41 -0500 Message-ID: Subject: Re: Allowed frames in 0-RTT To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000002c4d305814e1e16" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:50:00 -0000 --00000000000002c4d305814e1e16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mikkel, are you suggesting a connection ID be paired with a NewSessionTicket or Token for the purposes of resumption to make it easier for a server operator to prevent using the same NST or Token multiple times= ? If so, this thread has gone extraordinarily off the original topic of what frames to allow in 0RTT, so if you want to discuss that further, please start a new thread. On Thu, Feb 7, 2019 at 1:45 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Yes, I forgot the 0-RTT token is called a ticket. The fact that it is > encrypted does not change the general similarity to Retry if we assume > retry tokens are created in safe manner. Both can be replayed and both ca= n > have non-forgeable timestamps.. > > What is different is that TLS 1.3 over TCP does not have a concept of > Connection ID that it can use for routing, but Retry does. > > (Restating that currently Retry is not required, only recommended, to > enforce single use, but analysis shows that it is feasible to require). > > The time limit is, in this context, needed to ensure you do not have to > keep infinite state whereas for TLS in general it (I presume) has more to > do with tracking, reducing the attack surface, but to an extend also to > clean up state. > > By requiring that the 0-RTT NewSessionTicket is used with a CID that > routes to a specific endpoint, or cluster of endpoints, that can > synchronously verify non-reuse within the time limit, you can lift a > complex burden from the application layer - at the cost of complexity in > transport and cluster configuration. > > One reason not to do this is complexity - but it is still simpler that > dumping this on the average application, and you are not forced to to do > 0-RTT. > Another reason to not do this is that if you can=E2=80=99t control your r= outing > tightly you need an internal lookup which adds latency. > > The application layer has a few advantages: One is that it might not care > about replay (like GET hello/world), or it might have a convenient sync > mechanism like a database query. But these are notoriously difficult to g= et > right and fast at the same time. > > If you place the burden on transport, you loose the ability of cluster > wide fast GET, but that might not be a big issue, since routing to a > dedicated host will also work and on average it will level out. > > If the servers QUIC implementation is able and willing to share > synchronized state (e.g. via Redis or Zookeeper, etcd, or custom built-in= ), > you can take the complexity hit once and let applications piggyback on > that, and if its not, you still have single server guarantees. > > I believe this is the only sane way to go about it. I really can=E2=80=99= t see > 0-RTT being safe left to the average application developer (however smart= ) > when under time pressure to deliver. > > Regardless of much work the transport does, an application should of > course maintain its own integrity, and avoid double bookings etc. which c= an > happy by other means as well, unless, of course, that would be a business > strategy to do so. > > On 7 February 2019 at 03.06.37, Martin Thomson (mt@lowentropy.net) wrote: > > Hi Mikkel, are you talking about Retry? The token that is used for 0-RTT > (that is, the session ticket) is encrypted. The (very) short-lived token > that appears in a Retry packet is the only token-like thing that is expos= ed > to the network. > > The point about servers tracking clients is already well-treated in the > literature. (I can't remember if we have text in QUIC specifically, but i= t > should be in TLS.) > > As for time-limiting, TLS 1.3 already provides measures that strictly > limit the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be > retried within a week that the token is issued. More importantly, there i= s > a field in the TLS handshake that limits the time over which the token ca= n > be replayed. There are some limitations because it relies on clients and > servers having clocks that run at approximately the same speed and we hav= e > to make allowances for retransmissions, but the general guidance we have = is > that a 10 second window is what you get for replay. Of course, that is on= ly > one of the defenses. > > On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > I came to think about the recent discussion about interception of the > > replay token by a man on the side. > > Here it was pointed out that it would be practical to enforce single > token > > use because > > > > 1. the retry to goes to server designated CID > > 2. the token can have a timestamp > > > > We could do the same with 0-RTT (I think) > > There has previously been discussions on the CID used in 0-RTT - whethe= r > it > > is the original random CID or a server designated. > > But if 0-RTT uses the same approach as single use retry tokens, then it > > should be practical to enforce no replay. > > Of course data centers can work around this if they care enough with th= e > > risks involved and moved to the application layer - so the draft could > have > > an escape hatch for that. > > > > Such an enforcement would make the 0-RTT more short lived and at higher > > risk of being rejected, but I don=E2=80=99t think that is a major conce= rn. > > > > Also, 0-RTT tokens can allow servers to track anonymous end users, so > > limiting their life time is a good thing. Maybe more important than the > > discussion on migration linkability. > > > > Mikkel > > > > > > On 6 February 2019 at 09.41.16, Stephen Farrell ( > stephen.farrell@cs.tcd.ie) > > wrote: > > > > > > piping in from the sidelines so I don't expect this to be found so > > convincing, however... > > > > On 06/02/2019 04:11, Martin Thomson wrote: > > > it would be a mistake to try to make decisions about 0-RTT safety in > > > the transport, when replay risks are an application-layer concern. > > I believe that is not true for some decisions. > > > > If the WG decide to disallow something that could cause an application > > layer concern then that will remove the need to do application layer > > analyses of replay/0-rtt for those cases. Given application devs will > > in general not do those analyses, disallowing as much as you can (of > > the risks arising from 0-rtt) in the transport seems safer to me. > > > > If you want to name a principle ISTM that 0-rtt is a quite like a > > dangerous implement, which seems better avoided as far as possible.. > > > > One question though - do we have any information about real world > > 0-rtt issues arising in http/tls1.3 or is it still too early? If we > > did have such information that may better inform this discussion. > > > > Cheers, > > S. > > --00000000000002c4d305814e1e16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mikkel, are you suggesting a connection ID be paired = with a NewSessionTicket or Token for the purposes of resumption to make it = easier for a server operator to prevent using the same NST or Token multipl= e times?

If so, this thread has gone extraordinarily of= f the original topic of what frames to allow in 0RTT, so if you want to dis= cuss that further, please start a new thread.

On Thu, Feb 7, 2019 at 1:45 AM= Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Yes, I forgot the 0-RTT t= oken is called a ticket. The fact that it is encrypted does not change the = general similarity to Retry if we assume retry tokens are created in safe m= anner. Both can be replayed and both can have non-forgeable timestamps..

What is = different is that TLS 1.3 over TCP does not have a concept of Connection ID= that it can use for routing, but Retry does.

(Restating that c= urrently Retry is not required, only recommended, to enforce single use, bu= t analysis shows that it is feasible to require).

The time limit is, in this context= , needed to ensure you do not have to keep infinite state whereas for TLS i= n general it (I presume) has more to do with tracking, reducing the attack = surface, but to an extend also to clean up state.

By requiring that the 0-RTT NewSes= sionTicket is used with a CID that routes to a specific endpoint, or cluste= r of endpoints, that can synchronously verify non-reuse within the time lim= it, you can lift a complex burden from the application layer - at the cost = of complexity in transport and cluster configuration.

One reason not to do this is c= omplexity - but it is still simpler that dumping this on the average applic= ation, and you are not forced to to do 0-RTT.
Another reason to not do this is tha= t if you can=E2=80=99t control your routing tightly you need an internal lo= okup which adds latency.

The application layer has a few advantages: One is that it = might not care about replay (like GET hello/world), or it might have a conv= enient sync mechanism like a database query. But these are notoriously diff= icult to get right and fast at the same time.

If you place the burden on transport, = you loose the ability of cluster wide fast GET, but that might not be a big= issue, since routing to a dedicated host will also work and on average it = will level out.

If the servers QUIC implementation is able and willing to share sync= hronized state (e.g. via Redis or Zookeeper, etcd, or custom built-in), you= can take the complexity hit once and let applications piggyback on that, a= nd if its not, you still have single server guarantees.

I believe this is the only s= ane way to go about it. I really can=E2=80=99t see 0-RTT being safe left to= the average application developer (however smart) when under time pressure= to deliver.

Regardless of much work the tr= ansport does, an application should of course maintain its own integrity, a= nd avoid double bookings etc. which can happy by other means as well, unles= s, of course, that would be a business strategy to do so.

<= p class=3D"gmail-m_-7425013837032872060airmail_on">On 7 February 2019 at 03= .06.37, Martin Thomson (mt@lowentropy.net) wrote:

Hi Mikkel, a= re you talking about Retry? The token that is used for 0-RTT (that is, the= session ticket) is encrypted. The (very) short-lived token that appears i= n a Retry packet is the only token-like thing that is exposed to the networ= k.

The point about servers tracking clients is already well-treated in the= literature. (I can't remember if we have text in QUIC specifically, b= ut it should be in TLS.)

As for time-limiting, TLS 1.3 already provides measures that strictly l= imit the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be ret= ried within a week that the token is issued. More importantly, there is a = field in the TLS handshake that limits the time over which the token can be= replayed. There are some limitations because it relies on clients and ser= vers having clocks that run at approximately the same speed and we have to = make allowances for retransmissions, but the general guidance we have is th= at a 10 second window is what you get for replay. Of course, that is only = one of the defenses.

On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> I came to think about the recent discussion about interception of = the
> replay token by a man on the side.
> Here it was pointed out that it would be practical to enforce sing= le token
> use because
> =20
> 1. the retry to goes to server designated CID
> 2. the token can have a timestamp
> =20
> We could do the same with 0-RTT (I think)
> There has previously been discussions on the CID used in 0-RTT - w= hether it
> is the original random CID or a server designated.
> But if 0-RTT uses the same approach as single use retry tokens, th= en it
> should be practical to enforce no replay.
> Of course data centers can work around this if they care enough wi= th the
> risks involved and moved to the application layer - so the draft c= ould have
> an escape hatch for that.
> =20
> Such an enforcement would make the 0-RTT more short lived and at h= igher
> risk of being rejected, but I don=E2=80=99t think that is a major = concern.
> =20
> Also, 0-RTT tokens can allow servers to track anonymous end users,= so
> limiting their life time is a good thing. Maybe more important tha= n the
> discussion on migration linkability.
> =20
> Mikkel
> =20
> =20
> On 6 February 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.tcd.ie= )
> wrote:
> =20
> =20
> piping in from the sidelines so I don't expect this to be foun= d so
> convincing, however...
> =20
> On 06/02/2019 04:11, Martin Thomson wrote:
> > it would be a mistake to try to make decisions about 0-RTT sa= fety in
> > the transport, when replay risks are an application-layer con= cern.
> I believe that is not true for some decisions.
> =20
> If the WG decide to disallow something that could cause an applica= tion
> layer concern then that will remove the need to do application lay= er
> analyses of replay/0-rtt for those cases. Given application devs w= ill
> in general not do those analyses, disallowing as much as you can (= of
> the risks arising from 0-rtt) in the transport seems safer to me.
> =20
> If you want to name a principle ISTM that 0-rtt is a quite like a
> dangerous implement, which seems better avoided as far as possible= ..
> =20
> One question though - do we have any information about real world
> 0-rtt issues arising in http/tls1.3 or is it still too early? If w= e
> did have such information that may better inform this discussion.
> =20
> Cheers,
> S.
--00000000000002c4d305814e1e16-- From nobody Thu Feb 7 07:00:15 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C18C1228B7 for ; Thu, 7 Feb 2019 07:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=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 9j25lALmCRJX for ; Thu, 7 Feb 2019 07:00:10 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 F14D71200D7 for ; Thu, 7 Feb 2019 07:00:09 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id a6so338828itl.4 for ; Thu, 07 Feb 2019 07:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=OT0uVoL7DBPJTGezmlutkVjM3cwVkUAuAULBLwzQ/rs=; b=j2ZsAO9D6DcpK47eONtGmLzZfqwt65JY/w1d2LBfKnFtB+HRCtHaz03jijmO2D1Oxv jB3Q67Gsj81XtknUO7BTqltd9cT+7chafa+56HeJPISRU5JsQ4zoeVKwKjveOoTbeqZu eUNDy02GNvIJEwreIwR/DazrYqRTfy9W/KKg+MXXwIkMaov6gOYgzBqiohhz1OWnNNlI 0uOcalvHX48JJWA1JdAqbn3Jcl9lL6sK/yafU355CkVwXLTYWgST9Wl0p26kTNjoF/0p P9KLO5ClC4aKh6taAMzTORI6BWd48uvonY9c5CT5uSjmZYUcaGk8fEYS+D9FX283Wgsx oe6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=OT0uVoL7DBPJTGezmlutkVjM3cwVkUAuAULBLwzQ/rs=; b=lXMd78xmMw4j2OZ+BN0IiKmNzr2z26OC02VgdDQgtZ+UtwyMC0gHAHLcJE0uDZolM3 x3mRE4nbzCkJXvSIFinBh3phMAur5qVCWs+Gs54pH11f2jX3oBIpF4hoASxK7BphdXrj ncIyHuPSP8kJ37LB8nk5OQWNZ3va5dORN2NJTfJdWFVUZXcgvQpu7DPIEBORHfW1429w YyVQcvsuxlTWF0iNmVhwXzR/dqU5IfpABOZIopRsJgTG6SsYBsg2jmZQI3acMHkYrvvD LHEF32AU+wnx3aWFi2B6qpdJUtpZss4eUbMcoG2IFxS+JoiR51VWZGYoumpJvC+J8ln0 UfeQ== X-Gm-Message-State: AHQUAuYGTgTL/Wa0VkpFNPT3ubM3zzDXUWgBeUsQX2HpuzSW7QrlvGva vthTj0m1scuu7CBc3QYT6ZQwTwr7CYw3B5/gt+s= X-Google-Smtp-Source: AHgI3IZp1DrAHceBDlkAzN9526lDtmzCHxeMWBDcspeXL58RBjXjLPDUi2Uej4PQVX05YGF0ST1XHfQEpBwQ9PWfx9k= X-Received: by 2002:a02:2303:: with SMTP id u3mr8992053jau.42.1549551609180; Thu, 07 Feb 2019 07:00:09 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 7 Feb 2019 07:00:08 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> <1549505196.184749.1652574256.566C7304@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 7 Feb 2019 07:00:08 -0800 Message-ID: Subject: Require Single Use 0-RTT Session Tickets To: Ian Swett Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000039f70705814f1991" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:00:13 -0000 --00000000000039f70705814f1991 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, yes, but I already made my point. New thread here in case anyone wants to contest or support this proposal. I=E2=80=99m actually not suggestion this just make it easier for an operato= r to achieve single use, I am suggesting to require operators to honor it, otherwise application developers are still left guessing, although this belongs to the class of things that cannot easily be enforced. On 7 February 2019 at 14.49.56, Ian Swett (ianswett@google.com) wrote: Mikkel, are you suggesting a connection ID be paired with a NewSessionTicket or Token for the purposes of resumption to make it easier for a server operator to prevent using the same NST or Token multiple times= ? If so, this thread has gone extraordinarily off the original topic of what frames to allow in 0RTT, so if you want to discuss that further, please start a new thread. On Thu, Feb 7, 2019 at 1:45 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Yes, I forgot the 0-RTT token is called a ticket. The fact that it is > encrypted does not change the general similarity to Retry if we assume > retry tokens are created in safe manner. Both can be replayed and both ca= n > have non-forgeable timestamps.. > > What is different is that TLS 1.3 over TCP does not have a concept of > Connection ID that it can use for routing, but Retry does. > > (Restating that currently Retry is not required, only recommended, to > enforce single use, but analysis shows that it is feasible to require). > > The time limit is, in this context, needed to ensure you do not have to > keep infinite state whereas for TLS in general it (I presume) has more to > do with tracking, reducing the attack surface, but to an extend also to > clean up state. > > By requiring that the 0-RTT NewSessionTicket is used with a CID that > routes to a specific endpoint, or cluster of endpoints, that can > synchronously verify non-reuse within the time limit, you can lift a > complex burden from the application layer - at the cost of complexity in > transport and cluster configuration. > > One reason not to do this is complexity - but it is still simpler that > dumping this on the average application, and you are not forced to to do > 0-RTT. > Another reason to not do this is that if you can=E2=80=99t control your r= outing > tightly you need an internal lookup which adds latency. > > The application layer has a few advantages: One is that it might not care > about replay (like GET hello/world), or it might have a convenient sync > mechanism like a database query. But these are notoriously difficult to g= et > right and fast at the same time. > > If you place the burden on transport, you loose the ability of cluster > wide fast GET, but that might not be a big issue, since routing to a > dedicated host will also work and on average it will level out. > > If the servers QUIC implementation is able and willing to share > synchronized state (e.g. via Redis or Zookeeper, etcd, or custom built-in= ), > you can take the complexity hit once and let applications piggyback on > that, and if its not, you still have single server guarantees. > > I believe this is the only sane way to go about it. I really can=E2=80=99= t see > 0-RTT being safe left to the average application developer (however smart= ) > when under time pressure to deliver. > > Regardless of much work the transport does, an application should of > course maintain its own integrity, and avoid double bookings etc. which c= an > happy by other means as well, unless, of course, that would be a business > strategy to do so. > > On 7 February 2019 at 03.06.37, Martin Thomson (mt@lowentropy.net) wrote: > > Hi Mikkel, are you talking about Retry? The token that is used for 0-RTT > (that is, the session ticket) is encrypted. The (very) short-lived token > that appears in a Retry packet is the only token-like thing that is expos= ed > to the network. > > The point about servers tracking clients is already well-treated in the > literature. (I can't remember if we have text in QUIC specifically, but i= t > should be in TLS.) > > As for time-limiting, TLS 1.3 already provides measures that strictly > limit the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be > retried within a week that the token is issued. More importantly, there i= s > a field in the TLS handshake that limits the time over which the token ca= n > be replayed. There are some limitations because it relies on clients and > servers having clocks that run at approximately the same speed and we hav= e > to make allowances for retransmissions, but the general guidance we have = is > that a 10 second window is what you get for replay. Of course, that is on= ly > one of the defenses. > > On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > I came to think about the recent discussion about interception of the > > replay token by a man on the side. > > Here it was pointed out that it would be practical to enforce single > token > > use because > > > > 1. the retry to goes to server designated CID > > 2. the token can have a timestamp > > > > We could do the same with 0-RTT (I think) > > There has previously been discussions on the CID used in 0-RTT - whethe= r > it > > is the original random CID or a server designated. > > But if 0-RTT uses the same approach as single use retry tokens, then it > > should be practical to enforce no replay. > > Of course data centers can work around this if they care enough with th= e > > risks involved and moved to the application layer - so the draft could > have > > an escape hatch for that. > > > > Such an enforcement would make the 0-RTT more short lived and at higher > > risk of being rejected, but I don=E2=80=99t think that is a major conce= rn. > > > > Also, 0-RTT tokens can allow servers to track anonymous end users, so > > limiting their life time is a good thing. Maybe more important than the > > discussion on migration linkability. > > > > Mikkel > > > > > > On 6 February 2019 at 09.41.16, Stephen Farrell ( > stephen.farrell@cs.tcd.ie) > > wrote: > > > > > > piping in from the sidelines so I don't expect this to be found so > > convincing, however... > > > > On 06/02/2019 04:11, Martin Thomson wrote: > > > it would be a mistake to try to make decisions about 0-RTT safety in > > > the transport, when replay risks are an application-layer concern. > > I believe that is not true for some decisions. > > > > If the WG decide to disallow something that could cause an application > > layer concern then that will remove the need to do application layer > > analyses of replay/0-rtt for those cases. Given application devs will > > in general not do those analyses, disallowing as much as you can (of > > the risks arising from 0-rtt) in the transport seems safer to me. > > > > If you want to name a principle ISTM that 0-rtt is a quite like a > > dangerous implement, which seems better avoided as far as possible.. > > > > One question though - do we have any information about real world > > 0-rtt issues arising in http/tls1.3 or is it still too early? If we > > did have such information that may better inform this discussion. > > > > Cheers, > > S. > > --00000000000039f70705814f1991 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Well, yes, but I alr= eady made my point.
New thread here in case anyone wants to contest or support this prop= osal.

I=E2=80=99m actually not suggestion this just make it easier for an ope= rator to achieve single use, I am suggesting to require operators to honor = it, otherwise application developers are still left guessing, although this= belongs to the class of things that cannot easily be enforced.

On 7 February 2019 at 14.49.56, Ian Swett (<= a href=3D"mailto:ianswett@google.com">ianswett@google.com) wrote:

<= blockquote type=3D"cite" class=3D"clean_bq">
Mikkel, are you suggesting a connection ID be paired with a NewSessionTicket or Token for the purposes of resumption to make it easier for a server operator to prevent using the same NST or Token multiple times?

If so, this thread has gone extraordinarily off the original topic of what frames to allow in 0RTT, so if you want to discuss that further, please start a new thread.

On Thu, Feb 7, 2019 at 1:45 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Yes, I forgot the 0-RTT token is called a ticket. The fact that it is encrypted does not change the general similarity to Retry if we assume retry tokens are created in safe manner. Both can be replayed and both can have non-forgeable timestamps..

What is different is that TLS 1.3 over TCP does not have a concept of Connection ID that it can use for routing, but Retry does.

(Restating that currently Retry is not required, only recommended, to enforce single use, but analysis shows that it is feasible to require).

The time limit is, in this context, needed to ensure you do not have to keep infinite state whereas for TLS in general it (I presume) has more to do with tracking, reducing the attack surface, but to an extend also to clean up state.

By requiring that the 0-RTT NewSessionTicket is used with a CID that routes to a specific endpoint, or cluster of endpoints, that can synchronously verify non-reuse within the time limit, you can lift a complex burden from the application layer - at the cost of complexity in transport and cluster configuration.

One reason not to do this is complexity - but it is still simpler that dumping this on the average application, and you are not forced to to do 0-RTT.
Another reason to not do this is that if you can=E2=80=99t control your routing tightly you need an internal lookup which adds latency.

The application layer has a few advantages: One is that it might not care about replay (like GET hello/world), or it might have a convenient sync mechanism like a database query. But these are notoriously difficult to get right and fast at the same time.

If you place the burden on transport, you loose the ability of cluster wide fast GET, but that might not be a big issue, since routing to a dedicated host will also work and on average it will level out.

If the servers QUIC implementation is able and willing to share synchronized state (e.g. via Redis or Zookeeper, etcd, or custom built-in), you can take the complexity hit once and let applications piggyback on that, and if its not, you still have single server guarantees.

I believe this is the only sane way to go about it. I really can=E2=80=99t see 0-RTT being safe left to the average application developer (however smart) when under time pressure to deliver.

Regardless of much work the transport does, an application should of course maintain its own integrity, and avoid double bookings etc. which can happy by other means as well, unless, of course, that would be a business strategy to do so.

On 7 February 2019 at 03.06.37, Martin Thomson (mt@lowentropy.net) wrote:

Hi Mikkel, are you talking about Retry? The token that is used for 0-RTT (that is, the session ticket) is encrypted. The (very) short-lived token that appears in a Retry packet is the only token-like thing that is exposed to the network.

The point about servers tracking clients is already well-treated in the literature. (I can't remember if we have text in QUIC specifically, but it should be in TLS.)

As for time-limiting, TLS 1.3 already provides measures that strictly limit the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be retried within a week that the token is issued. More importantly, there is a field in the TLS handshake that limits the time over which the token can be replayed. There are some limitations because it relies on clients and servers having clocks that run at approximately the same speed and we have to make allowances for retransmissions, but the general guidance we have is that a 10 second window is what you get for replay. Of course, that is only one of the defenses.

On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> I came to think about the recent discussion about interception of the
> replay token by a man on the side.
> Here it was pointed out that it would be practical to enforce single token
> use because
>
> 1. the retry to goes to server designated CID
> 2. the token can have a timestamp
>
> We could do the same with 0-RTT (I think)
> There has previously been discussions on the CID used in 0-RTT - whether it
> is the original random CID or a server designated.
> But if 0-RTT uses the same approach as single use retry tokens, then it
> should be practical to enforce no replay.
> Of course data centers can work around this if they care enough with the
> risks involved and moved to the application layer - so the draft could have
> an escape hatch for that.
>
> Such an enforcement would make the 0-RTT more short lived and at higher
> risk of being rejected, but I don=E2=80=99t think that is a major concern.
>
> Also, 0-RTT tokens can allow servers to track anonymous end users, so
> limiting their life time is a good thing. Maybe more important than the
> discussion on migration linkability.
>
> Mikkel
>
>
> On 6 February 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.tcd.ie) > wrote:
>
>
> piping in from the sidelines so I don't expect this to be found so
> convincing, however...
>
> On 06/02/2019 04:11, Martin Thomson wrote:
> > it would be a mistake to try to make decisions about 0-RTT safety in
> > the transport, when replay risks are an application-layer concern.
> I believe that is not true for some decisions.
>
> If the WG decide to disallow something that could cause an application
> layer concern then that will remove the need to do application layer
> analyses of replay/0-rtt for those cases. Given application devs will
> in general not do those analyses, disallowing as much as you can (of
> the risks arising from 0-rtt) in the transport seems safer to me.
>
> If you want to name a principle ISTM that 0-rtt is a quite like a
> dangerous implement, which seems better avoided as far as possible..
>
> One question though - do we have any information about real world
> 0-rtt issues arising in http/tls1.3 or is it still too early? If we
> did have such information that may better inform this discussion.
>
> Cheers,
> S.
--00000000000039f70705814f1991-- From nobody Thu Feb 7 08:57:00 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9901200D8 for ; Thu, 7 Feb 2019 08:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UCTkA5NhaIq for ; Thu, 7 Feb 2019 08:56:57 -0800 (PST) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB51E124BF6 for ; Thu, 7 Feb 2019 08:56:56 -0800 (PST) Received: by mail-lf1-x142.google.com with SMTP id e27so394475lfj.8 for ; Thu, 07 Feb 2019 08:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=u3YYNs+kx/KzHSzbD4/bs/HCuAk70/kyKTbEc1nujgc=; b=D9sxFdIU+GhRLfM2+k5799D8DErLugwG57gLByP7jxTYx0SLFicUY/f/03KAxvwawc vaYNIeJGvz2mq/MxwfPJDhFDMl6AStc1/Jdmq8D9LUsclDZ2KhmrqWJ018NOeygGplTJ 1UrQx26YH9F9MUzmjcNgl2FgUcpGehylpwz6e7E5A+GuS3u4iGASPvqKaoOuvlFRPUTm yfn4wYCsPNUaFgi0hLDUjcufSzvJbDywzylXV97WtKg9AE1kNCysNTxVmdUwArkOgb02 0Yow8vybb4p8/0TyU8d+aBOan2wdaIPwdMTMfcAYvI/u5Xrw+FyFVBq3nJhkZBWTOYUS eZ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=u3YYNs+kx/KzHSzbD4/bs/HCuAk70/kyKTbEc1nujgc=; b=kX3k5hxnxtn6HfSCcZKqC+EOrZLhEcDgy7dNPB1hsfZvp+FAbpKr1xrw1lFPb4JkYB hxFq/k39mb6iAuOHNtmiln2n8fRiCVZbHS7C0ObWcZcF0565c4TtXgWTVpeHYJx4x1eP AwSJFzAzyxGEEIxXABfSpNJua2R4y9ZmqAj9GV89HBEgZZ5Z3y1jDC2wgv+6Plt0Hdgb NO44MeXgVPqdrDQRG/jHzSZX8pLQpXLdeJhL1yrPwpF9sB0EoF46wmkq+h7rXhWz9zZX md1oQcaY7BD/WP/8h54NjsFZUsEvZmm2kAI47ozUImfMmyYbaoRXDsDpYPrxN8VwmFpP io5g== X-Gm-Message-State: AHQUAuZZLt2cnRFjYP7/+kCO60xz2KkI3Ps2aNcescFXInF8zkDRLpN7 3sf11oMm8xKzAPLIFG4yWR2LvNcLf3OIxxj/DJs= X-Google-Smtp-Source: AHgI3IbYnq2ZboXO7XUzpd7cfBeiv30tmKaoKGKgFWrqPFAldXZe/URPDrjKaDW2CE7CbDvpLXv64zPgMvpUsoE5ElQ= X-Received: by 2002:a19:aace:: with SMTP id t197mr10538610lfe.7.1549558614746; Thu, 07 Feb 2019 08:56:54 -0800 (PST) MIME-Version: 1.0 References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> <1549505196.184749.1652574256.566C7304@webmail.messagingengine.com> In-Reply-To: From: Kazuho Oku Date: Fri, 8 Feb 2019 01:56:44 +0900 Message-ID: Subject: Re: Require Single Use 0-RTT Session Tickets To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Ian Swett , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:56:59 -0000 Hi, I think that the proposed approach works, and I think it's an interesting idea. However, I am not sure if I would prefer having this, at least in v1. The reasons are as follows: 1. The design requires CID-based routing to be stable for the lifetime of the session ticket (7 days). I am not sure if all of us can achieve that. Note that the CID encryption key (and therefore the stateless reset token key) needs to be stable for that amount of time. 2. The design requires the resumption CID to be bundled to the session ticket. That goes against our previous consensus to not introduce extensions in the session ticket (IIRC we discussed it during the handshake refactor). 3. HTTP (which is the target application of QUICv1) already has a way to handle replay attacks (425 Too Early). Most if not all server operators will deploy that regardless, because we need it to support 0-RTT in TLS 1.3. I do not think we need a different mechanism for HTTP/3. My preference goes to using the same mechanism in all HTTP versions to avoid confusion among the users. I might expand the argument that this would be the case not only for HTTP but for any protocol that might run on TLS-over-TCP and/or QUIC. 4. The design introduces burden to certain HTTP-QUIC stacks. Currently, it is possible to mitigate replay attacks by pattern-matching the HTTP method / URI to see if a request needs to be delayed until receiving the proof of non-replay. The proposed approach mandates the stacks to deploy a hash-table-based replay detection, which IMO is rather costly, considering the fact that most GET requests are idempotent and therefore replay-resistant. To summarize, the proposal seems like a gratuitous change considering the state of HTTP and QUIC v1. 2019=E5=B9=B42=E6=9C=888=E6=97=A5(=E9=87=91) 0:00 Mikkel Fahn=C3=B8e J=C3= =B8rgensen : > > Well, yes, but I already made my point. > New thread here in case anyone wants to contest or support this proposal. > > I=E2=80=99m actually not suggestion this just make it easier for an opera= tor to achieve single use, I am suggesting to require operators to honor it= , otherwise application developers are still left guessing, although this b= elongs to the class of things that cannot easily be enforced. > > On 7 February 2019 at 14.49.56, Ian Swett (ianswett@google.com) wrote: > > Mikkel, are you suggesting a connection ID be paired with a NewSessionTic= ket or Token for the purposes of resumption to make it easier for a server = operator to prevent using the same NST or Token multiple times? > > If so, this thread has gone extraordinarily off the original topic of wha= t frames to allow in 0RTT, so if you want to discuss that further, please s= tart a new thread. > > On Thu, Feb 7, 2019 at 1:45 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> >> Yes, I forgot the 0-RTT token is called a ticket. The fact that it is en= crypted does not change the general similarity to Retry if we assume retry = tokens are created in safe manner. Both can be replayed and both can have n= on-forgeable timestamps.. >> >> What is different is that TLS 1.3 over TCP does not have a concept of Co= nnection ID that it can use for routing, but Retry does. >> >> (Restating that currently Retry is not required, only recommended, to en= force single use, but analysis shows that it is feasible to require). >> >> The time limit is, in this context, needed to ensure you do not have to = keep infinite state whereas for TLS in general it (I presume) has more to d= o with tracking, reducing the attack surface, but to an extend also to clea= n up state. >> >> By requiring that the 0-RTT NewSessionTicket is used with a CID that rou= tes to a specific endpoint, or cluster of endpoints, that can synchronously= verify non-reuse within the time limit, you can lift a complex burden from= the application layer - at the cost of complexity in transport and cluster= configuration. >> >> One reason not to do this is complexity - but it is still simpler that d= umping this on the average application, and you are not forced to to do 0-R= TT. >> Another reason to not do this is that if you can=E2=80=99t control your = routing tightly you need an internal lookup which adds latency. >> >> The application layer has a few advantages: One is that it might not car= e about replay (like GET hello/world), or it might have a convenient sync m= echanism like a database query. But these are notoriously difficult to get = right and fast at the same time. >> >> If you place the burden on transport, you loose the ability of cluster w= ide fast GET, but that might not be a big issue, since routing to a dedicat= ed host will also work and on average it will level out. >> >> If the servers QUIC implementation is able and willing to share synchron= ized state (e.g. via Redis or Zookeeper, etcd, or custom built-in), you can= take the complexity hit once and let applications piggyback on that, and i= f its not, you still have single server guarantees. >> >> I believe this is the only sane way to go about it. I really can=E2=80= =99t see 0-RTT being safe left to the average application developer (howeve= r smart) when under time pressure to deliver. >> >> Regardless of much work the transport does, an application should of cou= rse maintain its own integrity, and avoid double bookings etc. which can ha= ppy by other means as well, unless, of course, that would be a business str= ategy to do so. >> >> On 7 February 2019 at 03.06.37, Martin Thomson (mt@lowentropy.net) wrote= : >> >> Hi Mikkel, are you talking about Retry? The token that is used for 0-RTT= (that is, the session ticket) is encrypted. The (very) short-lived token t= hat appears in a Retry packet is the only token-like thing that is exposed = to the network. >> >> The point about servers tracking clients is already well-treated in the = literature. (I can't remember if we have text in QUIC specifically, but it = should be in TLS.) >> >> As for time-limiting, TLS 1.3 already provides measures that strictly li= mit the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be retri= ed within a week that the token is issued. More importantly, there is a fie= ld in the TLS handshake that limits the time over which the token can be re= played. There are some limitations because it relies on clients and servers= having clocks that run at approximately the same speed and we have to make= allowances for retransmissions, but the general guidance we have is that a= 10 second window is what you get for replay. Of course, that is only one o= f the defenses. >> >> On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> > I came to think about the recent discussion about interception of the >> > replay token by a man on the side. >> > Here it was pointed out that it would be practical to enforce single t= oken >> > use because >> > >> > 1. the retry to goes to server designated CID >> > 2. the token can have a timestamp >> > >> > We could do the same with 0-RTT (I think) >> > There has previously been discussions on the CID used in 0-RTT - wheth= er it >> > is the original random CID or a server designated. >> > But if 0-RTT uses the same approach as single use retry tokens, then i= t >> > should be practical to enforce no replay. >> > Of course data centers can work around this if they care enough with t= he >> > risks involved and moved to the application layer - so the draft could= have >> > an escape hatch for that. >> > >> > Such an enforcement would make the 0-RTT more short lived and at highe= r >> > risk of being rejected, but I don=E2=80=99t think that is a major conc= ern. >> > >> > Also, 0-RTT tokens can allow servers to track anonymous end users, so >> > limiting their life time is a good thing. Maybe more important than th= e >> > discussion on migration linkability. >> > >> > Mikkel >> > >> > >> > On 6 February 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.tc= d.ie) >> > wrote: >> > >> > >> > piping in from the sidelines so I don't expect this to be found so >> > convincing, however... >> > >> > On 06/02/2019 04:11, Martin Thomson wrote: >> > > it would be a mistake to try to make decisions about 0-RTT safety in >> > > the transport, when replay risks are an application-layer concern. >> > I believe that is not true for some decisions. >> > >> > If the WG decide to disallow something that could cause an application >> > layer concern then that will remove the need to do application layer >> > analyses of replay/0-rtt for those cases. Given application devs will >> > in general not do those analyses, disallowing as much as you can (of >> > the risks arising from 0-rtt) in the transport seems safer to me. >> > >> > If you want to name a principle ISTM that 0-rtt is a quite like a >> > dangerous implement, which seems better avoided as far as possible.. >> > >> > One question though - do we have any information about real world >> > 0-rtt issues arising in http/tls1.3 or is it still too early? If we >> > did have such information that may better inform this discussion. >> > >> > Cheers, >> > S. --=20 Kazuho Oku From nobody Thu Feb 7 09:09:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F81129284 for ; Thu, 7 Feb 2019 09:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 9lFCCimJMHOD for ; Thu, 7 Feb 2019 09:09:30 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 19E351292F1 for ; Thu, 7 Feb 2019 09:09:30 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id q18so628449wrx.9 for ; Thu, 07 Feb 2019 09:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KASrkRrkeNgK3YnlK/BMaXZLhuRsFYcnVva+g3KF1Po=; b=hkNccyk+5uSqeyJ/BzMJKLVL6jZSsiOWRCN/ysjgiZW4ZXlttOlvOTGzTGhu2CpEtx dNSmvJT5Q8PU/khWW3sh9TEb35flHIl1hKTiIMEqJia83thOI4k7COa1+YaoCbibskpL nD2uTJrQy2I/0Dal1xARr2xWOkdrmSCHeD0HmKTc3++WUcKPIBSeNXjEKe9RKrr6G2A4 reSc3ARvES5KFyYimSYeGuDmcTH2zx/1P5uhS1HAG39RF0orquY/6p08rXXHtFvbkj1u f8RP93uIEpBFixKfPWm5wwsu/6m9OD/e7e9Fhij1I19u23wMY41V1VX8lrGLIEGJwBww htsg== 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=KASrkRrkeNgK3YnlK/BMaXZLhuRsFYcnVva+g3KF1Po=; b=fRgBTwCiAJiiuplSiPdPAVtZ9qTOdS6EPmmgoFuVv2uIDMsAiXaTuV9aaf5eII8h20 P52AnA2jrNOPmhWzNsBDquXnZ4MGz520HHzoJ+t7YYIvaDsb3np0f1y0argen27p/hOq Eb6H51uYHtMucRU7Vp4ozV2iJql/2F0KoMurK+SwWwhwdpIVnTTh4jYCWvIcVHA4Ny/H P/ecVIj2YfkaqjKAOxGOxa63I+DeVCWPCZ2CFWYnNfPvCixGj8IalTuBtcooXIN+c8JH paEe1Ek8im5lnKfSaP24LX+LC/0C778d3tyokFa6CJzdRfXJGsp9+QQOnD2PuSlOdpPF dI+Q== X-Gm-Message-State: AHQUAuYG1pD9VnlEaoGIBakAPKEFdypqYqtZMru5PZEU6tDmtWL1WfXV eHzb/oaW9yiWT8LaM029AZ9uC1rbkGipyWzcm3lKrg== X-Google-Smtp-Source: AHgI3IZZAlRbQXNOf6VKThfITGiSeAo2fWjEeS21q6EuhtE8iaXW3D7xy0nPeO7MRiKjdvfGcfvppGp4VOxuwTk+/4c= X-Received: by 2002:adf:f78e:: with SMTP id q14mr106492wrp.227.1549559368183; Thu, 07 Feb 2019 09:09:28 -0800 (PST) MIME-Version: 1.0 From: Martin Duke Date: Thu, 7 Feb 2019 09:09:16 -0800 Message-ID: Subject: Need any QUIC stream errors? To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b300ef058150e7f0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 17:09:32 -0000 --000000000000b300ef058150e7f0 Content-Type: text/plain; charset="UTF-8" I noticed that Stream Errors have gone away as a transport-layer concept recently. Most protocol violations (e.g., flow control) are now connection-level failures, and the error code in RESET_STREAM exists for application purposes. However, how should I communicate some sort of QUIC internal error that aborts the stream? For example, if there's a memory corruption or malloc failure in the stream send queue, a RESET_STREAM would be sufficient. Should I send with no error code, or take down the whole connection? Or do we need to reserve one stream error codepoint for this case? --000000000000b300ef058150e7f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I noticed that Stream Errors have gone away as a tran= sport-layer concept recently. Most protocol violations (e.g., flow control)= are now connection-level failures, and the error code in RESET_STREAM exis= ts for application purposes.

However, how should I= communicate some sort of QUIC internal error that aborts the stream? For e= xample, if there's a memory corruption or malloc failure in the stream = send queue, a RESET_STREAM would be sufficient. Should I send with no error= code, or take down the whole connection? Or do we need to reserve one stre= am error codepoint for this case?
--000000000000b300ef058150e7f0-- From nobody Thu Feb 7 09:37:53 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863E612F1A2 for ; Thu, 7 Feb 2019 09:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.903 X-Spam-Level: X-Spam-Status: No, score=0.903 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 7ugn2j4DD5mN for ; Thu, 7 Feb 2019 09:37:50 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47C812E04D for ; Thu, 7 Feb 2019 09:37:48 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id d11so1776300itf.2 for ; Thu, 07 Feb 2019 09:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=/v4KdCLxq69ZBdp0xv13XNe/RL9sFzZr2tZ+PkoTyYo=; b=Z4xIZFijGejjScHAUJIzbcPx5t2RmkE4mr8b8B0cLDJT0FKEWg0836XBacHv0RE3vL VGKZsC6TFJDK5LgzeOvPDQEdCPYz0Xd0I79dLjaAxY6keGzihw87bV/PVyMSHxZJxpfl PXkQY6n1qyJh+s30r7S5lf/8boaAC5MA/hhd+EB1YPfoAawaTu6kbZROospKe1P7BieF Dez07OGqH5rcfLHhXYpWOfWtfUqFFyYrNCZITebeU1DhTTijIjKbR2RuW77T7bnzg2K6 nSuCJjoC6J/JYVpd5ctYT34j1xg1pN7mgqEMy04yb3ojJ+lCYbKuf/WQPQBTvZahF4uF RyFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=/v4KdCLxq69ZBdp0xv13XNe/RL9sFzZr2tZ+PkoTyYo=; b=C1gR6drdKEwPsZUhbwk5VaX4K0FcEFR7iLL5UnLQtA3u1TXaYc+MzzuV89Hq8wss5e +7AN9BeZ2lj+GZO4viIvByaBhX47ANEwEwoEKAR93xA4JqiuLg2x0Az7jUeFsL71hXBk FwP/A8ID5IuReB45Vhg11HCf+6V5YQo6ObKaZOhAN6vWrA3Zlg/oi9WFqDRLS+s+ju8N Mi7ZeiOr0oLECFmrzRRx74ci8j+5M4qS/2sOtDcuwAYfmHWKsOnkyAtt+V26nyUA4rIR NdFOtyz/PDG37mg6QnisABjFg8qLfAipc1VzOZRN+vJo26f1WvyRnSbKF53lnNIblldX 5vwQ== X-Gm-Message-State: AHQUAuYLPz7vGs0CbAy31csfnAdoj1xCLoXqzoRJTnSGfa3HRBrKCo4P /rCbUrlxLvUG9Cdo94ZnUombcoM8WEnh1zox82g= X-Google-Smtp-Source: AHgI3IaUpmaiXqCOvLPj4foeIn3zJd6rMQ3H+ZFCrPZqH8eSpIcGSkW53cAeDALTyqJnHoHPh93PDuHg4QEtQrQnoyY= X-Received: by 2002:a02:2303:: with SMTP id u3mr9512955jau.42.1549561068007; Thu, 07 Feb 2019 09:37:48 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 7 Feb 2019 09:37:47 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> <1549505196.184749.1652574256.566C7304@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 7 Feb 2019 09:37:47 -0800 Message-ID: Subject: Re: Require Single Use 0-RTT Session Tickets To: Kazuho Oku Cc: Martin Thomson , Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000004375d0581514d08" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 17:37:53 -0000 --00000000000004375d0581514d08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 7 February 2019 at 17.56.55, Kazuho Oku (kazuhooku@gmail.com) wrote: 2. The design requires the resumption CID to be bundled to the session ticket. That goes against our previous consensus to not introduce extensions in the session ticket (IIRC we discussed it during the handshake refactor). This is not necessarily the case. If the ticket is keyed for a specific host, the CID only needs to make sure it hits the proper host, it does not need to verify the CID. If someone forges the CID they would either reach the same host as intended, or a different host, which does not have the key to verify the session ticket. If verification is based on CID rather than master keys for session tickets, it can become a guessing game that is easier to master. Another concern I have, is that the CID=E2=80=99s need to live for a long t= ime, and your recent issue on rate limiting CID=E2=80=99s highlights that they are a= limited resource, if short. Therefore the CID would need to be long, preferably so long that it need not be remembered. It should be thrown away like the original random CID of a new connection. This could also alleviate some routing consistency concerns, provided the actual host is online because the CID can hold more data. But, it complicates middle boxes that must now understand different CID lengths. On v1: If people are comfortable with the HTTP/3 as it is, the issue is not pressing. From what I hear it is still all rather unproven, so this would be an opportunity catch potential problems early. OTOH: there are probably many hidden problems that could use more time that v1 can afford. --00000000000004375d0581514d08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 7 February 2019 a= t 17.56.55, Kazuho Oku (kazuhooku@gm= ail.com) wrote:
2. The design requires the resumption CID to be bundled= to the session=C2=A0ticket. That goes against= our previous consensus to not introduce=C2=A0
ex= tensions in the session ticket (IIRC we discussed it during the=C2=A0
handshake refactor).=C2=A0

This is not nec= essarily the case. If the ticket is keyed for a specific host, the CID only= needs to make sure it hits the proper host, it does not need to verify the= CID. If someone forges the CID they would either reach the same host as in= tended, or a different host, which does not have the key to verify the sess= ion ticket.

If verification is based on CID rather than master keys f= or session tickets, it can become a guessing game that is easier to master.=


Another concern I have, is that the CID=E2=80=99s need to= live for a long time, and your recent issue on rate limiting CID=E2=80=99s= highlights that they are a limited resource, if short. Therefore the CID w= ould need to be long, preferably so long that it need not be remembered. It= should be thrown away like the original random CID of a new connection. Th= is could also alleviate some routing consistency concerns, provided the act= ual host is online because the CID can hold more data. But, it complicates = middle boxes that must now understand different CID lengths.


=

On v1: If people are comfortable with the HTTP/3 as it is, the issue is = not pressing. From what I hear it is still all rather unproven, so this wou= ld be an opportunity catch potential problems early. OTOH: there are probab= ly many hidden problems that could use more time that v1 can afford.

=

--00000000000004375d0581514d08-- From nobody Thu Feb 7 10:14:15 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8121292F1 for ; Thu, 7 Feb 2019 10:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSpXHyaFy1IT for ; Thu, 7 Feb 2019 10:14:11 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740090.outbound.protection.outlook.com [40.107.74.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D690129284 for ; Thu, 7 Feb 2019 10:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rD6BppSTWl/lJ4RziGLFVqAeGx/LRyAL0QP5o4Bswn8=; b=qnNCebd2Muz/bcxp2pYGr06vlqucganPmHTmclYw1HhTk7Hfq1hwWkP7C76ii3QkfIVkgu3S0mYJwBADbznIODTQ8uJcxmhBNYFKRqKAIRquJVQSbzOnEWo37uIkke9BopNBj9UMxZk5snV38MtcJ/Vsd858kwrViTGtMkex7qA= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0486.namprd22.prod.outlook.com (10.173.195.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Thu, 7 Feb 2019 18:14:08 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2%4]) with mapi id 15.20.1558.021; Thu, 7 Feb 2019 18:14:08 +0000 From: Mike Bishop To: Martin Duke , IETF QUIC WG Subject: RE: Need any QUIC stream errors? Thread-Topic: Need any QUIC stream errors? Thread-Index: AQHUvwfrPQvEi3VNkEeXGhjHNaDDsaXUozew Date: Thu, 7 Feb 2019 18:14:07 +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: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR22MB0486; 6:H8lwTDmQLaShaHY8qaZh346lCL4wKPNrF5BmALBWEoWCzt4rYzz+exk+tIR/wwye8VPjtP2VZ5mo4rLzVlFyHhxSK4I/x3G7us3LI+X3MukKzzKmiBA/Ul1TghG28tS6yM/KOKmBSTgK9kv8HqJ6s/Gl1PE33ItmQpwaQsboJ4HHdRSxulZfmSa7gAfgPMcSbP4PZnoWPyEftSJrc+SZRUwR0gfWSHXgjMmuQrdCOkadAceh1yx26OjFFLu71NJPNp5kr3H1ijNUlbQNldIoese/rcyDG5YG3jmr6K9dxqpg4t/EkqmEfStIUieZWRLBUexim0R70t+OD5SRGFNfI95UJepkt2EfqyeJ1ObTYdSSuObNEOqv55wSSRAZhhp99WLap0Z2cek4V0YM0ry0uTmV1vfILbARnZjSF8bJzHfsJ54ovGmAnCwow87soVuE7KMnSioIej3zjPlhBW/h6A==; 5:8b35xiP741lL9CQlHbQKwrLNMSoiI2Xvd5UtdFoPAiQduuW0fukYV4OIRX+HaXDD0HVFRvCGd3tyidByTd4R/amqg1rD03d0PrJTfViq0pQStFljEvkiyJ7oyi9jlcf6dCKkZJXQhBEaXLMzkO5VO2Y0OVZH+gwDjCayMpont6RjC4AFoCG6nrFi3wrRjDrdht0V4a4lMlxcSDwtxlqFtA==; 7:xsgzNEQxt08euSTpAMOADwUnts/e3jZWUeZSHHkcTakhnhRvnoEF7S2XYvDzS6z+0vBizuU46Cr55zjoHAzFhx+Fqzj9z3EpW3VZGRkvm7hF7hLITQQOEtfnfmXhVo7vpSh0okrc3hjX8kE38wFxMQ== x-ms-office365-filtering-correlation-id: d768b2cb-1897-436c-dc6c-08d68d280d52 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0486; x-ms-traffictypediagnostic: CY4PR22MB0486: x-microsoft-antispam-prvs: x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39830400003)(136003)(366004)(346002)(199004)(189003)(476003)(106356001)(86362001)(486006)(68736007)(71190400001)(71200400001)(8936002)(110136005)(186003)(7736002)(99286004)(74316002)(76176011)(316002)(81166006)(6246003)(81156014)(8676002)(25786009)(105586002)(2906002)(6436002)(53936002)(14444005)(229853002)(256004)(26005)(14454004)(66066001)(508600001)(97736004)(7696005)(446003)(74482002)(3846002)(790700001)(6116002)(33656002)(11346002)(102836004)(6506007)(53546011)(55016002)(54896002)(9686003)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0486; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ULya9ssDnTtyEcKuh/+bwrh28UjvDOjTuemvcmBgKZUdmDCwq//QDJmMu8usPPowJNDnegPwuReveUPURY/LTSZ3pKU0UQ/YQZxTu57sAdfJQrSnljB+e+4hDllVXWn0cWsOnwctNQPgoOGnJIkJN43AUSCHc1wyIPU0s9m+zwYo7ZHkGkZ0YE1gY8MDlEFGe7S2xGhAG1C15bODbJ3oXTAXTa3xfjRN0YRQGNuTv88nE/YbZmzI/Dv00waI2pPJfJ40gsz7UQ+l40tnAbNKZMQm1sXCNUhOdz59//Wuibz05oBKkhpE8Vc7Y/f9iOMKx89qVPkvEFn5/a4wUz/jYzi8iX50EIlVF2JVSK9jqjpmy3lXrNy1EsqjaaGT2Ed8VbmFAnWyFbaYIrIu5l+CDAUSY11lvZ8CN0M4ntweGaY= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983735C0F1FCE4A876DB738DA680CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: d768b2cb-1897-436c-dc6c-08d68d280d52 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 18:14:07.8193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0486 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 18:14:14 -0000 --_000_CY4PR22MB0983735C0F1FCE4A876DB738DA680CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gZmFyLCB3ZeKAmXZlIHRha2VuIHRoZSBwb3NpdGlvbiB0aGF0IHN0cmVhbXMgY29udGFpbiBh cHBsaWNhdGlvbiBkYXRhLCBzbyB0aGUgcmVhc29uIGZvciB0ZXJtaW5hdGluZyBhIHN0cmVhbSBp cyBleGNsdXNpdmVseSBpbiB0aGUgYXBwbGljYXRpb27igJlzIGRvbWFpbi4gIElmIHNvbWV0aGlu ZyBpcyB3cm9uZyB3aXRoIHRoZSB0cmFuc3BvcnQgbGF5ZXIsIGl0IChwb3RlbnRpYWxseSkgaW1w YWN0cyB0aGUgZW50aXJlIGNvbm5lY3Rpb24uICBJ4oCZbSBjb250ZW50IHdpdGggdGhlIGlkZWEg dGhhdCBhbiBFX09VVE9GTUVNT1JZIGNhbiBibG93IHVwIGEgY29ubmVjdGlvbi4NCg0KRnJvbTog UVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFydGluIER1a2UNClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSA3LCAyMDE5IDk6MDkgQU0NClRvOiBJRVRGIFFVSUMgV0cg PHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBOZWVkIGFueSBRVUlDIHN0cmVhbSBlcnJvcnM/DQoN Ckkgbm90aWNlZCB0aGF0IFN0cmVhbSBFcnJvcnMgaGF2ZSBnb25lIGF3YXkgYXMgYSB0cmFuc3Bv cnQtbGF5ZXIgY29uY2VwdCByZWNlbnRseS4gTW9zdCBwcm90b2NvbCB2aW9sYXRpb25zIChlLmcu LCBmbG93IGNvbnRyb2wpIGFyZSBub3cgY29ubmVjdGlvbi1sZXZlbCBmYWlsdXJlcywgYW5kIHRo ZSBlcnJvciBjb2RlIGluIFJFU0VUX1NUUkVBTSBleGlzdHMgZm9yIGFwcGxpY2F0aW9uIHB1cnBv c2VzLg0KDQpIb3dldmVyLCBob3cgc2hvdWxkIEkgY29tbXVuaWNhdGUgc29tZSBzb3J0IG9mIFFV SUMgaW50ZXJuYWwgZXJyb3IgdGhhdCBhYm9ydHMgdGhlIHN0cmVhbT8gRm9yIGV4YW1wbGUsIGlm IHRoZXJlJ3MgYSBtZW1vcnkgY29ycnVwdGlvbiBvciBtYWxsb2MgZmFpbHVyZSBpbiB0aGUgc3Ry ZWFtIHNlbmQgcXVldWUsIGEgUkVTRVRfU1RSRUFNIHdvdWxkIGJlIHN1ZmZpY2llbnQuIFNob3Vs ZCBJIHNlbmQgd2l0aCBubyBlcnJvciBjb2RlLCBvciB0YWtlIGRvd24gdGhlIHdob2xlIGNvbm5l Y3Rpb24/IE9yIGRvIHdlIG5lZWQgdG8gcmVzZXJ2ZSBvbmUgc3RyZWFtIGVycm9yIGNvZGVwb2lu dCBmb3IgdGhpcyBjYXNlPw0K --_000_CY4PR22MB0983735C0F1FCE4A876DB738DA680CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNvIGZhciwgd2XigJl2ZSB0YWtlbiB0aGUgcG9zaXRpb24gdGhhdCBzdHJlYW1zIGNv bnRhaW4gYXBwbGljYXRpb24gZGF0YSwgc28gdGhlIHJlYXNvbiBmb3IgdGVybWluYXRpbmcgYSBz dHJlYW0gaXMgZXhjbHVzaXZlbHkgaW4gdGhlIGFwcGxpY2F0aW9u4oCZcyBkb21haW4uJm5ic3A7 IElmIHNvbWV0aGluZyBpcyB3cm9uZyB3aXRoIHRoZSB0cmFuc3BvcnQgbGF5ZXIsIGl0IChwb3Rl bnRpYWxseSkgaW1wYWN0cyB0aGUgZW50aXJlDQogY29ubmVjdGlvbi4mbmJzcDsgSeKAmW0gY29u dGVudCB3aXRoIHRoZSBpZGVhIHRoYXQgYW4gRV9PVVRPRk1FTU9SWSBjYW4gYmxvdyB1cCBhIGNv bm5lY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDICZsdDtx dWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpNYXJ0aW4gRHVr ZTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgNywgMjAxOSA5OjA5IEFNPGJy Pg0KPGI+VG86PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IE5lZWQgYW55IFFVSUMgc3RyZWFtIGVycm9ycz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG5vdGljZWQgdGhhdCBTdHJlYW0gRXJyb3JzIGhhdmUg Z29uZSBhd2F5IGFzIGEgdHJhbnNwb3J0LWxheWVyIGNvbmNlcHQgcmVjZW50bHkuIE1vc3QgcHJv dG9jb2wgdmlvbGF0aW9ucyAoZS5nLiwgZmxvdyBjb250cm9sKSBhcmUgbm93IGNvbm5lY3Rpb24t bGV2ZWwgZmFpbHVyZXMsIGFuZCB0aGUgZXJyb3IgY29kZSBpbiBSRVNFVF9TVFJFQU0gZXhpc3Rz IGZvciBhcHBsaWNhdGlvbiBwdXJwb3Nlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgaG93IHNob3VsZCBJIGNvbW11bmljYXRl IHNvbWUgc29ydCBvZiBRVUlDIGludGVybmFsIGVycm9yIHRoYXQgYWJvcnRzIHRoZSBzdHJlYW0/ IEZvciBleGFtcGxlLCBpZiB0aGVyZSdzIGEgbWVtb3J5IGNvcnJ1cHRpb24gb3IgbWFsbG9jIGZh aWx1cmUgaW4gdGhlIHN0cmVhbSBzZW5kIHF1ZXVlLCBhIFJFU0VUX1NUUkVBTSB3b3VsZCBiZSBz dWZmaWNpZW50LiBTaG91bGQgSSBzZW5kIHdpdGggbm8NCiBlcnJvciBjb2RlLCBvciB0YWtlIGRv d24gdGhlIHdob2xlIGNvbm5lY3Rpb24/IE9yIGRvIHdlIG5lZWQgdG8gcmVzZXJ2ZSBvbmUgc3Ry ZWFtIGVycm9yIGNvZGVwb2ludCBmb3IgdGhpcyBjYXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR22MB0983735C0F1FCE4A876DB738DA680CY4PR22MB0983namp_-- From nobody Thu Feb 7 10:42:15 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2081130DFA for ; Thu, 7 Feb 2019 10:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=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 JSOgg0Zn34xw for ; Thu, 7 Feb 2019 10:42:11 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 6F27512F1A5 for ; Thu, 7 Feb 2019 10:42:11 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id i145so2287010ita.4 for ; Thu, 07 Feb 2019 10:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=+AfTq4VDM1IVSoTqMddvF1xrBvYB8ooYT850HogWSOw=; b=ihw6LciQtWLVZv+cd3boILu7p66QTQxsjC0EJUJ1wf97MXAvI//kD1hClN87gO5lNP 0zTsVbuK8GBkW9FiQKM2Z3Hpal9QPVvyrvel4mFTYbV2mBAseSZ43ACh0Vd7AMCeFc15 AYGN22UnCcqtljXebxN9WNK5Iezwn8q3KtBY+lTafVjT8wwZBS9sUmD5pHJqGtkp+afQ YizGRxK2Pb9bXOm5inNWD6kMazx8fkTTBt03UDJRsnb96MUessuO+elzUCigpRztlnH0 ugpYkYyU98blT+T4DJYnE94xaZfr8F8a9GK+ISIBIXDbDnonJQI9NeOAtdEdqXFtsXdc b9uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=+AfTq4VDM1IVSoTqMddvF1xrBvYB8ooYT850HogWSOw=; b=Bqn8EdtBXpQU4ZUzK1jP2j5+XVHh8TPgvxLbLLjqk4cmpHADR2gPoRWyC3DD3EFIzS Bhit+nt1uGuodi9icmAM5fIBFAmE8CrdMPEVUVO0KPCaS2D/AoRdQzRQ1ZVIjdCqlooF 1frCHcVO/G9ED1wfhy9pO7Uk6Q0OMiV7ASTcpAzAOrCb2w6VW4IC7aYqU2udQKDyXJ6w pdyL9Sq4kWroojiNSzo3dbrqY4Pkz72aaFCgHPRZkHfboXU1rA0Gk/ALG0H6zgRPRG3o Si7UwuUQlArZuFI3cx4UjahUO2rRZdOPDzxlZWkXQxkde68c2zRYtUbLxE7I5c3jUNaj Cl2Q== X-Gm-Message-State: AHQUAuYXwl1VRHN1GdYk586K/S85bU0dVaz5O8dEDvi8Ltp++057tuKx KBmd+WOuRHEOxRBy/arJDE/JP6ziIvBByPq3QsE= X-Google-Smtp-Source: AHgI3Ib2XqqcnfMt/rfgQfiXPrw8q5+0tO/NqhoDqtKG1kmQtgDarUw3UgGUjZ2cPsVab6TPLL+LinZ6JbjzNe7Hhrw= X-Received: by 2002:a02:6:: with SMTP id 6mr9254101jaa.19.1549564930462; Thu, 07 Feb 2019 10:42:10 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 7 Feb 2019 10:42:09 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 7 Feb 2019 10:42:09 -0800 Message-ID: Subject: RE: Need any QUIC stream errors? To: Mike Bishop , IETF QUIC WG , Martin Duke Content-Type: multipart/alternative; boundary="0000000000003c9a31058152333f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 18:42:14 -0000 --0000000000003c9a31058152333f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, it is a great simplification to only have application assigned stream errors. There was a long discussion (is 0 special) that lead to a change in how RESET_STREAM / STOP_SENDING handles the error flow in order to keep it strictly application level. If anything goes wrong with a stream, it can go to the application, e.g. out of flow credits for too long, which can then decide. The stream as such is not harmed even if it has outlived its useful lifespan. On 7 February 2019 at 19.14.25, Mike Bishop (mbishop@evequefou.be) wrote: So far, we=E2=80=99ve taken the position that streams contain application d= ata, so the reason for terminating a stream is exclusively in the application=E2=80= =99s domain. If something is wrong with the transport layer, it (potentially) impacts the entire connection. I=E2=80=99m content with the idea that an E_OUTOFMEMORY can blow up a connection. *From:* QUIC *On Behalf Of * Martin Duke *Sent:* Thursday, February 7, 2019 9:09 AM *To:* IETF QUIC WG *Subject:* Need any QUIC stream errors? I noticed that Stream Errors have gone away as a transport-layer concept recently. Most protocol violations (e.g., flow control) are now connection-level failures, and the error code in RESET_STREAM exists for application purposes. However, how should I communicate some sort of QUIC internal error that aborts the stream? For example, if there's a memory corruption or malloc failure in the stream send queue, a RESET_STREAM would be sufficient. Should I send with no error code, or take down the whole connection? Or do we need to reserve one stream error codepoint for this case? --0000000000003c9a31058152333f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Yes, it is a great s= implification to only have application assigned stream errors. There was a = long discussion (is 0 special) that lead to a change in how RESET_STREAM / = STOP_SENDING handles the error flow in order to keep it strictly applicatio= n level.

=
If anything = goes wrong with a stream, it can go to the application, e.g. out of flow cr= edits for too long, which can then decide. The stream as such is not harmed= even if it has outlived its useful lifespan.

On 7 February 2019 at 19.14.25, Mike Bishop (mbishop@evequefou.be) wrote:

So far, we=E2=80=99ve taken the position that stream= s contain application data, so the reason for terminating a stream is exclu= sively in the application=E2=80=99s domain.=C2=A0 If something is wrong wit= h the transport layer, it (potentially) impacts the entire connection.=C2=A0 I=E2=80=99m content with the idea that an E_OUTOFMEMORY = can blow up a connection.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Duke
Sent: Thursday, February 7, 2019 9:09 AM
To: IETF QUIC WG <quic@ietf.org<= /a>>
Subject: Need any QUIC stream errors?

=C2=A0

I noticed that Stream Errors have gone away as a tra= nsport-layer concept recently. Most protocol violations (e.g., flow control= ) are now connection-level failures, and the error code in RESET_STREAM exi= sts for application purposes.

=C2=A0

However, how should I communicate some sort of QUIC = internal error that aborts the stream? For example, if there's a memory= corruption or malloc failure in the stream send queue, a RESET_STREAM woul= d be sufficient. Should I send with no error code, or take down the whole connection? Or do we need to reserve on= e stream error codepoint for this case?

--0000000000003c9a31058152333f-- From nobody Thu Feb 7 15:00:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2780130EC1 for ; Thu, 7 Feb 2019 15:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=VaCJ0dOL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=5vjpxbfg 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 eROaKnNR8U6j for ; Thu, 7 Feb 2019 15:00:22 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73218130EC0 for ; Thu, 7 Feb 2019 15:00:22 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4C9E2221C6 for ; Thu, 7 Feb 2019 18:00:21 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 07 Feb 2019 18:00:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:date:in-reply-to:subject:references; s=fm1; bh=ygS aOQ3E0ndYEKCdMCzNediYMUJV8/IL6g3Woo4sMg0=; b=VaCJ0dOLFU2+4czq2XA 4GuWvkEKiJSUFWwBA39gKK3RpkWeZT/GruQIfYstp2vsywWK5l6khNIq30eStVsN 2NM683JqHhqTJNfulHDVFzCyHte4Wk49vQ1ejwBPx5jD4D46aXJklj7bjxNVygX1 DSt8pwoz+exOb4y6JSfMwLbrLxnqKPFKlsjVCS+8Bd++fRjCLgXfGn3MDehxJEDe Hu+W0CW2yl+1zaQA5HuVUXPB04AqNXdJbZkwZ2dFy1neGZ3K82iJVO5OhtOPlvKf 9ojoxvxExYcqmhg7M+WOSDno6afNqJWRiM/Iehd65uQ7EnW7v2D7suV6TYp9EXK6 yYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ygSaOQ3E0ndYEKCdMCzNediYMUJV8/IL6g3Woo4sM g0=; b=5vjpxbfgK4/Z4QmbhzWmka9ZmRxJUdE3X+hLvwMJAs5ar7TYvom8NF44v 5/R0hExQTaxB2hoC81kzpotxq0LwbV+0f6wXN7oFSnkgphfBG3osB5bQv9BOoGXZ vnUjLmH+pdmvBeTYjlxj9VdhB8RFQ9ISP5Q/CHqh6nC4WS5L/qfQGa6n+D6eyfoz 2JXxRCV4kcEi3x9OmOD0B6eTfWYCphH6hhj6wJI0gyN4pFLqddk2/Xjm0UzMO6BY PSCVFAT68HanW2PS3hEFd5qiQoDE9ivYOJ8KVlBLsKmlqFvejEoHVAA32Q58VVdV Ai+vJf4jSfOfCPbPTTxkA3CpxrPqQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrledugddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfoffgjufhfsehtqhertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucffohhmrghinheprhhgvghnshgvnhhmihhkkhgvlhhfjhhgmhgrihhlrdgtohhmpdhhth htphefrdhmhienucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 42F5F9E59A; Thu, 7 Feb 2019 18:00:20 -0500 (EST) Message-Id: <1549580420.772211.1653288848.03A79309@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1 Date: Fri, 08 Feb 2019 10:00:20 +1100 In-Reply-To: Subject: Re: Require Single Use 0-RTT Session Tickets References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> <1549505196.184749.1652574256.566C7304@webmail.messagingengine.com> Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 23:00:25 -0000 We had a similar debate in TLS. By my recollection, the conclusion was tha= t while there are distinct advantages in binding 0-RTT resumption to a sing= le instance, the practicalities (such as those that Kazhuo lists here) are = such that it was impractical for too many deployments. As such, there is a= dvice in TLS 1.3 about this (see Appendix E.5 and Section 8), but none of t= hat advice rises to the level of being mandatory. In the end, if your serv= er infrastructure can support this, or the rate of successful 0-RTT accepta= nce is not reduced significantly by enabling this, then all power to you. On Fri, Feb 8, 2019, at 03:56, Kazuho Oku wrote: > Hi, >=20 > I think that the proposed approach works, and I think it's an > interesting idea. However, I am not sure if I would prefer having > this, at least in v1. The reasons are as follows: >=20 > 1. The design requires CID-based routing to be stable for the lifetime > of the session ticket (7 days). I am not sure if all of us can achieve > that. Note that the CID encryption key (and therefore the stateless > reset token key) needs to be stable for that amount of time. >=20 > 2. The design requires the resumption CID to be bundled to the session > ticket. That goes against our previous consensus to not introduce > extensions in the session ticket (IIRC we discussed it during the > handshake refactor). >=20 > 3. HTTP (which is the target application of QUICv1) already has a way > to handle replay attacks (425 Too Early). Most if not all server > operators will deploy that regardless, because we need it to support > 0-RTT in TLS 1.3. I do not think we need a different mechanism for > HTTP/3. My preference goes to using the same mechanism in all HTTP > versions to avoid confusion among the users. I might expand the > argument that this would be the case not only for HTTP but for any > protocol that might run on TLS-over-TCP and/or QUIC. >=20 > 4. The design introduces burden to certain HTTP-QUIC stacks. > Currently, it is possible to mitigate replay attacks by > pattern-matching the HTTP method / URI to see if a request needs to be > delayed until receiving the proof of non-replay. The proposed approach > mandates the stacks to deploy a hash-table-based replay detection, > which IMO is rather costly, considering the fact that most GET > requests are idempotent and therefore replay-resistant. >=20 > To summarize, the proposal seems like a gratuitous change considering > the state of HTTP and QUIC v1. >=20 > 2019=E5=B9=B42=E6=9C=888=E6=97=A5(=E9=87=91) 0:00 Mikkel Fahn=C3=B8e J=C3= =B8rgensen : > > > > Well, yes, but I already made my point. > > New thread here in case anyone wants to contest or support this proposa= l. > > > > I=E2=80=99m actually not suggestion this just make it easier for an ope= rator to achieve single use, I am suggesting to require operators to honor = it, otherwise application developers are still left guessing, although this= belongs to the class of things that cannot easily be enforced. > > > > On 7 February 2019 at 14.49.56, Ian Swett (ianswett@google.com) wrote: > > > > Mikkel, are you suggesting a connection ID be paired with a NewSessionT= icket or Token for the purposes of resumption to make it easier for a serve= r operator to prevent using the same NST or Token multiple times? > > > > If so, this thread has gone extraordinarily off the original topic of w= hat frames to allow in 0RTT, so if you want to discuss that further, please= start a new thread. > > > > On Thu, Feb 7, 2019 at 1:45 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > >> > >> Yes, I forgot the 0-RTT token is called a ticket. The fact that it is = encrypted does not change the general similarity to Retry if we assume retr= y tokens are created in safe manner. Both can be replayed and both can have= non-forgeable timestamps.. > >> > >> What is different is that TLS 1.3 over TCP does not have a concept of = Connection ID that it can use for routing, but Retry does. > >> > >> (Restating that currently Retry is not required, only recommended, to = enforce single use, but analysis shows that it is feasible to require). > >> > >> The time limit is, in this context, needed to ensure you do not have t= o keep infinite state whereas for TLS in general it (I presume) has more to= do with tracking, reducing the attack surface, but to an extend also to cl= ean up state. > >> > >> By requiring that the 0-RTT NewSessionTicket is used with a CID that r= outes to a specific endpoint, or cluster of endpoints, that can synchronous= ly verify non-reuse within the time limit, you can lift a complex burden fr= om the application layer - at the cost of complexity in transport and clust= er configuration. > >> > >> One reason not to do this is complexity - but it is still simpler that= dumping this on the average application, and you are not forced to to do 0= -RTT. > >> Another reason to not do this is that if you can=E2=80=99t control you= r routing tightly you need an internal lookup which adds latency. > >> > >> The application layer has a few advantages: One is that it might not c= are about replay (like GET hello/world), or it might have a convenient sync= mechanism like a database query. But these are notoriously difficult to ge= t right and fast at the same time. > >> > >> If you place the burden on transport, you loose the ability of cluster= wide fast GET, but that might not be a big issue, since routing to a dedic= ated host will also work and on average it will level out. > >> > >> If the servers QUIC implementation is able and willing to share synchr= onized state (e.g. via Redis or Zookeeper, etcd, or custom built-in), you c= an take the complexity hit once and let applications piggyback on that, and= if its not, you still have single server guarantees. > >> > >> I believe this is the only sane way to go about it. I really can=E2=80= =99t see 0-RTT being safe left to the average application developer (howeve= r smart) when under time pressure to deliver. > >> > >> Regardless of much work the transport does, an application should of c= ourse maintain its own integrity, and avoid double bookings etc. which can = happy by other means as well, unless, of course, that would be a business s= trategy to do so. > >> > >> On 7 February 2019 at 03.06.37, Martin Thomson (mt@lowentropy.net) wro= te: > >> > >> Hi Mikkel, are you talking about Retry? The token that is used for 0-R= TT (that is, the session ticket) is encrypted. The (very) short-lived token= that appears in a Retry packet is the only token-like thing that is expose= d to the network. > >> > >> The point about servers tracking clients is already well-treated in th= e literature. (I can't remember if we have text in QUIC specifically, but i= t should be in TLS.) > >> > >> As for time-limiting, TLS 1.3 already provides measures that strictly = limit the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be ret= ried within a week that the token is issued. More importantly, there is a f= ield in the TLS handshake that limits the time over which the token can be = replayed. There are some limitations because it relies on clients and serve= rs having clocks that run at approximately the same speed and we have to ma= ke allowances for retransmissions, but the general guidance we have is that= a 10 second window is what you get for replay. Of course, that is only one= of the defenses. > >> > >> On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > >> > I came to think about the recent discussion about interception of the > >> > replay token by a man on the side. > >> > Here it was pointed out that it would be practical to enforce single= token > >> > use because > >> > > >> > 1. the retry to goes to server designated CID > >> > 2. the token can have a timestamp > >> > > >> > We could do the same with 0-RTT (I think) > >> > There has previously been discussions on the CID used in 0-RTT - whe= ther it > >> > is the original random CID or a server designated. > >> > But if 0-RTT uses the same approach as single use retry tokens, then= it > >> > should be practical to enforce no replay. > >> > Of course data centers can work around this if they care enough with= the > >> > risks involved and moved to the application layer - so the draft cou= ld have > >> > an escape hatch for that. > >> > > >> > Such an enforcement would make the 0-RTT more short lived and at hig= her > >> > risk of being rejected, but I don=E2=80=99t think that is a major co= ncern. > >> > > >> > Also, 0-RTT tokens can allow servers to track anonymous end users, so > >> > limiting their life time is a good thing. Maybe more important than = the > >> > discussion on migration linkability. > >> > > >> > Mikkel > >> > > >> > > >> > On 6 February 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.= tcd.ie) > >> > wrote: > >> > > >> > > >> > piping in from the sidelines so I don't expect this to be found so > >> > convincing, however... > >> > > >> > On 06/02/2019 04:11, Martin Thomson wrote: > >> > > it would be a mistake to try to make decisions about 0-RTT safety = in > >> > > the transport, when replay risks are an application-layer concern. > >> > I believe that is not true for some decisions. > >> > > >> > If the WG decide to disallow something that could cause an applicati= on > >> > layer concern then that will remove the need to do application layer > >> > analyses of replay/0-rtt for those cases. Given application devs will > >> > in general not do those analyses, disallowing as much as you can (of > >> > the risks arising from 0-rtt) in the transport seems safer to me. > >> > > >> > If you want to name a principle ISTM that 0-rtt is a quite like a > >> > dangerous implement, which seems better avoided as far as possible.. > >> > > >> > One question though - do we have any information about real world > >> > 0-rtt issues arising in http/tls1.3 or is it still too early? If we > >> > did have such information that may better inform this discussion. > >> > > >> > Cheers, > >> > S. >=20 >=20 >=20 > --=20 > Kazuho Oku >=20 From nobody Thu Feb 7 15:07:41 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D0130EC0 for ; Thu, 7 Feb 2019 15:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=ZovD0fwp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Oo0NZewm 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 lm4bkm4yfY76 for ; Thu, 7 Feb 2019 15:07:39 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D719130E62 for ; Thu, 7 Feb 2019 15:07:39 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 44D1F2206B for ; Thu, 7 Feb 2019 18:07:38 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 07 Feb 2019 18:07:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:references:in-reply-to:date; s=fm1; bh=AI2 iWli37B/Ndob+pOEOlsnexQkNvAF08AigKIStEic=; b=ZovD0fwptReLnBtJSj5 uasY/JlTGe9rMsat/LGO3u8yuQKGPth04wv3alvRYiF5PDGBiKt/nJYDB7r/+z0v TcF9a6OjFTAHAPgJ2uOsLR7T049kljO4BdzZ8ii7MzEOdPSjrwLFUFUFhCtCuaR6 clEjWcQclgL9z1L40/sKHiRG2+sp5j/VKZwaAJQcT9ti2VBHh7dpBIJL8+tp+RRv cKno1awNOhL5rNn/CNf99LfIo085lJF6YqFWypWb41IXse2BYCLw12Duq2RvKZWp LTURkwYFXQootmO0aVTgjWFP/mhcSiQwC/09EXO4m8EfEBY4qOj5g9TxR3dKqYzd HqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=AI2iWli37B/Ndob+pOEOlsnexQkNvAF08AigKIStE ic=; b=Oo0NZewmMIxuFTx5eKs2m931D29rtMiwG+ZDCryQEpTdHITu6l85W4cJ+ JcZ5czRKTmMFvFOvvldKUyrKCFpOF0vM5PPns6q0oF6BeiL+1PbduVsqmtyRpXQo zok3GlFGn7OUGAOUYEnh1VsOqjToW9DDOC3fF0lc+U0WaiXmeq51nLOvjQiKUMj+ T6PgV7QlRR3ASp/c3GnSuVAzsm7Px9XOXEKOW1G/+U1cPxOgvyIStmzc8f4elQqx ojwVpEXhAqpkxKlU+yKp4XR/axot340939fie7baoJV6trmPvCgfM9xoNbCyT6Ub /VzaTagP6b30JnslOCEzhbNho2ljQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrledugddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfoufhfjgffsehtqhertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B9D589E59A; Thu, 7 Feb 2019 18:07:37 -0500 (EST) Message-Id: <1549580857.775928.1653295368.302A6251@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1 Subject: Re: Need any QUIC stream errors? References: In-Reply-To: Date: Fri, 08 Feb 2019 10:07:37 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 23:07:40 -0000 An application might need to be aware of stream cancellation. For instance= , if a request stream is reset in h3, the compressor has to signal this or = the compression state can lose synchronization. On Fri, Feb 8, 2019, at 05:42, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Yes, it is a great simplification to only have application assigned stream > errors. There was a long discussion (is 0 special) that lead to a change = in > how RESET_STREAM / STOP_SENDING handles the error flow in order to keep it > strictly application level. >=20 > If anything goes wrong with a stream, it can go to the application, e.g. > out of flow credits for too long, which can then decide. The stream as su= ch > is not harmed even if it has outlived its useful lifespan. >=20 > On 7 February 2019 at 19.14.25, Mike Bishop (mbishop@evequefou.be) wrote: >=20 > So far, we=E2=80=99ve taken the position that streams contain application= data, so > the reason for terminating a stream is exclusively in the application=E2= =80=99s > domain. If something is wrong with the transport layer, it (potentially) > impacts the entire connection. I=E2=80=99m content with the idea that an > E_OUTOFMEMORY can blow up a connection. >=20 >=20 >=20 > *From:* QUIC *On Behalf Of * Martin Duke > *Sent:* Thursday, February 7, 2019 9:09 AM > *To:* IETF QUIC WG > *Subject:* Need any QUIC stream errors? >=20 >=20 >=20 > I noticed that Stream Errors have gone away as a transport-layer concept > recently. Most protocol violations (e.g., flow control) are now > connection-level failures, and the error code in RESET_STREAM exists for > application purposes. >=20 >=20 >=20 > However, how should I communicate some sort of QUIC internal error that > aborts the stream? For example, if there's a memory corruption or malloc > failure in the stream send queue, a RESET_STREAM would be sufficient. > Should I send with no error code, or take down the whole connection? Or do > we need to reserve one stream error codepoint for this case? From nobody Thu Feb 7 18:46:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7034130F1A for ; Thu, 7 Feb 2019 18:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=WIPRJ0CV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WM98TKey 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 b5vfFuivDEZ1 for ; Thu, 7 Feb 2019 18:46:23 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF82124408 for ; Thu, 7 Feb 2019 18:46:22 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 05D0A21EAD for ; Thu, 7 Feb 2019 21:46:22 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 07 Feb 2019 21:46:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:date:references:subject; s=fm1; bh=WdY R1sIbBow5DIDFttBbRsDSzsXq2FSBqKA+10RHPCU=; b=WIPRJ0CVV/NMV02iB2k QTLUYWQdK1DxThzTJsWSxusB7NpKr49SyqgPnTtNB+EuDgPXjfjuZ2a9HnD7CaQu cAeudS8x0Z2DvkRtMmdvrPr8AzRRmS2uoM0isFAaceDzO9M07kd3kO4LVwl+OpkQ Y5Eyr5rntlcx05Q9AvnVpJe6T+IIebgmtnLBt6TUH5FjK1/MQb7R4lFjQ6sUWhEG QgmoUE+o1gfC7KbLdgSCJAqZf++gjgcRxVdsaPyk6UeVcLIf9oLPFfEKmhZvAO3I a/QJjwK+6PiA/7t5+9YAFv2tN5Ycvy1JiQdeNgrWjHRELqItMQqw7wJvRSFFrRnn AAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=WdYR1sIbBow5DIDFttBbRsDSzsXq2FSBqKA+10RHP CU=; b=WM98TKeyOUu017idvNkRhiX0HIrS37V+o7TV6eoLSgfZm+uzMR/3evqmt ni9aukby09TDwSm+0S7XhjTHs8z2W687+ypPPiuhpG/5CaWJlsCSlD8pEpDKBC7R +WDy7HrAhFGwMAHnKFU3nz14H1ItX8dQfoM+QY4G1QYLjUSLs8BgGYaM9bOJZbe2 gq8K4ojuTGC49oV48zMkY7iQylWmwPwTVqTvqtdQhQNojN61Oxi6pByMlk76EDNW ifRdxQB2zkLrRpcJgnWECl7eIX45pzdR4fV0ASQdJOsE1c+yejc9lD5hAf2Jnm09 xb1e//g8w3/mtmA9TB95t6X4mueMQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrledugdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfojgfffhfusehtjeertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 59EE29E595; Thu, 7 Feb 2019 21:46:21 -0500 (EST) Message-Id: <1549593981.877482.1653392768.203A9C0B@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1 In-Reply-To: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> Date: Fri, 08 Feb 2019 13:46:21 +1100 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> Subject: Re: New path => new connection ID, right? Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 02:46:25 -0000 In an attempt to close the loop, I've updated https://github.com/quicwg/base-drafts/pull/2414 The controversial bits are apparently: * if you intentionally move to a new path, then you have to use a connection ID that hasn't been used on any other path * if you don't have a new connection ID (which also includes zero-length connection IDs in the latest change), then you can't use a new path I believe that both are editorial changes, but the volume of discussion on the thread indicates that some people would like to see the issue reopened. In the interests of forward progress, I would like the chairs to make an assessment. Note that this PR doesn't include the fix to https://github.com/quicwg/base-drafts/issues/2342, which reviewers will no doubt trip over in the process of reviewing this change. On Tue, Feb 5, 2019, at 10:15, Martin Thomson wrote: > I thought that we had agreed that an endpoint that intentionally > migrates has to use a new connection ID on the new path. But I couldn't > find any "MUST" in the spec that said that. > > On the off chance that this wasn't just a mistake and there was some > good reason not to mandate this, I'm bringing the discussion here. > > I've opened a design issue: > https://github.com/quicwg/base-drafts/issues/2413 > > The change I'm proposing is here: > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995236dda960b4cdff49e36f From nobody Thu Feb 7 18:55:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BA8130F1D for ; Thu, 7 Feb 2019 18:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=cc6wmj6u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JosNWaOD 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 0NCcYNCCRBx9 for ; Thu, 7 Feb 2019 18:55:03 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E54124408 for ; Thu, 7 Feb 2019 18:55:02 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EBA1122274 for ; Thu, 7 Feb 2019 21:55:01 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 07 Feb 2019 21:55:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date; s=fm1; bh=N243baTp0kqIGSG52LsnGM5Rd8 hjumqqF+vpALhKUQs=; b=cc6wmj6uxk8cLUZBIhOkDk/ZuKimQUxvuJuyp8gh+d lDwd4w2tBnvGfLOMt6EiJe4ncKkWrPWMFQwiVBK34qLQ5Lc5DrXlWJxs0NGJURtG XO+GC037adk0FjC+wqqt0bR6NVdAvcOWVnr4bqDW2+UgkdkjQd0X7rvXmZ/nDUT8 mEDOWZ2eri+Srhaz9GV8+PmPzPj3iYvcywamEAsDK+HSH4Su90OQuo8MGGLUp/lE QkqiFVSHXSZ8aqi5Q4ytiQbjf5N/O6cPY5/ACsKA9wE0IcF5OJghTWJtncN9M02n i1/18OyJXjwp0mGmpXPGoDUq3/ldI0MptrYo5/hrkVUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=N243ba Tp0kqIGSG52LsnGM5Rd8hjumqqF+vpALhKUQs=; b=JosNWaODOJmJyKBfqjO7tQ poVWy+mjY5/GnT75cfHvQVkamspKvlnEuVz6iYNgIa59SJBlR3FUOHBEYuWKoeRi YEeEktkGklULEJDrQ0+Iv1jYaO6ETJOxYZ+gDUbkBqp+wEDNzYUnk6d3xVfQvN3a zGC/1/SL5pjtrHGUqWeqngNBzP3IjwIuNUQW9yChqz6XyzhfdOYIBZ+PCtu3P8b6 licspMuloMc6oS24e/HhAxUTGwAgpz8NvSe1n8TzApMkISwhuSJFpYvdD+9L4zTQ zfdJdhJug0D57bI2Q855Woi+t8Ps2gOIk37XbKc9aGPGhpHgCKXYGmZvOnHPU/+Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrledugdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucgoteefjeefqddtgeculdehtddmnecujfgurhepkffhvfgggfgtoffuffesthejre dtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3F8DE9E595; Thu, 7 Feb 2019 21:55:01 -0500 (EST) Message-Id: <1549594501.881364.1653399392.63222EBD@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1 Subject: Limiting connection ID supply Date: Fri, 08 Feb 2019 13:55:01 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 02:55:04 -0000 https://github.com/quicwg/base-drafts/issues/2436 includes a simple issue: if someone starts retiring connection IDs aggressively, they can exhaust your supply. Kazuho suggests that we allow endpoints to limit the number of connection IDs they supply. There is a PR: https://github.com/quicwg/base-drafts/pull/2428 I don't think that this sort of rate limiting is generally advisable, because of the risk that this would discourage the use of new connection IDs. Long connection IDs are a better solution, but those are inefficient and I don't want to get into a situation where connection ID rotation on shorter connection IDs is infeasible. I think that the proposed text is worded carefully enough and strikes a good balance between these concerns. I would like to merge this one. From nobody Fri Feb 8 00:32:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC89130E6E for ; Fri, 8 Feb 2019 00:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNpgFjtFvP08 for ; Fri, 8 Feb 2019 00:32:34 -0800 (PST) Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E44D1286D8 for ; Fri, 8 Feb 2019 00:32:33 -0800 (PST) Received: by mail-it1-x12a.google.com with SMTP id x124so7985471itd.1 for ; Fri, 08 Feb 2019 00:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=2SA2VGIQVc26LC70vaB3fL4M/QhVJvIj9t1HCU790NU=; b=PP68cS1Fc4kXl0YRQ4pz2DtrwtfBIkPDnpQbDZSKvUjBWYy+WhhMY9wwvmmJHrJqhc C7HmDD/fDcuLbNK3L5GXKHmMYkAokafTMCaJjrSgYyjMGzVi+WMyaeZ7qfyqTz+lyVcB J749vmVBz3nfYMYe2py/5VA/Pysoea/L0Lq3TfWz8eRJAxAHosoukjCYecNFazjSUN3v JasA0UE/X1A4TinsUeoSOmRPp+UeX1DfhLfWtE8oCtPRzwB4hECqUSD+4n2Rc8BLS4pB bUsXE21anLwp9ZHvEnTBC+BCwIsb5SSvPG9WiR36+Ypj14z+YXZDJjfDkc0xSKCFjFjc 9gfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=2SA2VGIQVc26LC70vaB3fL4M/QhVJvIj9t1HCU790NU=; b=laYdxrFL7RySVTHmtemCgZLtVBjCSrUNiHqpnChiAuJilHOodAEVQ/tlSyfWSALeZ4 FjqYdQKp8nhOxEixcSANql3GLyyZeH90lMzH91I5DHbOtb0+OxLrdxuWQB9vb5R24Ub3 riIEsyKgXwCbhqNLAkf7OP3UXnaZOwacwoGq3Sy9umsMf2FXMXPmy8LIuaGmcGea+5QN /03olQdqnljow8ttYoMukpbA7nodaC9HigBfX7XfYzhC03y3EP+8XbLMay8lJ4jBj80W kxZY7bLy6FTkSqT3Mr93vDyEjI/8tZ/28EDCNSv2tg8TT0qd0sP2FtwAvX3+CIDU2DI0 2clA== X-Gm-Message-State: AHQUAuY0bsQW0++QnJfMsrc3pJC2LTW8f1lwCFOtpjpc3o9t8GNmCNrr fhPicX/ChTG/g0Aoym6Sql1dK6Up9HeJK68oPtb74Q== X-Google-Smtp-Source: AHgI3IZ5icZlkru0/Ceftt/EVaw3ZuVJCFsLXIDeXJ/DC4P9Bfki1HSOx/Ezxnfoug8cbOQlT/njSePSlN8LqfkAQbc= X-Received: by 2002:a6b:f206:: with SMTP id q6mr12164029ioh.166.1549614752992; Fri, 08 Feb 2019 00:32:32 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Feb 2019 00:32:31 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <1549580420.772211.1653288848.03A79309@webmail.messagingengine.com> References: <1549426311.3232701.1651780568.1A65255C@webmail.messagingengine.com> <68694259-6510-3da8-5651-407edb84a347@cs.tcd.ie> <1549505196.184749.1652574256.566C7304@webmail.messagingengine.com> <1549580420.772211.1653288848.03A79309@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 8 Feb 2019 00:32:31 -0800 Message-ID: Subject: Re: Require Single Use 0-RTT Session Tickets To: Martin Thomson , quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000e411fa05815dcc74" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 08:32:38 -0000 --000000000000e411fa05815dcc74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for these insights. I think it would, as a minimum, be good to ensure the design is friendly towards single use tickets. There is an open ticket on which DCID a 0-RTT uses. https://github.com/quicwg/base-drafts/issues/2398 If 0-RTT could (optionally) use a longer server selected DCID than normal, that would make the design possible even if not enforced - noting that it isn=E2=80=99t necessary for the session ticket to know the CID. As to the TLS discussion - TLS would have to make allowances for load balancers that cannot be assumed to understand 0-RTT flow. I think this is different for QUIC where CID routing must be assumed. That does not mean that QUIC single instance 0-RTT doesn=E2=80=99t cause more problems than is worthwhile, but dismissing it based on TLS observations alone is probably premature. On 8 February 2019 at 00.00.38, Martin Thomson (mt@lowentropy.net) wrote: We had a similar debate in TLS. By my recollection, the conclusion was that while there are distinct advantages in binding 0-RTT resumption to a single instance, the practicalities (such as those that Kazhuo lists here) are such that it was impractical for too many deployments. As such, there is advice in TLS 1.3 about this (see Appendix E.5 and Section 8), but none of that advice rises to the level of being mandatory. In the end, if your server infrastructure can support this, or the rate of successful 0-RTT acceptance is not reduced significantly by enabling this, then all power to you. On Fri, Feb 8, 2019, at 03:56, Kazuho Oku wrote: > Hi, > > I think that the proposed approach works, and I think it's an > interesting idea. However, I am not sure if I would prefer having > this, at least in v1. The reasons are as follows: > > 1. The design requires CID-based routing to be stable for the lifetime > of the session ticket (7 days). I am not sure if all of us can achieve > that. Note that the CID encryption key (and therefore the stateless > reset token key) needs to be stable for that amount of time. > > 2. The design requires the resumption CID to be bundled to the session > ticket. That goes against our previous consensus to not introduce > extensions in the session ticket (IIRC we discussed it during the > handshake refactor). > > 3. HTTP (which is the target application of QUICv1) already has a way > to handle replay attacks (425 Too Early). Most if not all server > operators will deploy that regardless, because we need it to support > 0-RTT in TLS 1.3. I do not think we need a different mechanism for > HTTP/3. My preference goes to using the same mechanism in all HTTP > versions to avoid confusion among the users. I might expand the > argument that this would be the case not only for HTTP but for any > protocol that might run on TLS-over-TCP and/or QUIC. > > 4. The design introduces burden to certain HTTP-QUIC stacks. > Currently, it is possible to mitigate replay attacks by > pattern-matching the HTTP method / URI to see if a request needs to be > delayed until receiving the proof of non-replay. The proposed approach > mandates the stacks to deploy a hash-table-based replay detection, > which IMO is rather costly, considering the fact that most GET > requests are idempotent and therefore replay-resistant. > > To summarize, the proposal seems like a gratuitous change considering > the state of HTTP and QUIC v1. > > 2019=E5=B9=B42=E6=9C=888=E6=97=A5(=E9=87=91) 0:00 Mikkel Fahn=C3=B8e J=C3= =B8rgensen : > > > > Well, yes, but I already made my point. > > New thread here in case anyone wants to contest or support this proposal. > > > > I=E2=80=99m actually not suggestion this just make it easier for an ope= rator to achieve single use, I am suggesting to require operators to honor it, otherwise application developers are still left guessing, although this belongs to the class of things that cannot easily be enforced. > > > > On 7 February 2019 at 14.49.56, Ian Swett (ianswett@google.com) wrote: > > > > Mikkel, are you suggesting a connection ID be paired with a NewSessionTicket or Token for the purposes of resumption to make it easier for a server operator to prevent using the same NST or Token multiple times? > > > > If so, this thread has gone extraordinarily off the original topic of what frames to allow in 0RTT, so if you want to discuss that further, please start a new thread. > > > > On Thu, Feb 7, 2019 at 1:45 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < mikkelfj@gmail.com> wrote: > >> > >> Yes, I forgot the 0-RTT token is called a ticket. The fact that it is encrypted does not change the general similarity to Retry if we assume retry tokens are created in safe manner. Both can be replayed and both can have non-forgeable timestamps.. > >> > >> What is different is that TLS 1.3 over TCP does not have a concept of Connection ID that it can use for routing, but Retry does. > >> > >> (Restating that currently Retry is not required, only recommended, to enforce single use, but analysis shows that it is feasible to require). > >> > >> The time limit is, in this context, needed to ensure you do not have to keep infinite state whereas for TLS in general it (I presume) has more to do with tracking, reducing the attack surface, but to an extend also to clean up state. > >> > >> By requiring that the 0-RTT NewSessionTicket is used with a CID that routes to a specific endpoint, or cluster of endpoints, that can synchronously verify non-reuse within the time limit, you can lift a complex burden from the application layer - at the cost of complexity in transport and cluster configuration. > >> > >> One reason not to do this is complexity - but it is still simpler that dumping this on the average application, and you are not forced to to do 0-RTT. > >> Another reason to not do this is that if you can=E2=80=99t control you= r routing tightly you need an internal lookup which adds latency. > >> > >> The application layer has a few advantages: One is that it might not care about replay (like GET hello/world), or it might have a convenient sync mechanism like a database query. But these are notoriously difficult to get right and fast at the same time. > >> > >> If you place the burden on transport, you loose the ability of cluster wide fast GET, but that might not be a big issue, since routing to a dedicated host will also work and on average it will level out. > >> > >> If the servers QUIC implementation is able and willing to share synchronized state (e.g. via Redis or Zookeeper, etcd, or custom built-in), you can take the complexity hit once and let applications piggyback on that, and if its not, you still have single server guarantees. > >> > >> I believe this is the only sane way to go about it. I really can=E2=80= =99t see 0-RTT being safe left to the average application developer (however smart) when under time pressure to deliver. > >> > >> Regardless of much work the transport does, an application should of course maintain its own integrity, and avoid double bookings etc. which can happy by other means as well, unless, of course, that would be a business strategy to do so. > >> > >> On 7 February 2019 at 03.06.37, Martin Thomson (mt@lowentropy.net) wrote: > >> > >> Hi Mikkel, are you talking about Retry? The token that is used for 0-RTT (that is, the session ticket) is encrypted. The (very) short-lived token that appears in a Retry packet is the only token-like thing that is exposed to the network. > >> > >> The point about servers tracking clients is already well-treated in the literature. (I can't remember if we have text in QUIC specifically, but it should be in TLS.) > >> > >> As for time-limiting, TLS 1.3 already provides measures that strictly limit the time that a 0-RTT can be replayed. Firstly, 0-RTT can only be retried within a week that the token is issued. More importantly, there is a field in the TLS handshake that limits the time over which the token can be replayed. There are some limitations because it relies on clients and servers having clocks that run at approximately the same speed and we have to make allowances for retransmissions, but the general guidance we have is that a 10 second window is what you get for replay. Of course, that is only one of the defenses. > >> > >> On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote= : > >> > I came to think about the recent discussion about interception of the > >> > replay token by a man on the side. > >> > Here it was pointed out that it would be practical to enforce single token > >> > use because > >> > > >> > 1. the retry to goes to server designated CID > >> > 2. the token can have a timestamp > >> > > >> > We could do the same with 0-RTT (I think) > >> > There has previously been discussions on the CID used in 0-RTT - whether it > >> > is the original random CID or a server designated. > >> > But if 0-RTT uses the same approach as single use retry tokens, then it > >> > should be practical to enforce no replay. > >> > Of course data centers can work around this if they care enough with the > >> > risks involved and moved to the application layer - so the draft could have > >> > an escape hatch for that. > >> > > >> > Such an enforcement would make the 0-RTT more short lived and at higher > >> > risk of being rejected, but I don=E2=80=99t think that is a major co= ncern. > >> > > >> > Also, 0-RTT tokens can allow servers to track anonymous end users, so > >> > limiting their life time is a good thing. Maybe more important than the > >> > discussion on migration linkability. > >> > > >> > Mikkel > >> > > >> > > >> > On 6 February 2019 at 09.41.16, Stephen Farrell ( stephen.farrell@cs.tcd.ie) > >> > wrote: > >> > > >> > > >> > piping in from the sidelines so I don't expect this to be found so > >> > convincing, however... > >> > > >> > On 06/02/2019 04:11, Martin Thomson wrote: > >> > > it would be a mistake to try to make decisions about 0-RTT safety in > >> > > the transport, when replay risks are an application-layer concern. > >> > I believe that is not true for some decisions. > >> > > >> > If the WG decide to disallow something that could cause an application > >> > layer concern then that will remove the need to do application layer > >> > analyses of replay/0-rtt for those cases. Given application devs will > >> > in general not do those analyses, disallowing as much as you can (of > >> > the risks arising from 0-rtt) in the transport seems safer to me. > >> > > >> > If you want to name a principle ISTM that 0-rtt is a quite like a > >> > dangerous implement, which seems better avoided as far as possible.. > >> > > >> > One question though - do we have any information about real world > >> > 0-rtt issues arising in http/tls1.3 or is it still too early? If we > >> > did have such information that may better inform this discussion. > >> > > >> > Cheers, > >> > S. > > > > -- > Kazuho Oku > --000000000000e411fa05815dcc74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Thanks for these ins= ights.

I think it wou= ld, as a minimum, be good to ensure the design is friendly towards single u= se tickets.
<= br>
There is = an open ticket on which DCID a 0-RTT uses.
https://github.com/quicwg/base-drafts/issues/2398

If 0-RTT could (optionall= y) use a longer server selected DCID than normal, that would make the desig= n possible even if not enforced - noting that it isn=E2=80=99t necessary fo= r the session ticket to know the CID.

As to the TLS discussion - TLS would have to make allowanc= es for load balancers that cannot be assumed to understand 0-RTT flow. I th= ink this is different for QUIC where CID routing must be assumed. That does= not mean that QUIC single instance 0-RTT doesn=E2=80=99t cause more proble= ms than is worthwhile, but dismissing it based on TLS observations alone is= probably premature.



On 8 February 20= 19 at 00.00.38, Martin Thomson (mt@low= entropy.net) wrote:

We had a similar debate in TLS. By my recollectio= n, the conclusion was that while there are distinct advantages in binding 0= -RTT resumption to a single instance, the practicalities (such as those tha= t Kazhuo lists here) are such that it was impractical for too many deployme= nts. As such, there is advice in TLS 1.3 about this (see Appendix E.5 and = Section 8), but none of that advice rises to the level of being mandatory. = In the end, if your server infrastructure can support this, or the rate of= successful 0-RTT acceptance is not reduced significantly by enabling this,= then all power to you.

On Fri, Feb 8, 2019, at 03:56, Kazuho Oku wrote:
> Hi,
> =20
> I think that the proposed approach works, and I think it's an
> interesting idea. However, I am not sure if I would prefer having
> this, at least in v1. The reasons are as follows:
> =20
> 1. The design requires CID-based routing to be stable for the life= time
> of the session ticket (7 days). I am not sure if all of us can ach= ieve
> that. Note that the CID encryption key (and therefore the stateles= s
> reset token key) needs to be stable for that amount of time.
> =20
> 2. The design requires the resumption CID to be bundled to the ses= sion
> ticket. That goes against our previous consensus to not introduce
> extensions in the session ticket (IIRC we discussed it during the
> handshake refactor).
> =20
> 3. HTTP (which is the target application of QUICv1) already has a = way
> to handle replay attacks (425 Too Early). Most if not all server
> operators will deploy that regardless, because we need it to suppo= rt
> 0-RTT in TLS 1.3. I do not think we need a different mechanism for
> HTTP/3. My preference goes to using the same mechanism in all HTTP
> versions to avoid confusion among the users. I might expand the
> argument that this would be the case not only for HTTP but for any
> protocol that might run on TLS-over-TCP and/or QUIC.
> =20
> 4. The design introduces burden to certain HTTP-QUIC stacks.
> Currently, it is possible to mitigate replay attacks by
> pattern-matching the HTTP method / URI to see if a request needs t= o be
> delayed until receiving the proof of non-replay. The proposed appr= oach
> mandates the stacks to deploy a hash-table-based replay detection,
> which IMO is rather costly, considering the fact that most GET
> requests are idempotent and therefore replay-resistant.
> =20
> To summarize, the proposal seems like a gratuitous change consider= ing
> the state of HTTP and QUIC v1.
> =20
> 2019=E5=B9=B42=E6=9C=888=E6=97=A5(=E9=87=91) 0:00 Mikkel Fahn=C3= =B8e J=C3=B8rgensen <mikkelfj@gmai= l.com>:
> >
> > Well, yes, but I already made my point.
> > New thread here in case anyone wants to contest or support th= is proposal.
> >
> > I=E2=80=99m actually not suggestion this just make it easier = for an operator to achieve single use, I am suggesting to require operators= to honor it, otherwise application developers are still left guessing, alt= hough this belongs to the class of things that cannot easily be enforced.
> >
> > On 7 February 2019 at 14.49.56, Ian Swett (ianswett@google.com) wrote:
> >
> > Mikkel, are you suggesting a connection ID be paired with a N= ewSessionTicket or Token for the purposes of resumption to make it easier f= or a server operator to prevent using the same NST or Token multiple times?
> >
> > If so, this thread has gone extraordinarily off the original = topic of what frames to allow in 0RTT, so if you want to discuss that furth= er, please start a new thread.
> >
> > On Thu, Feb 7, 2019 at 1:45 AM Mikkel Fahn=C3=B8e J=C3=B8rgen= sen <mikkelfj@gmail.com> wr= ote:
> >>
> >> Yes, I forgot the 0-RTT token is called a ticket. The fac= t that it is encrypted does not change the general similarity to Retry if w= e assume retry tokens are created in safe manner. Both can be replayed and = both can have non-forgeable timestamps..
> >>
> >> What is different is that TLS 1.3 over TCP does not have = a concept of Connection ID that it can use for routing, but Retry does.
> >>
> >> (Restating that currently Retry is not required, only rec= ommended, to enforce single use, but analysis shows that it is feasible to = require).
> >>
> >> The time limit is, in this context, needed to ensure you = do not have to keep infinite state whereas for TLS in general it (I presume= ) has more to do with tracking, reducing the attack surface, but to an exte= nd also to clean up state.
> >>
> >> By requiring that the 0-RTT NewSessionTicket is used with= a CID that routes to a specific endpoint, or cluster of endpoints, that ca= n synchronously verify non-reuse within the time limit, you can lift a comp= lex burden from the application layer - at the cost of complexity in transp= ort and cluster configuration.
> >>
> >> One reason not to do this is complexity - but it is still= simpler that dumping this on the average application, and you are not forc= ed to to do 0-RTT.
> >> Another reason to not do this is that if you can=E2=80=99= t control your routing tightly you need an internal lookup which adds laten= cy.
> >>
> >> The application layer has a few advantages: One is that i= t might not care about replay (like GET hello/world), or it might have a co= nvenient sync mechanism like a database query. But these are notoriously di= fficult to get right and fast at the same time.
> >>
> >> If you place the burden on transport, you loose the abili= ty of cluster wide fast GET, but that might not be a big issue, since routi= ng to a dedicated host will also work and on average it will level out.
> >>
> >> If the servers QUIC implementation is able and willing to= share synchronized state (e.g. via Redis or Zookeeper, etcd, or custom bui= lt-in), you can take the complexity hit once and let applications piggyback= on that, and if its not, you still have single server guarantees.
> >>
> >> I believe this is the only sane way to go about it. I rea= lly can=E2=80=99t see 0-RTT being safe left to the average application deve= loper (however smart) when under time pressure to deliver.
> >>
> >> Regardless of much work the transport does, an applicatio= n should of course maintain its own integrity, and avoid double bookings et= c. which can happy by other means as well, unless, of course, that would be= a business strategy to do so.
> >>
> >> On 7 February 2019 at 03.06.37, Martin Thomson (mt@lowentropy.net) wrote:
> >>
> >> Hi Mikkel, are you talking about Retry? The token that is= used for 0-RTT (that is, the session ticket) is encrypted. The (very) shor= t-lived token that appears in a Retry packet is the only token-like thing t= hat is exposed to the network.
> >>
> >> The point about servers tracking clients is already well-= treated in the literature. (I can't remember if we have text in QUIC sp= ecifically, but it should be in TLS.)
> >>
> >> As for time-limiting, TLS 1.3 already provides measures t= hat strictly limit the time that a 0-RTT can be replayed. Firstly, 0-RTT ca= n only be retried within a week that the token is issued. More importantly,= there is a field in the TLS handshake that limits the time over which the = token can be replayed. There are some limitations because it relies on clie= nts and servers having clocks that run at approximately the same speed and = we have to make allowances for retransmissions, but the general guidance we= have is that a 10 second window is what you get for replay. Of course, tha= t is only one of the defenses.
> >>
> >> On Wed, Feb 6, 2019, at 19:56, Mikkel Fahn=C3=B8e J=C3=B8= rgensen wrote:
> >> > I came to think about the recent discussion about in= terception of the
> >> > replay token by a man on the side.
> >> > Here it was pointed out that it would be practical t= o enforce single token
> >> > use because
> >> >
> >> > 1. the retry to goes to server designated CID
> >> > 2. the token can have a timestamp
> >> >
> >> > We could do the same with 0-RTT (I think)
> >> > There has previously been discussions on the CID use= d in 0-RTT - whether it
> >> > is the original random CID or a server designated.
> >> > But if 0-RTT uses the same approach as single use re= try tokens, then it
> >> > should be practical to enforce no replay.
> >> > Of course data centers can work around this if they = care enough with the
> >> > risks involved and moved to the application layer - = so the draft could have
> >> > an escape hatch for that.
> >> >
> >> > Such an enforcement would make the 0-RTT more short = lived and at higher
> >> > risk of being rejected, but I don=E2=80=99t think th= at is a major concern.
> >> >
> >> > Also, 0-RTT tokens can allow servers to track anonym= ous end users, so
> >> > limiting their life time is a good thing. Maybe more= important than the
> >> > discussion on migration linkability.
> >> >
> >> > Mikkel
> >> >
> >> >
> >> > On 6 February 2019 at 09.41.16, Stephen Farrell (stephen.farrell@cs.tcd.ie)
> >> > wrote:
> >> >
> >> >
> >> > piping in from the sidelines so I don't expect t= his to be found so
> >> > convincing, however...
> >> >
> >> > On 06/02/2019 04:11, Martin Thomson wrote:
> >> > > it would be a mistake to try to make decisions = about 0-RTT safety in
> >> > > the transport, when replay risks are an applica= tion-layer concern.
> >> > I believe that is not true for some decisions.
> >> >
> >> > If the WG decide to disallow something that could ca= use an application
> >> > layer concern then that will remove the need to do a= pplication layer
> >> > analyses of replay/0-rtt for those cases. Given appl= ication devs will
> >> > in general not do those analyses, disallowing as muc= h as you can (of
> >> > the risks arising from 0-rtt) in the transport seems= safer to me.
> >> >
> >> > If you want to name a principle ISTM that 0-rtt is a= quite like a
> >> > dangerous implement, which seems better avoided as f= ar as possible..
> >> >
> >> > One question though - do we have any information abo= ut real world
> >> > 0-rtt issues arising in http/tls1.3 or is it still t= oo early? If we
> >> > did have such information that may better inform thi= s discussion.
> >> >
> >> > Cheers,
> >> > S.
> =20
> =20
> =20
> -- =20
> Kazuho Oku
> =20

--000000000000e411fa05815dcc74-- From nobody Fri Feb 8 06:58:48 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20D12008F for ; Fri, 8 Feb 2019 06:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtlDAdCodCRI for ; Fri, 8 Feb 2019 06:58:34 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800E81228B7 for ; Fri, 8 Feb 2019 06:58:34 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id d15so3730340wmb.3 for ; Fri, 08 Feb 2019 06:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K7PmcJRT67OfOzYsfqa43gXUvzF9pbosGmgTWMNZAkk=; b=kuRqCzUw7bg+VrxAEqwnNfNteZwOpqSuWCNJxXgSfqWD8Aku569InsJlG6XNzI29qn DRx/xanjffAQXkKvULZdM94y6P4D7o8KRrjMIJGoi2fyqkockndtSb2pAfBzv2yMjGWf 9NeKj7j7XYQIr3GtwTY0KEKN0E3JpzJJam7yO9hXhWpj6qDwSjtrUGTiSvejOxy17F/2 i0MhleSc0tm6xrwTcP13vBZu4f3tbV/bF9Y9Yxr1Y4AHRMs7KUHLPr74ZCChw9xjtns0 EJf6HgOlQPjbgf8DQWUDSA6Tf+vIGDAVXjPXUfZLLhZ+JZpOT3gQkMpDXtIA7NjyhF4K NmPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K7PmcJRT67OfOzYsfqa43gXUvzF9pbosGmgTWMNZAkk=; b=P0XpJiOKGD5byS/vEtYpY9ADBP7iGGkpjybvOTmvbujQQbEem8XWTU9Wty5tQ/Bt5z jPAYTCDUtefbZFuzvCt3yxtGE3FJbA49hLZ0Z3rHbnOXEnDS7CzJ3oFon5FYIvDM7Uk8 n23P2g1qj6uGqaAksTVajRx4sp80x1IiwTSfIXNTHmXPoI8yHdENfmdIc7q35vrWEMS6 GsDr5oDy+hOJrQm9j4DL/IaGHVtcpBNoseh8NP4B1+DJSxZuyCQ2mONy0sZhsiVSmVes ohE6T352zktCiqsJkR44QXhsBIVeaiq5jba/Mpp5vdDijynw+KZhWHHhzArZe5oCZs4x O3yQ== X-Gm-Message-State: AHQUAuakwSdcTs1STDQkie+EYVhWtw9BEbEW0FPgcbxfVhYwZIow2tfC UcgOtEDeZc0/5/t/eZp8QHGmq8FEHhvB1PPzqXlHTGUBeBA= X-Google-Smtp-Source: AHgI3IZsUQ422uEzg4T2MvQMitLHEb1FDJ9JJkTGoajkLlZwoTVi4J9z/Z1aypdNqa2lxwjcV/UpY+MzRURbDe9mQRk= X-Received: by 2002:a1c:f312:: with SMTP id q18mr5475891wmq.106.1549637912238; Fri, 08 Feb 2019 06:58:32 -0800 (PST) MIME-Version: 1.0 References: <1549594501.881364.1653399392.63222EBD@webmail.messagingengine.com> In-Reply-To: <1549594501.881364.1653399392.63222EBD@webmail.messagingengine.com> From: Ian Swett Date: Fri, 8 Feb 2019 09:58:19 -0500 Message-ID: Subject: Re: Limiting connection ID supply To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004ae9c7058163313b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 14:58:38 -0000 --0000000000004ae9c7058163313b Content-Type: text/plain; charset="UTF-8" In the theme of "servers are going to do what they need to do", this text acknowledges the reality that CIDs may be a limited resource and servers will want to limit how many they provide to a peer. Merge it! On Thu, Feb 7, 2019 at 9:55 PM Martin Thomson wrote: > https://github.com/quicwg/base-drafts/issues/2436 includes a simple > issue: if someone starts retiring connection IDs aggressively, they can > exhaust your supply. Kazuho suggests that we allow endpoints to limit the > number of connection IDs they supply. > > There is a PR: https://github.com/quicwg/base-drafts/pull/2428 > > I don't think that this sort of rate limiting is generally advisable, > because of the risk that this would discourage the use of new connection > IDs. Long connection IDs are a better solution, but those are inefficient > and I don't want to get into a situation where connection ID rotation on > shorter connection IDs is infeasible. I think that the proposed text is > worded carefully enough and strikes a good balance between these concerns. > I would like to merge this one. > > --0000000000004ae9c7058163313b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the theme of "servers are going t= o do what they need to do", this text acknowledges the reality that CI= Ds may be a limited resource and servers will want to limit how many they p= rovide to a peer.

Merge it!

On Thu, = Feb 7, 2019 at 9:55 PM Martin Thomson <mt@lowentropy.net> wrote:
https://github.com/quicwg/base= -drafts/issues/2436 includes a simple issue: if someone starts retiring= connection IDs aggressively, they can exhaust your supply.=C2=A0 Kazuho su= ggests that we allow endpoints to limit the number of connection IDs they s= upply.

There is a PR: https://github.com/quicwg/base-drafts/= pull/2428

I don't think that this sort of rate limiting is generally advisable, b= ecause of the risk that this would discourage the use of new connection IDs= .=C2=A0 Long connection IDs are a better solution, but those are inefficien= t and I don't want to get into a situation where connection ID rotation= on shorter connection IDs is infeasible.=C2=A0 I think that the proposed t= ext is worded carefully enough and strikes a good balance between these con= cerns.=C2=A0 I would like to merge this one.

--0000000000004ae9c7058163313b-- From nobody Fri Feb 8 08:23:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A9012867A for ; Fri, 8 Feb 2019 08:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uH3nxdnJZnE for ; Fri, 8 Feb 2019 08:23:07 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 777A4124BAA for ; Fri, 8 Feb 2019 08:23:07 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id c8so4211587wrs.4 for ; Fri, 08 Feb 2019 08:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HNKT/YftDQck2D2D+z55e+X0ql0Nt+ooPzSJamd1fp4=; b=i7Fe10zyUiyGz3D5YzB7LH3Ilgy9xVA5TI5sgQ4fv6FI8W33UWY/zBuUuQZI1AWaaF +wvvw1hbXzsds7ImBoyZACC9J0oQ9PiwhkrzNDv0IYQ1rU20KDqZ5FqYqLYKY25o48vN kU5KlWI4YSDcKhcbQo8L+AgBm4+SXPkm1VmAeTOdDurxoWGFHzcMXZPIOgEcFAEaRbbI 2Gs9pFRmMZwvUS4vN176yftkHmaQm/NbwJfgnNoh5+YB0v43wMPhvd7H0l2xW6A52NjW kxnzYjEwms+K1pgfd3t0BZFyygdC2B/+jGzaKXnA5Ci2F8xZjVGTYjEkZwrO0CgZg+Rh iZaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HNKT/YftDQck2D2D+z55e+X0ql0Nt+ooPzSJamd1fp4=; b=psUGwdNGW9aSotuNGiRsC0v0JR0thngwtW+0UP3ulua77eVIVeaUwETPzwOA24Ah1u JHNVHpPP/JKHgINZDmE0OqXKyAJa3w2DsT03kEJEi+ff20Kh7++JImFYReY+W+Rmr8Mo W2KwDbbhNWkr4PpEb/bnLqvGv1Ig2dycb2P8J3OuJaQ2qJ90cRyvrb0gmF6KuV3rpt1v c18aYPRS/r+ofoXx0DzwxL1BTHbekD5DHe2Kqdd1rSU4xeMXpkvSQNaUWnWoMu8Z6CDc f4t+oBWA6S9rl/V/f0TqirYiRxbKuLuCWhul171iwub4+9Ay9+EJfND+tfXkjGxsng3m 2RrA== X-Gm-Message-State: AHQUAubmYAWDbLilISjzwEWq34dG/3RokSv/2ng2cO6qyIxosAu16sEX ROrXX+xitGFjU1GjsJF+oG4qdBjAhfcp6Srqyodnsw== X-Google-Smtp-Source: AHgI3IYJoT32rmxtXDdh07/HEhTcenLvmx5EKsf38Urvoy5VQ2kBWKpvERV9ueu5nICu2NoG1Sl+X0zx2ZDtAcqYtz8= X-Received: by 2002:adf:c711:: with SMTP id k17mr16720632wrg.197.1549642985041; Fri, 08 Feb 2019 08:23:05 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <1549593981.877482.1653392768.203A9C0B@webmail.messagingengine.com> In-Reply-To: <1549593981.877482.1653392768.203A9C0B@webmail.messagingengine.com> From: Ian Swett Date: Fri, 8 Feb 2019 11:22:53 -0500 Message-ID: Subject: Re: New path => new connection ID, right? To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000a7a6660581645f63" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 16:23:10 -0000 --000000000000a7a6660581645f63 Content-Type: text/plain; charset="UTF-8" It also adds "Similarly, an endpoint MUST NOT migrate if its peer supplies a zero-length connection ID". In a P2P use case where there's only one connection, this precludes migration in a case where it would otherwise work, so I don't see adding this restriction as being helpful. On Thu, Feb 7, 2019 at 9:46 PM Martin Thomson wrote: > In an attempt to close the loop, I've updated > https://github.com/quicwg/base-drafts/pull/2414 > > The controversial bits are apparently: > > * if you intentionally move to a new path, then you have to use a > connection ID that hasn't been used on any other path > > * if you don't have a new connection ID (which also includes zero-length > connection IDs in the latest change), then you can't use a new path > > I believe that both are editorial changes, but the volume of discussion on > the thread indicates that some people would like to see the issue > reopened. In the interests of forward progress, I would like the chairs to > make an assessment. > > Note that this PR doesn't include the fix to > https://github.com/quicwg/base-drafts/issues/2342, which reviewers will > no doubt trip over in the process of reviewing this change. > > On Tue, Feb 5, 2019, at 10:15, Martin Thomson wrote: > > I thought that we had agreed that an endpoint that intentionally > > migrates has to use a new connection ID on the new path. But I couldn't > > find any "MUST" in the spec that said that. > > > > On the off chance that this wasn't just a mistake and there was some > > good reason not to mandate this, I'm bringing the discussion here. > > > > I've opened a design issue: > > https://github.com/quicwg/base-drafts/issues/2413 > > > > The change I'm proposing is here: > > > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995236dda960b4cdff49e36f > > --000000000000a7a6660581645f63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It also adds "Similarly, an endpoint= MUST NOT migrate if its peer supplies a zero-length connection ID".

In a P2P use case where there's onl= y one connection, this precludes migration in a case where it would otherwi= se work, so I don't see adding this restriction as being helpful.
=

= On Thu, Feb 7, 2019 at 9:46 PM Martin Thomson <mt@lowentropy.net> wrote:
In an attempt to close the loop, I've upda= ted https://github.com/quicwg/base-drafts/pull/2414

The controversial bits are apparently:

* if you intentionally move to a new path, then you have to use a connectio= n ID that hasn't been used on any other path

* if you don't have a new connection ID (which also includes zero-lengt= h connection IDs in the latest change), then you can't use a new path
I believe that both are editorial changes, but the volume of discussion on = the thread indicates that some people would like to see the issue reopened.= =C2=A0 In the interests of forward progress, I would like the chairs to mak= e an assessment.

Note that this PR doesn't include the fix to ht= tps://github.com/quicwg/base-drafts/issues/2342, which reviewers will n= o doubt trip over in the process of reviewing this change.

On Tue, Feb 5, 2019, at 10:15, Martin Thomson wrote:
> I thought that we had agreed that an endpoint that intentionally
> migrates has to use a new connection ID on the new path.=C2=A0 But I c= ouldn't
> find any "MUST" in the spec that said that.
>
> On the off chance that this wasn't just a mistake and there was so= me
> good reason not to mandate this, I'm bringing the discussion here.=
>
> I've opened a design issue:
> https://github.com/quicwg/base-drafts/issues/2= 413
>
> The change I'm proposing is here:
> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a399= 5236dda960b4cdff49e36f

--000000000000a7a6660581645f63-- From nobody Fri Feb 8 09:44:51 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1BD1294FA for ; Fri, 8 Feb 2019 09:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF5qKoVZMUyr for ; Fri, 8 Feb 2019 09:44:47 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 2C01F130DEA for ; Fri, 8 Feb 2019 09:44:47 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id c9so10947206itj.1 for ; Fri, 08 Feb 2019 09:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j146UpuwKQIJ4mdbeTjcrQxV8C4ClwA1YeohEkEZvEs=; b=JNmypNpqXPCRq/I9W0naEQkGytzzykxq4DLq/qHjswPmlro39ZeGimrWa4oa5Fgdqg faXNV3Ud6IKfxWmwWY5LB6vcLPkKDaWwq3jf0rTVkqzRfpUME4qzZQl/0V3PhZYtjq4X nPxLJ51AjhTUBSnj+487oM1em7xHlm+OgudcOLTvhTjq4Areyf2bJgi8inMZdSB/ssAU bhCjgHNo3dBw3r3Mm+4nnSfM//yKS+L08mxbySs8I0kyqKzsMKWVM0RvVDXGCxpzrBuP 85kIEDfcjWqHS94Wvaa8vx5uPPa9Xny6O1UPOc9bbVh7KpFjKv3itJZuNTNYveaVpJhH TmDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j146UpuwKQIJ4mdbeTjcrQxV8C4ClwA1YeohEkEZvEs=; b=jZpir1wZkgE4TSOfTx73aUIHoJm296qUkT00uAkM3N0imd4U6yYJstUHWrkpKCJnpn qh5SvGr83Oi/pf6n9mJGDdMOclpW3magFHvqnErUmc0ap8vCCnAaIKrgpjxfeJN8IyPo 2UkoPBTFFB7C0fJumc8MNLsMd5m0stm8CADbNc23NcT6aRu7xkYa7RW4WBSmTZXDZyJe 0H8OJjUziFaCJbM/7UJDA+e5I5mnV8j5n2IRmCNcJT6Kyc2eYPz0PEIi9ljtSXjA/1hx ebiMvz6ENNU+rIiVzGOvhRQoCu2FXS0rPujuGViJ7ziqTt4t+iGuztHKwwG0v8hIZuGJ o8Ew== X-Gm-Message-State: AHQUAuZQ3rYqCZY5YC/2QeZ1Q3QbUZWRjxqpqyq6GZsQYayKQwVMhTDH RCNXETFXMSLGlXqYVYtaKgFisXOnj6tqFFhnrNeX8vKq X-Google-Smtp-Source: AHgI3IbSbFlgUalCa0T1yUOpLdO1NVav2L28TPGjkOVwAccBxu8Tz6c6tTupUCg1XkLm4M7TU8Zgw8h3erlLbxyvdTU= X-Received: by 2002:a02:2248:: with SMTP id o69mr5555133jao.140.1549647886010; Fri, 08 Feb 2019 09:44:46 -0800 (PST) MIME-Version: 1.0 References: <1549594501.881364.1653399392.63222EBD@webmail.messagingengine.com> In-Reply-To: <1549594501.881364.1653399392.63222EBD@webmail.messagingengine.com> From: Ted Hardie Date: Fri, 8 Feb 2019 09:44:18 -0800 Message-ID: Subject: Re: Limiting connection ID supply To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c5cd0c058165838b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 17:44:50 -0000 --000000000000c5cd0c058165838b Content-Type: text/plain; charset="UTF-8" On Thu, Feb 7, 2019 at 6:55 PM Martin Thomson wrote: > https://github.com/quicwg/base-drafts/issues/2436 includes a simple > issue: if someone starts retiring connection IDs aggressively, they can > exhaust your supply. Kazuho suggests that we allow endpoints to limit the > number of connection IDs they supply. > > There is a PR: https://github.com/quicwg/base-drafts/pull/2428 > > I think this idea is generally good, but I have a slight concern that the full text reads as if the connection-IDs should be provided just before migration. That's largely because the text above it has a just-in time flavor: > The endpoint SHOULD do this by supplying a new connection ID when a > connection ID is retired by its peer or when the endpoint receives a packet > with a previously unused connection ID, though it MAY limit the frequency > or the total number of connection IDs issued for each connection to avoid > the risk of running out of connection IDs (see {{reset-token}}). > > Endpoints that initiate migration and require non-zero-length connection > IDs SHOULD provide their peers with new connection IDs before migration, or > risk the peer closing the connection. > I'd suggest a slight adjustment, to link back to the minimum requirement: "Endpoints that initiate migration and require non-zero-length connection IDs SHOULD ensure that the pool of connection IDs available to their peers allows them to use a new connection ID on migration, as the peer will close the connection if the pool is exhausted." Does that change work for you? Ted > I don't think that this sort of rate limiting is generally advisable, > because of the risk that this would discourage the use of new connection > IDs. Long connection IDs are a better solution, but those are inefficient > and I don't want to get into a situation where connection ID rotation on > shorter connection IDs is infeasible. I think that the proposed text is > worded carefully enough and strikes a good balance between these concerns. > I would like to merge this one. > > --000000000000c5cd0c058165838b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 7, 2019 at 6:55 PM Martin Tho= mson <mt@lowentropy.net> wro= te:
https://github.com/quicwg/base-draft= s/issues/2436 includes a simple issue: if someone starts retiring conne= ction IDs aggressively, they can exhaust your supply.=C2=A0 Kazuho suggests= that we allow endpoints to limit the number of connection IDs they supply.=

There is a PR: https://github.com/quicwg/base-drafts/= pull/2428

I think this idea is generally good, but I have a sli= ght concern that the full text reads as if the connection-IDs should be pro= vided just before migration.=C2=A0 That's largely because the text abov= e it has a just-in time flavor:

The endpoint SHOULD do this by supplying a new connecti= on ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID, though it MAY limit the freq= uency or the total number of connection IDs issued for each connection to avoid t= he risk of running out of connection IDs (see {{reset-token}}).

Endpoints that initiate migration and require non-zero-length connection= IDs SHOULD provide their peers with new connection IDs before migration, or ris= k the peer closing the connection.

I'd suggest a s= light adjustment, to link back to the minimum requirement:

"Endpoints that initiate migration and require non-zero-lengt= h connection IDs SHOULD ensure that the pool of connection IDs available to their peers allo= ws them to use a new connection ID on migration, as the peer will close the connection if the pool is exhausted."
Does that change work for you?

Ted

=

=C2=A0
I don't think that this sort of rate limiting is generally advisable, b= ecause of the risk that this would discourage the use of new connection IDs= .=C2=A0 Long connection IDs are a better solution, but those are inefficien= t and I don't want to get into a situation where connection ID rotation= on shorter connection IDs is infeasible.=C2=A0 I think that the proposed t= ext is worded carefully enough and strikes a good balance between these con= cerns.=C2=A0 I would like to merge this one.

--000000000000c5cd0c058165838b-- From nobody Fri Feb 8 10:38:31 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEE91277CC for ; Fri, 8 Feb 2019 10:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05xNiCfZlnA8 for ; Fri, 8 Feb 2019 10:38:25 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780103.outbound.protection.outlook.com [40.107.78.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA33B1228B7 for ; Fri, 8 Feb 2019 10:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nWiczZjwV/oXYMHsXgGULQEEJbD9gz5RHChuazrRYqM=; b=dZFSOvejcuJNERSnmnqWt/U1i3SMAOGQXyaB2R1t+Bd6FiIYaDebSxaB8EQQnzwMpZ0qy3XKM2BPW7IwlSkLlubzPrc5q1eXh74M+nl61X0jDlwUFKtuL28J1Ox4+uwi7mzeORZJZ5UDhMO8Be/fdNa6AylQBxSyvlRVXzniNGQ= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0903.namprd22.prod.outlook.com (10.171.167.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Fri, 8 Feb 2019 18:38:22 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2%4]) with mapi id 15.20.1558.021; Fri, 8 Feb 2019 18:38:22 +0000 From: Mike Bishop To: Ian Swett , Martin Thomson CC: IETF QUIC WG Subject: RE: New path => new connection ID, right? Thread-Topic: New path => new connection ID, right? Thread-Index: AQHUvN+Hdo9IVj+onk2j/wqF4V0HsaXVNzOAgADkI4CAACUcwA== Date: Fri, 8 Feb 2019 18:38:22 +0000 Message-ID: References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <1549593981.877482.1653392768.203A9C0B@webmail.messagingengine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:b489:3060:f721:40e3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR22MB0903; 6:8ugkUGLOJL1eFGmsGcVRj0Pnd42lVSFmrbcjwshHwxQXeyxGZibnWsJgzeFrlwGNIEBGVLlzONFODgLh/55cODW7LeSHCqIw8nvuAE+nWT/nr9HkG90jyIpYkr2tF+0NHZ5VvQ0OjydVuGMWYgBm4vR3g1w4RXcY5ANXQbMg7x7XgG9ly2r8Ygmg3WFUhMY6H/5TVmD70yEAVN4nTdM5GK2B6lxrLNxD3K/8/Jzu0+ix+UJIv7oGxf9yqw8hRpWERyE3+B+3s6f+M4NA1cSqeI9Y2F38JHmig2UM3OtRcTnELOOTTIXrigXIhDMv/9VBUTo0gtyToCp2UA9Rv3IXyxJOLT1QyZBkgau/KaqJQvcbZPdPl6f3dCZy6aeffp0iNGVAwl7zB698ynl0s6Lj+CbxWKdqK6/RJVyNMQDK4qHaOUy4EI95+25r8sViiO0rIVfN6VRnTs7itqqexLLscw==; 5:Et6ZNPOemxdcbUa+Lon9z+225CewNC5CqfSmKefGBczVKjS4BWWYuCuD0psv17F5NfPEdIlnMLhWVb9Amh5bN3AHN2y1AbbkZ1pTHmA2aM70rdqwU8JiUJwzjOCx58yXqm5BElUgRT9SAdvx/47HP3wU8ayi6wf02rDSTM2ZRPJEM2XaigPCLxH0iueQZD/d9Mlv5JREocyVqL5PgTVsag==; 7:KH0FCbRyC2uHKmJcGGmiKaquBb5u2OtK0NZDd8t94Ga4T62DDc+1qF+Utddb01HglujY6wee53MXAlxAoUF5QZydXD4U8GaZi6JWtk8hfpe8foEGfSqbUfXmwLEL4158LMI9dx4/mMZK80Q1GAcefw== x-ms-office365-filtering-correlation-id: b1be49ba-0ef9-4024-3352-08d68df49ac7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0903; x-ms-traffictypediagnostic: CY4PR22MB0903: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 094213BFEA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(376002)(136003)(39830400003)(189003)(199004)(229853002)(790700001)(2906002)(102836004)(53546011)(6506007)(25786009)(7696005)(74316002)(7736002)(81156014)(4326008)(6246003)(53936002)(99286004)(6116002)(81166006)(76176011)(966005)(8676002)(8936002)(86362001)(11346002)(486006)(476003)(236005)(106356001)(55016002)(9686003)(105586002)(54896002)(6306002)(110136005)(14444005)(14454004)(71200400001)(71190400001)(446003)(256004)(74482002)(316002)(186003)(6436002)(68736007)(606006)(33656002)(46003)(97736004)(508600001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0903; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EVEp/HtQxewB4iGESKfSIcx7zGZ5373VDo0wxpxRlaopVq/L4rqZtyBb/VBXWbLkgumL7bMYp/wKjo08iTfOvCPruP/5zZQXsBOPQUCW+U9YGH5bv8f+0xM28GM5L9GLqTLoMCc7fw3NoSvMvSobYDD/iDXveAp6mGmSNno8eoT0JFZAPSTEHFdbBGKCpMWVR/3wEQettAMkaX+zL7O7wVDfMIxRRqyZPg1T6DVXhEffXjtBKD3Qr5ri4CCNyD3JSmCwzgYH4m8McMSPs/HNTKG56dWvHrDpsc0wDmnij3GUXR0NaSDFzS9nMmYRkFIOEbV3Mrwnh6rMZxsYxo9K5nhD7jVa39fLkCFX0jRN9zNrSBx8IKJx/goDv++0D/H4Hrk10NGmVK6hgpNx+YRQCCfxNau9uMWrln2Oefl6TYU= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983001DC1DDFAD5A8FD23C5DA690CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: b1be49ba-0ef9-4024-3352-08d68df49ac7 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2019 18:38:22.6155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0903 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 18:38:29 -0000 --_000_CY4PR22MB0983001DC1DDFAD5A8FD23C5DA690CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgbm90IGEgY2hhbmdlIOKAkyB0aGUgcmVxdWlyZW1lbnQgaXMgYWxyZWFkeSBpbiB0 aGUgc3BlYzoNCkFuIGVuZHBvaW50IHdob3NlIHBlZXIgaGFzIHNlbGVjdGVkIGEgemVyby1sZW5n dGggY29ubmVjdGlvbiBJRCBNVVNUIGNvbnRpbnVlIHRvIHVzZSBhIHplcm8tbGVuZ3RoIGNvbm5l Y3Rpb24gSUQgZm9yIHRoZSBsaWZldGltZSBvZiB0aGUgY29ubmVjdGlvbiBhbmQgTVVTVCBOT1Qg c2VuZCBwYWNrZXRzIGZyb20gYW55IG90aGVyIGxvY2FsIGFkZHJlc3MuDQoNCklmIHdlIHdhbnQg dG8gY2hhbmdlIHRoaXMgcmVzdHJpY3Rpb24sIGxldOKAmXMgZGlzY3VzcyB0aGF0IGFzIGEgc2Vw YXJhdGUgaXNzdWUsIHBsZWFzZS4gIChJ4oCZbSBub3QgaW4gZmF2b3Igb2YgY2hhbmdpbmcgaXQs IGJlY2F1c2UgaW4gdGhlIGdlbmVyYWwgY2FzZSBpdCByZXF1aXJlcyB0cmlhbCBkZWNyeXB0aW9u LiAgWW914oCZcmUgY29ycmVjdCB0aGF0IGluIHRoZSBzcGVjaWFsIGNhc2Ugb2YgdXNpbmcgYSB1 bmlxdWUgbG9jYWwgcG9ydCBwZXIgY29ubmVjdGlvbiB0aGVyZSBtaWdodCBiZSBzb21lIGxlZXdh eS4pDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIElh biBTd2V0dA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSA4LCAyMDE5IDg6MjMgQU0NClRvOiBNYXJ0 aW4gVGhvbXNvbiA8bXRAbG93ZW50cm9weS5uZXQ+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGll dGYub3JnPg0KU3ViamVjdDogUmU6IE5ldyBwYXRoID0+IG5ldyBjb25uZWN0aW9uIElELCByaWdo dD8NCg0KSXQgYWxzbyBhZGRzICJTaW1pbGFybHksIGFuIGVuZHBvaW50IE1VU1QgTk9UIG1pZ3Jh dGUgaWYgaXRzIHBlZXIgc3VwcGxpZXMgYSB6ZXJvLWxlbmd0aCBjb25uZWN0aW9uIElEIi4NCg0K SW4gYSBQMlAgdXNlIGNhc2Ugd2hlcmUgdGhlcmUncyBvbmx5IG9uZSBjb25uZWN0aW9uLCB0aGlz IHByZWNsdWRlcyBtaWdyYXRpb24gaW4gYSBjYXNlIHdoZXJlIGl0IHdvdWxkIG90aGVyd2lzZSB3 b3JrLCBzbyBJIGRvbid0IHNlZSBhZGRpbmcgdGhpcyByZXN0cmljdGlvbiBhcyBiZWluZyBoZWxw ZnVsLg0KDQpPbiBUaHUsIEZlYiA3LCAyMDE5IGF0IDk6NDYgUE0gTWFydGluIFRob21zb24gPG10 QGxvd2VudHJvcHkubmV0PG1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldD4+IHdyb3RlOg0KSW4gYW4g YXR0ZW1wdCB0byBjbG9zZSB0aGUgbG9vcCwgSSd2ZSB1cGRhdGVkIGh0dHBzOi8vZ2l0aHViLmNv bS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8yNDE0DQoNClRoZSBjb250cm92ZXJzaWFsIGJpdHMg YXJlIGFwcGFyZW50bHk6DQoNCiogaWYgeW91IGludGVudGlvbmFsbHkgbW92ZSB0byBhIG5ldyBw YXRoLCB0aGVuIHlvdSBoYXZlIHRvIHVzZSBhIGNvbm5lY3Rpb24gSUQgdGhhdCBoYXNuJ3QgYmVl biB1c2VkIG9uIGFueSBvdGhlciBwYXRoDQoNCiogaWYgeW91IGRvbid0IGhhdmUgYSBuZXcgY29u bmVjdGlvbiBJRCAod2hpY2ggYWxzbyBpbmNsdWRlcyB6ZXJvLWxlbmd0aCBjb25uZWN0aW9uIElE cyBpbiB0aGUgbGF0ZXN0IGNoYW5nZSksIHRoZW4geW91IGNhbid0IHVzZSBhIG5ldyBwYXRoDQoN CkkgYmVsaWV2ZSB0aGF0IGJvdGggYXJlIGVkaXRvcmlhbCBjaGFuZ2VzLCBidXQgdGhlIHZvbHVt ZSBvZiBkaXNjdXNzaW9uIG9uIHRoZSB0aHJlYWQgaW5kaWNhdGVzIHRoYXQgc29tZSBwZW9wbGUg d291bGQgbGlrZSB0byBzZWUgdGhlIGlzc3VlIHJlb3BlbmVkLiAgSW4gdGhlIGludGVyZXN0cyBv ZiBmb3J3YXJkIHByb2dyZXNzLCBJIHdvdWxkIGxpa2UgdGhlIGNoYWlycyB0byBtYWtlIGFuIGFz c2Vzc21lbnQuDQoNCk5vdGUgdGhhdCB0aGlzIFBSIGRvZXNuJ3QgaW5jbHVkZSB0aGUgZml4IHRv IGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzIzNDIsIHdoaWNo IHJldmlld2VycyB3aWxsIG5vIGRvdWJ0IHRyaXAgb3ZlciBpbiB0aGUgcHJvY2VzcyBvZiByZXZp ZXdpbmcgdGhpcyBjaGFuZ2UuDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTksIGF0IDEwOjE1LCBNYXJ0 aW4gVGhvbXNvbiB3cm90ZToNCj4gSSB0aG91Z2h0IHRoYXQgd2UgaGFkIGFncmVlZCB0aGF0IGFu IGVuZHBvaW50IHRoYXQgaW50ZW50aW9uYWxseQ0KPiBtaWdyYXRlcyBoYXMgdG8gdXNlIGEgbmV3 IGNvbm5lY3Rpb24gSUQgb24gdGhlIG5ldyBwYXRoLiAgQnV0IEkgY291bGRuJ3QNCj4gZmluZCBh bnkgIk1VU1QiIGluIHRoZSBzcGVjIHRoYXQgc2FpZCB0aGF0Lg0KPg0KPiBPbiB0aGUgb2ZmIGNo YW5jZSB0aGF0IHRoaXMgd2Fzbid0IGp1c3QgYSBtaXN0YWtlIGFuZCB0aGVyZSB3YXMgc29tZQ0K PiBnb29kIHJlYXNvbiBub3QgdG8gbWFuZGF0ZSB0aGlzLCBJJ20gYnJpbmdpbmcgdGhlIGRpc2N1 c3Npb24gaGVyZS4NCj4NCj4gSSd2ZSBvcGVuZWQgYSBkZXNpZ24gaXNzdWU6DQo+IGh0dHBzOi8v Z2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzI0MTMNCj4NCj4gVGhlIGNoYW5n ZSBJJ20gcHJvcG9zaW5nIGlzIGhlcmU6DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFz ZS1kcmFmdHMvcHVsbC8yNDE0L2NvbW1pdHMvMTM2OThjYmUzMTE5MjJhMzk5NTIzNmRkYTk2MGI0 Y2RmZjQ5ZTM2Zg0K --_000_CY4PR22MB0983001DC1DDFAD5A8FD23C5DA690CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdOKAmXMgbm90 IGEgY2hhbmdlIOKAkyB0aGUgcmVxdWlyZW1lbnQgaXMgYWxyZWFkeSBpbiB0aGUgc3BlYzo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj5BbiBlbmRwb2ludCB3aG9zZSBwZWVyIGhhcyBz ZWxlY3RlZCBhIHplcm8tbGVuZ3RoIGNvbm5lY3Rpb24gSUQgTVVTVCBjb250aW51ZSB0byB1c2Ug YSB6ZXJvLWxlbmd0aCBjb25uZWN0aW9uIElEIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhlDQogY29u bmVjdGlvbiA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxs b3ciPmFuZCBNVVNUIE5PVCBzZW5kIHBhY2tldHMgZnJvbSBhbnkgb3RoZXIgbG9jYWwgYWRkcmVz cy48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSB3YW50IHRvIGNo YW5nZSB0aGlzIHJlc3RyaWN0aW9uLCBsZXTigJlzIGRpc2N1c3MgdGhhdCBhcyBhIHNlcGFyYXRl IGlzc3VlLCBwbGVhc2UuJm5ic3A7IChJ4oCZbSBub3QgaW4gZmF2b3Igb2YgY2hhbmdpbmcgaXQs IGJlY2F1c2UgaW4gdGhlIGdlbmVyYWwgY2FzZSBpdCByZXF1aXJlcyB0cmlhbCBkZWNyeXB0aW9u LiZuYnNwOyBZb3XigJlyZSBjb3JyZWN0IHRoYXQgaW4gdGhlIHNwZWNpYWwgY2FzZSBvZiB1c2lu ZyBhIHVuaXF1ZQ0KIGxvY2FsIHBvcnQgcGVyIGNvbm5lY3Rpb24gdGhlcmUgbWlnaHQgYmUgc29t ZSBsZWV3YXkuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAmbHQ7 cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KSWFuIFN3ZXR0 PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgOCwgMjAxOSA4OjIzIEFNPGJyPg0K PGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBOZXcgcGF0aCA9Jmd0OyBuZXcgY29ubmVjdGlvbiBJRCwgcmlnaHQ/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgYWxzbyBhZGRzICZxdW90O1Np bWlsYXJseSwgYW4gZW5kcG9pbnQgTVVTVCBOT1QgbWlncmF0ZSBpZiBpdHMgcGVlciBzdXBwbGll cyBhIHplcm8tbGVuZ3RoIGNvbm5lY3Rpb24gSUQmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGEgUDJQIHVzZSBjYXNlIHdoZXJl IHRoZXJlJ3Mgb25seSBvbmUgY29ubmVjdGlvbiwgdGhpcyBwcmVjbHVkZXMgbWlncmF0aW9uIGlu IGEgY2FzZSB3aGVyZSBpdCB3b3VsZCBvdGhlcndpc2Ugd29yaywgc28gSSBkb24ndCBzZWUgYWRk aW5nIHRoaXMgcmVzdHJpY3Rpb24gYXMgYmVpbmcgaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgNywgMjAxOSBh dCA5OjQ2IFBNIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bXRAbG93ZW50cm9w eS5uZXQiPm10QGxvd2VudHJvcHkubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPkluIGFuIGF0dGVtcHQgdG8gY2xvc2UgdGhlIGxvb3AsIEkndmUgdXBkYXRl ZA0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzI0 MTQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRz L3B1bGwvMjQxNDwvYT48YnI+DQo8YnI+DQpUaGUgY29udHJvdmVyc2lhbCBiaXRzIGFyZSBhcHBh cmVudGx5Ojxicj4NCjxicj4NCiogaWYgeW91IGludGVudGlvbmFsbHkgbW92ZSB0byBhIG5ldyBw YXRoLCB0aGVuIHlvdSBoYXZlIHRvIHVzZSBhIGNvbm5lY3Rpb24gSUQgdGhhdCBoYXNuJ3QgYmVl biB1c2VkIG9uIGFueSBvdGhlciBwYXRoPGJyPg0KPGJyPg0KKiBpZiB5b3UgZG9uJ3QgaGF2ZSBh IG5ldyBjb25uZWN0aW9uIElEICh3aGljaCBhbHNvIGluY2x1ZGVzIHplcm8tbGVuZ3RoIGNvbm5l Y3Rpb24gSURzIGluIHRoZSBsYXRlc3QgY2hhbmdlKSwgdGhlbiB5b3UgY2FuJ3QgdXNlIGEgbmV3 IHBhdGg8YnI+DQo8YnI+DQpJIGJlbGlldmUgdGhhdCBib3RoIGFyZSBlZGl0b3JpYWwgY2hhbmdl cywgYnV0IHRoZSB2b2x1bWUgb2YgZGlzY3Vzc2lvbiBvbiB0aGUgdGhyZWFkIGluZGljYXRlcyB0 aGF0IHNvbWUgcGVvcGxlIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBpc3N1ZSByZW9wZW5lZC4mbmJz cDsgSW4gdGhlIGludGVyZXN0cyBvZiBmb3J3YXJkIHByb2dyZXNzLCBJIHdvdWxkIGxpa2UgdGhl IGNoYWlycyB0byBtYWtlIGFuIGFzc2Vzc21lbnQuPGJyPg0KPGJyPg0KTm90ZSB0aGF0IHRoaXMg UFIgZG9lc24ndCBpbmNsdWRlIHRoZSBmaXggdG8gPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjM0MiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjM0MjwvYT4sIHdoaWNoIHJl dmlld2VycyB3aWxsIG5vIGRvdWJ0IHRyaXAgb3ZlciBpbiB0aGUgcHJvY2VzcyBvZiByZXZpZXdp bmcgdGhpcyBjaGFuZ2UuPGJyPg0KPGJyPg0KT24gVHVlLCBGZWIgNSwgMjAxOSwgYXQgMTA6MTUs IE1hcnRpbiBUaG9tc29uIHdyb3RlOjxicj4NCiZndDsgSSB0aG91Z2h0IHRoYXQgd2UgaGFkIGFn cmVlZCB0aGF0IGFuIGVuZHBvaW50IHRoYXQgaW50ZW50aW9uYWxseSA8YnI+DQomZ3Q7IG1pZ3Jh dGVzIGhhcyB0byB1c2UgYSBuZXcgY29ubmVjdGlvbiBJRCBvbiB0aGUgbmV3IHBhdGguJm5ic3A7 IEJ1dCBJIGNvdWxkbid0IDxicj4NCiZndDsgZmluZCBhbnkgJnF1b3Q7TVVTVCZxdW90OyBpbiB0 aGUgc3BlYyB0aGF0IHNhaWQgdGhhdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gdGhlIG9mZiBj aGFuY2UgdGhhdCB0aGlzIHdhc24ndCBqdXN0IGEgbWlzdGFrZSBhbmQgdGhlcmUgd2FzIHNvbWUg PGJyPg0KJmd0OyBnb29kIHJlYXNvbiBub3QgdG8gbWFuZGF0ZSB0aGlzLCBJJ20gYnJpbmdpbmcg dGhlIGRpc2N1c3Npb24gaGVyZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSd2ZSBvcGVuZWQgYSBk ZXNpZ24gaXNzdWU6PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dn L2Jhc2UtZHJhZnRzL2lzc3Vlcy8yNDEzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIu Y29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjQxMzwvYT48YnI+DQomZ3Q7IDxicj4NCiZn dDsgVGhlIGNoYW5nZSBJJ20gcHJvcG9zaW5nIGlzIGhlcmU6PGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjQxNC9jb21taXRzLzEz Njk4Y2JlMzExOTIyYTM5OTUyMzZkZGE5NjBiNGNkZmY0OWUzNmYiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8yNDE0L2NvbW1pdHMv MTM2OThjYmUzMTE5MjJhMzk5NTIzNmRkYTk2MGI0Y2RmZjQ5ZTM2ZjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR22MB0983001DC1DDFAD5A8FD23C5DA690CY4PR22MB0983namp_-- From nobody Fri Feb 8 11:21:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B23130DEF for ; Fri, 8 Feb 2019 11:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvVoD4yFJ7Dw for ; Fri, 8 Feb 2019 11:21:32 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 929AD130E96 for ; Fri, 8 Feb 2019 11:21:31 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id q21so4930062wmc.5 for ; Fri, 08 Feb 2019 11:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ZY+4oykanRVnOhsyDDQ36c5LjflhZfHf+F3rxUfHUc=; b=LNzvIE2kDveKUyKAi5aG7XBvLctoObDv1nOovbNM9YnYrXphtiOhxKRPMYge+mNc+v F6EZHwPrMhBOXI8tgI+zUe9SyLXKGcLARivdjE9aF4wlV6OA0X+lSliYXcrg0UsqvwiU 1nN71tmSzeGsCxodKMu8zfGwMyxIxMTn8ijLQo1HUNcDmGj9cTB7VoLAWqQSssE1D2zi 8oeG8xPCTDjW3JBRqY0UWD8E1uAzIMOB5rVb4c/44XF+lEnmAh5xd5iiW0Vqj4g7CB87 N55C8K3hIQgxTQYCvhPX99Neyzf8e+AIqAwgzZUlqPkC9R8KsAW7o/JXzT8Bufyl7xmj vtqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0ZY+4oykanRVnOhsyDDQ36c5LjflhZfHf+F3rxUfHUc=; b=QLQPIF4/jgWxb4p1M2eiuxEZKtrahZwxDq0fW/rFJyYBy5iUta7MSw4wp703tgHrAO FGggJwgj1fuC/hspGamJ/bdA6xQGM3a3BILhgnrTC37VVIil7QPE3O1rqdHUUCdcTxtD Fuj2VgjjiBuSqmivBspknd+V7k4of5OtL9utMvHSZZjgeYfuvWQ1S1c1/cJjQT57tbY3 4IRP2s127SyueO2G2Exr74xi2nyleT4qBg/abF2UbZ2z76jDx7LeXtOVPz0cQ8NFgKEj g8VZh9HaNF/GH8dCHi8+KLE/OdDCzGLF9DMVdIMF7DK7I8sLlq1bpQI7xiCZSU/mkPfL JoLw== X-Gm-Message-State: AHQUAuZKy6IzmD0UrfNDZCrirkr4DQfF867kcxvdfrgnCA/sTJ1RunRl Hg5ztyofcI14RAcI+Oa/VXBcXb2SZiLCbU3ej/lbqAv61e1yZw== X-Google-Smtp-Source: AHgI3Ib+kd2kfliGtrSeM23o5G8z87wevJsF3Atdnt5ZuzEuZ1SgKx6t1NRnDPAH76cm8WBqbMmkQa6LpjGzscQ9f0k= X-Received: by 2002:adf:e290:: with SMTP id v16mr3311778wri.100.1549653689661; Fri, 08 Feb 2019 11:21:29 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <1549593981.877482.1653392768.203A9C0B@webmail.messagingengine.com> In-Reply-To: From: Ian Swett Date: Fri, 8 Feb 2019 14:20:48 -0500 Message-ID: Subject: Re: New path => new connection ID, right? To: Mike Bishop Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b2fd8b058166ddf8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 19:21:36 -0000 --000000000000b2fd8b058166ddf8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Mike, I was unaware of that restriction. Issue filed. https://github.com/quicwg/base-drafts/issues/2441 On Fri, Feb 8, 2019 at 1:38 PM Mike Bishop wrote: > That=E2=80=99s not a change =E2=80=93 the requirement is already in the s= pec: > > An endpoint whose peer has selected a zero-length connection ID MUST > continue to use a zero-length connection ID for the lifetime of the > connection and MUST NOT send packets from any other local address. > > > > If we want to change this restriction, let=E2=80=99s discuss that as a se= parate > issue, please. (I=E2=80=99m not in favor of changing it, because in the = general > case it requires trial decryption. You=E2=80=99re correct that in the sp= ecial case > of using a unique local port per connection there might be some leeway.) > > > > *From:* QUIC *On Behalf Of * Ian Swett > *Sent:* Friday, February 8, 2019 8:23 AM > *To:* Martin Thomson > *Cc:* IETF QUIC WG > *Subject:* Re: New path =3D> new connection ID, right? > > > > It also adds "Similarly, an endpoint MUST NOT migrate if its peer supplie= s > a zero-length connection ID". > > > > In a P2P use case where there's only one connection, this precludes > migration in a case where it would otherwise work, so I don't see adding > this restriction as being helpful. > > > > On Thu, Feb 7, 2019 at 9:46 PM Martin Thomson wrote: > > In an attempt to close the loop, I've updated > https://github.com/quicwg/base-drafts/pull/2414 > > The controversial bits are apparently: > > * if you intentionally move to a new path, then you have to use a > connection ID that hasn't been used on any other path > > * if you don't have a new connection ID (which also includes zero-length > connection IDs in the latest change), then you can't use a new path > > I believe that both are editorial changes, but the volume of discussion o= n > the thread indicates that some people would like to see the issue > reopened. In the interests of forward progress, I would like the chairs = to > make an assessment. > > Note that this PR doesn't include the fix to > https://github.com/quicwg/base-drafts/issues/2342, which reviewers will > no doubt trip over in the process of reviewing this change. > > On Tue, Feb 5, 2019, at 10:15, Martin Thomson wrote: > > I thought that we had agreed that an endpoint that intentionally > > migrates has to use a new connection ID on the new path. But I couldn'= t > > find any "MUST" in the spec that said that. > > > > On the off chance that this wasn't just a mistake and there was some > > good reason not to mandate this, I'm bringing the discussion here. > > > > I've opened a design issue: > > https://github.com/quicwg/base-drafts/issues/2413 > > > > The change I'm proposing is here: > > > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a39= 95236dda960b4cdff49e36f > > --000000000000b2fd8b058166ddf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mike, I was unaware of that restri= ction.=C2=A0 Issue filed.


On Fri, Feb 8, 2019 at 1:38 PM Mike Bishop <mbishop@evequefou.be> wrote:

That=E2=80=99s not a change =E2=80=93 the requiremen= t is already in the spec:

An endpoi= nt whose peer has selected a zero-length connection ID MUST continue to use= a zero-length connection ID for the lifetime of the connection and MUST NOT send packets fro= m any other local address.

=C2=A0

If we want to change this restriction, let=E2=80=99s= discuss that as a separate issue, please.=C2=A0 (I=E2=80=99m not in favor = of changing it, because in the general case it requires trial decryption.= =C2=A0 You=E2=80=99re correct that in the special case of using a unique local port per connection there might be some leeway.)

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Ian Swett
Sent: Friday, February 8, 2019 8:23 AM
To: Martin Thomson <mt@lowentropy.net>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: New path =3D> new connection ID, right?

=C2=A0

It also adds "Similarly, an endpoint MUST NOT m= igrate if its peer supplies a zero-length connection ID".

=C2=A0

In a P2P use case where there's only one connect= ion, this precludes migration in a case where it would otherwise work, so I= don't see adding this restriction as being helpful.

=C2=A0

On Thu, Feb 7, 2019 at 9:46 PM Martin Thomson <mt@lowentropy.net&= gt; wrote:

In an attempt to close = the loop, I've updated https://github.com/quicwg/base-drafts/pull/2414

The controversial bits are apparently:

* if you intentionally move to a new path, then you have to use a connectio= n ID that hasn't been used on any other path

* if you don't have a new connection ID (which also includes zero-lengt= h connection IDs in the latest change), then you can't use a new path
I believe that both are editorial changes, but the volume of discussion on = the thread indicates that some people would like to see the issue reopened.= =C2=A0 In the interests of forward progress, I would like the chairs to mak= e an assessment.

Note that this PR doesn't include the fix to https://github.com/quicwg/base-drafts/issues/2342, which reviewers will= no doubt trip over in the process of reviewing this change.

On Tue, Feb 5, 2019, at 10:15, Martin Thomson wrote:
> I thought that we had agreed that an endpoint that intentionally
> migrates has to use a new connection ID on the new path.=C2=A0 But I c= ouldn't
> find any "MUST" in the spec that said that.
>
> On the off chance that this wasn't just a mistake and there was so= me
> good reason not to mandate this, I'm bringing the discussion here.=
>
> I've opened a design issue:
> https://github.com/quicwg/base-drafts/issues/2413
>
> The change I'm proposing is here:
> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995= 236dda960b4cdff49e36f

--000000000000b2fd8b058166ddf8-- From nobody Sat Feb 9 16:45:32 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AC4127AC2 for ; Sat, 9 Feb 2019 16:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=EiZhXPlD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dk8bjNvx 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 GQv8CSTzM5QB for ; Sat, 9 Feb 2019 16:45:26 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCA8124BAA for ; Sat, 9 Feb 2019 16:45:25 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A530321BCA for ; Sat, 9 Feb 2019 19:45:23 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 09 Feb 2019 19:45:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=2z7H8NNUp4jA5hl7F1nILwAzHj4oKDsUnlOnafroioY=; b=EiZhXPlD a0wLEdPYUKyPeFbXVjkkpCMXxSZKYDGp1fxVJJhiJ3YKJN02Dto5JCWG9F67f9of D31AslHNKHdNguAH2WViNStJwigrCjeXGExgvbHIPZ4NYIBm8nGEnPlvtYLqedHi DClR9anteSbXWVspRmVsn1xkAEPhbF5iyU99HUVS9yoU3AXKoiKw1yyCGBaHPZQV Bqq8zs3bZ0uavIE7pcAeeOhO09XTakwpP5fHWB+7og99Rwt5F1M5hfc2ugbfkY40 P2alrrHP0tcU2s/eipquVpUuCdvcSBDRY9wEK+C4zeTkldjfV5DArLnppaSNmjZR v93ahlgYKvo6Mw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=2z7H8NNUp4jA5hl7F1nILwAzHj4oK DsUnlOnafroioY=; b=dk8bjNvxgaiv7UBlcc+OEW0jUEwpRfN/Cn6sAWNhu9Rro qNF3rP0maoM+EGcdyxpRXitXgsIrMkYqTqdJwhNFDegg3TM182H1kegXO4dljurg N6Mqvyl9YV6B2hHBUxGEVSTVJnZWAmBkYJJTStEt0c6/dOGkXKEzhthGIGS1qnbj Zu5n6cm6RitomafJIMSks+rH2O9JdMxk7rLEtdGuU3gjWb+OfnNosZbVlUxOVkhO It8zidhjrZ6FW441MP7HaKmD+knjlzu5pGqq/CUT3y5+qM2QGtVVsj3PjnMs7RXs 2oCKAFALOwUAhDZ+YyQIMK/PaVsdSjEJfJlWtkXaQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleehgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpefiihhthhhusg gppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhn vghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeduudelrdelrdegfe drvdegudenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehm nhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 98AE310288 for ; Sat, 9 Feb 2019 19:45:21 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 6D7DCC03D6 for ; Sun, 10 Feb 2019 00:45:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============4847957077847558476==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190210004517.6D7DCC03D6@cloud.mnot.net> Date: Sun, 10 Feb 2019 00:45:17 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 00:45:31 -0000 --===============4847957077847558476== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+11/-11/=F0=9F=92=AC58) 11 issues created: - Justification for Key Separation doesn't make sense (by martinduke) https://github.com/quicwg/base-drafts/issues/2447 = - Organize Security Considerations (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2444 = - Conflict between SETTINGS_NUM_PLACEHOLDERS and SETTINGS_ENABLE_CONNECT_= PROTOCOL (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2443 = - Put Initial Value of settings in IANA Considerations (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2442 = - Peers that only terminate a single connection on an IP/port cannot migr= ate (by ianswett) https://github.com/quicwg/base-drafts/issues/2441 [-transport] [design] = - Clarify use of HTTP request with http scheme over HTTP/3 (by gloinul) https://github.com/quicwg/base-drafts/issues/2439 = - rate-limiting the CID issuance needs to be allowed (by kazuho) https://github.com/quicwg/base-drafts/issues/2436 = - loss recovery of crypto packets is less aggressive, not more aggressive= (by marten-seemann) https://github.com/quicwg/base-drafts/issues/2435 = - Reserved versions are not version-dependent (by marten-seemann) https://github.com/quicwg/base-drafts/issues/2434 = - HTTP/3 doesn't mandate RFC8470 compliance (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2432 [-http] [design] = - Reserved versions will "probably" never represent a real protocol? (by = MikeBishop) https://github.com/quicwg/base-drafts/issues/2430 [-transport] [editori= al] = 23 issues received 58 new comments: - #2436 rate-limiting of CID issuance needs to be allowed (18 by kazuho, = MikeBishop, martinthomson, huitema, mikkelfj) https://github.com/quicwg/base-drafts/issues/2436 [-transport] [design] = - #2400 VN packets may be dropped more often when the QUIC bit is 0 (6 by= DavidSchinazi, kazuho, martinduke, mikkelfj) https://github.com/quicwg/base-drafts/issues/2400 [-transport] [design] = - #2413 Mandate using a new connection ID on migration (4 by martinthomso= n, MikeBishop, mikkelfj) https://github.com/quicwg/base-drafts/issues/2413 [-transport] [design] = - #2434 Reserved versions are not version-dependent (3 by martinthomson, = marten-seemann) https://github.com/quicwg/base-drafts/issues/2434 [-invariants] [-trans= port] = - #2398 Specify DCID of 0-RTT packets (3 by MikeBishop, mikkelfj) https://github.com/quicwg/base-drafts/issues/2398 [-transport] [editori= al] = - #2439 Clarify use of HTTP request with http scheme over HTTP/3 (2 by L= Pardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2439 [-http] = - #2447 Justification for Key Separation doesn't make sense (2 by martind= uke, mikkelfj) https://github.com/quicwg/base-drafts/issues/2447 = - #2145 Don't change CID on peer CID change (2 by martinthomson, mnot) https://github.com/quicwg/base-drafts/issues/2145 [-transport] [design] = - #2415 Unidirectional RESET_STREAM/STOP_SENDING semantics map poorly to = proxies (2 by MikeBishop, mikkelfj) https://github.com/quicwg/base-drafts/issues/2415 [-transport] [design] = - #2175 Key Diversity (2 by kazuho, martinduke) https://github.com/quicwg/base-drafts/issues/2175 [-tls] [editorial] = - #2430 Reserved versions will "probably" never represent a real protocol= ? (2 by martinthomson, MikeBishop) https://github.com/quicwg/base-drafts/issues/2430 [-transport] [editori= al] = - #1795 Define a safe algorithm for changing CID in response to a change = in CID (1 by mnot) https://github.com/quicwg/base-drafts/issues/1795 [-transport] [design] = - #2441 Peers that only terminate a single connection on an IP/port canno= t migrate with 0-byte CIDs (1 by kazuho) https://github.com/quicwg/base-drafts/issues/2441 [-transport] [design] = - #1810 Timing issues in version downgrade attack prevention (1 by mnot) https://github.com/quicwg/base-drafts/issues/1810 [-transport] [design] = - #2435 loss recovery of crypto packets is less aggressive, not more aggr= essive (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2435 [-recovery] [design] = - #1834 Flow control for post-handshake CRYPTO messages (1 by mnot) https://github.com/quicwg/base-drafts/issues/1834 [-tls] [design] [yaec= !] = - #2348 Specify IPv6 flow label for QUIC (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2348 [-transport] [design] = - #2101 Should retiring all CIDs be an error? (1 by mnot) https://github.com/quicwg/base-drafts/issues/2101 [-transport] [design] = - #2363 The initial table capacity is zero (1 by afrind) https://github.com/quicwg/base-drafts/issues/2363 [-qpack] [editorial] = [has-proposal] = - #2357 Stream Send State Machine is Confusing (1 by martinduke) https://github.com/quicwg/base-drafts/issues/2357 [-transport] [editori= al] = - #2319 Error code for acknowledgment of a packet that was never sent (1 = by mnot) https://github.com/quicwg/base-drafts/issues/2319 [-transport] [design]= [yaec!] = - #1885 DATA frame encoding is inefficient for long dynamically generated= bodies (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1885 [-http] [design] = - #1904 Alternative largest reference algorithm (1 by afrind) https://github.com/quicwg/base-drafts/issues/1904 [-qpack] [editorial] = [has-proposal] = 11 issues closed: - Justification for Key Separation doesn't make sense https://github.com/= quicwg/base-drafts/issues/2447 = - address-based access control https://github.com/quicwg/base-drafts/issu= es/2279 [-http] [editorial] = - Error code for indicating that a HTTP response is aborted https://githu= b.com/quicwg/base-drafts/issues/2416 [-http] [design] [yaec!] = - Specify IPv6 flow label for QUIC https://github.com/quicwg/base-drafts/= issues/2348 [-transport] [design] = - Mandate using a new connection ID on migration https://github.com/quicw= g/base-drafts/issues/2413 [-transport] [design] = - Stream Send State Machine is Confusing https://github.com/quicwg/base-d= rafts/issues/2357 [-transport] [editorial] = - loss recovery description mixes variables depending on the packet numbe= r space and packet numbers independent of it https://github.com/quicwg/base= -drafts/issues/2405 [-recovery] [design] = - Alternative largest reference algorithm https://github.com/quicwg/base-= drafts/issues/1904 [-qpack] [editorial] [has-proposal] = - The initial table capacity is zero https://github.com/quicwg/base-draft= s/issues/2363 [-qpack] [editorial] [has-proposal] = - Disallow changes of table size after 0-RTT https://github.com/quicwg/ba= se-drafts/issues/2276 [-http] [-qpack] [design] [has-proposal] = - Largest Reference algorithm can produce invalid values https://github.c= om/quicwg/base-drafts/issues/2112 [-qpack] [design] [has-proposal] = Pull requests ------------- * quicwg/base-drafts (+7/-8/=F0=9F=92=AC18) 7 pull requests submitted: - Minor TLS draft editorial corrections (by martinduke) https://github.com/quicwg/base-drafts/pull/2446 = - quic-tls nits (by martinduke) https://github.com/quicwg/base-drafts/pull/2445 = - Modify QPACK steam and instruction terminology (by LPardue) https://github.com/quicwg/base-drafts/pull/2440 = - QPACK table lookup noob clarifications (by ghedo) https://github.com/quicwg/base-drafts/pull/2438 = - VarInt all the HTTP things (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2437 [-http] [design] = - Require RFC8470 (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2433 [-http] [design] = - Discard inconsistent packets (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2431 [-transport] [editorial= ] = 13 pull requests received 18 new comments: - #2428 clarify what happens when consuming CIDs excessively (3 by ericki= nnear, mikkelfj) https://github.com/quicwg/base-drafts/pull/2428 [-transport] = - #2365 Persistent Congestion Time Threshold (2 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2365 [-recovery] [design] = - #1998 introduce a max_connection_ids transport parameter (2 by marten-s= eemann, mikkelfj) https://github.com/quicwg/base-drafts/pull/1998 [-transport] [design] = - #2417 update the pseudo code to include packet number spaces (2 by jana= iyengar, ianswett) https://github.com/quicwg/base-drafts/pull/2417 [-recovery] [design] = - #2433 Require RFC8470 (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2433 [-http] [design] = - #2438 QPACK table lookup noob clarifications (1 by dtikhonov) https://github.com/quicwg/base-drafts/pull/2438 = - #2249 Invalid Largest Reference is a stream error. (1 by afrind) https://github.com/quicwg/base-drafts/pull/2249 [-qpack] [editorial] = - #348 Define "httpq" (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/348 [-http] [parked] = - #2399 Ipv6 flow label (1 by becarpenter) https://github.com/quicwg/base-drafts/pull/2399 [-transport] [design] = - #2414 New connection IDs are mandatory for intentional migration (1 by= mikkelfj) https://github.com/quicwg/base-drafts/pull/2414 [-transport] [design] = - #2424 Reword Immediate ACK Recommendation (1 by martinduke) https://github.com/quicwg/base-drafts/pull/2424 = - #2090 create codec streams only when necessary (1 by afrind) https://github.com/quicwg/base-drafts/pull/2090 [-qpack] [design] = - #2431 Discard inconsistent packets (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/2431 [-transport] [editorial= ] = 8 pull requests merged: - Indicate initial-only frames https://github.com/quicwg/base-drafts/pull/2425 [-http] [editorial] = - Migration in Security Considerations https://github.com/quicwg/base-drafts/pull/2427 [-http] [editorial] = - Servers can still CANCEL, too. https://github.com/quicwg/base-drafts/pull/2426 [-http] [editorial] = - Update diagram: h2q is now h3 https://github.com/quicwg/base-drafts/pull/2422 [-tls] [editorial] = - update the pseudo code to include packet number spaces https://github.com/quicwg/base-drafts/pull/2417 [-recovery] [design] = - QPACK: Clarify how maximum dynamic table capacity can be set https://github.com/quicwg/base-drafts/pull/2330 [-qpack] [design] = - QPACK: Clarify how maximum dynamic table capacity can be set https://github.com/quicwg/base-drafts/pull/2330 [-qpack] [design] = - Replace the RequireInsertCount decoding algorithm https://github.com/quicwg/base-drafts/pull/2379 [-qpack] [editorial] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============4847957077847558476== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday February 10, 2019

Issues

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

11 issues created:

23 issues received 58 new comments:

11 issues closed:

Pull requests

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

7 pull requests submitted:

13 pull requests received 18 new comments:

8 pull requests merged:

Repositories tracked by this digest:

--===============4847957077847558476==-- From nobody Sun Feb 10 11:28:42 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173F4129524 for ; Sun, 10 Feb 2019 11:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7aoGnfxUu7z for ; Sun, 10 Feb 2019 11:28:38 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 B6D29126C15 for ; Sun, 10 Feb 2019 11:28:37 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id r17so13267034wmh.5 for ; Sun, 10 Feb 2019 11:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kt5SOYFFW/v9j7aU+m5hO/L5OocxklAQ1vREQNx38Gs=; b=s/gNPFVymqAuOP0TwFyw/pANtkG8DvrDRrEsgkQYhxDFdR+ZKsh8GnCjKNrVh6aQmd Mm6awdhQjExMl0GuFe+iUzYyrqxB/TGUI7MqzRkCF4Vysd9lH5D7pVxbgJ+JUPK7Hquf k5zZomy2pO8wpH95Pz3VYBAcc2B0STWlcc4GZTtNlms0ZE+64OGn9QoangWPglvSZhDS Q313HFYGhK648P70VYGByCoUZMbt59NC3F+wABOomifOgjzMpxsYCKwEyRb2eeilIVrc Z8A3MkwIz8Vxjf4dCXrndtd/hPZyzBmSxjelMh6z8jUmk1kAZiroJ80h+5F4LLBb9RHy qgnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kt5SOYFFW/v9j7aU+m5hO/L5OocxklAQ1vREQNx38Gs=; b=UQxvEHgKtp6vz/H66w95Lvzkute5VFOmhN23onI0+SeoM8fds8XDrdQJrH0kCGYeWM 0hiLsP5fVhZ0iveyjgoZ3nf76X9sf20brr7LaMbSWDPeHM2auO7qvSTh4JhXiJ+r3u9R O+qqEGC3Dx1Yq0VMGlX/kvDcMThx/EaSsrqb/Ve5O5fbPp3HvF+dJbFbpkqEHKwrMVAY M8Q2BPHLy6OlpAGEt+vO2SOfIvIIqwjcB6uuMN7Z7AEGTcFSc8f1vvyihLvmjTrRbQFo AeQylGb6WPHRm5OjGRiDteHLhvrGz0KKKZVvEic4gNzxtG2K+Vzt+F/0R7szbanc2tBg 2ToA== X-Gm-Message-State: AHQUAuaB55PceU+aT8Z/3Vp4xBhOhc/NbTFi2t9VkUGH6a+FdQmvnq6P eKcLvjF1Az37RVKdJuutPu0BndNmjRqCT94uY5o= X-Google-Smtp-Source: AHgI3IbDcsv/Q8TXZO83gmiszWSma56Oq4WC6YzoLFpJKFwMVSbXfaB+xFGgfttQucPyqi/Wb9g+SZBkW8IqZU7m/vA= X-Received: by 2002:a1c:2e43:: with SMTP id u64mr6743757wmu.52.1549826914957; Sun, 10 Feb 2019 11:28:34 -0800 (PST) MIME-Version: 1.0 References: <1549594501.881364.1653399392.63222EBD@webmail.messagingengine.com> In-Reply-To: From: Martin Duke Date: Sun, 10 Feb 2019 11:28:22 -0800 Message-ID: Subject: Re: Limiting connection ID supply To: Ted Hardie Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000babf6705818f32ea" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 19:28:41 -0000 --000000000000babf6705818f32ea Content-Type: text/plain; charset="UTF-8" I strongly support limiting Connection ID pulls. For servers with a relatively limited pool of connection IDs, for whatever reason, allowing an attacker to open a connection and getting a large sample of connection IDs from one server can open up various attempts to crack the route encoding scheme. On Fri, Feb 8, 2019 at 9:45 AM Ted Hardie wrote: > On Thu, Feb 7, 2019 at 6:55 PM Martin Thomson wrote: > >> https://github.com/quicwg/base-drafts/issues/2436 includes a simple >> issue: if someone starts retiring connection IDs aggressively, they can >> exhaust your supply. Kazuho suggests that we allow endpoints to limit the >> number of connection IDs they supply. >> >> There is a PR: https://github.com/quicwg/base-drafts/pull/2428 >> >> I think this idea is generally good, but I have a slight concern that the > full text reads as if the connection-IDs should be provided just before > migration. That's largely because the text above it has a just-in time > flavor: > >> The endpoint SHOULD do this by supplying a new connection ID when a >> connection ID is retired by its peer or when the endpoint receives a packet >> with a previously unused connection ID, though it MAY limit the frequency >> or the total number of connection IDs issued for each connection to avoid >> the risk of running out of connection IDs (see {{reset-token}}). >> >> Endpoints that initiate migration and require non-zero-length connection >> IDs SHOULD provide their peers with new connection IDs before migration, or >> risk the peer closing the connection. >> > I'd suggest a slight adjustment, to link back to the minimum requirement: > > "Endpoints that initiate migration and require non-zero-length connection > IDs SHOULD ensure that the pool of connection IDs available to their peers > allows them to use a new connection ID on migration, as the peer will close > the connection if the pool is exhausted." > > Does that change work for you? > > Ted > > > > >> I don't think that this sort of rate limiting is generally advisable, >> because of the risk that this would discourage the use of new connection >> IDs.. Long connection IDs are a better solution, but those are inefficient >> and I don't want to get into a situation where connection ID rotation on >> shorter connection IDs is infeasible. I think that the proposed text is >> worded carefully enough and strikes a good balance between these concerns. >> I would like to merge this one. >> >> --000000000000babf6705818f32ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I strongly support limiting Connection ID pulls. For = servers with a relatively limited pool of connection IDs, for whatever reas= on, allowing an attacker to open a connection and getting a large sample of= connection IDs from one server can open up various attempts to crack the r= oute encoding scheme.


On Fri, Feb 8, 2019 at 9:45 A= M Ted Hardie <ted.ietf@gmail.com> wrote:
https://github.com= /quicwg/base-drafts/issues/2436 includes a simple issue: if someone sta= rts retiring connection IDs aggressively, they can exhaust your supply.=C2= =A0 Kazuho suggests that we allow endpoints to limit the number of connecti= on IDs they supply.

There is a PR: https://github.com/quicwg/base-drafts/= pull/2428

I think this idea is generally good, but I have a sli= ght concern that the full text reads as if the connection-IDs should be pro= vided just before migration.=C2=A0 That's largely because the text abov= e it has a just-in time flavor:

The endpoint SHOULD do this by supplying a new connecti= on ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID, though it MAY limit the freq= uency or the total number of connection IDs issued for each connection to avoid t= he risk of running out of connection IDs (see {{reset-token}}).

Endpoints that initiate migration and require non-zero-length connection= IDs SHOULD provide their peers with new connection IDs before migration, or ris= k the peer closing the connection.

I'd suggest a s= light adjustment, to link back to the minimum requirement:

"Endpoints that initiate migration and require non-zero-lengt= h connection IDs SHOULD ensure that the pool of connection IDs available to their peers allo= ws them to use a new connection ID on migration, as the peer will close the connection if the pool is exhausted."
Does that change work for you?

Ted


=C2=A0
I don't think that this sort of rate limiting is generally advisable, b= ecause of the risk that this would discourage the use of new connection IDs= ..=C2=A0 Long connection IDs are a better solution, but those are inefficie= nt and I don't want to get into a situation where connection ID rotatio= n on shorter connection IDs is infeasible.=C2=A0 I think that the proposed = text is worded carefully enough and strikes a good balance between these co= ncerns.=C2=A0 I would like to merge this one.

--000000000000babf6705818f32ea-- From nobody Sun Feb 10 14:33:39 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CD412941A for ; Sun, 10 Feb 2019 14:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=bKLUtwTR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O1ZdguR8 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 oqueCGOUv_fw for ; Sun, 10 Feb 2019 14:33:36 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32ADF12958B for ; Sun, 10 Feb 2019 14:33:36 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5947B21A7F; Sun, 10 Feb 2019 17:33:35 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Sun, 10 Feb 2019 17:33:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:references:in-reply-to:date; s=fm1; bh=N5F mSoGnpb72bVK+fi7MeXyIxIZPuUNq8NgcnJlPRGA=; b=bKLUtwTRQDjZAviCuvN +PF6uHV409xmjB1mQQTXdpoOz9XTgeVNfztUdctVbpHXGx21/WsKaTFObotA/61R l3fMjQorUVMVY7+/e926H2P2WlOfML5icMbtIBWrNyH1VYtbzFNuddVzaHlVuFbt I07cSNusfB778EalJtsm2XwlYMX5DqgJXyWnBbS5jxUlmUEoXz766jVUHR1j/Ud5 LH64WpC0LdA2VFdcTD7jz5f4kZf7yCHndOCAYAdvTjSKj2iJ3SQQKcEQbim5E3u8 X57ZVvOf1MxcZCXwvyUC2H1BxLFzA3WHKRHYZT0sONOa00lm5XdccPVmmYe2w7Ni 6dA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=N5FmSoGnpb72bVK+fi7MeXyIxIZPuUNq8NgcnJlPR GA=; b=O1ZdguR8gelPqvmfpjMVFnLCdqmm2C71YrqL5K3zGyHLlSlAyzH6UztUU hClXwbN4wldAA9MziIzZP3yE/KZD0i7t/4D8wwWIIparRpuJYT18gDC3niF133mU j3YWYSnPM0gVC9toLn94to7si1tlTD4FNfR+KcknkdW1z3LqSWzi0OSvT0myhum+ HLBY2DN0KV9q5gu5LY2utBy7o6t7IY/zcny+rkZlXu9SD+rulxe9FHuP1iiXoM3W REat148BfN17XAMRXusPpunilBMWEymZGvX7OL985XPZSH5T4yGu0C87kAEJ0Asf qON3Eq2j8xbVlopN/xIcrPPJSPeIQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleeigdduieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg foufhfjgffsehtjeertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcu oehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9791C9E567; Sun, 10 Feb 2019 17:33:34 -0500 (EST) Message-Id: <1549838014.435230.1655074800.1E758CEE@webmail.messagingengine.com> From: Martin Thomson To: Ted Hardie Cc: IETF QUIC WG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1 Subject: Re: Limiting connection ID supply References: <1549594501.881364.1653399392.63222EBD@webmail.messagingengine.com> In-Reply-To: Date: Mon, 11 Feb 2019 09:33:34 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 22:33:38 -0000 On Sat, Feb 9, 2019, at 04:44, Ted Hardie wrote: > "Endpoints that initiate migration and require non-zero-length connection > IDs SHOULD ensure that the pool of connection IDs available to their peers > allows them to use a new connection ID on migration, as the peer will close > the connection if the pool is exhausted." Thanks Ted, That matches my understanding of the requirement much better. I've updated the PR to match. From nobody Sun Feb 10 20:21:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E21B12F295 for ; Sun, 10 Feb 2019 20:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=mnot.net header.b=SxbhJU/s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lETAN7AG 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 wA5CBbUnoyoh for ; Sun, 10 Feb 2019 20:21:26 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2935127133 for ; Sun, 10 Feb 2019 20:21:25 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EEA7E22012; Sun, 10 Feb 2019 23:21:24 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 10 Feb 2019 23:21:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm1; bh=dKGsW5opNk1r7PEVpQbMRZ64QWOgfK VIGvgVo88+w6E=; b=SxbhJU/sL/Ne9jPVAZ27MxOZnpK62SpF2xLRW5nIP/q/Dm AdCq66YAackTwwdhBGBzWX9Zl+fVWvA2M6OB5TOXTHMwnY5zoM6bY89T8b83ZeRw aFkPkUl7/xT2Nros/j59veY3Wg7QjNd4nzTGf5c9jnS2MR6rD+8i2iCRRt9uhnvu aRiL4elsiroPtGoxs4uvcQVNW3hHAUaSJS0+VNzIsnvOszHRHRmYLgtLYVeipDkR leOYG/OPUuhwBmTP55SP58mZgsyb9kAeNz1D0EpGDor0FKa3yyRH6CKkqik4GiUW UUsLY5PRoBoa2XPKvh0jw07o8qSidMcIBmeIQjNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=dKGsW5 opNk1r7PEVpQbMRZ64QWOgfKVIGvgVo88+w6E=; b=lETAN7AG8VR1bLBsjPUhyV FZrj8UxDs6i5yiTssaATBLPVfzu+6xD94f9pk48M4EOoNrZTeTZ7eYVNZNpQizwf 8MVxJFAHPnSG3PqBFrIDrIBTx5v7ZVgpaDoABbAp/oKpAkVdjGQhR46cU+YsfVMt wO+ge1Imu+1tITFCg9T6vX2tttc9Sr1UuoaagtlJfwJLFBwFkeYAjTnv+K5peUZU SmXxng4En5rRrmCIQV1NnOc+L+mO6xCwcxZdB7jqL2Cg+5cOtlZTqytmWKaF/Uux 5/7SKFKMAH4oqP0cYFHxhz3MMgYxLfyfKaV8wQInkT9mrPM5Y6z9Yy0gzwpO8+eQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleejgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephfgtgfgguffkff fvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehm nhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhmnh hothdrnhgvthenucfkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 430FA100BA; Sun, 10 Feb 2019 23:21:21 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: QUIC Issues discussed in Tokyo - confirming consensus Message-Id: Date: Mon, 11 Feb 2019 15:21:19 +1100 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 04:21:28 -0000 We discussed a *large* number of issues in the Tokyo interim. = Congratulations to everyone. To refresh people's minds: * The project boards we drove discussion from: = https://github.com/quicwg/base-drafts/projects * The draft minutes: = https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minutes.m= d * Individual issues: = https://github.com/quicwg/base-drafts/issues/{issue_number} Please have a look through the issues listed below and respond if you = agree with their disposition, as noted below each group. * The following issues need more discussion (on-list or in-repo): - 2344: Frames that are allowed in 0-RTT packets - 2223: When can you coalesce connections - 253: HTTP/QUIC without Alt-Svc? * The following issues are pending proposals (usually, PRs, or progress = on an already-existing PR) -- along with the responsible party or = parties: - 2308: handling of coalesced packets with decryption errors creates DoS = opportunity - marten - 2214: simultaneous key update can lead to deadlock - mt, marten, ekr, = victor, kazuho - 1834: Flow control for post-handshake CRYPTO messages - mt - 2170: Embed QUIC version in expansion - mt and EKR - 1773: Build a version negotiation mechanism that mostly doesn't add = round trips - editors, based upon #2133 - 2145: Don't change CID on peer CID change - mt - 2084: Discuss requirement that connection IDs not be correlatable - = editors - 2143: Be more conservative about migration? - editors - 1994: endpoints don't know how many connection IDs the peer is willing = to store - marten - 2342: Spoofed connection migration as a DoS vector - editors - 2360: 0-RTT flow control limits can't be increased - editors - 2267: loss of only two packets can lead to an unrecoverable situation = - editors - 2309: Migration before handshake completed is very messy - christian - 2275: Varint h3 unidirectional stream types - editors - 2253: Consider making h3 frame types varint - editors - 2233: Why are setting identifiers not varints? - editors - 2228: How do I generate an RST? - editors - 2258: Initial maximum table size needs clarification - editors - 2100: Avoid creating QPACK codec streams when unnecessary - editors - 2371: Assign QPACK error codes? - editors * The following issues already have text incorporated into the editors' = drafts: - 2101: Should retiring all CIDs be an error? - 1990: encoding of CONNECTION_CLOSE reason phrases - 2347: nothing can be sent when receiving a packet just after the idle = close timer expires - 2118: Allow PMTU probing of a path suspected of not supporting PMTU of = 1280 - 2395: HTTP/3 uses LTV unlike TLS or QUIC transport=20 - 2276: Disallow changes of table size after 0-RTT - 2363: The initial table capacity is zero - 2112: Largest Reference algorithm can produce invalid values - 1951: Disconnect with Initial Injection - 2397: "Invariant check" for any inbound LH packet - editors - 2348: Specify IPv6 flow label for QUIC - christian ^^ If you disagree with these resolutions, please say so on the mailing = list or in the issue before 2019-02-22; after that, they will be marked = as `has-consensus`. If your feedback is editorial, please say so = explicitly, so we don't block on it. * The following issues were felt to be able to be closed with no (or = just editorial) action for quicv1/h3: - 2329: Actions to take when Reserved Bits are not Zero - 1874: Formal analysis of the protocol - 1810: Timing issues in version downgrade attack prevention - overcome = by events - 1795: Define a safe algorithm for changing CID in response to a change = in CID - dup of #2145 - 2159: Why are we bothering to number CIDs? - 2026: Can Initial/0-RTT CIDs safely be used for routing? - 2372: PATH_* frames should not be ACK-eliciting - 203: Connection migration should be indistinguishable from a new = connection - 2319: Error code for acknowledgment of a packet that was never sent - 1989: frame type field of CONNECTION_CLOSE provides little value - 2151: Where can you send CONNECTION_CLOSE - 1638: Dead path timeout - 1243: ICMP and ICMPv6 PMTUD with asymmetric connection-ids - 279: Public Troubleshooting Flags - 632: On-path calculation of loss and congestion - 602: End-to-Path Close Signal - 2299: consider making the varint encoding unique - 2049: minimum payload size requirement creates awkward special case - 219: Increasing initial flow control window for streams - 969: ACK Frames should be in Increasing Packet Number Order - 1482: Extension poster-child - 1993: Introduce a bit to indicate the server doesn't do IP-based = authentication - 279: Public Troubleshooting Flags - 655: 1-RTT stateless rejects - 718: Retain use of SETTINGS_ENABLE_PUSH - 2232: Should receipt of multiple promises really be an error? - 2291: Allow extra data after self-terminating h3 frames - 2229: Can I send non-data frames on CONNECT streams? - 2224: Why do control streams need to be typed? - 2396: HTTP/3 frame encodings are unnecessarily difficult to serialize = and parse - 2230: When can PUSH_PROMISE frames be sent? - 1885: DATA frame encoding is inefficient for long dynamically = generated bodies - 371: ALTSVC Frame - 2384: What scheme should be used for HTTP/3? - 2226: Why do I have to explicitly cancel after GOAWAY - 1420: encoder stream can deadlock ^^ If you disagree with these resolutions, please say so on the mailing = list or in the issue before 2019-02-22; after that, the non-editorial = issues will be marked as `has-consensus`, and the editorial issues will = be presumed to be indeed editorial. If your feedback is editorial or = otherwise non-critical, please say so explicitly, so we don't block on = it. Cheers, -- Mark and Lars, WG Chairs -- Mark Nottingham https://www.mnot.net/ From nobody Mon Feb 11 09:02:04 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E71310AB for ; Mon, 11 Feb 2019 09:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNGjSIgWIPN7 for ; Mon, 11 Feb 2019 09:01:59 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750130.outbound.protection.outlook.com [40.107.75.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68131310AC for ; Mon, 11 Feb 2019 09:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pEaEfB8Bu121ruhQGVTnZXFsKVzvn1gERex/e4aZHsk=; b=Az5r/+U3gt0DKP4ZdGyNfQYfwMf21Lp92JdYhIVY+Ha5KvapSVrchPVRQ+yDoyPgttRXtMfrwnmRJ+QjAf9plWop5U9g73CuEDlMgJkZNFEbZumkAqL8L+PBJuCWsYlj2Rwk5x0oqqa/vKTXWRWY73zzaoLqNNAYiv/5pncGLm0= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0535.namprd22.prod.outlook.com (10.172.139.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Mon, 11 Feb 2019 17:01:55 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2%4]) with mapi id 15.20.1601.023; Mon, 11 Feb 2019 17:01:55 +0000 From: Mike Bishop To: Mantas Gridinas CC: IETF QUIC WG Subject: RE: Regarding TLS 1.3 Usage Thread-Topic: Regarding TLS 1.3 Usage Thread-Index: AQHUwePCgpnlJlG1okeRtwyMRNKoXaXa0YJA Date: Mon, 11 Feb 2019 17:01:55 +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: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:a577:d655:63c7:1fcb] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR22MB0535; 6:cKRmJgwlb335h/DdJs4Ul6NbyxCDYV8M6aH9ELmOfSXHtX4Fa3Gt60JZ2T/Gh/fdpTvYglhk4y0UeWkKlSfj4KVaVWyRYBcgsqhj2tThAIpk3uYxLnKMvsxRbRRPSpXPF9i6sFx6Ck4QwBxob7nou5GQbC2zadkJnhuZoXvqzwIoz0bYch4DtgD6YoRteGnsYbFRXIsfVB65fyT4Ql7/+JafEWKbVrxxn6NrETL+IC9R70b/wN3A09jbDQL1+ohS2fcQD9KCxrEKXC8j/PA7dqVQCB5nG0r6VFSG4hQe5hJ+MrYEYI1Y6IT9P6uwOCVXKCYRJX8IVgR/9IWasLepqaFe2Zc2RjaAPhc716AchGzRoYrfzoFU6B7n/xJYfza+fVrGr62bY8Gd+DlbOPhSX/ihRwA3gMwbwHtuDSBSonEqztF8umhuK/62IFmaoXWoigtVEB3QRUjJxOAfHoJKNQ==; 5:CaVFtJ1OSQYP5GzheeoGUijU2tXOUY+Wco9OGzNXpHk7yrY/nqfYNABYYC4lbNsoFLQTxiR/2B9CoBbUoGERC6S3cvJTCogyCtyvFWmV/xfT5LWz1bh1G6Jxi4f8YimAjWLoxHrR+eUfYJi8pdAhLweflAi2ZSeAzfg8/CY03TEZnlBQlHnVqlb4pQp82PGcvEuk+m8vs6JEDzFQ7r/0GA==; 7:C6mUCDLkyK2ZHzSIoiCG6aLn18f4sZx7HfnpRdwWdTYJYAHN92jEVlUSJLoXQ+/c0wjqn4EGnYODHv7IYXZNH6AfUVNcKPWBLRXQ9+S7zIBTum3Fa1EAXe2hI9FDT4C7wmNRzXGFcD9UeSt1FLZYvA== x-ms-office365-filtering-correlation-id: 3c255bb6-8b44-4566-429f-08d69042a0af x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0535; x-ms-traffictypediagnostic: CY4PR22MB0535: x-microsoft-antispam-prvs: x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(136003)(39830400003)(346002)(396003)(199004)(189003)(2906002)(105586002)(86362001)(106356001)(186003)(102836004)(53546011)(46003)(68736007)(790700001)(6116002)(6506007)(11346002)(446003)(476003)(256004)(97736004)(486006)(33656002)(53936002)(7116003)(55016002)(74316002)(9686003)(81166006)(7736002)(8676002)(8936002)(1411001)(81156014)(508600001)(229853002)(6436002)(316002)(71190400001)(76176011)(71200400001)(7696005)(74482002)(99286004)(14454004)(6246003)(25786009)(4326008)(54896002)(6916009)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0535; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3MPYcIG1gGpzRgKkXdsCewgo48zYuGr1EXaIWpfOu2bbXPpzW9ihh+QjzV/houI4t3RugmcpLyPOsz07VKRzxoZYIz2qRhPWuaXP1/RTYJ9m+HfK0QN5etzg4yn48qJHSH3yCXMVYuWrGhsx66TdlYkSKJg3YRpCJP4pH4pYzHnIslLUqCNCd3cjABSiyrPku7xCFmdDgz7nV+/VDBcIDjhERABXuNTx4c/erVvJLlCzhFqZfHUwMFo5ApzErP/iC269MeDAaJk4TcFY3gKRrhNFB6z+T+iSP/R5Cn3rB9PfYNXxP3ZcCQTzcbtomTOfCKR3BB232fqtJDaOlNq437ycukbMVoCbIeuLGPrhuC28My2y3oGOrGcfWqJRyqk/Rj1TsrlS3hXHOOYCUjITn822NivPaXXEINtVpBBGJjY= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB09834C1C31B6B350F8833CD4DA640CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 3c255bb6-8b44-4566-429f-08d69042a0af X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2019 17:01:55.5924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0535 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 17:02:03 -0000 --_000_CY4PR22MB09834C1C31B6B350F8833CD4DA640CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KE1vdmluZyBmcm9tIHRoZSBkcmFmdC1zcGVjaWZpYyBsaXN0IHRvIHRoZSBXRyBsaXN0LikNCg0K R2l2ZW4gdGhlIGZsZXhpYmlsaXR5IG9mIFRMUywgaXQgc2VlbXMgbW9yZSBsaWtlbHkgdGhhdCBp bmRpdmlkdWFsIGNpcGhlcnMgb3IgKGF0IG1vc3QpIHZlcnNpb25zIHdvdWxkIGJlIGRlcHJlY2F0 ZWQgcmF0aGVyIHRoYW4gVExTIGFzIGEgd2hvbGUuICBCb3RoIG9mIHRob3NlIHRoaW5ncyBoYXZl IGhhcHBlbmVkIGJlZm9yZSAoc2VlIFJDNCwgU1NMIDMuMDsgVExTIDEuMCBhbmQgMS4xIGFyZSBp biB0aGUgcHJvY2VzcyBvZiBiZWluZyBkZXByZWNhdGVkKSBhbmQgSFRUUFMgaGFzIHN1cnZpdmVk IGRlc3BpdGUgbWFuZGF0aW5nIHRoZSB1c2Ugb2YgVExTLg0KDQpIb3dldmVyLCBpbiB0aGUgZXh0 cmVtZSBjYXNlLCB0d28gdGhpbmdzIHdvdWxkIG5lZWQgdG8gaGFwcGVuOiAgQSByZXZpc2lvbiB0 byBIVFRQLzMgcGVybWl0dGluZyBpdCB0byB1c2UgdmVyc2lvbnMgb2YgUVVJQyB3aGljaCBlbXBs b3kgYSBkaWZmZXJlbnQgaGFuZHNoYWtlIHByb3RvY29sLCBhbmQgYSBuZXcgdmVyc2lvbiBvZiBR VUlDIGJhc2VkIG9uIHNvbWV0aGluZyBlbHNlLiAgVGhhdOKAmXMgYmVjYXVzZSBUTFMgaXMgc3Rp bGwgYmVpbmcgdXNlZCBhcyBhIG1vZHVsZSDigJMgYSBkaWZmZXJlbnQgdmVyc2lvbiBvZiBRVUlD IGNvdWxkIGNob29zZSBhIGRpZmZlcmVudCBoYW5kc2hha2UgcHJvdG9jb2wgdGhhdCBwcm92aWRl cyB0aGUgbmVjZXNzYXJ5IHByb3BlcnRpZXMgYW5kIHdvdWxkIHdvcmsganVzdCBmaW5lIChtb2R1 bG8gYW55IGV4dGVuc2lvbnMgdGhhdCBhc3N1bWUgdGhlIGF2YWlsYWJpbGl0eSBvZiBhIFRMUyBz dGFjaykuDQoNCkZyb206IE1hbnRhcyBHcmlkaW5hcyA8bWdyaWRpbmFzQGdtYWlsLmNvbT4NClNl bnQ6IE1vbmRheSwgRmVicnVhcnkgMTEsIDIwMTkgMTI6MjQgQU0NClRvOiBkcmFmdC1pZXRmLXF1 aWMtaHR0cEBpZXRmLm9yZw0KU3ViamVjdDogUmVnYXJkaW5nIFRMUyAxLjMgVXNhZ2UNCg0KSGkh DQoNCkkgaGF2ZSBsb29rZWQgdGhyb3VnaCB5b3VyIGRvY3VtZW50IGFib3V0IEhUVFAvMyBhbmQg aXRzIHN1Z2dlc3Rpb25zIHRvIHVzZSBRVUlDIGFzIHdlbGwgYXMgVExTIDEuMyBhdCB0cmFuc3Bv cnQgbGF5ZXIgYW5kIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24gb2NjdXJyZWQgdG8gbWU6IFdoYXQg d2lsbCBoYXBwZW4gaWYgVExTIGdldHMgZGVwcmVjYXRlZD8gV2lsbCB3ZSBuZWVkIGFuIGVudGly ZWx5IG5ldyBwcm90b2NvbCB0byByZXBsYWNlIEhUVFAvMyBvbmNlIHRoYXQgaGFwcGVucz8gV2Fz bid0IGl0IGVudGlyZSBwb2ludCBvZiBTU0wgYW5kIFRMUyB0aGF0IHRoZXkgd291bGRuJ3QgYmUg cGFja2VkIHdpdGggYW55IHBhcnRpY3VsYXIgcHJvdG9jb2wsIGJ1dCBpbnN0ZWFkIGFkZGVkIGFz IGEgbGF5ZXI/DQo= --_000_CY4PR22MB09834C1C31B6B350F8833CD4DA640CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPihNb3ZpbmcgZnJvbSB0aGUgZHJhZnQtc3BlY2lmaWMgbGlzdCB0byB0aGUgV0cgbGlz dC4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIHRoZSBmbGV4aWJpbGl0eSBvZiBUTFMs IGl0IHNlZW1zIG1vcmUgbGlrZWx5IHRoYXQgaW5kaXZpZHVhbCBjaXBoZXJzIG9yIChhdCBtb3N0 KSB2ZXJzaW9ucyB3b3VsZCBiZSBkZXByZWNhdGVkIHJhdGhlciB0aGFuIFRMUyBhcyBhIHdob2xl LiZuYnNwOyBCb3RoIG9mIHRob3NlIHRoaW5ncyBoYXZlIGhhcHBlbmVkIGJlZm9yZSAoc2VlIFJD NCwgU1NMIDMuMDsgVExTIDEuMCBhbmQgMS4xIGFyZSBpbiB0aGUgcHJvY2Vzcw0KIG9mIGJlaW5n IGRlcHJlY2F0ZWQpIGFuZCBIVFRQUyBoYXMgc3Vydml2ZWQgZGVzcGl0ZSBtYW5kYXRpbmcgdGhl IHVzZSBvZiBUTFMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIGluIHRoZSBleHRy ZW1lIGNhc2UsIHR3byB0aGluZ3Mgd291bGQgbmVlZCB0byBoYXBwZW46Jm5ic3A7IEEgcmV2aXNp b24gdG8gSFRUUC8zIHBlcm1pdHRpbmcgaXQgdG8gdXNlIHZlcnNpb25zIG9mIFFVSUMgd2hpY2gg ZW1wbG95IGEgZGlmZmVyZW50IGhhbmRzaGFrZSBwcm90b2NvbCwgYW5kIGEgbmV3IHZlcnNpb24g b2YgUVVJQyBiYXNlZCBvbiBzb21ldGhpbmcgZWxzZS4mbmJzcDsgVGhhdOKAmXMgYmVjYXVzZSBU TFMNCiBpcyBzdGlsbCBiZWluZyB1c2VkIGFzIGEgbW9kdWxlIOKAkyBhIGRpZmZlcmVudCB2ZXJz aW9uIG9mIFFVSUMgY291bGQgY2hvb3NlIGEgZGlmZmVyZW50IGhhbmRzaGFrZSBwcm90b2NvbCB0 aGF0IHByb3ZpZGVzIHRoZSBuZWNlc3NhcnkgcHJvcGVydGllcyBhbmQgd291bGQgd29yayBqdXN0 IGZpbmUgKG1vZHVsbyBhbnkgZXh0ZW5zaW9ucyB0aGF0IGFzc3VtZSB0aGUgYXZhaWxhYmlsaXR5 IG9mIGEgVExTIHN0YWNrKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1h bnRhcyBHcmlkaW5hcyAmbHQ7bWdyaWRpbmFzQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgRmVicnVhcnkgMTEsIDIwMTkgMTI6MjQgQU08YnI+DQo8Yj5Ubzo8L2I+IGRy YWZ0LWlldGYtcXVpYy1odHRwQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlZ2FyZGlu ZyBUTFMgMS4zIFVzYWdlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkh PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg aGF2ZSBsb29rZWQgdGhyb3VnaCB5b3VyIGRvY3VtZW50IGFib3V0IEhUVFAvMyBhbmQgaXRzIHN1 Z2dlc3Rpb25zIHRvIHVzZSBRVUlDIGFzIHdlbGwgYXMgVExTIDEuMyBhdCB0cmFuc3BvcnQgbGF5 ZXIgYW5kIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24gb2NjdXJyZWQgdG8gbWU6IFdoYXQgd2lsbCBo YXBwZW4gaWYgVExTIGdldHMgZGVwcmVjYXRlZD8gV2lsbCB3ZSBuZWVkIGFuIGVudGlyZWx5IG5l dyBwcm90b2NvbA0KIHRvIHJlcGxhY2UgSFRUUC8zIG9uY2UgdGhhdCBoYXBwZW5zPyBXYXNuJ3Qg aXQgZW50aXJlIHBvaW50IG9mIFNTTCBhbmQgVExTIHRoYXQgdGhleSB3b3VsZG4ndCBiZSBwYWNr ZWQgd2l0aCBhbnkgcGFydGljdWxhciBwcm90b2NvbCwgYnV0IGluc3RlYWQgYWRkZWQgYXMgYSBs YXllcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_CY4PR22MB09834C1C31B6B350F8833CD4DA640CY4PR22MB0983namp_-- From nobody Mon Feb 11 11:07:04 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A915131158 for ; Mon, 11 Feb 2019 11:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=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 Xxzpl2zbw4Ba for ; Mon, 11 Feb 2019 11:06:53 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 04651131145 for ; Mon, 11 Feb 2019 11:06:53 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id x124so779573itd.1 for ; Mon, 11 Feb 2019 11:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=+f7oS4JEgJro0Dgf53YQ5o7VBdsosatNomyhuiXNBTM=; b=bC0wsBKk8c35NOn45vBsJkHn6a9UH4nSHvjEI1+CzVGQYcXdtb/UF76Oe8lXqAdHg6 7L1V+eDK/5RyKxUT/cmPaeYOD6y/vh13IE9kQM4OEUKkhDHrnzdMieRWA5RUWehDpUxw VxWJDiE84/P28fhLypbTfl+qRBEuqz9K7F0kc/TzB3BBLWosEzX6HuduQBRV7bCUzzxi EDG/1xWjTNoUzcSy3K905AWBmcTqCu+RI5O3XxL5ZQnPbEy6u8tz4/BORg3EURPNPIl+ /ymPFYiXjUrwMyviBaQoIzrKjtWxAsHDrf1ZkCDdEgmINkjbSMFLZb2RpAWUiaJFLBjF QQpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=+f7oS4JEgJro0Dgf53YQ5o7VBdsosatNomyhuiXNBTM=; b=S9s27NlDFPaBKbdZwqMy/gTFiqemVqhWrMsHPRwa1wZ4IdKpk3uoDCm0YkQPaZeSzW Mm8BNf0AUBS+HtMWfOUa7OLDQ++WhI2omerRL+3QBvBv1loacJVPKtcKHzdD3wtqp3R6 XfNtIrbEZ7XCKIHgk9Hv+J6d7TIvpBi0THdK9X1NIedktOSUu4e7bMMXKlv3cNWqr3Ry 1JtpW531FldDuEr+G4v9BDcLHRi8kjCuKvf3eGFgf8S9AY919+g57eK6+EpO+s5C7HNT dLtxsCMlk91kAJFA+RODwQaVjRgftChz5qex7YC0FUhawjxlPGHTW/riMxEmRnoUle0t /3qg== X-Gm-Message-State: AHQUAubNqi6Il5reWFdNWuT/k7gEPWA+ZmaMC1j6rPms3GuC/7hDW1yR kdSM8Jl28AdciBOljw8x292goGjDUvl1Yfa+OKI= X-Google-Smtp-Source: AHgI3IbULai/4wQj1zMmeCiVn2X99lujo5dPeS8ZjYmgQWZAcPj7EkfAgKq3o5QSRa0RU2rHzTWnOKAy2os0mB5owS4= X-Received: by 2002:a6b:5b01:: with SMTP id v1mr17242371ioh.12.1549912012307; Mon, 11 Feb 2019 11:06:52 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 11 Feb 2019 11:06:51 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 11 Feb 2019 11:06:51 -0800 Message-ID: Subject: RE: Regarding TLS 1.3 Usage To: Mike Bishop , Mantas Gridinas Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000ed3e200581a3029b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 19:07:03 -0000 --000000000000ed3e200581a3029b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For very constrained devices, TLS is not the ideal protocol. Some of the ciphers in TLS 1.3 may be suitable, such as ChaCha20 and ed25519, but as a whole there is too much overhead. So there is a case for a simpler IoT handshake. Of course, if such a handshake breaks, it is not just reconfiguration of TLS, but a new version of QUIC and HTTP. Mikkel On 11 February 2019 at 18.02.26, Mike Bishop (mbishop@evequefou.be) wrote: (Moving from the draft-specific list to the WG list.) Given the flexibility of TLS, it seems more likely that individual ciphers or (at most) versions would be deprecated rather than TLS as a whole. Both of those things have happened before (see RC4, SSL 3.0; TLS 1.0 and 1.1 are in the process of being deprecated) and HTTPS has survived despite mandating the use of TLS. However, in the extreme case, two things would need to happen: A revision to HTTP/3 permitting it to use versions of QUIC which employ a different handshake protocol, and a new version of QUIC based on something else. That=E2=80=99s because TLS is still being used as a module =E2=80=93 a diff= erent version of QUIC could choose a different handshake protocol that provides the necessary properties and would work just fine (modulo any extensions that assume the availability of a TLS stack). *From:* Mantas Gridinas *Sent:* Monday, February 11, 2019 12:24 AM *To:* draft-ietf-quic-http@ietf.org *Subject:* Regarding TLS 1.3 Usage Hi! I have looked through your document about HTTP/3 and its suggestions to use QUIC as well as TLS 1.3 at transport layer and the following question occurred to me: What will happen if TLS gets deprecated? Will we need an entirely new protocol to replace HTTP/3 once that happens? Wasn't it entire point of SSL and TLS that they wouldn't be packed with any particular protocol, but instead added as a layer? --000000000000ed3e200581a3029b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = For very constrained= devices, TLS is not the ideal protocol. Some of the ciphers in TLS 1.3 may= be suitable, such as ChaCha20 and ed25519, but as a whole there is too muc= h overhead. So there is a case for a simpler IoT handshake. Of course, if s= uch a handshake breaks, it is not just reconfiguration of TLS, but a new ve= rsion of QUIC and HTTP.

Mikkel

On 11 February 2019= at 18.02.26, Mike Bishop (mbishop@= evequefou.be) wrote:

<= span>

(Moving from the draft-specific list to the WG list.= )

=C2=A0

Given the flexibility of TLS, it seems more likely t= hat individual ciphers or (at most) versions would be deprecated rather tha= n TLS as a whole.=C2=A0 Both of those things have happened before (see RC4,= SSL 3.0; TLS 1.0 and 1.1 are in the process of being deprecated) and HTTPS has survived despite mandating the use of T= LS.

=C2=A0

However, in the extreme case, two things would need = to happen:=C2=A0 A revision to HTTP/3 permitting it to use versions of QUIC= which employ a different handshake protocol, and a new version of QUIC bas= ed on something else.=C2=A0 That=E2=80=99s because TLS is still being used as a module =E2=80=93 a different version of QUIC coul= d choose a different handshake protocol that provides the necessary propert= ies and would work just fine (modulo any extensions that assume the availab= ility of a TLS stack).

=C2=A0

From: Mantas Gridinas <mgridinas@gmail.com>
Sent: Monday, February 11, 2019 12:24 AM
To: draft-ietf-quic= -http@ietf.org
Subject: Regarding TLS 1.3 Usage

=C2=A0

Hi!

=C2=A0

I have looked through your document about HTTP/3 and= its suggestions to use QUIC as well as TLS 1.3 at transport layer and the = following question occurred to me: What will happen if TLS gets deprecated?= Will we need an entirely new protocol to replace HTTP/3 once that happens? Wasn't it entire point of SSL and= TLS that they wouldn't be packed with any particular protocol, but ins= tead added as a layer?

--000000000000ed3e200581a3029b-- From nobody Mon Feb 11 11:40:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422DD131163 for ; Mon, 11 Feb 2019 11:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cnyfnt7Yw8lR for ; Mon, 11 Feb 2019 11:40:27 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681E2131164 for ; Mon, 11 Feb 2019 11:40:27 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1BJbKak011701; Mon, 11 Feb 2019 19:40:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=HZZH59c/sqLpOU46UDZZZiVabAwyreWvNGW4cYMGEj0=; b=Ht1guHZLRm0JECUAnGlIYTXXdzWPpICnMngXknVReKbNlR8ZSGbxo95Al1plsEZkLXlH QStP/zVYYCSBugINCa0RWHNX+a91QixDDW577mIWkeII1mGP/TsvP4wTBCcyWuaNY8ID MjHCRoQpXyLVU+tdfEB3Y8lGoqzzZGFE64J9bnidKx6Ot05whVsRW53qdulQI5g8CCJ1 52UkEaqlAkQOnQt0teuaEtBW5dMYgpCvTBCraOWtwa1UV+LZ/wEz19PFW7u5vm83Me3h 2nTrZ2FQQagR6fDz8xz+gQL0s8/V33c6+9kjzfhs/2cEWs8r52LzvHv4/c6+GaiBQ4GR jw== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2qhqd00vme-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Feb 2019 19:40:23 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x1BJVieZ010972; Mon, 11 Feb 2019 14:40:22 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2qhu31ta2a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Feb 2019 14:40:22 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Feb 2019 13:40:21 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1395.000; Mon, 11 Feb 2019 13:40:21 -0600 From: "Salz, Rich" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Mike Bishop , Mantas Gridinas CC: IETF QUIC WG Subject: Re: Regarding TLS 1.3 Usage Thread-Topic: Regarding TLS 1.3 Usage Thread-Index: AQHUwePCgpnlJlG1okeRtwyMRNKoXaXa0YJAgACJL4D//7WKgA== Date: Mon, 11 Feb 2019 19:40:21 +0000 Message-ID: <45672C8E-44EC-4703-8ED3-6CAA8423EB1F@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190203 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.98] Content-Type: multipart/alternative; boundary="_000_45672C8E44EC47038ED36CAA8423EB1Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-11_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=844 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902110142 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-11_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=845 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902110143 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 19:40:30 -0000 --_000_45672C8E44EC47038ED36CAA8423EB1Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkZvciB2ZXJ5IGNvbnN0cmFpbmVkIGRldmljZXMsIFRMUyBpcyBub3QgdGhlIGlkZWFsIHByb3Rv Y29sLiBTb21lIG9mIHRoZSBjaXBoZXJzIGluIFRMUyAxLjMgbWF5IGJlIHN1aXRhYmxlLCBzdWNo IGFzIENoYUNoYTIwIGFuZCBlZDI1NTE5LCBidXQgYXMgYSB3aG9sZSB0aGVyZSBpcyB0b28gbXVj aCBvdmVyaGVhZC4gU28gdGhlcmUgaXMgYSBjYXNlIGZvciBhIHNpbXBsZXIgSW9UIGhhbmRzaGFr ZS4gT2YgY291cnNlLCBpZiBzdWNoIGEgaGFuZHNoYWtlIGJyZWFrcywgaXQgaXMgbm90IGp1c3Qg cmVjb25maWd1cmF0aW9uIG9mIFRMUywgYnV0IGEgbmV3IHZlcnNpb24gb2YgUVVJQyBhbmQgSFRU UA0KDQpJdCB3aWxsIGJlIGludGVyZXN0aW5nIGlmIHRoZSDigJx2ZXJ5IGNvbnN0cmFpbmVkIGRl dmljZeKAnSBjb21tdW5pdHkgc3RhcnRzIHdpdGggYSBrbm93biBxdWFudGl0eSwgYW5kIHRoZW4g cmVtb3ZlcyB0aGUgdGhpbmdzIHRoYXQgdGhleSBiZWxpZXZlIGFyZW7igJl0IG5lZWRlZCwgYW5k IGRvIGl0IOKAnHByb3Blcmx54oCdIHRocmVhdCBtb2RlbCwgcHJvZmlsaW5nLCBwcm90b2NvbCBh bmFseXNpcywgZXRjLiBVbnRpbCB0aGVuLCBJIHRoaW5rIFFVSUMgc2hvdWxkIHN0aWNrIHdpdGgg VExTLg0KDQo= --_000_45672C8E44EC47038ED36CAA8423EB1Fakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <964F3B88FBBB3A4EBDB1E943FE3373B0@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1z dHlsZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZn dDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okhl bHZldGljYSI+Rm9yIHZlcnkgY29uc3RyYWluZWQgZGV2aWNlcywgVExTIGlzIG5vdCB0aGUgaWRl YWwgcHJvdG9jb2wuIFNvbWUgb2YgdGhlIGNpcGhlcnMgaW4gVExTIDEuMyBtYXkgYmUgc3VpdGFi bGUsIHN1Y2ggYXMgQ2hhQ2hhMjAgYW5kIGVkMjU1MTksDQogYnV0IGFzIGEgd2hvbGUgdGhlcmUg aXMgdG9vIG11Y2ggb3ZlcmhlYWQuIFNvIHRoZXJlIGlzIGEgY2FzZSBmb3IgYSBzaW1wbGVyIElv VCBoYW5kc2hha2UuIE9mIGNvdXJzZSwgaWYgc3VjaCBhIGhhbmRzaGFrZSBicmVha3MsIGl0IGlz IG5vdCBqdXN0IHJlY29uZmlndXJhdGlvbiBvZiBUTFMsIGJ1dCBhIG5ldyB2ZXJzaW9uIG9mIFFV SUMgYW5kIEhUVFA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdpbGwgYmUgaW50 ZXJlc3RpbmcgaWYgdGhlIOKAnHZlcnkgY29uc3RyYWluZWQgZGV2aWNl4oCdIGNvbW11bml0eSBz dGFydHMgd2l0aCBhIGtub3duIHF1YW50aXR5LCBhbmQgdGhlbiByZW1vdmVzIHRoZSB0aGluZ3Mg dGhhdCB0aGV5IGJlbGlldmUgYXJlbuKAmXQgbmVlZGVkLCBhbmQgZG8gaXQg4oCccHJvcGVybHni gJ0gdGhyZWF0IG1vZGVsLCBwcm9maWxpbmcsIHByb3RvY29sIGFuYWx5c2lzLCBldGMuIFVudGls IHRoZW4sDQogSSB0aGluayBRVUlDIHNob3VsZCBzdGljayB3aXRoIFRMUy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_45672C8E44EC47038ED36CAA8423EB1Fakamaicom_-- From nobody Mon Feb 11 13:28:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CD0126D00 for ; Mon, 11 Feb 2019 13:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdIyD5Pk9tt6 for ; Mon, 11 Feb 2019 13:28:13 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 B5B31126C15 for ; Mon, 11 Feb 2019 13:28:12 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id d15so751830wmb.3 for ; Mon, 11 Feb 2019 13:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dHnNqXTIxjhRBs9OBKeRIfgE458u86BWytZ6TIvBaZg=; b=JbmXhcO5dqFnrquZlWQqeGXU5O1FmqV625rNGxDvDbChtjX+cToQu5Awpxy3HeAwoC kD9Z/RAlvZ9NmVK0wSGckDcA86s3uh0sfNVxQSRJ9NodqWj1qw36eIN19KTlxplT52UT M2yNk4TUbVmhxCiEz2RfeOjjmAclnzS+RybAvYxoIzng9nQyphmvNdNTOl+26num0YAT nNkkS6kl3G+KfCOgBjkvu2hREnkH1CGrnPC7ZTHgVOPXJ1Dh4O4VADYYiaP1SmbpqwMF iNlRrPO2LP8YzwIxEjYU3KjwYoBc+4Tdq9iiGPW7xDkkdEPAbKqnwLrl9tzF6A+gX0EV xKsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dHnNqXTIxjhRBs9OBKeRIfgE458u86BWytZ6TIvBaZg=; b=Fmn91/6YSmUmXzoyY352oSsC2Xwo95PwKlviX+IOAp6WDnHDhyPvzz4bzvyJc6syMP 3Tcfhlo/JMOGmpznvlp2IRskII5SG0EQ2QHWQRz9TxIrsAUyDmv3S4omYwFUo4Jit7e5 ofRPGP0lCiiusu1fkBwUEfoNKgUl/bt60Y6OhcspP42GCdWfktjUXSoHG16H+EWYUDm2 i560OchMM0ZZwgCD3UTaEaZNPLGIDg7hcBD9zA3XvCv5oWL7b3X1novnrdGRAM/yWTZx oQBol1+JXgf09d+YmCr0oHcWWasd8loIxFs1vJf7xMwtK+4bZUt5OFY4i7Pcur4FRkwj 1AcQ== X-Gm-Message-State: AHQUAuYmfTLFwn8hpsA0fYDQnSSntK9p4JuUHJC8GjbupiYih4USkE26 6pKRlNuivADLxC+pYlpgs2kgXFMum7mWldlh/nk= X-Google-Smtp-Source: AHgI3IaNM9hZn3nFw0XJhypNH00zQoX4teCIONqWALs0JlH033q9iu83CMalOHAI+FY7GYyo+6OPfOjpPfeRhVCy2BI= X-Received: by 2002:a1c:1dd2:: with SMTP id d201mr180167wmd.49.1549920491138; Mon, 11 Feb 2019 13:28:11 -0800 (PST) MIME-Version: 1.0 References: <45672C8E-44EC-4703-8ED3-6CAA8423EB1F@akamai.com> In-Reply-To: <45672C8E-44EC-4703-8ED3-6CAA8423EB1F@akamai.com> From: Martin Duke Date: Mon, 11 Feb 2019 13:27:59 -0800 Message-ID: Subject: Re: Regarding TLS 1.3 Usage To: "Salz, Rich" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Mike Bishop , Mantas Gridinas , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004dfbe90581a4fc52" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 21:28:15 -0000 --0000000000004dfbe90581a4fc52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't believe there's anything stopping people from distributing PSKs using some out-of-band channel and using that for a lighter-weight handshake. On Mon, Feb 11, 2019 at 11:40 AM Salz, Rich wrote: > *>*For very constrained devices, TLS is not the ideal protocol. Some of > the ciphers in TLS 1.3 may be suitable, such as ChaCha20 and ed25519, but > as a whole there is too much overhead. So there is a case for a simpler I= oT > handshake. Of course, if such a handshake breaks, it is not just > reconfiguration of TLS, but a new version of QUIC and HTTP > > > > It will be interesting if the =E2=80=9Cvery constrained device=E2=80=9D c= ommunity starts > with a known quantity, and then removes the things that they believe aren= =E2=80=99t > needed, and do it =E2=80=9Cproperly=E2=80=9D threat model, profiling, pro= tocol analysis, > etc. Until then, I think QUIC should stick with TLS. > > > --0000000000004dfbe90581a4fc52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't believe there's anything stopping people f= rom distributing PSKs using some out-of-band channel and using that for a l= ighter-weight handshake.

On Mon, Feb 11, 2019 at 11:40 AM Salz, Rich &= lt;rsalz@akamai.com> wrote:
<= /div>

>For very constrained devi= ces, TLS is not the ideal protocol. Some of the ciphers in TLS 1.3 may be s= uitable, such as ChaCha20 and ed25519, but as a whole there is too much overhead. So there is a case for a simple= r IoT handshake. Of course, if such a handshake breaks, it is not just reco= nfiguration of TLS, but a new version of QUIC and HTTP=

=C2=A0

It will be interesting if the =E2=80=9Cvery constrai= ned device=E2=80=9D community starts with a known quantity, and then remove= s the things that they believe aren=E2=80=99t needed, and do it =E2=80=9Cpr= operly=E2=80=9D threat model, profiling, protocol analysis, etc. Until then= , I think QUIC should stick with TLS.

=C2=A0

--0000000000004dfbe90581a4fc52-- From nobody Tue Feb 12 01:10:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7B212894E for ; Tue, 12 Feb 2019 01:10:27 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=hI5dOit1; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=uz+7gyHW 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 5EDrOdxgF0YM for ; Tue, 12 Feb 2019 01:10:26 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F033124408 for ; Tue, 12 Feb 2019 01:10:25 -0800 (PST) Received: by mail.greenbytes.de (Postfix, from userid 117) id A361415A0335; Tue, 12 Feb 2019 10:10:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=greenbytes.de; s=mail; t=1549962606; bh=R3dg5Emv3YItdRoiKOGsqPM4Ng0udPp9PSv99q8CF0Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=hI5dOit1nT8o5chMAmMThVHmI3gd3XS6wNZrgDq1IjfkYc9mTP9teM8na3XRLctKf 3z2Pe7I9TztRn2X2/klqEyMfN5WishqYbC1ZKY4LGNmM5f4XxBUfIXxZ76rPj7zzUO VQUCdOMYGtSQbk0IemDjjZp1FNxQ30zo0MsfSyak= Received: from [192.168.1.65] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id AF90315A0335; Tue, 12 Feb 2019 10:10:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=greenbytes.de; s=mail; t=1549962605; bh=R3dg5Emv3YItdRoiKOGsqPM4Ng0udPp9PSv99q8CF0Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=uz+7gyHWaiHHEAN22IJ8n0wHyfZkSpeUBzTTnMg6sP1sXI71lx3I34Gb5w24kPEyA f4YN5yQDuctR2LopkVWNOUdl2DSMtbOOL6Ot0yT9wdhJPXA/5I74cbL8y20xKrSF1X EtbMrMUVKK9wDSh4DBxTca+zZPozI2wRwxm6o6yM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Regarding TLS 1.3 Usage From: Stefan Eissing In-Reply-To: <45672C8E-44EC-4703-8ED3-6CAA8423EB1F@akamai.com> Date: Tue, 12 Feb 2019 10:10:22 +0100 Cc: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Mike Bishop , Mantas Gridinas , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <4A01864D-7A2A-4839-8598-5D5CC3655676@greenbytes.de> References: <45672C8E-44EC-4703-8ED3-6CAA8423EB1F@akamai.com> To: Salz Rich X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 09:10:28 -0000 > Am 11.02.2019 um 20:40 schrieb Salz, Rich : >=20 > >For very constrained devices, TLS is not the ideal protocol. Are those the devices that some years ago could not afford to implement = SSL? It sounds as if these devices always stay just above what the market = would reject right away. Which might be a good business strategy for the = makers, but it seems disconnected from the purpose of this group. - Stefan From nobody Tue Feb 12 13:19:13 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDFD128B36 for ; Tue, 12 Feb 2019 13:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e75nCJGKlUjO for ; Tue, 12 Feb 2019 13:19:10 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 D8737124BF6 for ; Tue, 12 Feb 2019 13:19:09 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id t18so167595wrx.2 for ; Tue, 12 Feb 2019 13:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Zpnpj7BxI7egv/KAQG6eLLZXh5ZzlXFCexDC/d/G3Xc=; b=Izfb9yIXyKPpbWM3gNhWibX2Qa9aZeVgzCrI1ysmtzPDJ1sX/xJrZlgoT5ldPTofNn 5TOgRGIT260EVdZmRZnGEBHs5fGhfGjIOpKoC5ozcwcDF1JQwPIj0Ae0rDxhtmil6V+e pvddfqfZjcXuMFc0eTYtoYU0CJYxAYWBCY8YEOuajr7lL1ZtrXEfsbLItZU2nxCX3VWx uza2qwj1dE8fmqC0j4GfjQFZ1kq+24mDUQHS6z+PPL+GkG4nuBY9EmJpwNxG1oFDzxUN m6aYRJ+9+fHgbd90xswVF4jGWA8XdHbBeJVbfMBAoeRxJRZErFpMC55dH5YymRPPjYuK r0vQ== 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=Zpnpj7BxI7egv/KAQG6eLLZXh5ZzlXFCexDC/d/G3Xc=; b=OSUyWeWzc4/2IYueYhvFf6EZ199xw8tzGNxum1nD7HkQ1jY9y4Lhj4UBNuEqkOkCm8 85ZhIBsNZCD2JDKDF+bBmZvIo0M8Rw2yTY17rfCtWZA4KXuqjz10z3G9ZspbsdsrgYj3 XDRb/m01OJ5Es+nu9apqfpBpcliHyYYCTcAEgyH90C6oPvcGtCIMYgWryVJlFb3Ki2KS lS/lSRmDMS+S7P/cEP1j8RCJYDj5P4EM9mVLOOdPXbfRpqGFiF5iHWfJDkcrh4CzEjA3 xhcv76bCVuFBhbn/5xqdj1Dxjh8y48CauJSCkvh0W6eRlBAai+KfUh/ccQAj3XkyROsQ d4hQ== X-Gm-Message-State: AHQUAuay7JHh8oDdikzxX5lJobfhlQI11wQ2y5qhqGUupr6sfL6oORUB EqgmO1v7sPChyPxq8pcLiOJ0rw7mQ6eAcLTvUQVqeg== X-Google-Smtp-Source: AHgI3IbNAd9BLNdkexS763wuOtt1un0Qb1P3lLe5zGVf823JxFDchD0uRmNiQqTqUB9vijFq7D5y79rhpQHjONvkPOU= X-Received: by 2002:adf:ed0f:: with SMTP id a15mr4414655wro.249.1550006347782; Tue, 12 Feb 2019 13:19:07 -0800 (PST) MIME-Version: 1.0 From: Martin Duke Date: Tue, 12 Feb 2019 13:18:55 -0800 Message-ID: Subject: QUIC ossification To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c25fa50581b8f99e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 21:19:12 -0000 --000000000000c25fa50581b8f99e Content-Type: text/plain; charset="UTF-8" Mark's last call for design issues led me to think about ossification issues. We have done just about everything we can to prevent ossification. There's a thread elsewhere about the QUIC bit, but beyond that I see two big concerns. 1) Version. I can't think of any immediate negative consequences for a middlebox that drops any long header with a version > 1. TLS 1.3 had to surrender to this problem by hiding the version elsewhere. We might avoid this by routinely coalescing long headers with random version fields to connection-critical packets. Beyond that, I'm out of great ideas. If we don't have a robust defense against this, we ought to put some thought into how to deploy a v2 if the version fields is inoperable. 2) Client Transport Parameters. Initial Keys will help a little bit, but in TLS1.3 CCS still sorta exists because middleboxes are inspecting packets so deeply. It's not viable for v2 to have the same transport parameters; it's only slightly less gross to send v2 client TPs in some later message and have to send a fairly bulky "fake" set of v1 TPs in the client hello to get through the network. I don't have great solutions to either of these, but I think these are issues worth discussing given the effort we've put into blocking ossification. If we can't adequately punish misbehaving middleboxes via greasing-like behaviors, then we should at least have contingency plans if the ossifiable fields do, in fact, ossify. If this is a fruitful discussion area, I'm happy to file a github issue. --000000000000c25fa50581b8f99e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mark's last call for design issues led me to thin= k about ossification issues. We have done just about everything we can to p= revent ossification. There's a thread elsewhere about the QUIC bit, but= beyond that I see two big concerns.

1) Version. I= can't think of any immediate negative consequences for a middlebox tha= t drops any long header with a version > 1. TLS 1.3 had to surrender to = this problem by hiding the version elsewhere.

We m= ight avoid this by routinely coalescing long headers with random version fi= elds to connection-critical packets. Beyond that, I'm out of great idea= s. If we don't have a robust defense against this, we ought to put some= thought into how to deploy a v2 if the version fields is inoperable.
=

2) Client Transport Parameters. Initial Keys will help = a little bit, but in TLS1.3 CCS still sorta exists because middleboxes are = inspecting packets so deeply. It's not viable for v2 to have the same t= ransport parameters; it's only slightly less gross to send v2 client TP= s in some later message and have to send a fairly bulky "fake" se= t of v1 TPs in the client hello to get through the network.
<= br>
I don't have great solutions to either of these, but I th= ink these are issues worth discussing given the effort we've put into b= locking ossification. If we can't adequately punish misbehaving middleb= oxes via greasing-like behaviors, then we should at least have contingency = plans if the ossifiable fields do, in fact, ossify.

If this is a fruitful discussion area, I'm happy to file a github iss= ue.
--000000000000c25fa50581b8f99e-- From nobody Tue Feb 12 13:35:39 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42915130DC2 for ; Tue, 12 Feb 2019 13:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=R1X/e50n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EFRGUsQ3 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 X1zOrFHK4C92 for ; Tue, 12 Feb 2019 13:35:34 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF5F128CF2 for ; Tue, 12 Feb 2019 13:35:33 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4867B2223B for ; Tue, 12 Feb 2019 16:35:33 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Tue, 12 Feb 2019 16:35:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=AvB iNZlTq69uY6kyoiAwF4IkbsxR5xp6Cdv7ih7v5iw=; b=R1X/e50njSDGJm5Y10q ElBdGTiLt2kCgBEjmeYc+KixZe160UMuxONWB3TMvQWMYAAvpH/yGxlxnlUxZVB1 Is34G3nuEeaZStTXPjtGBytqNWt0DQ387kji5tteOiFJstiR+JvSCUjUXXTRkMLL Z1/MsT2AoiS1YDMW/Hu4ZX1pDbC2snZ+OuXFLDOt3NEUy/eDtL5BwI4P6JQ5kIQa W9YeD8XXttughnvUPRvt08acCwzwHv4xC2qTlCihusW/O+inykYtO833vEcui548 0a+GYVWfpIHEc1EloMKsFGo3DJm02Q13reWwlqOe+pQmfeBqncIdEnW7uyff4r4s IfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=AvBiNZlTq69uY6kyoiAwF4IkbsxR5xp6Cdv7ih7v5 iw=; b=EFRGUsQ3tEa/MB6qsTJ6uZGIrN4cRGN28FhH+vMpq2p+fHmYih2GkUF0Q 0an/wYY05FT0eufw5McbAueCH2W0zUfk+qblyrQIpTrIjpIKzS80LMbrTOxrlc/t vadHb/7SfnLu3+2Ar1mDz7gFybd2kSZV3Px1cyek3QnjAMxtAI3mbJQ4ixFtR62c uqsQ8EYXDJiFFCR1nyn4PhjkRLs//bSrpgxDRhwgW2ZZk2zLU6/gW6xhapF4Fu0J Hq7y2W2Xp+4zsfQUWh01F8XDzuwodBICJtIEfMIsL9Tgz8sjp9j8Y7UPmI26ewg8 lmh6OAjqbh1k9Pz3k84VPeiUu/0Yg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtuddgudehvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucenucfjughrpefkhffvggfgtgfofhfujgffsehtjeertdertdejnecuhfhroh hmpeforghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvght qeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth enucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A24B29E5C9; Tue, 12 Feb 2019 16:35:32 -0500 (EST) Message-Id: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 References: Subject: Re: QUIC ossification In-Reply-To: Date: Wed, 13 Feb 2019 08:35:32 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 21:35:37 -0000 On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote: > 1) Version. I can't think of any immediate negative consequences for a > middlebox that drops any long header with a version > 1. TLS 1.3 had to > surrender to this problem by hiding the version elsewhere. > > We might avoid this by routinely coalescing long headers with random > version fields to connection-critical packets. Beyond that, I'm out of > great ideas. If we don't have a robust defense against this, we ought to > put some thought into how to deploy a v2 if the version fields is > inoperable. As Mike points out, the Length field is version-specific, so there is no real defense here other than - as many have suggested - using the version field actively. That means shipping another version. In a sense, the fact that Google are still not on the same version gives us some time, but it could mean that we might want to look toward having the "add version negotiation and fallback protection" draft define a version rather than an extension. > 2) Client Transport Parameters. Initial Keys will help a little bit, but in > TLS1.3 CCS still sorta exists because middleboxes are inspecting packets so > deeply. It's not viable for v2 to have the same transport parameters; it's > only slightly less gross to send v2 client TPs in some later message and > have to send a fairly bulky "fake" set of v1 TPs in the client hello to get > through the network. I'm not concerned about transport parameters if the above issue is fixed. TLS had no real issues with extensions, and it looks like we already have the start of a pipeline of extensions coming. v2 can share the transport parameter extension, unless we decide to change the format in a non-compatible way. (Note: CCS in TLS 1.3 only exists because middleboxes were inspecting a lot, yes, but it also indicates that they weren't inspecting enough, because the compatibility hack we have wouldn't work if they did a proper job.) From nobody Tue Feb 12 13:54:05 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66222130DC2 for ; Tue, 12 Feb 2019 13:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hq3Eo03_uGFV for ; Tue, 12 Feb 2019 13:54:02 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B5112F1A6 for ; Tue, 12 Feb 2019 13:54:01 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id q1so220846wrp.7 for ; Tue, 12 Feb 2019 13:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iJibG5RVy83dNg2o7jNbWX6bqEoR8Z55JMT2MwgUfwg=; b=UfZs1A8La2lixoPkbYT55CN34ijSX3uHPFMLmflGBoIOJcxA+LSvZDmcfG6C2aRdQa floiVZLvgbG7d6t6MKtRTOf3t3GxztsOpMWiCrFN0z4JfG7oO+QdSO9IESoJYnRJWI5N fptoxGPHEoY8f/xZ/OwvQi2yhfdDYx2R1VwMN6q/8nViiHRsjupSVP0hAsXQYiqjR91O dq7NoA8qzzonWfoEZlmnVFEwJN2IQD/nYxzrwuZ9WWCsprD3ebuihqlCN6wVKGkyeb4q Y76DcuHvZiw9877qsZKkHNGeEFBqXC3adgfxukNLmT2VqKIhotAB9di1IR8vNzt8a0Zt XxtQ== 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=iJibG5RVy83dNg2o7jNbWX6bqEoR8Z55JMT2MwgUfwg=; b=E5H/aNvped8OUCzvwexJX7v8wk5VpmskMBdjJvWyuDPVik09x6ou/USyYl2dyPrkXL oN02HlC+HnFk3nT92O3JoMQyuRcbzFVHpKGdiHiSlg9vzl1VbprgsNxLuWWOFe3llNJh 9SpNeQGfAFpCGyZR4jOthAcgMJOU93fhwvVe6MKgLkh42b52N7CvME5zuTKUiJokp0FQ bdcqLMPDXeOuryqG53MKqDGaOBKL87PhM6Yu4ttoBG+K/Nmn5JwJIBpVMkdxqgFS/ADP xCvIXfd3EbDBseEcsTUwgM4aVdk8I3J7MUGDFFC8SX3n65pD5YJ5TVnZIokU62T5sOBw JelA== X-Gm-Message-State: AHQUAubLNDKQzxgMUy7ODfItMdML23a9HrwPPz0ffdYuMUZNIGS3SZun z26MfoY0SfZTXajx112dMxEyO9CbdWMHndfya/QjTQ== X-Google-Smtp-Source: AHgI3IbaQpKAXjC3RSPmb3SegtJO3sVhyYtaCxbrn9ftbLRpn56kzGqG5OP+eDQWS2r54KPaBiPtASy6QcM4U4pd8jg= X-Received: by 2002:a5d:4149:: with SMTP id c9mr4716607wrq.58.1550008439772; Tue, 12 Feb 2019 13:53:59 -0800 (PST) MIME-Version: 1.0 From: Martin Duke Date: Tue, 12 Feb 2019 13:53:48 -0800 Message-ID: Subject: Eight CIDs? To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000739d4b0581b976dc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 21:54:03 -0000 --000000000000739d4b0581b976dc Content-Type: text/plain; charset="UTF-8" Can someone point me to the discussion where we decided that we needed 8 CIDs? That seems really high to me. --000000000000739d4b0581b976dc Content-Type: text/html; charset="UTF-8"
Can someone point me to the discussion where we decided that we needed 8 CIDs? That seems really high to me.
--000000000000739d4b0581b976dc-- From nobody Tue Feb 12 14:14:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A4E130DE3 for ; Tue, 12 Feb 2019 14:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=FcgLmGXO; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=RPTamBNr 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 SFQUiuR0GhpZ for ; Tue, 12 Feb 2019 14:14:54 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 D5F3F130DD8 for ; Tue, 12 Feb 2019 14:14:53 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.27/8.16.0.27) with SMTP id x1CME1th023403; Tue, 12 Feb 2019 14:14:52 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=Zq4Mvcq8jMMSgqmjLFO6o1oZMKcS4f4cPaxyBxAm0wE=; b=FcgLmGXOE4xIl0W1FcsMLA7Iwt1qNxUhwt47kRo2R0Ih0eSmxNNmptp8UlFmD+ZVryX0 JXMj0lZ2fC4E0BC1IvnYk769/wtNZN7nm6SKFfxm2f07NJ/oT4NGefOU3M498Y7EKq5s uPcSY6E108I1qA0b9hSXytJeITqhgyGed+w= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2qm48brhyn-13 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 12 Feb 2019 14:14:52 -0800 Received: from prn-mbx01.TheFacebook.com (2620:10d:c081:6::15) by prn-hub01.TheFacebook.com (2620:10d:c081:35::125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 12 Feb 2019 14:14:27 -0800 Received: from prn-hub03.TheFacebook.com (2620:10d:c081:35::127) by prn-mbx01.TheFacebook.com (2620:10d:c081:6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 12 Feb 2019 14:14:27 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Tue, 12 Feb 2019 14:14:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zq4Mvcq8jMMSgqmjLFO6o1oZMKcS4f4cPaxyBxAm0wE=; b=RPTamBNrErvZ4OcEWNrL/yOZL4dNnWu+jzBqndGs0JkqWknxkmvfLCc/wRptoSaZ3W3Ck5jrp4ZpIjef6w6REtDOPZefWFxf1UEf7kQRbw09+S9/OBz5GKEdczqlOywhOHRmgiI1LLuO1zEcle3/K+93BLC8KMpndFFn3QEHAsM= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2373.namprd15.prod.outlook.com (52.135.198.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Tue, 12 Feb 2019 22:14:25 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084%5]) with mapi id 15.20.1601.023; Tue, 12 Feb 2019 22:14:25 +0000 From: Roberto Peon To: Martin Thomson , "quic@ietf.org" Subject: Re: QUIC ossification Thread-Topic: QUIC ossification Thread-Index: AQHUwxih7UYarYoV30WBSlEhJDleK6Xcr5EA//+EwAA= Date: Tue, 12 Feb 2019 22:14:25 +0000 Message-ID: <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> In-Reply-To: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::7:55b7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2764fc57-212c-4447-52be-08d6913772f0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2373; x-ms-traffictypediagnostic: BYAPR15MB2373: x-microsoft-exchange-diagnostics: 1; BYAPR15MB2373; 20:6oaOrHRp47mwBE1iRxTuu62wBm8BLQ8/kqrdkVCqHWYfoIxVkhGDPHz9xtuIh0gSaxfclgvOh7Nr2R2EiAVMMFOYWRABFKqW1nkjgv01E9WpHnkCzaubvMd9eRGen22Q/OEhN8h9IJ6jz/9q1eq/jburo7SnKnhrzSQfULLUqEQ= x-microsoft-antispam-prvs: x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(39860400002)(346002)(376002)(199004)(189003)(36756003)(8936002)(476003)(76176011)(7116003)(186003)(99286004)(81166006)(8676002)(81156014)(6116002)(83716004)(256004)(25786009)(97736004)(53936002)(2616005)(11346002)(46003)(6506007)(478600001)(316002)(102836004)(446003)(221733001)(86362001)(105586002)(6436002)(305945005)(33656002)(7736002)(68736007)(6486002)(2906002)(106356001)(14454004)(6246003)(71190400001)(3480700005)(58126008)(110136005)(82746002)(486006)(6512007)(229853002)(2501003)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2373; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cZW5ACuzYBC7w1ChPUnfHXwHVPq2z2FKLtS2BljLhQ4stHmYJZ+ct5DL8PB+RpqUe1iq9qh4teACb3QsOu80dUynUrgU/ETZcWq7xs2Msq9Yx3GjIFItp5Pz/02Zrme46b49l+/fMPIyzlNo3+bRdoEB1OLTwsk0vCGovJeERL83+MPdWcaKRLTZYqs876Q1rZmuIgZpnDBSLiTLqYwXYoPCgG2uQgidbWZMI9Gdzld84pZ0BihxtlqbDM3Q2X4htLi2AuOcZ2UnQiBzNr9LrIzkW3uOC3xjcIz4WBgZy9LTjWoKefnsijZgt8+/3UL4vrOdHYetQupU3aijMVt0Cy9L/zv3toO1UCYHffMMKqZBY3pa2lpWHsNQZFxiqW/oymyy8BeGeq4zgU+dJZKVCpTzWC/xgGAYY7emhsGTiRs= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2764fc57-212c-4447-52be-08d6913772f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2019 22:14:25.6154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2373 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-12_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 22:14:55 -0000 TXkgZmVhci9leHBlcmllbmNlIGFyb3VuZCB0aGlzIGlzIHdoeSBJJ2Qgc3Ryb25nbHkgcmVjb21t ZW5kIGRvaW5nIGEgUVVJQyBWMiBhcyBzb29uIGFzIHBvc3NpYmxlIHdoZXJlIHRoZSBkZWx0YSBm cm9tIFYxIC0+IFYyIGlzIGxpbWl0ZWQgdG8gKnNvbGVseSogd2hhdCBpcyBuZWNlc3NhcnkgZm9y IHZlcnNpb24gbmVnb3RpYXRpb24uIA0KDQpXZSBjYW4gc2ltdWx0YW5lb3VzbHkgaGF2ZSBhIFYz IGNvbnZlcnNhdGlvbiB3aGljaCB3b3VsZCAgaW5jbHVkZSB3aGF0ZXZlciBlbHNlIHdlIGRlY2lk ZSB3ZSBuZWVkIHRvIGNoYW5nZS9hZGQgYXMgYSBzZXBhcmF0ZSBjb252ZXJzYXRpb24gd2hpY2gg ZGVwZW5kcyBvbiBWMi4NCg0KLT1SDQoNCu+7v09uIDIvMTIvMTksIDE6MzYgUE0sICJRVUlDIG9u IGJlaGFsZiBvZiBNYXJ0aW4gVGhvbXNvbiIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgbXRAbG93ZW50cm9weS5uZXQ+IHdyb3RlOg0KDQogICAgT24gV2VkLCBGZWIgMTMsIDIw MTksIGF0IDA4OjE4LCBNYXJ0aW4gRHVrZSB3cm90ZToNCiAgICA+IDEpIFZlcnNpb24uIEkgY2Fu J3QgdGhpbmsgb2YgYW55IGltbWVkaWF0ZSBuZWdhdGl2ZSBjb25zZXF1ZW5jZXMgZm9yIGENCiAg ICA+IG1pZGRsZWJveCB0aGF0IGRyb3BzIGFueSBsb25nIGhlYWRlciB3aXRoIGEgdmVyc2lvbiA+ IDEuIFRMUyAxLjMgaGFkIHRvDQogICAgPiBzdXJyZW5kZXIgdG8gdGhpcyBwcm9ibGVtIGJ5IGhp ZGluZyB0aGUgdmVyc2lvbiBlbHNld2hlcmUuDQogICAgPiANCiAgICA+IFdlIG1pZ2h0IGF2b2lk IHRoaXMgYnkgcm91dGluZWx5IGNvYWxlc2NpbmcgbG9uZyBoZWFkZXJzIHdpdGggcmFuZG9tDQog ICAgPiB2ZXJzaW9uIGZpZWxkcyB0byBjb25uZWN0aW9uLWNyaXRpY2FsIHBhY2tldHMuIEJleW9u ZCB0aGF0LCBJJ20gb3V0IG9mDQogICAgPiBncmVhdCBpZGVhcy4gSWYgd2UgZG9uJ3QgaGF2ZSBh IHJvYnVzdCBkZWZlbnNlIGFnYWluc3QgdGhpcywgd2Ugb3VnaHQgdG8NCiAgICA+IHB1dCBzb21l IHRob3VnaHQgaW50byBob3cgdG8gZGVwbG95IGEgdjIgaWYgdGhlIHZlcnNpb24gZmllbGRzIGlz DQogICAgPiBpbm9wZXJhYmxlLg0KICAgIA0KICAgIEFzIE1pa2UgcG9pbnRzIG91dCwgdGhlIExl bmd0aCBmaWVsZCBpcyB2ZXJzaW9uLXNwZWNpZmljLCBzbyB0aGVyZSBpcyBubyByZWFsIGRlZmVu c2UgaGVyZSBvdGhlciB0aGFuIC0gYXMgbWFueSBoYXZlIHN1Z2dlc3RlZCAtIHVzaW5nIHRoZSB2 ZXJzaW9uIGZpZWxkIGFjdGl2ZWx5LiAgVGhhdCBtZWFucyBzaGlwcGluZyBhbm90aGVyIHZlcnNp b24uICBJbiBhIHNlbnNlLCB0aGUgZmFjdCB0aGF0IEdvb2dsZSBhcmUgc3RpbGwgbm90IG9uIHRo ZSBzYW1lIHZlcnNpb24gZ2l2ZXMgdXMgc29tZSB0aW1lLCBidXQgaXQgY291bGQgbWVhbiB0aGF0 IHdlIG1pZ2h0IHdhbnQgdG8gbG9vayB0b3dhcmQgaGF2aW5nIHRoZSAiYWRkIHZlcnNpb24gbmVn b3RpYXRpb24gYW5kIGZhbGxiYWNrIHByb3RlY3Rpb24iIGRyYWZ0IGRlZmluZSBhIHZlcnNpb24g cmF0aGVyIHRoYW4gYW4gZXh0ZW5zaW9uLg0KICAgICANCiAgICA+IDIpIENsaWVudCBUcmFuc3Bv cnQgUGFyYW1ldGVycy4gSW5pdGlhbCBLZXlzIHdpbGwgaGVscCBhIGxpdHRsZSBiaXQsIGJ1dCBp bg0KICAgID4gVExTMS4zIENDUyBzdGlsbCBzb3J0YSBleGlzdHMgYmVjYXVzZSBtaWRkbGVib3hl cyBhcmUgaW5zcGVjdGluZyBwYWNrZXRzIHNvDQogICAgPiBkZWVwbHkuIEl0J3Mgbm90IHZpYWJs ZSBmb3IgdjIgdG8gaGF2ZSB0aGUgc2FtZSB0cmFuc3BvcnQgcGFyYW1ldGVyczsgaXQncw0KICAg ID4gb25seSBzbGlnaHRseSBsZXNzIGdyb3NzIHRvIHNlbmQgdjIgY2xpZW50IFRQcyBpbiBzb21l IGxhdGVyIG1lc3NhZ2UgYW5kDQogICAgPiBoYXZlIHRvIHNlbmQgYSBmYWlybHkgYnVsa3kgImZh a2UiIHNldCBvZiB2MSBUUHMgaW4gdGhlIGNsaWVudCBoZWxsbyB0byBnZXQNCiAgICA+IHRocm91 Z2ggdGhlIG5ldHdvcmsuDQogICAgDQogICAgSSdtIG5vdCBjb25jZXJuZWQgYWJvdXQgdHJhbnNw b3J0IHBhcmFtZXRlcnMgaWYgdGhlIGFib3ZlIGlzc3VlIGlzIGZpeGVkLiAgVExTIGhhZCBubyBy ZWFsIGlzc3VlcyB3aXRoIGV4dGVuc2lvbnMsIGFuZCBpdCBsb29rcyBsaWtlIHdlIGFscmVhZHkg aGF2ZSB0aGUgc3RhcnQgb2YgYSBwaXBlbGluZSBvZiBleHRlbnNpb25zIGNvbWluZy4gIHYyIGNh biBzaGFyZSB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlciBleHRlbnNpb24sIHVubGVzcyB3ZSBkZWNp ZGUgdG8gY2hhbmdlIHRoZSBmb3JtYXQgaW4gYSBub24tY29tcGF0aWJsZSB3YXkuDQogICAgDQog ICAgKE5vdGU6IENDUyBpbiBUTFMgMS4zIG9ubHkgZXhpc3RzIGJlY2F1c2UgbWlkZGxlYm94ZXMg d2VyZSBpbnNwZWN0aW5nIGEgbG90LCB5ZXMsIGJ1dCBpdCBhbHNvIGluZGljYXRlcyB0aGF0IHRo ZXkgd2VyZW4ndCBpbnNwZWN0aW5nIGVub3VnaCwgYmVjYXVzZSB0aGUgY29tcGF0aWJpbGl0eSBo YWNrIHdlIGhhdmUgd291bGRuJ3Qgd29yayBpZiB0aGV5IGRpZCBhIHByb3BlciBqb2IuKQ0KICAg IA0KICAgIA0KDQo= From nobody Tue Feb 12 15:17:14 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2B0129AA0 for ; Tue, 12 Feb 2019 15:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-p13anm7_tP for ; Tue, 12 Feb 2019 15:17:10 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 1B325126C15 for ; Tue, 12 Feb 2019 15:17:10 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id i12so445703wrw.0 for ; Tue, 12 Feb 2019 15:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DAM2rbM+xZ3ljyPDttZo+Sg0CjX57hwQKU8lE+wPaeI=; b=IbCSkXrhHLNJFwbpG7Grb2/h9FAPOVPFJmsuY4mIbEOfNKb0lUmkBP7fnDNDOzWgAq DcpPHLiT8jcNfO9hu1D28o33JcuF8im1sMLUodGijIHel6mboNxkcsHPWkEvNzOsIHTB /JNECSIsHiXQUMh+AVqog5z2AETWL3oR3eaQ3WAutQGkiY41mUfFtgsUA1JOCGpD7nVm 1BmQs4/wKzhg0Scjp7K2zLoXjVRuZrbXf1EXIxkxsAoaH1cnb6kRNr9w6yq5tPHqd1L7 Q0k3DhnNCtEBigjwl+LRQ39XgSSAcVrkAFIq0zhNN9Z7p6Jo2LzZIu4EotJa22K4akA0 hJLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DAM2rbM+xZ3ljyPDttZo+Sg0CjX57hwQKU8lE+wPaeI=; b=mCA8c0RIU92z96TxZlzJFOYDdlw4mJN2mzDDzKwr74xG28MnKBth4zuXXeZhRWKUle pwb7+haSUh9+4CnrVIVKcHnnihDrMHZKGUUFWgfC287c9WmVtiKB3+k7x2kDGAiL7KzU 3Iic3Q6F7ZtjSC8zADdElWjHtXhu4Nhc7GIaOjX/7TeGZPW3AultXA91Cci/0ikwGTdZ 6RvzXBZWSgHR4eZfJ4zRyYpSKKUY9c1cMz9ulw3GIVhpJ37ijQYYtGu+B4FasdktHim8 0+A3EwJNNMjECSuDaEdCe+3SthN1hTiyqHXpFrcJRP5T3rQxB56JS2PbIExct0KUF40K AaOA== X-Gm-Message-State: AHQUAubKQNmPibIiBcNZjAzEhEHFdNifIxqX93XjTMMURxY4hBuWZZzl UErPdpbBcVZOUP/onSuP7mZPjrzwEvxx4YB6eBvxOg== X-Google-Smtp-Source: AHgI3IZatceCXFleYQUuwksQOnLJvbvpqRaGmcfpE808HKAnhAvjEc5WUwebX9HoAIxRQDOweeI/Ms1IlYZdKumUJwc= X-Received: by 2002:adf:fa51:: with SMTP id y17mr4888393wrr.233.1550013428300; Tue, 12 Feb 2019 15:17:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Tue, 12 Feb 2019 18:16:55 -0500 Message-ID: Subject: Re: Eight CIDs? To: Martin Duke Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000cb019b0581ba9fb5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 23:17:12 -0000 --000000000000cb019b0581ba9fb5 Content-Type: text/plain; charset="UTF-8" I'm not aware of an on-list discussion, but PR#1998 will remove that recommendation and replace it with a transport parameter once it lands. I agree that 8 seems extremely high. On Tue, Feb 12, 2019 at 4:54 PM Martin Duke wrote: > Can someone point me to the discussion where we decided that we needed 8 > CIDs? That seems really high to me. > --000000000000cb019b0581ba9fb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not aware of an on-list discussion, but PR#1998 will remove t= hat recommendation and replace it with a transport parameter once it lands.=

I agree that 8 seems extremely high.

On Tue, Feb 1= 2, 2019 at 4:54 PM Martin Duke <martin.h.duke@gmail.com> wrote:
Can someone point me to the disc= ussion where we decided that we needed 8 CIDs? That seems really high to me= .
--000000000000cb019b0581ba9fb5-- From nobody Tue Feb 12 15:19:09 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304601277CC for ; Tue, 12 Feb 2019 15:19:08 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uaLQcipoCM4 for ; Tue, 12 Feb 2019 15:19:06 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770124.outbound.protection.outlook.com [40.107.77.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84847126C01 for ; Tue, 12 Feb 2019 15:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lv2N6N7xiWaRNFtWmQEfZtTTPd+ow5RzQXKcCv8G4LE=; b=Sc3DbipKbFQ5ImfXSbATj9Bf9P8oMGU2Dfm8pJlVn4UQP4siphfRl0h527zGyl8YeMOHQZkHAQm/B0flVGBCOhTWvOQeJ2bMncXQqRXnCfMgwbQabPV33siC2G2lU8dLeyx/01wmGDEiTrXOeCzQmj/A7h6Euri5ADbSpNq8TOc= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0008.namprd22.prod.outlook.com (10.169.187.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Tue, 12 Feb 2019 23:19:03 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2%4]) with mapi id 15.20.1622.016; Tue, 12 Feb 2019 23:19:03 +0000 From: Mike Bishop To: Ian Swett , Martin Duke CC: IETF QUIC WG Subject: RE: Eight CIDs? Thread-Topic: Eight CIDs? Thread-Index: AQHUwx2CEhzsdzNYPkOs0OejRLzrgKXcy9uAgAAANjA= Date: Tue, 12 Feb 2019 23:19:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:600:8080:701:d8e1:f0fc:6e6:3711] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c44e6331-7978-49de-9366-08d691407a2e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0008; x-ms-traffictypediagnostic: CY4PR22MB0008: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(136003)(396003)(376002)(366004)(346002)(189003)(199004)(790700001)(6116002)(316002)(7736002)(7116003)(46003)(606006)(6246003)(53546011)(33656002)(446003)(6506007)(102836004)(53936002)(508600001)(186003)(99286004)(6346003)(7696005)(14454004)(76176011)(486006)(74316002)(2906002)(110136005)(25786009)(4326008)(74482002)(8936002)(11346002)(106356001)(476003)(3480700005)(6306002)(54896002)(105586002)(55016002)(6436002)(71200400001)(71190400001)(256004)(236005)(97736004)(4744005)(68736007)(81156014)(81166006)(8676002)(229853002)(9686003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0008; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTRQUjIyTUIwMDA4OzIzOjNSUGZhOFVnRkFhaDFaemluTFlpSUpqaVVL?= =?utf-8?B?SUVKMkRicE1vVUtiU2lzY2ZPNVBJY0Myb0NHSW9MN05PTDcwQzlqSjUyQ1h2?= =?utf-8?B?eU5HSjRmVTk1V2JJRVBWbkp1cEIvN0NLVVpjV1JrUGo0OUl6Y3RMa3dnZlJs?= =?utf-8?B?STBGTnl1VVF5cUxRcThETFREWG9iUDhHc0JCaXdJTnNjc1g1dTVaaWdYWkpY?= =?utf-8?B?enYzTzRRVkpOTGJITmZoZWw5dXZXblkvVGZSVnV0QkZ4b1FZckVsQTdEdFl6?= =?utf-8?B?ZGZRQURKNlVUZlJtNk92Rk5OSEJPTGttWjVKc2tpR3BPZzNhK2h2c3d4cTVm?= =?utf-8?B?aXRLYWZ3UWE2K3UvMGszeG1UTGEyWnZieDdPTk1sSWlRNURHNTNBRmNiRVRK?= =?utf-8?B?Sk9GT0pvNmg0M1hWaTQzeW8xOXJrSjZwZmJ4ZVBpNnZMY0pPVVdSRldiYXpN?= =?utf-8?B?Y2huT0dIY1M0N0R0Tk91QUdnd2dDMkEydDNRR0V5bTVDWWlQUWJRcDAwalFV?= =?utf-8?B?MHFobFNVNkVCRjRCTzJXVDNnNUJsNE9laWY3cmpVWFlSanVnTlJvWGozQTJV?= =?utf-8?B?dnFiaUtrM0xzOEdMYTNFckQ5TENHSUxhOGFYbEoxekw1dWhoT1RUMTB5NWpZ?= =?utf-8?B?RzRjeEY0bzdzMFZLTi9TeUJIWHBRZmptZ3ZPNjhWSmdJTDJCUW8wT1lEZzlh?= =?utf-8?B?T29HeEFvQ1lkaloxY1BobzB5cEpUU3VHaC8rb1RKZ1IvVzNZaGI3TDFVUVFk?= =?utf-8?B?RkF1MGJBOFI4U2g3UGFpSGlhaEN6OHR4VnVoZTZxMWp3cEtPQ25mV3pyNHho?= =?utf-8?B?Mmp3TkFZODE0VUsrZEhuekxuSFRrTE5MRHRJbFVSVUJiZXhvRWVzUzJ6cFBU?= =?utf-8?B?NG1WaVR2RjVmNUdldWIyU3hWNFJUUlhhVC9haEFDM1V6dHBPTER4Z3psNmdH?= =?utf-8?B?QzNSQ1NNU2ZnK250eVRjNytVTWVxMkxXN0hlVStpMnRlRHVFNnFXMVJSUkRO?= =?utf-8?B?Mm1QSXFGRUZUTXhsSXAybUNQR2R3RkE2aWF6OFpzZFNCejFFQ2hzNHg5SnJa?= =?utf-8?B?MG9XeU1qMkprc1JKVHNLSnovWkluektoOHo5RmJsVWZtTjBJRS9GWVVsQmJo?= =?utf-8?B?Z204VzdyRnpJaERtTG1oK0h5bWhZVTZGY05zVmZHRi9pajBua0h4U1o0d0RD?= =?utf-8?B?N2w3S3BSTWxGZldMdUlWMWhESDBLMG01WVcybW1OcFBBL1owVHoyOTllQllO?= =?utf-8?B?MGR4ZDY4TWRmbGhnNENnV2RyRkZ4dTU5cnVsajd4aXdKdEVtbjBMUDRISkZP?= =?utf-8?B?eU9wZng2aDl6b3AwZjRWYWZrWVBHTXpKbldNdDBpVjZ5ZEp2T1FBbVdjM2Jl?= =?utf-8?B?M2lneENnM21YRXp2OEgxWStVUlJTbEF0ellEU0dneTFSY3ViN25QdFFwNUhC?= =?utf-8?B?TTBhbVp4bnNHZ3JJUmIyZHRiTnErTEZZei8vVVgySWZZMHp2S2lnYTl3Y3o1?= =?utf-8?B?VVpIbmJqUDZJdEVZOFJLbzFmcC9QQjI5VHdnK0U3L3VscFJvYys3dGxYQlA0?= =?utf-8?B?cUlWR1dLNnVKekJrRDVhVXc0dC9YRHVPYmh2TlJ2Yzc1alA1WTYwa3JuKyt2?= =?utf-8?B?MHNBSnpMK0t6YnA0d1E0RCtISzZwdzBLV0dkUVQvSDVOTmtIc0g4MytxdmJL?= =?utf-8?B?QVNQN2V5c0JNMm9kZmdDYlBYaWRKcWRLc2M4ZzZlYWNibEdEcDZoSnVKNVpm?= =?utf-8?B?UEl5NjY0NVdnQ0VUSnFCUT09?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YKm9XY4+80q3OZBsaVH6zrYpsDJtAuz8iNJ8DSyPaKRTy9ceWv0ObcZpMosZUgcsEVjZQqJEuoBscSuMDE6TJeV4GrD+LO3gllYlccLqqdP2KV8TIUNIzOFyiUKUIyMl0C32ckl/mGFSL1JaHmwNZs8YX2CMZ5FHwi/yT1InMx7GW/RIGALRk5MD1VrHl0Dc0r2EkB8kQSUr7ttLA8SFinaHx38/CPP7vIDqGKncLtcRrRTRG2KgtQpKVMCRd6+tGl0CfN29MwMufJ+FHb3Y5lGAAFlGks24dqw1ws6ykbllZkgCkiK2CFzYS6HlWOWGVqYSaLBkDq+DO3KaJZY6a5sIvgCsOl1sJxesWwUSjHbabXj5TZu/lwjTNaluoAwPKLCp7l0bA1Y1XVMHrbJ1if/dBhqnbOWVJRnKruu+cCM= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983DE366ED92040D87703B6DA650CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: c44e6331-7978-49de-9366-08d691407a2e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2019 23:19:02.9978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0008 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 23:19:08 -0000 --_000_CY4PR22MB0983DE366ED92040D87703B6DA650CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhlIENJRCBkZXNpZ24gdGVhbSwgdHdvIHBlb3BsZSBjYW1lIHVwIHdpdGggdGhhdCBudW1i ZXIgaW5kZXBlbmRlbnRseSBhcyBhIGZpbmdlci1pbi1haXIgZ3Vlc3MuICBJdCB3ZW50IGluIHRo ZSBQUiBhbmQgaGFzIHN0dWNrIGZvciBsYWNrIG9mIGEgY29tcGVsbGluZyBhbHRlcm5hdGl2ZS4g ICMxOTk4IGlzIHRoZSBtb3N0IGxpa2VseSBjb21wZWxsaW5nIGFsdGVybmF0aXZlLg0KDQpGcm9t OiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNl bnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE5IDM6MTcgUE0NClRvOiBNYXJ0aW4gRHVrZSA8 bWFydGluLmguZHVrZUBnbWFpbC5jb20+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IEVpZ2h0IENJRHM/DQoNCkknbSBub3QgYXdhcmUgb2YgYW4gb24tbGlz dCBkaXNjdXNzaW9uLCBidXQgUFIjMTk5ODxodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2Ut ZHJhZnRzL3B1bGwvMTk5OD4gd2lsbCByZW1vdmUgdGhhdCByZWNvbW1lbmRhdGlvbiBhbmQgcmVw bGFjZSBpdCB3aXRoIGEgdHJhbnNwb3J0IHBhcmFtZXRlciBvbmNlIGl0IGxhbmRzLg0KDQpJIGFn cmVlIHRoYXQgOCBzZWVtcyBleHRyZW1lbHkgaGlnaC4NCg0KT24gVHVlLCBGZWIgMTIsIDIwMTkg YXQgNDo1NCBQTSBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb208bWFpbHRvOm1h cnRpbi5oLmR1a2VAZ21haWwuY29tPj4gd3JvdGU6DQpDYW4gc29tZW9uZSBwb2ludCBtZSB0byB0 aGUgZGlzY3Vzc2lvbiB3aGVyZSB3ZSBkZWNpZGVkIHRoYXQgd2UgbmVlZGVkIDggQ0lEcz8gVGhh dCBzZWVtcyByZWFsbHkgaGlnaCB0byBtZS4uDQo= --_000_CY4PR22MB0983DE366ED92040D87703B6DA650CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J biB0aGUgQ0lEIGRlc2lnbiB0ZWFtLCB0d28gcGVvcGxlIGNhbWUgdXAgd2l0aCB0aGF0IG51bWJl ciBpbmRlcGVuZGVudGx5IGFzIGEgZmluZ2VyLWluLWFpciBndWVzcy4mbmJzcDsgSXQgd2VudCBp biB0aGUgUFIgYW5kIGhhcyBzdHVjayBmb3IgbGFjayBvZiBhIGNvbXBlbGxpbmcgYWx0ZXJuYXRp dmUuJm5ic3A7ICMxOTk4IGlzIHRoZSBtb3N0IGxpa2VseSBjb21wZWxsaW5nIGFsdGVybmF0aXZl LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAmbHQ7cXVpYy1ib3Vu Y2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KSWFuIFN3ZXR0PGJyPg0KPGI+ U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE5IDM6MTcgUE08YnI+DQo8Yj5Ubzo8 L2I+IE1hcnRpbiBEdWtlICZsdDttYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IEVpZ2h0IENJRHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20g bm90IGF3YXJlIG9mIGFuIG9uLWxpc3QgZGlzY3Vzc2lvbiwgYnV0IDxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8xOTk4Ij4NClBSIzE5OTg8L2E+IHdp bGwgcmVtb3ZlIHRoYXQgcmVjb21tZW5kYXRpb24gYW5kIHJlcGxhY2UgaXQgd2l0aCBhIHRyYW5z cG9ydCBwYXJhbWV0ZXIgb25jZSBpdCBsYW5kcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhhdCA4IHNlZW1zIGV4dHJlbWVseSBoaWdoLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU dWUsIEZlYiAxMiwgMjAxOSBhdCA0OjU0IFBNIE1hcnRpbiBEdWtlICZsdDs8YSBocmVmPSJtYWls dG86bWFydGluLmguZHVrZUBnbWFpbC5jb20iPm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHNvbWVvbmUgcG9pbnQgbWUgdG8gdGhlIGRpc2N1c3Npb24g d2hlcmUgd2UgZGVjaWRlZCB0aGF0IHdlIG5lZWRlZCA4IENJRHM/IFRoYXQgc2VlbXMgcmVhbGx5 IGhpZ2ggdG8gbWUuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR22MB0983DE366ED92040D87703B6DA650CY4PR22MB0983namp_-- From nobody Tue Feb 12 15:46:48 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3051277CC for ; Tue, 12 Feb 2019 15:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYJZfCpo6kBp for ; Tue, 12 Feb 2019 15:46:45 -0800 (PST) Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 31B4B126C01 for ; Tue, 12 Feb 2019 15:46:45 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id v72so1366625itc.0 for ; Tue, 12 Feb 2019 15:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+Kl4gwqUMDAxJWqGqdYQZboeK8J2MD4Wjc3EfhAmf4A=; b=CYf2xzeBqPQtpCpdHaYtVTiDugD/H8CKiizz9w1o+1oKDHEmPeCN6AdGoYyGMiEIsW DHmNi0nuePy7VFU8nx5xh+wAjcCshjKccYmz6EKG6bvqtBgOqE10ekL7NX/3UMABjY1u ZAKUxo4fuA4zQnq5e9+qgBfkEE0qwOEALvuFt9tOnGBvPIGUopgZX7OR4M456xTuZ4a/ ASu2QODZnNzjBrGoNx+TyV9iJo8OryJbrOjGeeDLYjfqkVs2eu+1GkDoIlwtHCAD6HUG 3zI0Zdt4mkNGRnNlqa3JoXcGCvRGMP3BIvqJ84DDaA7UdutWM2701RcuYTS3YeToKM+r z/wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+Kl4gwqUMDAxJWqGqdYQZboeK8J2MD4Wjc3EfhAmf4A=; b=OBlNkDxeLhU9C6Xo1K5/skPG+kroHfv5MfC0fC9Yi8ZoYwhNST5qkvqBg7FXbOE54i h6uiHaqd+Bg4ZHN24Bqet314XPSAtFzYIKOR/NrtldVwlA2b4Ojx2C1Cq+i5YGg9fG56 obaMybtWScDoF4JGyQYFw99BXuCun2np2LbFR9xOuqWFBpbhoWg0vp+YzzbdJm5+Ia4o /VGgpdMdpqdtKHFIubDu2eIM6oE01MIXrhbDibxwVhWZQtNuYplCRyeshpigBBX6ehle gBQDqYut/VlgD39idmQCOblooZgM6zyqiymU72xClbrniX76ZBGZlX6Bzke/5yL8yUlp oHow== X-Gm-Message-State: AHQUAubkx2JyIGG595z1dARu2z9qYkjUqFXeLbGvH3ltRf4mKknDmHB8 3HgP/WaHIXLfaveCi7iAEFJJ58lh3Z6O0tNNrOA= X-Google-Smtp-Source: AHgI3IbjxDYGJzBp2YPFiT2eg/1ZeNMWu51+M6rUHYXrHOgJHYi8cbDNUNps+pStC6tpB2AC4xDY0MWG6eBNRzil12s= X-Received: by 2002:a6b:abc2:: with SMTP id u185mr3911981ioe.145.1550015204180; Tue, 12 Feb 2019 15:46:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Tue, 12 Feb 2019 15:46:17 -0800 Message-ID: Subject: Re: Eight CIDs? To: Ian Swett Cc: Martin Duke , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000a446af0581bb09aa" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 23:46:47 -0000 --000000000000a446af0581bb09aa Content-Type: text/plain; charset="UTF-8" On Tue, Feb 12, 2019 at 3:17 PM Ian Swett wrote: > I'm not aware of an on-list discussion, but PR#1998 > will remove that > recommendation and replace it with a transport parameter once it lands. > > I agree that 8 seems extremely high. > > So, perhaps I'm reading this wrong, but doesn't that PR discuss communicating the *maximum* number of CIDs you are wiling to store? 8, if used there, would be the *default maximum*, not the minimum? As a default maximum, I don't think 8 is high. I do think you need a default minimum, and that the minimum might end up pretty small (2, say, to have one in use and one spare), but I think that the smaller it is the more often Martin Duke's concern about a large number of connection ID pulls will come true. If we don't want to have to re-adjust this later when multipath comes in, I think the combination of multipath and connection migration might make 8 a reasonable minimum. If this will get re-worked for other reasons then, though, this concern does not apply. Ted > On Tue, Feb 12, 2019 at 4:54 PM Martin Duke > wrote: > >> Can someone point me to the discussion where we decided that we needed 8 >> CIDs? That seems really high to me.. >> > --000000000000a446af0581bb09aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 12, 2019 at 3:17 PM Ian Swett= <ianswett=3D40google.com@dmarc.ietf.org> wrote:
I'm not aware of an on-list discussion, but PR#1998 will remov= e that recommendation and replace it with a transport parameter once it lan= ds.

I agree that 8 seems extremely high.

=

So, perhaps I'm reading this wrong, bu= t doesn't that PR discuss communicating the *maximum* number of CIDs yo= u are wiling to store?=C2=A0 8, if used there, would be the *default maximu= m*, not the minimum?=C2=A0 As a default maximum, I don't think 8 is hig= h.

I do think you need a default minimum, and that= the minimum might end up pretty small (2, say, to have one in use and one = spare), but I think that the smaller it is the more often Martin Duke's= concern about a large number of connection ID pulls will come true.=C2=A0 = If we don't want to have to re-adjust this later when multipath comes i= n, I think the combination of multipath and connection migration might make= 8 a reasonable minimum.=C2=A0 If this will get re-worked for other reasons= then, though, this concern does not apply.

Ted

=C2=A0
On Tue, Feb 12, 2019 at 4:54 PM Martin Duke <martin.h.duke@gmail.com> wrote= :
Can someone point me to the discussion where we decided that we needed 8= CIDs? That seems really high to me..
--000000000000a446af0581bb09aa-- From nobody Tue Feb 12 16:13:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2C1228B7 for ; Tue, 12 Feb 2019 16:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ETIh-IREG89 for ; Tue, 12 Feb 2019 16:13:20 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 BD8321200D8 for ; Tue, 12 Feb 2019 16:13:20 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id i130so265768pgd.1 for ; Tue, 12 Feb 2019 16:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SKvlQa3pCgUbuBt/vOBfHLbwvp89honkwGTiO/RZSGI=; b=AJLM5Nxh/Ehg5a73+tMzgXu6QPGjot5X65ekwPS1bbGqCEhJi6yB3ZtfJbneMCNiB/ AkWf/9P8El40LAXNBn368OiApTkOc71jTEM9BQVgl/aWufko5F/3+ecoypSdPm+JsOo3 4AWsDeinDEGUE7Iy5qZV8Xf2I6503bz4pvQiOYfM1FMd6yt6fTSCQns4SQ1weBtaXPvs rDt2k158i7ntPgrGSdK8oyb8w8vmCdhUmlS8lsGvVTOUy43vmqazTq7US2qV3/Rgv1cW bzVns9/1pNXAwWbbv7Beg2C+0TOqJ7Hoih4aPeTy+8+6Xxm1iSYZUzj75gYtsnseOEvs 8ZCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SKvlQa3pCgUbuBt/vOBfHLbwvp89honkwGTiO/RZSGI=; b=uZfBXXt3iU8KfFfgJ11c82Mvkt4oSYBZaiGilfiolRnw4k7JQeG8Mbav3fPDUqBhMm V+8a0+PfgnAQeHiQVCb0MnVinkluVOKkHe8g6uD0KJQ/TmMfBXqiKapmBKgUVdDt/WqT 3c8MHq/7O3rR06H5+Fsih8f0T6cC8yxOpdknNyxD1VfCnc2Sn1bQbfpfIfK6d1Ps2AD9 yarcfx+pehHNfvNzhGv9m1ulnlH8t1IKF6r+p8nKkojo/mc9owCkquJBz2iokYdbaUAU k7g9WOZ/8DZXUze6SVx8aRJdN0Secozya+f1aIYGRdcAAYVZpHVA5AtjuwWibJncNCmN rwHQ== X-Gm-Message-State: AHQUAuY+24cwU4IiTJpDkTZDsZ9ypsJazcA/wlM00/IORFaIRm9X+OrI NlOnnrYMfHlr9IBhyzidh0e5PS8fv0Umd7dvz0RDBEcU X-Google-Smtp-Source: AHgI3IbjIjHO+6nssdNH7wLB9yKQWDN+v7Gmns1BQ7PDuhjV2uqM788bFAqaSiNojhRl/v2wEMaqYf+o3wl5kmeTBT0= X-Received: by 2002:a63:1ce:: with SMTP id 197mr6063959pgb.47.1550016800103; Tue, 12 Feb 2019 16:13:20 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> In-Reply-To: <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> From: David Schinazi Date: Tue, 12 Feb 2019 16:13:08 -0800 Message-ID: Subject: Re: QUIC ossification To: Roberto Peon Cc: Martin Thomson , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c4219f0581bb6849" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 00:13:22 -0000 --000000000000c4219f0581bb6849 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we may be able to limit ossification of version numbers by adding some GREASE to the (upcoming) in-band compatible version upgrade extension (what used to be EKR's PR). The idea of that extension is that the client sends a QUICv1 initial containing a transport parameter indicating it supports this extension and what versions of QUIC it supports. The server can then send its replies with a new QUIC version number. Back to GREASE: one option here would be for us to burn some versions for "v1 compatible version negotiation greasing" (similar but different to 0x?a?a?a?a) and servers can in-band upgrade to those versions. But we could also do that in the reverse direction: the servers advertise support for one of these in Alt-Svc and clients send their Initial to that version, and the server can then perform in-band version change to v1, to another of these versions, or just keep the client's version for the life of this connection. This will cause ossifying middleboxes to break these connections. Thoughts? David On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon wrote: > My fear/experience around this is why I'd strongly recommend doing a QUIC > V2 as soon as possible where the delta from V1 -> V2 is limited to *solel= y* > what is necessary for version negotiation. > > We can simultaneously have a V3 conversation which would include whateve= r > else we decide we need to change/add as a separate conversation which > depends on V2. > > -=3DR > > =EF=BB=BFOn 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" < > quic-bounces@ietf.org on behalf of mt@lowentropy.net> wrote: > > On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote: > > 1) Version. I can't think of any immediate negative consequences fo= r > a > > middlebox that drops any long header with a version > 1. TLS 1.3 ha= d > to > > surrender to this problem by hiding the version elsewhere. > > > > We might avoid this by routinely coalescing long headers with rando= m > > version fields to connection-critical packets. Beyond that, I'm out > of > > great ideas. If we don't have a robust defense against this, we > ought to > > put some thought into how to deploy a v2 if the version fields is > > inoperable. > > As Mike points out, the Length field is version-specific, so there is > no real defense here other than - as many have suggested - using the > version field actively. That means shipping another version. In a sense= , > the fact that Google are still not on the same version gives us some time= , > but it could mean that we might want to look toward having the "add versi= on > negotiation and fallback protection" draft define a version rather than a= n > extension. > > > 2) Client Transport Parameters. Initial Keys will help a little bit= , > but in > > TLS1.3 CCS still sorta exists because middleboxes are inspecting > packets so > > deeply. It's not viable for v2 to have the same transport > parameters; it's > > only slightly less gross to send v2 client TPs in some later messag= e > and > > have to send a fairly bulky "fake" set of v1 TPs in the client hell= o > to get > > through the network. > > I'm not concerned about transport parameters if the above issue is > fixed. TLS had no real issues with extensions, and it looks like we > already have the start of a pipeline of extensions coming. v2 can share > the transport parameter extension, unless we decide to change the format = in > a non-compatible way. > > (Note: CCS in TLS 1.3 only exists because middleboxes were inspecting > a lot, yes, but it also indicates that they weren't inspecting enough, > because the compatibility hack we have wouldn't work if they did a proper > job.) > > > > --000000000000c4219f0581bb6849 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we may be able to limit ossificat= ion of version numbers by adding some GREASE to the (upcoming) in-band comp= atible version upgrade extension (what used to be EKR's PR). The idea o= f that extension is that the client sends a QUICv1 initial containing a tra= nsport parameter indicating it supports this extension and what versions of= QUIC it supports. The server can then send its replies with a new QUIC ver= sion number. Back to GREASE: one option here would be for us to burn some v= ersions for "v1 compatible version negotiation greasing" (similar= but different to=C2=A00x?a?a?a?a) and servers can in-band upgrade to those= versions. But we could also do that in the reverse direction: the servers = advertise support for one of these in Alt-Svc and clients send their Initia= l to that version, and the server can then perform in-band version change t= o v1, to another of these versions, or just keep the client's version f= or the life of this connection. This will cause ossifying middleboxes to br= eak these connections.

Thoughts?
=

David

On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <fenix@fb.com> wrote:
My fear/experience around this is why I'd s= trongly recommend doing a QUIC V2 as soon as possible where the delta from = V1 -> V2 is limited to *solely* what is necessary for version negotiatio= n.

We can simultaneously have a V3 conversation which would=C2=A0 include what= ever else we decide we need to change/add as a separate conversation which = depends on V2.

-=3DR

=EF=BB=BFOn 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" = <quic-bounces= @ietf.org on behalf of mt@lowentropy.net> wrote:

=C2=A0 =C2=A0 On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote:
=C2=A0 =C2=A0 > 1) Version. I can't think of any immediate negative = consequences for a
=C2=A0 =C2=A0 > middlebox that drops any long header with a version >= 1. TLS 1.3 had to
=C2=A0 =C2=A0 > surrender to this problem by hiding the version elsewher= e.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We might avoid this by routinely coalescing long headers= with random
=C2=A0 =C2=A0 > version fields to connection-critical packets. Beyond th= at, I'm out of
=C2=A0 =C2=A0 > great ideas. If we don't have a robust defense again= st this, we ought to
=C2=A0 =C2=A0 > put some thought into how to deploy a v2 if the version = fields is
=C2=A0 =C2=A0 > inoperable.

=C2=A0 =C2=A0 As Mike points out, the Length field is version-specific, so = there is no real defense here other than - as many have suggested - using t= he version field actively.=C2=A0 That means shipping another version.=C2=A0= In a sense, the fact that Google are still not on the same version gives u= s some time, but it could mean that we might want to look toward having the= "add version negotiation and fallback protection" draft define a= version rather than an extension.

=C2=A0 =C2=A0 > 2) Client Transport Parameters. Initial Keys will help a= little bit, but in
=C2=A0 =C2=A0 > TLS1.3 CCS still sorta exists because middleboxes are in= specting packets so
=C2=A0 =C2=A0 > deeply. It's not viable for v2 to have the same tran= sport parameters; it's
=C2=A0 =C2=A0 > only slightly less gross to send v2 client TPs in some l= ater message and
=C2=A0 =C2=A0 > have to send a fairly bulky "fake" set of v1 T= Ps in the client hello to get
=C2=A0 =C2=A0 > through the network.

=C2=A0 =C2=A0 I'm not concerned about transport parameters if the above= issue is fixed.=C2=A0 TLS had no real issues with extensions, and it looks= like we already have the start of a pipeline of extensions coming.=C2=A0 v= 2 can share the transport parameter extension, unless we decide to change t= he format in a non-compatible way.

=C2=A0 =C2=A0 (Note: CCS in TLS 1.3 only exists because middleboxes were in= specting a lot, yes, but it also indicates that they weren't inspecting= enough, because the compatibility hack we have wouldn't work if they d= id a proper job.)



--000000000000c4219f0581bb6849-- From nobody Tue Feb 12 16:21:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0CE1228B7 for ; Tue, 12 Feb 2019 16:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=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=fb.com header.b=dLF5Nijj; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ZN9OwJ/B 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 AHK03BWcRX-7 for ; Tue, 12 Feb 2019 16:21:13 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 C61CB1200D8 for ; Tue, 12 Feb 2019 16:21:13 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.27/8.16.0.27) with SMTP id x1D041b0011963; Tue, 12 Feb 2019 16:21:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=bSaiZxsBE+cdm/QrhJjJVJ0x76/Qn1C84jymdDTBqD0=; b=dLF5Nijjs5ATf6/iDh090PWgghmj1f3hyjq9ANXaGD7iEsnOW2uLWA3yU8L0EgtS0KbC 653UM1bB+PFk0QMJXNfd68PDpmBJGAkWs8v1sQy+gZrKNrRl95GCnGf5PFyUhBMeczGl Dj8uEkpGsNO/bvO1d4JLRv69ciAHsci7wqI= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2qm7s805n9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 12 Feb 2019 16:21:12 -0800 Received: from prn-mbx01.TheFacebook.com (2620:10d:c081:6::15) by prn-hub04.TheFacebook.com (2620:10d:c081:35::128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 12 Feb 2019 16:21:10 -0800 Received: from prn-hub04.TheFacebook.com (2620:10d:c081:35::128) by prn-mbx01.TheFacebook.com (2620:10d:c081:6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 12 Feb 2019 16:21:10 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Tue, 12 Feb 2019 16:21:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bSaiZxsBE+cdm/QrhJjJVJ0x76/Qn1C84jymdDTBqD0=; b=ZN9OwJ/BjkMSsKK2ZJqv21GN58itcnBe01zlP4w5M31YbK70Iwc4LHiEyADPXJQlyg473yIAGEddKmKrvNSDObDpzewYymmScNJTM7w+ojBEEoueDuYU1lZziDn7RaA1l6TMgBdgkggRK3S6IA6x4DxZPpYXL70SJfVropbcv1c= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYASPR01MB0029.namprd15.prod.outlook.com (20.177.126.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Wed, 13 Feb 2019 00:20:52 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084%5]) with mapi id 15.20.1601.023; Wed, 13 Feb 2019 00:20:52 +0000 From: Roberto Peon To: David Schinazi CC: Martin Thomson , "quic@ietf.org" Subject: Re: QUIC ossification Thread-Topic: QUIC ossification Thread-Index: AQHUwxih7UYarYoV30WBSlEhJDleK6Xcr5EA//+EwACAAKdJAP//fAuA Date: Wed, 13 Feb 2019 00:20:52 +0000 Message-ID: <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::7:55b7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f941201-08ec-4113-3e65-08d691491ced x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYASPR01MB0029; x-ms-traffictypediagnostic: BYASPR01MB0029: x-microsoft-exchange-diagnostics: 1; BYASPR01MB0029; 20:+zN0l7N5t2SUERJRn+oFx7LP81Y7mweURVNzG5tBv2UJbfYB8C1WjBqbDYmjV7qShQwXltFQvsuB/WXn6HEbW07x4wYufYQMYxF+D1dIKCeMV7SfBBC9V46P/84thyMK1sP3Idp2Aajjb7VyOO50VTHFb9IfJOU6lYFUbFVQ2r8= x-microsoft-antispam-prvs: x-forefront-prvs: 094700CA91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(346002)(39860400002)(376002)(189003)(199004)(68736007)(6246003)(99286004)(4326008)(97736004)(236005)(476003)(25786009)(36756003)(7116003)(221733001)(7736002)(82746002)(6436002)(6306002)(486006)(14454004)(6512007)(8676002)(58126008)(6116002)(186003)(54896002)(53936002)(76176011)(6916009)(105586002)(11346002)(446003)(316002)(86362001)(6506007)(3480700005)(106356001)(81156014)(81166006)(2906002)(6486002)(71190400001)(71200400001)(14444005)(256004)(478600001)(102836004)(8936002)(33656002)(2616005)(46003)(93886005)(54906003)(6346003)(229853002)(83716004)(53546011)(569394003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYASPR01MB0029; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 85Hq2RN6KKhQ0UOihQQojUIBtBSe8DEcx/OSPlJ8ZcBh9cN5Ok14Fur+J7Phwn5Nrv6EBD9aFbveSlV/t4hgLRPSK0jX01UhphQWaFz8/5Xd7QR03wZWXs17dZyY7OGDpgOG0ossAk0BKWXLCHbaxPNz3OFWkmYddxYiI9Q99MDaktRynG8YPZ1/kzzgsZc9QK9i8eyaGY8qdasUqaUuM8SKpj9c81ePQKxMjfYARTpF1a4n5XB29V50o/a584NmsKyC5cNcGCqlFJT4os6/FXM5FVHRMYqK+DOGwlSkPS7mcmjsFF322sPvvJLUXurhFTesLCgpXjC8hP7j/RzDoaDYhfVu3MLWwWKCQUM9jyV/z5lxaBVMW4DhYMBqG8MQaYreka51TdtMBeq2qr15zYJsRwUsmURq2CTIZRiCJkA= Content-Type: multipart/alternative; boundary="_000_47E7A834B6CD4D73BF498768A48CADF0fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4f941201-08ec-4113-3e65-08d691491ced X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2019 00:20:52.2433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYASPR01MB0029 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-12_13:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 00:21:16 -0000 --_000_47E7A834B6CD4D73BF498768A48CADF0fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IGhhdmUgYW4gb3BpbmlvbiBvbiBob3cgdmVyc2lvbiBpcyBuZWdvdGlhdGVkIHll dC4NCknigJltIG5vdCBjb252aW5jZWQgaXQgaXMgZWFzeSB0byBnZXQgcmlnaHQuIEl0IG1heSBi ZSBtb3JlIGNvcnJlY3QgZm9yIG1lIHRvIHNheSB0aGF0IEnigJltIGNvbnZpbmNlZCBpdCBpcyBy ZWFzb25hYmxlIGRpZmZpY3VsdCB0byBnZXQgcmlnaHQgYmVjYXVzZSBpdCBpcyB0aGUgbW9zdCBp bXBvcnRhbnQgb2YgdGhlIHZhcmlvdXMgaW52YXJpYW50cy4NCg0KSSBhbHNvIHN1c3BlY3QgdGhh dCB5b3UgbmVlZCBtb3JlIHRoYW4gb25lIHdheSB0byBkbyBpdCwgZS5nLiBpbi1iYW5kIGFuZCBv dXQtb2YtYmFuZCAod2hpY2ggY291bGQgYmUgaW4tYmFuZCBpbiBhIFYyIHRvIGFsbG93IGZvciB1 cGdyYWRlIHRvIHNvbWV0aGluZyBlbHNlKS4gVGhlbiBkb2VzIGEgY2xpZW50IGNhY2hlIHRoZSB2 ZXJzaW9uPyBGb3IgaG93IGxvbmcvd2hlcmU/IFBlciBJUD8gSG9zdG5hbWU/IChibGFoIGJsYWgu LiBldGMuIGV0Yy4pDQoNCkkgY2FuIHNheSB0aGF0IHRoZSBBTFBOIGFuZCBOUE4gYXBwcm9hY2hl cyBlYWNoIGhhZCB0aGVpciBwb3NpdGl2ZXMgYW5kIG5lZ2F0aXZlcywgYW5kIGluIHRoZSBlbmQs IGhhdmluZyBzb21ldGhpbmcgbGlrZSBlaXRoZXIgaXMgcHJvYmFibHkgZ29vZCBlbm91Z2guDQoN ClJhdGhlciB0aGFuIGFuIG9waW5pb24gb24gaG93IGl0IHNob3VsZCBiZSBkb25lLCBJIGhhdmUg YW4gb3BpbmlvbiB0aGF0IHdlIG5lZWQgdG8gYWRkIHRoaXMgc29vbiwgYXMgYSBWMi4NCg0KLT1S DQoNCkZyb206IERhdmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+DQpEYXRl OiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxOSBhdCA0OjEzIFBNDQpUbzogUm9iZXJ0byBQZW9u IDxmZW5peEBmYi5jb20+DQpDYzogTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0Piwg InF1aWNAaWV0Zi5vcmciIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFFVSUMgb3NzaWZp Y2F0aW9uDQoNCkkgdGhpbmsgd2UgbWF5IGJlIGFibGUgdG8gbGltaXQgb3NzaWZpY2F0aW9uIG9m IHZlcnNpb24gbnVtYmVycyBieSBhZGRpbmcgc29tZSBHUkVBU0UgdG8gdGhlICh1cGNvbWluZykg aW4tYmFuZCBjb21wYXRpYmxlIHZlcnNpb24gdXBncmFkZSBleHRlbnNpb24gKHdoYXQgdXNlZCB0 byBiZSBFS1IncyBQUikuIFRoZSBpZGVhIG9mIHRoYXQgZXh0ZW5zaW9uIGlzIHRoYXQgdGhlIGNs aWVudCBzZW5kcyBhIFFVSUN2MSBpbml0aWFsIGNvbnRhaW5pbmcgYSB0cmFuc3BvcnQgcGFyYW1l dGVyIGluZGljYXRpbmcgaXQgc3VwcG9ydHMgdGhpcyBleHRlbnNpb24gYW5kIHdoYXQgdmVyc2lv bnMgb2YgUVVJQyBpdCBzdXBwb3J0cy4gVGhlIHNlcnZlciBjYW4gdGhlbiBzZW5kIGl0cyByZXBs aWVzIHdpdGggYSBuZXcgUVVJQyB2ZXJzaW9uIG51bWJlci4gQmFjayB0byBHUkVBU0U6IG9uZSBv cHRpb24gaGVyZSB3b3VsZCBiZSBmb3IgdXMgdG8gYnVybiBzb21lIHZlcnNpb25zIGZvciAidjEg Y29tcGF0aWJsZSB2ZXJzaW9uIG5lZ290aWF0aW9uIGdyZWFzaW5nIiAoc2ltaWxhciBidXQgZGlm ZmVyZW50IHRvIDB4P2E/YT9hP2EpIGFuZCBzZXJ2ZXJzIGNhbiBpbi1iYW5kIHVwZ3JhZGUgdG8g dGhvc2UgdmVyc2lvbnMuIEJ1dCB3ZSBjb3VsZCBhbHNvIGRvIHRoYXQgaW4gdGhlIHJldmVyc2Ug ZGlyZWN0aW9uOiB0aGUgc2VydmVycyBhZHZlcnRpc2Ugc3VwcG9ydCBmb3Igb25lIG9mIHRoZXNl IGluIEFsdC1TdmMgYW5kIGNsaWVudHMgc2VuZCB0aGVpciBJbml0aWFsIHRvIHRoYXQgdmVyc2lv biwgYW5kIHRoZSBzZXJ2ZXIgY2FuIHRoZW4gcGVyZm9ybSBpbi1iYW5kIHZlcnNpb24gY2hhbmdl IHRvIHYxLCB0byBhbm90aGVyIG9mIHRoZXNlIHZlcnNpb25zLCBvciBqdXN0IGtlZXAgdGhlIGNs aWVudCdzIHZlcnNpb24gZm9yIHRoZSBsaWZlIG9mIHRoaXMgY29ubmVjdGlvbi4gVGhpcyB3aWxs IGNhdXNlIG9zc2lmeWluZyBtaWRkbGVib3hlcyB0byBicmVhayB0aGVzZSBjb25uZWN0aW9ucy4N Cg0KVGhvdWdodHM/DQoNCkRhdmlkDQoNCk9uIFR1ZSwgRmViIDEyLCAyMDE5IGF0IDI6MTUgUE0g Um9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT4+IHdyb3RlOg0K TXkgZmVhci9leHBlcmllbmNlIGFyb3VuZCB0aGlzIGlzIHdoeSBJJ2Qgc3Ryb25nbHkgcmVjb21t ZW5kIGRvaW5nIGEgUVVJQyBWMiBhcyBzb29uIGFzIHBvc3NpYmxlIHdoZXJlIHRoZSBkZWx0YSBm cm9tIFYxIC0+IFYyIGlzIGxpbWl0ZWQgdG8gKnNvbGVseSogd2hhdCBpcyBuZWNlc3NhcnkgZm9y IHZlcnNpb24gbmVnb3RpYXRpb24uDQoNCldlIGNhbiBzaW11bHRhbmVvdXNseSBoYXZlIGEgVjMg Y29udmVyc2F0aW9uIHdoaWNoIHdvdWxkICBpbmNsdWRlIHdoYXRldmVyIGVsc2Ugd2UgZGVjaWRl IHdlIG5lZWQgdG8gY2hhbmdlL2FkZCBhcyBhIHNlcGFyYXRlIGNvbnZlcnNhdGlvbiB3aGljaCBk ZXBlbmRzIG9uIFYyLg0KDQotPVINCg0KT24gMi8xMi8xOSwgMTozNiBQTSwgIlFVSUMgb24gYmVo YWxmIG9mIE1hcnRpbiBUaG9tc29uIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBtdEBsb3dlbnRyb3B5Lm5ldDxtYWlsdG86 bXRAbG93ZW50cm9weS5uZXQ+PiB3cm90ZToNCg0KICAgIE9uIFdlZCwgRmViIDEzLCAyMDE5LCBh dCAwODoxOCwgTWFydGluIER1a2Ugd3JvdGU6DQogICAgPiAxKSBWZXJzaW9uLiBJIGNhbid0IHRo aW5rIG9mIGFueSBpbW1lZGlhdGUgbmVnYXRpdmUgY29uc2VxdWVuY2VzIGZvciBhDQogICAgPiBt aWRkbGVib3ggdGhhdCBkcm9wcyBhbnkgbG9uZyBoZWFkZXIgd2l0aCBhIHZlcnNpb24gPiAxLiBU TFMgMS4zIGhhZCB0bw0KICAgID4gc3VycmVuZGVyIHRvIHRoaXMgcHJvYmxlbSBieSBoaWRpbmcg dGhlIHZlcnNpb24gZWxzZXdoZXJlLg0KICAgID4NCiAgICA+IFdlIG1pZ2h0IGF2b2lkIHRoaXMg Ynkgcm91dGluZWx5IGNvYWxlc2NpbmcgbG9uZyBoZWFkZXJzIHdpdGggcmFuZG9tDQogICAgPiB2 ZXJzaW9uIGZpZWxkcyB0byBjb25uZWN0aW9uLWNyaXRpY2FsIHBhY2tldHMuIEJleW9uZCB0aGF0 LCBJJ20gb3V0IG9mDQogICAgPiBncmVhdCBpZGVhcy4gSWYgd2UgZG9uJ3QgaGF2ZSBhIHJvYnVz dCBkZWZlbnNlIGFnYWluc3QgdGhpcywgd2Ugb3VnaHQgdG8NCiAgICA+IHB1dCBzb21lIHRob3Vn aHQgaW50byBob3cgdG8gZGVwbG95IGEgdjIgaWYgdGhlIHZlcnNpb24gZmllbGRzIGlzDQogICAg PiBpbm9wZXJhYmxlLg0KDQogICAgQXMgTWlrZSBwb2ludHMgb3V0LCB0aGUgTGVuZ3RoIGZpZWxk IGlzIHZlcnNpb24tc3BlY2lmaWMsIHNvIHRoZXJlIGlzIG5vIHJlYWwgZGVmZW5zZSBoZXJlIG90 aGVyIHRoYW4gLSBhcyBtYW55IGhhdmUgc3VnZ2VzdGVkIC0gdXNpbmcgdGhlIHZlcnNpb24gZmll bGQgYWN0aXZlbHkuICBUaGF0IG1lYW5zIHNoaXBwaW5nIGFub3RoZXIgdmVyc2lvbi4gIEluIGEg c2Vuc2UsIHRoZSBmYWN0IHRoYXQgR29vZ2xlIGFyZSBzdGlsbCBub3Qgb24gdGhlIHNhbWUgdmVy c2lvbiBnaXZlcyB1cyBzb21lIHRpbWUsIGJ1dCBpdCBjb3VsZCBtZWFuIHRoYXQgd2UgbWlnaHQg d2FudCB0byBsb29rIHRvd2FyZCBoYXZpbmcgdGhlICJhZGQgdmVyc2lvbiBuZWdvdGlhdGlvbiBh bmQgZmFsbGJhY2sgcHJvdGVjdGlvbiIgZHJhZnQgZGVmaW5lIGEgdmVyc2lvbiByYXRoZXIgdGhh biBhbiBleHRlbnNpb24uDQoNCiAgICA+IDIpIENsaWVudCBUcmFuc3BvcnQgUGFyYW1ldGVycy4g SW5pdGlhbCBLZXlzIHdpbGwgaGVscCBhIGxpdHRsZSBiaXQsIGJ1dCBpbg0KICAgID4gVExTMS4z IENDUyBzdGlsbCBzb3J0YSBleGlzdHMgYmVjYXVzZSBtaWRkbGVib3hlcyBhcmUgaW5zcGVjdGlu ZyBwYWNrZXRzIHNvDQogICAgPiBkZWVwbHkuIEl0J3Mgbm90IHZpYWJsZSBmb3IgdjIgdG8gaGF2 ZSB0aGUgc2FtZSB0cmFuc3BvcnQgcGFyYW1ldGVyczsgaXQncw0KICAgID4gb25seSBzbGlnaHRs eSBsZXNzIGdyb3NzIHRvIHNlbmQgdjIgY2xpZW50IFRQcyBpbiBzb21lIGxhdGVyIG1lc3NhZ2Ug YW5kDQogICAgPiBoYXZlIHRvIHNlbmQgYSBmYWlybHkgYnVsa3kgImZha2UiIHNldCBvZiB2MSBU UHMgaW4gdGhlIGNsaWVudCBoZWxsbyB0byBnZXQNCiAgICA+IHRocm91Z2ggdGhlIG5ldHdvcmsu DQoNCiAgICBJJ20gbm90IGNvbmNlcm5lZCBhYm91dCB0cmFuc3BvcnQgcGFyYW1ldGVycyBpZiB0 aGUgYWJvdmUgaXNzdWUgaXMgZml4ZWQuICBUTFMgaGFkIG5vIHJlYWwgaXNzdWVzIHdpdGggZXh0 ZW5zaW9ucywgYW5kIGl0IGxvb2tzIGxpa2Ugd2UgYWxyZWFkeSBoYXZlIHRoZSBzdGFydCBvZiBh IHBpcGVsaW5lIG9mIGV4dGVuc2lvbnMgY29taW5nLiAgdjIgY2FuIHNoYXJlIHRoZSB0cmFuc3Bv cnQgcGFyYW1ldGVyIGV4dGVuc2lvbiwgdW5sZXNzIHdlIGRlY2lkZSB0byBjaGFuZ2UgdGhlIGZv cm1hdCBpbiBhIG5vbi1jb21wYXRpYmxlIHdheS4NCg0KICAgIChOb3RlOiBDQ1MgaW4gVExTIDEu MyBvbmx5IGV4aXN0cyBiZWNhdXNlIG1pZGRsZWJveGVzIHdlcmUgaW5zcGVjdGluZyBhIGxvdCwg eWVzLCBidXQgaXQgYWxzbyBpbmRpY2F0ZXMgdGhhdCB0aGV5IHdlcmVuJ3QgaW5zcGVjdGluZyBl bm91Z2gsIGJlY2F1c2UgdGhlIGNvbXBhdGliaWxpdHkgaGFjayB3ZSBoYXZlIHdvdWxkbid0IHdv cmsgaWYgdGhleSBkaWQgYSBwcm9wZXIgam9iLikNCg0KDQo= --_000_47E7A834B6CD4D73BF498768A48CADF0fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <00F0825B77F0634CA1F212FDDCDE0495@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDIgMyAzIDIgMjt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27i gJl0IGhhdmUgYW4gb3BpbmlvbiBvbiBob3cgdmVyc2lvbiBpcyBuZWdvdGlhdGVkIHlldC48YnI+ DQpJ4oCZbSBub3QgY29udmluY2VkIGl0IGlzIGVhc3kgdG8gZ2V0IHJpZ2h0LiBJdCBtYXkgYmUg bW9yZSBjb3JyZWN0IGZvciBtZSB0byBzYXkgdGhhdCBJ4oCZbSBjb252aW5jZWQgaXQgaXMgcmVh c29uYWJsZSBkaWZmaWN1bHQgdG8gZ2V0IHJpZ2h0IGJlY2F1c2UgaXQgaXMgdGhlIG1vc3QgaW1w b3J0YW50IG9mIHRoZSB2YXJpb3VzIGludmFyaWFudHMuPGJyPg0KPGJyPg0KSSBhbHNvIHN1c3Bl Y3QgdGhhdCB5b3UgbmVlZCBtb3JlIHRoYW4gb25lIHdheSB0byBkbyBpdCwgZS5nLiBpbi1iYW5k IGFuZCBvdXQtb2YtYmFuZCAod2hpY2ggY291bGQgYmUgaW4tYmFuZCBpbiBhIFYyIHRvIGFsbG93 IGZvciB1cGdyYWRlIHRvIHNvbWV0aGluZyBlbHNlKS4gVGhlbiBkb2VzIGEgY2xpZW50IGNhY2hl IHRoZSB2ZXJzaW9uPyBGb3IgaG93IGxvbmcvd2hlcmU/IFBlciBJUD8gSG9zdG5hbWU/IChibGFo IGJsYWguLiBldGMuIGV0Yy4pPGJyPg0KPGJyPg0KSSBjYW4gc2F5IHRoYXQgdGhlIEFMUE4gYW5k IE5QTiBhcHByb2FjaGVzIGVhY2ggaGFkIHRoZWlyIHBvc2l0aXZlcyBhbmQgbmVnYXRpdmVzLCBh bmQgaW4gdGhlIGVuZCwgaGF2aW5nIHNvbWV0aGluZyBsaWtlIGVpdGhlciBpcyBwcm9iYWJseSBn b29kIGVub3VnaC48YnI+DQo8YnI+DQpSYXRoZXIgdGhhbiBhbiBvcGluaW9uIG9uIGhvdyBpdCBz aG91bGQgYmUgZG9uZSwgSSBoYXZlIGFuIG9waW5pb24gdGhhdCB3ZSBuZWVkIHRvIGFkZCB0aGlz IHNvb24sIGFzIGEgVjIuPGJyPg0KPGJyPg0KLT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5EYXZpZCBTY2hpbmF6aSAmbHQ7ZHNjaGluYXppLmlldGZAZ21haWwu Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxOSBhdCA0 OjEzIFBNPGJyPg0KPGI+VG86IDwvYj5Sb2JlcnRvIFBlb24gJmx0O2Zlbml4QGZiLmNvbSZndDs8 YnI+DQo8Yj5DYzogPC9iPk1hcnRpbiBUaG9tc29uICZsdDttdEBsb3dlbnRyb3B5Lm5ldCZndDss ICZxdW90O3F1aWNAaWV0Zi5vcmcmcXVvdDsgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBRVUlDIG9zc2lmaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgd2Ug bWF5IGJlIGFibGUgdG8gbGltaXQgb3NzaWZpY2F0aW9uIG9mIHZlcnNpb24gbnVtYmVycyBieSBh ZGRpbmcgc29tZSBHUkVBU0UgdG8gdGhlICh1cGNvbWluZykgaW4tYmFuZCBjb21wYXRpYmxlIHZl cnNpb24gdXBncmFkZSBleHRlbnNpb24gKHdoYXQgdXNlZCB0byBiZSBFS1IncyBQUikuIFRoZSBp ZGVhIG9mIHRoYXQgZXh0ZW5zaW9uIGlzIHRoYXQgdGhlIGNsaWVudCBzZW5kcyBhIFFVSUN2MQ0K IGluaXRpYWwgY29udGFpbmluZyBhIHRyYW5zcG9ydCBwYXJhbWV0ZXIgaW5kaWNhdGluZyBpdCBz dXBwb3J0cyB0aGlzIGV4dGVuc2lvbiBhbmQgd2hhdCB2ZXJzaW9ucyBvZiBRVUlDIGl0IHN1cHBv cnRzLiBUaGUgc2VydmVyIGNhbiB0aGVuIHNlbmQgaXRzIHJlcGxpZXMgd2l0aCBhIG5ldyBRVUlD IHZlcnNpb24gbnVtYmVyLiBCYWNrIHRvIEdSRUFTRTogb25lIG9wdGlvbiBoZXJlIHdvdWxkIGJl IGZvciB1cyB0byBidXJuIHNvbWUgdmVyc2lvbnMNCiBmb3IgJnF1b3Q7djEgY29tcGF0aWJsZSB2 ZXJzaW9uIG5lZ290aWF0aW9uIGdyZWFzaW5nJnF1b3Q7IChzaW1pbGFyIGJ1dCBkaWZmZXJlbnQg dG8mbmJzcDsweD9hP2E/YT9hKSBhbmQgc2VydmVycyBjYW4gaW4tYmFuZCB1cGdyYWRlIHRvIHRo b3NlIHZlcnNpb25zLiBCdXQgd2UgY291bGQgYWxzbyBkbyB0aGF0IGluIHRoZSByZXZlcnNlIGRp cmVjdGlvbjogdGhlIHNlcnZlcnMgYWR2ZXJ0aXNlIHN1cHBvcnQgZm9yIG9uZSBvZiB0aGVzZSBp biBBbHQtU3ZjIGFuZCBjbGllbnRzDQogc2VuZCB0aGVpciBJbml0aWFsIHRvIHRoYXQgdmVyc2lv biwgYW5kIHRoZSBzZXJ2ZXIgY2FuIHRoZW4gcGVyZm9ybSBpbi1iYW5kIHZlcnNpb24gY2hhbmdl IHRvIHYxLCB0byBhbm90aGVyIG9mIHRoZXNlIHZlcnNpb25zLCBvciBqdXN0IGtlZXAgdGhlIGNs aWVudCdzIHZlcnNpb24gZm9yIHRoZSBsaWZlIG9mIHRoaXMgY29ubmVjdGlvbi4gVGhpcyB3aWxs IGNhdXNlIG9zc2lmeWluZyBtaWRkbGVib3hlcyB0byBicmVhayB0aGVzZSBjb25uZWN0aW9ucy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhv dWdodHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRhdmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFR1ZSwgRmViIDEyLCAyMDE5IGF0IDI6MTUgUE0gUm9iZXJ0byBQZW9uICZsdDs8 YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29tIj5mZW5peEBmYi5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TXkgZmVhci9leHBlcmllbmNlIGFyb3VuZCB0 aGlzIGlzIHdoeSBJJ2Qgc3Ryb25nbHkgcmVjb21tZW5kIGRvaW5nIGEgUVVJQyBWMiBhcyBzb29u IGFzIHBvc3NpYmxlIHdoZXJlIHRoZSBkZWx0YSBmcm9tIFYxIC0mZ3Q7IFYyIGlzIGxpbWl0ZWQg dG8gKnNvbGVseSogd2hhdCBpcyBuZWNlc3NhcnkgZm9yIHZlcnNpb24gbmVnb3RpYXRpb24uDQo8 YnI+DQo8YnI+DQpXZSBjYW4gc2ltdWx0YW5lb3VzbHkgaGF2ZSBhIFYzIGNvbnZlcnNhdGlvbiB3 aGljaCB3b3VsZCZuYnNwOyBpbmNsdWRlIHdoYXRldmVyIGVsc2Ugd2UgZGVjaWRlIHdlIG5lZWQg dG8gY2hhbmdlL2FkZCBhcyBhIHNlcGFyYXRlIGNvbnZlcnNhdGlvbiB3aGljaCBkZXBlbmRzIG9u IFYyLjxicj4NCjxicj4NCi09Ujxicj4NCjxicj4NCk9uIDIvMTIvMTksIDE6MzYgUE0sICZxdW90 O1FVSUMgb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGll dGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzptdEBsb3dlbnRyb3B5Lm5l dCIgdGFyZ2V0PSJfYmxhbmsiPm10QGxvd2VudHJvcHkubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyBPbiBXZWQsIEZlYiAxMywgMjAxOSwgYXQgMDg6MTgsIE1hcnRp biBEdWtlIHdyb3RlOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAxKSBWZXJzaW9uLiBJIGNhbid0 IHRoaW5rIG9mIGFueSBpbW1lZGlhdGUgbmVnYXRpdmUgY29uc2VxdWVuY2VzIGZvciBhPGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7IG1pZGRsZWJveCB0aGF0IGRyb3BzIGFueSBsb25nIGhlYWRlciB3 aXRoIGEgdmVyc2lvbiAmZ3Q7IDEuIFRMUyAxLjMgaGFkIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IHN1cnJlbmRlciB0byB0aGlzIHByb2JsZW0gYnkgaGlkaW5nIHRoZSB2ZXJzaW9uIGVsc2V3 aGVyZS48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFdl IG1pZ2h0IGF2b2lkIHRoaXMgYnkgcm91dGluZWx5IGNvYWxlc2NpbmcgbG9uZyBoZWFkZXJzIHdp dGggcmFuZG9tPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHZlcnNpb24gZmllbGRzIHRvIGNvbm5l Y3Rpb24tY3JpdGljYWwgcGFja2V0cy4gQmV5b25kIHRoYXQsIEknbSBvdXQgb2Y8YnI+DQombmJz cDsgJm5ic3A7ICZndDsgZ3JlYXQgaWRlYXMuIElmIHdlIGRvbid0IGhhdmUgYSByb2J1c3QgZGVm ZW5zZSBhZ2FpbnN0IHRoaXMsIHdlIG91Z2h0IHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHB1 dCBzb21lIHRob3VnaHQgaW50byBob3cgdG8gZGVwbG95IGEgdjIgaWYgdGhlIHZlcnNpb24gZmll bGRzIGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGlub3BlcmFibGUuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyBBcyBNaWtlIHBvaW50cyBvdXQsIHRoZSBMZW5ndGggZmllbGQgaXMgdmVyc2lv bi1zcGVjaWZpYywgc28gdGhlcmUgaXMgbm8gcmVhbCBkZWZlbnNlIGhlcmUgb3RoZXIgdGhhbiAt IGFzIG1hbnkgaGF2ZSBzdWdnZXN0ZWQgLSB1c2luZyB0aGUgdmVyc2lvbiBmaWVsZCBhY3RpdmVs eS4mbmJzcDsgVGhhdCBtZWFucyBzaGlwcGluZyBhbm90aGVyIHZlcnNpb24uJm5ic3A7IEluIGEg c2Vuc2UsIHRoZSBmYWN0IHRoYXQgR29vZ2xlIGFyZSBzdGlsbCBub3Qgb24gdGhlDQogc2FtZSB2 ZXJzaW9uIGdpdmVzIHVzIHNvbWUgdGltZSwgYnV0IGl0IGNvdWxkIG1lYW4gdGhhdCB3ZSBtaWdo dCB3YW50IHRvIGxvb2sgdG93YXJkIGhhdmluZyB0aGUgJnF1b3Q7YWRkIHZlcnNpb24gbmVnb3Rp YXRpb24gYW5kIGZhbGxiYWNrIHByb3RlY3Rpb24mcXVvdDsgZHJhZnQgZGVmaW5lIGEgdmVyc2lv biByYXRoZXIgdGhhbiBhbiBleHRlbnNpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 IDIpIENsaWVudCBUcmFuc3BvcnQgUGFyYW1ldGVycy4gSW5pdGlhbCBLZXlzIHdpbGwgaGVscCBh IGxpdHRsZSBiaXQsIGJ1dCBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBUTFMxLjMgQ0NTIHN0 aWxsIHNvcnRhIGV4aXN0cyBiZWNhdXNlIG1pZGRsZWJveGVzIGFyZSBpbnNwZWN0aW5nIHBhY2tl dHMgc288YnI+DQombmJzcDsgJm5ic3A7ICZndDsgZGVlcGx5LiBJdCdzIG5vdCB2aWFibGUgZm9y IHYyIHRvIGhhdmUgdGhlIHNhbWUgdHJhbnNwb3J0IHBhcmFtZXRlcnM7IGl0J3M8YnI+DQombmJz cDsgJm5ic3A7ICZndDsgb25seSBzbGlnaHRseSBsZXNzIGdyb3NzIHRvIHNlbmQgdjIgY2xpZW50 IFRQcyBpbiBzb21lIGxhdGVyIG1lc3NhZ2UgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGhh dmUgdG8gc2VuZCBhIGZhaXJseSBidWxreSAmcXVvdDtmYWtlJnF1b3Q7IHNldCBvZiB2MSBUUHMg aW4gdGhlIGNsaWVudCBoZWxsbyB0byBnZXQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgdGhyb3Vn aCB0aGUgbmV0d29yay48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEknbSBub3QgY29uY2VybmVk IGFib3V0IHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGlmIHRoZSBhYm92ZSBpc3N1ZSBpcyBmaXhlZC4m bmJzcDsgVExTIGhhZCBubyByZWFsIGlzc3VlcyB3aXRoIGV4dGVuc2lvbnMsIGFuZCBpdCBsb29r cyBsaWtlIHdlIGFscmVhZHkgaGF2ZSB0aGUgc3RhcnQgb2YgYSBwaXBlbGluZSBvZiBleHRlbnNp b25zIGNvbWluZy4mbmJzcDsgdjIgY2FuIHNoYXJlIHRoZSB0cmFuc3BvcnQgcGFyYW1ldGVyIGV4 dGVuc2lvbiwgdW5sZXNzIHdlDQogZGVjaWRlIHRvIGNoYW5nZSB0aGUgZm9ybWF0IGluIGEgbm9u LWNvbXBhdGlibGUgd2F5Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgKE5vdGU6IENDUyBpbiBU TFMgMS4zIG9ubHkgZXhpc3RzIGJlY2F1c2UgbWlkZGxlYm94ZXMgd2VyZSBpbnNwZWN0aW5nIGEg bG90LCB5ZXMsIGJ1dCBpdCBhbHNvIGluZGljYXRlcyB0aGF0IHRoZXkgd2VyZW4ndCBpbnNwZWN0 aW5nIGVub3VnaCwgYmVjYXVzZSB0aGUgY29tcGF0aWJpbGl0eSBoYWNrIHdlIGhhdmUgd291bGRu J3Qgd29yayBpZiB0aGV5IGRpZCBhIHByb3BlciBqb2IuKTxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_47E7A834B6CD4D73BF498768A48CADF0fbcom_-- From nobody Tue Feb 12 16:34:55 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB405130E68 for ; Tue, 12 Feb 2019 16:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrwIFy_8VRct for ; Tue, 12 Feb 2019 16:34:51 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on072c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe46::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F01130E5B for ; Tue, 12 Feb 2019 16:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zzzynMb4ZPBAb2xdbXEVCu19dssqzKlxFjbtMvoH3l0=; b=NDZB/isvdCXHTZ24asErj/Jc9unFu+M/FA8bBTACEU/M/GjaVABptpatY15tQEyXW0VX/RMr7y3B1oXBuxboUstmLs1ryyZM7TXcg1ZDomdoX3ljKdC7q8KcPl4Eys/oZ3UNIUL/feEuCmNvUidQRjviVcKbnwmE1kTrwP+fo8w= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0406.namprd22.prod.outlook.com (10.173.190.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Wed, 13 Feb 2019 00:34:47 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::90de:b35e:127a:ccc2%4]) with mapi id 15.20.1622.016; Wed, 13 Feb 2019 00:34:47 +0000 From: Mike Bishop To: Ted Hardie , Ian Swett CC: IETF QUIC WG , Martin Duke Subject: RE: Eight CIDs? Thread-Topic: Eight CIDs? Thread-Index: AQHUwx2CEhzsdzNYPkOs0OejRLzrgKXcy9uAgAAINICAAAy1UA== Date: Wed, 13 Feb 2019 00:34:46 +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: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:d8e1:f0fc:6e6:3711] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a86ea474-0c88-4039-dcc2-08d6914b0e71 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0406; x-ms-traffictypediagnostic: CY4PR22MB0406: x-microsoft-antispam-prvs: x-forefront-prvs: 094700CA91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(346002)(396003)(366004)(39830400003)(51444003)(199004)(189003)(55016002)(71200400001)(71190400001)(86362001)(99286004)(256004)(76176011)(97736004)(6436002)(7696005)(6506007)(2906002)(81166006)(7736002)(74316002)(106356001)(606006)(8676002)(81156014)(7116003)(105586002)(3480700005)(6246003)(53546011)(316002)(110136005)(54906003)(8936002)(236005)(476003)(102836004)(74482002)(14454004)(33656002)(508600001)(4326008)(229853002)(25786009)(186003)(68736007)(53936002)(46003)(6116002)(790700001)(11346002)(446003)(54896002)(486006)(9686003)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0406; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTRQUjIyTUIwNDA2OzIzOklVOG9RTkVpdngxUHNHelR0UzNFRnJQV1pQ?= =?utf-8?B?QzhsajN5TlZ2V0Z3aHQ0M0duYU9mOG0wRml0bklOT0d0NzBhK1phajlvOS9p?= =?utf-8?B?OFRjQndpNnpIeXJKNThrb1dPMlh0cVlEWTkyOWFhRk1LSXN5dWpuWmZOSDl6?= =?utf-8?B?WHhhVHRaK3VkVG5JbWZ4YVRqaUdyZHRxWlpuUnRRZFVVejNta0paTER2MSta?= =?utf-8?B?V0VkSm1WcnBKcGI4VUl2K3lPSFZwNUp4TDdMM0xpN016VWxJcDFTNUFFU0FS?= =?utf-8?B?djUrYUpaVCtDZ2tsYm9JNTVNWk5WSldicnNTVGJ6UlUzcTZVVXg1dThJY0ZR?= =?utf-8?B?Nm5nWmRhYXdDRlp5M0hTYlhoMlhNRG1qcUw3NWVBVzdud0licENrZnhoZXJB?= =?utf-8?B?ZHpZZWZOeWt6Z0Y4K015NHp0RlZzVytlRy9YYk9zS2tOaERRVjFDWjVoZzFQ?= =?utf-8?B?SURDa2lDMnF2enBPMXliZ3ZDYTJlVDFvQ3BLY1praW01VlM1cjQvcDllYmxm?= =?utf-8?B?bzdyTUxwZ1lyL3FpdjRuTjMzMkt6T21JaGMrdU8xR242QWxsQzgzMFA3ODJ0?= =?utf-8?B?Z1JpeVNWRXpXcHd1NHp0Z2pwMUxGRXkrVDBSQ3dnN3kzZFFRSTBBMmJtc1Fu?= =?utf-8?B?S2Y4b3RyVTcwRHV2dzBrWllPdENNN3k3d3hxajlCTkpIS1U5TXBKY3pTa0Rz?= =?utf-8?B?dU16cFpyK0JITndKSEZvTkNhNndSNU0veDFJL3Q3S1pmZG1oK1FBaVVGQkdS?= =?utf-8?B?ME85WW1RNlA5Rzh1Y2JhYXRBaHZXWlBoY1d3QXhVMWNQS1l4NURRNUdLZEhJ?= =?utf-8?B?L21kR1lRUmx4czVwSWc2SStpenNxa3BycGpXN01naGc4UHRyNm9wbFRRY2ZS?= =?utf-8?B?Yk9PZ2xUM1FuWi9pdUdreTA4cFVOU1hsUE10K1F0bjBoQThlSllNaFYzSm9C?= =?utf-8?B?OWVLRUx2eTB2dkVpV2V5cFoxNXovcXZTWXZ4b1VQQXNKeERqRUx3dWRCR0k2?= =?utf-8?B?TG9yNHZvMzNJTSt3Q2JvRHJGZkZEMVR0TkIvOStxTS93eUsyNUF1NXZDd2h3?= =?utf-8?B?dEVhdnpGelV6SUM1QytxUDFSMnU1Y2IvdDMreW9XSHRhbnZZQnRBRGZwNmRV?= =?utf-8?B?dUl0UnduQ2krU3pzVEJlV05KOExtYk4xSnRrdkw2Tis4U3Bycmc0d25QVGhw?= =?utf-8?B?NmdnbzhNL2FNY1NGZ3hpYmRmMGJwdVc4dGszd3pIYXFvMitIUENqcmJGbm5B?= =?utf-8?B?WXoySzFKOGdLc1VSNnlWeVc5QUIyaWhEV0JnSDY5MEhydGxySTZiYjVsMEhJ?= =?utf-8?B?RmxGRDludUNNRDZsVXhjeVppWlVCUnFUSmtoZWhtaVRBVlNQcFVzcllkUm5Y?= =?utf-8?B?akJPM3gyNEJSTUZEVGIybmU4L05lMUVRNFQrYVpQb3hRREZmb0xPcE1lUTNx?= =?utf-8?B?R0JEbExxei9hUTQ0OEZTRkhXQWx0MnU1NEpabjNISU9YRVRSRy9XdDZnM1ZG?= =?utf-8?B?N01MQWt5YkhRTXQvV1B6ZG1PampCUmE0Z0pMRWNRa0RNZ2JzN21GR2d3TFhz?= =?utf-8?B?UDl1VG9vTFFEVzYzLzc1MVdHSGFoZW9CQWsvUGFHaTA5bjJzUEpRenBoYXBF?= =?utf-8?B?cE11ZDUzbFA2cTNLRUxmcnBHOFNVeXF2b2dRYXdIMDhYcGlxNUVBRmNnK2NB?= =?utf-8?B?cjE3NUVDSi92NGJmWE82eWs5NG4zWjF6MHByN01ZM01BRHE1VEhOU3hzMDFX?= =?utf-8?Q?+UU/Pphmjabeu+g2QDxuYlJy/5pgHHBNqOTuA=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GWj7nBun/2ePji8r/C8rSrDZft1PugkZXSoqdiPA5+BQEOY8PpUcWr9nWyhsOlEzd/LdersOhI6dKg1U6FE7WABkg/JaI9qf54ShQyki+FcqMZ9YTYPX/kDPv2F5P6lPvPsBFNxQe2qcPKI6TLFSIQSo20UflaFyyFbE7aIMUxMP30ZtYdskF6cbhR6N6GqxazR5/1qq+Fbjy1pVXlX8i3DezjoD6k1Bl6z1gjI3/2b62lZnecoxnIeE908XUva4ylr3kZcmnd1YrNXA+RoHpaNJDKSoCygsT1jm4KfWvObM68uQrj4N9jwRwSnJhVeINd/AEvb2aThvCuyy0/+WcK4S6KSkwgVVS67hHRScaKkAyDECXG3IiTlh6flhKT1TQEJ5L2pMmAXXTipKGdB5574NLpVLbRqfrYJxABgDRpw= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983011DB64DCA1E5417487ADA660CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: a86ea474-0c88-4039-dcc2-08d6914b0e71 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2019 00:34:46.8880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0406 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 00:34:54 -0000 --_000_CY4PR22MB0983011DB64DCA1E5417487ADA660CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCwgSSB0aGluayB0aGUgcmVjb21tZW5kYXRpb24gd291bGQgYmVjb21lIHRoYXQgeW91IGdp dmUgdGhlIHBlZXIgYXMgbWFueSBhcyB5b3UgYXJlIHdpbGxpbmcgdG8gaXNzdWUsIGJ1dCBub3Qg bW9yZSB0aGFuIHRoZSBudW1iZXIgdGhleeKAmXZlIHJlcXVlc3RlZC4gIFRoZSBvbmx5IG1pbmlt dW0gaW4gcGxheSB3b3VsZCBiZSBndWlkYW5jZSB0aGF0IGlmIOKAnGFzIG1hbnkgYXMgeW91IGFy ZSB3aWxsaW5nIHRvIGlzc3Vl4oCdIGlzIDEsIHlvdSBhcmUgbGltaXRpbmcgUVVJQ+KAmXMgdXNl ZnVsbmVzcy4NCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgVGVkIEhhcmRpZQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTkgMzo0NiBQTQ0K VG86IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6 IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtl QGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBFaWdodCBDSURzPw0KDQpPbiBUdWUsIEZlYiAxMiwg MjAxOSBhdCAzOjE3IFBNIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmll dGYub3JnPG1haWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkknbSBu b3QgYXdhcmUgb2YgYW4gb24tbGlzdCBkaXNjdXNzaW9uLCBidXQgUFIjMTk5ODxodHRwczovL2dp dGh1Yi4uY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzE5OTg+IHdpbGwgcmVtb3ZlIHRoYXQg cmVjb21tZW5kYXRpb24gYW5kIHJlcGxhY2UgaXQgd2l0aCBhIHRyYW5zcG9ydCBwYXJhbWV0ZXIg b25jZSBpdCBsYW5kcy4NCg0KSSBhZ3JlZSB0aGF0IDggc2VlbXMgZXh0cmVtZWx5IGhpZ2guDQoN Cg0KU28sIHBlcmhhcHMgSSdtIHJlYWRpbmcgdGhpcyB3cm9uZywgYnV0IGRvZXNuJ3QgdGhhdCBQ UiBkaXNjdXNzIGNvbW11bmljYXRpbmcgdGhlICptYXhpbXVtKiBudW1iZXIgb2YgQ0lEcyB5b3Ug YXJlIHdpbGluZyB0byBzdG9yZT8gIDgsIGlmIHVzZWQgdGhlcmUsIHdvdWxkIGJlIHRoZSAqZGVm YXVsdCBtYXhpbXVtKiwgbm90IHRoZSBtaW5pbXVtPyAgQXMgYSBkZWZhdWx0IG1heGltdW0sIEkg ZG9uJ3QgdGhpbmsgOCBpcyBoaWdoLg0KDQpJIGRvIHRoaW5rIHlvdSBuZWVkIGEgZGVmYXVsdCBt aW5pbXVtLCBhbmQgdGhhdCB0aGUgbWluaW11bSBtaWdodCBlbmQgdXAgcHJldHR5IHNtYWxsICgy LCBzYXksIHRvIGhhdmUgb25lIGluIHVzZSBhbmQgb25lIHNwYXJlKSwgYnV0IEkgdGhpbmsgdGhh dCB0aGUgc21hbGxlciBpdCBpcyB0aGUgbW9yZSBvZnRlbiBNYXJ0aW4gRHVrZSdzIGNvbmNlcm4g YWJvdXQgYSBsYXJnZSBudW1iZXIgb2YgY29ubmVjdGlvbiBJRCBwdWxscyB3aWxsIGNvbWUgdHJ1 ZS4gIElmIHdlIGRvbid0IHdhbnQgdG8gaGF2ZSB0byByZS1hZGp1c3QgdGhpcyBsYXRlciB3aGVu IG11bHRpcGF0aCBjb21lcyBpbiwgSSB0aGluayB0aGUgY29tYmluYXRpb24gb2YgbXVsdGlwYXRo IGFuZCBjb25uZWN0aW9uIG1pZ3JhdGlvbiBtaWdodCBtYWtlIDggYSByZWFzb25hYmxlIG1pbmlt dW0uICBJZiB0aGlzIHdpbGwgZ2V0IHJlLXdvcmtlZCBmb3Igb3RoZXIgcmVhc29ucyB0aGVuLCB0 aG91Z2gsIHRoaXMgY29uY2VybiBkb2VzIG5vdCBhcHBseS4NCg0KVGVkDQoNCg0KT24gVHVlLCBG ZWIgMTIsIDIwMTkgYXQgNDo1NCBQTSBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5j b208bWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPj4gd3JvdGU6DQpDYW4gc29tZW9uZSBw b2ludCBtZSB0byB0aGUgZGlzY3Vzc2lvbiB3aGVyZSB3ZSBkZWNpZGVkIHRoYXQgd2UgbmVlZGVk IDggQ0lEcz8gVGhhdCBzZWVtcyByZWFsbHkgaGlnaCB0byBtZS4uDQo= --_000_CY4PR22MB0983011DB64DCA1E5417487ADA660CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZWxsLCBJIHRoaW5rIHRoZSByZWNvbW1lbmRhdGlvbiB3b3VsZCBiZWNvbWUgdGhhdCB5b3UgZ2l2 ZSB0aGUgcGVlciBhcyBtYW55IGFzIHlvdSBhcmUgd2lsbGluZyB0byBpc3N1ZSwgYnV0IG5vdCBt b3JlIHRoYW4gdGhlIG51bWJlciB0aGV54oCZdmUgcmVxdWVzdGVkLiZuYnNwOyBUaGUgb25seSBt aW5pbXVtIGluIHBsYXkgd291bGQgYmUgZ3VpZGFuY2UgdGhhdCBpZiDigJxhcyBtYW55IGFzIHlv dSBhcmUgd2lsbGluZyB0bw0KIGlzc3Vl4oCdIGlzIDEsIHlvdSBhcmUgbGltaXRpbmcgUVVJQ+KA mXMgdXNlZnVsbmVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMg Jmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NClRlZCBI YXJkaWU8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTkgMzo0NiBQ TTxicj4NCjxiPlRvOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1h cmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0 Zi5vcmcmZ3Q7OyBNYXJ0aW4gRHVrZSAmbHQ7bWFydGluLmguZHVrZUBnbWFpbC5jb20mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBFaWdodCBDSURzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDEyLCAyMDE5IGF0IDM6MTcgUE0gSWFuIFN3ZXR0 ICZsdDtpYW5zd2V0dD08YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3QgYXdhcmUgb2YgYW4gb24tbGlzdCBkaXNjdXNzaW9u LCBidXQgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVs bC8xOTk4IiB0YXJnZXQ9Il9ibGFuayI+DQpQUiMxOTk4PC9hPiB3aWxsIHJlbW92ZSB0aGF0IHJl Y29tbWVuZGF0aW9uIGFuZCByZXBsYWNlIGl0IHdpdGggYSB0cmFuc3BvcnQgcGFyYW1ldGVyIG9u Y2UgaXQgbGFuZHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFncmVlIHRoYXQgOCBzZWVtcyBleHRyZW1lbHkgaGlnaC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCBwZXJoYXBz IEknbSByZWFkaW5nIHRoaXMgd3JvbmcsIGJ1dCBkb2Vzbid0IHRoYXQgUFIgZGlzY3VzcyBjb21t dW5pY2F0aW5nIHRoZSAqbWF4aW11bSogbnVtYmVyIG9mIENJRHMgeW91IGFyZSB3aWxpbmcgdG8g c3RvcmU/Jm5ic3A7IDgsIGlmIHVzZWQgdGhlcmUsIHdvdWxkIGJlIHRoZSAqZGVmYXVsdCBtYXhp bXVtKiwgbm90IHRoZSBtaW5pbXVtPyZuYnNwOyBBcyBhIGRlZmF1bHQgbWF4aW11bSwgSSBkb24n dCB0aGluaw0KIDggaXMgaGlnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBkbyB0aGluayB5b3UgbmVlZCBhIGRlZmF1bHQgbWluaW11bSwg YW5kIHRoYXQgdGhlIG1pbmltdW0gbWlnaHQgZW5kIHVwIHByZXR0eSBzbWFsbCAoMiwgc2F5LCB0 byBoYXZlIG9uZSBpbiB1c2UgYW5kIG9uZSBzcGFyZSksIGJ1dCBJIHRoaW5rIHRoYXQgdGhlIHNt YWxsZXIgaXQgaXMgdGhlIG1vcmUgb2Z0ZW4gTWFydGluIER1a2UncyBjb25jZXJuIGFib3V0IGEg bGFyZ2UgbnVtYmVyIG9mIGNvbm5lY3Rpb24NCiBJRCBwdWxscyB3aWxsIGNvbWUgdHJ1ZS4mbmJz cDsgSWYgd2UgZG9uJ3Qgd2FudCB0byBoYXZlIHRvIHJlLWFkanVzdCB0aGlzIGxhdGVyIHdoZW4g bXVsdGlwYXRoIGNvbWVzIGluLCBJIHRoaW5rIHRoZSBjb21iaW5hdGlvbiBvZiBtdWx0aXBhdGgg YW5kIGNvbm5lY3Rpb24gbWlncmF0aW9uIG1pZ2h0IG1ha2UgOCBhIHJlYXNvbmFibGUgbWluaW11 bS4mbmJzcDsgSWYgdGhpcyB3aWxsIGdldCByZS13b3JrZWQgZm9yIG90aGVyIHJlYXNvbnMgdGhl biwgdGhvdWdoLA0KIHRoaXMgY29uY2VybiBkb2VzIG5vdCBhcHBseS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGVkPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEZlYiAxMiwgMjAxOSBhdCA0OjU0IFBNIE1hcnRpbiBEdWtlICZsdDs8YSBo cmVmPSJtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0 aW4uaC5kdWtlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiBzb21lb25lIHBv aW50IG1lIHRvIHRoZSBkaXNjdXNzaW9uIHdoZXJlIHdlIGRlY2lkZWQgdGhhdCB3ZSBuZWVkZWQg OCBDSURzPyBUaGF0IHNlZW1zIHJlYWxseSBoaWdoIHRvIG1lLi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR22MB0983011DB64DCA1E5417487ADA660CY4PR22MB0983namp_-- From nobody Tue Feb 12 17:46:00 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3812F130EE1 for ; Tue, 12 Feb 2019 17:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=g2SxsaUf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mE3OwLbh 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 ABybL0Ns1kGg for ; Tue, 12 Feb 2019 17:45:56 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C1C130DE4 for ; Tue, 12 Feb 2019 17:45:56 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B32982202A for ; Tue, 12 Feb 2019 20:45:55 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Tue, 12 Feb 2019 20:45:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date; s=fm1; bh=CW9lLa3t9eAEs98rh6utWl3iKj f+6xRArvDdecWnCiM=; b=g2SxsaUffBPGVuGYnMldTYMUJeVsqB7Yt8xpSPXP39 NaAG/mbpqiA8iY2JxnMOgA9DBmoOo/UQWMvdQaVDfXdmWr0v9/cuY19oeGChOqDC zvN15JnOr+Pjoh6n12SYkYwAaY19NWCPoZ2ap0DBSv//F0jRw9MZFdp1MqbpAIN6 d9WycckldNIGNqGjUlsAUoYesThuAwFz/ES01Cecup5li2ctLm6RZOTKLMd6g92E UnlIofpiLRSk7po69XnzZ1Q2nZwfNHteozKs4j247hkl8t1j93CJLSJCeYI7KEeD NwH3osVOIVpRwl1AimSeb4058BKSSdCiTD33HSJl3u9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=CW9lLa 3t9eAEs98rh6utWl3iKjf+6xRArvDdecWnCiM=; b=mE3OwLbhcjoV6Ag3uWA08T TPdDKmG6ja7KCdceUfmkILOXbxbgQAg2K4Df65MyQI7rNHYqbgTm7lycnXrFqe5j 8JuNcowz+XWFfNkqe73IMTOYgjH+JwoqoySFHko6BvpHNis4bu1Kbg/GbjRgPWQi RUAb9BeFl+GAqnlemVvHPA2dfKd0CY9wVxe+msUbo3kkI1Sv9rM6v1MCLzORP6v+ T5EKl35XhL4cIAxUddvXEeOvmySsas6a/UqcXanSSJx1FCEL/DJlgrVkZpUPAu8Q 6O8fnQbtUkYO/oN2I+pOCt+qo5B5N1SVglov49vL6a4VISuztlPBPTShZhK0HiRw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtvddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecuogetfeejfedqtdegucdlhedtmdenucfjughrpefkhffvggfgtgfoufffsehtje ertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6CFBB9E539; Tue, 12 Feb 2019 20:45:55 -0500 (EST) Message-Id: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 Subject: KEYS_READY Date: Wed, 13 Feb 2019 12:45:55 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 01:45:59 -0000 https://github.com/quicwg/base-drafts/pull/2237 has been updated to include the discussed new frame. This allows us to remove the implicit-ish acknowledgment of Initial packets, fix the problem Marten identified with discarding Handshake keys, and the problem Kazuho found with multiple and simultaneous key updates. There were two designs that were valid here, and I want to ensure that people think about the choice: The one I chose to write up uses a design like ACK. The keys used to protect the packet determine how the frame is interpreted. That is, KEYS_READY in a packet implies that the corresponding keys are in use. The cost here is that you have to purge any potential retransmissions of KEYS_READY when you update keys or you risk creating a false signal. The alternative involves more explicit signaling, and requires us to label each set of keys unambiguously. For that we could borrow the DTLS epoch convention, though that is inconveniently out of phase with the Key Phase we use; not a major issue, but a little hard to reason about. This doesn't have a retransmission problem, but in addition to the need to document the counting system, we would need to decide whether a mismatch between frame and packet is OK, or something that can produce a connection error. Obviously, I have a preference for the former, but if people feel differently, this is a good place to register your reasons. Editorial concerns should be directed toward the pull request. From nobody Tue Feb 12 21:55:42 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B49131023 for ; Tue, 12 Feb 2019 21:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80JuvNkwB8FS for ; Tue, 12 Feb 2019 21:55:38 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 4B5CF130F35 for ; Tue, 12 Feb 2019 21:55:38 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id v7so855119lfd.2 for ; Tue, 12 Feb 2019 21:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=s1HFUpgagEsxga9ye+RFJ7L2b0IsMiue6zBtysPJruE=; b=IjTw5BFez4rBmBQr0faHnzV6iB/8XLDb5h21tHMz7STQYjZow1CInRmr+o4IYLqBwx e0rAiOJDE2fl4FUUToBLrglZNl6jpIyjI4sHMZWZOuzYu/UYR7wb99mo+UMeJmEm05kq 98Evfxx3OocZnLQhXEhezMPSC2Vbt+IPRcSiZ7m2txYYJoXjLFTYZ6qDax4WXEL0rgpg qPFz/BLUkGLqXgC/cOk7Ok1bF29uL/89DcX99K9QJkRyf+L6ud6EAdxoNeB30V5wi6H+ z/DgXh1ytm8fWAl7UuQi+tZCyLi5x0IkYUZKefJB1UaUAgPs6vIAPWJP7vg41P96m2MF dBtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s1HFUpgagEsxga9ye+RFJ7L2b0IsMiue6zBtysPJruE=; b=rDgvlX1p0/8U2paqCPb8OiJjdsvAXdgOvJHE1B3TvGXl6bfSTiovbJDsN5/9HPCKm+ Cp7QXOkfDjq2JkB6MNe4NeSZg2dz68lUiFl/T9JwZPcqtFHVRPrCdH0fsQKhlv07U0Jp 5PlMKt8NHU+lMgiDzNAb8WYEDi1SC3OvLjvv9n/IcKWkP564usJutMoNJFTGOZrfK4kH K3NLKrTF20MW1SMeVH3osRqqN5yEXJKW3ltP5T43oV1bC7q6C7yHw39QyrUGG6T5itOR 6OrRS90GePJZcl8WPk9DKWQv4yFLEZeTSTL7+dWz6pibqnYq+Kel4+pqFP508CIvGXAK YFuA== X-Gm-Message-State: AHQUAuZrqoHlYvqTZnSh3LCyNdsGxWM9+dtWXkHkTB+wToUgdKd5C83g Mw8xKOU36iPG2ml8imvMoS7ksZ+cILjay3AgD+s+NA== X-Google-Smtp-Source: AHgI3IZKvKNme56PiAmMXuw6+LrquHTt3C19lNVuwsYFGCRVEO27KqyCy953d2x0m4Btzr0QuRtf9zaTcquIS0roPPQ= X-Received: by 2002:a19:1d1:: with SMTP id 200mr4546313lfb.7.1550037333521; Tue, 12 Feb 2019 21:55:33 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> In-Reply-To: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> From: Kazuho Oku Date: Wed, 13 Feb 2019 14:55:22 +0900 Message-ID: Subject: Re: KEYS_READY To: Martin Thomson Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 05:55:41 -0000 Hi, Martin Thank you for writing the PR. My comments inline. 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson : > > https://github.com/quicwg/base-drafts/pull/2237 has been updated to inclu= de the discussed new frame. > > This allows us to remove the implicit-ish acknowledgment of Initial packe= ts, fix the problem Marten identified with discarding Handshake keys, and t= he problem Kazuho found with multiple and simultaneous key updates. > > There were two designs that were valid here, and I want to ensure that pe= ople think about the choice: > > The one I chose to write up uses a design like ACK. The keys used to pro= tect the packet determine how the frame is interpreted. That is, KEYS_READ= Y in a packet implies that the corresponding keys are in use. The cost her= e is that you have to purge any potential retransmissions of KEYS_READY whe= n you update keys or you risk creating a false signal. > > The alternative involves more explicit signaling, and requires us to labe= l each set of keys unambiguously. My weak preference goes to burning a bit in the first byte (we have reserved bits in all the necessary packet types) due to the exceptional retransmission rule that we would have for the frame, but I'm not sure how much I care. > For that we could borrow the DTLS epoch convention, though that is inconv= eniently out of phase with the Key Phase we use; not a major issue, but a l= ittle hard to reason about. This doesn't have a retransmission problem, bu= t in addition to the need to document the counting system, we would need to= decide whether a mismatch between frame and packet is OK, or something tha= t can produce a connection error. > > Obviously, I have a preference for the former, but if people feel differe= ntly, this is a good place to register your reasons. > > Editorial concerns should be directed toward the pull request. > --=20 Kazuho Oku From nobody Wed Feb 13 00:36:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F0612D4E6 for ; Wed, 13 Feb 2019 00:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 g4DLdpPr1THj for ; Wed, 13 Feb 2019 00:36:13 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 A28A7128CB7 for ; Wed, 13 Feb 2019 00:36:13 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id l131so3735626ita.2 for ; Wed, 13 Feb 2019 00:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Do3NR88y6B2ZEm0OWkGt9W9lLhOzBFwJqyoveHYigUc=; b=UvcyMlGG4LTLQhTNJfsw35XGF5ZgIJdin4pAVuIc7I39FUPdZwVGcT6cU2mAHLuEgL yREEU/B0mEgQQBrbTOyoqY1miugceFlRbKFHmCtFim17QVVFv1Iy+teAQZrD35Ma7en7 0EI1U885a612ts2BBRCgPjoLv3Ce8b+v2H4XP8lb5zb+heBNLymP333PBlHEHFyJUWEv ht7/xSg3XGZuZ0W6eRqVL84x4p0ygzPwDCEu49mEKomaCreF3llylNBkUQKdx/gQ8f0p PTUOWm4v3Q6wr3k1sB6zdLkXYRgFP3qyFJGwTC5Nktws6lto5LZHCo3yfJmg1Xdv8IfK xtNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Do3NR88y6B2ZEm0OWkGt9W9lLhOzBFwJqyoveHYigUc=; b=J0JyTHu428nzG9DBMkPvZzhq27zTDxCjIX0Dpv5mpEHK7fStEslwp/3MUIUynGfe2z 1THlvozNv4wcGAyrSbgYGj2SReypBnofIVa0SiebyOapHIltJMg1AUhrp8d5L84lOCSN ABmgxNIrLlFlmMmA0SoWhdgWXJPPnkXlYaEFCJ3CM3FyniY+N9aE/0f01KMB0yPZzhw1 pN3NQdCS56ppxFCKLRVQmV66kUT7PxnNXj1IavJSs+ibXxYd2/YFD+Ot8gACXviSSMpt HrQPCMqUX9I6ju7e2rKqluch98+JOyfVk3Wi47zc1v/sj0izi8qWKTre7Ck54UvN7B1I CxMA== X-Gm-Message-State: AHQUAub7uQ1IEViwaZUkfCPQ/H44vi3z4bUfuvdHU8baOiqQ/Drms6f2 jkpmXSUtkMbYJu80hGoFCodFLDfVoMtrb57Y14o= X-Google-Smtp-Source: AHgI3Ibs7Iek36plyDu970VoWHCCL8tX7/wvj4lRHaRDGKx8xFB+KB2C7nWLBefg+REx0QbXoGqPORazwdIqXKa/qQY= X-Received: by 2002:a6b:5b01:: with SMTP id v1mr4041718ioh.12.1550046972830; Wed, 13 Feb 2019 00:36:12 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Feb 2019 00:36:11 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 13 Feb 2019 00:36:11 -0800 Message-ID: Subject: Re: KEYS_READY To: Martin Thomson , Kazuho Oku Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000003369d30581c26f67" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 08:36:16 -0000 --0000000000003369d30581c26f67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for pointing out the second alternative, although reluctantly. I think the first option with anonymous KEY_READY has a problem with idempotency as well as tying state to retransmission logic. This means that naive retransmission of packet content in a new packet number is no longer valid, and likewise, naive processing of a frame that passes authentication is also no longer possible. That is a strong principle break and I don=E2= =80=99t think the minor simplicity of a label-less KEY_READY frame can justify that (even if one ought no do such naive transmission). You could state that the KEY_PHASE bit is the lower bit the key counter which increments by one on each key update, starting at 0 or 1. Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an old count is ignored. The key phase or the packet protection of the packet containing the KEY_READY frame is of no significance. I also suspect that the alternatively two-bit proposal might have a problem with idempotency, but I think it sorts itself by failing packet protection. The text mentions that the updated key depends on the current traffic key with reference to TLS 1.3. From reading this naively, it sounds like forward secrecy is lost, which I am sure it is not. Finally, this is just a high level view. I find the overall text hard to understand, notably because it is not crystal clear whether the two endpoints update their transmission keys in sync with the ready keys, or if the (currently implicity) key phase counters can count independently. That said, I like the idea of an explicit READY frame, and i probably would also like and explicit handshake ready frame, if it isn=E2=80=99t effective= ly the same thing, and if it is, perhaps formalise that. Mikkel On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote: Hi, Martin Thank you for writing the PR. My comments inline. 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson : > > https://github.com/quicwg/base-drafts/pull/2237 has been updated to include the discussed new frame. > > This allows us to remove the implicit-ish acknowledgment of Initial packets, fix the problem Marten identified with discarding Handshake keys, and the problem Kazuho found with multiple and simultaneous key updates. > > There were two designs that were valid here, and I want to ensure that people think about the choice: > > The one I chose to write up uses a design like ACK. The keys used to protect the packet determine how the frame is interpreted. That is, KEYS_READY in a packet implies that the corresponding keys are in use. The cost here is that you have to purge any potential retransmissions of KEYS_READY when you update keys or you risk creating a false signal. > > The alternative involves more explicit signaling, and requires us to label each set of keys unambiguously. My weak preference goes to burning a bit in the first byte (we have reserved bits in all the necessary packet types) due to the exceptional retransmission rule that we would have for the frame, but I'm not sure how much I care. > For that we could borrow the DTLS epoch convention, though that is inconveniently out of phase with the Key Phase we use; not a major issue, but a little hard to reason about. This doesn't have a retransmission problem, but in addition to the need to document the counting system, we would need to decide whether a mismatch between frame and packet is OK, or something that can produce a connection error. > > Obviously, I have a preference for the former, but if people feel differently, this is a good place to register your reasons. > > Editorial concerns should be directed toward the pull request. > --=20 Kazuho Oku --0000000000003369d30581c26f67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Thanks for pointing = out the second alternative, although reluctantly.

I think the first option with anonymous KEY_RE= ADY has a problem with idempotency as well as tying state to retransmission= logic. This means that naive retransmission of packet content in a new pac= ket number is no longer valid, and likewise, naive processing of a frame th= at passes authentication is also no longer possible. That is a strong princ= iple break and I don=E2=80=99t think the minor simplicity of a label-less K= EY_READY frame can justify that (even if one ought no do such naive transmi= ssion).

<= /div>
You could sta= te that the KEY_PHASE bit is the lower bit the key counter which increments= by one on each key update, starting at 0 or 1.
Then, a KEY_READY with a future count is= a PROTOCOL_VIOLATION and an old count is ignored. The key phase or the pac= ket protection of the packet containing the KEY_READY frame is of no signif= icance.

<= /div>
I also suspec= t that the alternatively two-bit proposal might have a problem with idempot= ency, but I think it sorts itself by failing packet protection.

The text mentions that the updat= ed key depends on the current traffic key with reference to TLS 1.3. From r= eading this naively, it sounds like forward secrecy is lost, which I am sur= e it is not.
=
Finally,= this is just a high level view. I find the overall text hard to understand= , notably because it is not crystal clear whether the two endpoints update = their transmission keys in sync with the ready keys, or if the (currently i= mplicity) key phase counters can count independently.

That said, I like the idea of an explicit = READY frame, and i probably would also like and explicit handshake ready fr= ame, if it isn=E2=80=99t effectively the same thing, and if it is, perhaps = formalise that.

Mikke= l

On 13 February 2019 at 06.55.57, Kazuho= Oku (kazuhooku@gmail.com) wrote= :

Hi, Martin

Thank you for writing the PR. My comments inline.

2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson <= mt@lowentropy.net>:
>
> https:= //github.com/quicwg/base-drafts/pull/2237 has been updated to include t= he discussed new frame.
>
> This allows us to remove the implicit-ish acknowledgment of Initia= l packets, fix the problem Marten identified with discarding Handshake keys= , and the problem Kazuho found with multiple and simultaneous key updates.
>
> There were two designs that were valid here, and I want to ensure = that people think about the choice:
>
> The one I chose to write up uses a design like ACK. The keys used= to protect the packet determine how the frame is interpreted. That is, KE= YS_READY in a packet implies that the corresponding keys are in use. The c= ost here is that you have to purge any potential retransmissions of KEYS_RE= ADY when you update keys or you risk creating a false signal.
>
> The alternative involves more explicit signaling, and requires us = to label each set of keys unambiguously.

My weak preference goes to burning a bit in the first byte (we have
reserved bits in all the necessary packet types) due to the
exceptional retransmission rule that we would have for the frame, but
I'm not sure how much I care.

> For that we could borrow the DTLS epoch convention, though that is= inconveniently out of phase with the Key Phase we use; not a major issue, = but a little hard to reason about. This doesn't have a retransmission = problem, but in addition to the need to document the counting system, we wo= uld need to decide whether a mismatch between frame and packet is OK, or so= mething that can produce a connection error.
>
> Obviously, I have a preference for the former, but if people feel = differently, this is a good place to register your reasons.
>
> Editorial concerns should be directed toward the pull request.
>


-- =20
Kazuho Oku

--0000000000003369d30581c26f67-- From nobody Wed Feb 13 04:59:54 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4478128CE4 for ; Wed, 13 Feb 2019 04:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 eDw58-83ge2G for ; Wed, 13 Feb 2019 04:59:49 -0800 (PST) Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 B5E74128CB7 for ; Wed, 13 Feb 2019 04:59:49 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id o131so5639876itc.5 for ; Wed, 13 Feb 2019 04:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CU2/glF1Mb4/v81fukV6Kmu10Vou1SDEKA0Re5U2sEQ=; b=gbFFSbLU+vjWN26qJcupr1US6kxthdLtfEMW6LW0sJHde+5CBLsdHRdV5YnnqEuYuz Ncyrd37aaLdEG9DriACXRXzjp2Bj6B4qShAGbQl8FnUL7Kr2rHd6rU18aAjOA3ycokhw lA1OnHpVZXha1x0YSk0d8ldlePrkKu8/Nt0qajL0TCWlDCFt9MMa8Wd0y4+7PtwFrEnu XZDNdB55eddzegbNf1Q7ohCu/M8iPuqFXu7aTN+3xbyevpxUgSruYKfkIAaAEyMnExco jmqZKmRlHPZbj0IVhuiXap5hEtlPzqwSQDRqa8fCM1sydkBUx/igLhre6vJAD18F/jpv Hsiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CU2/glF1Mb4/v81fukV6Kmu10Vou1SDEKA0Re5U2sEQ=; b=BAGgwNClISrjO6hgVNVO3LU7J2A5IeOtujAPGaRxOILOlv92fgdUogFsLkMWKhIjTj V3APRMukyrfKdzZhsUAwOr5CgKvK6yWIr8LF+m9rKGmBfgXkYd+mbOmqPturur2QCHPy U5Bre/Np7DtF3Y1DM0LfVktl4uklJdnx2oh1QkcHFGi7EhGpcDr76QSEeS4PV7cO2HHg TeKnD5A5vrFCNfH1Oa/2+zTJNiW9lcAbxwHSlWPYXJBfPasrKt0DY8vOExJt1HNoosji LWGS4U9OxVsIwGNqBF8KNYX49lpPlzrdOxp3dlEeLz3FJ0VXM/hbIY7KdDL1KDc5T9RL Km6w== X-Gm-Message-State: AHQUAua625w4rWvc4WG/nMaUuWg1S8LRLOsD4Q+I+Q/E2TS5EZK3bLYy 6yZKqpAHqm+C+NQCp0d0ErRyBzIbQ9NIecWeOFg= X-Google-Smtp-Source: AHgI3IZe9nZJfd/K/DmsnFNpg4TQbufxNb3BMxutfPaAKWW4msIIEivLWOa9LOm5pr/HorG0CZZHKeCXJmy6XKdRQz4= X-Received: by 2002:a6b:f102:: with SMTP id e2mr211781iog.195.1550062788766; Wed, 13 Feb 2019 04:59:48 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> In-Reply-To: From: Marten Seemann Date: Wed, 13 Feb 2019 20:59:37 +0800 Message-ID: Subject: Re: KEYS_READY To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , Kazuho Oku , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e76f460581c61da3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 12:59:53 -0000 --000000000000e76f460581c61da3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I went through a few key update scenarios under different packet loss patterns, and I have to admit that I found the KEY_READY frame surprisingly difficult to reason about. The problem seems to be that we're replacing what is in reality a contiguous state (it is permitted to update the keys) with a one-time signal, which has to be retransmitted (taking care to either block further key updates until this frame has been acknowledged, or canceling the retransmission when performing another key update). The reason we decided to create an explicit signal instead of consulting the loss recovery state, was that we wanted to avoid a tight coupling between the loss recovery and the key management. I have the impression that we're now just trading one tight coupling for a slightly different one. I agree with Kazuho that using a bit in the first byte seems to capture the update logic we're looking for better. There's no need to retransmit any information, since the bit is set on every subsequent packet. On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Thanks for pointing out the second alternative, although reluctantly. > > I think the first option with anonymous KEY_READY has a problem with > idempotency as well as tying state to retransmission logic. This means th= at > naive retransmission of packet content in a new packet number is no longe= r > valid, and likewise, naive processing of a frame that passes authenticati= on > is also no longer possible. That is a strong principle break and I don=E2= =80=99t > think the minor simplicity of a label-less KEY_READY frame can justify th= at > (even if one ought no do such naive transmission). > > You could state that the KEY_PHASE bit is the lower bit the key counter > which increments by one on each key update, starting at 0 or 1. > Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an old > count is ignored. The key phase or the packet protection of the packet > containing the KEY_READY frame is of no significance. > > I also suspect that the alternatively two-bit proposal might have a > problem with idempotency, but I think it sorts itself by failing packet > protection. > > The text mentions that the updated key depends on the current traffic key > with reference to TLS 1.3. From reading this naively, it sounds like > forward secrecy is lost, which I am sure it is not. > > Finally, this is just a high level view. I find the overall text hard to > understand, notably because it is not crystal clear whether the two > endpoints update their transmission keys in sync with the ready keys, or = if > the (currently implicity) key phase counters can count independently. > > That said, I like the idea of an explicit READY frame, and i probably > would also like and explicit handshake ready frame, if it isn=E2=80=99t e= ffectively > the same thing, and if it is, perhaps formalise that. > > Mikkel > > On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote: > > Hi, Martin > > Thank you for writing the PR. My comments inline. > > 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson : > > > > https://github.com/quicwg/base-drafts/pull/2237 has been updated to > include the discussed new frame. > > > > This allows us to remove the implicit-ish acknowledgment of Initial > packets, fix the problem Marten identified with discarding Handshake keys= , > and the problem Kazuho found with multiple and simultaneous key updates. > > > > There were two designs that were valid here, and I want to ensure that > people think about the choice: > > > > The one I chose to write up uses a design like ACK. The keys used to > protect the packet determine how the frame is interpreted. That is, > KEYS_READY in a packet implies that the corresponding keys are in use. Th= e > cost here is that you have to purge any potential retransmissions of > KEYS_READY when you update keys or you risk creating a false signal. > > > > The alternative involves more explicit signaling, and requires us to > label each set of keys unambiguously. > > My weak preference goes to burning a bit in the first byte (we have > reserved bits in all the necessary packet types) due to the > exceptional retransmission rule that we would have for the frame, but > I'm not sure how much I care. > > > For that we could borrow the DTLS epoch convention, though that is > inconveniently out of phase with the Key Phase we use; not a major issue, > but a little hard to reason about. This doesn't have a retransmission > problem, but in addition to the need to document the counting system, we > would need to decide whether a mismatch between frame and packet is OK, o= r > something that can produce a connection error. > > > > Obviously, I have a preference for the former, but if people feel > differently, this is a good place to register your reasons. > > > > Editorial concerns should be directed toward the pull request. > > > > > -- > Kazuho Oku > > --000000000000e76f460581c61da3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I went through a few key update scenarios under diffe= rent packet loss patterns, and I have to admit that I found the KEY_READY f= rame surprisingly difficult to reason about. The problem seems to be that w= e're replacing what is in reality a contiguous state (it is permitted t= o update the keys) with a one-time signal, which has to be retransmitted (t= aking care to either block further key updates until this frame has been ac= knowledged, or canceling the retransmission when performing another key upd= ate). The reason we decided to create an explicit signal instead of consult= ing the loss recovery state, was that we wanted to avoid a tight coupling b= etween the loss recovery and the key management.=C2=A0I have the impression= that we're now just trading one tight coupling for a slightly differen= t one.

I agree with Kazuho that using a bit in the= first byte seems to capture the update logic we're looking for better.= There's no need to retransmit any information, since the bit is set on= every subsequent packet.



On = Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= wrote:
Thanks for pointing out the second alternative, although reluctan= tly.

I think the first option with anony= mous KEY_READY has a problem with idempotency as well as tying state to ret= ransmission logic. This means that naive retransmission of packet content i= n a new packet number is no longer valid, and likewise, naive processing of= a frame that passes authentication is also no longer possible. That is a s= trong principle break and I don=E2=80=99t think the minor simplicity of a l= abel-less KEY_READY frame can justify that (even if one ought no do such na= ive transmission).

=
You could state that t= he KEY_PHASE bit is the lower bit the key counter which increments by one o= n each key update, starting at 0 or 1.
Then, a KEY_READY with a future count is a PROTOCOL_VIOLATI= ON and an old count is ignored. The key phase or the packet protection of t= he packet containing the KEY_READY frame is of no significance.

I also suspect that the alternatively two-bit propos= al might have a problem with idempotency, but I think it sorts itself by fa= iling packet protection.
The text mention= s that the updated key depends on the current traffic key with reference to= TLS 1.3. From reading this naively, it sounds like forward secrecy is lost= , which I am sure it is not.

Finally, thi= s is just a high level view. I find the overall text hard to understand, no= tably because it is not crystal clear whether the two endpoints update thei= r transmission keys in sync with the ready keys, or if the (currently impli= city) key phase counters can count independently.

That said, I like t= he idea of an explicit READY frame, and i probably would also like and expl= icit handshake ready frame, if it isn=E2=80=99t effectively the same thing,= and if it is, perhaps formalise that.

Mikkel=

On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) = wrote:

Hi= , Martin

Thank you for writing the PR. My comments inline.

2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson <= mt@lowentropy.net>:
>
> https://github.com/quicwg/base-drafts/pull/2237 has been up= dated to include the discussed new frame.
>
> This allows us to remove the implicit-ish acknowledgment of Initia= l packets, fix the problem Marten identified with discarding Handshake keys= , and the problem Kazuho found with multiple and simultaneous key updates.
>
> There were two designs that were valid here, and I want to ensure = that people think about the choice:
>
> The one I chose to write up uses a design like ACK. The keys used= to protect the packet determine how the frame is interpreted. That is, KE= YS_READY in a packet implies that the corresponding keys are in use. The c= ost here is that you have to purge any potential retransmissions of KEYS_RE= ADY when you update keys or you risk creating a false signal.
>
> The alternative involves more explicit signaling, and requires us = to label each set of keys unambiguously.

My weak preference goes to burning a bit in the first byte (we have
reserved bits in all the necessary packet types) due to the
exceptional retransmission rule that we would have for the frame, but
I'm not sure how much I care.

> For that we could borrow the DTLS epoch convention, though that is= inconveniently out of phase with the Key Phase we use; not a major issue, = but a little hard to reason about. This doesn't have a retransmission = problem, but in addition to the need to document the counting system, we wo= uld need to decide whether a mismatch between frame and packet is OK, or so= mething that can produce a connection error.
>
> Obviously, I have a preference for the former, but if people feel = differently, this is a good place to register your reasons.
>
> Editorial concerns should be directed toward the pull request.
>


-- =20
Kazuho Oku

--000000000000e76f460581c61da3-- From nobody Wed Feb 13 05:31:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EF3128CE4 for ; Wed, 13 Feb 2019 05:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n31bwgcO5Z6j for ; Wed, 13 Feb 2019 05:31:54 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 E9D97128BCC for ; Wed, 13 Feb 2019 05:31:53 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id h6so4507027itl.1 for ; Wed, 13 Feb 2019 05:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=HBzx2tuS2GJ10A274fmK1EQ9f42RRYaKdvdFHHk0Mpg=; b=gBIuPn0zTgBYBijZtVru7x6qUfwsNWulrP44BZOrlhdCk7zzobAgYIWLP7NYw4fL3N dzuWNk2F8oxnItNcBf/+vtEJUTlSDc/3QcV7RpkKo2T/LNNs4jpMAVmYR6lGrBNq4neW Q5fj7f0yUu4MUVLsJeGFNsDXX3FMzoIeP8ZoECY1KzCGk/YgAwf/saTZLXEf12B+Fs6s k/DYZSqzE6JKrAJ6DK3k4MdQQV47VayOPgH4lnHXwiIZ8aLC8IGRwlbq5OHuVU/ct9H9 UQ89RnpHvpA/SOTo4uu9aGhsCK4P8clJ3ZoCEiQ8C+AW02sHpCEl2+Ey9GQqycmTqpjO OkOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=HBzx2tuS2GJ10A274fmK1EQ9f42RRYaKdvdFHHk0Mpg=; b=Wab38yJCx/CKM0EWfBQftA+y6ggEPAzZYirVkL0OvCl42mHYsRjXR8sWE2GlSFwlvT tdJRC3Orgn7NFkfgZCgdtG7hMyA5np2nJfb6aYjgPWOJfrzqafAsJY1RxZGhkj44Zm0M G3RZ/LSEwmBufG5FGUnmtT0ZuWaOkC1SbtcKPuNo2CtIoBhQZ+m131rMCPWPNWg8nwYk Hd8mqyM9b3Jjr4O0IL56U6u7/4U9Cet9U/W/9VuSL3roQJXesvBe+T1eBGGhWbkf6onF Pj7BlTkTiO4fhGPQAFEnwyLaOYQPCEUqiO8zq5+wKsz/JQ8tDbVKTWwoQuwSnHZTKveZ ++WA== X-Gm-Message-State: AHQUAubPDFR7rFK1qTwiu3UxFEx8ii+bDsmbRpote688HWU105o7XDHW yaG59BrkU6b23ci3DSNWY5jUywnxvBdIlQtZbV0+Mg== X-Google-Smtp-Source: AHgI3IZvFcsKoullGfF7Ji9nrKGctAdVs16DcqTnGW2VHxKKUK5RqwYeSh+lFqH1/Wt2a73oaOeVUlDaQ5GTNJGVpg8= X-Received: by 2002:a6b:f206:: with SMTP id q6mr338174ioh.166.1550064712946; Wed, 13 Feb 2019 05:31:52 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Feb 2019 05:31:52 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 13 Feb 2019 05:31:52 -0800 Message-ID: Subject: Servers Preferred Address redirection might never terminate To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000009818100581c690ab" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 13:31:56 -0000 --0000000000009818100581c690ab Content-Type: text/plain; charset="UTF-8" I filed the issue https://github.com/quicwg/base-drafts/issues/2462 Mikkel --0000000000009818100581c690ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I filed the issue


<= /div>
Mikkel

--0000000000009818100581c690ab-- From nobody Wed Feb 13 05:39:29 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5785A12DD85 for ; Wed, 13 Feb 2019 05:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWsXcjVTm8N4 for ; Wed, 13 Feb 2019 05:39:26 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 5B56B128CE4 for ; Wed, 13 Feb 2019 05:39:26 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id x131so4731014itc.3 for ; Wed, 13 Feb 2019 05:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=wHA8b24O+6TF4zK4BLHhQOgIXJjB1kFIW+mmPeeJOHI=; b=E8c19+9HdHOJy6OQMfGW/6/0Td9bweXw/dtWy4/NjbKBfesPk3RFhpCPYKLBCvTMAQ xgP+h3zC6lrGkF45TQxmRriA8ogjUpLZuMql2Nfwip6RT/Mr/V9gt5uZvukw5fbjpRlc L6ZeiwWnJaMJLK2OfMLCJEiFUljhskw+3CUEchG938kc3ljNL4H9jjeYojygzRHl9WaG cBkXYSMHZcIIbRvM0Qoz6EShUwELJAvaQcbCDusUuXCQ2eQiRw1lBhIU54dbGgq/vS6U LWACUU1Rfhtp0w3hu12JSO40ZsqJmgzJZI3xGuR+rL5vKkel23L4kJW26q8hd2IcbExI XYDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=wHA8b24O+6TF4zK4BLHhQOgIXJjB1kFIW+mmPeeJOHI=; b=NI8Gk4OAC3yrTqPzuhk5NY4lOUBereFtUnKboqjY60oJmWlvoaQKDJkz9ZPX+3uSUc jdjXl8ez9jlujhLqMEx4i5vAA0RA/YQgxoOXpzrQT/yh51jo2PUtkyN734kIcFxHrXG0 ievI1NWiFizllSwevtAal/ILDjdwEps6yU2NYfwcBPlRJecb60bBe61NAwGW51MkY0dt FkeL4YzhY5PNSodKWsNLYMjV9F8d2s2w6zUgeJApeDkL2dZafi0mUO7Qjrt+m6y+zi0S x0x68d7lZrC3L34elQ0UFJmXXEg+n/nvVE3CYzOQpfesxV9WqzSqn8kp6urJ5Ai5CNgh Uu2Q== X-Gm-Message-State: AHQUAuaRfuCFo//3c4WmXRKBocyqRT8KFvY9vR0IVtVtxhhMfZ2w0n4k XEJsDfeM1xKfCiimDlviIEQ0qGyCizkm2XuwzrnmSQ== X-Google-Smtp-Source: AHgI3IYOOpkNjGm4bBQOJJCwDf6l6IQg75gWzFiL4Px6qRE/vHFmj8Ncf5rkgR3l0kv3eeU54q1bpX/3ilt/E3pbhLc= X-Received: by 2002:a24:4487:: with SMTP id o129mr192957ita.167.1550065165371; Wed, 13 Feb 2019 05:39:25 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Feb 2019 05:39:25 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 13 Feb 2019 05:39:25 -0800 Message-ID: Subject: Re: Servers Preferred Address redirection might never terminate To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000008f97050581c6aba7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 13:39:28 -0000 --0000000000008f97050581c6aba7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But that would only happen if SPA started a new handshake, which it doesn=E2=80=99t, as Ian pointed, so the issue is closed. On 13 February 2019 at 14.31.52, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: I filed the issue https://github.com/quicwg/base-drafts/issues/2462 Mikkel --0000000000008f97050581c6aba7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = But that would only = happen if SPA started a new handshake, which it doesn=E2=80=99t, as Ian poi= nted, so the issue is closed.


On 13 February 2019 at= 14.31.52, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

--0000000000008f97050581c6aba7-- From nobody Wed Feb 13 07:03:45 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAAC12EB11 for ; Wed, 13 Feb 2019 07:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2CJW3AVpiq6 for ; Wed, 13 Feb 2019 07:03:33 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 0285A130E73 for ; Wed, 13 Feb 2019 07:03:32 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id m1so2828787wml.2 for ; Wed, 13 Feb 2019 07:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WbiECcx1cGmHQR3FwHRSuGaE+O07B7zHsYrQTdz+07k=; b=h91K+AK0TOFepxnY5LhONukmbfsxiTNksK+/arnNf3NehcAX60VUzwIjcNWgmrNZ8h BmbRRGKR7b9v+K8cvHuRNhRdblbdvZw8LKfyv1AGbQsHmWVn6PDVjN5pRxIs5hTRq6ib dQFD3MrDpVFeffcrMUXoPGl30KuF55r2V2Q0aAggHHboMIMTUfA2I0Jyk6tgC2DgSi75 DDO9LIij5bUp4JpBvNHQz7jIr3FOVtMZiip8VDja3jKtZhMHdz84KyvSOV6MWLmyJssk BXs4XQz5oW3KomtmhDN0IJvThfBhg7P8RMsz9lSmSaCXUPwMJVvRzUO+cjgxpOGxsWMB +Z1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WbiECcx1cGmHQR3FwHRSuGaE+O07B7zHsYrQTdz+07k=; b=jGkyhLvznfcz2AiPLwu+iz4M+Y36n0SZf9EoCCrA+RVk9+ygvhu3Xw8Co8VKkZqnRo dIadPqQaGEYV9HacG+qSAXUKU+GTopmmIuVr7FiZGHXAnDaaufRG5YP1g2aBAaDva0gU ylILwVIoMtQR2WniugN1wdQmthJ6JLo+Tm6lP+TlY8Jr90hFw+4f5tvTxzJyer+98j+U 1qPvjTLaqYCfd+tp/AUPiRDwusUXx4VdZn8sgB7d2QihOkV23BUyGJhNZvckIVR2hbWK 2R+I0YKIi9SDP9xSd/1MaOqUnM4Xz8x+cp1D4tXL4Dc+PJ+b8EXYFF2yeWHICXqHkg1W 2Chw== X-Gm-Message-State: AHQUAuYNRPrUUg2uW1GD3tPlMINjLVFQ1UN5tfnm0iQFSzyxgKvpsp/g fgQSo3Z47n5esyxOn01RyL2Pju3/nycSGmZ0vH9yrg== X-Google-Smtp-Source: AHgI3IaiCahsDMY3ctoohKOp9Gmy6wRUHbzRKgP34zdAdDSx9o0u/pSmevcvg+ZCQzWdlT59baEVHYXQQcb0FLbpis4= X-Received: by 2002:a7b:ce88:: with SMTP id q8mr712684wmj.78.1550070211198; Wed, 13 Feb 2019 07:03:31 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> In-Reply-To: From: Ian Swett Date: Wed, 13 Feb 2019 10:03:19 -0500 Message-ID: Subject: Re: KEYS_READY To: Marten Seemann Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000005128440581c7d8ec" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 15:03:44 -0000 --0000000000005128440581c7d8ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm happy with the approach you outline here and wrote up in the PR, but I did find the PR a bit confusing, partially because it's based on an existing PR that's gone through a lot of revisions. I don't think tying transmission of this to an encryption level will be overly complex, because since it's only a single byte, I might just put it in every ack-eliciting packet until it's no longer necessary and not use the standard retransmission logic. I'd rather not burn another bit in the first byte for this. On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann wrote: > I went through a few key update scenarios under different packet loss > patterns, and I have to admit that I found the KEY_READY frame surprising= ly > difficult to reason about. The problem seems to be that we're replacing > what is in reality a contiguous state (it is permitted to update the keys= ) > with a one-time signal, which has to be retransmitted (taking care to > either block further key updates until this frame has been acknowledged, = or > canceling the retransmission when performing another key update). The > reason we decided to create an explicit signal instead of consulting the > loss recovery state, was that we wanted to avoid a tight coupling between > the loss recovery and the key management. I have the impression that we'r= e > now just trading one tight coupling for a slightly different one. > > I agree with Kazuho that using a bit in the first byte seems to capture > the update logic we're looking for better. There's no need to retransmit > any information, since the bit is set on every subsequent packet. > > > > On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> Thanks for pointing out the second alternative, although reluctantly. >> >> I think the first option with anonymous KEY_READY has a problem with >> idempotency as well as tying state to retransmission logic. This means t= hat >> naive retransmission of packet content in a new packet number is no long= er >> valid, and likewise, naive processing of a frame that passes authenticat= ion >> is also no longer possible. That is a strong principle break and I don= =E2=80=99t >> think the minor simplicity of a label-less KEY_READY frame can justify t= hat >> (even if one ought no do such naive transmission). >> >> You could state that the KEY_PHASE bit is the lower bit the key counter >> which increments by one on each key update, starting at 0 or 1. >> Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an old >> count is ignored. The key phase or the packet protection of the packet >> containing the KEY_READY frame is of no significance. >> >> I also suspect that the alternatively two-bit proposal might have a >> problem with idempotency, but I think it sorts itself by failing packet >> protection. >> >> The text mentions that the updated key depends on the current traffic ke= y >> with reference to TLS 1.3. From reading this naively, it sounds like >> forward secrecy is lost, which I am sure it is not. >> >> Finally, this is just a high level view. I find the overall text hard to >> understand, notably because it is not crystal clear whether the two >> endpoints update their transmission keys in sync with the ready keys, or= if >> the (currently implicity) key phase counters can count independently. >> >> That said, I like the idea of an explicit READY frame, and i probably >> would also like and explicit handshake ready frame, if it isn=E2=80=99t = effectively >> the same thing, and if it is, perhaps formalise that. >> >> Mikkel >> >> On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote: >> >> Hi, Martin >> >> Thank you for writing the PR. My comments inline. >> >> 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson : >> > >> > https://github.com/quicwg/base-drafts/pull/2237 has been updated to >> include the discussed new frame. >> > >> > This allows us to remove the implicit-ish acknowledgment of Initial >> packets, fix the problem Marten identified with discarding Handshake key= s, >> and the problem Kazuho found with multiple and simultaneous key updates. >> > >> > There were two designs that were valid here, and I want to ensure that >> people think about the choice: >> > >> > The one I chose to write up uses a design like ACK. The keys used to >> protect the packet determine how the frame is interpreted. That is, >> KEYS_READY in a packet implies that the corresponding keys are in use. T= he >> cost here is that you have to purge any potential retransmissions of >> KEYS_READY when you update keys or you risk creating a false signal. >> > >> > The alternative involves more explicit signaling, and requires us to >> label each set of keys unambiguously. >> >> My weak preference goes to burning a bit in the first byte (we have >> reserved bits in all the necessary packet types) due to the >> exceptional retransmission rule that we would have for the frame, but >> I'm not sure how much I care. >> >> > For that we could borrow the DTLS epoch convention, though that is >> inconveniently out of phase with the Key Phase we use; not a major issue= , >> but a little hard to reason about. This doesn't have a retransmission >> problem, but in addition to the need to document the counting system, we >> would need to decide whether a mismatch between frame and packet is OK, = or >> something that can produce a connection error. >> > >> > Obviously, I have a preference for the former, but if people feel >> differently, this is a good place to register your reasons. >> > >> > Editorial concerns should be directed toward the pull request. >> > >> >> >> -- >> Kazuho Oku >> >> --0000000000005128440581c7d8ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm happy with the approach you outline here and wrote= up in the PR, but I did find the PR a bit confusing, partially because it&= #39;s based on an existing PR that's gone through a lot of revisions.
I don't think tying transmission of this to an encryp= tion level will be overly complex, because since it's only a single byt= e, I might just put it in every ack-eliciting packet until it's no long= er necessary and not use the standard retransmission logic.

<= /div>
I'd rather not burn another bit in the first byte for this.

On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann <martenseemann@gmail.com> wrote:
I went = through a few key update scenarios under different packet loss patterns, an= d I have to admit that I found the KEY_READY frame surprisingly difficult t= o reason about. The problem seems to be that we're replacing what is in= reality a contiguous state (it is permitted to update the keys) with a one= -time signal, which has to be retransmitted (taking care to either block fu= rther key updates until this frame has been acknowledged, or canceling the = retransmission when performing another key update). The reason we decided t= o create an explicit signal instead of consulting the loss recovery state, = was that we wanted to avoid a tight coupling between the loss recovery and = the key management.=C2=A0I have the impression that we're now just trad= ing one tight coupling for a slightly different one.

I agree with Kazuho that using a bit in the first byte seems to capture = the update logic we're looking for better. There's no need to retra= nsmit any information, since the bit is set on every subsequent packet.



On Wed, Feb 13, 2019 at 4:36 PM = Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Thanks for pointing = out the second alternative, although reluctantly.

I think the first option with anonymous KEY_READY has a pr= oblem with idempotency as well as tying state to retransmission logic. This= means that naive retransmission of packet content in a new packet number i= s no longer valid, and likewise, naive processing of a frame that passes au= thentication is also no longer possible. That is a strong principle break a= nd I don=E2=80=99t think the minor simplicity of a label-less KEY_READY fra= me can justify that (even if one ought no do such naive transmission).

You could state that the KEY_PHASE bi= t is the lower bit the key counter which increments by one on each key upda= te, starting at 0 or 1.
Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an o= ld count is ignored. The key phase or the packet protection of the packet c= ontaining the KEY_READY frame is of no significance.

I also suspect that the alternatively two-bit proposal = might have a problem with idempotency, but I think it sorts itself by faili= ng packet protection.

The text me= ntions that the updated key depends on the current traffic key with referen= ce to TLS 1.3. From reading this naively, it sounds like forward secrecy is= lost, which I am sure it is not.

Finally, this is just a high level view. I find the overall text hard to u= nderstand, notably because it is not crystal clear whether the two endpoint= s update their transmission keys in sync with the ready keys, or if the (cu= rrently implicity) key phase counters can count independently.

That said, I like the idea of an explicit READY fra= me, and i probably would also like and explicit handshake ready frame, if i= t isn=E2=80=99t effectively the same thing, and if it is, perhaps formalise= that.

Mikkel

On 13 February 2019 at = 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote:

Hi, Martin

Thank you for writing the PR. My comments inline.

2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson <= mt@lowentropy.net>:
>
> https://github.com/quicwg/base-drafts/pull/2237 has been up= dated to include the discussed new frame.
>
> This allows us to remove the implicit-ish acknowledgment of Initia= l packets, fix the problem Marten identified with discarding Handshake keys= , and the problem Kazuho found with multiple and simultaneous key updates.
>
> There were two designs that were valid here, and I want to ensure = that people think about the choice:
>
> The one I chose to write up uses a design like ACK. The keys used= to protect the packet determine how the frame is interpreted. That is, KE= YS_READY in a packet implies that the corresponding keys are in use. The c= ost here is that you have to purge any potential retransmissions of KEYS_RE= ADY when you update keys or you risk creating a false signal.
>
> The alternative involves more explicit signaling, and requires us = to label each set of keys unambiguously.

My weak preference goes to burning a bit in the first byte (we have
reserved bits in all the necessary packet types) due to the
exceptional retransmission rule that we would have for the frame, but
I'm not sure how much I care.

> For that we could borrow the DTLS epoch convention, though that is= inconveniently out of phase with the Key Phase we use; not a major issue, = but a little hard to reason about. This doesn't have a retransmission = problem, but in addition to the need to document the counting system, we wo= uld need to decide whether a mismatch between frame and packet is OK, or so= mething that can produce a connection error.
>
> Obviously, I have a preference for the former, but if people feel = differently, this is a good place to register your reasons.
>
> Editorial concerns should be directed toward the pull request.
>


-- =20
Kazuho Oku

--0000000000005128440581c7d8ec-- From nobody Wed Feb 13 07:27:08 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F38712867A for ; Wed, 13 Feb 2019 07:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljn_KXZf8aOs for ; Wed, 13 Feb 2019 07:27:04 -0800 (PST) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 DEFA6126C7E for ; Wed, 13 Feb 2019 07:27:03 -0800 (PST) Received: by mail-lf1-x144.google.com with SMTP id l10so2069721lfh.9 for ; Wed, 13 Feb 2019 07:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EK7jIr97/7Ed18DO0GBhkwgI5kHAYntG4SmeZniU+Qs=; b=IsVT2itQ9Xe/JfPgN+HO6k3jifE2yu7XnKy3t12PcvIFNmT/Eoxp8zfP1yolw8s2G9 Jq5Vbbgkg4Ol/ElgR1ASzO05zFcXzpgzkrPVKPlrAyx7cArlJH19LFOto2PobIAJ1vSe GFfWjpq3uZVlZRtAEpGJmkH4LOxPWSjS8KpdXKX2T+1EOuE5j7mwmZBk8fWwzUCjaSut AslTCNz3Q5xS6rwpspTpVyMVSBX3a3C+Rnb0D1dfIyP0gzvW2etRPoSgNOULxDqzxj+D paNvLbjUt20xJZkiX9OyWv87Ug5Z7D93KvsxSxstivz1Po4fRkZU4eAqEAEkoWuFeIRY i4ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EK7jIr97/7Ed18DO0GBhkwgI5kHAYntG4SmeZniU+Qs=; b=e03yp643akCwl9tRJwP4C+nKCC/i1e85QQNrbl23hOwrYHoiTiVJZ0fihZSKRPZqZJ sC5/lSLbtpQ2O49J5QBEbCw/fUCHUSpMvMFkBATYlPgP5AsAog9k7ISg0i0pAoi7Np1S x1qqvWAlROFQE/PtoNZvJPg+yot9hpR182KnnQU5R2YbBcozg7Pg27ohkSftABXidnNJ wBQCKZWbqH9IDoskEjI6SUlhVSnKVTRoV47VtkJSGtASLa6DSHDfDUzYIJ9xVuGKb3Q+ g89xhq7dBUKNmDZ5lmY4oNAfRPQZdxxaj4IzK6RemKYfnVH+68pbFHzN08WqB5IG2qq9 91Kg== X-Gm-Message-State: AHQUAuZRh+EdkxsTPCo6so4HKdDzo+LOwBfCP6CgPvnu7ZSaX97/OPaz JgfPJ7E/HwwlCflZaErzAOlTJdwG+5nQPuZue80= X-Google-Smtp-Source: AHgI3IZ7TTWSmgcjMnBP7RTE72nFMFrfGXcs8o0x/6ie/qENZDvP2xk77dEJ+prGaFvq7GHTa2LsVo4XJZ4KJ1v60S4= X-Received: by 2002:a19:7410:: with SMTP id v16mr683387lfe.166.1550071621891; Wed, 13 Feb 2019 07:27:01 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> In-Reply-To: From: Kazuho Oku Date: Thu, 14 Feb 2019 00:26:51 +0900 Message-ID: Subject: Re: KEYS_READY To: Ian Swett Cc: Marten Seemann , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 15:27:06 -0000 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 0:03 Ian Swett : > > I'm happy with the approach you outline here and wrote up in the PR, but = I did find the PR a bit confusing, partially because it's based on an exist= ing PR that's gone through a lot of revisions. > > I don't think tying transmission of this to an encryption level will be o= verly complex, because since it's only a single byte, I might just put it i= n every ack-eliciting packet until it's no longer necessary and not use the= standard retransmission logic. I tend to agree, because to me it the same as having a variable length packet header that, when being extended by one byte, indicates that the next key is ready. Though it seems a bit flexible. OTOH, I think it's interesting to discuss if the KEY_READY frame is ack-eliciting. My understanding is that per the current PR it is, because the list of non-ack-eliciting frames has not changed. I can see arguments for having the frame defined as ACK-eliciting, because it encourages endpoints to retire old keys soon. If we think that to be a good property, I think that might be an argument for using a frame (because calling a header bit ACK-eliciting would be strange). > > I'd rather not burn another bit in the first byte for this. > > On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann = wrote: >> >> I went through a few key update scenarios under different packet loss pa= tterns, and I have to admit that I found the KEY_READY frame surprisingly d= ifficult to reason about. The problem seems to be that we're replacing what= is in reality a contiguous state (it is permitted to update the keys) with= a one-time signal, which has to be retransmitted (taking care to either bl= ock further key updates until this frame has been acknowledged, or cancelin= g the retransmission when performing another key update). The reason we dec= ided to create an explicit signal instead of consulting the loss recovery s= tate, was that we wanted to avoid a tight coupling between the loss recover= y and the key management. I have the impression that we're now just trading= one tight coupling for a slightly different one. >> >> I agree with Kazuho that using a bit in the first byte seems to capture = the update logic we're looking for better. There's no need to retransmit an= y information, since the bit is set on every subsequent packet. >> >> >> >> On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >>> >>> Thanks for pointing out the second alternative, although reluctantly. >>> >>> I think the first option with anonymous KEY_READY has a problem with id= empotency as well as tying state to retransmission logic. This means that n= aive retransmission of packet content in a new packet number is no longer v= alid, and likewise, naive processing of a frame that passes authentication = is also no longer possible. That is a strong principle break and I don=E2= =80=99t think the minor simplicity of a label-less KEY_READY frame can just= ify that (even if one ought no do such naive transmission). >>> >>> You could state that the KEY_PHASE bit is the lower bit the key counter= which increments by one on each key update, starting at 0 or 1. >>> Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an ol= d count is ignored. The key phase or the packet protection of the packet co= ntaining the KEY_READY frame is of no significance. >>> >>> I also suspect that the alternatively two-bit proposal might have a pro= blem with idempotency, but I think it sorts itself by failing packet protec= tion. >>> >>> The text mentions that the updated key depends on the current traffic k= ey with reference to TLS 1.3. From reading this naively, it sounds like for= ward secrecy is lost, which I am sure it is not. >>> >>> Finally, this is just a high level view. I find the overall text hard t= o understand, notably because it is not crystal clear whether the two endpo= ints update their transmission keys in sync with the ready keys, or if the = (currently implicity) key phase counters can count independently. >>> >>> That said, I like the idea of an explicit READY frame, and i probably w= ould also like and explicit handshake ready frame, if it isn=E2=80=99t effe= ctively the same thing, and if it is, perhaps formalise that. >>> >>> Mikkel >>> >>> On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote= : >>> >>> Hi, Martin >>> >>> Thank you for writing the PR. My comments inline. >>> >>> 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson : >>> > >>> > https://github.com/quicwg/base-drafts/pull/2237 has been updated to i= nclude the discussed new frame. >>> > >>> > This allows us to remove the implicit-ish acknowledgment of Initial p= ackets, fix the problem Marten identified with discarding Handshake keys, a= nd the problem Kazuho found with multiple and simultaneous key updates. >>> > >>> > There were two designs that were valid here, and I want to ensure tha= t people think about the choice: >>> > >>> > The one I chose to write up uses a design like ACK. The keys used to = protect the packet determine how the frame is interpreted. That is, KEYS_RE= ADY in a packet implies that the corresponding keys are in use. The cost he= re is that you have to purge any potential retransmissions of KEYS_READY wh= en you update keys or you risk creating a false signal. >>> > >>> > The alternative involves more explicit signaling, and requires us to = label each set of keys unambiguously. >>> >>> My weak preference goes to burning a bit in the first byte (we have >>> reserved bits in all the necessary packet types) due to the >>> exceptional retransmission rule that we would have for the frame, but >>> I'm not sure how much I care. >>> >>> > For that we could borrow the DTLS epoch convention, though that is in= conveniently out of phase with the Key Phase we use; not a major issue, but= a little hard to reason about. This doesn't have a retransmission problem,= but in addition to the need to document the counting system, we would need= to decide whether a mismatch between frame and packet is OK, or something = that can produce a connection error. >>> > >>> > Obviously, I have a preference for the former, but if people feel dif= ferently, this is a good place to register your reasons. >>> > >>> > Editorial concerns should be directed toward the pull request. >>> > >>> >>> >>> -- >>> Kazuho Oku >>> --=20 Kazuho Oku From nobody Wed Feb 13 07:29:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C4E1200D7 for ; Wed, 13 Feb 2019 07:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ahQXldQeuiu9 for ; Wed, 13 Feb 2019 07:29:30 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083AF126C7E for ; Wed, 13 Feb 2019 07:29:30 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id z9so5067705itc.4 for ; Wed, 13 Feb 2019 07:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=sB2NDIEVzCI1XFIEA7N6AGZjDQmj3SluktEqA23sQck=; b=cZ3wkuHeFmZY+Ht0vERQLZ9sihp5Alwhp+lvNwdqxYmfBK6HY+ckEUXWsBkAl4FzSe Mb8e0w9fJnaz+ezfTIOiiDHg3+SCib/MxRG6rudsFwPES96y6p2CA4ayQCbJ1sv/idrz VMNkMEJjyLMydvtOX8VHU6pLcyWfrb9lOgnJGkfEsI6tL2CRyPhV8ikWbuMMknQ5bZ0Z Rpic5/1iZMv48F93dL/P2v44B3n3WYmoTtQl2svMva2HcmSSOM5qrx/V+0eegZWhmJjL 4T4JDrzAGRCVAwcSfGSw0LnKzUkhlhs6bQIuTaPWBCiMl4blXPlSIH5Wk9grK1r65C/l CvSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=sB2NDIEVzCI1XFIEA7N6AGZjDQmj3SluktEqA23sQck=; b=BgeVQwWdV8DO+i4mXvkeIaGaGWqfJS9WE0foiiSz3+61HuMiVi9jq/WGLs7aw93n3N Ju/ovFd//aNobBY7te5NLGqutkzxHxeeTdxrwp9b0oxCVO5dNa8X+N5U/ng9q+PY3cc7 ehTncngq8Kdn7pOn2gw6Y4BDIZNqr/mtKAzl38l5ieaBAlMWIxkYCZuRVOSzSa5U8oEj IhpzfAPxoD49m46P1yR4OXj2HJmL9QyOu2Bd9ATAgEPROu/pJ7PdmqOr0/SMMVoPMyit bytX7R7mTV/sMrw++To+tTv3UGilALXF+XjdY+fAPa//H+R4gFt1S0bJdpC/t/mnL2y4 RlFg== X-Gm-Message-State: AHQUAuYFLgTmvMTatt5/KKnlPzVz06CF4CtELo1gl1KjcR4JPhA0PQWJ 74w+TeGjGqzqrxMTS5ViKMdiAeJhRPOs3oA4k94= X-Google-Smtp-Source: AHgI3IadMw+MhPV0thNkCyDgiSX0zMd4QiE71uPZe6Rz85+3G+/ojtFPo7KwhzwAS4N4cHjPCYgbO/Jjt063rUyyY6I= X-Received: by 2002:a05:660c:12c7:: with SMTP id k7mr519561itd.148.1550071769163; Wed, 13 Feb 2019 07:29:29 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Feb 2019 07:29:28 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 13 Feb 2019 07:29:28 -0800 Message-ID: Subject: Re: KEYS_READY To: Ian Swett , Kazuho Oku Cc: IETF QUIC WG , Martin Thomson , Marten Seemann Content-Type: multipart/alternative; boundary="0000000000002d6c9a0581c83583" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 15:29:33 -0000 --0000000000002d6c9a0581c83583 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can see arguments for having the frame defined as ACK-eliciting, It cannot not be ACK-eliciting, otherwise a lost packet could mean that no new key updates would be possible. On 13 February 2019 at 16.27.02, Kazuho Oku (kazuhooku@gmail.com) wrote: 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 0:03 Ian Swett : > > I'm happy with the approach you outline here and wrote up in the PR, but I did find the PR a bit confusing, partially because it's based on an existing PR that's gone through a lot of revisions. > > I don't think tying transmission of this to an encryption level will be overly complex, because since it's only a single byte, I might just put it in every ack-eliciting packet until it's no longer necessary and not use the standard retransmission logic. I tend to agree, because to me it the same as having a variable length packet header that, when being extended by one byte, indicates that the next key is ready. Though it seems a bit flexible. OTOH, I think it's interesting to discuss if the KEY_READY frame is ack-eliciting. My understanding is that per the current PR it is, because the list of non-ack-eliciting frames has not changed. I can see arguments for having the frame defined as ACK-eliciting, because it encourages endpoints to retire old keys soon. If we think that to be a good property, I think that might be an argument for using a frame (because calling a header bit ACK-eliciting would be strange). > > I'd rather not burn another bit in the first byte for this. > > On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann wrote: >> >> I went through a few key update scenarios under different packet loss patterns, and I have to admit that I found the KEY_READY frame surprisingly difficult to reason about. The problem seems to be that we're replacing what is in reality a contiguous state (it is permitted to update the keys) with a one-time signal, which has to be retransmitted (taking care to either block further key updates until this frame has been acknowledged, or canceling the retransmission when performing another key update). The reason we decided to create an explicit signal instead of consulting the loss recovery state, was that we wanted to avoid a tight coupling between the loss recovery and the key management. I have the impression that we're now just trading one tight coupling for a slightly different one. >> >> I agree with Kazuho that using a bit in the first byte seems to capture the update logic we're looking for better. There's no need to retransmit any information, since the bit is set on every subsequent packet. >> >> >> >> On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < mikkelfj@gmail.com> wrote: >>> >>> Thanks for pointing out the second alternative, although reluctantly. >>> >>> I think the first option with anonymous KEY_READY has a problem with idempotency as well as tying state to retransmission logic. This means that naive retransmission of packet content in a new packet number is no longer valid, and likewise, naive processing of a frame that passes authentication is also no longer possible. That is a strong principle break and I don=E2= =80=99t think the minor simplicity of a label-less KEY_READY frame can justify that (even if one ought no do such naive transmission). >>> >>> You could state that the KEY_PHASE bit is the lower bit the key counter which increments by one on each key update, starting at 0 or 1. >>> Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an old count is ignored. The key phase or the packet protection of the packet containing the KEY_READY frame is of no significance. >>> >>> I also suspect that the alternatively two-bit proposal might have a problem with idempotency, but I think it sorts itself by failing packet protection. >>> >>> The text mentions that the updated key depends on the current traffic key with reference to TLS 1.3. From reading this naively, it sounds like forward secrecy is lost, which I am sure it is not. >>> >>> Finally, this is just a high level view. I find the overall text hard to understand, notably because it is not crystal clear whether the two endpoints update their transmission keys in sync with the ready keys, or if the (currently implicity) key phase counters can count independently. >>> >>> That said, I like the idea of an explicit READY frame, and i probably would also like and explicit handshake ready frame, if it isn=E2=80=99t eff= ectively the same thing, and if it is, perhaps formalise that. >>> >>> Mikkel >>> >>> On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote: >>> >>> Hi, Martin >>> >>> Thank you for writing the PR. My comments inline. >>> >>> 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson : >>> > >>> > https://github.com/quicwg/base-drafts/pull/2237 has been updated to include the discussed new frame. >>> > >>> > This allows us to remove the implicit-ish acknowledgment of Initial packets, fix the problem Marten identified with discarding Handshake keys, and the problem Kazuho found with multiple and simultaneous key updates. >>> > >>> > There were two designs that were valid here, and I want to ensure that people think about the choice: >>> > >>> > The one I chose to write up uses a design like ACK. The keys used to protect the packet determine how the frame is interpreted. That is, KEYS_READY in a packet implies that the corresponding keys are in use. The cost here is that you have to purge any potential retransmissions of KEYS_READY when you update keys or you risk creating a false signal. >>> > >>> > The alternative involves more explicit signaling, and requires us to label each set of keys unambiguously. >>> >>> My weak preference goes to burning a bit in the first byte (we have >>> reserved bits in all the necessary packet types) due to the >>> exceptional retransmission rule that we would have for the frame, but >>> I'm not sure how much I care. >>> >>> > For that we could borrow the DTLS epoch convention, though that is inconveniently out of phase with the Key Phase we use; not a major issue, but a little hard to reason about. This doesn't have a retransmission problem, but in addition to the need to document the counting system, we would need to decide whether a mismatch between frame and packet is OK, or something that can produce a connection error. >>> > >>> > Obviously, I have a preference for the former, but if people feel differently, this is a good place to register your reasons. >>> > >>> > Editorial concerns should be directed toward the pull request. >>> > >>> >>> >>> -- >>> Kazuho Oku >>> --=20 Kazuho Oku --0000000000002d6c9a0581c83583 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I can see arguments for having the frame defined a= s ACK-eliciting,=C2=A0

It cannot not be A= CK-eliciting, otherwise a lost packet could mean that no new key updates wo= uld be possible.

<= br>

On 13 February 2019 at 16.27.02= , Kazuho Oku (kazuhooku@gmail.com) wrote:

=
2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 0:03 Ian Swett <= ;ianswett@google.com>:
>
> I'm happy with the approach you outline here and wrote up in t= he PR, but I did find the PR a bit confusing, partially because it's ba= sed on an existing PR that's gone through a lot of revisions.
>
> I don't think tying transmission of this to an encryption leve= l will be overly complex, because since it's only a single byte, I migh= t just put it in every ack-eliciting packet until it's no longer necess= ary and not use the standard retransmission logic.

I tend to agree, because to me it the same as having a variable length
packet header that, when being extended by one byte, indicates that
the next key is ready. Though it seems a bit flexible.

OTOH, I think it's interesting to discuss if the KEY_READY frame is
ack-eliciting. My understanding is that per the current PR it is,
because the list of non-ack-eliciting frames has not changed.

I can see arguments for having the frame defined as ACK-eliciting,
because it encourages endpoints to retire old keys soon. If we think
that to be a good property, I think that might be an argument for
using a frame (because calling a header bit ACK-eliciting would be
strange).

>
> I'd rather not burn another bit in the first byte for this.
>
> On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann <martenseemann@gmail.com> wrote:
>>
>> I went through a few key update scenarios under different pack= et loss patterns, and I have to admit that I found the KEY_READY frame surp= risingly difficult to reason about. The problem seems to be that we're = replacing what is in reality a contiguous state (it is permitted to update = the keys) with a one-time signal, which has to be retransmitted (taking car= e to either block further key updates until this frame has been acknowledge= d, or canceling the retransmission when performing another key update). The= reason we decided to create an explicit signal instead of consulting the l= oss recovery state, was that we wanted to avoid a tight coupling between th= e loss recovery and the key management. I have the impression that we'r= e now just trading one tight coupling for a slightly different one.
>>
>> I agree with Kazuho that using a bit in the first byte seems t= o capture the update logic we're looking for better. There's no nee= d to retransmit any information, since the bit is set on every subsequent p= acket.
>>
>>
>>
>> On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgen= sen <mikkelfj@gmail.com> wr= ote:
>>>
>>> Thanks for pointing out the second alternative, although r= eluctantly.
>>>
>>> I think the first option with anonymous KEY_READY has a pr= oblem with idempotency as well as tying state to retransmission logic. This= means that naive retransmission of packet content in a new packet number i= s no longer valid, and likewise, naive processing of a frame that passes au= thentication is also no longer possible. That is a strong principle break a= nd I don=E2=80=99t think the minor simplicity of a label-less KEY_READY fra= me can justify that (even if one ought no do such naive transmission).
>>>
>>> You could state that the KEY_PHASE bit is the lower bit th= e key counter which increments by one on each key update, starting at 0 or = 1.
>>> Then, a KEY_READY with a future count is a PROTOCOL_VIOLAT= ION and an old count is ignored. The key phase or the packet protection of = the packet containing the KEY_READY frame is of no significance.
>>>
>>> I also suspect that the alternatively two-bit proposal mig= ht have a problem with idempotency, but I think it sorts itself by failing = packet protection.
>>>
>>> The text mentions that the updated key depends on the curr= ent traffic key with reference to TLS 1.3. From reading this naively, it so= unds like forward secrecy is lost, which I am sure it is not.
>>>
>>> Finally, this is just a high level view. I find the overal= l text hard to understand, notably because it is not crystal clear whether = the two endpoints update their transmission keys in sync with the ready key= s, or if the (currently implicity) key phase counters can count independent= ly.
>>>
>>> That said, I like the idea of an explicit READY frame, and= i probably would also like and explicit handshake ready frame, if it isn= =E2=80=99t effectively the same thing, and if it is, perhaps formalise that= .
>>>
>>> Mikkel
>>>
>>> On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote:
>>>
>>> Hi, Martin
>>>
>>> Thank you for writing the PR. My comments inline.
>>>
>>> 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin= Thomson <mt@lowentropy.net>= :
>>> >
>>> > https://github.com/quicwg/base-drafts/pull/2237 has been updated= to include the discussed new frame.
>>> >
>>> > This allows us to remove the implicit-ish acknowledgm= ent of Initial packets, fix the problem Marten identified with discarding H= andshake keys, and the problem Kazuho found with multiple and simultaneous = key updates.
>>> >
>>> > There were two designs that were valid here, and I wa= nt to ensure that people think about the choice:
>>> >
>>> > The one I chose to write up uses a design like ACK. T= he keys used to protect the packet determine how the frame is interpreted. = That is, KEYS_READY in a packet implies that the corresponding keys are in = use. The cost here is that you have to purge any potential retransmissions = of KEYS_READY when you update keys or you risk creating a false signal.
>>> >
>>> > The alternative involves more explicit signaling, and= requires us to label each set of keys unambiguously.
>>>
>>> My weak preference goes to burning a bit in the first byte= (we have
>>> reserved bits in all the necessary packet types) due to th= e
>>> exceptional retransmission rule that we would have for the= frame, but
>>> I'm not sure how much I care.
>>>
>>> > For that we could borrow the DTLS epoch convention, t= hough that is inconveniently out of phase with the Key Phase we use; not a = major issue, but a little hard to reason about. This doesn't have a ret= ransmission problem, but in addition to the need to document the counting s= ystem, we would need to decide whether a mismatch between frame and packet = is OK, or something that can produce a connection error.
>>> >
>>> > Obviously, I have a preference for the former, but if= people feel differently, this is a good place to register your reasons.
>>> >
>>> > Editorial concerns should be directed toward the pull= request.
>>> >
>>>
>>>
>>> --
>>> Kazuho Oku
>>>


-- =20
Kazuho Oku
--0000000000002d6c9a0581c83583-- From nobody Wed Feb 13 07:49:01 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A9412D826 for ; Wed, 13 Feb 2019 07:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWwaqGuAgzyK for ; Wed, 13 Feb 2019 07:48:57 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 41E1C1274D0 for ; Wed, 13 Feb 2019 07:48:57 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id j18so1329533pfe.1 for ; Wed, 13 Feb 2019 07:48:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NKXyaTwMq/3mJPcHUgo4az0xnVFEyoeJfBA2G55QJq0=; b=K2J3ySVr6zlmsuoceVdFzz9m9p/TWo8X9KX3YDnwn6vjpcVGwYD2xfB9gj6+tAQS8/ Mhtinan8GonwcQEMx2Snv2XihFfsVUdsfd1se07c8u76g2SMNJ1WYgsOKRzfbnDBBoHM 8JzVp+a+T5024YNnasdRGJY11r+CU0/+uc6+rB37MzFE1Hs1fWmqBBz8SWZpwokzBnwp SC+hObmeSuErDnBgQeVIwnA9Vif/OQtfZ3Am4tUy4u3uanoD6dkV6raLrwkYLXxNlM3Y ic4IrKUoI0j0M2bJX03z/64Ow0rLiOnsSzm6SJu9DhB5XjHsd1LsKk7Ebjev1RICB2eE cReQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NKXyaTwMq/3mJPcHUgo4az0xnVFEyoeJfBA2G55QJq0=; b=ahFqFVeHZhQFygayUmh7/bAJDB5aT8auc0O+X9PAzjFV/OWECBu8v285eRVeZQvAIA PVydf+FyMXgYZ6ssJHwhFvoPLqBxDjnitql4ZVSmHr6HRN3XjCYLPRH30Ze3oJvwNbv1 7y7vX3aqcVKTd5KLE0/KakH1jiog+RdKrwLPz8KIuzuV/+Kayip9E+C8ubqe3H9M6pin Yuit4QHR9E/9l4qB4CzFxpzc8Hw8O/JBJIcxygeWOLdlbKoUpeY1/s18I3IcL7h7BHhy Pq2VhUXUEVmbj6WAfvRMh/eQ7sVuAhyQ9cn5c+Sc7qAFJGgUQYBgq4+MLE7bGYw29Uhl gzww== X-Gm-Message-State: AHQUAubbLdsjw3EFrgcYJngFzcSG2wehXZ73WDBHznXbYyGVgxTfTGFW Vgraia41L3zIKnbY/uXPgNE= X-Google-Smtp-Source: AHgI3Ibkry70vJvjs63H6Cj+Gfy7CMmzKDLBHCqbO9mxuWiPtXl0CRI5G5JK8YSrRBYjPTxlI7mU1A== X-Received: by 2002:a63:df09:: with SMTP id u9mr994389pgg.299.1550072936634; Wed, 13 Feb 2019 07:48:56 -0800 (PST) Received: from ?IPv6:2400:4050:31c0:f200:f5a9:4485:183d:f3f9? ([2400:4050:31c0:f200:f5a9:4485:183d:f3f9]) by smtp.gmail.com with ESMTPSA id n10sm28906715pfj.14.2019.02.13.07.48.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 07:48:55 -0800 (PST) From: Kazuho Oku X-Google-Original-From: Kazuho Oku Content-Type: multipart/alternative; boundary=Apple-Mail-4D1C11AE-FBA9-4B11-9670-E5B2087106D6 Mime-Version: 1.0 (1.0) Subject: Re: KEYS_READY X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Thu, 14 Feb 2019 00:48:51 +0900 Cc: Ian Swett , IETF QUIC WG , Martin Thomson , Marten Seemann Content-Transfer-Encoding: 7bit Message-Id: <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 15:49:00 -0000 --Apple-Mail-4D1C11AE-FBA9-4B11-9670-E5B2087106D6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 2019/02/14 0:29=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >> I can see arguments for having the frame defined as ACK-eliciting,=20 >=20 >=20 > It cannot not be ACK-eliciting, otherwise a lost packet could mean that no= new key updates would be possible. IIUC key updates are rare, and therefore the frame can be non-ack-eliciting.= FWIW, the current design does not elicit an ACK in response to key update. >=20 >=20 >=20 >> On 13 February 2019 at 16.27.02, Kazuho Oku (kazuhooku@gmail.com) wrote: >>=20 >> 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 0:03 Ian Swett :=20 >> >=20 >> > I'm happy with the approach you outline here and wrote up in the PR, bu= t I did find the PR a bit confusing, partially because it's based on an exis= ting PR that's gone through a lot of revisions.=20 >> >=20 >> > I don't think tying transmission of this to an encryption level will be= overly complex, because since it's only a single byte, I might just put it i= n every ack-eliciting packet until it's no longer necessary and not use the s= tandard retransmission logic.=20 >>=20 >> I tend to agree, because to me it the same as having a variable length=20= >> packet header that, when being extended by one byte, indicates that=20 >> the next key is ready. Though it seems a bit flexible.=20 >>=20 >> OTOH, I think it's interesting to discuss if the KEY_READY frame is=20 >> ack-eliciting. My understanding is that per the current PR it is,=20 >> because the list of non-ack-eliciting frames has not changed.=20 >>=20 >> I can see arguments for having the frame defined as ACK-eliciting,=20 >> because it encourages endpoints to retire old keys soon. If we think=20 >> that to be a good property, I think that might be an argument for=20 >> using a frame (because calling a header bit ACK-eliciting would be=20 >> strange).=20 >>=20 >> >=20 >> > I'd rather not burn another bit in the first byte for this.=20 >> >=20 >> > On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann wrote:=20 >> >>=20 >> >> I went through a few key update scenarios under different packet loss p= atterns, and I have to admit that I found the KEY_READY frame surprisingly d= ifficult to reason about. The problem seems to be that we're replacing what i= s in reality a contiguous state (it is permitted to update the keys) with a o= ne-time signal, which has to be retransmitted (taking care to either block f= urther key updates until this frame has been acknowledged, or canceling the r= etransmission when performing another key update). The reason we decided to c= reate an explicit signal instead of consulting the loss recovery state, was t= hat we wanted to avoid a tight coupling between the loss recovery and the ke= y management. I have the impression that we're now just trading one tight co= upling for a slightly different one.=20 >> >>=20 >> >> I agree with Kazuho that using a bit in the first byte seems to captur= e the update logic we're looking for better. There's no need to retransmit a= ny information, since the bit is set on every subsequent packet.=20 >> >>=20 >> >>=20 >> >>=20 >> >> On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:=20 >> >>>=20 >> >>> Thanks for pointing out the second alternative, although reluctantly.= =20 >> >>>=20 >> >>> I think the first option with anonymous KEY_READY has a problem with i= dempotency as well as tying state to retransmission logic. This means that n= aive retransmission of packet content in a new packet number is no longer va= lid, and likewise, naive processing of a frame that passes authentication is= also no longer possible. That is a strong principle break and I don=E2=80=99= t think the minor simplicity of a label-less KEY_READY frame can justify tha= t (even if one ought no do such naive transmission).=20 >> >>>=20 >> >>> You could state that the KEY_PHASE bit is the lower bit the key count= er which increments by one on each key update, starting at 0 or 1.=20 >> >>> Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an o= ld count is ignored. The key phase or the packet protection of the packet co= ntaining the KEY_READY frame is of no significance.=20 >> >>>=20 >> >>> I also suspect that the alternatively two-bit proposal might have a p= roblem with idempotency, but I think it sorts itself by failing packet prote= ction.=20 >> >>>=20 >> >>> The text mentions that the updated key depends on the current traffic= key with reference to TLS 1.3. =46rom reading this naively, it sounds like f= orward secrecy is lost, which I am sure it is not.=20 >> >>>=20 >> >>> Finally, this is just a high level view. I find the overall text hard= to understand, notably because it is not crystal clear whether the two endp= oints update their transmission keys in sync with the ready keys, or if the (= currently implicity) key phase counters can count independently.=20 >> >>>=20 >> >>> That said, I like the idea of an explicit READY frame, and i probably= would also like and explicit handshake ready frame, if it isn=E2=80=99t eff= ectively the same thing, and if it is, perhaps formalise that.=20 >> >>>=20 >> >>> Mikkel=20 >> >>>=20 >> >>> On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wro= te:=20 >> >>>=20 >> >>> Hi, Martin=20 >> >>>=20 >> >>> Thank you for writing the PR. My comments inline.=20 >> >>>=20 >> >>> 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson :=20 >> >>> >=20 >> >>> > https://github.com/quicwg/base-drafts/pull/2237 has been updated to= include the discussed new frame.=20 >> >>> >=20 >> >>> > This allows us to remove the implicit-ish acknowledgment of Initial= packets, fix the problem Marten identified with discarding Handshake keys, a= nd the problem Kazuho found with multiple and simultaneous key updates.=20 >> >>> >=20 >> >>> > There were two designs that were valid here, and I want to ensure t= hat people think about the choice:=20 >> >>> >=20 >> >>> > The one I chose to write up uses a design like ACK. The keys used t= o protect the packet determine how the frame is interpreted. That is, KEYS_R= EADY in a packet implies that the corresponding keys are in use. The cost he= re is that you have to purge any potential retransmissions of KEYS_READY whe= n you update keys or you risk creating a false signal.=20 >> >>> >=20 >> >>> > The alternative involves more explicit signaling, and requires us t= o label each set of keys unambiguously.=20 >> >>>=20 >> >>> My weak preference goes to burning a bit in the first byte (we have=20= >> >>> reserved bits in all the necessary packet types) due to the=20 >> >>> exceptional retransmission rule that we would have for the frame, but= =20 >> >>> I'm not sure how much I care.=20 >> >>>=20 >> >>> > For that we could borrow the DTLS epoch convention, though that is i= nconveniently out of phase with the Key Phase we use; not a major issue, but= a little hard to reason about. This doesn't have a retransmission problem, b= ut in addition to the need to document the counting system, we would need to= decide whether a mismatch between frame and packet is OK, or something that= can produce a connection error.=20 >> >>> >=20 >> >>> > Obviously, I have a preference for the former, but if people feel d= ifferently, this is a good place to register your reasons.=20 >> >>> >=20 >> >>> > Editorial concerns should be directed toward the pull request.=20 >> >>> >=20 >> >>>=20 >> >>>=20 >> >>> --=20 >> >>> Kazuho Oku=20 >> >>>=20 >>=20 >>=20 >> --=20 >> Kazuho Oku=20 --Apple-Mail-4D1C11AE-FBA9-4B11-9670-E5B2087106D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 2019/02/14 0:29=E3=80=81Mikkel Fahn=C3=B8e J= =C3=B8rgensen <mikkelfj@gmail.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

I can see arguments for= having the frame defined as ACK-eliciting, 
It cannot not be ACK-eliciting, otherwise a lost packet could mean t= hat no new key updates would be possible.

I= IUC key updates are rare, and therefore the frame can be non-ack-eliciting. = FWIW, the current design does not elicit an ACK in response to key update.




On 13 February 2019 at 16.27.02, Kazuho Oku (kazuhooku@gmail.com) wrote:

2019=E5=B9=B42=E6=9C= =8814=E6=97=A5(=E6=9C=A8) 0:03 Ian Swett <ianswett@google.com>:
>
> I'm happy with the approach you outline here and wrote up in the PR= , but I did find the PR a bit confusing, partially because it's based on an e= xisting PR that's gone through a lot of revisions.
>
> I don't think tying transmission of this to an encryption level wil= l be overly complex, because since it's only a single byte, I might just put= it in every ack-eliciting packet until it's no longer necessary and not use= the standard retransmission logic.

I tend to agree, because to me it the same as having a variable length
packet header that, when being extended by one byte, indicates that
the next key is ready. Though it seems a bit flexible.

OTOH, I think it's interesting to discuss if the KEY_READY frame is
ack-eliciting. My understanding is that per the current PR it is,
because the list of non-ack-eliciting frames has not changed.

I can see arguments for having the frame defined as ACK-eliciting,
because it encourages endpoints to retire old keys soon. If we think
that to be a good property, I think that might be an argument for
using a frame (because calling a header bit ACK-eliciting would be
strange).

>
> I'd rather not burn another bit in the first byte for this.
>
> On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann <martenseemann@gmail.com> wrote:
>>
>> I went through a few key update scenarios under different packe= t loss patterns, and I have to admit that I found the KEY_READY frame surpri= singly difficult to reason about. The problem seems to be that we're replaci= ng what is in reality a contiguous state (it is permitted to update the keys= ) with a one-time signal, which has to be retransmitted (taking care to eith= er block further key updates until this frame has been acknowledged, or canc= eling the retransmission when performing another key update). The reason we d= ecided to create an explicit signal instead of consulting the loss recovery s= tate, was that we wanted to avoid a tight coupling between the loss recovery= and the key management. I have the impression that we're now just trading o= ne tight coupling for a slightly different one.
>>
>> I agree with Kazuho that using a bit in the first byte seems to= capture the update logic we're looking for better. There's no need to retra= nsmit any information, since the bit is set on every subsequent packet.
>>
>>
>>
>> On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgens= en <mikkelfj@gmail.com> wrot= e:
>>>
>>> Thanks for pointing out the second alternative, although re= luctantly.
>>>
>>> I think the first option with anonymous KEY_READY has a pro= blem with idempotency as well as tying state to retransmission logic. This m= eans that naive retransmission of packet content in a new packet number is n= o longer valid, and likewise, naive processing of a frame that passes authen= tication is also no longer possible. That is a strong principle break and I d= on=E2=80=99t think the minor simplicity of a label-less KEY_READY frame can j= ustify that (even if one ought no do such naive transmission).
>>>
>>> You could state that the KEY_PHASE bit is the lower bit the= key counter which increments by one on each key update, starting at 0 or 1.=
>>> Then, a KEY_READY with a future count is a PROTOCOL_VIOLATI= ON and an old count is ignored. The key phase or the packet protection of th= e packet containing the KEY_READY frame is of no significance.
>>>
>>> I also suspect that the alternatively two-bit proposal migh= t have a problem with idempotency, but I think it sorts itself by failing pa= cket protection.
>>>
>>> The text mentions that the updated key depends on the curre= nt traffic key with reference to TLS 1.3. =46rom reading this naively, it so= unds like forward secrecy is lost, which I am sure it is not.
>>>
>>> Finally, this is just a high level view. I find the overall= text hard to understand, notably because it is not crystal clear whether th= e two endpoints update their transmission keys in sync with the ready keys, o= r if the (currently implicity) key phase counters can count independently.
>>>
>>> That said, I like the idea of an explicit READY frame, and i= probably would also like and explicit handshake ready frame, if it isn=E2=80= =99t effectively the same thing, and if it is, perhaps formalise that.
>>>
>>> Mikkel
>>>
>>> On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote:
>>>
>>> Hi, Martin
>>>
>>> Thank you for writing the PR. My comments inline.
>>>
>>> 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin T= homson <mt@lowentropy.net>:
>>> >
>>> > https://github.com/quicwg/base-drafts/pull/2237 has been updated t= o include the discussed new frame.
>>> >
>>> > This allows us to remove the implicit-ish acknowledgme= nt of Initial packets, fix the problem Marten identified with discarding Han= dshake keys, and the problem Kazuho found with multiple and simultaneous key= updates.
>>> >
>>> > There were two designs that were valid here, and I wan= t to ensure that people think about the choice:
>>> >
>>> > The one I chose to write up uses a design like ACK. Th= e keys used to protect the packet determine how the frame is interpreted. Th= at is, KEYS_READY in a packet implies that the corresponding keys are in use= . The cost here is that you have to purge any potential retransmissions of K= EYS_READY when you update keys or you risk creating a false signal.
>>> >
>>> > The alternative involves more explicit signaling, and r= equires us to label each set of keys unambiguously.
>>>
>>> My weak preference goes to burning a bit in the first byte (= we have
>>> reserved bits in all the necessary packet types) due to the=
>>> exceptional retransmission rule that we would have for the f= rame, but
>>> I'm not sure how much I care.
>>>
>>> > For that we could borrow the DTLS epoch convention, th= ough that is inconveniently out of phase with the Key Phase we use; not a ma= jor issue, but a little hard to reason about. This doesn't have a retransmis= sion problem, but in addition to the need to document the counting system, w= e would need to decide whether a mismatch between frame and packet is OK, or= something that can produce a connection error.
>>> >
>>> > Obviously, I have a preference for the former, but if p= eople feel differently, this is a good place to register your reasons.
>>> >
>>> > Editorial concerns should be directed toward the pull r= equest.
>>> >
>>>
>>>
>>> --
>>> Kazuho Oku
>>>


-- =20
Kazuho Oku
= --Apple-Mail-4D1C11AE-FBA9-4B11-9670-E5B2087106D6-- From nobody Wed Feb 13 07:55:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECD212D826 for ; Wed, 13 Feb 2019 07:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 t53FzDHli-kV for ; Wed, 13 Feb 2019 07:55:34 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 19D631286D8 for ; Wed, 13 Feb 2019 07:55:34 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id i5so4746516oto.9 for ; Wed, 13 Feb 2019 07:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=K+704Vxhe0gWKb66JFeP05xxoN+2VTLpraaRDHLhp38=; b=MFRqkFIxOy8K+IrTjb+mudeUozMs5EBFIHrmIv1OeEuBArIQGNUBNF8PMOyjEAELLE y5EM1JqH9K1+3hEvK0rlA0qcubG8JU9McA/vDY1yjy5NqFc+qyrtMx+hDhUbMFJC9xKv S3SQp63Ez1fYaOpSdgNjAeW1txIxMyNMqZeb1Zifdcma+H49bVADBX4wb7Yiit+dqhvl B9cRCVeaGC4VDzMVsYBxMQXONPHayxd3a+afRlct82VBNo0dpJSTTUO5lgN1rapcwWzq ZIjuMDf1fVGZjrNnnw39+JaI4W23SJScndkOu1D39Eg0GXWLYl7s2iDzjtuOeXrIz3og 4lTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=K+704Vxhe0gWKb66JFeP05xxoN+2VTLpraaRDHLhp38=; b=KnCMMtqQhzJk2rZlanw5kc9suNMf4YuG1pe/616ZrtLf4C1hNwLCHlqHTdyl8JxLzT L15KbEYgf6wlVrOk/cXt0gY2kIOCs1l+r1Yy7+A+hnSeCJEEWs7gSuklZ+IBCV7Dj1NG Xv8T/hYbzzqrp/vJBdUfnVcd23qjXFo2x48jLn5W7JUW3Gj0OHhmD2lKRjSj6p8QdfdX 24V6XLZc/VvWVNzIDWKU0lGa8lh8jbJj0gU65uvbYzNkXxi24x+iFHWHMh0dtiXtkfEn NUUU1xvEEVWG0mNhis+H1jjUcFko/fE1YWfy24aK5MH5m/7H6YEng39Pr/+xNpoVCAGt aR3A== X-Gm-Message-State: AHQUAuahwiaOOpKWpI0wSF/EjXoDTVK9RDwcBGCLWoBKHEEn084ouZbl hBQ9Td9tz4s5B/Uqwl4lNIXBqhGdWgcKymlMx4I= X-Google-Smtp-Source: AHgI3Ibr8YOiTL437sO2sFFP8FQOlS2u233y2VMVtRc3IKJONfSpYX1SfCoinl1fPak9Rrbl/NJn/zv6ZQQ+Paaj25g= X-Received: by 2002:a02:2303:: with SMTP id u3mr734078jau.42.1550073333214; Wed, 13 Feb 2019 07:55:33 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Feb 2019 07:55:32 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 13 Feb 2019 07:55:32 -0800 Message-ID: Subject: Re: KEYS_READY To: Kazuho Oku Cc: Martin Thomson , IETF QUIC WG , Ian Swett , Marten Seemann Content-Type: multipart/alternative; boundary="00000000000066f7350581c8927c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 15:55:37 -0000 --00000000000066f7350581c8927c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The point is that under the rules set by the PR, it is not possible to update keys before a KEYS_ACTIVE / KEYS_READY frame has been received. If such a frame is sent, but lost, there is not path to update keys again. This goes wrong after a (long) while, when the current key is exchausted. It does not matter that updates are rare. On 13 February 2019 at 16.48.57, Kazuho Oku (kazuhooku@gmail.com) wrote: 2019/02/14 0:29=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: I can see arguments for having the frame defined as ACK-eliciting, It cannot not be ACK-eliciting, otherwise a lost packet could mean that no new key updates would be possible. IIUC key updates are rare, and therefore the frame can be non-ack-eliciting. FWIW, the current design does not elicit an ACK in response to key update. On 13 February 2019 at 16.27.02, Kazuho Oku (kazuhooku@gmail.com) wrote: 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 0:03 Ian Swett : > > I'm happy with the approach you outline here and wrote up in the PR, but I did find the PR a bit confusing, partially because it's based on an existing PR that's gone through a lot of revisions. > > I don't think tying transmission of this to an encryption level will be overly complex, because since it's only a single byte, I might just put it in every ack-eliciting packet until it's no longer necessary and not use the standard retransmission logic. I tend to agree, because to me it the same as having a variable length packet header that, when being extended by one byte, indicates that the next key is ready. Though it seems a bit flexible. OTOH, I think it's interesting to discuss if the KEY_READY frame is ack-eliciting. My understanding is that per the current PR it is, because the list of non-ack-eliciting frames has not changed. I can see arguments for having the frame defined as ACK-eliciting, because it encourages endpoints to retire old keys soon. If we think that to be a good property, I think that might be an argument for using a frame (because calling a header bit ACK-eliciting would be strange). > > I'd rather not burn another bit in the first byte for this. > > On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann wrote: >> >> I went through a few key update scenarios under different packet loss patterns, and I have to admit that I found the KEY_READY frame surprisingly difficult to reason about. The problem seems to be that we're replacing what is in reality a contiguous state (it is permitted to update the keys) with a one-time signal, which has to be retransmitted (taking care to either block further key updates until this frame has been acknowledged, or canceling the retransmission when performing another key update). The reason we decided to create an explicit signal instead of consulting the loss recovery state, was that we wanted to avoid a tight coupling between the loss recovery and the key management. I have the impression that we're now just trading one tight coupling for a slightly different one. >> >> I agree with Kazuho that using a bit in the first byte seems to capture the update logic we're looking for better. There's no need to retransmit any information, since the bit is set on every subsequent packet. >> >> >> >> On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < mikkelfj@gmail.com> wrote: >>> >>> Thanks for pointing out the second alternative, although reluctantly. >>> >>> I think the first option with anonymous KEY_READY has a problem with idempotency as well as tying state to retransmission logic. This means that naive retransmission of packet content in a new packet number is no longer valid, and likewise, naive processing of a frame that passes authentication is also no longer possible. That is a strong principle break and I don=E2= =80=99t think the minor simplicity of a label-less KEY_READY frame can justify that (even if one ought no do such naive transmission). >>> >>> You could state that the KEY_PHASE bit is the lower bit the key counter which increments by one on each key update, starting at 0 or 1. >>> Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an old count is ignored. The key phase or the packet protection of the packet containing the KEY_READY frame is of no significance. >>> >>> I also suspect that the alternatively two-bit proposal might have a problem with idempotency, but I think it sorts itself by failing packet protection. >>> >>> The text mentions that the updated key depends on the current traffic key with reference to TLS 1.3. From reading this naively, it sounds like forward secrecy is lost, which I am sure it is not. >>> >>> Finally, this is just a high level view. I find the overall text hard to understand, notably because it is not crystal clear whether the two endpoints update their transmission keys in sync with the ready keys, or if the (currently implicity) key phase counters can count independently. >>> >>> That said, I like the idea of an explicit READY frame, and i probably would also like and explicit handshake ready frame, if it isn=E2=80=99t eff= ectively the same thing, and if it is, perhaps formalise that. >>> >>> Mikkel >>> >>> On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote= : >>> >>> Hi, Martin >>> >>> Thank you for writing the PR. My comments inline. >>> >>> 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson : >>> > >>> > https://github.com/quicwg/base-drafts/pull/2237 has been updated to include the discussed new frame. >>> > >>> > This allows us to remove the implicit-ish acknowledgment of Initial packets, fix the problem Marten identified with discarding Handshake keys, and the problem Kazuho found with multiple and simultaneous key updates. >>> > >>> > There were two designs that were valid here, and I want to ensure that people think about the choice: >>> > >>> > The one I chose to write up uses a design like ACK. The keys used to protect the packet determine how the frame is interpreted. That is, KEYS_READY in a packet implies that the corresponding keys are in use. The cost here is that you have to purge any potential retransmissions of KEYS_READY when you update keys or you risk creating a false signal. >>> > >>> > The alternative involves more explicit signaling, and requires us to label each set of keys unambiguously. >>> >>> My weak preference goes to burning a bit in the first byte (we have >>> reserved bits in all the necessary packet types) due to the >>> exceptional retransmission rule that we would have for the frame, but >>> I'm not sure how much I care. >>> >>> > For that we could borrow the DTLS epoch convention, though that is inconveniently out of phase with the Key Phase we use; not a major issue, but a little hard to reason about. This doesn't have a retransmission problem, but in addition to the need to document the counting system, we would need to decide whether a mismatch between frame and packet is OK, or something that can produce a connection error. >>> > >>> > Obviously, I have a preference for the former, but if people feel differently, this is a good place to register your reasons. >>> > >>> > Editorial concerns should be directed toward the pull request. >>> > >>> >>> >>> -- >>> Kazuho Oku >>> -- Kazuho Oku --00000000000066f7350581c8927c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = The point is that un= der the rules set by the PR, it is not possible to update keys before a KEY= S_ACTIVE / KEYS_READY frame has been received. If such a frame is sent, but= lost, there is not path to update keys again. This goes wrong after a (lon= g) while, when the current key is exchausted.
It does not matter that updates are rare.= =C2=A0


On 13 February 2019 at 16.48.57, Kazuho Oku (= kazuhooku@gmail.com) wrote:

=
<= /div>
2019/02/14 0:29=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>=E3=81=AE=E3=83=A1=E3=83= =BC=E3=83=AB:

I can see arguments for having the frame defined as ACK-eliciting,=C2=A0

It cannot not be ACK-eliciting, otherwise a lost packet could mean that no new key updates would be possible.

IIUC key updates are rare, and therefore the frame can be non-ack-eliciting. FWIW, the current design does not elicit an ACK in response to key update.





On 13 February 2019 at 16.27.02, Kazuho Oku (kazuhooku@gmail.com) wrote:

2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 0:03 Ian Swett <= ;ianswett@google.com>:
>
> I'm happy with the approach you outline here and wrote up in the PR, but I did find the PR a bit confusing, partially because it's based on an existing PR that's gone through a lot of revisions.
>
> I don't think tying transmission of this to an encryption level will be overly complex, because since it's only a single byte, I might just put it in every ack-eliciting packet until it's no longer necessary and not use the standard retransmission logic.

I tend to agree, because to me it the same as having a variable length
packet header that, when being extended by one byte, indicates that
the next key is ready. Though it seems a bit flexible.

OTOH, I think it's interesting to discuss if the KEY_READY frame is
ack-eliciting. My understanding is that per the current PR it is,
because the list of non-ack-eliciting frames has not changed.

I can see arguments for having the frame defined as ACK-eliciting,
because it encourages endpoints to retire old keys soon. If we think
that to be a good property, I think that might be an argument for
using a frame (because calling a header bit ACK-eliciting would be
strange).

>
> I'd rather not burn another bit in the first byte for this.
>
> On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann <martenseemann@gmail.com> wrote:
>>
>> I went through a few key update scenarios under different packet loss patterns, and I have to admit that I found the KEY_READY frame surprisingly difficult to reason about. The problem seems to be that we're replacing what is in reality a contiguous state (it is permitted to update the keys) with a one-time signal, which has to be retransmitted (taking care to either block further key updates until this frame has been acknowledged, or canceling the retransmission when performing another key update). The reason we decided to create an explicit signal instead of consulting the loss recovery state, was that we wanted to avoid a tight coupling between the loss recovery and the key management. I have the impression that we're now just trading one tight coupling for a slightly different one.
>>
>> I agree with Kazuho that using a bit in the first byte seems to capture the update logic we're looking for better. There's no need to retransmit any information, since the bit is set on every subsequent packet.
>>
>>
>>
>> On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
>>>
>>> Thanks for pointing out the second alternative, although reluctantly.
>>>
>>> I think the first option with anonymous KEY_READY has a problem with idempotency as well as tying state to retransmission logic. This means that naive retransmission of packet content in a new packet number is no longer valid, and likewise, naive processing of a frame that passes authentication is also no longer possible. That is a strong principle break and I don=E2=80=99t think the minor simplicity of a label-less KEY_READY frame can justify that (even if one ought no do such naive transmission).
>>>
>>> You could state that the KEY_PHASE bit is the lower bit the key counter which increments by one on each key update, starting at 0 or 1.
>>> Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an old count is ignored. The key phase or the packet protection of the packet containing the KEY_READY frame is of no significance.
>>>
>>> I also suspect that the alternatively two-bit proposal might have a problem with idempotency, but I think it sorts itself by failing packet protection.
>>>
>>> The text mentions that the updated key depends on the current traffic key with reference to TLS 1.3. From reading this naively, it sounds like forward secrecy is lost, which I am sure it is not.
>>>
>>> Finally, this is just a high level view. I find the overall text hard to understand, notably because it is not crystal clear whether the two endpoints update their transmission keys in sync with the ready keys, or if the (currently implicity) key phase counters can count independently.
>>>
>>> That said, I like the idea of an explicit READY frame, and i probably would also like and explicit handshake ready frame, if it isn=E2=80=99t effectively the same thing, and if it is, perhaps formalise that.
>>>
>>> Mikkel
>>>
>>> On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wrote:
>>>
>>> Hi, Martin
>>>
>>> Thank you for writing the PR. My comments inline.
>>>
>>> 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Tho= mson <mt@lowentropy.net>: >>> >
>>> > https://github.com/quicwg/base-drafts/pull/2237 has been updated to include the discussed new frame.
>>> >
>>> > This allows us to remove the implicit-ish acknowledgment of Initial packets, fix the problem Marten identified with discarding Handshake keys, and the problem Kazuho found with multiple and simultaneous key updates.
>>> >
>>> > There were two designs that were valid here, and I want to ensure that people think about the choice:
>>> >
>>> > The one I chose to write up uses a design like ACK. The keys used to protect the packet determine how the frame is interpreted. That is, KEYS_READY in a packet implies that the corresponding keys are in use. The cost here is that you have to purge any potential retransmissions of KEYS_READY when you update keys or you risk creating a false signal.
>>> >
>>> > The alternative involves more explicit signaling, and requires us to label each set of keys unambiguously.
>>>
>>> My weak preference goes to burning a bit in the first byte (we have
>>> reserved bits in all the necessary packet types) due to the
>>> exceptional retransmission rule that we would have for the frame, but
>>> I'm not sure how much I care.
>>>
>>> > For that we could borrow the DTLS epoch convention, though that is inconveniently out of phase with the Key Phase we use; not a major issue, but a little hard to reason about. This doesn't have a retransmission problem, but in addition to the need to document the counting system, we would need to decide whether a mismatch between frame and packet is OK, or something that can produce a connection error.
>>> >
>>> > Obviously, I have a preference for the former, but if people feel differently, this is a good place to register your reasons.
>>> >
>>> > Editorial concerns should be directed toward the pull request.
>>> >
>>>
>>>
>>> --
>>> Kazuho Oku
>>>


--
Kazuho Oku
--00000000000066f7350581c8927c-- From nobody Wed Feb 13 08:13:11 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340D0129441 for ; Wed, 13 Feb 2019 08:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcvTvcywhkrh for ; Wed, 13 Feb 2019 08:13:06 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 C4A3612426A for ; Wed, 13 Feb 2019 08:13:05 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id h22so2235993wmb.0 for ; Wed, 13 Feb 2019 08:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A7V1gwGFfY4pZgqXQ8YRE0mC5L8PXRylp6v0R9wpAbY=; b=Oh1KWDIoC4f+41I3N/p3YHujrlvpEfllhsEU/cof9n6MZfdj7aLXEMuE95c3PXlT7O fLPxYK9tsxYVh+yARZvXlR3e8TCFpH3XfBZTq3mw7Skg4HXYmTZJpkKEKfq1LSupEtTB vL3DT6q+OU0OYLn5teTThZiS5hPSqKaUXyyEXVEhNWTNye/m28mcxVBQ5UPLiXdP0dSP aaWuvUhbZ6+Ncm2vnA4Ce/qN/cImSofn1Ke/9SEEMpi6LJOlscSSXrv1vAfS4Q1AJJ61 TG+5KR8yYEj8O5plhu27eVlOW07zI5aH0PTk/w18yOsvP9FsznzvEuqJbCi8a2SZu0lo jiAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A7V1gwGFfY4pZgqXQ8YRE0mC5L8PXRylp6v0R9wpAbY=; b=IWgCF2/B8J3mSSCn4WVwKIsWwm9kez3ABvxSa7p749zUqr3x8+VBeoeonD2Bs5eAbm v+b2MkQ+Hds3fkLlQu2XGCmhHLdJmN3epNJQi3WtMYWLF1URFSl/we886pJE21Jx2C42 oWfL/BcQmvb4ytQwHKwuFzhlgyTcJtt6p82FWUod+WcYvh5jOUPkcfxOi+yC7YKPj7bc 338gJ4blH2kokBGsjgE12qp9VnRObYtCx0p9M0Re4HLSMGuU0e3y38l8FAP6ahlGPWpq /h4NU2KcdvxNFf+0GHAxFPs/ldhdteQlGczVzz0c9s3CovFjfEzRgpzUGvBVRsn4jkUl XIbw== X-Gm-Message-State: AHQUAuYRWOkqd/8XAQp6nooqCdchPxv7VOH9R94G84P16FucUl7WCFxn HtdNMAIVWYu0gI+bupl2OJ0blalP8X968SrvJ5M= X-Google-Smtp-Source: AHgI3IYMQB8CXWXNYKExl92zYs4a8SSJDTh0tK59DRQZNo12ZVejBCpekdhSwKr5MiDgGi6VPecKk7FjMESpBfAykqg= X-Received: by 2002:a1c:1dd2:: with SMTP id d201mr867476wmd.49.1550074384128; Wed, 13 Feb 2019 08:13:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Wed, 13 Feb 2019 08:12:51 -0800 Message-ID: Subject: Re: Eight CIDs? To: Ian Swett Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000000aa1c80581c8d1c0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 16:13:09 -0000 --0000000000000aa1c80581c8d1c0 Content-Type: text/plain; charset="UTF-8" Thanks, I'll comment there. On Tue, Feb 12, 2019 at 3:17 PM Ian Swett wrote: > I'm not aware of an on-list discussion, but PR#1998 > will remove that > recommendation and replace it with a transport parameter once it lands. > > I agree that 8 seems extremely high. > > On Tue, Feb 12, 2019 at 4:54 PM Martin Duke > wrote: > >> Can someone point me to the discussion where we decided that we needed 8 >> CIDs? That seems really high to me. >> > --0000000000000aa1c80581c8d1c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, I'll comment there.

On Tue, Feb 12, 2019 at= 3:17 PM Ian Swett <ianswett@goog= le.com> wrote:
I'm not aware of an on-list discussion, but P= R#1998 will remove that recommendation and replace it with a transport = parameter once it lands.

I agree that 8 seems extremely = high.

On Tue, Feb 12, 2019 at 4:54 PM Martin Duke <martin.h.duke@gmail.com>= ; wrote:
Can someone point me to the discussion where we decided that we n= eeded 8 CIDs? That seems really high to me.
--0000000000000aa1c80581c8d1c0-- From nobody Wed Feb 13 08:17:27 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F137128D0B for ; Wed, 13 Feb 2019 08:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrihVaU12W8r for ; Wed, 13 Feb 2019 08:17:23 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 7169E128701 for ; Wed, 13 Feb 2019 08:17:23 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id t200so3060777wmt.0 for ; Wed, 13 Feb 2019 08:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p1KLRoL07SlaruzEmUhIEHXDHoq7EOC5kzL5u6kijmM=; b=kZMYzJjLCEtQT207twyPTzHrA0N8zBDNrvgtIYjhZPUlbrKx+966RR0ndH0ftN3fqM C+JxVJaFrUd+CGI9n/CE/qDT5TwDSOlycM6H84Anmoha9AE2QcFcPROXIXV2Ww5LzS+O oWBWUbCghaIG3ywrkWo68Cc9V/5jvTDz7O/IoKw7Oyu0cILP7xAmaJDHd151zKujVEO+ f7cmkH6/yvpIPhxFowfenVrwrQ7f4T2Y+75ZBH9qsh3hjneDnYolx6Se3lEZZnkI+SP6 mQzrkaijGsqpIJsvj8Q26C9Pk4FiofA535dfD6cRrQeFaCsUipMRnOl++Ygn1eUkr5Oq 0nBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p1KLRoL07SlaruzEmUhIEHXDHoq7EOC5kzL5u6kijmM=; b=uAnpooxk92l/TkWadns8PqT6qgRpFaBgM+IlQfxsgB4siCdDTeQnuzKqO5J17hLR7W Ok51npcNYrIqDFqS8HLfN+TUUW5QGVuQY+Wyak86ZKDJDexFR3qeDypp8Y2N9UVvAFZM 2L3+B/4SovBG3zUkBImlwvtT8Vq9oNO/cIJuduPqw7S5kv2tbZU9xr06rjx6xQersZxK 0WWnyQ20eCxcjpoIBCwoqigWe1jcEwFPnqCetmgkHMj9TDxnA+EtkpYEuontKJugfhrt 6iUjwP0XNizA5BhD8MKCn8TOB6S4G4HqVtrHMfMplxT4u6qfSbRCQ/h82yJDEk1u+iNO FvEA== X-Gm-Message-State: AHQUAuZrTKBGTlCu4crsicB6FoDzpP9ptcfixaSutR5OTx3BRTQ1N9l/ 8f90BCkKVf4ivLo5dQEaXU/BHydbPAYTTyLm51w= X-Google-Smtp-Source: AHgI3IaY2oBfVf68Bba7xAwxSBAsajy+IqfNKkVLZu+7EV5kd0WX3gsCHm7JQXL6Eo5V0ppFNPVq0PlUgd0TiYsU0XU= X-Received: by 2002:a7b:c359:: with SMTP id l25mr931866wmj.130.1550074640408; Wed, 13 Feb 2019 08:17:20 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> In-Reply-To: <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> From: Martin Duke Date: Wed, 13 Feb 2019 08:17:07 -0800 Message-ID: Subject: Re: QUIC ossification To: Roberto Peon Cc: David Schinazi , "quic@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000005126c60581c8e09b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 16:17:26 -0000 --0000000000005126c60581c8e09b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that a fast v2 would help here. However, it's hard to count on a fast IETF process, and even then the middlebox can be pretty dumb and still drop version > 2. I agree that David's scheme, by having the Initial be a v1 packet, may get that one through. But then you have subsequent long headers with the new version, which may still end badly. I don't see a good solution here, right now. Although it shouldn't be written in the spec, the working group should have some sort of contingency plan for how to proceed if the version field ossifies. On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon wrote: > I don=E2=80=99t have an opinion on how version is negotiated yet. > I=E2=80=99m not convinced it is easy to get right. It may be more correct= for me > to say that I=E2=80=99m convinced it is reasonable difficult to get right= because > it is the most important of the various invariants. > > I also suspect that you need more than one way to do it, e.g. in-band and > out-of-band (which could be in-band in a V2 to allow for upgrade to > something else). Then does a client cache the version? For how long/where= ? > Per IP? Hostname? (blah blah.. etc. etc.) > > I can say that the ALPN and NPN approaches each had their positives and > negatives, and in the end, having something like either is probably good > enough. > > Rather than an opinion on how it should be done, I have an opinion that w= e > need to add this soon, as a V2. > > -=3DR > > > > *From: *David Schinazi > *Date: *Tuesday, February 12, 2019 at 4:13 PM > *To: *Roberto Peon > *Cc: *Martin Thomson , "quic@ietf.org" > *Subject: *Re: QUIC ossification > > > > I think we may be able to limit ossification of version numbers by adding > some GREASE to the (upcoming) in-band compatible version upgrade extensio= n > (what used to be EKR's PR). The idea of that extension is that the client > sends a QUICv1 initial containing a transport parameter indicating it > supports this extension and what versions of QUIC it supports. The server > can then send its replies with a new QUIC version number. Back to GREASE: > one option here would be for us to burn some versions for "v1 compatible > version negotiation greasing" (similar but different to 0x?a?a?a?a) and > servers can in-band upgrade to those versions. But we could also do that = in > the reverse direction: the servers advertise support for one of these in > Alt-Svc and clients send their Initial to that version, and the server ca= n > then perform in-band version change to v1, to another of these versions, = or > just keep the client's version for the life of this connection. This will > cause ossifying middleboxes to break these connections. > > > > Thoughts? > > > > David > > > > On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon wrote: > > My fear/experience around this is why I'd strongly recommend doing a QUIC > V2 as soon as possible where the delta from V1 -> V2 is limited to *solel= y* > what is necessary for version negotiation. > > We can simultaneously have a V3 conversation which would include whateve= r > else we decide we need to change/add as a separate conversation which > depends on V2. > > -=3DR > > On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" < > quic-bounces@ietf.org on behalf of mt@lowentropy.net> wrote: > > On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote: > > 1) Version. I can't think of any immediate negative consequences fo= r > a > > middlebox that drops any long header with a version > 1. TLS 1.3 ha= d > to > > surrender to this problem by hiding the version elsewhere. > > > > We might avoid this by routinely coalescing long headers with rando= m > > version fields to connection-critical packets. Beyond that, I'm out > of > > great ideas. If we don't have a robust defense against this, we > ought to > > put some thought into how to deploy a v2 if the version fields is > > inoperable. > > As Mike points out, the Length field is version-specific, so there is > no real defense here other than - as many have suggested - using the > version field actively. That means shipping another version. In a sense= , > the fact that Google are still not on the same version gives us some time= , > but it could mean that we might want to look toward having the "add versi= on > negotiation and fallback protection" draft define a version rather than a= n > extension. > > > 2) Client Transport Parameters. Initial Keys will help a little bit= , > but in > > TLS1.3 CCS still sorta exists because middleboxes are inspecting > packets so > > deeply. It's not viable for v2 to have the same transport > parameters; it's > > only slightly less gross to send v2 client TPs in some later messag= e > and > > have to send a fairly bulky "fake" set of v1 TPs in the client hell= o > to get > > through the network. > > I'm not concerned about transport parameters if the above issue is > fixed. TLS had no real issues with extensions, and it looks like we > already have the start of a pipeline of extensions coming. v2 can share > the transport parameter extension, unless we decide to change the format = in > a non-compatible way. > > (Note: CCS in TLS 1.3 only exists because middleboxes were inspecting > a lot, yes, but it also indicates that they weren't inspecting enough, > because the compatibility hack we have wouldn't work if they did a proper > job.) > > > --0000000000005126c60581c8e09b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that a fast v2 would help here. However, it&#= 39;s hard to count on a fast IETF process, and even then the middlebox can = be pretty dumb and still drop version > 2.

I ag= ree that David's scheme, by having the Initial be a v1 packet, may get = that one through. But then you have subsequent long headers with the new ve= rsion, which may still end badly.

I don't see = a good solution here, right now. Although it shouldn't be written in th= e spec, the working group should have some sort of contingency plan for how= to proceed if the version field ossifies.

On Tue, Feb 12, 2019 at= 4:21 PM Roberto Peon <fenix@fb.com&= gt; wrote:

I don=E2=80=99t have an opinion on how version is ne= gotiated yet.
I=E2=80=99m not convinced it is easy to get right. It may be more correct f= or me to say that I=E2=80=99m convinced it is reasonable difficult to get r= ight because it is the most important of the various invariants.

I also suspect that you need more than one way to do it, e.g. in-band and o= ut-of-band (which could be in-band in a V2 to allow for upgrade to somethin= g else). Then does a client cache the version? For how long/where? Per IP? = Hostname? (blah blah.. etc. etc.)

I can say that the ALPN and NPN approaches each had their positives and neg= atives, and in the end, having something like either is probably good enoug= h.

Rather than an opinion on how it should be done, I have an opinion that we = need to add this soon, as a V2.

-=3DR

=C2=A0

From: = David Schinazi <dschinazi.ietf@= gmail.com>
Date: Tuesday, February 12, 2019 at 4:13 PM
To: Roberto Peon <fenix@fb.com>
Cc: Martin Thomson <mt@lowentropy.net>, "quic@ietf.org" <quic@ietf.org>
Subject: Re: QUIC ossification

=C2=A0

I think we may be able to limit ossification of vers= ion numbers by adding some GREASE to the (upcoming) in-band compatible vers= ion upgrade extension (what used to be EKR's PR). The idea of that exte= nsion is that the client sends a QUICv1 initial containing a transport parameter indicating it supports this exten= sion and what versions of QUIC it supports. The server can then send its re= plies with a new QUIC version number. Back to GREASE: one option here would= be for us to burn some versions for "v1 compatible version negotiation greasing" (similar but di= fferent to=C2=A00x?a?a?a?a) and servers can in-band upgrade to those versio= ns. But we could also do that in the reverse direction: the servers adverti= se support for one of these in Alt-Svc and clients send their Initial to that version, and the server can then perform in-ban= d version change to v1, to another of these versions, or just keep the clie= nt's version for the life of this connection. This will cause ossifying= middleboxes to break these connections.

=C2=A0

Thoughts?

=C2=A0

David

=C2=A0

On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <fenix@fb.com> wrote:<= u>

My fear/experience arou= nd this is why I'd strongly recommend doing a QUIC V2 as soon as possib= le where the delta from V1 -> V2 is limited to *solely* what is necessar= y for version negotiation.

We can simultaneously have a V3 conversation which would=C2=A0 include what= ever else we decide we need to change/add as a separate conversation which = depends on V2.

-=3DR

On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <quic-bounces@ietf.org= on behalf of mt@lowentropy.net> wrote:

=C2=A0 =C2=A0 On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote:
=C2=A0 =C2=A0 > 1) Version. I can't think of any immediate negative = consequences for a
=C2=A0 =C2=A0 > middlebox that drops any long header with a version >= 1. TLS 1.3 had to
=C2=A0 =C2=A0 > surrender to this problem by hiding the version elsewher= e.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We might avoid this by routinely coalescing long headers= with random
=C2=A0 =C2=A0 > version fields to connection-critical packets. Beyond th= at, I'm out of
=C2=A0 =C2=A0 > great ideas. If we don't have a robust defense again= st this, we ought to
=C2=A0 =C2=A0 > put some thought into how to deploy a v2 if the version = fields is
=C2=A0 =C2=A0 > inoperable.

=C2=A0 =C2=A0 As Mike points out, the Length field is version-specific, so = there is no real defense here other than - as many have suggested - using t= he version field actively.=C2=A0 That means shipping another version.=C2=A0= In a sense, the fact that Google are still not on the same version gives us some time, but it could mean that we might want to l= ook toward having the "add version negotiation and fallback protection= " draft define a version rather than an extension.

=C2=A0 =C2=A0 > 2) Client Transport Parameters. Initial Keys will help a= little bit, but in
=C2=A0 =C2=A0 > TLS1.3 CCS still sorta exists because middleboxes are in= specting packets so
=C2=A0 =C2=A0 > deeply. It's not viable for v2 to have the same tran= sport parameters; it's
=C2=A0 =C2=A0 > only slightly less gross to send v2 client TPs in some l= ater message and
=C2=A0 =C2=A0 > have to send a fairly bulky "fake" set of v1 T= Ps in the client hello to get
=C2=A0 =C2=A0 > through the network.

=C2=A0 =C2=A0 I'm not concerned about transport parameters if the above= issue is fixed.=C2=A0 TLS had no real issues with extensions, and it looks= like we already have the start of a pipeline of extensions coming.=C2=A0 v= 2 can share the transport parameter extension, unless we decide to change the format in a non-compatible way.

=C2=A0 =C2=A0 (Note: CCS in TLS 1.3 only exists because middleboxes were in= specting a lot, yes, but it also indicates that they weren't inspecting= enough, because the compatibility hack we have wouldn't work if they d= id a proper job.)


--0000000000005126c60581c8e09b-- From nobody Wed Feb 13 08:56:31 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F7E12D829 for ; Wed, 13 Feb 2019 08:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWBcg5q2NPWq for ; Wed, 13 Feb 2019 08:56:27 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC441200ED for ; Wed, 13 Feb 2019 08:56:26 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id q1so3321454wrp.7 for ; Wed, 13 Feb 2019 08:56:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+hQnhf0FCnPxROBTfZVwskmtQ++55bSx8OMUVEVuNQk=; b=OeJ9m4/skeOlwpq1EeCZW/i/EhLNkaebgMDqF0Y3DM3dyOgM5In+n0l1I/BxOF4HI6 gRZNgIVLCSMegSqhdpVhxcPQIavgVimMZjevUirC6U2cFlCsge/5ZxjXuKeXDQEGGOQK yy7Ov7yGD2V5Su2mRUNHZ5cf2jCaetDwinYAnaJzsHnELmtaXILPk4D98W8++EZ0m2gM P4MbLGFcPa0egUqXPAE7sN3t34u2Yrlx+VoVvmQfw/NFnnxH/jsyxughJ+jHwyj5Fzs1 UZyxoiuGiUJ2cvAP7+NBndeWkXPv9saYpIYdAakTDD3+5lm0QKJwjNsr4cLTKwQX8DWy 9fDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+hQnhf0FCnPxROBTfZVwskmtQ++55bSx8OMUVEVuNQk=; b=Zi8OTMm9MMELAtqOvlIZDDGc5Eo3h7WebH9FS0IuoEl2XQvAeIm4Q0yL+iURdhw1Rh meTZVb528EoZgU4ebBhNXvygX4mBWonljDy0Q3myRDDYkE0izhzNaT2cXckR1yFwikJl swUU7qUApP2Kqi0iGJs3OlmJCksOPbvkvS2G87u4z7KRFy1dIc2ZSMNlJBDBn9eykSM4 LBwUtZbsG07w7YC+509pEsmR5os1QtCzWd/EzGXH8MJhJ5ONev57goSWX5W3oZSQWcfQ Lp9XeYEC4UiuNHezSImodpk+G3MGcZpl5bI0v2HJRuPILjzdDWY2pgxhS1ZFceQriXj+ s5Kg== X-Gm-Message-State: AHQUAuaWGJV4FwoGBndySINVLSCo5Mx+FOSzuaUzDhs3rukUDsKkV2Rs 1dakC/K1F/CT3HRyUfQFCUJCAxDdCObOzlyVYHwCew== X-Google-Smtp-Source: AHgI3IZN49B1EGuqYNQgPQoErIF+qDtRH8QHK0mC2b/K2MD96FUA9dzoOp27QYJ+a9smlg5FQNsIsXJMhMSOPPbP1Ns= X-Received: by 2002:adf:e290:: with SMTP id v16mr1269768wri.100.1550076984646; Wed, 13 Feb 2019 08:56:24 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> In-Reply-To: From: Ian Swett Date: Wed, 13 Feb 2019 11:56:11 -0500 Message-ID: Subject: Re: QUIC ossification To: Martin Duke Cc: Roberto Peon , David Schinazi , "quic@ietf.org" , Martin Thomson , David Benjamin Content-Type: multipart/alternative; boundary="0000000000000bcf360581c96c2a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 16:56:30 -0000 --0000000000000bcf360581c96c2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Previously David Benjamin suggested spinning a new version of QUIC in Chrome for every Chrome milestone with the only change being the version number and the Initial keys. I'd be curious how the WG feels about that idea? On Wed, Feb 13, 2019 at 11:17 AM Martin Duke wrote: > I agree that a fast v2 would help here. However, it's hard to count on a > fast IETF process, and even then the middlebox can be pretty dumb and sti= ll > drop version > 2. > > I agree that David's scheme, by having the Initial be a v1 packet, may ge= t > that one through. But then you have subsequent long headers with the new > version, which may still end badly. > > I don't see a good solution here, right now. Although it shouldn't be > written in the spec, the working group should have some sort of contingen= cy > plan for how to proceed if the version field ossifies. > > On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon wrote: > >> I don=E2=80=99t have an opinion on how version is negotiated yet. >> I=E2=80=99m not convinced it is easy to get right. It may be more correc= t for me >> to say that I=E2=80=99m convinced it is reasonable difficult to get righ= t because >> it is the most important of the various invariants. >> >> I also suspect that you need more than one way to do it, e.g. in-band an= d >> out-of-band (which could be in-band in a V2 to allow for upgrade to >> something else). Then does a client cache the version? For how long/wher= e? >> Per IP? Hostname? (blah blah.. etc. etc.) >> >> I can say that the ALPN and NPN approaches each had their positives and >> negatives, and in the end, having something like either is probably good >> enough. >> >> Rather than an opinion on how it should be done, I have an opinion that >> we need to add this soon, as a V2. >> >> -=3DR >> >> >> >> *From: *David Schinazi >> *Date: *Tuesday, February 12, 2019 at 4:13 PM >> *To: *Roberto Peon >> *Cc: *Martin Thomson , "quic@ietf.org" >> *Subject: *Re: QUIC ossification >> >> >> >> I think we may be able to limit ossification of version numbers by addin= g >> some GREASE to the (upcoming) in-band compatible version upgrade extensi= on >> (what used to be EKR's PR). The idea of that extension is that the clien= t >> sends a QUICv1 initial containing a transport parameter indicating it >> supports this extension and what versions of QUIC it supports. The serve= r >> can then send its replies with a new QUIC version number. Back to GREASE= : >> one option here would be for us to burn some versions for "v1 compatible >> version negotiation greasing" (similar but different to 0x?a?a?a?a) and >> servers can in-band upgrade to those versions. But we could also do that= in >> the reverse direction: the servers advertise support for one of these in >> Alt-Svc and clients send their Initial to that version, and the server c= an >> then perform in-band version change to v1, to another of these versions,= or >> just keep the client's version for the life of this connection. This wil= l >> cause ossifying middleboxes to break these connections. >> >> >> >> Thoughts? >> >> >> >> David >> >> >> >> On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon wrote: >> >> My fear/experience around this is why I'd strongly recommend doing a QUI= C >> V2 as soon as possible where the delta from V1 -> V2 is limited to *sole= ly* >> what is necessary for version negotiation. >> >> We can simultaneously have a V3 conversation which would include >> whatever else we decide we need to change/add as a separate conversation >> which depends on V2. >> >> -=3DR >> >> On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" < >> quic-bounces@ietf.org on behalf of mt@lowentropy.net> wrote: >> >> On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote: >> > 1) Version. I can't think of any immediate negative consequences >> for a >> > middlebox that drops any long header with a version > 1. TLS 1.3 >> had to >> > surrender to this problem by hiding the version elsewhere. >> > >> > We might avoid this by routinely coalescing long headers with rand= om >> > version fields to connection-critical packets. Beyond that, I'm ou= t >> of >> > great ideas. If we don't have a robust defense against this, we >> ought to >> > put some thought into how to deploy a v2 if the version fields is >> > inoperable. >> >> As Mike points out, the Length field is version-specific, so there i= s >> no real defense here other than - as many have suggested - using the >> version field actively. That means shipping another version. In a sens= e, >> the fact that Google are still not on the same version gives us some tim= e, >> but it could mean that we might want to look toward having the "add vers= ion >> negotiation and fallback protection" draft define a version rather than = an >> extension. >> >> > 2) Client Transport Parameters. Initial Keys will help a little >> bit, but in >> > TLS1.3 CCS still sorta exists because middleboxes are inspecting >> packets so >> > deeply. It's not viable for v2 to have the same transport >> parameters; it's >> > only slightly less gross to send v2 client TPs in some later >> message and >> > have to send a fairly bulky "fake" set of v1 TPs in the client >> hello to get >> > through the network. >> >> I'm not concerned about transport parameters if the above issue is >> fixed. TLS had no real issues with extensions, and it looks like we >> already have the start of a pipeline of extensions coming. v2 can share >> the transport parameter extension, unless we decide to change the format= in >> a non-compatible way. >> >> (Note: CCS in TLS 1.3 only exists because middleboxes were inspectin= g >> a lot, yes, but it also indicates that they weren't inspecting enough, >> because the compatibility hack we have wouldn't work if they did a prope= r >> job.) >> >> >> --0000000000000bcf360581c96c2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Previously David Benjamin suggested spinning a new version= of QUIC in Chrome for every Chrome milestone with the only change being th= e version number and the Initial keys.=C2=A0 I'd be curious how the WG = feels about that idea?

On Wed, Feb 13, 2019 at 11:17 AM Martin Duke <martin.h.duke@gmail.com> wrot= e:
I agree that a fast v2 would help here. However, it's hard to = count on a fast IETF process, and even then the middlebox can be pretty dum= b and still drop version > 2.

I agree that Davi= d's scheme, by having the Initial be a v1 packet, may get that one thro= ugh. But then you have subsequent long headers with the new version, which = may still end badly.

I don't see a good soluti= on here, right now. Although it shouldn't be written in the spec, the w= orking group should have some sort of contingency plan for how to proceed i= f the version field ossifies.

On Tue, Feb 12, 2019 at 4:21 PM Robe= rto Peon <fenix@fb.com= > wrote:

I don=E2=80=99t have an opinion on how version is ne= gotiated yet.
I=E2=80=99m not convinced it is easy to get right. It may be more correct f= or me to say that I=E2=80=99m convinced it is reasonable difficult to get r= ight because it is the most important of the various invariants.

I also suspect that you need more than one way to do it, e.g. in-band and o= ut-of-band (which could be in-band in a V2 to allow for upgrade to somethin= g else). Then does a client cache the version? For how long/where? Per IP? = Hostname? (blah blah.. etc. etc.)

I can say that the ALPN and NPN approaches each had their positives and neg= atives, and in the end, having something like either is probably good enoug= h.

Rather than an opinion on how it should be done, I have an opinion that we = need to add this soon, as a V2.

-=3DR

=C2=A0

From: = David Schinazi <dschinazi.ietf@= gmail.com>
Date: Tuesday, February 12, 2019 at 4:13 PM
To: Roberto Peon <fenix@fb.com>
Cc: Martin Thomson <mt@lowentropy.net>, "quic@ietf.org" <quic@ietf.org>
Subject: Re: QUIC ossification

=C2=A0

I think we may be able to limit ossification of vers= ion numbers by adding some GREASE to the (upcoming) in-band compatible vers= ion upgrade extension (what used to be EKR's PR). The idea of that exte= nsion is that the client sends a QUICv1 initial containing a transport parameter indicating it supports this exten= sion and what versions of QUIC it supports. The server can then send its re= plies with a new QUIC version number. Back to GREASE: one option here would= be for us to burn some versions for "v1 compatible version negotiation greasing" (similar but di= fferent to=C2=A00x?a?a?a?a) and servers can in-band upgrade to those versio= ns. But we could also do that in the reverse direction: the servers adverti= se support for one of these in Alt-Svc and clients send their Initial to that version, and the server can then perform in-ban= d version change to v1, to another of these versions, or just keep the clie= nt's version for the life of this connection. This will cause ossifying= middleboxes to break these connections.

=C2=A0

Thoughts?

=C2=A0

David

=C2=A0

On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <fenix@fb.com> wrote:<= u>

My fear/experience arou= nd this is why I'd strongly recommend doing a QUIC V2 as soon as possib= le where the delta from V1 -> V2 is limited to *solely* what is necessar= y for version negotiation.

We can simultaneously have a V3 conversation which would=C2=A0 include what= ever else we decide we need to change/add as a separate conversation which = depends on V2.

-=3DR

On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <quic-bounces@ietf.org= on behalf of mt@lowentropy.net> wrote:

=C2=A0 =C2=A0 On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote:
=C2=A0 =C2=A0 > 1) Version. I can't think of any immediate negative = consequences for a
=C2=A0 =C2=A0 > middlebox that drops any long header with a version >= 1. TLS 1.3 had to
=C2=A0 =C2=A0 > surrender to this problem by hiding the version elsewher= e.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We might avoid this by routinely coalescing long headers= with random
=C2=A0 =C2=A0 > version fields to connection-critical packets. Beyond th= at, I'm out of
=C2=A0 =C2=A0 > great ideas. If we don't have a robust defense again= st this, we ought to
=C2=A0 =C2=A0 > put some thought into how to deploy a v2 if the version = fields is
=C2=A0 =C2=A0 > inoperable.

=C2=A0 =C2=A0 As Mike points out, the Length field is version-specific, so = there is no real defense here other than - as many have suggested - using t= he version field actively.=C2=A0 That means shipping another version.=C2=A0= In a sense, the fact that Google are still not on the same version gives us some time, but it could mean that we might want to l= ook toward having the "add version negotiation and fallback protection= " draft define a version rather than an extension.

=C2=A0 =C2=A0 > 2) Client Transport Parameters. Initial Keys will help a= little bit, but in
=C2=A0 =C2=A0 > TLS1.3 CCS still sorta exists because middleboxes are in= specting packets so
=C2=A0 =C2=A0 > deeply. It's not viable for v2 to have the same tran= sport parameters; it's
=C2=A0 =C2=A0 > only slightly less gross to send v2 client TPs in some l= ater message and
=C2=A0 =C2=A0 > have to send a fairly bulky "fake" set of v1 T= Ps in the client hello to get
=C2=A0 =C2=A0 > through the network.

=C2=A0 =C2=A0 I'm not concerned about transport parameters if the above= issue is fixed.=C2=A0 TLS had no real issues with extensions, and it looks= like we already have the start of a pipeline of extensions coming.=C2=A0 v= 2 can share the transport parameter extension, unless we decide to change the format in a non-compatible way.

=C2=A0 =C2=A0 (Note: CCS in TLS 1.3 only exists because middleboxes were in= specting a lot, yes, but it also indicates that they weren't inspecting= enough, because the compatibility hack we have wouldn't work if they d= id a proper job.)


--0000000000000bcf360581c96c2a-- From nobody Wed Feb 13 09:14:05 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C388124BAA for ; Wed, 13 Feb 2019 09:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=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 sGCTp9sHjvtj for ; Wed, 13 Feb 2019 09:14:02 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2030E1200B3 for ; Wed, 13 Feb 2019 09:14:02 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id z20so7351769itc.3 for ; Wed, 13 Feb 2019 09:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SM6GMMl/Pldll5V9LkuHQdsXm6d3D1dGJsnXJVqoAfI=; b=m7BhVgjWv9opOsaVvhwyUjEVWuMnsI/NBNWOd6YKrWSz8Tl42qfaGXtENS09eRqyrW zVsTj1NAA1PoJLdD+DLVc4rH4A5BqKn10sNtKdvKbB0NAnO9lznUVUaoiTqEMjOA6Juu C0tSL0s3hzqAdKlCLoRrDvHhII9Q7NrbKpOjUoyR9ZGQFuEnmXoiHlIGB3qWnSV+ZuTo ISjwHFyymxjgJUIS9/VNKORnc2OrXiCHEVziuIT3ONX7ooE7Xf/zmcKE4uqICJA8e0Yq Ec/TRw9+Lim4QS6vgtuNczQORmnM7F5+D/6/DI+48ppFkUElnaUfuKnXT9tB5zL+XBL8 Yibw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SM6GMMl/Pldll5V9LkuHQdsXm6d3D1dGJsnXJVqoAfI=; b=rY8C2m5dq8UplNNrMxZD2tXM0Qd28gEEJyX/Mt7bXAKBEjVtbIZQ9Raq0FVcAJeeYr VbEo1Z5p5medZWrqWhfQqTZFU7B1Ybjdoof+dV0znuIsl3+UIKF4jXTkF9q8O65s+Xah asd5zpRTJX94lSELJ1o8EkOlOI37fIjtuxmzf23bfTU/Kj00zBnuORFM8hYiYJJ7T0gj fawV+mSyQP+rikBPfB7fGG6BygHYlhbRF3DVxWOqg1eU2TmWvxsPTn1IjgGdZZRyK7WS XwspwO3BgZybpzEn+SFbv6BoHOqI1SFWs7rr39Q0MIbdqEH27kpQrhSjU7OCGA1oQRr1 tbBA== X-Gm-Message-State: AHQUAuYgtmS818yR1IG/QClnw6aMTdZAOsKhhOTGq15vakRkyFWE8B9h cwkmvPpCAT7lCYNgYCT8qx+WTkdCIT/Sd2S8p4k= X-Google-Smtp-Source: AHgI3Ibm4fQWHsBPltJoU80ZxRoNHpIYK3BH+STrNIJ6qA77+RL5fBAzWVQirH2qGqTAywJrxZ3Endjf43keii4vSx8= X-Received: by 2002:a05:660c:81a:: with SMTP id j26mr847830itk.70.1550078041291; Wed, 13 Feb 2019 09:14:01 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Feb 2019 09:14:00 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 13 Feb 2019 09:14:00 -0800 Message-ID: Subject: Re: QUIC ossification To: Ian Swett , Martin Duke Cc: David Schinazi , "quic@ietf.org" , David Benjamin , Roberto Peon , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000067ffc0581c9ab3e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 17:14:04 -0000 --000000000000067ffc0581c9ab3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is the risk that middle boxes learn that versions mean nothing, and that they are all the same, akin to crying wolf. If it also mutated transport parameters and other observables, it would start being a defence. Alas, once 1.0 hits, things are back to normal. So I doubt this exercise would be worthwhile. But, I don=E2=80=99t have any strong opinion. On 13 February 2019 at 17.56.47, Ian Swett ( ianswett=3D40google.com@dmarc.ietf.org) wrote: Previously David Benjamin suggested spinning a new version of QUIC in Chrome for every Chrome milestone with the only change being the version number and the Initial keys. I'd be curious how the WG feels about that idea? On Wed, Feb 13, 2019 at 11:17 AM Martin Duke wrote: > I agree that a fast v2 would help here. However, it's hard to count on a > fast IETF process, and even then the middlebox can be pretty dumb and sti= ll > drop version > 2. > > I agree that David's scheme, by having the Initial be a v1 packet, may ge= t > that one through. But then you have subsequent long headers with the new > version, which may still end badly. > > I don't see a good solution here, right now. Although it shouldn't be > written in the spec, the working group should have some sort of contingen= cy > plan for how to proceed if the version field ossifies. > > On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon wrote: > >> I don=E2=80=99t have an opinion on how version is negotiated yet. >> I=E2=80=99m not convinced it is easy to get right. It may be more correc= t for me >> to say that I=E2=80=99m convinced it is reasonable difficult to get righ= t because >> it is the most important of the various invariants. >> >> I also suspect that you need more than one way to do it, e.g. in-band an= d >> out-of-band (which could be in-band in a V2 to allow for upgrade to >> something else). Then does a client cache the version? For how long/wher= e? >> Per IP? Hostname? (blah blah.. etc. etc.) >> >> I can say that the ALPN and NPN approaches each had their positives and >> negatives, and in the end, having something like either is probably good >> enough. >> >> Rather than an opinion on how it should be done, I have an opinion that >> we need to add this soon, as a V2. >> >> -=3DR >> >> >> >> *From:* David Schinazi >> *Date:* Tuesday, February 12, 2019 at 4:13 PM >> *To:* Roberto Peon >> *Cc:* Martin Thomson , "quic@ietf.org" >> *Subject:* Re: QUIC ossification >> >> >> >> I think we may be able to limit ossification of version numbers by addin= g >> some GREASE to the (upcoming) in-band compatible version upgrade extensi= on >> (what used to be EKR's PR). The idea of that extension is that the clien= t >> sends a QUICv1 initial containing a transport parameter indicating it >> supports this extension and what versions of QUIC it supports. The serve= r >> can then send its replies with a new QUIC version number. Back to GREASE= : >> one option here would be for us to burn some versions for "v1 compatible >> version negotiation greasing" (similar but different to 0x?a?a?a?a) and >> servers can in-band upgrade to those versions. But we could also do that= in >> the reverse direction: the servers advertise support for one of these in >> Alt-Svc and clients send their Initial to that version, and the server c= an >> then perform in-band version change to v1, to another of these versions,= or >> just keep the client's version for the life of this connection. This wil= l >> cause ossifying middleboxes to break these connections. >> >> >> >> Thoughts? >> >> >> >> David >> >> >> >> On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon wrote: >> >> My fear/experience around this is why I'd strongly recommend doing a QUI= C >> V2 as soon as possible where the delta from V1 -> V2 is limited to *sole= ly* >> what is necessary for version negotiation. >> >> We can simultaneously have a V3 conversation which would include >> whatever else we decide we need to change/add as a separate conversation >> which depends on V2. >> >> -=3DR >> >> On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" < >> quic-bounces@ietf.org on behalf of mt@lowentropy.net> wrote: >> >> On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote: >> > 1) Version. I can't think of any immediate negative consequences >> for a >> > middlebox that drops any long header with a version > 1. TLS 1.3 >> had to >> > surrender to this problem by hiding the version elsewhere. >> > >> > We might avoid this by routinely coalescing long headers with rand= om >> > version fields to connection-critical packets. Beyond that, I'm ou= t >> of >> > great ideas. If we don't have a robust defense against this, we >> ought to >> > put some thought into how to deploy a v2 if the version fields is >> > inoperable. >> >> As Mike points out, the Length field is version-specific, so there i= s >> no real defense here other than - as many have suggested - using the >> version field actively. That means shipping another version. In a sens= e, >> the fact that Google are still not on the same version gives us some tim= e, >> but it could mean that we might want to look toward having the "add vers= ion >> negotiation and fallback protection" draft define a version rather than = an >> extension. >> >> > 2) Client Transport Parameters. Initial Keys will help a little >> bit, but in >> > TLS1.3 CCS still sorta exists because middleboxes are inspecting >> packets so >> > deeply. It's not viable for v2 to have the same transport >> parameters; it's >> > only slightly less gross to send v2 client TPs in some later >> message and >> > have to send a fairly bulky "fake" set of v1 TPs in the client >> hello to get >> > through the network. >> >> I'm not concerned about transport parameters if the above issue is >> fixed. TLS had no real issues with extensions, and it looks like we >> already have the start of a pipeline of extensions coming. v2 can share >> the transport parameter extension, unless we decide to change the format= in >> a non-compatible way. >> >> (Note: CCS in TLS 1.3 only exists because middleboxes were inspectin= g >> a lot, yes, but it also indicates that they weren't inspecting enough, >> because the compatibility hack we have wouldn't work if they did a prope= r >> job.) >> >> >> --000000000000067ffc0581c9ab3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = There is the risk th= at middle boxes learn that versions mean nothing, and that they are all the= same, akin to crying wolf.



But, I don=E2=80=99t have any strong opinion.

On 13 F= ebruary 2019 at 17.56.47, Ian Swett (ianswett=3D40google.com@dmarc.ietf.org) wrote:

=
Previously David Benjamin suggested spinning a new version of QUIC in Chrome for every Chrome milestone with the only change being the version number and the Initial keys.=C2=A0 I'd be curious how the WG feels about that idea?

On Wed, Feb 13, 2019 at 11:17 AM Martin Duke <martin.h.duke@gm= ail.com> wrote:
I agree that a fast v2 would help here. However, it's hard to count on a fast IETF process, and even then the middlebox can be pretty dumb and still drop version > 2.

I agree that David's scheme, by having the Initial be a v1 packet, may get that one through. But then you have subsequent long headers with the new version, which may still end badly.

I don't see a good solution here, right now. Although it shouldn't be written in the spec, the working group should have some sort of contingency plan for how to proceed if the version field ossifies.

On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon <fenix@fb= .com> wrote:

I don=E2=80=99t have an opinion on how version is negotiated yet.
I=E2=80=99m not convinced it is easy to get right. It may be more correct for me to say that I=E2=80=99m convinced it is reasonable difficult to get right because it is the most important of the various invariants.

I also suspect that you need more than one way to do it, e.g. in-band and out-of-band (which could be in-band in a V2 to allow for upgrade to something else). Then does a client cache the version? For how long/where? Per IP? Hostname? (blah blah.. etc. etc.)

I can say that the ALPN and NPN approaches each had their positives and negatives, and in the end, having something like either is probably good enough.

Rather than an opinion on how it should be done, I have an opinion that we need to add this soon, as a V2.

-=3DR

=C2=A0

From:<= /span> David Schinazi <dschinazi.ietf@= gmail.com>
Date: Tuesday, February 12, 2019 at 4:13 PM
To: Roberto Peon <fenix@fb.com>
Cc: Martin Thomson <mt@lowentropy.net>, "quic@ietf.org" <quic@ietf.org>= ;
Subject: Re: QUIC ossification

=C2=A0

I think we may be able to limit ossification of version numbers by adding some GREASE to the (upcoming) in-band compatible version upgrade extension (what used to be EKR's PR). The idea of that extension is that the client sends a QUICv1 initial containing a transport parameter indicating it supports this extension and what versions of QUIC it supports. The server can then send its replies with a new QUIC version number. Back to GREASE: one option here would be for us to burn some versions for "v1 compatible version negotiation greasing" (similar but differe= nt to=C2=A00x?a?a?a?a) and servers can in-band upgrade to those versions. But we could also do that in the reverse direction: the servers advertise support for one of these in Alt-Svc and clients send their Initial to that version, and the server can then perform in-band version change to v1, to another of these versions, or just keep the client's version for the life of this connection. This will cause ossifying middleboxes to break these connections.

=C2=A0

Thoughts?

=C2=A0

David

=C2=A0

On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <fenix@fb.com> = wrote:

My fear/experience around this is why I'd strongly recommend doing a QUIC V2 as soon as possible where the delta from V1 -> V2 is limited to *solely* what is necessary for version negotiation.

We can simultaneously have a V3 conversation which would=C2=A0 include whatever else we decide we need to change/add as a separate conversation which depends on V2.

-=3DR

On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <quic-bounces= @ietf.org on behalf of mt@lowentropy.net> wrote:

=C2=A0 =C2=A0 On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote:
=C2=A0 =C2=A0 > 1) Version. I can't think of any immediate negative consequences for a
=C2=A0 =C2=A0 > middlebox that drops any long header with a version > 1. TLS 1.3 had to
=C2=A0 =C2=A0 > surrender to this problem by hiding the version elsewhere.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We might avoid this by routinely coalescing long headers with random
=C2=A0 =C2=A0 > version fields to connection-critical packets. Beyond that, I'm out of
=C2=A0 =C2=A0 > great ideas. If we don't have a robust defense against this, we ought to
=C2=A0 =C2=A0 > put some thought into how to deploy a v2 if the version fields is
=C2=A0 =C2=A0 > inoperable.

=C2=A0 =C2=A0 As Mike points out, the Length field is version-specific, so there is no real defense here other than - as many have suggested - using the version field actively.=C2=A0 That means shipping another version.=C2=A0 In a sense, the fact that Google are still not on the same version gives us some time, but it could mean that we might want to look toward having the "add version negotiation and fallback protection" draft define a version rather than an extension.

=C2=A0 =C2=A0 > 2) Client Transport Parameters. Initial Keys will help a little bit, but in
=C2=A0 =C2=A0 > TLS1.3 CCS still sorta exists because middleboxes are inspecting packets so
=C2=A0 =C2=A0 > deeply. It's not viable for v2 to have the same transport parameters; it's
=C2=A0 =C2=A0 > only slightly less gross to send v2 client TPs in some later message and
=C2=A0 =C2=A0 > have to send a fairly bulky "fake" set of v1 T= Ps in the client hello to get
=C2=A0 =C2=A0 > through the network.

=C2=A0 =C2=A0 I'm not concerned about transport parameters if the above issue is fixed.=C2=A0 TLS had no real issues with extensions, and it looks like we already have the start of a pipeline of extensions coming.=C2=A0 v2 can share the transport parameter extension, unless we decide to change the format in a non-compatible way.

=C2=A0 =C2=A0 (Note: CCS in TLS 1.3 only exists because middleboxes were inspecting a lot, yes, but it also indicates that they weren't inspecting enough, because the compatibility hack we have wouldn't work if they did a proper job.)


--000000000000067ffc0581c9ab3e-- From nobody Wed Feb 13 09:17:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7A3129532 for ; Wed, 13 Feb 2019 09:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFmKa2_ggb8l for ; Wed, 13 Feb 2019 09:17:30 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781A01289FA for ; Wed, 13 Feb 2019 09:17:30 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id h6so6092343itl.1 for ; Wed, 13 Feb 2019 09:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=idwawwT711SyMnA+8B8iHV40F+R2lhgspv3sQGUllks=; b=ixuxb7paQezJSTM8L1OV2veXK2LhTO+UZHU23XBuaPsfL4joBGoKhMrmGV2Xf1so6t K+mTd7gx3rSQgGQmGqeGo1XlWf3t1dnCXEv6s1pZ1tT7v+d0IfvQ3xzTtqPYoezfkkv+ AQYalFnF7vYWyxeYv/szBSxgSoreaINicUDD9B0zpvO2FG1sxrl1o7f+XRaV6WPtjaiQ 9vzG/Thk3Tcw/3TacBpbl4q8vUYRrwXA3HtBy03b88vL6kap7DqZvO6Mea6/YKNEZtoI /tWq5nulB0bfRSlpGRvHzssqbv7ijvMUDjQ/6simFOHjOkzLb7VcEXCxmNxq1fALhU8s z7tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=idwawwT711SyMnA+8B8iHV40F+R2lhgspv3sQGUllks=; b=prpvyDRijdnD9P7QfPcoZSVYc3Qm1nn8QTq0luhOgZuG+EDknlP+iWacI8DZdq9Cj/ OxHQz3C/z4bil+TLfFRobCO3ehCtIUA+GeKUG1sjjYUarqv/qqlDRi5M4v2Jc9+aobC/ ivUwZr6TKBjc0zRba+3FeY/JsI9t2JfErEnn9+3PMZksqnucn53NzMVyVnFyakRyNUu0 7c9un2PgZ5h86nFcw7Sqm30lpKgjlD5OJzPZCOzeG3+5wAgeR0bionCr5H8+2bhnuNoF +EITpgD62k3e08o4to6M9hHX33AdADxcttMlTw3kJQGrXKvo8bWHnEmDRNYYhblBSFQC 0yJQ== X-Gm-Message-State: AHQUAuZmuBIGJmA9v7XdQ1FUUXGEPPfk87qV+cs2ndAH8LUxI7X2qFZb 9EwGKLlHSK4ZLzPhHzdloLAQBavJwsXjKyi+kWs= X-Google-Smtp-Source: AHgI3IaRxtlBnp/0pWneGhy6Pr7kTO7jh4w4fSBY8ovH9rgL2EGAvlmfpiZSt+hi60fq+7HEhCapn4oUVUarjhOWzv0= X-Received: by 2002:a5d:8d90:: with SMTP id b16mr1000348ioj.35.1550078249297; Wed, 13 Feb 2019 09:17:29 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> In-Reply-To: From: Ted Hardie Date: Wed, 13 Feb 2019 09:17:01 -0800 Message-ID: Subject: Re: QUIC ossification To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Ian Swett , Martin Duke , David Schinazi , "quic@ietf.org" , David Benjamin , Roberto Peon , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000006c6cb20581c9b706" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 17:17:33 -0000 --0000000000006c6cb20581c9b706 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > There is the risk that middle boxes learn that versions mean nothing, and > that they are all the same, akin to crying wolf. > > I tend to agree with this. Version numbers should shift when the interoperability among parties to the protocol shifts. While you can artificially create that shift in closed system, teaching the ecosystem that the shifts are meaningless doesn't seem to advance the general goal. Ted > If it also mutated transport parameters and other observables, it would > start being a defence. > > Alas, once 1.0 hits, things are back to normal. > So I doubt this exercise would be worthwhile. > > But, I don=E2=80=99t have any strong opinion. > > On 13 February 2019 at 17.56.47, Ian Swett ( > ianswett=3D40google.com@dmarc.ietf.org) wrote: > > Previously David Benjamin suggested spinning a new version of QUIC in > Chrome for every Chrome milestone with the only change being the version > number and the Initial keys. I'd be curious how the WG feels about that > idea? > > On Wed, Feb 13, 2019 at 11:17 AM Martin Duke > wrote: > >> I agree that a fast v2 would help here. However, it's hard to count on a >> fast IETF process, and even then the middlebox can be pretty dumb and st= ill >> drop version > 2. >> >> I agree that David's scheme, by having the Initial be a v1 packet, may >> get that one through. But then you have subsequent long headers with the >> new version, which may still end badly. >> >> I don't see a good solution here, right now. Although it shouldn't be >> written in the spec, the working group should have some sort of continge= ncy >> plan for how to proceed if the version field ossifies. >> >> On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon > > wrote: >> >>> I don=E2=80=99t have an opinion on how version is negotiated yet. >>> I=E2=80=99m not convinced it is easy to get right. It may be more corre= ct for me >>> to say that I=E2=80=99m convinced it is reasonable difficult to get rig= ht because >>> it is the most important of the various invariants. >>> >>> I also suspect that you need more than one way to do it, e.g. in-band >>> and out-of-band (which could be in-band in a V2 to allow for upgrade to >>> something else). Then does a client cache the version? For how long/whe= re? >>> Per IP? Hostname? (blah blah.. etc. etc.) >>> >>> I can say that the ALPN and NPN approaches each had their positives and >>> negatives, and in the end, having something like either is probably goo= d >>> enough. >>> >>> Rather than an opinion on how it should be done, I have an opinion that >>> we need to add this soon, as a V2. >>> >>> -=3DR >>> >>> >>> >>> *From:* David Schinazi >>> *Date:* Tuesday, February 12, 2019 at 4:13 PM >>> *To:* Roberto Peon >>> *Cc:* Martin Thomson , "quic@ietf.org" >> > >>> *Subject:* Re: QUIC ossification >>> >>> >>> >>> I think we may be able to limit ossification of version numbers by >>> adding some GREASE to the (upcoming) in-band compatible version upgrade >>> extension (what used to be EKR's PR). The idea of that extension is tha= t >>> the client sends a QUICv1 initial containing a transport parameter >>> indicating it supports this extension and what versions of QUIC it >>> supports. The server can then send its replies with a new QUIC version >>> number. Back to GREASE: one option here would be for us to burn some >>> versions for "v1 compatible version negotiation greasing" (similar but >>> different to 0x?a?a?a?a) and servers can in-band upgrade to those versi= ons. >>> But we could also do that in the reverse direction: the servers adverti= se >>> support for one of these in Alt-Svc and clients send their Initial to t= hat >>> version, and the server can then perform in-band version change to v1, = to >>> another of these versions, or just keep the client's version for the li= fe >>> of this connection. This will cause ossifying middleboxes to break thes= e >>> connections. >>> >>> >>> >>> Thoughts? >>> >>> >>> >>> David >>> >>> >>> >>> On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon wrote: >>> >>> My fear/experience around this is why I'd strongly recommend doing a >>> QUIC V2 as soon as possible where the delta from V1 -> V2 is limited to >>> *solely* what is necessary for version negotiation. >>> >>> We can simultaneously have a V3 conversation which would include >>> whatever else we decide we need to change/add as a separate conversatio= n >>> which depends on V2. >>> >>> -=3DR >>> >>> On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" < >>> quic-bounces@ietf.org on behalf of mt@lowentropy.net> wrote: >>> >>> On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote: >>> > 1) Version. I can't think of any immediate negative consequences >>> for a >>> > middlebox that drops any long header with a version > 1. TLS 1.3 >>> had to >>> > surrender to this problem by hiding the version elsewhere. >>> > >>> > We might avoid this by routinely coalescing long headers with >>> random >>> > version fields to connection-critical packets. Beyond that, I'm >>> out of >>> > great ideas. If we don't have a robust defense against this, we >>> ought to >>> > put some thought into how to deploy a v2 if the version fields is >>> > inoperable. >>> >>> As Mike points out, the Length field is version-specific, so there >>> is no real defense here other than - as many have suggested - using the >>> version field actively. That means shipping another version. In a sen= se, >>> the fact that Google are still not on the same version gives us some ti= me, >>> but it could mean that we might want to look toward having the "add ver= sion >>> negotiation and fallback protection" draft define a version rather than= an >>> extension. >>> >>> > 2) Client Transport Parameters. Initial Keys will help a little >>> bit, but in >>> > TLS1.3 CCS still sorta exists because middleboxes are inspecting >>> packets so >>> > deeply. It's not viable for v2 to have the same transport >>> parameters; it's >>> > only slightly less gross to send v2 client TPs in some later >>> message and >>> > have to send a fairly bulky "fake" set of v1 TPs in the client >>> hello to get >>> > through the network. >>> >>> I'm not concerned about transport parameters if the above issue is >>> fixed. TLS had no real issues with extensions, and it looks like we >>> already have the start of a pipeline of extensions coming. v2 can shar= e >>> the transport parameter extension, unless we decide to change the forma= t in >>> a non-compatible way. >>> >>> (Note: CCS in TLS 1.3 only exists because middleboxes were >>> inspecting a lot, yes, but it also indicates that they weren't inspecti= ng >>> enough, because the compatibility hack we have wouldn't work if they di= d a >>> proper job.) >>> >>> >>> --0000000000006c6cb20581c9b706 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fa= hn=C3=B8e J=C3=B8rgensen <mikkelfj= @gmail.com> wrote:
There is = the risk that middle boxes learn that versions mean nothing, and that they = are all the same, akin to crying wolf.

I tend to = agree with this. Version numbers should shift when the interoperability amo= ng parties to the protocol shifts.=C2=A0 While you can artificially create = that shift in closed system, teaching the ecosystem that the shifts are mea= ningless doesn't seem to advance the general goal.

Ted

=C2=A0
If it also mutated trans= port parameters and other observables, it would start being a defence.

Alas, once 1.0 = hits, things are back to normal.
So I doubt this exercise would be worthwhile.

But, I don=E2=80=99t have any strong opinion.

On 13 February 20= 19 at 17.56.47, Ian Swett (ianswett=3D40google.com@dmarc.ietf.org) wro= te:

Previously David Benjamin suggested spinning a new version of QUIC in Chrome for every Chrome milestone with the only change being the version number and the Initial keys.=C2=A0 I'd be curious how the WG feels about that idea?

On Wed, Feb 13, 2019 at 11:17 AM Martin Duke <martin.h.duke@gmail.com> wrote:
I agree that a fast v2 would help here. However, it's hard to count on a fast IETF process, and even then the middlebox can be pretty dumb and still drop version > 2.

I agree that David's scheme, by having the Initial be a v1 packet, may get that one through. But then you have subsequent long headers with the new version, which may still end badly.

I don't see a good solution here, right now. Although it shouldn't be written in the spec, the working group should have some sort of contingency plan for how to proceed if the version field ossifies.

On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon <fenix@fb= ..com> wrote:

I don=E2=80=99t have an opinion on how version is negotiated yet.
I=E2=80=99m not convinced it is easy to get right. It may be more correct for me to say that I=E2=80=99m convinced it is reasonable difficult to get right because it is the most important of the various invariants.

I also suspect that you need more than one way to do it, e.g. in-band and out-of-band (which could be in-band in a V2 to allow for upgrade to something else). Then does a client cache the version? For how long/where? Per IP? Hostname? (blah blah.. etc. etc.)

I can say that the ALPN and NPN approaches each had their positives and negatives, and in the end, having something like either is probably good enough.

Rather than an opinion on how it should be done, I have an opinion that we need to add this soon, as a V2.

-=3DR

=C2=A0

From:<= /span> David Schinazi <dschinazi.ietf@= gmail.com>
Date: Tuesday, February 12, 2019 at 4:13 PM
To: Roberto Peon <fenix@fb.com>
Cc: Martin Thomson <mt@lowentropy.net>, "quic@ietf.org" <quic@ietf.org>= ;
Subject: Re: QUIC ossification

=C2=A0

I think we may be able to limit ossification of version numbers by adding some GREASE to the (upcoming) in-band compatible version upgrade extension (what used to be EKR's PR). The idea of that extension is that the client sends a QUICv1 initial containing a transport parameter indicating it supports this extension and what versions of QUIC it supports. The server can then send its replies with a new QUIC version number. Back to GREASE: one option here would be for us to burn some versions for "v1 compatible version negotiation greasing" (similar but differe= nt to=C2=A00x?a?a?a?a) and servers can in-band upgrade to those versions. But we could also do that in the reverse direction: the servers advertise support for one of these in Alt-Svc and clients send their Initial to that version, and the server can then perform in-band version change to v1, to another of these versions, or just keep the client's version for the life of this connection. This will cause ossifying middleboxes to break these connections.

=C2=A0

Thoughts?

=C2=A0

David

=C2=A0

On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <fenix@fb.com> = wrote:

My fear/experience around this is why I'd strongly recommend doing a QUIC V2 as soon as possible where the delta from V1 -> V2 is limited to *solely* what is necessary for version negotiation.

We can simultaneously have a V3 conversation which would=C2=A0 include whatever else we decide we need to change/add as a separate conversation which depends on V2.

-=3DR

On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <quic-bounces= @ietf.org on behalf of mt@lowentropy.net> wrote:

=C2=A0 =C2=A0 On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote:
=C2=A0 =C2=A0 > 1) Version. I can't think of any immediate negative consequences for a
=C2=A0 =C2=A0 > middlebox that drops any long header with a version > 1. TLS 1.3 had to
=C2=A0 =C2=A0 > surrender to this problem by hiding the version elsewhere.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We might avoid this by routinely coalescing long headers with random
=C2=A0 =C2=A0 > version fields to connection-critical packets. Beyond that, I'm out of
=C2=A0 =C2=A0 > great ideas. If we don't have a robust defense against this, we ought to
=C2=A0 =C2=A0 > put some thought into how to deploy a v2 if the version fields is
=C2=A0 =C2=A0 > inoperable.

=C2=A0 =C2=A0 As Mike points out, the Length field is version-specific, so there is no real defense here other than - as many have suggested - using the version field actively.=C2=A0 That means shipping another version.=C2=A0 In a sense, the fact that Google are still not on the same version gives us some time, but it could mean that we might want to look toward having the "add version negotiation and fallback protection" draft define a version rather than an extension.

=C2=A0 =C2=A0 > 2) Client Transport Parameters. Initial Keys will help a little bit, but in
=C2=A0 =C2=A0 > TLS1.3 CCS still sorta exists because middleboxes are inspecting packets so
=C2=A0 =C2=A0 > deeply. It's not viable for v2 to have the same transport parameters; it's
=C2=A0 =C2=A0 > only slightly less gross to send v2 client TPs in some later message and
=C2=A0 =C2=A0 > have to send a fairly bulky "fake" set of v1 T= Ps in the client hello to get
=C2=A0 =C2=A0 > through the network.

=C2=A0 =C2=A0 I'm not concerned about transport parameters if the above issue is fixed.=C2=A0 TLS had no real issues with extensions, and it looks like we already have the start of a pipeline of extensions coming.=C2=A0 v2 can share the transport parameter extension, unless we decide to change the format in a non-compatible way.

=C2=A0 =C2=A0 (Note: CCS in TLS 1.3 only exists because middleboxes were inspecting a lot, yes, but it also indicates that they weren't inspecting enough, because the compatibility hack we have wouldn't work if they did a proper job.)


--0000000000006c6cb20581c9b706-- From nobody Wed Feb 13 09:28:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0C4130E6E for ; Wed, 13 Feb 2019 09:28:30 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxb_qajImOW8 for ; Wed, 13 Feb 2019 09:28:28 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120D3130E69 for ; Wed, 13 Feb 2019 09:28:28 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gtyKc-0003tQ-Go for quic@ietf.org; Wed, 13 Feb 2019 18:28:25 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gtyKW-0007Il-Up for quic@ietf.org; Wed, 13 Feb 2019 12:28:21 -0500 Received: (qmail 3666 invoked from network); 13 Feb 2019 17:28:15 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Feb 2019 17:28:14 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-5F153DC7-6AD0-41D0-A95E-DEB0342BA718 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Wed, 13 Feb 2019 07:28:11 -1000 Cc: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Roberto Peon , David Benjamin , Martin Thomson , Ian Swett , David Schinazi , "quic@ietf.org" , Martin Duke Content-Transfer-Encoding: 7bit Message-Id: <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> To: Ted Hardie Subject: Re: QUIC ossification X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.21) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5iwGE3iHBjJxVMwAjcmM0yp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVihMzZXIjroi7Vz3oVD5FaUc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBpxvnk7PJGygctl3LC86inx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaIRAGcxrXh6p78nNqdl8fWv5nvmah7oAQX1Q8bvqOef6xGPEExqYyyy 76sahQMSRKVqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+RA1ehb6HWONF4LFnY3FB8iDg5/bq7ChmPMN Ycw1QSmRJ7h2aIvhti8a039iil7t/uVVX0AgnCbdBdNmvfXDyuhm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhih19I4GlR3I7yPSC6eTb8vy+NTKQHNkjJg8xvPcdYB8XrwJaVYn9nnZjaUrj DGzQ2f27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 17:28:31 -0000 --Apple-Mail-5F153DC7-6AD0-41D0-A95E-DEB0342BA718 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How about an IANA registry of version numbers, tied to the extension process= ? -- Christian Huitema=20 > On Feb 13, 2019, at 7:17 AM, Ted Hardie wrote: >=20 >> On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >=20 >> There is the risk that middle boxes learn that versions mean nothing, and= that they are all the same, akin to crying wolf. >>=20 > I tend to agree with this. Version numbers should shift when the interoper= ability among parties to the protocol shifts. While you can artificially cr= eate that shift in closed system, teaching the ecosystem that the shifts are= meaningless doesn't seem to advance the general goal. >=20 > Ted >=20 > =20 >> If it also mutated transport parameters and other observables, it would s= tart being a defence. >>=20 >> Alas, once 1.0 hits, things are back to normal. >> So I doubt this exercise would be worthwhile. >>=20 >> But, I don=E2=80=99t have any strong opinion. >>=20 >>> On 13 February 2019 at 17.56.47, Ian Swett (ianswett=3D40google.com@dmar= c.ietf.org) wrote: >>>=20 >>> Previously David Benjamin suggested spinning a new version of QUIC in Ch= rome for every Chrome milestone with the only change being the version numbe= r and the Initial keys. I'd be curious how the WG feels about that idea? >>>=20 >>>> On Wed, Feb 13, 2019 at 11:17 AM Martin Duke w= rote: >>>> I agree that a fast v2 would help here. However, it's hard to count on a= fast IETF process, and even then the middlebox can be pretty dumb and still= drop version > 2. >>>>=20 >>>> I agree that David's scheme, by having the Initial be a v1 packet, may g= et that one through. But then you have subsequent long headers with the new v= ersion, which may still end badly. >>>>=20 >>>> I don't see a good solution here, right now. Although it shouldn't be w= ritten in the spec, the working group should have some sort of contingency p= lan for how to proceed if the version field ossifies. >>>>=20 >>>>> On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon wrote: >>>>> I don=E2=80=99t have an opinion on how version is negotiated yet. >>>>> I=E2=80=99m not convinced it is easy to get right. It may be more corr= ect for me to say that I=E2=80=99m convinced it is reasonable difficult to g= et right because it is the most important of the various invariants. >>>>>=20 >>>>> I also suspect that you need more than one way to do it, e.g. in-band a= nd out-of-band (which could be in-band in a V2 to allow for upgrade to somet= hing else). Then does a client cache the version? For how long/where? Per IP= ? Hostname? (blah blah.. etc. etc.) >>>>>=20 >>>>> I can say that the ALPN and NPN approaches each had their positives an= d negatives, and in the end, having something like either is probably good e= nough. >>>>>=20 >>>>> Rather than an opinion on how it should be done, I have an opinion tha= t we need to add this soon, as a V2. >>>>>=20 >>>>> -=3DR >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: David Schinazi >>>>> Date: Tuesday, February 12, 2019 at 4:13 PM >>>>> To: Roberto Peon >>>>> Cc: Martin Thomson , "quic@ietf.org" >>>>> Subject: Re: QUIC ossification >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I think we may be able to limit ossification of version numbers by add= ing some GREASE to the (upcoming) in-band compatible version upgrade extensi= on (what used to be EKR's PR). The idea of that extension is that the client= sends a QUICv1 initial containing a transport parameter indicating it suppo= rts this extension and what versions of QUIC it supports. The server can the= n send its replies with a new QUIC version number. Back to GREASE: one optio= n here would be for us to burn some versions for "v1 compatible version nego= tiation greasing" (similar but different to 0x?a?a?a?a) and servers can in-b= and upgrade to those versions. But we could also do that in the reverse dire= ction: the servers advertise support for one of these in Alt-Svc and clients= send their Initial to that version, and the server can then perform in-band= version change to v1, to another of these versions, or just keep the client= 's version for the life of this connection. This will cause ossifying middle= boxes to break these connections. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thoughts? >>>>>=20 >>>>> =20 >>>>>=20 >>>>> David >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon wrote: >>>>>=20 >>>>> My fear/experience around this is why I'd strongly recommend doing a Q= UIC V2 as soon as possible where the delta from V1 -> V2 is limited to *sole= ly* what is necessary for version negotiation. >>>>>=20 >>>>> We can simultaneously have a V3 conversation which would include what= ever else we decide we need to change/add as a separate conversation which d= epends on V2. >>>>>=20 >>>>> -=3DR >>>>>=20 >>>>> On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" wrote: >>>>>=20 >>>>> On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote: >>>>> > 1) Version. I can't think of any immediate negative consequences= for a >>>>> > middlebox that drops any long header with a version > 1. TLS 1.3= had to >>>>> > surrender to this problem by hiding the version elsewhere. >>>>> > >>>>> > We might avoid this by routinely coalescing long headers with ra= ndom >>>>> > version fields to connection-critical packets. Beyond that, I'm o= ut of >>>>> > great ideas. If we don't have a robust defense against this, we o= ught to >>>>> > put some thought into how to deploy a v2 if the version fields i= s >>>>> > inoperable. >>>>>=20 >>>>> As Mike points out, the Length field is version-specific, so there= is no real defense here other than - as many have suggested - using the ver= sion field actively. That means shipping another version. In a sense, the f= act that Google are still not on the same version gives us some time, but it= could mean that we might want to look toward having the "add version negoti= ation and fallback protection" draft define a version rather than an extensi= on. >>>>>=20 >>>>> > 2) Client Transport Parameters. Initial Keys will help a little b= it, but in >>>>> > TLS1.3 CCS still sorta exists because middleboxes are inspecting= packets so >>>>> > deeply. It's not viable for v2 to have the same transport parame= ters; it's >>>>> > only slightly less gross to send v2 client TPs in some later mes= sage and >>>>> > have to send a fairly bulky "fake" set of v1 TPs in the client h= ello to get >>>>> > through the network. >>>>>=20 >>>>> I'm not concerned about transport parameters if the above issue is= fixed. TLS had no real issues with extensions, and it looks like we alread= y have the start of a pipeline of extensions coming. v2 can share the trans= port parameter extension, unless we decide to change the format in a non-com= patible way. >>>>>=20 >>>>> (Note: CCS in TLS 1.3 only exists because middleboxes were inspect= ing a lot, yes, but it also indicates that they weren't inspecting enough, b= ecause the compatibility hack we have wouldn't work if they did a proper job= .) >>>>>=20 >>>>>=20 --Apple-Mail-5F153DC7-6AD0-41D0-A95E-DEB0342BA718 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable How about an IANA registry of version numbe= rs, tied to the extension process?

-- Christian Huitema 

On Feb 13, 201= 9, at 7:17 AM, Ted Hardie <ted.ietf= @gmail.com> wrote:

On Wed, Feb 13, 2019 at 9:14 AM Mikk= el Fahn=C3=B8e J=C3=B8rgensen <mikk= elfj@gmail.com> wrote:
There is t= he risk that middle boxes learn that versions mean nothing, and that they ar= e all the same, akin to crying wolf.

I tend to agree= with this. Version numbers should shift when the interoperability among par= ties to the protocol shifts.  While you can artificially create that sh= ift in closed system, teaching the ecosystem that the shifts are meaningless= doesn't seem to advance the general goal.

Ted<= br>

 
If it also mutated transport parameters and o= ther observables, it would start being a defence.

Alas, once 1.0 hits, things are back to n= ormal.
So I= doubt this exercise would be worthwhile.

But, I don=E2= =80=99t have any strong opinion.

On 13 February 2019 at 17.56.47, Ian Swett (ianswett=3D= 40google.com@dmarc.ietf.org) wrote:

Previously David Benjamin suggested spinning a new version of QUIC in Chrome for every Chrome milestone with the only change being the version number and the Initial keys.  I'd be curious how the WG feels about that idea?

On Wed, Feb 13, 2019 at 11:17 AM Martin Duke <martin.h.duke@gmail.com> wrote:
I agree that a fast v2 would help here. However, it's hard to count on a fast IETF process, and even then the middlebox can be pretty dumb and still drop version > 2.

I agree that David's scheme, by having the Initial be a v1 packet, may get that one through. But then you have subsequent long headers with the new version, which may still end badly.

I don't see a good solution here, right now. Although it shouldn't be written in the spec, the working group should have some sort of contingency plan for how to proceed if the version field ossifies.

On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon <fenix@fb.= ..com> wrote:

I don=E2=80=99t have an opinion on how version is negotiated yet.
I=E2=80=99m not convinced it is easy to get right. It may be more correct for me to say that I=E2=80=99m convinced it is reasonable difficult to get right because it is the most important of the various invariants.

I also suspect that you need more than one way to do it, e.g. in-band and out-of-band (which could be in-band in a V2 to allow for upgrade to something else). Then does a client cache the version? For how long/where? Per IP? Hostname? (blah blah.. etc. etc.)

I can say that the ALPN and NPN approaches each had their positives and negatives, and in the end, having something like either is probably good enough.

Rather than an opinion on how it should be done, I have an opinion that we need to add this soon, as a V2.

-=3DR

 

From: David Schinazi <dschinazi.ietf@gma= il.com>
Date: Tuesday, February 12, 2019 at 4:13 PM
To: Roberto Peon <fenix@fb.com>
Cc: Martin Thomson <mt@lowentropy.net>, "quic@ietf.org" <quic@ietf.org>=
Subject: Re: QUIC ossification

 

I think we may be able to limit ossification of version numbers by adding some GREASE to the (upcoming) in-band compatible version upgrade extension (what used to be EKR's PR). The idea of that extension is that the client sends a QUICv1 initial containing a transport parameter indicating it supports this extension and what versions of QUIC it supports. The server can then send its replies with a new QUIC version number. Back to GREASE: one option here would be for us to burn some versions for "v1 compatible version negotiation greasing" (similar but different to 0x?a?a?a?a) and servers can in-band upgrade to those versions. But we could also do that in the reverse direction: the servers advertise support for one of these in Alt-Svc and clients send their Initial to that version, and the server can then perform in-band version change to v1, to another of these versions, or just keep the client's version for the life of this connection. This will cause ossifying middleboxes to break these connections.

 

Thoughts?

 

David

 

On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <fenix@fb.com> w= rote:

My fear/experience around this is why I'd strongly recommend doing a QUIC V2 as soon as possible where the delta from V1 -> V2 is limited to *solely* what is necessary for version negotiation.

We can simultaneously have a V3 conversation which would  include whatever else we decide we need to change/add as a separate conversation which depends on V2.

-=3DR

On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <quic-bounces@= ietf.org on behalf of mt@lowentropy.net> wrote:

    On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote:
    > 1) Version. I can't think of any immediate negative consequences for a
    > middlebox that drops any long header with a version > 1. TLS 1.3 had to
    > surrender to this problem by hiding the version elsewhere.
    >
    > We might avoid this by routinely coalescing long headers with random
    > version fields to connection-critical packets. Beyond that, I'm out of
    > great ideas. If we don't have a robust defense against this, we ought to
    > put some thought into how to deploy a v2 if the version fields is
    > inoperable.

    As Mike points out, the Length field is version-specific, so there is no real defense here other than - as many have suggested - using the version field actively.  That means shipping another version.  In a sense, the fact that Google are still not on the same version gives us some time, but it could mean that we might want to look toward having the "add version negotiation and fallback protection" draft define a version rather than an extension.

    > 2) Client Transport Parameters. Initial Keys will help a little bit, but in
    > TLS1.3 CCS still sorta exists because middleboxes are inspecting packets so
    > deeply. It's not viable for v2 to have the same transport parameters; it's
    > only slightly less gross to send v2 client TPs in some later message and
    > have to send a fairly bulky "fake" set of v1 TPs in the client hello to get
    > through the network.

    I'm not concerned about transport parameters if the above issue is fixed.  TLS had no real issues with extensions, and it looks like we already have the start of a pipeline of extensions coming.  v2 can share the transport parameter extension, unless we decide to change the format in a non-compatible way.

    (Note: CCS in TLS 1.3 only exists because middleboxes were inspecting a lot, yes, but it also indicates that they weren't inspecting enough, because the compatibility hack we have wouldn't work if they did a proper job.)


= --Apple-Mail-5F153DC7-6AD0-41D0-A95E-DEB0342BA718-- From nobody Wed Feb 13 10:02:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E57130DE9 for ; Wed, 13 Feb 2019 10:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7iESRxW7GIJ for ; Wed, 13 Feb 2019 10:02:39 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 BD8A7130E6E for ; Wed, 13 Feb 2019 10:02:38 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id e27so2479702lfj.8 for ; Wed, 13 Feb 2019 10:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nJC5j+ZSp05/Q113Q52n1FnbugBSWfPg0d98RWaH+Qs=; b=XJrnjOyE5tksELaZYG64+6zYWdoIOqwo/GW4Hp5RjFlbbGioBso2xHrmPhXYld7W4m IdN8yVbIpW8oMPnR4rSjI7LPK3R56mp/UXN5Fa840T+D8jdFkB7rLKE0trIMPJI6eNDJ PemdQnGtQD6mSWBG+k94OChOyExHrLH19a90kRLkaZMyPdeRMKyJGNGKhI0xpyn/Yabg YDDRPYl8o9TYUbGhz/ri15Ud1b7RvbsBMKSp0OX7Whg4biybsuqZ4btuvFLZ7jARXBr4 sHE6pj+rX6AP6d73LVf+PUpFdgidjMSNnCgDgaI0NV0sUuHph0FZ95Ij/unJ+PCJTqsL QqKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nJC5j+ZSp05/Q113Q52n1FnbugBSWfPg0d98RWaH+Qs=; b=ul7E1H/XhJCZXfpRgR9+gLsAwWKnzUq4+/9FtFqjivfO3rkCbupnuLteaEcHpW5BAF 0wi2ZVzLrLTxgLqzin7pdg8hl0TdMt8kERr5/oAJasZ1pE5e8tVCZ2sdYisG/QZa3ju5 Qj8Sc4te7p2wqx2XJQbbwHcNaEz/6eSGnkrrhuxLTB1bYU9okZfiEh1eMgNlROfU5YR+ pgCzzDMfy6bxit5dCkGA9ArtUgBNeJUCXTQkRR9n8LJTY0KqEkgkpI3rFwfwq0N0odrk ey9HqcbGCScX0hc4Q9f7vx8RJjYFQ9R6B5icDFnI6bTwXd9aeX1MUyaqR/h2dCjdyjzl s1gA== X-Gm-Message-State: AHQUAuaBkpACAsB6bhQUeyLS+SsjOSm92E+uBt/AuGTRXxwN5Oyp8W8k XQP1I2EQ5yIZFWQ47362AMqBgnxDjhaKL9JdJTUryg== X-Google-Smtp-Source: AHgI3IYcC7jw1MgLUYbR/GmsYMxfKkflRfAVosWJom7lfQQxh91bRrJmhaMkbL4abIP/EZ6L2NuZghE8qILecSrBMiQ= X-Received: by 2002:a19:f249:: with SMTP id d9mr1043781lfk.83.1550080955344; Wed, 13 Feb 2019 10:02:35 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> In-Reply-To: <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> From: Spencer Dawkins at IETF Date: Wed, 13 Feb 2019 12:02:22 -0600 Message-ID: Subject: Re: QUIC ossification To: Christian Huitema Cc: Ted Hardie , Roberto Peon , David Benjamin , Martin Duke , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000b7721e0581ca58be" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 18:02:41 -0000 --000000000000b7721e0581ca58be Content-Type: text/plain; charset="UTF-8" Hi, Christian, On Wed, Feb 13, 2019 at 11:28 AM Christian Huitema wrote: > How about an IANA registry of version numbers, tied to the extension > process? > Asking as an individual - ISTM that QUIC might go through version numbers quickly enough to make a registry for version numbers a Good Thing, but could you help me understand how this helps discourage middleboxes blocking everything but QUICv1? I'm sure I'm missing something here ... Thanks, Spencer --000000000000b7721e0581ca58be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Christian,=C2=A0

On Wed, Feb 13, 2019 at 11:28 AM = Christian Huitema <huitema@huitem= a.net> wrote:
How about an IANA registry of version numbers, tied = to the extension process?

Asking as a= n individual - ISTM that QUIC might go through version numbers quickly enou= gh to make a registry for version numbers a Good Thing, but could you help = me understand how this helps discourage middleboxes blocking everything but= QUICv1?

I'm sure I'm missing=C2=A0somethi= ng here ...

Thanks,

Spenc= er=C2=A0
--000000000000b7721e0581ca58be-- From nobody Wed Feb 13 10:20:53 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCC5129532 for ; Wed, 13 Feb 2019 10:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAgztlA-QXyC for ; Wed, 13 Feb 2019 10:20:50 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CEB128766 for ; Wed, 13 Feb 2019 10:20:49 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gtz9J-0005ue-7q for quic@ietf.org; Wed, 13 Feb 2019 19:20:47 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gtz8l-0001gg-Ta for quic@ietf.org; Wed, 13 Feb 2019 13:20:42 -0500 Received: (qmail 28852 invoked from network); 13 Feb 2019 18:20:10 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Feb 2019 18:20:10 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-DD26C05A-8545-432E-946F-52CE3292A51B Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Wed, 13 Feb 2019 08:18:53 -1000 Cc: Kazuho Oku , Marten Seemann , Ian Swett , IETF QUIC WG , Martin Thomson Content-Transfer-Encoding: 7bit Message-Id: <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Subject: Re: KEYS_READY X-Originating-IP: 168.144.250.245 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.22) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5iwpPlMzY9McWCcnDexe+SB602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi9yycgTaoevOymOS184Cx587i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1XpqFDyTB1Bz0n/bLAAUYB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaJwAHPn4EuYWIk0YD/RIopThgL6QxS4osK9V1p/ZT+2S/2sJzkTPqLX OxynC3d/lOtk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlsTokFnU5zYymx0KpbmN9WVZYSpQQtCkh8qZ SV0LCxteHrovWChlJe1YIblhndLZoDa2wbrUn4GCIjlzEzWJjqUhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uKweW4Es5GC+3P+x9oa7YqbO9UshveVgoiypAicYsWUtd0ktSrwQbrgk6jfwM HIN4qo4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 18:20:52 -0000 --Apple-Mail-DD26C05A-8545-432E-946F-52CE3292A51B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20 > On Feb 13, 2019, at 5:55 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >=20 > The point is that under the rules set by the PR, it is not possible to upd= ate keys before a KEYS_ACTIVE / KEYS_READY frame has been received. If such a= frame is sent, but lost, there is not path to update keys again. This goes w= rong after a (long) while, when the current key is exchausted. > It does not matter that updates are rare.=20 The more I look at it, the more I think that key update / key ready should b= e treated in much the same way as path challenge / path response. Something l= ike: I just updated my key, can you receive it (challenge); yes, you can see= I am using your new key (response). This resolves the debate with ack-or-no= t (not), and also whether the mechanism can be used to delay update ad infin= itum (cannot). If we use the existing path challenge mechanism, we need to add a restrictio= n that responses must be sent in the same epoch. Or we can invent a new one.= -- Christian Huitema=20= --Apple-Mail-DD26C05A-8545-432E-946F-52CE3292A51B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable  

On Feb 13, 2= 019, at 5:55 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

The point is that under the rules set by the PR, it is not possibl= e to update keys before a KEYS_ACTIVE / KEYS_READY frame has been received. I= f such a frame is sent, but lost, there is not path to update keys again. Th= is goes wrong after a (long) while, when the current key is exchausted.
It does not matter= that updates are rare. 

The more I lo= ok at it, the more I think that key update / key ready should be treated in m= uch the same way as path challenge / path response. Something like: I just u= pdated my key, can you receive it (challenge); yes, you can see I am using y= our new key (response). This resolves the debate with ack-or-not (not), and a= lso whether the mechanism can be used to delay update ad infinitum (cannot).=

If we use the existing path challenge mechanism, w= e need to add a restriction that responses must be sent in the same epoch. O= r we can invent a new one.

-- Christian Huitema&nbs= p;
= --Apple-Mail-DD26C05A-8545-432E-946F-52CE3292A51B-- From nobody Wed Feb 13 10:32:49 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6804812DF71 for ; Wed, 13 Feb 2019 10:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=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 KIq_08u19gtl for ; Wed, 13 Feb 2019 10:32:47 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 BBB82129BBF for ; Wed, 13 Feb 2019 10:32:46 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id y184so8186978itc.1 for ; Wed, 13 Feb 2019 10:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=PNRdZCfw7rsqYCl/qqCq2z2E/VK8fvyCKNcwwycf8cE=; b=MMluafXy4T85i+idmXYlLKj7A2qW2RUjFLTIiUw719tKGOh7v0dCL03Xf6JdShqnXI M2Z5IjYcW9Vcw4umVFPNF+D6KhAmYyqxlSRHawxZ/O9w4H6Y9g8YbY4ZEVMTyZTPRBgj VBKDHCFXSQBxwU6oadcuQZBc3VmWhjkLEzsigl2pyKulrJFqp1ONez0/Ci209fmhQJOn w7ynbrDMD8Pspv4+M3F958ZKykkV25YKEytoB5JQtrZNkecT2omic/7usLMRKer+OnFf 6OGgkvF3Q8xflPlZKBF7YMk68MPUl88uzMI3J1UoLOb3SHql8VOPZQmKA/ncWSHiJeIJ Rcxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=PNRdZCfw7rsqYCl/qqCq2z2E/VK8fvyCKNcwwycf8cE=; b=VjpW9+NpPy8DUWrcXXD+PrItniiExy8fe6kL0qEm5yoXjU5WerQKpzf6HhPgZTLqbs XwmBUX28I0ylBW87in+vA5AWcT2EPEYH+ZKHLPCLFenB0L46ASm05EbbtDiDzvKbuE21 V/AzA4yttPQaWXTooLQrxFJtk2exMFNo97sjlPERt2LViLq7GjY398CCljk+unbT6j/2 YVUKYtYbkXcT2CJvyZzXft6gmW+3v+ya0ToBS5+VO46+lXRRnIcRB3U7mmupb1ZFpL7p 8Z5QPsrGeFeM+SHLwpa8Y3P8ePudNEvHP25WVfUDZWCsrAKaMeISo8pPGpna7myrj9kW zH1w== X-Gm-Message-State: AHQUAubGS07PybzSFTVec1Po8J7P7ZQ6RFECAudXVT9+Wyl8idYl5YMM lLfJPPW6kEZlCKe0PAWFavlvf05oQtioCS8NPEA= X-Google-Smtp-Source: AHgI3IbegnWOiW80k5WAgNFld7wGaShakr7hWcc2YsKqhO7HzIUAK3O74k8GuVmFZT/9OVSH7WLCNrXTdmNtu3C2aqc= X-Received: by 2002:a24:4487:: with SMTP id o129mr952727ita.167.1550082766070; Wed, 13 Feb 2019 10:32:46 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Feb 2019 10:32:45 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 13 Feb 2019 10:32:45 -0800 Message-ID: Subject: Re: KEYS_READY To: Christian Huitema Cc: IETF QUIC WG , Marten Seemann , Ian Swett , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000a4e8960581cac49d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 18:32:48 -0000 --000000000000a4e8960581cac49d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 13 February 2019 at 19.20.18, Christian Huitema (huitema@huitema.net) wrote: The more I look at it, the more I think that key update / key ready should be treated in much the same way as path challenge / path response. In a sense, it is a new path if a path in one direction is the 3-tuple: There isn=E2=80=99t strictly a need to separate the concepts. --000000000000a4e8960581cac49d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 13 February 2019 = at 19.20.18, Christian Huitema (huit= ema@huitema.net) wrote:
The more I look at it, the more I think that ke= y update / key ready should be treated in much the same way as path challen= ge / path response.=C2=A0


In a sense, it is a new pat= h if a path in one direction is the 3-tuple: <ip, port, key>=C2=A0

There isn=E2=80=99t strictly a need to separate the concepts.

<= /div> --000000000000a4e8960581cac49d-- From nobody Wed Feb 13 13:53:13 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2EC130DEF for ; Wed, 13 Feb 2019 13:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Sr6Oy7dQ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=NqqE0CHh 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 MVflFcYj5FCi for ; Wed, 13 Feb 2019 13:53:04 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B5213107E for ; Wed, 13 Feb 2019 13:53:03 -0800 (PST) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1DLgdZ7029151; Wed, 13 Feb 2019 13:52:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=56BFoyDDCyYdiQSoOZ1SS4xzu80F9DDai2K2QzVvFqY=; b=Sr6Oy7dQHGvWrEqZ3+gdPYM68uu81RMlsLgy7u/RP9JjHofyBi+h0PqVvQLRgNTA/lbh x+Yp7rgyWVrjlCeU8Qf+h/9+yIRcEafPy65QgTdz0JmFynVopzubYCEHbS4qLYsdylVx Z5qvCouHiez5P13ErsW+365vmtchveXx1Fg= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qmubtg19h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 13:52:49 -0800 Received: from frc-mbx08.TheFacebook.com (192.168.155.29) by frc-hub04.TheFacebook.com (192.168.177.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 13 Feb 2019 13:52:48 -0800 Received: from frc-hub06.TheFacebook.com (192.168.177.76) by frc-mbx08.TheFacebook.com (192.168.155.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 13 Feb 2019 13:52:48 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Wed, 13 Feb 2019 13:52:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=56BFoyDDCyYdiQSoOZ1SS4xzu80F9DDai2K2QzVvFqY=; b=NqqE0CHhvoXMjVWLC0pDHRy/17pDLWAx4KvNHJVSp9TfVSh5Hk44o1DgMKe4rVzdtlut0Ms1AbpwPQ6tXdZnTY4hHcjKCfgKriJ1Y6lclQmx1WtSY8Acp/JsB7aOJG0gM/MKt3A5P9NXLEIVZFoXKsz1vJ61KBczw277A4/7Xao= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2918.namprd15.prod.outlook.com (20.178.236.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Wed, 13 Feb 2019 21:52:46 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084%5]) with mapi id 15.20.1601.023; Wed, 13 Feb 2019 21:52:46 +0000 From: Roberto Peon To: Spencer Dawkins at IETF , Christian Huitema CC: Ted Hardie , David Benjamin , Martin Thomson , Ian Swett , David Schinazi , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , Martin Duke Subject: Re: QUIC ossification Thread-Topic: QUIC ossification Thread-Index: AQHUwxih7UYarYoV30WBSlEhJDleK6Xcr5EA//+EwACAAKdJAP//fAuAgAGRSoCAAArqgIAABPsAgAAA14CAAAMfgIAACY0A//+6QoA= Date: Wed, 13 Feb 2019 21:52:46 +0000 Message-ID: <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::7:55b7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b8cf73df-0ad6-4c50-c9b0-08d691fd96e2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2918; x-ms-traffictypediagnostic: BYAPR15MB2918: x-microsoft-exchange-diagnostics: 1; BYAPR15MB2918; 20:NzJB2AEa/FmVQl+2SLKvlahN5QTeJWGiEZl3UrhB0AaaB0bu5axYV2IG65ps2fLXYL/lzGHYMwU3wS4lr50khtiSWjjqqGSiEN1JGBpuNdNPsEDn7CllrIqju4MpnlI4D4SgKzGNVu+KU/F+1gCq3rX/o/pdmX8/kDL5qT0s9xI= x-microsoft-antispam-prvs: x-forefront-prvs: 094700CA91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(346002)(366004)(39860400002)(189003)(199004)(71200400001)(25786009)(8936002)(97736004)(71190400001)(36756003)(83716004)(229853002)(4326008)(3480700005)(105586002)(236005)(486006)(76176011)(54896002)(6246003)(6306002)(66574012)(93886005)(53936002)(14444005)(256004)(7416002)(54906003)(58126008)(316002)(7116003)(110136005)(6512007)(99286004)(14454004)(106356001)(478600001)(81156014)(6116002)(33656002)(186003)(6506007)(221733001)(6436002)(68736007)(53546011)(46003)(7736002)(2616005)(82746002)(6486002)(476003)(446003)(11346002)(8676002)(81166006)(86362001)(2906002)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2918; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DTOMFpvNbW1tMtv2zbavWniyFq29aHbE9QbSonhZDE3vFFyoSOHYs+F0dMIWI5O9XeKjkE5ZE7sQzoTBbr1poa/ZcNuFoxA5I1Wj2ammMxz5m/LUx2/C5NIV3fUCDbfB8sYtyAsVNnVKLWS7Afc6vgcXp1Jzi/xqNJ3UCwulG2/bRlLrbclPVMvznE1Ob1fP+u6/YP+9kWgsagkCyqxN228Y4S3SUSvm7wzXtZRN2j2hJ1cuCu0lU5Ds6kHD/64CULKPqV6f1hPybDUrN8M80VOLhGf4iUfMA11FfIicfweyCN8BiLwrH63wQiVBXaVXADhzZrUr0vYUbbvs+USKHlrKnUSkWqq3M5if0ZGumEDLl8sQN19nmnggL0RwmzbwMXKhfx2mkSccniOx5Bsyy6zac19uGw5QaIrOiI5DHaA= Content-Type: multipart/alternative; boundary="_000_271E52EDFA3A4B4D978C90CE5CE57053fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b8cf73df-0ad6-4c50-c9b0-08d691fd96e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2019 21:52:46.2831 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2918 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-13_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 21:53:11 -0000 --_000_271E52EDFA3A4B4D978C90CE5CE57053fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmV0dGVyIHRoYXQgdGhleSBoYXZlIHRvIGV4cGxpY2l0bHkgYmxvY2sgdGhhbiB0aGV5IGFjY2lk ZW50YWxseSBibG9jaz8NClJlbWluZGVyOiBUaGlzIGFwcGxpZXMgb25seSB0byBuZXR3b3JrLXZp c2libGUgbmVnb3RpYXRpb25zLg0KLT1SDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRm Lm9yZz4gb24gYmVoYWxmIG9mIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lu cy5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgRmVicnVhcnkgMTMsIDIwMTkgYXQg MTA6MDMgQU0NClRvOiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4NCkNj OiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+LCBSb2JlcnRvIFBlb24gPGZlbml4QGZi LmNvbT4sIERhdmlkIEJlbmphbWluIDxkYXZpZGJlbkBnb29nbGUuY29tPiwgTWFydGluIFRob21z b24gPG10QGxvd2VudHJvcHkubmV0PiwgSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21A ZG1hcmMuaWV0Zi5vcmc+LCBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29t PiwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPiwgInF1aWNA aWV0Zi5vcmciIDxxdWljQGlldGYub3JnPiwgTWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21h aWwuY29tPg0KU3ViamVjdDogUmU6IFFVSUMgb3NzaWZpY2F0aW9uDQoNCkhpLCBDaHJpc3RpYW4s DQoNCk9uIFdlZCwgRmViIDEzLCAyMDE5IGF0IDExOjI4IEFNIENocmlzdGlhbiBIdWl0ZW1hIDxo dWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj4gd3JvdGU6DQpI b3cgYWJvdXQgYW4gSUFOQSByZWdpc3RyeSBvZiB2ZXJzaW9uIG51bWJlcnMsIHRpZWQgdG8gdGhl IGV4dGVuc2lvbiBwcm9jZXNzPw0KDQpBc2tpbmcgYXMgYW4gaW5kaXZpZHVhbCAtIElTVE0gdGhh dCBRVUlDIG1pZ2h0IGdvIHRocm91Z2ggdmVyc2lvbiBudW1iZXJzIHF1aWNrbHkgZW5vdWdoIHRv IG1ha2UgYSByZWdpc3RyeSBmb3IgdmVyc2lvbiBudW1iZXJzIGEgR29vZCBUaGluZywgYnV0IGNv dWxkIHlvdSBoZWxwIG1lIHVuZGVyc3RhbmQgaG93IHRoaXMgaGVscHMgZGlzY291cmFnZSBtaWRk bGVib3hlcyBibG9ja2luZyBldmVyeXRoaW5nIGJ1dCBRVUlDdjE/DQoNCkknbSBzdXJlIEknbSBt aXNzaW5nIHNvbWV0aGluZyBoZXJlIC4uLg0KDQpUaGFua3MsDQoNClNwZW5jZXINCg== --_000_271E52EDFA3A4B4D978C90CE5CE57053fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <946637FD7ACD974F9EF3A933C5B069BB@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDIgMyAzIDIgMjt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmV0dGVy IHRoYXQgdGhleSBoYXZlIHRvIGV4cGxpY2l0bHkgYmxvY2sgdGhhbiB0aGV5IGFjY2lkZW50YWxs eSBibG9jaz88YnI+DQpSZW1pbmRlcjogVGhpcyBhcHBsaWVzIG9ubHkgdG8gbmV0d29yay12aXNp YmxlIG5lZ290aWF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi09 UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UVVJQyAmbHQ7cXVp Yy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgU3BlbmNlciBEYXdraW5zIGF0IElF VEYgJmx0O3NwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5XZWRuZXNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE5IGF0IDEwOjAzIEFNPGJyPg0KPGI+VG86IDwv Yj5DaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8YnI+DQo8Yj5D YzogPC9iPlRlZCBIYXJkaWUgJmx0O3RlZC5pZXRmQGdtYWlsLmNvbSZndDssIFJvYmVydG8gUGVv biAmbHQ7ZmVuaXhAZmIuY29tJmd0OywgRGF2aWQgQmVuamFtaW4gJmx0O2RhdmlkYmVuQGdvb2ds ZS5jb20mZ3Q7LCBNYXJ0aW4gVGhvbXNvbiAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7LCBJYW4g U3dldHQgJmx0O2lhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyZndDssIERhdmlk IFNjaGluYXppICZsdDtkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20mZ3Q7LCBNaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuDQogJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDssICZxdW90O3F1aWNAaWV0 Zi5vcmcmcXVvdDsgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7LCBNYXJ0aW4gRHVrZSAmbHQ7bWFydGlu LmguZHVrZUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBRVUlDIG9zc2lm aWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBDaHJpc3RpYW4sJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxMywgMjAxOSBhdCAxMToy OCBBTSBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVt YS5uZXQiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgYWJv dXQgYW4gSUFOQSByZWdpc3RyeSBvZiB2ZXJzaW9uIG51bWJlcnMsIHRpZWQgdG8gdGhlIGV4dGVu c2lvbiBwcm9jZXNzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bc2tpbmcgYXMgYW4gaW5kaXZpZHVhbCAtIElTVE0g dGhhdCBRVUlDIG1pZ2h0IGdvIHRocm91Z2ggdmVyc2lvbiBudW1iZXJzIHF1aWNrbHkgZW5vdWdo IHRvIG1ha2UgYSByZWdpc3RyeSBmb3IgdmVyc2lvbiBudW1iZXJzIGEgR29vZCBUaGluZywgYnV0 IGNvdWxkIHlvdSBoZWxwIG1lIHVuZGVyc3RhbmQgaG93IHRoaXMgaGVscHMgZGlzY291cmFnZSBt aWRkbGVib3hlcyBibG9ja2luZyBldmVyeXRoaW5nIGJ1dA0KIFFVSUN2MT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHN1cmUgSSdtIG1p c3NpbmcmbmJzcDtzb21ldGhpbmcgaGVyZSAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVuY2VyJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_271E52EDFA3A4B4D978C90CE5CE57053fbcom_-- From nobody Wed Feb 13 14:03:42 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB7A12D861 for ; Wed, 13 Feb 2019 14:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPmpfRHroQB7 for ; Wed, 13 Feb 2019 14:03:37 -0800 (PST) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 CD647128766 for ; Wed, 13 Feb 2019 14:03:36 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id h10so2776277lfc.12 for ; Wed, 13 Feb 2019 14:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2LD4OZYHhpHBFuqWEAloqbK3Fza4ngztsfBqJD3eiRs=; b=Ku5gsk4PTxm4FlBvtuPvoHHhAIYJH5Y8x4nzUvg813AF8kNmCtDqVMr4uT/mpC0DWw yQWGielrWI72DNSCQMmNy07KppJg6DaeRcxK812Bs/lMu2j/ql5tNS+fqK0pRDDGoYfp RXFV6uVFJs0j1M+rThFRaY2LjE+vK11rrqBFvFUL1IvxXNf5Wyb7iomwUKjm74I4kQdI r6stnT+HdJN0/MiFyUoCDSvN/BCJuoJJyKD8GY1ZO9hik/broy60U1eXMkA+OlmzLFei tGJpd2OLNNmV9/0IPBiSTrJJMFCklmUz1F2miHPumWGbQirIYWZfAPhiHgHqqLrone3x jcDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2LD4OZYHhpHBFuqWEAloqbK3Fza4ngztsfBqJD3eiRs=; b=Kn23jXH31C4V216g5bH2eMRzh5YKG0Gd7KPuKT+OHuvQDZ2Oy5kLJp2ENQigE+PF6f vSTONUILC2K9uppiv3PNQmNgxIXic87r+UN75+hofB7hoeir44XO438o555kGnhT7ypX B1ZWTox+0elaDREbqs6RQ/XYeWJQ+nQUDMldC/AVSW0U8KhkImy+7RlxVml/q/ZyLkSe 2LSFTKcbZ35bi2JRsrPXqYKxqmk3YuOUV3IhS4GXeWjUMbr79rfDC92he7zZiPufh94i tQs0GN/+0ydlwgD+qaFLBBJZ8ywKmPrjzjoizo/FNFvuZDWCfA1mCLd2TkgLfLhJOeQU dveQ== X-Gm-Message-State: AHQUAubJzyvQI8057XFgMO8/yvkN1Qw98Yc0gX0BrLItdLlvf/rPtAUJ vk8uokpCw1dJJsUNH/47D2PGgk0dY7e6ny+rX5Y= X-Google-Smtp-Source: AHgI3IYGrro3E1wrcJ+8JIWzE6YoObwKN7kEX9PBVsqbaU8J6hCVwZ89ZTKRfwof7fmcXlq+MCQXh/fUdA0tD0Ms9yY= X-Received: by 2002:a19:4f57:: with SMTP id a23mr237533lfk.46.1550095414697; Wed, 13 Feb 2019 14:03:34 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> In-Reply-To: From: Kazuho Oku Date: Thu, 14 Feb 2019 07:03:23 +0900 Message-ID: Subject: Re: KEYS_READY To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , IETF QUIC WG , Ian Swett , Marten Seemann Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 22:03:40 -0000 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 0:55 Mikkel Fahn=C3=B8e J=C3= =B8rgensen : > > The point is that under the rules set by the PR, it is not possible to up= date keys before a KEYS_ACTIVE / KEYS_READY frame has been received. If suc= h a frame is sent, but lost, there is not path to update keys again. This g= oes wrong after a (long) while, when the current key is exchausted. > It does not matter that updates are rare. I am not sure if that ever happens. The only way to exhaust the key without sending a packet that contain an ACK-eliciting frame is for both endpoints to continue sending packets that just contain non-ACK-eliciting frames, which are ACK, PADDING (and in this case KEY_READY). However, you would never send ACKs in response to ACKs. You would not be sending the other non-ACK-eliciting frames if there is nothing other to send. > > > On 13 February 2019 at 16.48.57, Kazuho Oku (kazuhooku@gmail.com) wrote: > > 2019/02/14 0:29=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > I can see arguments for having the frame defined as ACK-eliciting, > > > It cannot not be ACK-eliciting, otherwise a lost packet could mean that n= o new key updates would be possible. > > > IIUC key updates are rare, and therefore the frame can be non-ack-eliciti= ng. FWIW, the current design does not elicit an ACK in response to key upda= te. > > > > > > On 13 February 2019 at 16.27.02, Kazuho Oku (kazuhooku@gmail.com) wrote: > > 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 0:03 Ian Swett : > > > > I'm happy with the approach you outline here and wrote up in the PR, bu= t I did find the PR a bit confusing, partially because it's based on an exi= sting PR that's gone through a lot of revisions. > > > > I don't think tying transmission of this to an encryption level will be= overly complex, because since it's only a single byte, I might just put it= in every ack-eliciting packet until it's no longer necessary and not use t= he standard retransmission logic. > > I tend to agree, because to me it the same as having a variable length > packet header that, when being extended by one byte, indicates that > the next key is ready. Though it seems a bit flexible. > > OTOH, I think it's interesting to discuss if the KEY_READY frame is > ack-eliciting. My understanding is that per the current PR it is, > because the list of non-ack-eliciting frames has not changed. > > I can see arguments for having the frame defined as ACK-eliciting, > because it encourages endpoints to retire old keys soon. If we think > that to be a good property, I think that might be an argument for > using a frame (because calling a header bit ACK-eliciting would be > strange). > > > > > I'd rather not burn another bit in the first byte for this. > > > > On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann wrote: > >> > >> I went through a few key update scenarios under different packet loss = patterns, and I have to admit that I found the KEY_READY frame surprisingly= difficult to reason about. The problem seems to be that we're replacing wh= at is in reality a contiguous state (it is permitted to update the keys) wi= th a one-time signal, which has to be retransmitted (taking care to either = block further key updates until this frame has been acknowledged, or cancel= ing the retransmission when performing another key update). The reason we d= ecided to create an explicit signal instead of consulting the loss recovery= state, was that we wanted to avoid a tight coupling between the loss recov= ery and the key management. I have the impression that we're now just tradi= ng one tight coupling for a slightly different one. > >> > >> I agree with Kazuho that using a bit in the first byte seems to captur= e the update logic we're looking for better. There's no need to retransmit = any information, since the bit is set on every subsequent packet. > >> > >> > >> > >> On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > >>> > >>> Thanks for pointing out the second alternative, although reluctantly. > >>> > >>> I think the first option with anonymous KEY_READY has a problem with = idempotency as well as tying state to retransmission logic. This means that= naive retransmission of packet content in a new packet number is no longer= valid, and likewise, naive processing of a frame that passes authenticatio= n is also no longer possible. That is a strong principle break and I don=E2= =80=99t think the minor simplicity of a label-less KEY_READY frame can just= ify that (even if one ought no do such naive transmission). > >>> > >>> You could state that the KEY_PHASE bit is the lower bit the key count= er which increments by one on each key update, starting at 0 or 1. > >>> Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an = old count is ignored. The key phase or the packet protection of the packet = containing the KEY_READY frame is of no significance. > >>> > >>> I also suspect that the alternatively two-bit proposal might have a p= roblem with idempotency, but I think it sorts itself by failing packet prot= ection. > >>> > >>> The text mentions that the updated key depends on the current traffic= key with reference to TLS 1.3. From reading this naively, it sounds like f= orward secrecy is lost, which I am sure it is not. > >>> > >>> Finally, this is just a high level view. I find the overall text hard= to understand, notably because it is not crystal clear whether the two end= points update their transmission keys in sync with the ready keys, or if th= e (currently implicity) key phase counters can count independently. > >>> > >>> That said, I like the idea of an explicit READY frame, and i probably= would also like and explicit handshake ready frame, if it isn=E2=80=99t ef= fectively the same thing, and if it is, perhaps formalise that. > >>> > >>> Mikkel > >>> > >>> On 13 February 2019 at 06.55.57, Kazuho Oku (kazuhooku@gmail.com) wro= te: > >>> > >>> Hi, Martin > >>> > >>> Thank you for writing the PR. My comments inline. > >>> > >>> 2019=E5=B9=B42=E6=9C=8813=E6=97=A5(=E6=B0=B4) 10:46 Martin Thomson : > >>> > > >>> > https://github.com/quicwg/base-drafts/pull/2237 has been updated to= include the discussed new frame. > >>> > > >>> > This allows us to remove the implicit-ish acknowledgment of Initial= packets, fix the problem Marten identified with discarding Handshake keys,= and the problem Kazuho found with multiple and simultaneous key updates. > >>> > > >>> > There were two designs that were valid here, and I want to ensure t= hat people think about the choice: > >>> > > >>> > The one I chose to write up uses a design like ACK. The keys used t= o protect the packet determine how the frame is interpreted. That is, KEYS_= READY in a packet implies that the corresponding keys are in use. The cost = here is that you have to purge any potential retransmissions of KEYS_READY = when you update keys or you risk creating a false signal. > >>> > > >>> > The alternative involves more explicit signaling, and requires us t= o label each set of keys unambiguously. > >>> > >>> My weak preference goes to burning a bit in the first byte (we have > >>> reserved bits in all the necessary packet types) due to the > >>> exceptional retransmission rule that we would have for the frame, but > >>> I'm not sure how much I care. > >>> > >>> > For that we could borrow the DTLS epoch convention, though that is = inconveniently out of phase with the Key Phase we use; not a major issue, b= ut a little hard to reason about. This doesn't have a retransmission proble= m, but in addition to the need to document the counting system, we would ne= ed to decide whether a mismatch between frame and packet is OK, or somethin= g that can produce a connection error. > >>> > > >>> > Obviously, I have a preference for the former, but if people feel d= ifferently, this is a good place to register your reasons. > >>> > > >>> > Editorial concerns should be directed toward the pull request. > >>> > > >>> > >>> > >>> -- > >>> Kazuho Oku > >>> > > > -- > Kazuho Oku --=20 Kazuho Oku From nobody Wed Feb 13 14:10:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2201310A1 for ; Wed, 13 Feb 2019 14:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cN-uM5_AsCXv for ; Wed, 13 Feb 2019 14:09:58 -0800 (PST) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 DBBC7130E6E for ; Wed, 13 Feb 2019 14:09:57 -0800 (PST) Received: by mail-lj1-x243.google.com with SMTP id g80so3420047ljg.6 for ; Wed, 13 Feb 2019 14:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mPm33kga4CsdApTMoFqb7lL1khE77C4c1CY0pLAxvRg=; b=Qk08nisdt1pqbpR94Bn/HeoqHg1XE9ewLzbbDbp9kwWuSWRFMKssK8l3e110+JzcpO 0I8ifXZQ0O9JiO8H2hcN3EbkYVEmR8mfBDqF8hh/zEgvJyQ7sYx8IxK5b/sGwpO3w2wM C0/4Vzfl/c9ddai/bj87yu2iJmppO/AQ/KSO6W7IH8NHJysOboVFv6aMv72SEHYPPi4a VTmwzp3qIUNqoA6/iPRpXhtHLmAdXWxGbwZ+JDGQLP1UeaAdiz4/U2WDYYzUcosyrPji N+0LOZVTspW1GWumZH749Y2MRVcvMzGW7+ClU5bnhdkV3dvzVwG857EcLU8GnP5QI5eB hlSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mPm33kga4CsdApTMoFqb7lL1khE77C4c1CY0pLAxvRg=; b=ZLPeSYCxmqs8EFYqasrzp5nOJJ1gkpXqHmktPuPC7qZoMl6wyJU1IpMc3AjU8lvKB2 WC+3HhxlGlcfJpgj75T6lzlKyVijhM4Wx7M5a0FByrhlKXr/bMX6xew6Cddr1TSS69cn Bg1KiTdz3wwR/KBuldM9GWp8ohdPrVYu7wHZ5ftbhMNehH6abkx9Pu+ueL/k0c+PII6c jyHrmT/bN0R8JNh8AcvyQW8u0HFTQeq4bWMXA+HaOCUiyJk2SnoqGdFqHr3WUIYJD2oN g4EdeO0sOsb/dSKKFB56V4lIWiNUgwq/FUlwRtgvJZywKDExoSbqAv0K1g1H6nS1KXkn MgbQ== X-Gm-Message-State: AHQUAuYfsTW4OA6rk0SQNP1BmYjj6q6qhW/L3LGL4esFeCjZH0TdhwdW OLIU2BT99akMsFxcm6/eV/8mnhpk+/a3RrLSfhA= X-Google-Smtp-Source: AHgI3IYCgLHiPNZME/0Ir5dC+JlurqpEvH9rxXzVpjnYoeq8fsIeGMkF7xNrkSBve0cVzqUgcsTK9mjSkuWE2wLH3zo= X-Received: by 2002:a2e:8847:: with SMTP id z7mr197073ljj.99.1550095795952; Wed, 13 Feb 2019 14:09:55 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> In-Reply-To: <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> From: Kazuho Oku Date: Thu, 14 Feb 2019 07:09:45 +0900 Message-ID: Subject: Re: KEYS_READY To: Christian Huitema Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Marten Seemann , Ian Swett , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 22:10:00 -0000 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 3:20 Christian Huitema : > > > > On Feb 13, 2019, at 5:55 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > The point is that under the rules set by the PR, it is not possible to up= date keys before a KEYS_ACTIVE / KEYS_READY frame has been received. If suc= h a frame is sent, but lost, there is not path to update keys again. This g= oes wrong after a (long) while, when the current key is exchausted. > It does not matter that updates are rare. > > > The more I look at it, the more I think that key update / key ready shoul= d be treated in much the same way as path challenge / path response. I am not sure if I like that alternative, primary because it does not seem right as a way to drop Initial, 0-RTT, Handshake keys. We are trying to address two issues at once; how to drop those keys in lower epochs, and how to do key update correctly. The proposed approach of using a frame (or a header bit) to let each side unilaterally declare that it's done with the keys gives us a consistent pattern for switching between the keys. > Something like: I just updated my key, can you receive it (challenge); ye= s, you can see I am using your new key (response). This resolves the debate= with ack-or-not (not), and also whether the mechanism can be used to delay= update ad infinitum (cannot). > > If we use the existing path challenge mechanism, we need to add a restric= tion that responses must be sent in the same epoch. Or we can invent a new = one. > > -- Christian Huitema --=20 Kazuho Oku From nobody Wed Feb 13 14:21:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90C912F295 for ; Wed, 13 Feb 2019 14:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-CZtRxWB3z2 for ; Wed, 13 Feb 2019 14:21:29 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 6C866130DC8 for ; Wed, 13 Feb 2019 14:21:29 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id s5-v6so3407495ljd.12 for ; Wed, 13 Feb 2019 14:21:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6JHTQ3JULzzHd8jYpBDTwPnbJkdQtKPLHu+gUK+77L0=; b=Tmh//6RTkku63VGqOWZYZ3zDX8sAUITy8jRcybfsRyPe37hyPaPhTnvons3ppO1qae mtjUbEQjgG5fgXA7BzT5aYGlJGAYSlDQopbsnGwU7n5a7aE8NpSpNDKrjCtZW6EhiEBa ot+9Y17hbj3L1NocDvRHAH8nDXcxPk3OQ1M4RYjdVXVJDyYPE6wA7S6VD7UzdAeyOPT+ w8Ce18lYV+L9WttOZ4eMBWjRRjBX0sZkFx/mKbylnNm3ZP6rzFh4IetAkP51wclMQNhK T3TPM9cYtVlN2cBUU3bQBQfa1531QOzLdpK8xvutYbb9GCir6hBA7D+Ny/qOpVFoTN9F VhoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6JHTQ3JULzzHd8jYpBDTwPnbJkdQtKPLHu+gUK+77L0=; b=kP8+TV93bUlTLoTtp1xZxutaBIIfmEDLRzYdbA/hybSzUGEB86RJjnDoS0KYKetBQj t+wnXdstBWeypUfv4tHkWKPu2ZznuBVLj7Cv4AsorNG5vqWhn9IWWYwNB+yDr5DytW2T 5xVCsGC43ET5VRWN29WagIJ9AaUziQuYvyH5yc9e4q34dGperKB1iZdzE5jktnxOBxRT kQXq1CZuRRTk21QMmgKPFlCxnPiYRZdFP+L7BZJwq/wrKg8Cqo9GrZfEwrHLHViIYwa7 vwcPHN8Holzd/8kFtCdsGBC40Gw2XbL/qQfQwxNw6Nj07951i33ORUZIYoT1AbsNAuHQ 9sTg== X-Gm-Message-State: AHQUAua8k+vf0jhYA1WIa1ENFVkO8AueCtAXctbxWhfI365+wP2Ig3hn rv9WMcntekMEsfs60MyACZ+e9q6aQczaXqLGA9k= X-Google-Smtp-Source: AHgI3Ib3t/AZk0IHH+VJ7aiAXm+tlfknc783+d/nhYHFlQUEmDG/caGET3HfBgt9vxlTJ3OKAatMgY9GtL3PlhxvOKI= X-Received: by 2002:a2e:7e0f:: with SMTP id z15mr232371ljc.145.1550096487412; Wed, 13 Feb 2019 14:21:27 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> In-Reply-To: <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> From: Spencer Dawkins at IETF Date: Wed, 13 Feb 2019 16:21:13 -0600 Message-ID: Subject: Re: QUIC ossification To: Roberto Peon Cc: Christian Huitema , Ted Hardie , David Benjamin , Martin Thomson , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Duke Content-Type: multipart/alternative; boundary="0000000000007ff9a50581cdf6ce" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 22:21:32 -0000 --0000000000007ff9a50581cdf6ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Roberto, On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon wrote: > Better that they have to explicitly block than they accidentally block? > Well, right, but I'm not sure why someone accidentally blocking (especially QUICv1) is less likely to do that because we created a registry. But I asked Christian a question just before the IAB telechat today, so I should probably wait to give him a chance to explain what he was thinking. Spencer > Reminder: This applies only to network-visible negotiations. > > -=3DR > > > > *From: *QUIC on behalf of Spencer Dawkins at IETF > > *Date: *Wednesday, February 13, 2019 at 10:03 AM > *To: *Christian Huitema > *Cc: *Ted Hardie , Roberto Peon , David > Benjamin , Martin Thomson , Ian > Swett , David Schinazi < > dschinazi.ietf@gmail.com>, Mikkel Fahn=C3=B8e J=C3=B8rgensen , " > quic@ietf.org" , Martin Duke > *Subject: *Re: QUIC ossification > > > > Hi, Christian, > > > > On Wed, Feb 13, 2019 at 11:28 AM Christian Huitema > wrote: > > How about an IANA registry of version numbers, tied to the extension > process? > > > > Asking as an individual - ISTM that QUIC might go through version numbers > quickly enough to make a registry for version numbers a Good Thing, but > could you help me understand how this helps discourage middleboxes blocki= ng > everything but QUICv1? > > > > I'm sure I'm missing something here ... > > > > Thanks, > > > > Spencer > --0000000000007ff9a50581cdf6ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Roberto,=C2=A0

On Wed, Feb 13, 2019 at= 3:52 PM Roberto Peon <fenix@fb.com&= gt; wrote:

Better that they have to explicitly block than they = accidentally block?


Wel= l, right, but I'm not sure why someone accidentally blocking (especiall= y QUICv1) is less likely to do that because we created a registry.=C2=A0

But I asked Christian a question just before the IAB= telechat today, so I should probably wait to give him a chance to explain = what he was thinking.=C2=A0

Spencer
=C2= =A0

Reminder: This applies only to network-visible negotiations.<= /p>

-=3DR

=C2=A0

From: = QUIC <quic-bounces@ietf.org>= ; on behalf of Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Date: Wednesday, February 13, 2019 at 10:03 AM
To: Christian Huitema <huitema@huitema.net>
Cc: Ted Hardie <ted.ietf@gmail.com>, Roberto Peon <fenix@fb.com>, David Benjamin <davidben@google.com&g= t;, Martin Thomson <mt@lowentropy.net>, Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>, David Schinazi <dschinazi.ietf@gmail.com>, Mikkel Fahn=C3=B8e J=C3=B8rg= ensen <mikkelfj@gmail= .com>, "quic= @ietf.org" <= quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>
Subject: Re: QUIC ossification

=C2=A0

Hi, Christian,=C2=A0

=C2=A0

On Wed, Feb 13, 2019 at 11:28 AM Christian Huitema &= lt;huitema@huitema= .net> wrote:

How about an IANA registry of version numbers, tied = to the extension process?

=C2=A0

Asking as an individual - ISTM that QUIC might go th= rough version numbers quickly enough to make a registry for version numbers= a Good Thing, but could you help me understand how this helps discourage m= iddleboxes blocking everything but QUICv1?

=C2=A0

I'm sure I'm missing=C2=A0something here ...=

=C2=A0

Thanks,

=C2=A0

Spencer=C2=A0

--0000000000007ff9a50581cdf6ce-- From nobody Wed Feb 13 15:47:03 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED9B130E57 for ; Wed, 13 Feb 2019 15:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=hXMxmENR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Vyy0EvIL 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 99Xe97jfFgv7 for ; Wed, 13 Feb 2019 15:47:00 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824AF128B01 for ; Wed, 13 Feb 2019 15:47:00 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B419E21E97 for ; Wed, 13 Feb 2019 18:46:59 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 13 Feb 2019 18:46:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:date:in-reply-to:subject; s=fm1; bh=mO1 iwfAZ8dCUB4TVC8qoGZJSRlhU/BS2fm296Sw6P50=; b=hXMxmENRZ43C5ZJlt6O QiYsZ9HSEQZZuMU5qLsUJjO8yJU0iTm5QZdAicgnoVUDkWPP+o90N+zPYfZpCncq hQkgswfBtuZAWxM/yBEaSdEuxNmkmyEM1gn4WldjfKuYSqOigQ6CNC95K/RrCTaL kpEuKHP/mqalmW4sWt07Grd8GDCBP5USEM9cp7rPG5n25A9R/L4kNe/RAS5ajLod FxCxZb5G1eRDUclpLDw32Bn1H+PhMfhsbWFoEfzmkPf2qS9cifH8NuFRgLNJbXj0 /i4BfteQeUQylkds8r9WT25d5H+E4fKnRmbKZIYOcFiwLBrpwWyfLCLNRqnAfHlo onA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=mO1iwfAZ8dCUB4TVC8qoGZJSRlhU/BS2fm296Sw6P 50=; b=Vyy0EvILW4jAhFy3qPd5ZBuuDBVn/gOfR6oVMhS+CL8ULYTpXg3Aks6Dl 4btisIffZxPQxigkqzMA9HYa9r1uo/xvnCt7CZIPZbvxB6dMn0H/3wLubIbjEewt JfYWzkCW2HCDg++O1CM86iqYvdYIdW9kHNOjemOujSu9URJ0OhhfuFVmQHHTXYKr kDzO/Hjc3o+e0fDC4foMuiFnFhj8hgYHd/cZUvH6U80brexjaU+VEF53M/p75ask 6JWeYmPy/QA2JqCRmFlEUCy+gRxXfZ/6eNpYySUbKQHmbunGIBYhVvp3h2T2tBP2 EOJrmxCjkkyl/J3qEmatw8CqJuX3A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtgedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepkffhvfgggfgtofhfffgjufesthhqredtredtjeenucfhrhhomh epofgrrhhtihhnucfvhhhomhhsohhnuceomhhtsehlohifvghnthhrohhphidrnhgvtheq necurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0D4809E54B; Wed, 13 Feb 2019 18:46:59 -0500 (EST) Message-Id: <1550101618.3002483.1657568864.062669F6@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> Date: Thu, 14 Feb 2019 10:46:58 +1100 In-Reply-To: Subject: Re: QUIC ossification Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 23:47:02 -0000 On Thu, Feb 14, 2019, at 04:17, Ted Hardie wrote: > On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: >=20 > > There is the risk that middle boxes learn that versions mean nothing, a= nd > > that they are all the same, akin to crying wolf. >=20 > I tend to agree with this. Version numbers should shift when the > interoperability among parties to the protocol shifts. While you can > artificially create that shift in closed system, teaching the ecosystem > that the shifts are meaningless doesn't seem to advance the general goal. If I understand David's proposal, these versions would have meaningful chan= ges, or at least changes that go beyond the version number. In TLS he has = suggested a similar technique, with changes that are not compatible, but re= latively easy to implement. For instance, changing the salt for the Initia= l keys would be trivial to implement and make the protocol indecipherable. = Switching to ChaCha20-Poly1305 instead of AES-128-GCM would be another. H= e also suggested that we reorder key fields, switch endianness of various e= ncodings, rot13 extension codepoints, ... plus whatever you can imagine. A= s long as it is easier to respond correctly to new versions than it is to b= uild specific handling for every new permutation, the protocol designers wi= n. Now, I'm not sure if that is as good as having a good reason to deploy a ne= w version, but there you are. From nobody Wed Feb 13 17:57:14 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA594130E9B for ; Wed, 13 Feb 2019 17:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2gjb_WVaIhb4 for ; Wed, 13 Feb 2019 17:57:10 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13845130E66 for ; Wed, 13 Feb 2019 17:57:10 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx120.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gu6Gw-000bVe-9u for quic@ietf.org; Thu, 14 Feb 2019 02:57:07 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gu6Gr-0005Vc-1F for quic@ietf.org; Wed, 13 Feb 2019 20:57:05 -0500 Received: (qmail 16272 invoked from network); 14 Feb 2019 01:56:59 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Feb 2019 01:56:59 -0000 To: Spencer Dawkins at IETF , Roberto Peon Cc: Ted Hardie , David Benjamin , Martin Duke , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "quic@ietf.org" , Martin Thomson References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Wed, 13 Feb 2019 15:56:57 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E6E7115F3FD8AA8516077994" Content-Language: en-US Subject: Re: QUIC ossification X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5iz0j6QVlfj9Jw0PRC3NxTh602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVipU999sGTZNHRPEg6SDggMs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1RPScEHpAUegZl9l9jeRl05EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMT7wWCQ1bNVxVHMt1HKpEkC019jkkBafIM3k/pS+1FRKkVpwaURS0vv 9Nw3fqyiE0pk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlsfj3cQFz5QBYZW/yDwrWuVZYSpQQtCkh8qZ SV0LCxtekyKgOoRfp7w4kIFG947ZUbUHAxgNS5IFWjrPSxBvzQIhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK//KzSfzfwEldM3jWkCPmDu9UshveVgoiypAicYsWUtd9a2LHJVD1n7GG0fP 4s+aIo4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 01:57:13 -0000 This is a multi-part message in MIME format. --------------E6E7115F3FD8AA8516077994 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote: > Hi, Roberto,=C2=A0 > > On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon > wrote: > > Better that they have to explicitly block than they accidentally > block? > > > Well, right, but I'm not sure why someone accidentally blocking > (especially QUICv1) is less likely to do that because we created a > registry.=C2=A0 > > But I asked Christian a question just before the IAB telechat today, > so I should probably wait to give him a chance to explain what he was > thinking. OK, back to basics. The middle-boxes will only not do something if it hurts them. Blocking a little guy or blocking some experiment will not hurt them, because there will be few complaints. Blocking Google or some other big site, on the other hand, yes that could hurt -- calls to support line, complaints from ISP who bought the box, etc. So the version will only not ossify if the big players grease it in a meaningful way, or change it frequently. There are two plausible ways there. One would be a "version of the month", with at least a change in the clear text encryption key. The other would be "versions for extensions", tied to for example the negotiation of new transport parameters. In both cases, having something like an IANA registry for the version number would help. -- Christian Huitema --------------E6E7115F3FD8AA8516077994 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote:

Hi, Roberto, 

On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon <fenix@fb.com> wrote:

Better that they have to explicitly block than they accidentally block?


Well, right, but I'm not sure why someone accidentally blocking (especially QUICv1) is less likely to do that because we created a registry. 

But I asked Christian a question just before the IAB telechat today, so I should probably wait to give him a chance to explain what he was thinking.


OK, back to basics. The middle-boxes will only not do something if it hurts them. Blocking a little guy or blocking some experiment will not hurt them, because there will be few complaints. Blocking Google or some other big site, on the other hand, yes that could hurt -- calls to support line, complaints from ISP who bought the box, etc. So the version will only not ossify if the big players grease it in a meaningful way, or change it frequently.

There are two plausible ways there. One would be a "version of the month", with at least a change in the clear text encryption key. The other would be "versions for extensions", tied to for example the negotiation of new transport parameters. In both cases, having something like an IANA registry for the version number would help.

-- Christian Huitema

--------------E6E7115F3FD8AA8516077994-- From nobody Wed Feb 13 18:12:47 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C976D130E8B for ; Wed, 13 Feb 2019 18:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=I5ci4EKI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pQQYjhy1 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 t12TskFgucxz for ; Wed, 13 Feb 2019 18:12:43 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA70124B0C for ; Wed, 13 Feb 2019 18:12:43 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 85FD720EF7; Wed, 13 Feb 2019 21:12:42 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 13 Feb 2019 21:12:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=qG0 wFSjiuDX+xVEQ5bpc5eb/uthBIkMq7NWZMVK0gL0=; b=I5ci4EKIjFQeRrkMqRi tIQWvbOlxGQxiBW6MfJPu8lqGdBYsaH1b+rGjWN4HM47ry3bAGucrjQX5f16y9Q7 k7MgSJqkBrLSeItq1txYw2R3TCjA1sMtMhfH3KVIcWmoMNuI2OAf8o14ysZjJWu1 zgcHmOi722zy8d9kAz1wXLTI1EiEOAM6V8iTedpLKnh/C+h7LejeLzlOkyw8dZrF Mgokptq+bmboyXKLjcUxisZBnpPlgWVxCpHTIgf6LvLvmJ7/fqQbz90qI7F+jmnU WG7dfTt0TEruDP3s35Y4t4DZi8xf9Nr4l/VpE5zqQmGXIRtVCi3etjeIj3g0nT3N O5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=qG0wFSjiuDX+xVEQ5bpc5eb/uthBIkMq7NWZMVK0g L0=; b=pQQYjhy1YBlf25LtKBVHSFrIUrxNIdjMGuIOG4OiaxuiMofSh2zyrkGhx EfikXqi7KFHmSs7yD26/fDSiqW1UqGIZl2y2Ajvz6Wl0dwNLqJF6orR0lk4gH2SZ VsTWwuMwXC2Z3HTEaroDis182TXy5o6LKgM6tUWndm3qaQx+pLc68P1liaZBghhI aC7iJ2/C66F4I/TJBMVOmcbNeCLt/tklgJmpY8Z85Z5IoXo6846/Xbrz1HGdjLpC EdfiLBSUmmaSFd7b3jXcFxy+4LgwXAKHKe2KZjYNOeCIwqe1rIYbhusAcrC6lJmd h/uw6gkRmDFi3TGWWfhZxNvupd3Qg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtgedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg fofhfujgffsehtqhertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcu oehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 17CDF9E54B; Wed, 13 Feb 2019 21:12:42 -0500 (EST) Message-Id: <1550110362.3709205.1657632872.1AF4106B@webmail.messagingengine.com> From: Martin Thomson To: =?utf-8?Q?Mikkel=20Fahn=C3=B8e=20J=C3=B8rgensen?= , Kazuho Oku Cc: IETF QUIC WG MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> Subject: Re: KEYS_READY In-Reply-To: Date: Thu, 14 Feb 2019 13:12:42 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 02:12:45 -0000 On Wed, Feb 13, 2019, at 19:36, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I think the first option with anonymous KEY_READY has a problem with > idempotency as well as tying state to retransmission logic. This means th= at > naive retransmission of packet content in a new packet number is no longer > valid, and likewise, naive processing of a frame that passes authenticati= on > is also no longer possible. That is a strong principle break and I don=E2= =80=99t > think the minor simplicity of a label-less KEY_READY frame can justify th= at > (even if one ought no do such naive transmission). I don't see this is a strong break with principle. Like ACKs, KEYS_ACTIVE/= KEYS_READY is tightly bound to the associated logic. With ACK, it's packet= receipt, here it's the keys you use for protecting/un-protecting packets. = In processing a KEYS_ACTIVE frame, you check what the most recent keys you= have for reading and writing. If they are the same, then you set the "can= key update" flag on. If the read keys are ahead of the write keys, then y= ou have an error. It doesn't require an active connection to the packet pr= otection logic other than that. > The text mentions that the updated key depends on the current traffic key > with reference to TLS 1.3. From reading this naively, it sounds like > forward secrecy is lost, which I am sure it is not. This isn't relevant to this discussion, but I encourage you to read draft-i= rtf-cfrg-re-keying which goes through the various trade-offs of rekeying de= signs. TLS 1.3 has text on this also, and QUIC shares that design. =20 > Finally, this is just a high level view. I find the overall text hard to > understand, notably because it is not crystal clear whether the two > endpoints update their transmission keys in sync with the ready keys, or = if > the (currently implicity) key phase counters can count independently. If you have more specific comments (the one about read keys is a good one),= I'll take those on the PR. =20 > That said, I like the idea of an explicit READY frame, and i probably wou= ld > also like and explicit handshake ready frame, if it isn=E2=80=99t effecti= vely the > same thing, and if it is, perhaps formalise that. We're working on that as the next step. From nobody Wed Feb 13 18:18:14 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2702E130EBE for ; Wed, 13 Feb 2019 18:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dLaGn3C7Vxx for ; Wed, 13 Feb 2019 18:18:11 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC308130EBC for ; Wed, 13 Feb 2019 18:18:10 -0800 (PST) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx61.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gu6Gz-00084X-RV for quic@ietf.org; Thu, 14 Feb 2019 02:57:10 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gu6Gq-0008P7-FK for quic@ietf.org; Wed, 13 Feb 2019 20:57:06 -0500 Received: (qmail 25681 invoked from network); 14 Feb 2019 01:56:59 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Feb 2019 01:56:59 -0000 To: Spencer Dawkins at IETF , Roberto Peon Cc: Ted Hardie , David Benjamin , Martin Duke , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "quic@ietf.org" , Martin Thomson References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> Date: Wed, 13 Feb 2019 15:56:57 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D8C22FC79A62FC6E962EAEE7" Content-Language: en-US Subject: Re: QUIC ossification X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5iz0j6QVlfj9Jw0PRC3NxTh602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi3DsyXGI6CDuL5Op0ypXLE87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBo86SAdJ6bLtg5NStMc8F1x/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaKKIPrZJ10kMvva8ovj3zAHZqY0WkD+XXhBRGrlXn3JpVVbDewYTbm8 UgWuJRzGOHxG047RODDSOAU8VRBdjarRhquvBzKEzdsRbaiLpp7t82t4C4SlaCuF6Oqyplz7a94E pv+Z3RfD+aRmwAVlEJHcERWeKKG4PAQYNyavp7c49NytKwXBULDghWx/HNECYBbSGe3okMCcn14J 4XO+5ud/ncl+SJRnGnqWfLCMPiHIkHVRFtm//SFiue7JeciA1rzRZ4YizZEe9VMcrJA1TtxdruwC 6/RsMQ4p0WvdrKbTQj5uZu6/KnCQVobYDADwqQCbJpStz/eIZMdQBf3zqXbW15Q6CZxYjafGpi3c b03a4ZFy04e73oo5Jp1iUunX3+VlFawbDxpzYifNwA/+CbHA2fz9gpiGyR7D15JIzS+z7i8K8WY4 szo4Gwow0vwlYMfpTQuMHNi5DO10BOGC1ZJT0NaIcaHtK0XZjSPnTTBX4w== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 02:18:13 -0000 This is a multi-part message in MIME format. --------------D8C22FC79A62FC6E962EAEE7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote: > Hi, Roberto,=C2=A0 > > On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon > wrote: > > Better that they have to explicitly block than they accidentally > block? > > > Well, right, but I'm not sure why someone accidentally blocking > (especially QUICv1) is less likely to do that because we created a > registry.=C2=A0 > > But I asked Christian a question just before the IAB telechat today, > so I should probably wait to give him a chance to explain what he was > thinking. OK, back to basics. The middle-boxes will only not do something if it hurts them. Blocking a little guy or blocking some experiment will not hurt them, because there will be few complaints. Blocking Google or some other big site, on the other hand, yes that could hurt -- calls to support line, complaints from ISP who bought the box, etc. So the version will only not ossify if the big players grease it in a meaningful way, or change it frequently. There are two plausible ways there. One would be a "version of the month", with at least a change in the clear text encryption key. The other would be "versions for extensions", tied to for example the negotiation of new transport parameters. In both cases, having something like an IANA registry for the version number would help. -- Christian Huitema --------------D8C22FC79A62FC6E962EAEE7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote:

Hi, Roberto, 

On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon <fenix@fb.com> wrote:

Better that they have to explicitly block than they accidentally block?


Well, right, but I'm not sure why someone accidentally blocking (especially QUICv1) is less likely to do that because we created a registry. 

But I asked Christian a question just before the IAB telechat today, so I should probably wait to give him a chance to explain what he was thinking.


OK, back to basics. The middle-boxes will only not do something if it hurts them. Blocking a little guy or blocking some experiment will not hurt them, because there will be few complaints. Blocking Google or some other big site, on the other hand, yes that could hurt -- calls to support line, complaints from ISP who bought the box, etc. So the version will only not ossify if the big players grease it in a meaningful way, or change it frequently.

There are two plausible ways there. One would be a "version of the month", with at least a change in the clear text encryption key. The other would be "versions for extensions", tied to for example the negotiation of new transport parameters. In both cases, having something like an IANA registry for the version number would help.

-- Christian Huitema

--------------D8C22FC79A62FC6E962EAEE7-- From nobody Wed Feb 13 18:33:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59389130EBE for ; Wed, 13 Feb 2019 18:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjSu_TlGPXr4 for ; Wed, 13 Feb 2019 18:33:17 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 C967D130DE4 for ; Wed, 13 Feb 2019 18:33:16 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id q11so3387022lfd.3 for ; Wed, 13 Feb 2019 18:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8yWT6DvB/jyjwfSpDsYi5EglGfWyP05ciVM/+M8taUQ=; b=IXQ/TV7Xo8cULwP76+jb9ZCGJjwfQFYUhL4mIX54hQA2myQzhj4vkCbSq3Jnp1hBYv tPHOFHLuQhV/WHKrIm91L8rInZPXNB3SPHHPrypKfnOSHufhqiXgQpk23/fhoHoq2g9i 09bHE3iJjTpHpgttDuGEjnnZ9nMam7ljRXf/+33hqFT74ItSSFnLK0EKFR803RO5g+xC hhKj/zEtzuhORZCjshP3pIm1UBZTPc0aPoVE3dLyXrQQH8HAbljorochifDZ0A5sH/lA yXsBaMkg0rzhDygELjEMs2xDHHXeMDD5Uk5M9isb3C87pFIYwRESPuLnaQ+bHnYi2/ST 1SGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8yWT6DvB/jyjwfSpDsYi5EglGfWyP05ciVM/+M8taUQ=; b=i1XS86Rd8pGkODIeF+koxUM1EcPrBU1a3sTkkpEEXyCEFrtNXxMPy/QDh9GPgbO5qX 3G0BUNAQ4AtB8eUFrIh2nD2iwqvCBTb9EKVU06X8K1D/wwOLIqxsPVAk3OQ53F7WSLi2 VlLPxCI9eVGzS21IUgV4dW2Z15nmVmUaQeR5bgUWXtUQ8pJl5OCEO4D1wNJ/1xcXRu/3 rVGgQen2JV9dpOPwmtjuvKhXxyaRZn78QTWreZP4pGjf3HitvnNG83PvB8SjOEErc7Sw mDnmYIK7aDCCMxT4J21eJXeK+NRWtGccBbxmveYKfFt2yHOiHpi6A5ecUs7oqVCVi8lH aEzA== X-Gm-Message-State: AHQUAuYxR1spM7p5mYeXar7O12TqbqMO86EHtXWbL/vz6LaXI5lGNX7X OE2uiQ0UfV6VrKL+wYpimWm77EZwn+O89V+WM+0= X-Google-Smtp-Source: AHgI3Iae8tI08hIu8cFKCXh+PejM8lxKRB/5NYNJaZ36mc85tiWH8B+Tnog+jS3nhtJljxAe1auINnZJEYGSnTLxS2M= X-Received: by 2002:a19:ec0c:: with SMTP id b12mr779438lfa.27.1550111594820; Wed, 13 Feb 2019 18:33:14 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> In-Reply-To: <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> From: Jana Iyengar Date: Wed, 13 Feb 2019 18:33:03 -0800 Message-ID: Subject: Re: QUIC ossification To: Christian Huitema Cc: Spencer Dawkins at IETF , Roberto Peon , Ted Hardie , David Benjamin , Martin Thomson , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Duke Content-Type: multipart/alternative; boundary="000000000000f8bbe00581d17abe" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 02:33:19 -0000 --000000000000f8bbe00581d17abe Content-Type: text/plain; charset="UTF-8" I'm with Martin Duke in that even if we trust the IETF process to produce a v2 quicly (sorry), middleboxes could just as simply do "version == 1 or 2". I agree with Christian that we don't need *everyone* to do this; a few heavy hitters ought to be enough to dissuade middleboxes from ossifying a few versions. I'm intrigued by the "version of the month" idea, which is perhaps similar to David Benjamin's idea of running a QUIC version per Chrome cycle. Perhaps big sites (Google, Facebook, anyone else) could periodically publish their new equivalent versions on a wiki, and clients could keep up with them? Is there a more concrete proposal here? On Wed, Feb 13, 2019 at 6:18 PM Christian Huitema wrote: > On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote: > > Hi, Roberto, > > On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon wrote: > >> Better that they have to explicitly block than they accidentally block? >> > > Well, right, but I'm not sure why someone accidentally blocking > (especially QUICv1) is less likely to do that because we created a > registry. > > But I asked Christian a question just before the IAB telechat today, so I > should probably wait to give him a chance to explain what he was thinking. > > > OK, back to basics. The middle-boxes will only not do something if it > hurts them. Blocking a little guy or blocking some experiment will not hurt > them, because there will be few complaints. Blocking Google or some other > big site, on the other hand, yes that could hurt -- calls to support line, > complaints from ISP who bought the box, etc. So the version will only not > ossify if the big players grease it in a meaningful way, or change it > frequently. > > There are two plausible ways there. One would be a "version of the month", > with at least a change in the clear text encryption key. The other would be > "versions for extensions", tied to for example the negotiation of new > transport parameters. In both cases, having something like an IANA registry > for the version number would help. > > -- Christian Huitema > --000000000000f8bbe00581d17abe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm with Martin Duke in that even if we trust the= IETF process to produce a v2 quicly (sorry), middleboxes could just as sim= ply do "version =3D=3D 1 or 2".

I agree = with Christian that we don't need *everyone* to do this; a few heavy hi= tters ought to be enough to dissuade middleboxes from ossifying a few versi= ons.

I'm intrigued by the "version of the mont= h" idea, which is perhaps similar to David Benjamin's idea of runn= ing a QUIC version per Chrome cycle. Perhaps big sites (Google, Facebook, a= nyone else) could periodically publish their new equivalent versions on a w= iki, and clients could keep up with them?=C2=A0 Is there a more concrete pr= oposal here?



On Wed, Feb 13, 2019 at 6:18 PM Christia= n Huitema <huitema@huitema.net> wrote:
=20 =20 =20

On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote:

Hi, Roberto,=C2=A0

On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon <fenix@fb.com> wrote:

Better that they have to explicitly block than they accidentally block?


Well, right, but I'm not sure why someone accidentally blocking (especially QUICv1) is less likely to do that because we created a registry.=C2=A0

But I asked Christian a question just before the IAB telechat today, so I should probably wait to give him a chance to explain what he was thinking.


OK, back to basics. The middle-boxes will only not do something if it hurts them. Blocking a little guy or blocking some experiment will not hurt them, because there will be few complaints. Blocking Google or some other big site, on the other hand, yes that could hurt -- calls to support line, complaints from ISP who bought the box, etc. So the version will only not ossify if the big players grease it in a meaningful way, or change it frequently.

There are two plausible ways there. One would be a "version of the month", with at least a change in the clear text encryption key. The other would be "versions for extensions", tied to = for example the negotiation of new transport parameters. In both cases, having something like an IANA registry for the version number would help.

-- Christian Huitema

--000000000000f8bbe00581d17abe-- From nobody Wed Feb 13 18:33:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5057130EDC for ; Wed, 13 Feb 2019 18:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=TKeU0CDb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3dO+pcjB 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 BYigiR1bOPR0 for ; Wed, 13 Feb 2019 18:33:27 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A685130EBE for ; Wed, 13 Feb 2019 18:33:27 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C16F52202A for ; Wed, 13 Feb 2019 21:33:26 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 13 Feb 2019 21:33:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:date:in-reply-to:subject; s=fm1; bh=+5R IYKdzYlqCwu3DVz/0aqgF3djtT33vUEvhC4KKka8=; b=TKeU0CDbIMD2fCNXhWp HK0HMCsb9x2dUEuXicSfk6ic8/PTC6gAL8lN8NoSMzX5E6xxhyip3fiJ3LzMKdIl HDY+vPLm5QkjiNF7iUDNqE6P3z7DCqrY/aOBu6mQIB8HWSrECx7BYx0ELnfSdPst qTmMRku8HnC0uTuauHqUrf22VOgAbKTUwLpWlgY20eEgNcgJ06w1VgU3aQcrIR51 L7UlPH6geECLSY//EN4wsRzW03KL2tfi4/lZsnCW9CHYOIo2BKH0iEWTy/IfjClY 17M+WV2L9L7lcMXpZO5LR5s7uh6ucx8/tFYDVn2Qtv9PKKjfsnVT4bajd7+lxkUU 69Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=+5RIYKdzYlqCwu3DVz/0aqgF3djtT33vUEvhC4KKk a8=; b=3dO+pcjBRfg4EBtRs/npFaYQhDRKb2pEt5nGlCNl+j5qaH2ZUEwnbnkcq IxEWW0Jyg3jpdKy+5DmXiVZ0pFHMDa0C4M5VFOCx0l8x3GqYECzFMyujZBToEWEl Jtfjvq4KVM1OR5bkgTxwWah/C9gvBnC6KHwl9zMYKHcmhu2hOCXFB9abMjx/nl6T tz/Ms7PwQe2JK3W2xeabF7uK4seVuaLUr8vh6DEJy/DU8yN/iL5oM2wn7gFkdukB epOPaE3M2vpGA5GTd99Eee8QSI7V2KXkSTSqlFgq8BtMgaIhUmyYLbMvVmiIbKHZ 4SIymlYNH1Y73pNlml8dpgAaXS5KA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtgedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepkffhvfgggfgtofhfffgjufesthhqredtredtjeenucfhrhhomh epofgrrhhtihhnucfvhhhomhhsohhnuceomhhtsehlohifvghnthhrohhphidrnhgvtheq necurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 616B09E560; Wed, 13 Feb 2019 21:33:26 -0500 (EST) Message-Id: <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> Date: Thu, 14 Feb 2019 13:33:26 +1100 In-Reply-To: Subject: Re: KEYS_READY Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 02:33:36 -0000 A few different responses... On Wed, Feb 13, 2019, at 23:59, Marten Seemann wrote: > I agree with Kazuho that using a bit in the first byte seems to capture t= he > update logic we're looking for better. There's no need to retransmit any > information, since the bit is set on every subsequent packet. I was OK with that PR, and while we might go back and forth on the merits o= f using a bit vs. a frame, the consensus in Tokyo was that the frame was su= perior. Also, this solves more problems. On Thu, Feb 14, 2019, at 02:48, Kazuho Oku wrote: > IIUC key updates are rare, and therefore the frame can be non-ack- > eliciting. FWIW, the current design does not elicit an ACK in response=20 > to key update. I used the opposite logic. Key updates are rare and therefore eliciting an= acknowledgment does not cost much. It's one packet per update. The inter= esting thing there is that you guarantee that KEYS_ACTIVE frame is sent, so= maybe the text about not sending it until you have something to send is no= t needed. On Thu, Feb 14, 2019, at 09:09, Kazuho Oku wrote: > 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 3:20 Christian Huitema : > > The more I look at it, the more I think that key update / key ready sho= uld be treated in much the same way as path challenge / path response. >=20 > I am not sure if I like that alternative, primary because it does not > seem right as a way to drop Initial, 0-RTT, Handshake keys. We are > trying to address two issues at once; how to drop those keys in lower > epochs, and how to do key update correctly. The test we are looking for is whether a peer can read packets with a parti= cular key. You can test easily if they can write packets with a key becaus= e you receive a packet protected with that key. PATH_CHALLENGE/PATH_RESPONSE have baggage, so I don't want to use those. A= new challenge/response could work, but it doesn't offer much over a simple= assertion (which is what the proposed frame is). If the assertion is wron= g, then the consequence is a broken connection, so there isn't much incenti= ve to get this wrong. PATH_CHALLENGE/PATH_RESPONSE contain a field that pr= otects against lying, because there are scenarios in which lying provides a= dvantage (that is, the "DoS this IP please" case). From nobody Wed Feb 13 19:47:55 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634AF130F14 for ; Wed, 13 Feb 2019 19:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1es0cJ3ogTuD for ; Wed, 13 Feb 2019 19:47:51 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE79130F09 for ; Wed, 13 Feb 2019 19:47:51 -0800 (PST) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gu804-00098A-Cf for quic@ietf.org; Thu, 14 Feb 2019 04:47:49 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gu801-0004e6-DA for quic@ietf.org; Wed, 13 Feb 2019 22:47:46 -0500 Received: (qmail 29148 invoked from network); 14 Feb 2019 03:47:39 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Feb 2019 03:47:39 -0000 To: Martin Thomson , quic@ietf.org References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Wed, 13 Feb 2019 17:47:39 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: KEYS_READY X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.18) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ii5tbt9ncC05lZKnbLhn3J602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViq1Kx8IzxB2ZrTB4t4qoymc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1XpqFDyTB1Bz0n/bLAAUYB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaJwAHPn4EuYWIk0YD/RIopThgL6QxS4osK9V1p/ZT+2S9tRFnrZQ/50 ksa6WmbF54Fk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAliWlQbBThxwZFUQHKWb8B+lZYSpQQtCkh8qZ SV0LCxteNORmWdEXNhZyY5p+WDt6v/irC7690T0MBN+AjJwGMtYhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK04vW75yGJIA4He1K6wlrze9UshveVgoiypAicYsWUtdCDRZgQnFYkq0SOLr mvxpF44cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 03:47:53 -0000 On 2/13/2019 4:33 PM, Martin Thomson wrote: > PATH_CHALLENGE/PATH_RESPONSE have baggage, so I don't want to use those= =2E A new challenge/response could work, but it doesn't offer much over = a simple assertion (which is what the proposed frame is). If the asserti= on is wrong, then the consequence is a broken connection, so there isn't = much incentive to get this wrong. PATH_CHALLENGE/PATH_RESPONSE contain a= field that protects against lying, because there are scenarios in which = lying provides advantage (that is, the "DoS this IP please" case). Yes, I can see the logic behind that. I like the challenge/response because it has a clean state machine behind hit: send a challenge, expect a response, if the response does not come, repeat the challenge, if it still does not come, give up the path. The combination of the phase change and the KEY ACTIVE frame is not so clean. The phase change plays the same role as the challenge and the frame plays the same role as the response, but there is no way to repeat the challenge if the response is not received: the peer has to wait for the diligence and good will of the other peer. Of course, if the KEY ACTIVE frame requires an acknowledgement, it should arrive eventually. But what if it doesn't? What if the peer did not send it, or did not correctly retransmit it? Should the endpoint just abort the connection if some number of RTO pass after the phase change, and the KEY ACTIVE frame has not been received yet? Does the behavior change if some traffic encrypted with the new phase has been acknowledged? -- Christian Huitema From nobody Wed Feb 13 19:54:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACEA130F1B for ; Wed, 13 Feb 2019 19:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94hi-Pk29rg1 for ; Wed, 13 Feb 2019 19:54:44 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 8B711130F1D for ; Wed, 13 Feb 2019 19:54:44 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id m1so4777515wml.2 for ; Wed, 13 Feb 2019 19:54:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zq5iI9BZ/rAoU6n8RrwB/YhsbRFMqMqJrqoo/0mY7aI=; b=MLQe1I1XoiZjCbuWta2pWIVpEdUethPU2/KI1AMPXvAdqaIpCxYRj0IH/ANssVbtQQ HtpjswmcuPr3J4dafy9gzHfxgIOXc6Gkb94x8XhjLCwX/IRKuesOdKl9gdPwsVHGcJTT n80FkCC0oqsXWZZTIGVmr+A7R24AOSTQfJXvyaUBrYjIBsHrxrQGeAY77waIlwlsPjHj E3IbveY6y/IkVL/RGEt8oqf+d4RQW9WhZcFfl1h6rSCiOI9PLNr4eJQSmIxrZT6Gowwd Hn7QjW918UmMJNwCUCjX8yOL6mZRGXZXk6v7efSvSvNkWeW/LxdbsGV+FpZYCDzMBJST qw3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zq5iI9BZ/rAoU6n8RrwB/YhsbRFMqMqJrqoo/0mY7aI=; b=T+Xcwlq7JQVsWDtl5ke9fXudFZVvJ6UEJ4Ke7CLY+2S/MJQiqKRcsFE5e2TjIFFRDK DEzsx7WwNBQR/EqPmJaQvVdeUr+kxcFwJS6DczCkuAom/NfaWA6h/BUtOptOSRN9KMpX KmKdllgNidLosuFzA3AyppxTGvDUfPTn0CaGIgKXSNlVmWyYGjgy/V7pbLIFaFKsPE7g Di+JMSaTcbwUeUzAqDRT6uViwdUTnSBfKUc9bbYee5XgGaLWq2CgBxXAkRB80luvlZxJ TZ9DBKpFOwpWgGYNldhzJ80XYRGt2SEpR17LTuPvt0qru3TC8CQhR+6bv9FUv5SZwMeW qrOA== X-Gm-Message-State: AHQUAubDkByk/w+MZxgLDL0GewFojtxx0lSOKhfxdqJQDAi6ju8jPvw+ HMCvkYq9zo046ZHMVqw2y9xxi5v0yEKzW1y85D0= X-Google-Smtp-Source: AHgI3IYuL/uTpwPGhvsiEFFr9bTzBAunGLBAlCu5GIfAIpvVQltDNEp/t9Nwt8CX3vZz7rzAFIZBIx93PvxQBBNmEg0= X-Received: by 2002:a7b:c359:: with SMTP id l25mr881216wmj.130.1550116482851; Wed, 13 Feb 2019 19:54:42 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> In-Reply-To: From: Martin Duke Date: Wed, 13 Feb 2019 19:54:30 -0800 Message-ID: Subject: Re: QUIC ossification To: Jana Iyengar Cc: Christian Huitema , Spencer Dawkins at IETF , Roberto Peon , Ted Hardie , David Benjamin , Martin Thomson , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" Content-Type: multipart/alternative; boundary="00000000000052299c0581d29e75" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 03:54:48 -0000 --00000000000052299c0581d29e75 Content-Type: text/plain; charset="UTF-8" Just to close the loop on the transport parameter concern: changing the salt probably solves the problem. You can't read the TPs unless the implementer has processed the new version document. I like how the version # discussion is progressing, please keep at it. On Wed, Feb 13, 2019, 6:33 PM Jana Iyengar I'm with Martin Duke in that even if we trust the IETF process to produce > a v2 quicly (sorry), middleboxes could just as simply do "version == 1 or > 2". > > I agree with Christian that we don't need *everyone* to do this; a few > heavy hitters ought to be enough to dissuade middleboxes from ossifying a > few versions. > > I'm intrigued by the "version of the month" idea, which is perhaps similar > to David Benjamin's idea of running a QUIC version per Chrome cycle. > Perhaps big sites (Google, Facebook, anyone else) could periodically > publish their new equivalent versions on a wiki, and clients could keep up > with them? Is there a more concrete proposal here? > > > > On Wed, Feb 13, 2019 at 6:18 PM Christian Huitema > wrote: > >> On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote: >> >> Hi, Roberto, >> >> On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon wrote: >> >>> Better that they have to explicitly block than they accidentally block? >>> >> >> Well, right, but I'm not sure why someone accidentally blocking >> (especially QUICv1) is less likely to do that because we created a >> registry. >> >> But I asked Christian a question just before the IAB telechat today, so I >> should probably wait to give him a chance to explain what he was thinking. >> >> >> OK, back to basics. The middle-boxes will only not do something if it >> hurts them. Blocking a little guy or blocking some experiment will not hurt >> them, because there will be few complaints. Blocking Google or some other >> big site, on the other hand, yes that could hurt -- calls to support line, >> complaints from ISP who bought the box, etc. So the version will only not >> ossify if the big players grease it in a meaningful way, or change it >> frequently. >> >> There are two plausible ways there. One would be a "version of the >> month", with at least a change in the clear text encryption key. The other >> would be "versions for extensions", tied to for example the negotiation of >> new transport parameters. In both cases, having something like an IANA >> registry for the version number would help. >> >> -- Christian Huitema >> > --00000000000052299c0581d29e75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to close the loop on the transport parameter concern= : changing the salt probably solves the problem. You can't read the TPs= unless the implementer has processed the new version document.

I like how the version # discussion is pr= ogressing, please keep at it.

On Wed, Feb 13, 2019, 6:33 PM Jana Iyengar <jri.ietf@gmail.com wrote:
I'm with Martin Duke in that e= ven if we trust the IETF process to produce a v2 quicly (sorry), middleboxe= s could just as simply do "version =3D=3D 1 or 2".

=
I agree with Christian that we don't need *everyone* to do t= his; a few heavy hitters ought to be enough to dissuade middleboxes from os= sifying a few versions.

I'm intrigued by the "= version of the month" idea, which is perhaps similar to David Benjamin= 's idea of running a QUIC version per Chrome cycle. Perhaps big sites (= Google, Facebook, anyone else) could periodically publish their new equival= ent versions on a wiki, and clients could keep up with them?=C2=A0 Is there= a more concrete proposal here?



On Wed, Feb 13, 2019= at 6:18 PM Christian Huitema <huitema@huitema.net> wrote:
=20 =20 =20

On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote:

Hi, Roberto,=C2=A0

On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon <fenix@fb.com> wrote:

Better that they have to explicitly block than they accidentally block?


Well, right, but I'm not sure why someone accidentally blocking (especially QUICv1) is less likely to do that because we created a registry.=C2=A0

But I asked Christian a question just before the IAB telechat today, so I should probably wait to give him a chance to explain what he was thinking.


OK, back to basics. The middle-boxes will only not do something if it hurts them. Blocking a little guy or blocking some experiment will not hurt them, because there will be few complaints. Blocking Google or some other big site, on the other hand, yes that could hurt -- calls to support line, complaints from ISP who bought the box, etc. So the version will only not ossify if the big players grease it in a meaningful way, or change it frequently.

There are two plausible ways there. One would be a "version of the month", with at least a change in the clear text encryption key. The other would be "versions for extensions", tied to = for example the negotiation of new transport parameters. In both cases, having something like an IANA registry for the version number would help.

-- Christian Huitema

--00000000000052299c0581d29e75-- From nobody Wed Feb 13 20:00:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B26130F44 for ; Wed, 13 Feb 2019 20:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNfIXLipArWk for ; Wed, 13 Feb 2019 20:00:19 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 230BD1295D8 for ; Wed, 13 Feb 2019 20:00:19 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id y185so3312832wmd.1 for ; Wed, 13 Feb 2019 20:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AgowFZ/+uB0+VEQak54uTSxr4Ns8jdYDfQrG6h0abHk=; b=ILXTiHLRrNAROgiKlpPkK9EeJT4wLSG+JOMXNno5bE4YvWWbFsfC2kXBcvDKRKDMNq ZFjBNmQ/SoYI1dlbWF8fWvrtem2HE6o61x2SUv5einr/xao/QTNU2c5H52Ut9FNfWVsN gOK1Bno/AGwcZvjuTgvOU9JgqGvp77w/4sxpbm3N0jU4HZ9sCl+vAQ7FIIdpPbnP2voM zsLtveIotLzFCn4hDZPHw7YpDQ9Zs+ivZKMltjj0XylPqUqfwfyOj+zJRHFKiTW4xx04 iglMKv3oG1jkjJOkYxLDp+tpPMAilZVUcFZnWXkQ7KSbx1eX4yEkXck5m2GrC5sLVAdX r5KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AgowFZ/+uB0+VEQak54uTSxr4Ns8jdYDfQrG6h0abHk=; b=d7GVgKSwsLEwQx0k4zZQ1DbLmt8cUT0oaVn58ocJCL6VPccjINUwm3AB3d7vV9UN0O nAGUZrpEns22oRinpkUXxax5/WuplIABqVOxHCbvXIC1oqLM/kBO8C1dE0ofoagUzRQf kxhpbZvMxUENBq3o1926HVYmUJISw/H1X+9jGoTjqN9sHuZny/ruOxo3XGqdrAAjnnaM uqPYAYdBmbZfnNCkz4+neHHwu1R0hWD9EwDwSm/wnRhe1rIbXSH34lmparAXK5p0xCbO 8q5GdF5bGxKgGd25MP0S6rkEEemU0lRxwsXfNQ00KaSyTu/3iMjQ3b16Z0re+/EPrFD1 TLbw== X-Gm-Message-State: AHQUAuZ1KbePHtCm0X2Dy+K10jUK5loqCiCt/gFG2JzyNu39skaKVTYv wLTtF5m5VMt15vA15qd6Q6aQkrp1e1gSWxHyo34= X-Google-Smtp-Source: AHgI3Ibbw/HghxQA/SSSyXl1TPY3kj3qijE5VM2OoztqMuTAz9jlyha5Bhp7l9sZdGxtg8tEcUXV4yU8MQtP4bl/RWk= X-Received: by 2002:a1c:27c6:: with SMTP id n189mr862601wmn.108.1550116817457; Wed, 13 Feb 2019 20:00:17 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> In-Reply-To: From: Martin Duke Date: Wed, 13 Feb 2019 20:00:05 -0800 Message-ID: Subject: Re: QUIC ossification To: Jana Iyengar Cc: Christian Huitema , Spencer Dawkins at IETF , Roberto Peon , Ted Hardie , David Benjamin , Martin Thomson , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" Content-Type: multipart/alternative; boundary="00000000000043d6300581d2b296" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 04:00:22 -0000 --00000000000043d6300581d2b296 Content-Type: text/plain; charset="UTF-8" Would it make sense for "version of the month" to have essentially random version numbers, rather than have them increase monotonically? Similarly, setting aside IANA, is it sufficient for big players to accept ANY version in the short term and treat it as v1, and also have their clients propose totally random versions? On Wed, Feb 13, 2019, 7:54 PM Martin Duke Just to close the loop on the transport parameter concern: changing the > salt probably solves the problem. You can't read the TPs unless the > implementer has processed the new version document. > > I like how the version # discussion is progressing, please keep at it. > > On Wed, Feb 13, 2019, 6:33 PM Jana Iyengar >> I'm with Martin Duke in that even if we trust the IETF process to produce >> a v2 quicly (sorry), middleboxes could just as simply do "version == 1 or >> 2". >> >> I agree with Christian that we don't need *everyone* to do this; a few >> heavy hitters ought to be enough to dissuade middleboxes from ossifying a >> few versions. >> >> I'm intrigued by the "version of the month" idea, which is perhaps >> similar to David Benjamin's idea of running a QUIC version per Chrome >> cycle. Perhaps big sites (Google, Facebook, anyone else) could periodically >> publish their new equivalent versions on a wiki, and clients could keep up >> with them? Is there a more concrete proposal here? >> >> >> >> On Wed, Feb 13, 2019 at 6:18 PM Christian Huitema >> wrote: >> >>> On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote: >>> >>> Hi, Roberto, >>> >>> On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon wrote: >>> >>>> Better that they have to explicitly block than they accidentally block? >>>> >>> >>> Well, right, but I'm not sure why someone accidentally blocking >>> (especially QUICv1) is less likely to do that because we created a >>> registry. >>> >>> But I asked Christian a question just before the IAB telechat today, so >>> I should probably wait to give him a chance to explain what he was >>> thinking. >>> >>> >>> OK, back to basics. The middle-boxes will only not do something if it >>> hurts them. Blocking a little guy or blocking some experiment will not hurt >>> them, because there will be few complaints. Blocking Google or some other >>> big site, on the other hand, yes that could hurt -- calls to support line, >>> complaints from ISP who bought the box, etc. So the version will only not >>> ossify if the big players grease it in a meaningful way, or change it >>> frequently. >>> >>> There are two plausible ways there. One would be a "version of the >>> month", with at least a change in the clear text encryption key. The other >>> would be "versions for extensions", tied to for example the negotiation of >>> new transport parameters. In both cases, having something like an IANA >>> registry for the version number would help. >>> >>> -- Christian Huitema >>> >> --00000000000043d6300581d2b296 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would it make sense for "version of the month" = to have essentially random version numbers, rather than have them increase = monotonically?

Similarly, sett= ing aside IANA, is it sufficient for big players to accept ANY version in t= he short term and treat it as v1, and also have their clients propose total= ly random versions?

On Wed, Feb 13, 2019, 7:54 PM Martin Duke <martin.h.duke@gmail.com wrote:
Just to close the loop on the transport= parameter concern: changing the salt probably solves the problem. You can&= #39;t read the TPs unless the implementer has processed the new version doc= ument.

I like how the version = # discussion is progressing, please keep at it.

On Wed, Feb 13, 2019, 6:33 PM Jana Iyenga= r <jri.ietf@gmail.com wrote:
I'm with Martin Duke in that even if we trust th= e IETF process to produce a v2 quicly (sorry), middleboxes could just as si= mply do "version =3D=3D 1 or 2".

I agree= with Christian that we don't need *everyone* to do this; a few heavy h= itters ought to be enough to dissuade middleboxes from ossifying a few vers= ions.

I'm intrigued by the "version of the mon= th" idea, which is perhaps similar to David Benjamin's idea of run= ning a QUIC version per Chrome cycle. Perhaps big sites (Google, Facebook, = anyone else) could periodically publish their new equivalent versions on a = wiki, and clients could keep up with them?=C2=A0 Is there a more concrete p= roposal here?



On Wed, Feb 13, 2019 at 6:18 PM Christi= an Huitema <huitema@huitema.net> wrote:
=20 =20 =20

On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote:

Hi, Roberto,=C2=A0

On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon <fenix@fb.com> wrote:

Better that they have to explicitly block than they accidentally block?


Well, right, but I'm not sure why someone accidentally blocking (especially QUICv1) is less likely to do that because we created a registry.=C2=A0

But I asked Christian a question just before the IAB telechat today, so I should probably wait to give him a chance to explain what he was thinking.


OK, back to basics. The middle-boxes will only not do something if it hurts them. Blocking a little guy or blocking some experiment will not hurt them, because there will be few complaints. Blocking Google or some other big site, on the other hand, yes that could hurt -- calls to support line, complaints from ISP who bought the box, etc. So the version will only not ossify if the big players grease it in a meaningful way, or change it frequently.

There are two plausible ways there. One would be a "version of the month", with at least a change in the clear text encryption key. The other would be "versions for extensions", tied to = for example the negotiation of new transport parameters. In both cases, having something like an IANA registry for the version number would help.

-- Christian Huitema

--00000000000043d6300581d2b296-- From nobody Wed Feb 13 20:09:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9D6127AC2 for ; Wed, 13 Feb 2019 20:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=XYcpYZ/j; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Rtm6N8EH 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 9pIuSaI2w047 for ; Wed, 13 Feb 2019 20:09:12 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D747129619 for ; Wed, 13 Feb 2019 20:09:12 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3FAC224442; Wed, 13 Feb 2019 23:09:11 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 13 Feb 2019 23:09:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=Pqk b7wh4QlwaU2kaWMNI9FuH3w1dufkFxbM82Fp5fbo=; b=XYcpYZ/jGKpJ5FUBVqk iDC7Vz6cE1ZJhfL3Gbq4rzuDU8ZkuJCjv/qJHyUanzbH118l4inkQnI3Hzu5Yasm t89SI9iPsZr32ZbcAjt7PjhZycVlofIw3orwMFEiPnkN+B5uHphxJBSwlT58J6ky Hn9NxadXUMll+4/9cCjEVUqstwZ4Qqorv5HIeMD/v1u/qFT1w+obCmQl8FWTHUOY qEU46EXZ7dDIyo5wuiox9z8FlR6I8oETtvOvHUq6ywTYPxTBYHKiHall4h+KVo2h c4G6fFIPQliRk0Po3Cj4cE0acZ4i6mJKkeuU9THJDbZO2NhnK7XV6c9la1FEbYts Vog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Pqkb7wh4QlwaU2kaWMNI9FuH3w1dufkFxbM82Fp5f bo=; b=Rtm6N8EHPwUNhPI/15r0bQ+Nre/JNHcF79PwtGDMZ8r9KVCrjC2uF47ch eRiLUuKSw+SeaH7xN/C1paSIzz/0K2EbeD+AAIafWBz4cG9pMXUedcXT3q1FK78l NqD9nbkaTQngBY5YkGAqE94mcB1/mxnz8OhWKfzZchGLrz+Ohi8iFUHZ6UMX1h2W InOgPBdqfwwpNnKXNPpiXARcSKCsdDEFbg839kxP5PYXzxsBH654Oju4MpzJZR2c IvuUV9EI/oki9QxoBYg3uFMirsSX6ttf6+zZ1duAJ+YLpXS7re65kBnlbLxEaGHX 3e/0JH2rnxsnNSlNbQ/pwcwY6B42Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtgedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg fofhfujgffsehtjeertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcu oehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6EDD69E54B; Wed, 13 Feb 2019 23:09:10 -0500 (EST) Message-Id: <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> From: Martin Thomson To: Martin Duke , Jana Iyengar Cc: Christian Huitema , Spencer Dawkins at IETF , Roberto Peon , Ted Hardie , David Benjamin , Ian Swett , David Schinazi , =?utf-8?Q?Mikkel=20Fahn=C3=B8e=20J=C3=B8rgensen?= , quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> Subject: Re: QUIC ossification In-Reply-To: Date: Thu, 14 Feb 2019 15:09:10 +1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 04:09:15 -0000 On Thu, Feb 14, 2019, at 15:00, Martin Duke wrote: > Similarly, setting aside IANA, is it sufficient for big players to accept > ANY version in the short term and treat it as v1, and also have their > clients propose totally random versions? That would (or maybe only could) prevent us from using the version field for anything other than v1. From nobody Wed Feb 13 20:11:54 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEDA129619 for ; Wed, 13 Feb 2019 20:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=sDWsrPjg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nHcBLidO 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 g8b45eUbfmCy for ; Wed, 13 Feb 2019 20:11:51 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E49127AC2 for ; Wed, 13 Feb 2019 20:11:51 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CCF6D24442 for ; Wed, 13 Feb 2019 23:11:50 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 13 Feb 2019 23:11:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:date:subject:references:in-reply-to; s=fm1; bh=PwY ROBFzkW6JNx0i3Xh87lJHGw9pzil6O6Q+aA0Dmq0=; b=sDWsrPjgdtUQad5v1Rg rgPxfikHHS4SZVQF5LF49EJj7fddS9k/BLLnSm/0vleOdoRWKNldkC8Subefi0aq HQyzUB1Y5WVy4kGVeZu1YcDfLwtxUMfqLpXWy4OmFL4/BuMKaZrtbAYlXwWorNEZ bAq/baT7P7VsEBkkdSZTMePC3+YNwuaMw6vEPEX384+b/LmZbDrFE+6KoXgvJzo5 y61yLkc8HQO+ZN1Z8H/RN/hxsg6p73pPlu4TFHONY/jwFK6UxjyfzdX6yi+6CtF7 PizgvFLNGluTDuNduutz5vbvY4tNxyPLrbmoRdqUyjtpYYIy1ZlFfBRFfuS89K2u lQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=PwYROBFzkW6JNx0i3Xh87lJHGw9pzil6O6Q+aA0Dm q0=; b=nHcBLidOFz4O1hP3EMOTbbiFr/KFevFC4eooD3U2VDkjWpxfTksKVk4nl U6m92LdcRKUbXQxzIjCm02BLRKC6IQ5Qkh07bzCLfSdW+WIfn17eJm4B3lfHXmSn E1ep8khNWX/+3/0WHLlLCqQ95Cp8sDOv4C4fcxHehEv6Zq+FvubwDratg+8yS2F+ 1CJRu1i9LqaMQ+moRNeBOocsBmM/VIPdyoIcWZj4Csn3xD/C99aTIkhpL/ipYLoZ mKGuNefxw/0mO2sV5KBEM5ZA1MJTwLAM1VHdfFEf2AVAHf1w0zOWEFnK5rQCj1b8 AIvfqHCGuoTTS5LFb359UV49g+V6Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtgedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepkffhvfgggfgtofffufhfjgesthejredtredtjeenucfhrhhomh epofgrrhhtihhnucfvhhhomhhsohhnuceomhhtsehlohifvghnthhrohhphidrnhgvtheq necurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 348E89E54B; Wed, 13 Feb 2019 23:11:50 -0500 (EST) Message-Id: <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> From: Martin Thomson To: quic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 Date: Thu, 14 Feb 2019 15:11:50 +1100 Subject: Re: KEYS_READY References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> In-Reply-To: Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 04:11:53 -0000 On Thu, Feb 14, 2019, at 14:47, Christian Huitema wrote: > Of course, if the KEY ACTIVE frame requires an acknowledgement, it > should arrive eventually. But what if it doesn't? What if the peer did > not send it, or did not correctly retransmit it? Should the endpoint > just abort the connection if some number of RTO pass after the phase > change, and the KEY ACTIVE frame has not been received yet? Does the > behavior change if some traffic encrypted with the new phase has been > acknowledged? I'm happy leaving this to implementation discretion. There is no clear rule that say when you can treat the absence of the frame as an error, partly because your view of PTO is different than that of your peer. Maybe we can say that if you want to update and can't, you close the connection. That's the usual advice anyway. From nobody Wed Feb 13 20:22:49 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12EA130F6C for ; Wed, 13 Feb 2019 20:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E0IjxgCbk_Y for ; Wed, 13 Feb 2019 20:22:45 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 25591130F62 for ; Wed, 13 Feb 2019 20:22:45 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id s5-v6so3967636ljd.12 for ; Wed, 13 Feb 2019 20:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gAeCVvdpAls+5DSaYDTDAYBPHV1juzMbXnPe2/XLeKQ=; b=CyUFwwdBkuxVnC3A5zLa0zHty9R7dJkVI8lageShf4dZq8GLxwp25oQYkyyS3N1Yuu kwcNk2gtnAX1ichkR4caY9iSp+2MhFuIUvdT8m7pOuWkyTNvm+dgtCArl8QUbxuzKAW+ xn5IPPvR0ZFNnH0qjzB1EhRbX0Ak81632kE/KFXFSY9moCLmUXWUffnqf4sfNRp1PSSb mJYlmeVo59iyAASar0YWKFTxi4+JeHJwLoPiOIZ4V1DUu7Lw/pwPczT7Ynu8FjaTqoax sUqgjK7btegtjl49pRqPOR0L3knwOnseorgLbwGEHWESwgBXU+a+GPMs/7j2dugMTYsK Puqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gAeCVvdpAls+5DSaYDTDAYBPHV1juzMbXnPe2/XLeKQ=; b=c/QADtw+ffKHJFM6vlVRJ2jqcibh6joLiJw+8kQvDISkS4L5EZhPpP2jfT8EUVU5du 5CQoO2AIqbe8EXD9ZlOFdTE19WoujCmeaqE7Jc3c19jdWL1iIdqSYmb+rF7g4PauSrS3 v4tFQG4irMozXgXeUTXvz6fVSj3XBU/Mvmcj0wnj/ktJJOTaKWcD+NZl5vY/gmDA0hUH hvuZcFDD5A99n7oIh1roLosNxUk0uo7YzJ5NdNEkv6UL6EyJV0TzqulGWpHdql1rSUMT JsCa0i5FonhiRxAaWclU449bFM5JtspFSgDIf8mRZFpo/Z4gywoo6GU16hI0OcuWH+Wp uPrA== X-Gm-Message-State: AHQUAuaC5mrTnUlwq+n0B4oCdKQKJmfiRjRPEgrTY2TQEnEcCKbqJHOx PA30OmtlRSU015QQt6pL7iOkUzACUthQYqScLiWOlw== X-Google-Smtp-Source: AHgI3IY89WptN5xJdNWX63U4dfCIwosKZ/DvURAJFlP0ktOFs+HPaklIU0rXtS6bum2PB1KBJ7m6Aw87il5hpfTlqA8= X-Received: by 2002:a2e:8847:: with SMTP id z7mr851986ljj.99.1550118163223; Wed, 13 Feb 2019 20:22:43 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> In-Reply-To: <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> From: Kazuho Oku Date: Thu, 14 Feb 2019 13:22:31 +0900 Message-ID: Subject: Re: KEYS_READY To: Martin Thomson Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 04:22:48 -0000 TL;DR I think that the issue with the PR is that it not only tries to address issue but it changes existing mechanism. It might make sense to consider just fixing the issues. Proposal below. I think there are two concerns regarding the PR. The PR changes how Initial keys are retired. Instead of relying on the delivery of Handshake packets, it relies on the delivery of KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be included in every Handshake packet being sent. There is a risk that Initial keys might not get dropped as early as they are now. The other issue is that an endpoint might never receive a Handshake packet that carries a KEY_ACTIVE frame. This happens packet loss occurs. To accommodate that, the PR states that the delivery of KEY_ACTIVE frame in either a Handshake or a 1-RTT packet signals the disposal of the Initial packet. That's workable, but I think it shows the problem with the approach. KEY_ACTIVE frame does not name the key that is activated. That is causing the strange retransmission rules for the frame. The right approach seems to suggest endpoints to incorporate the frame in every ACK-eliciting packet it sends. This is a logic we have not had so far, and it could be difficult for certain implementations that do not know what it is sending when it starts to build a packet. Considering these two issues, I think it might be worth discussing the following straw-man: * Do not touch how Initial keys are dropped. Use the new frame just to indicate the completion of the handshake and the retirement of the previous generation of 1-RTT keys. * Include the 1-RTT key generation number in the frame, so that ordinary retransmission logic can be used. Note also that the retransmission rule does not need to be aggressive, because we do not use the frame for dropping Initial keys. When the handshake is complete, both endpoints send KEYS_ACTIVE(generation=3D0). That indicates the peer that the peer can drop the Handshake keys, and also that the endpoint is ready to receive a key update. Completion of key update works exactly the same way. When key update is complete, both endpoints send KEY_ACTIVE(generation=3Dprevious_generation), indicating that the peer can drop the 1-RTT keys, and that the endpoint is ready to receive another key update. Regarding the validation of the generation number, I think we can call it a= MAY. 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 11:33 Martin Thomson : > > A few different responses... > > On Wed, Feb 13, 2019, at 23:59, Marten Seemann wrote: > > I agree with Kazuho that using a bit in the first byte seems to capture= the > > update logic we're looking for better. There's no need to retransmit an= y > > information, since the bit is set on every subsequent packet. > > I was OK with that PR, and while we might go back and forth on the merits= of using a bit vs. a frame, the consensus in Tokyo was that the frame was = superior. Also, this solves more problems. > > On Thu, Feb 14, 2019, at 02:48, Kazuho Oku wrote: > > IIUC key updates are rare, and therefore the frame can be non-ack- > > eliciting. FWIW, the current design does not elicit an ACK in response > > to key update. > > I used the opposite logic. Key updates are rare and therefore eliciting = an acknowledgment does not cost much. It's one packet per update. The int= eresting thing there is that you guarantee that KEYS_ACTIVE frame is sent, = so maybe the text about not sending it until you have something to send is = not needed. > > On Thu, Feb 14, 2019, at 09:09, Kazuho Oku wrote: > > 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 3:20 Christian Huitema : > > > The more I look at it, the more I think that key update / key ready s= hould be treated in much the same way as path challenge / path response. > > > > I am not sure if I like that alternative, primary because it does not > > seem right as a way to drop Initial, 0-RTT, Handshake keys. We are > > trying to address two issues at once; how to drop those keys in lower > > epochs, and how to do key update correctly. > > The test we are looking for is whether a peer can read packets with a par= ticular key. You can test easily if they can write packets with a key beca= use you receive a packet protected with that key. > > PATH_CHALLENGE/PATH_RESPONSE have baggage, so I don't want to use those. = A new challenge/response could work, but it doesn't offer much over a simp= le assertion (which is what the proposed frame is). If the assertion is wr= ong, then the consequence is a broken connection, so there isn't much incen= tive to get this wrong. PATH_CHALLENGE/PATH_RESPONSE contain a field that = protects against lying, because there are scenarios in which lying provides= advantage (that is, the "DoS this IP please" case). > --=20 Kazuho Oku From nobody Wed Feb 13 20:24:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873EF130F70 for ; Wed, 13 Feb 2019 20:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0pL5XkNQxL0 for ; Wed, 13 Feb 2019 20:24:39 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 E4D4A130F6A for ; Wed, 13 Feb 2019 20:24:38 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id z25-v6so3994934ljk.7 for ; Wed, 13 Feb 2019 20:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Ay4lN723+d5PfybcQ+wRiCnVpTlmBfRhbi5xmGfEas=; b=iajdpAPk6JYmEdotU5qDilhxB+/DhQJWj2zVJ4XKa8XjGGMYp8PJIafjmyI+XvZPYB e7MY5GIFWTn4NT7Mh35VeQQE2pzbQ4EFsidvFWWUgpZRcT2+WlGpK5YCJ1cxcMKxANYz czj7YFzK1CYwETQZJd2hO8yQwkRgSEFnV4PZ6ho6/Xn5pAufTDDCsMM0XfDfiRIBDH8x wUIK7Vzqhf90wCOVAXNvpsXnkqsMt4q/ko4sg3kUmQQYIqn/31yHKmT1kPp8r+1bnHwH 7Gi5wFbAFUyyWAZNoAtLrN0XAcVmsX5yX1cuBK3vgP1Wng6/IUCrYVEHWU3GJNFf01gM eUtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Ay4lN723+d5PfybcQ+wRiCnVpTlmBfRhbi5xmGfEas=; b=FH+qNuZAWOjKcWWlOBOlaw/zrtc3jyY9QHSgQPH05wHS9W+j5ZGQhwfogqTxlteGKG PR5Pohu0QYGWdmiIlwpsl8sOBDPwBgf6vBrOQxJDUKwXutiPVEpDVI9m75GCX4ZBEgiH +FVDd40Dr1x7CjCCsw37exHXc7hlgIyEvg3ltfYeM7xzAYsyMDiuW0wh5kP/ln+mFmLv NFcrUa99TirHbAK6VJIKUOrC0VWyx/EAnVbHFpoT3qI6deaQ4CRQBoNp6kf6uMrufQpv nIA/Gxu/Yx5xm9ihnMYGywIkY61B3chyon6nMqy7s0UepFMgrqL6mesXVeV5YuIS+rlm ol6w== X-Gm-Message-State: AHQUAuYF9kch5V95VMsdr/WqUjADIWz/E+10CS3YgTXg2iCg8jVMK+cA QfyKoNqs7KUuzNLzPe7LTp++GiztR/OIio1jwfePEQ== X-Google-Smtp-Source: AHgI3IajHvogx2YqmMsjg4XZmxhqptbRzV6recICVJuGXfwwB8YLGZJ0LdV7OlOJbrxPcCHR3HFi/01D+U5Usew7ing= X-Received: by 2002:a2e:3c19:: with SMTP id j25mr939792lja.72.1550118277053; Wed, 13 Feb 2019 20:24:37 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> In-Reply-To: <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> From: Jana Iyengar Date: Wed, 13 Feb 2019 20:24:25 -0800 Message-ID: Subject: Re: KEYS_READY To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="00000000000043836c0581d3099c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 04:24:42 -0000 --00000000000043836c0581d3099c Content-Type: text/plain; charset="UTF-8" On Wed, Feb 13, 2019 at 8:12 PM Martin Thomson wrote: > On Thu, Feb 14, 2019, at 14:47, Christian Huitema wrote: > > Of course, if the KEY ACTIVE frame requires an acknowledgement, it > > should arrive eventually. But what if it doesn't? What if the peer did > > not send it, or did not correctly retransmit it? Should the endpoint > > just abort the connection if some number of RTO pass after the phase > > change, and the KEY ACTIVE frame has not been received yet? Does the > > behavior change if some traffic encrypted with the new phase has been > > acknowledged? > > I'm happy leaving this to implementation discretion. There is no clear > rule that say when you can treat the absence of the frame as an error, > partly because your view of PTO is different than that of your peer. > > Maybe we can say that if you want to update and can't, you close the > connection. That's the usual advice anyway. > (I've left this comment on the PR as well, but seeing that this discussion is happening here as well, echoing it here) If the peer hasn't acked the previous KEYS_ACTIVE, it may not have seen it yet. It is possible that it simultaneously did a key update and sent a KEYS_ACTIVE however. Under this condition, the endpoint wouldn't be able to update its keys again, since the peer may close the connection, right? --00000000000043836c0581d3099c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 13, 2019 at 8:12 PM Martin Th= omson <mt@lowentropy.net> wr= ote:
On Thu, Feb 14, 2019, at 14:47, Christian Huitema wrote: > Of course, if the KEY ACTIVE frame requires an acknowledgement, it
> should arrive eventually. But what if it doesn't? What if the peer= did
> not send it, or did not correctly retransmit it? Should the endpoint > just abort the connection if some number of RTO pass after the phase > change, and the KEY ACTIVE frame has not been received yet? Does the > behavior change if some traffic encrypted with the new phase has been<= br> > acknowledged?

I'm happy leaving this to implementation discretion.=C2=A0 There is no = clear rule that say when you can treat the absence of the frame as an error= , partly because your view of PTO is different than that of your peer.

Maybe we can say that if you want to update and can't, you close the co= nnection.=C2=A0 That's the usual advice anyway.
(I've left this comment on the PR as well, but seeing that= this discussion is happening here as well, echoing it here)
If t= he peer hasn't acked the previous KEYS_ACTIVE, it may not have seen it = yet. It is possible that it simultaneously did a key update and sent a KEYS= _ACTIVE however. Under this condition, the endpoint wouldn't be able to= update its keys again, since the peer may close the connection, right?
=C2=A0
--00000000000043836c0581d3099c-- From nobody Wed Feb 13 20:30:09 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F94130F6A for ; Wed, 13 Feb 2019 20:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlAQ_Hxfq9eH for ; Wed, 13 Feb 2019 20:30:05 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A002130F62 for ; Wed, 13 Feb 2019 20:30:04 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id m11so3514266lfc.6 for ; Wed, 13 Feb 2019 20:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sZLATNn2kBmUtYRRogVQ4DqySdNf6ZQQ0n+5okQ9TPc=; b=ZA2Z3y/iN1BmVyhhH/fpn1Bxn7hXcFhRu9qkYa7gWqQzfHWgXPWK68nnlQ4Cy/R/yz znYNhDsqQ4x9Wpw1VhF4GlqVk3iDj5XSDi1FMVQGR7Dgq0Y0Jse2WpjruSSM0yJLkCDb AVmbxxfLIf9b5wrplOurNVB4cEbYLJnuXTlvjpbQRiQktWgh3G1kF6X5k10vUX4d6ytA mJlwjEAjN1aTuVubOUZKkOfjz+YyggwWIkw3Oz3CiB+E02i6XlgkeBWBxnCEpRRQJ+uX cYuHp9ikvQtDmLtY+FecHIVtvM4zzZzpIIBNDT7Lxpl7VOv/qajOcxC789cNoVhSu/8L ca0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sZLATNn2kBmUtYRRogVQ4DqySdNf6ZQQ0n+5okQ9TPc=; b=F4JKSxwglphto2EPOtdNubxYERF+Va2HI5nhppGLjgiAqYDligNJCgFfC6Vyyf0ToK EkK0SQytkcdZsWrksCT0OewwUiv88qABwkLHHt/a3mNEfyhUJokYPGxoMTiO1k3HLRID iclV6Joz7qZydA7fEIPjcHYtXlnZSXzqHEIDmoggJ/ZDQ5aLsAJePuC5nCkoIJV0AaO/ WWixz5/VWNPtII4EdgiIUGBEeTcpYJIq57j/YrYrJpvONrUvOkO7SxXaNmULn47a0QsW BsJFhUV/cRrKDwwqo/gPF7aBrj/lMXLjwyKWRI54MkBXGFnO7k9BpWlz+e2DnehLK0z/ 5iSA== X-Gm-Message-State: AHQUAuaZmRsVPIEEMOCyaJi4VzinwwF+kNCV6oSsyPn53kouLrKhjJ+B diGBlfDnSrw8ekVAR4U2klPChMOupcYouOTG8KQ= X-Google-Smtp-Source: AHgI3IbHpHXvULCbzGrEM3SoEwvYZd3SfO6STno3q9qxOHUe8hr6hZiGmSgu3R+BbHzkjs0aqxaDk7u7gWW6pIcvB9g= X-Received: by 2002:a19:5013:: with SMTP id e19mr925042lfb.89.1550118602529; Wed, 13 Feb 2019 20:30:02 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> In-Reply-To: From: Jana Iyengar Date: Wed, 13 Feb 2019 20:29:51 -0800 Message-ID: Subject: Re: KEYS_READY To: Kazuho Oku Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000a9de9e0581d31c38" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 04:30:08 -0000 --000000000000a9de9e0581d31c38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2019 at 8:23 PM Kazuho Oku wrote: > TL;DR I think that the issue with the PR is that it not only tries to > address issue but it changes existing mechanism. It might make sense > to consider just fixing the issues. Proposal below. > > I think there are two concerns regarding the PR. > > The PR changes how Initial keys are retired. Instead of relying on the > delivery of Handshake packets, it relies on the delivery of > KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be > included in every Handshake packet being sent. There is a risk that > Initial keys might not get dropped as early as they are now. The other > issue is that an endpoint might never receive a Handshake packet that > carries a KEY_ACTIVE frame. This happens packet loss occurs. To > accommodate that, the PR states that the delivery of KEY_ACTIVE frame > in either a Handshake or a 1-RTT packet signals the disposal of the > Initial packet. That's workable, but I think it shows the problem with > the approach. > > KEY_ACTIVE frame does not name the key that is activated. That is > causing the strange retransmission rules for the frame. The right > approach seems to suggest endpoints to incorporate the frame in every > ACK-eliciting packet it sends. This is a logic we have not had so far, > and it could be difficult for certain implementations that do not know > what it is sending when it starts to build a packet. > > Considering these two issues, I think it might be worth discussing the > following straw-man: > > * Do not touch how Initial keys are dropped. Use the new frame just to > indicate the completion of the handshake and the retirement of the > previous generation of 1-RTT keys. > * Include the 1-RTT key generation number in the frame, so that > ordinary retransmission logic can be used. Note also that the > retransmission rule does not need to be aggressive, because we do not > use the frame for dropping Initial keys. > > When the handshake is complete, both endpoints send > KEYS_ACTIVE(generation=3D0). That indicates the peer that the peer can > drop the Handshake keys, and also that the endpoint is ready to > receive a key update. > > Completion of key update works exactly the same way. When key update > is complete, both endpoints send > KEY_ACTIVE(generation=3Dprevious_generation), indicating that the peer > can drop the 1-RTT keys, and that the endpoint is ready to receive > another key update. > This is a good simplification, I think. I'll note that you still cannot update keys again until you've received an ACK for the previous KEYS_ACTIVE= . > Regarding the validation of the generation number, I think we can call it > a MAY. > What validation? - jana > 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 11:33 Martin Thomson : > > > > A few different responses... > > > > On Wed, Feb 13, 2019, at 23:59, Marten Seemann wrote: > > > I agree with Kazuho that using a bit in the first byte seems to > capture the > > > update logic we're looking for better. There's no need to retransmit > any > > > information, since the bit is set on every subsequent packet. > > > > I was OK with that PR, and while we might go back and forth on the > merits of using a bit vs. a frame, the consensus in Tokyo was that the > frame was superior. Also, this solves more problems. > > > > On Thu, Feb 14, 2019, at 02:48, Kazuho Oku wrote: > > > IIUC key updates are rare, and therefore the frame can be non-ack- > > > eliciting. FWIW, the current design does not elicit an ACK in respons= e > > > to key update. > > > > I used the opposite logic. Key updates are rare and therefore elicitin= g > an acknowledgment does not cost much. It's one packet per update. The > interesting thing there is that you guarantee that KEYS_ACTIVE frame is > sent, so maybe the text about not sending it until you have something to > send is not needed. > > > > On Thu, Feb 14, 2019, at 09:09, Kazuho Oku wrote: > > > 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 3:20 Christian Huitema = : > > > > The more I look at it, the more I think that key update / key ready > should be treated in much the same way as path challenge / path response. > > > > > > I am not sure if I like that alternative, primary because it does not > > > seem right as a way to drop Initial, 0-RTT, Handshake keys. We are > > > trying to address two issues at once; how to drop those keys in lower > > > epochs, and how to do key update correctly. > > > > The test we are looking for is whether a peer can read packets with a > particular key. You can test easily if they can write packets with a key > because you receive a packet protected with that key. > > > > PATH_CHALLENGE/PATH_RESPONSE have baggage, so I don't want to use > those. A new challenge/response could work, but it doesn't offer much ov= er > a simple assertion (which is what the proposed frame is). If the asserti= on > is wrong, then the consequence is a broken connection, so there isn't muc= h > incentive to get this wrong. PATH_CHALLENGE/PATH_RESPONSE contain a fiel= d > that protects against lying, because there are scenarios in which lying > provides advantage (that is, the "DoS this IP please" case). > > > > > -- > Kazuho Oku > > --000000000000a9de9e0581d31c38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 13, 2019 at 8:23 PM Kazuh= o Oku <kazuhooku@gmail.com>= ; wrote:
TL;DR I= think that the issue with the PR is that it not only tries to
address issue but it changes existing mechanism. It might make sense
to consider just fixing the issues. Proposal below.

I think there are two concerns regarding the PR.

The PR changes how Initial keys are retired. Instead of relying on the
delivery of Handshake packets, it relies on the delivery of
KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be
included in every Handshake packet being sent. There is a risk that
Initial keys might not get dropped as early as they are now. The other
issue is that an endpoint might never receive a Handshake packet that
carries a KEY_ACTIVE frame. This happens packet loss occurs. To
accommodate that, the PR states that the delivery of KEY_ACTIVE frame
in either a Handshake or a 1-RTT packet signals the disposal of the
Initial packet. That's workable, but I think it shows the problem with<= br> the approach.

KEY_ACTIVE frame does not name the key that is activated. That is
causing the strange retransmission rules for the frame. The right
approach seems to suggest endpoints to incorporate the frame in every
ACK-eliciting packet it sends. This is a logic we have not had so far,
and it could be difficult for certain implementations that do not know
what it is sending when it starts to build a packet.

Considering these two issues, I think it might be worth discussing the
following straw-man:

* Do not touch how Initial keys are dropped. Use the new frame just to
indicate the completion of the handshake and the retirement of the
previous generation of 1-RTT keys.
* Include the 1-RTT key generation number in the frame, so that
ordinary retransmission logic can be used. Note also that the
retransmission rule does not need to be aggressive, because we do not
use the frame for dropping Initial keys.

When the handshake is complete, both endpoints send
KEYS_ACTIVE(generation=3D0). That indicates the peer that the peer can
drop the Handshake keys, and also that the endpoint is ready to
receive a key update.

Completion of key update works exactly the same way. When key update
is complete, both endpoints send
KEY_ACTIVE(generation=3Dprevious_generation), indicating that the peer
can drop the 1-RTT keys, and that the endpoint is ready to receive
another key update.

This is a good simp= lification, I think.=C2=A0 I'll note that you still cannot update keys = again until you've received an ACK for the previous KEYS_ACTIVE.
<= div>=C2=A0
Regarding the validation of the generation number, I think we can call it a= MAY.

What validation?

- jana
=C2=A0
2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 11:33 Martin Thomson <mt@lowentropy.net>= ;:
>
> A few different responses...
>
> On Wed, Feb 13, 2019, at 23:59, Marten Seemann wrote:
> > I agree with Kazuho that using a bit in the first byte seems to c= apture the
> > update logic we're looking for better. There's no need to= retransmit any
> > information, since the bit is set on every subsequent packet.
>
> I was OK with that PR, and while we might go back and forth on the mer= its of using a bit vs. a frame, the consensus in Tokyo was that the frame w= as superior.=C2=A0 Also, this solves more problems.
>
> On Thu, Feb 14, 2019, at 02:48, Kazuho Oku wrote:
> > IIUC key updates are rare, and therefore the frame can be non-ack= -
> > eliciting. FWIW, the current design does not elicit an ACK in res= ponse
> > to key update.
>
> I used the opposite logic.=C2=A0 Key updates are rare and therefore el= iciting an acknowledgment does not cost much.=C2=A0 It's one packet per= update.=C2=A0 The interesting thing there is that you guarantee that KEYS_= ACTIVE frame is sent, so maybe the text about not sending it until you have= something to send is not needed.
>
> On Thu, Feb 14, 2019, at 09:09, Kazuho Oku wrote:
> > 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 3:20 Christian Huit= ema <huitema@hu= itema.net>:
> > > The more I look at it, the more I think that key update / ke= y ready should be treated in much the same way as path challenge / path res= ponse.
> >
> > I am not sure if I like that alternative, primary because it does= not
> > seem right as a way to drop Initial, 0-RTT, Handshake keys. We ar= e
> > trying to address two issues at once; how to drop those keys in l= ower
> > epochs, and how to do key update correctly.
>
> The test we are looking for is whether a peer can read packets with a = particular key.=C2=A0 You can test easily if they can write packets with a = key because you receive a packet protected with that key.
>
> PATH_CHALLENGE/PATH_RESPONSE have baggage, so I don't want to use = those.=C2=A0 A new challenge/response could work, but it doesn't offer = much over a simple assertion (which is what the proposed frame is).=C2=A0 I= f the assertion is wrong, then the consequence is a broken connection, so t= here isn't much incentive to get this wrong.=C2=A0 PATH_CHALLENGE/PATH_= RESPONSE contain a field that protects against lying, because there are sce= narios in which lying provides advantage (that is, the "DoS this IP pl= ease" case).
>


--
Kazuho Oku

--000000000000a9de9e0581d31c38-- From nobody Wed Feb 13 20:40:49 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2278F130F75 for ; Wed, 13 Feb 2019 20:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82BkSr5VCQyO for ; Wed, 13 Feb 2019 20:40:46 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D462130F70 for ; Wed, 13 Feb 2019 20:40:45 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id z25-v6so4017089ljk.7 for ; Wed, 13 Feb 2019 20:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=f2LvL5hxDeroC7wRwLAnvk3hVjOfM8rSgOGLTjzK8ig=; b=HEtHOLbnv6iEtp+BhR+f3TeGlFKvSTSgjk2zgVPqtx9VSGiJRgHTGxIYRaVuOp8AV9 sGeRMoNmgwMVS/1LCvQwa9axivQTsAcLoTofYDMKNU3LrQUPBpOWDknaPInxliayTET/ jyDR+o8iSxFAA20tkhVJSH3t9/lCobTTg/j8CUgMjZ/C080m7SHkFz8RuBfP0B3BNxKq aq62S5vl8mvUn/YrxU2MprSz8IfaNd54Lu/Hegmav8LqljGy6nJgtFuzMRkjXpNMZ8La 4ThLt/sNFNTEiTnwyL+TxZTjNZxlaeGL3N4GlC7y+vUYUTeU9jZM+9+hDjvvmfoIWx/q 73JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=f2LvL5hxDeroC7wRwLAnvk3hVjOfM8rSgOGLTjzK8ig=; b=Ahqid3Dw4hEEQAXolIgQNtWvyVtFN9QI+aiUs/45j365Af2CB30GJT8tRYBrgsRD97 u3qu6O5ZomATolGl8jqWCGA6V1cvNVx1RwiHaWswG6ZdvHjuWYARBOMOgGSeLqC3BeP8 eSKqgWU8i2iDeICL+05XGRN0OkmHw59mSoGzxReFK1VJ9vSduH3DY+hP9aVCrNvU58Oo UqnJRhHxgyoeFPOy7+5xmVGfs1nU7N9/+0HPgbGFj1YJWxfEN22rJSnXaI/+DcmtQFBj mv7H7TuCSVOm5FlCIhizbN7wQX1f/9nXTLghszbsfz6B5wTOlUT5bYWlQnTRhzeXRtEp PaKw== X-Gm-Message-State: AHQUAuYo5oZFNqTazf17dcoXc3xr0l4+Xu4CaZz5Tn8CTY6hqfue7v5C xCKsVUpOd66F4v8fb41aZftsEEP/e/5vV3o/Exs= X-Google-Smtp-Source: AHgI3IbAAc+R4Klal9qLhWxYrmMrlHKHs23sLblhSFpm9l7Q4tHRpzi/4JISgTbeaIdT4of/sUJWANawzyZDN6KqrQ0= X-Received: by 2002:a2e:380d:: with SMTP id f13-v6mr999875lja.17.1550119243438; Wed, 13 Feb 2019 20:40:43 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> In-Reply-To: From: Kazuho Oku Date: Thu, 14 Feb 2019 13:40:31 +0900 Message-ID: Subject: Re: KEYS_READY To: Jana Iyengar Cc: Martin Thomson , IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 04:40:48 -0000 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 13:30 Jana Iyengar : > > > > On Wed, Feb 13, 2019 at 8:23 PM Kazuho Oku wrote: >> >> TL;DR I think that the issue with the PR is that it not only tries to >> address issue but it changes existing mechanism. It might make sense >> to consider just fixing the issues. Proposal below. >> >> I think there are two concerns regarding the PR. >> >> The PR changes how Initial keys are retired. Instead of relying on the >> delivery of Handshake packets, it relies on the delivery of >> KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be >> included in every Handshake packet being sent. There is a risk that >> Initial keys might not get dropped as early as they are now. The other >> issue is that an endpoint might never receive a Handshake packet that >> carries a KEY_ACTIVE frame. This happens packet loss occurs. To >> accommodate that, the PR states that the delivery of KEY_ACTIVE frame >> in either a Handshake or a 1-RTT packet signals the disposal of the >> Initial packet. That's workable, but I think it shows the problem with >> the approach. >> >> KEY_ACTIVE frame does not name the key that is activated. That is >> causing the strange retransmission rules for the frame. The right >> approach seems to suggest endpoints to incorporate the frame in every >> ACK-eliciting packet it sends. This is a logic we have not had so far, >> and it could be difficult for certain implementations that do not know >> what it is sending when it starts to build a packet. >> >> Considering these two issues, I think it might be worth discussing the >> following straw-man: >> >> * Do not touch how Initial keys are dropped. Use the new frame just to >> indicate the completion of the handshake and the retirement of the >> previous generation of 1-RTT keys. >> * Include the 1-RTT key generation number in the frame, so that >> ordinary retransmission logic can be used. Note also that the >> retransmission rule does not need to be aggressive, because we do not >> use the frame for dropping Initial keys. >> >> When the handshake is complete, both endpoints send >> KEYS_ACTIVE(generation=3D0). That indicates the peer that the peer can >> drop the Handshake keys, and also that the endpoint is ready to >> receive a key update. >> >> Completion of key update works exactly the same way. When key update >> is complete, both endpoints send >> KEY_ACTIVE(generation=3Dprevious_generation), indicating that the peer >> can drop the 1-RTT keys, and that the endpoint is ready to receive >> another key update. > > > This is a good simplification, I think. I'll note that you still cannot = update keys again until you've received an ACK for the previous KEYS_ACTIVE= . We can require that, however it might be simpler to state that receiving a KEY_ACTIVE frame from the peer allows an endpoint to execute a key update. > >> >> Regarding the validation of the generation number, I think we can call i= t a MAY. > > > What validation? In the straw-man, KEY_ACTIVE frame carries the generation number of the 1-RTT key. The value can be anything equal to or less than the current generation number, because the delivery of the frame can be severely delayed (this is the norm for QUIC frames used to communicate a monotonously increasing number; e.g., MAX_STREAMS). However, an endpoint should never receive a KEY_ACTIVE frame containing a generation number that is greater than the generation it has ever used. Endpoints might want to police that. That's the validation I'm referring to. > > - jana > >> >> 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 11:33 Martin Thomson : >> > >> > A few different responses... >> > >> > On Wed, Feb 13, 2019, at 23:59, Marten Seemann wrote: >> > > I agree with Kazuho that using a bit in the first byte seems to capt= ure the >> > > update logic we're looking for better. There's no need to retransmit= any >> > > information, since the bit is set on every subsequent packet. >> > >> > I was OK with that PR, and while we might go back and forth on the mer= its of using a bit vs. a frame, the consensus in Tokyo was that the frame w= as superior. Also, this solves more problems. >> > >> > On Thu, Feb 14, 2019, at 02:48, Kazuho Oku wrote: >> > > IIUC key updates are rare, and therefore the frame can be non-ack- >> > > eliciting. FWIW, the current design does not elicit an ACK in respon= se >> > > to key update. >> > >> > I used the opposite logic. Key updates are rare and therefore eliciti= ng an acknowledgment does not cost much. It's one packet per update. The = interesting thing there is that you guarantee that KEYS_ACTIVE frame is sen= t, so maybe the text about not sending it until you have something to send = is not needed. >> > >> > On Thu, Feb 14, 2019, at 09:09, Kazuho Oku wrote: >> > > 2019=E5=B9=B42=E6=9C=8814=E6=97=A5(=E6=9C=A8) 3:20 Christian Huitema= : >> > > > The more I look at it, the more I think that key update / key read= y should be treated in much the same way as path challenge / path response. >> > > >> > > I am not sure if I like that alternative, primary because it does no= t >> > > seem right as a way to drop Initial, 0-RTT, Handshake keys. We are >> > > trying to address two issues at once; how to drop those keys in lowe= r >> > > epochs, and how to do key update correctly. >> > >> > The test we are looking for is whether a peer can read packets with a = particular key. You can test easily if they can write packets with a key b= ecause you receive a packet protected with that key. >> > >> > PATH_CHALLENGE/PATH_RESPONSE have baggage, so I don't want to use thos= e. A new challenge/response could work, but it doesn't offer much over a s= imple assertion (which is what the proposed frame is). If the assertion is= wrong, then the consequence is a broken connection, so there isn't much in= centive to get this wrong. PATH_CHALLENGE/PATH_RESPONSE contain a field th= at protects against lying, because there are scenarios in which lying provi= des advantage (that is, the "DoS this IP please" case). >> > >> >> >> -- >> Kazuho Oku >> --=20 Kazuho Oku From nobody Wed Feb 13 20:48:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7770C130F75 for ; Wed, 13 Feb 2019 20:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7K-uc6OzLLE for ; Wed, 13 Feb 2019 20:48:15 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 5342B130F70 for ; Wed, 13 Feb 2019 20:48:15 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id j1so3520865lfb.10 for ; Wed, 13 Feb 2019 20:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/LZphzvbuo0Cib/vi4px1XahTk2jDyzBK/wnaMXeQh4=; b=OkSH4I0AQpIYyYMlZUQzgDblPQ0OOmE7qmHTnjkyb9ObzC8YF14a04u00SMuwWX2Uz ov6UcKcCgQGKlISrki6EN84VJ7EF19wrZjfnc+i7yaAeCrniNJ+tI0UC/wmpXmj3e4zi TtHiLtIjCclOi39fa08U7vrnoKzJ2z+6uectRVNxt5LpZDBz4Laa16a6zP/lLOP/em27 jQ5lYz6A3+O6bYh0Bq2cRhlVwSyQeE34gNP/ZvaNTfVYWuJLNFQsWadpNCbIxscrnvkx 2FBUjzEo/hTkL0dwRaMvnRhI2QyZbHo3tAyLl6OjEeWn9Aj/D/K0j+D4T+xhQhGVlhXv Oh1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/LZphzvbuo0Cib/vi4px1XahTk2jDyzBK/wnaMXeQh4=; b=oUKw4MupsuNGGcEen5ktBwZZJNZkct/vnPx/1Kuyx/8zKlkM8rqb7dDEgmAfTMK9ZJ bXnBIsxLARWRJe3yoJEqXkzlvzGoeyQRGdrWtTsCuZkUKYr/1s5AWV5itVTY/StOaHeZ hOO8iuUC/cDpt2SzOUPrfQCyuSTxvs1BA+blIo2AEM2mn64JJOr3kEmiQuv9QoybZMAn aXnMCeHbAF+toGfDyHpRN/egABCKNFwJ4P2u+YNdFmSDBtyO3TtWP3TJJ3eBIdGU3WLh 9WamNjvUfxREvSXZLdvQkYq7suU9ZYrsCppJj6oSrjDny4AImhxvsPZZW9Ba3a/f7kvT XJUQ== X-Gm-Message-State: AHQUAubacH/4iiIMpOFJ4lqbo/keCTr4nSXo2iDFuRAA48nzarf3/Muv 2Et1eK7SrDVen9buaPC7mNetPzstSJK4LG+rViCXug== X-Google-Smtp-Source: AHgI3IaVQ6fIUGval3C0ibEaW+IGj7V59HuC0caGKTJKl86Fs4Bgdljk8TfBxgGyYVgRLX0xvmtOwBKscP5fS2bASrs= X-Received: by 2002:a19:5013:: with SMTP id e19mr958529lfb.89.1550119693274; Wed, 13 Feb 2019 20:48:13 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> In-Reply-To: <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> From: Jana Iyengar Date: Wed, 13 Feb 2019 20:48:02 -0800 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson Cc: Martin Duke , Christian Huitema , Spencer Dawkins at IETF , Roberto Peon , Ted Hardie , David Benjamin , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Content-Type: multipart/alternative; boundary="000000000000ad53150581d35db1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 04:48:18 -0000 --000000000000ad53150581d35db1 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 13, 2019 at 8:09 PM Martin Thomson wrote: > On Thu, Feb 14, 2019, at 15:00, Martin Duke wrote: > > Similarly, setting aside IANA, is it sufficient for big players to accept > > ANY version in the short term and treat it as v1, and also have their > > clients propose totally random versions? > > That would (or maybe only could) prevent us from using the version field > for anything other than v1. Yes, agreed. There's no horizon for how long older versions circulate on the Internet. We can't assign all versions to v1 for the "short term" because we simply can't control when that term ends. I don't think we need to specify how versions are assigned. We just need to ensure that there are no collisions. We can use a wiki or IANA for this. There's a problem this exposes though. v2 is defined as version == 2, and we won't be able to use that for greasing v1. By extension, we won't be able to use the IETF reserved versions. If we're going to do this right, I would suggest that we separate on the wire version numbers from the QUIC (abstract) versions entirely. I know this makes it a bit harder to reason about from looking at packets on the wire, but that's exactly what we're trying to accomplish -- it shouldn't be easy to reason about versions from looking at packets on the wire. Basically, I'm proposing that QUIC v1 be assigned a random number for its version at RFC publication time. IANA can be used to reserve subsequent on-the-wire version numbers for v1. Anyone who wants to use a different version for v1 MUST request it from IANA first before using it in the wild. QUIC v2 will similarly have a random value assigned to it at RFC publication time. --000000000000ad53150581d35db1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 13, 2019 at 8:09 PM Martin Th= omson <mt@lowentropy.net> wr= ote:
On Thu, Feb 14, 2019, at 15:00, Martin Duke wrote:
> Similarly, setting aside IANA, is it sufficient for big players to acc= ept
> ANY version in the short term and treat it as v1, and also have their<= br> > clients propose totally random versions?

That would (or maybe only could) prevent us from using the version field fo= r anything other than v1.

Yes, agreed. Ther= e's no horizon for how long older versions circulate on the Internet. W= e can't assign all versions to v1 for the "short term" becaus= e we simply can't control when that term ends.
I don't th= ink we need to specify how versions are assigned. We just need to ensure th= at there are no collisions. We can use a wiki or IANA for this.

There's a problem this exposes though. v2 is defined = as version =3D=3D 2, and we won't be able to use that for greasing v1. = By extension, we won't be able to use the IETF reserved versions. If we= 're going to do this right, I would suggest that we separate on the wir= e version numbers from the QUIC (abstract) versions entirely. I know this m= akes it a bit harder to reason about from looking at packets on the wire, b= ut that's exactly what we're trying to accomplish -- it shouldn'= ;t be easy to reason about versions from looking at packets on the wire.

Basically, I'm proposing that QUIC v1 be assigne= d a random number for its version at RFC publication time. IANA can be used= to reserve subsequent on-the-wire version numbers for v1. Anyone who wants= to use a different version for v1 MUST request it from IANA first before u= sing it in the wild. QUIC v2 will similarly have a random value assigned to= it at RFC publication time.





=C2=A0
--000000000000ad53150581d35db1-- From nobody Wed Feb 13 21:05:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA81B12D4F3 for ; Wed, 13 Feb 2019 21:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=N/fI6mB2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=T+bjz+3r 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 UoGXz5S31tay for ; Wed, 13 Feb 2019 21:05:35 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1808F130E09 for ; Wed, 13 Feb 2019 21:05:35 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2A4B624614; Thu, 14 Feb 2019 00:05:34 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 14 Feb 2019 00:05:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=fm1; bh=Opo lvEEK+wgnTLLynEIS7Nr89UTuKbGAejaDKStdo0I=; b=N/fI6mB2bmm2S+Q1n8X 7m0GR3Ske/vqwSKYx5qVrGAXPPZZZmEerZ1ylSksHeqOoz+IS8k0Bi6kmLRxmw9O daaz7vbjDmD4CIjtvwldn7Sp8lpbhrTxmzhLai5V/0rw3oXRymJhbOwmiXimGCP9 siQNyomTMskUSV08C6F73eGp2wVvuAGZtCBpnV6hAdNjqHbXIkKkt9D9Lgw/H46d WapxqD1Ff5SNuEVv5dualdra1aoHCnHaEYFsRnWq8mk8HrCooZvVfW9jDDnh4NKK c6pnAnIGv9sGT/97aJiZ3FARTh5KB7ncFQ7Zhp/rDwzXarWHf0nYQMNmY+A6rQQE BhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=OpolvEEK+wgnTLLynEIS7Nr89UTuKbGAejaDKStdo 0I=; b=T+bjz+3rSe1xMdjCMi/XXc7y/N7IziWciR9+HTpL3E0N172JN5NTjlukU 18MHvI7Cyo8FVsHYnd+4eqsiR+vDjaadzZP/HXk9Z7z4gqQEhN5+q8WA+OyFKi/4 ZbXD4d0SKCYV8cRsgJVahNbs8X6XSckpBQqK2a5WnkoLBorkZ91W2C1ge4biIp+B rd8TVs5RnLlgV09eNiYsQ+aJaMOlR/egtdmePqmNXtLA+pLkp9qDp1MtRZP4Kn8m 1GIECaTZSgnhoelC9aG1xGj0q14Rwfp48457N2PgaOWjraSBh0gK5aan8VEm8jzn FruX5OXFsBMXAMguoulHSTssWNk6w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtgedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg foufffjghfsehtjeertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcu oehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 690119E54B; Thu, 14 Feb 2019 00:05:33 -0500 (EST) Message-Id: <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> From: Martin Thomson To: Jana Iyengar Cc: QUIC WG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 Subject: Re: KEYS_READY Date: Thu, 14 Feb 2019 16:05:33 +1100 In-Reply-To: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 05:05:37 -0000 On Thu, Feb 14, 2019, at 15:24, Jana Iyengar wrote: > (I've left this comment on the PR as well, but seeing that this discussion > is happening here as well, echoing it here) > If the peer hasn't acked the previous KEYS_ACTIVE, it may not have seen it > yet. It is possible that it simultaneously did a key update and sent a > KEYS_ACTIVE however. Under this condition, the endpoint wouldn't be able to > update its keys again, since the peer may close the connection, right? This is not a problem, but it requires thinking the process through. An endpoint can only initiate a key update if it has received KEYS_ACTIVE. It can only send KEYS_ACTIVE if it has received a key update (and is either responding, or initiated that). Take the example where an ACK is lost, so a key update occurs when one peer is retransmitting KEYS_ACTIVE: C: Update to Key Phase 1. S: Update to Key Phase 1. Send KEYS_ACTIVE. C: Send packet containing ACK for the server packet containing KEYS_ACTIVE, plus KEYS_ACTIVE. That packet is lost. C: Update to Key Phase 0. S: Update to Key Phase 0. Send KEYS_ACTIVE. The server might believe that its KEYS_ACTIVE hasn't been acknowledged, but it has to be prepared for a key update as soon as it sends the frame. If there is a simultanous update it looks like this: C: Update to Key Phase 1. S: Update to Key Phase 1. (Concurrent with previous.) C: Receive packet with KP1. Send KEYS_ACTIVE. Lost. S: Receive packet with KP1. Send KEYS_ACTIVE. At this point, both peers are fine, they are on the same keys, and a key update can be triggered by the client. The server can't update until the client repairs the lost KEYS_ACTIVE frame. This continues: C: Update to Key Phase 0. S: Receive KP0. Update to Key Phase 0. Send KEYS_ACTIVE. As you can see, the client stops sending when it updates again, but that's OK. It's also safe if the KEYS_ACTIVE frames get through, but acknowledgments for them don't. From nobody Wed Feb 13 21:08:46 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B234412D4E8 for ; Wed, 13 Feb 2019 21:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=dXJjLQIE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=P+cCcxb/ 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 vPVeF6850njK for ; Wed, 13 Feb 2019 21:08:41 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67226130ED0 for ; Wed, 13 Feb 2019 21:08:41 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F34432470C; Thu, 14 Feb 2019 00:08:39 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 14 Feb 2019 00:08:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:references:date:in-reply-to; s=fm1; bh=h5L wCM6q9+nutMQ9Cfz3VXxs7yVemd0nboeT9bmDwFs=; b=dXJjLQIETDLVH/rD2Ss 23S3l4tAA7BehOQHgW/9A+teLRrNaqFucj24C9YqJ95xYRl6ss607qcuhWAOp3zM R4n02p7TXKT9J486TOdSMfJeSBybzubQSn2RfGDQ6UsgHmaQEq7avvOa9oagfhfv 7ipfFfvA6nl2cHabw2pZwTqz6CxRlaCDMGqfMQwBitWSekfhIgeeWzXO2GL8QkpZ vhrNSKITMK7Ox4/kXHpBHBSI8dzFCDO8MJLNLdKLafaZq409G3ohB8BESe4oIrhu T6lJGzifvaIDe7P9qamSA1bm2GYTO+5I6wE9fXowe75LdeZkEkLSDOE3j1u6S7MY 5Og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=h5LwCM6q9+nutMQ9Cfz3VXxs7yVemd0nboeT9bmDw Fs=; b=P+cCcxb/9a8L8RxovKNdssj866ixkCMYUF57z48yaVGWElGrHAcEoOajw NfbdjxQQUDLuwxWloZlx355UoX9jZBAhbYDjmiIJzkqxbHyBGoG9hdF+BKnFMPly YJldGEjunSYKL0XPKHQiTuI3L2qYDWWnR/u8aMO03BemKxk/nAnhoXyfosmBQ1sd P57x4OtOzaN3Rr7etODhJKhT94BGElCn8xnl8om/eFpLIuLQhF8Jb0zmUSEqH1xg UAzeGm7A0z0AIuq/PCPDONwZBWBk8VqfwfkpbtII77A8AQjh98eNhDkMBdMMZLn2 IOwRfNqEth9TN6vxqfu4frWNF4Ijw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtgedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg foufhfffgjsehtjeertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcu oehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F20449E54B; Thu, 14 Feb 2019 00:08:38 -0500 (EST) Message-Id: <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> From: Martin Thomson To: Jana Iyengar Cc: QUIC WG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 Subject: Re: QUIC ossification References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> Date: Thu, 14 Feb 2019 16:08:38 +1100 In-Reply-To: Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 05:08:45 -0000 On Thu, Feb 14, 2019, at 15:48, Jana Iyengar wrote: > Basically, I'm proposing that QUIC v1 be assigned a random number for its > version at RFC publication time. What property do you expect that to provide? > Anyone who wants to use a different version for v1 MUST request it from IANA first before using it in the wild. This too. What does this achieve? I get that there seems to be the emerging view that unmanaged codepoint space is not good and we should ask IANA to manage it for us, but I don't understand what these proposals would provide. From nobody Wed Feb 13 21:27:42 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09CD130FCB for ; Wed, 13 Feb 2019 21:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXKqrFMNjVyu for ; Wed, 13 Feb 2019 21:27:40 -0800 (PST) Received: from mail-it1-x142.google.com (mail-it1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40FC130F99 for ; Wed, 13 Feb 2019 21:27:39 -0800 (PST) Received: by mail-it1-x142.google.com with SMTP id z9so10230948itc.4 for ; Wed, 13 Feb 2019 21:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vRDnUV+dVuKgK/lymnhrbKl2Kp7J4fTKoJfZw/cXp6E=; b=KL29tEqadhfimdHrXrqB1lyICYnYF2oxIp40PdTeSGvZ9iGNWPX/1jevbxiMrFTMMJ NV+76xvrNJ9BXghXxwkKm1bcvB8hA+C79GNpBJtMIPQQDloEEh9X5uRKSC0CzkurYbCP VtubyblsR+hyXFDtV/MzVDZj/RxU7AHHqCRtvhfCi8q+Xj5Kv2u5BwZnYJyxQDgXRF2C wC4gZlNJsUaupqYcYZp8jr5IBrHOZMikj5jzIhUFngk9ZiSSxUsl/7jG+XPdbm2ApD+d 8D71Gym1V8U2AdAiAAPnegyFhMnQmbbExmcnIS51LtkSzhTUPYBhxWDXdIoGQ0nieY9Y 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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vRDnUV+dVuKgK/lymnhrbKl2Kp7J4fTKoJfZw/cXp6E=; b=IzOb880JuKtuCTomeTq1Pm9n3NW2FoU80u3AWKLlp/WoPSKOJht7Emw/sQQUdAvqo4 DCLVBUoR48Yv3OaDQbkwKDNn4h/8Nc7EkWWi7STe4Gy03P0reH/OBmWe8vleFisT/1B8 bomJwIQ04gFtEfIjdHzOxDHy2Q72zSmD6TYaVrV00rE+mUjSR1CmE3kUBdPO9cCDM9xO zbCYGijFfx7d3GH/nAqSvpAJl4xS9a/f1G2blNxI5gusJEyZCfH1HS1oKhHTB7gFtaBE RJJS2ovIr3vXVlvtmM2PqPXP0PnDvK+zqgfn3MPHlOm9vje8M4pRSqaL0T6mA3I3J89Z iBCw== X-Gm-Message-State: AHQUAubmomn2D7A6rS5MKRV5OYA/f+NMTl+n9xTQYwdGCx+Ad/tIruk2 Nq5cg2+Mq0fWJ/SldLgFPJRGJgNtvPwjucb4ziY= X-Google-Smtp-Source: AHgI3IYbQr3bmlObsKaGXvZayOsz3LsdHp0X4O7cOw3aqrU2rlXn+lejdQlhuJN3N18qczPYVG+YD8raOshnPTLKImM= X-Received: by 2002:a6b:bc83:: with SMTP id m125mr1021490iof.83.1550122058856; Wed, 13 Feb 2019 21:27:38 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> In-Reply-To: <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> From: Marten Seemann Date: Thu, 14 Feb 2019 13:27:27 +0800 Message-ID: Subject: Re: KEYS_READY To: Martin Thomson Cc: Jana Iyengar , QUIC WG Content-Type: multipart/alternative; boundary="000000000000ad413d0581d3eafe" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 05:27:42 -0000 --000000000000ad413d0581d3eafe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I was OK with that PR, and while we might go back and forth on the merits of using a bit vs. a frame, the consensus in Tokyo was that the frame was superior. Also, this solves more problems. In my understanding, the consensus in Tokyo was based on the assumption that the bit and the frame were basically signaling the same thing - at least I wasn=E2=80=99t aware of the additional retransmission logic necessa= ry, and I would=E2=80=99ve opposed this solution if I had known. > The PR changes how Initial keys are retired. Instead of relying on the de= livery of Handshake packets, it relies on the delivery of KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be included in every Handshake packet being sent. This is again the problem of a discrete vs. a continuous signal. Using another bit in the first byte solves this problem. After the handshake completes, we want the peer to advance from handshake mode to normal mode in the loss recovery logic, since in handshake mode we don=E2=80=99t have PTOs. The only way to achieve this using the KEYS_ACTIVE= frame is to include it in multiple (all packets for one RTT?) after the handshake completes. That being said, adding a generation number as Kazuho suggested seems to be the second best solution, since it at least removes the necessity to implement separate retransmission rules. On Thu, Feb 14, 2019 at 13:05 Martin Thomson wrote: > On Thu, Feb 14, 2019, at 15:24, Jana Iyengar wrote: > > (I've left this comment on the PR as well, but seeing that this > discussion > > is happening here as well, echoing it here) > > If the peer hasn't acked the previous KEYS_ACTIVE, it may not have seen > it > > yet. It is possible that it simultaneously did a key update and sent a > > KEYS_ACTIVE however. Under this condition, the endpoint wouldn't be abl= e > to > > update its keys again, since the peer may close the connection, right? > > This is not a problem, but it requires thinking the process through. > > An endpoint can only initiate a key update if it has received > KEYS_ACTIVE. It can only send KEYS_ACTIVE if it has received a key updat= e > (and is either responding, or initiated that). > > Take the example where an ACK is lost, so a key update occurs when one > peer is retransmitting KEYS_ACTIVE: > > C: Update to Key Phase 1. > S: Update to Key Phase 1. Send KEYS_ACTIVE. > C: Send packet containing ACK for the server packet containing > KEYS_ACTIVE, plus KEYS_ACTIVE. That packet is lost. > C: Update to Key Phase 0. > S: Update to Key Phase 0. Send KEYS_ACTIVE. > > The server might believe that its KEYS_ACTIVE hasn't been acknowledged, > but it has to be prepared for a key update as soon as it sends the frame. > > If there is a simultanous update it looks like this: > > C: Update to Key Phase 1. > S: Update to Key Phase 1. (Concurrent with previous.) > C: Receive packet with KP1. Send KEYS_ACTIVE. Lost. > S: Receive packet with KP1. Send KEYS_ACTIVE. > > At this point, both peers are fine, they are on the same keys, and a key > update can be triggered by the client. The server can't update until the > client repairs the lost KEYS_ACTIVE frame. This continues: > > C: Update to Key Phase 0. > S: Receive KP0. Update to Key Phase 0. Send KEYS_ACTIVE. > > As you can see, the client stops sending when it updates again, but that'= s > OK. > > It's also safe if the KEYS_ACTIVE frames get through, but acknowledgments > for them don't. > > --000000000000ad413d0581d3eafe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I=C2=A0was OK with t= hat PR, and while we might go back and forth on the merits of using a bit v= s. a frame, the consensus in Tokyo was that the frame was superior.=C2=A0 A= lso, this solves more problems.

In my understanding, the consensus in Tokyo was based on the assu= mption that the bit and the frame were basically signaling the same thing -= at least I wasn=E2=80=99t aware of the additional retransmission logic nec= essary, and I would=E2=80=99ve opposed this solution if I had known.=

=
>=C2=A0The PR cha= nges how Initial keys are retired. Instead of relying on the=C2=A0delivery of Handshake packets, it relies on the delivery of=C2=A0= KEYS_ACTIVE frames. However, we do not require KEY_ACTIV= E frames to be=C2=A0included in every Handshake packet b= eing sent.

This is again the problem of= a discrete vs. a continuous signal. Using another bit in the first byte so= lves this problem.
After the = handshake completes, we want the peer to=C2=A0advance from ha= ndshake mode to normal mode in the loss recovery logic, since in handshake = mode we don=E2=80=99t have PTOs. The only way to achieve this using the KEY= S_ACTIVE frame is to include it in multiple (all packets for one RTT?) afte= r the handshake completes.=C2=A0
That being said, adding a generation number as Kaz= uho suggested seems to be the second best solution, since it at least remov= es the necessity to implement separate retransmission rules.

On Thu, Feb 14, 2019 at 13:05 Martin Thomson <mt@lowentropy.net&g= t; wrote:
On Thu, Feb 14, 2019, at = 15:24, Jana Iyengar wrote:
> (I've left this comment on the PR as well, but seeing that this di= scussion
> is happening here as well, echoing it here)
> If the peer hasn't acked the previous KEYS_ACTIVE, it may not have= seen it
> yet. It is possible that it simultaneously did a key update and sent a=
> KEYS_ACTIVE however. Under this condition, the endpoint wouldn't b= e able to
> update its keys again, since the peer may close the connection, right?=

This is not a problem, but it requires thinking the process through.

An endpoint can only initiate a key update if it has received KEYS_ACTIVE.= =C2=A0 It can only send KEYS_ACTIVE if it has received a key update (and is= either responding, or initiated that).

Take the example where an ACK is lost, so a key update occurs when one peer= is retransmitting KEYS_ACTIVE:

C: Update to Key Phase 1.
S: Update to Key Phase 1.=C2=A0 Send KEYS_ACTIVE.
C: Send packet containing ACK for the server packet containing KEYS_ACTIVE,= plus KEYS_ACTIVE.=C2=A0 That packet is lost.
C: Update to Key Phase 0.
S: Update to Key Phase 0. Send KEYS_ACTIVE.

The server might believe that its KEYS_ACTIVE hasn't been acknowledged,= but it has to be prepared for a key update as soon as it sends the frame.<= br>
If there is a simultanous update it looks like this:

C: Update to Key Phase 1.
S: Update to Key Phase 1.=C2=A0 (Concurrent with previous.)
C: Receive packet with KP1.=C2=A0 Send KEYS_ACTIVE.=C2=A0 Lost.
S: Receive packet with KP1.=C2=A0 Send KEYS_ACTIVE.

At this point, both peers are fine, they are on the same keys, and a key up= date can be triggered by the client.=C2=A0 The server can't update unti= l the client repairs the lost KEYS_ACTIVE frame.=C2=A0 This continues:

C: Update to Key Phase 0.
S: Receive KP0.=C2=A0 Update to Key Phase 0.=C2=A0 Send KEYS_ACTIVE.

As you can see, the client stops sending when it updates again, but that= 9;s OK.

It's also safe if the KEYS_ACTIVE frames get through, but acknowledgmen= ts for them don't.

--000000000000ad413d0581d3eafe-- From nobody Wed Feb 13 21:42:46 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533DF13106A for ; Wed, 13 Feb 2019 21:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L7YEk2GzNFF for ; Wed, 13 Feb 2019 21:42:41 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 5031C130FE9 for ; Wed, 13 Feb 2019 21:42:41 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id s22so2496563pfh.4 for ; Wed, 13 Feb 2019 21:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=Nfz+upCX6Hggm/PkuDeZLEBG6qcFgTvz0fUcZ1LA6VY=; b=cW9Fv4m7XgnqAcCqrDfWX4xAWKJGSYklNsAlQ6+5p7QDc9fbJMkK/JnQ+367hTsXRv exm9PMZRFvxKfjetQ4sEKKPWfY06WFliCsr3kztHKcagPJ/Lt8n+tP9sPbt+k9373Lhf Y/u0PH1JPXpRiFA0g0ll0HyVpyeVq5CHpmX81boiYMr7m7BZikqVhMeYERsgZl6A5Fa9 RrjrzjKEWyrV5rdFV41r7wmKCh+h68/buA5r4e59dq3f5YssP6Qpz3EOtO1Mc4WDSVxG OgU+CrMFopyj9KzpFK4GRrZW/73jEo0EtzYuHkmCNZcnCTkqft81lsEfAGWZaE+9T3Kx DDIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=Nfz+upCX6Hggm/PkuDeZLEBG6qcFgTvz0fUcZ1LA6VY=; b=MYGsYiA5Fpd0NzKTMORG+gqNS/d2dneAe+nb62LEqdFzD1b/RwzoFYP0Ww9xTu0khw V3QIRODPo34VsnVErCYYh2B10qxINN9asTKhx4du2kDRvIrLuZdwENJ0NQNTTi+Kj33W 5nuqn+O1+msXUhn4F4bDhWhsZDuIQJhoe9ANFXvNxDcozej/fWEx3Ybn5SQD7PaBmYGm k53KwQOplqQ1KzqVFG15NqIfkMUDAB/4Cw2JqaDAbRenHqIhnB6lb2jMQLavcsG4YZEH 8z1xc1XiAelP5L1nVeYEm5sJfNh89aQO+/ryew8lC+79HCiAV42hiQcN5ByUYsBzQEKt xI3A== X-Gm-Message-State: AHQUAub1HsDM/N91PFPc3N7YkxIDuFj/Hr18kVKYpXpcoZ/tNwjHh006 61bZ8vgh7vEcWSPirbQ2bm8= X-Google-Smtp-Source: AHgI3IbAFuOloHlxCpU3aSc5haRx3Z5NOwpuempiHOQBSNU4myFPf1VPNiR2DjZk24/Eg/NBU5elfw== X-Received: by 2002:a65:4784:: with SMTP id e4mr2105035pgs.12.1550122960556; Wed, 13 Feb 2019 21:42:40 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.61]) by smtp.gmail.com with ESMTPSA id a6sm1430970pfn.147.2019.02.13.21.42.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 21:42:39 -0800 (PST) From: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Marten Seemann , Martin Thomson CC: Jana Iyengar , QUIC WG Subject: Re: KEYS_READY Thread-Topic: KEYS_READY Thread-Index: ATY0ODE1WAmiSi3iEdmd5vS0ATj/SkFNNUt1UVJEWEtnNGItQUF5aXlqUS1kb3pBZEt3cDk0OTQ1UUtjdmRFMDc0NVFWUVFGQjA2NDZkNjFhZEE0Njkxd0t5UWNBNzc3M0FKcThnlp13a38= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Thu, 14 Feb 2019 05:42:31 +0000 Message-ID: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1766128EAD7248F02C1EAFA5AC670DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 05:42:44 -0000 --_000_DB6PR10MB1766128EAD7248F02C1EAFA5AC670DB6PR10MB1766EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Why do keys need to be in sync? Disregarding handshake, if each peer has a separate key index counter, at c= hange in phase bit ought to be sufficient. The endpoints can have vastly different consumption rates. With sync keys the peer can prevent you from updating while uou can update = after ca 3 PTO in the async design. Neither design can force the peer to up= date. ________________________________ Fra: QUIC p=E5 vegne af Marten Seemann Sendt: torsdag, februar 14, 2019 6:27 AM Til: Martin Thomson Cc: Jana Iyengar; QUIC WG Emne: Re: KEYS_READY > I was OK with that PR, and while we might go back and forth on the merits= of using a bit vs. a frame, the consensus in Tokyo was that the frame was = superior. Also, this solves more problems. In my understanding, the consensus in Tokyo was based on the assumption tha= t the bit and the frame were basically signaling the same thing - at least = I wasn=92t aware of the additional retransmission logic necessary, and I wo= uld=92ve opposed this solution if I had known. > The PR changes how Initial keys are retired. Instead of relying on the de= livery of Handshake packets, it relies on the delivery of KEYS_ACTIVE frame= s. However, we do not require KEY_ACTIVE frames to be included in every Han= dshake packet being sent. This is again the problem of a discrete vs. a continuous signal. Using anot= her bit in the first byte solves this problem. After the handshake completes, we want the peer to advance from handshake m= ode to normal mode in the loss recovery logic, since in handshake mode we d= on=92t have PTOs. The only way to achieve this using the KEYS_ACTIVE frame = is to include it in multiple (all packets for one RTT?) after the handshake= completes. That being said, adding a generation number as Kazuho suggested seems to be= the second best solution, since it at least removes the necessity to imple= ment separate retransmission rules. On Thu, Feb 14, 2019 at 13:05 Martin Thomson > wrote: On Thu, Feb 14, 2019, at 15:24, Jana Iyengar wrote: > (I've left this comment on the PR as well, but seeing that this discussio= n > is happening here as well, echoing it here) > If the peer hasn't acked the previous KEYS_ACTIVE, it may not have seen i= t > yet. It is possible that it simultaneously did a key update and sent a > KEYS_ACTIVE however. Under this condition, the endpoint wouldn't be able = to > update its keys again, since the peer may close the connection, right? This is not a problem, but it requires thinking the process through. An endpoint can only initiate a key update if it has received KEYS_ACTIVE. = It can only send KEYS_ACTIVE if it has received a key update (and is eithe= r responding, or initiated that). Take the example where an ACK is lost, so a key update occurs when one peer= is retransmitting KEYS_ACTIVE: C: Update to Key Phase 1. S: Update to Key Phase 1. Send KEYS_ACTIVE. C: Send packet containing ACK for the server packet containing KEYS_ACTIVE,= plus KEYS_ACTIVE. That packet is lost. C: Update to Key Phase 0. S: Update to Key Phase 0. Send KEYS_ACTIVE. The server might believe that its KEYS_ACTIVE hasn't been acknowledged, but= it has to be prepared for a key update as soon as it sends the frame. If there is a simultanous update it looks like this: C: Update to Key Phase 1. S: Update to Key Phase 1. (Concurrent with previous.) C: Receive packet with KP1. Send KEYS_ACTIVE. Lost. S: Receive packet with KP1. Send KEYS_ACTIVE. At this point, both peers are fine, they are on the same keys, and a key up= date can be triggered by the client. The server can't update until the cli= ent repairs the lost KEYS_ACTIVE frame. This continues: C: Update to Key Phase 0. S: Receive KP0. Update to Key Phase 0. Send KEYS_ACTIVE. As you can see, the client stops sending when it updates again, but that's = OK. It's also safe if the KEYS_ACTIVE frames get through, but acknowledgments f= or them don't. --_000_DB6PR10MB1766128EAD7248F02C1EAFA5AC670DB6PR10MB1766EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Why do keys need to be in sync?
Disregarding handshake, if each peer has a s= eparate key index counter, at change in phase bit ought to be sufficient.

The endpoints can have vastly different cons= umption rates.

With sync keys the peer can prevent you from= updating while uou can update after ca 3 PTO in the async design. Neither = design can force the peer to update.

 
Fra: QUIC= <quic-bounces@ietf.org> p=E5 vegne af Marten Seemann <martenseema= nn@gmail.com>
Sendt: torsdag, februar 14, 2019 6:27 AM
Til: Martin Thomson
Cc: Jana Iyengar; QUIC WG
Emne: Re: KEYS_READY
 
> I was OK with that PR, and while = we might go back and forth on the merits of using a bit vs. a frame, the co= nsensus in Tokyo was that the frame was superior.  Also, this solves more problems.

In my understanding, the consensus in Tokyo= was based on the assumption that the bit and the frame were basically sign= aling the same thing - at least I wasn=92t aware of the additional retransmission logic necessary, and I would=92ve o= pposed this solution if I had known.

> The PR chang= es how Initial keys are retired. Instead of relying on the delivery of Handshake packets, it relies = on the delivery of KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be included in every Handshake packet being sent.

This is again the problem of a discrete vs.= a continuous signal. Using another bit in the first byte solves this probl= em.
After the handshake completes, we want t= he peer to advance from handshake mode to normal mode in= the loss recovery logic, since in handshake mode we don=92t have PTOs. The only way to achieve this using the KEYS_ACT= IVE frame is to include it in multiple (all packets for one RTT?) after the= handshake completes. 

That being said, adding a generation number as Kazuho sug= gested seems to be the second best solution, since it at least removes the = necessity to implement separate retransmission rules.

On Thu, Feb 14, 2019 at 13:05 Martin = Thomson <mt@lowen= tropy.net> wrote:
On Thu, Feb 14, 2019, at 15:24= , Jana Iyengar wrote:
> (I've left this comment on the PR as well, but seeing that this discus= sion
> is happening here as well, echoing it here)
> If the peer hasn't acked the previous KEYS_ACTIVE, it may not have see= n it
> yet. It is possible that it simultaneously did a key update and sent a=
> KEYS_ACTIVE however. Under this condition, the endpoint wouldn't be ab= le to
> update its keys again, since the peer may close the connection, right?=

This is not a problem, but it requires thinking the process through.

An endpoint can only initiate a key update if it has received KEYS_ACTIVE.&= nbsp; It can only send KEYS_ACTIVE if it has received a key update (and is = either responding, or initiated that).

Take the example where an ACK is lost, so a key update occurs when one peer= is retransmitting KEYS_ACTIVE:

C: Update to Key Phase 1.
S: Update to Key Phase 1.  Send KEYS_ACTIVE.
C: Send packet containing ACK for the server packet containing KEYS_ACTIVE,= plus KEYS_ACTIVE.  That packet is lost.
C: Update to Key Phase 0.
S: Update to Key Phase 0. Send KEYS_ACTIVE.

The server might believe that its KEYS_ACTIVE hasn't been acknowledged, but= it has to be prepared for a key update as soon as it sends the frame.

If there is a simultanous update it looks like this:

C: Update to Key Phase 1.
S: Update to Key Phase 1.  (Concurrent with previous.)
C: Receive packet with KP1.  Send KEYS_ACTIVE.  Lost.
S: Receive packet with KP1.  Send KEYS_ACTIVE.

At this point, both peers are fine, they are on the same keys, and a key up= date can be triggered by the client.  The server can't update until th= e client repairs the lost KEYS_ACTIVE frame.  This continues:

C: Update to Key Phase 0.
S: Receive KP0.  Update to Key Phase 0.  Send KEYS_ACTIVE.

As you can see, the client stops sending when it updates again, but that's = OK.

It's also safe if the KEYS_ACTIVE frames get through, but acknowledgments f= or them don't.

--_000_DB6PR10MB1766128EAD7248F02C1EAFA5AC670DB6PR10MB1766EURP_-- From nobody Wed Feb 13 21:44:12 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7935A130FE9 for ; Wed, 13 Feb 2019 21:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J27x8lQsL48M for ; Wed, 13 Feb 2019 21:44:09 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 8B39E130FE8 for ; Wed, 13 Feb 2019 21:44:09 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id g6so2477641pfh.13 for ; Wed, 13 Feb 2019 21:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=VVjut9Z8dGU8k+uteETNwTfYlPk1EXfqBCmg01orzz0=; b=KU9tWDwv78xOgO1miJnzjPZhGOSGe7wnRd82HT1BBIyGxrl9p/Ib9uKNi2DE0yasBD k80/hPV23GOLEtRY+EjHE0XWrhDqAA9n7GLRm2aMcOHQMMOxAOCQ4tGXjEEbUIz+QDpf VTlz4aAz7qw2sSfLKNuTcESnor6lHWwU7wKvqJ8fjmlLZ69AmQn1ihepBxl4MZ1AqB+2 sFEibXakOgs9aYhzcV3hPVK9Jr0gygv4usHHEPTvNHZpo0LYQrXuOIn90w8QVzHOJVTl jUpEKuG/wDc1gGp22/gFQwhO/GeH+Km1bbmn14ykoRhHuk42XnbaBrVFU1hPOqFalk+Y 6UQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=VVjut9Z8dGU8k+uteETNwTfYlPk1EXfqBCmg01orzz0=; b=X7bg4OcmbTf5yflOwmAlAIWAS/HLcRUL7g5wHKBJUixbJ1YGqNKVqIToP7x/jVZG+9 jypfDILZZSSpu2TEIao8xGC82Z1Q4cuqfMRRuG5eHd51RYvSaodmJvWaSWee2jYnoYj9 8epI8xp1jt1Tyq+6fy3KfEP1pugqzRRcTtm941Afwkgbdn1t03/o1irIVOGFm3hzlMsc IMNB1LaT/Nwo8Fpmj79SalsrBicFD1khrW+bUIbx5X5RaGIv0w8xq7A/6Bbk9jKnw6b6 3JDKig/vyp4CXq76HXhr91VQUT35vZ3I4mhX1RoaBpTOuHgVe0+f6bc0sMDHXOegr6vo JuLQ== X-Gm-Message-State: AHQUAua341MkOA8soOH4wkC7aWr1oNKHWY92mz3h8Sj0EdWSUG7f52Uz ZE8YDsA60ujD4dcZb+Ty8fjmd+bBwOM= X-Google-Smtp-Source: AHgI3IYZdfuFJSU/CpOQYIINvqQ57DFHYqjGngzUi5H75HHCMQGn7gEHK0Ujl8KIe8n4Q3hZx8rYcw== X-Received: by 2002:a62:5910:: with SMTP id n16mr2228317pfb.128.1550123049026; Wed, 13 Feb 2019 21:44:09 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.61]) by smtp.gmail.com with ESMTPSA id k71sm2047104pga.44.2019.02.13.21.44.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 21:44:08 -0800 (PST) From: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Marten Seemann , Martin Thomson CC: Jana Iyengar , QUIC WG Subject: Re: KEYS_READY Thread-Topic: KEYS_READY Thread-Index: ATY0ODE1WAmiSi3iEdmd5vS0ATj/SkFNNUt1UVJEWEtnNGItQUF5aXlqUS1kb3pBZEt3cDk0OTQ1UUtjdmRFMDc0NVFWUVFGQjA2NDZkNjFhZEE0Njkxd0t5UWNBNzc3M0FKcThnMEZGRTGVG0cY+A== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Thu, 14 Feb 2019 05:44:00 +0000 Message-ID: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB176684E61A66BF01C66008F6AC670DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 05:44:11 -0000 --_000_DB6PR10MB176684E61A66BF01C66008F6AC670DB6PR10MB1766EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I guess because ACK? ________________________________ Fra: Mikkel Fahn=F8e J=F8rgensen Sendt: torsdag, februar 14, 2019 6:42 AM Til: Marten Seemann; Martin Thomson Cc: Jana Iyengar; QUIC WG Emne: Re: KEYS_READY Why do keys need to be in sync? Disregarding handshake, if each peer has a separate key index counter, at c= hange in phase bit ought to be sufficient. The endpoints can have vastly different consumption rates. With sync keys the peer can prevent you from updating while uou can update = after ca 3 PTO in the async design. Neither design can force the peer to up= date. ________________________________ Fra: QUIC p=E5 vegne af Marten Seemann Sendt: torsdag, februar 14, 2019 6:27 AM Til: Martin Thomson Cc: Jana Iyengar; QUIC WG Emne: Re: KEYS_READY > I was OK with that PR, and while we might go back and forth on the merits= of using a bit vs. a frame, the consensus in Tokyo was that the frame was = superior. Also, this solves more problems. In my understanding, the consensus in Tokyo was based on the assumption tha= t the bit and the frame were basically signaling the same thing - at least = I wasn=92t aware of the additional retransmission logic necessary, and I wo= uld=92ve opposed this solution if I had known. > The PR changes how Initial keys are retired. Instead of relying on the de= livery of Handshake packets, it relies on the delivery of KEYS_ACTIVE frame= s. However, we do not require KEY_ACTIVE frames to be included in every Han= dshake packet being sent. This is again the problem of a discrete vs. a continuous signal. Using anot= her bit in the first byte solves this problem. After the handshake completes, we want the peer to advance from handshake m= ode to normal mode in the loss recovery logic, since in handshake mode we d= on=92t have PTOs. The only way to achieve this using the KEYS_ACTIVE frame = is to include it in multiple (all packets for one RTT?) after the handshake= completes. That being said, adding a generation number as Kazuho suggested seems to be= the second best solution, since it at least removes the necessity to imple= ment separate retransmission rules. On Thu, Feb 14, 2019 at 13:05 Martin Thomson > wrote: On Thu, Feb 14, 2019, at 15:24, Jana Iyengar wrote: > (I've left this comment on the PR as well, but seeing that this discussio= n > is happening here as well, echoing it here) > If the peer hasn't acked the previous KEYS_ACTIVE, it may not have seen i= t > yet. It is possible that it simultaneously did a key update and sent a > KEYS_ACTIVE however. Under this condition, the endpoint wouldn't be able = to > update its keys again, since the peer may close the connection, right? This is not a problem, but it requires thinking the process through. An endpoint can only initiate a key update if it has received KEYS_ACTIVE. = It can only send KEYS_ACTIVE if it has received a key update (and is eithe= r responding, or initiated that). Take the example where an ACK is lost, so a key update occurs when one peer= is retransmitting KEYS_ACTIVE: C: Update to Key Phase 1. S: Update to Key Phase 1. Send KEYS_ACTIVE. C: Send packet containing ACK for the server packet containing KEYS_ACTIVE,= plus KEYS_ACTIVE. That packet is lost. C: Update to Key Phase 0. S: Update to Key Phase 0. Send KEYS_ACTIVE. The server might believe that its KEYS_ACTIVE hasn't been acknowledged, but= it has to be prepared for a key update as soon as it sends the frame. If there is a simultanous update it looks like this: C: Update to Key Phase 1. S: Update to Key Phase 1. (Concurrent with previous.) C: Receive packet with KP1. Send KEYS_ACTIVE. Lost. S: Receive packet with KP1. Send KEYS_ACTIVE. At this point, both peers are fine, they are on the same keys, and a key up= date can be triggered by the client. The server can't update until the cli= ent repairs the lost KEYS_ACTIVE frame. This continues: C: Update to Key Phase 0. S: Receive KP0. Update to Key Phase 0. Send KEYS_ACTIVE. As you can see, the client stops sending when it updates again, but that's = OK. It's also safe if the KEYS_ACTIVE frames get through, but acknowledgments f= or them don't. --_000_DB6PR10MB176684E61A66BF01C66008F6AC670DB6PR10MB1766EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I guess because ACK?

 
Fra: Mikk= el Fahn=F8e J=F8rgensen <mikkelfj@gmail.com>
Sendt: torsdag, februar 14, 2019 6:42 AM
Til: Marten Seemann; Martin Thomson
Cc: Jana Iyengar; QUIC WG
Emne: Re: KEYS_READY
 
Why do keys need to be in sync?
Disregarding handshake, if each peer has a sep= arate key index counter, at change in phase bit ought to be sufficient.

The endpoints can have vastly different consum= ption rates.

With sync keys the peer can prevent you from u= pdating while uou can update after ca 3 PTO in the async design. Neither de= sign can force the peer to update.

 
Fra: QUIC= <quic-bounces@ietf.org> p=E5 vegne af Marten Seemann <martenseema= nn@gmail.com>
Sendt: torsdag, februar 14, 2019 6:27 AM
Til: Martin Thomson
Cc: Jana Iyengar; QUIC WG
Emne: Re: KEYS_READY
 
> I was OK with that PR, and while = we might go back and forth on the merits of using a bit vs. a frame, the co= nsensus in Tokyo was that the frame was superior.  Also, this solves more problems.

In my understanding, the consensus in Tokyo= was based on the assumption that the bit and the frame were basically sign= aling the same thing - at least I wasn=92t aware of the additional retransmission logic necessary, and I would=92ve o= pposed this solution if I had known.

> The PR chang= es how Initial keys are retired. Instead of relying on the delivery of Handshake packets, it relies = on the delivery of KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be included in every Handshake packet being sent.

This is again the problem of a discrete vs.= a continuous signal. Using another bit in the first byte solves this probl= em.
After the handshake completes, we want t= he peer to advance from handshake mode to normal mode in= the loss recovery logic, since in handshake mode we don=92t have PTOs. The only way to achieve this using the KEYS_ACT= IVE frame is to include it in multiple (all packets for one RTT?) after the= handshake completes. 

That being said, adding a generation number as Kazuho sug= gested seems to be the second best solution, since it at least removes the = necessity to implement separate retransmission rules.

On Thu, Feb 14, 2019 at 13:05 Martin = Thomson <mt@lowen= tropy.net> wrote:
On Thu, Feb 14, 2019, at 15:24= , Jana Iyengar wrote:
> (I've left this comment on the PR as well, but seeing that this discus= sion
> is happening here as well, echoing it here)
> If the peer hasn't acked the previous KEYS_ACTIVE, it may not have see= n it
> yet. It is possible that it simultaneously did a key update and sent a=
> KEYS_ACTIVE however. Under this condition, the endpoint wouldn't be ab= le to
> update its keys again, since the peer may close the connection, right?=

This is not a problem, but it requires thinking the process through.

An endpoint can only initiate a key update if it has received KEYS_ACTIVE.&= nbsp; It can only send KEYS_ACTIVE if it has received a key update (and is = either responding, or initiated that).

Take the example where an ACK is lost, so a key update occurs when one peer= is retransmitting KEYS_ACTIVE:

C: Update to Key Phase 1.
S: Update to Key Phase 1.  Send KEYS_ACTIVE.
C: Send packet containing ACK for the server packet containing KEYS_ACTIVE,= plus KEYS_ACTIVE.  That packet is lost.
C: Update to Key Phase 0.
S: Update to Key Phase 0. Send KEYS_ACTIVE.

The server might believe that its KEYS_ACTIVE hasn't been acknowledged, but= it has to be prepared for a key update as soon as it sends the frame.

If there is a simultanous update it looks like this:

C: Update to Key Phase 1.
S: Update to Key Phase 1.  (Concurrent with previous.)
C: Receive packet with KP1.  Send KEYS_ACTIVE.  Lost.
S: Receive packet with KP1.  Send KEYS_ACTIVE.

At this point, both peers are fine, they are on the same keys, and a key up= date can be triggered by the client.  The server can't update until th= e client repairs the lost KEYS_ACTIVE frame.  This continues:

C: Update to Key Phase 0.
S: Receive KP0.  Update to Key Phase 0.  Send KEYS_ACTIVE.

As you can see, the client stops sending when it updates again, but that's = OK.

It's also safe if the KEYS_ACTIVE frames get through, but acknowledgments f= or them don't.

--_000_DB6PR10MB176684E61A66BF01C66008F6AC670DB6PR10MB1766EURP_-- From nobody Wed Feb 13 21:59:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC92131114 for ; Wed, 13 Feb 2019 21:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeEzE3ODjFZ6 for ; Wed, 13 Feb 2019 21:59:15 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 50E19130E25 for ; Wed, 13 Feb 2019 21:59:15 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id v28so2461864pgk.10 for ; Wed, 13 Feb 2019 21:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=nrg49mVCf3wgv+1GEwb1qlUsXOBCokg9uvdAih0RE2U=; b=KOMUlpFfLCcUiCfLi5zEs2+GT0Jbtg+ME70Nk7NwvPJa0ciPNDmsuZsT2jb0zCX2k9 rPXBFeF5p4DCMKd9DXmaALqlRSGYqNaMTKK20x/XmC2ikOtxJQeMu6Q98+9mfRMd1sez nnDNFh/0ns8OiVlADUL61lhI7EKIc9KW3mUPs30timLskzRGUYikGZ7hyLiyMy6BIhvM AT0rnynd67wcROHCoQzqXRlzYBRT8Vl/K5ZOEBd5B+ue2jFN1PNb88zD5JNz2HoV0RF9 6rmzkYaI4rL+IusEp+LPOgakRbQAOiIF0j42v3zNjINvpp9AZxvYrLPfVrYzdLz0fvhd tWCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=nrg49mVCf3wgv+1GEwb1qlUsXOBCokg9uvdAih0RE2U=; b=S8DWm2QLcaiqyURK0/Temp7xBEB75XQ7iADKjDw9nguSXOu9jidCNXTbKDOQ8lSmYq t8G7j5NigBEX0MExCA7lKInFSxG+6FAt8G98pwh9dScBxtbgQr78lq0UPt9KkSFFZyZw 7G3xjtl72fMkv346l19Xa+1mH+qRG8u6sMchrzBgc6F3Tsryh6xOZNpbhF/lojcePRHX kOkM/FNMtOylfn8Pny4oW/bZJsi2GRjc4pcwLPnunQIEXS75tGpURGS07i4bx2qyBCHZ OG70kcI0rH8CBXYTQPZJw4nxm/yxE4x1GggeRFzw8NhdUxXDqnHszFjpuGhHCOyybSkY GQeQ== X-Gm-Message-State: AHQUAub5hMR/wDnRmxww+5SneVdO87lIvfFpwano0r4JNVwppAH/R6f4 f3ZPLHsbySF/+OVFaOd0QYs= X-Google-Smtp-Source: AHgI3IbOMWSigT/5hJ6vitwQGY2sCAxlHwMVAa5pld9a9e0Pp1SzBv7BWqG5+ra3gCu167/Q2848Rw== X-Received: by 2002:a63:be0a:: with SMTP id l10mr2148162pgf.292.1550123954803; Wed, 13 Feb 2019 21:59:14 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.61]) by smtp.gmail.com with ESMTPSA id f67sm2411120pfc.141.2019.02.13.21.59.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 21:59:14 -0800 (PST) From: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Martin Thomson , Jana Iyengar CC: QUIC WG Subject: Re: QUIC ossification Thread-Topic: QUIC ossification Thread-Index: AWczejBHlg6ZkPl9jCqzvp1n/7+8K0UwNjUzOTU0NEJBa1U1azBBNDQ0QXZQWVBneVRiZWd0dUI4UU1oMVQyQkY0M3d5dHkrMzU4NERBYVlQMTRmYmVhQWRDT0JBMStoamdBa2lBODE2NjVBUEgzcEYyNzQxsLEo9Is= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Thu, 14 Feb 2019 05:59:06 +0000 Message-ID: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> , <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> In-Reply-To: <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1766CDECAEED8E8391F61CD4AC670DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 05:59:17 -0000 --_000_DB6PR10MB1766CDECAEED8E8391F61CD4AC670DB6PR10MB1766EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Version of the month is problematic: Google server would need to support a basic V1, otherwise non-chrome user a= gents would fail. Chrome browsers would have to reject V1 or the greasing w= on=92t work. This can only happen towards Google servers. Middleboxes now c= heck for V1 or Google domain. Eith future encrypted request domain, it is a= perfect wsy to firewall Google via Chrome. Users switch to other browser. ________________________________ Fra: QUIC p=E5 vegne af Martin Thomson Sendt: torsdag, februar 14, 2019 6:08 AM Til: Jana Iyengar Cc: QUIC WG Emne: Re: QUIC ossification On Thu, Feb 14, 2019, at 15:48, Jana Iyengar wrote: > Basically, I'm proposing that QUIC v1 be assigned a random number for its > version at RFC publication time. What property do you expect that to provide? > Anyone who wants to use a different version for v1 MUST request it from I= ANA first before using it in the wild. This too. What does this achieve? I get that there seems to be the emerging view that unmanaged codepoint spa= ce is not good and we should ask IANA to manage it for us, but I don't unde= rstand what these proposals would provide. --_000_DB6PR10MB1766CDECAEED8E8391F61CD4AC670DB6PR10MB1766EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Version of the month is problematic:

Google server would need to support a basic = V1, otherwise non-chrome user agents would fail. Chrome browsers would have= to reject V1 or the greasing won=92t work. This can only happen towards Go= ogle servers. Middleboxes now check for V1 or Google domain. Eith future encrypted request domain, it is a per= fect wsy to firewall Google via Chrome. Users switch to other browser.

 
Fra: QUIC= <quic-bounces@ietf.org> p=E5 vegne af Martin Thomson <mt@lowentro= py.net>
Sendt: torsdag, februar 14, 2019 6:08 AM
Til: Jana Iyengar
Cc: QUIC WG
Emne: Re: QUIC ossification
 
On Thu, Feb 14, 2019, at 15:48, Jana Iyengar wrote:
> Basically, I'm proposing that QUIC v1 be assigned a random number for = its
> version at RFC publication time.

What property do you expect that to provide?

> Anyone who wants to use a different version for v1 MUST request it fro= m IANA first before using it in the wild.

This too. What does this achieve?

I get that there seems to be the emerging view that unmanaged codepoint spa= ce is not good and we should ask IANA to manage it for us, but I don't unde= rstand what these proposals would provide.

--_000_DB6PR10MB1766CDECAEED8E8391F61CD4AC670DB6PR10MB1766EURP_-- From nobody Wed Feb 13 23:44:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B341613102D for ; Wed, 13 Feb 2019 23:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 UgcrwyUSaUCM for ; Wed, 13 Feb 2019 23:43:58 -0800 (PST) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A493312D7F8 for ; Wed, 13 Feb 2019 23:43:58 -0800 (PST) Received: from eggert.org (unknown [62.248.255.8]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 8DFBD3003F for ; Thu, 14 Feb 2019 09:43:56 +0200 (EET) Received: from slate.eggert.org (pf.eggert.org [172.16.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id C08B7885A59 for ; Thu, 14 Feb 2019 09:43:46 +0200 (EET) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_688ECF12-25CF-448F-8932-BD8AEB205F8D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Reply-To: Lars Eggert , =?utf-8?B?SsO2cmcgT3R0?= Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: 2nd academic workshop on QUIC (EPIQ'19) Message-Id: Date: Thu, 14 Feb 2019 09:43:46 +0200 To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) X-MailScanner-ID: C08B7885A59.A1D3A X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 07:44:01 -0000 --Apple-Mail=_688ECF12-25CF-448F-8932-BD8AEB205F8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, if you are doing R&D related to the QUIC protocol, please consider = submitting your work to the next instance of our workshop on the = evolution, performance, and interoperability of QUIC (EPIQ'19), which = will happen in conjunction with the main ACM SIGCOMM conference in = Beijing in August. EPIQ solicits two types of submissions for presentation and discussion = at the workshop: academic papers and posters & demos. See = http://conferences.sigcomm.org/sigcomm/2019/workshop-epiq.html Lars --Apple-Mail=_688ECF12-25CF-448F-8932-BD8AEB205F8D 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlxlHDIACgkQVLXDCb9w wVfslBAA2HNJZMOn7GppDVFxKMzhfWR1VIoKwtjCfDFFz0ZPwzNMSoYMxQH64K+f 117E+hc6D0Gdcit1GtZNEoVd6HMQBhX5V4UuPmRKi9ofQtvfpx86Qj7Gnq4tx/e9 Yd9EmHDBekO7ewzhZ7usNffRb8cx97zuqoemn6oMw2XTT5d4SsAumDrxDHxhk/Qu 5QlwS0fLxbC8sbl4gXZGyOlBR3fVLV02NRRAt+i8ln0pcirpnoVgL17rUgSNladt HAraWPKezu16TbXkHHuG72w+Intm40Vo/GPlJdx5/jkbOer88/xJvtiRxZowJT/j htFwHHlSJ6GvtbgCen+TNOoPkZ6kYHEKulUcM6RyZ7PKGCf4clTyYvrEWi4lyGdf cKbFUO4fjEibX40MdZCaJnIshTsgTOnGj/bkJQVcJKqun/TsgSexj/D8SgbquI8y hG/Jx8hHwz68mlbF1VpKf4iJKVxZacBmQ+2n/yIMFD3rUe313JdryCQs+nYsFnGk DwhDlgyXxpHHbRjyjg2lootDNK8tQ8Z/VtO5FrUvACb6+g3b8Soh6THszg1rgkRj lDholPZiFnEygMjqOkNH5LE/tZG6vbio9AAfFmdXXURO5UtwZg2CvkuAMGLWprZv go9lnr6G4vp1wxEil3YSpdrTw+wUNUyObOvWG3w94k0vKe0ylpI= =2quY -----END PGP SIGNATURE----- --Apple-Mail=_688ECF12-25CF-448F-8932-BD8AEB205F8D-- From nobody Thu Feb 14 08:15:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A205C131088 for ; Thu, 14 Feb 2019 08:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwjcX1TIUovn for ; Thu, 14 Feb 2019 08:15:12 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 7F78512867A for ; Thu, 14 Feb 2019 08:15:12 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id i2so15621703ite.5 for ; Thu, 14 Feb 2019 08:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yCNP++DdemNpjhBcy0NvGcfrbijpwCTSdaVd1noq6Sk=; b=mD32XrS5Cw97HJ8YPdTF5BKeMp3vTTgcc1Z2XJCtWbrOvwP9Wv3kqPK8cYe93ouzEI YdjgAiJJzXpyCtBNNNOMb5pOUAl1P2EoAUVNjPokQLQWsiQ7+MlkFqNcIlpSOxLcJ9vA MTJ6Ti1zS/T8QpDwFLhjJlmuXrjzXtDHhuI+NiRHxQcS991Ie9/Hhiq2wpYd43HgEBWg Ymw2UHjXGCql5zwFN7l1b9UW9sfODr9qGRu1D7v3G4wREkG7Z8G2Uzl4tcpH+JA9H+9e qHQjsipeNLsSYo4KCBP5CdWMuWdu98u3Nfesf5wrwzR3AIGgglStZNlW4hmmdSqpUtEE /JwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yCNP++DdemNpjhBcy0NvGcfrbijpwCTSdaVd1noq6Sk=; b=Lxdm911SylYvjcVofKeDKDxpT2ACK6hOrrrmx74uWQhjZdc1HcYNdnlFDNM30PNlNG J1ot9rpG2cQa2R6k6LkadcVCZHqAS1vtOWyKeSJcsX1+WZBoqInwUudIWXZ7yRCr46WF W0xI1f2odbZd6N4ThRNHiSb64qVxbu7lDbuicq9Oq4PNHvG9Ow80Ni1Ubhoxc/XnqzBh VKG9QBEHuOhxrxBeWMM4Y6MMO4pT9boUPyGwrNKZf3ScpQRCv3ZMQT47zZI18Pi22aR6 bTe8qs6a9wpUeQofVAdki0/iZfB9iey8M79sWvyXENQl752Ioo185HcFGesaZwa20A4n O1pA== X-Gm-Message-State: AHQUAubQRC3Fka9tyl77DIqJyT/PIpy5ofvSEWicBOtekktB+MEm3/DB tAg9MiPYwoSSh98cFc6RzzhSVSeRXI76ALZ1NWtClA== X-Google-Smtp-Source: AHgI3IYimVoHmukPoX2msBuRxoR1N8ua5H4kECSAwAJ6mfJFVHgD3cn2dcqQejSz7ZoDD7Rx14JwhwkjHg5x7g94t4I= X-Received: by 2002:a24:30c:: with SMTP id e12mr271497ite.1.1550160911428; Thu, 14 Feb 2019 08:15:11 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <1550101618.3002483.1657568864.062669F6@webmail.messagingengine.com> In-Reply-To: <1550101618.3002483.1657568864.062669F6@webmail.messagingengine.com> From: Ted Hardie Date: Thu, 14 Feb 2019 08:14:44 -0800 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000787cdc0581dcf6c2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 16:15:17 -0000 --000000000000787cdc0581dcf6c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2019 at 3:47 PM Martin Thomson wrote: > On Thu, Feb 14, 2019, at 04:17, Ted Hardie wrote: > > On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> > > wrote: > > > > > There is the risk that middle boxes learn that versions mean nothing, > and > > > that they are all the same, akin to crying wolf. > > > > I tend to agree with this. Version numbers should shift when the > > interoperability among parties to the protocol shifts. While you can > > artificially create that shift in closed system, teaching the ecosystem > > that the shifts are meaningless doesn't seem to advance the general goa= l. > > If I understand David's proposal, these versions would have meaningful > changes, or at least changes that go beyond the version number. In TLS h= e > has suggested a similar technique, with changes that are not compatible, > but relatively easy to implement. For instance, changing the salt for th= e > Initial keys would be trivial to implement and make the protocol > indecipherable. Changing the salt is the kind of thing I had in mind for "artificially create that shift." That's easy to do in a closed system; it's possible in a standards-based one, but the overall impact on functionality is so low, that the rate of uptake will be low. So you will do version negotiation down to the old version a lot of the time, I'm guessing. > Switching to ChaCha20-Poly1305 instead of AES-128-GCM would be another. > He also suggested that we reorder key fields, switch endianness of variou= s > encodings, rot13 extension codepoints, ... plus whatever you can imagine. > As long as it is easier to respond correctly to new versions than it is t= o > build specific handling for every new permutation, the protocol designers > win. > > Now, I'm not sure if that is as good as having a good reason to deploy a > new version, but there you are. > > As a personal opinion, I think we have enough semantic additions to do here that we don't need an artificial version which will have no natural driver of adoption. Ted --000000000000787cdc0581dcf6c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 13, 2019 at 3:47 PM Martin Th= omson <mt@lowentropy.net> wr= ote:
On Thu, Feb 14, 2019, at 04:17, Ted Hardie wrote:
> On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <= mikkelfj@gmail.com<= /a>>
> wrote:
>
> > There is the risk that middle boxes learn that versions mean noth= ing, and
> > that they are all the same, akin to crying wolf.
>
> I tend to agree with this. Version numbers should shift when the
> interoperability among parties to the protocol shifts.=C2=A0 While you= can
> artificially create that shift in closed system, teaching the ecosyste= m
> that the shifts are meaningless doesn't seem to advance the genera= l goal.

If I understand David's proposal, these versions would have meaningful = changes, or at least changes that go beyond the version number.=C2=A0 In TL= S he has suggested a similar technique, with changes that are not compatibl= e, but relatively easy to implement.=C2=A0 For instance, changing the salt = for the Initial keys would be trivial to implement and make the protocol in= decipherable.

=C2=A0 Switching to= ChaCha20-Poly1305 instead of AES-128-GCM would be another.=C2=A0 He also s= uggested that we reorder key fields, switch endianness of various encodings= , rot13 extension codepoints, ... plus whatever you can imagine.=C2=A0 As l= ong as it is easier to respond correctly to new versions than it is to buil= d specific handling for every new permutation, the protocol designers win.<= br>
Now, I'm not sure if that is as good as having a good reason to deploy = a new version, but there you are.



=
Ted
=C2=A0
--000000000000787cdc0581dcf6c2-- From nobody Thu Feb 14 09:57:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8BC128CE4 for ; Thu, 14 Feb 2019 09:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBqSb4_h8tje for ; Thu, 14 Feb 2019 09:57:15 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 2CB5312867A for ; Thu, 14 Feb 2019 09:57:15 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id n22so3469307pfa.3 for ; Thu, 14 Feb 2019 09:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WnwusM2M4J0YHNmFijlsdXfmdWexIMXVo1Zl7xvSsqA=; b=cACxjy0rqeKdxtERHTyux2/54ZyUk7+HpwXgU0ME8rvwWJSjAkBZXXc4EIKFXoJtLt h1RTYRZCkkRrJHXiYTbAl19nixyg9ombcoRFRVDTFOmR5Xy42c/yzOfmhsoKjZYGH6RI ubY7UcZDLa/uwJw0YwtpE+sDJiNiVrFXypxltYpmREGwOay6e+lTqJ9KaqENt83joiXU xIyEunh9WKCkDzEjE88SsxOBa31t5EDsGDnS4fNTHbX0cUDYGY5krs6J34i6K1kvWbfW tl6v02hoMXuluag7UyIg+Q//GT3Yq6FaNMgBC3nuEfj1fWcV7To6WOHUwrrKgHh0d3NO NRVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WnwusM2M4J0YHNmFijlsdXfmdWexIMXVo1Zl7xvSsqA=; b=ZG84gusQG09KOGXrvUMqn3PwdayeX5tIVrwQHEHrFGNHKe/rXG7gvhIId+1qhieBoU A0AJCkPCKjkNgrmoFKT7Z188o1pCsjFQkmhSNmdVqx9H93oLS1l7pA7Esj33cPJtYcq8 LmqnK7dFJUYBrYTLl3cOt5CbH47SlZQ2RhLn/sqTBUQRLOsLg6nZY5lPAbQSrvOlvcvY bYa8e8e3rW2p0Xc+oe0F95Mkd15gQRdLIsyH67vxeK4pZaqVNRfChuUeCj05rwOrx5j/ 04H1WTKXi/dJQJWvrTWcQIKR6XeCIX0cM6g8H+OqzPG1dEUfIJReJHh+iVzoSo/Vpudq AM0w== X-Gm-Message-State: AHQUAuZJTVNxNq6ubaoPomGdd6wsTJbSCKik9bJtOEkgNqBxTtMxDSs4 aY5FbCgssUOhPkp7zWIpuG9rr5oXhC2C0TtwZSI= X-Google-Smtp-Source: AHgI3IYT6lT7TFFmtJdxC4xlWS5vf7tbch0X1qxKErhOiN77esHji4aTFieQrkgGZgiY1BoU3gk5cGG3xHLDaIC+9PI= X-Received: by 2002:a63:1753:: with SMTP id 19mr1045892pgx.439.1550167034426; Thu, 14 Feb 2019 09:57:14 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> In-Reply-To: From: David Schinazi Date: Thu, 14 Feb 2019 09:57:02 -0800 Message-ID: Subject: Re: KEYS_READY To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Marten Seemann , Martin Thomson , Jana Iyengar , QUIC WG Content-Type: multipart/alternative; boundary="0000000000006dfc000581de63b6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 17:57:17 -0000 --0000000000006dfc000581de63b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think the proposed PR matches what we discussed in Tokyo, and it seems less robust than what we discussed. In Tokyo we had discussed a RETIRE_KEYS frame with the following properties= : 1) You send RETIRE_KEYS when both (a) you have sent everything you wanted with those keys AND (b) that has been ACKed In particular, the client sends a 1RTT packet with RETIRE_KEYS(Handshake) when the server ACKs the packet containing the crypto frame with the ClientFinished 2) You can discard keys (and congestion control state if applicable) when you've both sent and received RETIRE_KEYS The proposal in PR#2237 does not have these properties, because it focuses on the new keys being ready instead of focusing on when an endpoint is done sending with previous keys. In order to avoid the client infinitely retransmitting ClientFinished issue, PR#2237 has the server delay its 1-RTT KEYS_READY until it believes the handshake is complete. It would be more robust to have the endpoint who is sending decide when it is done sending, instead of having the peer assume it knows. David On Wed, Feb 13, 2019 at 9:44 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I guess because ACK? > > > ------------------------------ > *Fra:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Sendt:* torsdag, februar 14, 2019 6:42 AM > *Til:* Marten Seemann; Martin Thomson > *Cc:* Jana Iyengar; QUIC WG > *Emne:* Re: KEYS_READY > > Why do keys need to be in sync? > Disregarding handshake, if each peer has a separate key index counter, at > change in phase bit ought to be sufficient. > > The endpoints can have vastly different consumption rates. > > With sync keys the peer can prevent you from updating while uou can updat= e > after ca 3 PTO in the async design. Neither design can force the peer to > update. > > > ------------------------------ > *Fra:* QUIC p=C3=A5 vegne af Marten Seemann < > martenseemann@gmail.com> > *Sendt:* torsdag, februar 14, 2019 6:27 AM > *Til:* Martin Thomson > *Cc:* Jana Iyengar; QUIC WG > *Emne:* Re: KEYS_READY > > > I was OK with that PR, and while we might go back and forth on the > merits of using a bit vs. a frame, the consensus in Tokyo was that the > frame was superior. Also, this solves more problems. > > In my understanding, the consensus in Tokyo was based on the assumption > that the bit and the frame were basically signaling the same thing - at > least I wasn=E2=80=99t aware of the additional retransmission logic neces= sary, and > I would=E2=80=99ve opposed this solution if I had known. > > > The PR changes how Initial keys are retired. Instead of relying on the = delivery > of Handshake packets, it relies on the delivery of KEYS_ACTIVE frames. > However, we do not require KEY_ACTIVE frames to be included in every > Handshake packet being sent. > > This is again the problem of a discrete vs. a continuous signal. Using > another bit in the first byte solves this problem. > After the handshake completes, we want the peer to advance from handshake > mode to normal mode in the loss recovery logic, since in handshake mode w= e > don=E2=80=99t have PTOs. The only way to achieve this using the KEYS_ACTI= VE frame > is to include it in multiple (all packets for one RTT?) after the handsha= ke > completes. > > That being said, adding a generation number as Kazuho suggested seems to > be the second best solution, since it at least removes the necessity to > implement separate retransmission rules. > > On Thu, Feb 14, 2019 at 13:05 Martin Thomson wrote: > >> On Thu, Feb 14, 2019, at 15:24, Jana Iyengar wrote: >> > (I've left this comment on the PR as well, but seeing that this >> discussion >> > is happening here as well, echoing it here) >> > If the peer hasn't acked the previous KEYS_ACTIVE, it may not have see= n >> it >> > yet. It is possible that it simultaneously did a key update and sent a >> > KEYS_ACTIVE however. Under this condition, the endpoint wouldn't be >> able to >> > update its keys again, since the peer may close the connection, right? >> >> This is not a problem, but it requires thinking the process through. >> >> An endpoint can only initiate a key update if it has received >> KEYS_ACTIVE. It can only send KEYS_ACTIVE if it has received a key upda= te >> (and is either responding, or initiated that). >> >> Take the example where an ACK is lost, so a key update occurs when one >> peer is retransmitting KEYS_ACTIVE: >> >> C: Update to Key Phase 1. >> S: Update to Key Phase 1. Send KEYS_ACTIVE. >> C: Send packet containing ACK for the server packet containing >> KEYS_ACTIVE, plus KEYS_ACTIVE. That packet is lost. >> C: Update to Key Phase 0. >> S: Update to Key Phase 0. Send KEYS_ACTIVE. >> >> The server might believe that its KEYS_ACTIVE hasn't been acknowledged, >> but it has to be prepared for a key update as soon as it sends the frame= . >> >> If there is a simultanous update it looks like this: >> >> C: Update to Key Phase 1. >> S: Update to Key Phase 1. (Concurrent with previous.) >> C: Receive packet with KP1. Send KEYS_ACTIVE. Lost. >> S: Receive packet with KP1. Send KEYS_ACTIVE. >> >> At this point, both peers are fine, they are on the same keys, and a key >> update can be triggered by the client. The server can't update until th= e >> client repairs the lost KEYS_ACTIVE frame. This continues: >> >> C: Update to Key Phase 0. >> S: Receive KP0. Update to Key Phase 0. Send KEYS_ACTIVE. >> >> As you can see, the client stops sending when it updates again, but >> that's OK. >> >> It's also safe if the KEYS_ACTIVE frames get through, but acknowledgment= s >> for them don't. >> >> --0000000000006dfc000581de63b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think the proposed PR matches what we discusse= d in Tokyo, and it seems less robust than what we discussed.

I= n Tokyo we had discussed a RETIRE_KEYS frame with the following properties:=
1) You send RETIRE_KEYS when both (a) you have sent everything y= ou wanted with those keys AND (b) that has been ACKed
=C2=A0 =C2= =A0 In particular, the client sends a 1RTT packet with RETIRE_KEYS(Handshak= e) when the server ACKs the packet containing the crypto frame with the Cli= entFinished
2) You can discard keys (and congestion control state= if applicable) when you've both sent and received RETIRE_KEYS

The proposal in PR#2237 does not have these properties, be= cause it focuses on the new keys being ready instead of focusing on when an= endpoint is done sending with previous keys.
In order to avoid t= he client infinitely retransmitting ClientFinished issue, PR#2237 has the s= erver delay its 1-RTT KEYS_READY until it believes the handshake is complet= e.
It would be more robust to have the endpoint who is sending de= cide when it is done sending, instead of having the peer assume it knows.

David



I guess because ACK?

=C2=A0
Fra: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Sendt: torsdag, februar 14, 2019 6:42 AM
Til: Marten Seemann; Martin Thomson
Cc: Jana Iyengar; QUIC WG
Emne: Re: KEYS_READY
=C2=A0
Why do keys need to be in sync?
Disregarding handshake, if each peer has a sep= arate key index counter, at change in phase bit ought to be sufficient.

The endpoints can have vastly different consum= ption rates.

With sync keys the peer can prevent you from u= pdating while uou can update after ca 3 PTO in the async design. Neither de= sign can force the peer to update.

=C2=A0
Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne af Marten Seeman= n <martense= emann@gmail.com>
Sendt: torsdag, februar 14, 2019 6:27 AM
Til: Martin Thomson
Cc: Jana Iyengar; QUIC WG
Emne: Re: KEYS_READY
=C2=A0
> I=C2=A0was OK with that PR, and while we= might go back and forth on the merits of using a bit vs. a frame, the cons= ensus in Tokyo was that the frame was superior.=C2=A0 Also, this solves more problems.

In my understanding, the consensus in Tokyo w= as based on the assumption that the bit and the frame were basically signal= ing the same thing - at least I wasn=E2=80=99t aware of the additional retransmission logic necessary, and I would=E2=80= =99ve opposed this solution if I had known.

>=C2=A0The PR changes h= ow Initial keys are retired. Instead of relying on the=C2=A0delivery of Handshake packets, it relies on= the delivery of=C2=A0KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be=C2=A0included in every Handshake packet being sent.

This is again the problem of a discrete vs. a= continuous signal. Using another bit in the first byte solves this problem= .
After the handshake completes, we want th= e peer to=C2=A0advance from handshake mode to normal mode in = the loss recovery logic, since in handshake mode we don=E2=80=99t have PTOs. The only way to achieve this using the KE= YS_ACTIVE frame is to include it in multiple (all packets for one RTT?) aft= er the handshake completes.=C2=A0

That being said, adding a generation number as Kazuho sug= gested seems to be the second best solution, since it at least removes the = necessity to implement separate retransmission rules.

On Thu, Feb 14, 2019 at 13:05 Martin = Thomson <mt@lowen= tropy.net> wrote:
On Thu, Feb 14, 2019, at 15:24, Jana Iyen= gar wrote:
> (I've left this comment on the PR as well, but seeing that this di= scussion
> is happening here as well, echoing it here)
> If the peer hasn't acked the previous KEYS_ACTIVE, it may not have= seen it
> yet. It is possible that it simultaneously did a key update and sent a=
> KEYS_ACTIVE however. Under this condition, the endpoint wouldn't b= e able to
> update its keys again, since the peer may close the connection, right?=

This is not a problem, but it requires thinking the process through.

An endpoint can only initiate a key update if it has received KEYS_ACTIVE.= =C2=A0 It can only send KEYS_ACTIVE if it has received a key update (and is= either responding, or initiated that).

Take the example where an ACK is lost, so a key update occurs when one peer= is retransmitting KEYS_ACTIVE:

C: Update to Key Phase 1.
S: Update to Key Phase 1.=C2=A0 Send KEYS_ACTIVE.
C: Send packet containing ACK for the server packet containing KEYS_ACTIVE,= plus KEYS_ACTIVE.=C2=A0 That packet is lost.
C: Update to Key Phase 0.
S: Update to Key Phase 0. Send KEYS_ACTIVE.

The server might believe that its KEYS_ACTIVE hasn't been acknowledged,= but it has to be prepared for a key update as soon as it sends the frame.<= br>
If there is a simultanous update it looks like this:

C: Update to Key Phase 1.
S: Update to Key Phase 1.=C2=A0 (Concurrent with previous.)
C: Receive packet with KP1.=C2=A0 Send KEYS_ACTIVE.=C2=A0 Lost.
S: Receive packet with KP1.=C2=A0 Send KEYS_ACTIVE.

At this point, both peers are fine, they are on the same keys, and a key up= date can be triggered by the client.=C2=A0 The server can't update unti= l the client repairs the lost KEYS_ACTIVE frame.=C2=A0 This continues:

C: Update to Key Phase 0.
S: Receive KP0.=C2=A0 Update to Key Phase 0.=C2=A0 Send KEYS_ACTIVE.

As you can see, the client stops sending when it updates again, but that= 9;s OK.

It's also safe if the KEYS_ACTIVE frames get through, but acknowledgmen= ts for them don't.

--0000000000006dfc000581de63b6-- From nobody Thu Feb 14 10:13:15 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FBB130E5E for ; Thu, 14 Feb 2019 10:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO25QSLlmI9P for ; Thu, 14 Feb 2019 10:13:11 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 7D2EB13104F for ; Thu, 14 Feb 2019 10:13:11 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id l7-v6so6070199ljg.9 for ; Thu, 14 Feb 2019 10:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FeZXlcHiraHL1YElRuVE3XQp4UDCUUkhCB/43n35WQc=; b=jMt6PfhAlLPKHtwhATKKTjCQyLAmWM2X0GX0LLF2Lgel8YAS7zkFFzaDqJyrhGfzBj 5YFDUwD77ZDYZz4Gv1WQQYzHtIbeSHC0RnpDh9+0vW8k9C7xVZ2sqhuRsR0zSSGk2RVu oYbIbAl0Awaq07pbvUhWH2IM11MafqiAmYBRHaQMgx/1pp8UnsyUX8jQdMiHeQ2pR+Yx tIC4y52nDyJ8lr+WxOspQCRfaIueCsgyhWtRk4vWNZa1wADTECjlDCyXslBle1s7dEmW KccWa1nUvnAalRNreDabhavvNWzYCKHT7UN+9VJJJLMWzSLyvKqeUOcMiqc7L4izqv7b Tkhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FeZXlcHiraHL1YElRuVE3XQp4UDCUUkhCB/43n35WQc=; b=nI8ZI4KwoJMcZ+HfjGI0mfO6d1vOWOevNl61TxpyDt0LBsOpmIRnIma5qwpm5hwSgx hmAi4KJH/1gmNpE72CENEv12qmKHzrqWZfmqwRLMMAN+bmcwKSp0Y8bnwXnWSq5t8RMY vvqeezTtibLY8ftAvW71vG+QaD28E/3Q2FKgEm98hvax9B5VzucdW27XNPhU+yroODfu KK3F70lWpRctlay1hFkCPmPOZFsdTJ8Out3LMicrkuU7a+Xtl6Rn0Ej23asyUlpHHmyP wT95XkXiuhmk7h18czk5zBNYZv7GpNU54IVDF3++vbzTcnhDW1TVIkUTERrdY1OuTRL+ XccQ== X-Gm-Message-State: AHQUAub88JhGIiomon9TE3RBKx+xVFjsdkBBJ9p6ATDVMhibArImTzAj ZGv936xmr5yCuAmP1aKvoBXHK3/yhVHvnuG1qgc= X-Google-Smtp-Source: AHgI3Ib3D1GhgNsvz04gM4TXkth19nG/W/A8ALc040uvkGq4U5sh7iBmF087WAMBI8DdOJhiZ5MijqAlIS2rFmysbOk= X-Received: by 2002:a2e:89d7:: with SMTP id c23-v6mr3394287ljk.0.1550167989366; Thu, 14 Feb 2019 10:13:09 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 14 Feb 2019 12:12:55 -0600 Message-ID: Subject: Re: QUIC ossification To: Christian Huitema Cc: Ted Hardie , Roberto Peon , David Benjamin , Martin Duke , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary="00000000000059364a0581de9c0e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:13:14 -0000 --00000000000059364a0581de9c0e Content-Type: text/plain; charset="UTF-8" Hi, Christian, Thanks for the reply (which made perfect sense to me, and was helpful to me), but I was also asking the question below (which may have not popped out as the thread continued). So, backing up to this note: On Wed, Feb 13, 2019 at 12:02 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Christian, > > On Wed, Feb 13, 2019 at 11:28 AM Christian Huitema > wrote: > >> How about an IANA registry of version numbers, tied to the extension >> process? >> > > Asking as an individual - ISTM that QUIC might go through version numbers > quickly enough to make a registry for version numbers a Good Thing, but > could you help me understand how this helps discourage middleboxes blocking > everything but QUICv1? > > I'm sure I'm missing something here ... > I had guesses about why you suggested a registry, but I was guessing, and thought it better to ask what you were thinking. Thanks, Spencer --00000000000059364a0581de9c0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Christian,=C2=A0

Thanks for the reply (which made perfect sense to me, and = was helpful to me), but I was also asking the question below (which may hav= e not popped out as the thread continued). So, backing up to this note:=C2= =A0

On Wed, Feb 13, 2019 at 12:02 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>= wrote:
Hi, Christian,=C2=A0

On Wed, Feb 13, 2019 at 11:28 AM Christia= n Huitema <huit= ema@huitema.net> wrote:
How about an IANA registry of version numb= ers, tied to the extension process?

A= sking as an individual - ISTM that QUIC might go through version numbers qu= ickly enough to make a registry for version numbers a Good Thing, but could= you help me understand how this helps discourage middleboxes blocking ever= ything but QUICv1?

I'm sure I'm missing=C2= =A0something here ...

I had guesses about why you suggested a registry, but I was guessing, and = thought it better to ask what you were thinking.

T= hanks,

Spencer=C2=A0
--00000000000059364a0581de9c0e-- From nobody Thu Feb 14 11:09:00 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8B21288BD for ; Thu, 14 Feb 2019 11:08:58 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3ayWNpM1047 for ; Thu, 14 Feb 2019 11:08:53 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FFC12EB11 for ; Thu, 14 Feb 2019 11:08:53 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1guMNN-000A6b-VI for quic@ietf.org; Thu, 14 Feb 2019 20:08:51 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1guMNH-0001oV-G7 for quic@ietf.org; Thu, 14 Feb 2019 14:08:47 -0500 Received: (qmail 18211 invoked from network); 14 Feb 2019 19:08:40 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Feb 2019 19:08:39 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-5B1FFA49-CEC1-4656-A15C-3919FF4E0279 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Thu, 14 Feb 2019 09:08:38 -1000 Cc: Ted Hardie , Roberto Peon , David Benjamin , Martin Duke , Ian Swett , David Schinazi , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Thomson Content-Transfer-Encoding: 7bit Message-Id: <5C8412E5-8155-4F15-B463-2AEB90F2B627@huitema.net> References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> To: Spencer Dawkins at IETF Subject: Re: QUIC ossification X-Originating-IP: 168.144.250.215 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.19) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5oEOcegWaM6wxAxBNlIDm3h602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViR0vmiJiQkx1bxOiTXO7eYc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuzDn5j2tUhjYPVPi3bwTCB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaJwAHPn4EuYWIk0YD/RIopTqpzxuZ/FKz4x4mg8I92kblBSmbkFzm5t EoNq+rVNpFpk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlo4nwaEJvK5+6Pe7PRp6P6hZYSpQQtCkh8qZ SV0LCxteTwTxMnoiX9dD+uh7mToyw1Um5gxkzZgW7+Wcynj1FKYhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uKyB9lEOTMC1CDeyRjdgy1+29UshveVgoiypAicYsWUtdkye6uEH7Y2FUSOL4 rzI+g44cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:08:59 -0000 --Apple-Mail-5B1FFA49-CEC1-4656-A15C-3919FF4E0279 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 > On Feb 14, 2019, at 8:12 AM, Spencer Dawkins at IETF wrote: >=20 > Hi, Christian,=20 >=20 > Thanks for the reply (which made perfect sense to me, and was helpful to m= e), but I was also asking the question below (which may have not popped out a= s the thread continued). So, backing up to this note:=20 >=20 >> On Wed, Feb 13, 2019 at 12:02 PM Spencer Dawkins at IETF wrote: >> Hi, Christian,=20 >>=20 >>> On Wed, Feb 13, 2019 at 11:28 AM Christian Huitema = wrote: >>> How about an IANA registry of version numbers, tied to the extension pro= cess? >>=20 >> Asking as an individual - ISTM that QUIC might go through version numbers= quickly enough to make a registry for version numbers a Good Thing, but cou= ld you help me understand how this helps discourage middleboxes blocking eve= rything but QUICv1? >>=20 >> I'm sure I'm missing something here ... >=20 > I had guesses about why you suggested a registry, but I was guessing, and t= hought it better to ask what you were thinking. Communication between implementations. The point was already made in the thr= ead. Rotation was easy in gQuic because there was only one implementation. I= f we want rotation between multiple teams, an IANA registry does that. I think rotation will also require clients to maintain a cache of the last v= ersion supported by a server. The synchronization process could work like th= is: 1) client implements the new version, keeps proposing the old one. 2) server implements the new version, documents it in list of supported vers= ions in transport parameters. 3) client connects to server with old version, notices that new version is s= upported, remembers that. 4) client uses new version for next connection. -- Christian Huitema=20 > =20 --Apple-Mail-5B1FFA49-CEC1-4656-A15C-3919FF4E0279 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable  

On Feb 14, 2= 019, at 8:12 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

=
Hi, Christian, 

Thanks for the re= ply (which made perfect sense to me, and was helpful to me), but I was also a= sking the question below (which may have not popped out as the thread contin= ued). So, backing up to this note: 

On Wed, Feb 13, 2019 at 12:02 PM Spen= cer Dawkins at IETF <spe= ncerdawkins.ietf@gmail.com> wrote:
Hi, Christian, 

=
On Wed, Feb= 13, 2019 at 11:28 AM Christian Huitema <huitema@huitema.net> wrote:
How about an IAN= A registry of version numbers, tied to the extension process?

Asking as an individual - ISTM that QUIC might go th= rough version numbers quickly enough to make a registry for version numbers a= Good Thing, but could you help me understand how this helps discourage midd= leboxes blocking everything but QUICv1?

I'm sure I'= m missing something here ...
I had guesses about why you suggested a registry, but I was gues= sing, and thought it better to ask what you were thinking.
=

Communication between implementations. The= point was already made in the thread. Rotation was easy in gQuic because th= ere was only one implementation. If we want rotation between multiple teams,= an IANA registry does that.

I think rotation will also r= equire clients to maintain a cache of the last version supported by a server= . The synchronization process could work like this:

1) client implements the new version, keeps proposing the old one.

2) server implements the new version, documents it in list o= f supported versions in transport parameters.

3) cl= ient connects to server with old version, notices that new version is suppor= ted, remembers that.

4) client uses new version for= next connection.

-- Christian Huitema 
<= div>
 
= --Apple-Mail-5B1FFA49-CEC1-4656-A15C-3919FF4E0279-- From nobody Thu Feb 14 11:58:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E50128D52 for ; Thu, 14 Feb 2019 11:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01KZUFq7Vjof for ; Thu, 14 Feb 2019 11:58:40 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 D8F5A127287 for ; Thu, 14 Feb 2019 11:58:39 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id w6so1585612ljd.7 for ; Thu, 14 Feb 2019 11:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yIgClOM8ciJSL7TG+7kSSyHNSSb6F1/talKrX5hAPo4=; b=MZ9F8NBSQ68SGDBQvigT4kTviYHTvvp3ymnF+Z0yfFh508J0CWSgRGj2DWb57tRvrv AkvgtJgeXH8gOCBh6DX7KmFGrVfSLRXr1KQeNYaUTpC8wry/LscGdBPsrbPGwrR671cf CUgiv2dhDCuFLsS32+cfxFIUJYgBJ24/suLOPZr4OgjhTReA3mykmXArMd1XcptOrR2n ud996l5fTOl0UBPmpll9dN1wb5vtHdtDGa+zmqOeI5sfkqrsNZzsyrjrwCk62wiubPdf s3n5bwCV79So79jwaZL7wIRMvraQn/HN7N54yUSFOjf1c9YOH6GGzjMl98eGZ1FJzxGB vDBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yIgClOM8ciJSL7TG+7kSSyHNSSb6F1/talKrX5hAPo4=; b=eCA7tYYH8eYAegy9njfLPjNnRj9TU3OXUe4kf9VxnfK6V8UoOu1z5C1gz2bUx4fidl x14iebb+4q2gq+3eKH8uNEjTlHUGPzSufAC/f7X6TD9Gcp4DnTXKPK7/b6YkI3RrxC5t ald8IgoYehfiVqAI6UtTbOdqBVU1rsecG6wvWCM0qfY178+aTRGciTGalJkrBvXP01et gNQVVBKlCJXcFFf1/BUvog0AUBmafyXOnQSgU69yym1ptRaeidC/cEw1xdAEcPVDo4nQ s+JQuirEDNaaWqlqcyYJv4he0oShtGUZfihdNKDT9UdrkEcXZogcQ2Vq6rVfXF5GThrV gi9Q== X-Gm-Message-State: AHQUAuYEaK01kMyISX+MMEWWN2xbDIDtj6+oPYgxB9hJ5Cdwy264UB0E oUUBscsomcVDJoRgSo1TYu7zo2knIvgOdcmL4nw= X-Google-Smtp-Source: AHgI3Ibe4cImb78P1G4A+4DpQDQ0T4L0QONhvAM91Mu735kqmFoh33LdvwR2hAqO44kRvpophZedwYxqL16V9xXuQsg= X-Received: by 2002:a2e:9f49:: with SMTP id v9mr3425831ljk.77.1550174317952; Thu, 14 Feb 2019 11:58:37 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <5C8412E5-8155-4F15-B463-2AEB90F2B627@huitema.net> In-Reply-To: <5C8412E5-8155-4F15-B463-2AEB90F2B627@huitema.net> From: Spencer Dawkins at IETF Date: Thu, 14 Feb 2019 13:58:24 -0600 Message-ID: Subject: Re: QUIC ossification To: Christian Huitema Cc: Ted Hardie , Roberto Peon , David Benjamin , Martin Duke , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000008fc3430581e015e9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:58:42 -0000 --0000000000008fc3430581e015e9 Content-Type: text/plain; charset="UTF-8" Hi, Christian, On Thu, Feb 14, 2019 at 1:08 PM Christian Huitema wrote: > > > On Feb 14, 2019, at 8:12 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Hi, Christian, > > Thanks for the reply (which made perfect sense to me, and was helpful to > me), but I was also asking the question below (which may have not popped > out as the thread continued). So, backing up to this note: > > On Wed, Feb 13, 2019 at 12:02 PM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Hi, Christian, >> >> On Wed, Feb 13, 2019 at 11:28 AM Christian Huitema >> wrote: >> >>> How about an IANA registry of version numbers, tied to the extension >>> process? >>> >> >> Asking as an individual - ISTM that QUIC might go through version numbers >> quickly enough to make a registry for version numbers a Good Thing, but >> could you help me understand how this helps discourage middleboxes blocking >> everything but QUICv1? >> >> I'm sure I'm missing something here ... >> > > I had guesses about why you suggested a registry, but I was guessing, and > thought it better to ask what you were thinking. > > > Communication between implementations. The point was already made in the > thread. Rotation was easy in gQuic because there was only one > implementation. If we want rotation between multiple teams, an IANA > registry does that. > Ah. That helps. I was thinking about it from the other perspective - there's an IANA registry for QUIC versions because new ones appear so often, and if you want to block stuff off your network when you have no idea what it is, feel free to block stuff that's not in the registry, but the versions being added in the registry are specified and people are trying to use them, so sooner or later, you'll get tired of changing your firewalls to accept new versions. The point elsewhere in the thread about having a few large traffic sources using multiple versions was also helpful. Spencer I think rotation will also require clients to maintain a cache of the last > version supported by a server. The synchronization process could work like > this: > > 1) client implements the new version, keeps proposing the old one. > > 2) server implements the new version, documents it in list of supported > versions in transport parameters. > > 3) client connects to server with old version, notices that new version is > supported, remembers that. > > 4) client uses new version for next connection. > > -- Christian Huitema > --0000000000008fc3430581e015e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Christian,=C2=A0

On Thu, Feb 14, 2019= at 1:08 PM Christian Huitema <hu= itema@huitema.net> wrote:
=C2=A0

On Feb 14= , 2019, at 8:12 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com&g= t; wrote:

Hi, Christian,=C2=A0

Thanks for the reply (which made perfect sense to me, and was help= ful to me), but I was also asking the question below (which may have not po= pped out as the thread continued). So, backing up to this note:=C2=A0
=
On Wed= , Feb 13, 2019 at 12:02 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.co= m> wrote:
Hi, Christian,=C2=A0

On Wed, Feb 13, 2019 at 11:28 AM= Christian Huitema <huitema@huitema.net> wrote:
How about an IANA registry of ver= sion numbers, tied to the extension process?

Asking as an individual - ISTM that QUIC might go through version n= umbers quickly enough to make a registry for version numbers a Good Thing, = but could you help me understand how this helps discourage middleboxes bloc= king everything but QUICv1?

I'm sure I'm m= issing=C2=A0something here ...

<= /div>
I had guesses about why you suggested a registry, but I was guess= ing, and thought it better to ask what you were thinking.
=

Communication between implementations. Th= e point was already made in the thread. Rotation was easy in gQuic because = there was only one implementation. If we want rotation between multiple tea= ms, an IANA registry does that.

Ah. T= hat helps.=C2=A0

I was thinking about it from the = other perspective - there's an IANA registry for QUIC versions because = new ones appear so often, and if you want to block stuff off your network w= hen you have no idea what it is, feel free to block stuff that's not in= the registry, but the versions being added in the registry are specified a= nd people are trying to use them, so sooner or later, you'll get tired = of changing your firewalls to accept new versions.

The point elsewhere in the thread about having a few large traffic sources= using multiple versions was also helpful.

Spencer=

I think rotation will also require clients to maintain a= cache of the last version supported by a server. The synchronization proce= ss could work like this:

1) client implements = the new version, keeps proposing the old one.

2) s= erver implements the new version, documents it in list of supported version= s in transport parameters.

3) client connects to s= erver with old version, notices that new version is supported, remembers th= at.

4) client uses new version for next connection= .

-- Christian Huitema=C2=A0
--0000000000008fc3430581e015e9-- From nobody Thu Feb 14 12:34:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFFD131186 for ; Thu, 14 Feb 2019 12:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7J_XZpwLJZw for ; Thu, 14 Feb 2019 12:34:27 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 5A4971311D7 for ; Thu, 14 Feb 2019 12:34:27 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id b11so7774289wmj.1 for ; Thu, 14 Feb 2019 12:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XHluBcollh/ae6ObtZt5jBno0ElgpHSuSMikUe1DEUE=; b=YOWRI8tB66rKbldBNg+CmGabvj4ufypCC2mSe++e7rjyno1Lyim8CdRMTocAL5Ect/ xVXS2JxX5XfaGe+E/H5kNNOaiKdPVrXrR30Y1KZwACZD5UZgsLmr69gbJOCIkRFeUuUa U6PIr2b7jxa68qVlS/1DevswSp+hIy3RPuh6+3m/FHfpk7HHEYcGSzB2K4bmijfwnO0k nWtzwWB6hg9Ydt+hF8ZahqnRdAhof7qJEoaT7tsLqY0SelxH9P2KrLhphmYfuezIXe3U byQMJc3+8g3r5SLCGY2oO3eZ52G6REMgreQrjYBoXxfuX8WN9fchBfRo4kjJQ6r4NLRE EEcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XHluBcollh/ae6ObtZt5jBno0ElgpHSuSMikUe1DEUE=; b=J/2MSmGNVUbmg+/ZWdbju4CHFyPb/ZfBYZofbdoj+AGWAFYRP98Hc+A5vCITGFJfM+ nb648rxqkk1DfKbIMXUHlZ0+QlX3C5GaURoYYcH99QsWXlOGzaRNCaSJARHM2opu6TXg 5D2R9lSXwT3VHz181iYyD53VqF8JvaNcexMHg3cu9EaqkDV67IuES3Fs7h4rEuTyRgrt iPTcTYzHMOLnjRcJ0xX2Ttw+u0iZWjODR7zJBaWoo0QK2yHy2agVeR0VtNJdgVa0PuTm Ve7xK/4B4XgU5i3QkH1SPHZZmIAkJ2DJN8EuSoql5NOOlsS0OJHXxxngo3ni1EubVeNV 6lmA== X-Gm-Message-State: AHQUAubnWkMhXrPyXVh3hJfewUa13ojOYcJOlhHnFdRtIttXW2ef85kd 1xygCNK61+9NmaJ/bHcIKVTI7SoMXy8yntaVGPSJpQ== X-Google-Smtp-Source: AHgI3IZgqKS89HWupSPOSIJVvoUpa5iu+rnppYjRio7EIwZnlqWQqgRohFimBZeXxDDlnTScxQPCJll0g34lfADkFJA= X-Received: by 2002:a1c:9693:: with SMTP id y141mr4186754wmd.33.1550176465376; Thu, 14 Feb 2019 12:34:25 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> In-Reply-To: From: Ryan Hamilton Date: Thu, 14 Feb 2019 12:34:13 -0800 Message-ID: Subject: Re: KEYS_READY To: David Schinazi Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Marten Seemann , Jana Iyengar , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000008f336b0581e095f5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:34:37 -0000 --0000000000008f336b0581e095f5 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 14, 2019 at 9:57 AM David Schinazi wrote: > I don't think the proposed PR matches what we discussed in Tokyo, and it > seems less robust than what we discussed. > > In Tokyo we had discussed a RETIRE_KEYS frame with the following > properties: > 1) You send RETIRE_KEYS when both (a) you have sent everything you wanted > with those keys AND (b) that has been ACKed > In particular, the client sends a 1RTT packet with > RETIRE_KEYS(Handshake) when the server ACKs the packet containing the > crypto frame with the ClientFinished > 2) You can discard keys (and congestion control state if applicable) when > you've both sent and received RETIRE_KEYS > > The proposal in PR#2237 does not have these properties, because it focuses > on the new keys being ready instead of focusing on when an endpoint is done > sending with previous keys. > In order to avoid the client infinitely retransmitting ClientFinished > issue, PR#2237 has the server delay its 1-RTT KEYS_READY until it believes > the handshake is complete. > It would be more robust to have the endpoint who is sending decide when it > is done sending, instead of having the peer assume it knows. > I completely agree with this. The usage of RETIRE_KEYS, as outlined here and in summaries of the discussion in Tokyo that I read, seems simple and clear. --0000000000008f336b0581e095f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 14, 2019 at 9:57 AM David Schinazi <dschinazi.ietf@gmail.com> wrote:
I don't think the proposed PR m= atches what we discussed in Tokyo, and it seems less robust than what we di= scussed.

In Tokyo we had discussed a RETIRE_KEYS frame with th= e following properties:
1) You send RETIRE_KEYS when both (a) you= have sent everything you wanted with those keys AND (b) that has been ACKe= d
=C2=A0 =C2=A0 In particular, the client sends a 1RTT packet wit= h RETIRE_KEYS(Handshake) when the server ACKs the packet containing the cry= pto frame with the ClientFinished
2) You can discard keys (and co= ngestion control state if applicable) when you've both sent and receive= d RETIRE_KEYS

The proposal in PR#2237 does not hav= e these properties, because it focuses on the new keys being ready instead = of focusing on when an endpoint is done sending with previous keys.
In order to avoid the client infinitely retransmitting ClientFinished is= sue, PR#2237 has the server delay its 1-RTT KEYS_READY until it believes th= e handshake is complete.
It would be more robust to have the endp= oint who is sending decide when it is done sending, instead of having the p= eer assume it knows.

I completely agree with this. The usage of RETIRE_KEYS, as outlined here= and in summaries of the discussion in Tokyo that I read, seems simple and = clear.
--0000000000008f336b0581e095f5-- From nobody Thu Feb 14 12:38:58 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE82128D52 for ; Thu, 14 Feb 2019 12:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 ex284NDJZoUp for ; Thu, 14 Feb 2019 12:38:51 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 17AAE1289FA for ; Thu, 14 Feb 2019 12:38:51 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id n32so8422645qte.11 for ; Thu, 14 Feb 2019 12:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5yKmLzFzUKxeb/jGkNo1Gu/sgj8XeMg27/tf33s3B0M=; b=KPgXQk1yqefP+A57V44QJzg+v8s0anz041p28vhEcJApzuuhNHulxsDA4PFCP22mhq 8UraIm2r3CRRVOoNzkvelJ87oi9lUU7mRLT3oUEX0NfXoW8V0cq/EIJNzProGxzOBQbj Bn3FeyG8Mt4RoSy0nNDK1BOA20xasB2nfHOMY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5yKmLzFzUKxeb/jGkNo1Gu/sgj8XeMg27/tf33s3B0M=; b=nntt5uSbukAMI0gYlEpmnstWqsm+gWcNaALnQ95E1IGb5QmdHoQBeJKVCB57Ty0Mtl /k9VUuuC6vG9WmZy2WrhKPFYC7dwf2Ef32PthDxslzp75SBa4+UfZuSBXkwCoWPSeH5M clWM26SkWZZOqDZYQK5cCeltOHdrt4S8JOF4lVS/yfJlM6g2yeOVtltVx7S0SmZYAKmx 0tB9bqQ1vou27C0Z+e+NfQFUZvUvx21CN1d6Lv0ldns9GqeGcsSTeyok875nTt0r8v64 cWDUxtl1dmh1nQXyULqR4Ty95wkPyMGQ2EVjJY/W9ubinRNe0idUpUutvGFZLzU56VVU ZJ1Q== X-Gm-Message-State: AHQUAubQHgEuUp2kAtIGwZ8bsIdP5gFSR+aC/jyY6gPRvEwlTBolkP5a Nfy8VuMDqyqgCjQ+4RTY9VHv0/DAIQPF6NKrg4Qa X-Google-Smtp-Source: AHgI3IbndOiFoXCUbVu9kOsQ12ReYkjrmH6SqqsWYNK3IyDyviOy6Bb9zzLXBAU23R7nsOpJtXKrxnKAmqOsctyXUcE= X-Received: by 2002:a0c:d283:: with SMTP id q3mr4514020qvh.67.1550176729951; Thu, 14 Feb 2019 12:38:49 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> In-Reply-To: From: David Benjamin Date: Thu, 14 Feb 2019 14:38:37 -0600 Message-ID: Subject: Re: QUIC ossification To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , Jana Iyengar , QUIC WG Content-Type: multipart/alternative; boundary="0000000000005458e20581e0a588" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:38:53 -0000 --0000000000005458e20581e0a588 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At least in the TLS incarnation of this idea, yes, the point would be to support both V1 (for normal clients) and the rolling version. That does not require the client reject V1 for this to work, presuming your version negotiation has downgrade protection. (Being forced onto a version other than what you would have naturally negotiated is a downgrade.) I'm not familiar with QUIC's negotiation mechanisms, but I certainly hope you all are downgrade-protected. That's generally important independent of these kinds of games. David On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Version of the month is problematic: > > Google server would need to support a basic V1, otherwise non-chrome user > agents would fail. Chrome browsers would have to reject V1 or the greasin= g > won=E2=80=99t work. This can only happen towards Google servers. Middlebo= xes now > check for V1 or Google domain. Eith future encrypted request domain, it i= s > a perfect wsy to firewall Google via Chrome. Users switch to other browse= r. > > > ------------------------------ > *Fra:* QUIC p=C3=A5 vegne af Martin Thomson < > mt@lowentropy.net> > *Sendt:* torsdag, februar 14, 2019 6:08 AM > *Til:* Jana Iyengar > *Cc:* QUIC WG > *Emne:* Re: QUIC ossification > > On Thu, Feb 14, 2019, at 15:48, Jana Iyengar wrote: > > Basically, I'm proposing that QUIC v1 be assigned a random number for > its > > version at RFC publication time. > > What property do you expect that to provide? > > > Anyone who wants to use a different version for v1 MUST request it from > IANA first before using it in the wild. > > This too. What does this achieve? > > I get that there seems to be the emerging view that unmanaged codepoint > space is not good and we should ask IANA to manage it for us, but I don't > understand what these proposals would provide. > > --0000000000005458e20581e0a588 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At least in the TLS incarnation of this idea, yes, the poi= nt would be to support both V1 (for normal clients) and the rolling version= . That does not require the client reject V1 for this to work, presuming yo= ur version negotiation has downgrade protection. (Being forced onto a versi= on other than what you would have naturally negotiated is a downgrade.)
I'm not familiar with QUIC's negotiation mechanisms= , but I certainly hope you all are downgrade-protected. That's generall= y important independent of these kinds of games.

Dav= id

= On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Version of the month is problematic:

Google server would need to support a basic V1= , otherwise non-chrome user agents would fail. Chrome browsers would have t= o reject V1 or the greasing won=E2=80=99t work. This can only happen toward= s Google servers. Middleboxes now check for V1 or Google domain. Eith future encrypted request domain, it is a per= fect wsy to firewall Google via Chrome. Users switch to other browser.

=C2=A0
Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne af Martin Thomson &= lt;mt@lowentropy.net= >
Sendt: torsdag, februar 14, 2019 6:08 AM
Til: Jana Iyengar
Cc: QUIC WG
Emne: Re: QUIC ossification
=C2=A0
On Thu, Feb 14, 2019, at 15:48, Jana Iyengar wrote:
> Basically, I'm proposing that QUIC v1 be assigned a random number = for its
> version at RFC publication time.

What property do you expect that to provide?

> Anyone who wants to use a different version for v1 MUST request it fro= m IANA first before using it in the wild.

This too. What does this achieve?

I get that there seems to be the emerging view that unmanaged codepoint spa= ce is not good and we should ask IANA to manage it for us, but I don't = understand what these proposals would provide.

--0000000000005458e20581e0a588-- From nobody Thu Feb 14 12:39:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E2A1311B6 for ; Thu, 14 Feb 2019 12:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WU0npzWzFYX for ; Thu, 14 Feb 2019 12:38:53 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760093.outbound.protection.outlook.com [40.107.76.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A085612D4F2 for ; Thu, 14 Feb 2019 12:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g6vvXxJ8tQRJGMwzUpgLHfSTW4oTfE/tpxFsZJbG0/I=; b=Yi+XxJlYSPlTgHnv0IN6yR6YNiDlnV00K6UXZkGfBEQkB25HBa3zAX7zqr5qUQxS712pXk7CXBiQgoc58DarR3s7PmU9FAxErgxL2seJJEyI2dx9dSOohNVkCuJHC2M9ripjhr4ol/tgnmCwWtEF0UUVoKVFlxHg51YdHmWd4lQ= Received: from MWHPR22MB0991.namprd22.prod.outlook.com (10.171.145.21) by MWHPR22MB0093.namprd22.prod.outlook.com (10.168.249.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Thu, 14 Feb 2019 20:38:49 +0000 Received: from MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::31b1:b2c0:74a2:772e]) by MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::31b1:b2c0:74a2:772e%5]) with mapi id 15.20.1601.023; Thu, 14 Feb 2019 20:38:49 +0000 From: Mike Bishop To: Ryan Hamilton , David Schinazi CC: Marten Seemann , Jana Iyengar , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , QUIC WG , Martin Thomson Subject: RE: KEYS_READY Thread-Topic: KEYS_READY Thread-Index: AQHUwz3pxR+WCqZrW06dl1IlLgtz0aXdOu0AgAAs74CAAEmagIAAIpCAgAAGk4CAAAC7AIAABWuAgAAB3gCAACgNgIAAQIGAgABJrACAABS8gIAABsIAgAADhICAAAt+gIAABh+AgAAENYCAAABqAIAAzM8AgAAr64CAAACDUA== Date: Thu, 14 Feb 2019 20:38:49 +0000 Message-ID: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b0946074-be9f-45e1-5fa0-08d692bc6cc7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0093; x-ms-traffictypediagnostic: MWHPR22MB0093: x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39830400003)(396003)(376002)(136003)(366004)(199004)(189003)(3846002)(561944003)(66066001)(7116003)(25786009)(26005)(790700001)(6116002)(7736002)(53936002)(229853002)(86362001)(66574012)(55016002)(6506007)(53546011)(97736004)(6246003)(316002)(102836004)(106356001)(33656002)(6436002)(9686003)(105586002)(54896002)(6306002)(236005)(4326008)(256004)(446003)(11346002)(14454004)(476003)(2906002)(71200400001)(71190400001)(68736007)(54906003)(110136005)(74482002)(8936002)(14444005)(74316002)(81156014)(8676002)(76176011)(81166006)(486006)(508600001)(186003)(93886005)(7696005)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR22MB0093; H:MWHPR22MB0991.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtNV0hQUjIyTUIwMDkzOzIzOk9STUFZdmxVWkQvdTBIczZGNWxtMDhTWHN4?= =?utf-8?B?OVptSjc3eFVuWGNIUmovREFieVpjUWJJR21kdDYvN3RqbjlGK0ppWGhGTXV4?= =?utf-8?B?U1MwU1ZVSG5MeUNMYnMwZnJKR3dhRTdxa3RJS1UwOW5COUliZ0dDRHZxUmdz?= =?utf-8?B?Y1N2RUJnV3ZJekNpL3k2blIzdjR0ZDJ4OG4zOXNDTUVsRkFkZUgvQU5EbEQ0?= =?utf-8?B?bFZsUEFXUTZ6ZFUyNm9WTXVORWw4TTBuLzJCTXBVZU5iM1VsZ3dtb05DOXJE?= =?utf-8?B?dkxyVzUrY0R1K0k2cURYbmJNSHh4SzV2eU83YkRkdUM3bWREY3BueTNXeWtm?= =?utf-8?B?OGwzTE1Id0lsaDN0SG1iTmR2WE81dWtoN1F5K0xMbWVFVWZRSmxIT2xaRnFP?= =?utf-8?B?VE16VFB1RzhKY0FGRDRGMHFzUGhyNTBmb3R3N0xyd045QndTV3lQTTBkck5k?= =?utf-8?B?b2VxZkZZOXVSVGtsNjk2NjlqQ09PcEx2YU5KenZzTHJWMHI2cWhDSGR5ZTJH?= =?utf-8?B?cU8xUGFsUXMyZFhGQ0ZtYURJdW0zTWZiOWZQQnNTc1RYNDFLVlBDc3NZaWVE?= =?utf-8?B?ZG4zd1BuaWNCTVpBSWlYNUozMEdhcjJSeXl0dlE3WjFjWXFhdHVMcDJJMTA5?= =?utf-8?B?aEtvN0Y4ejR1eEgwWUQ5SEZYK1J4ek1pMlFnZXlvTjB0WFJsL0xxWU0rZERQ?= =?utf-8?B?MkpMV3BPcnUwdENkdk9rcDRrTjN5MVdNOERNMW0reWpTZkU3TVZKRlg2VGlp?= =?utf-8?B?V0k0b3NjQVhSdkFnUGFqQi9XTlcvb2dCSktpQ2xoa0YzMUdjTWVvcFJQeFg1?= =?utf-8?B?VkN5WFFndlpzczR6Uzl1ckd5UGVRZ28zdzh6VGVGUjFIay9iSkJGWFdJckNT?= =?utf-8?B?WXgwaUZ6a3lESzJTMjQvcWFJSUVMR0gvdHlyZWxrUzRkTC9UZFRJbkUzaEN1?= =?utf-8?B?cnJOWURLOWVsVW5ibnNteWFyWW5yVmFBdUtleTNsUC9TdEplbDlLd2VTS3h4?= =?utf-8?B?Q0RnU3JKN1lIakJZMG9YdWZ2QWM2WnlxTHVIeHJkK3JYZUVMK2UydGV3VmZm?= =?utf-8?B?M01VejhBVFZXUGhWbTZ4UCsxTkxaQXQ3dFQ1bVhmUXNmRUFDUW4xWkxkaWZw?= =?utf-8?B?VzFvYTFOSHF6anBjN1YvVkw1aERGelJDbStkL2dQcnBHOGhQYkNaUWI5Qi9p?= =?utf-8?B?M2VGb2N4eFBqa0VsVVBqZjZZZ1g5Q0NQZzQrN3hPZFhLU1BRL3Q4eVpJNXZY?= =?utf-8?B?NVVKdG1KbUZuVitCbTVsTHRXck52UFZkVkhTbEZQNC8xK1BzNlNJeHhobHZQ?= =?utf-8?B?YzgxNElLc3hpR1pGUnpuaTVyRC9IRjdwV1lEYXZwUHhBL3JiYk96Zy9pZmh0?= =?utf-8?B?ZERwdktTSXc4SDVWYmhMUS9uYTdTTS9PbzNwQzhpRGxSa2RQZVE2WU1sbG02?= =?utf-8?B?QjAyNjdCQjRXWDFiWXdFSUtQa1liVFdubXJ6NUZlME4zZUJnb0xVZ1FMRXo2?= =?utf-8?B?Z2lqMFBnQTZpVzFWVU5UL2Yxc3hNZTNzMDl3a0krKzBwVk9OSjliaUEvVERO?= =?utf-8?B?NVJ5VG5FSGpxdklBNUlOZWFhTS8rQXgrQzBsL2szQmcxVHltcytWSVdTZnVW?= =?utf-8?B?NUpjSEpzTHdWOUpPNnBpdzBkMklPWG5kamQrRGxyeS9TRTdzd3ZWRHZsQlNa?= =?utf-8?B?bGdQWnIvYnpTQkQyWC9sTTRhZzJabHhrUWQ4cFpFS3lUeXh5ZnJ3cVhLdVY1?= =?utf-8?B?MzZkMUpxeDBmQklUQzJzZ0V3bjlLMlhYbWRpQ2Rrbm95eGlSVHV5RWJiSkJK?= =?utf-8?B?ZzV2SFE1MDFqalR1OExwdDF3bko4dmd6TTJoYzg4eEF2MDFTREZhZm84VjM2?= =?utf-8?Q?UU9h+qfR/Y4=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZH8ZPFOjf3l0VzlB8xRYPYFzsr4B/1HmN7aNJsFMOkZIB2qQoKLetOWAeLua4ieal0ucMzibb+KUvXPW81nc8GUTdJ0JHFT45VotHJUxkmNzY05KxYozY2yKq6cumju8Y0NYDlbfu4yAfWZdc0SHCOB4hUn2F9SuUHFaxKkS3OksjgZzle3GsqmGHdKkrzhgZkBuoWDANqg0ekp5q8+ZHUUKF3fbzFfn90BVGxiX+lZJGYH3zDgoGgtylNwGv9UC2HZRZo0ENQAKRbJtRjC3iRzRk5poXVBajiqIuLBpM7s0DHmCO5Nu0AVfKXMjrK+sgqtkXV1FprrL9rAV3RA7xBwY5LqJnnrx3JWRxpTga7D2uMh3eZS82UUP87OdUKR6wAyQmcV0heopVJxA9VctLWDUR+AI1Nvj7ig5iL7Gl40= Content-Type: multipart/alternative; boundary="_000_MWHPR22MB0991FCD3ADA97790B238E491DA670MWHPR22MB0991namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: b0946074-be9f-45e1-5fa0-08d692bc6cc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 20:38:49.3964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0093 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:39:00 -0000 --_000_MWHPR22MB0991FCD3ADA97790B238E491DA670MWHPR22MB0991namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIHNhbWUgbWVjaGFuaXNtIGNhbi9zaG91bGQgYmUg dXNlZCBmb3IgcG9zdC1oYW5kc2hha2Uga2V5IHVwZGF0ZXMgb3IgaWYgdHdvIHNlcGFyYXRlIG1l Y2hhbmlzbXMgYXJlIG5lZWRlZC4gIFRoZXnigJlyZSB2ZXJ5IHNpbWlsYXIgcHJvYmxlbXMsIGJ1 dCBpdCBzZWVtcyBhcyBpZiB0aGUgcmVxdWlyZW1lbnRzIGFyZSBzbGlnaHRseSBkaWZmZXJlbnQu DQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJ5YW4g SGFtaWx0b24NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNCwgMjAxOSAxMjozNCBQTQ0KVG86 IERhdmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+DQpDYzogTWFydGVuIFNl ZW1hbm4gPG1hcnRlbnNlZW1hbm5AZ21haWwuY29tPjsgSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBn bWFpbC5jb20+OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+ OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHku bmV0Pg0KU3ViamVjdDogUmU6IEtFWVNfUkVBRFkNCg0KT24gVGh1LCBGZWIgMTQsIDIwMTkgYXQg OTo1NyBBTSBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0bzpk c2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkkgZG9uJ3QgdGhpbmsgdGhlIHByb3Bv c2VkIFBSIG1hdGNoZXMgd2hhdCB3ZSBkaXNjdXNzZWQgaW4gVG9reW8sIGFuZCBpdCBzZWVtcyBs ZXNzIHJvYnVzdCB0aGFuIHdoYXQgd2UgZGlzY3Vzc2VkLg0KDQpJbiBUb2t5byB3ZSBoYWQgZGlz Y3Vzc2VkIGEgUkVUSVJFX0tFWVMgZnJhbWUgd2l0aCB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6 DQoxKSBZb3Ugc2VuZCBSRVRJUkVfS0VZUyB3aGVuIGJvdGggKGEpIHlvdSBoYXZlIHNlbnQgZXZl cnl0aGluZyB5b3Ugd2FudGVkIHdpdGggdGhvc2Uga2V5cyBBTkQgKGIpIHRoYXQgaGFzIGJlZW4g QUNLZWQNCiAgICBJbiBwYXJ0aWN1bGFyLCB0aGUgY2xpZW50IHNlbmRzIGEgMVJUVCBwYWNrZXQg d2l0aCBSRVRJUkVfS0VZUyhIYW5kc2hha2UpIHdoZW4gdGhlIHNlcnZlciBBQ0tzIHRoZSBwYWNr ZXQgY29udGFpbmluZyB0aGUgY3J5cHRvIGZyYW1lIHdpdGggdGhlIENsaWVudEZpbmlzaGVkDQoy KSBZb3UgY2FuIGRpc2NhcmQga2V5cyAoYW5kIGNvbmdlc3Rpb24gY29udHJvbCBzdGF0ZSBpZiBh cHBsaWNhYmxlKSB3aGVuIHlvdSd2ZSBib3RoIHNlbnQgYW5kIHJlY2VpdmVkIFJFVElSRV9LRVlT DQoNClRoZSBwcm9wb3NhbCBpbiBQUiMyMjM3IGRvZXMgbm90IGhhdmUgdGhlc2UgcHJvcGVydGll cywgYmVjYXVzZSBpdCBmb2N1c2VzIG9uIHRoZSBuZXcga2V5cyBiZWluZyByZWFkeSBpbnN0ZWFk IG9mIGZvY3VzaW5nIG9uIHdoZW4gYW4gZW5kcG9pbnQgaXMgZG9uZSBzZW5kaW5nIHdpdGggcHJl dmlvdXMga2V5cy4NCkluIG9yZGVyIHRvIGF2b2lkIHRoZSBjbGllbnQgaW5maW5pdGVseSByZXRy YW5zbWl0dGluZyBDbGllbnRGaW5pc2hlZCBpc3N1ZSwgUFIjMjIzNyBoYXMgdGhlIHNlcnZlciBk ZWxheSBpdHMgMS1SVFQgS0VZU19SRUFEWSB1bnRpbCBpdCBiZWxpZXZlcyB0aGUgaGFuZHNoYWtl IGlzIGNvbXBsZXRlLg0KSXQgd291bGQgYmUgbW9yZSByb2J1c3QgdG8gaGF2ZSB0aGUgZW5kcG9p bnQgd2hvIGlzIHNlbmRpbmcgZGVjaWRlIHdoZW4gaXQgaXMgZG9uZSBzZW5kaW5nLCBpbnN0ZWFk IG9mIGhhdmluZyB0aGUgcGVlciBhc3N1bWUgaXQga25vd3MuDQoNCkkgY29tcGxldGVseSBhZ3Jl ZSB3aXRoIHRoaXMuIFRoZSB1c2FnZSBvZiBSRVRJUkVfS0VZUywgYXMgb3V0bGluZWQgaGVyZSBh bmQgaW4gc3VtbWFyaWVzIG9mIHRoZSBkaXNjdXNzaW9uIGluIFRva3lvIHRoYXQgSSByZWFkLCBz ZWVtcyBzaW1wbGUgYW5kIGNsZWFyLg0K --_000_MWHPR22MB0991FCD3ADA97790B238E491DA670MWHPR22MB0991namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZSBzYW1lIG1lY2hh bmlzbSBjYW4vc2hvdWxkIGJlIHVzZWQgZm9yIHBvc3QtaGFuZHNoYWtlIGtleSB1cGRhdGVzIG9y IGlmIHR3byBzZXBhcmF0ZSBtZWNoYW5pc21zIGFyZSBuZWVkZWQuJm5ic3A7IFRoZXnigJlyZSB2 ZXJ5IHNpbWlsYXIgcHJvYmxlbXMsIGJ1dCBpdCBzZWVtcyBhcyBpZiB0aGUgcmVxdWlyZW1lbnRz IGFyZSBzbGlnaHRseSBkaWZmZXJlbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBRVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8 L2I+DQpSeWFuIEhhbWlsdG9uPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAx NCwgMjAxOSAxMjozNCBQTTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgU2NoaW5hemkgJmx0O2RzY2hp bmF6aS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hcnRlbiBTZWVtYW5uICZs dDttYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSZndDs7IEphbmEgSXllbmdhciAmbHQ7anJpLmlldGZA Z21haWwuY29tJmd0OzsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21h aWwuY29tJmd0OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hcnRpbiBUaG9tc29u ICZsdDttdEBsb3dlbnRyb3B5Lm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEtFWVNf UkVBRFk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIFRodSwg RmViIDE0LCAyMDE5IGF0IDk6NTcgQU0gRGF2aWQgU2NoaW5hemkgJmx0OzxhIGhyZWY9Im1haWx0 bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20iPmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0 IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRv bid0IHRoaW5rIHRoZSBwcm9wb3NlZCBQUiBtYXRjaGVzIHdoYXQgd2UgZGlzY3Vzc2VkIGluIFRv a3lvLCBhbmQgaXQgc2VlbXMgbGVzcyByb2J1c3QgdGhhbiB3aGF0IHdlIGRpc2N1c3NlZC48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBUb2t5byB3ZSBoYWQgZGlzY3Vz c2VkIGEgUkVUSVJFX0tFWVMgZnJhbWUgd2l0aCB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBZb3Ug c2VuZCBSRVRJUkVfS0VZUyB3aGVuIGJvdGggKGEpIHlvdSBoYXZlIHNlbnQgZXZlcnl0aGluZyB5 b3Ugd2FudGVkIHdpdGggdGhvc2Uga2V5cyBBTkQgKGIpIHRoYXQgaGFzIGJlZW4gQUNLZWQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgSW4gcGFydGljdWxhciwgdGhlIGNsaWVudCBzZW5kcyBhIDFSVFQgcGFja2V0IHdpdGgg UkVUSVJFX0tFWVMoSGFuZHNoYWtlKSB3aGVuIHRoZSBzZXJ2ZXIgQUNLcyB0aGUgcGFja2V0IGNv bnRhaW5pbmcgdGhlIGNyeXB0byBmcmFtZSB3aXRoIHRoZSBDbGllbnRGaW5pc2hlZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgWW91IGNhbiBk aXNjYXJkIGtleXMgKGFuZCBjb25nZXN0aW9uIGNvbnRyb2wgc3RhdGUgaWYgYXBwbGljYWJsZSkg d2hlbiB5b3UndmUgYm90aCBzZW50IGFuZCByZWNlaXZlZCBSRVRJUkVfS0VZUzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJvcG9zYWwg aW4gUFIjMjIzNyBkb2VzIG5vdCBoYXZlIHRoZXNlIHByb3BlcnRpZXMsIGJlY2F1c2UgaXQgZm9j dXNlcyBvbiB0aGUgbmV3IGtleXMgYmVpbmcgcmVhZHkgaW5zdGVhZCBvZiBmb2N1c2luZyBvbiB3 aGVuIGFuIGVuZHBvaW50IGlzIGRvbmUgc2VuZGluZyB3aXRoIHByZXZpb3VzIGtleXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBvcmRlciB0 byBhdm9pZCB0aGUgY2xpZW50IGluZmluaXRlbHkgcmV0cmFuc21pdHRpbmcgQ2xpZW50RmluaXNo ZWQgaXNzdWUsIFBSIzIyMzcgaGFzIHRoZSBzZXJ2ZXIgZGVsYXkgaXRzIDEtUlRUIEtFWVNfUkVB RFkgdW50aWwgaXQgYmVsaWV2ZXMgdGhlIGhhbmRzaGFrZSBpcyBjb21wbGV0ZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIG1v cmUgcm9idXN0IHRvIGhhdmUgdGhlIGVuZHBvaW50IHdobyBpcyBzZW5kaW5nIGRlY2lkZSB3aGVu IGl0IGlzIGRvbmUgc2VuZGluZywgaW5zdGVhZCBvZiBoYXZpbmcgdGhlIHBlZXIgYXNzdW1lIGl0 IGtub3dzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5JIGNvbXBsZXRlbHkgYWdy ZWUgd2l0aCB0aGlzLiBUaGUgdXNhZ2Ugb2YgUkVUSVJFX0tFWVMsIGFzIG91dGxpbmVkIGhlcmUg YW5kIGluIHN1bW1hcmllcyBvZiB0aGUgZGlzY3Vzc2lvbiBpbiBUb2t5byB0aGF0IEkgcmVhZCwg c2VlbXMgc2ltcGxlIGFuZCBjbGVhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR22MB0991FCD3ADA97790B238E491DA670MWHPR22MB0991namp_-- From nobody Thu Feb 14 12:42:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7B312D4F2 for ; Thu, 14 Feb 2019 12:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlxRiwDeaNXc for ; Thu, 14 Feb 2019 12:42:03 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680094.outbound.protection.outlook.com [40.107.68.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34912128D52 for ; Thu, 14 Feb 2019 12:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rOm6cKlqqLOyTvgWG/jnmVIqFULM2UvV79AQ4py/B74=; b=j0ytmSr2BD0yMVoJetj1v9I5HY+6s2R4Y3gut3qaL8b8WYEi2swoW0qyU3NlQ4Q2wFEJ0Lr2q15ec9BKKqRTGEIW2nvkIBBYnIlWRJW5AKLPERdnrLZ6DoXrZFl1YMwee+0cO3TRzS/F4R6LnugoEaLgmeBr9FfAhX+iIRthnfc= Received: from MWHPR22MB0991.namprd22.prod.outlook.com (10.171.145.21) by MWHPR22MB0142.namprd22.prod.outlook.com (10.168.249.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Thu, 14 Feb 2019 20:41:59 +0000 Received: from MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::31b1:b2c0:74a2:772e]) by MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::31b1:b2c0:74a2:772e%5]) with mapi id 15.20.1601.023; Thu, 14 Feb 2019 20:41:52 +0000 From: Mike Bishop To: David Benjamin , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: Jana Iyengar , QUIC WG , Martin Thomson Subject: RE: QUIC ossification Thread-Topic: QUIC ossification Thread-Index: AQHUwxikpkoFMiv1H0edotsvCAcFS6Xcr5EAgAAK3YCAACEsAIAAAikAgAELLICAAArqgIAABPsAgAAA14CAAAMfgIAACY0AgABAYACAAAfzgIAAPEaAgAAKFoCAABbCAIAAAY+AgAACigCAAArcAIAABcEAgAAOGgCAAPW8gIAAAEPA Date: Thu, 14 Feb 2019 20:41:52 +0000 Message-ID: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f82ab487-f178-4f6e-582f-08d692bcd9df x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0142; x-ms-traffictypediagnostic: MWHPR22MB0142: x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39830400003)(136003)(366004)(396003)(189003)(199004)(71200400001)(71190400001)(81166006)(93886005)(99286004)(476003)(446003)(4326008)(221733001)(11346002)(14454004)(8676002)(256004)(74316002)(8936002)(14444005)(7696005)(2906002)(186003)(508600001)(110136005)(486006)(81156014)(68736007)(3480700005)(54906003)(74482002)(76176011)(6246003)(229853002)(53546011)(790700001)(53936002)(66066001)(7116003)(25786009)(26005)(316002)(102836004)(3846002)(6306002)(6436002)(9686003)(236005)(54896002)(66574012)(105586002)(6116002)(55016002)(7736002)(97736004)(6506007)(33656002)(106356001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR22MB0142; H:MWHPR22MB0991.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtNV0hQUjIyTUIwMTQyOzIzOnlZckRwak8ySlB5LzJGbEx4Zit4R0F0bUw0?= =?utf-8?B?WG4zQWNBTkF2TU5hWXpQbExNVTJhT1hFVUo3WUNVcWFBQ3ZMQjgzSVJHQXlF?= =?utf-8?B?N0dJT1p6L3Joc0d0MmowUW91eWxsR0ZnQVYzNmRscXNodHFKOVNXT1Qxeisz?= =?utf-8?B?RHlHa1JSbHUyWFVqSk1kOC9SZkZ1TzFpRko4V2oyRDBBUGkzNG1kZ1RrdVZn?= =?utf-8?B?ZTBHQXF0V3FNT29pc3dmMkNzblcvVFhVWlFGVWJ1dGx1dkdjMEN2ZlVkRHYv?= =?utf-8?B?cW1hclJKblcva1A5dU40UFFXdi9oa09hcktqcDlmanVmQVdaOU93VlZxUUZ4?= =?utf-8?B?VUwrVVVBcCtUNTIvdkl6VVgwbGJpby9EdjdsZVAraEZlVEVnQ1ZjTW41Nk9Y?= =?utf-8?B?VEFPMGtjQmhET1kwbnVhNFhsamJ4SFcwSU5CS0kwcjRrS2xFWUIrN1Q4dUp4?= =?utf-8?B?K0dPazl3WmMxdWRNNXJNcXBBdmFVQ3FMQjk2dVpkU3g1SW5aWTFZbFZob1B2?= =?utf-8?B?aTlNVGd1T3lBclRzVlo5SUliOU9LZ0Z0UzRxY0pwOENlcGFXcGh1OEdnSy9v?= =?utf-8?B?Z2hweDgwK2crU1ZwSTBUMUNXcEJ4NWxjbUNGZ05RU3pTeHBGRUppdFF1S3Ix?= =?utf-8?B?Z3M1QjN3UjBXTFI0WEVGTUNadDZTVEhPM01OVDFWRnFmeUxUWDZ6bGFIUTVX?= =?utf-8?B?R2xsOVVNMFRuQzF3RVZKeTRoL2xnL29ocDVqOUkvTUgwSDQ1cWxhREpmWGlV?= =?utf-8?B?WWlKUld1VFZmcS9Zd255Yk9jR1BCcnpOL2doVTMvWkIrY1NEZThNM2V6TnVi?= =?utf-8?B?MDZ4ZXhla3RpTjZ1WTdZNGk4aUlNQ0dSajNXSk9sdldvcWptQlVPcjNGWE54?= =?utf-8?B?ZmVEak1KNkxQN3M1emFadk51aVRlelgxRnZ2N21wVit3eC9pTW00SDR0Qnl6?= =?utf-8?B?QnFydnRac1d1cUxDTDJsTmJVUmhzU3VmYjA2QUFVMU5TTndibjlhNHRZREtx?= =?utf-8?B?d3JzdWtmZTZOOENMekk4Z1JNdlFsNFUvQW9OWUN6dHM5ODliU3ZpZURXLzBK?= =?utf-8?B?RFlaRGpDTFJTdWlmSkNGUjlzbHdQbGEySWQ2aVhYdUR1QTBNeXBicUJscTZC?= =?utf-8?B?aE9sN3pQcTFFbjJJVGFWVXJKK3RDSUMrQUpzVm9HandCU1owbVowYkNNSitZ?= =?utf-8?B?ckVuTjZCQjVwVDViTWhDcXNNcTZmU2N1MnVNVjJxUmw0bVYvenI2Zm9IUTRh?= =?utf-8?B?Tmd1V0dSdDdoQnY2cUZnL3dwQU5IK2d6N3Vmc09Lb1lpemVOek1zV0NDVjZS?= =?utf-8?B?dDNMa2F3TDR4YXRVaFU4UU1yYzVWcEVtYnNPTU4xKzFJM0U2SjBkOERkMlFm?= =?utf-8?B?a2pmb1ZVQjlpd29CK1ZjWkJBUUtLWUMyZ2NnLzBKMmdXb2l6ZyswMlNCOHo5?= =?utf-8?B?YWRVelZCVjJDQnVPNzFreXhabkxQbFV6OTZzQjRaV3NLSGdtcXZvejZWd3Yv?= =?utf-8?B?cU94RjhBdHBlcGlqQm5IcC8wQkJoSWhuZmJZdXFZTkV1WDFSMW5VTFBOOFB0?= =?utf-8?B?K20xOXN6V09tdlJ3VjQ4bkVzSmw1NmZXK2s0UWpHYXFmZ1gyMmVadVlSeFlM?= =?utf-8?B?dWFtQ0pwcnFyNGtiSWwxYmxlc0l4UkN5TC9qckk0TENDcWtXK3E2VmFpY3By?= =?utf-8?B?ajBXVkwzNVZ0NWR3aUhPZXVURzA2U2h6ZDNsRmFVZjVabHZNd2J5OFZJcW1U?= =?utf-8?B?QXhMVG9FTXlwVFE3cFhXR0pPUnJJa0JYZzhHeUJPUk9WQ2V5MFRPZjlabU1I?= =?utf-8?B?RzV3K1FxeUxQMzlCaVV4b1F0bVhaODIxSnJ0TXFvc0J6QUNJY1REb3gwamdh?= =?utf-8?Q?1ESuyQdUqgcU1amqYkLiwHGxU/4gJ4j7?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /SVAj+c7Xe7OJ/JqZ0AiYF2F868f5cBJCX07vFX9FfSnUgDOwPJEVpHzN2+SiM0cuGq0hLyMik3OYEK9Tf+Y81+FmyZIJmLrVIXsb6ibQMl9dGG/0JwQq5PMOf2LBD+AHhfWn0UgPtcjjzH7rHzO52AXX+sSkZ96oRJtjZKF9pKqL3gzlHQTxKNZvE3h1UVaLCAiP1kSjf2VC2z3DxO1HFyOVnBtVYKJAxWGjbsZenHsnxUPtzmTHHmiQ+4YkpyURUzh3mLdgJXiz+DhYA3Gc9U9ZcX55FiMBdPDvG3duEKe6AduGyG/MwsPlJN/I5C+mVWzT161Wl0D8KMvBOpDtce6Fn2U9wb4csE9M1TbZzMSjHpIg/lV04r4NH8dNRhk3m3V+eAicSL7DkS/mwKBf0G/y1gb06aOsaXYVbuxC7s= Content-Type: multipart/alternative; boundary="_000_MWHPR22MB09916CC98D4AB60AA6A185BEDA670MWHPR22MB0991namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: f82ab487-f178-4f6e-582f-08d692bcd9df X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 20:41:52.3121 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0142 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:42:06 -0000 --_000_MWHPR22MB09916CC98D4AB60AA6A185BEDA670MWHPR22MB0991namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgYWN0dWFsbHkgYWdyZWVkIGF0IHRoZSBpbnRlcmltIHRvIGxlYXZlIGRvd25ncmFkZSBwcm90 ZWN0aW9uIGFzIGZ1dHVyZSB3b3JrLCBzaW5jZSB0aGlzIGlzIGN1cnJlbnRseSB0aGUgb25seSB2 ZXJzaW9uIHdlIGNhcmUgYWJvdXQuICBBIGZ1dHVyZSB2ZXJzaW9uIHdvdWxkIG5lZWQgdG8gYmUg YWNjb21wYW5pZWQgYnkgYW4gZXh0ZW5zaW9uIHRvIHYxIHRoYXQgcHJvdmlkZXMgZG93bmdyYWRl IHByb3RlY3Rpb24uICDwn5mCDQoNCklmIHdlIHN0YXJ0IGFjdGl2ZWx5IGZsZXhpbmcgdmVyc2lv biBuZWdvdGlhdGlvbiwgb2YgY291cnNlLCB3ZSBwcm9iYWJseSBuZWVkIHRvIHJldmlzaXQgdGhh dCBkZWNpc2lvbi4NCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgRGF2aWQgQmVuamFtaW4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNCwgMjAxOSAx MjozOSBQTQ0KVG86IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNv bT4NCkNjOiBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbT47IFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc+OyBNYXJ0aW4gVGhvbXNvbiA8bXRAbG93ZW50cm9weS5uZXQ+DQpTdWJqZWN0OiBS ZTogUVVJQyBvc3NpZmljYXRpb24NCg0KQXQgbGVhc3QgaW4gdGhlIFRMUyBpbmNhcm5hdGlvbiBv ZiB0aGlzIGlkZWEsIHllcywgdGhlIHBvaW50IHdvdWxkIGJlIHRvIHN1cHBvcnQgYm90aCBWMSAo Zm9yIG5vcm1hbCBjbGllbnRzKSBhbmQgdGhlIHJvbGxpbmcgdmVyc2lvbi4uIFRoYXQgZG9lcyBu b3QgcmVxdWlyZSB0aGUgY2xpZW50IHJlamVjdCBWMSBmb3IgdGhpcyB0byB3b3JrLCBwcmVzdW1p bmcgeW91ciB2ZXJzaW9uIG5lZ290aWF0aW9uIGhhcyBkb3duZ3JhZGUgcHJvdGVjdGlvbi4gKEJl aW5nIGZvcmNlZCBvbnRvIGEgdmVyc2lvbiBvdGhlciB0aGFuIHdoYXQgeW91IHdvdWxkIGhhdmUg bmF0dXJhbGx5IG5lZ290aWF0ZWQgaXMgYSBkb3duZ3JhZGUuKQ0KDQpJJ20gbm90IGZhbWlsaWFy IHdpdGggUVVJQydzIG5lZ290aWF0aW9uIG1lY2hhbmlzbXMsIGJ1dCBJIGNlcnRhaW5seSBob3Bl IHlvdSBhbGwgYXJlIGRvd25ncmFkZS1wcm90ZWN0ZWQuIFRoYXQncyBnZW5lcmFsbHkgaW1wb3J0 YW50IGluZGVwZW5kZW50IG9mIHRoZXNlIGtpbmRzIG9mIGdhbWVzLg0KDQpEYXZpZA0KT24gV2Vk LCBGZWIgMTMsIDIwMTkgYXQgMTE6NTkgUE0gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlr a2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PiB3cm90ZToNClZlcnNp b24gb2YgdGhlIG1vbnRoIGlzIHByb2JsZW1hdGljOg0KDQpHb29nbGUgc2VydmVyIHdvdWxkIG5l ZWQgdG8gc3VwcG9ydCBhIGJhc2ljIFYxLCBvdGhlcndpc2Ugbm9uLWNocm9tZSB1c2VyIGFnZW50 cyB3b3VsZCBmYWlsLiBDaHJvbWUgYnJvd3NlcnMgd291bGQgaGF2ZSB0byByZWplY3QgVjEgb3Ig dGhlIGdyZWFzaW5nIHdvbuKAmXQgd29yay4gVGhpcyBjYW4gb25seSBoYXBwZW4gdG93YXJkcyBH b29nbGUgc2VydmVycy4gTWlkZGxlYm94ZXMgbm93IGNoZWNrIGZvciBWMSBvciBHb29nbGUgZG9t YWluLiBFaXRoIGZ1dHVyZSBlbmNyeXB0ZWQgcmVxdWVzdCBkb21haW4sIGl0IGlzIGEgcGVyZmVj dCB3c3kgdG8gZmlyZXdhbGwgR29vZ2xlIHZpYSBDaHJvbWUuIFVzZXJzIHN3aXRjaCB0byBvdGhl ciBicm93c2VyLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcmE6IFFV SUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPj4g cMOlIHZlZ25lIGFmIE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldDxtYWlsdG86bXRA bG93ZW50cm9weS5uZXQ+Pg0KU2VuZHQ6IHRvcnNkYWcsIGZlYnJ1YXIgMTQsIDIwMTkgNjowOCBB TQ0KVGlsOiBKYW5hIEl5ZW5nYXINCkNjOiBRVUlDIFdHDQpFbW5lOiBSZTogUVVJQyBvc3NpZmlj YXRpb24NCg0KT24gVGh1LCBGZWIgMTQsIDIwMTksIGF0IDE1OjQ4LCBKYW5hIEl5ZW5nYXIgd3Jv dGU6DQo+IEJhc2ljYWxseSwgSSdtIHByb3Bvc2luZyB0aGF0IFFVSUMgdjEgYmUgYXNzaWduZWQg YSByYW5kb20gbnVtYmVyIGZvciBpdHMNCj4gdmVyc2lvbiBhdCBSRkMgcHVibGljYXRpb24gdGlt ZS4NCg0KV2hhdCBwcm9wZXJ0eSBkbyB5b3UgZXhwZWN0IHRoYXQgdG8gcHJvdmlkZT8NCg0KPiBB bnlvbmUgd2hvIHdhbnRzIHRvIHVzZSBhIGRpZmZlcmVudCB2ZXJzaW9uIGZvciB2MSBNVVNUIHJl cXVlc3QgaXQgZnJvbSBJQU5BIGZpcnN0IGJlZm9yZSB1c2luZyBpdCBpbiB0aGUgd2lsZC4NCg0K VGhpcyB0b28uIFdoYXQgZG9lcyB0aGlzIGFjaGlldmU/DQoNCkkgZ2V0IHRoYXQgdGhlcmUgc2Vl bXMgdG8gYmUgdGhlIGVtZXJnaW5nIHZpZXcgdGhhdCB1bm1hbmFnZWQgY29kZXBvaW50IHNwYWNl IGlzIG5vdCBnb29kIGFuZCB3ZSBzaG91bGQgYXNrIElBTkEgdG8gbWFuYWdlIGl0IGZvciB1cywg YnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRoZXNlIHByb3Bvc2FscyB3b3VsZCBwcm92aWRl Lg0K --_000_MWHPR22MB09916CC98D4AB60AA6A185BEDA670MWHPR22MB0991namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V2UgYWN0dWFsbHkgYWdyZWVkIGF0IHRoZSBpbnRlcmltIHRvIGxlYXZl IGRvd25ncmFkZSBwcm90ZWN0aW9uIGFzIGZ1dHVyZSB3b3JrLCBzaW5jZSB0aGlzIGlzIGN1cnJl bnRseSB0aGUgb25seSB2ZXJzaW9uIHdlIGNhcmUgYWJvdXQuJm5ic3A7IEEgZnV0dXJlIHZlcnNp b24gd291bGQgbmVlZCB0byBiZSBhY2NvbXBhbmllZCBieSBhbiBleHRlbnNpb24gdG8gdjEgdGhh dCBwcm92aWRlcyBkb3duZ3JhZGUgcHJvdGVjdGlvbi4mbmJzcDsNCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4mIzEyODU3ODs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIHN0YXJ0IGFjdGl2ZWx5IGZsZXhp bmcgdmVyc2lvbiBuZWdvdGlhdGlvbiwgb2YgY291cnNlLCB3ZSBwcm9iYWJseSBuZWVkIHRvIHJl dmlzaXQgdGhhdCBkZWNpc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IFFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4N CkRhdmlkIEJlbmphbWluPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxNCwg MjAxOSAxMjozOSBQTTxicj4NCjxiPlRvOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAm bHQ7bWlra2VsZmpAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSmFuYSBJeWVuZ2FyICZs dDtqcmkuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozsg TWFydGluIFRob21zb24gJmx0O210QGxvd2VudHJvcHkubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogUVVJQyBvc3NpZmljYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkF0IGxlYXN0IGluIHRoZSBUTFMgaW5jYXJuYXRpb24gb2YgdGhpcyBpZGVhLCB5ZXMsIHRoZSBw b2ludCB3b3VsZCBiZSB0byBzdXBwb3J0IGJvdGggVjEgKGZvciBub3JtYWwgY2xpZW50cykgYW5k IHRoZSByb2xsaW5nIHZlcnNpb24uLiBUaGF0IGRvZXMgbm90IHJlcXVpcmUgdGhlIGNsaWVudCBy ZWplY3QgVjEgZm9yIHRoaXMgdG8gd29yaywgcHJlc3VtaW5nIHlvdXIgdmVyc2lvbiBuZWdvdGlh dGlvbiBoYXMNCiBkb3duZ3JhZGUgcHJvdGVjdGlvbi4gKEJlaW5nIGZvcmNlZCBvbnRvIGEgdmVy c2lvbiBvdGhlciB0aGFuIHdoYXQgeW91IHdvdWxkIGhhdmUgbmF0dXJhbGx5IG5lZ290aWF0ZWQg aXMgYSBkb3duZ3JhZGUuKTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSdtIG5vdCBmYW1pbGlhciB3aXRoIFFVSUMncyBuZWdvdGlhdGlvbiBtZWNoYW5pc21z LCBidXQgSSBjZXJ0YWlubHkgaG9wZSB5b3UgYWxsIGFyZSBkb3duZ3JhZGUtcHJvdGVjdGVkLiBU aGF0J3MgZ2VuZXJhbGx5IGltcG9ydGFudCBpbmRlcGVuZGVudCBvZiB0aGVzZSBraW5kcyBvZiBn YW1lcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+RGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTMsIDIwMTkgYXQgMTE6NTkgUE0g TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdt YWlsLmNvbSI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZlcnNpb24gb2YgdGhlIG1vbnRoIGlzIHByb2JsZW1hdGlj OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5H b29nbGUgc2VydmVyIHdvdWxkIG5lZWQgdG8gc3VwcG9ydCBhIGJhc2ljIFYxLCBvdGhlcndpc2Ug bm9uLWNocm9tZSB1c2VyIGFnZW50cyB3b3VsZCBmYWlsLiBDaHJvbWUgYnJvd3NlcnMgd291bGQg aGF2ZSB0byByZWplY3QgVjEgb3IgdGhlIGdyZWFzaW5nIHdvbuKAmXQgd29yay4gVGhpcyBjYW4g b25seSBoYXBwZW4gdG93YXJkcyBHb29nbGUgc2VydmVycy4gTWlkZGxlYm94ZXMgbm93IGNoZWNr IGZvciBWMSBvcg0KIEdvb2dsZSBkb21haW4uIEVpdGggZnV0dXJlIGVuY3J5cHRlZCByZXF1ZXN0 IGRvbWFpbiwgaXQgaXMgYSBwZXJmZWN0IHdzeSB0byBmaXJld2FsbCBHb29nbGUgdmlhIENocm9t ZS4gVXNlcnMgc3dpdGNoIHRvIG90aGVyIGJyb3dzZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFs aWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy00ODY3NDUxNDkyMTkzMTk4NTk2ZGl2 UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkZyYTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IFFVSUMgJmx0 OzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5x dWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBww6UgdmVnbmUgYWYgTWFydGluIFRob21zb24g Jmx0OzxhIGhyZWY9Im1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm10 QGxvd2VudHJvcHkubmV0PC9hPiZndDs8YnI+DQo8Yj5TZW5kdDo8L2I+IHRvcnNkYWcsIGZlYnJ1 YXIgMTQsIDIwMTkgNjowOCBBTTxicj4NCjxiPlRpbDo8L2I+IEphbmEgSXllbmdhcjxicj4NCjxi PkNjOjwvYj4gUVVJQyBXRzxicj4NCjxiPkVtbmU6PC9iPiBSZTogUVVJQyBvc3NpZmljYXRpb24g PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gVGh1LCBGZWIgMTQsIDIwMTksIGF0 IDE1OjQ4LCBKYW5hIEl5ZW5nYXIgd3JvdGU6DQo8YnI+DQomZ3Q7IEJhc2ljYWxseSwgSSdtIHBy b3Bvc2luZyB0aGF0IFFVSUMgdjEgYmUgYXNzaWduZWQgYSByYW5kb20gbnVtYmVyIGZvciBpdHMg PGJyPg0KJmd0OyB2ZXJzaW9uIGF0IFJGQyBwdWJsaWNhdGlvbiB0aW1lLiA8YnI+DQo8YnI+DQpX aGF0IHByb3BlcnR5IGRvIHlvdSBleHBlY3QgdGhhdCB0byBwcm92aWRlPyA8YnI+DQo8YnI+DQom Z3Q7IEFueW9uZSB3aG8gd2FudHMgdG8gdXNlIGEgZGlmZmVyZW50IHZlcnNpb24gZm9yIHYxIE1V U1QgcmVxdWVzdCBpdCBmcm9tIElBTkEgZmlyc3QgYmVmb3JlIHVzaW5nIGl0IGluIHRoZSB3aWxk Lg0KPGJyPg0KPGJyPg0KVGhpcyB0b28uIFdoYXQgZG9lcyB0aGlzIGFjaGlldmU/IDxicj4NCjxi cj4NCkkgZ2V0IHRoYXQgdGhlcmUgc2VlbXMgdG8gYmUgdGhlIGVtZXJnaW5nIHZpZXcgdGhhdCB1 bm1hbmFnZWQgY29kZXBvaW50IHNwYWNlIGlzIG5vdCBnb29kIGFuZCB3ZSBzaG91bGQgYXNrIElB TkEgdG8gbWFuYWdlIGl0IGZvciB1cywgYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRoZXNl IHByb3Bvc2FscyB3b3VsZCBwcm92aWRlLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR22MB09916CC98D4AB60AA6A185BEDA670MWHPR22MB0991namp_-- From nobody Thu Feb 14 12:42:42 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6CE12D4F2 for ; Thu, 14 Feb 2019 12:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em1vSZaarO5w for ; Thu, 14 Feb 2019 12:42:38 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 64FD512EB11 for ; Thu, 14 Feb 2019 12:42:32 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id r124so3646378pgr.3 for ; Thu, 14 Feb 2019 12:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Sbbid3yn7RAiAsD+/bM3vB9gu0Cm+BFx6xHECDqwbQ=; b=LW+aTJmIJPjxiqGIzKxSnpCBUMneeSe3EGJsn5PmoRGDCQe0WNfqFjZGiYxcpiqEPc h+j99iV2auUDldXxVW+y7ieXT5HRY53Xcn8Dje7JCtM+p+MiQoZc/xrmwgKhnyBikzyy MfIjVGY0uNgQ58ey5Etbnj7cwmg1EKJfuBsyVRcs74VxeDixAyla3yABoXHr+uuI818b lowb5k4/u0kfW5Mw+p3fqI+uH/7iKXsUBBllOTIIOxVRq+qu8tQCM28iNSWr7cUDRP0b Me5FBTafu9hGQfY6uOZ/Treg6Gws0tqiXyGs2H2Re+toENPDmhSKHQfYt7Ah0Xr+Yuhh d76g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6Sbbid3yn7RAiAsD+/bM3vB9gu0Cm+BFx6xHECDqwbQ=; b=PMwQdLjymMqpdrt5SK69NqVr9qs8AsDx2qnh+Ji58rhLQJS6KehtRYSi9zTkodFofM y3P0h9iM85lMbp7+TaWI3sd2iy31suuAj/y6dH5ce50xNsW44IIQYfjjDAF9Qid6WzWS KyC4V3e45Ip44U8V/H0umPw8GjlkPOZc3NGthcjO/IsZss/996oGLnlqP6JZ5MSvdImh B7YaMJZBzqpOmIYvJh9cO181Q/xLTveaWifNcpA+qbeXSkfH18kIB/MmuFnHwMbKtcTV lqNJnmxiEJdiRPv5dpiXGmdOUukqRNkcjSsrMfBMN3iq4P4XEmAV8wdBq3+XZWNfYsBd i74A== X-Gm-Message-State: AHQUAuaAuZze91TwgnndX2JZn/v79DN9hoK9SOABuCvYNApsZ+0R5+aF y+vdzDZTodISsEHHp3fY+7OJKo1VhiZGWO8kmGE= X-Google-Smtp-Source: AHgI3IbFXevmpWv/uf42fZPNFkAAduH+uchPOjSD3PKYBBEIgpO9yR1iv6YUG7z1AUl6RQsia3N0uoql0AMXqRYNNR0= X-Received: by 2002:a63:2a89:: with SMTP id q131mr5492943pgq.216.1550176951550; Thu, 14 Feb 2019 12:42:31 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> In-Reply-To: From: David Schinazi Date: Thu, 14 Feb 2019 12:42:19 -0800 Message-ID: Subject: Re: KEYS_READY To: Mike Bishop Cc: Ryan Hamilton , Marten Seemann , Jana Iyengar , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000008947540581e0b2a2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:42:41 -0000 --0000000000008947540581e0b2a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think RETIRE_KEYS solves both problems. I don't think KEYS_READY does. On Thu, Feb 14, 2019 at 12:38 PM Mike Bishop wrote: > The question is whether the same mechanism can/should be used for > post-handshake key updates or if two separate mechanisms are needed. > They=E2=80=99re very similar problems, but it seems as if the requirement= s are > slightly different. > > > > *From:* QUIC *On Behalf Of * Ryan Hamilton > *Sent:* Thursday, February 14, 2019 12:34 PM > *To:* David Schinazi > *Cc:* Marten Seemann ; Jana Iyengar < > jri.ietf@gmail.com>; Mikkel Fahn=C3=B8e J=C3=B8rgensen ; QUIC > WG ; Martin Thomson > *Subject:* Re: KEYS_READY > > > > On Thu, Feb 14, 2019 at 9:57 AM David Schinazi > wrote: > > I don't think the proposed PR matches what we discussed in Tokyo, and it > seems less robust than what we discussed. > > > > In Tokyo we had discussed a RETIRE_KEYS frame with the following > properties: > > 1) You send RETIRE_KEYS when both (a) you have sent everything you wanted > with those keys AND (b) that has been ACKed > > In particular, the client sends a 1RTT packet with > RETIRE_KEYS(Handshake) when the server ACKs the packet containing the > crypto frame with the ClientFinished > > 2) You can discard keys (and congestion control state if applicable) when > you've both sent and received RETIRE_KEYS > > > > The proposal in PR#2237 does not have these properties, because it focuse= s > on the new keys being ready instead of focusing on when an endpoint is do= ne > sending with previous keys. > > In order to avoid the client infinitely retransmitting ClientFinished > issue, PR#2237 has the server delay its 1-RTT KEYS_READY until it believe= s > the handshake is complete. > > It would be more robust to have the endpoint who is sending decide when i= t > is done sending, instead of having the peer assume it knows. > > > > I completely agree with this. The usage of RETIRE_KEYS, as outlined here > and in summaries of the discussion in Tokyo that I read, seems simple and > clear. > --0000000000008947540581e0b2a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think RETIRE_KEYS solves both problems. I don't thin= k KEYS_READY does.

On = Thu, Feb 14, 2019 at 12:38 PM Mike Bishop <mbishop@evequefou.be> wrote:

The question is whether the same mechanism can/shoul= d be used for post-handshake key updates or if two separate mechanisms are = needed.=C2=A0 They=E2=80=99re very similar problems, but it seems as if the= requirements are slightly different.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Ryan Hamilton
Sent: Thursday, February 14, 2019 12:34 PM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Marten Seemann <martenseemann@gmail.com>; Jana Iyengar <jri.ietf@gmail.com>= ; Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.org>; Martin Thomson = <mt@lowentropy.ne= t>
Subject: Re: KEYS_READY

=C2=A0

On Thu,= Feb 14, 2019 at 9:57 AM David Schinazi <dschinazi.ietf@gmail.com> wrote:

I don't think the proposed PR matches what we di= scussed in Tokyo, and it seems less robust than what we discussed.

=C2=A0

In Tokyo we had discussed a RETIRE_KEYS frame with t= he following properties:

1) You send RETIRE_KEYS when both (a) you have sent = everything you wanted with those keys AND (b) that has been ACKed=

=C2=A0 =C2=A0 In particular, the client sends a 1RTT= packet with RETIRE_KEYS(Handshake) when the server ACKs the packet contain= ing the crypto frame with the ClientFinished

2) You can discard keys (and congestion control stat= e if applicable) when you've both sent and received RETIRE_KEYS<= u>

=C2=A0

The proposal in PR#2237 does not have these properti= es, because it focuses on the new keys being ready instead of focusing on w= hen an endpoint is done sending with previous keys.

In order to avoid the client infinitely retransmitti= ng ClientFinished issue, PR#2237 has the server delay its 1-RTT KEYS_READY = until it believes the handshake is complete.

It would be more robust to have the endpoint who is = sending decide when it is done sending, instead of having the peer assume i= t knows.

=C2=A0

I completely agree with this. The usage of RETIRE_KEYS, as outl= ined here and in summaries of the discussion in Tokyo that I read, seems si= mple and clear.

--0000000000008947540581e0b2a2-- From nobody Thu Feb 14 12:54:47 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA8E12D4F2 for ; Thu, 14 Feb 2019 12:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNFoslaarShi for ; Thu, 14 Feb 2019 12:54:41 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 BBAE4129532 for ; Thu, 14 Feb 2019 12:54:41 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id k15so3760877pls.8 for ; Thu, 14 Feb 2019 12:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2ue34KUZ75aHL1y5iIfcSg5zH3hWHYHY7UAGVTHB3xI=; b=Oac21wet1t9jrHGOq4Riu/tM7gbnoGCA77hipVFrbQ6HQM5JS/L4qZJmatxL9q2xzO irY+PV1ndJQQWkDaoo2xU6dSl2rDDxHe/Sjca0DQTlHFNkaBwhosQ+HhVvHxNYIKsuhY AHuDDAzLce4xexFLKn4aie3M1rNKF9rG3e7Ni/ydMF/WZsfvHmPNJZir8GSJWzbBWeG4 RfLzWe2lflQZskcM3CdBRa7YegcIbe5LeLIiU6rLmrQhZl6++5Y1qI/FdDB555jd4/uQ CkZNLO2rHlDuxa1QMm82nfrLyyIO9wrqqtDuI846Iz+Y0rh/UhA1koqWO9+HgHL7Sou7 F80w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2ue34KUZ75aHL1y5iIfcSg5zH3hWHYHY7UAGVTHB3xI=; b=c34B/jlc1mqqZlqeZHOU/wToSagpHxe8RkAO+rthvNRjDo8CDVdqvMWB7hHRKN0s3r xly+nUf8EDdDI3YcAabMEPm1mfxPP7D4tBv3bVPr4v5Sy+FXrVNE4VigpO9Vs7YUv9XK 2ig66usIHcDfEnGbqoIrhi/WRrOK7KfL9Hwi1P2zoPfZRTMujRcoONB9MOh8ZZjWSYVq p05BZ6pgTENDe5g4hlZ3ln1Jzm41DVZ9Qn9YwiyT/lDFBrAPST2jX0B/fsereXNYQ4+l W/RCe+8E2KzxiFZP8lRDwy4f280LXk91VqxpBR3y8EX2RQ9OGkR5INr7Z3o8Ow0Ye+n0 T47w== X-Gm-Message-State: AHQUAuYU4MYH9G7/+h+l8GFcIKumwJtFjno54j/QZsOh/tgFSDligdzs 5j3NsvcihR+J1WhnORhk5dpDUg78hvD0v2RcymQ= X-Google-Smtp-Source: AHgI3Ib5TfoxlWB3MLgvJELyV7TvIJbJrxO4s0miz4JKg4Ry228qR2O7eeNUtpHMtNt7tGq9aHXM307yXE4pTpDIRbE= X-Received: by 2002:a17:902:bb0b:: with SMTP id l11mr6344852pls.127.1550177681176; Thu, 14 Feb 2019 12:54:41 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> In-Reply-To: From: David Schinazi Date: Thu, 14 Feb 2019 12:54:29 -0800 Message-ID: Subject: Re: QUIC ossification To: Mike Bishop Cc: David Benjamin , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Jana Iyengar , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000067f530581e0de1b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:54:45 -0000 --000000000000067f530581e0de1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, the version downgrade prevention was punted to whenever we start using another production version and performing in-band version negotiation. These rolling versions would qualify as such and absolutely require downgrade prevention if we have version negotiation inside QUIC. That said, an important difference between TLS and QUIC here is Alt-Svc. We don't need 100% of QUIC uses to use this rolling version to prevent ossification, it would be fine if only HTTP/3 clients did that. Those clients will know the server-supported versions thanks to Alt-Svc, so there is no need for in-band version negotiation between these versions. It would be feasible to deploy these rolling versions while still treating any Version Negotiation packet as a critical error. David On Thu, Feb 14, 2019 at 12:42 PM Mike Bishop wrote: > We actually agreed at the interim to leave downgrade protection as future > work, since this is currently the only version we care about. A future > version would need to be accompanied by an extension to v1 that provides > downgrade protection. =F0=9F=99=82 > > > > If we start actively flexing version negotiation, of course, we probably > need to revisit that decision. > > > > *From:* QUIC *On Behalf Of * David Benjamin > *Sent:* Thursday, February 14, 2019 12:39 PM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* Jana Iyengar ; QUIC WG ; Martin > Thomson > *Subject:* Re: QUIC ossification > > > > At least in the TLS incarnation of this idea, yes, the point would be to > support both V1 (for normal clients) and the rolling version.. That does > not require the client reject V1 for this to work, presuming your version > negotiation has downgrade protection. (Being forced onto a version other > than what you would have naturally negotiated is a downgrade.) > > > > I'm not familiar with QUIC's negotiation mechanisms, but I certainly hope > you all are downgrade-protected. That's generally important independent o= f > these kinds of games. > > > > David > > On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > Version of the month is problematic: > > > > Google server would need to support a basic V1, otherwise non-chrome user > agents would fail. Chrome browsers would have to reject V1 or the greasin= g > won=E2=80=99t work. This can only happen towards Google servers. Middlebo= xes now > check for V1 or Google domain. Eith future encrypted request domain, it i= s > a perfect wsy to firewall Google via Chrome. Users switch to other browse= r. > > > > > ------------------------------ > > *Fra:* QUIC p=C3=A5 vegne af Martin Thomson < > mt@lowentropy.net> > *Sendt:* torsdag, februar 14, 2019 6:08 AM > *Til:* Jana Iyengar > *Cc:* QUIC WG > *Emne:* Re: QUIC ossification > > > > On Thu, Feb 14, 2019, at 15:48, Jana Iyengar wrote: > > Basically, I'm proposing that QUIC v1 be assigned a random number for > its > > version at RFC publication time. > > What property do you expect that to provide? > > > Anyone who wants to use a different version for v1 MUST request it from > IANA first before using it in the wild. > > This too. What does this achieve? > > I get that there seems to be the emerging view that unmanaged codepoint > space is not good and we should ask IANA to manage it for us, but I don't > understand what these proposals would provide. > > --000000000000067f530581e0de1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, the version downgrade prevention was punted to whenev= er we start using another production version and performing in-band version= negotiation. These rolling versions would qualify as such and absolutely r= equire downgrade prevention if we have version negotiation inside QUIC.
That said, an important difference between TLS and QUIC her= e is Alt-Svc. We don't need 100% of QUIC uses to use this rolling versi= on to prevent ossification, it would be fine if only HTTP/3 clients did tha= t.
Those clients will know the server-supported versions thanks t= o Alt-Svc, so there is no need for in-band version negotiation between thes= e versions.

It would be feasible to deploy these r= olling versions while still treating any Version Negotiation packet as a cr= itical error.

David

On Thu, Feb 14, 2019 at 12:42 PM Mike Bishop &= lt;mbishop@evequefou.be> wro= te:

We actually agreed at the interim to leave downgrade= protection as future work, since this is currently the only version we car= e about.=C2=A0 A future version would need to be accompanied by an extensio= n to v1 that provides downgrade protection.=C2=A0 =F0=9F=99= =82

=C2=A0

If we start actively flexing version negotiation, of= course, we probably need to revisit that decision.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = David Benjamin
Sent: Thursday, February 14, 2019 12:39 PM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org>; Martin Thomson <mt@lowentropy.net> Subject: Re: QUIC ossification

=C2=A0

At least in the TLS incarnation of this idea, yes, t= he point would be to support both V1 (for normal clients) and the rolling v= ersion.. That does not require the client reject V1 for this to work, presu= ming your version negotiation has downgrade protection. (Being forced onto a version other than what you wou= ld have naturally negotiated is a downgrade.)

=C2=A0

I'm not familiar with QUIC's negotiation mec= hanisms, but I certainly hope you all are downgrade-protected. That's g= enerally important independent of these kinds of games.

=C2=A0

David

On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahn=C3=B8e = J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:

Version of the month is problematic:

=C2=A0

Google server would need to support a basic V1, othe= rwise non-chrome user agents would fail. Chrome browsers would have to reje= ct V1 or the greasing won=E2=80=99t work. This can only happen towards Goog= le servers. Middleboxes now check for V1 or Google domain. Eith future encrypted request domain, it is a perfect wsy t= o firewall Google via Chrome. Users switch to other browser.<= /p>

=C2=A0

=C2=A0

Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne af Martin Thoms= on <mt@lowentropy= .net>
Sendt: torsdag, februar 14, 2019 6:08 AM
Til: Jana Iyengar
Cc: QUIC WG
Emne: Re: QUIC ossification

=C2=A0

On Thu, Feb 14, 2019, a= t 15:48, Jana Iyengar wrote:
> Basically, I'm proposing that QUIC v1 be assigned a random number = for its
> version at RFC publication time.

What property do you expect that to provide?

> Anyone who wants to use a different version for v1 MUST request it fro= m IANA first before using it in the wild.

This too. What does this achieve?

I get that there seems to be the emerging view that unmanaged codepoint spa= ce is not good and we should ask IANA to manage it for us, but I don't = understand what these proposals would provide.

--000000000000067f530581e0de1b-- From nobody Thu Feb 14 13:03:04 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3AF1311DD for ; Thu, 14 Feb 2019 13:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=gB1hQY8v; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wtvkGwju 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 gj9UvoCB90OM for ; Thu, 14 Feb 2019 13:02:53 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DE41311F2 for ; Thu, 14 Feb 2019 13:02:52 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 23FF62054D; Thu, 14 Feb 2019 16:02:51 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 14 Feb 2019 16:02:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:cc:subject :content-type:content-transfer-encoding; s=fm1; bh=mYdzX4idUy26U uK7M+QSGAmxX7UdiBm7x8wBwTJOAqU=; b=gB1hQY8v0MPrIs+rtNjlS5eM5/i21 TnSBDdiTKWmKWWLkwIMLaD9BW1MZwUFmifyxAMYts5QqS3l/blsa4sk8AFLbUcNR iJbpMci/9K6z6uAOhNc4vV3AZ5SIe0UVezssREe+mDU9wauEkIuO8LCLEn9qQ/zF iI5YQ++gHqB83073pU/azbyMAeINhQErcIC27dlz4gVxzbftKPu9bw2CSPdnioLL XGfTccIgdeMDkbDhhGFVpD7TNiQ2I6QTS3OvwZ6q3Q0cVQLWj7rOOQ1y5Y0mUPmo dJeStNtiUc+TTDgd3po9FeVH/ukYYyYXNYETr5z4jr3iW8Ht4DnHxLFlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=mYdzX4idUy26UuK7M+QSGAmxX7UdiBm7x8wBwTJOAqU=; b=wtvkGwju atYgHQE2hlZifwWpSRYQyQV/9DwMw4KnYFvsaOmeHcMF2L5LAwKHtN6XpdXGI0JY LgX2/5kYV0W59fjd3lHF5es45XNujA81xsKUdlJmW4pvY64/ydvz65KaWrznHrwi lleEiczN3KhnijXu2sDWdreHeKr91XLQcs7G0M3mYZPor7nYeSCGDIgMXw70kq3V mD6YwhGznpBOpFAJtIUddL+1/e1KpqaRYPVztGsHqd0fh03CvK9EZ7nFPzeSwwH0 y3ZJH9Rw0gnjGNBf4/bBkU34KG5f7wpVmyEukENoCTQXC6TdIcGMEwurcEfjVWro Zfq7OTFvpX4q2g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddthedgudeghecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfh ffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshho nhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 24F317C1EB; Thu, 14 Feb 2019 16:02:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> Date: Thu, 14 Feb 2019 16:02:50 -0500 From: "Martin Thomson" To: "Mike Bishop" , "David Schinazi" Cc: "Ryan Hamilton" , "Marten Seemann" , "Jana Iyengar" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "QUIC WG" Subject: Re: KEYS_READY Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 21:03:02 -0000 Please explain how the two differ, because I'm not seeing a difference. On Fri, Feb 15, 2019, at 07:42, David Schinazi wrote: > I think RETIRE_KEYS solves both problems. I don't think KEYS_READY doe= s. >=20 > On Thu, Feb 14, 2019 at 12:38 PM Mike Bishop wr= ote: > > =20 > > =20 > > =20 > > The question is whether the same mechanism can/should be used for po= st-handshake key updates or if two separate mechanisms are needed. They=E2= =80=99re very similar problems, but it seems as if the requirements are = slightly different.____ >=20 > > =20 > > __ __ >=20 > > =20 > > *From:* QUIC *On Behalf Of * Ryan Hamilton > > *Sent:* Thursday, February 14, 2019 12:34 PM > > *To:* David Schinazi > > *Cc:* Marten Seemann ; Jana Iyengar ; Mikkel Fahn=C3=B8e J=C3=B8rgensen ; = QUIC WG ; Martin Thomson > > *Subject:* Re: KEYS_READY____ >=20 > > =20 > > __ __ >=20 > > =20 > > =20 > > =20 > > =20 > > On Thu, Feb 14, 2019 at 9:57 AM David Schinazi wrote:____ >=20 > > =20 > > =20 > > =20 > > =20 > >> =20 > >> I don't think the proposed PR matches what we discussed in Tokyo, a= nd it seems less robust than what we discussed.____ >=20 > >> =20 > >> =20 > >> __ __ >=20 > >> =20 > >> =20 > >> In Tokyo we had discussed a RETIRE_KEYS frame with the following pr= operties:____ >=20 > >> =20 > >> =20 > >> =20 > >> 1) You send RETIRE_KEYS when both (a) you have sent everything you = wanted with those keys AND (b) that has been ACKed____ >=20 > >> =20 > >> =20 > >> =20 > >> In particular, the client sends a 1RTT packet with RETIRE_KEYS(Han= dshake) when the server ACKs the packet containing the crypto frame with= the ClientFinished____ >=20 > >> =20 > >> =20 > >> =20 > >> 2) You can discard keys (and congestion control state if applicable= ) when you've both sent and received RETIRE_KEYS____ >=20 > >> =20 > >> =20 > >> =20 > >> __ __ >=20 > >> =20 > >> =20 > >> =20 > >> The proposal in PR#2237 does not have these properties, because it = focuses on the new keys being ready instead of focusing on when an endpo= int is done sending with previous keys.____ >=20 > >> =20 > >> =20 > >> =20 > >> In order to avoid the client infinitely retransmitting ClientFinish= ed issue, PR#2237 has the server delay its 1-RTT KEYS_READY until it bel= ieves the handshake is complete.____ >=20 > >> =20 > >> =20 > >> =20 > >> It would be more robust to have the endpoint who is sending decide = when it is done sending, instead of having the peer assume it knows.____= >=20 > >> =20 > >> =20 > >> =20 > >> =20 > > =20 > > __ __ >=20 > > =20 > > =20 > > =20 > > I completely agree with this. The usage of RETIRE_KEYS, as outlined = here and in summaries of the discussion in Tokyo that I read, seems simp= le and clear.____ >=20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > From nobody Thu Feb 14 14:02:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2E712D826 for ; Thu, 14 Feb 2019 14:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2BGwtNWwrDT for ; Thu, 14 Feb 2019 14:02:06 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 ADB111311E3 for ; Thu, 14 Feb 2019 14:02:06 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id f132so3775499pfa.6 for ; Thu, 14 Feb 2019 14:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ukwIomJNCPzIfHPdxdrbgIvBEeLqCMPM6veX9c4/7ec=; b=M5TONVM9h8r5U03AJI1XQc8yyPA/J/IxcMdgc/UCDnfjzTnfSO6XqjI80HkJLJVazU oDrFN6xls7iKER9L7Sj5EvbBF+YzG97DAkUa3Uvz47go4rhQZqimHHxaHTur7ravIKFs 8vqqZdlTbrFk7ZfTDqzbZ4IIw7Pyqk+Aa8uHXhzfsF80o24DLqrmE2nSAa1BJ/h7Rs/V /nVBUzKvKVlhQD06Q8IIjsdsYVl3CCahwiEaX8Vdru5SkSr6NIwkFW397E/Bfb4NBB7C eKig+6xQHNTWIA3qNn5grU1ZbGfY3L8h/sJjHaDJ1ac/cZTXfcORKUoO70tBEcL70Wuj 50hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ukwIomJNCPzIfHPdxdrbgIvBEeLqCMPM6veX9c4/7ec=; b=kw9kGvv7/vzk4zmJWIytbCaNNcBi9N8tURX9wzTZnfNCR1QYfLBcLBD3QTD+iFx8FN T6GTIj6fGT/YO27ui2rk29pHtYayxfB8Z9XLEqaTXtj0ga34dWILJL4a6eT6SqoK/PwW Dd0lAv6Uf75t7RJvuL9Qhxc05qZdNmuPOPShqJQKfyZheLYuPUkI4ifezSFu5yVxHD+b 5sD5CqC+ACxDBvqODu+g9sVWYZO1SNVjyd63aBInwnpznqFnjrCKkflhXpaTvS2/W9RI gVq+L/x8LZIvSYvliZyNGPM2xuXPwqxgOr3tKubsr+yorCYeAZ43L0dg3+aA0s8tBPS1 2/3Q== X-Gm-Message-State: AHQUAuYLJvoFSYiw2W4W3i3jHSvr5N221w9s6EXh27ChmyAPFx8rvVMT g/mjjZVYa7VykCuUCBxZ+9ssmHDj3V87HRFIwLH3ujdF X-Google-Smtp-Source: AHgI3IbQDQxvZyVyIk4X5pzZuxElY1wJFlCbAsWEzP4+3Vq+qYnvM0afs3pRgOGBpbhaJdsQoSSCXac5tjqvl5HJseQ= X-Received: by 2002:a65:6099:: with SMTP id t25mr5930732pgu.448.1550181725512; Thu, 14 Feb 2019 14:02:05 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> In-Reply-To: From: David Schinazi Date: Thu, 14 Feb 2019 14:01:54 -0800 Message-ID: Subject: Re: KEYS_READY To: Martin Thomson Cc: Mike Bishop , Ryan Hamilton , Marten Seemann , Jana Iyengar , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Content-Type: multipart/alternative; boundary="0000000000001629f70581e1cfe2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 22:02:09 -0000 --0000000000001629f70581e1cfe2 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 14, 2019 at 1:02 PM Martin Thomson wrote: > Please explain how the two differ, because I'm not seeing a difference. > Here's the difference between them as I understand it: I'd initially assumed KEYS_READY meant that the keys were installed - meaning that you send KEYS_READY when your keys are installed. But not quite! The server does not send KEYS_READY when the 1-RTT keys are installed, it sends it when it believes the handshake is done. So now you have a notion of keys being ready that is impacted by parts of the protocol further away. RETIRE_KEYS just means that you're done sending with a set of keys - so you send it when you have received ACKs for everything you cared about sending with those keys. I find that a lot more easier to reason about. --0000000000001629f70581e1cfe2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Feb 14, 2019 at 1:02 PM Martin Thomson <mt@lowentropy.net> wrote:
Please explain how the two diffe= r, because I'm not seeing a difference.

=
Here's the difference between them as I understand it:
<= br>
I'd initially assumed KEYS_READY meant that the keys were= installed - meaning that you send KEYS_READY=C2=A0when your keys are insta= lled. But not quite! The server does not send KEYS_READY when the 1-RTT key= s are installed, it sends it when it believes the handshake is done. So now= you have a notion of keys being ready that is impacted by parts of the pro= tocol further away.

RETIRE_KEYS just means that yo= u're done sending with a set of keys - so you send it when you have rec= eived ACKs for everything you cared about sending with those keys. I find t= hat a lot more easier to reason about.
--0000000000001629f70581e1cfe2-- From nobody Thu Feb 14 14:30:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4873D131209 for ; Thu, 14 Feb 2019 14:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=Z2zoyHPb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xgmC2uYx 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 aCoUb1_p_3L6 for ; Thu, 14 Feb 2019 14:30:31 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA371311F4 for ; Thu, 14 Feb 2019 14:30:31 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B2AAD221D1; Thu, 14 Feb 2019 17:30:30 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 14 Feb 2019 17:30:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:cc:subject :content-type; s=fm1; bh=BrQcyV4AiUizc+nNOxItZTMka4fbqNhRxLGsfI+ 6OAY=; b=Z2zoyHPbHPWuWi1bzx5wGTQMRvAtfTGHUqu7uPG9Ba9+4wlcBdeo7At gEJFU2Ey2/l5TjOlvaWQw2WEPFMufj2JFlP/vIf0e5Zmdu/PnNfJO9UeXqqmH/Pz 10v/cZ9xDLryCnlcuRVgFsfyvMyrycHvlyXHMWeb5hcobHVein4GpneOdYGY6rcO AfwPtpl+98ZtGY4zP26cPJ/UGcMwgKm7I0A2iRD83FaaOyXv6ug/wFeCQRRsNW5W RlmJ7cddYTwsSns4HLjHG7EZKfCl+cS4ToRlKlORzeRE/yrYi0xHKD/aHPWTLv9B pxIqGf6qcYhHgtQgJMR6Fw1SGKkv91A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=BrQcyV4AiUizc+nNO xItZTMka4fbqNhRxLGsfI+6OAY=; b=xgmC2uYxudLHQX+SU2ucSLHdvnRMG/WQH Ma9aSlthDC4g+ElL46qu5WGz/t1fteTKNfvly9nTa0M9WY1AF8A8HitF7COzvKvU 7PoCkz5a41NEcYzgGime8Dnc5RJWdcClLdgbx8kPYLgenMoWzpMUvdaLOgSlv82p DXj39mJ1v5lcaIGDi/YQ8QlkD6C+pHNOfTDCbDuq7rh+d/ROX5O5crKmci+2whoE OwwE/X4exIplMRjMrMamdsqV8g3Cf6tZ2YfmEQl2bv4tgqH9TR2hCLN9eIjZd7Ga b9BerhJolBjjmuVY2yvKcg7qhxXSYsxm120M2WotwQiwFnsrTBpBQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddthedgudeifecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfh ffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhn fdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 070FA7C1EB; Thu, 14 Feb 2019 17:30:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> Date: Thu, 14 Feb 2019 17:30:30 -0500 From: "Martin Thomson" To: "David Schinazi" Cc: "Mike Bishop" , "Ryan Hamilton" , "Marten Seemann" , "Jana Iyengar" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "QUIC WG" Subject: Re: KEYS_READY Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 22:30:33 -0000 On Fri, Feb 15, 2019, at 09:02, David Schinazi wrote: > > On Thu, Feb 14, 2019 at 1:02 PM Martin Thomson wrote: > > Please explain how the two differ, because I'm not seeing a difference. > > Here's the difference between them as I understand it: > > I'd initially assumed KEYS_READY meant that the keys were installed - > meaning that you send KEYS_READY when your keys are installed. But not > quite! The server does not send KEYS_READY when the 1-RTT keys are > installed, it sends it when it believes the handshake is done. So now > you have a notion of keys being ready that is impacted by parts of the > protocol further away. > > RETIRE_KEYS just means that you're done sending with a set of keys - so > you send it when you have received ACKs for everything you cared about > sending with those keys. I find that a lot more easier to reason about. Take another look at the PR and see if you can spot the difference. You will find that maybe you are just arguing for a name change here. From nobody Thu Feb 14 14:47:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DCF131227 for ; Thu, 14 Feb 2019 14:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 nuKTLoXSie2K for ; Thu, 14 Feb 2019 14:47:13 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 0A3EA131053 for ; Thu, 14 Feb 2019 14:47:12 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id d72so3792729pga.9 for ; Thu, 14 Feb 2019 14:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GZ8MOXj1yEl2Of7yLqG1ssjys2HG6MwQbbZDOe8x6EA=; b=sxXc6wKlBkAgEhbIVZ08AX5kHuBrxX9+oa7ZLj9LHpcVJ6JMTt5xgDtVd0sY5HSq8O sy4/Wuaj2kjBO1p8ZITYvzm80K9eN1JOkKlXuIzrOv/y86G6/dnDHNOrhLOISEzw+fpU ggIC19NgqrrmJ851atpiDYp0MMTXkolz/tivw+HlCpG9vBd/5vjv6PPI7gi5mNOAu1dE kJ11Mg25Wy2qILR6w7l3aZIlN1FoXH0HofXZlaRKrycOov+NbgXWoO4/dPc9JoEwXgXY JdjQqtZIqxy3PgoELjRLSCk3e7LfHzWzLHWrp9TMyyA7vX9aTdAEaUKLtMKaQCfKApit E55Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GZ8MOXj1yEl2Of7yLqG1ssjys2HG6MwQbbZDOe8x6EA=; b=tpQm6EN/8YQvHtmy+lpmTZbr3Mzair8+XDgno1UHpDAdqy/kgrF/QBqNDEgJ2tAk4e +BaNjpmgGS9/7G/KdYGw6YYOeVaBfz16auKHY3OYMzLZC/F+OE7CkNPtPZP0xZJFpyrt B6jd0/N27KoMR3y7PRvqlk1LDlueUi0KZidMeHkGZJrsRNBzHZMt7WGS1RrA6pGic9FI iWACfCVompCfMFasxtZYOMfFFdonK50dCGHJ6V3tqycCPI9/Jd+BW2iF7EexySDM75MR ojb4jt221NFn6SMGoGz+FfhM4rIZb0v3ZPcbsB7sA+qvCNNEBVhi9TvQAXbQrPlsQFN/ 7Uxg== X-Gm-Message-State: AHQUAuZLRzLBMwTkxvLXISx3FWySQQunBlMpA+U5/FNyurISao0jB0X8 yx9EwT9yY+RH03STY5JicQ5caw30qKDIi2y0veg= X-Google-Smtp-Source: AHgI3IaiZKrCXxyDjnsERg8/73r2Mx1d1MocqvYqtwep9GEOnbsYilqXpYVhi6MbaZ389Vym5e/Vh7LewgelsRtS/OQ= X-Received: by 2002:a63:1ce:: with SMTP id 197mr2233463pgb.47.1550184432320; Thu, 14 Feb 2019 14:47:12 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> In-Reply-To: From: David Schinazi Date: Thu, 14 Feb 2019 14:47:01 -0800 Message-ID: Subject: Re: KEYS_READY To: Martin Thomson Cc: Mike Bishop , Ryan Hamilton , Marten Seemann , Jana Iyengar , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Content-Type: multipart/alternative; boundary="0000000000006cc3cc0581e270d5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 22:47:15 -0000 --0000000000006cc3cc0581e270d5 Content-Type: text/plain; charset="UTF-8" Hi Martin, I've read the PR (in its latest version) and the comments in my previous email still hold. The text I object to from the PR is the following: A KEYS_ACTIVE frame sent in 1-RTT packets indicates that Handshake keys are no longer needed. A client MUST send this frame in its first 1-RTT packet, and a server MUST send this frame in the first packet it sends after completing the handshake. A server might send 1-RTT packets prior to this; a server MUST NOT process 1-RTT packets until the cryptographic handshake is complete. This means that the server sends KEYS_ACTIVE(1-RTT) not when the 1-RTT keys are active, but instead when the handshake finishes, which is when the server has received the client finished. Those are two different moments in time. My proposal is to have the client decide when it is done with the handshake keys by having the client delay sending RETIRE_KEYS(Handshake) instead of the server delaying sending KEYS_ACTIVE(1-RTT). David On Thu, Feb 14, 2019 at 2:30 PM Martin Thomson wrote: > On Fri, Feb 15, 2019, at 09:02, David Schinazi wrote: > > > > On Thu, Feb 14, 2019 at 1:02 PM Martin Thomson > wrote: > > > Please explain how the two differ, because I'm not seeing a difference. > > > > Here's the difference between them as I understand it: > > > > I'd initially assumed KEYS_READY meant that the keys were installed - > > meaning that you send KEYS_READY when your keys are installed. But not > > quite! The server does not send KEYS_READY when the 1-RTT keys are > > installed, it sends it when it believes the handshake is done. So now > > you have a notion of keys being ready that is impacted by parts of the > > protocol further away. > > > > RETIRE_KEYS just means that you're done sending with a set of keys - so > > you send it when you have received ACKs for everything you cared about > > sending with those keys. I find that a lot more easier to reason about. > > Take another look at the PR and see if you can spot the difference. You > will find that maybe you are just arguing for a name change here. > --0000000000006cc3cc0581e270d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin, I've read the PR (in its l= atest version) and the comments in my previous email still hold.
The text I object to from the PR is the following:

=
=C2=A0 =C2=A0 A KEYS_ACTIVE frame sent in 1-RTT packets ind= icates that Handshake keys are no
=C2=A0 =C2=A0 longer needed.=C2= =A0 A client MUST send this frame in its first 1-RTT packet, and a
=C2=A0 =C2=A0 server MUST send this frame in the first packet it sends af= ter completing the
=C2=A0 =C2=A0 handshake.=C2=A0 A server might = send 1-RTT packets prior to this; a server MUST NOT
=C2=A0 =C2=A0= process 1-RTT packets until the cryptographic handshake is complete.
=

This means that the server sends KEYS_ACTIVE(1-RT= T) not when the 1-RTT keys are active,
but instead when the hands= hake finishes, which is when the server has received the client finished.
Those are two different moments in time.

= My proposal is to have the client decide when it is done with the handshake= keys by having the client
delay sending RETIRE_KEYS(Handshake) i= nstead of the server delaying sending KEYS_ACTIVE(1-RTT).

David

On Thu, Feb 14, 2019 at 2:30 PM Martin Thomson <mt@lowentropy.net> wrote:
On Fri, Feb 15, 2019, at 09:02, David Sch= inazi wrote:
>
> On Thu, Feb 14, 2019 at 1:02 PM Martin Thomson <mt@lowentropy.net> wrote:
> > Please explain how the two differ, because I'm not seeing a d= ifference.
>
> Here's the difference between them as I understand it:
>
> I'd initially assumed KEYS_READY meant that the keys were installe= d -
> meaning that you send KEYS_READY when your keys are installed. But not=
> quite! The server does not send KEYS_READY when the 1-RTT keys are > installed, it sends it when it believes the handshake is done. So now =
> you have a notion of keys being ready that is impacted by parts of the=
> protocol further away.
>
> RETIRE_KEYS just means that you're done sending with a set of keys= - so
> you send it when you have received ACKs for everything you cared about=
> sending with those keys. I find that a lot more easier to reason about= .

Take another look at the PR and see if you can spot the difference.=C2=A0 Y= ou will find that maybe you are just arguing for a name change here.
--0000000000006cc3cc0581e270d5-- From nobody Thu Feb 14 15:46:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7A3130DC0 for ; Thu, 14 Feb 2019 15:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ITmcyUom; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=5juBbwZn 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 JpKPkfq14IbN for ; Thu, 14 Feb 2019 15:45:58 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579B512F295 for ; Thu, 14 Feb 2019 15:45:58 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4008122A67; Thu, 14 Feb 2019 18:45:57 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 14 Feb 2019 18:45:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:cc:subject :content-type; s=fm1; bh=c2YbeOXeMidOjK7elTSuVGnk9tyTM7YeOLPijBy d778=; b=ITmcyUomLmBt+rTbOsi8mPKCefmGSwcHQZoZJzlic6ngKiLt87wr3L/ YpZU2RZXEMw5hW85u3CfEwCa68smk0R0khsaC6CsMn9s6iZWJdNIRtX5NHeDXQUf L6XplnNfBMeShmxMGSYTUe31VnrCgIAoQlNfhweHH3YivLbgzXsrdroY1TxZ9IXF lv8vSRfeEpCv4cyj7V2AZQK91FKB/IE/+10buhFMCFapB7wJsy7lsedT0h0NPFBr 3J6DcuZd+gpmeAuV9ohXK0t3/nSVNBLzHx23HhzOJB9Gikja+0EgzsTuFiwH0RqQ kQ0YbrVFN0n7HEbJAhp7z5CHKjDUWww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=c2YbeOXeMidOjK7el TSuVGnk9tyTM7YeOLPijByd778=; b=5juBbwZn6JINCj8qPbEHhpVZBZwP13m1E 71UIwqT+8nB1caTOx6AGIb+XE6E5cHKqF9uVL+8NvFDBX65ZxxVsdzRLr8cQ6FZY tv6zLnRQi5fdn1eYTKlRq1QM8EjksOImxBMxQ7ZMxGaWfVTmgpXmhdmUnYawXNLQ 3X1h2weeHpXlUkDbZkYU5rM5NzCza6VipYvnHFTy0u7Sv7RUx1HjXwi98DvFxtYh YE9k9zVsoluH4IMw1S595M59ji5sExEb1WjJ312p/F2simlBsFJ6vdPoWp/pC9cM Lg++PCXuEH0WDg1PcyrOHznoM2bReqb/WfHuoDO4Zwlh02J2J8PUQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefofgfkjghfff fhvffutgesthdtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdf uceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1105D7C1EB; Thu, 14 Feb 2019 18:45:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 92534000 Message-Id: <045bbf5b-04e4-4f9f-886b-f7ff9254bdab@www.fastmail.com> In-Reply-To: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> Date: Thu, 14 Feb 2019 18:45:56 -0500 From: "Martin Thomson" To: "David Schinazi" Cc: "Mike Bishop" , "Ryan Hamilton" , "Marten Seemann" , "Jana Iyengar" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "QUIC WG" Subject: Re: KEYS_READY Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 23:46:00 -0000 On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote: > This means that the server sends KEYS_ACTIVE(1-RTT) not when the 1-RTT > keys are active, > but instead when the handshake finishes, which is when the server has > received the client finished. > Those are two different moments in time. Yes, because the keys aren't active when the server starts sending 1-RTT packets. They are only active when the server starts reading 1-RTT. The server can't activate its 1-RTT reading keys until the handshake is complete. That's why I chose to name this KEYS_ACTIVE(this), not RETIRE_KEYS(prev), but I don't really mind what it is called. > My proposal is to have the client decide when it is done with the > handshake keys by having the client > delay sending RETIRE_KEYS(Handshake) instead of the server delaying > sending KEYS_ACTIVE(1-RTT). This requires that the client send more Handshake packets. And it adds a lot of delay because the client has to wait until all its packets are acknowledged. We previously agreed that any such signal from the server is more direct and effective. From nobody Thu Feb 14 16:18:04 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A9B12F1A6 for ; Thu, 14 Feb 2019 16:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hcfkt0ikM9Q for ; Thu, 14 Feb 2019 16:17:59 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 51AE5128B36 for ; Thu, 14 Feb 2019 16:17:59 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id k15so4017226pls.8 for ; Thu, 14 Feb 2019 16:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PF0vUBIxeDU0gnKhOGTbi8r0sdu5sCYRhQpCG4RESDw=; b=O5xIdRz/f8h4I2etDHzkg4Fa7UOwCpGZuufEHpaLWd0Kdek555xfGqoy/4liK/wja3 Wf9owMUdUqmsSxSFyb56sCl6ahDlV0rEQEgv4hhlGNs/olnZruAbD68KNKw91h9Zozzi xhm2UaXyxlmm8/V/u+A8h/xGvzQJ70cjiR4CoiraEMUck2WJ+zId50JGh+Mpu/vep2C0 fBrowzkgOF1fEvifnX6PZm8FhioCz82NLvufZzxHlscfp7fAYu+0xjjvqkp0AID1W37S vIY6uXT4ItkK5zX6trqVKBsXlRe0B1XEw6cqbF5KFdBhQfQ1cOSr/3q0Yn0LDj4yvaSW nAog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PF0vUBIxeDU0gnKhOGTbi8r0sdu5sCYRhQpCG4RESDw=; b=TkfCULW730lZqkNW9QBAhXPCjkIk4r64QEu1Ard+UtrYBKeFju/0fHFSr76etiEZBg kpLEozmVlsgMS9BMy8oOTR0lZfcaWjBgHtht4rMwu/K5uhpb+wyqCitC/JWZmU/IBp3b XsXUooPJ1K7xQb8T5DG3Vh7+tkIADICqa7pEFgrpOt/ZULmS+WnLFvat9lmbvd6WIdBJ oi+WL2fzY1xETlluUWKmCaNaJ1opep7Q+TmmQMhgDcZSFWYf+6nL1uAa4roY9vlMLSzC CTJoaGe+yyhxSM4/A336ez2NgW9BB3NhU+MBz5YjNn7E0IIM5zRiGTJVCnyjVJkwKfjJ jQyg== X-Gm-Message-State: AHQUAuYqQEcZM0jRRaapz3egPuTm8RfOIoMXHWtgLHwmb6UkK+etv/zU +9810FG59inC895DXsrvVBRUvPf6Jx24CSwD3Sw= X-Google-Smtp-Source: AHgI3IazCZ2ITWbju0OzPVNldQ+m3BfVW5PBNa1t0ZxNfzcafswrg/69cMOhSkHMVPUUldwi6fETMuqeDQgfcyQHaeY= X-Received: by 2002:a17:902:bb0b:: with SMTP id l11mr7185817pls.127.1550189878404; Thu, 14 Feb 2019 16:17:58 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> <045bbf5b-04e4-4f9f-886b-f7ff9254bdab@www.fastmail.com> In-Reply-To: <045bbf5b-04e4-4f9f-886b-f7ff9254bdab@www.fastmail.com> From: David Schinazi Date: Thu, 14 Feb 2019 16:17:47 -0800 Message-ID: Subject: Re: KEYS_READY To: Martin Thomson Cc: Mike Bishop , Ryan Hamilton , Marten Seemann , Jana Iyengar , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Content-Type: multipart/alternative; boundary="0000000000000969d30581e3b51c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 00:18:02 -0000 --0000000000000969d30581e3b51c Content-Type: text/plain; charset="UTF-8" On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson wrote: > On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote: > > This means that the server sends KEYS_ACTIVE(1-RTT) not when the 1-RTT > > keys are active, > > but instead when the handshake finishes, which is when the server has > > received the client finished. > > Those are two different moments in time. > > Yes, because the keys aren't active when the server starts sending 1-RTT > packets. They are only active when the server starts reading 1-RTT. The > server can't activate its 1-RTT reading keys until the handshake is > complete. > Ah, thanks. Looking at it this way it makes sense to me - we may want to make the text clearer in case I'm not the only one who was confused. > That's why I chose to name this KEYS_ACTIVE(this), not RETIRE_KEYS(prev), > but I don't really mind what it is called. > I don't feel strongly about names either as long as they make sense - and now KEYS_ACTIVE also makes sense to me - so either name is fine by me. > > My proposal is to have the client decide when it is done with the > > handshake keys by having the client > > delay sending RETIRE_KEYS(Handshake) instead of the server delaying > > sending KEYS_ACTIVE(1-RTT). > > This requires that the client send more Handshake packets. And it adds a > lot of delay because the client has to wait until all its packets are > acknowledged. We previously agreed that any such signal from the server is > more direct and effective. > I don't think it means more handshake packets. And it's still a direct signal between endpoints. The only difference is that the client-to-server RETIRE_KEYS message is delayed by one RTT compared to its KEYS_ACTIVE message so the server will wait one RTT before throwing away handshake keys. But it has the advantage of not requiring any implicit ACKs. So the tradeoff we're facing is between allowing the server to throw away keys sooner at the cost of making implicit decisions. This implicitness means KEYS_ACTIVE does not allow the client to be able to send anything in Handshake after the ClientFinished. I'm worried that might prevent protocol changes down the road. I'm still in favor of paying the one RTT before key deletion to make the protocol more explicit. --0000000000000969d30581e3b51c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson <mt@lowentropy.net> wrote:
On Fri, Feb 15, 2019, at 09:= 47, David Schinazi wrote:
> This means that the server sends KEYS_ACTIVE(1-RTT) not when the 1-RTT=
> keys are active,
> but instead when the handshake finishes, which is when the server has =
> received the client finished.
> Those are two different moments in time.

Yes, because the keys aren't active when the server starts sending 1-RT= T packets.=C2=A0 They are only active when the server starts reading 1-RTT.= =C2=A0 The server can't activate its 1-RTT reading keys until the hands= hake is complete.

Ah, thanks. Looking a= t it this way it makes sense to me - we may want to make the text clearer i= n case I'm not the only one who was confused.
=C2=A0
That's why I chose to name this KEYS_ACTIVE(this), not RETIRE_KEYS(prev= ), but I don't really mind what it is called.

=
I don't feel strongly about names either as long as they mak= e sense - and now KEYS_ACTIVE also makes sense to me - so either name is fi= ne by me.
=C2=A0
=C2=A0> My proposal is to have the client decide when it is done with th= e
> handshake keys by having the client
> delay sending RETIRE_KEYS(Handshake) instead of the server delaying > sending KEYS_ACTIVE(1-RTT).

This requires that the client send more Handshake packets.=C2=A0 And it add= s a lot of delay because the client has to wait until all its packets are a= cknowledged.=C2=A0 We previously agreed that any such signal from the serve= r is more direct and effective.

I don&#= 39;t think it means more handshake packets. And it's still a direct sig= nal between endpoints. The only difference is that the client-to-server RET= IRE_KEYS message is delayed by one RTT compared to its KEYS_ACTIVE message = so the server will wait one RTT before throwing away handshake keys. But it= has the advantage of not requiring any implicit ACKs. So the tradeoff we&#= 39;re facing is between allowing the server to throw away keys sooner at th= e cost of making implicit decisions. This implicitness means KEYS_ACTIVE do= es not allow the client to be able to send anything in Handshake after the = ClientFinished. I'm worried that might prevent protocol changes down th= e road.

I'm still in favor of paying the one R= TT before key deletion to make the protocol more explicit.
--0000000000000969d30581e3b51c-- From nobody Thu Feb 14 17:02:51 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999F2130E3F for ; Thu, 14 Feb 2019 17:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zegxCvZfrHHO for ; Thu, 14 Feb 2019 17:02:47 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 645A1130DFA for ; Thu, 14 Feb 2019 17:02:47 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id z84so835164wmg.4 for ; Thu, 14 Feb 2019 17:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jFudzIjpH3PSj1jK/yfrImPW4106EB7wOg0UNQ1eK1w=; b=YMzY4Mp9lJlILet3s30Dgz/5fqNIGy3W/cwhXW1+iPUOAlIQjDacZBfbCzUle8iewE FA1nsN9dl9KEtfOh9MYKDROiuPiESNCXER+/0QXh9UDXDOf25rmUq9qGbCKrxdrHqIyS ELc5TJuTzsRtMx/d+aHShDfe54JaT0brgtxZLMmfh4gDHt6+AWEDz7penMRVZH9Sofz5 WGCHCUA+R3HNu7RGYM5hq2Cxr/J3q5qbkq1oQaOVfKkN72HM5sz/ttZNA8IiUEzhUTZW RxR7igQc3Q72/0aUCbPGJqKE8jIOPMzIjPlNlcpn9a/qm4SmyRsUfzFLc8mqtOjsadws iZQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jFudzIjpH3PSj1jK/yfrImPW4106EB7wOg0UNQ1eK1w=; b=dSD751Eae7zOqc37lHvZTRpA9yKuB7v8a2rtFS6gzRDEkTKGhmNQt+X7L8lYumU/iy 0yulG1aTXsfvFVkrXQw9g+F57UrQO63agFDvErA42DgHGjHuRCvOgufAQbaDmstLVnkf QW/Hdhj0O6YWjOiOmNpN8+aUKtOM4mQFwokBE6QFYqcFTyCh6clGULkCDXSbiAbDoNw0 fU8MUwTpt0PcBxbLiTCpKSoJAYSOuKmZbN6dtC9dISA75Z9YwRZJtBlFtmeqZg5B38eJ BlcYT/ffuyrrqoIVwEsD9DJwuPZWAUSEIX6Qe6K8JKQs2M8LoK+GHFW07vTVzInhHGbo 8NlQ== X-Gm-Message-State: AHQUAua6sqqdFgJQv/PvS69E7MJccija2FXmPaj/v1DPeQKT3nu4qQdE c/g/YbDT+roKrnxXYEtSl/khEJMGlAIiuvVIHA4= X-Google-Smtp-Source: AHgI3IaZZQVS/kfnRzsIr6W3DJFwj1hZyy4bWA/tD0yGHf6PUQvNdT+rsMK+wzl6wllr9cjUqrInFhVNZ6CieMloPPE= X-Received: by 2002:a1c:7e58:: with SMTP id z85mr669997wmc.52.1550192565736; Thu, 14 Feb 2019 17:02:45 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> In-Reply-To: From: Martin Duke Date: Thu, 14 Feb 2019 17:02:32 -0800 Message-ID: Subject: Re: QUIC ossification To: David Schinazi Cc: Mike Bishop , Jana Iyengar , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Martin Thomson , David Benjamin Content-Type: multipart/alternative; boundary="00000000000036dcce0581e455bc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:02:50 -0000 --00000000000036dcce0581e455bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Collective, time for me to file a github issue? Or leave it on the list? On Thu, Feb 14, 2019, 12:54 PM David Schinazi Yes, the version downgrade prevention was punted to whenever we start > using another production version and performing in-band version > negotiation. These rolling versions would qualify as such and absolutely > require downgrade prevention if we have version negotiation inside QUIC. > > That said, an important difference between TLS and QUIC here is Alt-Svc. > We don't need 100% of QUIC uses to use this rolling version to prevent > ossification, it would be fine if only HTTP/3 clients did that. > Those clients will know the server-supported versions thanks to Alt-Svc, > so there is no need for in-band version negotiation between these version= s. > > It would be feasible to deploy these rolling versions while still treatin= g > any Version Negotiation packet as a critical error. > > David > > On Thu, Feb 14, 2019 at 12:42 PM Mike Bishop wrote= : > >> We actually agreed at the interim to leave downgrade protection as futur= e >> work, since this is currently the only version we care about. A future >> version would need to be accompanied by an extension to v1 that provides >> downgrade protection. =F0=9F=99=82 >> >> >> >> If we start actively flexing version negotiation, of course, we probably >> need to revisit that decision. >> >> >> >> *From:* QUIC *On Behalf Of * David Benjamin >> *Sent:* Thursday, February 14, 2019 12:39 PM >> *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen >> *Cc:* Jana Iyengar ; QUIC WG ; Martin >> Thomson >> *Subject:* Re: QUIC ossification >> >> >> >> At least in the TLS incarnation of this idea, yes, the point would be to >> support both V1 (for normal clients) and the rolling version.. That does >> not require the client reject V1 for this to work, presuming your versio= n >> negotiation has downgrade protection. (Being forced onto a version other >> than what you would have naturally negotiated is a downgrade.) >> >> >> >> I'm not familiar with QUIC's negotiation mechanisms, but I certainly hop= e >> you all are downgrade-protected. That's generally important independent = of >> these kinds of games. >> >> >> >> David >> >> On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < >> mikkelfj@gmail.com> wrote: >> >> Version of the month is problematic: >> >> >> >> Google server would need to support a basic V1, otherwise non-chrome use= r >> agents would fail. Chrome browsers would have to reject V1 or the greasi= ng >> won=E2=80=99t work. This can only happen towards Google servers. Middleb= oxes now >> check for V1 or Google domain. Eith future encrypted request domain, it = is >> a perfect wsy to firewall Google via Chrome. Users switch to other brows= er. >> >> >> >> >> ------------------------------ >> >> *Fra:* QUIC p=C3=A5 vegne af Martin Thomson < >> mt@lowentropy..net > >> *Sendt:* torsdag, februar 14, 2019 6:08 AM >> *Til:* Jana Iyengar >> *Cc:* QUIC WG >> *Emne:* Re: QUIC ossification >> >> >> >> On Thu, Feb 14, 2019, at 15:48, Jana Iyengar wrote: >> > Basically, I'm proposing that QUIC v1 be assigned a random number for >> its >> > version at RFC publication time. >> >> What property do you expect that to provide? >> >> > Anyone who wants to use a different version for v1 MUST request it fro= m >> IANA first before using it in the wild. >> >> This too. What does this achieve? >> >> I get that there seems to be the emerging view that unmanaged codepoint >> space is not good and we should ask IANA to manage it for us, but I don'= t >> understand what these proposals would provide. >> >> --00000000000036dcce0581e455bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Collective, time for me to file a github issue? Or leave = it on the list?

On Thu= , Feb 14, 2019, 12:54 PM David Schinazi <dschinazi.ietf@gmail.com wrote:
Yes, the version downgrade prevention was pu= nted to whenever we start using another production version and performing i= n-band version negotiation. These rolling versions would qualify as such an= d absolutely require downgrade prevention if we have version negotiation in= side QUIC.

That said, an important difference between TL= S and QUIC here is Alt-Svc. We don't need 100% of QUIC uses to use this= rolling version to prevent ossification, it would be fine if only HTTP/3 c= lients did that.
Those clients will know the server-supported ver= sions thanks to Alt-Svc, so there is no need for in-band version negotiatio= n between these versions.

It would be feasible to = deploy these rolling versions while still treating any Version Negotiation = packet as a critical error.

David

<= div class=3D"gmail_quote">
On Thu, Feb 14, 2019 at 12:42 PM= Mike Bishop <mbishop@evequefou.be> wrote:

We actually agreed at the interim to leave downgrade= protection as future work, since this is currently the only version we car= e about.=C2=A0 A future version would need to be accompanied by an extensio= n to v1 that provides downgrade protection.=C2=A0 =F0=9F=99= =82

=C2=A0

If we start actively flexing version negotiation, of= course, we probably need to revisit that decision.

=C2=A0

From: QUIC <quic-bounces@ietf.org&g= t; On Behalf Of David Benjamin
Sent: Thursday, February 14, 2019 12:39 PM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>=
Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.or= g>; Martin Thomson <mt@lowentropy.net>
Subject: Re: QUIC ossification

=C2=A0

At least in the TLS incarnation of this idea, yes, t= he point would be to support both V1 (for normal clients) and the rolling v= ersion.. That does not require the client reject V1 for this to work, presu= ming your version negotiation has downgrade protection. (Being forced onto a version other than what you wou= ld have naturally negotiated is a downgrade.)

=C2=A0

I'm not familiar with QUIC's negotiation mec= hanisms, but I certainly hope you all are downgrade-protected. That's g= enerally important independent of these kinds of games.

=C2=A0

David

On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahn=C3=B8e = J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

Version of the month is problematic:

=C2=A0

Google server would need to support a basic V1, othe= rwise non-chrome user agents would fail. Chrome browsers would have to reje= ct V1 or the greasing won=E2=80=99t work. This can only happen towards Goog= le servers. Middleboxes now check for V1 or Google domain. Eith future encrypted request domain, it is a perfect wsy t= o firewall Google via Chrome. Users switch to other browser.<= /p>

=C2=A0

=C2=A0

Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 ve= gne af Martin Thomson <mt@lowentropy..net>
Sendt: torsdag, februar 14, 2019 6:08 AM
Til: Jana Iyengar
Cc: QUIC WG
Emne: Re: QUIC ossification

=C2=A0

On Thu, Feb 14, 2019, a= t 15:48, Jana Iyengar wrote:
> Basically, I'm proposing that QUIC v1 be assigned a random number = for its
> version at RFC publication time.

What property do you expect that to provide?

> Anyone who wants to use a different version for v1 MUST request it fro= m IANA first before using it in the wild.

This too. What does this achieve?

I get that there seems to be the emerging view that unmanaged codepoint spa= ce is not good and we should ask IANA to manage it for us, but I don't = understand what these proposals would provide.

--00000000000036dcce0581e455bc-- From nobody Thu Feb 14 17:04:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290D2130E1C for ; Thu, 14 Feb 2019 17:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=PktiMMUr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e1kHi0V6 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 bhxK4dtRZU-8 for ; Thu, 14 Feb 2019 17:04:34 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E031130DFA for ; Thu, 14 Feb 2019 17:04:34 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B994C22953 for ; Thu, 14 Feb 2019 20:04:33 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 14 Feb 2019 20:04:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=ijOO7BzVvK6FhlAGUpfeafQC06qXsVpa2xE5VgI nxDI=; b=PktiMMUr0BKdG28ED9p4sLXqo01E1H0Z7t/qNxVZucxJ4lqqecoApOi Vx0ZrWJnUltyCRvHJL5cTldRS8kOL4r4TmAs3jBtIOUIqPooO+HW2/aI4LiAy2vF cYz9HiNansnkPFLBDGAN39rCxI4hW0kaCaIRJyxChAn/Bz5GKW+ZGgLIDaBRS/3c bcvw4u59EwpEXyq4lE55oORq2G/xo6gHnYl74lA9QQjrRKsW5aYOQle+GvaYk9s/ +MUkOrWM0bhBTxN60PBsAU5UePCnEJWyntoazYsezyKsy3+6SmgLBo7rnGjBsRvo kI6DulaqdjKYZ3Q6KpvqLZcuhRJ9rjA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ijOO7BzVvK6FhlAGU pfeafQC06qXsVpa2xE5VgInxDI=; b=e1kHi0V632HQiKaR+GiTQcoxU4lDqNmns gCFrrtqfl+RW5cMF94PKJ4Gh5HK+AqsmGhHm5HldLqebzjekZL1xB4A6CWWPwxXX e8hTISjsCmXrBV8aoAQJgAOGMebQqnQBUz7Of8kbh+BB2geZFBdF/IzCkY84B1yD 7yz38mHvq3JqqfYpGLnRLdHxjS+hlY8IpkZJobORYh6BYxNiLsIhanfxtWMs9rsH /bJ1kF4IeChBwKbFHqH15vLGCBGcvGNhhlkAJwpB50+qb9lxUwaq7Fcif6i/iayk 1mEgRiFo0vEzaCZhgW1BZYl5Pz3j6jTAGeSoaf30J94hFLxH09bcg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpe dfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvght qeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth enucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 21CD77C1EB; Thu, 14 Feb 2019 20:04:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 92534000 Message-Id: <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> In-Reply-To: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> Date: Thu, 14 Feb 2019 20:04:33 -0500 From: "Martin Thomson" To: quic@ietf.org Subject: Re: QUIC ossification Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:04:36 -0000 On Fri, Feb 15, 2019, at 12:02, Martin Duke wrote: > Collective, time for me to file a github issue? Or leave it on the list? What do you believe the issue would be? Because a lot of the discussion here has been very much "quicv2" territory. From nobody Thu Feb 14 17:09:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E4130E1C for ; Thu, 14 Feb 2019 17:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I0Pr8uEW7Nx for ; Thu, 14 Feb 2019 17:09:41 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 0D8F2130DFA for ; Thu, 14 Feb 2019 17:09:41 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id w7so3949057pgp.13 for ; Thu, 14 Feb 2019 17:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8n+0ABs1lhD0jUUbni7XeMibQHtECejkGONYb33sZKs=; b=MyTOBBrMGXmndZGreQk0SMJmRJcwXGB4RjL8AhVP72oeI6X2DuyX9MqmSmY/MLTcZ+ za6hPlg654YCg4QsnvEil77d/kCBT0HPc/uX0h/SKCOUY81zQU+bFiA0TwljALvizpD9 4LpVKvnrZfCZKPkFl6FuEs1+Z7zVqMKK5G49Wjbs1+ixEj3nvL3HqaP+zkR0j5L0HkuQ l7dIVRfOjjvd9JzYo2DaHkUfPqvUpqymOQsAeTuIvpmTZZpULC+x2ioaznmdwCHguHil 5RsP45yP76ONSslwluV7fqZCMKyWzPJhJhAkxb6fzYJtAZZDiRzgSspMsQMKhZB8lKKm Agtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8n+0ABs1lhD0jUUbni7XeMibQHtECejkGONYb33sZKs=; b=iwYDs6+Qv4zcM8pH2WEisgx/TxJH5HhSX5ZY0Dz6GdhZv8JduP0BBo6hW2XIj6k/rX lPTaYIoNRwOPpzSMkSy6WysHe/JkV3B9ZYZN36AHgoILsHaE7AZh2TPBNa6mBZnV/Mez 7wyI1+ksgUFwBzOmB6TYbFmvvtVuGUX86d4A12gsxmYKOp4sAYoalGEOR3CgZkXrxK7H dw0297HmFGpmXi+7zZSQhD0etb8EzUHd2ErpgQAlAIdFe5sgSftZBVaepXeSPB2bI9w7 IiCystQhnS9VWiA2CktNiwdVHo+JTUtUs/4rxBBwQouaRL1/slUdmpgqPqDOua5shOrP HDpw== X-Gm-Message-State: AHQUAuYpLIo/k0Yy5hKkIXwqfp6eZYcveYbo1A6y+rGW2ludTjBTJSuv 6VBJgcdIOsj+1z4hMT3zOgKSrVOKmFo8u6fLkyk= X-Google-Smtp-Source: AHgI3IaW6JDYG2S91QNc9bdpdwjSQCUcFklC6gxizg4az6sGXsTa1ki1kxJIJj39/1TFPure3e3q27PC6BAvf4nnTlo= X-Received: by 2002:a62:ee0e:: with SMTP id e14mr7095378pfi.201.1550192980272; Thu, 14 Feb 2019 17:09:40 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> In-Reply-To: <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> From: David Schinazi Date: Thu, 14 Feb 2019 17:09:28 -0800 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson Cc: quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000ec2a3c0581e46d1c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:09:43 -0000 --000000000000ec2a3c0581e46d1c Content-Type: text/plain; charset="UTF-8" One potential change to v1 that has come out of this discussion is that we could change the 32bit version number from 0x00000001 to a value randomly generated at RFC publication time. On Thu, Feb 14, 2019 at 17:04 Martin Thomson wrote: > On Fri, Feb 15, 2019, at 12:02, Martin Duke wrote: > > Collective, time for me to file a github issue? Or leave it on the list? > > What do you believe the issue would be? Because a lot of the discussion > here has been very much "quicv2" territory. > > --000000000000ec2a3c0581e46d1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One potential change to v1 that has come out of this= discussion is that we could change the 32bit version number from 0x0000000= 1 to a value randomly generated at RFC publication time.


On Thu, Feb 14, 2019 at 17:04 Martin Thomson <mt@lowentropy.net> wrote:
On Fri, Feb 15, 2019, at 12:02, Martin Duke wr= ote:
> Collective, time for me to file a github issue? Or leave it on the lis= t?

What do you believe the issue would be?=C2=A0 Because a lot of the discussi= on here has been very much "quicv2" territory.

--000000000000ec2a3c0581e46d1c-- From nobody Thu Feb 14 17:11:24 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144E3130E5A for ; Thu, 14 Feb 2019 17:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEEckBnnhofD for ; Thu, 14 Feb 2019 17:11:21 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 1AE96130DFA for ; Thu, 14 Feb 2019 17:11:21 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id v16so8549561wrn.11 for ; Thu, 14 Feb 2019 17:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sr1p+do96zFPHXJfkhtBEB1AiWnwyo5ipX9feEoolPo=; b=JwUHwVA4ZnZHVDQP7g1l/KVA3b7RbldTOfhi9BHnuBcR6tsQVzoanBsaRZdJGVNOkU B/JZy2m3dRkSSSMslDXdb7eqoT3y4QDSf2FaACLGoiwuurdjr4FDnlptB45oWIyKUNfa rDjqHxL6wLrxdInsbJx+uoJCnYDSfJazbrMzEt6yu0ilLh1K267HZPPkdxvPkamhQ4bC ZuJv3T8wfrBLKU9fAlasufnzIkmHIXjS9f+YdUJJlwWrsrQaqFGS/JCnLc3bzKGT7gIJ zWofIgIAR/RBogoUIvNrX3LnpFGoAmCx1CS6zfWdR46wMZP0RXc7RpnjRsUrqaDVy3Sx 43EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sr1p+do96zFPHXJfkhtBEB1AiWnwyo5ipX9feEoolPo=; b=e2zpI3U4aGsOzLkq+sOo4nn50j/OngZdaLXReBQfQkKQtritQ5JZ7f2Sev5sVE1Tci 4B3QZpbSUXgzA7cx+dOKoOfV16W8wtt4G1ZU7U/yhfBZBoW80++A7IiQ3O9827yNQwkK e1rrRw1W/ycJTfQxfIlSnszspd442yzK7wX/OhgHkM/kosBn/nLVADldLKs73QzcWKLe h9lRiCIB5ElCaZeYtVWVIe1vUQq9w17WJ5snimHgThxi8JNxj7VD1tjhEVoNY5eURTU0 ky/abTDymdGngnZHfxtsosrOmFiO5gPKCNXWaMHjUieYqHdk/VgfDn9Hp52ciF2ezFpk gf2A== X-Gm-Message-State: AHQUAuY00Yq3/a8fj0rinl2soXAOzkbqNJH6BzWTCzZJFMPPwWO135bp 4fBLEzG7+03rX5HqzUD3bQurzxCk2NXrUTAvbX2WDw== X-Google-Smtp-Source: AHgI3IYzyImO2TUo/lpuikdY3zFEofGqn21hLQ6houLNNWFsNzsrrismpgh0o2MlA4M72kzq696XgDHPHcoBduFVyj8= X-Received: by 2002:a5d:4841:: with SMTP id n1mr3417964wrs.85.1550193079381; Thu, 14 Feb 2019 17:11:19 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> In-Reply-To: <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> From: Martin Duke Date: Thu, 14 Feb 2019 17:11:07 -0800 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000d474470581e47374" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:11:23 -0000 --000000000000d474470581e47374 Content-Type: text/plain; charset="UTF-8" I think we are edging towards shenanigans in v1 deployments, possibly involving IANA action? On Thu, Feb 14, 2019, 5:04 PM Martin Thomson On Fri, Feb 15, 2019, at 12:02, Martin Duke wrote: > > Collective, time for me to file a github issue? Or leave it on the list? > > What do you believe the issue would be? Because a lot of the discussion > here has been very much "quicv2" territory. > > --000000000000d474470581e47374 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we are edging towards shenanigans in v1 deploymen= ts, possibly involving IANA action?

On Thu, Feb 14, 2019, 5:04 PM Martin Thomson <mt@lowentropy.net wrote:
On Fri, Feb 15, 2019, at 12:02, Martin Duke wrote:
> Collective, time for me to file a github issue? Or leave it on the lis= t?

What do you believe the issue would be?=C2=A0 Because a lot of the discussi= on here has been very much "quicv2" territory.

--000000000000d474470581e47374-- From nobody Thu Feb 14 17:13:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF5D130E5A for ; Thu, 14 Feb 2019 17:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=m2zqh8H2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jaDiYUL2 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 dxhfCKPCcQRd for ; Thu, 14 Feb 2019 17:13:17 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B24130E6B for ; Thu, 14 Feb 2019 17:13:17 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2E1A622075 for ; Thu, 14 Feb 2019 20:13:16 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 14 Feb 2019 20:13:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=LPwEHWdn4oxJ6vjd9laTp2pzxvkKREg9KnPtGxp Dz/I=; b=m2zqh8H2wIdHzWsWRYiktCZ7y7MK7oTpD0t+MetKpsrTBXPOFF9wI0a uP+9gx+Xt85jPNGG8Ck0lQBI9ZLqPM9ZCs8Leo1clGjtm63b/V6CGRNztYMa+OAU r9DAqEqKB6uCI/S55W/FdBBhfbudBx2fTlR4/dFLyZ+w9LMzNBAZUT3J4SwaZVKq eXH+RzKavAqWjxvaGplPaaE0onhMZoMEPTnGqdsMjK6LnEldsfubxVb9A2MQc1Zx az9M1l8/GkWbi4klOGbPhvb3DqYkksTbUcj+V/vLEf7JFIfHYnmjYbeAjr9JAC10 3Zt/FmDnD3AKfWT10fmy6PdZJ39QxaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=LPwEHWdn4oxJ6vjd9 laTp2pzxvkKREg9KnPtGxpDz/I=; b=jaDiYUL2AvLsiHRLqIz2w3g/2sToh9qnr 1Gfn0igdlFD+vg6HcFjXsf3KrbEs4OHHxN5kr6Cx0+mlndFFzrcUSAE5dE4YdstX fL8yDfUPwOPTx66ZdbteuET3YR57gvom2M4UMj77ZWirxQPI+asLdxwwa9TgjK25 hbFrL7/FkrYvmlJGJ/J9eUNdfwaUv9ugBpCK+FIu9/xi6wyoHMj+gXaXj0i/+Nak ZNj5AvNlRpybR62bnWJtkL5/swIOQOa7W2cCMva2K+mibBhV+zGUGKQby7RiXW1P mx+ElQZc4CIOKlcQBzWEJecEAPOrJLn7kfCTgWw+DE7fl8H6+oMvA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpe dfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvght qeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth enucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8E3687C21A; Thu, 14 Feb 2019 20:13:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 92534000 Message-Id: <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> In-Reply-To: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> Date: Thu, 14 Feb 2019 20:13:15 -0500 From: "Martin Thomson" To: quic@ietf.org Subject: Re: QUIC ossification Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:13:18 -0000 On Fri, Feb 15, 2019, at 12:09, David Schinazi wrote: > One potential change to v1 that has come out of this discussion is that > we could change the 32bit version number from 0x00000001 to a value > randomly generated at RFC publication time. I didn't get an answer to my questions about that, because that seems silly. On Fri, Feb 15, 2019, at 12:11, Martin Duke wrote: > I think we are edging towards shenanigans in v1 deployments, possibly > involving IANA action? The IANA bit would be a good one to track. For some reason that is lost to me, we decided not to have IANA manage this space. I never really understood how that was supposed to work, so I would definitely support having them take that bit over. From nobody Thu Feb 14 17:22:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DFD130E79 for ; Thu, 14 Feb 2019 17:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvnqNDjyB-OW for ; Thu, 14 Feb 2019 17:22:24 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 81D2F130E6B for ; Thu, 14 Feb 2019 17:22:24 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id q1so8594107wrp.7 for ; Thu, 14 Feb 2019 17:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8plzfQp/CPPLB+werMB98Q1R7Lt0HmZYjrXn4qaYy9M=; b=oaicx0/UbhY77mOIu17aPmPbYAF3pMy2lxbQJ5E/VgjthFunmpxP3jo0gn50aXxglD EaAjd/8/GxJZoOAMlDJFvPXoOHta7pPmfZyzsrMab3ELOK73gxpAy2L6mKmGi8BnaSRH xlZ5das+ETM0La8l9SwsH4PcnRVjfqdCfqRrCN/JHtyMvh5HRT+0izCwT8dmB9UkED7h 0pliKIzyUIXiY/IW89v2BBtP8rSOU15YeG4EHUlFb3+YJgog+zUvX0oD3Rc2ghLGNg5g B2JP2yaGcDOXw2271MPPmX9WfPHyYkMalx0FwvKHWkaKocfhlyRHtIsj2RW+pG1s57Uj guqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8plzfQp/CPPLB+werMB98Q1R7Lt0HmZYjrXn4qaYy9M=; b=qkob1u60mf8jrwoB8U+PyMlGjApq9YpnIlaR5r59kvk3XF42tfjqu8czPWvZTwsXns HVTRe97iidrogzqjbx18eGJa5dNlTu27VJdHTuZL370TbwVjRA/uMbIMhWm2+oNNDrK8 JR4gR25tfLRJguh9rQ3nxZxdZLgGxUsX3jolQIY9PmydYdHWXtQKMS/lB4GNEH9t8A10 wQj7w/8E2yFlnLQGSGUgru+uREx6iT7mhQhP2VpMdo1gM0ZjwtGBLe5npkV+Kxo5gySz L5w/ln/BdfFz5a2lkVg2wfWTKtMBB6Hj8sVeJhoPThgJ+3+cO9z2MLd1YYoLwZFXZcmp UjRw== X-Gm-Message-State: AHQUAuYM/SCxYgY8yUQcfsymByi2W3jMKmdNg2di5rnH405NolKPwEEX uAfUTMKcR6zhZkVg2W4LLy8EGzyEX2lOPXHbOP27Ww== X-Google-Smtp-Source: AHgI3IbJcwFzgr4alVgic54o3hX7j1w/83dZgfljLjaKKEmzTOLeWszCkVcyxRMSHXdhixEtC56c1o9ESOAzLG+cVqg= X-Received: by 2002:adf:eb07:: with SMTP id s7mr4963053wrn.158.1550193742697; Thu, 14 Feb 2019 17:22:22 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> In-Reply-To: <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> From: Ian Swett Date: Thu, 14 Feb 2019 20:22:06 -0500 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000005e529b0581e49bf0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:22:27 -0000 --0000000000005e529b0581e49bf0 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 14, 2019 at 8:13 PM Martin Thomson wrote: > On Fri, Feb 15, 2019, at 12:09, David Schinazi wrote: > > One potential change to v1 that has come out of this discussion is that > > we could change the 32bit version number from 0x00000001 to a value > > randomly generated at RFC publication time. > > I didn't get an answer to my questions about that, because that seems > silly. > I believe the concern is that a middlebox/etc will conclude that a certain range of versions are IETF standard versions and should be allowed and others are fine to block because they're experimental, thereby making the majority of versions largely undeployable. > > On Fri, Feb 15, 2019, at 12:11, Martin Duke wrote: > > I think we are edging towards shenanigans in v1 deployments, possibly > > involving IANA action? > > The IANA bit would be a good one to track. For some reason that is lost > to me, we decided not to have IANA manage this space. I never really > understood how that was supposed to work, so I would definitely support > having them take that bit over. > > --0000000000005e529b0581e49bf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 14, 2019 at 8:13 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
On Fri,= Feb 15, 2019, at 12:09, David Schinazi wrote:
> One potential change to v1 that has come out of this discussion is tha= t
> we could change the 32bit version number from 0x00000001 to a value > randomly generated at RFC publication time.

I didn't get an answer to my questions about that, because that seems s= illy.

I believe the concern is that a m= iddlebox/etc will conclude that a certain range of versions are IETF standa= rd versions and should be allowed and others are fine to block because they= 're experimental, thereby making the majority of versions largely undep= loyable.
=C2=A0

On Fri, Feb 15, 2019, at 12:11, Martin Duke wrote:
> I think we are edging towards shenanigans in v1 deployments, possibly =
> involving IANA action?

The IANA bit would be a good one to track.=C2=A0 For some reason that is lo= st to me, we decided not to have IANA manage this space.=C2=A0 I never real= ly understood how that was supposed to work, so I would definitely support = having them take that bit over.

--0000000000005e529b0581e49bf0-- From nobody Thu Feb 14 17:52:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3B512950A for ; Thu, 14 Feb 2019 17:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRpa5k3MEnRl for ; Thu, 14 Feb 2019 17:51:57 -0800 (PST) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 1CAB21310E1 for ; Thu, 14 Feb 2019 17:51:57 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id q11so6025385lfd.3 for ; Thu, 14 Feb 2019 17:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9T+e/61cjpi49hGxagu0qptzOHOEeSc62rhY58aUAc0=; b=RX3iqLFs6Cgw1M0VCe6XAk2UpOAV+REUMo5612UjXhD9yElOnzGHtbQOoh3jgI4Dop a57jDi0M/C2wpYdx6YY3qVKVQjLpLL8mbPhX/IzdOFHMgmkN/ZKJFTDJ6pEs4dwTU3WQ s/zJaJHMSiAdP6PdSjOApRe0Z/0b1TeCchm6wfLFdsg82LJkJELsyl82DxpF/nVRMw2K gYYq/SdUxd+0OKR6K4Daidz7Apr2pyx3iXz1w6KIJOcBAr7k7x63NGiblRBh0FVynq7e ZSS237iAYeF8idipxtVBUg8W2TQR79QDjOMExJf/cSWdL5nmvdsLhSoXGKyTh+KsS6W7 hOxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9T+e/61cjpi49hGxagu0qptzOHOEeSc62rhY58aUAc0=; b=DNjIQdJ+0CFAKqAQuWI77LGvBozK2PEmeGEf5LSB5n0Zzk52QBgbsmEMW5UAw4Zk3i NCaohj9Of6DX9AZcJFFerkTYL5OvnowwCHJlJZMh3KPOyt/Kk4vuANiOpYqfesyAwzER nz+lkcDWfiCzlnqoRqvOkAb3uIwm0zqbtDRgxmRsfjkwWRCJcB9JIIJZPFqL452Vqauw DDjGvqfNqoR6wNoukpd8WcPC+GexyXcn7bMWnLjlBXUyrqJOnkTCHQWmH4ncsNNBHIe1 BQvyil/BeWUguGOouY9s9ks31jprio3Loa4dWwrrvLbFs1JTfrlHKq0G6IFT4/qR+oXa UvJg== X-Gm-Message-State: AHQUAuaO0THpwXCqEmPxAIfQLnCw0DY3J59gcT+rf/nbmhuGbLLse4r0 a6S6BHqEqpYTYehCrTfnQ+0LgUdegjKffs9XImc= X-Google-Smtp-Source: AHgI3IbxxKyG/rcTyt2rkTidUYvqNGcCgJwkLCbXyk4n9pBOVtwO5PNAk431BF3FfYFRrTBNcyPzzLeyDp0tb93MIjs= X-Received: by 2002:a19:7b0e:: with SMTP id w14mr4006622lfc.8.1550195515144; Thu, 14 Feb 2019 17:51:55 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> <045bbf5b-04e4-4f9f-886b-f7ff9254bdab@www.fastmail.com> In-Reply-To: From: Kazuho Oku Date: Fri, 15 Feb 2019 10:51:43 +0900 Message-ID: Subject: Re: KEYS_READY To: David Schinazi Cc: Martin Thomson , Jana Iyengar , Ryan Hamilton , Marten Seemann , Mike Bishop , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:52:06 -0000 2019=E5=B9=B42=E6=9C=8815=E6=97=A5(=E9=87=91) 9:18 David Schinazi : > > > > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson wrote: >> >> On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote: >> > This means that the server sends KEYS_ACTIVE(1-RTT) not when the 1-RTT >> > keys are active, >> > but instead when the handshake finishes, which is when the server has >> > received the client finished. >> > Those are two different moments in time. >> >> Yes, because the keys aren't active when the server starts sending 1-RTT= packets. They are only active when the server starts reading 1-RTT. The = server can't activate its 1-RTT reading keys until the handshake is complet= e. > > > Ah, thanks. Looking at it this way it makes sense to me - we may want to = make the text clearer in case I'm not the only one who was confused. > >> >> That's why I chose to name this KEYS_ACTIVE(this), not RETIRE_KEYS(prev)= , but I don't really mind what it is called. > > > I don't feel strongly about names either as long as they make sense - and= now KEYS_ACTIVE also makes sense to me - so either name is fine by me. > >> >> > My proposal is to have the client decide when it is done with the >> > handshake keys by having the client >> > delay sending RETIRE_KEYS(Handshake) instead of the server delaying >> > sending KEYS_ACTIVE(1-RTT). >> >> This requires that the client send more Handshake packets. And it adds = a lot of delay because the client has to wait until all its packets are ack= nowledged. We previously agreed that any such signal from the server is mo= re direct and effective. > > > I don't think it means more handshake packets. And it's still a direct si= gnal between endpoints. The only difference is that the client-to-server RE= TIRE_KEYS message is delayed by one RTT compared to its KEYS_ACTIVE message= so the server will wait one RTT before throwing away handshake keys. But i= t has the advantage of not requiring any implicit ACKs. So the tradeoff we'= re facing is between allowing the server to throw away keys sooner at the c= ost of making implicit decisions. This implicitness means KEYS_ACTIVE does = not allow the client to be able to send anything in Handshake after the Cli= entFinished. I'm worried that might prevent protocol changes down the road. > > I'm still in favor of paying the one RTT before key deletion to make the = protocol more explicit. I share the same view. Admittedly, it means that then the frame would no longer be useful for dropping the Initial keys, assuming that we want to drop them ASAP as we do now. But even with that downside, I think it makes sense to delay when the handshake and each generation of 1-RTT keys are dropped. After all, we can argue that the requirement for when to drop the Initial keys is exceptional due to security concerns. Hence something like https://mailarchive.ietf.org/arch/msg/quic/NNOzxNWldmfiUN9avCdiQMNVXMw. --=20 Kazuho Oku From nobody Thu Feb 14 18:43:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8E130E96 for ; Thu, 14 Feb 2019 18:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=laYVYlKu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o9c+iJV1 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 AGoN1Nss-FWx for ; Thu, 14 Feb 2019 18:43:07 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8AF130DE3 for ; Thu, 14 Feb 2019 18:43:07 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0538422101 for ; Thu, 14 Feb 2019 21:43:06 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 14 Feb 2019 21:43:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=6GllVLfJWQuBQsG0OVVi0UNhpGbQYj0eBWPAIHZ TM5o=; b=laYVYlKuc2GLj/vQzyU3S4lC4Cdod0BAKzXAB3gG2DDTm4F43kr5IFa /rUAHqgMD7FYraNX0QFNaWj5kco7/7MdfY2nLYXRb/+MHSrC66JApg9kMLFRn94w o69ekOjy4ET3y3ySN+/8zjTQimmFQtDzK9jYQELDk04HcRk0GoJwKSUjlJMLTC2b 0V6eYgePm0kDSo/A3B0zDYfiK2kadiT+orc8U6K837Ylrg8Ks0uDtTqbeQ+Gv5Ke rNbXruLT61qxmjIpcyorcNWf86oCTl1BjtzXnKxEfKDnLu6T0BliGSBjbLVN+obH HE3zwV2o3D94SBAX0wdplRuwSuUUAPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=6GllVLfJWQuBQsG0O VVi0UNhpGbQYj0eBWPAIHZTM5o=; b=o9c+iJV16Q7EP/1aGarBL0D8QdWyaKvQZ ocrfwYEELV9VvfnpyC5Iv+9k5RTNnV4LTERR5+29v3FayksNb3klcsZotJHdMbas 6bVqa2Ow1Rfu9tg92+xqAh7sK/6RHvIobv5SzT8UPl8QVRntu6AYGfxs/c6NVZ1m 0lh8EuXQBwWLPr1SG8bXVqo1PbMJofcuiOAnXlH1oj12JZofa3+xVPhnjfCuMLvf EAfAt9aEoKn6SRg6YhYoqFAX58XVgDl9vWLSt/qJKItEy3wKbLh6vtRxWKGZ9kpl SlT8HQ/KlqGRHGTloScBnu+Gjol2pvoxzzSbLV5mQE5XjKi+ZZUTw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpe dfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvght qeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth enucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 36B227C1EB; Thu, 14 Feb 2019 21:43:05 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 92534000 Message-Id: <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> In-Reply-To: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> Date: Thu, 14 Feb 2019 21:43:06 -0500 From: "Martin Thomson" To: quic@ietf.org Subject: Re: QUIC ossification Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 02:43:10 -0000 On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote: > I believe the concern is that a middlebox/etc will conclude that a > certain range of versions are IETF standard versions and should be > allowed and others are fine to block because they're experimental, > thereby making the majority of versions largely undeployable. That only suggests to me that we not segregate the space. The proposed variations won't all happen in that space. From nobody Thu Feb 14 23:33:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5CA12867A for ; Thu, 14 Feb 2019 23:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 6u2lZye1etXL for ; Thu, 14 Feb 2019 23:33:13 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 3BF69128766 for ; Thu, 14 Feb 2019 23:33:13 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id b17so7164555eds.2 for ; Thu, 14 Feb 2019 23:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=e+fm07zEL2zJj4ZYINkzr1A8jGPi9nmuKhkbjOQzeKA=; b=J3sGEsg2IHyKf26ZVfnWezlye7LFJ+kOnQ4b0Ko2N0172m8eYp08/KQkT0Qqsbb+id jz4iFl8AGqZG4xq2s3iRhqNtK8mtaEBXmCZxRiz96HfswpnVRhuAfFIqM6zCmBxTmuMb qZqruHoXVKtcUJ9p/fpjmQRTHOUhXs/EMjec/b2wtPV6zfd+vPKAGxHNL0MG7N53iKmw DKoKe5RtKLSEUhqh43mACfzTB/ZkSGiKOphXGT3kbKN5nNXKH3frPgoIbZgIye/k7MKX 0qTLO2EjMr536KO8ct6zRKRq2YtyKAn7IEDHoDwkYiA9Gp6Dl0aCeXSKie/tMFabwAx/ HviQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=e+fm07zEL2zJj4ZYINkzr1A8jGPi9nmuKhkbjOQzeKA=; b=G3YISVeQebCv8+GyDX13+ScDtd2Y9tUOjKqMHhdBwyHTCNYf1rO7AWDdcp4GcsqfZT /BCf0lUPXRhAxazdI6Q6Wrsy4WHGjzfFwh055c77QWWwjRrTwMXf+ZLE8Vr2uOpmbTvt u6eGuyW6bQDmzPj0okaSwFR7J8/tRB7Lm0KR5qjcACJ4GB0LQF+prPGuS4bZ93lw0r76 PeO6YhOs/lywbrGHRMgdWqIAXxZybYm8ipIN9hMV/fJlFbugV6e7R1MYyKKSuHbGGvY6 weeNVUaTu7yRbdEy1aOmFOgi64oIMI04JgPF5JYgFCoVANNcki+7RWPdrxgYl+7luqlc 7Xfg== X-Gm-Message-State: AHQUAua/CXGhRUKa8+l0MrMjl73q6bBTkiX8h4k4JjceuuWf9CADw82m FmB9UBZ3KyveYnz2A0EZqZ3VBLAd X-Google-Smtp-Source: AHgI3IYOVD9xuD7bZBKhZ4tLxF/LjSvf536U3s/n6p3GCoqYvJZtlT6GhRs0d0KJPg6aV/OloReeRw== X-Received: by 2002:a50:a622:: with SMTP id d31mr6682015edc.228.1550215991393; Thu, 14 Feb 2019 23:33:11 -0800 (PST) Received: from VI1PR10MB1773.EURPRD10.PROD.OUTLOOK.COM ([40.101.76.245]) by smtp.gmail.com with ESMTPSA id c9sm1344733edk.15.2019.02.14.23.33.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 23:33:10 -0800 (PST) From: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Martin Thomson , "quic@ietf.org" Subject: Re: QUIC ossification Thread-Topic: QUIC ossification Thread-Index: AWczejBHlg6ZkPl9jCqzvp1n/7+8K0UwNjUzOTU0NEJBa1U1azBBNDQ0QXZQWVBneVRiZWd0dUI4UU1oMVQyQkY0M3d5dHkrMzU4NERBYVlQMTRmYmVhQWRDT0JBMStoamdBa2lBODE2NjVBUEgzcEYyNzQxMEM4QzFRdjhHSzA1MDkwZ1BGR0tndHNmNjA1YTRjQUJ5K3piNWY0YkFDckdkODIyNDmaRCTVYA== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 15 Feb 2019 07:33:09 +0000 Message-ID: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> , <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> In-Reply-To: <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_VI1PR10MB17737A81D9F0B9E90A49423FAC600VI1PR10MB1773EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 07:33:16 -0000 --_000_VI1PR10MB17737A81D9F0B9E90A49423FAC600VI1PR10MB1773EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It would be useful with a private version range that can be deployed in a l= imited context without involving IANA. ________________________________ Fra: QUIC p=E5 vegne af Martin Thomson Sendt: fredag, februar 15, 2019 3:43 AM Til: quic@ietf.org Emne: Re: QUIC ossification On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote: > I believe the concern is that a middlebox/etc will conclude that a > certain range of versions are IETF standard versions and should be > allowed and others are fine to block because they're experimental, > thereby making the majority of versions largely undeployable. That only suggests to me that we not segregate the space. The proposed vari= ations won't all happen in that space. --_000_VI1PR10MB17737A81D9F0B9E90A49423FAC600VI1PR10MB1773EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It would be useful with a private version ra= nge that can be deployed in a limited context without involving IANA.

 
Fra: QUIC= <quic-bounces@ietf.org> p=E5 vegne af Martin Thomson <mt@lowentro= py.net>
Sendt: fredag, februar 15, 2019 3:43 AM
Til: quic@ietf.org
Emne: Re: QUIC ossification
 
On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote:
> I believe the concern is that a middlebox/etc will conclude that a > certain range of versions are IETF standard versions and should be > allowed and others are fine to block because they're experimental, > thereby making the majority of versions largely undeployable.

That only suggests to me that we not segregate the space. The proposed vari= ations won't all happen in that space.

--_000_VI1PR10MB17737A81D9F0B9E90A49423FAC600VI1PR10MB1773EURP_-- From nobody Fri Feb 15 05:54:01 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A120412D4E9 for ; Fri, 15 Feb 2019 05:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18QrkeP5Pzfq for ; Fri, 15 Feb 2019 05:53:58 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 288D412D4E6 for ; Fri, 15 Feb 2019 05:53:57 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id l10so7229107lfh.9 for ; Fri, 15 Feb 2019 05:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YTl4wTnkvyyk3IkJycEb9gJhPItSg/XcNJ9alVtJnkU=; b=LevuCwMQ7ZRjb6WMLjiR9PLErwWM2OpPSBHFh4M5acWNQiP8U7Dbb3dUNcbPoke25M Z4H0/3iJ0Vh8uUS//OYzBSv2pwCtst42LtkqsybZtot5avGW2TsY0Py/nLlQdNFhWGtP TNS3sxDe68kfeSuFEYgKO9TdHeH4S9qbg5kK3uMl+kZq4JJWtSXvbHdPW3+CDTMVjFfX oFY5c9KoJtJhHXUhem0Y2+BzgJpQ0ERfu3l9D4kLAYo7M0OEwRgkShR/4RVjsdC3dyLM WBCs9Bvgg9x92l9HSfeOOzwM7aLKf6yE6UM/tGh4GNXxN2JH27vSdn9fmg2Xdm8DUa/8 1XKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YTl4wTnkvyyk3IkJycEb9gJhPItSg/XcNJ9alVtJnkU=; b=SU2qadCnbSFSwiJtZIS43RyG3QrMNs9x2VoHkoIxnUi3wPEUPXb6KbxAGc8fPn6Kij rvlm/+Uw+WclotH8sdp5fRsVL1ZSloHxcIfeS/7HXkJSlaKuoDurgiLIGFKNVOh2EvPB EZLYAF8gEvoAqnHMp2fNxPUcroIsc3YamMIgac7NGdcugX3WrSFKwDMt9+fZlWqzP8U5 RiDXewWHeeseRfrnmibBBMaQVdPs1uIDVrCzuj8JL5zHlJ/TBQLeZnkzGkc+gU66ukzo pMfeMoqwewL/9/PmTW563N2hZ05MosAHUwj2PG7m6p4CdZYU/hass650xKw6Wb6W98Hk EbMQ== X-Gm-Message-State: AHQUAuasCJMR8LK1m9LLNNaLDcaIx85ZE4TdKQM2pb70aaJEt1+vn/I0 iMUDYeOB8AZ4RHVTB7H2rrmsv+Ph5Ic5XmBL2UE= X-Google-Smtp-Source: AHgI3IYIUJH+4Eh0IT1iptekGYo21gUy49ahhPFCznc4Z2nJvQqeVvJHGHCR2FPvl0OZQij0le9gNZ2DxwpOdYqtxcQ= X-Received: by 2002:a19:c116:: with SMTP id r22mr5605269lff.32.1550238835852; Fri, 15 Feb 2019 05:53:55 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 15 Feb 2019 07:53:42 -0600 Message-ID: Subject: Re: QUIC ossification To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , "quic@ietf.org" Content-Type: multipart/alternative; boundary="00000000000020c8f70581ef1b0c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 13:54:01 -0000 --00000000000020c8f70581ef1b0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking as an individual who is trying to be helpful :-) On Fri, Feb 15, 2019 at 1:33 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > It would be useful with a private version range that can be deployed in a > limited context without involving IANA. > > > ------------------------------ > *Fra:* QUIC p=C3=A5 vegne af Martin Thomson < > mt@lowentropy.net> > *Sendt:* fredag, februar 15, 2019 3:43 AM > *Til:* quic@ietf.org > *Emne:* Re: QUIC ossification > > On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote: > > I believe the concern is that a middlebox/etc will conclude that a > > certain range of versions are IETF standard versions and should be > > allowed and others are fine to block because they're experimental, > > thereby making the majority of versions largely undeployable. > > That only suggests to me that we not segregate the space. The proposed > variations won't all happen in that space. > So, yes, I get the interest in being able to dork around without immediately having to involve IANA, and I think you're both exactly right to point to the tension/tussle between people wanting to know what they're admitting and people wanting to experiment. ISTM (keeping in mind that TSV ADs are stuckees for appointing services and port number registry expert reviewers) that this is EXACTLY analogous to transport-level port numbers, except (for extra credit) all the transport stuff in QUIC is encrypted, so anyone who cares about what they're admitting has to look at something else, and if anyone has a better suggestion than looking at version numbers, you should probably tell the working group, which will immediately encrypt it :D So - if you don't want people to squat on version numbers, which has been problematic for port numbers since the 1980s, you probably want a segregated version number space for experiments, and if you think (or observe) that people who care what traffic they are admitting are blocking experimental version numbers, you probably want that space to be so small that it really can't be used for wide-scale, long-term deployments. I'll stop typing now, and let people like Lars, who has forgotten more about port number reviews than I've ever known, tell me why this is a bad plan ;-) ... Spencer, again, as individual --00000000000020c8f70581ef1b0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as an individual who is trying t= o be helpful :-)=C2=A0

On Fri, Feb 15, 2019 at 1:33 AM Mikkel Fahn=C3=B8e J= =C3=B8rgensen <mikkelfj@gmail.com<= /a>> wrote:
It would be useful with a private version rang= e that can be deployed in a limited context without involving IANA.

=C2=A0
Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne af Martin Tho= mson <mt@lowentro= py.net>
Sendt: fredag, februar 15, 2019 3:43 AM
Til: quic@ietf.or= g
Emne: Re: QUIC ossification
=C2=A0
On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote:
> I believe the concern is that a middlebox/etc will conclude that a > certain range of versions are IETF standard versions and should be > allowed and others are fine to block because they're experimental,=
> thereby making the majority of versions largely undeployable.

That only suggests to me that we not segregate the space. The proposed vari= ations won't all happen in that space.

=C2=A0So, yes, I get the i= nterest in being able to dork around without immediately having to involve = IANA, and I think you're both exactly right to point to the tension/tus= sle between people wanting to know what they're admitting and people wa= nting to experiment.=C2=A0

ISTM (keeping in mind t= hat TSV ADs are stuckees for appointing services and port number registry e= xpert reviewers) that this is EXACTLY analogous to transport-level port num= bers, except (for extra credit) all the transport stuff in QUIC is encrypte= d, so anyone who cares about what they're admitting has to look at some= thing else, and if anyone has a better suggestion than looking at version n= umbers, you should probably tell the working group, which will immediately = encrypt it :D

So - if you don't want people to= squat on version numbers, which has been problematic for port numbers sinc= e the 1980s, you probably want a segregated version number space for experi= ments, and if you think (or observe) that people who care what traffic they= are admitting are blocking experimental version numbers, you probably want= that space to be so small that it really can't be used for wide-scale,= long-term deployments.=C2=A0

I'll stop typing= now, and let people like Lars, who has forgotten more about port number re= views than I've ever known, tell me why this is a bad plan ;-) ...

Spencer, again, as individual
--00000000000020c8f70581ef1b0c-- From nobody Sat Feb 16 07:48:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4CE130EF9; Sat, 16 Feb 2019 07:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4mWv4_k17F0T; Sat, 16 Feb 2019 07:48:02 -0800 (PST) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (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 5BEDF1275F3; Sat, 16 Feb 2019 07:48:02 -0800 (PST) Received: by mail-lj1-f174.google.com with SMTP id z25so3028546ljk.8; Sat, 16 Feb 2019 07:48:02 -0800 (PST) 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=fjM90OsfjVfZcKva1VBJ7ZCVovtil0kJiZnlpMYkzSc=; b=aNM6sPcNw1BJi/dPnUu+spBnayGBVVyPlh1Xi8WOBEm/G3fbasIYMUFF7+qTpU3yRb +2dRtZO8I5qJl5CDu98JnvErJk4UTEV+ewGzGnXhOu2+alTGoHPNTKD57bcSdEKNfDj0 azAf096WbDYiP1dThqZcPrQ0IdNXTpnBKX7lkgi/vlR0hSebcRCwW7dp+cwSYd9g5uZN F/QxurovDVKVuHH2bmRY4M/YljU9I3W+i/PP0Dk4Uv5zb2+kK2WYFFJdJ1hrvG0McNOw pKB8hub+d18MFJx0sxvT7D/mrr7Int9uHhZZByP1jfEVfMf5f97GI26p5SMlyawjhV1d S4oA== X-Gm-Message-State: AHQUAuYth/C+iXlXl8Ihx2JQj+6LuLzMKoI4o4uKwQeFCNEdeQfdVCL8 g/FXI42hDh+UGurxeurLZ6OOSniWaMLvoTajxUaWVNWU X-Google-Smtp-Source: AHgI3IYWU738Zm0AxQrUky2fQHoe0kn2kE0Xl0R+ytlv5W56dYdQozHkNO7agwKz054zFLAZqiFhW2+bAeEdANOx8pI= X-Received: by 2002:a2e:6505:: with SMTP id z5mr3413640ljb.180.1550332079900; Sat, 16 Feb 2019 07:47:59 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Sat, 16 Feb 2019 10:47:48 -0500 Message-ID: Subject: netdev0x13 - ietf related topics To: tls , IPsecME WG , saag@ietf.org, nvo3@ietf.org, sfc@ietf.org, quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000e80cf2058204d014" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 15:48:05 -0000 --000000000000e80cf2058204d014 Content-Type: text/plain; charset="UTF-8" Hi, Please find among many others some IETF related topics [1] that will be discussed at netdev0x13 just before the IETF meeting in Pragues. Early bird registration is open until February 20. !!!! Netdev 0x13 will be held at Hotel Grandium in Prague, this spring March 20th - 22th, 2019 Yours, Daniel [1] https://www.netdevconf.org/0x13/IETF-relevant-talks.html --000000000000e80cf2058204d014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

=C2=A0

Please find among many others some IET= F related topics [1] that will be discussed at netdev0x13 just before the IETF meeting in Pragues.

=C2=A0

Early bird registration is open until= =C2=A0February 20.=C2=A0!!!!

=C2=A0

Netdev 0x13 will be held at Hotel Grandium in Prague, this spring March 2= 0th - 22th, 2019=C2=A0


=

Yours,

Daniel

=C2=A0

[1] https://www.netdevconf.org/0x13/IETF-relevant-talks.html


--000000000000e80cf2058204d014-- From nobody Sat Feb 16 14:18:29 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6269B1286D8 for ; Sat, 16 Feb 2019 14:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcYQcktbBaoX for ; Sat, 16 Feb 2019 14:18:26 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0099E128D52 for ; Sat, 16 Feb 2019 14:18:23 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A4F0B340F86; Sat, 16 Feb 2019 23:18:21 +0100 (CET) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/3959.9362); Sat, 16 Feb 2019 23:18:21 +0100 (CET) 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; Sat, 16 Feb 2019 23:18:20 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.83]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.2.9) with ESMTPSA id 83423675; Sat, 16 Feb 2019 23:18:20 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: QUIC ossification From: "Brian Trammell (IETF)" In-Reply-To: Date: Sat, 16 Feb 2019 23:18:19 +0100 Cc: Martin Thomson , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> To: Ian Swett X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 22:18:28 -0000 hi Ian, all, > On 15 Feb 2019, at 02:22, Ian Swett = wrote: >=20 > I believe the concern is that a middlebox/etc will conclude that a = certain range of versions are IETF standard versions and should be = allowed and others are fine to block because they're experimental, = thereby making the majority of versions largely undeployable. So if I understand the proposal behind this correctly, then, there would = be no segregation of the version number space (aside from "grease" and = "nongrease"), the entire non-assigned version number space would be = IANA-managed FCFS, and the IETF-standard versions would grab random = codepoints out of that FCFS space at publication time? That fixes the "middleboxes preferentially block experimental versions" = problem, at the expense of maybe edging them toward blocking everything = that isn't IETF-V1.=20 This is of course assuming that middleboxes exist that have an incentive = to block non-V1 versions while letting V1 versions through. I could = maybe see firewalls with default-deny policies wanting to "offer" this, = but I don't see why a box deployed to blocking any QUIC on purpose would = need to be picky about version numbers. Given that the TCP fallback = makes it connectivity-safe to block *all* QUIC while also gaining the = "advantages" (from the middlebox PoV, with respect to wire-image = accessibility and wire-image editability) of TCP, just turning QUIC off = is easier than having to keep per-flow VN outcome state. going back to a point Ted made on Thursday, though: > As a personal opinion, I think we have enough semantic additions to do = here that we don't need an artificial version which will have no natural = driver of adoption. +1 to this. I think I've said this before, maybe multiple times: the only way to = keep version negotiation from ossifying it is to use it for real. I'd = argued for shipping v1 and v2 simultaneously, perhaps with different = feature profiles (indeed, we even discussed using the spin bit as a = version-differentiator to exercise VN, but this turned out to not work = very well for spin-bit-and-connection-ID physics reasons). It seems = we're not going to do that: we'll ship v1 and start work on v2 after = that. I observe that there's an ossification window for version negotiation = that arises as a logical consequence of the process we're following: = after v2 ships, if it sees wide deployment, version negotiation as a = mechanism will be protected (yeah sure some lazy middleboxes might = hardcode two version numbers, but see above for my skepticism about the = likelihood of that). Until then, it will not (grease notwithstanding, = but grease isn't real protection for VN because it's safe to ignore).=20 The risk of VN breaking is a function of how long that window is, and = how quickly middleboxes that understand QUIC versioning will deploy. = Recent proposals (I forget the details, have been paying only cursory = attention during my month off) to punt VN to version 2 in essence make a = pessimistic bet about this risk: anything we can design will be broken = by the time we try to use it, so let's design it later.=20 I think if we care about designing VN into V1 that has a chance of = working, though, being aggressive about shipping V2 is the only action = under our control as a WG. Cheers, Brian= From nobody Sat Feb 16 16:45:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3B812785F for ; Sat, 16 Feb 2019 16:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ur830vPi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=APTXlj9p 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 uSZqNELq7lhb for ; Sat, 16 Feb 2019 16:45:25 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F33124BF6 for ; Sat, 16 Feb 2019 16:45:24 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8413E21ECD for ; Sat, 16 Feb 2019 19:45:23 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 16 Feb 2019 19:45:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=b0XEBp/b4iTDAVr6tEjCZJmS5CiEpX3XgR7J91BFYFs=; b=ur830vPi 34wWYlJdAlelQMTDq3a8CNHtHRfOtJrLjZE7q0RUvCcHosz4RR87l4Jv8AaPQnyp 2ckmEdhKvrBuJed1p+ecnhPFfRmE/9N2xInyzy0iRgayGhwWNhXMa1d7tMSRPNcz CkllqfehWyJ7ksOeIKBHfN9KRIjiz57OV+Kog4u7OblcRX+/7d1thXIyXl8Je9O3 7mqkGHBlw5xAlUoFLaky9U21Tfw0pBtj2U7vwzTzg8x2CtdVBHV9/aPIJWRSDgWK ue4tFYHuoWCzdHZtiA8mq2mSxvacPP5THcYw26zOaiMMW6xdf/HGxJK0W2ivI9uG 0Mu7l5YHhMUvhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=b0XEBp/b4iTDAVr6tEjCZJmS5CiEp X3XgR7J91BFYFs=; b=APTXlj9p+/QvTjfBOpjGg8N4oUTL5BHFoWxuJbqyHOd/C 6G235VWEdMBOgtJ7fRk5n4Q0qMyhcujGSQgCLEsizeL3Iy/85I71DctEKXVA425L z+FUGuYzsa6tLoLvnlgYiO5rHnK2R3PW4/1Pq/PiwbomymrhPRRFiVGsrD5lGfZv BfGkIbJEjo9cK5h8pu+s25b8ycfINlwMPgQNwKEkN3caEGUmpKf5CHxue5Ifg1xT 29wDb38Zix+ccNg0p1hZI7EiTmEYm9j9R2dBLMLzKzjVwIGRsPJsWuCWvW3N/5mr eIsZIqgSgYo+mq2poJ0whqEpXRamNY3R4V5yhlbTA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddutddgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomhepifhithhhuh gspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghrvghplhihsehmnhhothdr nhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepudduledrledrge efrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhies mhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 91D4910288 for ; Sat, 16 Feb 2019 19:45:21 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id DFA9EC071F for ; Sun, 17 Feb 2019 00:45:18 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============6642196318283093815==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190217004518.DFA9EC071F@cloud.mnot.net> Date: Sun, 17 Feb 2019 00:45:18 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 00:45:29 -0000 --===============6642196318283093815== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+8/-4/=F0=9F=92=AC54) 8 issues created: - CID's should be compared in constant time (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2477 = - Invalid CONNECTION_CLOSE frames (by martinduke) https://github.com/quicwg/base-drafts/issues/2475 = - Connection ID Length changes (by martinduke) https://github.com/quicwg/base-drafts/issues/2473 = - PTO calculation (by ddragana) https://github.com/quicwg/base-drafts/issues/2472 = - Stateless Reset Lacks Normative Text (by martinduke) https://github.com/quicwg/base-drafts/issues/2471 = - Suggestion that Retry might not change CID (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2465 [-transport] [editori= al] = - Remember Fewer Transport Parameters for 0-RTT (by martinduke) https://github.com/quicwg/base-drafts/issues/2464 = - SPA ad Infinitum (by mikkelfj) https://github.com/quicwg/base-drafts/issues/2462 = 10 issues received 54 new comments: - #2473 Connection ID Length changes (27 by kazuho, nibanks, mikkelfj, Ra= lith, ianswett, martinthomson, MikeBishop, dtikhonov, martinduke) https://github.com/quicwg/base-drafts/issues/2473 = - #2464 Remember Fewer Transport Parameters for 0-RTT (6 by martinthomson= , ianswett, martinduke, MikeBishop) https://github.com/quicwg/base-drafts/issues/2464 [-transport] = - #2477 CID's should be compared in constant time (5 by kazuho, MikeBisho= p, dtikhonov, mikkelfj) https://github.com/quicwg/base-drafts/issues/2477 [-transport] = - #2475 Invalid CONNECTION_CLOSE frames (4 by mikkelfj, martinduke, MikeB= ishop) https://github.com/quicwg/base-drafts/issues/2475 = - #2441 Peers that only terminate a single connection on an IP/port canno= t migrate with 0-byte CIDs (3 by MikeBishop, janaiyengar, mikkelfj) https://github.com/quicwg/base-drafts/issues/2441 [-transport] [design] = - #2458 Client MUST use 1-RTT packets if it reads 1-RTT packets (3 by kaz= uho, MikeBishop, ianswett) https://github.com/quicwg/base-drafts/issues/2458 [-transport] [design] = - #2462 SPA ad Infinitum (3 by marten-seemann, ianswett, mikkelfj) https://github.com/quicwg/base-drafts/issues/2462 = - #2283 STOP_SENDING is not depicted in the send FSM (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2283 [-transport] [editori= al] = - #2472 PTO calculation (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2472 [-recovery] [design] = - #2453 Change Idle Timeout Units of Milliseconds (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2453 [-transport] [design] = 4 issues closed: - What else confirms that the peer is also closing/draining https://githu= b.com/quicwg/base-drafts/issues/2147 [-transport] [editorial] = - Change Idle Timeout Units of Milliseconds https://github.com/quicwg/bas= e-drafts/issues/2453 [-transport] [design] [has-consensus] = - SPA ad Infinitum https://github.com/quicwg/base-drafts/issues/2462 = - STOP_SENDING is not depicted in the send FSM https://github.com/quicwg/= base-drafts/issues/2283 [-transport] [editorial] = Pull requests ------------- * quicwg/base-drafts (+9/-5/=F0=9F=92=AC30) 9 pull requests submitted: - Packetization Nits (by martinduke) https://github.com/quicwg/base-drafts/pull/2476 = - Eliminate duplicate word (by martinduke) https://github.com/quicwg/base-drafts/pull/2474 = - More specific IANA registration xref (by LPardue) https://github.com/quicwg/base-drafts/pull/2470 = - Fix inconsistent leading zeros (by LPardue) https://github.com/quicwg/base-drafts/pull/2469 = - Address Validation Nits (by martinduke) https://github.com/quicwg/base-drafts/pull/2468 = - Refine Discussion of 0-RTT Transport Parameters (by martinduke) https://github.com/quicwg/base-drafts/pull/2467 = - Bound 0-to-1-RTT Transition (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2466 [-transport] [design] = - Fix packet and stream numbers in example (by martinduke) https://github.com/quicwg/base-drafts/pull/2463 = - 0-RTT can't use transport parameters or 1-RTT frames (by martinthomso= n) https://github.com/quicwg/base-drafts/pull/2461 [-transport] [design] = 8 pull requests received 30 new comments: - #2461 0-RTT can't use transport parameters or 1-RTT frames (12 by Dav= idSchinazi, martinthomson, kazuho, MikeBishop) https://github.com/quicwg/base-drafts/pull/2461 [-transport] [design] = - #2466 Bound 0-to-1-RTT Transition (10 by DavidSchinazi, kazuho, MikeBis= hop, martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/pull/2466 [-transport] [design] = - #2468 Address Validation Nits (2 by DavidSchinazi, mikkelfj) https://github.com/quicwg/base-drafts/pull/2468 [-transport] [editorial= ] = - #1998 introduce a max_connection_ids transport parameter (2 by martinth= omson, kazuho) https://github.com/quicwg/base-drafts/pull/1998 [-transport] [design] = - #2414 New connection IDs are mandatory for intentional migration (1 by= larseggert) https://github.com/quicwg/base-drafts/pull/2414 [-transport] [design] = - #2237 Rework Key Update (1 by huitema) https://github.com/quicwg/base-drafts/pull/2237 [-tls] [design] = - #2454 Change Idle Timeout to Milliseconds (1 by larseggert) https://github.com/quicwg/base-drafts/pull/2454 [-transport] [design] = - #2463 Fix packet and stream numbers in example (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2463 [-transport] [editorial= ] = 5 pull requests merged: - Address Validation Nits https://github.com/quicwg/base-drafts/pull/2468 [-transport] [editorial= ] = - describe what happens when the PTO timer expires https://github.com/quicwg/base-drafts/pull/2455 [-recovery] [editorial] = - Fix packet and stream numbers in example https://github.com/quicwg/base-drafts/pull/2463 [-transport] [editorial= ] = - Reword closing confirmation text https://github.com/quicwg/base-drafts/pull/2459 [-transport] [editorial= ] = - Change Idle Timeout to Milliseconds https://github.com/quicwg/base-drafts/pull/2454 [-transport] [design] [= has-consensus] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============6642196318283093815== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday February 17, 2019

Issues

quicwg/base-drafts (+8/-4/=F0=9F=92=AC54)

8 issues created:

10 issues received 54 new comments:

4 issues closed:

Pull requests

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

9 pull requests submitted:

8 pull requests received 30 new comments:

5 pull requests merged:

Repositories tracked by this digest:

--===============6642196318283093815==-- From nobody Sun Feb 17 19:04:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4C51295EC for ; Sun, 17 Feb 2019 19:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=mnot.net header.b=txA3IKHz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VgtF5XJg 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 LKqdpmXEUaF1 for ; Sun, 17 Feb 2019 19:04:02 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705AF127287 for ; Sun, 17 Feb 2019 19:04:02 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9567A283B; Sun, 17 Feb 2019 22:04:01 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 17 Feb 2019 22:04:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=5474cLTWdlYnOWH/I6GK3ETJA1OuxB 6ekcB+m35VMCU=; b=txA3IKHzQrRQWtEKJ2FWLCTypg/41mhdT7P2CQPCTykbHa pZbFgqL8noOeqgO+h1gd22gVCrw3j+Roo1eccJ/yDcEDh0nOed75GBA22xlYFBDf 2p/jPBBOV7Jntdv+cN8DO5rXalfjqZnlNdJ+6MwrOi+F5/l63fUZPMHw9n1nlbOI SrjUjnp54SawFmmpjnHwhY5rL+CkfXfl8lEr0j8m0Db+5b3Z9QYvUcyXYF+h8g7c X5TmuOS9mWn/jUrZ9lJNNnfv3S22l5+/5SiDvL0V6U+w04s1uPa0xXnhf9cql9Z+ /wl5KSoiS1lXgZdvRsBSqJEeruYxYN3HClqB9rkA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5474cL TWdlYnOWH/I6GK3ETJA1OuxB6ekcB+m35VMCU=; b=VgtF5XJgiD/7D0TVY/fjZx 3G9WT42sAHlCZMJZHvT8nnz3IoN6v6Z15QjIMKOx6oXJfZWCA/mAMSodp4vKfHth NwuakqMCJsaJY1iWof/r4xxfKKRqx+247kor1fqBKIY5cnXdxVmBw6zRDgpXcdwc eWkfj/gZKx5HyhzTvXAVKjzJt3qfnny4CLY/I6195tGlXmbfdlDk9pZ8Qpm8Jf4g e9aBcF9aZS+tdQ7mDaOHqLfcBF7YSkZGc77PcZnClGk0s20UJqMXsMUZADrSLRR3 SHKV3AQXueZCtshd8BsWMK7B5DHfopbPp+Tv/ScCHrn16wgZuBoU/jhRvKdIYk1w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrudduvddgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhtgfgggfukf ffvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceo mhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehmnhhothdrnhgvthenucfkph epudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhho thesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 310C5E427A; Sun, 17 Feb 2019 22:03:58 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Next interim - planning Message-Id: Date: Mon, 18 Feb 2019 14:03:54 +1100 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 03:04:04 -0000 Everyone, As discussed in Tokyo, we're starting to plan another interim after = IETF104, since it seems we're likely to need one. At the meeting, we canvassed the week of May 20, to take place in Europe = (since that's next in our rotation). That seemed to work well for people there, and due to a variety of = conflicts, it's not likely we'll find another week. However, if this = means a number of people can't make it that would otherwise go, we might = have to reconsider. So, if it does, please tell Lars and I ASAP so we = can judge whether there's an issue with those dates. Also, if you have a European venue that's suitable for our meetings = (based upon past participation, at least 45 people, in a U-shape or = conference table layout, with good Internet, power and a projector, in a = location that's near restaurants and hotels, ideally without requiring = car rental), please get in touch. Cheers, -- Mark Nottingham https://www.mnot.net/ From atticuswu@tencent.com Sun Feb 17 20:02:22 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7711200B3 for ; Sun, 17 Feb 2019 20:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 010eUlhWKm00 for ; Sun, 17 Feb 2019 20:02:15 -0800 (PST) Received: from mail2.tencent.com (mail2.tencent.com [163.177.67.195]) by ietfa.amsl.com (Postfix) with ESMTP id 802FE124C04 for ; Sun, 17 Feb 2019 20:02:05 -0800 (PST) Received: from EXHUB-SZMail03.tencent.com (unknown [10.14.6.33]) by mail2.tencent.com (Postfix) with ESMTP id BC86017B94 for ; Mon, 18 Feb 2019 12:02:03 +0800 (CST) Received: from EXMBX-SZMAIL016.tencent.com ([fe80::1c14:d62a:a06f:3866]) by EXHUB-SZMail03.tencent.com ([::1]) with mapi id 14.03.0415.000; Mon, 18 Feb 2019 12:02:03 +0800 From: =?gb2312?B?YXR0aWN1c3d1KM7i6Mkp?= To: "quic@ietf.org" Subject: Apply for permission of translating quic-draft to Chinese Thread-Topic: Apply for permission of translating quic-draft to Chinese Thread-Index: AQHUxz607fA9LAGpLU6t6gr43c0e4g== Date: Mon, 18 Feb 2019 04:02:02 +0000 Message-ID: <61BB1770-9B0C-4D95-A4A0-F96569EAE271@tencent.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.14.87.245] Content-Type: multipart/alternative; boundary="_000_61BB17709B0C4D95A4A0F96569EAE271tencentcom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 18 Feb 2019 00:12:56 -0800 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 04:05:57 -0000 --_000_61BB17709B0C4D95A4A0F96569EAE271tencentcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBhbSBvbmUgb2YgQ2hpbmVzZSBkZXZlbG9wZXJzIHdobyByZWNlaXZlZCBtdWNoIGhlbHAgZnJv bSB0aGUgZGV2ZWxvcG1lbnQgb2YgUVVJQy4gQnV0IHRoZXJlIGFyZSBzbyBmZXcgQ2hpbmVzZSBk b2N1bWVudHMgYWJvdXQgUVVJQy4gU28gc2V2ZXJhbCBvZiB1cyB3b3VsZCBsaWtlIHRvIHNoYXJl IG91ciBzcGFyZSB0aW1lIGZvciB0cmFuc2xhdGluZyBxdWljLWRyYWZ0KGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQvKSBmcm9tIEVuZ2xp c2ggdG8gQ2hpbmVzZS4NCg0KV2UgcGxhbiB0byBiYXNlIG91ciB0cmFuc2xhdGlvbiBvbiBxdWlj LWRyYWZ0IHZlcnNpb24gMTggYW5kIHN1cHBvcnQgZnVydGhlciB2ZXJzaW9ucyBpZiBwb3NzaWJs ZS4gQW5kIG91ciB0cmFuc2xhdGlvbiB3aWxsIGJlIHB1YmxpYyBvbiBnaXRodWIgYW5kICB3aWxs IGJlIHN1Ym1pdHRlZCBmb3IgSUVURidzIGNoZWNraW5nIGJlZm9yZSBiZWluZyBwdWJsaWMgaWYg bmVlZGVkLg0KDQpCZXN0IHJlZ2FyZHMNCg0K --_000_61BB17709B0C4D95A4A0F96569EAE271tencentcom_ Content-Type: text/html; charset="gb2312" Content-ID: <51E4F390D657F3488A252B0398649722@tencent.com> Content-Transfer-Encoding: quoted-printable
I am one of Chinese developers who received much help from the development = of QUIC. But there are so few Chinese documents about QUIC. So several of u= s would like to share our spare time for translating quic-draft(htt= ps://datatracker.ietf.org/doc/draft-ietf-quic-transport/) from English to Chinese.

We plan to base our translation on quic-draft version 18 and support furthe= r versions if possible. And our translation will be public on github and &n= bsp;will be submitted for IETF's checking before being public if needed.

Best regards

--_000_61BB17709B0C4D95A4A0F96569EAE271tencentcom_-- From nobody Mon Feb 18 18:55:11 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73B0130DD8 for ; Mon, 18 Feb 2019 18:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsxIXIAQeJx2 for ; Mon, 18 Feb 2019 18:55:07 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 5A9FF12785F for ; Mon, 18 Feb 2019 18:55:07 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id l10so13754308lfh.9 for ; Mon, 18 Feb 2019 18:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b9O+CcjHmsU8AJ3ch0/3Yv+W1D8gCeqrP2+nupn9hFM=; b=WS9teTutcEP9C2SPK+IodzQdydbHiULTJvRh5JC4wIu8ROE0nv6Wzu4BHM0nwDf1vi qPw/JjlalKErjAXtUNGsoaus6o5LLdMNEZhUNPXiH581hVbg+TWe4QKxplnqyKiYmtrN n/VJhcxPF+WhKPjTQOWyiIGTrJ2penxyNz30n2EYqPRXl9aNd2JAOQPdotyYcNm147UK nbF94DMV/Hqu0nQnrEvz61d5V9vmh6OYRuW1gVQuRODjloKHDg9UOBFFVBZTynMBP54x drjALt9TEE1+O1SNZaaDFGeLAiQ+Ju8vRtk2quz3s8pwsOaSQ9dlZiiaQovlhOTLj7Kv TeEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b9O+CcjHmsU8AJ3ch0/3Yv+W1D8gCeqrP2+nupn9hFM=; b=LKyS80GSGym911BbOBohaxBZ1W44cAWZAaXQK6yzWmy/vZIWt13tGt0AARn3UnsM37 EVf+3A5dUj23R0J/a3muiranMue43+9Fwun+GKQkHwveOrf3SVBYOP+F2+z5TT068ezD LjPVgWBZgMya8qYtZvTgFzSYYogNQsahJrL0vNW9yYNW18NKsKe8q0p8DfQO0Q4HPI7a zCD4En2/GEA1J4YlCQUTdMFgx2bL5phPAo0Z7guVyuqnccnGk2GbioyK1VyAbHf16Tb+ VOteyl8Y7pVP7qHuxbKB4dc9Q7HB7NqRiveh9zN++dLoW7EoD1qvxWy7xomJAae/6jMO 3mRw== X-Gm-Message-State: AHQUAuZ0k0wvvNKtAcDgWhv3Ti+JXnv3mC4M4Ap2fBxbaRgv3xBor6Tx mPNicstjr/yfHDznWvmKK8i9aXye6B5UmvmjBD1V3Rt/ X-Google-Smtp-Source: AHgI3Iai/VfuiAR4MAMQFopKZtB2rS9ESQ4tStBfo8sPz58Hzi6UZXWnFo41UYTZNOCAvqXl4cr8hgikVwJbNgrAHR4= X-Received: by 2002:a19:d83:: with SMTP id 125mr15081197lfn.159.1550544905338; Mon, 18 Feb 2019 18:55:05 -0800 (PST) MIME-Version: 1.0 References: <1549322113.4162602.1650849912.50B780CD@webmail.messagingengine.com> <1549593981.877482.1653392768.203A9C0B@webmail.messagingengine.com> In-Reply-To: <1549593981.877482.1653392768.203A9C0B@webmail.messagingengine.com> From: Jana Iyengar Date: Mon, 18 Feb 2019 18:54:54 -0800 Message-ID: Subject: Re: New path => new connection ID, right? To: Martin Thomson Cc: QUIC WG , Mark Nottingham , Lars Eggert Content-Type: multipart/alternative; boundary="0000000000004a849e0582365e5e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 02:55:10 -0000 --0000000000004a849e0582365e5e Content-Type: text/plain; charset="UTF-8" Attempting to bring this discussion back to the PR in question. As noted by ekinnear , the PR that Martin has proposed is an editorial fix. I would suggest that if anyone who wants to change behavior from PR #2414 should open a new issue. Is anyone arguing that PR 2414 is not editorial? - jana On Thu, Feb 7, 2019 at 6:46 PM Martin Thomson wrote: > In an attempt to close the loop, I've updated > https://github.com/quicwg/base-drafts/pull/2414 > > The controversial bits are apparently: > > * if you intentionally move to a new path, then you have to use a > connection ID that hasn't been used on any other path > > * if you don't have a new connection ID (which also includes zero-length > connection IDs in the latest change), then you can't use a new path > > I believe that both are editorial changes, but the volume of discussion on > the thread indicates that some people would like to see the issue > reopened. In the interests of forward progress, I would like the chairs to > make an assessment. > > Note that this PR doesn't include the fix to > https://github.com/quicwg/base-drafts/issues/2342, which reviewers will > no doubt trip over in the process of reviewing this change. > > On Tue, Feb 5, 2019, at 10:15, Martin Thomson wrote: > > I thought that we had agreed that an endpoint that intentionally > > migrates has to use a new connection ID on the new path. But I couldn't > > find any "MUST" in the spec that said that. > > > > On the off chance that this wasn't just a mistake and there was some > > good reason not to mandate this, I'm bringing the discussion here. > > > > I've opened a design issue: > > https://github.com/quicwg/base-drafts/issues/2413 > > > > The change I'm proposing is here: > > > https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995236dda960b4cdff49e36f > > --0000000000004a849e0582365e5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Attempting to bring this discussion back to the PR in= question. As noted by ekinnear, the PR that Martin has propo= sed is an editorial fix. I would suggest that if anyone who wants to change= behavior from = PR #2414 should open a new issue.

Is anyone ar= guing that PR 2= 414=C2=A0is not editorial?

- jana

On Thu, Feb 7, 2019 at 6:46 PM Martin = Thomson <mt@lowentropy.net> = wrote:
In an attempt to close the loop, I've updated https://github.com/quicwg/base-drafts/pull/2414

The controversial bits are apparently:

* if you intentionally move to a new path, then you have to use a connectio= n ID that hasn't been used on any other path

* if you don't have a new connection ID (which also includes zero-lengt= h connection IDs in the latest change), then you can't use a new path
I believe that both are editorial changes, but the volume of discussion on = the thread indicates that some people would like to see the issue reopened.= =C2=A0 In the interests of forward progress, I would like the chairs to mak= e an assessment.

Note that this PR doesn't include the fix to ht= tps://github.com/quicwg/base-drafts/issues/2342, which reviewers will n= o doubt trip over in the process of reviewing this change.

On Tue, Feb 5, 2019, at 10:15, Martin Thomson wrote:
> I thought that we had agreed that an endpoint that intentionally
> migrates has to use a new connection ID on the new path.=C2=A0 But I c= ouldn't
> find any "MUST" in the spec that said that.
>
> On the off chance that this wasn't just a mistake and there was so= me
> good reason not to mandate this, I'm bringing the discussion here.=
>
> I've opened a design issue:
> https://github.com/quicwg/base-drafts/issues/2= 413
>
> The change I'm proposing is here:
> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a399= 5236dda960b4cdff49e36f

--0000000000004a849e0582365e5e-- From nobody Mon Feb 18 19:36:11 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB91130E64 for ; Mon, 18 Feb 2019 19:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IpLq3xNGLnK for ; Mon, 18 Feb 2019 19:36:07 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 8C5B0130E5F for ; Mon, 18 Feb 2019 19:36:06 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id w6so11368195ljd.7 for ; Mon, 18 Feb 2019 19:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hVJI8RKNw9tIixB/9huAgk5SrFMyPATU7qASthjLVO0=; b=YwL6BQYsZk0z/+zSV2KeHAK1rXSw0RCTsFawdQys4foWVtW3d3C41MxgKu5O2SK0a3 vYIw3hpDDKgYuTiKOnE8yj0nEzG8zfWWTTYUc2v+S9PY+SC14ei8wViLts8977ZBP1UI XCToDpMB9YuRLwHv6WrmQq6jVWAySYCt+xENhxhDcvETCZpTPhSOoJ/eSo/Z6vGdLVmE ynAp8hzhGZRrsxoSDSTWFklsJsXUJQRq0zcLma2jOh4oDXyZdEU/mTX/x9kVr3SAijMK E/Xhm9zfGxDtSG8perExVSlrxqpaXaTiv+AclBa3vr0Wn0wURpq61ShEWM76cX6dbs6s G9eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hVJI8RKNw9tIixB/9huAgk5SrFMyPATU7qASthjLVO0=; b=GyIJbw+/h9xy6J3c1pKTVooHRiQqpvhbWA+fnY2z4A4o2AH7+DKMArXBxWPwmSgd8U hsrqHYIFux3EBJxzFW8Yc3JbSSVWSg8TJn2K7e8+fwEHXO1NPnvHcFwQORoOXoi81NTD D2G8DXKTAvA8ouCSIYaSJz9L5Nb/f6o8oqbvvlzfrQbNqbooFVz8iXG2La3vdDl3ilKm 0l39cX1cpn/ZhKkiz0jmG7BK5tyY99sb0LFQrgl7R5l0DruwwjjnUovh6YzV+CBOYDEo a+evmPpkC6Yo08rOVcxE/9ENEwIYFgAoI4BOSGJr5qWW6R31xI+FQ5tDao8zSYEIx/Cu /RMg== X-Gm-Message-State: AHQUAuZNdNaQI3Jr/VMrPxzIRMf6YRlEzDQBZv5Mihzr0QeuGywE3MOs 19WCmbq6fXe72r2u3tZ8SIku08GxsxXZkJMIV7w= X-Google-Smtp-Source: AHgI3IYAa5657sUcaswtxignNgMMCLgeyDAEVRaeBYW/lnIKZjOMCYcAsfWk4+D+LM9BK8kJj2V3SUZnNXJKwA/rhUA= X-Received: by 2002:a2e:2285:: with SMTP id i127mr7344961lji.40.1550547364657; Mon, 18 Feb 2019 19:36:04 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> In-Reply-To: <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> From: Jana Iyengar Date: Mon, 18 Feb 2019 19:35:53 -0800 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="000000000000e0bd58058236f084" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 03:36:10 -0000 --000000000000e0bd58058236f084 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 14, 2019 at 6:43 PM Martin Thomson wrote: > On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote: > > I believe the concern is that a middlebox/etc will conclude that a > > certain range of versions are IETF standard versions and should be > > allowed and others are fine to block because they're experimental, > > thereby making the majority of versions largely undeployable. > > That only suggests to me that we not segregate the space. The proposed > variations won't all happen in that space. > The whole point of the proposal was to avoid segregating this space. Let me articulate a bit better, and folks can poke holes. Whatever we choose for the on-wire representation of version 1, that's visible to mboxes and they can ossify around it. We want more versions on the wire to avoid this from happening. As long as a few major players use a few more versions on the wire besides v1, that's all we need to keep the ecosystem from ossifying. Ideally, the additional versions keep changing over time to avoid those getting ossified as well. So a server can simply choose a random version periodically and use it. But we need clients to use the version as well, and since not everyone is Google, we use IANA to publish this new version. Basically, (i) org requests new version from IANA, (ii) IANA either assigns a new version (randomly) or approves the requested version for use as additional v1, and (iii) clients and servers roll out support for this new version. Note again that all servers and clients continue supporting the original v1 version; this is an additional preferred version when it is available on both sides. This gets us greasing, and ensures that we have a mechanism in play that protects against downgrade protection. Let's say we use 0x00000001 as v1. Do we allow 0x00000002 as an additional version for v1? If we do, then what is the on-wire representation for v2? If we don't, then we have to segregate the space. To avoid this problem, I suggested that we randomize everything. It's not that hard: IANA can easily assign a version to us at RFC publication time much in the same way as they would to anyone requesting an additional on-wire version for v1 in the future. --000000000000e0bd58058236f084 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 14, 2019 at 6:43 PM Martin Th= omson <mt@lowentropy.net> wr= ote:
On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote:
> I believe the concern is that a middlebox/etc will conclude that a > certain range of versions are IETF standard versions and should be > allowed and others are fine to block because they're experimental,=
> thereby making the majority of versions largely undeployable.

That only suggests to me that we not segregate the space.=C2=A0 The propose= d variations won't all happen in that space.

<= /div>
The whole point of the proposal was to avoid segregating thi= s space. Let me articulate a bit better, and folks can poke holes.

Whatever we choose for the on-wire representation of versi= on 1, that's visible to mboxes and they can ossify around it. We want m= ore versions on the wire to avoid this from happening.=C2=A0 As long as a f= ew major players use a few more versions on the wire besides v1, that's= all we need to keep the ecosystem from ossifying.

Ideally, the additional versions keep changing over time to avoid those ge= tting ossified as well. So a server can simply choose a random version peri= odically and use it. But we need clients to use the version as well, and si= nce not everyone is Google, we use IANA to publish this new version. Basica= lly, (i) org requests new version from IANA, (ii) IANA either assigns a new= version (randomly) or approves the requested version for use as additional= v1, and (iii) clients and servers roll out support for this new version. N= ote again that all servers and clients continue supporting the original v1 = version; this is an additional preferred version when it is available on bo= th sides. This gets us greasing, and ensures that we have a mechanism in pl= ay that protects against downgrade protection.

Let= 's say we use 0x00000001 as v1. Do we allow 0x00000002 as an additional= version for v1? If we do, then what is the on-wire representation for v2? = If we don't, then we have to segregate the space. To avoid this problem= , I suggested that we randomize everything. It's not that hard: IANA ca= n easily assign a version to us at RFC publication time much in the same wa= y as they would to anyone requesting an additional on-wire version for v1 i= n the future.

--000000000000e0bd58058236f084-- From nobody Mon Feb 18 23:16:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740BA130E74 for ; Mon, 18 Feb 2019 23:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zfXwVXUht5-C for ; Mon, 18 Feb 2019 23:16:35 -0800 (PST) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC96124B0C for ; Mon, 18 Feb 2019 23:16:35 -0800 (PST) Received: from eggert.org (unknown [62.248.255.8]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id C59243008A; Tue, 19 Feb 2019 09:16:32 +0200 (EET) Received: from slate.eggert.org (pf.eggert.org [172.16.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 242FD886CC8; Tue, 19 Feb 2019 09:16:26 +0200 (EET) From: Lars Eggert Message-Id: <845BA6BC-1C79-4EB3-AB7D-B38A27E64559@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_9CB3DFBC-6C2B-42CA-86E4-832D4F6FB2A2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Apply for permission of translating quic-draft to Chinese Date: Tue, 19 Feb 2019 09:16:25 +0200 In-Reply-To: <61BB1770-9B0C-4D95-A4A0-F96569EAE271@tencent.com> Cc: "quic@ietf.org" To: =?utf-8?B?ImF0dGljdXN3dSjlkLTmnq0pIg==?= References: <61BB1770-9B0C-4D95-A4A0-F96569EAE271@tencent.com> X-Mailer: Apple Mail (2.3445.102.3) X-MailScanner-ID: 242FD886CC8.A8033 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 07:16:37 -0000 --Apple-Mail=_9CB3DFBC-6C2B-42CA-86E4-832D4F6FB2A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2019-2-18, at 6:02, atticuswu(=E5=90=B4=E6=9E=AD) = wrote: > I am one of Chinese developers who received much help from the = development of QUIC. But there are so few Chinese documents about QUIC. = So several of us would like to share our spare time for translating = quic-draft(https://datatracker.ietf.org/doc/draft-ietf-quic-transport/) = from English to Chinese. >=20 > We plan to base our translation on quic-draft version 18 and support = further versions if possible. And our translation will be public on = github and will be submitted for IETF's checking before being public if = needed. thank you very much for the kind offer! Mark and I discussed this, and participation in the IETF already gives = each participant the right to make such translations of our documents = and to make them available (per = https://trustee.ietf.org/license-info/IETF-TLP-5.htm). So you are free = to go ahead with this effort. We'd be happy to help this effort by creating a GitHub repository for = this translation work under the QUIC WG GitHub organization = (https://github.com/quicwg) as a permanent home. This will make it = easier for others to find these translations and hopefully contribute to = them. Thanks, Lars --Apple-Mail=_9CB3DFBC-6C2B-42CA-86E4-832D4F6FB2A2 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlxrrUkACgkQVLXDCb9w wVf5SQ/7BpA2s4z8wPoa6yuJm+Mv/EcKv6cr+rcCG8Exhdcll+Ht4JPAlLXKjlCK 1joP5bfO7+BySZz5ABExHOeFoZpvF/fCV45yvhycfLfLv/GEIntjDvVs6yXfk37R HCTdrBE90I3GU5PwInyBn8hlvHUKVnswAgHBLOG4ixz0GxT/CMdnd07f58dw31WN Ut3N/x7DfRenjfbwIoOBwQ/Ub9yxmc9RBiDX6K1Iu1D/bN4G3mt7LSLZ3VmWv09k iwWVe7DZEbAM3X0ov1GOWMB7Bb2H3hLud3lW21qYLhW20aoWJE4eJIJcPwmxv29x AvDBCS8+ItIqljQzWdfxWMtfbZhLXJFJqWsXQWOhBwgO25gt59uPA53HBctZWXI7 SPU1tY4k2VW9KYiqb5C8OFHxsrplo+5W1I6GoET2fVL8u71UHAsYHLXgAg3+McXF x8ELJJgOs+I7l0G22/jNqxx579wi4doEB5VqvrveLctU92J8uAPXXZjFyCUw70D+ qokz05AyDEFd1xTAu+gcrSArXEL8QAaZp/iUL5BiN8Y9LRAmCwpgPVgH2zxUih5k IDpvCfA5vIC8K8O6otgw8Bp2Wvr8BCArya0HDKXI4CcU6yCxbY8H8t0y6zLWLoH/ tO23zqsjuboF+o+s77LcTl6N/lY0a8Fu6XJDwmo3Jil11RhVKlY= =tOGk -----END PGP SIGNATURE----- --Apple-Mail=_9CB3DFBC-6C2B-42CA-86E4-832D4F6FB2A2-- From nobody Mon Feb 18 23:22:48 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215DC130E77 for ; Mon, 18 Feb 2019 23:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Mt0wkUPUCl0e for ; Mon, 18 Feb 2019 23:22:46 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B150130E74 for ; Mon, 18 Feb 2019 23:22:46 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id m137so3905869ita.0 for ; Mon, 18 Feb 2019 23:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Rz8fJFoDmDoTpfEz3/pFQ9OGKXpK7r+UknvjorqksLo=; b=FTdxe7L+EOllRwlCfpIWm/ANSKe+hURN+5uUrpMzMt/47GTWelvKl8cOgXzCIbLXef Mt5nFrXLMQLZhjYj4Gj3Pd2WWY4FtQ+QkNAxQCeZsjOmp9LzzUg+uyMB8OgMn7HSJFhH /uXlbnwVQgvuFzRgCTKt4oxhUrQ1pNnKR4RATEMffgpKXq2t+eOrNLOoJ081t8NVG9dJ wGYk7PiNWoEdJfZkGWPiDsEqZDRIDXyRlL9l5zFKaCq7KS4CBU0TIfsAQ9t9PI7WCReE hKzTxUrv4vlnT3nRKXX77XOPPEdeIWgfDgD1glq4Zy1BW/mSbOjj+5QBpI+ngEAoEawQ IWvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Rz8fJFoDmDoTpfEz3/pFQ9OGKXpK7r+UknvjorqksLo=; b=gNbeJLJxmOnL28gvG0E1zib+v9wDwBXRrTGwqzlXQwelF2dkGqLf5j7V5MK7TTnxTA HzTE5enE0NgAhrSrkwfvlpXfsdcT1yI1+Zji9tQQyDwJDQUjVEkJTdXikNP7r+1a96ax gPxAzzWEgrn9VeKbkqRG866vkYESk4Sn7fqqxIDQE/NyUVtk/8lIBra+x+pv5PCA7R0w tRd97ljHVBDb7TjvbtvHXad/cApMqtdhJPA3HtRxNSGY9dVu8cPzjv9PThElVuOG9U3D pokf4LKzekHuPuSsYC20nyggNsozIn3+8ENcFQ2NrZkS40cJvJTwrtd6DPdFe3+wbsqL dSdw== X-Gm-Message-State: AHQUAubcShCRoB0sfjHacHYxH8QHlI5yhhjhiu5f2emtjxI5W0L3D2z3 JKbDjB9kEryIGsDLrDzBALaeuZpgVIo9sCMvONk= X-Google-Smtp-Source: AHgI3Ia6TCE0ALaysu75Wn4Av84Azbu8/G7UY/sjm88Xphl04EmliUezGuIbXbx8xppm195/FndLSAW3i5IsAKqYmvY= X-Received: by 2002:a05:660c:12c7:: with SMTP id k7mr1348164itd.148.1550560965373; Mon, 18 Feb 2019 23:22:45 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 18 Feb 2019 23:22:44 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 18 Feb 2019 23:22:44 -0800 Message-ID: Subject: Re: QUIC ossification To: Jana Iyengar , Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="0000000000008b33d305823a1b25" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 07:22:48 -0000 --0000000000008b33d305823a1b25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I still think there is a need for private experimentation without going all IANA. If randomisation is a good idea, why not have 128-bit version identifiers - each org with special needs can encrypt their own version numbers. Now you have fully randomised keys and infinitely many spaces. Since the VN=E2=80=99s are only used in a few header packets, 128-bits is a= fine length. Mikkel On 19 February 2019 at 04.36.21, Jana Iyengar (jri.ietf@gmail.com) wrote: On Thu, Feb 14, 2019 at 6:43 PM Martin Thomson wrote: > On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote: > > I believe the concern is that a middlebox/etc will conclude that a > > certain range of versions are IETF standard versions and should be > > allowed and others are fine to block because they're experimental, > > thereby making the majority of versions largely undeployable. > > That only suggests to me that we not segregate the space. The proposed > variations won't all happen in that space. > The whole point of the proposal was to avoid segregating this space. Let me articulate a bit better, and folks can poke holes. Whatever we choose for the on-wire representation of version 1, that's visible to mboxes and they can ossify around it. We want more versions on the wire to avoid this from happening. As long as a few major players use a few more versions on the wire besides v1, that's all we need to keep the ecosystem from ossifying. Ideally, the additional versions keep changing over time to avoid those getting ossified as well. So a server can simply choose a random version periodically and use it. But we need clients to use the version as well, and since not everyone is Google, we use IANA to publish this new version. Basically, (i) org requests new version from IANA, (ii) IANA either assigns a new version (randomly) or approves the requested version for use as additional v1, and (iii) clients and servers roll out support for this new version. Note again that all servers and clients continue supporting the original v1 version; this is an additional preferred version when it is available on both sides. This gets us greasing, and ensures that we have a mechanism in play that protects against downgrade protection. Let's say we use 0x00000001 as v1. Do we allow 0x00000002 as an additional version for v1? If we do, then what is the on-wire representation for v2? If we don't, then we have to segregate the space. To avoid this problem, I suggested that we randomize everything. It's not that hard: IANA can easily assign a version to us at RFC publication time much in the same way as they would to anyone requesting an additional on-wire version for v1 in the future. --0000000000008b33d305823a1b25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I still think there = is a need for private experimentation without going all IANA.

If randomisation is a good idea, = why not have 128-bit version identifiers - each org with special needs can = encrypt their own version numbers.
Now you have fully randomised keys and infinitely ma= ny spaces.
Si= nce the VN=E2=80=99s are only used in a few header packets, 128-bits is a f= ine length.
<= br>
<= div style=3D"font-size:13px">Mikkel

=

On 19 February 2019 at 04.36.21, J= ana Iyengar (jri.ietf@gmail.com) = wrote:

On Thu, Feb 14, 2019 at 6:43 PM Martin Thomson <mt@lowentropy.net> wrote:
On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote:
> I believe the concern is that a middlebox/etc will conclude that a
> certain range of versions are IETF standard versions and should be
> allowed and others are fine to block because they're experimental,
> thereby making the majority of versions largely undeployable.

That only suggests to me that we not segregate the space.=C2=A0 The proposed variations won't all happen in that space.

The whole point of the proposal was to avoid segregating this space. Let me articulate a bit better, and folks can poke holes.

Whatever we choose for the on-wire representation of version 1, that's visible to mboxes and they can ossify around it. We want more versions on the wire to avoid this from happening.=C2=A0 As long as a few major players use a few more versions on the wire besides v1, that's all we need to keep the ecosystem from ossifying.

Ideally, the additional versions keep changing over time to avoid those getting ossified as well. So a server can simply choose a random version periodically and use it. But we need clients to use the version as well, and since not everyone is Google, we use IANA to publish this new version. Basically, (i) org requests new version from IANA, (ii) IANA either assigns a new version (randomly) or approves the requested version for use as additional v1, and (iii) clients and servers roll out support for this new version. Note again that all servers and clients continue supporting the original v1 version; this is an additional preferred version when it is available on both sides. This gets us greasing, and ensures that we have a mechanism in play that protects against downgrade protection.

Let's say we use 0x00000001 as v1. Do we allow 0x00000002 as an additional version for v1? If we do, then what is the on-wire representation for v2? If we don't, then we have to segregate the space. To avoid this problem, I suggested that we randomize everything. It's not that hard: IANA can easily assign a version to us at RFC publication time much in the same way as they would to anyone requesting an additional on-wire version for v1 in the future.

--0000000000008b33d305823a1b25-- From nobody Tue Feb 19 01:48:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B32130E81 for ; Tue, 19 Feb 2019 01:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=mnot.net header.b=akAGEOkc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=7FMaS9vF 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 1heTOJQJFRMr for ; Tue, 19 Feb 2019 01:48:35 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8935B128CF2 for ; Tue, 19 Feb 2019 01:48:35 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7B71F222F2; Tue, 19 Feb 2019 04:48:34 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 19 Feb 2019 04:48:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=0ZIXgwLzws4lvMvhYXCrnnUBYpeYTZ iJBpsj9dhcIE0=; b=akAGEOkc1cbhIR+Ip5SLZgu+QOUyn5IZ2/4TGbQugOJY6G YTpXaCXiMuNbUd43u1+un/M0Ad7hjAu90/fvl/na56j672PDwLrkevtKGPY0n5hx 39pFIKcJjgaBuGojkAsEk38O6UDayw0ZdQN40ZwxVP1P7PseSpctAdPdmWvU8kda 1XN5+mQCHflrIlyhJz57HRTvRgZInObBcChu5SEaYLGcEh4zBG8u/epnU5Ssmm+l p6SFlS5Jw4tlAfXyrJzeC/UR2KIXdKce+blV+o2k7tUJ5PVOV5zGaenS3oyOXHyc 7MtWiMXEBhXGABjJLZDnC5axT71rmGik3xlYZMDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0ZIXgw Lzws4lvMvhYXCrnnUBYpeYTZiJBpsj9dhcIE0=; b=7FMaS9vFCX4whGvnfwDJY8 zlX7GmrRIbyMha9JMc3Ta61uALOPZpRjqLk0A+x735EaG3ep3IXZXQMvmsGL2M5o paC9lwmBH6GkOhY3ytLW0gTXzXTB7sCSyPM6pPI2IZj25/ihTMluZE+4N15BVn88 r4dM8URyQK8DjOld3WGLXl4/mfWufxJIXgVmXQ84YyvpQFGY1ca9g8+d/mLKKbVH MemKxvd/bJB31Qnq9JIuPA3Ei27wj/VAnwolO0qJun6l8EdOn00Vo56JVkVG+HTn IPvo5ZcIyqIAcblgcHxXsPD83uD6J20PfzNxNlmnmIrVPHH7t7Ch2kVFXtC8wtxg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrtdeggddtjeculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 81AE5E40C1; Tue, 19 Feb 2019 04:48:31 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Changing our Work Mode, and Raising the Bar: Call for Consensus Message-Id: <3A8E56CA-0CF0-4BFD-B9BB-3CFB9072782F@mnot.net> Date: Tue, 19 Feb 2019 20:48:26 +1100 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 09:48:38 -0000 As discussed both on-list and in Tokyo [1], we're getting to a stage = where at least some of our documents would benefit from slower and = slightly more formal process, so that the rate of change is not so high, = changes that do occur are well-vetted, and the documents get closer to = reflecting consensus in the working group. In particular, the chairs and editors feel that the Invariants, = Transport and TLS documents are ready for such a change. I've created a PR that describes what we currently do (and will continue = to do for the other documents, until they also transition) as the = "early-stage" process, and a new "late-stage" process. See: https://github.com/quicwg/base-drafts/pull/2479/files In a nutshell, PRs won't be merged until the chairs flag the = corresponding issue as `has-consensus`, after checking for consensus on = the mailing list (although discussion can still take place on the = issue). Note that this only affects `design` issues, not editorial ones. The above is mostly a change in the bookkeeping and roles for how we = record issue state; if you have feedback or questions, please make them = here or on the PR, but barring any unforeseen hiccups, we should be = merging that shortly, and the new process will apply to all currently = open and new design issues against these drafts. We also discussed "raising the bar" for new issues against these three = drafts in Tokyo. Our charter says: """ Note that consensus is required both for changes to the current protocol = mechanisms and retention of current mechanisms. In particular, because = something is in the initial document set does not imply that there is = consensus around the feature or around how it is specified. """ Effectively, if we do this, we're saying that we have gained consensus = on what remains in these documents, excepting their outstanding issues.=20= That doesn't mean that new issues can't be raised against those drafts. = However, new issues against them will be judged for whether they contain = new information (in particular, security or interoperability impact), a = clear technical default, or have significant (in the judgement of the = chairs) support for further discussion. If the issue isn't = well-described or atomic, it may be closed with a request to refactor, = or refactored for you. Again, this does not affect editorial issues. Practically speaking, it means that new issues will be triaged by the = Chairs -- not the editors (although they can still "claim" purely = editorial issues) -- and those that don't meet the criteria above will = be closed. Those that do will be labeled (again, by the Chairs only) as = `design`. It also means that all of the closed `design` issues against these = drafts will be marked as `has-consensus`. Additionally, the `quicv2` = issues against them will be closed and marked `has-consensus`. The issues that will be labeled `has-consensus` (and closed, if still = open) are listed here: = https://github.com/quicwg/base-drafts/issues?q=3Dis%3Aissue+is%3Aclosed+la= bel%3Adesign+-label%3Ahas-consensus+-label%3A-http+-label%3Arecovery = https://github.com/quicwg/base-drafts/issues?q=3Dis%3Aissue+is%3Aopen+labe= l%3Aquicv2+label%3Adesign+-label%3Ahas-consensus+-label%3A-http+-label%3Ar= ecovery We believe that all of these issues have been discussed and the group = has formed consensus on them; this only formalises that. Again, this = does not (yet) affect the Recovery and HTTP documents. After discussion, there seemed to be good support for doing this in = Tokyo. If you have concerns or questions, please discuss them on-list; = barring pushback, we'll adopt this on 5-Mar-2019. Raising the bar for = our other drafts will be considered separately (but doesn't appear to be = too distant). Cheers, 1. See the minutes at: = https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minutes.m= d#process-change-discussion -- Mark and Lars, QUIC WG Chairs -- Mark Nottingham https://www.mnot.net/ From nobody Tue Feb 19 07:51:53 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA15130F0B for ; Tue, 19 Feb 2019 07:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=CBolTJCv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Mokag0xV 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 0sis1twHEYFo for ; Tue, 19 Feb 2019 07:51:49 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BC6130F07 for ; Tue, 19 Feb 2019 07:51:49 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9787222246 for ; Tue, 19 Feb 2019 10:51:47 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 19 Feb 2019 10:51:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=Kb1etyKcy5eHqTR0WaNh45wUx2Rshce24wdlpMF 0CeM=; b=CBolTJCvGhd9K+8GwShPkt+qem19QgLhXwv2rgigB57asLb7+KvWbk4 LrXkDBKBjLpoKA3edOyFl73SjXnlRGvw6RbC0qfyt6zruPadrOpqf/+UwU78ChhK O9ANSbBKkste1FBm4y9x3jvw35N6mXNRJp6kq8Wqkjdsi2hiuSyjmx09aSSwF+Vg eLijEqkbti5rslzP2X+J5TQ9bzMmKWxhpYyOYMDPBctpTxdXlI+WrK6efhUh9R3e t8PKMBDiEFCT19Ux9hjIZPOfHIelEOZoE1zTlb1JLnqR0M7PhRIE3+XLwHeC1IEJ vTkTPk0RnhbEVZdC2SiDJMhM/7MXcCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Kb1etyKcy5eHqTR0W aNh45wUx2Rshce24wdlpMF0CeM=; b=Mokag0xV/wqj64Kt4nToUcB8UK0/deKUE PL/B5skhFj8i48RPsalKm9X2hhQRUB9wuQg26VffhU5BsRZRr7CDlmpY7Ck53kA/ IMuVRKOnZR5rvrD/bIVlLK92z+AAtF+ZUl1xmZw6aPnR1L3zmYGlSyHcTsJXhEqY fcQNr2tYBloc5tNE2Ix3FLe0oZK53+Hi8NUCYBD+m6TuLrkthQhfiD22KKrfD8aS HsJSDEJ9dpWKu6crBNVDStJNATXH92bzWAyqeAZDxZCgLpqqnNnGShn/YK0iZ1t5 XczGvH+Q3jmgqrffZLZnh9rVsiOtSzr4BniORcdOjfDvObu69AOEQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrtdeggdejleculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A1D4D7C293; Tue, 19 Feb 2019 10:51:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-895-g0d23ba6-fmstable-20190213v1 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> Date: Tue, 19 Feb 2019 10:51:48 -0500 From: "Martin Thomson" To: quic@ietf.org Subject: Re: QUIC ossification Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 15:51:52 -0000 On Mon, Feb 18, 2019, at 19:36, Jana Iyengar wrote: > Let's say we use 0x00000001 as v1. Do we allow 0x00000002 as an > additional version for v1? If we do, then what is the on-wire > representation for v2? If we don't, then we have to segregate the > space. To avoid this problem, I suggested that we randomize everything. > It's not that hard: IANA can easily assign a version to us at RFC > publication time much in the same way as they would to anyone > requesting an additional on-wire version for v1 in the future. I don't think that there is much value in using two version numbers to refer to the same protocol. But even if we did, as long as we didn't establish any pattern in doing so, that couldn't be used against us. So I might tentatively agree that 0x1 == 0x2 would be inadvisable, there is no strong need to do anything special with the first version. Any attempt to profile QUIC will be done with full knowledge of the version number we pick, so randomness doesn't serve any real purpose. Subsequent versions might need to use a randomized value, but we can make that decision then. The problem of course being that as long as v1 remains, we might find places that no other version does. The QUIC "magic number" will be whatever we pick, and we can't prevent someone from fixating on that. We'll convince those people in the same way they will be convinced to open up UDP for QUIC version 1: by making a QUIC version 2 worth enabling. I completely get the don't segregate thing. But to - I think - Mikkel's point about experimentation without permission, I do think that squatting is a perfectly sound approach in a space this big. TLS people do it in a much smaller space. As long squatters pick random values, they do so infrequently, and they get IANA registrations for codepoints relatively soon afterwards, the risk of collision is low. Randomness here is useful - but primarily as a collision-avoidance technique. The TLS extension codepoint 26 is a great example of why. Keeping the bar on registrations low (FCFS is a reasonable policy) would also have the effect of making the pool of apparent versions larger, which might be more effective than any other strategy we might employ. From nobody Tue Feb 19 10:52:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0593612D4E7 for ; Tue, 19 Feb 2019 10:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrD8GppS6zeE for ; Tue, 19 Feb 2019 10:52:20 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA55D1277CC for ; Tue, 19 Feb 2019 10:52:19 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id m137so8661924ita.0 for ; Tue, 19 Feb 2019 10:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yzU2azDSHpY0uWSV2VrEOGd8fFFUCZzhiEHtz40aELc=; b=STZ9U3sGyuYY57c90aJk3Xi2ATyjT9ZB9zSxuXKQhwJ2Cfpmp/sLXTdQ4Doa9gDN+Q zL5PCJulSTdRrgAkgGcbLYAeuL3t7cE7IdijfP/aVjmvrr5Nfm9DkcIYVMnBn3kPTOde SIUlmVMEKpl+5OzuqUu2MGd+yiMNxuSn1bcspLWGpmBR30dMHdsrsB9VjYw6rwrF8xGo 5v4CRWOtFl1xjoiPoBQW3esNeLzl6huCd0q3CZ3AgI/Q8WdJLtFBo7Xj5/YM8yqlW+SV 38XtoX2fPK3XHXnCX4zL8ngFPX2pZ3ErU0RuL/qo5J9JCu6O5pk+SZFx8deFI59V7R1O gUFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yzU2azDSHpY0uWSV2VrEOGd8fFFUCZzhiEHtz40aELc=; b=Wg6jMQAIzCbgeHh0MYEImbKySZ0xgEFyk4VZi1yHrv+B4Wphy2nCYk+U7bMwss7sfT q396EMOhnqexlpw27SooC/XIMksCOuobp6EBmPPcwW/9xG56zzYAsAmSicPLOhSIycQI KTgsV0NFUOCddLtRw6bkRO5kZXSBKBZWOdRP6rHFl0/UwfSotEYt+Sfhq/EO3uDwdZ4f 0fQxcpWIvt0nJkpboxTadiVEDS1SM0FdBcEzyTyC9Bhi6a7HuQakHYlCLbVIVzBmGl2i sF5TDJkanLnDnu1OaPKF09wzGNW+Re6RCuVFMIheg+blXFeS+MqIUmxPPVffT43mi2zr lixw== X-Gm-Message-State: AHQUAuZGywI1sfynXOdqR7b2WmTkWsw6tQoq2dcewrNiu8CVskR627Kr lRXj1SBNRA1OXlvpGZHsB2XTRGHxwY4drulP2tQ8gqGA X-Google-Smtp-Source: AHgI3IaYSYgx34frh77vj/u4vxGj2+QnqTdGCU98QPizmNdvfB87A8Rw+3XON66WSMBGoegbRNxRhdWOZuSzgVtU9F4= X-Received: by 2002:a02:601d:: with SMTP id i29mr14944912jac.11.1550602338710; Tue, 19 Feb 2019 10:52:18 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> In-Reply-To: From: Ted Hardie Date: Tue, 19 Feb 2019 10:51:51 -0800 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000009639fb058243bd4c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 18:52:22 -0000 --0000000000009639fb058243bd4c Content-Type: text/plain; charset="UTF-8" On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson wrote: > > I completely get the don't segregate thing. But to - I think - Mikkel's > point about experimentation without permission, I do think that squatting > is a perfectly sound approach in a space this big. TLS people do it in a > much smaller space. As long squatters pick random values, they do so > infrequently, and they get IANA registrations for codepoints relatively > soon afterwards, the risk of collision is low. The difficulty, of course, is that squatters use whatever process they like for picking code points and it is easier to be lazy*. One way out of this is to have IANA generate random values for "unregistered" codepoints and block those from appearing in the public registry for a period of time (say, 6 months). At the end of six months they must either be formally registered or dropped. A slightly different, but probably similar effect can be gotten by IANA generating random codepoints for a shifting experimental range; they put out N code points at time T and age them out and replace them at some interval afterwards. That would, as a side effect, give you a changing random pool that middleboxes would likely want to track, rather than a static small number of versions. Ted *I have anecdata on this from ULAs but it is depressing enough that you probably don't want to see it. --0000000000009639fb058243bd4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 19, 2019 at 7:52 AM Martin Th= omson <mt@lowentropy.net> wr= ote:

I completely get the don't segregate thing.=C2=A0 But to - I think - Mi= kkel's point about experimentation without permission, I do think that = squatting is a perfectly sound approach in a space this big.=C2=A0 TLS peop= le do it in a much smaller space.=C2=A0 As long squatters pick random value= s, they do so infrequently, and they get IANA registrations for codepoints = relatively soon afterwards, the risk of collision is low.=C2=A0

The difficulty, of course, is that squatters use whate= ver process they like for picking code points and it is easier to be lazy*.= =C2=A0 One way out of this is to have IANA generate random values for "= ;unregistered" codepoints and block those from appearing in the public= registry for a period of time (say, 6 months). At the end of six months th= ey must either be formally registered or dropped.=C2=A0 A slightly differen= t, but probably similar effect can be gotten by IANA generating random code= points for a shifting experimental range; they put out N code points at tim= e T and age them out and replace them at some interval afterwards.=C2=A0 Th= at would, as a side effect, give you a changing random pool that middleboxe= s would likely want to track, rather than a static small number of versions= .

Ted

*I have anecdata on= this from ULAs but it is depressing enough that you probably don't wan= t to see it.

=C2=A0
--0000000000009639fb058243bd4c-- From nobody Tue Feb 19 14:11:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49286130F4D for ; Tue, 19 Feb 2019 14:11:16 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 uGT9z_juiUn2 for ; Tue, 19 Feb 2019 14:11:14 -0800 (PST) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710120.outbound.protection.outlook.com [40.107.71.120]) (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 0EE51128BCC for ; Tue, 19 Feb 2019 14:11:14 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=StUlg1SXGYkHmpY5Qw6dx5oaAgvpGtmipEYmN/SMCOU=; b=PvQZKPXMOmKuxUSfZuQn2QPZpdr0m/Ev+doLSTHuqom8FKXnAgeXVes8twWZPDgd0YSSU5lFHiCFnaKs3n1ygeDCenAwTUSYFURrkSPQvgvNu23xrqD/kMw6PS/62jgrEbVOpDTj2uOP6O7G28achKLEIRB9Oc05xf4Ltc2g9KU= Received: from CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) by CY4PR21MB0773.namprd21.prod.outlook.com (10.173.192.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.2; Tue, 19 Feb 2019 22:11:12 +0000 Received: from CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46]) by CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46%3]) with mapi id 15.20.1665.002; Tue, 19 Feb 2019 22:11:12 +0000 From: Nick Banks To: IETF QUIC WG Subject: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: AdTInrfRZAbJSsLZSlWCCrlUkiWX7A== Date: Tue, 19 Feb 2019 22:11:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-02-19T22:11:11.1368746Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=1bb6e3a3-087f-4ba8-bdd1-a91996d4b014; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [2001:4898:80e8:8:de02:373b:ea82:c41a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c3f6396a-f7c5-4ee4-cd41-08d696b728c7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR21MB0773; x-ms-traffictypediagnostic: CY4PR21MB0773: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; CY4PR21MB0773; 23:lBWXV/IVctotZMCes24oiu7qhQp0OWrxjnKVuBJLE?= =?us-ascii?Q?dvdh3AF2w+YFzSARfho/9S29kkqaqVM5J5gkxBMv5Z7Dtw9Cfry81ZcLHfsz?= =?us-ascii?Q?ykpMdFSwBDl+O2QUYyqTWsiG3lEsBsa7H9KiAtTd5lnXeEgsutDw2L9YvSir?= =?us-ascii?Q?yUPwv2KaywN/gnXnTuPJLvPxvDz1FHU+l/bCn2uSBnBUM1cGrXsQ6NrUbLZM?= =?us-ascii?Q?Ia2BObi9iH0j8eCGfcMP3vBUBYrTvkSRaYOtLMEqN95vrNTYgA1mrDcUkim6?= =?us-ascii?Q?abE4iJAtIkD8Olq2tLrjGEWfjdAA2fnptk5F6LWksyAI1gIGcG268arKn5/V?= =?us-ascii?Q?EJT+WtCTj6OrFvoK/7Br7V8HnVZqLkW/RBVjyATSQ7o1wQ6frmfXZovXuea9?= =?us-ascii?Q?O74fQu09P0E1Y2cmOj6lOVjHK3Ki7pUrxjeIWDtE6C7vDLRS3jl6eqbq7nta?= =?us-ascii?Q?89pqmxrmudKlsGQW3YET8Vd1mfYqxMPU5JaTRKHfALK0v2zVcypDAVDlVzj/?= =?us-ascii?Q?B1hKhBnMK5FpzccW4yzfOkoJUtlV7RVxbB7oI4a9+gCnhQr4GU2mo/WJkRrR?= =?us-ascii?Q?VCTuiOGjjCqDCMPiS0mByyfxKVRzPmI965gRG3mhLHGin6p47f3bP1wsAU00?= =?us-ascii?Q?jU0dHe37UytkRFg+SjiJIfy/HHWc5VejR0/9kVoeFq8BMurfDysWQICYxkwp?= =?us-ascii?Q?zEfCaXIv5lAnmCEg4NHLgXA5+fyJpU96C2tGaz0haoxC7B0Rll3EIZwHFQrn?= =?us-ascii?Q?OcPc/HPd80oBQjxNrLrLjR+DEbjc4MQWU8Ek9mVXeVzAE0xNfZlppIHGwziS?= =?us-ascii?Q?rn8XRDRxp6B+Px51jHDyqjR5ktzP9LVrwgS32dm0RvusxceVQuF79n6ndavk?= =?us-ascii?Q?zsMMTZxC8QFRSwYxi3JmGqr95AOi7GUQeREFLwCumZk0evwZUwZT9dZunKzc?= =?us-ascii?Q?tG+cyxNBHH0UmkxSgLHD86EIOp9cNtchQSf551XqUM8PUCsfcWVHsBamHOxa?= =?us-ascii?Q?ae83qA8iYeLPLTbjBILz87/f3DG3ZQS9tPaRy4V/CzBerujM2onx6TJeFTQA?= =?us-ascii?Q?34GjGCZcM/Sav16mqpHLgKpHtXrNKq+1zeacYKhrJKvMGOZ91cJNfSuWTaGb?= =?us-ascii?Q?qBzqZOj9mKdh2JqFanJ7Qfv3lI+wbLa+5eYjSaznBvdeYnoYoxmZMgq2Nv0x?= =?us-ascii?Q?CiP99nAzio/JCM70GNfY5/cMJufrYTGRaSKbYAe10uor0hcOkzVyn2vdw=3D?= =?us-ascii?Q?=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(136003)(366004)(346002)(199004)(189003)(55016002)(102836004)(22452003)(6346003)(9686003)(54896002)(6306002)(53936002)(6506007)(25786009)(8990500004)(476003)(486006)(74316002)(71190400001)(8936002)(10290500003)(106356001)(256004)(14454004)(14444005)(71200400001)(97736004)(105586002)(86612001)(86362001)(478600001)(6116002)(790700001)(81166006)(81156014)(7736002)(8676002)(9326002)(7696005)(6916009)(316002)(5660300002)(10090500001)(2906002)(6436002)(46003)(186003)(99286004)(68736007)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0773; H:CY4PR21MB0854.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4U+JTgsK30WlQfk3FvP19m2Bt+HG64OFBKhEZdq/Obs18ezsGNSThDW2ey3KulUwZR4wdlS6pAd838qlDwdshsIa14myMYox3VuxWq2VBcoAMbn/GmyKGv1D5SOgUMD18L/7nX3onolcVpkUuc87d4/uoqjZgZnQyK4g/tiWsj2YzAPLkSpQhaZzE1hDNIqhzYs2V2ozR41C3PPT9gd4rImjdv2B35PFr8Y1Sxbj4guMQdZGDKtasTL/nVUy4eYZKJhOq6DpLGZfbSnyJIVIFcwqdUjR9Djg3fpKfTI5Yzjin868f/W1VKYkPco3DSNB/5pqzsXC+k9r4niwx3nVR2mM36VQW/tiOHnyi9V63zKOyVhIg1LrUtRWTO57Es/rcR2ZXA1MgpNA/Dd3eqjqu5vtYYDJkmJpGXGl6bCRCqo= Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0854341128C64E450E7C2DA2B37C0CY4PR21MB0854namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3f6396a-f7c5-4ee4-cd41-08d696b728c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 22:11:12.5777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0773 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 22:11:16 -0000 --_000_CY4PR21MB0854341128C64E450E7C2DA2B37C0CY4PR21MB0854namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Folks, I've been looking at interim DDoS mitigation strategies for QUIC until we c= an have a more complete and QUIC aware DDoS and LB solution. One thing I ca= me up with is just trying to force the client to fallback to TCP. Eventuall= y, we will use Stateless Retry but that still requires a good bit of design= work and cooperation between the offload device and the backend server. Un= til that is complete, a simple solution could be a device in path just resp= onding to new QUIC connection attempts (while an attack is in progress) wit= h a connection close frame containing the SERVER_BUSY error. The logic to i= mplement a simple device to do that should be quite trivial. To that end, I was trying to figure out what the expected client response t= o any immediate (in the first RTT) connection close packets/frames would be= and it seems we don't have anything in the spec. What about SERVER_BUSY sp= ecifically? Is the client supposed to retry a new connection attempt? Shoul= d they fallback to TCP immediately? Should we say anything in the spec? Thanks, - Nick --_000_CY4PR21MB0854341128C64E450E7C2DA2B37C0CY4PR21MB0854namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Folks,

 

I’ve been looking at interim DDoS mitigation s= trategies for QUIC until we can have a more complete and QUIC aware DDoS an= d LB solution. One thing I came up with is just trying to force the client = to fallback to TCP. Eventually, we will use Stateless Retry but that still requires a good bit of design work and = cooperation between the offload device and the backend server. Until that i= s complete, a simple solution could be a device in path just responding to = new QUIC connection attempts (while an attack is in progress) with a connection close frame containing the SER= VER_BUSY error. The logic to implement a simple device to do that should be= quite trivial.

 

To that end, I was trying to figure out what the exp= ected client response to any immediate (in the first RTT) connection close = packets/frames would be and it seems we don’t have anything in the sp= ec. What about SERVER_BUSY specifically? Is the client supposed to retry a new connection attempt? Should they fall= back to TCP immediately? Should we say anything in the spec?

 

Thanks,

- Nick

--_000_CY4PR21MB0854341128C64E450E7C2DA2B37C0CY4PR21MB0854namp_-- From nobody Tue Feb 19 15:10:13 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59DA131027 for ; Tue, 19 Feb 2019 15:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvww0vY-TCSY for ; Tue, 19 Feb 2019 15:10:10 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 4BD53131024 for ; Tue, 19 Feb 2019 15:10:08 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id g11-v6so19126816ljk.3 for ; Tue, 19 Feb 2019 15:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3/aUWo1Ithg1SH2/7vTetBWRp2thtHLPU+8EnRwy2A=; b=K+jGpkOiXRpAG5gHTqiCVFryb0THV0AVHBT7WrMdDqH8IqmXFnnUE5etdNtFXb9XsJ QGjj5YRttOD+7o33dGV/vmlyuOfXdywlTeIT2T5fTDONXaNw9VcUVnFlpntVrtdNJt9h /BlOwE2s//RThA+XSPLC8XZvKRjujBrs4CrBCWvUaNzzwLEMi30mHt9Jz3LcAQ4NJCPH uKsy1gYaKOByoVtsgpXoMPsUxewSfd5+z6xQFxw3FjzfCDSTliQoXMglI5hjnhkOVEkl qdJHt6TNW2w2OzTKcrsQ9Bn3kaf5nIGRk+4MhKZQLwB3tNFe6TNXsqKlaNSWqpr2Jj3A lADw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3/aUWo1Ithg1SH2/7vTetBWRp2thtHLPU+8EnRwy2A=; b=BB9FR27XnsgcvbBRsZb9UwqL40UI9lO71wTpW37d8PI5zt9SvT/bnRyX99y+2/Cvvp UBav24BSa8fxIk/M/YjdvNhI5H0BXynaTbMAx/Ro4iC60I/QaTrWXSyg75E6rzcEydCM Bn1/YcsylKbV9ruZUv1GTO8A0aXCKpqZ8jlLd2NwLxStWIeExXv7foUKwSJSDLFIsteh H7Gh9lTPQNJbqGsj8OOx4660jsD30lYB5dGrc/IGunypNi5V+QR0DmM87W5kEd5V0QTF xTUBpQS8hiKsRussES5MiQZ+1VRqn5hG8hP4xtOvwMhh0Qy4sXIVabg0Do7md/BoHAu+ 1ktA== X-Gm-Message-State: AHQUAuavBzJIDW+yaSc7lmdgVNys2XrGQ6esJ5iBDVgAQU46VPkk3kzp 1EgiZPcgSTZZ1TKQCXuyaBkISPLmacHaMyD5f87o1XHs X-Google-Smtp-Source: AHgI3IalEjcYJ+muE3RQ2jh/SNQ7fsytqjCpp2QW6TBc/fBil8IT0uw/VBLZHKF1E73gI8EP6p4QxGTZ++xa5sKeHhc= X-Received: by 2002:a2e:6801:: with SMTP id c1mr7785439lja.81.1550617806314; Tue, 19 Feb 2019 15:10:06 -0800 (PST) MIME-Version: 1.0 References: <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com> In-Reply-To: From: Jana Iyengar Date: Tue, 19 Feb 2019 15:09:55 -0800 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="00000000000087256f05824757ca" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 23:10:13 -0000 --00000000000087256f05824757ca Content-Type: text/plain; charset="UTF-8" On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson wrote: > I don't think that there is much value in using two version numbers to > refer to the same protocol. But even if we did, as long as we didn't > establish any pattern in doing so, that couldn't be used against us. So I > might tentatively agree that 0x1 == 0x2 would be inadvisable, there is no > strong need to do anything special with the first version. Any attempt to > profile QUIC will be done with full knowledge of the version number we > pick, so randomness doesn't serve any real purpose. Subsequent versions > might need to use a randomized value, but we can make that decision then. > I figured that making all version assignments random instead of special-casing 0x1 made it simpler to reason about and uniform to code for, but I actually don't care about the IANA assignment for v1 for the reason you note. v1 will be one specific bit-pattern on the wire to start of with, and that can just as well be 0x1. It still does segregate the space, but we can't do anything about it anyways - it'll be 0x1 or some other random number getting special treatment. The problem of course being that as long as v1 remains, we might find > places that no other version does. The QUIC "magic number" will be > whatever we pick, and we can't prevent someone from fixating on that. > We'll convince those people in the same way they will be convinced to open > up UDP for QUIC version 1: by making a QUIC version 2 worth enabling. > That was the entire point of having alternate and preferred versions to 0x1. If we have downgrade protection in place, and if there are those who try alternate version numbers for v1, that gives us what we need at the endpoints. I believe that there would be interest at some major vendors to do this at some endpoints. Presumably, we can convince Google to do something, since it has been bit by mbox ossification in the past. I am operating on the premise that we have buy in from a few major providers. IANA is for me a publication venue where these alternate versions are published and other clients/servers interested in keeping the ecosystem from ossifying can use these alternate versions as well. I completely get the don't segregate thing. But to - I think - Mikkel's > point about experimentation without permission, I do think that squatting > is a perfectly sound approach in a space this big. TLS people do it in a > much smaller space. As long squatters pick random values, they do so > infrequently, and they get IANA registrations for codepoints relatively > soon afterwards, the risk of collision is low. Randomness here is useful - > but primarily as a collision-avoidance technique. The TLS extension > codepoint 26 is a great example of why. Keeping the bar on registrations > low (FCFS is a reasonable policy) would also have the effect of making the > pool of apparent versions larger, which might be more effective than any > other strategy we might employ. > I'm totally fine with experimentation without permission, and using random to avoid collision. My point was entirely about using alternate on-wire version numbers for v1. Nothing here about new or experimental versions. --00000000000087256f05824757ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 19, 2019 at 7:52 AM Martin Th= omson <mt@lowentropy.net> wr= ote:=C2=A0
I don't think that there is much value in using two v= ersion numbers to refer to the same protocol.=C2=A0 But even if we did, as = long as we didn't establish any pattern in doing so, that couldn't = be used against us.=C2=A0 So I might tentatively agree that 0x1 =3D=3D 0x2 = would be inadvisable, there is no strong need to do anything special with t= he first version.=C2=A0 Any attempt to profile QUIC will be done with full = knowledge of the version number we pick, so randomness doesn't serve an= y real purpose.=C2=A0 Subsequent versions might need to use a randomized va= lue, but we can make that decision then.

I figured that making all version assignments random instead of special-c= asing 0x1 made it simpler to reason about and uniform to code for, but I ac= tually don't care about the IANA assignment for v1 for the reason you n= ote. v1 will be one specific bit-pattern on the wire to start of with, and = that can just as well be 0x1. It still does segregate the space, but we can= 't do anything about it anyways - it'll be 0x1 or some other random= number getting special treatment.

The problem of course being that as long as v1 remains, we might find place= s that no other version does.=C2=A0 The QUIC "magic number" will = be whatever we pick, and we can't prevent someone from fixating on that= .=C2=A0 We'll convince those people in the same way they will be convin= ced to open up UDP for QUIC version 1: by making a QUIC version 2 worth ena= bling.

That was the entire point of hav= ing alternate and preferred versions to 0x1. If we have downgrade protectio= n in place, and if there are those who try alternate version numbers for v1= , that gives us what we need at the endpoints. I believe that there would b= e interest at some major vendors to do this at some endpoints. Presumably, = we can convince Google to do something, since it has been bit by mbox ossif= ication in the past. I am operating on the premise that we have buy in from= a few major providers.

IANA is for me a publicati= on venue where these alternate versions are published and other clients/ser= vers interested in keeping the ecosystem from ossifying can use these alter= nate versions as well.

I completely get the don't segregate thing.=C2=A0 But to - I think - Mi= kkel's point about experimentation without permission, I do think that = squatting is a perfectly sound approach in a space this big.=C2=A0 TLS peop= le do it in a much smaller space.=C2=A0 As long squatters pick random value= s, they do so infrequently, and they get IANA registrations for codepoints = relatively soon afterwards, the risk of collision is low.=C2=A0 Randomness = here is useful - but primarily as a collision-avoidance technique.=C2=A0 Th= e TLS extension codepoint 26 is a great example of why.=C2=A0 Keeping the b= ar on registrations low (FCFS is a reasonable policy) would also have the e= ffect of making the pool of apparent versions larger, which might be more e= ffective than any other strategy we might employ.

=
I'm totally fine with experimentation without permission, an= d using random to avoid collision. My point was entirely about using altern= ate on-wire version numbers for v1. Nothing here about new or experimental = versions.

--00000000000087256f05824757ca-- From nobody Tue Feb 19 15:15:05 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A10130E11 for ; Tue, 19 Feb 2019 15:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=LxtGHUSQ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=MzcKhl9Y 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 rqKi59X2kkYb for ; Tue, 19 Feb 2019 15:15:01 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F36F1274D0 for ; Tue, 19 Feb 2019 15:15:01 -0800 (PST) Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1JNANa5013381; Tue, 19 Feb 2019 15:14:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=HALqEDCz3CtIwfBLkNpA/fXjCTqOZmg1qYtXViqVAyk=; b=LxtGHUSQohLruThu3YWl12qPar0CmTb+W4f6FJu/wM4aVpj6V5YwP4zeaoIygFAnMHOT hn/ffiCrnm+zzyoleiwDhayoBS0xmA5xLmgi1/LCgCyxsmLqoY/Qh9yykub2fEeaXBUS Ow1GV5AGUkWrnjSck4ncwhb3PNciyG/P31M= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qrsuh8acp-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Feb 2019 15:14:59 -0800 Received: from frc-hub06.TheFacebook.com (2620:10d:c021:18::176) by frc-hub01.TheFacebook.com (2620:10d:c021:18::171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 19 Feb 2019 15:14:27 -0800 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Tue, 19 Feb 2019 15:14:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HALqEDCz3CtIwfBLkNpA/fXjCTqOZmg1qYtXViqVAyk=; b=MzcKhl9Y3Cmb2UMnkMWnc59rbsRy5b9JgLZ/QwlFtyxMpByGsOdJNoaX5khScrliS6ZXMM2nP++GDH4wpKTgeoTr8EBDnFg4mesPmHWNrvpabwv/luifPtvrWng1cH0RaTeo6bQTW6eRR5cpX4QCPoJzqTCyt4i16X2kDmSHWD0= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2437.namprd15.prod.outlook.com (52.135.198.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.19; Tue, 19 Feb 2019 23:14:26 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084%5]) with mapi id 15.20.1622.018; Tue, 19 Feb 2019 23:14:26 +0000 From: Roberto Peon To: Jana Iyengar , Martin Thomson CC: QUIC WG Subject: Re: QUIC ossification Thread-Topic: QUIC ossification Thread-Index: AQHUwxih7UYarYoV30WBSlEhJDleK6Xcr5EA//+EwACAAKdJAP//fAuAgAGRSoCAAArqgIAABPsAgAAA14CAAAMfgIAACY0A//+6QoAAEcIhgAAHiM6AAAFCw4AAAtg4AAAAMeuAAABRNgAAAVt/AAAAuC4AAAHDNQAAHrd+gAAAHQ4AAABwzoAACKm9AAAAEgiAAAAr9QAAACHTgAAATyAAAALUMwAAywJVgAAZs5wAAA9NEYD//3slgA== Date: Tue, 19 Feb 2019 23:14:26 +0000 Message-ID: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::6:a040] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a3be0cd-1486-4ea1-9279-08d696bffe1a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2437; x-ms-traffictypediagnostic: BYAPR15MB2437: x-microsoft-exchange-diagnostics: 1; BYAPR15MB2437; 20:W1c0nvwum/aOtwWsaRpV9YdOWqJPltlUXx3sotoDInhY+FFs7Ap7cKetXRQYoGzCz/CNEmdR3Ln76CjnJSDjkWH8hKOfEI4ICHS1z7QlOnjL6H0HQE+FJ8WksHnjWTlQYIYlFxpTZGzFu35cAATmBz9OtYZa8B6shkMWvl7vFAQ= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(136003)(39860400002)(366004)(346002)(189003)(199004)(6246003)(68736007)(2906002)(46003)(33656002)(106356001)(97736004)(316002)(102836004)(5660300002)(186003)(486006)(110136005)(86362001)(105586002)(476003)(53936002)(81156014)(81166006)(8936002)(58126008)(7736002)(11346002)(8676002)(99286004)(6506007)(53546011)(2616005)(446003)(6436002)(478600001)(236005)(71200400001)(71190400001)(7116003)(3480700005)(6486002)(6512007)(6116002)(14444005)(25786009)(221733001)(54896002)(6306002)(82746002)(4326008)(36756003)(14454004)(83716004)(229853002)(76176011)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2437; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zr9jeC/rJ4XhjcvQNNRRRcNLXtLCRb8OuWuwj/Jg5iYgijkhGR4c5a0cPR1AQJehjpxGx2K6hDBxuU5otbJstAjW+WlL9fVTkVUbVd9gmEZJGXzuuDmDLVb5MY7wY33lKLXTBx5HpBf9cb6/TjHymATExGM+SKP8y9IaMGIgLY3jHaHgrnx8j1ctn0jdz/OpSQtw2XbdNwFmo+jwWdUrLuawnK05XAz4tcDVTR0LTEt2K5hpjfIzXEwHXRAlugKYBJUnwPhKJv+NuyrIv3reBFZwVYmc/w2aoAiph6BuQvyXEQirzXRZIvsTnQo5Q19MECVFCbVU9nSNnSd6u2Oym1kDOQPcx7oh8WHNi11c1FgENwgg0srAm2PrQXIturGsZodwcJChNj2sW8vqUKKpUirMHf/Tcd0BR1MBJ0ean6k= Content-Type: multipart/alternative; boundary="_000_783327C4387748F4A41A5987458C39B7fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1a3be0cd-1486-4ea1-9279-08d696bffe1a X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 23:14:26.3976 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2437 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-19_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 23:15:04 -0000 --_000_783327C4387748F4A41A5987458C39B7fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgb3RoZXJzIGhhdmUgaW50aW1hdGVkIGluIHNvbWUgZm9ybSBvciBhbm90aGVyLCB5b3UgY2Fu IGFsc28gdXNlIG11bHRpcGxlIG51bWJlcnMgdG8gZXhwcmVzcyDigJx2ZXJzaW9uIDHigJ0uDQoN CkZvciBpbnN0YW5jZSwgcGljayA2NCAob3Igc29tZSBzaW1pbGFyIGNvbnN0YW50KSByYW5kb20g bnVtYmVycywgYW5kIGNhbGwgdGhlbSBhbGwgdmVyc2lvbiAxLg0KLT1SDQoNCkZyb206IFFVSUMg PHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEphbmEgSXllbmdhciA8anJpLmll dGZAZ21haWwuY29tPg0KRGF0ZTogVHVlc2RheSwgRmVicnVhcnkgMTksIDIwMTkgYXQgMzoxMCBQ TQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD4NCkNjOiBRVUlDIFdHIDxx dWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFFVSUMgb3NzaWZpY2F0aW9uDQoNCk9uIFR1ZSwg RmViIDE5LCAyMDE5IGF0IDc6NTIgQU0gTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0 PG1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldD4+IHdyb3RlOg0KSSBkb24ndCB0aGluayB0aGF0IHRo ZXJlIGlzIG11Y2ggdmFsdWUgaW4gdXNpbmcgdHdvIHZlcnNpb24gbnVtYmVycyB0byByZWZlciB0 byB0aGUgc2FtZSBwcm90b2NvbC4gIEJ1dCBldmVuIGlmIHdlIGRpZCwgYXMgbG9uZyBhcyB3ZSBk aWRuJ3QgZXN0YWJsaXNoIGFueSBwYXR0ZXJuIGluIGRvaW5nIHNvLCB0aGF0IGNvdWxkbid0IGJl IHVzZWQgYWdhaW5zdCB1cy4gIFNvIEkgbWlnaHQgdGVudGF0aXZlbHkgYWdyZWUgdGhhdCAweDEg PT0gMHgyIHdvdWxkIGJlIGluYWR2aXNhYmxlLCB0aGVyZSBpcyBubyBzdHJvbmcgbmVlZCB0byBk byBhbnl0aGluZyBzcGVjaWFsIHdpdGggdGhlIGZpcnN0IHZlcnNpb24uICBBbnkgYXR0ZW1wdCB0 byBwcm9maWxlIFFVSUMgd2lsbCBiZSBkb25lIHdpdGggZnVsbCBrbm93bGVkZ2Ugb2YgdGhlIHZl cnNpb24gbnVtYmVyIHdlIHBpY2ssIHNvIHJhbmRvbW5lc3MgZG9lc24ndCBzZXJ2ZSBhbnkgcmVh bCBwdXJwb3NlLiAgU3Vic2VxdWVudCB2ZXJzaW9ucyBtaWdodCBuZWVkIHRvIHVzZSBhIHJhbmRv bWl6ZWQgdmFsdWUsIGJ1dCB3ZSBjYW4gbWFrZSB0aGF0IGRlY2lzaW9uIHRoZW4uDQoNCkkgZmln dXJlZCB0aGF0IG1ha2luZyBhbGwgdmVyc2lvbiBhc3NpZ25tZW50cyByYW5kb20gaW5zdGVhZCBv ZiBzcGVjaWFsLWNhc2luZyAweDEgbWFkZSBpdCBzaW1wbGVyIHRvIHJlYXNvbiBhYm91dCBhbmQg dW5pZm9ybSB0byBjb2RlIGZvciwgYnV0IEkgYWN0dWFsbHkgZG9uJ3QgY2FyZSBhYm91dCB0aGUg SUFOQSBhc3NpZ25tZW50IGZvciB2MSBmb3IgdGhlIHJlYXNvbiB5b3Ugbm90ZS4gdjEgd2lsbCBi ZSBvbmUgc3BlY2lmaWMgYml0LXBhdHRlcm4gb24gdGhlIHdpcmUgdG8gc3RhcnQgb2Ygd2l0aCwg YW5kIHRoYXQgY2FuIGp1c3QgYXMgd2VsbCBiZSAweDEuIEl0IHN0aWxsIGRvZXMgc2VncmVnYXRl IHRoZSBzcGFjZSwgYnV0IHdlIGNhbid0IGRvIGFueXRoaW5nIGFib3V0IGl0IGFueXdheXMgLSBp dCdsbCBiZSAweDEgb3Igc29tZSBvdGhlciByYW5kb20gbnVtYmVyIGdldHRpbmcgc3BlY2lhbCB0 cmVhdG1lbnQuDQoNClRoZSBwcm9ibGVtIG9mIGNvdXJzZSBiZWluZyB0aGF0IGFzIGxvbmcgYXMg djEgcmVtYWlucywgd2UgbWlnaHQgZmluZCBwbGFjZXMgdGhhdCBubyBvdGhlciB2ZXJzaW9uIGRv ZXMuICBUaGUgUVVJQyAibWFnaWMgbnVtYmVyIiB3aWxsIGJlIHdoYXRldmVyIHdlIHBpY2ssIGFu ZCB3ZSBjYW4ndCBwcmV2ZW50IHNvbWVvbmUgZnJvbSBmaXhhdGluZyBvbiB0aGF0Li4gIFdlJ2xs IGNvbnZpbmNlIHRob3NlIHBlb3BsZSBpbiB0aGUgc2FtZSB3YXkgdGhleSB3aWxsIGJlIGNvbnZp bmNlZCB0byBvcGVuIHVwIFVEUCBmb3IgUVVJQyB2ZXJzaW9uIDE6IGJ5IG1ha2luZyBhIFFVSUMg dmVyc2lvbiAyIHdvcnRoIGVuYWJsaW5nLg0KDQpUaGF0IHdhcyB0aGUgZW50aXJlIHBvaW50IG9m IGhhdmluZyBhbHRlcm5hdGUgYW5kIHByZWZlcnJlZCB2ZXJzaW9ucyB0byAweDEuIElmIHdlIGhh dmUgZG93bmdyYWRlIHByb3RlY3Rpb24gaW4gcGxhY2UsIGFuZCBpZiB0aGVyZSBhcmUgdGhvc2Ug d2hvIHRyeSBhbHRlcm5hdGUgdmVyc2lvbiBudW1iZXJzIGZvciB2MSwgdGhhdCBnaXZlcyB1cyB3 aGF0IHdlIG5lZWQgYXQgdGhlIGVuZHBvaW50cy4gSSBiZWxpZXZlIHRoYXQgdGhlcmUgd291bGQg YmUgaW50ZXJlc3QgYXQgc29tZSBtYWpvciB2ZW5kb3JzIHRvIGRvIHRoaXMgYXQgc29tZSBlbmRw b2ludHMuIFByZXN1bWFibHksIHdlIGNhbiBjb252aW5jZSBHb29nbGUgdG8gZG8gc29tZXRoaW5n LCBzaW5jZSBpdCBoYXMgYmVlbiBiaXQgYnkgbWJveCBvc3NpZmljYXRpb24gaW4gdGhlIHBhc3Qu IEkgYW0gb3BlcmF0aW5nIG9uIHRoZSBwcmVtaXNlIHRoYXQgd2UgaGF2ZSBidXkgaW4gZnJvbSBh IGZldyBtYWpvciBwcm92aWRlcnMuDQoNCklBTkEgaXMgZm9yIG1lIGEgcHVibGljYXRpb24gdmVu dWUgd2hlcmUgdGhlc2UgYWx0ZXJuYXRlIHZlcnNpb25zIGFyZSBwdWJsaXNoZWQgYW5kIG90aGVy IGNsaWVudHMvc2VydmVycyBpbnRlcmVzdGVkIGluIGtlZXBpbmcgdGhlIGVjb3N5c3RlbSBmcm9t IG9zc2lmeWluZyBjYW4gdXNlIHRoZXNlIGFsdGVybmF0ZSB2ZXJzaW9ucyBhcyB3ZWxsLg0KDQpJ IGNvbXBsZXRlbHkgZ2V0IHRoZSBkb24ndCBzZWdyZWdhdGUgdGhpbmcuICBCdXQgdG8gLSBJIHRo aW5rIC0gTWlra2VsJ3MgcG9pbnQgYWJvdXQgZXhwZXJpbWVudGF0aW9uIHdpdGhvdXQgcGVybWlz c2lvbiwgSSBkbyB0aGluayB0aGF0IHNxdWF0dGluZyBpcyBhIHBlcmZlY3RseSBzb3VuZCBhcHBy b2FjaCBpbiBhIHNwYWNlIHRoaXMgYmlnLiAgVExTIHBlb3BsZSBkbyBpdCBpbiBhIG11Y2ggc21h bGxlciBzcGFjZS4gIEFzIGxvbmcgc3F1YXR0ZXJzIHBpY2sgcmFuZG9tIHZhbHVlcywgdGhleSBk byBzbyBpbmZyZXF1ZW50bHksIGFuZCB0aGV5IGdldCBJQU5BIHJlZ2lzdHJhdGlvbnMgZm9yIGNv ZGVwb2ludHMgcmVsYXRpdmVseSBzb29uIGFmdGVyd2FyZHMsIHRoZSByaXNrIG9mIGNvbGxpc2lv biBpcyBsb3cuICBSYW5kb21uZXNzIGhlcmUgaXMgdXNlZnVsIC0gYnV0IHByaW1hcmlseSBhcyBh IGNvbGxpc2lvbi1hdm9pZGFuY2UgdGVjaG5pcXVlLiAgVGhlIFRMUyBleHRlbnNpb24gY29kZXBv aW50IDI2IGlzIGEgZ3JlYXQgZXhhbXBsZSBvZiB3aHkuICBLZWVwaW5nIHRoZSBiYXIgb24gcmVn aXN0cmF0aW9ucyBsb3cgKEZDRlMgaXMgYSByZWFzb25hYmxlIHBvbGljeSkgd291bGQgYWxzbyBo YXZlIHRoZSBlZmZlY3Qgb2YgbWFraW5nIHRoZSBwb29sIG9mIGFwcGFyZW50IHZlcnNpb25zIGxh cmdlciwgd2hpY2ggbWlnaHQgYmUgbW9yZSBlZmZlY3RpdmUgdGhhbiBhbnkgb3RoZXIgc3RyYXRl Z3kgd2UgbWlnaHQgZW1wbG95Lg0KDQpJJ20gdG90YWxseSBmaW5lIHdpdGggZXhwZXJpbWVudGF0 aW9uIHdpdGhvdXQgcGVybWlzc2lvbiwgYW5kIHVzaW5nIHJhbmRvbSB0byBhdm9pZCBjb2xsaXNp b24uIE15IHBvaW50IHdhcyBlbnRpcmVseSBhYm91dCB1c2luZyBhbHRlcm5hdGUgb24td2lyZSB2 ZXJzaW9uIG51bWJlcnMgZm9yIHYxLiBOb3RoaW5nIGhlcmUgYWJvdXQgbmV3IG9yIGV4cGVyaW1l bnRhbCB2ZXJzaW9ucy4NCg0K --_000_783327C4387748F4A41A5987458C39B7fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDIgMyAzIDIgMjt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgb3Ro ZXJzIGhhdmUgaW50aW1hdGVkIGluIHNvbWUgZm9ybSBvciBhbm90aGVyLCB5b3UgY2FuIGFsc28g dXNlIG11bHRpcGxlIG51bWJlcnMgdG8gZXhwcmVzcyDigJx2ZXJzaW9uIDHigJ0uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpGb3IgaW5zdGFuY2UsIHBpY2sgNjQg KG9yIHNvbWUgc2ltaWxhciBjb25zdGFudCkgcmFuZG9tIG51bWJlcnMsIGFuZCBjYWxsIHRoZW0g YWxsIHZlcnNpb24gMS48YnI+DQotPVI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9m IEphbmEgSXllbmdhciAmbHQ7anJpLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UdWVzZGF5LCBGZWJydWFyeSAxOSwgMjAxOSBhdCAzOjEwIFBNPGJyPg0KPGI+VG86IDwvYj5N YXJ0aW4gVGhvbXNvbiAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5R VUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogUVVJ QyBvc3NpZmljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAxOSwgMjAxOSBhdCA3OjUyIEFN IE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bXRAbG93ZW50cm9weS5uZXQiPm10 QGxvd2VudHJvcHkubmV0PC9hPiZndDsgd3JvdGU6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB0aGlu ayB0aGF0IHRoZXJlIGlzIG11Y2ggdmFsdWUgaW4gdXNpbmcgdHdvIHZlcnNpb24gbnVtYmVycyB0 byByZWZlciB0byB0aGUgc2FtZSBwcm90b2NvbC4mbmJzcDsgQnV0IGV2ZW4gaWYgd2UgZGlkLCBh cyBsb25nIGFzIHdlIGRpZG4ndCBlc3RhYmxpc2ggYW55IHBhdHRlcm4gaW4gZG9pbmcgc28sIHRo YXQgY291bGRuJ3QgYmUgdXNlZCBhZ2FpbnN0IHVzLiZuYnNwOyBTbyBJIG1pZ2h0IHRlbnRhdGl2 ZWx5IGFncmVlDQogdGhhdCAweDEgPT0gMHgyIHdvdWxkIGJlIGluYWR2aXNhYmxlLCB0aGVyZSBp cyBubyBzdHJvbmcgbmVlZCB0byBkbyBhbnl0aGluZyBzcGVjaWFsIHdpdGggdGhlIGZpcnN0IHZl cnNpb24uJm5ic3A7IEFueSBhdHRlbXB0IHRvIHByb2ZpbGUgUVVJQyB3aWxsIGJlIGRvbmUgd2l0 aCBmdWxsIGtub3dsZWRnZSBvZiB0aGUgdmVyc2lvbiBudW1iZXIgd2UgcGljaywgc28gcmFuZG9t bmVzcyBkb2Vzbid0IHNlcnZlIGFueSByZWFsIHB1cnBvc2UuJm5ic3A7IFN1YnNlcXVlbnQNCiB2 ZXJzaW9ucyBtaWdodCBuZWVkIHRvIHVzZSBhIHJhbmRvbWl6ZWQgdmFsdWUsIGJ1dCB3ZSBjYW4g bWFrZSB0aGF0IGRlY2lzaW9uIHRoZW4uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGZpZ3VyZWQgdGhhdCBtYWtpbmcgYWxsIHZl cnNpb24gYXNzaWdubWVudHMgcmFuZG9tIGluc3RlYWQgb2Ygc3BlY2lhbC1jYXNpbmcgMHgxIG1h ZGUgaXQgc2ltcGxlciB0byByZWFzb24gYWJvdXQgYW5kIHVuaWZvcm0gdG8gY29kZSBmb3IsIGJ1 dCBJIGFjdHVhbGx5IGRvbid0IGNhcmUgYWJvdXQgdGhlIElBTkEgYXNzaWdubWVudCBmb3IgdjEg Zm9yIHRoZSByZWFzb24geW91IG5vdGUuIHYxIHdpbGwgYmUgb25lDQogc3BlY2lmaWMgYml0LXBh dHRlcm4gb24gdGhlIHdpcmUgdG8gc3RhcnQgb2Ygd2l0aCwgYW5kIHRoYXQgY2FuIGp1c3QgYXMg d2VsbCBiZSAweDEuIEl0IHN0aWxsIGRvZXMgc2VncmVnYXRlIHRoZSBzcGFjZSwgYnV0IHdlIGNh bid0IGRvIGFueXRoaW5nIGFib3V0IGl0IGFueXdheXMgLSBpdCdsbCBiZSAweDEgb3Igc29tZSBv dGhlciByYW5kb20gbnVtYmVyIGdldHRpbmcgc3BlY2lhbCB0cmVhdG1lbnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9i bGVtIG9mIGNvdXJzZSBiZWluZyB0aGF0IGFzIGxvbmcgYXMgdjEgcmVtYWlucywgd2UgbWlnaHQg ZmluZCBwbGFjZXMgdGhhdCBubyBvdGhlciB2ZXJzaW9uIGRvZXMuJm5ic3A7IFRoZSBRVUlDICZx dW90O21hZ2ljIG51bWJlciZxdW90OyB3aWxsIGJlIHdoYXRldmVyIHdlIHBpY2ssIGFuZCB3ZSBj YW4ndCBwcmV2ZW50IHNvbWVvbmUgZnJvbSBmaXhhdGluZyBvbiB0aGF0Li4mbmJzcDsgV2UnbGwg Y29udmluY2UgdGhvc2UgcGVvcGxlDQogaW4gdGhlIHNhbWUgd2F5IHRoZXkgd2lsbCBiZSBjb252 aW5jZWQgdG8gb3BlbiB1cCBVRFAgZm9yIFFVSUMgdmVyc2lvbiAxOiBieSBtYWtpbmcgYSBRVUlD IHZlcnNpb24gMiB3b3J0aCBlbmFibGluZy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgd2FzIHRoZSBlbnRpcmUgcG9pbnQg b2YgaGF2aW5nIGFsdGVybmF0ZSBhbmQgcHJlZmVycmVkIHZlcnNpb25zIHRvIDB4MS4gSWYgd2Ug aGF2ZSBkb3duZ3JhZGUgcHJvdGVjdGlvbiBpbiBwbGFjZSwgYW5kIGlmIHRoZXJlIGFyZSB0aG9z ZSB3aG8gdHJ5IGFsdGVybmF0ZSB2ZXJzaW9uIG51bWJlcnMgZm9yIHYxLCB0aGF0IGdpdmVzIHVz IHdoYXQgd2UgbmVlZCBhdCB0aGUgZW5kcG9pbnRzLiBJIGJlbGlldmUNCiB0aGF0IHRoZXJlIHdv dWxkIGJlIGludGVyZXN0IGF0IHNvbWUgbWFqb3IgdmVuZG9ycyB0byBkbyB0aGlzIGF0IHNvbWUg ZW5kcG9pbnRzLiBQcmVzdW1hYmx5LCB3ZSBjYW4gY29udmluY2UgR29vZ2xlIHRvIGRvIHNvbWV0 aGluZywgc2luY2UgaXQgaGFzIGJlZW4gYml0IGJ5IG1ib3ggb3NzaWZpY2F0aW9uIGluIHRoZSBw YXN0LiBJIGFtIG9wZXJhdGluZyBvbiB0aGUgcHJlbWlzZSB0aGF0IHdlIGhhdmUgYnV5IGluIGZy b20gYSBmZXcgbWFqb3INCiBwcm92aWRlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklBTkEgaXMgZm9yIG1lIGEgcHVibGljYXRpb24gdmVu dWUgd2hlcmUgdGhlc2UgYWx0ZXJuYXRlIHZlcnNpb25zIGFyZSBwdWJsaXNoZWQgYW5kIG90aGVy IGNsaWVudHMvc2VydmVycyBpbnRlcmVzdGVkIGluIGtlZXBpbmcgdGhlIGVjb3N5c3RlbSBmcm9t IG9zc2lmeWluZyBjYW4gdXNlIHRoZXNlIGFsdGVybmF0ZSB2ZXJzaW9ucyBhcyB3ZWxsLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGNvbXBsZXRlbHkgZ2V0IHRoZSBkb24ndCBzZWdyZWdhdGUgdGhpbmcuJm5ic3A7IEJ1dCB0byAt IEkgdGhpbmsgLSBNaWtrZWwncyBwb2ludCBhYm91dCBleHBlcmltZW50YXRpb24gd2l0aG91dCBw ZXJtaXNzaW9uLCBJIGRvIHRoaW5rIHRoYXQgc3F1YXR0aW5nIGlzIGEgcGVyZmVjdGx5IHNvdW5k IGFwcHJvYWNoIGluIGEgc3BhY2UgdGhpcyBiaWcuJm5ic3A7IFRMUyBwZW9wbGUgZG8gaXQgaW4g YSBtdWNoIHNtYWxsZXIgc3BhY2UuJm5ic3A7DQogQXMgbG9uZyBzcXVhdHRlcnMgcGljayByYW5k b20gdmFsdWVzLCB0aGV5IGRvIHNvIGluZnJlcXVlbnRseSwgYW5kIHRoZXkgZ2V0IElBTkEgcmVn aXN0cmF0aW9ucyBmb3IgY29kZXBvaW50cyByZWxhdGl2ZWx5IHNvb24gYWZ0ZXJ3YXJkcywgdGhl IHJpc2sgb2YgY29sbGlzaW9uIGlzIGxvdy4mbmJzcDsgUmFuZG9tbmVzcyBoZXJlIGlzIHVzZWZ1 bCAtIGJ1dCBwcmltYXJpbHkgYXMgYSBjb2xsaXNpb24tYXZvaWRhbmNlIHRlY2huaXF1ZS4mbmJz cDsgVGhlIFRMUw0KIGV4dGVuc2lvbiBjb2RlcG9pbnQgMjYgaXMgYSBncmVhdCBleGFtcGxlIG9m IHdoeS4mbmJzcDsgS2VlcGluZyB0aGUgYmFyIG9uIHJlZ2lzdHJhdGlvbnMgbG93IChGQ0ZTIGlz IGEgcmVhc29uYWJsZSBwb2xpY3kpIHdvdWxkIGFsc28gaGF2ZSB0aGUgZWZmZWN0IG9mIG1ha2lu ZyB0aGUgcG9vbCBvZiBhcHBhcmVudCB2ZXJzaW9ucyBsYXJnZXIsIHdoaWNoIG1pZ2h0IGJlIG1v cmUgZWZmZWN0aXZlIHRoYW4gYW55IG90aGVyIHN0cmF0ZWd5IHdlIG1pZ2h0DQogZW1wbG95Ljxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSdtIHRvdGFsbHkgZmluZSB3aXRoIGV4cGVyaW1lbnRhdGlvbiB3aXRob3V0IHBlcm1pc3Np b24sIGFuZCB1c2luZyByYW5kb20gdG8gYXZvaWQgY29sbGlzaW9uLiBNeSBwb2ludCB3YXMgZW50 aXJlbHkgYWJvdXQgdXNpbmcgYWx0ZXJuYXRlIG9uLXdpcmUgdmVyc2lvbiBudW1iZXJzIGZvciB2 MS4gTm90aGluZyBoZXJlIGFib3V0IG5ldyBvciBleHBlcmltZW50YWwgdmVyc2lvbnMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_783327C4387748F4A41A5987458C39B7fbcom_-- From nobody Tue Feb 19 15:17:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC4130DE7 for ; Tue, 19 Feb 2019 15:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iR8GYk4sn9mO for ; Tue, 19 Feb 2019 15:17:32 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 5D6841274D0 for ; Tue, 19 Feb 2019 15:17:32 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id j13-v6so19146579ljc.2 for ; Tue, 19 Feb 2019 15:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KxJYMPHTSeqqqajYcptZcxO+883thpmVhqESNgcBe+0=; b=nAvv7P68g1Coap3RTMUr74iKMdPP3hLabSEojgLWCBpBWXitstjP6UX7mfG4zJgt+S 9cMLhvYnDGvd3eC2VzM1kwcCAib4tR2Lj6MzGeF/mB3flmhiluPYhuP11NYiybdYlQjg MltNbQcCk7pzMFTsDIU1tjPrCBrir0MMIoxywrehuvg/P/e1tzdHgNwntX8uTg1E8HaA ffcznux6qFNuU43zA/vKIW2FNTavd8qE9Ujg+uuBJrLqwLqdy9mQSkQaTXUY+ggH2SEB SuMGPxfztnON5WMFWxZL3gAhe2VhJzZ7itV/28CgUl8quMAukZ+lbzsECXh+vvfc1Iss 7pcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KxJYMPHTSeqqqajYcptZcxO+883thpmVhqESNgcBe+0=; b=k3OyC39cznfpqPXcQCnDUtBhvhDGtWfjglhwA6aNUa0tPrgZoKvXne5cvA1L0DUV/G PBcuTzzgSRi2TdQ24VaW7zNVzmU+6Fj46rt7kwwlcnentnAIYq9q1Dc79AqnIYY8JW1t sR52zoEHb4yoMrGJ81u0e0m8zibR+GLT6TA8SAUXkAsRv9ClFlpyKWD0EFFoHQkUTW3X Td/jaBo77bdV+qzVkxzioYQ83yqVxd+loUKOlmrlpQ+A+NKAT2VtZj9yAxdOW7TMC93w wB/zUpZi5WDHtYSo5ndPzDoa00ox77kXW0cj/T5JOLsa1QhSEuKTavaxtBKgLy6C8p2u i9Uw== X-Gm-Message-State: AHQUAuYTrZ7HU3TnNE3sdpU2spbp3GadRSlgtLIud8Q4n/ytAcqPu+OC XgmEShqhRh7yCHU2/5Fwc3hBsdhA0DZUKvZQ0JA= X-Google-Smtp-Source: AHgI3IYFV4FWu/mky6UYUUBy8QtNIdLcPDk/71QIaFqSYSYamWSKjdkF4fphGcIV/iqvk8vuNh9R+BwSqi8TQYQjNIo= X-Received: by 2002:a2e:2285:: with SMTP id i127mr10195686lji.40.1550618250404; Tue, 19 Feb 2019 15:17:30 -0800 (PST) MIME-Version: 1.0 References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> In-Reply-To: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> From: Jana Iyengar Date: Tue, 19 Feb 2019 15:17:19 -0800 Message-ID: Subject: Re: QUIC ossification To: Roberto Peon Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="000000000000ff679905824771a0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 23:17:35 -0000 --000000000000ff679905824771a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Roberto -- yes, that's basically what I'm proposing too, just one variant of how to go about doing it dynamically over time. On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon wrote: > As others have intimated in some form or another, you can also use > multiple numbers to express =E2=80=9Cversion 1=E2=80=9D. > > > For instance, pick 64 (or some similar constant) random numbers, and call > them all version 1. > -=3DR > > > > *From: *QUIC on behalf of Jana Iyengar < > jri.ietf@gmail.com> > *Date: *Tuesday, February 19, 2019 at 3:10 PM > *To: *Martin Thomson > *Cc: *QUIC WG > *Subject: *Re: QUIC ossification > > > > On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson wrote: > > I don't think that there is much value in using two version numbers to > refer to the same protocol. But even if we did, as long as we didn't > establish any pattern in doing so, that couldn't be used against us. So = I > might tentatively agree that 0x1 =3D=3D 0x2 would be inadvisable, there i= s no > strong need to do anything special with the first version. Any attempt t= o > profile QUIC will be done with full knowledge of the version number we > pick, so randomness doesn't serve any real purpose. Subsequent versions > might need to use a randomized value, but we can make that decision then. > > > > I figured that making all version assignments random instead of > special-casing 0x1 made it simpler to reason about and uniform to code fo= r, > but I actually don't care about the IANA assignment for v1 for the reason > you note. v1 will be one specific bit-pattern on the wire to start of wit= h, > and that can just as well be 0x1. It still does segregate the space, but = we > can't do anything about it anyways - it'll be 0x1 or some other random > number getting special treatment. > > > > The problem of course being that as long as v1 remains, we might find > places that no other version does. The QUIC "magic number" will be > whatever we pick, and we can't prevent someone from fixating on that.. > We'll convince those people in the same way they will be convinced to ope= n > up UDP for QUIC version 1: by making a QUIC version 2 worth enabling. > > > > That was the entire point of having alternate and preferred versions to > 0x1. If we have downgrade protection in place, and if there are those who > try alternate version numbers for v1, that gives us what we need at the > endpoints. I believe that there would be interest at some major vendors t= o > do this at some endpoints. Presumably, we can convince Google to do > something, since it has been bit by mbox ossification in the past. I am > operating on the premise that we have buy in from a few major providers. > > > > IANA is for me a publication venue where these alternate versions are > published and other clients/servers interested in keeping the ecosystem > from ossifying can use these alternate versions as well. > > > > I completely get the don't segregate thing. But to - I think - Mikkel's > point about experimentation without permission, I do think that squatting > is a perfectly sound approach in a space this big. TLS people do it in a > much smaller space. As long squatters pick random values, they do so > infrequently, and they get IANA registrations for codepoints relatively > soon afterwards, the risk of collision is low. Randomness here is useful= - > but primarily as a collision-avoidance technique. The TLS extension > codepoint 26 is a great example of why. Keeping the bar on registrations > low (FCFS is a reasonable policy) would also have the effect of making th= e > pool of apparent versions larger, which might be more effective than any > other strategy we might employ. > > > > I'm totally fine with experimentation without permission, and using rando= m > to avoid collision. My point was entirely about using alternate on-wire > version numbers for v1. Nothing here about new or experimental versions. > > > --000000000000ff679905824771a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roberto -- yes, that's basically what I'm proposin= g too, just one variant of how to go about doing it dynamically over time.<= /div>
O= n Tue, Feb 19, 2019 at 3:14 PM Roberto Peon <fenix@fb.com> wrote:

As others have intimated in some form or another, yo= u can also use multiple numbers to express =E2=80=9Cversion 1=E2=80=9D.<= /u>


For instance, pick 64 (or some similar constant) random numbers, and call t= hem all version 1.
-=3DR

=C2=A0

From: = QUIC <quic-bounces@ietf.org>= ; on behalf of Jana Iyengar <jri.ietf@gmail.com>
Date: Tuesday, February 19, 2019 at 3:10 PM
To: Martin Thomson <mt@lowentropy.net>
Cc: QUIC WG <q= uic@ietf.org>
Subject: Re: QUIC ossification

=C2=A0

On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <<= a href=3D"mailto:mt@lowentropy.net" target=3D"_blank">mt@lowentropy.net= > wrote:=C2=A0

I don't think that there is much value in using = two version numbers to refer to the same protocol.=C2=A0 But even if we did= , as long as we didn't establish any pattern in doing so, that couldn&#= 39;t be used against us.=C2=A0 So I might tentatively agree that 0x1 =3D=3D 0x2 would be inadvisable, there is no strong need to do an= ything special with the first version.=C2=A0 Any attempt to profile QUIC wi= ll be done with full knowledge of the version number we pick, so randomness= doesn't serve any real purpose.=C2=A0 Subsequent versions might need to use a randomized value, but we can make that decisi= on then.

=C2=A0

I figured that making all version assignments random= instead of special-casing 0x1 made it simpler to reason about and uniform = to code for, but I actually don't care about the IANA assignment for v1= for the reason you note. v1 will be one specific bit-pattern on the wire to start of with, and that can just as we= ll be 0x1. It still does segregate the space, but we can't do anything = about it anyways - it'll be 0x1 or some other random number getting spe= cial treatment.

=C2=A0

The problem of course being that as long as v1 remai= ns, we might find places that no other version does.=C2=A0 The QUIC "m= agic number" will be whatever we pick, and we can't prevent someon= e from fixating on that..=C2=A0 We'll convince those people in the same way they will be convinced to open up UDP for QUIC version 1: = by making a QUIC version 2 worth enabling.

=C2=A0

That was the entire point of having alternate and pr= eferred versions to 0x1. If we have downgrade protection in place, and if t= here are those who try alternate version numbers for v1, that gives us what= we need at the endpoints. I believe that there would be interest at some major vendors to do this at some endp= oints. Presumably, we can convince Google to do something, since it has bee= n bit by mbox ossification in the past. I am operating on the premise that = we have buy in from a few major providers.

=C2=A0

IANA is for me a publication venue where these alter= nate versions are published and other clients/servers interested in keeping= the ecosystem from ossifying can use these alternate versions as well.<= /u>

=C2=A0

I completely get the don't segregate thing.=C2= =A0 But to - I think - Mikkel's point about experimentation without per= mission, I do think that squatting is a perfectly sound approach in a space= this big.=C2=A0 TLS people do it in a much smaller space.=C2=A0 As long squatters pick random values, they do so infrequently, and they ge= t IANA registrations for codepoints relatively soon afterwards, the risk of= collision is low.=C2=A0 Randomness here is useful - but primarily as a col= lision-avoidance technique.=C2=A0 The TLS extension codepoint 26 is a great example of why.=C2=A0 Keeping the bar on= registrations low (FCFS is a reasonable policy) would also have the effect= of making the pool of apparent versions larger, which might be more effect= ive than any other strategy we might employ.

=C2=A0

I'm totally fine with experimentation without pe= rmission, and using random to avoid collision. My point was entirely about = using alternate on-wire version numbers for v1. Nothing here about new or e= xperimental versions.

=C2=A0

--000000000000ff679905824771a0-- From nobody Tue Feb 19 17:05:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4665F130E25 for ; Tue, 19 Feb 2019 17:05:37 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Mu1Uxqb8wwhz for ; Tue, 19 Feb 2019 17:05:35 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790114.outbound.protection.outlook.com [40.107.79.114]) (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 23FEF128D0B for ; Tue, 19 Feb 2019 17:05:35 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=/LhgWvKuwjsPS4cPAo5/bfmbtkiniNcrTSdvW7xJ6MU=; b=bdsOZDoYZ8ct3+ORlAZ0+IMYne3LZKyDZ3X6v7KkjMwAx7uPwaAZEarv49O3FJ2yatW7Z2RGXk7X1hyuatO6Qn2PxHdjo6j/7/FKOAuU6De2DpdvPLCfLluFIyIEvydB9JMqh/b7qkwrvYuFB+zRQDhkrcf/yuZg3nr+h/pYqnc= Received: from MW2PR2101CA0024.namprd21.prod.outlook.com (2603:10b6:302:1::37) by MWHPR21MB0750.namprd21.prod.outlook.com (2603:10b6:300:76::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.4; Wed, 20 Feb 2019 01:05:33 +0000 Received: from BL2NAM06FT005.Eop-nam06.prod.protection.outlook.com (2a01:111:f400:7e55::201) by MW2PR2101CA0024.outlook.office365.com (2603:10b6:302:1::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1665.0 via Frontend Transport; Wed, 20 Feb 2019 01:05:33 +0000 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 157.58.196.101 as permitted sender) receiver=protection.outlook.com; client-ip=157.58.196.101; helo=mail.exchange.microsoft.com; Received: from mail.exchange.microsoft.com (157.58.196.101) by BL2NAM06FT005.mail.protection.outlook.com (10.152.106.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1679.0 via Frontend Transport; Wed, 20 Feb 2019 01:05:32 +0000 Received: from CYS-E16DFM04.exchange.corp.microsoft.com (10.221.226.71) by CYS-E16DFM02.exchange.corp.microsoft.com (10.221.226.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.2; Tue, 19 Feb 2019 17:05:31 -0800 Received: from CYS-E16DFM04.exchange.corp.microsoft.com ([fe80::79:73ff:fe2b:1f81]) by CYS-E16DFM04.exchange.corp.microsoft.com ([fe80::79:73ff:fe2b:1f81%17]) with mapi id 15.01.1713.002; Tue, 19 Feb 2019 17:05:31 -0800 From: Kenneth McMillan To: QUIC WG Subject: Unit test proposal Thread-Topic: Unit test proposal Thread-Index: AQHUyLDljBly2P/KJkCJ6nDqOPEc3A== Date: Wed, 20 Feb 2019 01:05:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.255.3] Content-Type: multipart/alternative; boundary="_000_e53f540dae3845659b99ea0c0626aebaCYSE16DFM04exchangecorp_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:157.58.196.101; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(136003)(346002)(376002)(39860400002)(396003)(2980300002)(189003)(199004)(10090500001)(68736007)(478600001)(7116003)(71190400001)(561944003)(26005)(336012)(8936002)(54896002)(3846002)(356004)(186003)(6916009)(16586007)(6116002)(14454004)(55016002)(5660300002)(2906002)(97736004)(316002)(106466001)(53936002)(22452003)(476003)(81156014)(102836004)(8676002)(126002)(86362001)(81166006)(7696005)(86612001)(10290500003)(486006)(7736002)(19627405001)(108616005)(24736004)(106002)(6346003)(84326002)(3480700005)(426003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0750; H:mail.exchange.microsoft.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 89819397-30f9-4790-828f-08d696cf83a5 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7193020); SRVR:MWHPR21MB0750; X-MS-TrafficTypeDiagnostic: MWHPR21MB0750: X-O365-Sonar-Daas-Pilot: True X-Microsoft-Exchange-Diagnostics: 1; MWHPR21MB0750; 20:dfrHUdlMjXdBEpbxb+/uBKoqDUJWhopbW3J7us4EH5SDiPmBIZIlNp5OQVD6CyNUOGaD8nEg5dwSi71jDvL1b41tWOtWiFfnU6aUSyoEMj8IOMy43VRHo5NDt29PbsbRVXRflp30zkShBlmyNiqyhHBweAkxIItA3UBNPvlWpAgpXIUzXiFlKw7cUAsSr3c7FDIREyq1Prjy0K69GqytMBsPWO9P7tha1L0Y0TeMOkESW70gLWxC+JrrPp/obLGe3GwOf9JMak5lsbdrZn+j41M5i3rwW9snBGOwmv93kAkUTUHVoSb+mA1/XNzwdl/jq5goh32fzfvqZx+0tzSlRV14xCsqdl+4xTwGuErPgjOGOljJzQylckNV352/6Yp+4iPXcIU2OFyZZYiXZmp7iYOsdpsrTE+q8bjywyCviy5P+XICBJ86vKqqonEhmuqspjy5Rs/m7f/oyzed+Z5AdM5/3qql/lDgZ2GM6ww5J9uJHdgbroz5pOMKRDEHLOS5 X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0954EE4910 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR21MB0750; 23:TzkIxu57gok+RguI0cYp4fb8KYt0T103OrCDDmQlO?= =?us-ascii?Q?4cAjggGH0k/qzvDHDg2EBl6ffpmy44F3M+KFKWnZyaAtZ/5B9vqUQbgCUMo/?= =?us-ascii?Q?qa94z7Z5U39uRFkAjY7IR+TkKHAr/Rusf009pU1Oyccq0gpWknhblepbfWVA?= =?us-ascii?Q?dvKGnnUrkRmm7q3BLfLNXIrj8ut0zRh0eG83SG4qR8t4tH5U9BAUcZ8JSLHY?= =?us-ascii?Q?XZCJd6cxacd0OfWa2RDwG8KU4Fwss20oSnyVQIgrTYk/M71wezLZlsz03ULv?= =?us-ascii?Q?0AB7OAq7axunk8H+w2rbu+pzMd06a3JM5eoyYt4R1ieznG1K16lHO+9gDxBV?= =?us-ascii?Q?w7yn0xxi9/SS62WHSn3hSc7dS+48UvIGf0w3vABVZPpx0P33gD8UeNbCHcNS?= =?us-ascii?Q?5t8y3LrIhsMI/oy8fr1BD+is01HaYbNz8/MT1qb8On1hAx9kIPts1/HcB6Lh?= =?us-ascii?Q?2EZep7uSbbkLQXKD4zopP7f/gEEnySfWFOWtD2VfYrXVKKVcuSLkaE1hv9tA?= =?us-ascii?Q?HVzKw0SZAoSfqnfAtxgFpqaMxevT07y3QZL8erN0F4upDQUZZdNSpGtDsei0?= =?us-ascii?Q?AIHu/LMAVywKVSC5D5KjPtkoz+sZc/BblyJzQtjwWOnWkDfcXVEyY7QcCC4z?= =?us-ascii?Q?AmfxHjpJN5Yma7n+gkZS4W908yKfLVqzoxi+SV8XgnCmXbJyxwWhl2QFcHJR?= =?us-ascii?Q?7cWMilkMSuWpDr8jYv/JgJaxLVMVVjkYFUMMFfrOOphWK5M0SyoNh75RiTWa?= =?us-ascii?Q?VvURvKWJW1oEWDpWTn2pEThSBmnggeadGw35g/GmKXiHlr2AfsYf/JxgSULe?= =?us-ascii?Q?IPHeMg4wBc8gnkf8us8HQ3lkt6hloOxemtRhtFfl0UDgkiRJytT4b9g+wsld?= =?us-ascii?Q?SRGysDj/J8gEntodgS0zNVkElZBlBfwoEsCiNjMSbcMqI5bHMTWGdWdgy8FA?= =?us-ascii?Q?6ZqNscWzwX8J6Dc/7/z3gAjqfrVpHTwzX0MVQiL0XPD0daCTxfUdRwkZZmVD?= =?us-ascii?Q?yuxj8BWAy5aF7awOolIeK2fzQSJMlAsq2kWl3Gdw3rdCduG9Gxmvq57wDPZQ?= =?us-ascii?Q?cj8tc2tKNm+G3H5p9An1A9nMwRQZQyEZRdxu9tWrR/dNAFnAbyfpHLMGAylq?= =?us-ascii?Q?+GuavC5kP9FvqAlaFoSJuOABJxYnivQUREO+o18VTtwQRWh9qyng8DSE2GI+?= =?us-ascii?Q?dXRISo9iVmBlO8B51n+15Fit9Ye1krf1MhFJIwm+PqELaAsSG7Z2d5mcmau7?= =?us-ascii?Q?vs80XqhPqHuJzNIE3llVqlTih3lJ5n4L2wyGCncemAyboAXFtxhYvxQzLvWv?= =?us-ascii?B?QT09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 44zIA597WOimU+QT0jwALvuzcCym0WuzoUF9qCyjaW3K4+hhlDv1BgL2ytcM5tfUCru9WEoKXJ94UrNfgI16MQFl8N6nv4gD+dFim+jIYwTKbS49Wp8amCa1Im8Cf1tl5YxLpoSgJCKL6P7BvIZhROSR9bKO7i8K+VuQu3Wra7mxv3vznENZrUI7ey2vEqY33gy5j5cBXnzoJ2BVtNaD8x5E1XV6ONYqguSgjSUdIOA46I6Ci4dRXF0TsOT0Hxd6Hgt8TjikWQ2Rneo12LzQ8rk8s9pO70aC/+++D0wfR94Yt6ec3TSOcT8vTvc5Xp9lYdcxmmA0pNZbBX4QVTtGDCjiup5HsIYVaLMuf4yZMXmbfGSh22KXye0+Bkw8DHsooBkcNaHn9Hm14/LylLwWi3XXeLLuN8YdJa1lfuTdWkk= X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2019 01:05:32.9534 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 89819397-30f9-4790-828f-08d696cf83a5 X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[157.58.196.101]; Helo=[mail.exchange.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0750 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 01:05:37 -0000 --_000_e53f540dae3845659b99ea0c0626aebaCYSE16DFM04exchangecorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a proposal to make regarding unit testing of QUIC implementations. I= would like to ask if there is any interest in the group and if anything al= ong these lines has been considered or is in the works. Currently I'm working on unit testing of QUIC implementations, but the effo= rt is somewhat hampered by the fact that they all have different API's. Tha= t is, they present different interfaces to applications, and also use diffe= rent system service API's. As a result, I can only test the implementations= through the network (since this interface is standardized). This means tha= t there are many behaviors that cannot be tested, since they can only stimu= lated through the implementation's client or system API's. What I would like to propose is a common unit test interface for QUIC. This= would be a value-based, language-independent API that provides QUIC servic= es to applications and system services to QUIC. This interface would have s= everal advantages: 1) Since it is generic, it would allow re-use of unit tests between impleme= ntations 2) Since it is value-based, it would allow logging and replay of runs 3) It could be made to support deterministic replay even for threaded imple= mentations, by simulating cooperative multitasking. 4) It could also be used in interoperability testing to provide local repla= y. In my experience, logging and replay of an interface is also enormously use= ful for bug reports, since there is no need even to build the user's applic= ation to diagnose the problem. The investment required would be that each implementation would need a wrap= per that presents the common unit test interface. My sense is that this eff= ort would be moderate, since QUIC's interface to applications is relatively= simple, and the implementations seem to require few system services (mainl= y file I/O, network I/O, locks, timers and random number generation). I thi= nk the advantages mentioned above would more than pay back this effort. I'm not thinking of this as an official standard. It would just be a de fac= to standard that would be used optionally by developers who want to take ad= vantage of a common base of unit tests. Please let me know if you think this seems worthwhile, or if it's redundant= with any existing work. Thanks -- Ken --_000_e53f540dae3845659b99ea0c0626aebaCYSE16DFM04exchangecorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have a proposal to make regarding unit testing of QUIC implementatio= ns. I would like to ask if there is any interest in the group an= d if anything along these lines has been considered or is in the works.

Currently I'm working on unit testing of QUIC implementations, but the= effort is somewhat hampered by the fact that they all have different API's= . That is, they present different interfaces to applications, and also use = different system service API's. As a result, I can only test the implementations through the network (sinc= e this interface is standardized). This means that there are many behaviors= that cannot be tested, since they can only stimulated through the implemen= tation's client or system API's.  

What I would like to propose is a common unit test interface for QUIC.= This would be a value-based, language-independent API that provides QUIC s= ervices to applications and system services to QUIC. This interface would h= ave several advantages:

1) Since it is generic, it would allow re-use of unit tests between im= plementations
2) Since it is value-based, it would allow logging and replay of runs<= /div>
3) It could be made to support deterministic replay even for threaded = implementations, by simulating cooperative multitasking.
4) It could also be used in interoperability testing to provide local = replay.

In my experience, logging and replay of an interface is also enormousl= y useful for bug reports, since there is no need even to build the user's a= pplication to diagnose the problem.

The investment required would be that each implementation would need a= wrapper that presents the common unit test interface. My sense is that thi= s effort would be moderate, since QUIC's interface to applications is relat= ively simple, and the implementations seem to require few system services (mainly file I/O, network I/O, locks, = timers and random number generation). I think the advantages mentioned abov= e would more than pay back this effort. 

I'm not thinking of this as an official standard. It would just be a d= e facto standard that would be used optionally by developers who want to ta= ke advantage of a common base of unit tests. 

Please let me know if you think this seems worthwhile, or if it's redu= ndant with any existing work. 


Thanks -- Ken






--_000_e53f540dae3845659b99ea0c0626aebaCYSE16DFM04exchangecorp_-- From nobody Tue Feb 19 22:59:32 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9B4131132 for ; Tue, 19 Feb 2019 22:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 vCrkTDLlwpt6 for ; Tue, 19 Feb 2019 22:59:16 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2801310A2 for ; Tue, 19 Feb 2019 22:58:55 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D1E0D341327; Wed, 20 Feb 2019 07:58:53 +0100 (CET) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/3959.14213); Wed, 20 Feb 2019 07:58:53 +0100 (CET) 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; Wed, 20 Feb 2019 07:58:53 +0100 (CET) Received: from [213.55.211.21] (account ietf@trammell.ch HELO [172.20.10.2]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.2.12) with ESMTPSA id 83747163; Wed, 20 Feb 2019 07:58:53 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: QUIC ossification From: "Brian Trammell (IETF)" In-Reply-To: Date: Wed, 20 Feb 2019 07:58:53 +0100 Cc: Roberto Peon , QUIC WG , Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 06:59:23 -0000 hi Jana, The middlebox adaptation model that this proposal addresses seems = limited to middleboxes built based on naive traffic analysis and = pre-QUIC assumptions about wire images. This is admittedly the model = behind one of Google's experiences with QUIC middlebox breakage, and the = one we seem most concerned with because by definition we cannot fix it = by writing things in documents. > On 20 Feb 2019, at 00:17, Jana Iyengar wrote: >=20 > Roberto -- yes, that's basically what I'm proposing too, just one = variant of how to go about doing it dynamically over time. >=20 > On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon wrote: > As others have intimated in some form or another, you can also use = multiple numbers to express =E2=80=9Cversion 1=E2=80=9D. >=20 >=20 > For instance, pick 64 (or some similar constant) random numbers, and = call them all version 1. > -=3DR >=20 > =20 >=20 > From: QUIC on behalf of Jana Iyengar = > Date: Tuesday, February 19, 2019 at 3:10 PM > To: Martin Thomson > Cc: QUIC WG > Subject: Re: QUIC ossification >=20 > =20 >=20 > On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson = wrote:=20 >=20 > I don't think that there is much value in using two version numbers to = refer to the same protocol. But even if we did, as long as we didn't = establish any pattern in doing so, that couldn't be used against us. So = I might tentatively agree that 0x1 =3D=3D 0x2 would be inadvisable, = there is no strong need to do anything special with the first version. = Any attempt to profile QUIC will be done with full knowledge of the = version number we pick, so randomness doesn't serve any real purpose. = Subsequent versions might need to use a randomized value, but we can = make that decision then. >=20 > =20 >=20 > I figured that making all version assignments random instead of = special-casing 0x1 made it simpler to reason about and uniform to code = for, but I actually don't care about the IANA assignment for v1 for the = reason you note. v1 will be one specific bit-pattern on the wire to = start of with, and that can just as well be 0x1. It still does segregate = the space, but we can't do anything about it anyways - it'll be 0x1 or = some other random number getting special treatment. >=20 > =20 >=20 > The problem of course being that as long as v1 remains, we might find = places that no other version does. The QUIC "magic number" will be = whatever we pick, and we can't prevent someone from fixating on that.. = We'll convince those people in the same way they will be convinced to = open up UDP for QUIC version 1: by making a QUIC version 2 worth = enabling. >=20 > =20 >=20 > That was the entire point of having alternate and preferred versions = to 0x1. If we have downgrade protection in place, and if there are those = who try alternate version numbers for v1, that gives us what we need at = the endpoints. I believe that there would be interest at some major = vendors to do this at some endpoints. Presumably, we can convince Google = to do something, since it has been bit by mbox ossification in the past. = I am operating on the premise that we have buy in from a few major = providers. >=20 > =20 >=20 > IANA is for me a publication venue where these alternate versions are = published and other clients/servers interested in keeping the ecosystem = from ossifying can use these alternate versions as well. >=20 > =20 >=20 > I completely get the don't segregate thing. But to - I think - = Mikkel's point about experimentation without permission, I do think that = squatting is a perfectly sound approach in a space this big. TLS people = do it in a much smaller space. As long squatters pick random values, = they do so infrequently, and they get IANA registrations for codepoints = relatively soon afterwards, the risk of collision is low. Randomness = here is useful - but primarily as a collision-avoidance technique. The = TLS extension codepoint 26 is a great example of why. Keeping the bar = on registrations low (FCFS is a reasonable policy) would also have the = effect of making the pool of apparent versions larger, which might be = more effective than any other strategy we might employ. >=20 > =20 >=20 > I'm totally fine with experimentation without permission, and using = random to avoid collision. My point was entirely about using alternate = on-wire version numbers for v1. Nothing here about new or experimental = versions. >=20 > =20 >=20 From nobody Tue Feb 19 23:03:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2D7130E0A for ; Tue, 19 Feb 2019 23:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 DdGWqSfGrO1D for ; Tue, 19 Feb 2019 23:03:49 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774B8127287 for ; Tue, 19 Feb 2019 23:03:49 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 02B6F34131A; Wed, 20 Feb 2019 08:03:48 +0100 (CET) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/3959.15864); Wed, 20 Feb 2019 08:03:47 +0100 (CET) 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; Wed, 20 Feb 2019 08:03:47 +0100 (CET) Received: from [213.55.211.21] (account ietf@trammell.ch HELO [172.20.10.2]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.2.12) with ESMTPSA id 83748027; Wed, 20 Feb 2019 08:03:47 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: QUIC ossification From: "Brian Trammell (IETF)" In-Reply-To: <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> Date: Wed, 20 Feb 2019 08:03:46 +0100 Cc: Roberto Peon , QUIC WG , Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> To: Jana Iyengar X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 07:03:52 -0000 (oops, hit send too soon...) > On 20 Feb 2019, at 07:58, Brian Trammell (IETF) = wrote: >=20 > hi Jana, >=20 > The middlebox adaptation model that this proposal addresses seems = limited to middleboxes built based on naive traffic analysis and = pre-QUIC assumptions about wire images. This is admittedly the model = behind one of Google's experiences with QUIC middlebox breakage, and the = one we seem most concerned with because by definition we cannot fix it = by writing things in documents. I don't think these are the only things we're concerned about though. = Concerns about partitioning VN space have a less naive model in mind: = here we think more about default-deny firewalls that have been told that = some versions of QUIC are okay but all others are not. As noted before I = personally cannot think of a reason an operator would want to do this -- = if you've already decided to allow a protocol with low observability and = built-in extensibility as a design goal on your network, does the exact = flavor really matter all that much? -- but it's a checkbox on the = firewall feature list so yeah, I suppose someone will ship it. Are there other middlebox adaptation models we are concerned about here? Cheers, Brian >> On 20 Feb 2019, at 00:17, Jana Iyengar wrote: >>=20 >> Roberto -- yes, that's basically what I'm proposing too, just one = variant of how to go about doing it dynamically over time. >>=20 >> On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon wrote: >> As others have intimated in some form or another, you can also use = multiple numbers to express =E2=80=9Cversion 1=E2=80=9D. >>=20 >>=20 >> For instance, pick 64 (or some similar constant) random numbers, and = call them all version 1. >> -=3DR >>=20 >>=20 >>=20 >> From: QUIC on behalf of Jana Iyengar = >> Date: Tuesday, February 19, 2019 at 3:10 PM >> To: Martin Thomson >> Cc: QUIC WG >> Subject: Re: QUIC ossification >>=20 >>=20 >>=20 >> On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson = wrote:=20 >>=20 >> I don't think that there is much value in using two version numbers = to refer to the same protocol. But even if we did, as long as we didn't = establish any pattern in doing so, that couldn't be used against us. So = I might tentatively agree that 0x1 =3D=3D 0x2 would be inadvisable, = there is no strong need to do anything special with the first version. = Any attempt to profile QUIC will be done with full knowledge of the = version number we pick, so randomness doesn't serve any real purpose. = Subsequent versions might need to use a randomized value, but we can = make that decision then. >>=20 >>=20 >>=20 >> I figured that making all version assignments random instead of = special-casing 0x1 made it simpler to reason about and uniform to code = for, but I actually don't care about the IANA assignment for v1 for the = reason you note. v1 will be one specific bit-pattern on the wire to = start of with, and that can just as well be 0x1. It still does segregate = the space, but we can't do anything about it anyways - it'll be 0x1 or = some other random number getting special treatment. >>=20 >>=20 >>=20 >> The problem of course being that as long as v1 remains, we might find = places that no other version does. The QUIC "magic number" will be = whatever we pick, and we can't prevent someone from fixating on that.. = We'll convince those people in the same way they will be convinced to = open up UDP for QUIC version 1: by making a QUIC version 2 worth = enabling. >>=20 >>=20 >>=20 >> That was the entire point of having alternate and preferred versions = to 0x1. If we have downgrade protection in place, and if there are those = who try alternate version numbers for v1, that gives us what we need at = the endpoints. I believe that there would be interest at some major = vendors to do this at some endpoints. Presumably, we can convince Google = to do something, since it has been bit by mbox ossification in the past. = I am operating on the premise that we have buy in from a few major = providers. >>=20 >>=20 >>=20 >> IANA is for me a publication venue where these alternate versions are = published and other clients/servers interested in keeping the ecosystem = from ossifying can use these alternate versions as well. >>=20 >>=20 >>=20 >> I completely get the don't segregate thing. But to - I think - = Mikkel's point about experimentation without permission, I do think that = squatting is a perfectly sound approach in a space this big. TLS people = do it in a much smaller space. As long squatters pick random values, = they do so infrequently, and they get IANA registrations for codepoints = relatively soon afterwards, the risk of collision is low. Randomness = here is useful - but primarily as a collision-avoidance technique. The = TLS extension codepoint 26 is a great example of why. Keeping the bar = on registrations low (FCFS is a reasonable policy) would also have the = effect of making the pool of apparent versions larger, which might be = more effective than any other strategy we might employ. >>=20 >>=20 >>=20 >> I'm totally fine with experimentation without permission, and using = random to avoid collision. My point was entirely about using alternate = on-wire version numbers for v1. Nothing here about new or experimental = versions. >>=20 >>=20 >>=20 >=20 From nobody Wed Feb 20 05:34:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706401286E7 for ; Wed, 20 Feb 2019 05:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k35xjcFhqkr for ; Wed, 20 Feb 2019 05:34:32 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 B6B6A124408 for ; Wed, 20 Feb 2019 05:34:31 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id r5so12621698wrg.9 for ; Wed, 20 Feb 2019 05:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VAKrr0fGAiCTO4ik8HPLiPbuQ1MElRv2Gq/dJs0giLQ=; b=ohh3+HSdWglBNO1MhgjTCnls1ieeyy0pg9MfxkR6MBubLlY/gD0tQMocdEn1QJ6FiC FyUPQw51n20y8nX3kF6KsA5VGDusCaB+acZwCIvGVtt5qZbGq/QjP7tUqgaE/dGS15UT A05q8dFwBiLVkm8Lk8hcmQ0PWFsoom6i+L4b//4+LOqPJwwURI30fsnELYMEExe9XxMH raN2xlU54+X0ES3Sq6bSU/GIfsN8wyafQJnH+2Bw8qJPFe2E8HjIJZC91GG6vB8nzyUC YigQyvg8wFuYE63qOIYVUrgwGoEMjtF+8nRbzuryzqGLtZ854Bv+A1h5xc36Esa1QCg7 iKnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VAKrr0fGAiCTO4ik8HPLiPbuQ1MElRv2Gq/dJs0giLQ=; b=cABN/mri27ivmGqToeW+U6qQVm8Radof4AclascXxrJr9BFbruSU6ZI4gS731Y7fhd YwxRdsrashK2jQEEL3N7kmyffiKiFwLt20qZffE19H1afOraRweeen0M1WEbSqTFFKiD G1egOnGh8Ylv4dfzPQpLJ4pqi8ZSFW192IvFS5iTjore++hPzE2yaaQ09n46MrXjDvxQ XaI0L7wluMPmuGuRvXCengAB27DggmCI74P+bQqwuZEjFESmejY3J2JhgBJtsHjS3KLQ 4ICCWytp2Eft2KVNAzic1m4WqXehygCfO7y3NjSepdmYGKTp3e8eBr656qHMZRmibWyO cGmA== X-Gm-Message-State: AHQUAubaQoZCj1r9myTJe+8kN7/z5t+0Nd405pGTfjaRMy+P9qT1VfJO 3Onn21HlUN8YVjkeKs7Obn3YFOsSI3anbsuPsqs7924e3AU+/Q== X-Google-Smtp-Source: AHgI3IaHq8YB1o1WiIqWRwkZnR0KAG06uvzTErWZN7yosoPUgBy7w5InsS0cbMvceFGacRN1eltrM9f/O26RGClP2MM= X-Received: by 2002:adf:eb84:: with SMTP id t4mr11403832wrn.100.1550669669804; Wed, 20 Feb 2019 05:34:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 20 Feb 2019 08:34:17 -0500 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Nick Banks Cc: IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary="000000000000d5b89e0582536a12" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 13:34:35 -0000 --000000000000d5b89e0582536a12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For HTTP/3, my intent was to close the connection immediately with a connection close as you suggest, then the client would fall back to TCP, and then ensure the next Alt-Svc advertisement via TCP cleared any existing Alt-Svc entry so QUIC wasn't tried again in the immediate future. I hadn't thought of assigning semantics to a specific error code, but I'm reluctant to do so. In our case, I think a more likely error code would indicate the infrastructure doesn't support QUIC, rather than DDoS, but the desired behavior of falling back to TCP and not attempting QUIC for a while is the same. The assumption I made above is that the client immediately falls back to TCP. That of course depends upon the type of client it is. I'd expect a browser to fall back, but I wouldn't expect curl or wget to. There is a decent amount of text on fallback in the Applicability draft: https://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicabil= ity.md On Tue, Feb 19, 2019 at 5:11 PM Nick Banks wrote: > Hello Folks, > > > > I=E2=80=99ve been looking at interim DDoS mitigation strategies for QUIC = until we > can have a more complete and QUIC aware DDoS and LB solution. One thing I > came up with is just trying to force the client to fallback to TCP. > Eventually, we will use Stateless Retry but that still requires a good bi= t > of design work and cooperation between the offload device and the backend > server. Until that is complete, a simple solution could be a device in pa= th > just responding to new QUIC connection attempts (while an attack is in > progress) with a connection close frame containing the SERVER_BUSY error. > The logic to implement a simple device to do that should be quite trivial= . > > > > To that end, I was trying to figure out what the expected client response > to any immediate (in the first RTT) connection close packets/frames would > be and it seems we don=E2=80=99t have anything in the spec. What about SE= RVER_BUSY > specifically? Is the client supposed to retry a new connection attempt? > Should they fallback to TCP immediately? Should we say anything in the sp= ec? > > > > Thanks, > > - Nick > --000000000000d5b89e0582536a12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For HTTP/3, my intent was to close the connection immediat= ely with a connection close as you suggest, then the client would fall back= to TCP, and then ensure the next Alt-Svc advertisement via TCP cleared any= existing Alt-Svc entry so QUIC wasn't tried again in the immediate fut= ure.

I hadn't thought of assigning semantics to a sp= ecific error code, but I'm reluctant to do so.=C2=A0 In our case, I thi= nk a more likely error code would indicate the infrastructure doesn't s= upport QUIC, rather than DDoS, but the desired behavior of falling back to = TCP and not attempting QUIC for a while is the same.

The assumption I made above is that the client immediately falls back to= TCP.=C2=A0 That of course depends upon the type of client it is.=C2=A0 I&#= 39;d expect a browser to fall back, but I wouldn't expect curl or wget = to.

There is a decent amount of text on fallback i= n the Applicability draft:=C2=A0https://github.com/quicw= g/ops-drafts/blob/master/draft-ietf-quic-applicability.md



On Tue, Feb 19, 2019 at 5:11 PM Nick Banks= <nibanks=3D40microsof= t.com@dmarc.ietf.org> wrote:

Hello Folks,

=C2=A0

I=E2=80=99ve been looking at interim DDoS mitigation= strategies for QUIC until we can have a more complete and QUIC aware DDoS = and LB solution. One thing I came up with is just trying to force the clien= t to fallback to TCP. Eventually, we will use Stateless Retry but that still requires a good bit of design work and = cooperation between the offload device and the backend server. Until that i= s complete, a simple solution could be a device in path just responding to = new QUIC connection attempts (while an attack is in progress) with a connection close frame containing the SER= VER_BUSY error. The logic to implement a simple device to do that should be= quite trivial.

=C2=A0

To that end, I was trying to figure out what the exp= ected client response to any immediate (in the first RTT) connection close = packets/frames would be and it seems we don=E2=80=99t have anything in the = spec. What about SERVER_BUSY specifically? Is the client supposed to retry a new connection attempt? Should they fall= back to TCP immediately? Should we say anything in the spec?<= /p>

=C2=A0

Thanks,

- Nick

--000000000000d5b89e0582536a12-- From nobody Wed Feb 20 05:52:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF612E036 for ; Wed, 20 Feb 2019 05:52:04 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctPjltC7zQRy for ; Wed, 20 Feb 2019 05:52:02 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F301286E7 for ; Wed, 20 Feb 2019 05:52:02 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 89496340FE0; Wed, 20 Feb 2019 14:52:00 +0100 (CET) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/3959.13903); Wed, 20 Feb 2019 14:51:58 +0100 (CET) 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; Wed, 20 Feb 2019 14:51:58 +0100 (CET) Received: from [213.55.211.40] (account ietf@trammell.ch HELO [10.154.66.82]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.2.12) with ESMTPSA id 83804259; Wed, 20 Feb 2019 14:51:57 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-55A4A5DA-F609-496C-9789-9D787FCE667C Mime-Version: 1.0 (1.0) Subject: Re: Expected Client Response to SERVER_BUSY From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Wed, 20 Feb 2019 14:51:56 +0100 Cc: Nick Banks , IETF QUIC WG , =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Transfer-Encoding: 7bit Message-Id: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> References: To: Ian Swett Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 13:52:05 -0000 --Apple-Mail-55A4A5DA-F609-496C-9789-9D787FCE667C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable hi Ian, Sent from my iPhone > On 20 Feb 2019, at 14:34, Ian Swett wrote: >=20 > For HTTP/3, my intent was to close the connection immediately with a conne= ction close as you suggest, then the client would fall back to TCP, and then= ensure the next Alt-Svc advertisement via TCP cleared any existing Alt-Svc e= ntry so QUIC wasn't tried again in the immediate future. >=20 > I hadn't thought of assigning semantics to a specific error code, but I'm r= eluctant to do so. In our case, I think a more likely error code would indi= cate the infrastructure doesn't support QUIC, rather than DDoS, but the desi= red behavior of falling back to TCP and not attempting QUIC for a while is t= he same. >=20 > The assumption I made above is that the client immediately falls back to T= CP. That of course depends upon the type of client it is. I'd expect a bro= wser to fall back, but I wouldn't expect curl or wget to. This is a bit of an aside, but I=E2=80=99m curious here: why not? I=E2=80=99= ve always thought of the semantics of TCP fallback as equivalent to a 3xx re= direct (either temporary or permanent, depending on the client heuristics wr= t the underlying reason for the redirect). curl won=E2=80=99t do this automa= gically unless you tell it to, but iirc wget will... Am I wrong in thinking that most clients will see this as YA form of redirec= t? Cheers, =20 Brian > There is a decent amount of text on fallback in the Applicability draft: h= ttps://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicabilit= y.md >=20 >=20 >=20 >> On Tue, Feb 19, 2019 at 5:11 PM Nick Banks wrote: >> Hello Folks, >>=20 >> =20 >>=20 >> I=E2=80=99ve been looking at interim DDoS mitigation strategies for QUIC u= ntil we can have a more complete and QUIC aware DDoS and LB solution. One th= ing I came up with is just trying to force the client to fallback to TCP. Ev= entually, we will use Stateless Retry but that still requires a good bit of d= esign work and cooperation between the offload device and the backend server= . Until that is complete, a simple solution could be a device in path just r= esponding to new QUIC connection attempts (while an attack is in progress) w= ith a connection close frame containing the SERVER_BUSY error. The logic to i= mplement a simple device to do that should be quite trivial. >>=20 >> =20 >>=20 >> To that end, I was trying to figure out what the expected client response= to any immediate (in the first RTT) connection close packets/frames would b= e and it seems we don=E2=80=99t have anything in the spec. What about SERVER= _BUSY specifically? Is the client supposed to retry a new connection attempt= ? Should they fallback to TCP immediately? Should we say anything in the spe= c? >>=20 >> =20 >>=20 >> Thanks, >>=20 >> - Nick --Apple-Mail-55A4A5DA-F609-496C-9789-9D787FCE667C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable hi Ian,

Sent from my iPhone

On 20 Feb 2019,= at 14:34, Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:

For HTTP/3, my int= ent was to close the connection immediately with a connection close as you s= uggest, then the client would fall back to TCP, and then ensure the next Alt= -Svc advertisement via TCP cleared any existing Alt-Svc entry so QUIC wasn't= tried again in the immediate future.

I hadn't thought of= assigning semantics to a specific error code, but I'm reluctant to do so.&n= bsp; In our case, I think a more likely error code would indicate the infras= tructure doesn't support QUIC, rather than DDoS, but the desired behavior of= falling back to TCP and not attempting QUIC for a while is the same.
<= div>
The assumption I made above is that the client immediatel= y falls back to TCP.  That of course depends upon the type of client it= is.  I'd expect a browser to fall back, but I wouldn't expect curl or w= get to.

This is a bit of a= n aside, but I=E2=80=99m curious here: why not? I=E2=80=99ve always thought o= f the semantics of TCP fallback as equivalent to a 3xx redirect (either temp= orary or permanent, depending on the client heuristics wrt the underlying re= ason for the redirect). curl won=E2=80=99t do this automagically unless you t= ell it to, but iirc wget will...

Am I wrong in thin= king that most clients will see this as YA form of redirect?

<= /div>
Cheers,  

Brian

There is a decent amou= nt of text on fallback in the Applicability draft: ht= tps://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicability= .md



On Tue, Feb 19, 2019 at 5= :11 PM Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org> wrote:

Hello Folks,

 

I=E2=80=99ve been looking at interim DDoS mitigation s= trategies for QUIC until we can have a more complete and QUIC aware DDoS and= LB solution. One thing I came up with is just trying to force the client to= fallback to TCP. Eventually, we will use Stateless Retry but that still requires a good bit of design work and c= ooperation between the offload device and the backend server. Until that is c= omplete, a simple solution could be a device in path just responding to new Q= UIC connection attempts (while an attack is in progress) with a connection close frame containing the SERV= ER_BUSY error. The logic to implement a simple device to do that should be q= uite trivial.

 

To that end, I was trying to figure out what the expe= cted client response to any immediate (in the first RTT) connection close pa= ckets/frames would be and it seems we don=E2=80=99t have anything in the spe= c. What about SERVER_BUSY specifically? Is the client supposed to retry a new connection attempt? Should they fallb= ack to TCP immediately? Should we say anything in the spec?

 

Thanks,

- Nick

= --Apple-Mail-55A4A5DA-F609-496C-9789-9D787FCE667C-- From nobody Wed Feb 20 06:42:03 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53AA130E09 for ; Wed, 20 Feb 2019 06:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSb_y1Vp5ly9 for ; Wed, 20 Feb 2019 06:41:59 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 2FC78127AC2 for ; Wed, 20 Feb 2019 06:41:59 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id x10so6647033wmg.2 for ; Wed, 20 Feb 2019 06:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9PfG2AI8RheDos3yeJM2X+UDZ8ngBTuWWtzqskmSNJ0=; b=N1lLzW+sXAqoTAF83q07SU3iApCbWUF36KvNJW+h0bzk9W+p2zkmPh+7ptUW0D1HHy RDeSv/60EaVGENvhWnZMu/ishLwnBL1T554V7lJvanG+wGj5M6oxwckKuu/8Xqd/wkmE rB6SEbePW/yB0XMhJ+cNGuvM9hh4oy5rlnk1ChqmrCizTU6orD+L3U/H2Eduf/HvpDsa uzRfiKfi5yZGZrbN36Q86+yXqmGPILnxxP+cKahhBsIaKvZ5uK1zs56QGjKIE2x0n8YY doXJmILFR/0AtJ53Ao6EtswaHA6EXVP4XXYduR1X4/re3iDxsF2/WcS6lU2YAf6Gk/Wz OkTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9PfG2AI8RheDos3yeJM2X+UDZ8ngBTuWWtzqskmSNJ0=; b=pKNw3GKC4aYT65ELEn8gZkv/FpsB69Gx51yHdG4thayGjylmkgKUOYZcD+L7Ha7y4F 1s7rkdDmdWZ4vPQLq8ZUQ3CvIwe2TzZDtZh2X7MAJvuygn6Js6s4SvzK/Jg77QU89s6/ MWIpm77U6eQe0FdEDykT2HxHdQVhj36ymHlimVT2rg3EYVAc7+0q9vNul0vGCW2HJMEO STkss4n6IutiC1oTmLbn+mKkr/jPJ3kfkQ2A5NlVQjh03zoLepX4wuvrx8cJPxyPlN0k MUoihkWJ7j+BAhTGWT0k/jekv/KgeBYySuEDqCSLJ6xEU8ZwxxOQ0Um4Euq3NDUwMQbf PjpQ== X-Gm-Message-State: AHQUAubYZKtp9EPW0XpXEWpDb2U3E2TzCrUAhOWJYj7f8Qk3EiA6JUc+ 7aL6hbIMtB+JMr5OQK8bDVtlbZxUxUKeyFkul0EE4g== X-Google-Smtp-Source: AHgI3IaKwjvscMENBqK5T8dDQU32Bf821RP2saciMqErZkSRFI/mSGOJt8VpDsIcK+/7hfIcdIxkX3wpzV+HKuZBcGU= X-Received: by 2002:a1c:6789:: with SMTP id b131mr6881905wmc.22.1550673717274; Wed, 20 Feb 2019 06:41:57 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> From: Ian Swett Date: Wed, 20 Feb 2019 09:41:40 -0500 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: "Brian Trammell (IETF)" Cc: Nick Banks , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary="0000000000001539f00582545c15" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 14:42:02 -0000 --0000000000001539f00582545c15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If a client follows 3xx redirects by default, then it seems sensible it'd fall back to TCP automatically, but I'm not sure an immediate QUIC connection close is equivalent to a redirect. I can also imagine clients that don't follow redirects by default falling back to TCP, so I think I just chose a poor example. On Wed, Feb 20, 2019 at 8:52 AM Brian Trammell (IETF) wrote: > hi Ian, > > Sent from my iPhone > > On 20 Feb 2019, at 14:34, Ian Swett > wrote: > > For HTTP/3, my intent was to close the connection immediately with a > connection close as you suggest, then the client would fall back to TCP, > and then ensure the next Alt-Svc advertisement via TCP cleared any existi= ng > Alt-Svc entry so QUIC wasn't tried again in the immediate future. > > I hadn't thought of assigning semantics to a specific error code, but I'm > reluctant to do so. In our case, I think a more likely error code would > indicate the infrastructure doesn't support QUIC, rather than DDoS, but t= he > desired behavior of falling back to TCP and not attempting QUIC for a whi= le > is the same. > > The assumption I made above is that the client immediately falls back to > TCP. That of course depends upon the type of client it is. I'd expect a > browser to fall back, but I wouldn't expect curl or wget to. > > > This is a bit of an aside, but I=E2=80=99m curious here: why not? I=E2=80= =99ve always > thought of the semantics of TCP fallback as equivalent to a 3xx redirect > (either temporary or permanent, depending on the client heuristics wrt th= e > underlying reason for the redirect). curl won=E2=80=99t do this automagic= ally > unless you tell it to, but iirc wget will... > > Am I wrong in thinking that most clients will see this as YA form of > redirect? > > Cheers, > > Brian > > There is a decent amount of text on fallback in the Applicability draft: > https://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicab= ility..md > > > > > On Tue, Feb 19, 2019 at 5:11 PM Nick Banks 40microsoft.com@dmarc.ietf.org <40microsoft.com@dmarc.ietf..org>> wrote: > >> Hello Folks, >> >> >> >> I=E2=80=99ve been looking at interim DDoS mitigation strategies for QUIC= until we >> can have a more complete and QUIC aware DDoS and LB solution. One thing = I >> came up with is just trying to force the client to fallback to TCP. >> Eventually, we will use Stateless Retry but that still requires a good b= it >> of design work and cooperation between the offload device and the backen= d >> server. Until that is complete, a simple solution could be a device in p= ath >> just responding to new QUIC connection attempts (while an attack is in >> progress) with a connection close frame containing the SERVER_BUSY error= . >> The logic to implement a simple device to do that should be quite trivia= l. >> >> >> >> To that end, I was trying to figure out what the expected client respons= e >> to any immediate (in the first RTT) connection close packets/frames woul= d >> be and it seems we don=E2=80=99t have anything in the spec. What about S= ERVER_BUSY >> specifically? Is the client supposed to retry a new connection attempt? >> Should they fallback to TCP immediately? Should we say anything in the s= pec? >> >> >> >> Thanks, >> >> - Nick >> > --0000000000001539f00582545c15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If a client follows 3xx redirects by default, then it seem= s sensible it'd fall back to TCP automatically, but I'm not sure an= immediate QUIC connection close is equivalent to a redirect.=C2=A0 I can a= lso imagine clients that don't follow redirects by default falling back= to TCP, so I think I just chose a poor example.


On Wed, Feb = 20, 2019 at 8:52 AM Brian Trammell (IETF) <ietf@trammell.ch> wrote:
hi Ian,

<= div id=3D"gmail-m_-4754392925361203797gmail-m_-1270953616528307938AppleMail= Signature" dir=3D"ltr">Sent from my iPhone

On 20 = Feb 2019, at 14:34, Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:





<= /div>
Cheers, =C2=A0

Brian




On Tue, Feb 19, 2019 at 5:11 PM Nick Banks <nibanks=3D40microsoft.com@dmarc= .ietf.org> wrote:

Hello Folks,

=C2=A0

I=E2=80=99ve been looking at interim DDoS mitigation= strategies for QUIC until we can have a more complete and QUIC aware DDoS = and LB solution. One thing I came up with is just trying to force the clien= t to fallback to TCP. Eventually, we will use Stateless Retry but that still requires a good bit of design work and = cooperation between the offload device and the backend server. Until that i= s complete, a simple solution could be a device in path just responding to = new QUIC connection attempts (while an attack is in progress) with a connection close frame containing the SER= VER_BUSY error. The logic to implement a simple device to do that should be= quite trivial.

=C2=A0

To that end, I was trying to figure out what the exp= ected client response to any immediate (in the first RTT) connection close = packets/frames would be and it seems we don=E2=80=99t have anything in the = spec. What about SERVER_BUSY specifically? Is the client supposed to retry a new connection attempt? Should they fall= back to TCP immediately? Should we say anything in the spec?<= /p>

=C2=A0

Thanks,

- Nick

--0000000000001539f00582545c15-- From nobody Wed Feb 20 06:49:51 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3C129741 for ; Wed, 20 Feb 2019 06:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, SPF_PASS=-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 3LCcxiVi_Jcg for ; Wed, 20 Feb 2019 06:49:45 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750104.outbound.protection.outlook.com [40.107.75.104]) (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 7D453127AC2 for ; Wed, 20 Feb 2019 06:49:45 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=dPu8j4PVqfDcjUbicCzP4jfzZdyaO6+gUh5EH7xym6A=; b=cWPu82iRHRkveNMUBzrHCUnvxS198TCiqzjC1QI6QeXip1l6c30cTCL/5qFQyNxCn56k/AtObqLmB80gI4pcRS2NXbiQWkUBJ6tjzwAufE5cjqdb9l3hc4o+MXXUpoBDNHo8AQuIZ783tSNnvUR2KNwT3Y9j8/3cqkO8lgUZa2Y= Received: from CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) by CY4PR21MB0694.namprd21.prod.outlook.com (10.175.121.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.2; Wed, 20 Feb 2019 14:49:43 +0000 Received: from CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46]) by CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46%3]) with mapi id 15.20.1665.002; Wed, 20 Feb 2019 14:49:42 +0000 From: Nick Banks To: Ian Swett , "Brian Trammell (IETF)" CC: IETF QUIC WG , =?Windows-1252?Q?Mirja_K=FChlewind?= Subject: RE: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: AdTInrfRZAbJSsLZSlWCCrlUkiWX7AAgkIeAAACdzgAAAbynAAAAN6co Date: Wed, 20 Feb 2019 14:49:42 +0000 Message-ID: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [167.220.2.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3aeefaef-b7ae-459e-6f8a-08d69742a617 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR21MB0694; x-ms-traffictypediagnostic: CY4PR21MB0694: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; CY4PR21MB0694; 23:+O/j8VDCnvTKDS/2wfPsGkI+GbyPRQ/M2zVYJ?= =?Windows-1252?Q?ZUeR2+lGYqGL1OihCu+BzS5EWImV3BxuqGxwzxY7WBOgFZmCBe3sCGr1?= =?Windows-1252?Q?+GL2rtqd/9/JW3FsYNPPinKKaiK1Zbg38TblpK6S9XBdfgdI+fy5GCKW?= =?Windows-1252?Q?SM9Dg/3gU4UTZ5QhWMmHGZn1jf8xIj5/gVy6dvNnj5GnYfis+g8lYuFT?= =?Windows-1252?Q?Aln3g0JcwZqzQH+qo6xtCpTss4SKgI1+Y+rjN4W9pGepfnNNH2f7wjbI?= =?Windows-1252?Q?U+KbCvK7h+/49HkgeQA9ZRctZ895/01k1YymQ0rlY+ELuEexMaCcu00w?= =?Windows-1252?Q?3W1v0DxC7FJL00cW0JpFl0aI7tH7I2f5gZIESOJuL29WOSNfws3Lm5wT?= =?Windows-1252?Q?e1Y6+DxWWCi4HVo9h3SatBd5rymw4v1pOPO7P2WUr2l5QLEU7xsWAaIv?= =?Windows-1252?Q?tIbFevGprXDigWskGWBACZVXpCT0sGZ0pzPSQ2Lu0SKzSe0fWMwJcC1U?= =?Windows-1252?Q?IkYhs3oA3nWnMoEJ19OeBwUd5HBKnum8qcXThAd5cVtQbK/4YC7lCjVi?= =?Windows-1252?Q?PIIkcWeee4BPmBh2/caDO974hfGWHdlU7Z2eBiXWwrjuffoOeZR6lYXg?= =?Windows-1252?Q?moQWIAZO47okH1IEuqY4bLvwvQFwPMbMDb5O5tcdp13enaLvxLYmQ0Yh?= =?Windows-1252?Q?TaaUhX8ylFENB9zu/vjOYbWs/C6giYNIEwsIHTWpbmqAxWKGKLHYIDvr?= =?Windows-1252?Q?Livx98NiPsiDv1N2ZIgtnl4zU6qnyXSIoz6MooTmz58phGvPS+cXKVWG?= =?Windows-1252?Q?RuIwupLPvQBJlB0rYCSKQl5AuKWF1FwrjOLD/ooOQ1jpz2LpFWfZ/dOj?= =?Windows-1252?Q?n+TjT+hIgJLE39E9Twgq4eZX0Vpp+kZv0pkoXPkdwfgoOg/E4wcp2ulj?= =?Windows-1252?Q?fga42jJmIv5MUsyfUxGbSK2Qeeiq8i0PPIwa4dqXJLfA3JA2WRkeKY0L?= =?Windows-1252?Q?yU0hVK/RVtTa9gQ9nzhS2Ddwrgtc/J2G3MUFlmrabscWaYVabjofpJBJ?= =?Windows-1252?Q?XDavaV7C7fc2XZ9r9HrTkNumvE+OwXxkN7Wlf0SKJF1F7FMkVorcKLfN?= =?Windows-1252?Q?/VsnKMPzAznllcTqD9XieBZHE6AfUNvBxqxWRjIEGw974XUGgbrTY/qt?= =?Windows-1252?Q?8Fm00fT6V/f7ny5HbnddieRN/xfa4uTlKYXS580CtCwQL2hL6I9KDzay?= =?Windows-1252?Q?J7BNYjIlUtF08qTnK0VWWufZN3ejGGMDxpEireBfjy1aPIAyZGcUQBzb?= =?Windows-1252?Q?q0Aj+lT2JTuBB125UHcbQfCQHNBoWNz8RJ0Gr25Uw8goS0Tog2a5FgOt?= =?Windows-1252?Q?U7StqZf+VbmHko7lTw7VuRlstU/bOEMKUZn5J2lYWD03Tn965AQv64wk?= =?Windows-1252?Q?6U+XHBkML0ACoiA9VlPrsFpFgmcqv18NqXCF/bwDEpfmDQC+ga952ax3?= =?Windows-1252?Q?jWOaa02B71nDJIS+HOP9paaPdtYfeI+NLG8d8UKMR9444hB1ZxSiqasi?= =?Windows-1252?Q?v0hfssnpUQF68Rm0HkKeIx5MHnIwfp8hiCNs6J/vZzWew1fVg2vagGb/?= =?Windows-1252?Q?j820qKjIaGjhe39yVVjrh4pVyh1j4xgCHEhZyy/8DMVLSO2N06a1y5WW?= =?Windows-1252?Q?3HKQZBRfw=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(366004)(376002)(136003)(189003)(199004)(8990500004)(68736007)(6436002)(229853002)(33656002)(517774005)(14454004)(97736004)(440504004)(606006)(66574012)(2906002)(6246003)(76176011)(10290500003)(966005)(10090500001)(478600001)(71200400001)(71190400001)(105586002)(99286004)(14444005)(102836004)(6346003)(6506007)(53546011)(4326008)(110136005)(54906003)(316002)(93886005)(486006)(53936002)(86612001)(106356001)(256004)(446003)(11346002)(9686003)(5660300002)(55016002)(8676002)(476003)(6306002)(7736002)(81166006)(26005)(5070765005)(8936002)(236005)(81156014)(54896002)(186003)(86362001)(22452003)(74316002)(3846002)(6116002)(66066001)(25786009)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0694; H:CY4PR21MB0854.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Xpoo7YF5p7tUUee5nNGnWTdYgey/NjORNIEQxvrOzwAIa2A274tuxi5BB2ZF5NOxFcy8tedyn+ml3c4xb4umOWcucBNVCSCkJLBwvCXviN2sSJaYWZE63TwkgsylRyJVNlJefyjDdEm+qGa6EWunOyW6uiUuDTD46nYni6xR928OZ4G77s02LStYeo5avG1/zrybHqkEeyXGpyq8jDLICt6naJRyz7SDTlScdx0hA8fQkehAyf5NZ/+wsp4nj6Wmib3QCAlu4Z/qVbwljwZfEGyzMt7gGHYMOROPGru+0lkP7lgTjvEM3C2tzMyBl4MQ9GnnSw0eMppWB5CZ0iJFVGD1eGVJiS73Mz+VMfoQyw2QJe2O1FIlIc9rtPX8WxP1KMU/8uCeG2unLYgrTguXhOmrbQFRW8CUGSKV57HGubM= Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0854D8F7383CDF72EEDAE9FBB37D0CY4PR21MB0854namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3aeefaef-b7ae-459e-6f8a-08d69742a617 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 14:49:42.8432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0694 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 14:49:49 -0000 --_000_CY4PR21MB0854D8F7383CDF72EEDAE9FBB37D0CY4PR21MB0854namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It would be nice to have a way for the server to say =93QUIC is temporarily= unavailable right now, please go use TCP instead.=94 Additionally, I don= =92t want to have to modify anything on the TCP side (Alt-Svc). The next co= nnection after you fallback to TCP may try QUIC again, but you might just g= et the same behavior. Sent from Mail for Window= s 10 ________________________________ From: Ian Swett Sent: Wednesday, February 20, 2019 6:41:40 AM To: Brian Trammell (IETF) Cc: Nick Banks; IETF QUIC WG; Mirja K=FChlewind Subject: Re: Expected Client Response to SERVER_BUSY If a client follows 3xx redirects by default, then it seems sensible it'd f= all back to TCP automatically, but I'm not sure an immediate QUIC connectio= n close is equivalent to a redirect. I can also imagine clients that don't= follow redirects by default falling back to TCP, so I think I just chose a= poor example. On Wed, Feb 20, 2019 at 8:52 AM Brian Trammell (IETF) > wrote: hi Ian, Sent from my iPhone On 20 Feb 2019, at 14:34, Ian Swett > wrote: For HTTP/3, my intent was to close the connection immediately with a connec= tion close as you suggest, then the client would fall back to TCP, and then= ensure the next Alt-Svc advertisement via TCP cleared any existing Alt-Svc= entry so QUIC wasn't tried again in the immediate future. I hadn't thought of assigning semantics to a specific error code, but I'm r= eluctant to do so. In our case, I think a more likely error code would ind= icate the infrastructure doesn't support QUIC, rather than DDoS, but the de= sired behavior of falling back to TCP and not attempting QUIC for a while i= s the same. The assumption I made above is that the client immediately falls back to TC= P. That of course depends upon the type of client it is. I'd expect a bro= wser to fall back, but I wouldn't expect curl or wget to. This is a bit of an aside, but I=92m curious here: why not? I=92ve always t= hought of the semantics of TCP fallback as equivalent to a 3xx redirect (ei= ther temporary or permanent, depending on the client heuristics wrt the und= erlying reason for the redirect). curl won=92t do this automagically unless= you tell it to, but iirc wget will... Am I wrong in thinking that most clients will see this as YA form of redire= ct? Cheers, Brian There is a decent amount of text on fallback in the Applicability draft: ht= tps://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicabilit= y..md On Tue, Feb 19, 2019 at 5:11 PM Nick Banks > wrote: Hello Folks, I=92ve been looking at interim DDoS mitigation strategies for QUIC until we= can have a more complete and QUIC aware DDoS and LB solution. One thing I = came up with is just trying to force the client to fallback to TCP. Eventua= lly, we will use Stateless Retry but that still requires a good bit of desi= gn work and cooperation between the offload device and the backend server. = Until that is complete, a simple solution could be a device in path just re= sponding to new QUIC connection attempts (while an attack is in progress) w= ith a connection close frame containing the SERVER_BUSY error. The logic to= implement a simple device to do that should be quite trivial. To that end, I was trying to figure out what the expected client response t= o any immediate (in the first RTT) connection close packets/frames would be= and it seems we don=92t have anything in the spec. What about SERVER_BUSY = specifically? Is the client supposed to retry a new connection attempt? Sho= uld they fallback to TCP immediately? Should we say anything in the spec? Thanks, - Nick --_000_CY4PR21MB0854D8F7383CDF72EEDAE9FBB37D0CY4PR21MB0854namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

It would be nice to have a way for the server to say= =93QUIC is temporarily unavailable right now, please go use TCP instead.= =94 Additionally, I don=92t want to have to modify anything on the TCP side= (Alt-Svc). The next connection after you fallback to TCP may try QUIC again, but you might just get the same behavi= or.

 

Sent from Mail for Windows 10

 

From: Ian Swett <ianswet= t@google.com>
Sent: Wednesday, February 20, 2019 6:41:40 AM
To: Brian Trammell (IETF)
Cc: Nick Banks; IETF QUIC WG; Mirja K=FChlewind
Subject: Re: Expected Client Response to SERVER_BUSY
 
If a client follows 3xx redirects by default, then it seem= s sensible it'd fall back to TCP automatically, but I'm not sure an immedia= te QUIC connection close is equivalent to a redirect.  I can also imag= ine clients that don't follow redirects by default falling back to TCP, so I think I just chose a poor example.


On Wed, Feb 20, 2019 at 8:52 AM Brian= Trammell (IETF) <= ietf@trammell.ch> wrote:
hi Ian,

Sent from my iPhone

On 20 Feb 2019, at 14:34, Ian Swett <ianswett=3D40google.com@dmarc.ietf= .org> wrote:

For HTTP/3, my intent was to close the connection immediat= ely with a connection close as you suggest, then the client would fall back= to TCP, and then ensure the next Alt-Svc advertisement via TCP cleared any= existing Alt-Svc entry so QUIC wasn't tried again in the immediate future.

I hadn't thought of assigning semantics to a specific error code, but = I'm reluctant to do so.  In our case, I think a more likely error code= would indicate the infrastructure doesn't support QUIC, rather than DDoS, = but the desired behavior of falling back to TCP and not attempting QUIC for a while is the same.

The assumption I made above is that the client immediately falls back = to TCP.  That of course depends upon the type of client it is.  I= 'd expect a browser to fall back, but I wouldn't expect curl or wget to.

This is a bit of an aside, but I=92m curious here: why not? I=92ve alw= ays thought of the semantics of TCP fallback as equivalent to a 3xx redirec= t (either temporary or permanent, depending on the client heuristics wrt th= e underlying reason for the redirect). curl won=92t do this automagically unless you tell it to, but iirc wget wi= ll...

Am I wrong in thinking that most clients will see this as YA form of r= edirect?

Cheers,  

Brian

There is a decent amount of text on fallback in the Applicability draf= t: https://github.com/quicwg/ops-drafts/blob/master/dra= ft-ietf-quic-applicability..md



On Tue, Feb 19, 2019 at 5:11 PM Nick = Banks <nibanks=3D40microsoft.com@dmarc.ietf.org> wrote:

Hello Folks,

 

I=92ve been looking at interim DDoS mitigation strat= egies for QUIC until we can have a more complete and QUIC aware DDoS and LB= solution. One thing I came up with is just trying to force the client to f= allback to TCP. Eventually, we will use Stateless Retry but that still requires a good bit of design work and = cooperation between the offload device and the backend server. Until that i= s complete, a simple solution could be a device in path just responding to = new QUIC connection attempts (while an attack is in progress) with a connection close frame containing the SER= VER_BUSY error. The logic to implement a simple device to do that should be= quite trivial.

 

To that end, I was trying to figure out what the exp= ected client response to any immediate (in the first RTT) connection close = packets/frames would be and it seems we don=92t have anything in the spec. = What about SERVER_BUSY specifically? Is the client supposed to retry a new connection attempt? Should they fall= back to TCP immediately? Should we say anything in the spec?<= /p>

 

Thanks,

- Nick

--_000_CY4PR21MB0854D8F7383CDF72EEDAE9FBB37D0CY4PR21MB0854namp_-- From nobody Wed Feb 20 07:04:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D09130ECF for ; Wed, 20 Feb 2019 07:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBhYitlCQGuG for ; Wed, 20 Feb 2019 07:04:10 -0800 (PST) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 E9694130EC0 for ; Wed, 20 Feb 2019 07:04:09 -0800 (PST) Received: by mail-yw1-xc32.google.com with SMTP id f192so441075ywh.6 for ; Wed, 20 Feb 2019 07:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+gsAYIHKdViqNCoTlSD5W/uuGXdXn9uNIaFk5FnZts0=; b=aA5mP89csrK2D5P796niHtYiya5db9G83c2OqVG09s/eUrRAAFFk9XBVrWujcGZ1tG RuG53538Ca5OVao4pRHqVOoUuywWGpAF85XTUgAV6Hatv8qV84mMNNsuGjDzMUsRTHet /Cv2lUTuZy1ANTDfffxLgYHy3TQswOr6zN1N2JED0kx8fk93GUwsD8x4DtRYLKkUJXzO V6wCNehWw980QVFRtx/DLllfHhx7aIEqmXGtfHdQAJNOrJiELecmyTuFkuweSnkepX2j hOGV94xwWvmTDKKejzQLFYsqr/6NEWktyR/s8JhC39AXDF6T1Dn/7ZqW9n68TuFm4ena OViQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+gsAYIHKdViqNCoTlSD5W/uuGXdXn9uNIaFk5FnZts0=; b=YrES0BfmUXUoSy4K7LBiYwqOs1kJmG6ZRiMaxoC57jo7lforp0ZfRgAzaQietiVE1c /IuclyPFaBVXUq4FUSrzFvmco+/vJ1P2ua0BeFvr6HYFHa3XNk2fHQlpM1QBeVbZ91vF HaU7OKvhMVzP04p6P+x6pPZq360dMboVcSTZ4C1Xzf+6qWTDHRCXrAX34GuTypICWr8F YU4eegCieKcE4mG1Om5xd3ZztBvVkMqNQOhHIEjrb5MvzeqrACJmd5QX0UbgK4m8mCfO iRmme+dJn0QoCce4Lf1H7fWNoJQN6QinC/vtVu7x2ewn9WLvMAqwupdFB7JSaM29kI8+ EJIA== X-Gm-Message-State: AHQUAuZnEbUwoF5tns2Zu9D6wflRJO9XdmiZbb5SJQfslZWAc9Unerd3 53iO5TbnfRBguq9viVhTskH0drOKr3YKxMmx8ok= X-Google-Smtp-Source: AHgI3Ib1VZIIkdYHymxkK3ZkOsqEKdQkB2bUDo+mCWPwZNJQ9y4NyS4FnqswPS06qYwvZc9MUs9yabS+7sddsWyJKhk= X-Received: by 2002:a81:1d15:: with SMTP id d21mr27389433ywd.323.1550675048771; Wed, 20 Feb 2019 07:04:08 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Wed, 20 Feb 2019 07:03:49 -0800 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Nick Banks Cc: Ian Swett , "Brian Trammell (IETF)" , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:04:17 -0000 On Wed, Feb 20, 2019 at 6:50 AM Nick Banks wrote: > It would be nice to have a way for the server to say > =E2=80=9CQUIC is temporarily unavailable right now, please > go use TCP instead.=E2=80=9D One issue here is that under a DDoS attack an ISP would just apply selective blackholing or flow specification which would simply drop all the incoming UDP traffic to protect the last mile. Depends on the attack pattern somewhat, sometimes blackholing might be more granular, but all in all you should expect that. The only hope here is that a client would interpret response timeout in the same way as SERVER_BUSY. -- T=C3=B6ma From nobody Wed Feb 20 07:20:01 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2845130DF6 for ; Wed, 20 Feb 2019 07:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 mden6FJ36hzE for ; Wed, 20 Feb 2019 07:19:57 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680097.outbound.protection.outlook.com [40.107.68.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F09129741 for ; Wed, 20 Feb 2019 07:19:56 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=Q2U3Va/En6kkle4sVj3j+w5bA4KjpC/Fbu1LYZG7uVs=; b=ZzbWJp2zinwuDdX3pWDmxWVIhC39hZ1t3iQrYP/+xmuKCjb2gtEPO74Il4MJuHwMkVCz2tyoCSRvhlTSZ/5AqOZey4fCECpHOQhFlVdHCcDscSoWgv8XmiRZRlmZsm2K6dKzsQf3QYCBZqedBSyBvBv01Ay4ih6dtzVJeZ2JUCE= Received: from CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) by CY4PR21MB0631.namprd21.prod.outlook.com (10.175.115.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.2; Wed, 20 Feb 2019 15:19:54 +0000 Received: from CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46]) by CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46%3]) with mapi id 15.20.1665.002; Wed, 20 Feb 2019 15:19:54 +0000 From: Nick Banks To: =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= , Ian Swett , "Brian Trammell (IETF)" , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: AdTInrfRZAbJSsLZSlWCCrlUkiWX7AAgkIeAAACdzgAAAbynAAAAN6coAACOYoAAAIKXwA== Date: Wed, 20 Feb 2019 15:19:54 +0000 Message-ID: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-02-20T15:19:52.9119086Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=0ed0b7f0-3625-4591-8628-e67a458f56c8; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [2001:4898:80e8:3:682d:1a0f:7fc0:ca5c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7335720-6f62-40dd-dc2e-08d69746de14 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR21MB0631; x-ms-traffictypediagnostic: CY4PR21MB0631: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTRQUjIxTUIwNjMxOzIzOlUvZnRuTUx5YzQwUDFkdTR5NlV0cHZpZmNp?= =?utf-8?B?OWxvQ0EzejNFb1o1bTl4cXo4dVBTY3BQckgyM3FkdlllQXZvazErSEIvdDNH?= =?utf-8?B?WkQwbnZUWG5uejlCUmtEc1cwZ1I0M1kvWFYvQ29EZHdyRFJyNG0yalVMUDlE?= =?utf-8?B?ZWVQM0VFeXJHRlYxd1dpaFhHNVM3d2h6d1VyWGRLaHNDRE9lanowVnhmdnNV?= =?utf-8?B?ZEJzdTUreENHVzlxV1cyWC9KSTllM3dOUm5rYTQwMDh4aHZjK1NPVEFDNkFJ?= =?utf-8?B?R1VpRDRIS1E0ZHloNFFIWTRUek9TTm9tY3Y2TkwwNlNJNFBBWlRVNmYwZHRW?= =?utf-8?B?czdJdmp3RXpTRnQvVzA0VTV0UG43bjZyQmR3QnE2NG5DbW1ZVG9SMTJCbnRi?= =?utf-8?B?NlFpSGRzQlFMbXN1eGVKaWtTMUppWUdxWVpqRzNlSS9xZ2FtY2E5bVVyUGVF?= =?utf-8?B?SGVndjYrTGk3c0JLZ2NxUncwS3l1VWtQMVNmdTd2cGdITnl2YjNidmh1MDNo?= =?utf-8?B?cnBtMXhOVFpoZU1qdVVWamIvcm51aTlScGtYUDBDenVqWVRNcnNEengrbHN5?= =?utf-8?B?VTkxZGRML1FmTEc4QzJCVy9MS0poTzU5NlptUFlHQ2lFYkxGM1pmdDNVNWRO?= =?utf-8?B?bHZTalBVeFlwZHhhbTgxZ0tFa3lpWGlFM3I4R0poUktGaEFidUhMSUU3Y3Bj?= =?utf-8?B?dmh0alJ0aWxCZmhEbk05cHJkRHJTV0JNTlpjKzZMczJPdEdsSGF4Q2piQXV4?= =?utf-8?B?VHltQVRHQTN5cFI0b1EvVEM1UE5qS0drSUhZVFNtcTBaSU9iSE9hV0xvVUZM?= =?utf-8?B?NEZIeXNKOUtGM1FYZTNqdnlobGZLVjl3NEVJS09naHhtOE9Lc2dWNVREdVhJ?= =?utf-8?B?anF5WDNZMGpXcUhsUno2ZTkzVU5idGtqcGFVbnJ4dDJKL21JakNPOTFFblFw?= =?utf-8?B?aXlLS3RTRWtGUGtGQjhTakhYOXIvSUhIQUhERkJsRWowSVg5eURJOStNWDli?= =?utf-8?B?NHBRdlZRZE02cVpwVUtJN2QrNytUVGRJdkM5TXdLaXFucjFoeFgxc0NYMDlZ?= =?utf-8?B?cnB0blViNDFiUHJKeW5uSWtBNnpQVDhUR2hvbWVMT1pqdE4xMFppS1UxK0VE?= =?utf-8?B?VlhEU2NUSVNMeXcyeW8wSTRQYU5KMUZlRkl0ek00RzdQeVE5bHduTXY5VDBW?= =?utf-8?B?SkNQUTFkYXRXQnNhNnRSVGs0THhGakZRaG05VEN3eG9QYjhDZnFwY0w5cUZ4?= =?utf-8?B?N0N5YkJTNEpFR3czemJNUFEwS1docjBZVkdVOEFkOVE4dGxoNmlQNEcwN05U?= =?utf-8?B?QmZwOVlwZHhmbUVXMFh0VFdlcDg4VWdZWTRFaitLRzFwWFNSUFoxZTBHb2dS?= =?utf-8?B?YkpqQTY4NjFwT1l4S0d3TTFOeU56cWdTeUo4L05xbTlyNUxNeUpaUld1eHhH?= =?utf-8?B?YXorZHFwVE14NVV3VGtneTdWamxZOVJkQ3NZeUg4dkJ3eU8ydHpYaXlUN1pF?= =?utf-8?B?c0VLSWdmM0loeUFVUDhCcC9yNDRERXZUaVFXMkxtcjJBRG9IR25RYjlXVnI0?= =?utf-8?B?Q2tGZ2pZb2I1eEtQbXN6V29sSnBlbHRydzcrTXNCVTRtTTRsUGxwQ20yaTQ3?= =?utf-8?B?UUhXRlFsQnM1dE9USXhqQm80WWRlQ0ZHY2FKQmY1V2N6dXZ5M09ZR21GcTRi?= =?utf-8?B?T2dnTlZ5b05TZjRVNGdUT2lqTUFVOW5mWkRVMnFxOGFHQ3pJNnVRSk5IaGtx?= =?utf-8?B?Y3AxdGI4Nm4zYnhxV2dTSGRNeXVubUlTMWY0QVQ1TzNQTExKcGxsS1g4Z3Fi?= =?utf-8?B?QVJPZ2MrWE9hdVJGSDZEeVVxdGViR1pPcDZneit5YjdXaFE9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(136003)(366004)(346002)(396003)(199004)(189003)(13464003)(71190400001)(10090500001)(6246003)(33656002)(99286004)(446003)(86612001)(316002)(93886005)(106356001)(110136005)(8990500004)(11346002)(68736007)(105586002)(6506007)(22452003)(9686003)(71200400001)(86362001)(25786009)(97736004)(55016002)(478600001)(53936002)(6116002)(81166006)(81156014)(53546011)(6436002)(14454004)(74316002)(229853002)(486006)(5660300002)(8936002)(6346003)(102836004)(305945005)(7736002)(8676002)(14444005)(256004)(46003)(476003)(186003)(76176011)(66574012)(10290500003)(7696005)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0631; H:CY4PR21MB0854.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xpOCB6FZhuOiukVIxwSdVvEVGlFxRcyMMLpC/2sFhyGI+p7A8J3NHKZDr3Y48LvAoXwr/6Z8v5WCzS8V7qqS99oZHLeOEQ+PCrW0cGr8AXnzSLM723uUTTxLtQs5g+gL10LKoxVA7Sn2GHFqG/Z3xpbsuKRlrM9rR+18IRQwsGEvKUO5kOl7t9V7P1xLxQijXIcknDQyxzcH96SNP+Knob24+DsGifgZ037cBdInGfhYkshV08F7j9Xa4dLF5iVeh71hhXaaWbq1Uv2sf6wsejxR7u2hUgifZnrQvqMRFmRjHunqTwtD59/ucDSiLGUBerhgK5BzsLPRHp85DPmXL9QC4uWjtBxpX6x+uFOOAc4zMiZw+5FDqeSvy45EGS9BMW07cW12/1I4SRZoXHafXJTIbKqaydbZYjlVVVZY9/Q= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7335720-6f62-40dd-dc2e-08d69746de14 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 15:19:54.7436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0631 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:20:00 -0000 SSB3YW50IHRvIHN1cHBvcnQgc29tZXRoaW5nIGEgYml0IG1vcmUgZWZmaWNpZW50IHRoYW4gc2lt cGxlIHJhdGUgbGltaXRpbmcgYW5kIHBhY2tldCBkcm9wcy4gVGhlIGNsaWVudCBtaWdodCBoYXZl IHJlbGF0aXZlbHkgbGFyZ2UgdGltZW91dCBpbiB0aGF0IGNhc2UgYmVmb3JlIGZhbGxpbmcgYmFj ayB0byBUQ1AuIElmIHBvc3NpYmxlLCBJIHdhbnQgdG8gYmUgYWJsZSB0byBnaXZlIGFuIGltbWVk aWF0ZSBpbmRpY2F0aW9uIHRoYXQgaXQgc2hvdWxkIHRyeSB0byBmYWxsYmFjay4NCg0KLSBOaWNr DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUw7ZtYSBHYXZyaWNoZW5rb3Yg PHhpbWFlcmFAZ21haWwuY29tPiANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjAsIDIwMTkg NzowNCBBTQ0KVG86IE5pY2sgQmFua3MgPG5pYmFua3NAbWljcm9zb2Z0LmNvbT4NCkNjOiBJYW4g U3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZA dHJhbW1lbGwuY2g+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNaXJqYSBLw7xobGV3 aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KU3ViamVjdDogUmU6IEV4cGVj dGVkIENsaWVudCBSZXNwb25zZSB0byBTRVJWRVJfQlVTWQ0KDQpPbiBXZWQsIEZlYiAyMCwgMjAx OSBhdCA2OjUwIEFNIE5pY2sgQmFua3MgPG5pYmFua3M9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmll dGYub3JnPiB3cm90ZToNCj4gSXQgd291bGQgYmUgbmljZSB0byBoYXZlIGEgd2F5IGZvciB0aGUg c2VydmVyIHRvIHNheSDigJxRVUlDIGlzIA0KPiB0ZW1wb3JhcmlseSB1bmF2YWlsYWJsZSByaWdo dCBub3csIHBsZWFzZSBnbyB1c2UgVENQIGluc3RlYWQu4oCdDQoNCk9uZSBpc3N1ZSBoZXJlIGlz IHRoYXQgdW5kZXIgYSBERG9TIGF0dGFjayBhbiBJU1Agd291bGQganVzdCBhcHBseSBzZWxlY3Rp dmUgYmxhY2tob2xpbmcgb3IgZmxvdyBzcGVjaWZpY2F0aW9uIHdoaWNoIHdvdWxkIHNpbXBseSBk cm9wIGFsbCB0aGUgaW5jb21pbmcgVURQIHRyYWZmaWMgdG8gcHJvdGVjdCB0aGUgbGFzdCBtaWxl LiBEZXBlbmRzIG9uIHRoZSBhdHRhY2sgcGF0dGVybiBzb21ld2hhdCwgc29tZXRpbWVzIGJsYWNr aG9saW5nIG1pZ2h0IGJlIG1vcmUgZ3JhbnVsYXIsIGJ1dCBhbGwgaW4gYWxsIHlvdSBzaG91bGQg ZXhwZWN0IHRoYXQuDQoNClRoZSBvbmx5IGhvcGUgaGVyZSBpcyB0aGF0IGEgY2xpZW50IHdvdWxk IGludGVycHJldCByZXNwb25zZSB0aW1lb3V0IGluIHRoZSBzYW1lIHdheSBhcyBTRVJWRVJfQlVT WS4NCg0KLS0NClTDtm1hDQo= From nobody Wed Feb 20 07:38:51 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E16D1228B7 for ; Wed, 20 Feb 2019 07:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnv_eipBVN-X for ; Wed, 20 Feb 2019 07:38:48 -0800 (PST) Received: from mail-yw1-xc41.google.com (mail-yw1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) (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 A80A91200D8 for ; Wed, 20 Feb 2019 07:38:47 -0800 (PST) Received: by mail-yw1-xc41.google.com with SMTP id u200so9349747ywu.10 for ; Wed, 20 Feb 2019 07:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x4I3MNNKANJSV7ShHAApt3FtZ8gRy36F6hrHrbrCDeU=; b=LQ0HTCnYDwivganNvWE7AA/qM1LoAWr6z2+KJI7H+awcFFKxdbWnsUnNcchjpNxGnk kV0Cvw7tEcy47aVtV4klnFYCQTDkueCjDGGb6hBTrOViiyYfgqkKBO0dkY2l0jIF2GjS VYgVAilrn7MRoTk3EUhdq7/gaDTwHGA2zWxZMNQkZjhwKVuXSEdokXmGFQGHfB29CbkO FcnXTqxJqHNwGtCpnzWKHaKqh9c+UI8x7Z5bN/WeWQzP7kPFB8k8a/7Xd8w8+ARfe19u DJVgDxk9RRkJjnocQVE5cnWXPGOS7LPAHjn4OjRNqc8v4d28Va8hkUxvE0+QCpbs15X7 rvpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=x4I3MNNKANJSV7ShHAApt3FtZ8gRy36F6hrHrbrCDeU=; b=Cx3BJ2N2MNpmA39jKnct4floXPfR0d4tjX5SDFLzHY4rmuyS7+ACXwj/atNGan57uk 2qgY08e3gHiYaM6dGWO2bAhdqX7r2CkCg9Ndex9LeVZIitepH8eDU+uuqKgtEcZ5OWjG fkaUCgzmQzsvtv7YdpzKru/2aRLr4Sxv9r2S5WPXVbEUnq7SDdX3/5e9bqBiT+9ovvwc 99wh9/vzZUNs0etn4sEpAnWeo9O2z2sy/nLfeP5gPh2JiLSMcopIQUrzosnRVj2SegM0 6HMRbwGNnURV3646bdNBuV7DVkbT09oiWzwJf05bqjEJi70hj0zEQBGiTvFTpMG22Skg f/3A== X-Gm-Message-State: AHQUAuYttBP/sCxmvbc5DAr/QTVN0Tc3Mt9M7U5HbewbOm/P2FhyN+4F fn0hK6FOJSMnL1QH2An6MlnVmvlv9qdBuaGTW/o= X-Google-Smtp-Source: AHgI3IY7hAtFE6LpzHdihtQGe9utEtF0TixyYgqqGVUOLkN3X1J2eQu0fL1ysi3CZaVBP1MpDqi9E93Y9qpxi+V3n/s= X-Received: by 2002:a81:6b09:: with SMTP id g9mr17011427ywc.255.1550677126565; Wed, 20 Feb 2019 07:38:46 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Wed, 20 Feb 2019 07:38:28 -0800 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Nick Banks Cc: Ian Swett , "Brian Trammell (IETF)" , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:38:50 -0000 I mean, yes, handling such a case explicitly totally makes sense. I just wanted to point out that there's an additional use case when UDP transmission just suddenly stops under an attack. Note that a DDoS attack towards a QUIC server isn't the only possible scenario, the other one being a DDoS towards a client. In the latter scenario, given the not-so-likely-but-completely-possible case when a newly discovered DDoS amplifying protocol would be using port 443/udp, even selective blackholing won't help to preserve QUIC connectivity. As a matter of fact, there's no way to handle it transport-protocol-wise, but maybe adding a timeout-related suggestion of a SHOULD CONSIDER style to the spec would be a good idea. | T=C3=B6ma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 On Wed, Feb 20, 2019 at 7:19 AM Nick Banks wrote: > > I want to support something a bit more efficient than simple rate limitin= g and packet drops. The client might have relatively large timeout in that = case before falling back to TCP. If possible, I want to be able to give an = immediate indication that it should try to fallback. > > - Nick > > -----Original Message----- > From: T=C3=B6ma Gavrichenkov > Sent: Wednesday, February 20, 2019 7:04 AM > To: Nick Banks > Cc: Ian Swett ; Brian Trammell (IETF) ; IETF QUIC WG ; Mirja K=C3=BChlewind > Subject: Re: Expected Client Response to SERVER_BUSY > > On Wed, Feb 20, 2019 at 6:50 AM Nick Banks wrote: > > It would be nice to have a way for the server to say =E2=80=9CQUIC is > > temporarily unavailable right now, please go use TCP instead.=E2=80=9D > > One issue here is that under a DDoS attack an ISP would just apply select= ive blackholing or flow specification which would simply drop all the incom= ing UDP traffic to protect the last mile. Depends on the attack pattern som= ewhat, sometimes blackholing might be more granular, but all in all you sho= uld expect that. > > The only hope here is that a client would interpret response timeout in t= he same way as SERVER_BUSY. > > -- > T=C3=B6ma From nobody Wed Feb 20 09:44:39 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3EC130E13 for ; Wed, 20 Feb 2019 09:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsqU6SfSLrz8 for ; Wed, 20 Feb 2019 09:44:35 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 22B61130E57 for ; Wed, 20 Feb 2019 09:44:35 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id w14so7503491vso.6 for ; Wed, 20 Feb 2019 09:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+5yuI7UZnWo7T3ANpDiK1ZB/rpVRMm4Ej9dLZOfvmy8=; b=cIKud5n0wYWxha9kWU6lXfahflvs9Hf6qQB6y5Q761Dp61Zyu0JNrBw5HjOSgMyyqz K+pVcstyHDtbvYiyWDQFAUzZv3UU+IT4EiVWAX6ZLjFXlv9y1gdl4AzUtYHHlrzYdpWb rMqBgjh2cJgPsONxTErDtGvmY/BKrRF2TStRTGcdUCVidjNsQAj5Tqv6EdYDg4R5Csjc lbBL9vxQEL5vAGs8lcptnPtkBsFQap1m8FfZwbDQBXZ43O+CYbiJK9FIENxCbxzZCYt5 5DdGKlqghZrovyTp3iArVBk2DeyO41VdOjDPqOXLakQdM7mOv0iejhb2nfzBORMAZLkA 90RQ== 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=+5yuI7UZnWo7T3ANpDiK1ZB/rpVRMm4Ej9dLZOfvmy8=; b=TZMo/vO/EcADmXWxEeJTZuzyb0FuivDi3XC4n9uIgw+yQT7cauaHVPOLdaFTgED/zj FY5rDBZCmm40rGTTiEyUe+Qj43dIl5aEDAgVELETCg0ywWCiNSGZppU7fyzKmkBReKJQ phgA3V2L165DL5VqkwIxlHpElVZiFUOeqdCPRv+H3sDrV0Uc85TMvDJ4WSK+uvsiBV2c 2/j7jVIbzUWJeXOu+Lg6uzejnMtA3FBLjK2egfRZBOTCElVPvXU12JjRBNybcspWN57f 0Rj4nqIiduqe9i1l1pJbQ5EYlBKI4mwxBNPuKZx3UdvRP+tKM15p9nZYn1A75jclvtYO gPAw== X-Gm-Message-State: AHQUAuZHLYsI4ggk91TThX6S7yipfnS5ZNh9viZz7LTC7vEgWQoBBzK/ jLejg56FhglKxoKFVX2qUFqEzWKlhUbE12WlHCWn8obS X-Google-Smtp-Source: AHgI3IZ3QSVNqqtDWdmeCqF6WIlhjTMsj2lGz2sRiDWUGkse/5UHDkdvMJo0gP6CaLTa7CitbapcQB7gufRIaAlXku4= X-Received: by 2002:a67:e9cc:: with SMTP id q12mr19044292vso.113.1550684673565; Wed, 20 Feb 2019 09:44:33 -0800 (PST) MIME-Version: 1.0 From: Bernard Aboba Date: Wed, 20 Feb 2019 09:44:22 -0800 Message-ID: Subject: QUIC API trial in Chrome To: QUIC WG Content-Type: multipart/alternative; boundary="0000000000002066bd058256e94c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 17:44:38 -0000 --0000000000002066bd058256e94c Content-Type: text/plain; charset="UTF-8" For those of you who are interested in experimenting with QUIC P2P application development in Javascript, there is now an opportunity to do so: http://lists.w3.org/Archives/Public/public-ortc/2019Feb/0000.html --0000000000002066bd058256e94c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For those of you who are interested in ex= perimenting with QUIC P2P application development in Javascript, there is n= ow an opportunity to do so:
--0000000000002066bd058256e94c-- From nobody Wed Feb 20 10:50:03 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642FB130E7B for ; Wed, 20 Feb 2019 10:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy9l393yN8dQ for ; Wed, 20 Feb 2019 10:49:59 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D691130E77 for ; Wed, 20 Feb 2019 10:49:59 -0800 (PST) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gwWwM-0001hg-Vo for quic@ietf.org; Wed, 20 Feb 2019 19:49:57 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gwWwC-000309-RG for quic@ietf.org; Wed, 20 Feb 2019 13:49:49 -0500 Received: (qmail 19482 invoked from network); 20 Feb 2019 18:49:41 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[208.54.5.227]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 20 Feb 2019 18:49:41 -0000 To: =?UTF-8?Q?T=c3=b6ma_Gavrichenkov?= , Nick Banks Cc: "Brian Trammell (IETF)" , Ian Swett , IETF QUIC WG , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Wed, 20 Feb 2019 10:49:42 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: Expected Client Response to SERVER_BUSY X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.27) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5joBpBKke7a0K3ekAElLIMJ602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViCmF9kKioocUUOkjdm1K1f87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBZ2ueFSQXe2iRuiGZQLqR4x/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaJVTCM/kg/vVe0IDRSDEWhkvy7NvAbxEgZSsI+HSLa0cYlUIZP64+Xv WKqUVvNV6rNk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAliWlQbBThxwZFUQHKWb8B+lZYSpQQtCkh8qZ SV0LCxtehLsKz7jb6sff7w2dFlSf0V2f5gIc7tIbqZH8URkv+vshu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK04vW75yGJIA4He1K6wlrze9UshveVgoiypAicYsWUtdCDRZgQnFYkq0SOLr mvxpF44cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 18:50:02 -0000 Can we do better than an unauthenticated signal to "drop QUIC immediately and use something else"? I understand the desire of protecting servers against DOS attacks, but the proposition here allows a middle-box or a man-on-the-side to send an unencrypted signal and have the client immediately immediately drop the connection. That does not feel right. -- Christian Huitema On 2/20/2019 7:38 AM, Töma Gavrichenkov wrote: > I mean, yes, handling such a case explicitly totally makes sense. I > just wanted to point out that there's an additional use case when UDP > transmission just suddenly stops under an attack. > > Note that a DDoS attack towards a QUIC server isn't the only possible > scenario, the other one being a DDoS towards a client. In the latter > scenario, given the not-so-likely-but-completely-possible case when a > newly discovered DDoS amplifying protocol would be using port 443/udp, > even selective blackholing won't help to preserve QUIC connectivity. > As a matter of fact, there's no way to handle it > transport-protocol-wise, but maybe adding a timeout-related suggestion > of a SHOULD CONSIDER style to the spec would be a good idea. > > | Töma Gavrichenkov > | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 > | mailto: ximaera@gmail.com > | fb: ximaera > | telegram: xima_era > | skype: xima_era > | tel. no: +7 916 515 49 58 > > On Wed, Feb 20, 2019 at 7:19 AM Nick Banks wrote: >> I want to support something a bit more efficient than simple rate limiting and packet drops. The client might have relatively large timeout in that case before falling back to TCP. If possible, I want to be able to give an immediate indication that it should try to fallback. >> >> - Nick >> >> -----Original Message----- >> From: Töma Gavrichenkov >> Sent: Wednesday, February 20, 2019 7:04 AM >> To: Nick Banks >> Cc: Ian Swett ; Brian Trammell (IETF) ; IETF QUIC WG ; Mirja Kühlewind >> Subject: Re: Expected Client Response to SERVER_BUSY >> >> On Wed, Feb 20, 2019 at 6:50 AM Nick Banks wrote: >>> It would be nice to have a way for the server to say “QUIC is >>> temporarily unavailable right now, please go use TCP instead.” >> One issue here is that under a DDoS attack an ISP would just apply selective blackholing or flow specification which would simply drop all the incoming UDP traffic to protect the last mile. Depends on the attack pattern somewhat, sometimes blackholing might be more granular, but all in all you should expect that. >> >> The only hope here is that a client would interpret response timeout in the same way as SERVER_BUSY. >> >> -- >> Töma From nobody Wed Feb 20 10:52:35 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED96130E57 for ; Wed, 20 Feb 2019 10:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emppOkrJuXEw for ; Wed, 20 Feb 2019 10:52:30 -0800 (PST) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 74899130DBE for ; Wed, 20 Feb 2019 10:52:30 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id v26so7479955wmh.3 for ; Wed, 20 Feb 2019 10:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e5cOpo9KGwEkjKqrDixl1D4vqnFKNKsTHg4Inv4/eQg=; b=h3L0z19Eqdjx4eqO/UIXWt+Ia+hdkDUFX8q3ycs9RVcAcllrz9npyr4mdFzMeXVoOh B4LVreQwEXwG15cQR4a4ELy8mxkZJVdYs6xpfwZm/+NjW+tEucE3q5ln0v7PcWtiKv4u fR60lr5xy9KP0abxRxQ+dUAb4VL//exr4V08tf/vmyRXj74yrPWmKJjVY72fMI5pVIE7 cj8ZdZunU1kIWqPXZYZVTRwaUn12F7IWSALn5/f1T39RN/RC2S1GlCUxKeGHC0RD1pyU /x8L76JUEDdJsk4lfqKazai7FG3l6s+JR9k5hbCGo8PjrbCjTFVk+JF5C9dgKyonDTJg arSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e5cOpo9KGwEkjKqrDixl1D4vqnFKNKsTHg4Inv4/eQg=; b=m7Oa4qhSQzQ31AnLi9XevgTJ85BJj8aI/Zgeh9uOKzDPKJwLfY9bMdtXEXb37Hs+9O N0geFYdv8WpmS5Vzx0ttG3oeiPOGjpyme5SkUC0Y+nFd8Ws1WNqRcpjBq+1CaxiilO0Q rR/HYAYXIRZhvC4cpcfKtSk/YdRNT1ZFgA6n6t7UeXZAPqHye/G1AuOFOWXEnKRIWTKX BFu4EgtMu7uxEXFmo1fAAfw79XRP0I7ztgPh7OkF1bzZsmOFP32NMH//LAsSKbsBeHjo F4dneE9KUB43K1TOSoxWmcOgSURPY3sxMKD82hbqo59XJM+04te3YVvUPofj+4TYhNhh Smvg== X-Gm-Message-State: AHQUAuYupKsBBrbAibrktFh54O8/5DWsoY67CdTR2gidplrxBHc+K6dF msBL6tBIYOJk9rdalHmRPweGnxK06sY/7FdJbfPIHw== X-Google-Smtp-Source: AHgI3IZGINHTiq59JJ3LbNVMWJIU1c4cBOWQ3CiT8/omBK28gai08brd+pBVqdw08T19nHFpxaI09nE5JUFCN20KBLo= X-Received: by 2002:a1c:6789:: with SMTP id b131mr7583624wmc.22.1550688748391; Wed, 20 Feb 2019 10:52:28 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: From: Ian Swett Date: Wed, 20 Feb 2019 13:52:16 -0500 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Christian Huitema Cc: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= , Nick Banks , "Brian Trammell (IETF)" , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary="00000000000001bf17058257dc1d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 18:52:34 -0000 --00000000000001bf17058257dc1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed it's not amazing, but stateless reset isn't available until the handshake completes. Did you have any suggestions? On Wed, Feb 20, 2019 at 1:49 PM Christian Huitema wrote: > Can we do better than an unauthenticated signal to "drop QUIC > immediately and use something else"? > > I understand the desire of protecting servers against DOS attacks, but > the proposition here allows a middle-box or a man-on-the-side to send an > unencrypted signal and have the client immediately immediately drop the > connection. That does not feel right. > > -- Christian Huitema > > > On 2/20/2019 7:38 AM, T=C3=B6ma Gavrichenkov wrote: > > I mean, yes, handling such a case explicitly totally makes sense. I > > just wanted to point out that there's an additional use case when UDP > > transmission just suddenly stops under an attack. > > > > Note that a DDoS attack towards a QUIC server isn't the only possible > > scenario, the other one being a DDoS towards a client. In the latter > > scenario, given the not-so-likely-but-completely-possible case when a > > newly discovered DDoS amplifying protocol would be using port 443/udp, > > even selective blackholing won't help to preserve QUIC connectivity. > > As a matter of fact, there's no way to handle it > > transport-protocol-wise, but maybe adding a timeout-related suggestion > > of a SHOULD CONSIDER style to the spec would be a good idea. > > > > | T=C3=B6ma Gavrichenkov > > | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 > > | mailto: ximaera@gmail.com > > | fb: ximaera > > | telegram: xima_era > > | skype: xima_era > > | tel. no: +7 916 515 49 58 > > > > On Wed, Feb 20, 2019 at 7:19 AM Nick Banks > wrote: > >> I want to support something a bit more efficient than simple rate > limiting and packet drops. The client might have relatively large timeout > in that case before falling back to TCP. If possible, I want to be able t= o > give an immediate indication that it should try to fallback. > >> > >> - Nick > >> > >> -----Original Message----- > >> From: T=C3=B6ma Gavrichenkov > >> Sent: Wednesday, February 20, 2019 7:04 AM > >> To: Nick Banks > >> Cc: Ian Swett ; Brian Trammell (IETF) > ; IETF QUIC WG ; Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> > >> Subject: Re: Expected Client Response to SERVER_BUSY > >> > >> On Wed, Feb 20, 2019 at 6:50 AM Nick Banks 40microsoft.com@dmarc.ietf.org> wrote: > >>> It would be nice to have a way for the server to say =E2=80=9CQUIC is > >>> temporarily unavailable right now, please go use TCP instead.=E2=80= =9D > >> One issue here is that under a DDoS attack an ISP would just apply > selective blackholing or flow specification which would simply drop all t= he > incoming UDP traffic to protect the last mile. Depends on the attack > pattern somewhat, sometimes blackholing might be more granular, but all i= n > all you should expect that. > >> > >> The only hope here is that a client would interpret response timeout i= n > the same way as SERVER_BUSY. > >> > >> -- > >> T=C3=B6ma > --00000000000001bf17058257dc1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed it's not amazing, but stateless reset isn't= available until the handshake completes.=C2=A0 Did you have any suggestion= s?

On Wed, Feb 20, 2019 at 1:49 PM Christian Huitema <huitema@huitema.net> wrote:
Can we do better than an unauthentic= ated signal to "drop QUIC
immediately and use something else"?

I understand the desire of protecting servers against DOS attacks, but
the proposition here allows a middle-box or a man-on-the-side to send an unencrypted signal and have the client immediately immediately drop the
connection. That does not feel right.

-- Christian Huitema


On 2/20/2019 7:38 AM, T=C3=B6ma Gavrichenkov wrote:
> I mean, yes, handling such a case explicitly totally makes sense. I > just wanted to point out that there's an additional use case when = UDP
> transmission just suddenly stops under an attack.
>
> Note that a DDoS attack towards a QUIC server isn't the only possi= ble
> scenario, the other one being a DDoS towards a client. In the latter > scenario, given the not-so-likely-but-completely-possible case when a<= br> > newly discovered DDoS amplifying protocol would be using port 443/udp,=
> even selective blackholing won't help to preserve QUIC connectivit= y.
> As a matter of fact, there's no way to handle it
> transport-protocol-wise, but maybe adding a timeout-related suggestion=
> of a SHOULD CONSIDER style to the spec would be a good idea.
>
> | T=C3=B6ma Gavrichenkov
> | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
> | mailto: ximae= ra@gmail.com
> | fb: ximaera
> | telegram: xima_era
> | skype: xima_era
> | tel. no: +7 916 515 49 58
>
> On Wed, Feb 20, 2019 at 7:19 AM Nick Banks <nibanks@microsoft.com> wrote: >> I want to support something a bit more efficient than simple rate = limiting and packet drops. The client might have relatively large timeout i= n that case before falling back to TCP. If possible, I want to be able to g= ive an immediate indication that it should try to fallback.
>>
>> - Nick
>>
>> -----Original Message-----
>> From: T=C3=B6ma Gavrichenkov <ximaera@gmail.com>
>> Sent: Wednesday, February 20, 2019 7:04 AM
>> To: Nick Banks <nibanks@microsoft.com>
>> Cc: Ian Swett <ianswett@google.com>; Brian Trammell (IETF) <ietf@tramme= ll..ch>; IETF QUIC WG <quic@ietf.org>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz= .ch>
>> Subject: Re: Expected Client Response to SERVER_BUSY
>>
>> On Wed, Feb 20, 2019 at 6:50 AM Nick Banks <nibanks=3D40microsoft.co= m@dmarc.ietf.org> wrote:
>>> It would be nice to have a way for the server to say =E2=80=9C= QUIC is
>>> temporarily unavailable right now, please go use TCP instead.= =E2=80=9D
>> One issue here is that under a DDoS attack an ISP would just apply= selective blackholing or flow specification which would simply drop all th= e incoming UDP traffic to protect the last mile. Depends on the attack patt= ern somewhat, sometimes blackholing might be more granular, but all in all = you should expect that.
>>
>> The only hope here is that a client would interpret response timeo= ut in the same way as SERVER_BUSY.
>>
>> --
>> T=C3=B6ma
--00000000000001bf17058257dc1d-- From nobody Wed Feb 20 10:58:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8E0130DBE for ; Wed, 20 Feb 2019 10:58:32 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pGllxWVzv1p7 for ; Wed, 20 Feb 2019 10:58:29 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790119.outbound.protection.outlook.com [40.107.79.119]) (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 B67FD130E6D for ; Wed, 20 Feb 2019 10:58:28 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=OPto63+xQ6XKXIeoSpivu5+8dIqgfOF9/pXBjhJyqRI=; b=nXv+4YoneEoJ1SAQp8DhNRRyWN4CeRk4UO1xpLMZsbyTuxzseP/LMYGBSs2wh7XFuYSeqvmIYrp/0GKY1LuVs96cKu9sdKRDg45CgrsPBj+IAd62VbjuFt+p0F02TQ6i9HD4R3PX8DTMXe2A/oLql3auSkfP1EBNTpzYVLvzDLE= Received: from CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) by CY4PR21MB0856.namprd21.prod.outlook.com (10.173.192.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.3; Wed, 20 Feb 2019 18:58:27 +0000 Received: from CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46]) by CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46%3]) with mapi id 15.20.1665.002; Wed, 20 Feb 2019 18:58:27 +0000 From: Nick Banks To: Ian Swett , Christian Huitema CC: =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= , "Brian Trammell (IETF)" , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: AdTInrfRZAbJSsLZSlWCCrlUkiWX7AAgkIeAAACdzgAAAbynAAAAN6coAACOYoAAAIKXwAAAszQAAAatwwAAABbyAAAALguQ Date: Wed, 20 Feb 2019 18:58:27 +0000 Message-ID: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-02-20T18:58:25.5356596Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=e866ef22-7d9f-421b-9bbe-1003a88a1fdd; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [2001:4898:80e8:3:682d:1a0f:7fc0:ca5c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db2ffb22-f183-461c-0abd-08d6976565a1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR21MB0856; x-ms-traffictypediagnostic: CY4PR21MB0856: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTRQUjIxTUIwODU2OzIzOmR5S1dIdFpER2ZyWnpmNHRndVp5Y2ZRL3N4?= =?utf-8?B?VWdvTXRUaVc2S0FwNWdxc2VKNEN3WFhXa0ZiTC9neTZwT0JzcTRWdlVKTmZu?= =?utf-8?B?Lyt0VmoyRTJqWDJ3VTVIZWhGYnh1ODg0M3lsdXA4aVFsTlpWdm9sT0RwaXpM?= =?utf-8?B?YllVN1B2T2lIRC95aGRrV05DcUNWbzdSNFhaMWJ5NHlSRHQ2MWJaYWZ4Q3RH?= =?utf-8?B?M2ltRWx3VHRyMVJRclVNbmx6c3BIWTFCVzdYZy9od3MybWZabDhWSFdUQXdU?= =?utf-8?B?b1N6TjdSOUMxTkZzbUR0YlV5WE5XbndhODVVekt1aElmdFpkbkVlQXlhVlEz?= =?utf-8?B?RnZTMGlVQnJjQmtjSDZsa0UrUERMS013VkltN2JFWHlyWVR6UUFjbDV5cDV0?= =?utf-8?B?VThLMytZbUoyOFdKWHZZdU9GZmNMNUtCK3h5dG9FRFBXSVo4bytybE9YQ1hD?= =?utf-8?B?ZWx6eGs2Q0o3dHY2c0J1NTBGZDUrSFRsejQzZGNRNkVlbEwxYk9NUUppLzRX?= =?utf-8?B?Wm1DSDNuL1dzSXVqcURaQ3lBQ0dUcGZMUStvYXcxakV4VzVuTkxiV2UyYXA5?= =?utf-8?B?SWZpWnViWUVtZUNLcndEZWd4enhBRUVHcGl4UmpaMmNNdGRRcU5uUGoxSjlm?= =?utf-8?B?L2RZU2VFeXBxTVZCT0lXRUpUcHFFT1NEeENtY2NOWmxzVlR6dHZkMVRYQ0sv?= =?utf-8?B?L3VobE9lRndaMVFTVGNleW5NOGJnU3B0SGZRRUhLRUFPanFGVHVHK01Ldm5s?= =?utf-8?B?MGsyRm9LY2dCc01hallnUXpUU1k3cVJlZ2RFRUdOZUQ2bFVQb0JMaFNEbGJz?= =?utf-8?B?MEhMREZWZkZoN0ZrZkNHMGkvRFN4U3ZsS2kreW5WZEJXaW9LUDcvbC83aEtt?= =?utf-8?B?b3c4bjRxSm80bjRZdDdiN2FJK0F6TytNS0E1ZDNaMUEwY0ZrWHFJQ2J6T2Zi?= =?utf-8?B?TDRyLzQ4R3NEUGpnTmNPNEVCVkZGc3pPVW9VYXVlZ051eHVMcUhUOW9uOG54?= =?utf-8?B?eVVvZG9WQmJ4YitSTmJVc01Femc1VnpXaEF6T3hsRzNJOHZ2RVREVHVuSDFC?= =?utf-8?B?bWpMMWM5My9pOUREbjF6dk9SbXlPNkE2dEpkWXFSaUdzY2p0RHEvcXF1N3d2?= =?utf-8?B?cjJxZURjU0tNTHRjMlpSeERsdTBuNEt2NjFmckVLSE9ST0pkVHEwbXJhTFpw?= =?utf-8?B?RFNlR0hRUkpFMVdFcm11NG9WUWV1UDdCUDZodHlYd25IaEUwVTZzT09pUWtS?= =?utf-8?B?aTNMM0ZxaGR6RGdMS3JyUWdoTTNuYTdqcGVmSlZnWGtnbExkRytZTWhaRE9y?= =?utf-8?B?ellHWUg4V3I2aytCanp4Rk9BQUlwS1pMTm1wYVFWdWkxSWhBcTlDYktVbFl0?= =?utf-8?B?MFd1TURFSWJmVkUxdEZsMjE5K1YzYWhFWFNGRlQwTTY5ZkUvU2dEZm9sa3la?= =?utf-8?B?SUIvVmdsa0RrN0tRV2poMEk0Qnl2OWFyd3U0VllxamROUXBjaTFuTkI2dUZv?= =?utf-8?B?SVBpMmIrc1hXeGRabWdnSTFtVGdFTEpXVUlvMlo5TmNyd3BQcWtuVVV1d0xW?= =?utf-8?B?OEtFSGh4SHcrMjVYa0lJS2IyTUlBb3pDMmRTTk5vd203a0p0cmlPMUFxeXJl?= =?utf-8?B?elRhcmoyUmJSOURhcHdqUXpFWXFoK1JUYzZwbEV1ZG9SQUdEN0dOV1EvOHNt?= =?utf-8?B?YkZabWEwNFYxamlDRlpTaDJvUHFOUEprNi9FMDlYVFMyVkgzQlRuUmR3WlRa?= =?utf-8?B?cHpiR2t4bUc4UytIWXZndDVjQjdtdjB6RW1pWXZQR3Z2Y3NFcGNVRlpRWXdw?= =?utf-8?B?UEJvVkQ5bks0L3FxdkJGRE5DTnU5ak9HL2FXTjgyc1grTERWc0t4WDdHcTRo?= =?utf-8?B?c3YxUWpsTXFUd1JOMlBnTFp0K2NOeEtwNzVkOGc3MENyK1plODdmeE9SaEZ4?= =?utf-8?B?WDdQWmlXVEdzd01SR3VvUUNuVC91eDNJKzNVRC9hb2hmVFhKc3c0bTV1eWxX?= =?utf-8?Q?2jLaDl?= x-microsoft-antispam-prvs: x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(136003)(39860400002)(189003)(199004)(13464003)(53936002)(476003)(102836004)(236005)(2906002)(71200400001)(71190400001)(66574012)(4326008)(790700001)(53546011)(6506007)(229853002)(186003)(46003)(6116002)(5660300002)(486006)(446003)(11346002)(9686003)(6436002)(33656002)(6306002)(55016002)(54896002)(25786009)(6346003)(81156014)(22452003)(478600001)(86362001)(316002)(54906003)(14454004)(74316002)(110136005)(93886005)(105586002)(8676002)(106356001)(10290500003)(86612001)(76176011)(14444005)(256004)(7696005)(6246003)(97736004)(10090500001)(8990500004)(99286004)(7736002)(8936002)(68736007)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0856; H:CY4PR21MB0854.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lEUs1eVCXg//VylrjqshqirOHXtbl9xQYnFu6oZTMHa3xpFHUGpT5NEyR2W43NHiLJ4tEOmRGadQW1RKJvDo7PuzLeu3r0THsbeNMuoJX05GJRCkkHWvcsjm1BCbr7Cbb7QHL7a/0+9EkP9zdorUo9y/FKuHCa4q+v7J4ZIsZAVXbxgeJZvkdx7By8CpLjlaRsWxIQJD1na5GVUy10yRegUnOvtN84eN0BoHCIeHs4Wufbtqr7jS8UBJ7588/pKB0rKiVnwMbyUnqyX9GLnTalDCN3Rl9IFOOLcswm09k2wMWudwc5G1h6Dj5114teq2+6/nQSxgF3BDJUxPOp96vY0jojQR8jbS+yOXdYs/YqnHIE3YuVNcV4+v3CHqK96gVLZmUfouKJ5FTpm5A22iNDAaY3lZcS9JBxvECrC1tjI= Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0854ECFAAB302C7C8B488C97B37D0CY4PR21MB0854namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: db2ffb22-f183-461c-0abd-08d6976565a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 18:58:27.1317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0856 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 18:58:32 -0000 --_000_CY4PR21MB0854ECFAAB302C7C8B488C97B37D0CY4PR21MB0854namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGJlc3QgdGhpbmcgSSBjb3VsZCB0aGluayBvZiBpcyBzb21lIGNsaWVudCBzaWRlIGxvZ2lj IHRoYXQgaGFzIGEgdGltZXIgdG8gd2FpdCBmb3IgYSBwb3NzaWJsZSB2YWxpZCBzZXJ2ZXIgcmVz cG9uc2UgZm9yIHNvbWUgc2hvcnQgdGltZSBhZnRlciBpdCByZWNlaXZlcyB0aGUgY29ubiBjbG9z ZSBmcmFtZS4gSWYgaXQgY29tZXMsIGlnbm9yZSB0aGUgY2xvc2UuDQoNCi0gTmljaw0KDQpGcm9t OiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+DQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDIwLCAyMDE5IDEwOjUyIEFNDQpUbzogQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVp dGVtYS5uZXQ+DQpDYzogVMO2bWEgR2F2cmljaGVua292IDx4aW1hZXJhQGdtYWlsLmNvbT47IE5p Y2sgQmFua3MgPG5pYmFua3NAbWljcm9zb2Z0LmNvbT47IEJyaWFuIFRyYW1tZWxsIChJRVRGKSA8 aWV0ZkB0cmFtbWVsbC5jaD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1pcmphIEvD vGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+DQpTdWJqZWN0OiBSZTog RXhwZWN0ZWQgQ2xpZW50IFJlc3BvbnNlIHRvIFNFUlZFUl9CVVNZDQoNCkFncmVlZCBpdCdzIG5v dCBhbWF6aW5nLCBidXQgc3RhdGVsZXNzIHJlc2V0IGlzbid0IGF2YWlsYWJsZSB1bnRpbCB0aGUg aGFuZHNoYWtlIGNvbXBsZXRlcy4gIERpZCB5b3UgaGF2ZSBhbnkgc3VnZ2VzdGlvbnM/DQoNCk9u IFdlZCwgRmViIDIwLCAyMDE5IGF0IDE6NDkgUE0gQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFA aHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PiB3cm90ZToNCkNhbiB3ZSBk byBiZXR0ZXIgdGhhbiBhbiB1bmF1dGhlbnRpY2F0ZWQgc2lnbmFsIHRvICJkcm9wIFFVSUMNCmlt bWVkaWF0ZWx5IGFuZCB1c2Ugc29tZXRoaW5nIGVsc2UiPw0KDQpJIHVuZGVyc3RhbmQgdGhlIGRl c2lyZSBvZiBwcm90ZWN0aW5nIHNlcnZlcnMgYWdhaW5zdCBET1MgYXR0YWNrcywgYnV0DQp0aGUg cHJvcG9zaXRpb24gaGVyZSBhbGxvd3MgYSBtaWRkbGUtYm94IG9yIGEgbWFuLW9uLXRoZS1zaWRl IHRvIHNlbmQgYW4NCnVuZW5jcnlwdGVkIHNpZ25hbCBhbmQgaGF2ZSB0aGUgY2xpZW50IGltbWVk aWF0ZWx5IGltbWVkaWF0ZWx5IGRyb3AgdGhlDQpjb25uZWN0aW9uLiBUaGF0IGRvZXMgbm90IGZl ZWwgcmlnaHQuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0KT24gMi8yMC8yMDE5IDc6Mzgg QU0sIFTDtm1hIEdhdnJpY2hlbmtvdiB3cm90ZToNCj4gSSBtZWFuLCB5ZXMsIGhhbmRsaW5nIHN1 Y2ggYSBjYXNlIGV4cGxpY2l0bHkgdG90YWxseSBtYWtlcyBzZW5zZS4gSQ0KPiBqdXN0IHdhbnRl ZCB0byBwb2ludCBvdXQgdGhhdCB0aGVyZSdzIGFuIGFkZGl0aW9uYWwgdXNlIGNhc2Ugd2hlbiBV RFANCj4gdHJhbnNtaXNzaW9uIGp1c3Qgc3VkZGVubHkgc3RvcHMgdW5kZXIgYW4gYXR0YWNrLg0K Pg0KPiBOb3RlIHRoYXQgYSBERG9TIGF0dGFjayB0b3dhcmRzIGEgUVVJQyBzZXJ2ZXIgaXNuJ3Qg dGhlIG9ubHkgcG9zc2libGUNCj4gc2NlbmFyaW8sIHRoZSBvdGhlciBvbmUgYmVpbmcgYSBERG9T IHRvd2FyZHMgYSBjbGllbnQuIEluIHRoZSBsYXR0ZXINCj4gc2NlbmFyaW8sIGdpdmVuIHRoZSBu b3Qtc28tbGlrZWx5LWJ1dC1jb21wbGV0ZWx5LXBvc3NpYmxlIGNhc2Ugd2hlbiBhDQo+IG5ld2x5 IGRpc2NvdmVyZWQgRERvUyBhbXBsaWZ5aW5nIHByb3RvY29sIHdvdWxkIGJlIHVzaW5nIHBvcnQg NDQzL3VkcCwNCj4gZXZlbiBzZWxlY3RpdmUgYmxhY2tob2xpbmcgd29uJ3QgaGVscCB0byBwcmVz ZXJ2ZSBRVUlDIGNvbm5lY3Rpdml0eS4NCj4gQXMgYSBtYXR0ZXIgb2YgZmFjdCwgdGhlcmUncyBu byB3YXkgdG8gaGFuZGxlIGl0DQo+IHRyYW5zcG9ydC1wcm90b2NvbC13aXNlLCBidXQgbWF5YmUg YWRkaW5nIGEgdGltZW91dC1yZWxhdGVkIHN1Z2dlc3Rpb24NCj4gb2YgYSBTSE9VTEQgQ09OU0lE RVIgc3R5bGUgdG8gdGhlIHNwZWMgd291bGQgYmUgYSBnb29kIGlkZWEuDQo+DQo+IHwgVMO2bWEg R2F2cmljaGVua292DQo+IHwgZ3BnOiAyZGViIDk3YjEgMGEzYyAxNTFkIGI2N2YgMWVlNSAwMGU3 IDk0YmMgNGQwOCA5MTkxDQo+IHwgbWFpbHRvOiB4aW1hZXJhQGdtYWlsLmNvbTxtYWlsdG86eGlt YWVyYUBnbWFpbC5jb20+DQo+IHwgZmI6IHhpbWFlcmENCj4gfCB0ZWxlZ3JhbTogeGltYV9lcmEN Cj4gfCBza3lwZTogeGltYV9lcmENCj4gfCB0ZWwuIG5vOiArNyA5MTYgNTE1IDQ5IDU4DQo+DQo+ IE9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDc6MTkgQU0gTmljayBCYW5rcyA8bmliYW5rc0BtaWNy b3NvZnQuY29tPG1haWx0bzpuaWJhbmtzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4+IEkgd2Fu dCB0byBzdXBwb3J0IHNvbWV0aGluZyBhIGJpdCBtb3JlIGVmZmljaWVudCB0aGFuIHNpbXBsZSBy YXRlIGxpbWl0aW5nIGFuZCBwYWNrZXQgZHJvcHMuIFRoZSBjbGllbnQgbWlnaHQgaGF2ZSByZWxh dGl2ZWx5IGxhcmdlIHRpbWVvdXQgaW4gdGhhdCBjYXNlIGJlZm9yZSBmYWxsaW5nIGJhY2sgdG8g VENQLiBJZiBwb3NzaWJsZSwgSSB3YW50IHRvIGJlIGFibGUgdG8gZ2l2ZSBhbiBpbW1lZGlhdGUg aW5kaWNhdGlvbiB0aGF0IGl0IHNob3VsZCB0cnkgdG8gZmFsbGJhY2suDQo+Pg0KPj4gLSBOaWNr DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFTDtm1hIEdhdnJp Y2hlbmtvdiA8eGltYWVyYUBnbWFpbC5jb208bWFpbHRvOnhpbWFlcmFAZ21haWwuY29tPj4NCj4+ IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjAsIDIwMTkgNzowNCBBTQ0KPj4gVG86IE5pY2sg QmFua3MgPG5pYmFua3NAbWljcm9zb2Z0LmNvbTxtYWlsdG86bmliYW5rc0BtaWNyb3NvZnQuY29t Pj4NCj4+IENjOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0 QGdvb2dsZS5jb20+PjsgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLi5jaDxt YWlsdG86aWV0ZkB0cmFtbWVsbC4uY2g+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1h aWx0bzpxdWljQGlldGYub3JnPj47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRA dGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+Pg0K Pj4gU3ViamVjdDogUmU6IEV4cGVjdGVkIENsaWVudCBSZXNwb25zZSB0byBTRVJWRVJfQlVTWQ0K Pj4NCj4+IE9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDY6NTAgQU0gTmljayBCYW5rcyA8bmliYW5r cz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBk bWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KPj4+IEl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBhIHdh eSBmb3IgdGhlIHNlcnZlciB0byBzYXkg4oCcUVVJQyBpcw0KPj4+IHRlbXBvcmFyaWx5IHVuYXZh aWxhYmxlIHJpZ2h0IG5vdywgcGxlYXNlIGdvIHVzZSBUQ1AgaW5zdGVhZC7igJ0NCj4+IE9uZSBp c3N1ZSBoZXJlIGlzIHRoYXQgdW5kZXIgYSBERG9TIGF0dGFjayBhbiBJU1Agd291bGQganVzdCBh cHBseSBzZWxlY3RpdmUgYmxhY2tob2xpbmcgb3IgZmxvdyBzcGVjaWZpY2F0aW9uIHdoaWNoIHdv dWxkIHNpbXBseSBkcm9wIGFsbCB0aGUgaW5jb21pbmcgVURQIHRyYWZmaWMgdG8gcHJvdGVjdCB0 aGUgbGFzdCBtaWxlLiBEZXBlbmRzIG9uIHRoZSBhdHRhY2sgcGF0dGVybiBzb21ld2hhdCwgc29t ZXRpbWVzIGJsYWNraG9saW5nIG1pZ2h0IGJlIG1vcmUgZ3JhbnVsYXIsIGJ1dCBhbGwgaW4gYWxs IHlvdSBzaG91bGQgZXhwZWN0IHRoYXQuDQo+Pg0KPj4gVGhlIG9ubHkgaG9wZSBoZXJlIGlzIHRo YXQgYSBjbGllbnQgd291bGQgaW50ZXJwcmV0IHJlc3BvbnNlIHRpbWVvdXQgaW4gdGhlIHNhbWUg d2F5IGFzIFNFUlZFUl9CVVNZLg0KPj4NCj4+IC0tDQo+PiBUw7ZtYQ0K --_000_CY4PR21MB0854ECFAAB302C7C8B488C97B37D0CY4PR21MB0854namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgYmVzdCB0aGluZyBJIGNvdWxkIHRoaW5rIG9mIGlzIHNvbWUgY2xpZW50IHNpZGUgbG9naWMg dGhhdCBoYXMgYSB0aW1lciB0byB3YWl0IGZvciBhIHBvc3NpYmxlIHZhbGlkIHNlcnZlciByZXNw b25zZSBmb3Igc29tZSBzaG9ydCB0aW1lIGFmdGVyIGl0IHJlY2VpdmVzIHRoZSBjb25uIGNsb3Nl IGZyYW1lLiBJZiBpdCBjb21lcywgaWdub3JlIHRoZSBjbG9zZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LSBOaWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBJYW4gU3dl dHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDIwLCAyMDE5IDEwOjUyIEFNPGJyPg0KPGI+VG86PC9iPiBDaHJpc3RpYW4g SHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IFTDtm1h IEdhdnJpY2hlbmtvdiAmbHQ7eGltYWVyYUBnbWFpbC5jb20mZ3Q7OyBOaWNrIEJhbmtzICZsdDtu aWJhbmtzQG1pY3Jvc29mdC5jb20mZ3Q7OyBCcmlhbiBUcmFtbWVsbCAoSUVURikgJmx0O2lldGZA dHJhbW1lbGwuY2gmZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBNaXJq YSBLw7xobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogRXhwZWN0ZWQgQ2xpZW50IFJlc3BvbnNlIHRvIFNFUlZFUl9C VVNZPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQgaXQncyBub3QgYW1hemlu ZywgYnV0IHN0YXRlbGVzcyByZXNldCBpc24ndCBhdmFpbGFibGUgdW50aWwgdGhlIGhhbmRzaGFr ZSBjb21wbGV0ZXMuJm5ic3A7IERpZCB5b3UgaGF2ZSBhbnkgc3VnZ2VzdGlvbnM/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAyMCwgMjAx OSBhdCAxOjQ5IFBNIENocmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVt YUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHdl IGRvIGJldHRlciB0aGFuIGFuIHVuYXV0aGVudGljYXRlZCBzaWduYWwgdG8gJnF1b3Q7ZHJvcCBR VUlDPGJyPg0KaW1tZWRpYXRlbHkgYW5kIHVzZSBzb21ldGhpbmcgZWxzZSZxdW90Oz88YnI+DQo8 YnI+DQpJIHVuZGVyc3RhbmQgdGhlIGRlc2lyZSBvZiBwcm90ZWN0aW5nIHNlcnZlcnMgYWdhaW5z dCBET1MgYXR0YWNrcywgYnV0PGJyPg0KdGhlIHByb3Bvc2l0aW9uIGhlcmUgYWxsb3dzIGEgbWlk ZGxlLWJveCBvciBhIG1hbi1vbi10aGUtc2lkZSB0byBzZW5kIGFuPGJyPg0KdW5lbmNyeXB0ZWQg c2lnbmFsIGFuZCBoYXZlIHRoZSBjbGllbnQgaW1tZWRpYXRlbHkgaW1tZWRpYXRlbHkgZHJvcCB0 aGU8YnI+DQpjb25uZWN0aW9uLiBUaGF0IGRvZXMgbm90IGZlZWwgcmlnaHQuPGJyPg0KPGJyPg0K LS0gQ2hyaXN0aWFuIEh1aXRlbWE8YnI+DQo8YnI+DQo8YnI+DQpPbiAyLzIwLzIwMTkgNzozOCBB TSwgVMO2bWEgR2F2cmljaGVua292IHdyb3RlOjxicj4NCiZndDsgSSBtZWFuLCB5ZXMsIGhhbmRs aW5nIHN1Y2ggYSBjYXNlIGV4cGxpY2l0bHkgdG90YWxseSBtYWtlcyBzZW5zZS4gSTxicj4NCiZn dDsganVzdCB3YW50ZWQgdG8gcG9pbnQgb3V0IHRoYXQgdGhlcmUncyBhbiBhZGRpdGlvbmFsIHVz ZSBjYXNlIHdoZW4gVURQPGJyPg0KJmd0OyB0cmFuc21pc3Npb24ganVzdCBzdWRkZW5seSBzdG9w cyB1bmRlciBhbiBhdHRhY2suPGJyPg0KJmd0Ozxicj4NCiZndDsgTm90ZSB0aGF0IGEgRERvUyBh dHRhY2sgdG93YXJkcyBhIFFVSUMgc2VydmVyIGlzbid0IHRoZSBvbmx5IHBvc3NpYmxlPGJyPg0K Jmd0OyBzY2VuYXJpbywgdGhlIG90aGVyIG9uZSBiZWluZyBhIEREb1MgdG93YXJkcyBhIGNsaWVu dC4gSW4gdGhlIGxhdHRlcjxicj4NCiZndDsgc2NlbmFyaW8sIGdpdmVuIHRoZSBub3Qtc28tbGlr ZWx5LWJ1dC1jb21wbGV0ZWx5LXBvc3NpYmxlIGNhc2Ugd2hlbiBhPGJyPg0KJmd0OyBuZXdseSBk aXNjb3ZlcmVkIEREb1MgYW1wbGlmeWluZyBwcm90b2NvbCB3b3VsZCBiZSB1c2luZyBwb3J0IDQ0 My91ZHAsPGJyPg0KJmd0OyBldmVuIHNlbGVjdGl2ZSBibGFja2hvbGluZyB3b24ndCBoZWxwIHRv IHByZXNlcnZlIFFVSUMgY29ubmVjdGl2aXR5Ljxicj4NCiZndDsgQXMgYSBtYXR0ZXIgb2YgZmFj dCwgdGhlcmUncyBubyB3YXkgdG8gaGFuZGxlIGl0PGJyPg0KJmd0OyB0cmFuc3BvcnQtcHJvdG9j b2wtd2lzZSwgYnV0IG1heWJlIGFkZGluZyBhIHRpbWVvdXQtcmVsYXRlZCBzdWdnZXN0aW9uPGJy Pg0KJmd0OyBvZiBhIFNIT1VMRCBDT05TSURFUiBzdHlsZSB0byB0aGUgc3BlYyB3b3VsZCBiZSBh IGdvb2QgaWRlYS48YnI+DQomZ3Q7PGJyPg0KJmd0OyB8IFTDtm1hIEdhdnJpY2hlbmtvdjxicj4N CiZndDsgfCBncGc6IDJkZWIgOTdiMSAwYTNjIDE1MWQgYjY3ZiAxZWU1IDAwZTcgOTRiYyA0ZDA4 IDkxOTE8YnI+DQomZ3Q7IHwgbWFpbHRvOiA8YSBocmVmPSJtYWlsdG86eGltYWVyYUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj54aW1hZXJhQGdtYWlsLmNvbTwvYT48YnI+DQomZ3Q7IHwgZmI6 IHhpbWFlcmE8YnI+DQomZ3Q7IHwgdGVsZWdyYW06IHhpbWFfZXJhPGJyPg0KJmd0OyB8IHNreXBl OiB4aW1hX2VyYTxicj4NCiZndDsgfCB0ZWwuIG5vOiAmIzQzOzcgOTE2IDUxNSA0OSA1ODxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDc6MTkgQU0gTmljayBCYW5r cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm5pYmFua3NAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7IEkg d2FudCB0byBzdXBwb3J0IHNvbWV0aGluZyBhIGJpdCBtb3JlIGVmZmljaWVudCB0aGFuIHNpbXBs ZSByYXRlIGxpbWl0aW5nIGFuZCBwYWNrZXQgZHJvcHMuIFRoZSBjbGllbnQgbWlnaHQgaGF2ZSBy ZWxhdGl2ZWx5IGxhcmdlIHRpbWVvdXQgaW4gdGhhdCBjYXNlIGJlZm9yZSBmYWxsaW5nIGJhY2sg dG8gVENQLiBJZiBwb3NzaWJsZSwgSSB3YW50IHRvIGJlIGFibGUgdG8gZ2l2ZSBhbiBpbW1lZGlh dGUgaW5kaWNhdGlvbiB0aGF0IGl0IHNob3VsZA0KIHRyeSB0byBmYWxsYmFjay48YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IC0gTmljazxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBUw7ZtYSBHYXZyaWNo ZW5rb3YgJmx0OzxhIGhyZWY9Im1haWx0bzp4aW1hZXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnhpbWFlcmFAZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyBTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDIwLCAyMDE5IDc6MDQgQU08YnI+DQomZ3Q7Jmd0OyBUbzogTmljayBCYW5r cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm5pYmFua3NAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgQ2M6IElhbiBT d2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDs7IEJyaWFuIFRyYW1tZWxsIChJRVRGKSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwuLmNoIj5pZXRmQHRyYW1tZWxsLi5jaDwv YT4mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7Ow0KIE1pcmphIEvDvGhsZXdpbmQg Jmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIiB0YXJn ZXQ9Il9ibGFuayI+bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsgU3ViamVjdDogUmU6IEV4cGVjdGVkIENsaWVudCBSZXNwb25zZSB0byBTRVJWRVJf QlVTWTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gV2VkLCBGZWIgMjAsIDIwMTkgYXQg Njo1MCBBTSBOaWNrIEJhbmtzICZsdDtuaWJhbmtzPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgSXQgd291bGQgYmUg bmljZSB0byBoYXZlIGEgd2F5IGZvciB0aGUgc2VydmVyIHRvIHNheSDigJxRVUlDIGlzPGJyPg0K Jmd0OyZndDsmZ3Q7IHRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlIHJpZ2h0IG5vdywgcGxlYXNlIGdv IHVzZSBUQ1AgaW5zdGVhZC7igJ08YnI+DQomZ3Q7Jmd0OyBPbmUgaXNzdWUgaGVyZSBpcyB0aGF0 IHVuZGVyIGEgRERvUyBhdHRhY2sgYW4gSVNQIHdvdWxkIGp1c3QgYXBwbHkgc2VsZWN0aXZlIGJs YWNraG9saW5nIG9yIGZsb3cgc3BlY2lmaWNhdGlvbiB3aGljaCB3b3VsZCBzaW1wbHkgZHJvcCBh bGwgdGhlIGluY29taW5nIFVEUCB0cmFmZmljIHRvIHByb3RlY3QgdGhlIGxhc3QgbWlsZS4gRGVw ZW5kcyBvbiB0aGUgYXR0YWNrIHBhdHRlcm4gc29tZXdoYXQsIHNvbWV0aW1lcyBibGFja2hvbGlu ZyBtaWdodA0KIGJlIG1vcmUgZ3JhbnVsYXIsIGJ1dCBhbGwgaW4gYWxsIHlvdSBzaG91bGQgZXhw ZWN0IHRoYXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgb25seSBob3BlIGhlcmUg aXMgdGhhdCBhIGNsaWVudCB3b3VsZCBpbnRlcnByZXQgcmVzcG9uc2UgdGltZW91dCBpbiB0aGUg c2FtZSB3YXkgYXMgU0VSVkVSX0JVU1kuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLTxi cj4NCiZndDsmZ3Q7IFTDtm1hPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB0854ECFAAB302C7C8B488C97B37D0CY4PR21MB0854namp_-- From nobody Wed Feb 20 11:43:31 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13842130E7E for ; Wed, 20 Feb 2019 11:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 205RuF3FUfjf for ; Wed, 20 Feb 2019 11:43:28 -0800 (PST) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 4471F130E6A for ; Wed, 20 Feb 2019 11:43:28 -0800 (PST) Received: by mail-yw1-xc32.google.com with SMTP id q128so9673623ywg.8 for ; Wed, 20 Feb 2019 11:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vmZShSUwoPlGZeDNkSiIj1ZPEOirjJ41lUey0+/ji5M=; b=RCPKvhquKSzjYhv29fn0i3dhd0L9Us8Oa28wUsZuQoKSVq5yKGhVwnfdOWf3ioVab7 xPqB1BTmz0gexvfazX78Wji6CFnkPpUhziwG2QtL1Zy8aRq0xqQu/Ha/f320araTaJ8X AQUrzQtATuI1UK47TswhlCLe6jOgX4yyBTrEfpl9chF9ILJZ9qjs+lGr0P1l5v8K0Fy0 mxSNmuRFh0ZugaiK/XTI5d4yWG+BNyaNRQSTrYyBO0aqs1Dby+38GXuZaw65znKX9bJv PdQlAGOf169HgOUO+SlBm6Zc1irUZmY6nJCVsgjzzfD+bWE/blWDgeJXuBDvcypbarl6 OF0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vmZShSUwoPlGZeDNkSiIj1ZPEOirjJ41lUey0+/ji5M=; b=mU19VdO8EfujuaNWZ/30ojC3CHL0U970HiY8WHLEt834aeKdFKxNnJwM8UvJPq0XkM /Bl/zOW8xiLOOn4UCryBbRXYFxCCTIe92i3R4n2c/WrmF5pC1cQ2sz5quowC69zAr5rT 0sMRtLmuWyM6hV5CpKyi/w+A+rGH0ocGSdNzAbimNzWWhRNehsP74fgrEtkjCycy1NMa PtTyjgAuNrsFGw98jPcPG3A1qdQX9W4Jyw6id89DyGbla4R76ogkW+8TkoUZRW2wa6hq rSdhpH5bU3SffkBbDIRt/z+W3OmJ1uRrs1mx+ZvYPraWeDav58pNp7fcYODCqbpOREwC MGJg== X-Gm-Message-State: AHQUAubbC+dnllaRTQn4cK0drkABJzhDdvXPN4gHu3qeMuKiWUwiDgq0 bmagbcJ75Rtdc5YnGO1ng+2T1bd9JJd34VesBlg= X-Google-Smtp-Source: AHgI3IZOCVgJGsXYFKbLnjE5oMHTTZXXUeFOyxCyoE8vipsDyQoPmmAVveDstYcK/dG1rD+KoPo82jrTsDLH8oy+KMc= X-Received: by 2002:a81:6b09:: with SMTP id g9mr18003803ywc.255.1550691807100; Wed, 20 Feb 2019 11:43:27 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Wed, 20 Feb 2019 11:43:08 -0800 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Christian Huitema Cc: Nick Banks , "Brian Trammell (IETF)" , Ian Swett , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 19:43:30 -0000 On Wed, Feb 20, 2019 at 10:49 AM Christian Huitema wr= ote: > the proposition here allows a middle-box or a man-on-the-side to send an > unencrypted signal and have the client immediately immediately drop the > connection. That does not feel right. A man-on-the-side (don't even mentioning a box-in-the-middle) could *always* make a client drop a connection, e.g., by sending a large amount of junk packets towards the client that the client would be unable to correctly handle. It's just a matter of how much harm does that box need to do to the network. Any opposite approach I can think of requires to put the private key of the server on a DDoS handling machine or to deploy it onto a DDoS mitigation cloud, which not only increases exposure of the users' data but is also explicitly forbidden in certain countries for companies from certain industries. It's already only narrowly possible to avoid doing so with QUIC (and that already requires either a collaboration between the QUIC library supplier and the DDoS mitigation vendor =E2=80=94 which in turn leads to vendor lock =E2=80=94 or a reverse engineering-based design), so until we have a v2 which is (hopefully) more LB and DDoS-aware, this is the lesser of two evils. -- T=C3=B6ma From nobody Wed Feb 20 12:49:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9091A130E91 for ; Wed, 20 Feb 2019 12:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=OkIz2rWj; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=A0eeNkV4 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 fMAhrvEc01DI for ; Wed, 20 Feb 2019 12:49:16 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFC1130E7E for ; Wed, 20 Feb 2019 12:49:16 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1KKlB2A029410; Wed, 20 Feb 2019 12:49:07 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=T1p+//s4ug4TxM/Ifn2X455d30Jb9n/CoDsilpo8hjs=; b=OkIz2rWjmMglifG7zUAhVLv+PdeLQ+1Xa/qxmapqPULLh0I2h2Op8rthgykimsAFeHn2 mMEM6QbpiX2fVhKqH9v+yd3JNJac8qxqJz+xA8eDm2J8nKp6CwfmSBV57P4eUWMeJvkk AmJsnSearaZSCPBBpqZieAKx/Dz5+Iiy5Qo= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qse1u81hy-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Feb 2019 12:49:07 -0800 Received: from prn-mbx03.TheFacebook.com (2620:10d:c081:6::17) by prn-hub01.TheFacebook.com (2620:10d:c081:35::125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 20 Feb 2019 12:47:58 -0800 Received: from prn-hub01.TheFacebook.com (2620:10d:c081:35::125) by prn-mbx03.TheFacebook.com (2620:10d:c081:6::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 20 Feb 2019 12:47:58 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Wed, 20 Feb 2019 12:47:58 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T1p+//s4ug4TxM/Ifn2X455d30Jb9n/CoDsilpo8hjs=; b=A0eeNkV4QcoqYPk9PNxmhS+m1rJv/ilJDs4+fKB4oVTN8Pm7dq/uccSEZGdF/KoBm1vaYNKb/XZPn8HrZsGIEwA8Lmpm93XzKrbe8aGTV9iqY9P9n9tSpb5hGqNFALA67+iZ3vPdMEK6PxVfZOw6vw4S5APAiNhbzAwvzVp0Z0c= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB3478.namprd15.prod.outlook.com (20.179.60.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.20; Wed, 20 Feb 2019 20:47:57 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084%5]) with mapi id 15.20.1622.018; Wed, 20 Feb 2019 20:47:57 +0000 From: Roberto Peon To: =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= , "Christian Huitema" CC: Nick Banks , "Brian Trammell (IETF)" , Ian Swett , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: Re: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: AdTInrfRZAbJSsLZSlWCCrlUkiWX7AAgkIeAAACdzgAAAbynAAAAN6coAACOYoAAAIKXwAAAszQAAAatwwAAAd27AP//i/wA Date: Wed, 20 Feb 2019 20:47:57 +0000 Message-ID: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::6:a040] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2a0e146-2649-4c16-ed66-08d69774b1a0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB3478; x-ms-traffictypediagnostic: BYAPR15MB3478: x-microsoft-exchange-diagnostics: 1; BYAPR15MB3478; 20:/IoGvTMfBItzXPFipv6hyNqDUvgkCf0o/NalTDT9uRUscGpjIJMcZDQsyP+MibDpMZiLbxEHbBAI8Jw4npTNyIYKPprvynAwmYiiwmRwBBj7HMJg9FPWNc2YQNRpRwwtN28128k7PBtJ6DW9ZxDfnRKgS0IpRQ7rREKlk2OTSAQ= x-microsoft-antispam-prvs: x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(136003)(396003)(39860400002)(199004)(189003)(53824002)(93886005)(83716004)(58126008)(71200400001)(54906003)(256004)(76176011)(5660300002)(14444005)(71190400001)(105586002)(4326008)(25786009)(476003)(106356001)(8676002)(305945005)(6246003)(53936002)(7736002)(66574012)(2616005)(110136005)(316002)(486006)(446003)(11346002)(86362001)(6116002)(81156014)(6436002)(46003)(68736007)(229853002)(6512007)(102836004)(2906002)(6486002)(97736004)(36756003)(82746002)(81166006)(53546011)(6506007)(186003)(478600001)(99286004)(14454004)(33656002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB3478; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7ETkW4B7Bz4pjiblBmI7wxQsGd0NEoGjl2mJSdAXDOVvNei1Onzhf6DVjks1NAs6Q6Bl2CDL92YhwwOIF6XQuPiFWuvIoxBDJDV1vNb2wqVSpUJeARJXs+l/3Z6SK8Nv5Ve7e8FjcqDxLgICnGtOYKRSErD/uwUymNXj35w0neCnveAUrWvr3BpSzfE22aR5kEqanHfwOFSVNUMNlJBVEgBLTQm3/ly8XmkHyvqckXZfp71m7af2LS2R56R4zYJUs1KQRx2OZjR5st0RpTFF8R785Uv510lzH7ZJVpY0uUJwmm7ZP3SQblMcjaL3XMbt+/kBEN390sd9OYvMWr3c4gPhJ0mg698D7djQN302UVYJypBAxbjaKDxfAAE/AMP7omYJhtY3hOIneHV+QhlJ8kTO4fSnUcHZ0CQBIbdpxQE= Content-Type: text/plain; charset="utf-8" Content-ID: <9A6DA136ED05244285BBABB99A07576F@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c2a0e146-2649-4c16-ed66-08d69774b1a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 20:47:57.0577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3478 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-20_16:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 20:49:19 -0000 SSBiZWxpZXZlIHRoYXQgdGhlIHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbSAod2hhdCBhIGNsaWVu dCBkb2VzIHdoZW4gdGhlIHNlcnZlciBpcyBiZWluZyBEb1MnZCkgaXMgaW5oZXJlbnRseSBvdXQt b2YtYmFuZCwgYW5kIHRodXMgbm90IHBhcnQgb2YgdGhlIFFVSUMgcHJvdG9jb2wuDQoNCkNsaWVu dHMgc2hvdWxkIGRvIHdoYXRldmVyIHRoZXkgd2FudCB0byBkbyBhcyBhIHJlc3BvbnNlIHRvIFNF UlZFUl9CVVNZLiBXZSBjYW4ndCBtYWtlIHRoZSBtYWxpY2lvdXMgb25lcyBzdG9wLCBhbmQgYW55 dGhpbmcgd2UgZG8gdG8gYWxsb3cgbm9uLW1hbGljaW91cyBvbmVzIHRvIHJlc3BvbmQgYXBwcm9w cmlhdGVseSByZXF1aXJlcyBwcmUtc2hhcmluZyBvZiBzb21ldGhpbmcsIG9yIGZvciB0aGUgY29u bmVjdGlvbiB0byBzdWNjZWVkICh3aGljaCBpcyBlc3NlbnRpYWxseSBlc3RhYmxpc2hpbmcgYSBj b250ZXh0IGZvciBzdWNoIHNoYXJpbmcpLg0KDQpEZXNpZ25pbmcgcG9saWN5IGFyb3VuZCB0aGF0 IGlzIHByb2JhYmx5IGZvZGRlciBmb3IgYW5vdGhlciBkaXNjdXNzaW9uICh0aGF0IEkgaG9wZSB3 ZSBnZXQgdG9nZXRoZXIgYW5kIGhhdmUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIEhUVFAgd2cpLg0K DQotPVINCg0K77u/T24gMi8yMC8xOSwgMTE6NDQgQU0sICJRVUlDIG9uIGJlaGFsZiBvZiBUw7Zt YSBHYXZyaWNoZW5rb3YiIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHhpbWFl cmFAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIE9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDEwOjQ5 IEFNIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PiB3cm90ZToNCiAgICA+ IHRoZSBwcm9wb3NpdGlvbiBoZXJlIGFsbG93cyBhIG1pZGRsZS1ib3ggb3IgYSBtYW4tb24tdGhl LXNpZGUgdG8gc2VuZCBhbg0KICAgID4gdW5lbmNyeXB0ZWQgc2lnbmFsIGFuZCBoYXZlIHRoZSBj bGllbnQgaW1tZWRpYXRlbHkgaW1tZWRpYXRlbHkgZHJvcCB0aGUNCiAgICA+IGNvbm5lY3Rpb24u IFRoYXQgZG9lcyBub3QgZmVlbCByaWdodC4NCiAgICANCiAgICBBIG1hbi1vbi10aGUtc2lkZSAo ZG9uJ3QgZXZlbiBtZW50aW9uaW5nIGEgYm94LWluLXRoZS1taWRkbGUpIGNvdWxkDQogICAgKmFs d2F5cyogbWFrZSBhIGNsaWVudCBkcm9wIGEgY29ubmVjdGlvbiwgZS5nLiwgYnkgc2VuZGluZyBh IGxhcmdlDQogICAgYW1vdW50IG9mIGp1bmsgcGFja2V0cyB0b3dhcmRzIHRoZSBjbGllbnQgdGhh dCB0aGUgY2xpZW50IHdvdWxkIGJlDQogICAgdW5hYmxlIHRvIGNvcnJlY3RseSBoYW5kbGUuIEl0 J3MganVzdCBhIG1hdHRlciBvZiBob3cgbXVjaCBoYXJtIGRvZXMNCiAgICB0aGF0IGJveCBuZWVk IHRvIGRvIHRvIHRoZSBuZXR3b3JrLg0KICAgIA0KICAgIEFueSBvcHBvc2l0ZSBhcHByb2FjaCBJ IGNhbiB0aGluayBvZiByZXF1aXJlcyB0byBwdXQgdGhlIHByaXZhdGUga2V5DQogICAgb2YgdGhl IHNlcnZlciBvbiBhIEREb1MgaGFuZGxpbmcgbWFjaGluZSBvciB0byBkZXBsb3kgaXQgb250byBh IEREb1MNCiAgICBtaXRpZ2F0aW9uIGNsb3VkLCB3aGljaCBub3Qgb25seSBpbmNyZWFzZXMgZXhw b3N1cmUgb2YgdGhlIHVzZXJzJyBkYXRhDQogICAgYnV0IGlzIGFsc28gZXhwbGljaXRseSBmb3Ji aWRkZW4gaW4gY2VydGFpbiBjb3VudHJpZXMgZm9yIGNvbXBhbmllcw0KICAgIGZyb20gY2VydGFp biBpbmR1c3RyaWVzLiBJdCdzIGFscmVhZHkgb25seSBuYXJyb3dseSBwb3NzaWJsZSB0byBhdm9p ZA0KICAgIGRvaW5nIHNvIHdpdGggUVVJQyAoYW5kIHRoYXQgYWxyZWFkeSByZXF1aXJlcyBlaXRo ZXIgYSBjb2xsYWJvcmF0aW9uDQogICAgYmV0d2VlbiB0aGUgUVVJQyBsaWJyYXJ5IHN1cHBsaWVy IGFuZCB0aGUgRERvUyBtaXRpZ2F0aW9uIHZlbmRvciDigJQNCiAgICB3aGljaCBpbiB0dXJuIGxl YWRzIHRvIHZlbmRvciBsb2NrIOKAlCBvciBhIHJldmVyc2UgZW5naW5lZXJpbmctYmFzZWQNCiAg ICBkZXNpZ24pLCBzbyB1bnRpbCB3ZSBoYXZlIGEgdjIgd2hpY2ggaXMgKGhvcGVmdWxseSkgbW9y ZSBMQiBhbmQNCiAgICBERG9TLWF3YXJlLCB0aGlzIGlzIHRoZSBsZXNzZXIgb2YgdHdvIGV2aWxz Lg0KICAgIA0KICAgIC0tDQogICAgVMO2bWENCiAgICANCiAgICANCg0K From nobody Wed Feb 20 13:02:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD091128AFB for ; Wed, 20 Feb 2019 13:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 GtJOP65eixze for ; Wed, 20 Feb 2019 13:02:20 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740095.outbound.protection.outlook.com [40.107.74.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD2D12894E for ; Wed, 20 Feb 2019 13:02:19 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=kPYa299KZD5DRVeFcwTS0vpu+vHOxWZfJ4iiD17Js4M=; b=Fxx/+4w8o5xteW+vVKDRMvmfcs+NDGCffwdxUeU5GHtrA5oiYIBqLnHg1FP1sOUwSUKb0D2FaHG9g0KI2OPAgV67ctzp9v/qkYvhqmN6AUvDD02uCjDgJ3QKnjs2fAOOm4sD/zeJUX7MBQ7hNnfAoRIGUpm20FKwxOobi0RLBuE= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1020.namprd21.prod.outlook.com (52.132.148.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.2; Wed, 20 Feb 2019 21:02:17 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::a490:2c67:6786:b826]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::a490:2c67:6786:b826%7]) with mapi id 15.20.1665.002; Wed, 20 Feb 2019 21:02:16 +0000 From: Praveen Balasubramanian To: Roberto Peon , =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= , Christian Huitema CC: Nick Banks , "Brian Trammell (IETF)" , Ian Swett , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: AdTInrfRZAbJSsLZSlWCCrlUkiWX7AAgkIeAAACdzgAAAbynAAAAN6coAACOYoAAAIKXwAAAszQAAAatwwAAAd27AP//i/wA//92IBA= Date: Wed, 20 Feb 2019 21:02:16 +0000 Message-ID: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:0:e4e5:68c7:c780:e632] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 61f7a654-08c9-4ade-dabe-08d69776b221 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MW2PR2101MB1020; x-ms-traffictypediagnostic: MW2PR2101MB1020: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtNVzJQUjIxMDFNQjEwMjA7MjM6MFVVNUc4MHFuMmJOd3hwRGg4N21aVkpJ?= =?utf-8?B?R1UwS1B6dWZqRjZmTkE3d1l6a1oyZjlTOHFKcWRVQUpDNDZPUzFKUytjcVNo?= =?utf-8?B?bmxzQU8xNmVVekV6ZWNXU3ZLSVgyWnpkY2M0Rkc5MmpmMUpsbXFNa2hleHBS?= =?utf-8?B?VWVuZ09xNXdUL1pHUDNlekZaczZ5Z3lSSnRGRVhEV2hqZ1lYUmhreFEvY082?= =?utf-8?B?dTM3cjRUZ1lobHhBamxxcTNHLzNXOXdaLzRqUkVBSXhyZkJhdmtwOVNqVzFT?= =?utf-8?B?UEJKVXQxT2I0VEt4UDFwQk0rVkxFbGszYkVxZktrK2NDL2szY3ZtNkhnbnpW?= =?utf-8?B?MUdBWFcwT2lzZnN1RE5NT1hrZzErNUZiVzdWelRESFJhUUlqUUlqMG5ubHZw?= =?utf-8?B?NnpGQWlGdUk3V2VlWHFyVmU4THFVb0VKWGxtMHh1MzRtdGtTNVFVSWJ2QXJ3?= =?utf-8?B?VWJZV1FPeHlvam15cnVrczBhazBQckJsNHZJNXBWY2lVaHh5S1JRT0FmN1R5?= =?utf-8?B?d0RNaFJKNVJyc2NJc21WSHJiRGx6VUZZS1ljRWxHbFJ3WHhiQnBaTXg2NlVO?= =?utf-8?B?NkU3QmwwcjhiNlB2NzltMVd5TVczaW5SZWQ4QnR0a2Q5bjVnVlBjbEFaZ3V0?= =?utf-8?B?YXgxUjFaY2hPTUl3V3lseFV6OFh3QWxQVHhGd0RGNUVFd1o0SFEwMHlFWXFX?= =?utf-8?B?aDdGb2lodkQzR2RJR1llVjMyOXhORzNxQWN5Q3VKbHVvUG1qR0l6V1N3NXZs?= =?utf-8?B?RXZia1VYbU1aSDkyQ3BwS3FtQ2ZmaVFWSHZNK2pNWk9vZUVna3FUVm8xalhU?= =?utf-8?B?WlF5aWZGMmpMdFA0a2NUQ3hFZ2k1N0Q1WjlHOE1ZVGFMRHl2ZVJ0aEtMcjNG?= =?utf-8?B?cWNNR1VmNDNKK29RcDZ3NFQrSTQrMXE1OWlQdXRwRXFGdndlcEdJS3NXd1BL?= =?utf-8?B?OGhxQ1AwenZibnBWOHQrajF5bW9weXVYN09ud0MvMWhvSyt0Ni9lYmwxU2N0?= =?utf-8?B?bFJjdUxsNUFYM2ZoN3JVQTQzMjdrSE9HZUJIbHhEWE5GamlIVFhJZ2xKVHZj?= =?utf-8?B?ZUdWc25zSjJiMXpIUEpGL2Y3c0FKaU5HNTNWREVteGF1T2x4TTVHdVFQMHJN?= =?utf-8?B?Z0JmYzJaYjBjd1Z5a3dwcDBBbTc3Vm9QazQxL1pQTm5Sb214UFU3M2xOTmhB?= =?utf-8?B?VEVGUnRSTWlMWkNHUHFhcGVpYWo5SGtIU0NWWk9oWFF6T2IvVjNjK1NEaDhh?= =?utf-8?B?a1hYejBHUGJGUDVZdS9uRDE0R1VzVDQ5NlJVSTQ4VVgvaFR2WWpuWWxDOUkr?= =?utf-8?B?eUlqTnFIeUJ5VlVLU2pVS0dhRGxPRnc3TkNZTXViM0JBU20wM0ErMTM3eExL?= =?utf-8?B?N1pJNEJRMVV1dkNVV1ozWWs3M0F1NWhYOGlwWTUyRXp4OHllMDUxM0Erb0ty?= =?utf-8?B?V0pFVm1PdEpDSGN5K3diZGRzajVVRG1XZEJYTVRLdjNsYTJkVnI4QzFWWjV4?= =?utf-8?B?amtjNWpPcS9qZWlZdU4vT2puL3ZaeDhPRnV1OTlKSm9rVUFiMlc2K3lwbk5i?= =?utf-8?B?aENYR3lnZDgybUxWcmEzME5rUUxueVpYNzg3WnZFN1l0aWFqemJGd1g3M0U4?= =?utf-8?B?VnY4VVJJZ05pcjh4SEhacEJQMUNUVDlMeHNZclRHUXFGTHE0bHdERjQwazhy?= =?utf-8?B?Nm5uOFZXU2hoQSt1QlE4MUZnUmFvdEkyTkFwQWw5dis3UUZVWnhsNU9oSTJM?= =?utf-8?B?LzRrK2x2bWxIMlhLZnJsdkE0SXBIdTh4NkZHLzNQY0Uxam1PYXNuMHpTWUtZ?= =?utf-8?B?UFV1dWtFQXJIUUF1RmI2M0JTNWxXNzNFeHdQWTgxSUc2c3M5WGluNm5JcjdM?= =?utf-8?B?VEREOXhzZCtSbmE4ekI0S0tLOEpSbThNVFN4MGM0QWpFSWYwVEx5cVh1TXlo?= =?utf-8?B?Zmh2N1RkUTVqNVE9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(136003)(396003)(346002)(13464003)(53824002)(189003)(199004)(256004)(486006)(11346002)(46003)(106356001)(4326008)(186003)(14444005)(25786009)(7736002)(86362001)(6346003)(66574012)(305945005)(53936002)(6436002)(55016002)(9686003)(105586002)(446003)(86612001)(8676002)(81166006)(476003)(229853002)(74316002)(81156014)(71200400001)(8936002)(71190400001)(6116002)(14454004)(478600001)(76176011)(2906002)(7696005)(10290500003)(10090500001)(22452003)(93886005)(316002)(6246003)(8990500004)(102836004)(99286004)(110136005)(53546011)(33656002)(54906003)(97736004)(6506007)(5660300002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1020; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cow2hKnb6RIa1Z+wxFAUfziCFB9eqKd0At2KKh7GsJAoqOPSTEdGhZAiaAK19Y36/Ca6a6Joqg6BQPwcVvbJDjU57rKmF7ak8PaB2Zhm7W13p4J6g3JxwAWQW+09vpQPQ8knkGY16CJhysAl1JKg4dJXfxTulLSW7B3xQR4/NvqocoQRDRRYJXOeGejhdn50aDs9GaL8GwZuq4Km594k4GSXYvpvMhBAcmp3lMXEA2Wn94qGtL/HklUh/VkfAFutYb1mtZouWiPTy4DHIdQ+ei1dCYxYyK4eE1rGVap3ZLYDaVxEEURfkFX7G2lN7xMJrWmGqNzTHMBu+mZidip2M42+Q+A9+WmoKEf3azrA9//XKlE357eZsIGHz68hHcFqpu8lor3B8NMm4ARrqZ7n+Juw/jO+RWTAr7wmCmPEnpU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61f7a654-08c9-4ade-dabe-08d69776b221 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 21:02:16.8363 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1020 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 21:02:24 -0000 QWdyZWVkIHRoYXQgd2UgY2Fubm90IG1hbmRhdGUgYW55IGNsaWVudCBiZWhhdmlvciBmb3IgbWFs aWNpb3VzIGNsaWVudHMsIGJ1dCBoYXZlIGNsZWFyIGd1aWRhbmNlIGZvciB3ZWxsLWJlaGF2ZWQg Y2xpZW50cyB0byBmYWxsIGJhY2sgdG8gVENQLiBUaGlzIG1lY2hhbmlzbSBwcm92aWRlcyBhIHZl cnkgbG93IENQVSBjb3N0IGZhc3QgZmFsbGJhY2sgdG8gVENQIHVuZGVyIERvUyBhdHRhY2tzIHVu dGlsIGFsbCBpbmZyYXN0cnVjdHVyZSBjYW4gc3VwcG9ydCBRVUlDIG5hdGl2ZWx5LiBDZXJ0YWlu bHkgYSBiaWcgc3RlcCB1cCBmcm9tIGp1c3QgcmF0ZSBsaW1pdGluZyBVRFAgdHJhZmZpYy4gVGhp cyB3YXkgd2VsbCBiZWhhdmVkIGNsaWVudHMgd2lsbCBoYXZlIGEgZ29vZCBjaGFuY2UgZm9yIGNv bm5lY3Rpdml0eSBhbmQgdGhlIG1hbGljaW91cyBvbmVzIHdpbGwgYmUgcmF0ZSBsaW1pdGVkLiBB bmQgYXMgcG9pbnRlZCBvdXQgbWlkZGxlYm94ZXMgY2FuIGRvIG90aGVyIGJhZCB0aGluZ3MgbGlr ZSBkcm9wIGFsbCBDSXMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlD IDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb2JlcnRvIFBlb24NClNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMjAsIDIwMTkgMTI6NDggUE0NClRvOiBUw7ZtYSBHYXZyaWNo ZW5rb3YgPHhpbWFlcmFAZ21haWwuY29tPjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVp dGVtYS5uZXQ+DQpDYzogTmljayBCYW5rcyA8bmliYW5rc0BtaWNyb3NvZnQuY29tPjsgQnJpYW4g VHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBn b29nbGUuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWlyamEgS8O8aGxld2lu ZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4NClN1YmplY3Q6IFJlOiBFeHBlY3Rl ZCBDbGllbnQgUmVzcG9uc2UgdG8gU0VSVkVSX0JVU1kNCg0KSSBiZWxpZXZlIHRoYXQgdGhlIHNv bHV0aW9uIHRvIHRoaXMgcHJvYmxlbSAod2hhdCBhIGNsaWVudCBkb2VzIHdoZW4gdGhlIHNlcnZl ciBpcyBiZWluZyBEb1MnZCkgaXMgaW5oZXJlbnRseSBvdXQtb2YtYmFuZCwgYW5kIHRodXMgbm90 IHBhcnQgb2YgdGhlIFFVSUMgcHJvdG9jb2wuDQoNCkNsaWVudHMgc2hvdWxkIGRvIHdoYXRldmVy IHRoZXkgd2FudCB0byBkbyBhcyBhIHJlc3BvbnNlIHRvIFNFUlZFUl9CVVNZLiBXZSBjYW4ndCBt YWtlIHRoZSBtYWxpY2lvdXMgb25lcyBzdG9wLCBhbmQgYW55dGhpbmcgd2UgZG8gdG8gYWxsb3cg bm9uLW1hbGljaW91cyBvbmVzIHRvIHJlc3BvbmQgYXBwcm9wcmlhdGVseSByZXF1aXJlcyBwcmUt c2hhcmluZyBvZiBzb21ldGhpbmcsIG9yIGZvciB0aGUgY29ubmVjdGlvbiB0byBzdWNjZWVkICh3 aGljaCBpcyBlc3NlbnRpYWxseSBlc3RhYmxpc2hpbmcgYSBjb250ZXh0IGZvciBzdWNoIHNoYXJp bmcpLg0KDQpEZXNpZ25pbmcgcG9saWN5IGFyb3VuZCB0aGF0IGlzIHByb2JhYmx5IGZvZGRlciBm b3IgYW5vdGhlciBkaXNjdXNzaW9uICh0aGF0IEkgaG9wZSB3ZSBnZXQgdG9nZXRoZXIgYW5kIGhh dmUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIEhUVFAgd2cpLg0KDQotPVINCg0K77u/T24gMi8yMC8x OSwgMTE6NDQgQU0sICJRVUlDIG9uIGJlaGFsZiBvZiBUw7ZtYSBHYXZyaWNoZW5rb3YiIDxxdWlj LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHhpbWFlcmFAZ21haWwuY29tPiB3cm90ZToN Cg0KICAgIE9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDEwOjQ5IEFNIENocmlzdGlhbiBIdWl0ZW1h IDxodWl0ZW1hQGh1aXRlbWEubmV0PiB3cm90ZToNCiAgICA+IHRoZSBwcm9wb3NpdGlvbiBoZXJl IGFsbG93cyBhIG1pZGRsZS1ib3ggb3IgYSBtYW4tb24tdGhlLXNpZGUgdG8gc2VuZCBhbg0KICAg ID4gdW5lbmNyeXB0ZWQgc2lnbmFsIGFuZCBoYXZlIHRoZSBjbGllbnQgaW1tZWRpYXRlbHkgaW1t ZWRpYXRlbHkgZHJvcCB0aGUNCiAgICA+IGNvbm5lY3Rpb24uIFRoYXQgZG9lcyBub3QgZmVlbCBy aWdodC4NCiAgICANCiAgICBBIG1hbi1vbi10aGUtc2lkZSAoZG9uJ3QgZXZlbiBtZW50aW9uaW5n IGEgYm94LWluLXRoZS1taWRkbGUpIGNvdWxkDQogICAgKmFsd2F5cyogbWFrZSBhIGNsaWVudCBk cm9wIGEgY29ubmVjdGlvbiwgZS5nLiwgYnkgc2VuZGluZyBhIGxhcmdlDQogICAgYW1vdW50IG9m IGp1bmsgcGFja2V0cyB0b3dhcmRzIHRoZSBjbGllbnQgdGhhdCB0aGUgY2xpZW50IHdvdWxkIGJl DQogICAgdW5hYmxlIHRvIGNvcnJlY3RseSBoYW5kbGUuIEl0J3MganVzdCBhIG1hdHRlciBvZiBo b3cgbXVjaCBoYXJtIGRvZXMNCiAgICB0aGF0IGJveCBuZWVkIHRvIGRvIHRvIHRoZSBuZXR3b3Jr Lg0KICAgIA0KICAgIEFueSBvcHBvc2l0ZSBhcHByb2FjaCBJIGNhbiB0aGluayBvZiByZXF1aXJl cyB0byBwdXQgdGhlIHByaXZhdGUga2V5DQogICAgb2YgdGhlIHNlcnZlciBvbiBhIEREb1MgaGFu ZGxpbmcgbWFjaGluZSBvciB0byBkZXBsb3kgaXQgb250byBhIEREb1MNCiAgICBtaXRpZ2F0aW9u IGNsb3VkLCB3aGljaCBub3Qgb25seSBpbmNyZWFzZXMgZXhwb3N1cmUgb2YgdGhlIHVzZXJzJyBk YXRhDQogICAgYnV0IGlzIGFsc28gZXhwbGljaXRseSBmb3JiaWRkZW4gaW4gY2VydGFpbiBjb3Vu dHJpZXMgZm9yIGNvbXBhbmllcw0KICAgIGZyb20gY2VydGFpbiBpbmR1c3RyaWVzLiBJdCdzIGFs cmVhZHkgb25seSBuYXJyb3dseSBwb3NzaWJsZSB0byBhdm9pZA0KICAgIGRvaW5nIHNvIHdpdGgg UVVJQyAoYW5kIHRoYXQgYWxyZWFkeSByZXF1aXJlcyBlaXRoZXIgYSBjb2xsYWJvcmF0aW9uDQog ICAgYmV0d2VlbiB0aGUgUVVJQyBsaWJyYXJ5IHN1cHBsaWVyIGFuZCB0aGUgRERvUyBtaXRpZ2F0 aW9uIHZlbmRvciDigJQNCiAgICB3aGljaCBpbiB0dXJuIGxlYWRzIHRvIHZlbmRvciBsb2NrIOKA lCBvciBhIHJldmVyc2UgZW5naW5lZXJpbmctYmFzZWQNCiAgICBkZXNpZ24pLCBzbyB1bnRpbCB3 ZSBoYXZlIGEgdjIgd2hpY2ggaXMgKGhvcGVmdWxseSkgbW9yZSBMQiBhbmQNCiAgICBERG9TLWF3 YXJlLCB0aGlzIGlzIHRoZSBsZXNzZXIgb2YgdHdvIGV2aWxzLg0KICAgIA0KICAgIC0tDQogICAg VMO2bWENCiAgICANCiAgICANCg0K From nobody Wed Feb 20 13:18:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AF012D4E7 for ; Wed, 20 Feb 2019 13:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=msg8qKLF; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Rggn/MX3 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 mLVZdN5sxIoq for ; Wed, 20 Feb 2019 13:18:11 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDFA129C6A for ; Wed, 20 Feb 2019 13:18:06 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1KLAV4P017461; Wed, 20 Feb 2019 13:17:55 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=Q7i/KpbnzjmAlWo0k1us3K2i3pIqyGW0VoPGfIcNpV0=; b=msg8qKLFL0PLraBr7uVBoYR0I3Ig3Cj5u3Sta9TZtG5o99HddwTTEnipuLRDeYDkM5WU MNQZegwqCAhlsd0BYIBH7EBF7cEZnE+qs/VZEwvZc2T0wGD038bNE8pCNKC5IXcmhwpG NM7tWfKBcBVKN/P4UJNWpdVLy7Z9bTJPRWs= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qse1u84n6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Feb 2019 13:17:55 -0800 Received: from prn-mbx05.TheFacebook.com (2620:10d:c081:6::19) by prn-hub01.TheFacebook.com (2620:10d:c081:35::125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 20 Feb 2019 13:17:54 -0800 Received: from prn-hub02.TheFacebook.com (2620:10d:c081:35::126) by prn-mbx05.TheFacebook.com (2620:10d:c081:6::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 20 Feb 2019 13:17:54 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Wed, 20 Feb 2019 13:17:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q7i/KpbnzjmAlWo0k1us3K2i3pIqyGW0VoPGfIcNpV0=; b=Rggn/MX3KwVNmI+lYbg0OPiy3Y8A6AIhYBvyFnth9VYYbB5/xEBLHYCTm1SmwKOpn9ka3R8BBq+Gm4ejOesdazqLP80RNrKKMniAogX+js6X7+swmngSkABzgDqBHZQOnyd1r5ecCS3Aqgx/qnAFXIf3B9hMHFmDpnj8niIr4IM= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2584.namprd15.prod.outlook.com (20.179.155.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Wed, 20 Feb 2019 21:17:52 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::2403:324c:ac17:7084%5]) with mapi id 15.20.1622.018; Wed, 20 Feb 2019 21:17:52 +0000 From: Roberto Peon To: Praveen Balasubramanian , =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= , Christian Huitema CC: Nick Banks , "Brian Trammell (IETF)" , Ian Swett , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: Re: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: AdTInrfRZAbJSsLZSlWCCrlUkiWX7AAgkIeAAACdzgAAAbynAAAAN6coAACOYoAAAIKXwAAAszQAAAatwwAAAd27AP//i/wA//92IBCAAJI+gA== Date: Wed, 20 Feb 2019 21:17:52 +0000 Message-ID: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::6:a040] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 79d00858-5250-4068-6757-08d69778df9c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2584; x-ms-traffictypediagnostic: BYAPR15MB2584: x-microsoft-exchange-diagnostics: 1; BYAPR15MB2584; 20:SRrq8EtuwEQfUp2vNwrG7KB67Y0hHKF2kKrkMLGTs5gFTe2ogfUXoZI7wmXRn9dmzhblKPxy/7SepDBS1XBTwPH+x85d5VQtCfqIWt75Tp5pvJC7/6XcWxhBlsWuviAn9niA1AJfjPhNowZ1xKJVNVZHIpMR53Mx0FiXa9Q1BVE= x-microsoft-antispam-prvs: x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(136003)(376002)(39860400002)(53824002)(13464003)(199004)(189003)(5660300002)(46003)(8936002)(36756003)(186003)(82746002)(14454004)(33656002)(6506007)(53546011)(6436002)(478600001)(8676002)(81156014)(6116002)(25786009)(316002)(2906002)(54906003)(93886005)(110136005)(58126008)(81166006)(99286004)(76176011)(7736002)(305945005)(4326008)(1511001)(83716004)(14444005)(486006)(53936002)(11346002)(71190400001)(71200400001)(68736007)(97736004)(106356001)(2616005)(446003)(476003)(6486002)(229853002)(102836004)(66574012)(86362001)(6246003)(6512007)(105586002)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2584; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CLl4RzoT+zk8W15Vzz+nUlePf3RUDvmI/3a0sbGq3A5Lk1YciS0ter5AM4EK7WoHo3LisLQkInGpL6iNlUpAZTLZeFEKNDvDnNKxLqbGVw8uIF7Pp7kXubVmOYgAM/fG7RF4zk2xbriZxcqzBiT8N8TWm9d6UcNwsLNwGh+yvb52LMHDGOEow/YWWoUXsWD6o0p/e5mkNazGUBbXxjRjA2t3qCwjirDvFNSrdycn7eT4P4g4tUX6z/Jx1SnqPsPi2CgdWIJRH+s/17fGKOaCgWVrfeowE4nPVv2SL3t4nWixYQd/bsgDgRavy7PtqBMsC0oD+E89CXmcoy51ESZXSqcEr4Fj5Rw/hbyc+AiyACmB292zVCtfOIBXCOGH1pFKsXmSVSn6caVxiNKPhKIIwbjfsNNsVYpB0KI55ozpAq0= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 79d00858-5250-4068-6757-08d69778df9c X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 21:17:52.1351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2584 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-20_16:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 21:18:16 -0000 SW4gc29tZSBjaXJjdW1zdGFuY2VzLCBmYWxsaW5nIGJhY2sgdG8gVENQIG1heSBiZSBzb21ldGhp bmcgdGhhdCB0aGUgYXBwbGljYXRpb24gc2hvdWxkbid0IGRvIChUQ1Agb2ZmZXJzIHRoZSB3cm9u ZyBzZW1hbnRpY3MsIG9yIHRoZXJlIGFyZSBjb25jZXJucyBhYm91dCB2aXNpYmlsaXR5KS4NCg0K SSB0aGluayB0aGlzIGlzIHZlcnkgbXVjaCBhbiBhcHBsaWNhdGlvbi1sZXZlbCB0aGluZywgYW5k IG5vdCBzbyBtdWNoIGEgdHJhbnNwb3J0LWxldmVsIHRoaW5nLg0KDQotPVINCg0K77u/T24gMi8y MC8xOSwgMTowMiBQTSwgIlByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIiA8cHJhdmJAbWljcm9zb2Z0 LmNvbT4gd3JvdGU6DQoNCiAgICBBZ3JlZWQgdGhhdCB3ZSBjYW5ub3QgbWFuZGF0ZSBhbnkgY2xp ZW50IGJlaGF2aW9yIGZvciBtYWxpY2lvdXMgY2xpZW50cywgYnV0IGhhdmUgY2xlYXIgZ3VpZGFu Y2UgZm9yIHdlbGwtYmVoYXZlZCBjbGllbnRzIHRvIGZhbGwgYmFjayB0byBUQ1AuIFRoaXMgbWVj aGFuaXNtIHByb3ZpZGVzIGEgdmVyeSBsb3cgQ1BVIGNvc3QgZmFzdCBmYWxsYmFjayB0byBUQ1Ag dW5kZXIgRG9TIGF0dGFja3MgdW50aWwgYWxsIGluZnJhc3RydWN0dXJlIGNhbiBzdXBwb3J0IFFV SUMgbmF0aXZlbHkuIENlcnRhaW5seSBhIGJpZyBzdGVwIHVwIGZyb20ganVzdCByYXRlIGxpbWl0 aW5nIFVEUCB0cmFmZmljLiBUaGlzIHdheSB3ZWxsIGJlaGF2ZWQgY2xpZW50cyB3aWxsIGhhdmUg YSBnb29kIGNoYW5jZSBmb3IgY29ubmVjdGl2aXR5IGFuZCB0aGUgbWFsaWNpb3VzIG9uZXMgd2ls bCBiZSByYXRlIGxpbWl0ZWQuIEFuZCBhcyBwb2ludGVkIG91dCBtaWRkbGVib3hlcyBjYW4gZG8g b3RoZXIgYmFkIHRoaW5ncyBsaWtlIGRyb3AgYWxsIENJcy4NCiAgICANCiAgICAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIFJvYmVydG8gUGVvbg0KICAgIFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkg MjAsIDIwMTkgMTI6NDggUE0NCiAgICBUbzogVMO2bWEgR2F2cmljaGVua292IDx4aW1hZXJhQGdt YWlsLmNvbT47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KICAgIENj OiBOaWNrIEJhbmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb20+OyBCcmlhbiBUcmFtbWVsbCAoSUVU RikgPGlldGZAdHJhbW1lbGwuY2g+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBJ RVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KICAgIFN1YmplY3Q6IFJlOiBFeHBlY3RlZCBDbGllbnQg UmVzcG9uc2UgdG8gU0VSVkVSX0JVU1kNCiAgICANCiAgICBJIGJlbGlldmUgdGhhdCB0aGUgc29s dXRpb24gdG8gdGhpcyBwcm9ibGVtICh3aGF0IGEgY2xpZW50IGRvZXMgd2hlbiB0aGUgc2VydmVy IGlzIGJlaW5nIERvUydkKSBpcyBpbmhlcmVudGx5IG91dC1vZi1iYW5kLCBhbmQgdGh1cyBub3Qg cGFydCBvZiB0aGUgUVVJQyBwcm90b2NvbC4NCiAgICANCiAgICBDbGllbnRzIHNob3VsZCBkbyB3 aGF0ZXZlciB0aGV5IHdhbnQgdG8gZG8gYXMgYSByZXNwb25zZSB0byBTRVJWRVJfQlVTWS4gV2Ug Y2FuJ3QgbWFrZSB0aGUgbWFsaWNpb3VzIG9uZXMgc3RvcCwgYW5kIGFueXRoaW5nIHdlIGRvIHRv IGFsbG93IG5vbi1tYWxpY2lvdXMgb25lcyB0byByZXNwb25kIGFwcHJvcHJpYXRlbHkgcmVxdWly ZXMgcHJlLXNoYXJpbmcgb2Ygc29tZXRoaW5nLCBvciBmb3IgdGhlIGNvbm5lY3Rpb24gdG8gc3Vj Y2VlZCAod2hpY2ggaXMgZXNzZW50aWFsbHkgZXN0YWJsaXNoaW5nIGEgY29udGV4dCBmb3Igc3Vj aCBzaGFyaW5nKS4NCiAgICANCiAgICBEZXNpZ25pbmcgcG9saWN5IGFyb3VuZCB0aGF0IGlzIHBy b2JhYmx5IGZvZGRlciBmb3IgYW5vdGhlciBkaXNjdXNzaW9uICh0aGF0IEkgaG9wZSB3ZSBnZXQg dG9nZXRoZXIgYW5kIGhhdmUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIEhUVFAgd2cpLg0KICAgIA0K ICAgIC09Ug0KICAgIA0KICAgIE9uIDIvMjAvMTksIDExOjQ0IEFNLCAiUVVJQyBvbiBiZWhhbGYg b2YgVMO2bWEgR2F2cmljaGVua292IiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiB4aW1hZXJhQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgDQogICAgICAgIE9uIFdlZCwgRmViIDIw LCAyMDE5IGF0IDEwOjQ5IEFNIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0 PiB3cm90ZToNCiAgICAgICAgPiB0aGUgcHJvcG9zaXRpb24gaGVyZSBhbGxvd3MgYSBtaWRkbGUt Ym94IG9yIGEgbWFuLW9uLXRoZS1zaWRlIHRvIHNlbmQgYW4NCiAgICAgICAgPiB1bmVuY3J5cHRl ZCBzaWduYWwgYW5kIGhhdmUgdGhlIGNsaWVudCBpbW1lZGlhdGVseSBpbW1lZGlhdGVseSBkcm9w IHRoZQ0KICAgICAgICA+IGNvbm5lY3Rpb24uIFRoYXQgZG9lcyBub3QgZmVlbCByaWdodC4NCiAg ICAgICAgDQogICAgICAgIEEgbWFuLW9uLXRoZS1zaWRlIChkb24ndCBldmVuIG1lbnRpb25pbmcg YSBib3gtaW4tdGhlLW1pZGRsZSkgY291bGQNCiAgICAgICAgKmFsd2F5cyogbWFrZSBhIGNsaWVu dCBkcm9wIGEgY29ubmVjdGlvbiwgZS5nLiwgYnkgc2VuZGluZyBhIGxhcmdlDQogICAgICAgIGFt b3VudCBvZiBqdW5rIHBhY2tldHMgdG93YXJkcyB0aGUgY2xpZW50IHRoYXQgdGhlIGNsaWVudCB3 b3VsZCBiZQ0KICAgICAgICB1bmFibGUgdG8gY29ycmVjdGx5IGhhbmRsZS4gSXQncyBqdXN0IGEg bWF0dGVyIG9mIGhvdyBtdWNoIGhhcm0gZG9lcw0KICAgICAgICB0aGF0IGJveCBuZWVkIHRvIGRv IHRvIHRoZSBuZXR3b3JrLg0KICAgICAgICANCiAgICAgICAgQW55IG9wcG9zaXRlIGFwcHJvYWNo IEkgY2FuIHRoaW5rIG9mIHJlcXVpcmVzIHRvIHB1dCB0aGUgcHJpdmF0ZSBrZXkNCiAgICAgICAg b2YgdGhlIHNlcnZlciBvbiBhIEREb1MgaGFuZGxpbmcgbWFjaGluZSBvciB0byBkZXBsb3kgaXQg b250byBhIEREb1MNCiAgICAgICAgbWl0aWdhdGlvbiBjbG91ZCwgd2hpY2ggbm90IG9ubHkgaW5j cmVhc2VzIGV4cG9zdXJlIG9mIHRoZSB1c2VycycgZGF0YQ0KICAgICAgICBidXQgaXMgYWxzbyBl eHBsaWNpdGx5IGZvcmJpZGRlbiBpbiBjZXJ0YWluIGNvdW50cmllcyBmb3IgY29tcGFuaWVzDQog ICAgICAgIGZyb20gY2VydGFpbiBpbmR1c3RyaWVzLiBJdCdzIGFscmVhZHkgb25seSBuYXJyb3ds eSBwb3NzaWJsZSB0byBhdm9pZA0KICAgICAgICBkb2luZyBzbyB3aXRoIFFVSUMgKGFuZCB0aGF0 IGFscmVhZHkgcmVxdWlyZXMgZWl0aGVyIGEgY29sbGFib3JhdGlvbg0KICAgICAgICBiZXR3ZWVu IHRoZSBRVUlDIGxpYnJhcnkgc3VwcGxpZXIgYW5kIHRoZSBERG9TIG1pdGlnYXRpb24gdmVuZG9y IOKAlA0KICAgICAgICB3aGljaCBpbiB0dXJuIGxlYWRzIHRvIHZlbmRvciBsb2NrIOKAlCBvciBh IHJldmVyc2UgZW5naW5lZXJpbmctYmFzZWQNCiAgICAgICAgZGVzaWduKSwgc28gdW50aWwgd2Ug aGF2ZSBhIHYyIHdoaWNoIGlzIChob3BlZnVsbHkpIG1vcmUgTEIgYW5kDQogICAgICAgIEREb1Mt YXdhcmUsIHRoaXMgaXMgdGhlIGxlc3NlciBvZiB0d28gZXZpbHMuDQogICAgICAgIA0KICAgICAg ICAtLQ0KICAgICAgICBUw7ZtYQ0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQoNCg== From nobody Wed Feb 20 14:56:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A802F130E9C for ; Wed, 20 Feb 2019 14:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRk-yuyIysfI for ; Wed, 20 Feb 2019 14:56:52 -0800 (PST) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 4060E12D7EA for ; Wed, 20 Feb 2019 14:56:52 -0800 (PST) Received: by mail-yb1-xb29.google.com with SMTP id j189so10290586ybj.9 for ; Wed, 20 Feb 2019 14:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mlPG5bT1MfMKc/8YBPAN28vs55zVUlu1lNP193ZKhYE=; b=Q6cDqQgKSF6RVipFGK/nCIW85stBZFWKYK3zSTOOtvaMGTipD3y1bw7z7t7Vg6BfAG hgq/hnF1Oc1BUz6CvBCx3foEMaE19vIy9uo+eUndKzCPCByN2Kjshxfz3VJS7+vDbI/T F8hK8W0REHbutiL0BydMeEOuvLzKMJ6P/Pbe40q11ebZHppR5zuDI+DRsasiZuMVhFl9 rv3ub6qG6ENtc0TBt5vQzpM5Y4t0r/UP8UxNBCxNP6YVAopYtkaXhYY36jSiSL89W9p9 nL0geW/KUna1bR+CKgO7zgTTMRbQcvy5B97qJt59hMWSOr32F08xfrX/L+iJu1mzP38G of3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mlPG5bT1MfMKc/8YBPAN28vs55zVUlu1lNP193ZKhYE=; b=JjU02Kha8Q6BZo6d7zhGpdMJ5iCb29Mn+4K0bK86a327+RXrr6kBMoSFFkqgPIbHum 1gkXY5KMPGTYLz9E2thi3DQbQSgEeHAxyau2ycYhAT0h1RCWNLPz24dniM5Mh640D7Dm 6khuQoaUURAkOe+wewXKsoL+GcnKaHxP47UEEt5F2i5biYmMdeKrxeMHA3SVC85oBWzJ Wmv2TLXTV8aJxVhsEzx5R/Kh6v0JFxeVCu0Crw90OR8Fw89YGAnoxgjPZE12k5ROQvxG osobi7F1vALJANGhb9FpMt5UEOLz6gBpqdS+0/bYNm5tcHdhVzgvIgW2DGDWkZ6lWXkq sarA== X-Gm-Message-State: AHQUAuaNDh/mIG4YtXhFOaNMVq+jpUJ2ivnZP3CJaj8NnXrGfcuJIMtk Xno5h2YHxqmo/4ZvFQb93K03SpNeDakM4u04FYE= X-Google-Smtp-Source: AHgI3Ia/MjG0iLwrS5Y/tQgifvs7JpjjVmyLr57JSbTGDYcCWsMr8yS7LOUyIOAAmIEV/+fprRuOQrP25Eu4vLHahQU= X-Received: by 2002:a5b:903:: with SMTP id a3mr30892271ybq.445.1550703411086; Wed, 20 Feb 2019 14:56:51 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Wed, 20 Feb 2019 14:56:32 -0800 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Roberto Peon Cc: Praveen Balasubramanian , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000f849e405825b4546" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 22:56:54 -0000 --000000000000f849e405825b4546 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > This mechanism provides a very low CPU cost > fast fallback to TCP under DoS attacks until all > infrastructure can support QUIC natively There are [a] few use cases when switching from TCP to QUIC v1 (in its current state) is not feasible because of huge operational costs. So it would be a more long term solution than that, probably till v2 or even further. > anything we do to allow non-malicious ones to > respond appropriately requires pre-sharing, > or for the connection to succeed The question here is basically how to ensure the latter given a X00 Gbps attack scale if you're neither Facebook nor Google. > In some circumstances, falling back to TCP > may be something that the application shouldn't do Well, maybe, but then IMO the consequences of not being able to benefit from switching to TCP if you're doing certain things with QUIC should be outlined in the spec. Again, this is an application-level thing *now*, but formerly the transport used to take full care of it, and the change in that sort of breaks the habit of the users. -- T=C3=B6ma --000000000000f849e405825b4546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> This mechanism provides a very low CPU cost
> fast fallback to TCP under=20 DoS attacks until all
> infrastructure can support QUIC native= ly

There are [a] few use cases when switching from= TCP to QUIC v1 (in its current state) is not feasible because of huge oper= ational costs. So it would be a more long term solution than that, probably= till v2 or even further.

> anything we do to a= llow non-malicious ones to
> respond appropriately requires pr= e-sharing,
> or for the connection to succeed

The question here is basically how to ensure the latter given a X0= 0 Gbps attack scale if you're neither Facebook nor Google.

> In some circumstances, falling back to TCP
= > may be something that the application shouldn't do

<= /div>
Well, maybe, but then IMO the consequences of not being able to b= enefit from switching to TCP if you're doing certain things with QUIC s= hould be outlined in the spec. Again, this is an application-level thing *n= ow*, but formerly the transport used to take full care of it, and the chang= e in that sort of breaks the habit of the users.

--
T=C3=B6ma
--000000000000f849e405825b4546-- From nobody Wed Feb 20 17:01:41 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F21D130F2B for ; Wed, 20 Feb 2019 17:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzQjgc8eSyxd for ; Wed, 20 Feb 2019 17:01:38 -0800 (PST) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 07679130F0E for ; Wed, 20 Feb 2019 17:01:38 -0800 (PST) Received: by mail-lf1-x141.google.com with SMTP id m11so19048874lfc.6 for ; Wed, 20 Feb 2019 17:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=urnVeXbAl1LCDlq5RwGgwL2rSuuV9o52GjYYm637GZg=; b=JNIcVPHssbkRhyoitQk+daJocZ+2p2XGxKb+bLVkCxn6yj2RxruuachxpB/BZIoWvC GEXieOC7UKXyiIptqEueImOcywX6CxiMU14iT4GIgHwmMP01bJifqFgVINmBnjMHiKRF 6fUd8vwj8Jd25Sgh48BMDEDYUgwOlDw96LMGoR19ifuqK5OA/6zdsU/FuBnvQgPsMq+q 7Yob8jhynAdR3rIycPn3ezRAwV3y7ro0SRwur7tDNu8VxylwvLdBUs1LUursxWuF5U5n /t34cY3aU1htGwIsDg1SqnwAau/InGk0IV2UfibK1X7x/BeD42o7CdRe636LE6ZTFz/P GHiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=urnVeXbAl1LCDlq5RwGgwL2rSuuV9o52GjYYm637GZg=; b=jla6RT5OwBxZ+T+8dimGYb5VvopLaR/15qvkio8zSakZpvsdNzY0FsPHcOE/0yY+KQ bNUxbhe5pafbzP63W1x4KDEsKLTtGWp5QbhmNJoKT4Sco9CpzhTwMptK1hRDBCZvpjg3 tf9oeuXTAZ/J8b6mHdIHDS1gmjIpTgJvrxDBVwFleIQYyLTsPjSkzYUJXRJCL+igh3f4 0zohhOHR0X6dx2i/FJt2dODWAtK5Ns5EqSSamhzV2B3oYVrMy0zcKx23b4O1uiHt2xRK ywnczgmBtGN/o1xLge/cKl4jshHwV5C+G6zq8HISKyXdj3wv1cI4apEy6glDC+w0UnpI UVew== X-Gm-Message-State: AHQUAuaywIjGNGkrCjhjjX6mk2SIGoXPO6yJqAaOs+O/zMtFvagUcybe DqyDesVbJ7hmZWdYs4KOyiZC0zG5FV4/CPv7Qx4= X-Google-Smtp-Source: AHgI3Ia2KZWqYFYL9o0QZqZmr+/h5um2A5AqPzwPokOv1iLJxziU0HGHO+/JsktKIvyS58O9W/IiStMr6tK7SeAZkOo= X-Received: by 2002:a19:c942:: with SMTP id z63mr21701303lff.162.1550710896251; Wed, 20 Feb 2019 17:01:36 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: From: Kazuho Oku Date: Thu, 21 Feb 2019 10:01:24 +0900 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Roberto Peon Cc: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= , Christian Huitema , Nick Banks , "Brian Trammell (IETF)" , Ian Swett , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 01:01:40 -0000 2019=E5=B9=B42=E6=9C=8821=E6=97=A5(=E6=9C=A8) 5:49 Roberto Peon : > > I believe that the solution to this problem (what a client does when the = server is being DoS'd) is inherently out-of-band, and thus not part of the = QUIC protocol. > > Clients should do whatever they want to do as a response to SERVER_BUSY. = We can't make the malicious ones stop, and anything we do to allow non-mali= cious ones to respond appropriately requires pre-sharing of something, or f= or the connection to succeed (which is essentially establishing a context f= or such sharing). > > Designing policy around that is probably fodder for another discussion (t= hat I hope we get together and have in the context of the HTTP wg). I think I mostly agree with Roberto here. Anyways, the issue is with H3, not QUIC as a transport protocol. HTTP is unique in sense that it can use either TCP or QUIC as a transport. We cannot expect every application protocol to have that kind of property. And even in case of H3, our conclusion might depend on how the H3 endpoint was discovered. We might argue that it makes sense to permit the fallback when the H3 endpoint was discovered due to an upgrade from TCP (e.g. alt-svc). But the situation would be different if the H3 endpoint was discovered through other means (e.g., extension field of ESNI record). > -=3DR > > =EF=BB=BFOn 2/20/19, 11:44 AM, "QUIC on behalf of T=C3=B6ma Gavrichenkov"= wrote: > > On Wed, Feb 20, 2019 at 10:49 AM Christian Huitema wrote: > > the proposition here allows a middle-box or a man-on-the-side to se= nd an > > unencrypted signal and have the client immediately immediately drop= the > > connection. That does not feel right. > > A man-on-the-side (don't even mentioning a box-in-the-middle) could > *always* make a client drop a connection, e.g., by sending a large > amount of junk packets towards the client that the client would be > unable to correctly handle. It's just a matter of how much harm does > that box need to do to the network. > > Any opposite approach I can think of requires to put the private key > of the server on a DDoS handling machine or to deploy it onto a DDoS > mitigation cloud, which not only increases exposure of the users' dat= a > but is also explicitly forbidden in certain countries for companies > from certain industries. It's already only narrowly possible to avoid > doing so with QUIC (and that already requires either a collaboration > between the QUIC library supplier and the DDoS mitigation vendor =E2= =80=94 > which in turn leads to vendor lock =E2=80=94 or a reverse engineering= -based > design), so until we have a v2 which is (hopefully) more LB and > DDoS-aware, this is the lesser of two evils. > > -- > T=C3=B6ma > > > --=20 Kazuho Oku From nobody Wed Feb 20 22:15:25 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA7412F1AB for ; Wed, 20 Feb 2019 22:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbSrS2JJdjKM for ; Wed, 20 Feb 2019 22:15:20 -0800 (PST) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (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 8969F12EB11 for ; Wed, 20 Feb 2019 22:15:20 -0800 (PST) Received: by mail-pg1-x541.google.com with SMTP id 196so1376169pgf.13 for ; Wed, 20 Feb 2019 22:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=w9suIiUtc65oMehoeSJHsfWuBP5WR02lODHziMpw5bs=; b=WoIs6JP3AYOF9xA52Smeq0qouHXRXm/1vg1k1NrOIZHYUXGeU1K2nYB091G8h4SIpo l/Gg+SzIEFmbO7vQW6TwSlMRbRhExu5ayPN9qAUbdeDuzC2dE9roMi9nrgcFjDTLZH2v GP9auneAyiSmtcDCjV6u6asJWIkgDPa5jI+hZk3HR+7G9SgkW19M0xe3YfAsQfNT1nxV WQ2s3vb4U5RwDkiF6ywWHcs6cxP2HYx3IAG5w8AXZzGM38WlPoWc/3A3YM8QL7DhLJL+ sLMDg5QFOxImg4uBvICSsiJWZ12MHGqfjG+ZyGd4WQkoN/V7o9YVdobAgvT/wplkN2cI 41iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=w9suIiUtc65oMehoeSJHsfWuBP5WR02lODHziMpw5bs=; b=fb4R2MbzG6ptTPsg06bbR2TnqleRE07zcgrbF0IWX8P9OLBbRQc7zrvqCkE7QcywSc P4JRQb2MFfmb/751WjIrzBNm79xEUSdKh+KVK22jPE7Si/mj9V+on8L0tBk3/JOhcGZ5 QH38Fd7m0SHwTLu7QQiVakiryFmb+swCow1llqqu+o47yYHkBeIC8T94KzMJ+f+crOOo zCpt+mA8+IwolA7TUPAkcvgEfHOqLeYIPzD9EsajUt9JLERGDfJ55efWfACkBCl/jsS7 Tof3m3me7ylWUA5A2ycaNHEIDSqxOFdGT4xGqhTyvIXud4PhJHYpwtNhAd6Pu2yD7h3e lMpw== X-Gm-Message-State: AHQUAubzpXN7aFcJ7W19f+UH4avIwtGXxQSq8vxkKgQ0B+d81PIItQdq Q8ocrdgyB+78EZf0z3Yy1Ms= X-Google-Smtp-Source: AHgI3IaTQ3l7wIhIuq25MWKPrybdlwaLpaVkGoezXSY/d5XoFph1FKOkJuM/e3SFgnQ57xL6MNfdLQ== X-Received: by 2002:a63:3648:: with SMTP id d69mr24259140pga.314.1550729719736; Wed, 20 Feb 2019 22:15:19 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.61]) by smtp.gmail.com with ESMTPSA id 33sm21848178pgs.81.2019.02.20.22.15.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 22:15:18 -0800 (PST) From: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= To: Kazuho Oku , Roberto Peon CC: =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= , Ian Swett , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema , Nick Banks , "Brian Trammell (IETF)" , IETF QUIC WG Subject: Re: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: ATBENDEw3+lgVYjQ4fRx896/dRO/AGdQTDRpQUY1NDJBMXkrPTA5NzcwZ3FfT3UwMEM5MEF6RW5xNTA5ZmJnbjk2ZTgzQjQ5Z1IwMHevkOfuCg== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Thu, 21 Feb 2019 06:15:09 +0000 Message-ID: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB17663D1D1A04E7337E02CBA0AC7E0DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 06:15:24 -0000 --_000_DB6PR10MB17663D1D1A04E7337E02CBA0AC7E0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2h5IG5vdCBkZWFsIHdpdGggdGhpcyBhdCB0aGUgRE5TIGxheWVyIGFuZCB3b3JrIHdpdGggdGhl IGRlc2lnbnMgdGhhdCBhcmUgZmxvYXRpbmc/DQoNCk90aGVyIHRoYW4gdGhhdCBJIGFncmVlIHdp dGggUm9iZXJ0byBhbmQgS2F6dWhvLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcmE6IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gcMOlIHZlZ25lIGFmIEthenVo byBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpTZW5kdDogdG9yc2RhZywgZmVicnVhciAyMSwg MjAxOSAyOjAxIEFNDQpUaWw6IFJvYmVydG8gUGVvbg0KQ2M6IFTDtm1hIEdhdnJpY2hlbmtvdjsg SWFuIFN3ZXR0OyBNaXJqYSBLw7xobGV3aW5kOyBDaHJpc3RpYW4gSHVpdGVtYTsgTmljayBCYW5r czsgQnJpYW4gVHJhbW1lbGwgKElFVEYpOyBJRVRGIFFVSUMgV0cNCkVtbmU6IFJlOiBFeHBlY3Rl ZCBDbGllbnQgUmVzcG9uc2UgdG8gU0VSVkVSX0JVU1kNCg0KMjAxOeW5tDLmnIgyMeaXpSjmnKgp IDU6NDkgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+Og0KPg0KPiBJIGJlbGlldmUgdGhhdCB0 aGUgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtICh3aGF0IGEgY2xpZW50IGRvZXMgd2hlbiB0aGUg c2VydmVyIGlzIGJlaW5nIERvUydkKSBpcyBpbmhlcmVudGx5IG91dC1vZi1iYW5kLCBhbmQgdGh1 cyBub3QgcGFydCBvZiB0aGUgUVVJQyBwcm90b2NvbC4NCj4NCj4gQ2xpZW50cyBzaG91bGQgZG8g d2hhdGV2ZXIgdGhleSB3YW50IHRvIGRvIGFzIGEgcmVzcG9uc2UgdG8gU0VSVkVSX0JVU1kuIFdl IGNhbid0IG1ha2UgdGhlIG1hbGljaW91cyBvbmVzIHN0b3AsIGFuZCBhbnl0aGluZyB3ZSBkbyB0 byBhbGxvdyBub24tbWFsaWNpb3VzIG9uZXMgdG8gcmVzcG9uZCBhcHByb3ByaWF0ZWx5IHJlcXVp cmVzIHByZS1zaGFyaW5nIG9mIHNvbWV0aGluZywgb3IgZm9yIHRoZSBjb25uZWN0aW9uIHRvIHN1 Y2NlZWQgKHdoaWNoIGlzIGVzc2VudGlhbGx5IGVzdGFibGlzaGluZyBhIGNvbnRleHQgZm9yIHN1 Y2ggc2hhcmluZykuDQo+DQo+IERlc2lnbmluZyBwb2xpY3kgYXJvdW5kIHRoYXQgaXMgcHJvYmFi bHkgZm9kZGVyIGZvciBhbm90aGVyIGRpc2N1c3Npb24gKHRoYXQgSSBob3BlIHdlIGdldCB0b2dl dGhlciBhbmQgaGF2ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgSFRUUCB3ZykuDQoNCkkgdGhpbmsg SSBtb3N0bHkgYWdyZWUgd2l0aCBSb2JlcnRvIGhlcmUuDQoNCkFueXdheXMsIHRoZSBpc3N1ZSBp cyB3aXRoIEgzLCBub3QgUVVJQyBhcyBhIHRyYW5zcG9ydCBwcm90b2NvbC4gSFRUUA0KaXMgdW5p cXVlIGluIHNlbnNlIHRoYXQgaXQgY2FuIHVzZSBlaXRoZXIgVENQIG9yIFFVSUMgYXMgYSB0cmFu c3BvcnQuDQpXZSBjYW5ub3QgZXhwZWN0IGV2ZXJ5IGFwcGxpY2F0aW9uIHByb3RvY29sIHRvIGhh dmUgdGhhdCBraW5kIG9mDQpwcm9wZXJ0eS4NCg0KQW5kIGV2ZW4gaW4gY2FzZSBvZiBIMywgb3Vy IGNvbmNsdXNpb24gbWlnaHQgZGVwZW5kIG9uIGhvdyB0aGUgSDMNCmVuZHBvaW50IHdhcyBkaXNj b3ZlcmVkLiBXZSBtaWdodCBhcmd1ZSB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHBlcm1pdA0KdGhl IGZhbGxiYWNrIHdoZW4gdGhlIEgzIGVuZHBvaW50IHdhcyBkaXNjb3ZlcmVkIGR1ZSB0byBhbiB1 cGdyYWRlDQpmcm9tIFRDUCAoZS5nLiBhbHQtc3ZjKS4gQnV0IHRoZSBzaXR1YXRpb24gd291bGQg YmUgZGlmZmVyZW50IGlmIHRoZQ0KSDMgZW5kcG9pbnQgd2FzIGRpc2NvdmVyZWQgdGhyb3VnaCBv dGhlciBtZWFucyAoZS5nLiwgZXh0ZW5zaW9uIGZpZWxkDQpvZiBFU05JIHJlY29yZCkuDQoNCj4g LT1SDQo+DQo+IO+7v09uIDIvMjAvMTksIDExOjQ0IEFNLCAiUVVJQyBvbiBiZWhhbGYgb2YgVMO2 bWEgR2F2cmljaGVua292IiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB4aW1h ZXJhQGdtYWlsLmNvbT4gd3JvdGU6DQo+DQo+IE9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDEwOjQ5 IEFNIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PiB3cm90ZToNCj4gPiB0 aGUgcHJvcG9zaXRpb24gaGVyZSBhbGxvd3MgYSBtaWRkbGUtYm94IG9yIGEgbWFuLW9uLXRoZS1z aWRlIHRvIHNlbmQgYW4NCj4gPiB1bmVuY3J5cHRlZCBzaWduYWwgYW5kIGhhdmUgdGhlIGNsaWVu dCBpbW1lZGlhdGVseSBpbW1lZGlhdGVseSBkcm9wIHRoZQ0KPiA+IGNvbm5lY3Rpb24uIFRoYXQg ZG9lcyBub3QgZmVlbCByaWdodC4NCj4NCj4gQSBtYW4tb24tdGhlLXNpZGUgKGRvbid0IGV2ZW4g bWVudGlvbmluZyBhIGJveC1pbi10aGUtbWlkZGxlKSBjb3VsZA0KPiAqYWx3YXlzKiBtYWtlIGEg Y2xpZW50IGRyb3AgYSBjb25uZWN0aW9uLCBlLmcuLCBieSBzZW5kaW5nIGEgbGFyZ2UNCj4gYW1v dW50IG9mIGp1bmsgcGFja2V0cyB0b3dhcmRzIHRoZSBjbGllbnQgdGhhdCB0aGUgY2xpZW50IHdv dWxkIGJlDQo+IHVuYWJsZSB0byBjb3JyZWN0bHkgaGFuZGxlLiBJdCdzIGp1c3QgYSBtYXR0ZXIg b2YgaG93IG11Y2ggaGFybSBkb2VzDQo+IHRoYXQgYm94IG5lZWQgdG8gZG8gdG8gdGhlIG5ldHdv cmsuDQo+DQo+IEFueSBvcHBvc2l0ZSBhcHByb2FjaCBJIGNhbiB0aGluayBvZiByZXF1aXJlcyB0 byBwdXQgdGhlIHByaXZhdGUga2V5DQo+IG9mIHRoZSBzZXJ2ZXIgb24gYSBERG9TIGhhbmRsaW5n IG1hY2hpbmUgb3IgdG8gZGVwbG95IGl0IG9udG8gYSBERG9TDQo+IG1pdGlnYXRpb24gY2xvdWQs IHdoaWNoIG5vdCBvbmx5IGluY3JlYXNlcyBleHBvc3VyZSBvZiB0aGUgdXNlcnMnIGRhdGENCj4g YnV0IGlzIGFsc28gZXhwbGljaXRseSBmb3JiaWRkZW4gaW4gY2VydGFpbiBjb3VudHJpZXMgZm9y IGNvbXBhbmllcw0KPiBmcm9tIGNlcnRhaW4gaW5kdXN0cmllcy4gSXQncyBhbHJlYWR5IG9ubHkg bmFycm93bHkgcG9zc2libGUgdG8gYXZvaWQNCj4gZG9pbmcgc28gd2l0aCBRVUlDIChhbmQgdGhh dCBhbHJlYWR5IHJlcXVpcmVzIGVpdGhlciBhIGNvbGxhYm9yYXRpb24NCj4gYmV0d2VlbiB0aGUg UVVJQyBsaWJyYXJ5IHN1cHBsaWVyIGFuZCB0aGUgRERvUyBtaXRpZ2F0aW9uIHZlbmRvciDigJQN Cj4gd2hpY2ggaW4gdHVybiBsZWFkcyB0byB2ZW5kb3IgbG9jayDigJQgb3IgYSByZXZlcnNlIGVu Z2luZWVyaW5nLWJhc2VkDQo+IGRlc2lnbiksIHNvIHVudGlsIHdlIGhhdmUgYSB2MiB3aGljaCBp cyAoaG9wZWZ1bGx5KSBtb3JlIExCIGFuZA0KPiBERG9TLWF3YXJlLCB0aGlzIGlzIHRoZSBsZXNz ZXIgb2YgdHdvIGV2aWxzLg0KPg0KPiAtLQ0KPiBUw7ZtYQ0KPg0KPg0KPg0KDQoNCi0tDQpLYXp1 aG8gT2t1DQoNCg== --_000_DB6PR10MB17663D1D1A04E7337E02CBA0AC7E0DB6PR10MB1766EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOiBsdHI7Ij5XaHkgbm90IGRlYWwgd2l0aCB0 aGlzIGF0IHRoZSBETlMgbGF5ZXIgYW5kIHdvcmsgd2l0aCB0aGUgZGVzaWducyB0aGF0IGFyZSBm bG9hdGluZz88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246 IGx0cjsiPk90aGVyIHRoYW4gdGhhdCBJIGFncmVlIHdpdGggUm9iZXJ0byBhbmQgS2F6dWhvLjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibXMtb3V0bG9vay1p b3Mtc2lnbmF0dXJlIj48L2Rpdj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxociBzdHls ZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7d2lkdGg6OTglIiB0YWJpbmRleD0iLTEiPg0KPGRpdiBp ZD0iZGl2UnBseUZ3ZE1zZyIgZGlyPSJkaXI9JnF1b3Q7bHRyJnF1b3Q7Ij48Zm9udCBmYWNlPSJD YWxpYnJpLCBzYW5zLXNlcmlmIiBzdHlsZT0iZm9udC1zaXplOjExcHQiIGNvbG9yPSIjMDAwMDAw Ij48Yj5GcmE6PC9iPiBRVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IHDDpSB2ZWdu ZSBhZiBLYXp1aG8gT2t1ICZsdDtrYXp1aG9va3VAZ21haWwuY29tJmd0Ozxicj4NCjxiPlNlbmR0 OjwvYj4gdG9yc2RhZywgZmVicnVhciAyMSwgMjAxOSAyOjAxIEFNPGJyPg0KPGI+VGlsOjwvYj4g Um9iZXJ0byBQZW9uPGJyPg0KPGI+Q2M6PC9iPiBUw7ZtYSBHYXZyaWNoZW5rb3Y7IElhbiBTd2V0 dDsgTWlyamEgS8O8aGxld2luZDsgQ2hyaXN0aWFuIEh1aXRlbWE7IE5pY2sgQmFua3M7IEJyaWFu IFRyYW1tZWxsIChJRVRGKTsgSUVURiBRVUlDIFdHPGJyPg0KPGI+RW1uZTo8L2I+IFJlOiBFeHBl Y3RlZCBDbGllbnQgUmVzcG9uc2UgdG8gU0VSVkVSX0JVU1kNCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 L2ZvbnQ+PC9kaXY+DQoyMDE55bm0MuaciDIx5pelKOacqCkgNTo0OSBSb2JlcnRvIFBlb24gJmx0 O2Zlbml4QGZiLmNvbSZndDs6IDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGJlbGlldmUgdGhhdCB0 aGUgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtICh3aGF0IGEgY2xpZW50IGRvZXMgd2hlbiB0aGUg c2VydmVyIGlzIGJlaW5nIERvUydkKSBpcyBpbmhlcmVudGx5IG91dC1vZi1iYW5kLCBhbmQgdGh1 cyBub3QgcGFydCBvZiB0aGUgUVVJQyBwcm90b2NvbC4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBD bGllbnRzIHNob3VsZCBkbyB3aGF0ZXZlciB0aGV5IHdhbnQgdG8gZG8gYXMgYSByZXNwb25zZSB0 byBTRVJWRVJfQlVTWS4gV2UgY2FuJ3QgbWFrZSB0aGUgbWFsaWNpb3VzIG9uZXMgc3RvcCwgYW5k IGFueXRoaW5nIHdlIGRvIHRvIGFsbG93IG5vbi1tYWxpY2lvdXMgb25lcyB0byByZXNwb25kIGFw cHJvcHJpYXRlbHkgcmVxdWlyZXMgcHJlLXNoYXJpbmcgb2Ygc29tZXRoaW5nLCBvciBmb3IgdGhl IGNvbm5lY3Rpb24gdG8gc3VjY2VlZCAod2hpY2gNCiBpcyBlc3NlbnRpYWxseSBlc3RhYmxpc2hp bmcgYSBjb250ZXh0IGZvciBzdWNoIHNoYXJpbmcpLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgRGVz aWduaW5nIHBvbGljeSBhcm91bmQgdGhhdCBpcyBwcm9iYWJseSBmb2RkZXIgZm9yIGFub3RoZXIg ZGlzY3Vzc2lvbiAodGhhdCBJIGhvcGUgd2UgZ2V0IHRvZ2V0aGVyIGFuZCBoYXZlIGluIHRoZSBj b250ZXh0IG9mIHRoZSBIVFRQIHdnKS4NCjxicj4NCjxicj4NCkkgdGhpbmsgSSBtb3N0bHkgYWdy ZWUgd2l0aCBSb2JlcnRvIGhlcmUuIDxicj4NCjxicj4NCkFueXdheXMsIHRoZSBpc3N1ZSBpcyB3 aXRoIEgzLCBub3QgUVVJQyBhcyBhIHRyYW5zcG9ydCBwcm90b2NvbC4gSFRUUCA8YnI+DQppcyB1 bmlxdWUgaW4gc2Vuc2UgdGhhdCBpdCBjYW4gdXNlIGVpdGhlciBUQ1Agb3IgUVVJQyBhcyBhIHRy YW5zcG9ydC4gPGJyPg0KV2UgY2Fubm90IGV4cGVjdCBldmVyeSBhcHBsaWNhdGlvbiBwcm90b2Nv bCB0byBoYXZlIHRoYXQga2luZCBvZiA8YnI+DQpwcm9wZXJ0eS4gPGJyPg0KPGJyPg0KQW5kIGV2 ZW4gaW4gY2FzZSBvZiBIMywgb3VyIGNvbmNsdXNpb24gbWlnaHQgZGVwZW5kIG9uIGhvdyB0aGUg SDMgPGJyPg0KZW5kcG9pbnQgd2FzIGRpc2NvdmVyZWQuIFdlIG1pZ2h0IGFyZ3VlIHRoYXQgaXQg bWFrZXMgc2Vuc2UgdG8gcGVybWl0IDxicj4NCnRoZSBmYWxsYmFjayB3aGVuIHRoZSBIMyBlbmRw b2ludCB3YXMgZGlzY292ZXJlZCBkdWUgdG8gYW4gdXBncmFkZSA8YnI+DQpmcm9tIFRDUCAoZS5n LiBhbHQtc3ZjKS4gQnV0IHRoZSBzaXR1YXRpb24gd291bGQgYmUgZGlmZmVyZW50IGlmIHRoZSA8 YnI+DQpIMyBlbmRwb2ludCB3YXMgZGlzY292ZXJlZCB0aHJvdWdoIG90aGVyIG1lYW5zIChlLmcu LCBleHRlbnNpb24gZmllbGQgPGJyPg0Kb2YgRVNOSSByZWNvcmQpLiA8YnI+DQo8YnI+DQomZ3Q7 IC09UiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg77u/T24gMi8yMC8xOSwgMTE6NDQgQU0sICZxdW90 O1FVSUMgb24gYmVoYWxmIG9mIFTDtm1hIEdhdnJpY2hlbmtvdiZxdW90OyAmbHQ7cXVpYy1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB4aW1hZXJhQGdtYWlsLmNvbSZndDsgd3JvdGU6DQo8 YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gV2VkLCBGZWIgMjAsIDIwMTkgYXQgMTA6NDkgQU0gQ2hy aXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7IHdyb3RlOg0KPGJyPg0K Jmd0OyAmZ3Q7IHRoZSBwcm9wb3NpdGlvbiBoZXJlIGFsbG93cyBhIG1pZGRsZS1ib3ggb3IgYSBt YW4tb24tdGhlLXNpZGUgdG8gc2VuZCBhbiA8YnI+DQomZ3Q7ICZndDsgdW5lbmNyeXB0ZWQgc2ln bmFsIGFuZCBoYXZlIHRoZSBjbGllbnQgaW1tZWRpYXRlbHkgaW1tZWRpYXRlbHkgZHJvcCB0aGUg PGJyPg0KJmd0OyAmZ3Q7IGNvbm5lY3Rpb24uIFRoYXQgZG9lcyBub3QgZmVlbCByaWdodC4gPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEEgbWFuLW9uLXRoZS1zaWRlIChkb24ndCBldmVuIG1lbnRpb25p bmcgYSBib3gtaW4tdGhlLW1pZGRsZSkgY291bGQgPGJyPg0KJmd0OyAqYWx3YXlzKiBtYWtlIGEg Y2xpZW50IGRyb3AgYSBjb25uZWN0aW9uLCBlLmcuLCBieSBzZW5kaW5nIGEgbGFyZ2UgPGJyPg0K Jmd0OyBhbW91bnQgb2YganVuayBwYWNrZXRzIHRvd2FyZHMgdGhlIGNsaWVudCB0aGF0IHRoZSBj bGllbnQgd291bGQgYmUgPGJyPg0KJmd0OyB1bmFibGUgdG8gY29ycmVjdGx5IGhhbmRsZS4gSXQn cyBqdXN0IGEgbWF0dGVyIG9mIGhvdyBtdWNoIGhhcm0gZG9lcyA8YnI+DQomZ3Q7IHRoYXQgYm94 IG5lZWQgdG8gZG8gdG8gdGhlIG5ldHdvcmsuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbnkgb3Bw b3NpdGUgYXBwcm9hY2ggSSBjYW4gdGhpbmsgb2YgcmVxdWlyZXMgdG8gcHV0IHRoZSBwcml2YXRl IGtleSA8YnI+DQomZ3Q7IG9mIHRoZSBzZXJ2ZXIgb24gYSBERG9TIGhhbmRsaW5nIG1hY2hpbmUg b3IgdG8gZGVwbG95IGl0IG9udG8gYSBERG9TIDxicj4NCiZndDsgbWl0aWdhdGlvbiBjbG91ZCwg d2hpY2ggbm90IG9ubHkgaW5jcmVhc2VzIGV4cG9zdXJlIG9mIHRoZSB1c2VycycgZGF0YSA8YnI+ DQomZ3Q7IGJ1dCBpcyBhbHNvIGV4cGxpY2l0bHkgZm9yYmlkZGVuIGluIGNlcnRhaW4gY291bnRy aWVzIGZvciBjb21wYW5pZXMgPGJyPg0KJmd0OyBmcm9tIGNlcnRhaW4gaW5kdXN0cmllcy4gSXQn cyBhbHJlYWR5IG9ubHkgbmFycm93bHkgcG9zc2libGUgdG8gYXZvaWQgPGJyPg0KJmd0OyBkb2lu ZyBzbyB3aXRoIFFVSUMgKGFuZCB0aGF0IGFscmVhZHkgcmVxdWlyZXMgZWl0aGVyIGEgY29sbGFi b3JhdGlvbiA8YnI+DQomZ3Q7IGJldHdlZW4gdGhlIFFVSUMgbGlicmFyeSBzdXBwbGllciBhbmQg dGhlIEREb1MgbWl0aWdhdGlvbiB2ZW5kb3Ig4oCUIDxicj4NCiZndDsgd2hpY2ggaW4gdHVybiBs ZWFkcyB0byB2ZW5kb3IgbG9jayDigJQgb3IgYSByZXZlcnNlIGVuZ2luZWVyaW5nLWJhc2VkIDxi cj4NCiZndDsgZGVzaWduKSwgc28gdW50aWwgd2UgaGF2ZSBhIHYyIHdoaWNoIGlzIChob3BlZnVs bHkpIG1vcmUgTEIgYW5kIDxicj4NCiZndDsgRERvUy1hd2FyZSwgdGhpcyBpcyB0aGUgbGVzc2Vy IG9mIHR3byBldmlscy4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tIDxicj4NCiZndDsgVMO2bWEg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJy Pg0KS2F6dWhvIE9rdSA8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB6PR10MB17663D1D1A04E7337E02CBA0AC7E0DB6PR10MB1766EURP_-- From nobody Thu Feb 21 00:22:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABC412D4F3 for ; Thu, 21 Feb 2019 00:22:05 -0800 (PST) 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, HTML_MESSAGE=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 nLqhLpfro-aQ for ; Thu, 21 Feb 2019 00:22:02 -0800 (PST) Received: from enrai.xavamedia.nl (enrai.xavamedia.nl [217.115.195.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213F4130FF0 for ; Thu, 21 Feb 2019 00:22:01 -0800 (PST) Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by enrai.xavamedia.nl (Postfix) with ESMTPSA id F13CD90007E for ; Thu, 21 Feb 2019 09:21:58 +0100 (CET) Received: by mail-ua1-f47.google.com with SMTP id d21so9187894uap.9 for ; Thu, 21 Feb 2019 00:21:58 -0800 (PST) X-Gm-Message-State: AHQUAub8kkb17m+2U+lH9K5l0U1UAP73thL5hnBSWjHOWvuFfso0hVlX BhV9424z+5EHYxwrOMnkjQR1TApfdbq3ZB7GNdg= X-Google-Smtp-Source: AHgI3IbxRJCKXbPZcsU0cE0ETqV2BFGw0wsO6D9V0T1nL3B/OBB4pc9azDpv2yTeaQf1GhiDmkwhxBi358p2UcAPe/M= X-Received: by 2002:ab0:26d:: with SMTP id 100mr21038380uas.110.1550737317853; Thu, 21 Feb 2019 00:21:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dirkjan Ochtman Date: Thu, 21 Feb 2019 09:21:46 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Unit test proposal To: Kenneth McMillan Cc: QUIC WG Content-Type: multipart/alternative; boundary="000000000000f87f250582632afe" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 08:22:05 -0000 --000000000000f87f250582632afe Content-Type: text/plain; charset="UTF-8" On Wed, Feb 20, 2019 at 2:05 AM Kenneth McMillan wrote: > Please let me know if you think this seems worthwhile, or if it's > redundant with any existing work. > It sounds useful to me. On the other hand, I'm not sure a language-independent API is the best form here? It seems that languages are sufficiently different that a single API might be hard to implement sanely/simply across different languages. Maybe it would make more sense to define a file format, similar to what's already been done for QPACK (I believe it's called QIF)? It could probably be based on how Wireshark pcaps are defined. Regards, Dirkjan --000000000000f87f250582632afe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 20, 2019 at 2:05 AM Kenneth M= cMillan <kenmcmil=3D40microsoft.com@dmarc.ietf.org> wrote:
Please let me know if you think this seems worth= while, or if it's redundant with any existing work.

=C2=A0It sounds useful to me. On the other hand, I= 'm not sure a language-independent API is the best form here? It seems = that languages are sufficiently different that a single API might be hard t= o implement sanely/simply across different languages. Maybe it would make m= ore sense to define a file format, similar to what's already been done = for QPACK (I believe it's called QIF)? It could probably be based on ho= w Wireshark pcaps are defined.

Regards,
=
Dirkjan
--000000000000f87f250582632afe-- From nobody Thu Feb 21 02:43:00 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60807130F39 for ; Thu, 21 Feb 2019 02:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcA20nUpF5wg for ; Thu, 21 Feb 2019 02:42:52 -0800 (PST) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 8311A130FF6 for ; Thu, 21 Feb 2019 02:42:50 -0800 (PST) Received: by mail-yw1-xc32.google.com with SMTP id d190so10436297ywd.12 for ; Thu, 21 Feb 2019 02:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=g6AzZlydCqdh9pxWbE4DtK2fJum6DN49RS61zmN382I=; b=Q1Y+n4w9biqMEhOnWAwDXCu3hd/OjwWf7+4oAPKHY1ptSlD5JdBeE3dNdjE8BtSXGQ 3On9nhuZwps24NKVLmcPlrt4dNgnO8b+dPHFuhCX8Wmx9MK8OBsC4QrcXmnqBnNApezJ q7LFqlSpLS+81BZ2GriUFjs+FlYfI2m/4vDH5HQmyIqV+2DYU0Z1V6PlWGsXXLfE4p7u nYxcJolCT5v3UBcJAKf/kWKTfcaJ2/i53wvP/0G+SqJ26MTeEFyPtuQ3EiGnW3phbfXk yS7JZHx6cLFf9bt/sQVQv5nCL/k59Y6Ew4syiKR1q5vBCYO/fScsosUC6ByAVLv2DxFL Yy7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=g6AzZlydCqdh9pxWbE4DtK2fJum6DN49RS61zmN382I=; b=g5TM3C0csLggJ3f667iDgnWcZgOx4DypTCpnZHw3uk9LaA49L806jh6MjQ36sql1fo ewKtm5kO9cEXQNo0W46kfXk6voWZABI/5uNSEEffEuTXlU+3S8sbDdMzvG9Zps88TWoP ybOx50rWWrgqQh0qV/LEVrUDNdEx9AQAoVz++mh1NXHsxco2Y0Yvhz6dtr9jRbdTN2Vy b1g0vBIuZpOMlXm51eirauGYzvRgjcPqIEJpaTSkuDHbNF/FoO2ozlkJw+CKQV+B4BMr S6oSVDbKvmbuqanqi5nHQ4vmegjs/SgBalwRnjwmR6+dSqmgk7N5ajt+EJHqVPLzd6K8 Oi1g== X-Gm-Message-State: AHQUAubH8JNy2km+WYgNOQ+K7P6gMr4WieCzB96ptwjLt00Nvzqr5LZY CUo1t7Ha+9mbcNstyals/nXt27hgBQxM4ZWK8C4= X-Google-Smtp-Source: AHgI3IaQJGsXXjKcD1cZmy4jPCNXE+4s0DwqHPjKUNo43QRbwgo99ab/gIRxVN7P/6Z3yuKKXBtX+oTNUXrCkjux6C0= X-Received: by 2002:a81:6b09:: with SMTP id g9mr20384719ywc.255.1550745769395; Thu, 21 Feb 2019 02:42:49 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Thu, 21 Feb 2019 02:42:30 -0800 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Kazuho Oku Cc: Roberto Peon , Christian Huitema , Nick Banks , IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 10:42:58 -0000 > Anyways, the issue is with H3, not QUIC as a transport protocol. HTTP > is unique in sense that it can use either TCP or QUIC as a transport. > We cannot expect every application protocol to have that kind of > property. =E2=80=94 Well, I personally agree as long as two conditions are met: 1) The considerations discussed above are reflected in the HTTP/3 spec =E2=80=94 and that one certainly might be outside of this WG's area of responsibility; 2) The QUIC spec is tailored for consistency with the charter, specifically in the Section 1 "Introduction" where it states that, to quote, "QUIC is a multiplexed and secure general-purpose transport protocol". As far as my myopic eyes can read, there's no requirement in the charter for the protocol to be general purpose, and also effectively the overall context of the discussions in the mailing list (as a whole) and within this thread (in particular) doesn't imply generic applicability, focusing strictly on the HTTP/X use case instead. A "general purpose" goal IMO implies sort of more attention to the variety of use cases, featuring probably some suggestions on how [nearly] all the important applications active within the Internet should be able to switch from the previous general purpose protocols No. 6 and 17 towards the new 17+, or if some of them couldn't, then why. If the new protocol only fits some certain use cases (e.g. HTTP), then it's fine to release it under the existing charter, however, the promise in the Section 1 in this case needs to be further reviewed. 1) > And even in case of H3, our conclusion might depend on how the H3 > endpoint was discovered. We might argue that it makes sense to permit > the fallback when the H3 endpoint was discovered due to an upgrade > from TCP (e.g. alt-svc). But the situation would be different if the > H3 endpoint was discovered through other means 2) > Why not deal with this at the DNS layer > and work with the designs that are floating? =E2=80=94 This is totally correct as long as the required changes in the DN= S protocol =E2=80=94 whatever they are =E2=80=94 are implemented and deployed= across the DNS infrastructure before HTTP/3 sees the light of day. -- T=C3=B6ma From nobody Thu Feb 21 04:00:03 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939DD130F9C for ; Thu, 21 Feb 2019 04:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 ppc0Wkt-C-pz for ; Thu, 21 Feb 2019 03:59:59 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 61D39128B36 for ; Thu, 21 Feb 2019 03:59:59 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id m137so22007690ita.0 for ; Thu, 21 Feb 2019 03:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=yFkomaD3ibZ0bUNC1lm9mpF1tKPRi8WKAg4adOxNccE=; b=VJnwqUFpoizpqtg6vNeLbSGUszST9NYERkKwDRK9s+GU1sYjZrJDaMRq4ONyeRdgRf KwMr2rTW4Qj23JMnfRJ8TWRvTMpyO+lvXm+l8kGRaL6RQ6YM7io5byQ/qT3WBVRjSnu5 TS67cU48McvqBKqVp9k8ZclvlwUIKhjSFbYZzamu2c12NsyuajYCXst88JJuVX5Qehly FGV+hAju/nDQKdIa86LKSbBt6aLYJ0fTuKyWrt8mRAAUlCT2a5xJKniZjLESwNdOZ5Y8 x+mNl5H9r1c6HMlmmyGEghTXNpYulDhoxhRdZJxdFvrX9M6vKD5qW3IINpZ/Xq1qROTu URAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=yFkomaD3ibZ0bUNC1lm9mpF1tKPRi8WKAg4adOxNccE=; b=qdjtCukC4sx90TuA7StNli1tkPVE5kuHMRV5KZtxQvxcsCmxKnuzsWtvs2n0pwTuf8 OQ9Osdymil2dNkpp1Gva7EV2u0thYyPnXMzsLG0kfUIqlBE7LMRgddP1A10DncVch+YE F7B/xL4ZIlU/0FkgRaVtX47UeE3t0eE0bkKulhM2OFxv/Xyne8vqmoUY5woXGsr6Ya0P uOvxjtrtiw1/ZORQ4C30KDvYuCoFSpaR1/AoVNr5ys84WRgVLYAN2ahHDm9vcEdLTNgD Nf1AndcbaDPwGElk4myibA16uUi9dzLNbp+OTcQMyx1oYZtsraDPcYmSz5TLVFt6wiDY B6lA== X-Gm-Message-State: AHQUAuZgEXtQyGO+8HNBXCNyKjhG/OkB0iNfzo2zlT5MJFx7YLTnw5pY fRH62oxY1l1u7wPq3FOd59kW1zFlU4zZEAwVx4o= X-Google-Smtp-Source: AHgI3IYEVU1Aqk9i40CtUJ1HO62Ce++P8z8Z62txoAoy6br3JieMq3cRLmrhXhnfbVs9o0/z0lSsMR+q/WEI5B+7iuw= X-Received: by 2002:a02:6:: with SMTP id 6mr20855532jaa.19.1550750398645; Thu, 21 Feb 2019 03:59:58 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Feb 2019 03:59:57 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 21 Feb 2019 03:59:57 -0800 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Kazuho Oku , =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Cc: Nick Banks , IETF QUIC WG , Roberto Peon , Christian Huitema Content-Type: multipart/alternative; boundary="000000000000a58c76058266364d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 12:00:03 -0000 --000000000000a58c76058266364d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > effectively the overall context of the discussions in the mailing list (as a > whole) and within this thread (in particular) doesn't imply generic > applicability, focusing strictly on the HTTP/X use case instead. I would strongly oppose that. While there are more general purpose features schedule for v2 and the main driver for v1 is HTTP, a lot of design decisions and discussion consider other uses cases, for example tunnelling, extension frames, peer to peer networking, separation of stream id semantics and the general layer segregation as is evident in error codes. On 21 February 2019 at 11.43.10, T=C3=B6ma Gavrichenkov (ximaera@gmail.com) wrote: > Anyways, the issue is with H3, not QUIC as a transport protocol. HTTP > is unique in sense that it can use either TCP or QUIC as a transport. > We cannot expect every application protocol to have that kind of > property. =E2=80=94 Well, I personally agree as long as two conditions are met: 1) The considerations discussed above are reflected in the HTTP/3 spec =E2=80=94 and that one certainly might be outside of this WG's area of responsibility; 2) The QUIC spec is tailored for consistency with the charter, specifically in the Section 1 "Introduction" where it states that, to quote, "QUIC is a multiplexed and secure general-purpose transport protocol". As far as my myopic eyes can read, there's no requirement in the charter for the protocol to be general purpose, and also effectively the overall context of the discussions in the mailing list (as a whole) and within this thread (in particular) doesn't imply generic applicability, focusing strictly on the HTTP/X use case instead. A "general purpose" goal IMO implies sort of more attention to the variety of use cases, featuring probably some suggestions on how [nearly] all the important applications active within the Internet should be able to switch from the previous general purpose protocols No. 6 and 17 towards the new 17+, or if some of them couldn't, then why. If the new protocol only fits some certain use cases (e.g. HTTP), then it's fine to release it under the existing charter, however, the promise in the Section 1 in this case needs to be further reviewed. 1) > And even in case of H3, our conclusion might depend on how the H3 > endpoint was discovered. We might argue that it makes sense to permit > the fallback when the H3 endpoint was discovered due to an upgrade > from TCP (e.g. alt-svc). But the situation would be different if the > H3 endpoint was discovered through other means 2) > Why not deal with this at the DNS layer > and work with the designs that are floating? =E2=80=94 This is totally correct as long as the required changes in the DN= S protocol =E2=80=94 whatever they are =E2=80=94 are implemented and deployed= across the DNS infrastructure before HTTP/3 sees the light of day. --=20 T=C3=B6ma --000000000000a58c76058266364d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = > effectivel= y=C2=A0the overall context of the discussions in the mailing li= st (as a=C2=A0
> whole) and within this thread (in particu= lar) doesn't imply generic=C2=A0
> applicability, focu= sing strictly on the HTTP/X use case instead.=C2=A0

I would strongly opp= ose that. While there are more general purpose features schedule for v2 and= the main driver for v1 is HTTP, a lot of design decisions and discussion c= onsider other uses cases, for example tunnelling, extension frames, peer to= peer networking, separation of stream id semantics and the general layer s= egregation as is evident in error codes.

On 21 February 2019 at 11.43.10, T=C3=B6ma Gavrichenkov (ximaera@gmail.com) wrote:

> Anyways, the = issue is with H3, not QUIC as a transport protocol. HTTP
> is unique in sense that it can use either TCP or QUIC as a transpo= rt.
> We cannot expect every application protocol to have that kind of
> property.

=E2=80=94 Well, I personally agree as long as two conditions are met:
1) The considerations discussed above are reflected in the HTTP/3 spec
=E2=80=94 and that one certainly might be outside of this WG's area= of
responsibility;
2) The QUIC spec is tailored for consistency with the charter,
specifically in the Section 1 "Introduction" where it states = that, to
quote, "QUIC is a multiplexed and secure general-purpose transport
protocol".

As far as my myopic eyes can read, there's no requirement in the
charter for the protocol to be general purpose, and also effectively
the overall context of the discussions in the mailing list (as a
whole) and within this thread (in particular) doesn't imply generic
applicability, focusing strictly on the HTTP/X use case instead.

A "general purpose" goal IMO implies sort of more attention t= o the
variety of use cases, featuring probably some suggestions on how
[nearly] all the important applications active within the Internet
should be able to switch from the previous general purpose protocols
No. 6 and 17 towards the new 17+, or if some of them couldn't, then
why. If the new protocol only fits some certain use cases (e.g. HTTP),
then it's fine to release it under the existing charter, however, t= he
promise in the Section 1 in this case needs to be further reviewed.

1)
> And even in case of H3, our conclusion might depend on how the H3
> endpoint was discovered. We might argue that it makes sense to per= mit
> the fallback when the H3 endpoint was discovered due to an upgrade
> from TCP (e.g. alt-svc). But the situation would be different if t= he
> H3 endpoint was discovered through other means
2)
> Why not deal with this at the DNS layer
> and work with the designs that are floating?

=E2=80=94 This is totally correct as long as the required changes in th= e DNS
protocol =E2=80=94 whatever they are =E2=80=94 are implemented and depl= oyed across the
DNS infrastructure before HTTP/3 sees the light of day.

--
T=C3=B6ma

--000000000000a58c76058266364d-- From nobody Thu Feb 21 06:52:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696FF1286E7 for ; Thu, 21 Feb 2019 06:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hQlPNbkGzCs for ; Thu, 21 Feb 2019 06:52:15 -0800 (PST) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 41291124408 for ; Thu, 21 Feb 2019 06:52:15 -0800 (PST) Received: by mail-yw1-xc2a.google.com with SMTP id c67so10746357ywa.7 for ; Thu, 21 Feb 2019 06:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z3Vv/86fEVepvSK2FbPJFFBvFwluAWfTQv0tr+hBVqk=; b=kfElcUu0TnpBWUHKzLisimrI4V8Oo1w4QNwntzX7TMzYpTLPoGVhbyESFzCgL4Z2ok DAYDxYcIkFxh/AEodkj2+zrgbMHVu4vgQyUuUvgiA8Yw3jtRpIue0kv58OdOuUtw3pXo ePG4H8n7sXhp79zaPMOM70LE77hEAGAG8Rk71UAKqH9Pall0hxE9tTE11qD8YPri+1kc NNSuoboRltp+L6RnIqiaie0HBCfEpDbrnN5ygXEvGm4KqY/K5ieLOMElki6f8Dv4Kws0 zZIVVXlE8FmWvPWsPNHEK1vtYQuEDC2rFr8JrzyaG/CzvAzSAPVqYbTzWaWgaDtywJuZ Gzgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z3Vv/86fEVepvSK2FbPJFFBvFwluAWfTQv0tr+hBVqk=; b=NGiy/g1LrPLP7zZqEHztLvnqH7ehNvrPqTBophihcwfucBRoLwPUhPopaO2/0ptCGL qvKwIweByf5ucfsOBQ1ziOHSc60m8hMNoLtb/0qIMjiMvcdJLJJD7kAtT9ai1LNORm0D UGXgPfdnKExDIlltC5kxs5CgQs1wAzC3RHrkIrkh+l0Ub6+cm5NglIMo6OMhAvUGJ5S3 TOmhgBBd1ShlmuuPlPPodn7I6ZCl3cj4gwDD/FDJlg0psnm6UCiUF2VfU18bi1y/8FDU 5cD5g6btXNUAs7cm5oKPB/t15y4Zqhf7KhxvOcWT8cTQ+vbtBA6xwgxxFdgS/e+q32Hg ayfA== X-Gm-Message-State: AHQUAuZ9kTzY+kzV05rXAmeKOTLiLml2MsrirHvvQHfVdQmNTFNnoN01 CeZNQ7cUScZHyvCarbKPkKyKZV1B9Z36S1KE3kY= X-Google-Smtp-Source: AHgI3IaEo5lIQDnoWnbdpKpUbI2uM75MoymrdnKKf8Pid/9siPordv2LrCXIe6lITbFZbKN8pxyeHVgadQp8YQbf+vs= X-Received: by 2002:a81:1d15:: with SMTP id d21mr31898781ywd.323.1550760733612; Thu, 21 Feb 2019 06:52:13 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Thu, 21 Feb 2019 06:52:00 -0800 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Christian Huitema , quic@ietf.org, Kazuho Oku , Nick Banks , Roberto Peon Content-Type: multipart/alternative; boundary="000000000000a8cc6f0582689e8e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:52:18 -0000 --000000000000a8cc6f0582689e8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2019, 3:59 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I would strongly oppose that. While there are more general purpose > features schedule for v2 and the main driver for v1 is HTTP, a lot of > design decisions and discussion consider other uses cases, > Well, I agree with that, my point being that "a lot of" is not equal to "all of the". -- T=C3=B6ma > --000000000000a8cc6f0582689e8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 21, 2019, 3:59 AM M= ikkel Fahn=C3=B8e J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:
I woul= d strongly oppose that. While there are more general purpose features sched= ule for v2 and the main driver for v1 is HTTP, a lot of design decisions an= d discussion consider other uses cases,

Well, I agree with that, my point being that "a = lot of" is not equal to "all of the".

--
T=C3=B6ma
--000000000000a8cc6f0582689e8e-- From nobody Thu Feb 21 07:02:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C88124408 for ; Thu, 21 Feb 2019 07:02:34 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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=-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 6R7zPjcUYg-z for ; Thu, 21 Feb 2019 07:02:31 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750117.outbound.protection.outlook.com [40.107.75.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 DA50B1286E7 for ; Thu, 21 Feb 2019 07:02:30 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=jCn7Qm7ewpByGk7mqZaq5ZCUfkeycJCDxlZW+tFHRhI=; b=JQpsUQIS60b82zo5zPg3yJ1PUOWMNybpZhPzeFRv7n2ogDZDyPwwxrLggcu8Hlkn5PImpDFDHtilPMnJVPeJ+Dgfbal7FiUfPAqCbYzptlIcQ+IZt0NacqTZl6j2PzZGDfrqsL7xG/Qw7UINz+rLYzC/Bdd1ouArTYwtefFy9UA= Received: from CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) by CY4PR21MB0791.namprd21.prod.outlook.com (10.175.121.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.2; Thu, 21 Feb 2019 15:02:28 +0000 Received: from CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46]) by CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46%3]) with mapi id 15.20.1665.002; Thu, 21 Feb 2019 15:02:28 +0000 From: Nick Banks To: =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: Christian Huitema , "quic@ietf.org" , Kazuho Oku , Roberto Peon Subject: RE: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: AdTInrfRZAbJSsLZSlWCCrlUkiWX7AAgkIeAAACdzgAAAbynAAAAN6coAACOYoAAAIKXwAAAszQAAAatwwAAAd27AP//i/wAgADM8ACAAKJbAIAAFaSAgAAwEgD///4PkA== Date: Thu, 21 Feb 2019 15:02:28 +0000 Message-ID: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-02-21T15:02:25.4654899Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=9dba8210-b584-4baf-8a75-b608484ea427; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [2001:4898:80e8:1:9831:2783:bd10:60a9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 02aad5f0-07b6-45cd-4e63-08d6980d98c5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR21MB0791; x-ms-traffictypediagnostic: CY4PR21MB0791: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTRQUjIxTUIwNzkxOzIzOmhkWnJGd004Q3hYWkYrZkxlZDFuZFlkRjhy?= =?utf-8?B?RUorSUc1RktkSEIyWXBJMGc5c0ovUE1sODlHRitFZlJ6ZkthTVhPUzhaQVR6?= =?utf-8?B?TWFZdk5tVTdlOFRnYURBK1JSWGFYL0lFOWlkTkxSZVBVNkI4TThVNDI2SUww?= =?utf-8?B?VFlwcTNCb2d5cGxBTTlCdStteGpDMDF0NGdNNm5qN3pUcVRyQS8vVGh1a01X?= =?utf-8?B?bmg1aURzK1MzdFUxWitJU2pkZ3BFRDRTQTJWbXlpaGRpc0tTanZGUnNZU1Jr?= =?utf-8?B?N2YxUmtwZWwzU1F2VXpzMG0wQjJGRUcrUy91aWxhQnpFS0RQZzNad0gxWHR6?= =?utf-8?B?OWtVaDJPTk5GcEdlVTlKYXRGQjZMSVIyZmJVaCtNaGNMa0YrK2s5b2J0ZGlC?= =?utf-8?B?MmFwVVh6amJXVEZ6QkpqR05wdy9FbjhIcU9pQnBjajRIWlY5NjJSSnVoY2o2?= =?utf-8?B?UkVKS0xoMDA1MWx3UUpMRVBadE8vZW51bnh3ZStpY01xakJ2VFJPei9hejBW?= =?utf-8?B?ZTVGTk40WDBQTjZMUTh4NDNCQ3VpRS9Ua1hYQWxiWWJIbzVlRGFzbStJcE16?= =?utf-8?B?WXgxL3V3QjNXbVkwbVlvSDJRWUNPems4K2JqamtvWDdQdVFXcTVkb2w3Z2ds?= =?utf-8?B?emxPQU5RRW5rWXRBMXdlaFFoYmxjMGdnSERIOHprSzJyMjN5d2VseStwL0pB?= =?utf-8?B?ZVVUQ2tDVUx1RDQyK051R1RKcFFCdHlPNnVNMWF5aytRRnhEcTdMK1MyNXBn?= =?utf-8?B?TXdPYlc1a1Bvc0w3N3A0RWhKeFY5MmFJVGJUWUUzUkpGbjFIQWxFeTBGc0Ni?= =?utf-8?B?U1c2SC9ESlVCTEd0cWQvNVBJMFhJTHIxUWFCZDhlTjBBdFVsaFY1YWZaeFZR?= =?utf-8?B?SXA4WjUxR1Jja29uU2FKTHJSNHZpMkRYT3ZLb3FvVXZXTVlUS04wSlZzVWdS?= =?utf-8?B?VXVVRXNpOWU4d2lXZnlhY3N5QVdIdU56Q0Z6d080M0QxNXU4a3FMT3ZMcWgr?= =?utf-8?B?WXppZDRMVEp4SEdSL3g4cjdRVzk0T1g5T1hYZFdwam0ySStmM0ZmTEVPSnJs?= =?utf-8?B?UEVRSXk5NXlhSUVtRm9xU3UzemZVRUxBK2RvNkRSZ1lDZVB0VVpkV3lHZ3Rl?= =?utf-8?B?SnZZNjd2R1RuL2E1Wm9kK3R2OVZGUmdJVmVBZmlTNGV1VXBlanlGZlVqMWUy?= =?utf-8?B?aW5lUWcrOG5XczJjN3JycktPc2FXL3FNMWxNMW5MaVc4RWFZT25oazhhaWs5?= =?utf-8?B?NHVlNHpMSGtadmZSR1h4MWJyWW9jVS95TWE0M3NkMElmYitwNG9iY0F4VGhx?= =?utf-8?B?N2dWaktEbXJlSDg3ZjNsdEdWRUU3VkhIR1B1TGllcGYxeXUrcDV6VmFrbTA4?= =?utf-8?B?WlJNTFR5OFhuTjJZYWJBV3dVZ1BpbzFaWWhaUUI5eTF3c0tPVWlBcDhHZmQy?= =?utf-8?B?ZjhBWGZBZHFEY3dRUkZ0Z0UwQVZDU0V1RmxzTHFNczhPajQzNjkyQ2h5aXhQ?= =?utf-8?B?MDhTOUFDTU1JakljanJRVytsSmJXa0VyK1JiV25mV2k0TlJwNWJ1dktaRkxj?= =?utf-8?B?WG1VQWdNV09EaFpTem4ybWF0K213QUpMcG1JakhhWFVOKzZOWlUzMVcwWTU2?= =?utf-8?B?cVlUcXNWbGg0WVcrbks3eHUvZ2RBZUZSZm1NWERzQ1VPU1hxVmhnWml4YjNO?= =?utf-8?B?OE42VWFBNDJjQTF1OHRxRi9MMjI0ZGw5ZUsrNGtyRjJzVXpaZFBiLzgxMEdX?= =?utf-8?B?ZUl2RjhPbjF6QThHSUhodkhTVm5vYnhwVEg2MmhTbjlnd1lqTWUwN2JGOEx3?= =?utf-8?B?QUVJVDF4cjg2K0s1c3UvbllaaVJLS2hmbFYvczlhRlY3dFhyZXlaL0IyTzJs?= =?utf-8?B?VFgxZGJ3VHZHRTkvOElia3VYMVI0bXkydTJhdENjdXRLTmVzeG1udmpWU1Qy?= =?utf-8?Q?/ypW/1RHig/vPRpEfK/5jqUnEq8NJE=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(136003)(39860400002)(396003)(189003)(199004)(14454004)(229853002)(66574012)(11346002)(7736002)(446003)(55016002)(8990500004)(9686003)(74316002)(236005)(8676002)(81166006)(81156014)(8936002)(6306002)(54896002)(478600001)(33656002)(93886005)(68736007)(10290500003)(10090500001)(486006)(5660300002)(476003)(54906003)(97736004)(6246003)(7696005)(25786009)(14444005)(110136005)(105586002)(2906002)(46003)(186003)(106356001)(790700001)(76176011)(22452003)(86612001)(6346003)(102836004)(71190400001)(6436002)(71200400001)(6116002)(256004)(6506007)(53546011)(53936002)(99286004)(4326008)(86362001)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0791; H:CY4PR21MB0854.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lF4IQf1xukkW3g7YJ0m1kapzQBlPKMSPjhQTq9oV076Hh5SuzWvK+8ajvKu3TjCghDAiUF4OthRDkyQ/7PMfliJWZiMa2iIKgR+hIJahMe/VJR2TIBJ2wevn8miJBbCVmri3ou7hinPlo6aKvWSi8m1QQ8SCT0XFMglPK3MRlBEgszE4qZKHa8XuDmLx2RRV8sQk5I/gTLe4yBP6fdJPRw3x49fizYdP16nlBgbzHNJIJJBS82jdpcsmhrJ33q/XT1FdLnLFQvAWlqiiAFSdT4C8U45DW295vdYcZzOP+9W9mkOddkbC1xy0ojyjxtoF98rE79r4bmlDcRuf4iDeKFfVr5J38rAFXavqfWlcBM07JE0QtjVxePly5q+HP6N9Y3A/lQSukBj4AiTrANyoZHDciQ4fwppsHr52dEVQ3g4= Content-Type: multipart/alternative; boundary="_000_CY4PR21MB08548DD7D1D4628969AAFDCEB37E0CY4PR21MB0854namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02aad5f0-07b6-45cd-4e63-08d6980d98c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 15:02:28.3467 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0791 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 15:02:34 -0000 --_000_CY4PR21MB08548DD7D1D4628969AAFDCEB37E0CY4PR21MB0854namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIHRoZW4gcGVyaGFwcyBJIHNob3VsZCBwb3NlIGEgc2xpZ2h0bHkgbW9yZSB0YXJnZXRlZCBx dWVzdGlvbi4gV2hhdCBhcmUgcGVvcGxl4oCZcyBIMyBpbXBsZW1lbnRhdGlvbnMgZ29pbmcgdG8g ZG8gaWYgdGhleSBnZXQgYSBTRVJWRVJfQlVTWSBmcm9tIGEgUVVJQyBzZXJ2ZXI/IFdoYXQgc2hv dWxkIHdlIHJlY29tbWVuZCB0aGV5IGRvIChlaXRoZXIgaW4gYXBwbGljYWJpbGl0eSBvciBoMyBk cmFmdHMpPw0KDQpGb3IgQXp1cmUsIHdlIGFyZSBzZXJpb3VzbHkgY29uc2lkZXJpbmcgdXNpbmcg dGhpcyBhcyBhIHRlbXBvcmFyeSBERG9TIHByb3RlY3Rpb24gc29sdXRpb24gdW50aWwgd2UgY2Fu IGdldCBhIG1vcmUgZnVsbHkgZnVuY3Rpb25hbCBzeXN0ZW0gaW4gcGxhY2UuIEkganVzdCB3YW50 IHRvIG1ha2Ugc3VyZSBpdCBkb2VzbuKAmXQgcmVzdWx0IGluIGF3ZnVsIGJlaGF2aW9yIG9uIHRo ZSBjbGllbnQgc2lkZS4NCg0KVGhhbmtzLA0KLSBOaWNrDQoNCkZyb206IFTDtm1hIEdhdnJpY2hl bmtvdiA8eGltYWVyYUBnbWFpbC5jb20+DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjEsIDIw MTkgNjo1MiBBTQ0KVG86IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWls LmNvbT4NCkNjOiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IHF1aWNA aWV0Zi5vcmc7IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+OyBOaWNrIEJhbmtzIDxu aWJhbmtzQG1pY3Jvc29mdC5jb20+OyBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4NClN1Ympl Y3Q6IFJlOiBFeHBlY3RlZCBDbGllbnQgUmVzcG9uc2UgdG8gU0VSVkVSX0JVU1kNCg0KT24gVGh1 LCBGZWIgMjEsIDIwMTksIDM6NTkgQU0gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2Vs ZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PiB3cm90ZToNCkkgd291bGQg c3Ryb25nbHkgb3Bwb3NlIHRoYXQuIFdoaWxlIHRoZXJlIGFyZSBtb3JlIGdlbmVyYWwgcHVycG9z ZSBmZWF0dXJlcyBzY2hlZHVsZSBmb3IgdjIgYW5kIHRoZSBtYWluIGRyaXZlciBmb3IgdjEgaXMg SFRUUCwgYSBsb3Qgb2YgZGVzaWduIGRlY2lzaW9ucyBhbmQgZGlzY3Vzc2lvbiBjb25zaWRlciBv dGhlciB1c2VzIGNhc2VzLA0KDQpXZWxsLCBJIGFncmVlIHdpdGggdGhhdCwgbXkgcG9pbnQgYmVp bmcgdGhhdCAiYSBsb3Qgb2YiIGlzIG5vdCBlcXVhbCB0byAiYWxsIG9mIHRoZSIuDQoNCi0tDQpU w7ZtYQ0K --_000_CY4PR21MB08548DD7D1D4628969AAFDCEB37E0CY4PR21MB0854namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PaywgdGhlbiBwZXJoYXBzIEkgc2hvdWxkIHBvc2UgYSBzbGlnaHRseSBt b3JlIHRhcmdldGVkIHF1ZXN0aW9uLiBXaGF0IGFyZSBwZW9wbGXigJlzIEgzIGltcGxlbWVudGF0 aW9ucyBnb2luZyB0byBkbyBpZiB0aGV5IGdldCBhIFNFUlZFUl9CVVNZIGZyb20gYSBRVUlDIHNl cnZlcj8gV2hhdCBzaG91bGQgd2UgcmVjb21tZW5kIHRoZXkgZG8gKGVpdGhlciBpbiBhcHBsaWNh YmlsaXR5IG9yIGgzIGRyYWZ0cyk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBBenVyZSwg d2UgYXJlIHNlcmlvdXNseSBjb25zaWRlcmluZyB1c2luZyB0aGlzIGFzIGEgdGVtcG9yYXJ5IERE b1MgcHJvdGVjdGlvbiBzb2x1dGlvbiB1bnRpbCB3ZSBjYW4gZ2V0IGEgbW9yZSBmdWxseSBmdW5j dGlvbmFsIHN5c3RlbSBpbiBwbGFjZS4gSSBqdXN0IHdhbnQgdG8gbWFrZSBzdXJlIGl0IGRvZXNu 4oCZdCByZXN1bHQgaW4gYXdmdWwgYmVoYXZpb3Igb24gdGhlIGNsaWVudCBzaWRlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tIE5pY2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFTDtm1hIEdh dnJpY2hlbmtvdiAmbHQ7eGltYWVyYUBnbWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgRmVicnVhcnkgMjEsIDIwMTkgNjo1MiBBTTxicj4NCjxiPlRvOjwvYj4gTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7OyBxdWlj QGlldGYub3JnOyBLYXp1aG8gT2t1ICZsdDtrYXp1aG9va3VAZ21haWwuY29tJmd0OzsgTmljayBC YW5rcyAmbHQ7bmliYW5rc0BtaWNyb3NvZnQuY29tJmd0OzsgUm9iZXJ0byBQZW9uICZsdDtmZW5p eEBmYi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBFeHBlY3RlZCBDbGllbnQgUmVz cG9uc2UgdG8gU0VSVkVSX0JVU1k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBUaHUsIEZlYiAyMSwgMjAxOSwgMzo1OSBBTSBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2Vu ICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIj5taWtrZWxmakBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2IGlkPSJtXzE3NDcxMzYwMjYyNzA2MjIwOWJsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd291bGQgc3Ryb25nbHkgb3Bw b3NlIHRoYXQuIFdoaWxlIHRoZXJlIGFyZSBtb3JlIGdlbmVyYWwgcHVycG9zZSBmZWF0dXJlcyBz Y2hlZHVsZSBmb3IgdjIgYW5kIHRoZSBtYWluIGRyaXZlciBmb3IgdjEgaXMgSFRUUCwgYSBsb3Qg b2YgZGVzaWduIGRlY2lzaW9ucyBhbmQgZGlzY3Vzc2lvbiBjb25zaWRlcg0KIG90aGVyIHVzZXMg Y2FzZXMsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZWxsLCBJIGFncmVlIHdpdGggdGhhdCwgbXkgcG9pbnQgYmVpbmcgdGhhdCAm cXVvdDthIGxvdCBvZiZxdW90OyBpcyBub3QgZXF1YWwgdG8gJnF1b3Q7YWxsIG9mIHRoZSZxdW90 Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlTD tm1hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB08548DD7D1D4628969AAFDCEB37E0CY4PR21MB0854namp_-- From nobody Thu Feb 21 07:32:59 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249C3130EA4 for ; Thu, 21 Feb 2019 07:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYoK_C0mZCn8 for ; Thu, 21 Feb 2019 07:32:51 -0800 (PST) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAC312F1A2 for ; Thu, 21 Feb 2019 07:32:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 444z4d0sRyz15Knq; Thu, 21 Feb 2019 16:32:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbX00yA57WKy; Thu, 21 Feb 2019 16:32:47 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.24] (i577BCE6A.versanet.de [87.123.206.106]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 21 Feb 2019 16:32:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Expected Client Response to SERVER_BUSY From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 21 Feb 2019 16:32:45 +0100 Cc: Roberto Peon , Praveen Balasubramanian , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> To: =?utf-8?Q?T=C3=B6ma_Gavrichenkov?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 15:32:58 -0000 As pointer out earlier in this thread there is text in = https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/ (section = 2).=20 Do you think anything else is needed? > Am 20.02.2019 um 23:56 schrieb T=C3=B6ma Gavrichenkov = : >=20 > > This mechanism provides a very low CPU cost > > fast fallback to TCP under DoS attacks until all > > infrastructure can support QUIC natively >=20 > There are [a] few use cases when switching from TCP to QUIC v1 (in its = current state) is not feasible because of huge operational costs. So it = would be a more long term solution than that, probably till v2 or even = further. >=20 > > anything we do to allow non-malicious ones to > > respond appropriately requires pre-sharing, > > or for the connection to succeed >=20 > The question here is basically how to ensure the latter given a X00 = Gbps attack scale if you're neither Facebook nor Google. >=20 > > In some circumstances, falling back to TCP > > may be something that the application shouldn't do >=20 > Well, maybe, but then IMO the consequences of not being able to = benefit from switching to TCP if you're doing certain things with QUIC = should be outlined in the spec. Again, this is an application-level = thing *now*, but formerly the transport used to take full care of it, = and the change in that sort of breaks the habit of the users. >=20 > -- > T=C3=B6ma From nobody Thu Feb 21 07:43:14 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80512F1A2 for ; Thu, 21 Feb 2019 07:43:13 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 4T-MczaQbnAF for ; Thu, 21 Feb 2019 07:43:11 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680119.outbound.protection.outlook.com [40.107.68.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04C8129284 for ; Thu, 21 Feb 2019 07:43:10 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=Zlv0xMMPcYcZZx5Qll5FfkD4k6pCFKcY4iAon+ltxm4=; b=WcwIuKjEJd/FdETAqAcQSXTUGq+c/r3LjwNllL1SzzCbPSlePNfR553ICxVYDFWiX4XTlWqCxyRWd2YbpBoum+xynRgQgmOvXpAZ48v+74c5b0o2i03ktwkzd15exDQS7UmYWN45/ow7mrpSxduBAjeTOXfd/9bWUS4j7wZqU9M= Received: from CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) by CY4PR21MB0471.namprd21.prod.outlook.com (10.172.121.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.9; Thu, 21 Feb 2019 15:43:07 +0000 Received: from CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46]) by CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46%3]) with mapi id 15.20.1665.002; Thu, 21 Feb 2019 15:43:07 +0000 From: Nick Banks To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= CC: Praveen Balasubramanian , IETF QUIC WG , Roberto Peon Subject: RE: Expected Client Response to SERVER_BUSY Thread-Topic: Expected Client Response to SERVER_BUSY Thread-Index: AdTInrfRZAbJSsLZSlWCCrlUkiWX7AAgkIeAAACdzgAAAbynAAAAN6coAACOYoAAAIKXwAAAszQAAAatwwAAAd27AP//i/wAgACqDQCAARZXgP///4vg Date: Thu, 21 Feb 2019 15:43:07 +0000 Message-ID: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-02-21T15:43:05.9306986Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=787fdfda-8e50-415c-bb94-724a5dc19c05; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [2001:4898:80e8:1:9831:2783:bd10:60a9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9b271e2-ad67-4b4a-38f6-08d6981346cc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:CY4PR21MB0471; x-ms-traffictypediagnostic: CY4PR21MB0471: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTRQUjIxTUIwNDcxOzIzOnJ3M3VzS3BtK21oYVVISklWNlJOeVJZeUE1?= =?utf-8?B?ZmdpaHk4dFlKdEhXbkc1WUFyaWNML050VHRQcmxtU1puUkdtRDBOYTRjTW5K?= =?utf-8?B?S0p3bFFVY2FYQTZoSlJ1Y2pvN0lZNng0YmIxUlJjVmdnTkhwN09zY3I0dzQv?= =?utf-8?B?SUlIWUNIbHhJOFhsSnUvTjlrVlpneFhQdC9KME8zdys1V1dEcXN3T2daM0ht?= =?utf-8?B?YXM0ckdLQXVjUEN0VGg0YlJxYTlBZWdmelJWZnY2dHNsWlUrK041Vmx4R1Zs?= =?utf-8?B?d2J0bnRyN1VHNlBWNHo2RS9CQzR6TjJSUXg1NUxITGxZbVFoejhVek5UK0l4?= =?utf-8?B?ODA1eVp6WkR3MFdQendPN3BxRFZuVUJpQ3BhZTNKekZjRUNndGN4RHpveHBL?= =?utf-8?B?ZW9uRGFlekpTMkxMa3RqaWUrRWdWNGYrd29wZm9CcGR3RVJHZU9xTmNFUVFG?= =?utf-8?B?WlNESytOdndoaUxITGMxSlpJQ3FlcS85MVU3eDVPSVNrZ1pIb0FZQjVQRmlp?= =?utf-8?B?SytGMksvR3FBQjc5bjhDV3AyVkF1N3lEdzV2UmxJUU92TEx4aGFsTVo5TjdQ?= =?utf-8?B?SFJscHRodWFNSUw2eHYyc05xRmJhRGNtUkdSN2lNWnQrNzg0L1BrZUxHL2pZ?= =?utf-8?B?TDNTT1RVSVB6Y1NXWHlSWkZHV1RQTUV5LzRKU1FKV1o0NEMzNndNbjZwY28v?= =?utf-8?B?SStudmpzeEUvVmpWTTZDOEQrN3JWQmdjQWNLc0JESVVrREZHQTNqRVZXVTk2?= =?utf-8?B?NW05eHlNdWx6QUpuU2lNaXBiOWowcXpObnl3MzdKQ09Dek9MUUp6QzhJbDUz?= =?utf-8?B?MzhkRHRwWmI3cmJvcUIyeGtkV3lvcXZnWXh2K1BtcTdFcXN3WGVJME9HTjJM?= =?utf-8?B?dVZRcjlOYVFYMmk3QnVta2xxakZOTlBScEh6aE1UL0NQc0JnSWJ5SzBuOXk3?= =?utf-8?B?cFJ5b1ZwUllLT2RaQzBUeWs3QWN6bXVpMnBobGRrU3M0SzRYODg4WUFvdktZ?= =?utf-8?B?NzVlaVk4K3V1aVN1OThEQlBSVlc2TnJJNkRzdG1leXN6Y1lWcUFVc0ZKU3NR?= =?utf-8?B?QkRFNDNGb3BKVmU0Rkl6cE1VakkrUlpmc1l6WHpnZkNYOEpMcTcwdlhwS2Jo?= =?utf-8?B?UGxWRTcyUlVPNklqQVlreTZKL04rQmRZZ0U1a0lvYnMxM3BpV2p6emRWbHNq?= =?utf-8?B?NDB3YzQxam1wR0N5cUUybmJ2anFDYVA0b1FDSlNZS3JmTWtTSFQzcGd4UFAz?= =?utf-8?B?YS9NNWNTR2IzMEp5ME9oMnQxbHRNQWVNMFE5dW1mSzdQNU9yNXBIcksyRmJy?= =?utf-8?B?MWt1c0RmT1hqNHFkOU9Wbyt2Ukg4Y1dHWFFEMmhtaXdFa3pmeUtXS1dCMVcw?= =?utf-8?B?NDYvbExzcWNHZCtnQVBoNVo4ekp4WGg5NDhydTBhM2U3cDZVM3dUNXZmTjdY?= =?utf-8?B?aGZWaHdmdXpNdmJXV3ZwcUNXT0VjTjRnY2RJNlRlaGExK2E0OHo5ZFRFUThu?= =?utf-8?B?MHBuQW9kVEUrRG84Q2JKU2o4dHNlZ0M5RUw3d0RZekdRbTMwYmFJdXFxSGE5?= =?utf-8?B?QTRzOWJIeWV1ZjF6ZnFWVjZmaC9BMHhMNlNlWGl0RlRVK0k4WXBVQm9pd05Y?= =?utf-8?B?MmdrbnNweUh1Tng5M2FzYzdQN0tPWTMwTHk5ZldIWWtWSWdKY0owYlNRVDJV?= =?utf-8?B?NCtGQTd2QWozdGZnVnBSSVhvS2Z6dzd4aC8yTFY4aTRVdEtIT0dVa3c5NnBv?= =?utf-8?B?blcxV2xhd3RxUy9heFFTY0tuUkFqeUh6V1h3ZHlBQkhyZjVrSE1SNFFvV3FY?= =?utf-8?B?Qk5tWHNpVjhRVCtXYWk2ZFNwR2krcHdiOVNkZUNxeTFucEQ2d0RsdjJjVW91?= =?utf-8?B?M3JYeVFoV0pwcVdSQU5NVFgzR2p1Qi9ocjNmSGxIcSt4QlBqUk5FbDlXaFZt?= =?utf-8?Q?vS6p41kuY+ssYL7QkXuUpShF4ZqQao=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(39860400002)(366004)(13464003)(199004)(189003)(14454004)(478600001)(10290500003)(2906002)(8990500004)(97736004)(102836004)(53546011)(6506007)(966005)(6346003)(316002)(22452003)(25786009)(10090500001)(99286004)(4326008)(71190400001)(71200400001)(446003)(14444005)(46003)(476003)(86612001)(11346002)(256004)(186003)(66574012)(86362001)(5660300002)(486006)(8676002)(8936002)(53936002)(105586002)(33656002)(305945005)(7736002)(68736007)(81156014)(81166006)(6246003)(229853002)(110136005)(6116002)(54906003)(93886005)(76176011)(106356001)(55016002)(6306002)(9686003)(74316002)(7696005)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0471; H:CY4PR21MB0854.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: UREtfwh0+VvVBMxQcmP1i6h96mCu2/24/HOEKj9JHUZy4nnadGuavb/wtnI6VO0HiN7ghnBL9LhH6b1JhOWtx7IhKoN6YeQVx9A4kvYXkzEsEEPWmbIYH+59F34DGbb59txrAfkF9WlNkGYUbt0qbQYztNu4g1Egk9DJbKWwkP4P8/Ict7BhWydGc7IijClpBgv4b2AckpwK83bpw4yIs20m5afCx5BbvkcP2viz0tsIz9ljkj+wE/4iP2i5Vi7qjfxPkU26+nEhmqNxcVe5cADNyaO863izMtLZn9i8ZR0uRG8l90C2RLSTpGlqsw19hevgqw6KtUtFR0CWbdJwbnu5k35uS7ElNrJ+/IHMb8IZBLANwH5/igkKLgNybFduL0gne+Zp+Aps2Mnf9bssmILIeGLsjbSQ33IRU3fc76c= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9b271e2-ad67-4b4a-38f6-08d6981346cc X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 15:43:07.7982 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0471 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 15:43:14 -0000 SSByZWFkIHRoYXQgc2VjdGlvbiwgZ2VuZXJhbGx5LCBhcyB5b3Ugc2hvdWxkIHN1cHBvcnQgZmFs bGJhY2sgdG8gVENQLiBObyByZWFsIHNwZWNpZmljcy4NCg0KSSdtIGFza2luZyBpZiB3ZSBzaG91 bGQgYWRkIG1vcmUuIEFzIElhbiBoYWQgYWxyZWFkeSBhbGx1ZGVkIHRvIHRoZSBjbGllbnQgbWln aHQgdGFrZSB0aGUgQWx0LVN2YyBpbnRvIGFjY291bnQgd2hlbiBmYWxsaW5nIGJhY2suIEhvdyBp cyBpdCBzdXBwb3NlZCB0byBkZWNpZGUgd2hhdCB0byBkbyBpZiB0aGF0IHNheXMgUVVJQyBpcyBh dmFpbGFibGUsIGJ1dCByaWdodCBub3cgdGhleSBqdXN0IGdldCBhIFNFUlZFUl9CVVNZIGVycm9y IGZyb20gUVVJQz8NCg0KSXQgbWlnaHQgYmUgd29ydGggY2FsbGluZyBvdXQgYSBmZXcgcG9zc2li bGUgc2NlbmFyaW9zIHRoYXQgbWlnaHQgYmUgZW5jb3VudGVyZWQgYW5kIHJlY29tbWVuZCBhIGNv dXJzZSBvZiBhY3Rpb24uIEkgY2FuIHRoaW5rIG9mIHNldmVyYWwgc2NlbmFyaW9zIHRoYXQgYSBj bGllbnQgbWlnaHQgZW5jb3VudGVyIHRoYXQgbWlnaHQgYmUgaW50ZXJlc3RlZCB0byBkZXNjcmli ZToNCg0KMS4gQ2xpZW50IGdldHMgbm8gcmVzcG9uc2UgZXZlci4NCjIuIENsaWVudCBvbmx5IGdl dHMgYSByZXNwb25zZSBhZnRlciBhIGxvbmcgdGltZS4NCjMuIENsaWVudCBnZXRzIHNvbWUga2lu ZCBvZiBwcm90b2NvbCBlcnJvciBpbiByZXNwb25zZSAoYmFkIG1pZGRsZWJveD8pLg0KNC4gQ2xp ZW50IGdldHMgYSB2YWxpZCBjb25uZWN0aW9uIGNsb3NlIGluIHJlc3BvbnNlLg0KNS4gQ2xpZW50 IGhhbmRzaGFrZSBldmVudHVhbGx5IGZhaWxzIChwZXJoYXBzIHRhbXBlcmVkIHdpdGgpLg0KDQpU aGFua3MsDQotIE5pY2sgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlD IDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaXJqYSBLw7xobGV3aW5kDQpT ZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjEsIDIwMTkgNzozMyBBTQ0KVG86IFTDtm1hIEdhdnJp Y2hlbmtvdiA8eGltYWVyYUBnbWFpbC5jb20+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4g PHByYXZiQG1pY3Jvc29mdC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBSb2Jl cnRvIFBlb24gPGZlbml4QGZiLmNvbT4NClN1YmplY3Q6IFJlOiBFeHBlY3RlZCBDbGllbnQgUmVz cG9uc2UgdG8gU0VSVkVSX0JVU1kNCg0KQXMgcG9pbnRlciBvdXQgZWFybGllciBpbiB0aGlzIHRo cmVhZCB0aGVyZSBpcyB0ZXh0IGluIGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9j JTJGZHJhZnQtaWV0Zi1xdWljLWFwcGxpY2FiaWxpdHklMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q25p YmFua3MlNDBtaWNyb3NvZnQuY29tJTdDMDA4NGQ2YzA0ZTI4NGY3NmNmZDUwOGQ2OTgxMWUwOTkl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2ODYzNTk5OTAz Mjg2MzIxJmFtcDtzZGF0YT1LTzM2QnQ2alg1WGUlMkIzNzlGT2ZMWXZpS1FOUFJoSnJ3SUxTUXI2 b1BLU0ElM0QmYW1wO3Jlc2VydmVkPTAgKHNlY3Rpb24gMikuIA0KDQpEbyB5b3UgdGhpbmsgYW55 dGhpbmcgZWxzZSBpcyBuZWVkZWQ/DQoNCg0KDQo+IEFtIDIwLjAyLjIwMTkgdW0gMjM6NTYgc2No cmllYiBUw7ZtYSBHYXZyaWNoZW5rb3YgPHhpbWFlcmFAZ21haWwuY29tPjoNCj4gDQo+ID4gVGhp cyBtZWNoYW5pc20gcHJvdmlkZXMgYSB2ZXJ5IGxvdyBDUFUgY29zdCBmYXN0IGZhbGxiYWNrIHRv IFRDUCANCj4gPiB1bmRlciBEb1MgYXR0YWNrcyB1bnRpbCBhbGwgaW5mcmFzdHJ1Y3R1cmUgY2Fu IHN1cHBvcnQgUVVJQyBuYXRpdmVseQ0KPiANCj4gVGhlcmUgYXJlIFthXSBmZXcgdXNlIGNhc2Vz IHdoZW4gc3dpdGNoaW5nIGZyb20gVENQIHRvIFFVSUMgdjEgKGluIGl0cyBjdXJyZW50IHN0YXRl KSBpcyBub3QgZmVhc2libGUgYmVjYXVzZSBvZiBodWdlIG9wZXJhdGlvbmFsIGNvc3RzLiBTbyBp dCB3b3VsZCBiZSBhIG1vcmUgbG9uZyB0ZXJtIHNvbHV0aW9uIHRoYW4gdGhhdCwgcHJvYmFibHkg dGlsbCB2MiBvciBldmVuIGZ1cnRoZXIuDQo+IA0KPiA+IGFueXRoaW5nIHdlIGRvIHRvIGFsbG93 IG5vbi1tYWxpY2lvdXMgb25lcyB0byByZXNwb25kIGFwcHJvcHJpYXRlbHkgDQo+ID4gcmVxdWly ZXMgcHJlLXNoYXJpbmcsIG9yIGZvciB0aGUgY29ubmVjdGlvbiB0byBzdWNjZWVkDQo+IA0KPiBU aGUgcXVlc3Rpb24gaGVyZSBpcyBiYXNpY2FsbHkgaG93IHRvIGVuc3VyZSB0aGUgbGF0dGVyIGdp dmVuIGEgWDAwIEdicHMgYXR0YWNrIHNjYWxlIGlmIHlvdSdyZSBuZWl0aGVyIEZhY2Vib29rIG5v ciBHb29nbGUuDQo+IA0KPiA+IEluIHNvbWUgY2lyY3Vtc3RhbmNlcywgZmFsbGluZyBiYWNrIHRv IFRDUCBtYXkgYmUgc29tZXRoaW5nIHRoYXQgdGhlIA0KPiA+IGFwcGxpY2F0aW9uIHNob3VsZG4n dCBkbw0KPiANCj4gV2VsbCwgbWF5YmUsIGJ1dCB0aGVuIElNTyB0aGUgY29uc2VxdWVuY2VzIG9m IG5vdCBiZWluZyBhYmxlIHRvIGJlbmVmaXQgZnJvbSBzd2l0Y2hpbmcgdG8gVENQIGlmIHlvdSdy ZSBkb2luZyBjZXJ0YWluIHRoaW5ncyB3aXRoIFFVSUMgc2hvdWxkIGJlIG91dGxpbmVkIGluIHRo ZSBzcGVjLiBBZ2FpbiwgdGhpcyBpcyBhbiBhcHBsaWNhdGlvbi1sZXZlbCB0aGluZyAqbm93Kiwg YnV0IGZvcm1lcmx5IHRoZSB0cmFuc3BvcnQgdXNlZCB0byB0YWtlIGZ1bGwgY2FyZSBvZiBpdCwg YW5kIHRoZSBjaGFuZ2UgaW4gdGhhdCBzb3J0IG9mIGJyZWFrcyB0aGUgaGFiaXQgb2YgdGhlIHVz ZXJzLg0KPiANCj4gLS0NCj4gVMO2bWENCg0K From nobody Thu Feb 21 08:01:03 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C180B13105F for ; Thu, 21 Feb 2019 08:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwHxLZLXfGsm for ; Thu, 21 Feb 2019 08:00:52 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 7EC4113108C for ; Thu, 21 Feb 2019 08:00:49 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id x10so9704251wmg.2 for ; Thu, 21 Feb 2019 08:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8YmgdrjqrAYJ3WnIxBs0A8QHtyc+0/47Gve2/H31dmI=; b=jXHl97oJeCOqtMGfdx5yWlfgr9dc9Fivsi1gSlM1AfySWCikqPCwUsgLidc+dAfXvi 7r+x97VPvrbF3vhPpEEe1/k7D9XoWsqLqhFHUk3F+0u5kJ/TQONx3zFdU4px4vVCDX2s ggixN5IBOO2a8pmOJ6XfsuoGXlgE7uxOgijnErT+Og61JoWH0AWbDGhl0TcxCnTyCswh 2xWKa7rZl0Fkz9LqDqqGdui90M104C/LheYwosyPX4ew/M4awpwrcFnENbTFnE6LoLcn q92CBT6ynMJ7oC9Z52ZbBCc6ygENLdL3sjZOCo8zrbbFXsKW0rypB1jdH5nx+fozdyN9 nVhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8YmgdrjqrAYJ3WnIxBs0A8QHtyc+0/47Gve2/H31dmI=; b=IufurRXZHL7SR/wCqDZ3Zzy5r9OKrsTMwiV0K5oUb6le/O2KoT5fy5Nb5jSdx2Mahu 1Tn7u19vm62vIkMJwKnZ/dFUH3pwZxxfU5xrAgbzA+Whu68xMYyWuxzBTzLcwZEve17/ eob5BFnNJLMSAcOi9HmS0FUMosaaHO73GFpnnYx5dibHnzV/xpEvtPDfFk+nw/Z8hh32 uFd5xP0mwej0kUsiqZZA8X8ylj6eS/RnwVTBwxDxOo7H1Ju/GuRClLYrItg1qsXrgjma TyAAOymqm6ETCsH+50V7ZX+6NqWXHxB90HN7NLUJUwBOhD5/AQFtrjqB703WIYhY4wbD o2XQ== X-Gm-Message-State: AHQUAuYUjQk3bGVy6zefTkI6YKSdf5NuIWUDRc0nugGzd3RyIZU0NphX MniqTBB777L3Lc8rxggdpfG82ID/kfdFcgg6N8wwzSq22xo= X-Google-Smtp-Source: AHgI3IZ+BeM53cqVdjrC6BAVHpcvm/yPTge0nHow3x38fNN7NatG0+/Y0sryszoQO2nO+AV+qERlGMUEOFtNmWS/iwE= X-Received: by 2002:a1c:f312:: with SMTP id q18mr10925644wmq.106.1550764847257; Thu, 21 Feb 2019 08:00:47 -0800 (PST) MIME-Version: 1.0 References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> In-Reply-To: From: Ian Swett Date: Thu, 21 Feb 2019 11:00:33 -0500 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Nick Banks Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= , Praveen Balasubramanian , IETF QUIC WG , Roberto Peon Content-Type: multipart/alternative; boundary="000000000000da518305826993e0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 16:01:02 -0000 --000000000000da518305826993e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When the handshake fails for any reason, Chrome stops attempting to use QUIC for 5 minutes to that hostname, and if the Alt-Svc is still present 5 minutes later(ie: it hasn't been cleared), then the next request to that hostname after 5 minutes will try QUIC again. If that QUIC handshake fails, Chrome exponentially backs off and waits 10 minutes before trying again. An old, but fairly accurate doc describes this: https://docs.google.com/document/d/1i4m7DbrWGgXafHxwl8SwIusY2ELUe8WX258xt2L= FxPM/edit I think breaking it down by reason makes sense, as you suggest. If the handshake fails due to a connection close, not trying that hostname for 5 minutes seems like a reasonable approach. If you receive no packets in response, then it might make more sense to assume that UDP 443 is blocked completely and not try QUIC at all for 5 minutes(unless you have other active/recent QUIC connections). This is an area of heuristics, so we should be careful not to over-specify what a client should do, but I'd be happy to see a bit more detail on the blackhole and connection close cases at least. I'm also curious what people think we should do in response to 3 or 5? On Thu, Feb 21, 2019 at 10:43 AM Nick Banks wrote: > I read that section, generally, as you should support fallback to TCP. No > real specifics. > > I'm asking if we should add more. As Ian had already alluded to the clien= t > might take the Alt-Svc into account when falling back. How is it supposed > to decide what to do if that says QUIC is available, but right now they > just get a SERVER_BUSY error from QUIC? > > It might be worth calling out a few possible scenarios that might be > encountered and recommend a course of action. I can think of several > scenarios that a client might encounter that might be interested to > describe: > > 1. Client gets no response ever. > 2. Client only gets a response after a long time. > Defining 'a long time' is hard. I'd avoid trying to specify behavior for this case separately. 3. Client gets some kind of protocol error in response (bad middlebox?). > 4. Client gets a valid connection close in response. > 5. Client handshake eventually fails (perhaps tampered with). > > Thanks, > - Nick > > -----Original Message----- > From: QUIC On Behalf Of Mirja K=C3=BChlewind > Sent: Thursday, February 21, 2019 7:33 AM > To: T=C3=B6ma Gavrichenkov > Cc: Praveen Balasubramanian ; IETF QUIC WG < > quic@ietf.org>; Roberto Peon > Subject: Re: Expected Client Response to SERVER_BUSY > > As pointer out earlier in this thread there is text in > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-ietf-quic-applicability%2F&data=3D02%7C01= %7Cnibanks%40microsoft.com%7C0084d6c04e284f76cfd508d69811e099%7C72f988bf86f= 141af91ab2d7cd011db47%7C1%7C1%7C636863599903286321&sdata=3DKO36Bt6jX5Xe= %2B379FOfLYviKQNPRhJrwILSQr6oPKSA%3D&reserved=3D0 > (section 2). > > Do you think anything else is needed? > > > > > Am 20.02.2019 um 23:56 schrieb T=C3=B6ma Gavrichenkov : > > > > > This mechanism provides a very low CPU cost fast fallback to TCP > > > under DoS attacks until all infrastructure can support QUIC natively > > > > There are [a] few use cases when switching from TCP to QUIC v1 (in its > current state) is not feasible because of huge operational costs. So it > would be a more long term solution than that, probably till v2 or even > further. > > > > > anything we do to allow non-malicious ones to respond appropriately > > > requires pre-sharing, or for the connection to succeed > > > > The question here is basically how to ensure the latter given a X00 Gbp= s > attack scale if you're neither Facebook nor Google. > > > > > In some circumstances, falling back to TCP may be something that the > > > application shouldn't do > > > > Well, maybe, but then IMO the consequences of not being able to benefit > from switching to TCP if you're doing certain things with QUIC should be > outlined in the spec. Again, this is an application-level thing *now*, bu= t > formerly the transport used to take full care of it, and the change in th= at > sort of breaks the habit of the users. > > > > -- > > T=C3=B6ma > > --000000000000da518305826993e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When the handshake fails= for any reason, Chrome stops attempting to use QUIC for 5 minutes to that = hostname, and if the Alt-Svc is still present 5 minutes later(ie: it hasn&#= 39;t been cleared), then the next request to that hostname after 5 minutes = will try QUIC again.=C2=A0 If that QUIC handshake fails, Chrome exponential= ly backs off and waits 10 minutes before trying again.


I think breaking it= down by reason makes sense, as you suggest.=C2=A0 If the handshake fails d= ue to a connection close, not trying that hostname for 5 minutes seems like= a reasonable approach.=C2=A0 If you receive no packets in response, then i= t might make more sense to assume that UDP 443 is blocked completely and no= t try QUIC at all for 5 minutes(unless you have other active/recent QUIC co= nnections).

This is an area of heuristics, so we s= hould be careful not to over-specify what a client should do, but I'd b= e happy to see a bit more detail on the blackhole and connection close case= s at least.=C2=A0 I'm also curious what people think we should do in re= sponse to 3 or 5?

On Thu, Feb 21, 2019 at 10:43 AM Nick Banks &= lt;nibanks=3D40microsoft.com@dmarc.ietf.org> wrote:
I read that section, generally, as you = should support fallback to TCP. No real specifics.

I'm asking if we should add more. As Ian had already alluded to the cli= ent might take the Alt-Svc into account when falling back. How is it suppos= ed to decide what to do if that says QUIC is available, but right now they = just get a SERVER_BUSY error from QUIC?

It might be worth calling out a few possible scenarios that might be encoun= tered and recommend a course of action. I can think of several scenarios th= at a client might encounter that might be interested to describe:

1. Client gets no response ever.
2. Client only gets a response after a long time.
Defi= ning 'a long time' is hard. I'd avoid trying to specify behavio= r for this case separately.

3. Client gets some kind of protocol error in response (bad middlebox?). 4. Client gets a valid connection close in response.
5. Client handshake eventually fails (perhaps tampered with).

Thanks,
- Nick

-----Original Message-----
From: QUIC <q= uic-bounces@ietf.org> On Behalf Of Mirja K=C3=BChlewind
Sent: Thursday, February 21, 2019 7:33 AM
To: T=C3=B6ma Gavrichenkov <ximaera@gmail.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>; Roberto Peon <= ;fenix@fb.com>
Subject: Re: Expected Client Response to SERVER_BUSY

As pointer out earlier in this thread there is text in https://nam06.safelinks.protection.outlook.com/?url=3Dhtt= ps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-quic-applicability%2F&am= p;amp;data=3D02%7C01%7Cnibanks%40microsoft.com%7C0084d6c04e284f76cfd508d698= 11e099%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636863599903286321&= amp;sdata=3DKO36Bt6jX5Xe%2B379FOfLYviKQNPRhJrwILSQr6oPKSA%3D&amp;reserv= ed=3D0 (section 2).

Do you think anything else is needed?



> Am 20.02.2019 um 23:56 schrieb T=C3=B6ma Gavrichenkov <ximaera@gmail.com>:
>
> > This mechanism provides a very low CPU cost fast fallback to TCP =
> > under DoS attacks until all infrastructure can support QUIC nativ= ely
>
> There are [a] few use cases when switching from TCP to QUIC v1 (in its= current state) is not feasible because of huge operational costs. So it wo= uld be a more long term solution than that, probably till v2 or even furthe= r.
>
> > anything we do to allow non-malicious ones to respond appropriate= ly
> > requires pre-sharing, or for the connection to succeed
>
> The question here is basically how to ensure the latter given a X00 Gb= ps attack scale if you're neither Facebook nor Google.
>
> > In some circumstances, falling back to TCP may be something that = the
> > application shouldn't do
>
> Well, maybe, but then IMO the consequences of not being able to benefi= t from switching to TCP if you're doing certain things with QUIC should= be outlined in the spec. Again, this is an application-level thing *now*, = but formerly the transport used to take full care of it, and the change in = that sort of breaks the habit of the users.
>
> --
> T=C3=B6ma

--000000000000da518305826993e0-- From nobody Thu Feb 21 08:46:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5452512F1AC for ; Thu, 21 Feb 2019 08:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBsfDlaalrAG for ; Thu, 21 Feb 2019 08:45:57 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94109128B01 for ; Thu, 21 Feb 2019 08:45:57 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id y6so2105431ioq.10 for ; Thu, 21 Feb 2019 08:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=XxuGhHyagCWA8nnembQM9rlgpWuutvc0036HqK0L8KM=; b=fvXOH43+a4L+zvNJt/RTOOlXhOYNKxg+T/9z63/xaHdQeMKyky8tX/VBySOfIIkgzo sfqLrspdQLcZA8xDC+RIvxYpSNsE1TPGFKSlsw4jHqm4dqnVXklPG9G2Qe+/e7jVo8cw xC77dvgSYPvFIhPsLXUrinNArdps4W1xWn7Kt363IjKYOIoasGVFVziYOPmsDMFqkz0W d12+nrHzpRQC1D0V9I3vqKx29jZ7hhdSLRPwoT9FsiMI3biLa24nyIYV4fXtFklSiUC8 TNeCidLBRqeTbkdst0xQH/lSEbmqubrCbariJxoFJsUuTNF/tvPyMgcHA0F5bDRwCO1I IztQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=XxuGhHyagCWA8nnembQM9rlgpWuutvc0036HqK0L8KM=; b=R2AWjuaUgUOIG/04BuBhkDGs2t5F84B9LEXTaHsjxgLQA5hZJ82cJvyNqMUHqyic6n XoCwzDhXyryJ2U6w0T+z4z9wfmG9s+POr8Rc4XnEtwmHPxZl/u8v2U2/T+JiGW74WAja AYQxCDLrIPPBq3DZ4s1CXra1jSPwu2WS5T+412yCi43QSM51PyQ4S5wi/iZts06vnc72 kKS3noz8BK1vScw9yPzTFSq8poNKUpZvzsaNfeUoBHAYuI24njp1FufbCQY0mcbQX1z4 qRIAVHEco8wQlFuEimTrGXG5dMgRhbYrVIVl1kB6PzU35ivZK8zmV0cSkMRc6rydBFsh FA0w== X-Gm-Message-State: AHQUAuZKzEPF4xWoK6KxciEUaxKsidKWDOJG/HqI4eugo2OBRkwQvwx/ altDTvO4xUi04PZKUm28mH4YYHUJVLBk/kUpIC0= X-Google-Smtp-Source: AHgI3Iab3O7bwouCREzlhGHtiC2Y/Yssq92CFKzKmJgUeTouBVwlKYsp2/6Zi/mX8j2katJZoeIrmkMm092fOSUEXvY= X-Received: by 2002:a6b:5b01:: with SMTP id v1mr21864202ioh.12.1550767556660; Thu, 21 Feb 2019 08:45:56 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Feb 2019 08:45:55 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1AF7E952-4542-4C40-8652-BFFBFA61784A@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 21 Feb 2019 08:45:55 -0800 Message-ID: Subject: Re: Expected Client Response to SERVER_BUSY To: Ian Swett , Nick Banks Cc: Praveen Balasubramanian , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IETF QUIC WG , Roberto Peon , =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Content-Type: multipart/alternative; boundary="00000000000058183c05826a35fd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 16:46:01 -0000 --00000000000058183c05826a35fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Exponential backoff hopefully has a backstop (unlike the Iphone lockout incident when you entered the wrong pin too many times). How about a background QUIC poll ever so often while pursuing other interests. Even if the connection cannot be used per se, it can provide useful information. That might to an extend deal with some of the interference events (3, 5). On 21 February 2019 at 17.01.17, Ian Swett ( ianswett=3D40google.com@dmarc.ietf.org) wrote: When the handshake fails for any reason, Chrome stops attempting to use QUIC for 5 minutes to that hostname, and if the Alt-Svc is still present 5 minutes later(ie: it hasn't been cleared), then the next request to that hostname after 5 minutes will try QUIC again. If that QUIC handshake fails, Chrome exponentially backs off and waits 10 minutes before trying again. An old, but fairly accurate doc describes this: https://docs.google.com/document/d/1i4m7DbrWGgXafHxwl8SwIusY2ELUe8WX258xt2L= FxPM/edit I think breaking it down by reason makes sense, as you suggest. If the handshake fails due to a connection close, not trying that hostname for 5 minutes seems like a reasonable approach. If you receive no packets in response, then it might make more sense to assume that UDP 443 is blocked completely and not try QUIC at all for 5 minutes(unless you have other active/recent QUIC connections). This is an area of heuristics, so we should be careful not to over-specify what a client should do, but I'd be happy to see a bit more detail on the blackhole and connection close cases at least. I'm also curious what people think we should do in response to 3 or 5? On Thu, Feb 21, 2019 at 10:43 AM Nick Banks wrote: > I read that section, generally, as you should support fallback to TCP. No > real specifics. > > I'm asking if we should add more. As Ian had already alluded to the clien= t > might take the Alt-Svc into account when falling back. How is it supposed > to decide what to do if that says QUIC is available, but right now they > just get a SERVER_BUSY error from QUIC? > > It might be worth calling out a few possible scenarios that might be > encountered and recommend a course of action. I can think of several > scenarios that a client might encounter that might be interested to > describe: > > 1. Client gets no response ever. > 2. Client only gets a response after a long time. > Defining 'a long time' is hard. I'd avoid trying to specify behavior for this case separately. 3. Client gets some kind of protocol error in response (bad middlebox?). > 4. Client gets a valid connection close in response. > 5. Client handshake eventually fails (perhaps tampered with). > > Thanks, > - Nick > > -----Original Message----- > From: QUIC On Behalf Of Mirja K=C3=BChlewind > Sent: Thursday, February 21, 2019 7:33 AM > To: T=C3=B6ma Gavrichenkov > Cc: Praveen Balasubramanian ; IETF QUIC WG < > quic@ietf.org>; Roberto Peon > Subject: Re: Expected Client Response to SERVER_BUSY > > As pointer out earlier in this thread there is text in > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-ietf-quic-applicability%2F&data=3D02%7C01= %7Cnibanks%40microsoft.com%7C0084d6c04e284f76cfd508d69811e099%7C72f988bf86f= 141af91ab2d7cd011db47%7C1%7C1%7C636863599903286321&sdata=3DKO36Bt6jX5Xe= %2B379FOfLYviKQNPRhJrwILSQr6oPKSA%3D&reserved=3D0 > > (section 2). > > Do you think anything else is needed? > > > > > Am 20.02.2019 um 23:56 schrieb T=C3=B6ma Gavrichenkov : > > > > > This mechanism provides a very low CPU cost fast fallback to TCP > > > under DoS attacks until all infrastructure can support QUIC natively > > > > There are [a] few use cases when switching from TCP to QUIC v1 (in its > current state) is not feasible because of huge operational costs. So it > would be a more long term solution than that, probably till v2 or even > further. > > > > > anything we do to allow non-malicious ones to respond appropriately > > > requires pre-sharing, or for the connection to succeed > > > > The question here is basically how to ensure the latter given a X00 Gbp= s > attack scale if you're neither Facebook nor Google. > > > > > In some circumstances, falling back to TCP may be something that the > > > application shouldn't do > > > > Well, maybe, but then IMO the consequences of not being able to benefit > from switching to TCP if you're doing certain things with QUIC should be > outlined in the spec. Again, this is an application-level thing *now*, bu= t > formerly the transport used to take full care of it, and the change in th= at > sort of breaks the habit of the users. > > > > -- > > T=C3=B6ma > > --00000000000058183c05826a35fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Exponential backoff = hopefully has a backstop (unlike the Iphone lockout incident when you enter= ed the wrong pin too many times).
How about a background QUIC poll ever so often while= pursuing other interests. Even if the connection cannot be used per se, it= can provide useful information. That might to an extend deal with some of = the interference events (3, 5).

On 21 Feb= ruary 2019 at 17.01.17, Ian Swett (ianswett=3D40google.com@dmarc.ietf.org) wrote:

When the handshake fails for any reason, Chrome stops attempting to use QUIC for 5 minutes to that hostname, and if the Alt-Svc is still present 5 minutes later(ie: it hasn't been cleared), then the next request to that hostname after 5 minutes will try QUIC again.=C2=A0 If that QUIC handshake fails, Chrome exponentially backs off and waits 10 minutes before trying again.


I think breaking it down by reason makes sense, as you suggest.=C2=A0 If the handshake fails due to a connection close, not trying that hostname for 5 minutes seems like a reasonable approach.=C2=A0 If you receive no packets in response, then it might make more sense to assume that UDP 443 is blocked completely and not try QUIC at all for 5 minutes(unless you have other active/recent QUIC connections).

This is an area of heuristics, so we should be careful not to over-specify what a client should do, but I'd be happy to see a bit more detail on the blackhole and connection close cases at least.=C2=A0 I'm also curious what people think we should do in response to 3 or 5?

On Thu, Feb 21, 2019 at 10:43 AM Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org> wrote:
I read that section, generally, as you should support fallback to TCP. No real specifics.

I'm asking if we should add more. As Ian had already alluded to the client might take the Alt-Svc into account when falling back. How is it supposed to decide what to do if that says QUIC is available, but right now they just get a SERVER_BUSY error from QUIC?

It might be worth calling out a few possible scenarios that might be encountered and recommend a course of action. I can think of several scenarios that a client might encounter that might be interested to describe:

1. Client gets no response ever.
2. Client only gets a response after a long time.
Defining 'a long time' is hard. I'd avoid trying to specif= y behavior for this case separately.

3. Client gets some kind of protocol error in response (bad middlebox?).
4. Client gets a valid connection close in response.
5. Client handshake eventually fails (perhaps tampered with).

Thanks,
- Nick

-----Original Message-----
From: QUIC <q= uic-bounces@ietf.org> On Behalf Of Mirja K=C3=BChlewind
Sent: Thursday, February 21, 2019 7:33 AM
To: T=C3=B6ma Gavrichenkov <ximaera@gmail.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>; Roberto Peon <fenix@fb= .com>
Subject: Re: Expected Client Response to SERVER_BUSY

As pointer out earlier in this thread there is text in https://nam06.safelinks.protection.outlook.com/?url=3Dht= tps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-quic-applicability%2F&a= mp;amp;data=3D02%7C01%7Cnibanks%40microsoft.com%7C0084d6c04e284f76cfd508d69= 811e099%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636863599903286321&= ;amp;sdata=3DKO36Bt6jX5Xe%2B379FOfLYviKQNPRhJrwILSQr6oPKSA%3D&amp;reser= ved=3D0 (section 2).

Do you think anything else is needed?



> Am 20.02.2019 um 23:56 schrieb T=C3=B6ma Gavrichenkov <ximaera@gmail.com>:
>
> > This mechanism provides a very low CPU cost fast fallback to TCP
> > under DoS attacks until all infrastructure can support QUIC natively
>
> There are [a] few use cases when switching from TCP to QUIC v1 (in its current state) is not feasible because of huge operational costs. So it would be a more long term solution than that, probably till v2 or even further.
>
> > anything we do to allow non-malicious ones to respond appropriately
> > requires pre-sharing, or for the connection to succeed
>
> The question here is basically how to ensure the latter given a X00 Gbps attack scale if you're neither Facebook nor Google.
>
> > In some circumstances, falling back to TCP may be something that the
> > application shouldn't do
>
> Well, maybe, but then IMO the consequences of not being able to benefit from switching to TCP if you're doing certain things with QUIC should be outlined in the spec. Again, this is an application-level thing *now*, but formerly the transport used to take full care of it, and the change in that sort of breaks the habit of the users.
>
> --
> T=C3=B6ma

 --00000000000058183c05826a35fd-- From nobody Thu Feb 21 20:24:15 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10921130E11 for ; Thu, 21 Feb 2019 20:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFXbh8R9Kvpc for ; Thu, 21 Feb 2019 20:24:11 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 001D41275F3 for ; Thu, 21 Feb 2019 20:24:10 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id h10so702249lfc.12 for ; Thu, 21 Feb 2019 20:24:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1zjaf0Cpk38hfPjK3JxQey2ejXwpPcpqtVfX5tILbkc=; b=HRtinBRRax++KqjChdu232JHg9JsvB5+kyawr/7ImA+pcb0T3fUJkboKzcd60ZwVXB Z0Nvf23rxjDNhNzKRamHi2suDM73/y78NxpfNi5qd1c43PWupsr0hJwaANC/FUwD5ysc JqT0Og8PXhjbJVz5+i5t7tki824lAJBb7nuHMyS3UkKAnYQ/+8dC2jhzY+9d7LhZrCf4 bYt1ma/nrwZ6hMrfggitHS38o+gyeP9zh06coPlCNoauN0W0Fu2sNUv76HT3QAG4lXOs LzuQrLeote9r4YjBtgyD0E0AZvINMaesQGjQwf0TW2uaxuPnbFciUJD6HW5KZu3gQxMg 9CnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1zjaf0Cpk38hfPjK3JxQey2ejXwpPcpqtVfX5tILbkc=; b=nTOyLCFgL2xiJ+HUtYvUXUcXakaGiwFZ4hPobNfo+b78zjosp+M+4LofJuBNPRyCz1 KKtCSPUzo1wLab0m+XKIYD8yfPM+LSXi+Qg8cmH7mLjZkqfYIptJ2UafTK1tSKrhiYOY XEwRsL/dod366kVEl+zsbezrOJuk3RM36BloPA7YIU/9IOGBmfNNHFqQIaobtamMUoPV yjfORw6atbMlTktl5aUK5fhF5qvXV45ET+pUqhSJHRZuZEM0FZ1tg9dO1azbu2THTjq4 aMzxLk/Hu7P1wAzTw6ypfMVVfMWDuNQ6jiuBG+JaWt+2qkYnS7R/q2+TLvvcbs+1QJO3 64OA== X-Gm-Message-State: AHQUAuatoeKGkFWlLlq/l2f5flLZfR9HZHt9ihdkEvMibFPPrkw6v6nW 3nJd7vuq4+3d1walzJixiaVQF1+Bw6WViX2fQeI= X-Google-Smtp-Source: AHgI3IZ5CHD9GZRU+9q3l7APvpCrr2kkDTJCYm+rAD9WK49E1km9ugBwpUdq4Wp9Ndk47UEjR+bqOhbS4zORjNOOPwI= X-Received: by 2002:a19:5601:: with SMTP id k1mr950249lfb.99.1550809448940; Thu, 21 Feb 2019 20:24:08 -0800 (PST) MIME-Version: 1.0 References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> In-Reply-To: From: Jana Iyengar Date: Thu, 21 Feb 2019 20:23:57 -0800 Message-ID: Subject: Re: QUIC ossification To: "Brian Trammell (IETF)" Cc: Roberto Peon , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000518b4d058273f6be" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 04:24:14 -0000 --000000000000518b4d058273f6be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian, I agree that there are potentially other models as well, but the one we know from experience is the naive one. We should at least protect against the one model we know, naive or not. I'll note that it quickly gets difficult to come up with measures if we assume a smarter ossifier. - jana On Tue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) wrote: > (oops, hit send too soon...) > > > On 20 Feb 2019, at 07:58, Brian Trammell (IETF) > wrote: > > > > hi Jana, > > > > The middlebox adaptation model that this proposal addresses seems > limited to middleboxes built based on naive traffic analysis and pre-QUIC > assumptions about wire images. This is admittedly the model behind one of > Google's experiences with QUIC middlebox breakage, and the one we seem mo= st > concerned with because by definition we cannot fix it by writing things i= n > documents. > > I don't think these are the only things we're concerned about though. > Concerns about partitioning VN space have a less naive model in mind: her= e > we think more about default-deny firewalls that have been told that some > versions of QUIC are okay but all others are not. As noted before I > personally cannot think of a reason an operator would want to do this -- = if > you've already decided to allow a protocol with low observability and > built-in extensibility as a design goal on your network, does the exact > flavor really matter all that much? -- but it's a checkbox on the firewal= l > feature list so yeah, I suppose someone will ship it. > > Are there other middlebox adaptation models we are concerned about here? > > Cheers, > > Brian > > > >> On 20 Feb 2019, at 00:17, Jana Iyengar wrote: > >> > >> Roberto -- yes, that's basically what I'm proposing too, just one > variant of how to go about doing it dynamically over time. > >> > >> On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon wrote: > >> As others have intimated in some form or another, you can also use > multiple numbers to express =E2=80=9Cversion 1=E2=80=9D. > >> > >> > >> For instance, pick 64 (or some similar constant) random numbers, and > call them all version 1. > >> -=3DR > >> > >> > >> > >> From: QUIC on behalf of Jana Iyengar < > jri.ietf@gmail.com> > >> Date: Tuesday, February 19, 2019 at 3:10 PM > >> To: Martin Thomson > >> Cc: QUIC WG > >> Subject: Re: QUIC ossification > >> > >> > >> > >> On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson > wrote: > >> > >> I don't think that there is much value in using two version numbers to > refer to the same protocol. But even if we did, as long as we didn't > establish any pattern in doing so, that couldn't be used against us. So = I > might tentatively agree that 0x1 =3D=3D 0x2 would be inadvisable, there i= s no > strong need to do anything special with the first version. Any attempt t= o > profile QUIC will be done with full knowledge of the version number we > pick, so randomness doesn't serve any real purpose. Subsequent versions > might need to use a randomized value, but we can make that decision then. > >> > >> > >> > >> I figured that making all version assignments random instead of > special-casing 0x1 made it simpler to reason about and uniform to code fo= r, > but I actually don't care about the IANA assignment for v1 for the reason > you note. v1 will be one specific bit-pattern on the wire to start of wit= h, > and that can just as well be 0x1. It still does segregate the space, but = we > can't do anything about it anyways - it'll be 0x1 or some other random > number getting special treatment. > >> > >> > >> > >> The problem of course being that as long as v1 remains, we might find > places that no other version does. The QUIC "magic number" will be > whatever we pick, and we can't prevent someone from fixating on that.. > We'll convince those people in the same way they will be convinced to ope= n > up UDP for QUIC version 1: by making a QUIC version 2 worth enabling. > >> > >> > >> > >> That was the entire point of having alternate and preferred versions t= o > 0x1. If we have downgrade protection in place, and if there are those who > try alternate version numbers for v1, that gives us what we need at the > endpoints. I believe that there would be interest at some major vendors t= o > do this at some endpoints. Presumably, we can convince Google to do > something, since it has been bit by mbox ossification in the past. I am > operating on the premise that we have buy in from a few major providers. > >> > >> > >> > >> IANA is for me a publication venue where these alternate versions are > published and other clients/servers interested in keeping the ecosystem > from ossifying can use these alternate versions as well. > >> > >> > >> > >> I completely get the don't segregate thing. But to - I think - > Mikkel's point about experimentation without permission, I do think that > squatting is a perfectly sound approach in a space this big. TLS people = do > it in a much smaller space. As long squatters pick random values, they d= o > so infrequently, and they get IANA registrations for codepoints relativel= y > soon afterwards, the risk of collision is low. Randomness here is useful= - > but primarily as a collision-avoidance technique. The TLS extension > codepoint 26 is a great example of why. Keeping the bar on registrations > low (FCFS is a reasonable policy) would also have the effect of making th= e > pool of apparent versions larger, which might be more effective than any > other strategy we might employ. > >> > >> > >> > >> I'm totally fine with experimentation without permission, and using > random to avoid collision. My point was entirely about using alternate > on-wire version numbers for v1. Nothing here about new or experimental > versions. > >> > >> > >> > > > > --000000000000518b4d058273f6be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian,

I agree that there are potential= ly other models as well, but the one we know from experience is the naive o= ne.=C2=A0 We should at least protect against the one model we know, naive o= r not. I'll note that it quickly gets difficult to come up with measure= s if we assume a smarter ossifier.

- jana

On = Tue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) <ietf@trammell.ch> wrote:
(oops, hit send too soon...)

> On 20 Feb 2019, at 07:58, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>
> hi Jana,
>
> The middlebox adaptation model that this proposal addresses seems limi= ted to middleboxes built based on naive traffic analysis and pre-QUIC assum= ptions about wire images. This is admittedly the model behind one of Google= 's experiences with QUIC middlebox breakage, and the one we seem most c= oncerned with because by definition we cannot fix it by writing things in d= ocuments.

I don't think these are the only things we're concerned about thoug= h. Concerns about partitioning VN space have a less naive model in mind: he= re we think more about default-deny firewalls that have been told that some= versions of QUIC are okay but all others are not. As noted before I person= ally cannot think of a reason an operator would want to do this -- if you&#= 39;ve already decided to allow a protocol with low observability and built-= in extensibility as a design goal on your network, does the exact flavor re= ally matter all that much? -- but it's a checkbox on the firewall featu= re list so yeah, I suppose someone will ship it.

Are there other middlebox adaptation models we are concerned about here?
Cheers,

Brian


>> On 20 Feb 2019, at 00:17, Jana Iyengar <jri.ietf@gmail.com> wrote:
>>
>> Roberto -- yes, that's basically what I'm proposing too, j= ust one variant of how to go about doing it dynamically over time.
>>
>> On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon <fenix@fb.com> wrote:
>> As others have intimated in some form or another, you can also use= multiple numbers to express =E2=80=9Cversion 1=E2=80=9D.
>>
>>
>> For instance, pick 64 (or some similar constant) random numbers, a= nd call them all version 1.
>> -=3DR
>>
>>
>>
>> From: QUIC <quic-bounces@ietf.org> on behalf of Jana Iyengar <jri.ietf@gmail.com>=
>> Date: Tuesday, February 19, 2019 at 3:10 PM
>> To: Martin Thomson <mt@lowentropy.net>
>> Cc: QUIC WG <quic@ietf.org>
>> Subject: Re: QUIC ossification
>>
>>
>>
>> On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <mt@lowentropy.net> wrote: >>
>> I don't think that there is much value in using two version nu= mbers to refer to the same protocol.=C2=A0 But even if we did, as long as w= e didn't establish any pattern in doing so, that couldn't be used a= gainst us.=C2=A0 So I might tentatively agree that 0x1 =3D=3D 0x2 would be = inadvisable, there is no strong need to do anything special with the first = version.=C2=A0 Any attempt to profile QUIC will be done with full knowledge= of the version number we pick, so randomness doesn't serve any real pu= rpose.=C2=A0 Subsequent versions might need to use a randomized value, but = we can make that decision then.
>>
>>
>>
>> I figured that making all version assignments random instead of sp= ecial-casing 0x1 made it simpler to reason about and uniform to code for, b= ut I actually don't care about the IANA assignment for v1 for the reaso= n you note. v1 will be one specific bit-pattern on the wire to start of wit= h, and that can just as well be 0x1. It still does segregate the space, but= we can't do anything about it anyways - it'll be 0x1 or some other= random number getting special treatment.
>>
>>
>>
>> The problem of course being that as long as v1 remains, we might f= ind places that no other version does.=C2=A0 The QUIC "magic number&qu= ot; will be whatever we pick, and we can't prevent someone from fixatin= g on that..=C2=A0 We'll convince those people in the same way they will= be convinced to open up UDP for QUIC version 1: by making a QUIC version 2= worth enabling.
>>
>>
>>
>> That was the entire point of having alternate and preferred versio= ns to 0x1. If we have downgrade protection in place, and if there are those= who try alternate version numbers for v1, that gives us what we need at th= e endpoints. I believe that there would be interest at some major vendors t= o do this at some endpoints. Presumably, we can convince Google to do somet= hing, since it has been bit by mbox ossification in the past. I am operatin= g on the premise that we have buy in from a few major providers.
>>
>>
>>
>> IANA is for me a publication venue where these alternate versions = are published and other clients/servers interested in keeping the ecosystem= from ossifying can use these alternate versions as well.
>>
>>
>>
>> I completely get the don't segregate thing.=C2=A0 But to - I t= hink - Mikkel's point about experimentation without permission, I do th= ink that squatting is a perfectly sound approach in a space this big.=C2=A0= TLS people do it in a much smaller space.=C2=A0 As long squatters pick ran= dom values, they do so infrequently, and they get IANA registrations for co= depoints relatively soon afterwards, the risk of collision is low.=C2=A0 Ra= ndomness here is useful - but primarily as a collision-avoidance technique.= =C2=A0 The TLS extension codepoint 26 is a great example of why.=C2=A0 Keep= ing the bar on registrations low (FCFS is a reasonable policy) would also h= ave the effect of making the pool of apparent versions larger, which might = be more effective than any other strategy we might employ.
>>
>>
>>
>> I'm totally fine with experimentation without permission, and = using random to avoid collision. My point was entirely about using alternat= e on-wire version numbers for v1. Nothing here about new or experimental ve= rsions.
>>
>>
>>
>

--000000000000518b4d058273f6be-- From nobody Thu Feb 21 22:02:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9063112F1A5 for ; Thu, 21 Feb 2019 22:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co 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 UVCMVXDB1I72 for ; Thu, 21 Feb 2019 22:02:14 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 5F4F31275F3 for ; Thu, 21 Feb 2019 22:02:14 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id l15so1609323iti.4 for ; Thu, 21 Feb 2019 22:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=3lk1djdI/fdq9rGMl1UG5kk8+ojqUGLWm9j6zZvLmCQ=; b=hJudzOxzZg8ofa/NocLFV0JKYsCilo5h+QSfv4f0Xk1hXpJXhkK6Ldxr1213ySb5KT Rd/pT3T/7iQvNDZ204a2G0g2R0L6n2QkwefPcGH9sPMq36iie4vjdGGMXdH4MYWb+CoC NjwxUZIyzybWVo2vVl9TPX+Pf+rBByr4KA9xo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=3lk1djdI/fdq9rGMl1UG5kk8+ojqUGLWm9j6zZvLmCQ=; b=drfgKSkSXYbx+MMdRf2KUUJndw/reeQzDbCsRVKKPttFT19sI1JoPNEWkPTMBZBaYe JbAmHHkEZ4mwVlGrUUIyEjcCMN7qahT3qnAd64GT8BOpnYfNw6STzGfTIEHZPrOkaVL8 OYgXOc+bZ+Hu0/51YDZqyDj4A7fbIgc49th+nGv6yox6t5HgjZisBd8bfEssVExWVACT KbB7NMeRlMcOoOk/2rJ/Th8JLL0BMxMIdAUR0JzjFZMl7pYig3cfqDjGh1S9Jba6DDXD XGeALK0vBotFH/AWs7uZtjDSWWHtnqFebtI6XIy8tfgGrziy4pXlVY2o92WG10xJpJgh gT4Q== X-Gm-Message-State: AHQUAuZrFevg9Y9CHepyElyAIs65E+QeLxRfEIhKApZDF7foBKEm7RRo cNaKEMWeVXd1J8YrV7BEG08/4wesQvuWIDIUntUHvA== X-Google-Smtp-Source: AHgI3IZ5ULM+2rxL6Zs+Ua6003uZcMeFfVwxc1qQxX3cr+Q9FwCh7GExQUUQ5ACOokHRnGvs1/VKdwRyYKIu2ID/v7c= X-Received: by 2002:a24:80cb:: with SMTP id g194mr1143316itd.121.1550815333236; Thu, 21 Feb 2019 22:02:13 -0800 (PST) MIME-Version: 1.0 References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> In-Reply-To: Reply-To: ek@loon.co From: Erik Kline Date: Thu, 21 Feb 2019 22:02:00 -0800 Message-ID: Subject: Re: QUIC ossification To: Jana Iyengar Cc: "Brian Trammell (IETF)" , QUIC WG , Roberto Peon , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000000d3a080582755519" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 06:02:18 -0000 --0000000000000d3a080582755519 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 21 Feb 2019 at 20:24, Jana Iyengar wrote: > Brian, > > I agree that there are potentially other models as well, but the one we > know from experience is the naive one. We should at least protect agains= t > the one model we know, naive or not. I'll note that it quickly gets > difficult to come up with measures if we assume a smarter ossifier. > You would pretty much have to move version negotiation bits (and subsequent protocol differences) to underneath the crypto umbrella, wouldn't you? Negotiating a newer version would have to be like negotiating some extensions, or something, I would think... - jana > > On Tue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) > wrote: > >> (oops, hit send too soon...) >> >> > On 20 Feb 2019, at 07:58, Brian Trammell (IETF) >> wrote: >> > >> > hi Jana, >> > >> > The middlebox adaptation model that this proposal addresses seems >> limited to middleboxes built based on naive traffic analysis and pre-QUI= C >> assumptions about wire images. This is admittedly the model behind one o= f >> Google's experiences with QUIC middlebox breakage, and the one we seem m= ost >> concerned with because by definition we cannot fix it by writing things = in >> documents. >> >> I don't think these are the only things we're concerned about though. >> Concerns about partitioning VN space have a less naive model in mind: he= re >> we think more about default-deny firewalls that have been told that some >> versions of QUIC are okay but all others are not. As noted before I >> personally cannot think of a reason an operator would want to do this --= if >> you've already decided to allow a protocol with low observability and >> built-in extensibility as a design goal on your network, does the exact >> flavor really matter all that much? -- but it's a checkbox on the firewa= ll >> feature list so yeah, I suppose someone will ship it. >> >> Are there other middlebox adaptation models we are concerned about here? >> >> Cheers, >> >> Brian >> >> >> >> On 20 Feb 2019, at 00:17, Jana Iyengar wrote: >> >> >> >> Roberto -- yes, that's basically what I'm proposing too, just one >> variant of how to go about doing it dynamically over time. >> >> >> >> On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon wrote: >> >> As others have intimated in some form or another, you can also use >> multiple numbers to express =E2=80=9Cversion 1=E2=80=9D. >> >> >> >> >> >> For instance, pick 64 (or some similar constant) random numbers, and >> call them all version 1. >> >> -=3DR >> >> >> >> >> >> >> >> From: QUIC on behalf of Jana Iyengar < >> jri.ietf@gmail.com> >> >> Date: Tuesday, February 19, 2019 at 3:10 PM >> >> To: Martin Thomson >> >> Cc: QUIC WG >> >> Subject: Re: QUIC ossification >> >> >> >> >> >> >> >> On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson >> wrote: >> >> >> >> I don't think that there is much value in using two version numbers t= o >> refer to the same protocol. But even if we did, as long as we didn't >> establish any pattern in doing so, that couldn't be used against us. So= I >> might tentatively agree that 0x1 =3D=3D 0x2 would be inadvisable, there = is no >> strong need to do anything special with the first version. Any attempt = to >> profile QUIC will be done with full knowledge of the version number we >> pick, so randomness doesn't serve any real purpose. Subsequent versions >> might need to use a randomized value, but we can make that decision then= . >> >> >> >> >> >> >> >> I figured that making all version assignments random instead of >> special-casing 0x1 made it simpler to reason about and uniform to code f= or, >> but I actually don't care about the IANA assignment for v1 for the reaso= n >> you note. v1 will be one specific bit-pattern on the wire to start of wi= th, >> and that can just as well be 0x1. It still does segregate the space, but= we >> can't do anything about it anyways - it'll be 0x1 or some other random >> number getting special treatment. >> >> >> >> >> >> >> >> The problem of course being that as long as v1 remains, we might find >> places that no other version does. The QUIC "magic number" will be >> whatever we pick, and we can't prevent someone from fixating on that.. >> We'll convince those people in the same way they will be convinced to op= en >> up UDP for QUIC version 1: by making a QUIC version 2 worth enabling. >> >> >> >> >> >> >> >> That was the entire point of having alternate and preferred versions >> to 0x1. If we have downgrade protection in place, and if there are those >> who try alternate version numbers for v1, that gives us what we need at = the >> endpoints. I believe that there would be interest at some major vendors = to >> do this at some endpoints. Presumably, we can convince Google to do >> something, since it has been bit by mbox ossification in the past. I am >> operating on the premise that we have buy in from a few major providers. >> >> >> >> >> >> >> >> IANA is for me a publication venue where these alternate versions are >> published and other clients/servers interested in keeping the ecosystem >> from ossifying can use these alternate versions as well. >> >> >> >> >> >> >> >> I completely get the don't segregate thing. But to - I think - >> Mikkel's point about experimentation without permission, I do think that >> squatting is a perfectly sound approach in a space this big. TLS people= do >> it in a much smaller space. As long squatters pick random values, they = do >> so infrequently, and they get IANA registrations for codepoints relative= ly >> soon afterwards, the risk of collision is low. Randomness here is usefu= l - >> but primarily as a collision-avoidance technique. The TLS extension >> codepoint 26 is a great example of why. Keeping the bar on registration= s >> low (FCFS is a reasonable policy) would also have the effect of making t= he >> pool of apparent versions larger, which might be more effective than any >> other strategy we might employ. >> >> >> >> >> >> >> >> I'm totally fine with experimentation without permission, and using >> random to avoid collision. My point was entirely about using alternate >> on-wire version numbers for v1. Nothing here about new or experimental >> versions. >> >> >> >> >> >> >> > >> >> --0000000000000d3a080582755519 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 21 Feb 2019 at 20:24, Jana Iy= engar <jri.ietf@gmail.com> = wrote:
Brian,

I agree that there are potentially other= models as well, but the one we know from experience is the naive one.=C2= =A0 We should at least protect against the one model we know, naive or not.= I'll note that it quickly gets difficult to come up with measures if w= e assume a smarter ossifier.

Yo= u would pretty much have to move version negotiation bits (and subsequent p= rotocol differences) to underneath the crypto umbrella, wouldn't you?= =C2=A0 Negotiating a newer version would have to be like negotiating some e= xtensions, or something, I would think...

- jana

On T= ue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) <ietf@trammell.ch> wrote:
=
(oops, hit send too soon.= ..)

> On 20 Feb 2019, at 07:58, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>
> hi Jana,
>
> The middlebox adaptation model that this proposal addresses seems limi= ted to middleboxes built based on naive traffic analysis and pre-QUIC assum= ptions about wire images. This is admittedly the model behind one of Google= 's experiences with QUIC middlebox breakage, and the one we seem most c= oncerned with because by definition we cannot fix it by writing things in d= ocuments.

I don't think these are the only things we're concerned about thoug= h. Concerns about partitioning VN space have a less naive model in mind: he= re we think more about default-deny firewalls that have been told that some= versions of QUIC are okay but all others are not. As noted before I person= ally cannot think of a reason an operator would want to do this -- if you&#= 39;ve already decided to allow a protocol with low observability and built-= in extensibility as a design goal on your network, does the exact flavor re= ally matter all that much? -- but it's a checkbox on the firewall featu= re list so yeah, I suppose someone will ship it.

Are there other middlebox adaptation models we are concerned about here?
Cheers,

Brian


>> On 20 Feb 2019, at 00:17, Jana Iyengar <jri.ietf@gmail.com> wrote:
>>
>> Roberto -- yes, that's basically what I'm proposing too, j= ust one variant of how to go about doing it dynamically over time.
>>
>> On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon <fenix@fb.com> wrote:
>> As others have intimated in some form or another, you can also use= multiple numbers to express =E2=80=9Cversion 1=E2=80=9D.
>>
>>
>> For instance, pick 64 (or some similar constant) random numbers, a= nd call them all version 1.
>> -=3DR
>>
>>
>>
>> From: QUIC <quic-bounces@ietf.org> on behalf of Jana Iyengar <jri.ietf@gmail.com>=
>> Date: Tuesday, February 19, 2019 at 3:10 PM
>> To: Martin Thomson <mt@lowentropy.net>
>> Cc: QUIC WG <quic@ietf.org>
>> Subject: Re: QUIC ossification
>>
>>
>>
>> On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <mt@lowentropy.net> wrote: >>
>> I don't think that there is much value in using two version nu= mbers to refer to the same protocol.=C2=A0 But even if we did, as long as w= e didn't establish any pattern in doing so, that couldn't be used a= gainst us.=C2=A0 So I might tentatively agree that 0x1 =3D=3D 0x2 would be = inadvisable, there is no strong need to do anything special with the first = version.=C2=A0 Any attempt to profile QUIC will be done with full knowledge= of the version number we pick, so randomness doesn't serve any real pu= rpose.=C2=A0 Subsequent versions might need to use a randomized value, but = we can make that decision then.
>>
>>
>>
>> I figured that making all version assignments random instead of sp= ecial-casing 0x1 made it simpler to reason about and uniform to code for, b= ut I actually don't care about the IANA assignment for v1 for the reaso= n you note. v1 will be one specific bit-pattern on the wire to start of wit= h, and that can just as well be 0x1. It still does segregate the space, but= we can't do anything about it anyways - it'll be 0x1 or some other= random number getting special treatment.
>>
>>
>>
>> The problem of course being that as long as v1 remains, we might f= ind places that no other version does.=C2=A0 The QUIC "magic number&qu= ot; will be whatever we pick, and we can't prevent someone from fixatin= g on that..=C2=A0 We'll convince those people in the same way they will= be convinced to open up UDP for QUIC version 1: by making a QUIC version 2= worth enabling.
>>
>>
>>
>> That was the entire point of having alternate and preferred versio= ns to 0x1. If we have downgrade protection in place, and if there are those= who try alternate version numbers for v1, that gives us what we need at th= e endpoints. I believe that there would be interest at some major vendors t= o do this at some endpoints. Presumably, we can convince Google to do somet= hing, since it has been bit by mbox ossification in the past. I am operatin= g on the premise that we have buy in from a few major providers.
>>
>>
>>
>> IANA is for me a publication venue where these alternate versions = are published and other clients/servers interested in keeping the ecosystem= from ossifying can use these alternate versions as well.
>>
>>
>>
>> I completely get the don't segregate thing.=C2=A0 But to - I t= hink - Mikkel's point about experimentation without permission, I do th= ink that squatting is a perfectly sound approach in a space this big.=C2=A0= TLS people do it in a much smaller space.=C2=A0 As long squatters pick ran= dom values, they do so infrequently, and they get IANA registrations for co= depoints relatively soon afterwards, the risk of collision is low.=C2=A0 Ra= ndomness here is useful - but primarily as a collision-avoidance technique.= =C2=A0 The TLS extension codepoint 26 is a great example of why.=C2=A0 Keep= ing the bar on registrations low (FCFS is a reasonable policy) would also h= ave the effect of making the pool of apparent versions larger, which might = be more effective than any other strategy we might employ.
>>
>>
>>
>> I'm totally fine with experimentation without permission, and = using random to avoid collision. My point was entirely about using alternat= e on-wire version numbers for v1. Nothing here about new or experimental ve= rsions.
>>
>>
>>
>

--0000000000000d3a080582755519-- From nobody Fri Feb 22 13:35:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52481275F3 for ; Fri, 22 Feb 2019 13:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=RfQt2Qg7; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Kt9RyJ8q 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 V0Bw-G4P6a-0 for ; Fri, 22 Feb 2019 13:35:39 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 1D1C0130E79 for ; Fri, 22 Feb 2019 13:35:38 -0800 (PST) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1MLWjTC013332; Fri, 22 Feb 2019 13:35:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=75b6MEBTAFnOMIdSwgPGmfp6snrCK4SlNSFIXHBSo7A=; b=RfQt2Qg7SFmRQqde1WxzHjwOL3bkRMTsYw+NDPL39qBi+kllQaJPsLQbir26gvZeuf0+ juHZemQ3osXc9JW3HtWq1TIVJqOfg6qNilIrEpR2ZkaVZNfj+DfX2pOaAAjdlBYBKbf8 n5BApnaI/jjAu93LOKPl5PK8SRVciJdzQaw= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 2qtpvjgeyk-13 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 22 Feb 2019 13:35:36 -0800 Received: from prn-mbx03.TheFacebook.com (2620:10d:c081:6::17) by prn-hub02.TheFacebook.com (2620:10d:c081:35::126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Fri, 22 Feb 2019 13:35:29 -0800 Received: from prn-hub04.TheFacebook.com (2620:10d:c081:35::128) by prn-mbx03.TheFacebook.com (2620:10d:c081:6::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Fri, 22 Feb 2019 13:35:28 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Fri, 22 Feb 2019 13:35:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=75b6MEBTAFnOMIdSwgPGmfp6snrCK4SlNSFIXHBSo7A=; b=Kt9RyJ8qQK1XBkOsVfpozlFX9a68OKn4Prft8TvJwQ3X4JQzYLXnJd+VHi39taekxUYUOonWnu4owGEbScN1PRUGac/w1/7Ln0N3Div7JwEfehY3o9gqFfwXWfJnfC+IXyYH04bfOZGW6rR1On60OprHE4W0j7HL6nkBmz1/nXI= Received: from BN7PR15MB2308.namprd15.prod.outlook.com (52.132.217.149) by BN7PR15MB2196.namprd15.prod.outlook.com (52.132.216.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Fri, 22 Feb 2019 21:35:26 +0000 Received: from BN7PR15MB2308.namprd15.prod.outlook.com ([fe80::2496:df75:390f:90a4]) by BN7PR15MB2308.namprd15.prod.outlook.com ([fe80::2496:df75:390f:90a4%5]) with mapi id 15.20.1643.014; Fri, 22 Feb 2019 21:35:26 +0000 From: Roberto Peon To: "ek@loon.co" , Jana Iyengar CC: "Brian Trammell (IETF)" , QUIC WG , Martin Thomson Subject: Re: QUIC ossification Thread-Topic: QUIC ossification Thread-Index: AQHUwxih7UYarYoV30WBSlEhJDleK6Xcr5EA//+EwACAAKdJAP//fAuAgAGRSoCAAArqgIAABPsAgAAA14CAAAMfgIAACY0A//+6QoAAEcIhgAAHiM6AAAFCw4AAAtg4AAAAMeuAAABRNgAAAVt/AAAAuC4AAAHDNQAAHrd+gAAAHQ4AAABwzoAACKm9AAAAEgiAAAAr9QAAACHTgAAATyAAAALUMwAAywJVgAAZs5wAAA9NEYD//3slgIAAhuyAgACA9oCAAAFdAIAC+AOAgAAbZQCAAH6vgA== Date: Fri, 22 Feb 2019 21:35:25 +0000 Message-ID: References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [2620:10d:c090:200::5:24d6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f6d5a282-905c-45c2-1896-08d6990da901 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN7PR15MB2196; x-ms-traffictypediagnostic: BN7PR15MB2196: x-microsoft-exchange-diagnostics: 1; BN7PR15MB2196; 20:g7kZz661T5igFQQEF7J2jXcXc7Pg3CE4FQnpdHuWRkrBnBAquxoj4oEHQixe1fiM322AsLlaZ+9BhSsm8whpmy1dWUG46DcuN0ft3ihFvr6nx2FDn6kLBdqvdT7HvOE28oxNg0otlxjErE0n+3iL8brHoT77+Gx4G1NI5U1v6pw= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(366004)(396003)(39860400002)(189003)(199004)(76176011)(6116002)(53546011)(6506007)(14444005)(71200400001)(7736002)(97736004)(2906002)(83716004)(33656002)(478600001)(105586002)(54896002)(102836004)(8936002)(25786009)(256004)(5660300002)(36756003)(86362001)(14454004)(71190400001)(93886005)(81156014)(68736007)(486006)(106356001)(446003)(8676002)(46003)(221733001)(110136005)(186003)(476003)(7116003)(2616005)(11346002)(6486002)(3480700005)(6436002)(99286004)(6246003)(82746002)(561944003)(53936002)(316002)(6512007)(4326008)(236005)(2501003)(229853002)(81166006)(6306002)(54906003)(58126008)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR15MB2196; H:BN7PR15MB2308.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /urfFtBaSrF2EO1zsXjR3AShRDW/Cqyoj3A/wyOFTKt0y5MInfJnAyXB/ryollYiSw5MEUtLi/AVFgkgeZwrd8JWT67tHPBc4y2/M9+f99dqlWX1gCvY35jE0XjBhU38ZCLbfobkC3lFDL2+4RM/rQFgBdqU6RV89EhXBnNUm8dq7bnUhJUezQAZlxdZ1II52D2NS860ZecgxscHPPaZ1h29E1kt0BJwTHB3HyylNrHn8I0kpNRJxbM+T0z/EqqMne2C8/kliMZJOoJRE8LRcUPSOF52HUfOlacztMQXmBzapnVo7xkbWGz859ubpPi5VVz3RMBKH6nVfgM4u/z31m+r7M8dIQ6aarmiKc5lk68YH4hMUdtQEHB6GEpH6azzllGGYGykKa44i7hFG03gTavnLpHlMj/eXA93MqqX1cE= Content-Type: multipart/alternative; boundary="_000_DAC9E580909C4E9E82E0A6AB22CADA24fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f6d5a282-905c-45c2-1896-08d6990da901 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 21:35:26.8099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR15MB2196 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-22_13:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 21:35:43 -0000 --_000_DAC9E580909C4E9E82E0A6AB22CADA24fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB3b3VsZCBiZSDigJxmdW7igJ0gKGkuZS4gc29tZXdoYXQgaGFyZCkgdG8gYXR0ZW1wdCB0 byBtYXRjaCB2aWEgc2ltcGxlIGZpbHRlcmluZyBydWxlcyA6DQogICBXaGVuIGV4cHJlc3NlZCBp bi10aGUtY2xlYXIsIHZlcnNpb24gaXMgZXhwcmVzc2VkIGFzIHR3byB2YXItaW50cywgd2hpY2gg YXJlIHN1bW1lZCBhbmQgbW9kdWxvIDJeMTYNCmkuZS4NCiAgIHZlcnNpb24gPSAoZGVjb2RlVmFy SW50KCkgKyBkZWNvZGVWYXJJbnQoKSkgJSAoMSA8PCAxNikNCi09Ug0KDQpGcm9tOiBFcmlrIEts aW5lIDxla0Bsb29uLmNvPg0KUmVwbHktVG86ICJla0Bsb29uLmNvIiA8ZWtAbG9vbi5jbz4NCkRh dGU6IFRodXJzZGF5LCBGZWJydWFyeSAyMSwgMjAxOSBhdCAxMDowMiBQTQ0KVG86IEphbmEgSXll bmdhciA8anJpLmlldGZAZ21haWwuY29tPg0KQ2M6ICJCcmlhbiBUcmFtbWVsbCAoSUVURikiIDxp ZXRmQHRyYW1tZWxsLmNoPiwgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4sIFJvYmVydG8gUGVvbiA8 ZmVuaXhAZmIuY29tPiwgTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0Pg0KU3ViamVj dDogUmU6IFFVSUMgb3NzaWZpY2F0aW9uDQoNCg0KDQpPbiBUaHUsIDIxIEZlYiAyMDE5IGF0IDIw OjI0LCBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86anJpLmlldGZAZ21h aWwuY29tPj4gd3JvdGU6DQpCcmlhbiwNCg0KSSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBwb3RlbnRp YWxseSBvdGhlciBtb2RlbHMgYXMgd2VsbCwgYnV0IHRoZSBvbmUgd2Uga25vdyBmcm9tIGV4cGVy aWVuY2UgaXMgdGhlIG5haXZlIG9uZS4gIFdlIHNob3VsZCBhdCBsZWFzdCBwcm90ZWN0IGFnYWlu c3QgdGhlIG9uZSBtb2RlbCB3ZSBrbm93LCBuYWl2ZSBvciBub3QuIEknbGwgbm90ZSB0aGF0IGl0 IHF1aWNrbHkgZ2V0cyBkaWZmaWN1bHQgdG8gY29tZSB1cCB3aXRoIG1lYXN1cmVzIGlmIHdlIGFz c3VtZSBhIHNtYXJ0ZXIgb3NzaWZpZXIuDQoNCllvdSB3b3VsZCBwcmV0dHkgbXVjaCBoYXZlIHRv IG1vdmUgdmVyc2lvbiBuZWdvdGlhdGlvbiBiaXRzIChhbmQgc3Vic2VxdWVudCBwcm90b2NvbCBk aWZmZXJlbmNlcykgdG8gdW5kZXJuZWF0aCB0aGUgY3J5cHRvIHVtYnJlbGxhLCB3b3VsZG4ndCB5 b3U/ICBOZWdvdGlhdGluZyBhIG5ld2VyIHZlcnNpb24gd291bGQgaGF2ZSB0byBiZSBsaWtlIG5l Z290aWF0aW5nIHNvbWUgZXh0ZW5zaW9ucywgb3Igc29tZXRoaW5nLCBJIHdvdWxkIHRoaW5rLi4u DQoNCi0gamFuYQ0KDQpPbiBUdWUsIEZlYiAxOSwgMjAxOSBhdCAxMTowMyBQTSBCcmlhbiBUcmFt bWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PiB3 cm90ZToNCihvb3BzLCBoaXQgc2VuZCB0b28gc29vbi4uLikNCg0KPiBPbiAyMCBGZWIgMjAxOSwg YXQgMDc6NTgsIEJyaWFuIFRyYW1tZWxsIChJRVRGKSA8aWV0ZkB0cmFtbWVsbC5jaDxtYWlsdG86 aWV0ZkB0cmFtbWVsbC5jaD4+IHdyb3RlOg0KPg0KPiBoaSBKYW5hLA0KPg0KPiBUaGUgbWlkZGxl Ym94IGFkYXB0YXRpb24gbW9kZWwgdGhhdCB0aGlzIHByb3Bvc2FsIGFkZHJlc3NlcyBzZWVtcyBs aW1pdGVkIHRvIG1pZGRsZWJveGVzIGJ1aWx0IGJhc2VkIG9uIG5haXZlIHRyYWZmaWMgYW5hbHlz aXMgYW5kIHByZS1RVUlDIGFzc3VtcHRpb25zIGFib3V0IHdpcmUgaW1hZ2VzLiBUaGlzIGlzIGFk bWl0dGVkbHkgdGhlIG1vZGVsIGJlaGluZCBvbmUgb2YgR29vZ2xlJ3MgZXhwZXJpZW5jZXMgd2l0 aCBRVUlDIG1pZGRsZWJveCBicmVha2FnZSwgYW5kIHRoZSBvbmUgd2Ugc2VlbSBtb3N0IGNvbmNl cm5lZCB3aXRoIGJlY2F1c2UgYnkgZGVmaW5pdGlvbiB3ZSBjYW5ub3QgZml4IGl0IGJ5IHdyaXRp bmcgdGhpbmdzIGluIGRvY3VtZW50cy4NCg0KSSBkb24ndCB0aGluayB0aGVzZSBhcmUgdGhlIG9u bHkgdGhpbmdzIHdlJ3JlIGNvbmNlcm5lZCBhYm91dCB0aG91Z2guIENvbmNlcm5zIGFib3V0IHBh cnRpdGlvbmluZyBWTiBzcGFjZSBoYXZlIGEgbGVzcyBuYWl2ZSBtb2RlbCBpbiBtaW5kOiBoZXJl IHdlIHRoaW5rIG1vcmUgYWJvdXQgZGVmYXVsdC1kZW55IGZpcmV3YWxscyB0aGF0IGhhdmUgYmVl biB0b2xkIHRoYXQgc29tZSB2ZXJzaW9ucyBvZiBRVUlDIGFyZSBva2F5IGJ1dCBhbGwgb3RoZXJz IGFyZSBub3QuIEFzIG5vdGVkIGJlZm9yZSBJIHBlcnNvbmFsbHkgY2Fubm90IHRoaW5rIG9mIGEg cmVhc29uIGFuIG9wZXJhdG9yIHdvdWxkIHdhbnQgdG8gZG8gdGhpcyAtLSBpZiB5b3UndmUgYWxy ZWFkeSBkZWNpZGVkIHRvIGFsbG93IGEgcHJvdG9jb2wgd2l0aCBsb3cgb2JzZXJ2YWJpbGl0eSBh bmQgYnVpbHQtaW4gZXh0ZW5zaWJpbGl0eSBhcyBhIGRlc2lnbiBnb2FsIG9uIHlvdXIgbmV0d29y aywgZG9lcyB0aGUgZXhhY3QgZmxhdm9yIHJlYWxseSBtYXR0ZXIgYWxsIHRoYXQgbXVjaD8gLS0g YnV0IGl0J3MgYSBjaGVja2JveCBvbiB0aGUgZmlyZXdhbGwgZmVhdHVyZSBsaXN0IHNvIHllYWgs IEkgc3VwcG9zZSBzb21lb25lIHdpbGwgc2hpcCBpdC4NCg0KQXJlIHRoZXJlIG90aGVyIG1pZGRs ZWJveCBhZGFwdGF0aW9uIG1vZGVscyB3ZSBhcmUgY29uY2VybmVkIGFib3V0IGhlcmU/DQoNCkNo ZWVycywNCg0KQnJpYW4NCg0KDQo+PiBPbiAyMCBGZWIgMjAxOSwgYXQgMDA6MTcsIEphbmEgSXll bmdhciA8anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+PiB3cm90 ZToNCj4+DQo+PiBSb2JlcnRvIC0tIHllcywgdGhhdCdzIGJhc2ljYWxseSB3aGF0IEknbSBwcm9w b3NpbmcgdG9vLCBqdXN0IG9uZSB2YXJpYW50IG9mIGhvdyB0byBnbyBhYm91dCBkb2luZyBpdCBk eW5hbWljYWxseSBvdmVyIHRpbWUuDQo+Pg0KPj4gT24gVHVlLCBGZWIgMTksIDIwMTkgYXQgMzox NCBQTSBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbTxtYWlsdG86ZmVuaXhAZmIuY29tPj4gd3Jv dGU6DQo+PiBBcyBvdGhlcnMgaGF2ZSBpbnRpbWF0ZWQgaW4gc29tZSBmb3JtIG9yIGFub3RoZXIs IHlvdSBjYW4gYWxzbyB1c2UgbXVsdGlwbGUgbnVtYmVycyB0byBleHByZXNzIOKAnHZlcnNpb24g MeKAnS4NCj4+DQo+Pg0KPj4gRm9yIGluc3RhbmNlLCBwaWNrIDY0IChvciBzb21lIHNpbWlsYXIg Y29uc3RhbnQpIHJhbmRvbSBudW1iZXJzLCBhbmQgY2FsbCB0aGVtIGFsbCB2ZXJzaW9uIDEuDQo+ PiAtPVINCj4+DQo+Pg0KPj4NCj4+IEZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEphbmEgSXllbmdhciA8 anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+Pg0KPj4gRGF0ZTog VHVlc2RheSwgRmVicnVhcnkgMTksIDIwMTkgYXQgMzoxMCBQTQ0KPj4gVG86IE1hcnRpbiBUaG9t c29uIDxtdEBsb3dlbnRyb3B5Lm5ldDxtYWlsdG86bXRAbG93ZW50cm9weS5uZXQ+Pg0KPj4gQ2M6 IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KPj4gU3ViamVj dDogUmU6IFFVSUMgb3NzaWZpY2F0aW9uDQo+Pg0KPj4NCj4+DQo+PiBPbiBUdWUsIEZlYiAxOSwg MjAxOSBhdCA3OjUyIEFNIE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldDxtYWlsdG86 bXRAbG93ZW50cm9weS5uZXQ+PiB3cm90ZToNCj4+DQo+PiBJIGRvbid0IHRoaW5rIHRoYXQgdGhl cmUgaXMgbXVjaCB2YWx1ZSBpbiB1c2luZyB0d28gdmVyc2lvbiBudW1iZXJzIHRvIHJlZmVyIHRv IHRoZSBzYW1lIHByb3RvY29sLiAgQnV0IGV2ZW4gaWYgd2UgZGlkLCBhcyBsb25nIGFzIHdlIGRp ZG4ndCBlc3RhYmxpc2ggYW55IHBhdHRlcm4gaW4gZG9pbmcgc28sIHRoYXQgY291bGRuJ3QgYmUg dXNlZCBhZ2FpbnN0IHVzLiAgU28gSSBtaWdodCB0ZW50YXRpdmVseSBhZ3JlZSB0aGF0IDB4MSA9 PSAweDIgd291bGQgYmUgaW5hZHZpc2FibGUsIHRoZXJlIGlzIG5vIHN0cm9uZyBuZWVkIHRvIGRv IGFueXRoaW5nIHNwZWNpYWwgd2l0aCB0aGUgZmlyc3QgdmVyc2lvbi4gIEFueSBhdHRlbXB0IHRv IHByb2ZpbGUgUVVJQyB3aWxsIGJlIGRvbmUgd2l0aCBmdWxsIGtub3dsZWRnZSBvZiB0aGUgdmVy c2lvbiBudW1iZXIgd2UgcGljaywgc28gcmFuZG9tbmVzcyBkb2Vzbid0IHNlcnZlIGFueSByZWFs IHB1cnBvc2UuICBTdWJzZXF1ZW50IHZlcnNpb25zIG1pZ2h0IG5lZWQgdG8gdXNlIGEgcmFuZG9t aXplZCB2YWx1ZSwgYnV0IHdlIGNhbiBtYWtlIHRoYXQgZGVjaXNpb24gdGhlbi4NCj4+DQo+Pg0K Pj4NCj4+IEkgZmlndXJlZCB0aGF0IG1ha2luZyBhbGwgdmVyc2lvbiBhc3NpZ25tZW50cyByYW5k b20gaW5zdGVhZCBvZiBzcGVjaWFsLWNhc2luZyAweDEgbWFkZSBpdCBzaW1wbGVyIHRvIHJlYXNv biBhYm91dCBhbmQgdW5pZm9ybSB0byBjb2RlIGZvciwgYnV0IEkgYWN0dWFsbHkgZG9uJ3QgY2Fy ZSBhYm91dCB0aGUgSUFOQSBhc3NpZ25tZW50IGZvciB2MSBmb3IgdGhlIHJlYXNvbiB5b3Ugbm90 ZS4gdjEgd2lsbCBiZSBvbmUgc3BlY2lmaWMgYml0LXBhdHRlcm4gb24gdGhlIHdpcmUgdG8gc3Rh cnQgb2Ygd2l0aCwgYW5kIHRoYXQgY2FuIGp1c3QgYXMgd2VsbCBiZSAweDEuIEl0IHN0aWxsIGRv ZXMgc2VncmVnYXRlIHRoZSBzcGFjZSwgYnV0IHdlIGNhbid0IGRvIGFueXRoaW5nIGFib3V0IGl0 IGFueXdheXMgLSBpdCdsbCBiZSAweDEgb3Igc29tZSBvdGhlciByYW5kb20gbnVtYmVyIGdldHRp bmcgc3BlY2lhbCB0cmVhdG1lbnQuDQo+Pg0KPj4NCj4+DQo+PiBUaGUgcHJvYmxlbSBvZiBjb3Vy c2UgYmVpbmcgdGhhdCBhcyBsb25nIGFzIHYxIHJlbWFpbnMsIHdlIG1pZ2h0IGZpbmQgcGxhY2Vz IHRoYXQgbm8gb3RoZXIgdmVyc2lvbiBkb2VzLiAgVGhlIFFVSUMgIm1hZ2ljIG51bWJlciIgd2ls bCBiZSB3aGF0ZXZlciB3ZSBwaWNrLCBhbmQgd2UgY2FuJ3QgcHJldmVudCBzb21lb25lIGZyb20g Zml4YXRpbmcgb24gdGhhdC4uICBXZSdsbCBjb252aW5jZSB0aG9zZSBwZW9wbGUgaW4gdGhlIHNh bWUgd2F5IHRoZXkgd2lsbCBiZSBjb252aW5jZWQgdG8gb3BlbiB1cCBVRFAgZm9yIFFVSUMgdmVy c2lvbiAxOiBieSBtYWtpbmcgYSBRVUlDIHZlcnNpb24gMiB3b3J0aCBlbmFibGluZy4NCj4+DQo+ Pg0KPj4NCj4+IFRoYXQgd2FzIHRoZSBlbnRpcmUgcG9pbnQgb2YgaGF2aW5nIGFsdGVybmF0ZSBh bmQgcHJlZmVycmVkIHZlcnNpb25zIHRvIDB4MS4gSWYgd2UgaGF2ZSBkb3duZ3JhZGUgcHJvdGVj dGlvbiBpbiBwbGFjZSwgYW5kIGlmIHRoZXJlIGFyZSB0aG9zZSB3aG8gdHJ5IGFsdGVybmF0ZSB2 ZXJzaW9uIG51bWJlcnMgZm9yIHYxLCB0aGF0IGdpdmVzIHVzIHdoYXQgd2UgbmVlZCBhdCB0aGUg ZW5kcG9pbnRzLiBJIGJlbGlldmUgdGhhdCB0aGVyZSB3b3VsZCBiZSBpbnRlcmVzdCBhdCBzb21l IG1ham9yIHZlbmRvcnMgdG8gZG8gdGhpcyBhdCBzb21lIGVuZHBvaW50cy4gUHJlc3VtYWJseSwg d2UgY2FuIGNvbnZpbmNlIEdvb2dsZSB0byBkbyBzb21ldGhpbmcsIHNpbmNlIGl0IGhhcyBiZWVu IGJpdCBieSBtYm94IG9zc2lmaWNhdGlvbiBpbiB0aGUgcGFzdC4gSSBhbSBvcGVyYXRpbmcgb24g dGhlIHByZW1pc2UgdGhhdCB3ZSBoYXZlIGJ1eSBpbiBmcm9tIGEgZmV3IG1ham9yIHByb3ZpZGVy cy4NCj4+DQo+Pg0KPj4NCj4+IElBTkEgaXMgZm9yIG1lIGEgcHVibGljYXRpb24gdmVudWUgd2hl cmUgdGhlc2UgYWx0ZXJuYXRlIHZlcnNpb25zIGFyZSBwdWJsaXNoZWQgYW5kIG90aGVyIGNsaWVu dHMvc2VydmVycyBpbnRlcmVzdGVkIGluIGtlZXBpbmcgdGhlIGVjb3N5c3RlbSBmcm9tIG9zc2lm eWluZyBjYW4gdXNlIHRoZXNlIGFsdGVybmF0ZSB2ZXJzaW9ucyBhcyB3ZWxsLg0KPj4NCj4+DQo+ Pg0KPj4gSSBjb21wbGV0ZWx5IGdldCB0aGUgZG9uJ3Qgc2VncmVnYXRlIHRoaW5nLiAgQnV0IHRv IC0gSSB0aGluayAtIE1pa2tlbCdzIHBvaW50IGFib3V0IGV4cGVyaW1lbnRhdGlvbiB3aXRob3V0 IHBlcm1pc3Npb24sIEkgZG8gdGhpbmsgdGhhdCBzcXVhdHRpbmcgaXMgYSBwZXJmZWN0bHkgc291 bmQgYXBwcm9hY2ggaW4gYSBzcGFjZSB0aGlzIGJpZy4gIFRMUyBwZW9wbGUgZG8gaXQgaW4gYSBt dWNoIHNtYWxsZXIgc3BhY2UuICBBcyBsb25nIHNxdWF0dGVycyBwaWNrIHJhbmRvbSB2YWx1ZXMs IHRoZXkgZG8gc28gaW5mcmVxdWVudGx5LCBhbmQgdGhleSBnZXQgSUFOQSByZWdpc3RyYXRpb25z IGZvciBjb2RlcG9pbnRzIHJlbGF0aXZlbHkgc29vbiBhZnRlcndhcmRzLCB0aGUgcmlzayBvZiBj b2xsaXNpb24gaXMgbG93LiAgUmFuZG9tbmVzcyBoZXJlIGlzIHVzZWZ1bCAtIGJ1dCBwcmltYXJp bHkgYXMgYSBjb2xsaXNpb24tYXZvaWRhbmNlIHRlY2huaXF1ZS4gIFRoZSBUTFMgZXh0ZW5zaW9u IGNvZGVwb2ludCAyNiBpcyBhIGdyZWF0IGV4YW1wbGUgb2Ygd2h5LiAgS2VlcGluZyB0aGUgYmFy IG9uIHJlZ2lzdHJhdGlvbnMgbG93IChGQ0ZTIGlzIGEgcmVhc29uYWJsZSBwb2xpY3kpIHdvdWxk IGFsc28gaGF2ZSB0aGUgZWZmZWN0IG9mIG1ha2luZyB0aGUgcG9vbCBvZiBhcHBhcmVudCB2ZXJz aW9ucyBsYXJnZXIsIHdoaWNoIG1pZ2h0IGJlIG1vcmUgZWZmZWN0aXZlIHRoYW4gYW55IG90aGVy IHN0cmF0ZWd5IHdlIG1pZ2h0IGVtcGxveS4NCj4+DQo+Pg0KPj4NCj4+IEknbSB0b3RhbGx5IGZp bmUgd2l0aCBleHBlcmltZW50YXRpb24gd2l0aG91dCBwZXJtaXNzaW9uLCBhbmQgdXNpbmcgcmFu ZG9tIHRvIGF2b2lkIGNvbGxpc2lvbi4gTXkgcG9pbnQgd2FzIGVudGlyZWx5IGFib3V0IHVzaW5n IGFsdGVybmF0ZSBvbi13aXJlIHZlcnNpb24gbnVtYmVycyBmb3IgdjEuIE5vdGhpbmcgaGVyZSBh Ym91dCBuZXcgb3IgZXhwZXJpbWVudGFsIHZlcnNpb25zLg0KPj4NCj4+DQo+Pg0KPg0K --_000_DAC9E580909C4E9E82E0A6AB22CADA24fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <1C439474C2011B45AEAEB7D446E758A7@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoaXMgd291bGQgYmUg4oCcZnVu4oCdIChpLmUuIHNvbWV3aGF0IGhhcmQpIHRv IGF0dGVtcHQgdG8gbWF0Y2ggdmlhIHNpbXBsZSBmaWx0ZXJpbmcgcnVsZXMgOjxicj4NCiZuYnNw OyZuYnNwOyBXaGVuIGV4cHJlc3NlZCBpbi10aGUtY2xlYXIsIHZlcnNpb24gaXMgZXhwcmVzc2Vk IGFzIHR3byB2YXItaW50cywgd2hpY2ggYXJlIHN1bW1lZCBhbmQgbW9kdWxvIDJeMTY8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmkuZS48YnI+DQombmJzcDsmbmJzcDsgdmVy c2lvbiA9IChkZWNvZGVWYXJJbnQoKSAmIzQzOyBkZWNvZGVWYXJJbnQoKSkgJSAoMSAmbHQ7Jmx0 OyAxNikgPGJyPg0KLT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5FcmlrIEtsaW5lICZsdDtla0Bsb29uLmNvJmd0Ozxicj4NCjxiPlJlcGx5LVRvOiA8L2I+JnF1 b3Q7ZWtAbG9vbi5jbyZxdW90OyAmbHQ7ZWtAbG9vbi5jbyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VGh1cnNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE5IGF0IDEwOjAyIFBNPGJyPg0KPGI+VG86IDwvYj5K YW5hIEl5ZW5nYXIgJmx0O2pyaS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZx dW90O0JyaWFuIFRyYW1tZWxsIChJRVRGKSZxdW90OyAmbHQ7aWV0ZkB0cmFtbWVsbC5jaCZndDss IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7LCBSb2JlcnRvIFBlb24gJmx0O2Zlbml4QGZi LmNvbSZndDssIE1hcnRpbiBUaG9tc29uICZsdDttdEBsb3dlbnRyb3B5Lm5ldCZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFFVSUMgb3NzaWZpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIDIxIEZl YiAyMDE5IGF0IDIwOjI0LCBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmkuaWV0 ZkBnbWFpbC5jb20iPmpyaS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJy aWFuLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdy ZWUgdGhhdCB0aGVyZSBhcmUgcG90ZW50aWFsbHkgb3RoZXIgbW9kZWxzIGFzIHdlbGwsIGJ1dCB0 aGUgb25lIHdlIGtub3cgZnJvbSBleHBlcmllbmNlIGlzIHRoZSBuYWl2ZSBvbmUuJm5ic3A7IFdl IHNob3VsZCBhdCBsZWFzdCBwcm90ZWN0IGFnYWluc3QgdGhlIG9uZSBtb2RlbCB3ZSBrbm93LCBu YWl2ZSBvciBub3QuIEknbGwgbm90ZSB0aGF0IGl0IHF1aWNrbHkgZ2V0cyBkaWZmaWN1bHQgdG8g Y29tZSB1cA0KIHdpdGggbWVhc3VyZXMgaWYgd2UgYXNzdW1lIGEgc21hcnRlciBvc3NpZmllci48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3Ugd291bGQgcHJldHR5IG11Y2ggaGF2ZSB0byBtb3ZlIHZl cnNpb24gbmVnb3RpYXRpb24gYml0cyAoYW5kIHN1YnNlcXVlbnQgcHJvdG9jb2wgZGlmZmVyZW5j ZXMpIHRvIHVuZGVybmVhdGggdGhlIGNyeXB0byB1bWJyZWxsYSwgd291bGRuJ3QgeW91PyZuYnNw OyBOZWdvdGlhdGluZyBhIG5ld2VyIHZlcnNpb24gd291bGQgaGF2ZSB0byBiZSBsaWtlIG5lZ290 aWF0aW5nIHNvbWUgZXh0ZW5zaW9ucywgb3Igc29tZXRoaW5nLA0KIEkgd291bGQgdGhpbmsuLi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIGphbmE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMTksIDIwMTkgYXQgMTE6MDMgUE0gQnJp YW4gVHJhbW1lbGwgKElFVEYpICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaCIg dGFyZ2V0PSJfYmxhbmsiPmlldGZAdHJhbW1lbGwuY2g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+KG9vcHMsIGhpdCBzZW5kIHRvbyBzb29uLi4uKTxicj4NCjxi cj4NCiZndDsgT24gMjAgRmViIDIwMTksIGF0IDA3OjU4LCBCcmlhbiBUcmFtbWVsbCAoSUVURikg Jmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIiB0YXJnZXQ9Il9ibGFuayI+aWV0 ZkB0cmFtbWVsbC5jaDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBoaSBKYW5h LDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgbWlkZGxlYm94IGFkYXB0YXRpb24gbW9kZWwgdGhh dCB0aGlzIHByb3Bvc2FsIGFkZHJlc3NlcyBzZWVtcyBsaW1pdGVkIHRvIG1pZGRsZWJveGVzIGJ1 aWx0IGJhc2VkIG9uIG5haXZlIHRyYWZmaWMgYW5hbHlzaXMgYW5kIHByZS1RVUlDIGFzc3VtcHRp b25zIGFib3V0IHdpcmUgaW1hZ2VzLiBUaGlzIGlzIGFkbWl0dGVkbHkgdGhlIG1vZGVsIGJlaGlu ZCBvbmUgb2YgR29vZ2xlJ3MgZXhwZXJpZW5jZXMgd2l0aCBRVUlDIG1pZGRsZWJveA0KIGJyZWFr YWdlLCBhbmQgdGhlIG9uZSB3ZSBzZWVtIG1vc3QgY29uY2VybmVkIHdpdGggYmVjYXVzZSBieSBk ZWZpbml0aW9uIHdlIGNhbm5vdCBmaXggaXQgYnkgd3JpdGluZyB0aGluZ3MgaW4gZG9jdW1lbnRz Ljxicj4NCjxicj4NCkkgZG9uJ3QgdGhpbmsgdGhlc2UgYXJlIHRoZSBvbmx5IHRoaW5ncyB3ZSdy ZSBjb25jZXJuZWQgYWJvdXQgdGhvdWdoLiBDb25jZXJucyBhYm91dCBwYXJ0aXRpb25pbmcgVk4g c3BhY2UgaGF2ZSBhIGxlc3MgbmFpdmUgbW9kZWwgaW4gbWluZDogaGVyZSB3ZSB0aGluayBtb3Jl IGFib3V0IGRlZmF1bHQtZGVueSBmaXJld2FsbHMgdGhhdCBoYXZlIGJlZW4gdG9sZCB0aGF0IHNv bWUgdmVyc2lvbnMgb2YgUVVJQyBhcmUgb2theSBidXQgYWxsIG90aGVycw0KIGFyZSBub3QuIEFz IG5vdGVkIGJlZm9yZSBJIHBlcnNvbmFsbHkgY2Fubm90IHRoaW5rIG9mIGEgcmVhc29uIGFuIG9w ZXJhdG9yIHdvdWxkIHdhbnQgdG8gZG8gdGhpcyAtLSBpZiB5b3UndmUgYWxyZWFkeSBkZWNpZGVk IHRvIGFsbG93IGEgcHJvdG9jb2wgd2l0aCBsb3cgb2JzZXJ2YWJpbGl0eSBhbmQgYnVpbHQtaW4g ZXh0ZW5zaWJpbGl0eSBhcyBhIGRlc2lnbiBnb2FsIG9uIHlvdXIgbmV0d29yaywgZG9lcyB0aGUg ZXhhY3QgZmxhdm9yIHJlYWxseQ0KIG1hdHRlciBhbGwgdGhhdCBtdWNoPyAtLSBidXQgaXQncyBh IGNoZWNrYm94IG9uIHRoZSBmaXJld2FsbCBmZWF0dXJlIGxpc3Qgc28geWVhaCwgSSBzdXBwb3Nl IHNvbWVvbmUgd2lsbCBzaGlwIGl0Ljxicj4NCjxicj4NCkFyZSB0aGVyZSBvdGhlciBtaWRkbGVi b3ggYWRhcHRhdGlvbiBtb2RlbHMgd2UgYXJlIGNvbmNlcm5lZCBhYm91dCBoZXJlPzxicj4NCjxi cj4NCkNoZWVycyw8YnI+DQo8YnI+DQpCcmlhbjxicj4NCjxicj4NCjxicj4NCiZndDsmZ3Q7IE9u IDIwIEZlYiAyMDE5LCBhdCAwMDoxNywgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86 anJpLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+anJpLmlldGZAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgUm9iZXJ0byAtLSB5ZXMs IHRoYXQncyBiYXNpY2FsbHkgd2hhdCBJJ20gcHJvcG9zaW5nIHRvbywganVzdCBvbmUgdmFyaWFu dCBvZiBob3cgdG8gZ28gYWJvdXQgZG9pbmcgaXQgZHluYW1pY2FsbHkgb3ZlciB0aW1lLjxicj4N CiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IE9uIFR1ZSwgRmViIDE5LCAyMDE5IGF0IDM6MTQgUE0g Um9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZmVuaXhAZmIuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgQXMgb3RoZXJz IGhhdmUgaW50aW1hdGVkIGluIHNvbWUgZm9ybSBvciBhbm90aGVyLCB5b3UgY2FuIGFsc28gdXNl IG11bHRpcGxlIG51bWJlcnMgdG8gZXhwcmVzcyDigJx2ZXJzaW9uIDHigJ0uPGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgRm9yIGluc3RhbmNlLCBwaWNrIDY0IChv ciBzb21lIHNpbWlsYXIgY29uc3RhbnQpIHJhbmRvbSBudW1iZXJzLCBhbmQgY2FsbCB0aGVtIGFs bCB2ZXJzaW9uIDEuPGJyPg0KJmd0OyZndDsgLT1SPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgRnJvbTogUVVJQyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmkuaWV0ZkBnbWFp bC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IERhdGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE5LCAy MDE5IGF0IDM6MTAgUE08YnI+DQomZ3Q7Jmd0OyBUbzogTWFydGluIFRob21zb24gJmx0OzxhIGhy ZWY9Im1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm10QGxvd2VudHJv cHkubmV0PC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyBDYzogUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8 YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogUVVJQyBvc3NpZmljYXRpb248YnI+DQomZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBPbiBUdWUsIEZl YiAxOSwgMjAxOSBhdCA3OjUyIEFNIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86 bXRAbG93ZW50cm9weS5uZXQiIHRhcmdldD0iX2JsYW5rIj5tdEBsb3dlbnRyb3B5Lm5ldDwvYT4m Z3Q7IHdyb3RlOg0KPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSSBkb24ndCB0aGluayB0 aGF0IHRoZXJlIGlzIG11Y2ggdmFsdWUgaW4gdXNpbmcgdHdvIHZlcnNpb24gbnVtYmVycyB0byBy ZWZlciB0byB0aGUgc2FtZSBwcm90b2NvbC4mbmJzcDsgQnV0IGV2ZW4gaWYgd2UgZGlkLCBhcyBs b25nIGFzIHdlIGRpZG4ndCBlc3RhYmxpc2ggYW55IHBhdHRlcm4gaW4gZG9pbmcgc28sIHRoYXQg Y291bGRuJ3QgYmUgdXNlZCBhZ2FpbnN0IHVzLiZuYnNwOyBTbyBJIG1pZ2h0IHRlbnRhdGl2ZWx5 IGFncmVlIHRoYXQgMHgxID09IDB4Mg0KIHdvdWxkIGJlIGluYWR2aXNhYmxlLCB0aGVyZSBpcyBu byBzdHJvbmcgbmVlZCB0byBkbyBhbnl0aGluZyBzcGVjaWFsIHdpdGggdGhlIGZpcnN0IHZlcnNp b24uJm5ic3A7IEFueSBhdHRlbXB0IHRvIHByb2ZpbGUgUVVJQyB3aWxsIGJlIGRvbmUgd2l0aCBm dWxsIGtub3dsZWRnZSBvZiB0aGUgdmVyc2lvbiBudW1iZXIgd2UgcGljaywgc28gcmFuZG9tbmVz cyBkb2Vzbid0IHNlcnZlIGFueSByZWFsIHB1cnBvc2UuJm5ic3A7IFN1YnNlcXVlbnQgdmVyc2lv bnMgbWlnaHQNCiBuZWVkIHRvIHVzZSBhIHJhbmRvbWl6ZWQgdmFsdWUsIGJ1dCB3ZSBjYW4gbWFr ZSB0aGF0IGRlY2lzaW9uIHRoZW4uPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSSBmaWd1cmVkIHRoYXQgbWFraW5nIGFsbCB2ZXJzaW9u IGFzc2lnbm1lbnRzIHJhbmRvbSBpbnN0ZWFkIG9mIHNwZWNpYWwtY2FzaW5nIDB4MSBtYWRlIGl0 IHNpbXBsZXIgdG8gcmVhc29uIGFib3V0IGFuZCB1bmlmb3JtIHRvIGNvZGUgZm9yLCBidXQgSSBh Y3R1YWxseSBkb24ndCBjYXJlIGFib3V0IHRoZSBJQU5BIGFzc2lnbm1lbnQgZm9yIHYxIGZvciB0 aGUgcmVhc29uIHlvdSBub3RlLiB2MSB3aWxsIGJlIG9uZSBzcGVjaWZpYyBiaXQtcGF0dGVybg0K IG9uIHRoZSB3aXJlIHRvIHN0YXJ0IG9mIHdpdGgsIGFuZCB0aGF0IGNhbiBqdXN0IGFzIHdlbGwg YmUgMHgxLiBJdCBzdGlsbCBkb2VzIHNlZ3JlZ2F0ZSB0aGUgc3BhY2UsIGJ1dCB3ZSBjYW4ndCBk byBhbnl0aGluZyBhYm91dCBpdCBhbnl3YXlzIC0gaXQnbGwgYmUgMHgxIG9yIHNvbWUgb3RoZXIg cmFuZG9tIG51bWJlciBnZXR0aW5nIHNwZWNpYWwgdHJlYXRtZW50Ljxicj4NCiZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoZSBwcm9ibGVtIG9m IGNvdXJzZSBiZWluZyB0aGF0IGFzIGxvbmcgYXMgdjEgcmVtYWlucywgd2UgbWlnaHQgZmluZCBw bGFjZXMgdGhhdCBubyBvdGhlciB2ZXJzaW9uIGRvZXMuJm5ic3A7IFRoZSBRVUlDICZxdW90O21h Z2ljIG51bWJlciZxdW90OyB3aWxsIGJlIHdoYXRldmVyIHdlIHBpY2ssIGFuZCB3ZSBjYW4ndCBw cmV2ZW50IHNvbWVvbmUgZnJvbSBmaXhhdGluZyBvbiB0aGF0Li4mbmJzcDsgV2UnbGwgY29udmlu Y2UgdGhvc2UgcGVvcGxlIGluIHRoZSBzYW1lIHdheQ0KIHRoZXkgd2lsbCBiZSBjb252aW5jZWQg dG8gb3BlbiB1cCBVRFAgZm9yIFFVSUMgdmVyc2lvbiAxOiBieSBtYWtpbmcgYSBRVUlDIHZlcnNp b24gMiB3b3J0aCBlbmFibGluZy48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUaGF0IHdhcyB0aGUgZW50aXJlIHBvaW50IG9mIGhhdmlu ZyBhbHRlcm5hdGUgYW5kIHByZWZlcnJlZCB2ZXJzaW9ucyB0byAweDEuIElmIHdlIGhhdmUgZG93 bmdyYWRlIHByb3RlY3Rpb24gaW4gcGxhY2UsIGFuZCBpZiB0aGVyZSBhcmUgdGhvc2Ugd2hvIHRy eSBhbHRlcm5hdGUgdmVyc2lvbiBudW1iZXJzIGZvciB2MSwgdGhhdCBnaXZlcyB1cyB3aGF0IHdl IG5lZWQgYXQgdGhlIGVuZHBvaW50cy4gSSBiZWxpZXZlIHRoYXQgdGhlcmUgd291bGQNCiBiZSBp bnRlcmVzdCBhdCBzb21lIG1ham9yIHZlbmRvcnMgdG8gZG8gdGhpcyBhdCBzb21lIGVuZHBvaW50 cy4gUHJlc3VtYWJseSwgd2UgY2FuIGNvbnZpbmNlIEdvb2dsZSB0byBkbyBzb21ldGhpbmcsIHNp bmNlIGl0IGhhcyBiZWVuIGJpdCBieSBtYm94IG9zc2lmaWNhdGlvbiBpbiB0aGUgcGFzdC4gSSBh bSBvcGVyYXRpbmcgb24gdGhlIHByZW1pc2UgdGhhdCB3ZSBoYXZlIGJ1eSBpbiBmcm9tIGEgZmV3 IG1ham9yIHByb3ZpZGVycy48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJQU5BIGlzIGZvciBtZSBhIHB1YmxpY2F0aW9uIHZlbnVlIHdo ZXJlIHRoZXNlIGFsdGVybmF0ZSB2ZXJzaW9ucyBhcmUgcHVibGlzaGVkIGFuZCBvdGhlciBjbGll bnRzL3NlcnZlcnMgaW50ZXJlc3RlZCBpbiBrZWVwaW5nIHRoZSBlY29zeXN0ZW0gZnJvbSBvc3Np ZnlpbmcgY2FuIHVzZSB0aGVzZSBhbHRlcm5hdGUgdmVyc2lvbnMgYXMgd2VsbC48YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIGNvbXBs ZXRlbHkgZ2V0IHRoZSBkb24ndCBzZWdyZWdhdGUgdGhpbmcuJm5ic3A7IEJ1dCB0byAtIEkgdGhp bmsgLSBNaWtrZWwncyBwb2ludCBhYm91dCBleHBlcmltZW50YXRpb24gd2l0aG91dCBwZXJtaXNz aW9uLCBJIGRvIHRoaW5rIHRoYXQgc3F1YXR0aW5nIGlzIGEgcGVyZmVjdGx5IHNvdW5kIGFwcHJv YWNoIGluIGEgc3BhY2UgdGhpcyBiaWcuJm5ic3A7IFRMUyBwZW9wbGUgZG8gaXQgaW4gYSBtdWNo IHNtYWxsZXIgc3BhY2UuJm5ic3A7IEFzIGxvbmcgc3F1YXR0ZXJzDQogcGljayByYW5kb20gdmFs dWVzLCB0aGV5IGRvIHNvIGluZnJlcXVlbnRseSwgYW5kIHRoZXkgZ2V0IElBTkEgcmVnaXN0cmF0 aW9ucyBmb3IgY29kZXBvaW50cyByZWxhdGl2ZWx5IHNvb24gYWZ0ZXJ3YXJkcywgdGhlIHJpc2sg b2YgY29sbGlzaW9uIGlzIGxvdy4mbmJzcDsgUmFuZG9tbmVzcyBoZXJlIGlzIHVzZWZ1bCAtIGJ1 dCBwcmltYXJpbHkgYXMgYSBjb2xsaXNpb24tYXZvaWRhbmNlIHRlY2huaXF1ZS4mbmJzcDsgVGhl IFRMUyBleHRlbnNpb24gY29kZXBvaW50DQogMjYgaXMgYSBncmVhdCBleGFtcGxlIG9mIHdoeS4m bmJzcDsgS2VlcGluZyB0aGUgYmFyIG9uIHJlZ2lzdHJhdGlvbnMgbG93IChGQ0ZTIGlzIGEgcmVh c29uYWJsZSBwb2xpY3kpIHdvdWxkIGFsc28gaGF2ZSB0aGUgZWZmZWN0IG9mIG1ha2luZyB0aGUg cG9vbCBvZiBhcHBhcmVudCB2ZXJzaW9ucyBsYXJnZXIsIHdoaWNoIG1pZ2h0IGJlIG1vcmUgZWZm ZWN0aXZlIHRoYW4gYW55IG90aGVyIHN0cmF0ZWd5IHdlIG1pZ2h0IGVtcGxveS48YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJJ20gdG90 YWxseSBmaW5lIHdpdGggZXhwZXJpbWVudGF0aW9uIHdpdGhvdXQgcGVybWlzc2lvbiwgYW5kIHVz aW5nIHJhbmRvbSB0byBhdm9pZCBjb2xsaXNpb24uIE15IHBvaW50IHdhcyBlbnRpcmVseSBhYm91 dCB1c2luZyBhbHRlcm5hdGUgb24td2lyZSB2ZXJzaW9uIG51bWJlcnMgZm9yIHYxLiBOb3RoaW5n IGhlcmUgYWJvdXQgbmV3IG9yIGV4cGVyaW1lbnRhbCB2ZXJzaW9ucy48YnI+DQomZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DAC9E580909C4E9E82E0A6AB22CADA24fbcom_-- From nobody Fri Feb 22 15:06:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31487128CF3 for ; Fri, 22 Feb 2019 15:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=qq1RGOwt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JoRviApy 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 LWpQocjb3Alf for ; Fri, 22 Feb 2019 15:06:51 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D396128BCC for ; Fri, 22 Feb 2019 15:06:51 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 66E3822152; Fri, 22 Feb 2019 18:06:50 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Fri, 22 Feb 2019 18:06:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:cc:subject :content-type:content-transfer-encoding; s=fm1; bh=SFmS8BXAmLz7B za9YDVvFL70P+Spy3tRVxS5Cvs5Uy0=; b=qq1RGOwtmPGjkKIuXD4rJi2TmMt+H abwOZqOiLxKviqBUcjTxuCnq8KwvFCpeUtdM7o0NXW52O2IkDurTtleQFP3CVwTI uH4NiZVR8hl4qO157QTxCsfRP3rJc2qjQ2wKqSj+kgWNApNqVVSnN/Pl4CiBzo9/ QdGSGvAkKHs/LN49xAqnTGrfTrwyRmOY62htGQKJxW25iAF5jeYbT86zUih+XbhW RxzG4Z69rQ+MlO0c0iE9zjzP44uEo+EntvNrfqyhrNvBpgAW1XeAuQDlvD+Gy2W3 ivdQTlmqbw51UqNZbgfW/ZTReOOMQAy3fMnnPwap/NNtlvucwdp/MPfbQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=SFmS8BXAmLz7Bza9YDVvFL70P+Spy3tRVxS5Cvs5Uy0=; b=JoRviApy s/kOJlvLZ/22mCmbx60i5HLpIt6UVPsHwlfXgK7eZnC5cfPwcWAop6GskrJrrw3J gR8ilzym2xlsIDWqQwTGQxtIghtPLSG5gP28UZSeMlTvvfT/gbczYKjwsRitD8XF htFIq8RKDrsgBuKlHLKed4WVdc969/3O1xNyXrgqc+z/RNTwUA4cQTTiGH/qel+n P28AKUfAnxlG05DseybFU7Zvfm400A57N1sICl1SFrKnnu3nZLtAEoYBhE6kA8Ld ebBX4ZZctZBLJNUnpScP6BBL2Gx0uM2v+KsHynCPaGIVVPyR+zFAmelU6zaRiG5O VnKiuX3miNrcrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddruddtgddujeduucdltddurdegtdelrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc frrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B90C17C1EB; Fri, 22 Feb 2019 18:06:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-895-g0d23ba6-fmstable-20190213v1 X-Me-Personality: 92534000 Message-Id: <50fa8e3a-a997-4c09-ba38-b8cdcde3b27c@www.fastmail.com> In-Reply-To: References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> Date: Fri, 22 Feb 2019 18:06:46 -0500 From: "Martin Thomson" To: "Roberto Peon" Cc: "QUIC WG" Subject: Re: QUIC ossification Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 23:06:54 -0000 Leaving the specifics of the proposal aside for the moment, the problem = here is that we have no shared context AND we want to ensure that legiti= mate endpoints don't have to go to extreme measures to get the informati= on they need. A little obfuscation might get us somewhere (esp. if we a= re willing to burn either more octets or part of our existing space), bu= t let's try to focus on what we think we're going to achieve by doing so= mething here. Funny that TLS are concurrently talking about hiding the existence of ES= NI, which has so many of the same constraints: you have to standardize t= he semantics so that it can be decoded, but you would rather that only t= he intended recipient was able to read it. In both cases, the answer is= that you lose because you have no shared keys that would enable the onl= y thing that we know works (crypto). (I haven't ingested Stephen's long= email there, maybe he has a brilliant idea for breaking the deadlock, b= ut I doubt that it will help us here, because at least with ESNI you *ma= ybe* have a key and it seems to be using crypto.) On Fri, Feb 22, 2019, at 13:35, Roberto Peon wrote: > =20 > This would be =E2=80=9Cfun=E2=80=9D (i.e. somewhat hard) to attempt to= match via simple=20 > filtering rules : > When expressed in-the-clear, version is expressed as two var-ints,=20= > which are summed and modulo 2^16 >=20 > =20 > i.e. > version =3D (decodeVarInt() + decodeVarInt()) % (1 << 16)=20 > -=3DR >=20 > =20 > =20 >=20 > =20 > =20 > *From: *Erik Kline > *Reply-To: *"ek@loon.co" > *Date: *Thursday, February 21, 2019 at 10:02 PM > *To: *Jana Iyengar > *Cc: *"Brian Trammell (IETF)" , QUIC WG=20 > , Roberto Peon , Martin Thomson=20 > > *Subject: *Re: QUIC ossification >=20 > =20 > =20 > =20 > =20 >=20 > =20 > =20 > =20 > =20 > =20 >=20 > =20 > =20 > =20 >=20 > =20 > =20 > =20 > On Thu, 21 Feb 2019 at 20:24, Jana Iyengar wrote:= >=20 > =20 > =20 > > =20 > > Brian,=20 >=20 > > =20 > > =20 > > =20 >=20 > > =20 > > =20 > > =20 > > I agree that there are potentially other models as well, but the one= we know from experience is the naive one. We should at least protect ag= ainst the one model we know, naive or not. I'll note that it quickly get= s difficult to come up with measures if we assume a smarter ossifier. >=20 > > =20 > > =20 > > =20 > =20 > =20 >=20 > =20 > =20 > =20 > You would pretty much have to move version negotiation bits (and=20 > subsequent protocol differences) to underneath the crypto umbrella,=20= > wouldn't you? Negotiating a newer version would have to be like=20 > negotiating some extensions, or something, I would think... >=20 > =20 > =20 > =20 > =20 >=20 > =20 > =20 > > =20 > > =20 > > - jana >=20 > > =20 > > =20 > > =20 > > =20 >=20 > > =20 > > =20 > > =20 > > On Tue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) wrote: >=20 > > =20 > > =20 > >> (oops, hit send too soon...) > >> =20 > >> > On 20 Feb 2019, at 07:58, Brian Trammell (IETF) wrote: > >> >=20 > >> > hi Jana, > >> >=20 > >> > The middlebox adaptation model that this proposal addresses seem= s limited to middleboxes built based on naive traffic analysis and pre-Q= UIC assumptions about wire images. This is admittedly the model behind o= ne of Google's experiences with QUIC middlebox breakage, and the one we = seem most concerned with because by definition we cannot fix it by writi= ng things in documents. > >> =20 > >> I don't think these are the only things we're concerned about thou= gh. Concerns about partitioning VN space have a less naive model in mind= : here we think more about default-deny firewalls that have been told th= at some versions of QUIC are okay but all others are not. As noted befor= e I personally cannot think of a reason an operator would want to do thi= s -- if you've already decided to allow a protocol with low observabilit= y and built-in extensibility as a design goal on your network, does the = exact flavor really matter all that much? -- but it's a checkbox on the = firewall feature list so yeah, I suppose someone will ship it. > >> =20 > >> Are there other middlebox adaptation models we are concerned about= here? > >> =20 > >> Cheers, > >> =20 > >> Brian > >> =20 > >> =20 > >> >> On 20 Feb 2019, at 00:17, Jana Iyengar wro= te: > >> >>=20 > >> >> Roberto -- yes, that's basically what I'm proposing too, just o= ne variant of how to go about doing it dynamically over time. > >> >>=20 > >> >> On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon wro= te: > >> >> As others have intimated in some form or another, you can also = use multiple numbers to express =E2=80=9Cversion 1=E2=80=9D. > >> >>=20 > >> >>=20 > >> >> For instance, pick 64 (or some similar constant) random numbers= , and call them all version 1. > >> >> -=3DR > >> >>=20 > >> >>=20 > >> >>=20 > >> >> From: QUIC on behalf of Jana Iyengar > >> >> Date: Tuesday, February 19, 2019 at 3:10 PM > >> >> To: Martin Thomson > >> >> Cc: QUIC WG > >> >> Subject: Re: QUIC ossification > >> >>=20 > >> >>=20 > >> >>=20 > >> >> On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson wrote:=20 > >> >>=20 > >> >> I don't think that there is much value in using two version num= bers to refer to the same protocol. But even if we did, as long as we di= dn't establish any pattern in doing so, that couldn't be used against us= . So I might tentatively agree that 0x1 =3D=3D 0x2 would be inadvisable,= there is no strong need to do anything special with the first version. = Any attempt to profile QUIC will be done with full knowledge of the vers= ion number we pick, so randomness doesn't serve any real purpose. Subseq= uent versions might need to use a randomized value, but we can make that= decision then. > >> >>=20 > >> >>=20 > >> >>=20 > >> >> I figured that making all version assignments random instead of= special-casing 0x1 made it simpler to reason about and uniform to code = for, but I actually don't care about the IANA assignment for v1 for the = reason you note. v1 will be one specific bit-pattern on the wire to star= t of with, and that can just as well be 0x1. It still does segregate the= space, but we can't do anything about it anyways - it'll be 0x1 or some= other random number getting special treatment. > >> >>=20 > >> >>=20 > >> >>=20 > >> >> The problem of course being that as long as v1 remains, we migh= t find places that no other version does. The QUIC "magic number" will b= e whatever we pick, and we can't prevent someone from fixating on that..= We'll convince those people in the same way they will be convinced to o= pen up UDP for QUIC version 1: by making a QUIC version 2 worth enabling= . > >> >>=20 > >> >>=20 > >> >>=20 > >> >> That was the entire point of having alternate and preferred ver= sions to 0x1. If we have downgrade protection in place, and if there are= those who try alternate version numbers for v1, that gives us what we n= eed at the endpoints. I believe that there would be interest at some maj= or vendors to do this at some endpoints. Presumably, we can convince Goo= gle to do something, since it has been bit by mbox ossification in the p= ast. I am operating on the premise that we have buy in from a few major = providers. > >> >>=20 > >> >>=20 > >> >>=20 > >> >> IANA is for me a publication venue where these alternate versio= ns are published and other clients/servers interested in keeping the eco= system from ossifying can use these alternate versions as well. > >> >>=20 > >> >>=20 > >> >>=20 > >> >> I completely get the don't segregate thing. But to - I think - = Mikkel's point about experimentation without permission, I do think that= squatting is a perfectly sound approach in a space this big. TLS people= do it in a much smaller space. As long squatters pick random values, th= ey do so infrequently, and they get IANA registrations for codepoints re= latively soon afterwards, the risk of collision is low. Randomness here = is useful - but primarily as a collision-avoidance technique. The TLS ex= tension codepoint 26 is a great example of why. Keeping the bar on regis= trations low (FCFS is a reasonable policy) would also have the effect of= making the pool of apparent versions larger, which might be more effect= ive than any other strategy we might employ. > >> >>=20 > >> >>=20 > >> >>=20 > >> >> I'm totally fine with experimentation without permission, and u= sing random to avoid collision. My point was entirely about using altern= ate on-wire version numbers for v1. Nothing here about new or experiment= al versions. > >> >>=20 > >> >>=20 > >> >>=20 > >> >=20 >=20 > >> =20 > > =20 > =20 > =20 > From nobody Fri Feb 22 19:03:24 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D87130EB3 for ; Fri, 22 Feb 2019 19:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 ETi0OgweRvGc for ; Fri, 22 Feb 2019 19:03:20 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FF0130EAE for ; Fri, 22 Feb 2019 19:03:20 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx63.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gxNav-000Bxc-Q4 for quic@ietf.org; Sat, 23 Feb 2019 04:03:18 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gxNas-0008St-Od for quic@ietf.org; Fri, 22 Feb 2019 22:03:15 -0500 Received: (qmail 1235 invoked from network); 23 Feb 2019 03:03:12 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Feb 2019 03:03:11 -0000 To: Martin Thomson , Roberto Peon Cc: QUIC WG References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> <50fa8e3a-a997-4c09-ba38-b8cdcde3b27c@www.fastmail.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Fri, 22 Feb 2019 19:03:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <50fa8e3a-a997-4c09-ba38-b8cdcde3b27c@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: QUIC ossification X-Originating-IP: 168.144.250.232 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.20) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5lWN+ePDgQFwSYLkYXX7Tep602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViF+RSagawoWokBe2JChm+Os7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB4lampmfDNuiABFovtjnMdR/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaIaRz7MMaWWw7JDSyG1BzB5Qu3kEb3Mh2nAU5YXIFsE6uTWFXq6RAot ClKBPZZrYGmAImxrekFydH4DojSCKJXVXfdz0+Q1eHsqtFQKXUaZ+h596SWGosiQ15/fAFUBngWU swziTuoonQBgr0dS5AZLiwQzKw+6v3CaIMG6s7LqJFA2+ajytfCzORPDOH6X2/5SyaRgIwuFZktu hI3SFVknneU4NFyG5BHLia4kAhEmypLvfpXQb3kQ6IMxGnbD8n7tOuTWXXIj0TpQpfUxR/zGwBdV FCAdssvNXtvdLBNmqz5Gegm2Di+XkC+U0gjMGGKSn11dj1tX732somwMviE4rNLMkKiSx4DbX99P +gh4iWPT5m4OdqWMdE0b4Joz08+J+cv73CChOPjKA0/DVd830vHLIFSGGMV7x6CHvZpJG/9P/4OG qJ5dkO1xTEy0joEwyGTHIAoNFX+jcW7DGmdEezpuI9IICsCKA/p66v7fhw== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 03:03:22 -0000 On 2/22/2019 3:06 PM, Martin Thomson wrote: > Leaving the specifics of the proposal aside for the moment, the problem= here is that we have no shared context AND we want to ensure that legiti= mate endpoints don't have to go to extreme measures to get the informatio= n they need. A little obfuscation might get us somewhere (esp. if we are= willing to burn either more octets or part of our existing space), but l= et's try to focus on what we think we're going to achieve by doing someth= ing here. > > Funny that TLS are concurrently talking about hiding the existence of E= SNI, which has so many of the same constraints: you have to standardize t= he semantics so that it can be decoded, but you would rather that only th= e intended recipient was able to read it. In both cases, the answer is t= hat you lose because you have no shared keys that would enable the only t= hing that we know works (crypto). (I haven't ingested Stephen's long ema= il there, maybe he has a brilliant idea for breaking the deadlock, but I = doubt that it will help us here, because at least with ESNI you *maybe* h= ave a key and it seems to be using crypto.) Martin, you seem uncharacteristically restrained today. How about, "If it is not encrypted, middle boxes will ossify, and pathetic efforts at obfuscation are not going to save you?" I get the point about grease, etc. But grease mostly works between semi-consenting endpoints, such as QUIC peers who might have forgotten to actually implement a part of the extension mechanisms. Greasing Transport Parameter codes, for example. In the case of version numbers, we have a quandary. We can only use a scheme that is standard enough that many implementations understand what a particular version means. But if it is standard enough, then the villains that design the middle-boxes will know everything about it, and won't stop stroking their furry white cats for even a second. -- Christian Huitema From nobody Fri Feb 22 23:03:04 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6D7131025 for ; Fri, 22 Feb 2019 23:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=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 c283C_UH5CP7 for ; Fri, 22 Feb 2019 23:03:00 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5500A12F295 for ; Fri, 22 Feb 2019 23:03:00 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id z124so6603682itc.2 for ; Fri, 22 Feb 2019 23:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=wqYQ4BFcuDcgVMhVL3EMmvkt4L2v9SMQOqtJfWFjHZg=; b=nVTJqjP02Dw4wPdr/iuw5RJChLQy96wRXQpBoJR2bvJuOPyf37r2pNDNg6qH2WbQnu 0OisVxkEa8gMspmMjZIYHXIwkjz0HiV9pbEPInAZlfvvDAQHwOjxzJVDyQZKx9z9KyBc f57NQ2n+aS7Nzkibnr0yjedSaHVvb1UAv/t0TjA09wP3WxPXmNQPA+vphLvwid81XRyd Og09N6YN86eH+vOglQ/t3xR61uyp6qynbkrysGVMcoznmwtskKl1v1LXNudXwEFe8xl8 i0pVkZCVXbFj/fLomcyTMds4ht2hCmP2EVk2gCWATje9RBtpzC+dwczB6XFIfu9IMvFw Q4hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=wqYQ4BFcuDcgVMhVL3EMmvkt4L2v9SMQOqtJfWFjHZg=; b=iOPJdukbkfeCTl/lpOiue5jcizUbskTh2JS8JvCDs1YdjKZtchC4jyoGAX6dNoEi0N 0SlOkjrsZxOP6XWpsh6TPNlzaNLVMftHmWzksUJSq384B5viurTWDbqtuGdmMycw6NRY bSxLZaHQFEAAZHAM6YwJQz75ruFQFxlIKvg5dV8el5EeVH/tS2RclS4HReuQ/8HCtztb 3x91wAGByVxBFM6lZPV6G6+3fctT/vNQTB9Cm6Z+m16kTuoS6ZMn6u8T1VqZivrYOpLZ J0EAWPPmIwzYtF0vx5/pWZ8d1MaY35Oa8RXHRMdd+qrcnN+3uJVQh3e8TjvN4XdH46wu LdcA== X-Gm-Message-State: AHQUAubl8I9eC7nxzplQpUqVL4CYby+vYLvFBmKnjxZndFzgjUOiDtwZ AA93H//9ugsJQI0/h9X+dhDzPrvgzjHx0z2GxEA= X-Google-Smtp-Source: AHgI3IYu6Pq43xxhJQOp302FbXZifXTR+4EE2zXV/+GTjVuHJsrZ4birSfu3fi8R7/MZQoN3XV7dKdGO96K95eV4tzk= X-Received: by 2002:a24:4487:: with SMTP id o129mr4114150ita.167.1550905379250; Fri, 22 Feb 2019 23:02:59 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 Feb 2019 23:02:58 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> <50fa8e3a-a997-4c09-ba38-b8cdcde3b27c@www.fastmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 22 Feb 2019 23:02:58 -0800 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson , Christian Huitema , Roberto Peon Cc: QUIC WG Content-Type: multipart/alternative; boundary="00000000000035eb7f05828a4cd0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 07:03:03 -0000 --00000000000035eb7f05828a4cd0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But if it is standard enough, then the villains that design the middle-boxes will know everything about it, and won't stop stroking their furry white cats for even a second hear I fear we are making the already complicated concept of vneg more difficult without any actual benefit. But if we must obfuscate, I=E2=80=99d prefer a longer version id of 128 bit= s and use secure hash or crypto. And if not, can=E2=80=99t we please make use of Fibonacci numbers somehow -= Roberto already suggested adding two numbers. On 23 February 2019 at 04.03.35, Christian Huitema (huitema@huitema.net) wrote: On 2/22/2019 3:06 PM, Martin Thomson wrote: > Leaving the specifics of the proposal aside for the moment, the problem here is that we have no shared context AND we want to ensure that legitimate endpoints don't have to go to extreme measures to get the information they need. A little obfuscation might get us somewhere (esp. if we are willing to burn either more octets or part of our existing space), but let's try to focus on what we think we're going to achieve by doing something here. > > Funny that TLS are concurrently talking about hiding the existence of ESNI, which has so many of the same constraints: you have to standardize the semantics so that it can be decoded, but you would rather that only the intended recipient was able to read it. In both cases, the answer is that you lose because you have no shared keys that would enable the only thing that we know works (crypto). (I haven't ingested Stephen's long email there, maybe he has a brilliant idea for breaking the deadlock, but I doubt that it will help us here, because at least with ESNI you *maybe* have a key and it seems to be using crypto.) Martin, you seem uncharacteristically restrained today. How about, "If it is not encrypted, middle boxes will ossify, and pathetic efforts at obfuscation are not going to save you?" I get the point about grease, etc. But grease mostly works between semi-consenting endpoints, such as QUIC peers who might have forgotten to actually implement a part of the extension mechanisms. Greasing Transport Parameter codes, for example. In the case of version numbers, we have a quandary. We can only use a scheme that is standard enough that many implementations understand what a particular version means. But if it is standard enough, then the villains that design the middle-boxes will know everything about it, and won't stop stroking their furry white cats for even a second. -- Christian Huitema --00000000000035eb7f05828a4cd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
But if it is standard e= nough, then the villains that design the=C2=A0
middle-boxes will know ev= erything about it, and won't stop stroking=C2=A0
their furry white c= ats for even a second

hear

I fear we are making = the already complicated concept of vneg more difficult without any actual b= enefit.

But if we must obfuscate, I=E2=80=99d prefer a longer version= id of 128 bits and use secure hash or crypto.

And if not, can=E2=80= =99t we please make use of Fibonacci numbers somehow - Roberto already sugg= ested adding two numbers.



= On 23 February 2019 at 04.03.35, Christian Huitema (huitema@huitema.net) wrote:

On 2/22/2019 3:06 PM, Mart= in Thomson wrote:

> Leaving the specifics of the proposal aside for the moment, the pr= oblem here is that we have no shared context AND we want to ensure that leg= itimate endpoints don't have to go to extreme measures to get the infor= mation they need. A little obfuscation might get us somewhere (esp. if we = are willing to burn either more octets or part of our existing space), but = let's try to focus on what we think we're going to achieve by doing= something here.
>
> Funny that TLS are concurrently talking about hiding the existence= of ESNI, which has so many of the same constraints: you have to standardiz= e the semantics so that it can be decoded, but you would rather that only t= he intended recipient was able to read it. In both cases, the answer is th= at you lose because you have no shared keys that would enable the only thin= g that we know works (crypto). (I haven't ingested Stephen's long = email there, maybe he has a brilliant idea for breaking the deadlock, but I= doubt that it will help us here, because at least with ESNI you *maybe* ha= ve a key and it seems to be using crypto.)


Martin, you seem uncharacteristically restrained today. How about, &quo= t;If
it is not encrypted, middle boxes will ossify, and pathetic efforts at
obfuscation are not going to save you?"

I get the point about grease, etc. But grease mostly works between
semi-consenting endpoints, such as QUIC peers who might have forgotten
to actually implement a part of the extension mechanisms. Greasing
Transport Parameter codes, for example. In the case of version numbers,
we have a quandary. We can only use a scheme that is standard enough
that many implementations understand what a particular version means.
But if it is standard enough, then the villains that design the
middle-boxes will know everything about it, and won't stop stroking
their furry white cats for even a second.

-- Christian Huitema


--00000000000035eb7f05828a4cd0-- From nobody Sat Feb 23 10:21:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB02130DE3 for ; Sat, 23 Feb 2019 10:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ap7SaR9K; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=8iwzbhp9 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 RvoYdbViWt3h for ; Sat, 23 Feb 2019 10:20:59 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18171286E7 for ; Sat, 23 Feb 2019 10:20:59 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id BA47832C3 for ; Sat, 23 Feb 2019 13:20:58 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sat, 23 Feb 2019 13:20:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=+j3mOqXffft1GR4Gb64PBmU3fHXrU4VkhWTHCZz asdw=; b=ap7SaR9Knu5DeGkuXIf/+lJ3q1PNPQ4UTIAW3+3a6kYpm1NO5BaS0KG J8+QUxJHEZL0WxwFJ7efqHalyFv/u5ILtKxhxkDgiLfxwy0pzDoKT+OYDbsl/nPA rjV4GSinKH5Ti0+ZWs0d5CoUODeYGwVZkKdwWGxcODa5YaRQTA33BS7X6DFI5zYa mmS2/IDNG8BaLQEu4GhbQk0yxRSHB487StaDbiVXYbcEMS1L0bs4LS/Nku+AcwnJ ooyo7Msxi01ZRwmV62joVSyIe/+EE1QUT01a9Skm+mQhutAaMbtZLWD8Sge9nzIf 3+tZui3RKeGUMaUBHf/0A0DuFBsBrMQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=+j3mOqXffft1GR4Gb 64PBmU3fHXrU4VkhWTHCZzasdw=; b=8iwzbhp9qTRgEraH7dhRVwLwoOR62j8Ey PyxjaVCii8MH9Ye4UlaziZ3sqQJvxZBa1auYFU0xJSGddg6FqCV5czZI+oGFIfLp 6wvQ44DpRY3i7jqqL90er45mIlBbxRXIZyjgzFq3psr/KY48Uqm2TxNPM/5kqzAF PE9jxACeqS7I9uPRfL/Gj/3rctbv0BZ5UJMIIe0aC7qIuixQy99Wa9cguEjSJOf6 WEczrRzgT6lJezX67q2yUr03iIEbjP9HywnQQ6S3oJZluJN4YFrhi04aYn0sefLz FLYlY4y6BkixD+OaGU7DNcbcS2dHR4eK/oqSBK6Xx4p0HxuX37kfw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddruddvgdduudefucdltddurdegtdelrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8E4BB7C1EB; Sat, 23 Feb 2019 13:20:57 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-895-g0d23ba6-fmstable-20190213v1 X-Me-Personality: 92534000 Message-Id: <31aec777-de1e-45d2-a27f-590c73bc71b9@www.fastmail.com> In-Reply-To: References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> <50fa8e3a-a997-4c09-ba38-b8cdcde3b27c@www.fastmail.com> Date: Sat, 23 Feb 2019 13:20:56 -0500 From: "Martin Thomson" To: quic@ietf.org Subject: Re: QUIC ossification Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 18:21:01 -0000 On Fri, Feb 22, 2019, at 19:03, Christian Huitema wrote: > > Martin, you seem uncharacteristically restrained today. How about, "If > it is not encrypted, middle boxes will ossify, and pathetic efforts at > obfuscation are not going to save you?" That is what I typed first... Maybe if we all agree on this point, we can move on. From nobody Sat Feb 23 15:37:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435951310DD for ; Sat, 23 Feb 2019 15:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW9IR-rKd-Hv for ; Sat, 23 Feb 2019 15:37:39 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDAD1310D9 for ; Sat, 23 Feb 2019 15:37:39 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id g12so4263092lfb.13 for ; Sat, 23 Feb 2019 15:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x8niXluOQ/t3hH6c5uwqXShVgvbj0husEfhewfEN89I=; b=idvQzNafpCkhDfx2KKY2BvJzl854ZZCKXsiW7tuO4P67JCg0hV7rFBj8oe6p3pNDpp R7vJ+A7yc3dq1+dM4Lt+tHPm9Y6Q03tO/cRBiC57CVuopIzsXCbJ8TKR0pb4shAu6bB9 4fGqWYzzr4sSpP4XOd0MyqarGU9a4eK2MZljlPH8cHc2EpRCuq6MDWjCR1T6UnzRLDma 52OOSm+HUvQdu2/ZsE4/lMeKw/Ys+yv1Gqu3rFC9d2cd3tr8GejYz5Zlg/OXAKQ2Y/AU v+ztmmUMQ+LCMCNyJHcpI5VX2wX7qq4XPTdFuRSxGntBuvogVQZnmWi24wlJE+PxbdOT rP7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x8niXluOQ/t3hH6c5uwqXShVgvbj0husEfhewfEN89I=; b=LZIblPn/tMZxtbqBi85xBuEKwnOmIQpZW1DhIpkHI+aZBUsBCpUuzdauyGtxd0ZVE+ ZiOwLESfuPFhikTlPHlzNL1UKkQbLBfKgnAV7hJPygcD+wvPy718hViZ20ISXgjebdes tJl3AuRxFEM4piKNIC3mRzvg2PhvvkBcQqk7g/CMgehi3XV6Bm/c7FVd77S7BdqGzwYw mQEBUqjHHglRzvDFT3lL5C0jb9PCeQV3E6ldBLuxIxe9tHzSF446/EgT0zfmx45JngL6 KgGXdrV+07xcJj5u/rgnm4YHyPPwlp4vd9qfXIiOAlYvho0Y08C4EMi7wYvgBxufwdtC 4DHw== X-Gm-Message-State: AHQUAua0NTGkXEfSQa/QLP4KQH91ps5nvulOcYwHmHhoDkvvINCrbEjC 1PqgwPeV92oM9wPfuYjCgCM/K7+3+Z0ozkZpQCKrvytK X-Google-Smtp-Source: AHgI3IZWtoMPp752/FWKHu3JorV0p68aU3fW7Y55BC60BC4l4lThshNLU8QH7fAI4GFWgDqu4tzisQcs+nCLDBmvJ7s= X-Received: by 2002:a19:5601:: with SMTP id k1mr4436742lfb.99.1550965056773; Sat, 23 Feb 2019 15:37:36 -0800 (PST) MIME-Version: 1.0 References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> <50fa8e3a-a997-4c09-ba38-b8cdcde3b27c@www.fastmail.com> <31aec777-de1e-45d2-a27f-590c73bc71b9@www.fastmail.com> In-Reply-To: <31aec777-de1e-45d2-a27f-590c73bc71b9@www.fastmail.com> From: Jana Iyengar Date: Sat, 23 Feb 2019 15:37:21 -0800 Message-ID: Subject: Re: QUIC ossification To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="00000000000044a52a058298311c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 23:37:41 -0000 --00000000000044a52a058298311c Content-Type: text/plain; charset="UTF-8" On Sat, Feb 23, 2019 at 10:21 AM Martin Thomson wrote: > > On Fri, Feb 22, 2019, at 19:03, Christian Huitema wrote: > > > > Martin, you seem uncharacteristically restrained today. How about, "If > > it is not encrypted, middle boxes will ossify, and pathetic efforts at > > obfuscation are not going to save you?" > > That is what I typed first... Maybe if we all agree on this point, we can > move on. > I've seen and worked through one ossification case with QUIC so far, I can say that making versions dynamic in any way would have helped us. This is after talking to the middlebox vendor, and understanding their process. I think I've made my case -- that there's value in making the on-the-wire version more dynamic. If there is a proposal to encrypt version number, I'm all ears. This conversation is premised on not having encryption to save us. Without a proposal that encrypts version numbers, it does not make sense to say that encryption is the only solution. It is counter-productive to argue that nothing should be done in any situation when encryption is not available as a solution. --00000000000044a52a058298311c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Feb 23, 2019 at 10:21 AM Martin T= homson <mt@lowentropy.net> w= rote:

On Fri, Feb 22, 2019, at 19:03, Christian Huitema wrote:
>
> Martin, you seem uncharacteristically restrained today. How about, &qu= ot;If
> it is not encrypted, middle boxes will ossify, and pathetic efforts at=
> obfuscation are not going to save you?"

That is what I typed first... Maybe if we all agree on this point,=C2=A0 we= can move on.

I've seen and worked = through one ossification case with QUIC so far, I can say that making versi= ons dynamic in any way would have helped us. This is after talking to the m= iddlebox vendor, and understanding their process.=C2=A0

I think I've made my case -- that there's value in making the= on-the-wire version more dynamic. If there is a proposal to encrypt versio= n number, I'm all ears. This conversation is premised on not having enc= ryption to save us. Without a proposal that encrypts version numbers, it do= es not make sense to say that encryption is the only solution.
It is counter-productive to argue that nothing should be done = in any situation when encryption is not available as a solution.
--00000000000044a52a058298311c-- From nobody Sat Feb 23 16:45:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF4112950A for ; Sat, 23 Feb 2019 16:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nhfhbCsa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FojmPfgH 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 0cblvglcxHhR for ; Sat, 23 Feb 2019 16:45:20 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE3B128701 for ; Sat, 23 Feb 2019 16:45:20 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id EB93A33EE for ; Sat, 23 Feb 2019 19:45:18 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 23 Feb 2019 19:45:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=IXT8o2txPpwantMyxUujGnUSToXpZup/FVUaiL9+pwA=; b=nhfhbCsa 17B3+b0sppktUJWz20s0CpzDOkOWeJqZDSXDCNf/z4nHiiPaMsbGNVHzfIY8Y2nN 8l8EAUjxBBcwbFgQzw6/s+JLZG0m6VMs+33fhOzYaz74mn55zXZ8gG9FTjQHZH5V 3EnyVF8LAXE0r37P3gAdE7SSrdGLR8s7xrZbbB1Zmh0x86TutsFhBn/X442pGTWv N51eKl9CEQ8/EIWCGB+Eg2ojzc+c04PRQIn+oizFZFFPIwrt2avdM8fZFlnVFSYs O2C5BaNcgrRhxIDCYkGWE+aQ6AYee9gCkuudWOelpjUheqmnaHMBD0f1OPWJuZ9L qIhay+zH1vOhZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=IXT8o2txPpwantMyxUujGnUSToXpZ up/FVUaiL9+pwA=; b=FojmPfgHwQkl5kZBuFQ7zkVAImWrhr/xMKvLV1l3m1eLU qpZ64Y2J5Qt5SJ5cB/VUmSvksXYPKbPvqBPi5A76U5My5mOChONymoed72uNtEdh PiCAQl7QlWgLSHUZaVj3QK05SYvenWWhuMnfEFT+BEByie9uZgDQvSm9mZTeuvXk 6bJ+GftMs/3WFoB5VN3s8gkDfK3mq/9tgg2n443BGj8c8s8tIwB2rWYGifJKSDoh 7+k++6Ncr+58Ba30zwrORC0GlvK6YS3ETUaMQmPixQr5sQk236FvXs08MmBG77RN Swubqjapqvb8lg1G+tuJD82sEOx3QclUwg7lJELrA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrudefgddvtdculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusggppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeduudelrdelrdegfedrvdegudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 3EDF7E4385 for ; Sat, 23 Feb 2019 19:45:16 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id ED72BC0975 for ; Sun, 24 Feb 2019 00:45:12 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============4040592996691109197==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190224004512.ED72BC0975@cloud.mnot.net> Date: Sun, 24 Feb 2019 00:45:12 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 00:45:25 -0000 --===============4040592996691109197== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+3/-4/=F0=9F=92=AC28) 3 issues created: - Specify what occurs when the maximum Stream Id exceeds 2^62 - 1 in MAX_= STREAMS (by ianswett) https://github.com/quicwg/base-drafts/issues/2487 [-transport] [design] = - DetectLostPackets needs to be per packet number space (by janaiyengar) https://github.com/quicwg/base-drafts/issues/2484 [-recovery] [design] = - Definition of Stream Final Size is ambiguous (by dtikhonov) https://github.com/quicwg/base-drafts/issues/2481 = 13 issues received 28 new comments: - #2473 Connection ID Length changes (5 by DavidSchinazi, martinthomson, = kazuho, martinduke) https://github.com/quicwg/base-drafts/issues/2473 [-transport] [design] = - #2477 CID's should be compared in constant time (4 by martinthomson, ia= nswett, janaiyengar, mikkelfj) https://github.com/quicwg/base-drafts/issues/2477 [-transport] = - #2400 VN packets may be dropped more often when the QUIC bit is 0 (3 by= kazuho, janaiyengar) https://github.com/quicwg/base-drafts/issues/2400 [-transport] [design] = - #2407 Can VN and Retry packets be coalesced? (3 by mnot, kazuho, janaiy= engar) https://github.com/quicwg/base-drafts/issues/2407 [-transport] = - #2487 Specify what occurs when the maximum Stream Id exceeds 2^62 - 1 i= n MAX_STREAMS (3 by marten-seemann, janaiyengar, mikkelfj) https://github.com/quicwg/base-drafts/issues/2487 [-transport] [design] = - #2435 loss recovery of crypto packets is less aggressive, not more aggr= essive (2 by marten-seemann, ianswett) https://github.com/quicwg/base-drafts/issues/2435 [-recovery] [design] = - #2475 Invalid CONNECTION_CLOSE frames (2 by ronieven, martinthomson) https://github.com/quicwg/base-drafts/issues/2475 [-transport] [editori= al] = - #2049 minimum payload size requirement creates awkward special case (1 = by marten-seemann) https://github.com/quicwg/base-drafts/issues/2049 [-transport] [editori= al] = - #2436 rate-limiting of CID issuance needs to be allowed (1 by janaiyeng= ar) https://github.com/quicwg/base-drafts/issues/2436 [-transport] [design] = - #2472 PTO calculation (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2472 [-recovery] [design] = - #2464 Remember Fewer Transport Parameters for 0-RTT (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2464 [-transport] [design] = - #2484 DetectLostPackets needs to be per packet number space (1 by marte= n-seemann) https://github.com/quicwg/base-drafts/issues/2484 [-recovery] [design] = - #2413 Mandate using a new connection ID on migration (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2413 [-transport] [design] = 4 issues closed: - minimum payload size requirement creates awkward special case https://g= ithub.com/quicwg/base-drafts/issues/2049 [-transport] [editorial] = - DetectLostPackets needs to be per packet number space https://github.co= m/quicwg/base-drafts/issues/2484 [-recovery] [design] = - loss recovery of crypto packets is less aggressive, not more aggressive= https://github.com/quicwg/base-drafts/issues/2435 [-recovery] [design] = - PTO calculation https://github.com/quicwg/base-drafts/issues/2472 [-rec= overy] [design] = Pull requests ------------- * quicwg/base-drafts (+7/-9/=F0=9F=92=AC16) 7 pull requests submitted: - Don't close the connection if MAX_STREAMS is too large (by ianswett) https://github.com/quicwg/base-drafts/pull/2486 [-transport] [design] = - add the pn_space index for largest_acked_packet (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2485 = - Clarify what to do when ALPN negotiation fails (by ghedo) https://github.com/quicwg/base-drafts/pull/2483 = - Add #2302 to the list of items changed since ID-17 (by dtikhonov) https://github.com/quicwg/base-drafts/pull/2482 = - Fix PTO computation (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2480 = - Introduce a "late-stage" process (by mnot) https://github.com/quicwg/base-drafts/pull/2479 = - fix incorrect field name (by kazuho) https://github.com/quicwg/base-drafts/pull/2478 = 8 pull requests received 16 new comments: - #2414 New connection IDs are mandatory for intentional migration (7 by= larseggert, janaiyengar, martinthomson, mnot) https://github.com/quicwg/base-drafts/pull/2414 [-transport] [design] = - #1998 introduce a max_connection_ids transport parameter (3 by kazuho, = marten-seemann, janaiyengar) https://github.com/quicwg/base-drafts/pull/1998 [-transport] [design] = - #2454 Change Idle Timeout to Milliseconds (1 by mnot) https://github.com/quicwg/base-drafts/pull/2454 [-transport] [design] [= has-consensus] = - #2406 Close connection if peer becomes unreachable (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2406 [-transport] [editorial= ] = - #2483 Clarify what to do when ALPN negotiation fails (1 by ghedo) https://github.com/quicwg/base-drafts/pull/2483 = - #2485 add the pn_space index for largest_acked_packet (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2485 = - #2476 Packetization Nits (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2476 = - #2365 Persistent Congestion Time Threshold (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2365 [-recovery] [design] = 9 pull requests merged: - Introduce a "late-stage" process https://github.com/quicwg/base-drafts/pull/2479 = - add the pn_space index for largest_acked_packet https://github.com/quicwg/base-drafts/pull/2485 = - Add a loss_time per packet number space https://github.com/quicwg/base-drafts/pull/2451 [-recovery] [design] = - the crypto timeout is based on the last crypto packet sent https://github.com/quicwg/base-drafts/pull/2456 [-recovery] [editorial] = - Fix PTO computation https://github.com/quicwg/base-drafts/pull/2480 = - Add #2302 to the list of items changed since ID-17 https://github.com/quicwg/base-drafts/pull/2482 = - fix incorrect field name https://github.com/quicwg/base-drafts/pull/2478 [-transport] [editorial= ] = - Packetization Nits https://github.com/quicwg/base-drafts/pull/2476 = - Eliminate duplicate word https://github.com/quicwg/base-drafts/pull/2474 [-transport] [editorial= ] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============4040592996691109197== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday February 24, 2019

Issues

quicwg/base-drafts (+3/-4/=F0=9F=92=AC28)

3 issues created:

13 issues received 28 new comments:

4 issues closed:

Pull requests

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

7 pull requests submitted:

8 pull requests received 16 new comments:

9 pull requests merged:

Repositories tracked by this digest:

--===============4040592996691109197==-- From nobody Sat Feb 23 17:27:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B94F128701 for ; Sat, 23 Feb 2019 17:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZnV3yGZ_TrV for ; Sat, 23 Feb 2019 17:27:13 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 36086126C7E for ; Sat, 23 Feb 2019 17:27:13 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id q12so4402287lfm.0 for ; Sat, 23 Feb 2019 17:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rS5paxoqvR/P65lR+66ZecyVyxslpSK8BHVho30M9W0=; b=El7EueNSqsr3MzqEO52YufthQNSQsw44KN6v4mIqyabj4YLp2TvTOJPTTfinFCWZD6 V9d9PKsyjC4feZT5z7aXlL1IitViSciwqikvy0j9l7d9jSh1vlJAVkMP5fTaDuOz9RAV n8Gyhv7t/oNuXnwmx7FlJQTrBtNwGMQgQPm0dyhbHYmpW5f7CiOC4pCs9dq5DXbf7LD+ 9Du0raESI0le6DNXiQw0Y8+1qNwda9dywe2A9iIen8AhcDAG+KIAqNxYq/FDd/cfL+1m i+an7JzmHQAw/9DwEfMYMDmAtqIxtlwfGVp3LNG/rVK8MHL5T5JP9OVOg7TLH55N9c7s xNWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rS5paxoqvR/P65lR+66ZecyVyxslpSK8BHVho30M9W0=; b=YT+Jk/jmsYFcq8komev3YrKL7cKeT9islVcx3ell+jeq+8w11mjjmP/mRmVbptnyKc zYUO8rBTLWhVTV8BtTJP1C40faaWjdCVKBzklzbks8W+4IMPGy2gYiwj9A+Tj/1RIeUk 9HMt4Bu5t/8MfTok61/BHDrswL0OhpM03OG9QSoMaFRwYHAnlzvVQIPxAdwKiXJtFaMa gOfBP1dTrnpB85Y86ToFWFdSkP4u3K/VSOTACBEnzRUqA2vRCSbakWLCbZ8s8enVeuS5 2zbgmOavyt0h29Lrby8TRQB8XSMmgBHqpBKqB1EAoFunKSXrdbVHJOdEmCRvybJJSxx5 CnWg== X-Gm-Message-State: AHQUAuZczDuexVNj3TTnOR6rrxUMv99iqQb79mzCB4CBttCcTi0QY80+ OU27STUr0ShhWvK5BGlfBrCqkgaKmUQ4zr5r4y8= X-Google-Smtp-Source: AHgI3IagmJkvbYGaFiOgLNL7z4KIzWzVw5Na+rkPzrNOtalzvtSgOuIEzEy6YW/wJVLnxSbtQNJZCRUqZ+llkeSR8aQ= X-Received: by 2002:ac2:4317:: with SMTP id l23mr5170550lfh.98.1550971631263; Sat, 23 Feb 2019 17:27:11 -0800 (PST) MIME-Version: 1.0 References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> <50fa8e3a-a997-4c09-ba38-b8cdcde3b27c@www.fastmail.com> <31aec777-de1e-45d2-a27f-590c73bc71b9@www.fastmail.com> In-Reply-To: From: Kazuho Oku Date: Sun, 24 Feb 2019 10:26:59 +0900 Message-ID: Subject: Re: QUIC ossification To: Jana Iyengar Cc: Martin Thomson , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 01:27:15 -0000 2019=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=97=A5) 8:37 Jana Iyengar : > > On Sat, Feb 23, 2019 at 10:21 AM Martin Thomson wrote= : >> >> >> On Fri, Feb 22, 2019, at 19:03, Christian Huitema wrote: >> > >> > Martin, you seem uncharacteristically restrained today. How about, "If >> > it is not encrypted, middle boxes will ossify, and pathetic efforts at >> > obfuscation are not going to save you?" >> >> That is what I typed first... Maybe if we all agree on this point, we c= an move on. > > > I've seen and worked through one ossification case with QUIC so far, I ca= n say that making versions dynamic in any way would have helped us. This is= after talking to the middlebox vendor, and understanding their process. > > I think I've made my case -- that there's value in making the on-the-wire= version more dynamic. If there is a proposal to encrypt version number, I'= m all ears. This conversation is premised on not having encryption to save = us. Without a proposal that encrypts version numbers, it does not make sens= e to say that encryption is the only solution. > > It is counter-productive to argue that nothing should be done in any situ= ation when encryption is not available as a solution. Yeah. And IIUC encryption cannot be a solution for QUIC v1. To be precise, encryption can be a solution for QUIC v1 only when we can assume that ESNI (or something other that allows the endpoints to negotiate shared knowledge) gets deployed along with QUIC v1 by a significant portion of the endpoints. I'd be very happy to see that happen, but I am skeptical if it would. --=20 Kazuho Oku From nobody Mon Feb 25 10:27:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68216130EFE for ; Mon, 25 Feb 2019 10:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=fb.com header.b=aqMPnMet; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=IkNLArhr 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 3sQI9glqVmOt for ; Mon, 25 Feb 2019 10:27:12 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7ED126D00 for ; Mon, 25 Feb 2019 10:27:12 -0800 (PST) Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1PINhNf002589; Mon, 25 Feb 2019 10:27:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=+H72CdxqpKAindAggT6swNgFQIqIEc+XdE2SOglto/8=; b=aqMPnMetn+veceXFvRVa/9z20WK3K6hr4evWV6msk6XWl7cUwbh0/UlRiGgGojiiu0J7 NmfK1DnN9SzMO1lP/zS5UI1hYJbS5seRXaExNkrvybCWSAy3ReiX/r/15sKVSzTL3AmA /yZQCXVkoayLwd4XUdr00zZX35S25OYd96E= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qvmndg7x1-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Feb 2019 10:27:10 -0800 Received: from frc-mbx06.TheFacebook.com (2620:10d:c0a1:f82::30) by frc-hub05.TheFacebook.com (2620:10d:c021:18::175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Mon, 25 Feb 2019 10:27:03 -0800 Received: from frc-hub02.TheFacebook.com (2620:10d:c021:18::172) by frc-mbx06.TheFacebook.com (2620:10d:c0a1:f82::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Mon, 25 Feb 2019 10:27:03 -0800 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Mon, 25 Feb 2019 10:27:03 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+H72CdxqpKAindAggT6swNgFQIqIEc+XdE2SOglto/8=; b=IkNLArhrF6J1RX14lquY1GEIG6yIaeFNbg5HrvROV4hD0BtOEnqFBMr7wcw4Vaz5hE48ZxUpeA9rOjC3VB/pnXUhYcUOsNS5NwScBBk1D+ns6+7ASqII2+3FEolp1QeR/6+bbU9J+yLDuPLkoMU0Z0aGUG3D7e3YZr2OBwSup20= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2757.namprd15.prod.outlook.com (20.179.157.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Mon, 25 Feb 2019 18:27:02 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::9d7b:c4a4:e46c:ab71]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::9d7b:c4a4:e46c:ab71%7]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 18:27:02 +0000 From: Roberto Peon To: Kazuho Oku , Jana Iyengar CC: QUIC WG , Martin Thomson Subject: Re: QUIC ossification Thread-Topic: QUIC ossification Thread-Index: AQHUwxih7UYarYoV30WBSlEhJDleK6Xcr5EA//+EwACAAKdJAP//fAuAgAGRSoCAAArqgIAABPsAgAAA14CAAAMfgIAACY0A//+6QoAAEcIhgAAHiM6AAAFCw4AAAtg4AAAAMeuAAABRNgAAAVt/AAAAuC4AAAHDNQAAHrd+gAAAHQ4AAABwzoAACKm9AAAAEgiAAAAr9QAAACHTgAAATyAAAALUMwAAywJVgAAZs5wAAA9NEYD//3slgIAAhuyAgACA9oCAAAFdAIAC+AOAgAAbZQCAAH6vgIAAn6IAgABCDoCAAQBqAIAAWGiAgAAeooCAAik1AA== Date: Mon, 25 Feb 2019 18:27:01 +0000 Message-ID: References: <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> <50fa8e3a-a997-4c09-ba38-b8cdcde3b27c@www.fastmail.com> <31aec777-de1e-45d2-a27f-590c73bc71b9@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [2620:10d:c090:200::6:a040] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07cfeae7-52f8-4b9e-bb61-08d69b4ed61d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2757; x-ms-traffictypediagnostic: BYAPR15MB2757: x-microsoft-exchange-diagnostics: 1; BYAPR15MB2757; 20:hCsST2OAfrC5Y87pT7WF19hMPRWRcRNozBVGqIUSecuaw2ZIU+ToIbSW0R/1DWC2mEpxE/SlhMu0TKsJXRfDhCNJ9wxgHyGfZ0F0V5C0boi9nlvG7xIUs7m7KJXWUKX7mHXnbQV75YhayvKrL8uajF7awdRcv3c5gtIhHz+5F80= x-microsoft-antispam-prvs: x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(39860400002)(136003)(376002)(366004)(346002)(199004)(189003)(561944003)(33656002)(11346002)(446003)(14454004)(476003)(2616005)(2906002)(486006)(25786009)(46003)(478600001)(4326008)(6116002)(6486002)(6436002)(6246003)(256004)(6512007)(53936002)(76176011)(102836004)(316002)(186003)(58126008)(110136005)(53546011)(6506007)(82746002)(99286004)(54906003)(97736004)(221733001)(81156014)(71190400001)(71200400001)(68736007)(83716004)(105586002)(93886005)(7116003)(106356001)(305945005)(7736002)(86362001)(5660300002)(229853002)(8936002)(3480700005)(81166006)(36756003)(8676002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2757; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lLMXpk1dA1ION6Ge8cyLSRhU0TOo9GDh9jsBY82vE++p7ILJ46gYkA7tzK9wu72RtJytG9v267cyB80OiKBPckK+2LASKiPiPvsUNRuZ5LoZQGvl4VI6RiPD/XgEXpdIbSpwmAqGEbAzBfbfiQuV00N4Qa7tvBTV9pQfr4n7iLj1f0vD04wgZ6EYXJaERsquUUr+fSJRh1li1k30txThyF56n7c42BaosE7q0ZuMDvDGmfjWlCE4nPphOUmLzp/dhidT0KL5YfUI5b1RnYi5M7dp0zFclP9FISTrMxgF3UJRPV+rzkCwtc1bybE4SUULgqlAHtTmHkiGGMx079va7czjvWdCwLe7dezOHrm49pV/wXK6l4f/coXSKGfp9xvjERe4VfxQMLuWff1nztbf4h1npsOLz+x8i3FqqjV3b8U= Content-Type: text/plain; charset="utf-8" Content-ID: <30FF9EA6FD6A2648A91F2FF0CE365207@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 07cfeae7-52f8-4b9e-bb61-08d69b4ed61d X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 18:27:01.9969 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2757 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-25_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 18:27:14 -0000 WW91J2QgY2VydGFpbmx5IGdldCBhZ3JlZW1lbnQgdGhhdCB0aGUgb25seSB3YXkgdG8gcHJldmVu dCB0aGluZ3MgZnJvbSByZWFjdGluZy9yZWNvZ25pemluZyB0byBzb21ldGhpbmcgaXMgdG8gbWFr ZSBpdCB1bnJlY29nbml6YWJsZSBhcyB0aGF0IHNvbWV0aGluZy4NCg0KU28sIGluIHRoZSBsb25n LXRlcm0gd2Ugd2FudCBzb21lIGNvbWJpbmF0aW9uIG9mIGVuY3J5cHRpb24gKGJ5dGVzIHVucmVj b2duaXphYmxlKSBhbmQgcGF0dGVybi90aW1pbmcgb2JmdXNjYXRpb24uIEknbSBzdXJlIHdlJ2Qg YWxsIGJlIGhhcHB5IGlmIHdlIGNvdWxkIGhhdmUgdGhpcyB0b21vcnJvdyBhbmQgdGh1cyBhcHBs eSB0byBWMSwgYnV0IGl0IHNlZW1zIHVubGlrZWx5Lg0KDQpJZiB0aGF0IGlzIHRydWUsIHRoZW4g Zm9yIFYxIHRoZSBxdWVzdGlvbiBpcyB3aGF0IHBvdGVudGlhbGx5IGltcGVyZmVjdCB0aGluZyBj b3VsZCB3ZSBkbyB0aGF0IGdpdmVzIHVzIHRoZSBicmVhdGhpbmcgcm9vbSB0byBnZXQgdG8gVjIs IHdoaWNoIGNvdWxkL3Nob3VsZCBoYXZlIHRoZSBtb3JlIHBlcmZlY3QgYW5kIG1vcmUgcm9idXN0 IChsaWtlbHkgZW5jcnlwdGlvbi1iYXNlZCkgc29sdXRpb24/DQoNClRoZSBhbnN3ZXIgdG8gdGhh dCBkZXBlbmRzIG9uIG91ciBzaGFyZWQgdW5kZXJzdGFuZGluZyBvZiB0aGUgdGhyZWF0IG1vZGVs Lg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgd2UncmUgd29ycmllZCBhYm91dCBhY2NpZGVu dGFsIHBhdHRlcm4tbWF0Y2hpbmcgYmFzZWQgInRocmVhdHMiLS0gaS5lLiBwcm90ZWN0aW5nIGFn YWluc3QgYXNzdW1wdGlvbnMgdGhhdCBhIHBhcnRpY3VsYXIgcmFuZ2Ugb2YgYml0cyBpbiBhIHBh cnRpY3VsYXIgcGxhY2UgaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIFFVSUMuDQoNCi09Ug0KDQrv u79PbiAyLzIzLzE5LCA1OjI3IFBNLCAiUVVJQyBvbiBiZWhhbGYgb2YgS2F6dWhvIE9rdSIgPHF1 aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga2F6dWhvb2t1QGdtYWlsLmNvbT4gd3Jv dGU6DQoNCiAgICAyMDE55bm0MuaciDI05pelKOaXpSkgODozNyBKYW5hIEl5ZW5nYXIgPGpyaS5p ZXRmQGdtYWlsLmNvbT46DQogICAgPg0KICAgID4gT24gU2F0LCBGZWIgMjMsIDIwMTkgYXQgMTA6 MjEgQU0gTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PiB3cm90ZToNCiAgICA+Pg0K ICAgID4+DQogICAgPj4gT24gRnJpLCBGZWIgMjIsIDIwMTksIGF0IDE5OjAzLCBDaHJpc3RpYW4g SHVpdGVtYSB3cm90ZToNCiAgICA+PiA+DQogICAgPj4gPiBNYXJ0aW4sIHlvdSBzZWVtIHVuY2hh cmFjdGVyaXN0aWNhbGx5IHJlc3RyYWluZWQgdG9kYXkuIEhvdyBhYm91dCwgIklmDQogICAgPj4g PiBpdCBpcyBub3QgZW5jcnlwdGVkLCBtaWRkbGUgYm94ZXMgd2lsbCBvc3NpZnksIGFuZCBwYXRo ZXRpYyBlZmZvcnRzIGF0DQogICAgPj4gPiBvYmZ1c2NhdGlvbiBhcmUgbm90IGdvaW5nIHRvIHNh dmUgeW91PyINCiAgICA+Pg0KICAgID4+IFRoYXQgaXMgd2hhdCBJIHR5cGVkIGZpcnN0Li4uIE1h eWJlIGlmIHdlIGFsbCBhZ3JlZSBvbiB0aGlzIHBvaW50LCAgd2UgY2FuIG1vdmUgb24uDQogICAg Pg0KICAgID4NCiAgICA+IEkndmUgc2VlbiBhbmQgd29ya2VkIHRocm91Z2ggb25lIG9zc2lmaWNh dGlvbiBjYXNlIHdpdGggUVVJQyBzbyBmYXIsIEkgY2FuIHNheSB0aGF0IG1ha2luZyB2ZXJzaW9u cyBkeW5hbWljIGluIGFueSB3YXkgd291bGQgaGF2ZSBoZWxwZWQgdXMuIFRoaXMgaXMgYWZ0ZXIg dGFsa2luZyB0byB0aGUgbWlkZGxlYm94IHZlbmRvciwgYW5kIHVuZGVyc3RhbmRpbmcgdGhlaXIg cHJvY2Vzcy4NCiAgICA+DQogICAgPiBJIHRoaW5rIEkndmUgbWFkZSBteSBjYXNlIC0tIHRoYXQg dGhlcmUncyB2YWx1ZSBpbiBtYWtpbmcgdGhlIG9uLXRoZS13aXJlIHZlcnNpb24gbW9yZSBkeW5h bWljLiBJZiB0aGVyZSBpcyBhIHByb3Bvc2FsIHRvIGVuY3J5cHQgdmVyc2lvbiBudW1iZXIsIEkn bSBhbGwgZWFycy4gVGhpcyBjb252ZXJzYXRpb24gaXMgcHJlbWlzZWQgb24gbm90IGhhdmluZyBl bmNyeXB0aW9uIHRvIHNhdmUgdXMuIFdpdGhvdXQgYSBwcm9wb3NhbCB0aGF0IGVuY3J5cHRzIHZl cnNpb24gbnVtYmVycywgaXQgZG9lcyBub3QgbWFrZSBzZW5zZSB0byBzYXkgdGhhdCBlbmNyeXB0 aW9uIGlzIHRoZSBvbmx5IHNvbHV0aW9uLg0KICAgID4NCiAgICA+IEl0IGlzIGNvdW50ZXItcHJv ZHVjdGl2ZSB0byBhcmd1ZSB0aGF0IG5vdGhpbmcgc2hvdWxkIGJlIGRvbmUgaW4gYW55IHNpdHVh dGlvbiB3aGVuIGVuY3J5cHRpb24gaXMgbm90IGF2YWlsYWJsZSBhcyBhIHNvbHV0aW9uLg0KICAg IA0KICAgIFllYWguIEFuZCBJSVVDIGVuY3J5cHRpb24gY2Fubm90IGJlIGEgc29sdXRpb24gZm9y IFFVSUMgdjEuDQogICAgDQogICAgVG8gYmUgcHJlY2lzZSwgZW5jcnlwdGlvbiBjYW4gYmUgYSBz b2x1dGlvbiBmb3IgUVVJQyB2MSBvbmx5IHdoZW4gd2UNCiAgICBjYW4gYXNzdW1lIHRoYXQgRVNO SSAob3Igc29tZXRoaW5nIG90aGVyIHRoYXQgYWxsb3dzIHRoZSBlbmRwb2ludHMgdG8NCiAgICBu ZWdvdGlhdGUgc2hhcmVkIGtub3dsZWRnZSkgZ2V0cyBkZXBsb3llZCBhbG9uZyB3aXRoIFFVSUMg djEgYnkgYQ0KICAgIHNpZ25pZmljYW50IHBvcnRpb24gb2YgdGhlIGVuZHBvaW50cy4NCiAgICAN CiAgICBJJ2QgYmUgdmVyeSBoYXBweSB0byBzZWUgdGhhdCBoYXBwZW4sIGJ1dCBJIGFtIHNrZXB0 aWNhbCBpZiBpdCB3b3VsZC4NCiAgICANCiAgICAtLSANCiAgICBLYXp1aG8gT2t1DQogICAgDQog ICAgDQoNCg== From nobody Wed Feb 27 05:44:29 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B6D130EC5 for ; Wed, 27 Feb 2019 05:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 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, FROM_EXCESS_BASE64=0.979, HTML_IMAGE_ONLY_04=1.172, HTML_IMAGE_RATIO_02=0.437, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 YPhvhtJr9PNT for ; Wed, 27 Feb 2019 05:44:27 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 69BA9124C04 for ; Wed, 27 Feb 2019 05:44:26 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id z124so9895268itc.2 for ; Wed, 27 Feb 2019 05:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BqTRe3mkguJ3aJtv6K1Tq6naJMWqBQ1DCU5NLI1/D0c=; b=SzvsJRxoND9nLoA5O0jEQLUkLZ3CwVzkUVfkjq4E6lccO0FbfL1cj/sK0BFTzb7Ok1 RY38FLrwnRBIeDwd1xibBdE3HJafrTtk9ncUIcPR6RaV4oBIy8pH/84CAzJ/3zUnnq4L mdnXkSiuSEaso7waGsdwo03wzzAtq39osJIOFmUdZ/sowjdnnxe4AJ8QLDbtB3dEecXQ OLPrzjoCMqMyhky8Udx5Z+EYYD1HoR0U01TFtl4GvdFeHa0kKz7O0CktP6FLxKdPUH9W U4vT+5qcglTJmcL3HQKCjEipkjb7IvdralHDXQXOoj560rU/BVAM+Y/0HRMJue+MvYT2 YaMQ== 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=BqTRe3mkguJ3aJtv6K1Tq6naJMWqBQ1DCU5NLI1/D0c=; b=cySbISch3BnekqXApe9BMYH8jHjDHENWWmVDUtoKzfTYhzX2WgmnQFR2eSqZ+LkrdQ M6y+BkGLrge50dbrY98tF/vXzf0qyRukT9ZE11mXIHbxgHkeKehT2MSVsJwZMKNmYe9Q PUTNFWVFu8eLvnjgSEBZvHQMWY6cOqRETMsL1m8DCytojkQ1eAYgNzE7N3WmMIUZlb/R iHZlRNbwNhQPS+ct8SM5ILUKquWaSzXf2AuEEX+GiEtR2koKrHinQ/jmf3P4QmmxQaxu dFqizJHJAeOeL4pCksk6eAOWisgypfhLsPPipDe7+KilL6el0MjReh7d3V/z/5OR/LZc N1GA== X-Gm-Message-State: APjAAAVcmsvb9QsmuKw+Ze5zgOFpOadaxEIYXOHSZxyxYBD46Fa5PyFj e0Lr15J8ih7AVmgOGwplIqoScdA3P4nbZ/1P/aAbRHV/bHE= X-Google-Smtp-Source: APXvYqwm+5k+IsynUO1kF4gFscPmtEB/XWU6ZWa3C0bDCydcsUE3Jwzja4POq593rxqpTM35n+OkOMO5GRiUea/yMFA= X-Received: by 2002:a24:4202:: with SMTP id i2mr1339124itb.85.1551275063090; Wed, 27 Feb 2019 05:44:23 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?5YiY5b2m5qKF?= Date: Wed, 27 Feb 2019 21:44:12 +0800 Message-ID: Subject: QUIC Example 0-RTT Handshake To: quic@ietf.org Content-Type: multipart/related; boundary="00000000000015c61c0582e05f74" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 13:44:28 -0000 --00000000000015c61c0582e05f74 Content-Type: multipart/alternative; boundary="00000000000015c61a0582e05f73" --00000000000015c61a0582e05f73 Content-Type: text/plain; charset="UTF-8" In draft-ietf-quic-transport-18, section 7.1. Example Handshake Flows [image: image.png] Should this 1-RTT packet number be [1] ? Because the previous client 0-RTT packet number is 0. --00000000000015c61a0582e05f73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In=C2=A0draft-ietf-quic-transport-18= ,=C2=A0
section=C2=A07.1. Examp= le Handshake Flows
=3D"image.png"
Should thi= s 1-RTT packet number be [1] ?=C2=A0
Because the previous client = 0-RTT packet number is 0.
--00000000000015c61a0582e05f73-- --00000000000015c61c0582e05f74 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jsn8sxj30 iVBORw0KGgoAAAANSUhEUgAABXgAAAKUCAYAAAC+KlBAAAAgAElEQVR4AezdCbxV4/7H8SfJnKmJ BhLqikLGW3LToJIkqUuKlIzVxeUiQzdDZrlEpm6IUKgkpIGkookS0oDmQiPNw/6/vut6nv+z91l7 n73P2eecvU+f5/U6d6/hWc961nutvdx++1m/VSISiUQMBQEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ QCDrBPbIuh7TYQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAIFAgAAvFwICCCCAAAIIIIAAAggggAAC CCCAAAIIIJClAgR4s/TE0W0EEEAAAQQQQAABBBBAAAEEEEAAAQQQQIAAL9cAAggggAACCCCAAAII IIAAAggggAACCCCQpQIEeLP0xNFtBBBAAAEEEEAAAQQQQAABBBBAAAEEEECAAC/XAAIIIIAAAggg gAACCCCAAAIIIIAAAgggkKUCBHiz9MTRbQQQQAABBBBAAAEEEEAAAQQQQAABBBBAgAAv1wACCCCA AAIIIIAAAggggAACCCCAAAIIIJClAgR4s/TE0W0EEEAAAQQQQAABBBBAAAEEEEAAAQQQQIAAL9cA AggggAACCCCAAAIIIIAAAggggAACCCCQpQIEeLP0xNFtBBBAAAEEEEAAAQQQQAABBBBAAAEEEECA AC/XAAIIIIAAAggggAACCCCAAAIIIIAAAgggkKUCBHiz9MTRbQQQQAABBBBAAAEEEEAAAQQQQAAB BBBAgAAv1wACCCCAAAIIIIAAAggggAACCCCAAAIIIJClAgR4s/TE0W0EEEAAAQQQQAABBBBAAAEE EEAAAQQQQIAAL9cAAggggAACCCCAAAIIIIAAAggggAACCCCQpQIEeLP0xNFtBBBAAAEEEEAAAQQQ QAABBBBAAAEEEECAAC/XAAIIIIAAAggggAACCCCAAAIIIIAAAgggkKUCBHiz9MTRbQQQQAABBBBA AAEEEEAAAQQQQAABBBBAgAAv1wACCCCAAAIIIIAAAggggAACCCCAAAIIIJClAgR4s/TE0W0EEEAA AQQQQAABBBBAAAEEEEAAAQQQQIAAL9cAAggggAACCCCAAAIIIIAAAggggAACCCCQpQIEeLP0xNFt BBBAAAEEEEAAAQQQQAABBBBAAAEEEECAAC/XAAIIIIAAAggggAACCCCAAAIIIIAAAgggkKUCBHiz 9MTRbQQQQAABBBBAAAEEEEAAAQQQQAABBBBAgAAv1wACCCCAAAIIIIAAAggggAACCCCAAAIIIJCl AgR4s/TE0W0EEEAAAQQQQAABBBBAAAEEEEAAAQQQQIAAL9cAAggggAACCCCAAAIIIIAAAggggAAC CCCQpQIEeLP0xNFtBBBAAAEEEEAAAQQQQAABBBBAAAEEEECAAC/XAAIIIIAAAggggAACCCCAAAII IIAAAgggkKUCBHiz9MTRbQQQQAABBBBAAAEEEEAAAQQQQAABBBBAgAAv1wACCCCAAAIIIIAAAggg gAACCCCAAAIIIJClAgR4s/TE0W0EEEAAAQQQQAABBBBAAAEEEEAAAQQQQIAAL9cAAggggAACCCCA AAIIIIAAAggggAACCCCQpQIEeAvpxG3bts188803Zt26dYW0R3aDAAIIIIAAAggggAACCCCAAAII IIAAAsVdYM/ifoDJHt/atWuN/mLL/vvvbypUqBC7OKX5+fPnm1NOOcX8/vvvpnTp0mbZsmXBZ0qN UBkBBBBAAAEEEEAAAQQQQAABBBBAAAEEEIgRIMBrjHnvvfdMq1atYmj+f3bWrFmmdu3a/78gxanZ s2cHwV1tpiDvzz//bGrVqpViK1RHAAEEEEAAAQQQQAABBBBAAAEEEEAAAQSiBYpFgFdpD5T+4Ouv vw7+9txzT3PkkUeak08+2Zxzzjlm4cKFZtKkSaZhw4bmmGOOiRYwxqxcuTLHMn/Bhg0b/Nl8T+/a tSvfbWRSA3PmzDFDhgwxzZo1M3Xr1s2krtEXBBBAAAEEEEAAAQQQQAABBIqtgGIdU6dONfPmzTOL Fi0KnkCuXr168O/znTt3msGDBwcD1jp16lRsDTgwBBAwpkQkEolkK8TWrVvN3XffbR599NG4h6CU CBo1q9K+fXvz+uuv56j7xx9/mOHDh5tVq1YZtany0UcfmYkTJwbT+jzrrLNybJfsghkzZphTTz3V Vdd+ypcv7+azfeK8884zH374YXBMOjYKAggggAACCCCAAAIIIIAAAggUnIAGud12223Bv8WT2cvm zZvNPvvsk0xV6iCAQBYKZO0IXuW1veSSS8zMmTMTstvgrirp16ywcsABB5gOHTpErSpRooQL8Eat yMNMnTp1zPTp04Mcv0rNUJyCu+KwQd1ffvklDzpsggACCCCAAAIIIIAAAggggAACyQpMmzbNnH76 6VHVNbjt8MMPD0byRq34c2b16tWmUqVKYatYhgACxUBgj2w8hqVLlxo9cuAHd1966SWzYMECo/QH v/76a5AyQCkZMqEoWKyXrDVu3DjfL2zLhOOhDwgggAACCCCAAAIIIIAAAgggUPgCegK5UaNGbsdN mjQxem+QUkv+8MMPZtOmTeaDDz7I8WJ3pbakIIBA8RXIyhG8N998szsjCvTqJWk1atRwy8qWLWva tm0bvDitefPmZvz48cG6bdu2uToFPaHMF1u2bMmxGz0SoYBvXstvv/0W/CKn/DqlSpUyxx13XBDs 1ijk3IqOXzl4VPx+6D8QX331VfDyt2rVqpmaNWuaQw45JLfmWI8AAggggAACCCCAAAIIIIAAAoUo MHLkSJeG8rTTTgviIX7qhX333dcoDqIUDnqC2D7VvH79+qR6uXHjRhdz0LRiLvpL9klkpb303zuk uIXek+SXxYsXm7lz5wbvQ1Lbeup5r7328qsYpZTwi+Io/nHadTt27DDbt2+3s+7Tj3m4hd6E+rhs 2bIgKP7TTz+ZcuXKBXGlo48+OkdfvM3cpGIrfowprH9ar1iLjnePPfYwf/3rX03FihVdG0wgkFYB 5eDNpjJ69GjlDHZ/s2bNStj9Tz/91NWtU6dOwrr+yj59+rjtJk6c6K/KdXrp0qWR8uXLu+39/tav Xz/X7cMqDBkyJFK5cuXQNtV+ixYtIgsWLAjbNFjWsmXLqG1PO+20yNq1ayNXXHFF1HLbVx3/9u3b 47b3yy+/RH788cfIwoULI9WqVXNtaD7sTyYUBBBAAAEEEEAAAQQQQAABBBDIu0DXrl3dv79ffPHF hA316tXL1Z02bVrCujNmzIiceeaZrr6NDdjP6tWrR8aPH5+wjVatWoVuv27dumA79aFp06ahdQYO HBjUWbFiRdzYR+nSpSPLli1zfbj55ptD21KfFT/5448/XF07sXnz5sh9990Xdztte9NNN0XWr19v N8nxOWnSpIj6Ym3sp9pV2bJlS7CPsLiQjNesWZOjTRYgkF+BrEvRcNddd7kAd8eOHYO3QboFIRP1 6tVzvzRVqFAhpEb6Fy1ZssTEy0erRyZSKUpH0axZM9OuXTuj6Xhl1KhR5phjjjF9+/bNUUW/aH36 6adRy5WzR6OeX3nllajldqZnz57mX//6l52N+rzuuusCU4321a9bP/74o1uv+bC/ypUrm3//+9+u HhMIIIAAAggggAACCCCAAAIIIJB3gdiRsbEt6d/0ffr0Mf369QvSRsau17xG3N50003B+i+++CKs SrBMTxErDebll1/uXk4fW9k+PR27XKOIFavQiOPRo0fHrg7m9cI4leXLl8eNfagdP6aiUcrxiuIn CxcujFo9efJkc/zxx5u77747annsjPp67LHHmnHjxsWuCua/++47NzLar6ARwT///LOpW7dusI+w uJCMFb+hIJBugehx8uluPc3tKVCpwKQt3bt3t5NxP3XDe+ONN8yAAQOCtA1xK6ZxhZKd9+/fPyq5 eVjgNbdd6niVasK/ybZq1cp06dLFHHXUUcFNVcP977zzThdQVvoKBV5VzxYZDBkyJHhpnG7uttib Tfv27YMbkFI1/Pe//3X9Vp+vvvpq85e//MVuEnyuWLEiaj7Zmdiba7LbUQ8BBBBAAAEEEEAAAQQQ QAABBEyQdsE63Hfffebcc8+N+9j/fvvtZ+644w5bPfSzV69e5sknn3TrateubW699dYgdePee+8d xAcef/xxM2nSpKDOoEGDjNJiPvHEE24bOzFs2LAgfrFmzRrz/vvvu9iC4hCKkdiigXgKtI4dO9YN GNN7i1SUruHZZ581H374oVE6ClsU/zn11FNN/fr17SKjfo0YMSJ48buC2LYoWHzSSSdFDQi0g+ds ygrVVWC7RYsWRgPSlA5TAV15qChe0rp1azN79mxTtWpV23TwqTiN0lfohfOKj7z88svB8kWLFgX5 ke0gOL347qKLLjLKf6x+2qLgMQWBdAuU0BDgdDdaUO3Nnz8/yP1i29dNo6ByxT744INGo1hVJk6c aM466yy72zx92pGuylujm0AyRTfre+65x1XVDVI3n9iiJOoXXnihGTNmTLBKNxH9oqSbVGzRTVTr bNFNWr8u2aK2dMO0L7B76qmnTGwgXYHajz76yNhLR072Jvn000/bpqI+999//2Akst7qSUEAAQQQ QAABBBBAAAEEEEAAgdQF5syZExXkVQvXXnttELPQO3qqVKkSBGCTefePnvQ955xzXCf0xHTv3r2D fLFuofIPRCJB4FMxClv0Ijfl+o1XFEfwg66qp3y7eor4zDPPdJtNnz7d6JguuOACc+ihh7rliveU KVPGzQ8ePNhceumlbt6feOutt8wll1wSLGrTpo15++23/dXBu4gUCLcjjBWX0WhexWlii0bgnnHG GW4QnfqqmFC80dIacVypUqXYZowsNYJa8RkV5UBWHEX79s1zbMgCBPIqkN8cD4W5/ciRI12OE+U7 KciSnxy8Yf2yeWqVgyWZorwwNo+LPp977rmEm/36669ROWD69esXWr9mzZqu3UGDBoXWGT58uKvT rVu30Dr+QuU2tn31lzONAAIIIIAAAggggAACCCCAAALpFXj88cfdv8Htv8VjP5UPV3EBvXsnXmnQ oIFr55JLLons2rUrXtXIzp07Iw0bNnT127RpE7euViiW4PepefPmEZuLN+GG3sobb7zRtVGvXj1v TfSkH5NQftzYMmHCBNeO+jR79uzYKlHzsfUTvftJOYH949T0e++9F9UeMwgUhkBW5eDVLyO2HHTQ QXayWH7qMQC/nH/++Wb16tVx//TrnH6RssVPZWGXxX7qF7KwolG+tiiHDAUBBBBAAAEEEEAAAQQQ QAABBDJDQKkZ9ch/zZo143ZI67t16xa8e0fpDmJL7Lt6rrzySqNRs/HiDmvXrjUtW7Z0zWhUa7Kl SZMm5p133jGpxnFuuOEGtws9few/jWxXqB/2CWSNtvWfULZ1/PiI0kNUrFgx7nHq+OVqR96qDdu+ bS/Rp0Y2+06J6rIOgXQKZFUOXj/vifKnbN++3ZQqVSqdHhnTlh5T8EtYugV/fey0fwOLXad53awO PPDAsFVRj0Hs2rUrtA4LEUAAAQQQQAABBBBAAAEEEECgaAQ0YEt/3377rfn888/N119/bebOnRsE Qe37dtQzTZ933nlGKS/1YnZbYoOlTZs2tauS+lS7ylurfLy5leeff97su+++uVXLsV79Vb7boUOH Buv0biXl3fWL/74j+6I2f72mv/zyS7dIgeJk+uw2MCbIw+vPx5vW+5ISpa2Itx3LEUiHQFaN4FW+ Fr8sXrzYny1W00uWLMnX8eQnaXcyuXry1Tk2RgABBBBAAAEEEEAAAQQQQACBfAvoCdxrrrkmeInZ J598ErzzR08EKy+vX+69915/1uT3aV0NGvNHuUY1HjOTn4F5Gq1sy4svvmj03iBbFLTWi91U9LJ5 PfkcVpRXNz/lyCOPTGrz/BxnUjugEgIJBLJqBK+ShftFb1wMS4rt18nWaf8GohvVQw89lNSh7LHH HsFN9vTTT0+qfror7dy505QsWTLdzdIeAggggAACCCCAAAIIIIAAAru9wDPPPBOM0r3lllvMUUcd FepRq1atIOCrl3/dfffdQR1/FKsWxMZXhgwZEtpW2ML99tvPnHDCCWbvvfcOW53WZUq7oLQKGnmr l7u/++67pkOHDsE+/Je833rrrXFfhCYn+5Rzq1atzGWXXZZUH/ViNY329V8Kl9SGVEKgCASyKsCr wGGDBg2M3vSocs899wRf7P33378I6Ap2l34e3D/++CN4LKFg95ie1vVmSP/Nl+lplVYQQAABBBBA AAEEEEAAAQQQ2L0FlBZBeXVVFi1aZN5///2EIAqE2gDvvHnzourGPvVbp06djB1Ap2C2Arwqzz33 XBAHUq5cG+DVSOKOHTtGHZ8/U7t2bWMD2IccckjWxFf8Y2AagdwEsipFgw7mkUceccekm1vv3r1N JKKXFsYvuvH16NHD9OrVK9e68Vsp3DXHHXec26GO86233nLziSa2bdtmfvzxR6ORtIVV/Fw6/ovw wvavRO4UBBBAAAEEEEAAAQQQQAABBBBITWDDhg1ug1GjRpkFCxa4+bAJ/9/f5cuXj6qi0bf+S9pi c9tGVfZmFH9RjMVPleCtLpBJpV7Qk80qCvTOmTPHvPTSS25f//znP02igX8abWzLyy+/nKubrbtu 3bp8p7KwbfGJQEELZF2A97TTTjPXX3+9c3n00UfN3//+d+Pf6OxKveVR6/VyNv2yo5wzuhFkQ9Fj APaXOfW3a9eu5rPPPovb9R9++MH861//Ch4fUNqKq6++Om7ddK/w00m8/vrrOZrXjV8B6mbNmgUv xWvXrl2OOixAAAEEEEAAAQQQQAABBBBAAIH4AgcccEDUSr0YLd77exTc1chXWy666CI76T41YM6W /v37G6V/iDdYTC9Ue/LJJ4MXtSnGUqNGjbh1bZvp+lSqBKVgsEX9fOKJJ+xskIPYzYRM6MVnGsVr i2JIP/30k52N+tSL5idOnGguvfRSo9G+euH9oEGDouowg0AmCpSI5Db8NQN7vWbNGnPiiSeapUuX ut5pSH7jxo3NKaecEuSA1RshY7+E+sVHb5WMTXytIf5686RfFExVYnKVFi1a5Mhtc+CBBwYB1YMO OsjfLEjwrRQSuin4pV+/fm7WD9zahbpB6lcnvyg1g0by+sepfDG6iav+1q1bjR6zePvtt10+Gbt9 +/btjR9s1aMbkydPNg8++KCtYpSsXLlk9FZKFfVZScuVm0Zvp1TRr3yXXHJJ8CZIBWjDyptvvhnc /Ow6PRpx8sknB7PTp083gwcPtquCT52rsIB8VCVmEEAAAQQQQAABBBBAAAEEEEDACWzcuNHEBnkV gLz99tuDWIiCmIojzJgxIxjg9sUXX7ht9W9zxUtii4KdNn2B1qmNK664IkjXsNdeexm9oOzDDz80 I0eOjNpUsQI9wWvfwfP9998HMRjlyVX54IMPgqeLNa34RGwqR40gvuGGG3LEWqJ24s3o2A8//PAg D6+3OHiZnILTuRXFdxRH8otiMzKRoQLYqqM4kh+DUX3FSa666iq36QsvvGC++eabYF6jfF977bVg WjGn8847z9WzEyeddJLp0qWLneUTgYIRUIA3G8uaNWsi7dq1U26GpP5at24dWb16dY5D/fbbb5Pa Pmw/Q4YMiWpv8+bNeW5L7c+bNy+qPc3MmjUrUrt27ZTabdOmTWTFihVRbYX13y7bsGFDUHf27Nlx 91O+fPmo9vyZnTt3Rrp16xZ3W7sffZYuXToS6+a3xTQCCCCAAAIIIIAAAggggAACCOQU2LVrV1L/ 7vb/Da7pV199NWdjfy5RnETxkthtEs0rRjFt2rSoNtu3b59SG2r/jjvuiGojt5levXrl2Md3332X 22Zu/dChQ4OYRKJji13Xs2fPyJYtW1wb2l9snWTm161b59pgAoGCEMi6FA02zK2h8nrsf+DAgaZ6 9ep2cY7P1q1bm6lTpwZvWoz9xUiVNRLWH6qfo4E4C/RrlR5J8Ms+++xjtL+8FOW+0a9RsUV90y9t evxAI1/jFW3/2GOPBY9naETvYYcdFlU1XsJxpbywvwAqtYPNa+NvrP22adPGXxQ1vccee5innnrK 9OnTJ+650P71tsuVK1e6EcNRjTCDAAIIIIAAAggggAACCCCAAAJxBUqUKBEVv1DqgURFTyPPnDkz 4QvIFCfRv9X11G+i2IpiIEoLqfZmzZplTj311Khdx3viN6qSN6M4g17slkrp3r178JSx3UajYv33 F9nl8T4vvvjiIDXDtddeG69KsLxJkybBSF69RP6BBx4wGm1si2ImqcaQ6tWr5+Iuth0+EUi3QFam aAhD0GMAGiKv1AwKWOpLp4BlmTJlwqpn7TI9NqC0DHrx2n777Rc8SlClSpWEwd/CPlg9OqHHM5S7 R32rUKGCe2yjsPvC/hBAAAEEEEAAAQQQQAABBBAoLgITJkwIXjCmIOTll18exAaUikG5eH/99dcg AHrUUUeZY489NsiXm+pxK8XD/Pnzg/QL9t/0+ne9YisKMBd1URqF4cOHBwPklE4y0UC4RH1Vikql YlB8Rcds8+0qXYMf0E3UBusQyCSBYhPgzSRU+oIAAggggAACCCCAAAIIIIAAAggggAACCBSGQNam aCgMHPaBAAIIIIAAAggggAACCCCAAAIIIIAAAghksgAB3kw+O/QNAQQQQAABBBBAAAEEEEAAAQQQ QAABBBBIIECANwEOqxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAgUwWIMCbyWeHviGAAAIIIIAAAggg gAACCCCAAAIIIIAAAgkECPAmwGEVAggggAACCCCAAAIIIIAAAggggAACCCCQyQIEeDP57NA3BBBA AAEEEEAAAQQQQAABBBBAAAEEEEAggQAB3gQ4rEIAAQQQQAABBBBAAAEEEEAAAQQQQAABBDJZgABv Jp8d+oYAAggggAACCCCAAAIIIIAAAggggAACCCQQIMCbAIdVCCCAAAIIIIAAAggggAACCCCAAAII IIBAJgsQ4M3ks0PfEEAAAQQQQAABBBBAAAEEEEAAAQQQQACBBAIEeBPgsAoBBBBAAAEEEEAAAQQQ QAABBBBAAAEEEMhkAQK8mXx26BsCCCCAAAIIIIAAAggggAACCCCAAAIIIJBAgABvAhxWIYAAAggg gAACCCCAAAIIIIAAAggggAACmSxAgDeTzw59QwABBBBAAAEEEEAAAQQQQAABBBBAAAEEEggQ4E2A wyoEEEAAAQQQQAABBBBAAAEEEEAAAQQQQCCTBQjwZvLZoW8IIIAAAggggAACCCCAAAIIIIAAAggg gEACAQK8CXBYhQACCCCAAAIIIIAAAggggAACCCCAAAIIZLIAAd5MPjv0DQEEEEAAAQQQQAABBBBA AAEEEEAAAQQQSCBAgDcBDqsQQAABBBBAAAEEEEAAAQQQQAABBBBAAIFMFiDAm8lnh74hgAACCCCA AAIIIIAAAggggAACCCCAAAIJBAjwJsBhFQIIIIAAAggggAACCCCAAAIIIIAAAgggkMkCBHgz+ezQ NwQQQAABBBBAAAEEEEAAAQQQQAABBBBAIIEAAd4EOKxCAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQy WYAAbyafHfqGAAIIIIAAAggggAACCCCAAAIIIIAAAggkECDAmwCHVQgggAACCCCAAAIIIIAAAggg gAACCCCAQCYLEODN5LND3xBAAAEEEEAAAQQQQAABBBBAAAEEEEAAgQQCBHgT4LAKAQQQQAABBBBA AAEEEEAAAQQQQAABBBDIZAECvJl8dugbAggggAACCCCAAAIIIIAAAggggAACCCCQQIAAbwIcViGA AAIIIIAAAggggAACCCCAAAIIIIAAApksQIA3k88OfUMAAQQQQAABBBBAAAEEEEAAAQQQQAABBBII EOBNgMMqBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAgkwUI8Gby2aFvCCCAAAIIIIAAAggggAACCCCA AAIIIIBAAgECvAlwWIUAAggggAACCCCAAAIIIIAAAggggAACCGSyAAHeTD479A0BBBBAAAEEEEAA AQQQQAABBBBAAAEEEEggQIA3AQ6rEEAAAQQQQAABBBBAAAEEEEAAAQQQQACBTBYgwJvJZ4e+IYAA AggggAACCCCAAAIIIIAAAggggAACCQQI8CbAYRUCCCCAAAIIIIAAAggggAACCCCAAAIIIJDJAgR4 M/ns0DcEEEAAAQQQQAABBBBAAAEEEEAAAQQQQCCBAAHeBDisQgABBBBAAAEEEEAAAQQQQAABBBBA AAEEMlmAAG8mnx36hgACCCCAAAIIIIAAAggggAACCCCAAAIIJBAgwJsAh1UIIIAAAggggAACCCCA AAIIIIAAAggggEAmCxDgzeSzQ98QQAABBBBAAAEEEEAAAQQQQAABBBBAAIEEAgR4E+CwCgEEEEAA AQQQQAABBBBAAAEEEEAAAQQQyGQBAryZfHboGwIIIIAAAggggAACCCCAAAIIIIAAAgggkECAAG8C HFYhgAACCCCAAAIIIIAAAggggAACCCCAAAKZLECAN5PPDn1DAAEEEEAAAQQQQAABBBBAAAEEEEAA AQQSCBDgTYDDKgQQQAABBBBAAAEEEEAAAQQQQAABBBBAIJMFCPAW0tnZtm2b+eabb8y6desKaY/J 7yaT+5b8UVATAQQQQAABBBBAAAEEEEAAAQQQQACB3U9gz93vkAv/iOfPn29OOeUU8/vvv5vSpUub ZcuWBZ+F35Oce8ykvu3atcssWbLE7Ny5M6qjJUqUMJUrVzalSpWKWs4MAggggAACCCCAAAIIIIAA AggggAACu7sAAd5CuAJmz54dBHe1KwV5f/75Z1OrVq1C2HPuu8ikvp122mlm5syZoZ1u27atGTJk SOi6wl4osw8//NB8/PHHwbk899xzTcOGDbwjZCEAACAASURBVE2LFi3MfvvtV9jdYX8IIIAAAggg gAACCCCAAAIIIIAAAruxQNYGeBcuXGg2bdqU9KmrWrVqxoya1UjVVMucOXOCAGezZs1M3bp1U908 6fp56VvSjSeoqP1qNHG8snr16nirklr+448/mo0bN0bVrVSpkjn00EOjluU2M2rUKHP++edHVXvu ueeM/po0aWJGjBhh9t1336j1iWZ03PPmzTPbt2+Pqnb00UcXu2Cx0pMoTcnXX38d/O25557myCOP NCeffLI555xzjL7TkyZNCoLlxxxzjPPQuV++fLmbj50oWbKk2WuvvczBBx8cnM899kiceUZtxV5P 6kuVKlXMAQcc4JrXjzFLly41O3bscMv233//YDS59qei8/fDDz9E1XGV/5xQm4cddlhS18WWLVvM ggULTCQSiW0m13n9uKDrJlFZtWqVmTVrlpkxY0ZwDipUqGD0w8pJJ51kjjvuOCOHVIq+U/pu+UUj 7WvUqGE08j6VopH7Onb9gKIfemSv76ju3fpuHXHEEeadd94xOt9t2rQx/nkO64eOpVy5cqZs2bJB N3Qe9ePa5s2bo7qlc1qtWrWoZbEzu9P3NPbYmUcAAQQQQAABBBBAAAEEEMgCgUgWlvvuu0/Rj5T+ SpcuHdm4cWORHO306dOj+rpq1aqU+9G8efOgjfLly6e8baIN0tG3RO2nsu6LL76I9O/fP9KnT5/I Aw88ELn//vudW8OGDVNpKqruo48+6tqJvW7Wr18fVTfRzOjRo3O0o+vKb1PnacuWLYmaiVrXu3fv qO1tW0V5vUZ1MA0z8rj11ltDj9M/Xjvdvn17t9clS5Yk3M5uYz/l1qNHj8i3337r2vAnRo4cGbe9 6tWrR3bt2hVU16e+a7Zd/7NVq1auyWuvvTa0jl/fTqtvuo6HDx8e2bFjh2vDTmif1apVS7o9267/ +eabb9rmoj63b98e6dmzZ8K2dfzx3KIa+3Pm999/j8Re/7Yvuq5TKVOnTk3p2L///nvX/KZNm+L2 Q/2ZNm1aUFfnzfYv9rNfv36uvbCJ3eF7GnbcLEMAAQQQQAABBBBAAAEEEMgOgcRD3TI0QL1hw4aU e6bReEX1grM6deqY6dOnmzFjxpiVK1ea8uXLp9x/jbxT+eWXX1LeNtEG6ehbovZTWXfGGWeYa6+9 1txxxx2mZ8+ewWcq28er+/3334euUj7kZEcZavRfx44dXTudOnUKriddi59//rlbrtQNb7zxhpvP bSJeSgddrytWrMht84xfr1HZGnH+6KOPJuyrjteWRYsW2cmEI2NdJW9C7Tz11FPm+OOPD0apequC yUT3AI2ktvmfNYI2dqSnbcsfaf7rr7/axbl+qm/jx483F154oalevbrxj1Mbh41CzbXRmArfffdd zBITjH5WCpE+ffrkWOcv0PHL7fXXX/cXx53Wvcg/b37FZEexy/uxxx4zp59+eo6RwH57sdP+iG6N fo/XD22nvN4qv/32W2wzbj52RLdb8edEcf+exh4v8wgggAACCCCAAAIIIIAAAtklkNrzuBlybLfc coupXbt2VMBWj/M+/PDDQQ9r1qxprrvuOtdbPdKrR4YrVqzolhXmhIKIeslaJpZM7ltBeN1zzz3m qquuCprWo9vJBqLGjh3rguu6vp555hmXQqFevXrmtddeMx06dAjaffbZZ40CwMkUXcvazqZo0GPo xaXoO6lApl9eeukl06BBg+CReAXVPvnkkyC9hQKfYUWP5yutgwJ6b7/9tnnxxReDat27dzdNmzYN phV81w8nSv2gVBm2KO2Dgvt6zN8WPdqva/6DDz4wgwcPtouD8/m3v/3NpSjQ4//KsTxs2DDzyCOP BPX0w4zuMWeddZbb7vHHHzfnnXdekC7m1VdfNdOmTQvW6YcKBUsVKF67dm2QbkDBf5moKK3BBRdc YKZMmeKuo61bt7p2lTbh8ssvd/OJ7m8KXPbu3TuoGxuUlo0cFLy15f777w/6rP7pHCgdgn5QUWoE FV2PSlugQHQqZfHixUF1pWhQSopkin7M8YP/LVu2NLfffnuQo1xB1a+++sqMHj3a3HXXXVHNKWWC LQceeKCZOnVqkL7B/jdAP1zpHCjVx9lnnx1Uffnll824ceOCcyADFV2f9957r1Ee7USlOH9PEx03 6xBAAAEEEEAAAQQQQAABBLJEIDsGGufey3nz5rnHbzt27Jj7Bn/W2LlzZ0SP+Opv27Ztbjs9Lj1/ /vzIkCFDIsOGDYvMnTs3osecky3a3rbrf2p5XkqdOnXc8eVle3+bdPdNbf/xxx+RSZMmRfQI/KBB gyJvvPFGZMqUKZHffvvN33VK0zo39lHq/KRo6Ny5s2snt0ex43WwTZs2ro2BAwfmqCZT/5H+WbNm 5aiTzAL/kfcFCxYks0nG1mnbtq0z0+P/+g6Fla1btwapC+y5Pu2008KqBek7bB1dY2Fl8eLFUefh 2WefDasWXK/++VIaj7Cie0lu+7TbKTWErfvZZ5/Zxe5T948BAwa4Oqr79NNPu/XLli1z67p16+aW ayLR/W358uVxt3vuuefcOl1bY8aMiWrXzmzYsCHipzBQqojNmzfb1aGfCxcudG3rWFIt+o5YL30q 9Y6+82Fl7NixUXWVLiW2zJw509Xp2rVr7Go3v2jRIlfPT7fhKiQxUZy+p0kcLlUQQAABBBBAAAEE EEAAAQQyXCArUzSkK3auEXV6MZNGiulPL07SMr1ISyPQjj32WNOuXTvTunVr85e//MUohcC3336b 6+6XLVsWbG/b9T81SjDZose/f/rpp2C0n/9ouUb/hf1pv7mVdPXN7kcjLzVCUC+S0khWjcBTKoNL L73U/PWvfw1ecHTzzTdHjba222bL57Zt24LRgba/euFTbNGo0Isvvtgtfv/99910YU/ocXWlibjv vvuCEZCFvX/tT6Nfhw4d6nataY2iDyv63mlktS02TYKdT+VTL0r797//7Tb59NNP3bQ/oRGqSuVg i0ZxxqZb+OKLL8ygQYOCKmeeeaZp3769rZ6nT730q3PnzubWW29122vkqS3+CF7dM5It++yzj6vq j+DVyGF/Xw888IBp3Lixq+tPKF2JUjPoU0X3F41SL6iiEbjXX3+9a173WY3S9V+c5lYaYxo1ahSM /LbL7Ih3O88nAggggAACCCCAAAIIIIAAAruzwG4d4NVjy7G5G/W49fnnn+8ex/cvDj3KfMIJJ7jH rP11/rRyPsbLlfvDDz/4VeNOK8WEHgnX292PPvroIOBiK2s+7K9y5cpRwS1b3/9MR99se3rjvQIv 8YJotl7fvn2Dx9H1uHo2Fj/wp0e6/Uf+/eORhS32UXw7X1ifCqzqkXUFIxU01aPqSg+i/K6FWfxH 6hXwV0qVREU/Dtjc1BUqVEhUNdd1/vmZM2dO3PoKKtavXz9Yr/uAAuK2KADZo0cPOxsEg+MFH12l JCf8IOuXX37ptvIDvMmmDtHGfl0/wPvmm2+6+5sCt1deeaXbV9iEgt5Kj2CLTftg59P5qet00qRJ rkkF2HMrfoBd6VUoCCCAAAIIIIAAAggggAACCCDwP4GszMGbrpOnHJdbtmwxEyZMCEbu+u0qWKpc rRrJO2PGDJf7U3WUr1L5NuMVvTCof//+UXkvFeRMpeT1BVsLFy5MuJt09M3uIPalRXqRk/KraqSz HfWqvJcqEydODHKeXnbZZXbzrPlUfldbjjzySDuZ49PPO1pUAd6wQJl+mBgyZEiuAb4cB5THBcr7 anPRqgnly82taHSrRh0PGDDAtG3bNrfqCddPnjzZrdco/HhFo66ffvppc9JJJwVVNH3DDTcEI42V U9keQ5cuXYxy4qarxBt96gd4UxnBu/fee7uuyd4W/+WCCu5qlH1uRSOM77zzzqCagt669v3rOrft k11v8/2qfosWLeKO7vbb071DPyqpX3qigoIAAggggAACCCCAAAIIIIAAAv8T2K0DvIcccoi57bbb ghftKDWDLVdccYXRi7L8IIsey9eIPxU9tv3KK68EL2uy2/ifGumnF/z4ZcSIEVGjcP11YdN6eZP2 aUe9KqhsRxsrEBVWNAKvWbNmYavcsnT0zTamoJcC3QqSa9Tz4YcfblcFn1qmgKgdCaiXJWV7gLdM mTJRx+jP6HqyJZl0GbZuuj4VOPRHRfrtKtVHYZXYfelFV8kU/UCgv7wWBUh1PdoXbamdsHQafvsn nnii6datm+nXr1+wWPcDteGnNrAv5PK3y8+0n77juOOOc00ddNBBbjqVF0IqUK0fpPSjgh0FrYbm zp3r2ksU6HaVjMkRzNUPRgUR4PVHVutlb8kU3Y/9c5toG72YTyknwkpefzwLa4tlCCCAAAIIIIAA AggggAACCGSCwG4d4A07AXoEX6Nv/ceeVU+jCvWYuR15piBBKkGYsH0lWqYUDBpNaMvAgQODt91r XgGpTCglS5YM8u0m6otSTdgArx9wSrRNpq3z020ceuihcbvnB+iKYgRvqVKlgpQeyp8aW3IL/MfW z8+8n4ZEqQH8wHd+2vW3VX5YmxpEo8UVUNeIW/sjiOrWrFnTdO3a1d8sdFo5e/WDjbbVDzHKKW3P uX5oSVeAc9OmTcGI4eeee871w//Bo2rVqmbs2LFBOo2mTZu6OslMKG+47k3nnnuuqz5r1iw3rQBw skVu3333XVB9/vz5QW7tZLdNtp7fN6WhSXdR/mT9URBAAAEEEEAAAQQQQAABBBDYHQQI8Mac5Ysu uihHcNdWUT5TG+BdtWpVgQZ47T4z/VMvxPrggw+CFAAauamAkIJjCuxpRK99/F3HsWjRokw/nND+ +S+x8h+jj63sP3qvF4cVRXn++eeDUdI2QKk+dOrUydStW7fQurN8+XK3Lz/o7RamYSK3AJ4e+1fQ NpnzoFHZjzzyiNGPESpKaaGiwGNef0zREwBjxowJ2lm9erVR7msFpP0AtEYXt2rVKqhj/8fP42yX JfOpH5/8PMca+e9fA3qZZLJFo4BtgNfvb7LbJ1PPH+WtJw8oCCCAAAIIIIAAAggggAACCCCQdwEC vDF2Gjkbr/iPP8erszst1wui9OKjsBGjCgzpTy+yy/bij+Bcs2ZN3MNZt26dW5coV6+rVAATeoGX RpcrAKrzopG7hf1CKo1EtUUjmRX41ujidBb9gFClSpUgcBobhFS+4VTz+CrftlKf2MCm+qq0DckE iMOOSy84S1SUwuXRRx/Nc/uJ2tY6pW1QgNp+N/080rltu3jxYlelXLlybjqdE8qha3McF8QPPwqc P/bYY6Fd1v78F92FVmIhAggggAACCCCAAAIIIIAAAlkkQIA35mQpMBKvJFoXb5viulwvO9IIRD+4 ppy8Z599tqlQoUJw2Bq1OG7cuKigWTZ62ONR3/1RkbHH4gd/FXwsqqI8yxqxW5ijdv1jVZoTvyhg mOiHE79ustMaIduhQweza9cu8/XXXwcBXRvMvPnmm4MAXiqpIfSSN+Xa1Qh+FV3bzZs3T7Y7ofUU hFZRkFRB7yOOOMIo565yfPvXVOjGaVhYq1YtF+DVdzGZIk/rqPrJ5u5Npm2/jkYb2wCv7iXpLvox Ll7u57wG7dPdR9pDAAEEEEAAAQQQQAABBBBAIF0CBHjTJVmI7SgtgvLfFmVRMMwGdzVScPjw4UYB pbBy4IEHurph6zN9mT+CVyk64vn7o5UrVaqU6YdVYP2LDW4rr2y6A7y28wpmK3WKctDaF5Zp1PAt t9xiBgwYYKsl9ekHhDXCND/ls88+M/Xr189PE/neVh7KKayiIHgyxb+GVb+gzpvy/NqiFC96UaOf CsWu4xMBBBBAAAEEEEAAAQQQQAABBHIX2CP3KtTINIH169cXeZcmTpzo+vDRRx/FDe7qxVI2EOw2 yLIJBf5seg4di83RGnsYI0eOdIv8AJZbWAgTGoE5efJk06NHjyA9g3LyKl90YRb9+NCgQQO3y3vu uSd4cZhbUAATCsj6Ly/773//az7++OMC2FP2NKnAty2DBw9OKgf2U089ZTcJUjykkrvXbZjExKmn nupqaVS8rlMKAggggAACCCCAAAIIIIAAAgjkTYAAb97cCn2rfffd1+3Tf4mVW+hN7Nixw5tL/+S2 bduiHuNONMpPeU2zvSg1x9VXX+0OQ6NFY8uGDRuCUaR2uX3U384X1qdGrdarVy/IJzt69GijXK96 zF6jWguz6KVltiiA17t3b6MXfyUqyo2qwHSvXr1yrRvWTteuXaMCy126dMn6HxfCjjPZZa1bt456 8Vq8nLS2PV0j/fv3t7Pm4YcfdtPpnlAql5YtW7pm7777buO/eM2t8Cb044VyG1922WVmxowZ3hom EUAAAQQQQAABBBBAAAEEENi9BQjwZsn591/a9frrr+fotUbKvvXWW8GoTb3Qql27djnqpGuBclhW rlzZNecHhexCBaGvv/56c/vtt9tFWf2pvKm2KFj5zTff2Nngs1u3bm5egcWCGvnodhIyodQRDz30 UI41GnWsFBqFWZSPWeffFr1Q7O9//7tRIDy2rF27NnjhmPLU6geBe++918yZMye2Wq7zStfw0ksv uXoKWN55551ufnebUF7h//znP+6w9dI4Bc8VKI0tP/zwg/nb3/7mFutHgjZt2rj5gpjw+6Zr9MQT T4z6kcTfp0ala1T4pZdeajQauSCDz/5+mUYAAQQQQAABBBBAAAEEEEAgGwSyMgfvt99+a1577TXz xx9/OGP/MfRPPvnEdO/e3a1TQLJGjRpRozC1Um+WV7BUIx1tGThwoNFLf6655prgxUha/t1335kh Q4aYYcOG2WrBiMSTTjrJ6IVOyjFri+p8+umnOYIo9sVFGs3o981up+DWP//5Tzub41Oj3RTYUFEQ b9myZebkk08O5qdPn+7W2Q2VNiG2pLNvTZs2dTlOFdxUnxRUPuCAA4Lgp29l+2GPvWzZskajLStW rGhXBQE9ndONGze6ZX4gSi9kCnM777zz8v0yLLfDBBN6YZNeuvXhhx8GtS688MIgeKjzNnToUDNo 0CC3ta6doir2Oovdv4KohV3uu+8+895777nRw3LSddm4cWNzyimnBHmk9d3y7dRH5XS2OXAVtNYP CApA6jq35YUXXghe0qXvQKdOneziIGesApk24K6A8datW4Plt956q/FflKh7htI6rF69OhgxvHDh QteO7gn2etPL0lq0aBGMjHYV/pz48ssvgx9Wtm/fHpUSQgFI3TNUtE/l423btm3s5nHn1Tcdo74z KonubxoNG69tBUX1Mjp9t1QUPFefW7VqFdwTFVidOnVqEFjXtC1K1eBb2eXp/DzqqKNM3759zU03 3RQ0q/2ff/75Rj8OnHHGGcFL0lasWBF855T72i+q5xcdn58iRS931Pk7/PDDg3u08vtOmjTJjB8/ 3sydO9dtOmXKFHPHHXdE3e/dSiYQQAABBBBAAAEEEEAAAQQQyBaBSBaWTp066VnvlP+WLVsWdbSP PfZY3DbuuusuV7djx45x673yyiuu3ubNm+PWS6a/8+bNc23FTuzcuTPSrVu3pNovXbp0ZMiQIVFN pLtvv/zyS6R8+fK59kd2derUyVGvd+/eUf1r3bp1jjrJmFWrVi2qnbCZzp07u7b79esXViWpZWvW rAk9Fr+fgwYNSqqteJV07mx7CxYsiFct7vJ69eq57W07+sxLW3F3ksIKmbVr1y60T37/7LSug9Wr V7s9TJs2LddtV6xY4eprYseOHZEGDRrk2G7mzJlR9Z544okcdWw/Yj/r168fta2dadq0adJtbNmy xW6W62ffvn2Tbld9TVTkoe9b7DGFzVevXj0ye/bsRM25dQsXLoxq061IceK9996L+Nd9WL/sMtUb OnRo1B50X7frwz7ffffdoL7uFWHrtey2226LajO3Gb+/RfXdyq2PrEcAAQQQQAABBBBAAAEEENh9 BLIyRYNGj6Za9MKh2MfmNapOo/PCygknnOAWazRZWKlevbrx62mUmPJe5qXopVwabRav6PFzjarr 06eP0X7DSseOHc27774bjEyOHdGX7r6VK1cueJmXRgKGFY3C0yjIV1991fTs2TOqiszPPPPMqGV+ Ps6oFbnMnHvuubnUSN9qvWxNx6TH18OKXuyl0ZJFWTQC/ZJLLnFd0LWiUaqJ8iS7ygUwITOlDlG/ 4l232q2+NxpJquv30EMPdT3RyHuN6I1X9B2O/V7rJW8aLeyfJ7WhEaN+0fp433+/nuo0atTIX+Sm mzRp4qYTTej6VuqUZIu+H8n0Te21b98+YbPy0IvudO0mOgedO3cORknXqlUrYXvpXikbjarVPSve Meslh08++aRR6peLL744qguHHXZY1Ln2V+q+qtH3KtourH0tq1u3rr8Z0wgggAACCCCAAAIIIIAA AghklUAJxbKzqsd0NhBQKoPvv//e6BH2KlWqmAoVKgSPvBcFz5IlS8z8+fODF1qpLwqqKKCcKUU5 cRV8VdHj+zfccEO+u6ZA02effWaU+kA/HijlgHKe5rco3Yd9VF6pQvIamFUb69atC66N/PYpndur X8pfrNQMSuehwKuOsUyZMuncDW0lENB1MWvWrCAVzf777x+kelEQVIHgVIrSgfjXZzr+U6K0LHrZ mlIyKD2Fco+rb/pMJUCeynHkpW66vqd52TfbIIAAAggggAACCCCAAAIIIBArkP+IVGyLzBeKgAIz p556aqHsK7edKKirv92pKH+wP1I2045doxLDRisWdT/taElGTBbdmdCIZ71QzX+pWtH1JnrPelJB QWM/cBxdgzkEEEAAAQQQQAABBBBAAAEEEIgVyMoUDbEHwTwCCCCAAAIIIIAAAggggAACCCCAAAII ILA7CjCCd3c867vxMY8bN849iq5Hvxs3blykGqtWrTKjRo0y27ZtC/ph0zMUaafYOQJ5EFCuZ5W9 997btGjRwihvbnEpfE+Ly5nkOBBAAAEEEEAAAQQQQACB4ilAgLd4nleOyhMoUaKEmxs2bJjRny0r V64M8hfb+cL+vP/++4O8wIW9X/aHQH4F/O+V2rruuutckzfeeKPp27evm8/2Cb6n2X4G6T8CCCCA AAIIIIAAAgggULwFCPAW7/PL0RljOnToYKZMmWI2bNgQ5XHiiSeasmXLRi0r7JlmzZqZjz/+2Gza tClq1w0aNDBVq1aNWsYMApkkoOuzY8eOZtKkSW4Euvq33377mUaNGmVSV/PdF76n+SakAQQQQAAB BBBAAAEEEEAAgQIUKBFJx6vPC7CDNI0AAggggAACCCCAAAIIIIAAAggggAACCCAQLsBL1sJdWIoA AggggAACCCCAAAIIIIAAAggggAACCGS8AAHejD9FdBABBBBAAAEEEEAAAQQQQAABBBBAAAEEEAgX IMAb7sJSBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAg4wUI8Gb8KaKDCCCAAAIIIIAAAggggAACCCCA AAIIIIBAuAAB3nAXliKAAAIIIIAAAggggAACCCCAAAIIIIAAAhkvQIA3408RHUQAAQQQQAABBBBA AAEEEEAAAQQQQAABBMIF9gxfzFIEEEAAAQSyU2Dt2rVm8+bN5oADDjAHHnhgcBC7du0yK1euDKbL ly9v9tyT//zFnl3cYkWYRwABBBBAAAEEEEAAAQSyQ4ARvNlxnuglAggggEASAgsWLDCHHnqoqVSp kjnooIPMpk2bgq3uu+++YJmWd+3aNYmWdq8quO1e55ujRQABBBBAAAEEEEAAgeIlUCyGMM2ePdt8 +OGH5uOPPzY///yzOffcc03Dhg1NixYtzH777Ve8zthucjSc093kRHOYhSqgYOfIkSPN+PHjzdix Y03VqlVN06ZNTfPmzU2tWrUKtS8FtTMb0LXtb926NfjvwIYNG+wis379ejfNxP8EcONKQAABBBBA AAEEEEAAAQSyVyDrA7yjRo0y559/ftQZeO6554z+mjRpYkaMGGH23XffqPUFMaPHf+fNm2e2b98e 2nyJEiVMqVKlgr6ULVs2qcDzkiVLzLp160Lby23hUUcdFTyebOtt2bLFaIRWJBKxi5L+VJD86KOP zrX+jz/+aDZu3BhVT6PlNJoulZLucxrv3OiYitMPADt27DCy+/bbb83cuXPNmjVrzBFHHGFOOOEE 07JlS/Pll1+ayZMnm9atW5v69evnOCXput7iedsdpvpd0DWlaysvpUKFCkaP44eVVatWmdWrV5ud O3dGrVb/KlasmNR1++uvv7rH/tVI5cqVzSGHHBLVXuzMokWLjA02Kk1A9erVTcmSJWOrufmw49e9 pEaNGkZ9TbYogKfrQMFdW+Sq+dtuu8188MEHQaDXrsvWzzJlykR1XaN4VcqVK+eW67qgRAsUhFu8 e0Fxu/dGSzKHAAIIIIAAAggggAACCBSBQCSLy+jRoxWtjPorXbp01Hzz5s0jW7ZsKfCj7NatW9R+ Y/sVO1+vXr3IwIED4/btjTfeSKm92ParVavmjnnXrl0RzcfWSWX+zTffdO2FTTz66KNx21+/fn3Y JqHLCuKc9u7dO7RvulY2btwY2o9sWzhy5MhI9erVQ48z9jw3adIkx+Gl83pL53dB5yf2Ox17PLnN z507N8fxjhgxIler+fPn59jOX7B06dLQNqZPn+5Xi5pu3bp1jm26d+8eVcef+f333+Mev67rZMvm zZsjTZs2jdp3mOuYMWOSbTJj623atMkdZ/ny5V0/BwwY4Jb36tXLLWfifwIF4VZc772//fZbZPv2 7Vw6CCCAAAIIIIAAAggggEDGCGRtDl6NVuzYsaMLiXfq1CkY7aqRcZ9//rlbrtQNb7zxhpsvqAk9 BpxKmTRpkrnyyitN586djUY5xZZvvvkmdlFK8xqZZx+5DRsBmFJjxpjvvvsu4Sbff/996PrSpUsn PcqwoM5pvFG6v//+u1mxYkVov7NpZy1rwQAAIABJREFU4bPPPhuMzNQIcls0klR/YWXhwoU5Fqfz ekvnd2Hbtm1G5yk/RaOZY0syfXz88cdjN4uaV9/CyoMPPhi22Hz11Vdm2LBhOdbpxVbxyi+//BL3 +FN5MkH3wNGjR7vd6B6pe6WeENC90xbdk2JHNNt12fLpuxx22GGu23pywhZ/NK9dtrt/FoRbcbz3 /uc//zG6lvRkivI6axQ/BQEEEEAAAQQQQAABBBAoaoGsTdGg/JEKfqjUrFnTPPPMM+5x+3r16pnX XnvNdOjQIVivAJgfxCgI9EceecRcfvnlQW5HmzJCwU0/uKyAih6Df/31141yzKoMHjzYHHPMMaZ3 795R3VJKBVt69eoV/IPSzr/44otuez1a7QfyXn31VTNt2rSgqs096QezTjvttKCftq2lS5eahx9+ OJiV43XXXWdXmd9++831S2+kT7bcc8895qqrrgqq6x/CfuAgURsFdU5vueWW4Fqw6TOUtqC4FKVd uOGGG9zhdO/e3fTs2dPYwJaCh/ou9OjRw9UJC0ik83pL53fh4IMPNp9++mnwA4MC2E8++WRwHLVr 1074oiylqVCalnjlwgsvNG+++WZwjSttSd++fXOkgdD2Dz30UPCirrB2lAZl5syZ5rHHHgu+x7bO O++8Y+Qem6rh7bfftlXc58SJE81JJ53k5nObWLx4cVBFKRrsOc5tG63v37+/q6brQfdIFaUv0L1z 6tSpgbHuB+PGjQvymLsNsnCiWrVqwfk8/PDDXe/9AK8/7SowYdLtVhzvvTZ/s3540n/r9Kf77j/+ 8Y+kUhlxmSGAAAIIIIAAAggggAACBSKQMWOJU+xImzZt3OO2SnUQW5SWQI/n2se3Z82aFVulwObt o8+VK1cO3Yf6pkeEbd9Uf+fOnVF1/cfcly1bFrWuY8eObtvYx8/97ZYvXx5sp+3tvrTeL/PmzXPr 1K5ftH287fx6mu7cubOr269fv9jVSc0X1jm150fHtmDBgqT6lqmVrr76aud+4403xu1mbEqCHTt2 RNX1r5v8Xm9+w9Y6P98F296MGTPcsV5xxRV2cejnhAkTXN3hw4eH1rEL9ai1vVcozUWrVq3cti+8 8IKtFvezT58+rr79vrzyyitR9fX9loFdbz9jv/dRG0UikYULF0ZtE7s+mXnd++z+dJy6/8QW3UNt nbZt28auzrp5pcDR8fj3NN0r7TGOHTs2646pMDpc0G72fqDzkK33XqWyuOeee9y1ZK8pfbZr1y4y bdq0wjhV7AMBBBBAAAEEEEAAAQQQiBLIyhQNejRao+Rs0cvUYotePnTxxRe7xe+//76bLuoJ9U2j fjTCV0UjgWJTHPgjZpMdAau2/Edi7ahMfwSvvz43h3322cdV8fvjFqZxItvOqc6ZRmfrEV09el9U RS/GsuWaa66xkzk+L7jgAjdqUytjX7bnn9/8Xm85dp5gQTLfhQSbp2XVmDFj3NMAXbp0Mddee61r t1+/fm463oT//dIL01Q0StYvGiGr0bEqGiVpi7+tXZbuT//e16ZNm9CUKeeee67b7dChQ+O+LNJV yvCJU045JeihPzq6atWq7p573HHHZfgRFE33cMvdXfdHPXGj9CZK4+K/xHHIkCFGT8mcc8455qOP Pspxn829dWoggAACCCCAAAIIIIAAAnkTyMoAr/+IuQIqlSpVCj36Ro0aueU2uOIWFPHEHnvsYfSI ty1+/lQt8wNufqDV1o/36QdwbfDIfmqbVIJ3fl2/P/H2nZ/l2XROP/74Y3PggQea9u3bB4H6OnXq GAVGlOu4KMueeybOuKLUIHfccYdRUDi2rn9+83u9pWqQ23chmfYmT54cPB796KOPBtXtjyeaUZqH ROXll192qy+55BKjH4xs2hOlUrEpT1ylmAn7Q4oWd+3aNViroLGf31lBUxWlRjj55JODaf2P/910 C9M84d/7/Huiv5uKFSsaG5zWcpv+xq+TTdNKubFmzRpz8803u27vvffeZtWqVcH3VMdLySmAW06T eEuU3kTXl9IuDRo0KEgVZesqrUzz5s3NCSecEPzYEy9ft63PJwIIIIAAAggggAACCCCQX4GsDPCu XLnSHfeRRx7ppmMn/ByVfpAjtl5RzCu/rc3Dq/3HHkc6Am4256wfRPIDwLkdtwIitugFaAVZsumc 3nvvvTkolItVo7cKu9gRd9rv7bffHvXDQGxfdI316dMnCDzErkvn9Rbbdm7zuX0Xctte68ePHx/k XLWB1Fq1agWj7O6+++5gRF28NrRve94aNmxolJ+5ZMmSQU5Nu81LL71kJ0M/fbt27dq5Ou+++24w re+OHdF72WWXGf975X833YZpnvDvfX5O2tjd+D84+d/H2HrZMK8fDWJzIKvf+tEqlXtgNhxrOvuI W+qae+21V5Djfc6cOUYvddV9xBa9nFQvg61SpUqQP1x5+CkIIIAAAggggAACCCCAQEEIZH2At0yZ MnFd/H/gL1u2LG69wl7xww8/GL3kyRY94hn7yLDe0K2ikYR6jD3Z4gdwrI1GGtmSysg17deOZPQf Q7VtpfPTDyjZfoe1X9TnVEHzSZMmhXXN/PTTT6HLC3JhixYtXPNKW6LH0O+8807z3nvvGb1oLNmA QjqvN9ehJCaS+S6ENaOXk2k0sv0bNmxYUM0GTDVCWWlQFIxPFNCzAWFt7L+IUS9MtOWFF14IXp5o 52M//RG8ChDXr18/qGKDurpe7IhYfe8VELLF9tfOF8Snf+9LNJrZ/97538eC6BNtIlDcBPTfy2bN mgUvKZw+fXrwhIc9Rn3/b7rppuC/p7qfUBBAAAEEEEAAAQQQQACBdAskfqY73XtLU3s2WKLmbGAq rGk/sOmPYgurWxDLtM+rrrrKNa3RggoC+iN3tVJ5Pv10CFqmkZYNGjQwZ5xxhts+mQnlHVZwS6OX bTBXQb+xY8cGjyY3bdo0mWZcnVGjRgX99XN0upVpnMiWc1qqVCn3pvnYw9c/7gu76PoaOXJk8Kd9 y1HXjl8UnD/vvPOC4INysMamZ1DddF5v/r7tdH6+C7YN//PHH380Dz30kL8oT9P+6NxWrVq5NvT9 UbqGN998M1imUb42/YKr9OeEHcFr00J06NDBKAD9xRdfmIULF7oRwkr9oB9g/BQYhfHotn/vSxTg 9e+lSmVAQQCBvAnoyQqlxLn//vvNXXfdZQYPHhw0pNztypV+1llnRaV0yNte2AoBBBBAAAEEEEAA AQQQ+H+BrAzw+gGSRCPgbIoCHa4/au7/D98Y5X5VECbVolGBegw8t9G1AwYMiNu0AkL9+/c3bdu2 zVFHQTkFilItslFgKrbEy70ZWy92vnbt2kZ/BV3SeU4Luq/PP/+80aP2flBaoz/r1q1b0LvO0b6u P43c/c9//mOUf9bvk62sZcozqz+9AEj5ImvUqGFXB5/pvt6iGv9zJq/fhbC29N05++yz3SrlyQ07 dlchZEI/tCi1hooeo1ZeZb9cffXVLsCrH2HiBXj9EbzavnXr1kEQR9MK8shb5dJLLw0+9SOBLbHb 2uXp/PTvfYkCyv69NPYHp3T2h7YQKAqBgv5vfewx/fzzz+bpp592wV27XvdapWygIIAAAggggAAC CCCAAALpFMjKAK+fW1cv0olX9JZrW2Jz3NrlCtqMGDHCzqb0qeCQ/8KksI1r1qxplIMz9iVq1apV M998803Cx8fD2iuuy9J5TgvaqHHjxsELtDRCUyNJNXK3bNmyBb3buO0rYHjLLbeYG2+80UyZMsVM nTrVzJo1y8ydOzf406gxWxQIveiii4LApp8L1q4vyM90fhd0DP7L0TRSTvl2w0Ynxzsmm0JB65WS 4OGHH46qumvXLjdvX7amAHls2bRpU7DIBkXLlStnlDpDo9979erlqtsRwn7A1Q+quoppnlBuXTuK d+3atUEaj7Bd6AkDWypUqGAn+USgWAgU9H/rLZLuvY8//rj7Yccu149SukfrxWx2tL9dxycCCCCA AAIIIIAAAgggkF+BrAzw+sGHRKP2/OBvvBEziUa05YabW3BG+WuVB1VFgRWN5rEBHwUGlYtP/+Cj GJPOc1oYnnoZkUbsFsWo3XjHp+Cm8r/aHLCqpyCl0nM89dRTQcBRy/TiH40s7dy5c7ym0r68oL8L J554YtBnjaq3RT+s6Pj9gKpdp+/9c889Z2fNmDFjgj+3IGRC6RzCArw2RYO/H43wVoDXlpYtW7p0 Mn693O4hdvv8fFaqVMltrvtQvOIHeP0fXOLVZzkC2SRQkP+tl8Mnn3wSPEWhF635RSN2b7vtNtOl Sxfjp43y6zCNAAIIIIAAAggggAACCORXICtfsuYHHzSybufOnaEO/qhZP8jhVz7ggAP82ZSmYx/p TrSxXg6mlz7pH3m26KUreskUxQQ5g61Dfs+pbae4f+oFaj179gxGrtpRpLHHrEC08ie///77QU5n u/6rr76yk4X+WRDfBQVQ9WPPwIEDg+PRiFzllNUo5UWLFuU4xtGjRxt/ZHOOCiEL4r1szQZp/Ze5 XXDBBUaBHVt69OhhJ6Ny8BZGigb/3uffE12HjAnuoV9//bVb5N9j3UImEMhigYL4b71+RFKKnNNP P900bNjQ+MFdPaXz3//+N7j/aNQuwd0svnjoOgIIIIAAAggggAACWSCQlSN4FSBS8EQBHQVplCoh bGSdXj5lix4PDysvvviiufPOO8NWJVymRyz1D7hUy5NPPmkUXLKPTCvgO2HCBFOyZMlUmypW9dN5 TgsaRqNClZ5BL+BSwEw5Vy+88MKoUcgF3Qe1P27cOPPggw8Gu5KfggiJypVXXmk+/fTToIpe9lfU Jd3fBaVGsEUj5G0Ad86cOSY2RYsNBKu+RtnHuz9o/fnnn+9G47711ltGuXn9Ykfw+ukh9t9/f/Pl l18GL1s79thjzZlnnuk28XPw2uCwW1kAE8cdd5xrVYH+a6+91s3bCd1DrZfurbqeki0aqaw0N35K C6WjUNC9OBWNcB42bFgQ0NM5bdeuXTCCPy/37nTfQ9LZt+J0zvxjSed/6/WDmp6C0Iseda/xi/6/ yB133GH0I09erg2/LaYRQAABBBBAAAEEEEAAgaQFIlla7rrrrogxJvjr1atXjqNYv369W696a9eu zVGnoBaULl062HflypVDd/HJJ59E9a1fv36h9eIt7Nixo9t+7ty58aoltXzevHmuLbWb19K5c2fX TqrHY/dZWOfUnh9dFwsWLLC7T/rzhRdecMdqr0G1uWTJkqTbSEfFgQMHun5Uq1YtsnXr1oTN+vVT Odf5ud6sdTq+CzNmzHDHe8UVVyQ81gkTJri6w4cPj6q7cuVKt65OnTpR68JmRo4c6erXrl07R5Xq 1asH65NpSxs/9thjrr133303R3v+goULF7q6utbyUtasWRPVxrp163I0o3uovZbD7qc5NvAW6Nza be3ns88+69XI/kl9t8qXL5/jOG+77bY8HVw67yHp7lueDijJjez9QNdJXu69Se6mQKvNnDkzEnbN N23aNDJ+/PgC3TeNI4AAAggggAACCCCAAALxBLIyRYOi11dccYULYvfu3Tt4YZlbYIzp1q2bm9Uo 2YMPPtjNF/VEgwYNzPXXX++6ob7qjdu7e8mGc6p0IBq1FVs0+nH48OGxiwt03n9Rj0aRaURhvBGh Gu2ul5DZct5559nJIv0siu/CkCFD3DFrVHNuRS/Rs+kW7MvW/G1segw/t66/Pnbaf7ldvPMVu01+ 5jUat1OnTq6J7t27u2lN6GWPuofacvnll9vJXD913dmnEWxlXZeptGG3y+RPXTNh+d71Yj5/5HIy x5Due0g6+5ZM/3f3Onq5o3/Nt2/fPniK6KOPPjLnnHPO7s7D8SOAAAIIIIAAAggggEARCWRligZZ HXPMMaZ58+Yu550ekVeqhapVq5qhQ4dGvcH6mmuuKXBe5TTV49sbN250jzrrH4EKpij3n/qgvtmi R+vfe+899w9FPdLcpEkTc+mll5pTTjnFVgs+9Vi1HsdXvj8VvczFFgXt7AvK9Fi4HtO3wShbx/9c tWpV8HI3G6zQvC1q1w/+nH322aZt27Z2dYF/Zto5jXfAsY/k2nqJXmBl66Tz0w/wql09Jq9gpF6e VqdOHXP00UcHQamPP/44CODZoISujxYtWsTtSn6vt3R/F/QyNOWq9tNK6PvgX6uxB+PXtesUnH33 3XfNgAED7CIjm/nz55uKFSuaf/7zn8ZPs7BgwQLz9ttvm2XLlhmbhkEb3nDDDUHahuOPP95MmzbN fYeVtkN9KlOmTPADU9myZd1+NKFUBqrzwQcfuOV6bHzu3Lmh9V2lNEzo/qPAlMqgQYOM7hX6QUBO DzzwgNuD0iqkknrm888/d9vaCeWFVvvFqfj3ydjjUpB+3333jV2ccD6d95B09y1hx1lpFNDV90b3 2A4dOgT/XwQWBBBAAAEEEEAAAQQQQKDIBeIN7c2G5Xr0WI9F28eCwz4HDRpUKIfSsmXLhP3o0aNH jn6MGTMmxzatWrXKUS/suOItyy09Qt++fXPsM15bWp5sSUeKBu2rMM5pfh8TrlevXqhhYT9yPGXK lNB+JDqfOvbZs2cnPK2Jto9dF3a9pfO7sHTp0pSPMbaPI0aMCI63bdu2CdsaPXp0lEvXrl0T1o/d jz//+OOPR7W1ffv2hG0988wzUfXtTDpSNNi2/BQdfl/ttO6lqaay6dSpU9Rx6fpKtQ3bv0z+DLtX y61Lly556nY67yHp7lueDijJjfJ7701yN1RDAAEEEEAAAQQQQAABBHY7gaxN0aDIuB491gvL6tWr Fxoo1xusNcKmMIpGTsYrGjGpt2zHlsaNGwejaf3ljRo18meDaY0YSqZoRGfs6N/Y7fSyp9iRn7F1 7Hyy+7X10/GZSec03vHoBV2XXHKJW129enWjUaYaMVuYRSOebdE51YiyRKVHjx7BSNhatWolqhaM UEtY4c+V8a63dH4XDjvssKgXlCXTL79O5cqVzamnnhos0gj5eEX1Ykeu6rsY77uiunr5WlhRW7Vr 145apZHBGqUfVpI5d2HbpbpMaRo0Yjis6B46ZsyYlFPZ+KOR1e5NN92Uchth/cm0ZbpXP/XUU0bf dVt0f/TTntjlyXym8x6S7r4l03/qIIAAAggggAACCCCAAAIIZJZACYW0M6tLeevN8uXLzWeffWb0 mLwCXQp0+o9b561VtkpWQHmOFVBX6devX/AYe7LbxqtXUOf0wAMPdGk09Bh+XgOzyru7bt06U6VK lXiHUODLX3rpJTNhwgRz3XXXmbp16wYBXKUiWLx4cZAuRH076qijzHHHHedSeRR4p9hB2gT0KL9/ fabjdr19+3YzY8YMo1Qahx56qFEqlsMPPzzlPiu1hR/wVANK/VKuXLmU28qmDfTdkptS7+S3pPse ks6+5ffYwrZP1703rG2WIYAAAggggAACCCCAAAK7s0DW5uCNPWnKoemPqoxdz3z2CWT6OdXIy3gj PAtL+6qrrjL6s6VGjRpGfxQE4gmUKlUqGBWt0fz5KRMnTozaXDmMi3twVwd8xBFHRB13fmbSfQ9J Z9/yc1xsiwACCCCAAAIIIIAAAgggULgCWZ2ioXCp2BsCCCCAgBXwX/aoZUrPQEEAAQQQQAABBBBA AAEEEEAAgcIXKDYjeAufjj3GExg3bpwpWbJksFp5YpUjsiiL3jI/atQos23btqAbeiyagkA2CijX s8ree+9tWrRoYZTfu6jK5MmT3a6VIqRSpUpungkEJMC9l+sAAQQQQAABBBBAAAEEECgcAQK8heNc 7PdSokQJd4zDhg0z+rNl5cqVRZr/9f777w/yAtv+8IlAtgj43yv1WYFUW2688UbTt29fO1von926 dTO9evUK8lnfeuuthb5/dpj5Atx7M/8c0UMEEEAAAQQQQAABBBAoHgIEeIvHeSzyo+jQoYOZMmWK 2bBhQ1RfTjzxRFO2bNmoZYU906xZM/Pxxx+bTZs2Re26QYMGpmrVqlHLmEEgkwR0fXbs2NFMmjTJ jUBX//bbbz/TqFGjIu2qUjJ0797dbN68uchzURcpBDuPK8C9Ny4NKxBAAAEEEEAAAQQQQACBtAqU iKTjtexp7RKNIYAAAggggAACCCCAAAIIIIAAAggggAACCCQjwEvWklGiDgIIIIAAAggggAACCCCA AAIIIIAAAgggkIECBHgz8KTQJQQQQAABBBBAAAEEEEAAAQQQQAABBBBAIBkBArzJKFEHAQQQQAAB BBBAAAEEEEAAAQQQQAABBBDIQAECvBl4UugSAggggAACCCCAAAIIIIAAAggggAACCCCQjAAB3mSU qIMAAggggAACCCCAAAIIIIAAAggggAACCGSgAAHeDDwpdAkBBBBAAAEEEEAAAQQQQAABBBBAAAEE EEhGgABvMkrUQQABBBBAAAEEEEAAAQQQQAABBBBAAAEEMlCAAG8GnhS6hAACCCCAAAIIIIAAAggg gAACCCCAAAIIJCNAgDcZJeoggAACCCCAAAIIIIAAAggggAACCCCAAAIZKECANwNPCl1CAAEEEEAA AQQQQAABBBBAAAEEEEAAAQSSESDAm4wSdRBAAAEEEEAAAQQQQAABBBBAAAEEEEAAgQwUIMCbgSeF LiGAAAIIIIAAAggggAACCCCAAAIIIIAAAskIEOBNRok6CCCAAAIIIIAAAggggAACCCCAAAIIIIBA BgoQ4M3Ak0KXEEAAAQQQQAABBBBAAAEEEEAAAQQQQACBZAQI8CajRB0EEEAAAQQQQAABBBBAAAEE EEAAAQQQQCADBQjwZuBJoUsIIIAAAggggAACCCCAAAIIIIAAAggggEAyAgR4k1GiDgIIIIAAAggg gAACCCCAAAIIIIAAAgggkIECBHgz8KTQJQQQQAABBBBAAAEEEEAAAQQQQAABBBBAIBkBArzJKFEH AQQQQAABBBBAAAEEEEAAAQQQQAABBBDIQAECvBl4UugSAggggAACCCCAAAIIIIAAAggggAACCCCQ jAAB3mSUqIMAAggggAACCCCAAAIIIIAAAggggAACCGSgAAHeDDwpdAkBBBBAAAEEEEAAAQQQQAAB BBBAAAEEEEhGgABvMkrUQQABBBBAAAEEEEAAAQQQQAABBBBAAAEEMlCAAG8GnhS6hAACCCCAAAII IIAAAggggAACCCCAAAIIJCNAgDcZJeoggAACCCCAAAIIIIAAAggggAACCCCAAAIZKECANwNPCl1C AAEEEEAAAQQQQAABBBBAAAEEEEAAAQSSESDAm4wSdRBAAAEEEEAAAQQQQAABBBBAAAEEEEAAgQwU IMCbgSeFLiGAAAIIIIAAAggggAACCCCAAAIIIIAAAskIEOBNRok6CCCAAAIIIIAAAggggAACCCCA AAIIIIBABgoQ4M3Ak0KXEEAAAQQQQAABBBBAAAEEEEAAAQQQQACBZAQI8CajRB0EEEAAAQQQQAAB BBBAAAEEEEAAAQQQQCADBQjwZuBJoUsIIIAAAggggAACCCCAAAIIIIAAAggggEAyAgR4k1GiDgII IIAAAggggAACCCCAAAIIIIAAAgggkIECBHgz8KTQJQQQQAABBBBAAAEEEEAAAQQQQAABBBBAIBkB ArzJKFEHAQQQQAABBBBAAAEEEEAAAQQQQAABBBDIQAECvBl4UugSAggggAACCCCAAAIIIIAAAggg gAACCCCQjAAB3mSUqIMAAggggAACCCCAAAIIIIAAAggggAACCGSgAAHeDDwpdAkBBBBAAAEEEEAA AQQQQAABBBBAAAEEEEhGgABvMkrUQQABBBBAAAEEEEAAAQQQQAABBBBAAAEEMlCAAG8GnhS6hAAC CCCAAAIIIIAAAggggAACCCCAAAIIJCNAgDcZJeoggAACCCCAAAIIIIAAAggggAACCCCAAAIZKECA NwNPCl1CAAEEEEAAAQQQQAABBBBAAAEEEEAAAQSSESDAm4wSdRBAAAEEEEAAAQQQyKfA0qVLzQ8/ /JDPVgpm83Xr1pk5c+aYrVu3FswOaBUBBBBAAAEEEECgwAQI8BYYLQ0jgAACCCCAAAIIIPA/gR49 epgqVaqYv/zlL+bBBx/MKJY333zTHHLIIaZWrVqmZcuWRdq3LVu2mB9//DHH3+LFi00kEinSvrFz BBBAAAEEEEAgUwX2zNSO0S8EEEAAAQQQQAABBIqLwOjRo92hfPXVV246EyYmT57suvHFF1+46cKe WL58ualUqVLc3T7zzDPm+uuvj7u+MFeMHTvW6G/MmDHBbs8991zTqFEj07hx48LsBvtCAAEEEMij gP6b8/777wf38ilTppi//vWvpkmTJub88883hx9+eB5bZTMEik6AAG/R2bNnBBBAAAEEEEAAgTwK /PHHH+ann35Keut9993XHHPMMUnXL8iKO3bsSLl5bTNgwACzceNGc/XVV5sDDjgg5TaS2eD3339P plqB1FGaiEQlt/WJtt25c2eQHkOffjn22GPNPvvs4y/Kdbpnz545RmHPnDnTPPTQQ+buu+829957 b65t+BU0ann+/Pn+IlOyZElTo0aN4DNqRZbPKKAya9Ysox855s6dG4wcP/LII81ZZ51lTj31VPPJ J5+Yn3/+2Vx88cXmoIMOcke7aNEis2HDBjcfO7Hnnnuavffe2xx66KHm4IMPjl0dNa+R4AsXLjSb N2+OWq7roGrVqqZUqVJu+apVq8xvv/1mdu3aFSwrUaJE0GcFf/bY438Pw6qdBQsWuG3CJsqUKWPK ly9v1M/cypo1a8yyZctyqxa6XvuoUKFC6Dot1LFrhPzXX39tZsyYEfRb3wHZn3TSScHx6xhTKTL6 5ZdfojbRuTviiCOiliUzM2nSJDN16lQzb948o3OuY6levbpp1qyZ0Xd38ODBpnbt2qZTp045mlMf 1Be/6JzqXNn7pf67Idtt27ZRdfLDAAAgAElEQVT51YL9yC5RybTvqb4PK1asyHEsOgY9kVG5cuVE h5NwXV6/p7/++qtZuXJljrb1XalYsWLQL60Mu2Z03ela1Pc4UQnbNi/Xm+4BdevWjbp2hw4davSn a0E/dh511FGJupJjnZ40Wb9+fdRyXcO5XVtRGzCDQH4EIhQEEEAAAQQQQAABBLJIYP369XpWP+W/ hx9+uMiOsmXLlq6/N910U8r9mDJlitv+lVdeSXn7RBv07dvXtV2zZs1EVQt83bBhwyJPP/105IEH Hgj+OnXq5PqmZXktzZs3d+341079+vVTarJ379452ildunTUsvvuuy+lNtUHv092WtdMcSnLly+P NG3aNPQ47fH6ji+++KI79CFDhiTczm5vP6tVqxZ58MEHI7/88otrw5+49dZb47Z3/fXXu6rz58+P W+/JJ58M6u3atSui/dl95/ZZvnz5SPv27SPTpk1z+/EnFi1alHRb8fa1ePFiv0k3/dtvv0VatGiR sP1WrVpF1qxZ47bJbeLLL7+M29748eNz29ytnz17diTedzTsODdv3uy21USifui6Uv1169ZF/Gss tt2ZM2dGtRk7k0nfU32fYvsfO//GG2/EHkKu8/n5ni5cuDDXPukc6FzH9tXO16lTJ2EfE53nVK63 n3/+OVK5cuWofui7afuhT62P910K66T272/vT3/xxRdhm7AMgbQLkIM3P9FxtkUAAQQQQAABBBAo dIHY0VfJdkAj44qqaPStHuefPn26eeSRR1LuxurVq902GiWVznLttdeaCRMmBH9ffvllOptOua0L L7zQdOvWzWiUrP6uuuqqlNsI20CjFcOKHdkXti52mV6Q16tXL7dYKSN0LercaNoWjeLNbUSnravP eH0o6nPh9zE/0x9++GEwGtlPUxLWnj963B/Bmur3XSNU77jjjmBU8Nq1a3PsKtF9QKNGbUn0wkFb T6NKU/k+apSpRqGedtpp5oILLsgx+lKjmvNbwl7kqNGINWvWNKNGjUrY/IgRI4IRshqRnkwJ25fd LreRmLbetGnTgn3qOrGldOnSwchdOx/76d8Ptc6/dmLrap1GVWr0cqJ6YSNP/bYy6XtqR5T7/Yud vvPOO93I89h1YfP5/Z4msrX702j4TZs22dkcn7FPMsRWSMf1pjZ1j9ZLT1X0vdDIW40M1vda8ypa f8899wTTyfxPous9Ub+TaZs6CCQrkPszIsm2RD0EEEAAAQQQQAABBApBoGzZsmb8+PHBY7zbt293 e3zxxRfN7Nmzg/nbbrst6hFV/eNcefWKqpQrVy5t+Vlj0wzk95j0GPPZZ5+d32ayZnvlXNRj3nok WI8NJ1teeeUVV7Vr165R+YCVG1iPvesaVBk4cKB54IEHXP1EE+qPHolWAErXb1Fep4n6mZd1Ojb/ xX3VqlUzTz31VJASQI8uKxA+btw4c//997uAi/bjB7D+/ve/B49uK6inALsCgirPP/+8y9msNAl6 XF0/oowcOTJYr8f8W7VqFaR9UMoLW5RCQ7k2tb1tS+uGDBkSBIVtveOPP968++67pm/fvmbixInB 4vr165vu3bsH+Za1QCkX1P9vv/3W6PF//ShhA13aTuuVXkWB3SVLlhgFUO169fMf//iH6d+/v92l URoAW9q3bx/0085/+umn5p133glmW7dubRo2bGhXGf0Y8NprrwXzfhtaoFQ2Ol5bFDx99tlnzZln nhk8gq6AuFIj6EWQ6psCW6ecckoQ9NKLIZMtyl2qH7JUtI/cUmWonsyUu9oWtfHYY48F308t03nV cesasG5arnQtfr7uBg0aBOdv0KBB7vy3a9cu+C6dcMIJLm3F559/HqQI0Q9aOt8quj6vueaaIPdq sCDO/2TS91THrhzgChzqu/LBBx8YP0CuQ9B51XGec845cY7o/xen43t64oknmuHDhwf3MqVaUaoD FX0H9cOdzsPRRx9tdA/QtdqhQwfXAS276667gpQJbmEuE3m53tSkfuDRdWKLvuP2OldaEc3rZagq L7/8snniiSdcagm7Tdin0j3oByV7nXbp0sXlaA+rzzIECkQg7WOCaRABBBBAAAEEEEAAgSIQ6Nix o3tEcu7cuUn3YOvWrZFNmzYFf3rk2pbff/898tlnn0VeffXVyOeff57So8tqY9u2ba5d276W5aW8 //777tjSkWpix44dOfq2ZcuWvHTNbbNq1arIJ5988n/snQe8FNX1x68aNdHYW1T+djGxECX2LhZU NIgIVqwxQSU2xEJUJLZEY0dFDRKwxoINYxRbjIgVBbEEIWDDggVQEFHY/+c7yZmcnTdb3+6+3fd+ 5/PZNzN3bpvvzNx9e+4552YIszB06NDMiBEjMuPGjcvMnj07zlPqDtzN1bU5IRq8+y19KlV4Rrx7 N+77SfEu/eSlTKlC3+x66XMjy9dff53lBt2tW7fITT7tmnAN93z79++fli3Ts2fPmM+UKVNS8zz6 6KNxHljiEp4muOQba7ZpbtS49vsQDBMnTkyrKk5r3759XOd3330Xp9sO4WUIA+Hb9aEBfDgK9r3c fPPNcbkhQ4b4U5m77747Pse+F8+M/uFKnyY8v77/jKeFhLHRrqV79+6Fsjc5f/vtt8flt9hiiyiU QpNMmUwGl3r/fIwePTotWxTexfpz6623puYh0bd79dVX58yX60S9vaf+Hvft2zdmSjiQQlKN95Tx 3+7D9ddfn9UF3ikfsohn7oMPPsjKk+uguc8b9Q4aNCju2xFHHJHaFOnW/2uvvTY1T6HEHj16xHVU OqxSobZ1vu0SUIiGqqjNVakIiIAIiIAIiIAIiEAjEMBNGtfKJZZYIvpstdVWkXUYi/hghYZl6+GH Hx5Z9rGA08UXXxxZ5BW6tvPOOy8stthicb1WP2lYXhUjWOJh9YclFlsTXElJS/uwCFshwU2bRXis T7bFkrfUBcJoa/DgwQFrRywysRbDuvCoo44K+++/f8Cq6yc/+UmUp5zF5QpdS63Os/CTWWZhbZa2 YB9pnEPIS5mWEkIcXHPNNdHHPzu17A+LzpkbNIsM3XbbbVkLp/m+sBBWv3794qTmPCt77LFH6NGj R1zXc889F+/7nc022ywcd9xxcVLfvn0jK+o4IYTI2pj3DDnzzDMjS2J/vtT9pZdeOlx11VVRiAYr i+W3iQ8LwXtZrLCIpIm34MUy1yxVOX/nnXfGz6jlty3Pr7dsZL/aYUKw9DRh8UjGoDRhIb5TTz01 PsU4KvkPASzb7R537tw5siI3NoQDSS6AZ+dsW8v3lPAMfC+YlT3hELAy9tbY1q9qbbHQNdlrr71s N2vbpUuX+Nis5uME7YhAHROQgreOb466JgIiIAIiIAIiIAIiUD0CKJFw//WCy/YGG2wQvDu+P48L 9umnn+6TUveJeZlLTOmV6zzpuK6jtMFlFLdWr4jCZZS0tA+hKPLFGKVu3MlNWZnsA+7cpQgKI/r2 5ptv5ixGW+TBDb9RxceE9T/+k9fjwyv4Msl81Tw+//zzo/AkuNzz4Rnyz08127a6cVX29xslkldC Wj6/PeCAA+JDQpo0R8zlmjryxbVlQoOJHARlqFf+EDaDUC8ICmri+lZCCNuAe7mJV/B65WwuZaeV 81vP1teBMtkE5R9K7Xyy5ZZbZoV+YKyplcAlnzDuXnTRRWHQoEFRCIl8edvSOQuFwDUzMclEJFsT C91hx35by/eUyUdCNVgoiY4dO0bKXSYAaylTp06Nm9tpp53ifb/jQxb5/D6P9kWgHglIwVuPd0V9 EgEREAEREAEREAERqDoBFApYPqG09WIWT8TARJmAcqp9+/ZxFmJr5lMakfGyyy6L6j3llFMCHx8v M64oz04uBWyeIvGpQorFo48+OlKUWN+OOOKIuGypOyxOY4KirHv37pHVKJZ5sN1uu+3sdBg4cGCY PHlyfNxIO8R3NckXt9ef82WsbLW3KPfTFgbCyrrQAkaV7FtyUaFevXoVrP5nP/tZFBuWvCgjyxVi VFvMXOpYa621clZFPG/ebxOUiGZFyyJVJrzPWN9WSnwcbWIvm1jbHC+55JKWXHDrrX193ePGjYvL YiFbjBBP2sQrny2tkttNNtkkro6JCZTquYRrRMl+wgknRPGzc+Vra+kW95vrtnjXxBQ2YQFIH9Pa 0tnW6j3l+4zJL2JkIywyiCcL71+txSzyaTfXRJJP9/lr3Ve1JwKlEsg/TVZqbcovAiIgAiIgAiIg AiIgAg1EYM899wx8WBzGW6FizceiKSYsrMQCS7a6PD9UbSEWy+O3hCzwi2xh6crCcMXKpptuGilI CceAvPLKK9GCL+yj/PKWor5O+uSVJv6c7fOj2lsj4sKfy2LZyuTaojQixAWKTSxbvaKJMih8WQDJ FG7PPPNMZHmcq756Tf/444/jrmEhl0v8uZZQ8OabeGCF+PXXXz9X1yua/tZbb8X1YalXyDrTMmNp 3BxrY9zVUXD7xdN4/vIJzzBKMN5/lDkow1mUjAWWEJRRTPZUSrCwNRd16sQS32SZZZax3Si0SXxQ YMdbQa6wwgpRbhagZKE5k7XXXtt2824tzAiZKI+nQ7H3L2/FKSf9AmCwx1W/d+/eUUgcFP5YYjNe sSBiqeLDPyTL5juXzFvPx6+//nr8ncTEnU0KsIAe4Q/smc612Fot3lMmnQiFwHcqwqQfi8JVcsKk 2HvE4nwmTEj6xRctne3CCy8cWfbbRCuWzoQ1kohAvROQgrfe75D6JwIiIAIiIAIiIAIiUFMCxJ70 yl0aR3GJ4ggXU8QrTqrRORQaPo4ocXNN4YQ1cJ8+farRbMl1LrvssuGkk07KWY4fyieffHKs4K02 t5wdaeYJb1mY74c+PExaQsHrQxNYP9iizCC+dK3EK47S4hVXoh/EZDWFOooYLNdNiWT1Y41KHOh8 gvISBa8pG88555wsyz6s+HmOKyE8R8T69ZNJPjQF+4RmQGGbz/I42Rfy4vr+zTffRMo0zqPQ99Ku XTt/mHM/mQ8X9Wrdw4033jjydoCJCQp2Pl66du0ahbU49NBDg3/HfJ7k/pAhQwKf1iw+/MJhhx2W damMy2bJ++c//zl+vn2mWryn3hKetnmXCAVU6L30/azU/vTp0+OqvJVunOh2iAtuCl68evKN+66Y dkWgRQlIwdui+NW4CIiACIiACIiACIhAvRFg4bU0wSrXpFAYBMvXFrZff/11tDgTVs0olQgFwA9j lIpYjPr4oC2h9KzEPfDX4N3ok3XPmzcvTvJl4sQq76DgveSSS5rEif7Tn/4Ux5qtchei6v3CbjwH 1ZD77rsvb7WEW/BW9PkyY+Xbs2fPyGqeZ9cUO1hFEpe2HGFCCOUxIROwxCecibmoW30sxugXmEK5 6xW+lq+YLZ4IXj777DN/WLSCKqnIMhZZlVXwAEU9CmS8Crzi2zfxwAMPBD7ETGaiK9fiWL5Ma9/H Qvv666+PLpMY0T5uLIkHHnhgrOBlsTVCC5HPSy3eU98e+3hz4KHyxBNPlBy6KFlXqcd4m5j4sdrS /JYF4UxaYiy3trUVgVIISMFbCi3lFQEREAEREAEREAERaNUEUEblch0112cA5Ipp2KrhpFzczTff HFnopimBSLOQFla0Ubl5JZx387Xrsq0/5+Px2vlabPv16xdZeBPjEkvwXXfdNUvJXos+eDf/Uhfu K7Z/tIFCNE0piKV4qeEoUIwTN9qLXyjOpxezf/HFF+fMxjgzYMCAyJo3Z6ZmnkhacxNmJGmdm9aE hYWxc4UsHS1fc7ZMqvFhAchnn302EPuXcCPcW4uJTv3s77333tEkUiGrYvjnUpbfe++94cwzz2xO l1u87KOPPhpPRCy22GKBSZyk8JzZ2Iy1L8p0L7V4T2mPRQV32223aOFF6w/jEpOBhe6j729z972C u9Bip/68L9fcPqi8CFSTgBS81aSrukVABERABERABERABFoNgXLiQLaai0+5ECzqjjnmmKwzLPKD 2zVKIdzF+QFPvEWvpMkq0CAHPsYpcV5ziT+Hi29LCRZntuBSS/SB+KkmEyZMsN2KbrEAJDQBFtU8 Y/vvv39cP0puLHxLeWfXXHPNaLLiyiuvjOpBQdice2iWy9wL4sgSAxelKxbBBx10UNWV7skJBhRW xSh4vWILEMl6YshV2MFLwntK0ARxZq+77rqssA1Y8g4fPjxvD2CdS3m4xhpr5C3bCCctZA995Z4V UlgThoRwOT7cSC3eU2Kzo1DHepb42hxbTPZjjz02suT1faomeyaEvNKbscNb9Vrb3kuD/JSTiEAj EJCCtxHukvooAiIgAiIgAiIgAiIgAv8lgMt3PQiLU5kQI5PV3NOs/VipPd+CdFZHPW+9oi/NYtT6 jgWiiS9jaW1lu8EGG8SXinIfLknFXZyhmTsoaLp16xaFCenVq1dUG5MPWCzacbFN+PAEpVoAJ9tg calqLU6WbCvtGOU2C8TZgnMo2ll8q5CgUDVhgbxqKt9scbvTTjstUoBbu37LopGEIsCKnvjIyAsv vOCztLl93imUpqUIi9glF1urxXvKgqCmREVZysQLC8BxDU8//XSkqD/yyCNLuZRm5WWiZfz48VEd TEAyIZmUSZMmxUnFLk4YF9COCLQggcpEi2/BC1DTIiACIiACIiACIiACItDaCXgli7cSbanrxmLM rHKxCrznnntSlbv0LxkLtKX63Jx227dvHxfHjT8tfiNp3sXfl4kL12AHy2kUnMTg5DNixIjg40nW oAtNFPrJhZaq0QcWmSKOrskJJ5wQCEvQlsUvrHfppZdG8YDz8WDyiHwmvrylVWrL+MFikVjn/va3 vy1YrV9ErFEXayx4kUVmuPvuu+OcN9xwQ8hkMjk/PnTDjTfeGJdjJznxVov3lFBHLFxocuKJJ4aZ M2faYdW3HTp0iNt47LHH4n2/Q/gLk5ZYDM7a1lYESiUgBW+pxJRfBERABERABERABERABGpMgBiL Jn5hHEtLbr///vtkUkWPJ0+eHNeHhV0uS0WUnl5hFBdqsB0s3bz1o7kY+8vwadttt13w1nE+X7X3 f/WrX4X99tsvUjajcO7evXsUh7faz4S/Liz1WNTJBIXzQw89ZIc5t88//3w4/PDDw5133pkzT74T 11xzTbyYHLE+USC2ZWGhOROUooUWprv//vuDV56eccYZVrzi21mzZsV1Pvzww8FbTcYn3I5/ftt6 TFSvqOX9zifeip33yibmKNNS7ymxkRkjEd5T4l/XSjwPJr/SxKcfccQRaVmUJgJ1SUAK3rq8LeqU CIiACIiACIiACIiACPyPgI+DidJu+vTp/zv53z1CB7AS/SqrrBIWXXTRgLKsWuLdVh955JHw4osv Nmnq1VdfjRbWQbnXGuQ3v/lNfBnHH398+Prrr+Nj9kkz6d27t+3WdIsb9u23396kTZ4F73rfJEMV ErCgxRXbhEW0iGubttAe/YbvNttsE4Va8OE/rHwxWxR/Q4YMibPixl6qK3tcuBXsEId24MCB8ZX0 6NEjPPjgg/Gx3yHdL0rGInDEJa6W/PjHP86qunPnziHX5BXKXcI4mPh4y5bWVraMqxZigNAkfvHP NAa8E16pSegSLy3xnhI+xCt1L7rooiiOsO9XtfZZ3M1iUY8ePTqwUKgXjklHyLfLLrv409oXgbom oBi8dX171DkREAEREAEREAEREIEkAdxRcevF4stbdT311FNxVmI1oug0WX755cMhhxzSxKpy5MiR 4bnnnotWaycv1kR9+/aNrDVRhiAopIgva7EsSRszZkw46aSTwl577RX23HPPKB9/pk2bFv785z83 UcCOGzcuzsP5V155JT5mBwvYo446Knj3UZ8BV1pWPEcRhhAbkx/mSy65ZOSGjuVdMjYscU+91Snu 17jGJi3liBVq8vjjj6e6S7MKOgo6ExRH/Pi1BZlw5SbeJwvoEA6AH8j2I9nKsOUenXLKKdHCTWy9 5S+KYlxm/T2dMmVKXPyvf/1r+Oijj+JjdlBks1CPXywoK0MFD1B+4U7MM4KVI3GHOUauvvrq2PIR qzgULy0h+cJheIvJWvSNe8N7Y5Z6tNm/f//o/dhhhx2iZx2WxFPl3nvxVomffPJJwGLRYnZaPiYz mPjgPuy4446WHHhv4W/WqrxXzz77bNQPr8CkwNixYyNL59mzZ0fln3nmmbge3hVihCIsknb00UdH i6TFGf67g1WkPeve+pVnY5FFFolywYLxZ/PNN08Wz3mMIo9n3vrGsQlKKDsmfAtWhowJacJ4NmzY sHjsgBfvDMx4j1Gqct3cKxPeba9QtfRKbnlPvDC2bbvtttFiYb/4xS+i54OJE8ZKFlXzE1ZYqXvh OUKx7yc3CF3AxNNmm20WLMYr9wrlKM+DyS233BKFCOB663kxLSb1WFjNT5gxxhPegkXjDj300KwF 8WDCfSfOrP/++eMf/xh4p5hQ4TulUu8p4zYW9NxHezZhTB/eeuutaLLHT5Jxr3kW7Xp4b/meYaLM L2pp96lSW95JvrtZiBFhoVDYMk7xXDCumPDu+PBIlq6tCNQtgYxEBERABERABERABERABBqIwKRJ kzIhhJI/ffr0aXKV+eqZNWtWlH/8+PE521p55ZWz6vz973+fM2++tjjXq1evrLqSB+PGjcvQXqF6 ON+lS5fMzJkzs6oYPXp0UWXT6k9eJxU/88wzRdV3wQUXpOZ76qmnsvqX1m4xaccff3xWPWkHnhsc y5WxY8dmllpqqdTroa+ca079lLVrTmNeqN+ff/55XN7qYbvOOutkvvvuu0LFq3L+zTffzHTo0CG1 X76Ptn/uuedm9fXyyy/PW7Z9+/ZN+j1t2rTU+7RgwYKsvPvuu2/euq1PbAcOHJhVlgOY+jz59nff ffcm5fMllNK3bt265asq88UXX2S6du1aVF9pl+eoGBk+fHhcZ/fu3YspEufhXuTjlescbSblrrvu ylvXxx9/nHn//ffz5hk5cmSy2pzHzX1Pc1ac58S1116bt/9nn312Vulbb701b/7+/ftn5W/ue1rM 9wvf3V5oM3mfr7jiCp8la785z5uvaP78+ZljjjmmSdu+L717986Qr1zp0aNHXP+wYcPKrUblRKAk AgrRULeqd3VMBERABERABERABEQgjQBuw1iLliJYi2EVlhTvuurPUb+5EK+77rqRpZM/zz51ektD 0nbaaac4Bmgyf6Fjb22blhfrXiyMcGVOWr+Rn/O4umLJi2Xy0ksvnVWNWQFnJRZ5sMceezTJiRUm FrneDd9n2nfffSOrVhbu8bFAyYPlWHIRMqwKSxU4lPoslNqGz4814BNPPBHSYoCShsVnLitsX0+1 9rFUZ4GgnXfeOW6iU6dOkXWjt5aOT9ZgB+tqrHSJ55rGzbqARTfWpIQU8H0lbEPa827l9t57b9uN t6uuumoYNWpU7IrNCSwEcQ33wrtUjGDRyr1PCv3ECrGQ0H/GhlLEewYUKrfbbrvlzbLccstFFs2X XXZZznvAvcFtHm8AnqNqC/fCvyt4Q+QTvAOwuE4bs7FezvVsMU4ts8wykXWrtyb3bVF2vfXW80l1 t5/vPeD52nTTTbP6jFcFz22akD9p8d3c93T99dfP2R59YJxO3iPa9CFE6FcpVu5p11ZMGla5WHjn CgVz3HHHRd4ust4thqby1BOBhVAH11OH1BcREAEREAEREAEREAEREIH8BPgX/r333gvvvvtuWGml laIf1vw4bgnBNZdF1wj9wA9ilLcoS8w9vSX6lGyTcB22uBDuyl6xlMxbzDH833777ShUB/lRHKGw TioQi6nL58F93FZtRxmCK3W5YnGaeT7qST7++OMwYcKE6HnBFZvnhUkUwo1IakPgww8/DK+99lpg u/rqq0fKQbalCuENWBQPYbLrnnvuKamKf/zjH1HIDlzzqYd3lFAMKPp5fnkHiPeN8rCeFLCVfE9L AlbDzPX4njb3eUvDRygLQqzw/cUYTugIm9xNy19sWs+ePcPdd98dZSdMhb0nxZZXPhEoh4Bi8JZD TWVEQAREQAREQAREQAREoAUJoEjEkrmaiyAVe3lYMW6wwQZN4hsXW74R88Ef6zM+9Sr1ptg1Tih1 +RSyOrX82laeAMrcchS6le4JVs3eshmFro/1Xen2VF/xBNrKe8rEaCnW8sUTVE4RqD0BhWioPXO1 KAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIVISAL3opgVCUiIAIiIAIiIAIiIAIiIAKNQOC2 224Lzz33XBROYfvttw8bbbRRi3abcAW4CBP2YerUqS3aFzUuAuUSeP3118PgwYOj4sT83W+//cLi iy9ebnV1V07vaX3dknp73ubOnRvFr54xY0YEilBAEhGoNQEpeGtNXO2JgAiIgAiIgAiIgAiIgAjU lMBiiy0Wt8dCUiYsEPfGG2/YYYtsiV06ceLEFmlbjYpAcwj4mNM8wyxOZTJixIjQrVs3O2z4rd7T lr+F9fy8sbDpwQcfnArJ9zs1gxJFoEIEpOCtEEhVIwIiIAIiIAIiIAIiIAIiUJ8ETj/99GhV9Dlz 5mR18MADD8w6bomDQw89NLAIz7x58+LmUUj36dMnPtaOCNQjgU6dOoUddtghTJkyJat7xNJt7kKG WRXWwYHe05a/CfX8vHXs2DHwscU8jRaLBO666652qK0IVJXAQhl8gSQiIAIiIAIiIAIiIAIiIAIi IAIiIAIiIAIiIAIiIAINR0CLrDXcLVOHRUAEREAEREAEREAEREAEREAEREAEREAEREAEROA/BKTg 1ZMgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAg1KQAreBr1x6rYIiIAIiIAIiIAIiIAIiIAI iIAIiIAIiIAIiIAISMGrZ0AEREAEREAEREAEREAEREAEREAEREAEREAEREAEGpSAFLwNeuPUbREQ AREQAREQAREQAREQATIbAYEAACAASURBVBEQAREQAREQAREQARGQglfPgAiIgAiIgAiIgAiIgAiI gAiIgAiIgAiIgAiIgAg0KAEpeBv0xqnbIiACIiACIiACIiACIiACIiACIiACIiACIiACIvADIRAB ERABERABERCBtk7g+++/D++//37IZDIRioUWWiisuuqq4Yc//GFV0Xz++edh5syZURu0tdpqq1W1 vVIq//LLLwMfkxVXXDEsvfTSdqitCIiACIiACIiACIiACIhAnRCQgrdOboS6IQIiIAIiIAIi0DIE 5s2bF9Zdd93wwQcfZHXg2GOPDTfeeGNWWiUP/vKXv4Sjjjoqq8pRo0aF3XbbLSutJQ5GjBgRunfv 3qRpWC266KJN0ltbwvjx48MjjzwSHnvssTB16tSwxx57hE6dOoUuXbqEJZZYorVdrq5HBERABERA BERABESgwQlIwdvgN1DdFwEREAEREIFyCMyePTv8+9//zir6gx/8IKy00koBS00Eq1aUW998801W viWXXDKss846WWmNfIDSMqnc5XrMsrZa1/bRRx81qXrGjBlN0loi4eOPP05t9rvvvqtbBS/PM8+1 l9VXXz0sv/zyPqng/sMPPxz22WefrHyDBw8OfHbffffwwAMPhB/96EdZ5/MdLFiwIEycODHAzguT CvWgLJ42bVoYN25cePXVV8Pbb78dlltuubDmmmuG7bffPmy++ebhqaeeisaBAw44ICyzzDLxJbz7 7rth1qxZ8XFyh/Fk8cUXj/gvu+yyydNZx1jOT548uclYg1X7WmutlfXMffLJJ+Gzzz4LcEWwtqfP WNwvvPB/os8xZk2aNCmrjeTBCiusEFZeeeVAPwvJF198ET788MNC2VLP08Yqq6ySeo5Erp1n97XX XguvvPJK1O/1118/Yr/ppptG1881liIw+vTTT7OKcO/WWGONrLTkQVq5ZJ5cx8nnme8Pnvv58+fn KpIz/cc//nFYe+21c55vhBNz584Nb775ZvRujR07Nnz99dcR//bt24e99tor+n5lrFlvvfXCDjvs EF9SpblV8j2lk9V8F2IIdbpTzj3l/eY94P8ML4xVeOwwdnnhO2zKlCmxN5GdW2yxxQLPTqljgZWv 1fbbb78N77zzTpP+F9M+36u8D0kp9Z2A7QYbbNBkbPffHXDk/4Mkf9r+6quvwnvvvRd/x1h/+P/4 Jz/5iR2mbimX/N+R8Z/vAYkI1IRARiICIiACIiACItCmCMyZMyez1FJLEYsg9fPSSy9FPLp27Zp6 nnKDBg1qVcyefvrp6JrOPPPM+Jp79uxZ1Wv88ssvMzfccENm3333jdu8++67q9pmsZV/9dVXmaFD h2YuueSSTLt27eL+zZ49u9gqaprv0ksvjfuYfK5nzpxZdF8effTRJvUk35W99torM3fu3KLrHDhw YJM66SP1tiTPadOmZTp37pzaN2Por/2mm26Kr/muu+7KW87K23adddbJXHzxxZlPP/00rsPv9OvX L2d9xx9/fJz1nXfeyZnvyiuvjPItWLAgQ3vWdqHtyiuvnDnkkEMyNu7Fjf1359133y26rlxtvffe e8lqo+PPPvss06VLl7z1Mw5/8cUXqeXTEl944YWc9T355JNpRaK0MWPG5CyX67p8OuPE/Pnz4/p5 T/z5UvcZfxpVhg8fXvS18455qSS3Sr+n1XwXPIN63C/3nvbv3z/vs+C/A1577bW8ec8555x6RJPV p44dO+a9hkLjwDXXXJNVHwc777xzyXXy3eaFMT7ZNu/e1KlTfbbMqFGjmuTz5caOHZuV3x8wvvq8 fv/555/3WbUvAlUjoEXWaqJGVyMiIAIiIAIiUD8EsCTEQiGXEIsWwUoulxA7tjXJTjvtFE444YRw +umn1+yysGr89a9/Hfbff/+atVlsQ1jQHXnkkaFfv35hs802K7ZYi+V76623UtteaqmlirZ4wkqo V69ecT1cPxbVWKk+++yzcTqhG+644474uNBOLitd3sE0K+5C9VXiPNeAhdOjjz6atzo/TngL1qQ1 Wt5KQogsVM8666zIKtjHdbZyWAXmEiwQTbAOyyWWD4vR6dOn58rWJB1L19tvvz1sscUW4Ze//GUT Szusmpsr//rXv5pU8fzzz4cNN9wwYMWZT7AY79ChQ8AKtBhJa8vKYVGdS7AwbY7gBeHvY9p9LqV+ wqQ0mmC5xxhy+OGHF9113jEsQ00qya3S72m13gW79nrcNvee+nci7fq8tWfSWyqZ34/ByXP1cpz0 HCi1X3gyJKUQw2R+jrGC9mLfDz6Nd++3v/2tTwr5vmPIiBVwLsk3vuYbl3PVp3QRKIdAYZ+kcmpV GREQAREQAREQgbolwEJZL774Yrj33nvDH//4x6ifHTt2DL17947c43bccccojRixTzzxRBS+4IIL LojScBH8/e9/H8UkrdsLVMfaNIFzzz03/OpXv4oYEG6k2HAKjz/+eOzWjuLt2muvjUMobLfdduHW W28Nhx12WFTvddddFynAiwF92mmnReUsREMhN/li6mxOnpEjR4Z99903roJwK1dffXUUEgBXUkIb 8N7zzvvQJRYSgYIHHnhgIIwAEz0DBgwIL730UlTfDTfcELm9coCyAgU2caUfeuih6Dyuyl27do3C PiyyyCJRGn8YU7bZZptAeauL9LvuuitSClvGjTbaKBAf+oorrgj//Oc/o2Tc2/mRvuuuu0bHhFyg /2+88UbkFt+/f/94QotynEeZjyKCySwUqKbIpp8nnXRSuP76663JLOXbIYccEvXTTj799NPROMpx t27dojjNdu6FF16InhmOvQKPY5QPXK8JExE8U1tvvXUUmoCQDaNHjw4nnnhi1Dfuwy9+8YvIbfj/ /u//rFjBLSFFhgwZEuWjjXyhMnbeeeeIN1yYADDFM7G4OZdL7rvvvvDkk082OT106NAwZsyYKGyK V6Jcc801TfJaAu/IqaeeaocNteWZgrd/fs8888xw8MEHh5/97GdRiJbnnnsuYnzTTTdlXZt/tyrJ rdLvqX+OK/UuZIGos4NK3NNzzjkn/PznPw/HHXdcfHWnnHJKFPefd5rQMiZbbbVVNL6hyEU537dv XzsVbrnllob4v+vBBx+MJqMI/cN3MUJ4AjjkExsjbKFbn5cJVcZTH4Ip39hLOAtCDHnh+5sxlYm1 QYMGxacY8//+97+HPffcM0pje/fddwfCVM2ZMyecccYZUTr/A/zud7/Lu0bCtttuGy1Ma98nxxxz TPT9FzemHRGoBYGq2QarYhEQAREQAREQgbomgKuZuZAde+yxOfvq3TJxFy5Gvv7668zo0aMzDz30 UOaWW27J3HHHHRlcgHFJLka+/fbbDKEk+OBybULogGeeeSaDu+Szzz5bkuuy1WFb3Oy/++47O4y2 uEIbk2JCNOBeOW7cuMzf/va3KKTBgw8+mBk/fnzkek+/Ycx15xNcka1NC9GAq/Pbb78dcXvggQcy uKZ79+d89flzlMPlkHpph35Sb/K6fZnkvg8h4d1JyUc9dp9sW2zd8+bNi/oCM0JVEB4Bd8lyrvPo o4+OGZYbPqR79+5xHWnu4dxP3PntXnHfyxEf9mDSpEnlVFF2Gd5LH3KjW7dumRkzZqTWRwgH31dc jdOE98SYTJkyJS1LdG8tD1vekTTxYxL50txav/nmm6wQDBMnTkyrKk5r37593L+0Z5MQHoSB8P3z brjezZ19LzfffHNcbsiQIf5U9M5ZnfZeWwbPjP5NnjzZTmVteX99/3v16pV1Pu3Au5LzTJcjhLuw vqe9C77O888/P847ffp0fyret7p4f/IJ98fynnLKKfmy1t256667Lu47783IkSNz9nHAgAFxXq6X 77U0MRaV4OafuXLf02q8C2nXXS9plbynxxxzTHzPL7zwwoKX6MMF9e7du2D+esvAWGDP73bbbVew e5aX7/JiJN/Ym698Wigaxlj+H0kK/+9Yv/r27Zs8XfC4R48ecflhw4YVzK8MIlAJAgrRUAstutoQ AREQAREQgTZCAEuuXXbZJeDij8UDloK4rGLFhMUaFpVYaOVbTAw3aVzdcG3ng1UL+XGZxwoNC2Nc YLHQYAGtiy++OLLIKwYxlmlHHXVUwBKQBZwWXXTRqF9Y7WHxV6xguYg1BwtuYJ2z9957R/XSd9yp WYiOc1hGc93FulfTPtYjWNr99Kc/jbhh8Yi1JNddaOEoyhNSAMsxrDEph1VZjx49ov7RT+rl+rFY bY5guQk/u0+2Je0f//hHzqqx6uT+YWVDX2D2m9/8JnTu3DlaUIprv/HGG8tanClnowVOYC2FRbsJ zJLCoiwsNGaCJWyjyR/+8IfYKherqttuuy1r4TR/PViWEaLDBGu2cmWPPfaInkErjyVjmhAOxFu6 YcGWtOjC2tgWiOQ55xlvjuDRcNVVV0UhGqwe7ybsXXZ5xosVbznuLR+xIsMy2eTOO+/MuWglCw5h uWfCPpZskvoigLWfWfrRs0suuSR06dIlZye9ZSaZzLo/Z4EanSj0nlb6XajRZZXVTKXv6dFHHx33 Aw+BQosPYsltcsQRR9iutlUggGcJi6hKRKA1EJCCtzXcRV2DCIiACIiACNQBAZSPuEnjOpdPcJNG qZdU3FAGJVKyPC6vxAsdNmxYarW4YBeKnUtcQxS7KDgJPcHq5ia47KE02njjjXO2YXnZUheueBdd dFHs2u3P276PRccPiGIERWzPnj1T60UxhMK4UPxjFA2E3vDtJ9umPygxcWUvV9Ji2llduWLi4i7O vfRKKytjW9wbUfiiGJ86daolV3XrY7YShoTVtdPEwgBwzocvSMtbb2k8txZqhb6h7PVKyLT+eoU2 K4g3R3xogXyxPAnXwEQOwjNPSAYT3H5NkYaCmri+lRDCNnilvlfweuUsk0LFimfr60CZbMKkRqEY 11tuuWVW6IfLL7/cirfIFuXUuuuuG48dyyyzTNwPJvZKEZ5J3NT322+/qBj3wSRtdXs7V29bvj/M Lbtdu3bBK/PS+srzTYgDEyYES5Fqcsv3nvrnuBLvQinXXOu8lb6nfJ/x3YLw3ZH8P8dfHzFnmfhB KEPoltYkjONMjLPugQnjOVLKJJqVLXdLGCb7rmHC3v8fUG6dKicCLU1ACt6WvgNqXwREQAREQARa CYHkomydOnWKYmuykBNxzrDANSF+JgsbJYUf+Fi3obT1YspKfhQTPw3llP1YIh9K41xKI36UYu2L YtcLP5roo/2Dzzli4xUS2jeFLT/miRv6zjvvRDFHUWxivZWUNGV2Mo8/5trOP//8KBaoX/gLJQIK sHziFxfhRxNx4FCOP/XUU1Ff6bPJ8ccfX7T1s5WxrVeIkQZH6uO+okxPCtbTxMY1RQj5L7vsskiJ x73jOfHPCIp9lN2lLhSUbLeYY6y1TNZcc03bbbLFKtuk0RS8yUVe/HNl15TcEjuU2LDkRRlZrmCt ZjFzqWOttdbKWRVW/rzfJkzemOUgP8JNeHawvq2UeIs6/75a27RTiiLOKyp83ePGjYu7zCKLxQjv lYlXPltaLbeMz1hQ2+QQMXqJFcw4WIrSjz6//vrrkXeDj4PM5A/xOL0CtJbXV05b3kOD7xC8EwoJ 4ziKYCYKi8nv66sWt0LvaaXfBX9N9bZf6XuKB4j3Trj55ptzXrK38GdthNYmjIEsosh3iwlxqfv0 6ZPFyM5Va8ukpf2/xv8lFjO4Wu2pXhGoBYH/TZPWojW1IQIiIAIiIAIiUJcE+MGIu3aa4FJfjLAK /fDhw6MFhfbZZ5+sxUMoTxrKs4EDB0bVodA79NBDm1TNIhd87r///ixLW6z5sJw1QQnAAkv2Q4zF nHD5Two/oL3F7tlnnx34+BWPWcQDq1FTPibr8Md+QSEUE1jVmtA+HywfuV5r17dleXNtua4//elP 8Y9+fuChoKZ/CJY93gowWQ8KaKweN99887DTTjsFv5gViyWxGBQWeFwrimoUwqW6uV966aVZVtNY DBN6w1vg+X6hoGfBHxOUw/TRW/xh2YuLMEpdLK0RlLz86PIKP6ujkluv4F1hhRVyVu2tChthRXN/ Id6qmmc2173yZdhHKeEVE8nzhY6xOOce+sWn8i3aRX0oPrGu4v1BmYj7LBZwNknDWFNJBSCTQLYQ HO3zfph4C1Wv4LfzubY+rz1TuOLb5BDl1l577VzFs9JZCM+E8ng6FHv/rFy5WxSufnLglVdeiaoy Zd9qq62Wdzzy7TIOeKtr/0zaRA4LGdpihr5sPe+/+uqrcfcYx4oRnjFbAK9Q/lpwK+Y9reS7UOia W/p8Ne4pY5ZNIjMRyvc4E1pJ8YvwEd6q0QVlrn/vbQzx14VXF59aC5POLPzIdw3fM3z3FPKqqHUf 1Z4IlEJACt5SaCmvCIiACIiACLRSAoQp4NMcQZFYyCoQRZEpeHNZ3Kb1ASWDV+6SBws5FEfm3usV J1YHigksYU1QGnlrOEvnRxRxaXEbLCQ+XmIuxS2KGyzciMOIdS9uyMUIiitcsJPKG6xwuQ6sRvmx z2rSuawJiduZL2QFVitY2OKCihBao1gFL0od3CpN0YYV7mOPPVbQhZSYuqY8R1l1zz33ZCl3PZu9 9torulZbdRsrH5T0Cy9cPcczmJoQ1zmXeAVHo1nwemUaz0g1BCW/8eN+owRnYsYL71+h94znn3eV eN4Iz4IPEcEkRqWeB9yFiYlqkzG050NTsI9lKgrbfJbH/hrZJy9W6998803gmUaSYU28NX2yvD9O 5iN0SbXuoW+XfSa0/KRW8nypx9WerCm1P83NT7gEP36U8oyU0nYluZX7nlbyXSjl2mudt1r3FI8a JjDNQpfJWqxWvaAMtUlrJmP9RJHP10j7fBdU8vmt5LXzXcP3Cd5cCOsxsIYAFtcSEWhEAlLwNuJd U59FQAREQAREoE4J4OL5t7/9LfoBg2Uoyk1+/KIIZNGmTTfdNO55UtkRn0jZyWXZgVLWJM2i0iuX sFo0K1gr47csjoZlr49T6s/bPovHWb38KMDCFosPFFtcJ9Z6KKP4Yfbyyy9Hi6kkFbZWV3LLD+i0 vCjPURKbUvGTTz7JuTATdZIPKyAsZbgPprziByYWZp4VdRUrWF7yAxRBUYsVdjGKJj95gBUTSvJ8 sYRRiJmClx+HWHEW006x15HM513LzTIxmYdjr9wv1a06rb5apr3//vtxczyn1ZD77rsvb7VMPFx4 4YV589hJnjVThvAM8EFwaycubTnChBDvF+MUz/17770XsPz3ct5552XFYObZ8Apfn7fQPp4IXpJh bLxFuM+X3E/mMxbJfNU4JlyMnwB6+OGHm9WMX3yMZ9LGk2ZV2oKFkx4uuSbemtvFSnIr9z2t5LvQ XB7VLF/Ne8pkrSl4iWedVPDeeuut8aWlhTqKTzbYjn9++b8wbUK+pS6JiUTWP2CBW0IJseBquWN+ S12D2hUBIyAFr5HQVgREQAREQATaMIGuXbtGYQHSEKCI3W233dJOZaWxujvKO1vh3p80BU05/9Sj jMoVa9Ncn2lrwYIFvslon9ATJvvuu29WuAJL91sUMoUUvISVsLhtKK9zxcRFAcqPOZgUa9WVz2Xb FiGhvz5GqO8/CkjiYeZaEZr+emuzfHX5em3fK2NQ2CctCy2f33JfnnnmmTgJvoUYx5n/u/PGG29U VcHrraRY4CaXzJgxIz6VL1ZvnKmOdrybv4/TXMku0gZKIJtQ8HXz7ntFoT+Xa5/3zJQhlqfUZ8fK sb344ov9YdY+48yAAQMia96sExU88AtYUS2hQYp5h5KTMN6auYLdS60K12ofGxtlCAtELbrooqn5 8yUyho0cOTLOwrhAGBnEh5KJMzTAzhprrJHVS5TWxY73WQXzHFSaW6Xf0zxdb8hT1bynLNTJO88k LOMk/zdttdVWESfClNh3N+NRcoKoIWGGEJgU9+894bewTq4nIcwUCl6EMBoWJqqe+qi+iEAxBKrn 61ZM68ojAiIgAiIgAiJQFwT4AYmFZNqnGKUMbv7EVfXKXcIN4PqMkoYPsWU33HDDil5vITc6r5Ak VmQhSf6wS8uPpS8KDq9wTcsHCxaFQmnrLVjT8lpavuvJd87Ko1C2H4ik8SPxiCOOCFglshAd4TFQ 5pPeXMGKmViZxAPNJ19//XVsfZkvX75zScVYvrzlnFtllVXiYkkFeHwihOCVv9Xuk2+3EvssmGYy YcIE263olrAkKOOJaUuMZS/9+vXLOTHh8/l9lOgnn3xynISClomFcoXnng/vLmMRVmVY4LPgEUpU xqtqSnIMMov8Qm0m8yXrKVS+kufNetrHmmViqdA4kNYHs8rnftiYxOTVnDlz0rLXZRpxxL2SvlqT J/7im8ut0u+p71tr2K/mPWUiw3sSWbgjuBHSxazzCWVTziRKI/C3tRJQ/NaL8H8aE3wI4y2hsiQi 0IgEZMHbiHdNfRYBERABERCBOiOAVZ39MME6CAuNTTbZJLWXWONa3tQMFUz0Fr6zZs0qWLN3Y8+X Gasz8hKigMWjiCdM/Sg6sPLEBdFfI0pVrPWKUdLmazffOZR2xCo2wbL4tNNOCz/60Y8sKd6yuA+L i5QqxMLdf//9A8p7rg9XRmLyolTOdW3cb5Q3xgM3+Y033riopolxjCK12oueeAteJgVw4U+zKPQW 6KuvvnpR11AvmbxCDiU2ilgf4qSS/eS+YaHF82hxuVmQEPdjOy62PR+eoJjJpnz1oqBPC4GSr0wl z/GO8O7YgnO8s1tvvXXBJrwnAqFmKhV/uGDDKRmwdEMRbhNcf//736MYw4Ry8IuxpRRtkoSieubM mdGCkva+sXAmk0fE6e7evXuTMvWYQExpU8ITwuLwww+vajcrxa2S72lVL7gFKq/mPeX5sBBEfHcy Ac535NChQ+MrrfYzFDfUAjsoeBmL/SKrLdCNJk3y/xJhM/h+5P4oTEMTREpoAAJS8DbATVIXRUAE REAERKDeCRC3zIQf/LkUMVhmmaLP8ldzi5LZ3O6wuuUf+HxCnkLCgkMsLIaClLAPfJKCgvChhx6K 3RD5wYBll3eTT5Zp7jELg5igRLMfkJbmt/msVH2+5D4LkLC43VNPPRU233zz6DQLqKFIR/mbS1Bq 2UJNrB5PvLt6EpSIKKzgwvPJIjf0OSncU5NKW6NbvdXamtWU1Y91ORMx1RQsvGFmYRaYDMDS3yvU q9l+PdaNO7YpeC+99NJowUNTbqb1l7GEfCbmzm3HLbE15S5tjxs3LuoCkx9Mbi277LIldcmH3yGc i8U3h1ExCl4WD7zmmmsC7u0mTGZgMV4rQUlvsYl51ok1XezCmuX2sbncfLv19p629nuKpxBx5rHY RZgo7dy5c2ASDOF5Kuf7pR64RRdQxB8/cVdE9ppkQeF81VVXBRbdRfItVluTDqkRESiDgEI0lAFN RURABERABERABP5HgB/WPjQDCrxcwg/xWoq3IuYH+IMPPpiz+cmTJ0chFXJm+O+JM888M2DFRlzK XLFwUdjst99+AWs7k2q77vpFy/x1W/u2ZQGZ6667zg7L2qK8wM3XBNf5fC6NWEOZXHbZZZELvx3n 22L17MMi5MvbnHNYVv7617+OqzBlTZwQQmSh7dOxZG4kwUKMMB0mKBO8wtrSk1vCi2BNxorv5Qjv vLnfozxPLipUTp2NXMYrDVCKFlrwCiW8txw/44wz6ury/cKD5YRp8Bfj46h7ha3Pk9xnPMHqDq8E +5gCPZm3WsfEPfdKb2J4zp49O29zhK75wx/+ELnrlzvhZg2Uw83K2rae3tO2cE+PPfZYQx9uuOGG rPG1HO8aKqsHbvFFNejOgQceGMUMpvvFfD826GWq262YgBS8rfjm6tJEQAREQAREoBYEFltssawY hPzYTsq0adMCMeVQjtZSsJLBddgESyVi3iUVsyz2s/POO1u2vFtcihGLQfvll1+m5ueasQQ18QoA S6vk1ltN//nPfw6fffZZVvVYAqKg3HTTTWN34qwMJR506tQpcqO2YrhtDx8+3A6ztl6pRwgE4p7m CpnxzTffRFbX22+/fRRvFetgYjxXW4hVbEKsYu8WT7q/BmIdl2qpaHW35BYLWm8Z9stf/jJaeMwr iKx/TNoQK3KbbbaJQi14BbjlKWbLc4/izQRrNT5tVQg5wvNlgjV7rokn0r2bMDEiG21xP7vOam0J k5OUQp4ayfzNPcaadtCgQXE1eLQQqzgtZAUKcbxKiInNAnZ4QNTD+1BP72lbuKfE/7aJLybRTj31 1Pj58e98nFjETj1wK6KbdZ2Fyd4rr7yyrvuozolAPgIK0ZCPjs6JgAiIgAiIQCslQCxMb52ANSaL oLGAET80fvjDH0YKTNzqiS9rMmbMmOhHKYofv1I47oWmxEERhmVSz549oxhrKMrSrNSwWqLNFVdc MWDNYgsHsdryc889F60wTbtY/aE8xG3RXPtRSN10002xqzP56BshBFDq2urTxBgkrp0t5kFdRx11 VKTUQnFFfNpXXnklqx67VsI1UB8/togLmSa33357ePzxxyNmxJVFmfzee+8FFMYs3GSCUi1pVUu+ v/71r7FbJnmvvfba8Oqrr0bKRFtMCiUx/GjHpH///lEcWx9j14cUwOJvpZVWihaR2nbbbQNWu3/7 29+yLK2tLu4b8Vgpj/UKgjUwfUFJzCrfuYTYwrCxEB0oSZ999tno+cGCGSUwQmgKYg2i2EWGDRsW LcJF/3Gnxl0ThTj3HUtR7pOX5loG+rpy7bNwkXebpf+EMeA5RyHj4xv7RXJy1VeP6Szaw3tj7wN9 5FliQoD7yAKCsOeem/uwXYd3l2dBMhRTvMM+rAkKK95jnosdd9zRikbvLTF5bRzgHeQ5oR9JZQbP O27uZgHJu2SCEs3aY9w4+uijoxjNdt62PEPm6u+tX7G0tHAIsDjkkEPiUCNWNt+Wd5N31vrGsQnv ux0TI5d3wVvwXBf60AAAIABJREFUWz62jGe8A+b5AC/GQJihACa+N9fNvTJhIa9qKi6ZcME9efr0 6VmLQvJsMEbmEn9/fB7C2PD59ttv42Qb8+OExE6p7zleFxb71qoiBIgtBGdptdjy3cR9NDf7N998 MxAWhTGQsBo8r3hx8GwnLXaJ6W5SSW7VfE8r9S7Yddu2Nd5Tuza/ZWKcSW+8gbzgGbTMMsv4pKL2 64Ubk8j8P+k9b5jU5X89EyZEGMuKDdPAdxH//3irfhtrqdOPvRwvueSSYbfddos+1iZbJvf9ZBqe TIxffBfsvffecX7CTzGJa//T+jq0LwJ1TyAjEQEREAEREAERaFMEPvzww0wIIednxIgREY911lkn Z54zzjgji9mnn36aWXnllXPmt/Z69eqV6dixY5N8AwcOjOuzvGnbWbNmRfnGjx/fpA7LTz+ScuON N+bMb+XY9u7du0m+Dh06ZFW34YYbNsnj60juL7XUUpmxY8dm1cHB2WefnbOeSy+9NM6/77775sx3 //33x/nYueiii3LmtX7Bp1+/fqn5Zs+eHdU3ePDg1PPffvttVns8K1ZvcrvFFltk5Z0/f37mnHPO yZk/WZ5j+nrrrbdm1ZN2cPTRR8f1Dho0KC1LUWlffPFF6vPp+3bLLbcUVVeuTDwPVt+kSZNyZatq +ptvvpnhubZ+FNqee+65me+++y7u0+WXX563bPv27eO8tjNt2rSMv3Zrc8GCBZYl2uZ73q2Mbf24 YZXQTztfaLv77rtbsaK2pfStW7dueevkWevatWtRfaXdzz//PG99dnL48OFxnd27d7fkgts777wz LleIW67zn332WdxOvu+PXOV9+qmnnhrXlWtn6NChTfr89NNP58pe9XSevQsvvLBJn/x1+X2+S/gu 81JJbvXynhZ6F/z1t8Z76q/P70+cOLHJs/LPf/7TZyl6v164+ec73z7jVLFSzP+WybaS30GF/u9t 165dVnc++uijrHvTt2/frPPFHPTo0SOuY9iwYcUUUR4RaDYBhWioexW8OigCIiACIiAClSXAAkfe gs/XjqUplowIlnXmQujzkIZVqBesRbG+xIIpTbAOxX0QF34sBr1Qn19JngXC0oQ6bNVl4vymLVhG Xd7S0OrBOg4rVd+OnWOLlRULlHgrEzu/zz772G60xVLXBKvHNEZ2HotVFiHabLPNLCne7rLLLqll qQ9LSpNc9wqLvo022siyRVvie2L1l9Yn0rg+3IZZEC3JApdRLJoR7m8ypARcsTrywj1Ia4s8uP97 warx97//fXQfsLLLJzwDPC8ffvhhOPTQQ/Nlreg5LIpoNxdzLIUI89Hogns4VrrEc03eZ39txBLF mpSQAj/4wf8c/7B+z3XfKY81VFKwSB81alRWOBesHnGJ9YI3QDHC85/2XtHPXOOQr5f+e8tJfy7X vnkG5Drv07Egyyc8a1g0Ezcz1z0g/ZJLLokWw1t++eXzVdfsc8TVztWPYipnDCWciol5W9hxqdtC YwT1mTW31c17W+o9tbKV2PLs8f2Gy31yfPX1Y9k9YsSIgGVj0rOjktyq+Z5W8l3wbFrjPfXX5/cJ q+QXQ+UdIjRROVIv3LBALiSMMz4uf6H8eFqUKsmQW6usskredzI5XvN/sl+rgMVlJSLQCAQWQkXc CB1VH0VABERABERABBqDAAqhd955J3L1xt0YpTEhH+pFcEEnbASuyKxmjcIWF71ixVzY+WHOjwbC ReB6SxgEFs5BuG5iZZpCuti6K5Vvzpw50T3AfRmXdPq6+uqrV6r6itRDLEpc1ImvC0MmCeAGU69M LKYx3CktJAZu/MSaba4QMgL3TWIso5BBAVZqv9L6gHsqzxDCtedblDCtfDXSWMxuwoQJUX/4YYvi nn7h6iqpDQEmM1577bVoUoN3lVjZ5byzhBJhUTyESZl77rmnNhfQAq0wVvhwB4ShIcxKvQgu5YQ4 QpHLeGcTk9zX5MRGvfS5pfvRFu8p/zPxvwMhniyETKn3od65lXo99ZAfNRljMlsmRW0CvNi+EaaM 8E4IIXlsXC62vPKJQDkE/jcVX05plREBERABERABERCBBAGUdHzqVbDcS1ogl9JXyntrDyxT+eFe D4o6uw6sTbCQKcVKxsrWaotSnfi7fOpRiCV70EEH1WPXKt4nlLp8/HNd8UZUYV4CKP3KUejmrbQV n8QTwSt3mYQpxaq0FmjweMAbw3tk1KLdRm2jrd7T5v6/1AjcGvGZZBImzUukEa9FfW47BBSioe3c a12pCIiACIiACIiACIiACIiACDQ8ARbp88KCiLKK9UQab1/3tLx7Jm7lcVMpEWiNBGTB2xrvqq5J BERABERABERABNooAVbwNjdX4km3tFUqK9mzsritAG7hGdro7dFl15AAoWgGDx4ctUjM3/322y8s vvjiNexB9Zp6+eWX48pxbS8m7nJcQDt1SUD3tLzbIm7lcat0qblz50bx0mfMmBFVzfoLEhGoNQEp eGtNXO2JgAiIgAiIgAiIgAhUlIC33GPhKj4mxJclPmFLyQUXXBCICywRgVoQ8O/CxIkTw3HHHRc3 y8Je3bp1i48beYfrePLJJwPXeOGFF8aTOo18TW2977qn5T0B4lYet0qXGjlyZDj44INTq/XjcmoG JYpAhQhIwVshkKpGBERABERABERABESgZQgcdthhYcyYMWHWrFlZHSAG8YorrpiVVusD4oI+9thj gYXvvLDK91prreWTtC8CzSbQqVOnsMMOO0QLP/rKWLm+NcWC3WOPPQKxR1kEEetkSeMT0D0t7x6K W3ncKl2KOOB8fGxw2lh77bXDrrvuWunmVJ8IpBJYKMOygBIREAEREAEREAEREAEREAEREAEREAER EAEREAEREIGGI6BF1hrulqnDIiACIiACIiACIiACIiACIiACIiACIiACIiACIvAfAlLw6kkQAREQ AREQAREQAREQAREQAREQAREQAREQAREQgQYlIAVvg944dVsEREAEREAEREAEREAEREAEREAEREAE REAEREAEpODVMyACIiACIiACIiACIiACIiACIiACIiACIiACIiACDUpACt4GvXHqtgiIgAiIgAiI gAiIgAiIgAiIgAiIgAiIgAiIgAhIwatnQAREQAREQAREQAREQAREQAREQAREQAREQAREQAQalMAP GrTf6rYIiIAIiIAIiIAIiIAIiIAIiIAItGoCH3/8cViwYEFYfvnlww9/+MPoWufOnRu++OKLsPDC C4ef/OQnrfr6y704cSuXnMqJgAg0KgFZ8DbqnVO/RUAEREAEREAEREAEREAEREAEWi2Bv/zlL2HV VVcNq6++ethjjz3i69xtt92iNM6RR5JNQNyyeehIBESgbRCQgrdt3GddpQiIgAiIgAiIQIMQ+PLL L8ODDz4YTjzxxLDNNtuEBx54oEF6rm6mEZgzZ07461//Gn7zm9+EddddN+y6667hkksuCa+//npa dqWJgAiUQODdd9+NFJy9evUK22+/fZg0aVIJpes/6+zZs+NO+v2vvvoqNT1ObOM7npXfF7c2/mAk Ln/atGnhxhtvDD179gz/93//F21vuumm8NFHHyVy6lAEGoOAQjQ0xn1SL0VABERABERABFoxgQ8+ +CAMHTo0/O1vfwvPP/981pX+/e9/D127ds1Kq/bB559/Hvjhk0sWWWSRsNhii4Vll102chvGTTif 4E6M4iWTyeTLlnpuiSWWiBSj/uT7778fZsyY4ZOK3l977bXDj3/847z5UQj8+9//zsqz6KKLhg02 2CAstNBCWen5DlDu7rvvvuHJJ5+Ms1Evx2eccUZ0v/faa6/4XDE7uGV/+OGHWVmXXHLJsM4662Sl NfoBEx0jR44MEydODP/617/CvHnzomvccsstw5577hkGDx4cPvvss3DSSSdFP8z99eLO/s4770Rl fHox+zzb7du3Dz/4wX9+Jn3zzTd5lYY8++RdaqmlwkorrRR4TvLJJ598Ej799NN8WXKeY4KA9yEp vFfvvfdeQHmVfMfo25prrplaLlnPlClTwtdffx0lc13rrbdeWHzxxZPZ4uPvv/8+TJ48OebMe8X7 lU/Srn+ZZZYJa6yxRr5iWedeeumlcPvtt0cTYcn39OWXX476nVWggQ9WXHHFuPerrLJK6v4KK6wQ p2vnPwSqwY3vMcYVL4wXfC+wrbXMmjUrUkQyNiZlueWWC+3atUsmF33M9/+4cePCq6++Gt5+++1A fYwjTKJsvvnm4amnngpTp04NBxxwQOD9NZk+fXogNEZSGE9WW221qB7OpY0DfLeuv/76ececXGVL HUOoh7Fr2223zRqP77777sBn5ZVXjv4XKzSeJa+TcXjmzJlZyby31CcRgZoQyEhEQAREQAREQARE oBUQ+OqrrzKzZ89uyCvZfffd0Xymfnr37l3Ta3r//fdT+5Grf0sttVTmxBNPzLzxxhup/VywYEFm nXXWKanOZFt33nlnXPcdd9zRrLroSz7hOeKakn3geODAgfmKZp375ptvMp07d86qJ63eUaNGZZXL dzB37tycfbv88svzFW2Yc99++23myiuvzHmdyfty0UUXNbk23plkvlKOjzvuuLjO9u3bl1RXjx49 Mo8++mhc3u+MGTOmpLqSfW7Xrl1m/vz5vspo/9RTT81b74Ybbpjh2cknd911V5M6aO/LL79MLfbF F19kOJ/s47333puan8QXXnihSX4r/+STT+Ys50/MmTMnZx3UxfjQmuSJJ56Ir7dXr17xpbFv7B5/ /PE4XTv/IVANbjvssEPM3Niz3XfffWuOfdq0aal98f0q512g3uT3lq+Tff89dtNNN8XXPnny5IJ9 mjFjRmb8+PE583Xs2DGuL22nEmMI9U6dOrXJ+LXyyitn9Yvx7b333kvrRmoaY1iSlR0///zzqWWU KAKVJpDf3KImKmY1IgIiIAIiIAIiIALlExg7dmw49NBDIws6LBkb0UW3Y8eOEQAsbo455pjQu3fv 8oE0syRWeaUIVoNXX3112GijjcIrr7zSpGiaNWyTTAUS3nzzzThHc0MbYPGHZW0uwbrSu/H6fD/6 0Y/8Yd79O+64Izz66KNxnmeffTZgcYXl8ZFHHhmnH3XUUWH+/Pnxcb4dLFNzyfjx43Odaph0rg9X +5NPPjnrHmCdjIVsmmDNnZS05zCZJ9+xZ5nvWUmrA+uvzp07R26/yfNmHZtML/YYS38suJOSZsHn 8/D+3HfffT6pyf63337bJI32brvttibpJJDO+aRgeZ1LsMTOJfkshX0ZPAe22GKLKIlx89RTTw27 7767z9Kq9r0lqrcCxFrcxOextLa+9UwqxS2X58cLL7xQc9z5vgusM7/73e+ixfnsuND2kUceiayR /fdWWhn//ei9SXx6WjnS8LrIN6YmLaST9VRiDKHOc845Jx6/Ntxww8gDAqtiQr5wjDC+nXvuucku 5DzON4bl63fOCnVCBMogoBANZUBTEREQAREQAREQgZYlgBvyqFGjwh//+Mcs93d6hRtlo8kf/vCH cMEFF8Ru4c8991zkgt4S17HWWmtF8WFx0bznnnsC8eiQ3/72t5Hiin2UwLhhvvbaa1n93GWXXcJb b70VLf5jffeKIxQzhx9+uJ2KfkBxDxF+VB133HHxOX4IDhw4MDrGTd7E398BAwYE/0OevppyjhAI 3kV1+PDhAdduhD6lubpbG36LyyWC630pq9Vff/31cTW33npr2G677aJjXEmvvfba8OKLLwYUb/yI fOKJJ7IWUIoLJnZQMPMjFDbIkCFDYkaJrA15eOWVV4a77ror7vugQYPC0UcfHUyxDit+mPtFpQgn khR75lAKX3TRRVmneY5NrrnmGtuNtv37948Uy15RwbvIpBHPFYpnZOeddw6nnXZatM9YxP3A3ZdY jhZ+gZjLvEt+YSzKcX3kQZny8MMPR3V07949qjM6SPmDctaH+UhmQQmBstNijfprtLzXXXddOOig g+ywyZZz9JcJJsJimAwbNiyccMIJdhhveZ+8ENaCSY0OHTr45Jz7KGV5fhHuE+FeihFc4Xl3GIMs jAbjJ98HrVH8+OaVul5p6fO0RgblXJNnUiluhIzhe5F3nvFgn332KadrFSnDonuPP/54FL4GZS/h nRhTvDCZ+Y9//CPwvVxIuDbCCZkwqcbELeEYCDHAGMj3FP+n+Ikdr2j++c9/Hu6///6IESEcmOxC CDG13377hY033jgKt0TdfCcedthh1lwUfufss8+OQibEiQV2yh1DmCS75ZZb4tpHjBgRh/khVAzH P/3pT6PzfNdcfvnlcWiJuFDKDuEemOCy7w/G0tY6LqVcvpLqhUClTYJVnwiIgAiIgAiIgAhUi8C8 efMyt99+e6ZDhw5NXOFwvb/nnnuq1XRN6x09enR8fbUO0eAv9Prrr4/7ccstt/hT8T4ujN618brr rovPsfPhhx/GdfTp0yfr3MSJE+Nz3v2YTN4F1Zdj39weqduLd1t+++23/amML0fduSTpZporX770 cePGxX2EDWEqkjJ06NA4D2795ci1114b13HkkUeWU0XdlEmG8hgxYkTOvvmQBIQ3SYqFVWCbFHtW 2SYlX7nXX389Zn3MMccki0bHhEHw4Vby3VfCUNhzzLOQT84///w47/Tp0/NlzUyYMCHOSz+9O/Wb b76Ztywnff+tf5MmTcoqx7Gds23afcgqlMlkhg8fHpfr3r178nTZxxdffHFcbzlu6WU3XIOChHox xkOGDIlbZN/SCVshySZQbW7JMT679dof9ezZM34e+vbtG+8fcsghBTvz9ddfZ4Ur6NatW4ZQCmnC d6cfU/r375+WLeO/3/g/wgv3hrAW9vwy7n7wwQc+S879SowhgwYNits+4ogjUtsi3frH92w5wvhv dQwbNqycKlRGBEomoBAN9aJpVz9EQAREQAREQARyEsAiAms7LDIPOeSQ2EqTAlhGPvDAA5HVGZZw ktoSYOXp8847L2706aefjvfZMWtK9ou1miXvD3/4w7geb8Hr982yM86YZ8e37a2A8xQp+xTWUCY8 k2kLs3nLTiydvvvuOytS8y1utrxffNJCHtSiQ1hK24JZWHR269YtZ7NnnXVWHLLBPydWwFyAc7lU W77k1vJb+eT5Qse46F522WVxNhZITC56Fp+s0g6WcSa/+tWvQp8+fewwtpiNE1J27Nr9on1miWfZ sXBDfB4rZ3m0rQwBnm+soxEsIE1sH8+HUsZBK9/at22JG14M5vlAeBg8EUxYjNC8CiwtucUC3qxy sQwn/IpfOM3nX3XVVUO/fv3ipFJDOjFO7L///uGhhx6K6uD5xcoYi+RaiY1ftJdrkdMuXbrE3bn3 3nvjfe2IQL0TkIK33u+Q+icCIiACIiACbZjARx99FMVA45//E088MeuHCoqz0aNHB2Kb/vKXv2yR Vazb8K3JunT/42zChAlZ57yCtxRFhM/rlbp+P025l9W4O/AKXt8nl6Viu/ZjmQp33XXX1HpZUdwU N2Qo9CM8tZIKJJ5//vnRxAnvFx9cVH2ojAo0UXIV/t6nFcb9GndkwnAkQzCQ31YxL1RPsm7Lb+WT 54s59u8CE1OsKl+qEN5j3XXXjVyiKeuVLaaETquTSYKbb745OoXydauttopCXFheQkj498fS/dbO 074pOYYOHeqzRO7VJBAv2cTK2bG2lSNA3HGepS233DKulH1iehMmR5JOoK1w8xMwxHdffvnls+K8 +0mfJClCChB2wQRlr42DlpbcHnDAAXGSD38RJ+bYIYQMoRoslARhZVDulhL6KEfVJSVPnTo1zr/T TjvF+35nxx13jA99/jhROyJQpwSk4K3TG6NuiYAIiIAIiEBbJsCCFCiZUIKhgLKYZjA5/vjjI2td 4sMS80zS8gSIU2qy/vrr22609cpUr2TNypRy4Bcs8VZCXpFUroK32tayXsGLxVMuWXvtteNTxDSu tRCLMG0RmcGDB4dCi91Uuq9Ygpug7P7Tn/6U1/oVy32UEWbJaGXZ2niRTxnq89v+0ksvbbtlb8eM GZNV1scCzTqR5wBrPKyZiXmJMJmF8v2GG27IsmxPVvHYY4/FEwXEf8RyfL311otjZ8OFGJn5xBaC I74ti1cixOS12NbE2LZ9+mWL31m5fHXrXHkEWFgu7VmGPbHBJekE2go3i5MPBYujSwxwE2K++1i5 ls42ufiXn7Tx+fz+z372s0BMb/JiMVyMMPYQs9hi0hKPnxjC5YyPxbSXL495ipAnl4Lap/v8+erV ORGoBwJaZK0e7oL6IAIiIAIiIAIiEBGYMWNGtHiRLb5jWPghy6JGvXv3Dn5xGTuvbcsQQHnLYku2 UBq9SK5o760PUdgXKyinCMmBstTfc6yTEM6lhT7IVb9XtK6wwgq5slUk3a8snm/xKN+PllDwvv32 2zmvl9XEk8r6nJkrcGLhhReOwq/gUozgBoyiEyUiC/2sueaa0T0vRqlvzw3bUsSeT/+sFFueUAyE Jzn44IPjIvSd6yokLPjjFS2vvPJKVMQmR+jXVVddVaiawIJoJn5BNSbLHn300egU1sG+j5bfthZq AeWYWfByDitBFlBjYg3B+nyTTTaJrP1Q3lg5q0dbERCB6hPASnns2LFRQyxIueSSS0b7W2+9dbRw KQt5oqDMtdgaEzYmWNTawoWWlmvLmFKspwcTiYRCwOMKYXKOReEqMaGWq3+50vkf04T/K1m0MU0Y tzlvk4VYOi+33HJpWZUmAnVFQAreurod6owIiIAIiIAItG0CrNqcVO4OGjQoHHXUUSXFb23bFKtz 9VgBWXzdefPmBZSYL730UvwDiFaJp3fsscdmdWCttdaKLHVwzyzW2scqePjhhyNrQR+vFpf8nXfe OXI/t3zFbHEr5ccr7qCmyCumXDl5vAVvPgWvKatp45NPPimnqWaV8VazviJ+2OLeX2shBvAzzzwT x4Pk+eLjhWeM54gYvTvssIM/Fe+jzHz11VfDnnvuGacVs4Or8vbbb1/w2qmf+LbI/Pnzo3uHgjZp 6YWFcTHy5JNPBj7Nkc8++yxetR4uPj7u3nvvHU2SYBn9z3/+M6DUwQovTXi3ERS8KGBQFN95552B 1eQHDhwYh2fAFRzBspR6rVyUqD8iIAI1IeDDLxx22GFZbZ500knBLHn//Oc/h1122SXrPAdewYu1 fzXkd7/7XVa1KE+nTJkSfv7zn2el1+LAh8zxVrppbTPRZwpexjgpeNMoKa3eCEjBW293RP0RAREQ AREQgTZMAKuTpFx++eWRYg53wFJc/K0e/qGfPHmyHRa9pS0s1EqxEi268ipkxIKQeIxm9VdKE1jj eWVjWtnnn38+8MklWPthQYhiKCm54tAm8yWPsRjk4wVr3uQPWX8+1z6Wn96qMVe+SqR7BvkUX/5e FYp7WIl+JetAwXvJJZeE008/PesU4RFQ8tZaeAZRzJ5zzjmBMBFpgkUanyuuuCJyEWbiIdlXlMB8 ShWU/6a4zFcWBX5yIsrnR7nKwo/FKkx4/7y1NBMbpYotskQ5JsS84MZ/wgknhAEDBkTJ9J17nCYW AsVc/1nUEgUv14xbNuEaEIvDaRZ/Vi6tTqWJgAhUngChhrDIR/he9HFjSTvwwANjBS+eEYyZ3huG PH5RzeQ4GlVchT9MMm266aZRCJpOnTpVoYXcVfrQT/m+m6nBeyW0xPdz7qvQGRHITUAK3txsdEYE REAEREAERKDGBLDUHDduXDjvvPPCfffdF7WOVRyhGXDZZlEl9r1re6EuYlGKsqUcwfVxs802K6do zcug3MXFshzBGtKvLJ1WBz/+UAjyg9CsWiwfyqUePXrYYZvfElvXrHhx7cSKOU2wujRZZZVVbLem W96rPn36RFbWTGagjG/JH7PEZERpgQISq1YUvsR8JSawxX41QIQ2wCXZlByWXostCmQWubL7bG0S +xbltCk+LT3f9qyzzspSLGNph7W8KVnzlbVzxOc1IfSGD5tCug8bwmJrxDZPu8/2btskBSFXePdJ /+1vfxs1wThjCmkLmWHlrA/aioAIVJcAngT23vG+pk3a2LtLT7D2PfXUU7M65S39saqtljCO7Lbb btGCbtZnvmsY14udCKtE37yCOzl2J+v35325ZD4di0A9ESgcFKqeequ+iIAIiIAIiIAItHoCWGyi bMR1EGWJCT8Kzj777GhRDn6kFLuycSErDas/bestLNPO11Nac/rqLVVyXRPWe2+88UYghh0xQv0P Q+4HikzJfwisvvrqMYp8XLyCt9YriccdDCFS9LE4D4vgpCn9fN5a7aO4pU8sAkfcVyZ+CPMxdOjQ LKtulKk+fm0t+se4xLvAZMd7770XunbtGjeLdazF0I0TS9zZcsstoxIbbLBBXBJrPb/YYHwihEjx 7ZXfWGWfeeaZWR+UuiaMpWmLrRFuwsQUvChwkzF7vQW9t4jDi0AiAiJQGwKETTFBGZl85zk2ZSr5 0hZb86FaJkyYYNVVdIt3z0MPPRR5ijDR5EPrMAGfawG4inbiv5UxnnlL5Vz/N/l08ttEVjX6pDpF oJIEpOCtJE3VJQIiIAIiIAIiUDECP/3pTwNx4/jhguWuF1wNsZIkbAMWfvkkbfXxfPn9uZZYBMS3 X8q+La5SShnLW4pFNPHzsODzbuTcIxbBk/yHgFfwmkt7kg3KNKyuTVpSwWt9aMktVqeEEeCdzyWE TSGEwrPPPpuVhYWGWkqwasf92YeEOPzww8PcuXPL7hLWt8RktlALf//736PQJxtttFFqnSx0WKqk WT17pYYpeKkXrwkTlB2EbTDxig9f3s5rKwIiUHkCxIS99957S6rYFlvzhfwkEnUycVVpYeLQJoIY P/DOMotYPBXKGb+a00f+dzTBgjhNJk2aFCf7/HGidkSgTglIwVunN0bdEgEREAEREAER+A8BlGUs VsRKzBcv0x7zAAAgAElEQVRffHGW9QUuhygbWUzpiSeeSEV20003RYo0lGmlfIjb65U2qZXXUSLx glGSlXKNlhdGpQoKeB8n9eabbw6PPfZYqdW0yvzeKmrkyJGp10j4D7Ou4sduSy3gQuxUQpgQr5EP 1vPFWHSnXlQzEgkxgJU4Fl3JhdWS1aIk8LFy33333WSWmh6jeL7jjjviNlHqX3jhhfFxOTumAKEs 1ssI9fpV4EnDQ8GscymDpS+WtGkfLKBhhxAHk1jGXryC1oeHIEzNCy+8EAiJwXPrw4m0NgUvMd9Z QM9/am0h7u9JtfZRbLGoIOFACNfhF9sqtc1KjyGV7Fup19Io+e++++64q4ydae+7pfnQDTZWWGG+ x70kF0Tz5yq1z4Qyi+eanHjiiWHmzJl2WPWtj+uf638Wwl+YtMRicNa2tiJQMoGMRAREQAREQARE QAQaiMDs2bMzgwcPzrRr1w5/4KxP586dM3Pnzm2gq0nv6ujRo+Pr6t27d3qmGqRef/31cT9uueWW Ji3Onz8/s/POO8d5uCezZs1qki9XwsSJE+OyvXr1ypWt6HTqsGfi7bffLrqczzh58uS4DuoqR774 4ousOmbMmNGkmgEDBsR52C9Hrr322riOI488spwqMoccckhch7HbeuutM999911Z9ZVbiP5b+8Vc yxFHHBHnHzJkSNHNrrzyylE5tqXI66+/Hrd3zDHHpBYdOHBgnIdrGTt2bGo+Eq+88so479ChQ3Pm 48T5558f550+fXpW3gceeCA+d8YZZ2SdSzvo169fnL9v375ZWT766KP4XDF1UbhLly5xmU8++SSr vuTB8OHD47zdu3dPni77+OKLL47rveOOO8quZ8qUKXE99iyyHT9+fNl11mPBN954I/U6R44cWVZ3 KzmGVLpvZV1QEYXGjRsXMyx1LCmi+oJZOnToELf/2Wef5c3Pe+mf5+R7esUVV2Sdf/DBB/PWx8kx Y8Zk+L7N9b4xplmb/B+RlAULFmS22267OE///v2TWVKPKzGGPProo3G79CFNfN8ef/zxtCwF03r0 6BG3M2zYsIL5lUEEKkFAFrwlq8RVQAREQAREQAREoCUJYC33m9/8JrAgCKu7e2sMrC5efPHFluxe m2qbcA3epZ5QDbWwAKp3yFjjegtTW5zK+k1IgYEDB9phwKW/JQSXXcILJOX5558PtQ57YJal9IXY kljt55LnnnsuDBs2LD7NAj71IMS89OMRzwAWtdUULOdNsMAuJD6uOdZ8WF+a5LLgtfNpWx/KwZdP y1vvaVg1J4X4oXhHtCbBSjlNiB9dqlR6DKlk30q9lkbJbwtP0l8WSC0UYgnLfsJZmeD55IXQON5b 6Ze//GXkLZUWG5f7zf9f22yzTWTR/+tf/9pXVfQ+C3oSK9zkoosuarJgpZ2r9JbF3dq1axdVO3r0 6ODHUBI5Jh0hH1buEhFoFAI/aJSOqp8iIAIiIAIiIAIi4AmwSj0KjZ49e4ZRo0ZFCh+UDYRsaDRB Uf3yyy8HU5D41axxITQFIXHsVl111XDSSScFrr8aQmxY4nPilkyfTFAG4TqPu7ZXXq677rqRu2Wf Pn2irNdcc010HaT369cv8EPOhLii1EOsP4Rjk6eeeiq+TtJ23HHH0KNHDzuduiX8AaE5bPEp6jA5 55xzYldy4hOzEJx3e7d81dryI9gWwcG1nT7wrHJvvfs+C4n5Beuq1Z+0ev0ib8nzs2bNSiZV9XiZ ZZbJqv+ss84KKBP22muv6J3m3rGg2W233Ra5lFtmFBzEwU0TXJRZWMi72Nuzx9beK8oSCub0008P TFp4efDBBwPPlQ8DYc8qcZP79u0bL8DD+MMicL/4xS+iKlj4jP7h4ss7SziDq666KkyfPj2gRDdh kiTfwmzPPPOMZY23jAuPP/54FF7DElFMEFqBRdoOOuggS4621EF+v+gfIUIOPfTQiDHvPWEYTO66 667IbZr4kyeffHLWe8z7xnXC1RQhlOOdQxnKu+bfe6uzElvGSMaYadOmxcpzFP4mhPmwPhF/fdNN N42+J+x8vu2TTz7Z5HT//v2bpDV6wscff5x6Cf7ZSM2QkljpMaSSfUvpbkMnMW7wnUJIHRNi5jKO rbHGGtG7vNpqq9mpKAQQE2GEvLAwL5y0GN98R/Hdw5hBmKbtttsuLstzz7jEgmhMWjFWMD488sgj cR52unfvHh8zLvBuMm77tRHoAyFAUCLTpsm2224bLVBp18P3PZN1xx9/fKhmTPpFFlkkGo/5/wRh 0gu2XD/x3fnuMWF8T34n2DltRaAuCVTCDFh1iIAIiIAIiIAIiIAIlEeAkBPmyljstlyXwWJ6+NJL LxXsD67cXr7//vusUA12HUkX9aQrqOXLtfVtpO3nKpeWPmjQoLQqmqRVIkSDVerdVNP61LFjx8yX X35p2UveNjdEw+eff556r9dZZ52ah2i45JJLUvuSxs3ScFOeOXNmTm7ejdrK5Nu+9tprTerKl59z I0aMaFLGh9+w8ldffXXmzjvvLPkarbxtzR17qaWWyltXkktaSBurs9D2xRdfzLrGf/7zn3nbhnua VMK9etSoUXnbTruWr776Kq07TdIsfIfVQfiZ1ijnnntuKsO0MDyFrr/SY0gl+1ao780578eWWoVo 8OO9PaN+e/bZZ2dd0q233pp6n61MMizCm2++mfGhHyxfri33yofy8aGlcpWZNGlSVh9pM5mX/xNy SSXGEOomvBShdpJt+2PCY5GvXFGIhnLJqVxzCGRPUdelClqdEgEREAEREAEREIHWS4CQE127di36 ArG48StfF12wyIzUnc+iFIueZZddNqs2LGJY9MVbAFFHcvXprbfeOl7kKauClINDDjkkJTU7qZg8 lMD936wqs2uo7hGWzrkWsIMVludJltXtUXbtyy+/fCCsyc477xyf6NSpU8BVu1oW4nFDiR2/2A+W XvmsrbmfV1xxRRgzZkxYeumlEzX975Dnr3379v9LyLPH85r23Od7xqg7zX0fS1bvukx/8SzgGcx3 XXm6F53i3pg7trecS5bj2WJc8ZLPGn777bdv8q5aWaz3khbSG2+8cezibPlsm/be27lKbLHITbtP uerGAhzr+UIyadKk2LPA8rbWcDNnnHFGZJVtYVHYnnLKKUVbOhsftpUeQyrZN9/P1rBPWAS7Z8nr IZ13w8tWW22V8z0lf9LbicVBsdLlHuQbp3hW3n///SjMkP+eWH/99XO2R7+22GKLJvXSpg9XRL82 33xzfxlV2ccql8Xp/DjtGzruuOMizyRZ73oq2m8EAguhHW6EjqqPIiACIiACIiACIiACIlBtAriX El7CpBL/KhOHFRd83FZRiBB+glAbzRXc0YmfiKBMxm2+XMFFFVlppZXKraJZ5ebMmRPFfSR0woAB AyIXXUKC4F5MaAYExd5aa60VUDDifi9pLAKEKrF40yio77nnnrq5AN6do48+Ou4PyqjWHs8dl3pC j6y55poVmdCp5BhS6b7FN7ZCO4RfIfQKgjLUhxuqUBMtXg3hMiZMmBCY/CBkAuMv343FTJhUq/PV GEMIP0FYF66TSTtCR1Ti+4WQTEx8I4SpsLGvWmxUrwhAoDrB28RWBERABERABERABERABEQgIkCM Q6yX+dSrtJRi13hgcXr++efbYbTFAo2PRASqTcDH76YtrLBbu2B96Sezmnu9lRxDKt235l5bWyyP UpfPbrvt1qovH6vhPffcs1Vfoy6u7RBQiIa2c691pSIgAiIgAiIgAiIgAiIgAiIgAo4AVvqEKjEh REiXLl3sUFsREAEREAERaAgCsuBtiNukToqACIiACIiACIiACLQEgcGDB0fNLr744pHSJ19swlr0 77HHHotWKaetxx9/vBZNqg0RqDiB119/Pdi7tdxyy4X99tsv8I61hHz44YdZ8XfPPffcoNibLXEn 6rtNwhXgys+EwNSpU+u7s22gd/U0hoB77ty54f777w8zZsyI6I8bN64N3AVdYr0RkIK33u6I+iMC IiACIiACIiACItBiBBZaaKGstllsxeTkk0+OFvey41pvP/roo9C5c+daN6v2RKAiBPy7NXHixODf rREjRoRu3bpVpJ1SKyG0APF3b7755oD1br4F7EqtW/lbDwGeC55bScsRqNcxBCIjR44MBx98cCoc 3+/UDEoUgQoRkIK3QiBVjQiIgAiIgAiIgAiIQOMTYBGvXr16RZZa8+bNiy+IGLG77rprfNwSO1gP d+3aNWC55PvGwm2HHXZYS3RJbYpA0QQ6deoUdthhhzBlypSsMjzXHTp0yEqr5QGWw0OGDAnXXHNN WGSRRSqy4Fgt+6+2akPg0EMPjRbL8mPvYostFvr06VObDqiVUK9jCLemY8eO0YeFQr2svfbaLf6/ g++P9ls3gYUylVgauHUz0tWJgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIQF0S0CJrdXlb1CkR EAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERABERABERABERABERA BERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERA BERABERABERABERABERABERABERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAER EAEREAERKExACt7CjJRDBERABERABERABERABERABERABERABERABERABOqSgBS8dXlb1CkREAER EAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERABERABERABERABERABERA BERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERA BERABERABERABERABERABERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAER EAERKExACt7CjJRDBERABERABERABERABERABERABERABERABERABOqSgBS8dXlb1CkREAEREAER EAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERABERABERABERABERABERABERA BOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERA BERABERABERABERABERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAER KExACt7CjJRDBERABERABERABERABERABERABERABERABERABOqSgBS8dXlb1CkREAEREAEREAER EAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERABERABERABERABERABERABERABOqS gBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERABERA BERABERABERABERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExA Ct7CjJRDBERABERABERABERABERABERABERABERABERABOqSgBS8dXlb1CkREAEREAEREAEREAER EAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERABERABERABERABERABERABERABOqSgBS8 dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERABERABERA BERABERABERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7C jJRDBERABERABERABERABERABERABERABERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAER EAEREAEREAEREAERKExACt7CjJRDBERABERABERABERABERABERABERABERABERABOqSgBS8dXlb 1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERABERABERABERA BERABERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRD BERABERABERABERABERABERABERABERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAER EAEREAEREAERKExACt7CjJRDBERABERABERABERABERABERABERABERABERABOqSgBS8dXlb1CkR EAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERABERABERABERABERABERABERA BERABERABOqSgBS8dXlb1CkREAEREAEREAEREAEREAEREAEREAEREAEREAERKExACt7CjJRDBERA BERABERABERABERABERABERABERABERABOqSgBS8Nbot8+bNC6+//nqYMWNGjVosvpl67lvxV6Gc IiACIiACIiACIiACIiACIiACIiACIiACItD2CPyg7V1y7a/4nXfeCb/4xS/CV199FZZaaqnw4Ycf Rtva96Rpi/XUtwULFoT3338/zJ8/P6ujCy20UGjXrl1YdNFFs9J1IAIiIAIiIAIiIAIiIAIiIAIi IAIiIAIiIAJtnYAUvDV4AsaPHx8pd2kKJe/UqVPDJptsUoOWCzdRT33bYostwtixY1M73aNHj3DX XXelnqt1IoroCRMmhCeffDL6cPzAAw+ERRZZpNZdUXttgADv6COPPBIee+yxaOzYY489QqdOnUKX Ll3CEkss0QYI6BJFQAREQAREQAREQAREQAREQAREQATyEWhYBe/kyZPDnDlz8l1b1rm11lqrbqxm UQiWKigUUXDuueeeYdttty21eNH5y+lb0ZXnyUi7WBPnks8//zzXqaLS//3vf4fZs2dn5V199dXD 8ssvn5WW6yCTyYT7778/3HfffdEWRb2Xjz76KLIy9mnF7HPdEydODN99911W9nXXXbdVKO8++eST wL1Ls8pebbXViuafBSeEqL5JkyYFlJ9MCnzwwQeB+8l7vvvuu4c11lgj3HvvvZHSvXv37mHhhf8X jYYJluT9o34sxClnStO0Z2axxRYL7du3D1iV55O0sqU8b1b3ww8/HPbZZx87jLaDBw8OfLhOJhZ+ 9KMfZZ3Pd9Dan7d8165zIiACIiACIiACIiACIiACIiACItBaCTSkgveCCy4I55xzTkn3hNAIH3/8 cay8KalwMzOjdPKy6qqr+sOi9k8//fTIiu+GG24IKM0qJZXoWyX6ggJu1KhR4dVXXw1ffvllQKHK 5+yzz2529X/6059Cv379UuuZOXNmWHrppVPP+cQxY8aE/fff3ydl7dPXcoRnecCAAU2KtuTz2qQz ZSY8+OCDoWvXrnlLo9Rfb7318uZJnnzppZfCQQcdFFCiFiNvvfVW+OlPfxplve2228Jhhx2Ws9h2 220Xnn322UiBetxxx6XmO+OMM8If/vCH1HMkVuJ5ox4sdpPKXZ4LU07zvqC8ZtJh8cUXz9kff6I1 P2/+OrUvAiIgAiIgAiIgAiIgAiIgAiIgAm2JwP/M2hroqmfNmlVyb1GKtNQCZx07dgwvv/xypMBE ybzyyiuX3H9T6n766acll81XoBJ9y1d/Kee22mqr0Lt373DWWWeF/v37R9tSyufKi4IvTVCWFbLE tHJYm5IfwT3+97//fVn30eqzrVmL2rFteV6xCm5k+fbbbwt2/7LLLiuYxzJgBYzydMsttyxauUvZ adOmWRUFxwAmF5CktXdcQQhRnGh/nNyvxPP2/fffh169esVVH3nkkVHfGftQQJsQuuGOO+6ww4Lb 1vy8Fbx4ZRABERABERABERABERABERABERCBVkqgIS14TzvttNChw/+zdx7gUhRZGy6CCCqYMIMB M+bMirioKCqyiIquCoooRnBdXcPv7qoshlVXMaBiZM2sYQ0oq4CuCTBhRNeAShABQZKS4c7/vKWn renbM3fm3pm56TsPQ3dXV1dVv13dc+frU6d2ThNrGKJ97bXX+svUtm1bF3rfERt12223dYh01WGI iEyyVhOtJretGLwuu+wyd9ppp/miW7ZsmfPwdjydeUGAp67F2n399de9aF+VdtKX8Si1EA2ECKgr duSRR7phw4a52bNne26DBg0qJ8wSagBv2DXXXLPC00b4v/7666N8Xbt2dZdccomPZ41wiff3iy++ WM7rOww7gmi67rrr+rARd911lw/xQIHnn3++F455yYD17dvX/fTTT+6KK66I6uvcubM75ZRT3AEH HBClVbRS2f42evRoZy9zeJ7ddttt0egDvIwfeuihyBP59ttvdwjAuVhd7m+5nL/yiIAIiIAIiIAI iIAIiIAIiIAIiEBdJFArBV48YOPDrBnqbQIvYmq/fv1yul6IP+Zp2LhxYx+HkwMR8ojzi2hEbM7t t9/eEReVPLkYxy9ZsqRc1qZNm+bsNVru4AIlFKNteDx++OGHbs6cOV4IhROi6NZbb+0FtQI1vcrF 0Hdat25dqXLCOK6VKiDDQRtuuGG0JxyCHyXW0hXum+OOO863Ho/UgQMH+nVi2HI/ET8WI7Y0gmo2 I9ZuKO5SFl7e4TXZc889HZ927dq5Tp06RcWFAi/hOAjvgOFVT7kYwu2OO+7o1/kPMf+BBx6Itrt3 7+49ZXMNhWAHVra/3XPPPVaEDy8S97w94YQTvCiNCEzICs6Dl165WF3tb7mcu/KIgAiIgAiIgAiI gAiIgAiIgAiIQF0kkJtaWRfP3Dkf0xYBymJacpojRoxwCEJ9+vSJPOjs9AlngOizww47WFLictq0 aY685oEXZurQoYN77bXXwqSM67NmzfJehAiyYXiJTLFHEZ+YyCmbFaptVsfLL7/shbtXXnnFksot //jHPzo8Gddaa61y+5RQeAL05+eee84xCRkxXHfbbbfCV5JnicSLtfvh1FNP9WKkCbyDBw/OKvBy P5599tlRjccee2w5L91op3PuoIMOch07dnTWJ807OsyTbf2bb75x+++/v5+4jXyIqf/85z+jlz/Z ji3EvmXLlvkJ4qwsJlOLG573xxxzjMN7F+N65yrwxsvStgiIgAiIgAiIgAiIgAiIgAiIgAiIQO0m UK8F3i+++CJN3OVSHn744Rmv6Hvvvee9/KZOnepatWqVMR/7TcyKZ/r888/jSYnbhJhg+HqS4Umc yZiwKxxWHs9XiLZZmQiIiGkVGUPz8ZZ89dVXq917uaK21vb9TMxFKAEzhHVeNvBSYfXVV7fkki8R SM3woOVFBPcQoVXwPsULda+99rIsaUvOacyYMVEa8Y8rMkRZE3gJxZGr0acJgWD3L6EP7r777pw9 93OtJ1s+XuyY4e2c6aUN954JvHCUiYAIiIAIiIAIiIAIiIAIiIAIiIAI1E8C9VrgPemkk3wYBYRH JisKDfGJWK0MZx4/frwXeWw/Q8PD4duWbksmgbrjjjscArIZImc+VtkJtggrkc0K0TYrn9iqoTH5 GJ6TxDE1L0QT9ohX+8gjj7gTTzwxPETrBSaQJH7yYoIwCIQhqA6jn1A/Rh+xOMP9+/d3F198sU8n JEEmgdfCKJCxS5cuPp62PyjLf/QzxFq8mbfbbrssOX/dxcsXPHdN3OUlC97FYRiIX3MXb42JGM02 22wzWy23DEMtSOAth0cJIiACIiACIiACIiACIiACIiACIlBvCNRrgXfttdf2AhNecqHAe/LJJ3vP uDDuJcOkGRqOPfjgg+7+++/P6I2KIHTmmWemdSKGo2cKrZCW8ZeNG264wVEn4RkwRGULJXHrrbcm HeI9NA899NDEfZZYiLZZWQhyCN3EGiYUwEYbbWS7/JI0BKoBAwb4bSbAksCbhqigG4QiCD1dw8IJ O1Bd9vjjj0dVh5OB8YLFBF4mPLvuuusSJ1ubMGFCdHxF4VEsI/euxeS2tGzLjz/+2J133nmRuEtY Ee5BQiGU2kKBlwnhMhnPLzNCr8hEQAREQAREQAREQAREQAREQAREQATqJ4F6LfAmXXLEXrxvmzVr lra7R48ePsaleRPiYbvxxhun5SnkBmEYzjnnnKjIoUOHOjwxsVwnkIsOLtJKo0aNXK9evbKWjhek CbyfffZZ1rzaWTUCTGrWpk2bxBcJFQn/Vas5+9HhhGHdunWLMuOBSriGYcOG+bRMk60xeZ8Z51cM I6RDaLy0wPN4vfXWC5NLsm4exFS2zjrrZKxzzTXXjPbJgzdCoRUREAEREAEREAEREAEREAEREAER qHcEGta7M67ghI866qhy4q4dQixTs5kzZ9pqvV6uXLnSDR8+3Au9++23n9tggw2812OLFi38UPpz zz034jN58uRoXSvFIXDnnXe69ddfP61wvGb33XfftLRSbfBCxF5M8DKAfhHa6aefHm0SDiHJQu/j UsUR5iUP/XnKlClJTSpqWtOmTaPyly5dGq3HV8LJ45o0aRLfrW0REAEREAEREAEREAEREAEREAER EIF6QkAevLELnW0Cs7hwFju03m2+9dZbDs/HpNAThJPgE8YhrneAquGEO3Xq5PAuf/PNN/11wXM3 n0nGCt3khx56KCqS0APxsAllZWXR/kyTrRFDl0nYsGK+JCAsw4oVK5yFQKHvdu/e3Ye9CEXXqMFF Wglj686ZMydjLfPmzYv2ZYvVG2XSigiIgAiIgAiIgAiIgAiIgAiIgAiIQJ0kIIE3dlmzxdzMti9W TJ3fZAIrYgRbXGBOmJi8TFKFFy82depU99JLL7lPP/20zvOoSSdInGU8dqvLa9dYMNHekCFDbNON GmN4SckAACAASURBVDXKf6KEhJWkydZ23nnnSOCl3xXDrrzySvfnP//ZF01oFPoyfRvvY2IDX3bZ ZcWoNrFMu3/YGYZriGcOxd/WrVvHd2tbBERABERABERABERABERABERABESgnhCQwFsLLzRhEYh/ W52GIGbiLnFRn376abfTTjslNolh+ZY3MYMS6yQBJtXL97onTbbWtm3biM+IESP8pH6F9qgNYwNv u+227oUXXnDt27f39V5++eXuuOOO8yFHooYUcSX04MWrOdP9HnrHb7LJJkVskYoWAREQAREQAREQ AREQAREQAREQARGoyQQUg7cmX50MbZs/f36GPaVLfv3116PKEMMyibuLFi3KW+SLCtZK3gQIeTB2 7FhH7GPCMxCTt7riRTMxoNknn3ziUqlUxk+XLl0sq/vXv/4VrbOy5557Rtt4tHJOxTa8n88+++yo GsI3lMrWXnvtKI6yeREn1U3sa7NQBLc0LUVABERABERABERABERABERABERABOoHAQm8teQ6N2vW LGrpd999F60nrRBHtJjG0Psw7m62uMUWz7SY7VHZvxK49957vecp3PGgPfPMM93WW2/tvv32218z lWANUfmpp57yNTE5YUUCJO00u+2222zVLwn70bVr1yjtr3/9qwsnXot2BCsI3cOGDXMnnniiGz9+ fLAn99UBAwZEmf/zn/+4kSNHRtvFXCEUTDj53PPPP1+uugULFrgwnckhZSIgAiIgAiIgAiIgAiIg AiIgAiIgAvWTgATeWnLdw0mUHn744XKtxlMWz0e8NldZZRV37LHHlstTqIQmTZq4Vq1aRcXdcccd 0bqtIELjAXnJJZdYkpZFJsBQ/r///e/lasELlBAapbTHHnssqu6UU06J1jOt0G9tEkObbC3Me/PN N0ebnM8uu+ySJnBGO53zHswdO3Z0xx9/vHvkkUfKTewW5s22zuR011xzTZTlwgsv9OESooQirpx8 8slR6QjNH3/8cbTNSr9+/aLtU0891a211lrRtlZEQAREQAREQAREQAREQAREQAREQATqF4FaGYOX 4d4PPfSQ++mnn6KrFQ5D/+9//+v69+8f7UOQJK5m6BXHzhkzZjjEUjwdzRhWzkROZ5xxhtt88819 MpOEIViZRyKJiC677rqrO//88x0xZs3I88orrzg8CEMzj1eGmIdtszzUdcEFF9hmuSUejIhVGCLe tGnT3G677ea333333WifHUjYhLgVsm2dO3d2eItiiE20CVF5jTXW8GJUyMraYeeOcNa3b1+38cYb 2y43YcIEf00XLlwYpYUM33nnnURuhx9+uDvssMOiY4q1Ql8hNAATW1m73nzzzag6hOx11lnHb6+7 7rpeaG/Xrl20v1Qr1s/i9c2dOzeeVJRtxNl///vfUd+gEjxfv/zyS3+96eONG//62OFee+KJJ3x/ Xrx4cdQmJjo74ogj3EUXXeSIt7vFFlu4QYMGOQuVgMjLfiZD22effdxWW23lpk+f7vC0pQ2hkc+M +4Z+O2vWLDd69GhL9pOocQ/Snzp16hSlc69SL32XchGNCRnxpz/9yTGZXbGM86Ffcz7YkUce6SeB o42PP/64e/DBB6OqeVbJREAEREAEREAEREAEREAEREAEREAE6jGBVC203r17p5xzeX+mTZuWdrb/ +Mc/Mpbxl7/8Jcrbq1evjPnuv//+KN/ixYsz5sulvV988UVUVnxl5cqVqX79+uVUfvPmzVOPPfZY WhGFbtv333+fWn/99StsD+x23333cvkGDBiQ1r7u3buXy5MLszZt2qSVk7TRp0+fqOzBgwcnZakw 7eqrr47KyKVd7du3r7DMpAxcOyt/4sSJSVmyplGvHR8uK1NW1ooy7OzRo0di/daWF198Me3Ivn37 5pX/2WefTYWMrNykJfkef/zxtPoGDhyYtT76dNzuvffecse8++678WzRdiH6G4XNmTMn8d4Jz/XB Bx+M6q3MSsiyVH2kMu3UMSIgAiIgAiIgAiIgAiIgAiIgAiIgApkJFM8FrYiiOd6j+RpxQOPDmDt0 6OCaN2+eWNSOO+4YpeMhmGTbbLONC/Phadi9e/ekrBWmEaN0o402ypgPb8FbbrnFXX311Y56k6xX r17eexJv0x49eqRlKXTb1ltvPT8Uvlu3bmn12AaelXhGP/DAA+7SSy+1ZL+Eedy7NYyxmpa5go1D DjmkghyF2f2b3/wmY19JqqEyfTSpnHzT8ED//e9/Hx1GXxkyZIjLFic5ylyAlYMPPjhjKYT1aNOm Tdr+gw46KCNX8sbz008+++wz378z3buEerjpppscYUKOOeaYtPrat2+fsT4yHnfccWn52TjppJNc eF5J7Sp3UAESmGyNe4g2J9l9993nevbsmbRLaSIgAiIgAiIgAiIgAiIgAiIgAiIgAvWIQAO033p0 vnXmVAll8L///c/HBG3durXbYIMNXKNGjarl/KZOneqH4DNsnrYgViMo1xQjRiliGDZ48GDH8P+a aoT7gCNG+ILKCrOUMW/ePH89auq5VrVdhMpgsjVCJxBCgTjVhDZgSRzq6rJi9DfE6tdee80RaoOX VXvssUdaqIvKnmuh+ltl69dxIiACIiACIiACIiACIiACIiACIiACVSfwazDMqpelEkpIYPXVV/ex QEtYZcaqEHX5yGoOAbxbM3m41pxWVq0leLUjgFdWBK9a7aU9mnjVoWd2aWtXbSIgAiIgAiIgAiIg AiIgAiIgAiIgAjWZQK0M0VCTgaptIiACIiACIiACIiACIiACIiACIiACIiACIiACIlAqAvLgLRVp 1VMjCLz00ktRKAuG83fq1Kla2zVz5kz3/PPPu2XLlvl2WHiGam2UKi8YAfW3gqFUQSIgAiIgAiIg AiIgAiIgAiIgAiIgAhkISODNAEbJdYdAgwYNopN56qmnHB8zJqQjfnF12ZVXXunjAldX/aq38ATU 3wrPVCWKgAiIgAiIgAiIgAiIgAiIgAiIgAhkJiCBNzMb7akjBHr27OnGjRvnFixYkHZGu+yyi2vZ smVaWqk3Dj30UDdy5Ei3aNGitKo7duzoNt9887Q0bdQOAupvteM6qZUiIAIiIAIiIAIiIAIiIAIi IAIiUFcINEilUqm6cjI6DxEQAREQAREQAREQAREQAREQAREQAREQAREQARGoTwQ0yVp9uto6VxEQ AREQAREQAREQAREQAREQAREQAREQAREQgTpFQAJvnbqcOhkREAEREAEREAEREAEREAEREAEREAER EAEREIH6REACb3262jpXERABERABERABERABERABERABERABERABERCBOkVAAm+dupw6GREQAREQ AREQAREQAREQAREQAREQAREQAREQgfpEQAJvfbraOlcREAEREAEREAEREAEREAEREAEREAEREAER EIE6RUACb526nDoZERABERABERABERABERABERABERABERABERCB+kRAAm99uto6VxEQAREQAREQ AREQAREQAREQAREQAREQAREQgTpFoHGdOpt6eDIrVqxwU6dOdalUyp99gwYN3EYbbeSaNm1aVBo/ /PCDmz9/vq+DujbeeOOi1pdP4XPnznV8zFq2bOlatGhhm1qKgAiIgAiIgAiIgAiIgAiIgAiIgAiI gAiIQJ0hIIG3Fl/KZcuWuS233NJ9++23aWfRt29fd9ddd6WlFXLjn//8pzvllFPSihw1apTr1KlT Wlp1bPz73/92Rx99dLmqYbXKKquUS69rCR999JH7z3/+40aOHOkmTZrkDjnkEHfggQe6Ll26uNVW W62una7ORwREQAREoIQEFi1a5IYPH+5efvllN3r0aLf55pu7zp07u8MOO8zttNNOJWyJqhIBERAB ERABERABERABEQgJ1DqBd+HChe7rr78Oz8E1btzYrbfeeg5PTQyvVsStxYsXp+VbffXVXZs2bdLS avMGomVc3OV8zLO2WOc2ffr0ckXPmzevXFp1JMyYMSOx2uXLl9dYgZf+TL8ObZNNNnHrrLNOmFTh +vPPP++OOOKItHxDhgxxfA4++GD3zDPPuGbNmqXtz7ZRVlbmvvjiCwe70HipUNfEYvrvxx9/7D74 4AP/4Zmy2Wabud12280dcMAB7quvvnJjxozxYvlWW20V4cCT/bvvvou24yuNGjVyTZo0cWuttZa/ ng0bZo+KQ1mUGRptad26tVtjjTWi5B9//NHf+zzrzHi+tWrVytdHGtfv888/989DyxNfUuaGG26Y U79YsmSJmzhxYjRaIF5Wtm36C/0mm82cOdN9+OGHbvz48f4abLDBBm6vvfZyu+66q9t+++39cz7b 8fF9Sd8VvOTZdtttHSMdMhmjIej3PF/zNa4v5XPN4kYfQhzL1RDOmjdvnpad686IjZUrV/p0nhE8 K+JG27/55pty58D9H/bf+HFsz5kzx02bNi1tV1357oTLlClTyv1twMnCZosttnDcs5Wxyj5D6BP0 jSQLr29Sf+YY7vm111476fAoLenYXO6FqIBfVmhr165dvbhr+/j+Quy9+OKL3YgRI7zQa/tyWdbl /pbL+SuPCIiACIiACIiACIiACBSMQKoW2aJFi1LNmzcnFkHi55133vFn061bt8T9HDd48OBadMYV N/WVV17x53TJJZdE53zsscdWfGAVcsydOzd15513prp27RrV+fjjj1ehxMId+uOPP6aGDh2auu66 61KtWrWK2rdw4cLCVVLAkq6//vqojfF+PX/+/JxrevHFF8uVE79XDjvssNSSJUtyLnPAgAHlyqSN lFtTeeZ8cr9khMeFF16YeJ52PUKOJ5xwQlTF1KlTsx5nx9uScs4999zUJ598EpURrgwfPjxjedts s02qrKzMZ2e5/vrrJ+bl2Wd25plnJuax9oRL2nbggQemnn766dSKFSusiGhJnW3atMm5vLBsWx82 bFhUXriyfPny1KWXXpq1bM4/E7ewLFvnORBeN2sDS/p1Nrv44ouztiUsK2m9e/fu5YofOHBg3mXS /vA+45mbVN9zzz2XVt8PP/yQmM+OzfYdyP2QiduNN96YVk9t3Nh5552zsuGeydeq8gzhvgq/p+wa hcuXXnopxT2S6bqQd9asWRmbXZV7ISx08eLFqc6dO6fxS2rTqFGjwsOyrtf1/pb15LVTBERABERA BERABERABApMILs7WcFk5MIUhCchHkyZDM8mbPbs2ZmylPOOy5ixluz47W9/68455xx30UUXlazF eCOefvrp7qijjipZnblWhEdi79693YUXXui9L3M9rrry/e9//0usGs+9bF6G4UF4cfbq1StK4vzx JluwYIF74403onRCNzz66KPRdkUrmbx0uQeTvLgrKq+m7f/yyy/dvvvu666//vqsTQufOZMnT47y ht6zUWKWFcq55ZZb3A477OC9VONZs3nB41FqXpt4mMZHJ1hZnJPZrFmzbLXCJW3DC+/II49022yz jQvPk4OTPAArLDSW4dNPP42lOO/9TAiRq6++uty+MIHzh9vDDz8cJmdc//777zN+V1TkxZ7t+yNj hcGOd955J9j6eZV7MV/jmoR9Iu5Va+X16dPH3+u2jed2NstUDsdkO5bwL7Xd8ELPZox2iPf9bPmr +gzhnq5oxA2jdMgXPofibcrWZ6tyL4T18N3x4osvRkl8t9Cv6aN855gRvsmeVZaWaVnX+1um81a6 CIiACIiACIiACIiACBSDQPlxpMWopUBlMlHW22+/7Z588kl37bXX+lJ33313d+aZZ/php/vvv79P I0bsSy+95IcwX3nllT4N0eJvf/ubj0laoOaoGBEoKIHLLrvMnXbaab5Mwo1UJERZ5cRB5Ec81rZt W3fbbbdFIRTat2/vHnroIdezZ0+///bbb0/7MW5lJC3/9Kc/+eMsRMOmm26alK1WpiGa8EwI7Z57 7nEdO3b0YVwIk/Df//7Xh7dA+EwyhtAT1oGwCk888YS7++67fbb+/fv7mJRsIAITNoTQD4hHZoR9 QNwPh9cTOxpRn2HOjzzyiGX115MXOTbsnzAAxFh+6qmn3HXXXefzrb/++v6ZuN9++0XH3XDDDe7w ww/3YQEeeOABZ8Ijz0vEUoRiJiOEBeK/hXthyPXvfvc7N27cuKgfLV26NCqXsAknnXRStM1x9jym /5111lnRPoSnAQMG+O24KA0bOCDemvG8ps20j2vw3nvvuUsvvdSZuEg/JlwAQnQ+xrB8jGHphKTI ZldccYWDN8IbdZuwButs9+Stt96aMbQD99LOO++cJthm40aYAEI9hJNXUsaOO+7oX2CeffbZ0Slw 7//973+PRHKeHa+99ppnxjUeOHCgfz7w0ujee+/NGiud8yNUhgmG5LfrF1VYi1eI0Y4wyTMNbrCJ 2/333+94FldkXL+qPkO4p7mXeY4QpsHuI8q94IIL/LOIvki/JUTMoYceGvVH2sfLqd/85jduu+22 q6i50f587oXoIOfcHXfcEW3yncJ3C7bmmmv6ZxR/m/ESBy78/UX894qsrve3is5f+0VABERABERA BERABESgoAQK7BFckuLee++9aJhg3759M9Y5efLkKF84dDnjAalU6qeffkqNGTMmxXDpBx98MPXo o4+mxo0bl5o9e3a2w6J9S5cuTRFKgo8NqWYnwyRfe+211AMPPJB64403UnPmzImOyXeFYY0M2QyN 8mxYZy4hGhj6++GHH6ZGjBjhQxo8++yzqY8++sgPCabdMOa8sxmhEKxOC9GwcuXK1Geffea5PfPM M6kvv/wyRVq+xnEM9aRc6qGdlBs/72zlhiEkwqHOHEM5dp1smWvZy5Yt822BGcOmCY8wadKkSp1n nz59IobZhk5nO8+jjz46KgNWceN6hkP6ue6VsXA47sSJEytTRI05pkePHhEzhv/Tt5KM+5nQBdbP 99prr6RsqTvuuCPKw3MjyaZMmZJ2HW6//fakbP4ZFF4vwngkWa9evSqs044jNISdA8+huNH37733 3igPeW+99dYo27Rp06J9/fr1i9JZ+eKLL6J9tCm07777LtoXP27IkCHRPvpWpqHdCxYsSIVhdwgV wXDxbPbVV19FZXMulbW2bdtG5cSfIfEyrY1cu1wsG7eKjrdrGS55ZiZZ+/bt/TkQniBfu+2226Lz 7927d76H1+j8Yf+76KKLovPk+uXyXVDoZwjXz65n0nf4VVddFe0nH+GZcrFC3At8Z1jb4BP+bWNt CP8egE1lrC73t8rw0DEiIAIiIAIiIAIiIAIikA+BWhWioaDKdqwwvPTwJmOIP54pTCTCsPfjjz/e e8jgFXX++eeneWDFivBeb6uuuqr3emN4+z777BMNX8R7Cg9jPN/wsmPylGuuuSbrBEhh+XjYMfQR z7amTZt6jx48d/7whz+4Tz75JMyadR2vuD//+c/ei22XXXbx3nKUi8ceHmZ4x+Hhhmc05eNBl6s9 /vjjfjIpvIng1q1bN7f11lv782ZypoqM4Z6XXHKJY3IljmNisB49evjzxquPcjl/PFarYpdffrnn xzUKP3hJvfrqqxmLJiwB149Js2gLzM444wzvrYk3J6Er7rrrrpyHp2asKI8dTBqER7sZzOKGV+gx xxwTJT/33HPReqlX8IZkqC+ec++//36pq/f14TFHXzVjHW/JJONah958uQ49TiqLidLwDjV75ZVX bDVtyT1IKAczRh7Ewy28+eab7sEHH/RZ2rVr50444QTLXqklnoQM9Se0iRkeeWahB2+m0B2WN1zy rDILPXjxHA7ruuqqqzJ6lvLsJDQDSwwPY7zUa5pVNIFesduLh68sdwJ4J2P0K74T8EzH8Ozl+zab lfoZghc139sY7cWbF8/eUln4nWEjDeJ1hx67PFNt5Ec8n7ZFQAREQAREQAREQAREQASKQ0ACr3N+ ZviDDjrIZRJcDP2gQYO8qMew17gx3Dh+PEOiEY4Y8plkDP+tKHYuQggCLAInoSfCOJaIPAhBDNvN VEdYL2URc5R4lzbsONxv6zbcn+1w+LTtT1oixB577LGJ5fJjFMEYcTmbMQs3Q1TD+uP5aQ8iJkNA K2vZYixmiomLGMC1NFEtqW6YIvgijE+aNCkpS8HTQuGPYb3hkP+wMvq3GUNoq8MQRQizghiJaEqf 2GOPPXx811K25y9/+UtUHS9xeLGRzXjhQwgEjJcPVbHw+kyYMCFjUdxLHTp08PvpV+FQcuJWnnvu udGxPAMKJS526tQpKvett96K1kOBN1uYguiAX1bCvKHAO2zYsOhZgWDFMy6bIXrz8sesJoQNIEzE 3nvv7SyuK30b40VPqYxQDYQVwZ555pkqv/wqVburux7uPQtZcuKJJ/oXff369Yuadeedd0brSSul fIbwd4K9GOJe4WU03+OltPA7I/wuCdtAOJEwZEW27/HwOK2LgAiIgAiIgAiIgAiIgAgUhoAE3oRJ 2Zj0B685JhQZPnx4WszS119/PS0+pl0GPOAee+wxH7PR0ljajxxErcGDB/tYieGPIETjzz77LDwk Wkc4wNsXYTc0PPZoIz/2zP74xz/aasYl9Ztg26pVK8ePWCaJQXhB2LR4nmEBSWJ2uD++zrkhRhGv L5z4C5EKptnsm2++iXYjqJ166qleuCYWKm2lzWYIG4jqlbG4lyscKY+4p0lCE95cxMY1UZz8xDdF uOba0U/CSWYQDhDo8K4tthHf1WyzzTaz1XLLMO5o+GO9XMYiJiRdfzzEuW9KZfQZE3aok3i5FRn3 Nl7H3MNMLlgVGzt2bHQ4XuqZDK9rYrqasf7555/7TeJf2jlwj5jnoeWtyjKT110o8ObjwcuIBrPw fg1fpHDPMXKiIsPD2Ix7Mez7ll6qJfF5EVS5DvZMZYQHIuGNN95YqmZ4Yf/mm2+O6mNER6ZrGGXS io9LbhgQeDFGOdh36vPPP59xsrVSPUP47uUFMCN9MNpG/OA999zTb5fyv/A7Y6ONNspY9RZbbBHt q877M2qEVkRABERABERABERABESgHhGoVZOsJV0XJifJNLM6Q+pzMQQSJiFCUD3iiCNc/AcMaYhn 5jWGoGc/CsPymQCFz9NPP53maYsQGHrcICrhnWfhD0aNGpU4SQqetqHHLl5DfELRBOEJr1ETH8P2 xNfDyaIQJ/CgNCPkAB9+5HK+Vm9Yl+XNtOS8/vGPf/gQBuRhMicEatqH4bUXihHxchCgmQSHH7AM P2WiITO81Lp37+623HJLf66IKgjC2UQyOzZcMilN6DWNxzDCDCJekiHQH3fccdEuxGHaGApSePYy PBVRF09rDOEHL1UmPyqmhT+i11133YxVrb322tG+adOmReulWkF04j5IslDYT9pfyLR4XVtttVVO xfNChU9lDYGUZ4xNokQ58RcN8bIJoYJgyH2B4eFOGWFoA5tEMn5sZbfDodjbb799VAwTKZmFE39Z WqYlQjUvZhCIzAuavOFLrVzv4fAlBWUwKVU8LVM7CpEePntDz3kL24EneCjKF6LOXMqgXusnPLcJ E3POOefkcmi9zMOziMkmMfqmfTfz4oIXebx0xTJNtlaKZwji7nnnnReFauHe4UUnkxhWh4XfGdk8 1MPvoPC7qTrarDpFQAREQAREQAREQAREoL4RSFa1ahEFwhTwqYohJIbepkllMTO8CbyhOJGUN0xj SL/9gLR0fkgi/tlM8OYBZvtZ4q0XDssm5mQ4c7rlJdYtcWkRgyqy0LMrk3CLBw7hD7p06eK9exlC n4shkuO5FhdK8TDkPBB4EEsXLlzo4/wmlYnYFoqv8Tzrrbee97C1+KTE9c1VHEJgQ/Qwb2i8oQgZ gDd0NkMsMfG8TZs27oknnkgTd8NjDzvsMH+uf/3rX30yIgIifaGGz4d12bp5iLNNXOdMFgp0oTdW pvyFTie+MfyInxo3XoqUyswLlvroA6HwXag2cK9auBa8uBFHEPytH1EPQk3fvn0rrJKh2QhNHMtL GeKE2zXHi7xQAueiRYu8ODlkyJCoTeFLLGJME/ua+7dz585RnlxW8Ib86KOP/EsQy//hhx/aappn fpSYYQVu9vKJ0QeEzyiVmfBXqvryqYcYstZP/u///s+/lCJuvKw8AZ77di9yD4bPZ76v7DpzHxMe If6dVopnSBgj3M6AeqtL4A2/M7IJvOF30MyZM63pWoqACIiACIiACIiACIiACJSAQK0XeAvFCC+s ESNG+OHieOggHiCkIALh0bvrrrtGVWWL4Rpl+mWFibiSDFHWLPSOsbTQ2xFPW/OCtf3hEg8uvMsq 8uZDDLFy8UbEw3a33XbzwiDnifcNIiqi0bvvvusnC4v/uA3rDdfx/E3Ki3iOSGw/EPnRh9CXych3 9913u/Hjx3sPXRNz8GDCUzZklc8PSDyAEZkw6scLOxfvzfDlAUP0EcmzxRJG5DWBFxEBQTOXejLx qCg9nMQqHEYfPy4U95k4rDqMMBuIhiZQ0gZCW8RfgBSzbd99911UfCh6R4kFWKnopRMvTxDjcrkO 3JOETuEFE2Ze//ThMGZoPs3mxQOjBjD68tSpU70gbaIX6XgXM0liaJlib4Z5ktZ5PvExwzsx7APZ BCM7xpY8B+yZELbX9hdzibBtz7h58+ZFz9Ji1plr2Yi5jBbgJRZceBlZHd7Euba3OvNx75nxgjQ0 vpcZXUMoJvoo4XmYcDW0UjxDwvpYpy1HHXWUv8Z48pfawmdVttBD4XdQGH+71O1VfSIgAiIgAiIg AiIgAiJQHwnUeoEXEYKwAEmGEBtOGpSUhzQmE0K8S/Iu5McynyQv20zlWTqiqU28Y2m2DIcyMmlS 3Ag9YcYPzDBcgaWHS7wgKxJ4Edcszi4/GJNiolIm4hGeTDDBcy8XC2PvxfOHQ7MzxfRFgGTiqNCD MCyH9vIJLVNZYR5bN3GXbQT7MJ6v5YkvuS6vvfZalAzfihhHmX9Z+eSTT4oq8IYenHPmzIlXM+NK 5AAAIABJREFUH20jSJlli9VreYqx5F4kbAoCKPcafbbUXoZhf+ZlAv0O7+JCGvd969atvXAaFyGJ N8yEhPkYw8YR60zY5FjCNoSiSz7lESolm/Hih1AmlS0/W9nsI2wDzxh73uYzlHvKlClR8byMKqUR msXiDxOiIXyulbIdmeoiPjRep/QT+gfeqaGwnum4+pTOdQu9Y7mmcbNJ80jnpVRc4C3FM4S6+Y76 85//nHbvM9EgYYp4oVpK4/vdXtIyWWvIIGzH7Nmzo82qTkgZFaQVERABERABERABERABERCBnAjU eoGXH9mZPCRzESgY5o+3WijEEG5g//33d/YDBQ83whaEAktOdLNkQuTIZqEgmUvMy0033TRbcX4f P/YZOk6s2LhYGh6M8MIPSz7jxo2rMIwBx2Y7n2z7rF4EZcJZmCGS4bHED0s8LRcsWOC9F4kjHF4r y5/PEi/mnj17+pjA5pGXdPxPP/1U5boQ+opp1kepI9s1DcXfYrcp2/kyHBqP3VJ67YbtCSc4JB3B EMGkkIaHLP2LFwQffPCBF3RNzCTeM0J3PqEh6KO8WOB+wHhe4SleFeP+whBJEWt4fhBz9+STT46e e1Upv6Jjd9ppp0jg5fmai8HTOJI/1/AsuZSdbx64WWzhbC+38i23KvnpJ4SvsZeaTLzJ95bsVwLx CR0RTLOZTbYWvhQrxTOEvsV3L0uEekJF2MtZJhvk75NSvmDYZJNNIkwIvJksFHjDl4+Z8itdBERA BERABERABERABESgcARqvcBbVRQIJyYY4lXGBGmID0mGN67lTdpfyLTQwxdxsyLLVSRh8jLyEqKA uKDEE6Z8PBnx8iQ0RXiOeEjjYZeLSFtRGzPtnzBhQpq4i2fxn/70J5c0xPPee+/1E+FkKitTOrFw EcgQ7zm/J5980g9nxmM407lxvRHCjAdxk3fcccdMVaSlE+MYIZUQGMW08Ec0LwUINZLk7R16oIc/ 1ovZtppYdlzcJq5soQVeO2/EbMKrIBLZhGV4wdG36cf5WCgIMxliVQyvdIahV6fBg5jCGCJ4Lhb2 YfIX67rl0hby0J4VK1b4Z0SuxxQ7H2E0mIzyqaeecrwMYyn7lQAx1fM1Qjrw7DcrxTOEF2CIuxjP 82uuucYxqoeQEXwfEaZh6NCh1qSiL8PvDPp90oSTfPeE93L43VT0BqoCERABERABERABERABERAB 17C+MyDWntkLL7yQUdxlEiIT+ix/MZehyGwTNmWrL5c8/ODHYwmvRYadIqTi0cR54+lF3Fu8c0JR AK/Q+Kzh2dpRmX2vvvpqdBiT3RHDNkncJVM2L9WokISVP/zhDz6GLzORm/FjHy/lbIYgbIagxPD6 XD7EXi62uEu7EP7Mk4v+aTFarc22HD58uK1W20Q9eGCOHTvWh+IgPAPDn/OJoxydQBVWEEuIx2yG cMPEYcU0BNkw9Mh9993nJ/grZp01vWyEb7NHHnnE5RLX3CZX5DhexuUTu9fqKuSSZ5R5Qhey3KqW RXgNM8LelPJ7y+oNl9xfeK4TasQ+xAoO47WG+Yu1zsR+NjLm97//vSPET6YPYZvMCHuBkG9WHc8Q XhbRDjMmCw3baOnFWtoLKsp/7rnnEqvhu8f6Gt9J4UupxAOUKAIiIAIiIAIiIAIiIAIiUFAC9Vrg ZbKQcMhvNo+wUk9YEwq8eAA+++yzGS/8V199VaFQycGIu9dee62f2CpT/Fp+vB555JHe89AqLLbA G05aFp631W9L4rcy/L0qxoRv4bBlPKNuvPHGjEXusssu0b4bbrjBhfEZox0JK3g9h2ERErIUJAnv Y2JvmtFX4oaHdphuQ/3j+Yq9jdcqE/1xL+FBTqxXhtlbbMdi12/l21BntnlhwIRUme4HOwYBErHs 8ssvrzCvHRMuGWYdCsuEJDExJMxXX9bxMg3jw2aKo2486CN33HGHbfrnWLShlTQCfI8x6SYGNxM1 0zKVcIMXhoMGDfJe6zwD+BCOB9GylPbAAw9E1RFCJZvtvffe0Xcgzwg8Z0OrjmcIoUBCT+Lzzjuv Us+i8DxyXQ+/M/gumT9/frlDw+8YJoXMNDKm3IFKEAEREAEREAEREAEREAERKAiB0v7CytLkuCcN 3n7ZPlYUx1U2HzELw6GHeMjEy+IHMj9Wwlh9FdVpYlFF+bKdAzO2hzEmmSANzz+GQYZtxHOXsAuh ZarXJtoiBi3lIayGZdk65xx6gjIRlu2LL63eeHq4bTzIG6bbeiis33333V50s30sCR+BBypiK20z C/MkrWeqF6EtjMV4wQUXODyiwjI4lg+eZmYIJYiSmUJmLF682E/gs99++/mJ3AizQYznYhtxU80Q K8MJ+kjv16+f7faT51WH5yP99u9//3vUDltB5CQsSikNr+yzzz47qhKPx+OOOy7xuuLRzn7i1CJM 4/VOSJF8DTHrnnvuiQ6jH1fkPR5lroMrPHtvvvnm6MyYFAzxnHswbp9//nnaM46XBEcffXQ8m7YD AhdddFHk2R8kV8tqOGrCGsC1LvTkhlZ20hJvYb5bMLyuiWNdkYXPfkYbhFYdzxDqJ66yeY0zWWU4 2iZsX6HX8cbt3bt3VGz//v2jdVb4zuG7x+ykk06yVS1FQAREQAREQAREQAREQARKRKBaY/B6EW3K ty715S8iWMpFHimhOBeyIMzA22+/7Q5utKpPXvqfUW7wUce6ddZZx3U/qrtrskoTPxkawzERUSxf kzfedPeeeLKfnCicmOq8nXd3I2f8PPPz8D9e6MZeda3r0GE/16xpMzdp0iQ/0QkVWTm+0jkLfJ0t 1lzTHXpoZ7fuOuv6ZNr16f/+51p98bVrRfsWL3dDjjvBMUS7w34/x7zkvAiJQBw7K5O23XbM791e e+7p8DDFuDBPnH2uj9fpExYvd8NOP9u9PuAqt9322/nzRDwkZm5b51zbX3iQN/XSq768Dvvt53bY YQd/OP+1X7rSbf5LvtmP/dud+eJLntlmm23uNtlkY8cM4xM+nuBGjhoVta31ppu6tjNmu5Uzfg1t 8P2sWe71115zH44bF+V765rr3YKnn/OhH7gWGO0bO26cW/LKK1E+zoEJaxBobBK8/ZaVRfvd11Nc z4039bFyGRaKF+y7777r4wDvSqHBeX5002B35wujHZPeMOkMtuDHH91zw4d7sa7p2F/7iXv5Nbdy 1Z/7DPm6rrGm+8POu7tPP/nEHzf0tDPcuNdec42bNXPEHSbGIB5ICHt4DZsgSDxGZl4njuq2227r h6F+9913PvTAsGHDynllhkN7fUVF+I9JBpl0y7zM8MBGPKTtzBgfTl53xhlnFKEFuRUZesuHR2Sb tCfMV8j1gQMHeq94e2EAJ+5LJqjiHsSTnUkVQ3bUT2gAi4GLaI1XKQIkfdSM0B/EtyZERyiK8CID IdMEdwRjhCfSL7zwwjSPN0JXENaBlzA8M/DSN8P72QQWxJ4uXbp4z2jbb0uGcP/rX//yL0hGjhxp yd771V5w0MeJx0vYkVyNtnGOFi4lDLOBmGdtozzuy0xl86IFT8qHHnrIV414Tpu5/7i3EP95psIp 9HYmVEMxvQN5kfPoo486JlkMJ9bEY5LY2hjiJF7Y4fPV78jw3yeffOLPkzLNsnHj2QiD0Duf4/j+ C6/liBEjfHHwoC12f9MvGHFAyJvqtviQftqGR3spjBcGCLu8CA37EC/1eHF5xBFHRN+51p6HH37Y 8fcDI0bM8E4lzA/P1gMOOMAnF+IZQkF8nxCmiFEfZrSX+4hQB4i6a6yxht/Fy7mrrrrKjyYggTZx zxxzzDH+O9OOL8aSvsWLUIzn4uqrr+4nbGWED20yI/wTz0mZCIiACIiACIiACIiACIhAaQk0SGVS UovYjrKVK50b/YpL3X2/c6P+i6pbxNpUtAjkRmB62Up3z/KF7q3ttnT/fnOsF5HwvOQW4cd8+CO2 ohL5YU7oBzylsxkiEZ7ZGOJf6DWW7bj4PkRSxMnQ8zqehx/lFQ1Njh8TboeTDCLeh57XYb5M63g2 4z0et8qUFS+jMtswwyPbxM6KyiCsAF649gIDUTeM0Zx0PCJRONkQojDXKR4zm+sWxmxmSDtxS3Mx BFomTosbcY4Rg3MxQo+YeFlR/ptuusmLThXls/3ZvmLgwX2FR2dFxoucJ554ImOc9PB4XiaE/TNb G8LjWEcsYxLGiqxPnz45T5Z3yimnROJYReWG+6dNm+Y23njjKIlzyvSihEyEEtl00019fsRNvJ3x 9MQIiYFwmY/xcsueSbysyHdiL+7tcCQKdSPkE2e9FIZYH4bZidfZrl276CUu++DHi7FMxv3OSwez qj5DGJ1iLzqtzPiSl4qhRywvhXipZy+nyI+omimMU1XuhXhbEHjpy5mM2NqEQKrsKJGq9rdM7VK6 CIiACIiACIiACIiACNQHAiUN0VD2wxxXNug2l9qtg0v1ONm5kS9L3K0PvayWnONGDRu5v67awj0z abZrePJZbsXLrzriNCNCEdPy/fffd8xSn83wmENUQ5ipSNzNVk6++xhCS70IOkmGiFwVcTepzHzT EIeY3MgMwQ4v1VCIs32lWMIMD1faRVsyGcIuog6edibukhcPy2yeagivcaEDz2C8hcPrRBnE1wyN /TYUO0yPr5MnU5/MZRg65SEO5TNcHlEsl7ZR9gknnBBvcto2PIgrSt/Ndg0QUxHUs8XoTiu4ChuE x8nFwpjKFeXPtcywHMSyeP9BfM5kbdu2dYSFMePlVBizfLXVVrNdJVu+8cYb5eoywbjcjiIk0Key 9Svu0dBatWqV9aUNIztCq+ozhPsOD/xMxrMhnOCMfLyIIY5xaPF2hfsKuY7Ib6Eu4uXyzBo1alS5 PhvPp20REAEREAEREAEREAEREIHiECiZB2/ZrXe61IBrnVu2rDhnolJFoAgEVm6xmVv0+D9dww03 8MP2EaQQfAnfgWcUnoF467Zu3doR+oPYovlYoTx4wzoJGYFHJ95liESEHMi3XWF5tl5VD14rh6HS xIOGWU0y2kUsSYblMyQacQXxORTNalJ762Jb6Bd4meL5yRBwvJrxVuS+y8cK6bWYT701MS8sCfWB J234giKXtlbVoxLP0zDMCbHsmdiyrlpNfIYU417A83j8+PH+pSd9ilAsG220UZUva1X7W5UboAJE QAREQAREQAREQAREoBYTyE+NquSJli1e7FLX3yJxt5L8dFj1EWj0zWTX4MF/uSX9T/ciKUIpH0Qn PDjxkiP+ZTFjguZ79gzpDj1l8z2+2Pnx/szVA7TYbQnLp0377ruv/4TpWi8dATxWmTQyPnFk6VpQ 92riWcWn1MbLr3iIEGLG1mWrL88QPI/x5OcjEwEREAEREAEREAEREAERqBkEShOi4clnnZs3v2ac sVohAnkSaDrsSbf4p5/8hFiEbMB7icnT8OQlziVCRj4xPvOsXtlFQAREoNYRYCJRm4iPxp977rlp 8ahr3QmpwSIgAiIgAiIgAiIgAiIgAiJQgwkU3YPXi19MppbBVrZo7pZst7VLeaHMuZRL8d/PywzH KFkECk2g0cJFbo3PJyYW23jmLNdw1H/d4oMP8KKuibnmuWvLxIPzSGRyGhuKjscdk3FVp82cOdMx ezyiNhbOQl+d7VLdIpAvAWI9Y8QvJeYpYVVkyQRGjhwZTeQ2evTo5Ew5pBKzPLQLLrgg3NR6NRGo afdCofpbNeFUtSIgAiIgAiIgAiIgAiJQYwgUX+B9/yPn+CTYyjVbuEm3XON+3LSVF87wiJQ3ZAIo JZWEwOa33+c2HP5iYl3NH3vafdfhN95j1zKYsGtL0lnPx8L8Tz31lONjNmPGDB/X17ZLvbzyyivd 4MGDS12t6hOBKhMI7ysKO+uss6IyzzvvPDdo0KBoWyu/Epg+fbqrzIRwv5bw69o+++zjmOiPibf6 9evnNt100193aq1kBGryvVDI/lYyoKpIBERABERABERABERABGoogaIKvD977/4z8dQRd7+5+Rq3 oNXGbsWyZYmekRwY/3GSWJgSRaAABCad3ceXkiTyrvHO+65s4tdu6ZZbRDF3ib8bfirTV3v27OnG jRvnFixYkHYGu+yyi2vZsmVaWqk3Dj30UId31aJFi9Kq7tixo9t8883T0rQhAjWJAP2zV69ebsyY MZEHOu1bbbXV3EEHHVSTmlqj2oJnc7du3fxkg+a5TwOZSItnVT62xRZb+OcHkz0SW1lWPQRq8r1Q yP5WPXRVqwiIgAiIgAiIgAiIgAjUHAINUjbevAhtKlvwo0tttatzS5amlV7WdFX3zZ03ugWtN/E/ vs1zF4HMBDNbN9HMlmkFaUMECkTAPMdZbnbDbW69F14uV/KMHt3c9/1Oc02bNnXNmjXzH9abNGni J14jvAL9VyYCIiACIiACIiACIiACIiACIiACIiACIiACpSJQVA9eN2duOXGXE1u51prup81au+VL l0aeuwi4CGR8Gjdu7JeIZaRL3C1Vd6jf9SDuMmnaoj13cy5B4G38/Sw/wZr1UWYSZ7I1+msoEKu/ 1u9+pLMXAREQAREQAREQAREQAREQAREQAREQgVISKKrAi+iVZCQjjCGmkcfEXQQz+5jIawKvRLMk kkorBAHrpyzpk3jkJhm9GW9z+q592OYj790kYkoTAREQAREQAREQAREQAREQAREQAREQAREoNoGi Cbw/i2bJAq9zPwtpiGmhuMsM53xM5DXRTOJusbuByocA/ZHPKhkEXssTirysc0woEqu/qj+JgAiI gAiIgAiIgAiIgAiIgAiIgAiIgAiUikDRBN6KTgBRDAsFXjwnQ5FXAm9FFLW/UAQQaPl4b9wMAm8D 53weE4JN3LVtE3kL1SaVIwIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIVESiqwIvghSgWN0I0+H2/ TKpmMU1N4GXJxwTe+PHaFoFiEDCB1zXOfluQz0RdlmzbpxjtUpkiIAIiIAIiIAIiIAIiIAIiIAIi IAIiIAIikIlAdiUr01EFTGciNRN4ibvLhxANFoOX/ZiGvRcQuooqR8AEWvpbWaNG5fb7hAY/v66w vOGS/eG2+msyQqWKgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAgUlkC1CryIYHwQ1UzoRewNPybwFva0 VZoIlCeAQOuF2V9eKsRzIO+acBuKubYez69tERCB6iEwd+5ct3jxYrfGGmu4Fi1a+EbgbT9jxgy/ vv766/uXiNXTuppbq7jV3GujlomACIiACIiACIiACIiACIhANgI/u8dmy1HJfT+LXhUfHBd5Tey1 pe3X8mcxXByKz6HhL566FfVeE3ZZykRABGoGgYkTJ7p11lnHbbLJJm7NNdd0ixYt8g0bOHCgTyO9 b9++NaOxNagV4laDLoaaIgIiIAIiIAIiIAIiIAIiIAJ5EqhWD96wrQiXmC3DfRWt45k1YcIE9/LL L/sP288884z3BK7oWO2veQQ+/fRT9+KLL7r333/fjR8/3q1YscLtueeerl27du60005zzZo1K0qj TTzPXPivEaXjom58O3MZ2iMC1UcAsXP48OH+OTl69Gi3+eabu86dO7vDDjvM7bTTTtXXsALWbIKu Fbl06VK32mqruQULFliSmz9/frSulZ8JiJt6Qi4E6sMzJBcOyiMCIiACIiACIiACIiACNY1AjRB4 TdSNL7PBQlB7+umn3VNPPeWXP/74Y1r26dOnu1atWqWlFXMDUfmLL75wy5cvT6yGcyO2MOJky5Yt veCQmDFInDp1qps3b16QkvvqFlts4Ycn2xFLlixxeGhVRohEHNlyyy2tqIzLr7/+2i1cuDBtP95y eNPlYhyLl921115bLjtsH3nkETd48GB3//33e7G3XKYMCZmuDefEudUVQwh//vnn3SeffOI+++wz N2fOHLfpppu6HXfc0XXt2tW99dZbbuzYsa579+6uQ4cO5U67UP0tE2+rMN97gX5B36qMbbDBBo7h +Ek2c+ZM98MPP7iVK1em7aZ9G2+8cU79dtasWdGwfwrhmbP22munlRffmDx5ciQ2Emt8m222yfoy Kun8eZZsu+22eb0QQ5ihH/AizAyubF988cVuxIgRXui1fbV1ue6666Y1HS9ebL311ovS6ReydALF 4JbpWVBdz95ly5a5KVOm+PAd6Wfv/Hcz35uEiKqM8V398ccfuw8++MB/uLc322wzt9tuu7kDDjjA ffXVV27MmDHuwAMPdFtttVVUBfcl+5LMPNHZl/QcID2XZ07SsTXlGcL31LRp09JOf/XVV3dt2rRJ S9OGCIiACIiACIiACIiACIhABQRSRbKVK1emlk38OrWi+SblPgu33DX1xhtv+M9bb72V+uijj1IT J05MTZ8+PTVv3rzU4sWLU8uXL0+VlZVlbN2YMWMYF5/xM2XKlIzHFmNHv379MrYlqZ3t27dPDR06 NLVkyZLE5jz66KN5lRevo02bNlG5cGQ7nief7WHDhkXlJa1cf/31GcufP39+0iFpaXPnzk1s4157 7ZXafffd08pu3rx5avLkyWnHZ9sYMGBA2vF23pSzcOHCtEN9v334sXJ9ln48s+txvs+OHTs29c47 76QmTJiQ+uabb1IzZ85McY5cyxUrVmTtt2mVFXBj+PDhqW222SbxPO18bXnwwQeXq7mQ/a2Q9wLX h+tkba/M8rPPPit3vs8880yFZX755ZfljgsTvv3228Qy3n333TBb2nr37t3LHdO/f/+0POHGjz/+ mPH86de5Gs/Uzp07p9WdxHXUqFG5Fllj8y1atCg6z/XXXz9q57333hulX3755VG6Vn4mUAxu+Tx7 S3Eddt5556gPJD1LzjzzzLybwXP/wgsvzFpueK+dcMIJUR18N7dq1SrrsS+99JL/eygsI972WbNm RWXGV2ryMwR2mc7rxhtvjJ9KrdnmvPibRiYCIiACIiACIiACIiACpSRQtBi8FejKVd6Nh13z5s19 OXjE/O1vf8voqVflynIogGHA+RiePKeccorr06ePw8spbngCVcXwzLMht0neO/mWTdiEbPa///0v cTfXyDyzEzP8kkg4htBLs1+/ft5j6e233/ZhGt57773IIxtvbUI15GqZvHQpB0/v2m63336798zE y9kMr65MHuxJ3mKF7G+FvBfwuIt759s55rrEmzluubTxhhtuiB+Wtk3bkuyaa65JSvYhRxhxEDcm tspk33//fcbzzydUyaOPPurDnlg9b7zxhvcixuuwd+/eluyfSXGP5mhnLVkJuWy44YZRqxk5YRZ6 81pafV8Wg1tNe/YykiWbDRkyxOFhn6t9+eWXbt9993XXX3991kPCZ1hYPvdaReFCvv32Wz/KICwj Xtns2bPjSdF2TX6GJP3tYw3/6KOPbLVWLfm7i+cLIzkOPfRQRyicyoycqlUnrcaKgAiIgAiIgAiI gAjUCAI1IkRDZUgQOxJxgj+cbUjl66+/7kaNGlWZ4qp8zHXXXedOOukk/2PtiCOO8OUhbiKsmBED kmHwDz/8sLMfL4QdYLjmgAEDLJtfhj9EL7/8ch/WwTLcfffd0fEMrQ6FvAceeMC98847PqvFngzF rL322su308rix6OFRGjbtq0766yzbJfjR6O1ixnpc7XLLrssEmARVULhIFMZNoya/Yj1f/3rX9Oy Msx16NCh7uCDD/bpXGd+GIfHpR0QbPzpT39yPXv2jMJnELagrhhhF84555zodPr37+8uvfRSZ8IW 4uFDDz3kzj333CgPYQXiVsj+Vsh7Ya211nKvvPKK4wUDAvZNN93km77zzjtnnSiLMBWINZnsyCOP dMOGDfN9nGfIoEGD0l4wcBzH//3vf8/YxxjOzYuHf/zjHz58iNX15JNPOrjHQzU88cQTliVa8sza ddddo+2KVhhejjG82q5xRcew/4477oiy0R/at2/vt7l/brvtNseLFBjzPHjppZfcIYccEuWvjSsM 7+aF0UYbbRQ1PxR4w/Uog1b8sPhCcqtpz95///vfjpcbhFJC+CQkUNwIAcR3WEXGvUJ4ldDuuece 17FjR8+R8C///e9//XMkDIsS5ieMw8iRI31oB1682Xcx5V5wwQW+nN/+9rf+fuelMIJhKPQiLP/m N79x2223XVhs1vWa9AzhbwNC5ZhAfe+990Z/c2Q9iRq8E9HerhFzCfDh++r//u//3NFHH+2vZQ1u vpomAiIgAiIgAiIgAiJQmwkUy1242CEaktrN0HMbuljqEA1he2zIIUMvk4xhmQwRtraSH16hhcPc p02bFu5K9erVKzo2Pvw8PO67777zx3G81cX+0L744otoH+WGxvGZjgvzsd6nT58o7+DBg+O7K9xm CPnFF1+cGjhwoA9zkOkAY0u7Xn/99UzZsqaHZRAaJLTaFqLh9NNPj7ifd9554amkrcdDEhBKIrSw 31S1v4XlGuuq3AtW3vjx46NzPfnkky05cfnqq69GeZ9++unEPJZIOBiG8tOnCHPRrVu36Ni77rrL smVcXn311VF+u1/uv//+tPz0q6Sh2PH7Pu2gVCr11VdfpZUd35/L9ocffhiVwXkmhb4hXIy1vUeP HrkUW6PzEAKH8wmfaTwr7RxHjx5do9tfXY0rNjd7HnAd4s/eUp/zkCFDov5w0UUXRevcIzwTKjLu E+tPPDfi38V2/NKlS1MHHnhglJewQ0lGSBgr79hjjy2X5aqrror2k++VV14plycpoTY9Q2677bbo HHv37p10OrUibdy4cSm7l+yasuQ7gL+PCJshEwEREAEREAEREAEREIFCE6i1IRpqs6hOyAI8hCzE BN4e8RAHocdsLh6wxiMcEmtemaEHb7jfjsm0bNq0abQrbE+UWMAV6sJb8i9/+UvkkZ1UfMiioqGt SccXKo2wF0xKdcstt3jvq0KVm285tMHsjDPOsNVyy9/97neR1yY740NGw+sbMi5XUCwUdeP6AAAg AElEQVQh7E/W32JZsm7mci9kLaAAO/EGx5sPO/XUU92ZZ54ZlcqkfhVZeH+ZRx9esqHhIYvHHxZO HhQeG+Yv5Ppzzz0XFYcHWVLIlNBj9/HHH4+83aMDa9nKHnvs4Vscekcz6sOeudtvv30tO6PSNLc+ ccNbFKNPMEqG0S0Yz4L//Oc/fj3Tf3jdcp+Ysc6kh0nWpEmTNI/gyoRAYSTNn//8Z1887cWbF8/e Ull9fIZUhW27du28pzjXiUlNzfgOIPwUIcauuOKKtAk6LY+WIiACIiACIiACIiACIlBZAhJ4K0uu isc1bNjQMcTbLIyfSloouIVCq+XPtAwFNxOPbMkx+Yh3Yd6wPZnqLnb6hAkTIiGOugjbUB1GWASG 4V500UV+aH+nTp3c/vvv72MGV0d7rE6G+2YzQoMwTBRROJ43vL5V7W/Z2pC0r6J7IemYeNrYsWPd lltuGcXCNCGPfIR5yGb//Oc/o92///3vfRgQC3tCKBULeRJliq2Ewnbfvn39XkTjML6ziUGERgj7 bXhvxoot2KYJyxR40EEHJZaL4GDiNBlM8E7MXAsSCbkxZ84cd/7550etXXXVVf1wcF7OcL6y8gTq Cze+S+y+PvHEEx3fmwhvZnfeeaetJi55EWnWq1cvPwTftpOW3Pfrr7++37XBBhskZcmYRsgdxECM 5xrhHoj7W0qrj8+QQvDlOhEWhDjwYfgrXuoj2hNC5uyzz3aff/55IapTGSIgAiIgAiIgAiIgAvWc gATeauoAxJyzOLw0YbPNNktrSSEEN+IMYqGIFArAaRUmbCCImK1YscJWq21JPEezDh06VJtIc999 91kzouWHH37okmKsRhmKtGIedxR/ySWXpL0YiFdJH7v66qvdYYcdFt+VdlxlBV7rb+UKryChonuh gsP9bkQPYoeakLrTTjv5H9DEcjbPvKRyqPuxxx7zu5iskfjMxPQmlrEZcTWzWXivHnvssVFWfthj 3Dvm0YuYFN5X4b0ZHVjglVCcCWPSxqsJXzjNmDEjvrtWbfPSIB4DmRPgpVU+z8BaddIFaGx94Wb3 I8i4J7Fjjjkm8vB+/vnnM062xv1s4jDHhc8KX1DCf7xQIx7/CSec4E4//fSEHOWTGGXBS0SbtBFx l/jBe+65Z/nMRU6pj8+QQiLFu5vJUHmuItaHLyCJj04MZfrfm2++WchqVZYIiIAIiIAIiIAIiEA9 IyCBtxouON4aTPJkhmdPfMjwOuus43fjSZg0pNqOjS9DAWfdddf1u8OJyPLxXKNe82Q076N4faXa xqOKyUrMmNiqOowf9x9//HFi1ZMmTUpML2Zily5douKZ3Ith6AzlffbZZx0TjTGxXy5WyP6WS32W J5d7wfKGSyYnwxvZPk899ZTfbYIpggphUJiwL5ugZ4IwB/fu3TuqggkTze66666sM92HHrwIxLx8 wExEYpiuecRy3zNk28zaa9vFWE6bNi0qNps3sz0vyFzbBd7ohLUiAjECvIhCbMP4fjNvWJ4Tp512 WpSbydaS7JtvvklLZpLUXIwXSIyiCL/7Mx2HuHveeedFIxL4/kX8Y7Ku6jA9QwpDHe9twoEwuoPJ Le3vK0rn+5sJ85hIzybCK0ytKkUEREAEREAEREAERKC+EMg+pru+UCjSeeL1Ev5gxFuQH4eh5y5V E+czDIdAGp6WhAHYZ5998modXiCIWxtuuGHk4YroN3r0aB9CoHPnznmVhycT7Q1jdOZVQAEyMxN5 GBeVH7577713AUrOvwjYIpJ/99135Q6uDkb0r+HDh/sPDUJIpO+Ehjhw+OGH+x+OxGDlHOJWyP4W L5vtqtwLSeXhrUvM5qpa6J3brVu3qDjuH8I1DBs2zKfh5WvhF6JMv6yYB695ZfXs2dMhQCPIfPXV V5GH8MEHH+yH5IYe0suWLYsXV/Dt0Psum8BrIj8NYGZ7mQjURQLEz2WIPMY9jdeyGTG4CVOBIcAR HiH+vAyH03PPJ3mKW3mVXYYvnqwM6m3btq1tlnSpZ0hhca+++uo+NAPe3LycDEd+8CKbF5e8DJCJ gAiIgAiIgAiIgAiIQD4Eyis9+RxdB/LOmjXLizD5ngrePgwDr8i71iZySSqfH4cMz+vRo0e53Yhy CEX5GuIRwlTcMsXejOeLb+MxVF1eQ7SF0Aeh8EYsw2uvvTbezJJuX3zxxX6Y5dy5c6N6GXqL902p jf6H58/NN9/svb3MUzRsB2nEmeVDuIIHH3yw3IRAhe5vYf22Xtl7wY4Pl9w7xD02Y8h00rnb/qQl Ly7ee+89v4s4mi1atEjLxo9vE3h5CZNJ4A09eCmASXVswjt+pMMbO/744/1ylVVW8Uv+ix8b7Sjg SugxnE1QDr2J4y+cCtgcFSUC1Uog9My1e9IatMMOO3gPfF7Q8DxhsrWuXbvabr8MX+6Fo2PSMhV4 g7YcddRR/qUW3z+ltvrwDMFr+oMPPkgLaZUrZ+KXhy/IcjmO0UBPP/104ovK6vhbIpc2K48IiIAI iIAIiIAIiEDNJlDvBV5Em2eeeaZSVwlxKJwwKakQPG74Qz4+iVqbNm38UP9sw8eTyqtPaQhwDHc3 byuY4dkU/tisDh6IpC+88IK/prwgYEjlJptsUh1N8XUiGBKfGM/mcePGubffftsL40zswsf4kRkh FKGAvhvGgi1F4wt5L3AO4eRoV155pSPebtzbLtt5WQgF8hCSIP7ioKysLDqcvgi7pHi+ixYt8vlM FF1vvfUcoTPwfmc4rpm9qAj7byiqWr5CL4mtax54vJTAoz/JGGFglu9EUHacliJQkwnwvA69Yy1O dtjm8KULoYHiAm94/3BfEfIhfGkTllWVdYbvE27n1ltvdZ9++qkvijjrTCbJSJ1SWn14hiDu7r77 7pXCyku9pL6UVBjfF7z0u+6663zc+DAPf+/wnVHZF/JhWVoXAREQAREQAREQARGofwTqvcCbzaOt ou5QkTjDDzTioGIIK/xQM8GHIebE9kSUk5UngKC23377ReIkLAnVEMYYLn9U6VIY1ou4z1DLmiLS I27yA9FiwEIDkZLwHLfccosXHElDLMCztE+fPiUDVux7YZdddvHngle9GS9WOP9QULV93PdDhgyx TTdq1Cj/iRISVgjnkCTwWoiGsB4mbkLgNUMkMg+vMF9FzxA7virL8OVD6HUeLzMUeAlRIROBukbA JlS080IwzWY22Vo4CSremqERLxXRtZDG85KXdSx5CU2oCARBjOc2oxcYdVEqqw/PkKo8i+0lX7br 8cMPPzheGBBaKHzpyjG8/KMvtmvXLlsR2icCIiACIiACIiACIiACWQn8Gnwua7a6u3ONNdao9MnF h3RnK4g4fUz6RIw/sz/+8Y8ujOdn6fV9iQdqKO7yQ/bVV191TGAl+5UAE6jxwx/P1Uw/MBGiiQ38 3HPP+ZjOdvT7779vqyVfFuNeQEBlGPPQoUP9+eCRi6CKl/LkyZPLnSNxDuM/sstliiVkmmzNhIFQ 6P/d736XJsCce+65UWlhDN7QWzDKUOCVUJyJjySwqlauXOmHJ9u2BF4joWVdIsA9nK+FIR04tnXr 1mlF8AKt0MbEb4i7WKNGjdw111zjDjvsML/Nc6vUYRrqwzOEl7WVtXCCyngZfP9ccMEFrmXLlt4j O/zeQazHCYBQDRJ34+S0LQIiIAIiIAIiIAIikC+Beu/Be/fdd/s/uvMFRwxQQgbkazfddJNDXLIh 0wi+iJf8iJM5PzFVGH8Oxi+//LILPaiqmxNeocQGpl1cxyOOOMLHXY3/8C92O1966SX/w596EE3P P//8rFWecsop7pVXXvF54jPBZz2wSDsLfS8QGsEMD3n7IT1hwoRy/ceEYPLzAzvb5EVcX/PG/de/ /uWIzRuaefCG4SEQC9566y0/2drWW2+d9uM9HM5t4nBYXqHXt99++6hIhP5wwkLbQcgO48ULlXwm joINYW7CkBZ4pMWHtltdtXWJhzMTIhHzmmvKxEgIcZV5dsOKSfiI8YzozhDvI4880lU2NEYh21Zb r09F7eaZzcgQjDj1jz76aMZDeMloE5zGJ1vjejMBqj1LeXFLvPyqCIQZG/LLDl7U0Q77m4PwNNzH 1saKjq/q/mI/Q6ravkIcz+gPQhpV5qUbz4O40dduvPFGF39BQD4E3z/84Q/lXhbEy9C2CIiACIiA CIiACIiACORDoN4LvEySYsO78wFX2bx4DBN/7YADDvBFjBkzxg8VP+eccypbZJ05bvz48d7b1E6I obCEZdh4440tyS/x1OSz4447pqWXamP48OFp8Vpfe+0197e//c17QIbxGYvdnvnz50dV8OO/X79+ ieEILFMowFm4ANtXHcti3guEZzAL10mbOXOmF+pYJ+ZiNnGXPAgpJvDCOS7w/vTTT76q0DOXBPpC Un8IQzRURkzwleXxH/GKTzvtNH8E50G/iU8OZedHprPOOqvCySPD6uFjL6wsfY899rDVOrEkpAcT cPHcwXhJx8R7eFIy5DpfY8LBsB9R3oUXXujDp5jnZq5lFrptudZb2/I98MADUZMrmsB077339s8G XnxwzeOTrREugTwY+wcMGOC/E7JNuoon5w033OBfnlxxxRV53WPUQxxcxGS+azDCO40dOzbvcvzB ef5X7GdIns0pWvZtt922IGX379/fPx/CwnAK4HnB8zKbx294jNZFQAREQAREQAREQAREIB8C9T5E Qz6wCpUX75+zzz47Kg5hbtKkSdF2fVwhVAWit3kR7rzzzu6NN94oJ+4SigAvN7xtmOis1MZQdgT6 uCHyPfvss/Hkom7zg9EMj1U8CjN5hCJCEMrB7PDDD7fVal1Wx70QxuHEq7kiYxI9i3dpk62Fx1h4 jFC4DffH18PJ7TJdr/gxVdnGG7d3795REYgPoX388cdeoLK0k046yVYrXNLv4uIu/TKfMiqspAZk oM+YuBs2h4n5whcn4b5M6zxDkkRhnn0M1c7XCtm2fOuuLfm5zxitg9E/Dz744AqbHr50JXZqaMTi Dr/Dr7/+enfcccc5wubEjbjX7OdlD3H4EWgZVVAZI6yTPffxAMejvBRWzGdIKdpfyjp4gcjLHzNe 2PBikLBBTJoncdfIaCkCIiACIiACIiACIlBoArXWg5c/lvnRNWfOnOgHNj94zJiwwrwU+YMakaaY Mc6Iacrw7YULF0YiJcIHYgqeimeccUaaNx8x9RAETRxhSDM/Oo8//ngX935jWDXD8c0TEa9WM0Q7 G9bLEFGG6ZsYZXnCJT8+iENoYgXbZpQbij9M5NKjRw/bXdQlP5ZN3KUihLSkGa3DSfEmTpxY1DZl Kvy7775L3DVv3rzE9GIl2g99K59h8vRz4vrBjol/uM4jR470Ap71NfpHly5d7LByy6r2t0LfC0yG xguAMKwE90PYV+MnEea1ffQpZjrHe9IMNl9++aV/kcCw2TDMAv3riSeecNOmTXMWhoHjEH4I24BH 5zvvvBPdwzx/aBPPG17aEHMxNLxkyTNixIgoGdGJYcFJ+aNMBVjh+cOwbowXFDwreCEAp6uuuiqq gbAKNgw8SsyywkuYuBEXupjD1eP1lWI7fE7G60M8bNasWTw56zbCeJJlmwQvKT9phW5bpnpqYzri O/cY4RTC7xeLicp9HP++ZQJKwjlMnz49OmXuXYbUE0bDRt8MHDgw7Tv88ccf9y8dO3Xq5MsklAMT WsZfCHJ/bbfddlHZPJMI08TfNGa0l2cJz2pEXZsrYK211vL3q8X0pk2EgjnmmGMSJ4C08gqxLNYz pBBtq0ll8PcY14z7kv7CJwzLU5PaqraIgAiIgAiIgAiIgAjUMQKpItnKlStTyyZ+nVrRfJNyn4Vb 7pp64403/Oett95KffTRR6mJEyempk+fnpo3b15q8eLFqeXLl6fKysoytu7qq69OOedy/rRv3z5j WYXY0bVr16xtOffcc8tVM2rUqHLHdOvWrVy+fM5z8ODB5Y4PEwYNGlSuzmzlh8dmW+/Tp09UbkVt iJcze/bs6NhsbYnve+yxx+JF5bTdvHnzqD76XWi+3z78WLk+Sz+e2fU432d32mmn6PiwTZ988klq xYoVWfttWFdV18eNG5fYjrBN8XXOnfstm8WPybaddK0LeS98++23eZ9jvL3PPPOMP90ePXpkLevF F19Mw9K3b9+s+eP1hNs33HBDWlk8z8L98fXbbrstLb9tfPXVV2nHWXpllkOHDk0rK96G3XffPTV3 7ty8iu7du3damfSvfMvIq8Jqypz0rIbfqaeeWqkW8X0U5892/HmUS+GFblsudVY2T7Znb2XLzHbc hx9+mMjZ2Ldr1y7t8EmTJmXNv9dee6XlnzNnTurYY4/NeozVxbJ79+6pH374ISpj2bJlFR57//33 R/lZWbJkSapVq1Zpx/HMzWQ1/RkStpvnoPHi2SITAREQAREQAREQAREQARHInUCtDdHARFxxD8Zs 2nvnzp2z7a7yPjwnMxleOBavL8yDp098Vu+DDjoozOLXTzjhhHJpSQnwiHsjxfPhxZwrt1zrjdeR 7zYej0w2l49xDkxwVB32l7/8JS1WMB5ZgwYN8h6zpWzPVlttFVUHjySP5yiDcw6vLzxhCW+RzXK9 7pn6WyHvhQ033LBKnvcMj91zzz396WYblk2+uOcq92Kme4W8eP8lGWURYiQ0PIPx0k+yXK5d0nH5 phGmwYapx49t3769GzVqlMNDMB8LvZE5Ds+1fMvIp77qysuz+pZbbnHEBTfjPgnDnlh6Lksm+WOi LzPKxVMdr/t8rdBty7f+mpwfruE1i7e1Q4cOaUncu4RfyGQHHnhg2i5CFzByh+uZrR4m0WPiNrx1 bWQRBeHZmW00Bc+ZcIIzjiHESzgKgbR4u9IaWcCNYjxDCtg8FSUCIiACIiACIiACIiAC9ZpAA7Tg YhBgaOTKbya7hrul/4CirqXrr+fev//nGGX8wGF462qrreaH9bLODxgEEYY4Zpu0pBjtVpmVI4BA e9999/mDiT8Xxi+sXInFO6pFixbRcF2G4Yeiiu+3w550Dc/8Y7kG/NBxP/flxf0dM5rTb8lL2AyE VibYsn7L/lL123vuuccP72ViLARvBFxCEUyZMsWHC2ndurWfnAeRwEJ5lDsxJdRYAgzlD/tnIR7X y5cvd0xoSCgNxCZCsWy00UZ5MyC0RVzUIiTIeuutl3dZtekA7i242bD5qrSdsAGEduE+LYQVsm2F aE+8jGzP3nje2rjN9SSmNaEZ6B8ItNy/1Rl3tSY/Q+LX+Pbbb4/+dkBMRjiXiYAIiIAIiIAIiIAI iIAI5Eag1sbgze30lEsEikeAOKPVHWv0tNNOc3zMmAW8UDOBW5la1i0CvJzAk7+qMclff/31NDDE Na3r4i4nvOmmm6add1U28N7O5CVemXIL2bbK1F/fj+Fa8qKtukaXlIp/oZ4hpWqv6hEBERABERAB ERABERCB+kCg1oZoqA8XR+coAiIgAjWVQDjZI20kPINMBERABERABERABERABERABERABESg9ATk wVt65nW+xpdeesmH1+BECV9AjMjqNGazZhb0ZcuW+WaEs6lXZ7tUtwjkS4A4rRjhQIjdSXzv6rKx Y8dGVRMiZJNNNom2tSICENCzt+b1g5r0DIHOyJEjHWEksNGjR9c8YGqRCIiACIiACIiACIiACNQS AhJ4a8mFqunNDGPOPvXUU46P2YwZM6o1/uuVV17piAssE4HaRiC8r2g7QqrZeeed5yf3s+1SL/v1 6+cuv/xyH8/6wgsvLHX1qq8WENCzt/ovUk1+hkyfPt0VewLc6r8CaoEIiIAIiIAIiIAIiIAIlIaA BN7ScK7ztfTs2dONGzfOLViwIO1cd9llF9eyZcu0tFJvHHrood5LaNGiRWlVd+zY0W2++eZpadoQ gZpEgP7Zq1cvN2bMmMgDnfYxKeVBBx1UrU0lJEP//v3d4sWLCxpHtlpPSpUXlICevQXFWanCavIz hBEI3bp18xPT2QgbTpJJDPmbQiYCIiACIiACIiACIiACIpA7gQapQkzLnlBfWVmZWzltumu4wz7l 9i5fq4V774E7XGqVxo7JOpo2beoFCyasatasmR9+THqjRo1c3PukXGFKEIECEli5cqUru/t+1/Ci y8qVOvuQjm7iH89yDRs2dE2aNPH9lj6L2Ea/Ja1x48Z+v/ptOXxKEAEREAEREAEREAEREAEREAER EAEREAERKAKBok6y1mCjDVzZnruWa/Yq8xa4ra+60TVYvsKhL2f7lDtYCSJQJAL+XcfYt12DK65J rGFO+3Zp6Sbi2jJtpzZEQAREQAREQAREQAREQAREQAREQAREQAREoAQEihaiwUSvst4nuobvflDu VNZ5a7wXeb++7E8uteqqznv84j1ZVhZ9KAPRzcoqV4gSRKBABEzcTfU4yTVYtLhcqUs3WN/N3WtX 3x9tJ/1SfdNoaCkCIiACIiACIiACIiACIiACIiACIiACIlAdBIoWogHBjOHuKxYudI13bu8azJ2X eH5z99ndzT/kANdklSY/h2b4ZZi7DXVv2KBB4nFKFIGCEljwo2tw2VWJ4i71TDu1p5t6TFcv8BI6 ZNVVV/WhGQjPwIcwI2GIhoK2TYWJgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIQAYCRfPgpT7v3bjq qm758Ue7Jrffm9iEtd96z/GRiUBNJVC2SmM385COkfcu/Zo4vOFHnrw19eqpXSIgAiIgAiIgAiIg AiIgAiIgAiIgAiJQtwkUNQYv6BC+Vp50vEvJE7du96Q6fHZz99/XLWvRPAoXEgq7rNPH7VOHMejU REAEREAEREAEREAEREAEREAEREAEREAEaiCBogq8Jno12Ky1W9Fxvxp4+mqSCFRMYEaXg31caHLS pwnREH5M8LX+XnGJyiECIiACIiACIiACIiACIiACIiACIiACIiAChSFQtBi8NM8mTluxYoVbOmu2 a/Dok27Vhx9zq0yaUpjWqxQRKBKBssaN3bz9f+OmdznYzd9ua++9i5C7yiqr+Pi7zZo187F3WRJ/ l3SLG43QKxMBERABERABERABERABERABERABERABERCBUhAoqsDLRGuIvAi8y5Ytc0uXLnWLFy92 7rUxbvVh/3YtXn/TNSgrK8V5qg4RyInAsg3Wc7O6HOJmdj7Ah2Wg/9KPEW0RcJlIDUEXYdfEXSZc Q+DFqxcRWCYCIiACIiACIiACIiACIiACIiACIiACIiACpSJQdIEXcQyB13vxLl0aibxLlixxK76d 5tZ8eoRbdfJU51KpX8+ZmKaugeOfrP4SoO9UZIXylk2tsoqb06Gdm7vXbj5eNHVb/dSBeGveuwi8 JvKauIv4S55Ctaei89Z+ERABERABERABERABERABERABERABERABEYBAUQVeKsAD0rx4ly9f7j15 EXf54NGLZy/pCMDmLRleGglmIY36sd5q6COuxaefu3m77uTm7rqj+3GrNs41SveMpV/YByqF6icm 6lqZlItwa967CLp8EHhZ4tFr4q5NuFY/rpLOUgREQAREQAREQAREQAREQAREQAREQAREoCYQKLrA i2AWF3lN2LUlIi8C78qVKyORNxTawvWaAE1tKB6B1b74yu143qWuQdmv3rsrVmvm5u3c1k3+fXe3 cIvNImHXBN5wWdmWxQVitm3yNARcvHcRc/mYsMt6GJpB4RkqS1/HiYAIiIAIiIAIiIAIiIAIiIAI iIAIiIAIVJZA48oemOtxJr4hfuEJiVjLx9LNOxIvXgTeJJFXAm+utGt3vtSKFW7Lm+9ME3c5o8aL FruWb453TWfOcu/feKVr0LihF1/pQxYWwbxnSaus2bEsTdy1/omQG4q8rCP8Wj47trJ16zgREAER EAEREAEREAEREAEREAEREAEREAERqAyBogu8NMrEL8QwRDFLYzsU0EKB18I1SNytzGWtnces88C/ 3GpfTcrY+DW+meI2GTHKzTjycN9v6DvWp0JR1vpbxoIy7OC48EP51j/Ni5elfax+OyZDsUoWAREQ AREQAREQAREQAREQAREQAREQAREQgaIRKHqIBmu5ee5auAYTc20ZhmgIxV0TeG1p5WlZtwg0mjzV bdSjt2u4dFnWE1vRrJn74O4bXWr99bzQaiESEF0rK7iGgrCJteaZayKvCb22bftZYmEZWU9AO0VA BERABERABERABERABERABERABERABESggARKJvDSZhN5WZrQa0sLzRAXdyXsFvBq19CiuMYtep7h mrz1bk4tnL3/b9zkyy70Aq/FxbWQCSbymvCaU4G/ZDKRNknkDQVdWw/z51OP8oqACIiACIiACIiA CIiACIiACIiACIiACIhAoQiUJESDNTYUxFhHKDNBF2EuFIBt3Y6V0Gsk6t6y0SNP5CzucvYtXxvn Zr/9nlu6797ec5Z+RP+Ji7zW33IhFuZl3T6UzbotLd2WuZStPCIgAiIgAiIgAiIgAiIgAiIgAiIg AiIgAiJQLAIl9eANT8IEWxNy49vktbTwOK3XLQKpGd+7xu0PcQ0W/JjXiS3eeEP3+X23ulVbNHdN mzb1n1VXXTVN5K2sCMtxmB0fLi09r8YqswiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAgUiUBJPXjD cwhFNBNybUm+cD08Tut1i0Dq0gF5i7sQaPbdDNfy4cfd3L4nOQvvQZ+hX5lHr3ndVoZY2D/teEuz bS1FQAREQAREQAREQAREQAREQAREQAREQAREoLoJVJvAG564CWe2tH0SeY1E3VyWPfeCazD8hUqf 3MbDnnLzDunolm/ZxnvuhkKvFUqfivcr25dpmW/+TOUoXQREQAREQAREQAREQAREQAREQAREQARE QASKTaDaQjQU+8RUfs0mUDZ/gUvtdYBzM2ZWqaHz9tjFTb5hoFtttdX8p1mzZhbc8DgAACAASURB VI5QDUy+1rhxY+/NiyevTAREQAREQAREQAREQAREQAREQAREQAREQATqIgEpX3XxqtaCc0pddlWV xV1Oc63xH7rVR7/qli1b5j/Lly93K1asSAvbIE/wWtAh1EQREAEREAEREAEREAEREAEREAEREAER EIFKEZDAWylsOqgqBMrGvOnc0IcTi0glpjqXKZ3sre8Y6lbMny+RNwM7JYuACIiACIiACIiACIiA CIiACIiACIiACNRdAhJ46+61rZFnVrZkiUv1vyhj2+Z3bJ+4b+6Wm7vFa6+ZuG/VH+a49e99OE3g NU/esrIyx0devInolCgCIiACIiACIiACIiACIiACIiACIiACIlDLCUjgreUXsLY1P3Xdzc5N/Dqx 2ctbruu+P+SAxH1ljRu7Lw7vlLiPxA2fHuEafT4xTeRVqIaMuLRDBERABERABERABERABERABERA BERABESgjhCQwFtHLmRtOI2yCZ86d9MdGZs64/fd3fKGDTLun3pAe7dkrRaJ+xuUlbnWg+5wy5Yu jWLxhl68ePDaJ7EAJYqACIiACIiACIiACIiACIiACIiACIiACIhALSQggbcWXrTa2OSylStdqt+F zq1Ykdj85euu7WZ0PsBPjpaUoUED51JNmriJRxyStNunNf/0c9fiuRfLefGaJ6/CNGREpx0iIAIi IAIiIAIiIAIiIAIiIAIiIAIiIAK1lIAE3lp64Wpds4fc59x7H2Zs9oxjj3TLGzb08XKTMzVwjRo1 ct8etL9bumayFy/HtbrrAVc2+4dyIm8Yi1dCbzJhpYqACIiACIiACIiACIiACIiACIiACIiACNQ+ AhJ4a981q3UtLps0xaUGXpex3cvXXtNNP/Qg772bSXxt0OBngbdBs6bum991zljWKj/+5DYcMjQK 07Bs2TKHB6958WrCtYzotEMEREAEREAEREAEREAEREAEREAEREAERKAWEpDAWwsvWm1rcuqGW51b tDhjs6f3ONItb5TNe9c5QjTgwcsHMXhZFi/eli+87Bp+MzkSeRWLNyN67RABERABERABERABERAB ERABERABERABEajlBCTw1vILWNOb7z1yt9kqYzOXr4X37oFRaAY8dZOtgWvYsKEXeBus1sxNPfLw 5GzOOUpIzZvvEHbx4DWBd+XKlb6eTF7CGQvUDhEQAREQAREQAREQAREQAREQAREQAREQARGooQQk 8NbQC1OnmtWxQ8bTmXHM79yKJqs4E10RcZPMQjSYyPt9185ueYvmSVl9GpO6IeyauGshGhB5qcvq y1iAdoiACIiACIiACIiACIiACIiACIiACIiACIhALSCQrKbVgoaribWIQNttXWr9luUavKJFcze9 S6fIexfxtmHDRuXykYDAa+IuYRoarrG6m9GjW2JeEstSKR/TF0E3SdyVyJsRnXaIgAiIgAiIgAiI gAiIgAiIgAiIgAiIgAjUIgISeGvRxaqtTfVi6v7tyzV/5nFHurKmTSPxtnHjxq5x42SBl4N/FoAR gX8O1TDnqC5uxZrpXrwrVl/NzW63p1u+7tq+PiZVs4+JuvLeLXcplCACIiACIiACIiACIiACIiAC IiACIiACIlBLCTSupe1Ws2sZgbIDOrgGI0YRHdelUs6tXGN1N/vIwyOxFg/dnwXe5C5JaF7yhJ68 DZs3dz/0PNatMeZt9+Oeu7p5u+7oFrTZzJU1aOBDMDT+Jb+hMoHXtrUUAREQAREQAREQAREQAREQ AREQAREQAREQgdpOIFlNq+1npfbXOAKpHke6Rd0Od0uWLHGLFy92ixYtcg2XLnWNly//f/bOA0yK KmvDd1DMOee4RhRdVswooiyyBkygmOMaMCcUFRXFtIo5K4iYAyYMCCoqGDGg6G8AEwqoiIAJBab/ 5y08xe2aquow09Pdw3eep6eqbt1Ub4We/urcc0PP3NkCb/OEvs8Wd03gNS/eqQfv56Yd0jXw0p05 Y4abb+bMIDQDYi6hHIJwDs2aheJwQuVKFgEREAEREAEREAEREAEREAEREAEREAEREIGqJCCBtypP W3V12jxvTZxFdEXMJXQCaYixJtg2b558SZIXi9ZDWauDeom7S92kN2/ePGjLhF7SrJ7qoqjeioAI iIAIiIAIiIAIiIAIiIAIiIAIiIAIiEBdAslqWt28ShGBoglERdn55psvqAvhFZsj8CZ58M5u2sRZ liYUWx0m7iLwIviShzTaQug1kZd0q2d2rforAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAtVJQAJv dZ63quq1CaomyOJdax63/jr7mzefLfymHaDVx9LqNC9e6rM6/f0Ivb7Am1a/9omACIiACIiACIiA CIiACIiACIiACIiACIhAtRCQwFstZ6pK+4nIipkAO1vEbR561yLGYuQjz7zzzvboDRJT/lj+2WVm i7ekIRzbh+L+fkRetslnn5QmtEsEREAEREAEREAEREAEREAEREAEREAEREAEKp6ABN6KP0VNo4Mm yCKy2rp52nKEpGHN5s3/krR6fC9eo2UhGvw8iLsm8Fo+LUVABERABERABERABERABERABERABERA BESgmgnkr6ZV81Gq72UlEIq3zZqF/UBoNe/dMJGVv2PyZqXFbFCnfagLkZePtWVF/Dy2bkvLo6UI iIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIVCsBCbzVeuaqrN8mvJoHrcXg9Q8jCK3gicD+vqR1E2tN 5LVty2/t+umWZnm0FAEREAEREAEREAEREAEREAEREAEREAEREIFqJSCBt1rPXBX224RVloi5UcOj t/bvUA3RfUnbJtzaEqGXT5xZ+3H7lCYCIiACIiACIiACIiACIlAdBH777Tc3depU17x5c7fsssuG nf7xxx/djBkz3OKLL+4WXnjhMF0rswmIm64EERABEWi6BOKVsKZ7vDqyMhOICrEmyFq6c7Nj8RbS TSvLkvr8bX+9kDqVVwREQAREQAREQAREQAREoDIJrLXWWm7llVd2yy23nBs2bFjQyRdffDHYJp39 sroExK0uE6WIgAiIQFMhIA/epnImq/w4GkKIpQ6ZCIiACIhA5RD4+eef3auvvuqGDh3q3n77bXfW WWe5Tp06VU4H1ZOCCeicFoxMBUQglsCvv/7qXn75ZffTTz/F7rfEBRdc0O20005uySWXtKTY5ejR o92oUaPcrFmzYvdb4rrrruu23HJL26za5Q8//BD2Ha9UDKZm/n5L09I5n4u46YpoLAJff/21e+ml l9wLL7zgvvzyS3fXXXe5f/zjH43VfGw7ePs//vjj7v333w/+R+VZ3KJFC9eqVSv33//+16200kqx 5ZQoApVMQAJvJZ8d9U0EREAEREAEqozAt99+6/r16+eeeeYZ98Ybb2T1/rnnnmt0gZd/2MePH5/V D3+DCTrnm28+t8QSS7illloqMcyPlZk+fbobM2ZMbKghy5O0XGihhdzaa6+dtXvcuHFuypQpWWn5 bqy55ppukUUWSc3OD/gvvvgiKw9Dmtdbb706E5NmZfI2SnVOJ0+e7L777juvJRcMqW5qnneff/65 w7Pw008/Da4dho1zjDvssINbf/313Y033ujmn39+d+6557p5583+17whr7c//vgjaD8LuLfBKCja X3TRRYMh71wnafb9999niUVpeaP7uA+4H6JGCK9vvvnG/fLLL3XuMfq2+uqrx5aL1oOAYGIfx4WQ AOMkmzlzphs7dqz766+/gizcV9xfaRZ3/IQFWG211dKKhfuuvvpq17Nnz3A7bWX//fd39957b2KW 33//3W288caJ+6M7Pv74Y7fBBhtEk6tqm3vInm1LL7100PdlllkmPIam9hwJD6yeK6Xgxj1LuAzf ll9++cCb2k+rxvVp06a5CRMmhM8G/xh46bLKKqv4SQWt878JL2Xee+8998knnwQvcXjGbbvttm6z zTYLBNGvvvrK7bPPPkHIEascYXLixIm2GS551iFK2suguGcUDlHrrLNO6vOQCuPKFvJ8ow5e7N93 333uySefDO9V6+zIkSPLJvASFvLuu+92J554YvBdY31iyTPlqaeecn369HHXXnutO+yww/zdOdeb 8r2Q8+CVoTIIZGQiUCEEZs2alfnrxVcyMxdduc5n8tbtM8OHD8+MGDEi89Zbb2U+/PDDzNixYzMT J07MTJ06NfPHH39kZs6cmamtra2Qo1E3REAERGDuJNC+fXuCrMd+jjnmmEaFMm7cuNh+JPVv0UUX zZx44omZjz76KLaffMestdZaBdUZbeuBBx4I677//vvrVRd9SbNffvklwzFF+8D2hRdemFY0a18p zun06dMT+9anT5+s9qt144cffsiccMIJsfzjzgn/5/jW0Nfbuuuum3df6F/nzp0zgwcP9rsUrr/+ +usF1RU93lVWWSXD/31RO/XUU1Pr3XDDDTNcO2n20EMP1amD9n7++efYYpMnT86wP9rHRx99NDY/ iW+++Wad/Fb+xRdfTCzn7+jevXtiHVaXLTt16uQXrbM+ZcqUvOuiznfeeadOHdWWsM0224TH/Nln nwXd/+STT8I09svqEmhoblzvdp1Gl2+88UbdDlRRyvjx4xOPzY6V7/FCjXo7dOiQWrf/3X377beH TfD719pOWvI8+OCDDxLztWrVKqwvbqUhnm+///57Yvv0uxhucX0tJo3vtig7vh/btGlTJ/3JJ5/M u4mmfC/kDUEZy04g202gMjRn9UIEREAEREAERKBKCTC0bciQIYFXS4cOHYIJcG655ZayHA1eeYUY XoPXXXdd8MG75F//+ldW8Thv2KwMeWzgOWf24Ycf2mpRSzxN8NyL84SkQobickxxxrDvfK0U5xQP miT74IMPknZVTTqe43hhffbZZ1l9Znh8NM0y4CntW0Nfb1wrhdjDDz/s+Nx6663BcFW/rHnH+mmF rHOseHD7HpeUNw/apLq4fx577DG33377JWVxf/75Z519tIcHbLdu3ersIz3KnkyEI0kyvLGTLM1T OKlMr1696rCwvHjj/fvf/7bNnEvCLxx88MGx+fDe23TTTYMhyLEZqihxhRVWCHsb58FLbF5ZXQIN zS3teuc+2WKLLep2okpS0r6n7BDOOecc16VLl5yjfyz/s88+6/bdd9/E72bL5393+yNd/HTLG11O mjQp+N8gmm7bjCpJs4Z4vjEyqnXr1oEXL/9DtG3b1vE/D/8fltP4fuB7zaxNmzbBd8Oqq64aJPF/ 04EHHhj284ADDnCElzCvaCsXt2zK90Lc8SqtMglI4K3M86JeiYAIiIAIiEBVErjsssvcxRdfHA41 f+2111y5BN411lgj+EHBMMhHHnnE3X777QHTE044wSE+Y4jADHUkBpvfT4bP/9///V8wiY+dCF84 4oeLL6IgEF1++eVB1g033NAde+yxVszxY+vCCy8Mthkmb8bwe7Pzzz8/S+ChryZ0du/ePWsYKEML GfqI0ackgdfqtiVDBzGG3vs/8m1/0rIU5xSBmSGgsMHuvPPOkFFSP6op/ZBDDgmFXIZEM9Rzl112 CcJicM0hVDL089133w0PKxqqo6GvN+5FwotwXZ188slBu/zoPv3004N1wiNwPghVcNttt4XhF44+ +mjHveSLjJR76KGHgjwIFk8//XRQx9577x38kA8PKrKCOEu4iiQjZAFigMUG5V6N2k033ZQq8CL+ 0t8jjjgiPAfU0b9//1iBl/vJN0T4+++/37Vs2dJPTlxv3759cP2SgfAWhHsp1I488ki34oorFlos Nj9Du/3nT2ymJpBICAAzY25L0gt5xlk9c8OyobltvfXWwcsQEx6578ot4jXUeWSyPuYQQPBE7CX0 FM8733jRSixt/mfIZYMGDXK77bZbmI3vBl4qc89yXng+E6OW/6H8l06+0LzJJpsEcWP5v4aYtiZW Mr/BHnvs4TbaaKMgFBR133PPPYFYaQ2SRiggzlm+VuzzjfBXb731VvA/loUe4n+Jcl8bfughjo1z av2DCS+G4EZYH65pPoQb69ixY05kTfleyHnwylAxBCTwVsypUEdEQAREQAREoGkQ8P9ZLvcR8WOH j8VqpD+bb755ILZF+9ajR4/gh5Z5vhI3zhdKfMENr6Tjjz8+rAKPGBN48fz19xG/L07g9b0VoxN6 8MPIBF6EQGLmmvFj0wReXyS2/UlL81BJ2p+WXopzishrfWpK3nZ4+5jgieD3/PPPZ8VehiXiIRMQ IpqOGDEiQB/1GG3o6w3WfJZddtnwVBMLF+E5aogACBH2Y/yOO+7IEng5hs6dOwfFEKzteHfddVd3 6KGHRqsLtxGx0wRe+mYxDz/66KOwHKIRgjI/tuHGy5ekGLL0De9pYln63tLcM4jXfhxstu1essYo h8icry222GLhdZxvGeWrPwF7ZrAk9iiGqMQ2z3DbX/+WmlYNxqUhuSGsm7huy6ZCbccdd3R8MJ49 Zqeddpq76qqrgk2ej7kEXl5a+f9P7LnnnsF8BcS1NUNU5LP77rsH3/kmmvOM9c0mq+U71ATenXfe OevZy/fHgw8+GBbjxRXPXkTrQqy+z7dS/O9QSP+jeXlW8AKT/694oRjXP+4NBF2+czBiJOcj8JK3 Kd8LUZbarkwCs78NK7Nv6pUIiIAIiIAIiIAINBoBxK8LLrggbG/YsGHhOiu+4Jav1yzlFlhggbAe 34PXXy8kZILfdiECb9iJJrzChDUXXXRR4IEZnfSnsQ57+PDhYVOIpL6gGO5wLvC8NuGf9Ojwzoa+ 3vy2c63TFxMvyMsEiXj4NqbhRWWGh6v/0gSP71xmISnwWjMzMcS2Bw4cGKz6eayc5dGyMgnYpHKM pvDNQgLg6SirS0Dc6jLJJ4WwOyb4MQKIF8JmTCTGS4U0w3vVvHIREAkN44u7flm8+c8444wwKSrw hjsSVniG7bXXXsFkYWRhVBFexoWKuwnVV33yUUcd5a6//vqsl53Rg/L/zyrX/xLRPmlbBPIhIIE3 H0rKIwIiIAIiIAIiMFcQ8H8AjR49OuuYfcGtEEHWz+uLuv66LwJnNRqz4f/w8PsUk3WuSUJ8xMuK +KJ45ey///6BJ40vEpYDhj8cNK59+kzoAIReP+QHef1z619DcfX4aX5e/xrz8+Sz7t8LeJIxc3uh dvPNNwcCN8OOMV/QWGSRRRKrmzFjhuvbt2+wH/EV0e7www8P8+OBlevYbL/vpdyvX7+wDlbs+jjo oIPCdCsXJjTCCoIMjIh33Lt370D8wcMMDsUYnsmEmbjyyivd1VdfHQwzJyRKUzIELDzCn3jiiazD IgwI6XhIyuoSELe6TPJJ8V8OMUphqaWWyvKYtWdJXF2MziDsghlir/+ctnR/uc8++4Sb/qiLMDFh BU9hQjVYKAlGIyDuKmRJArCYZF6cE7rBjBAaMhGoFgIK0VAtZ0r9FAEREAEREAERKDkB4pSarbPO OrYaLH3BzRdZszLFbPiemb4nji8kFSvwFisAxXSzqpMQx+KG/jOMlglTGtPwljJDvCW8ABO5JFlU 2LV8DX29Wb35Ll9//fWsrNEJ0bJ2Jmzg8UZ4FM4PYjYxeokz2aJFiyzP9mhxwlqYRxz8mByMoct4 zg0ePDgI1fD444+7rl27RouG2zYRHENwmSiHMBKEbEA4JUQGYR4sDAr96tOnT1CvlQsraoQVji3O GFaNd2B0wse4vJZ2ww03OD5xhtchL0D8Z1JcvmpJ818YWJ8J0xCXbvu1zH7RYjzEzUjELy2GP3st ji7xye+6666gwI033hjENrdwIX4t0UnL/BdKfj5/nRA0xBvnOWxzBvj749Z5EUd4Bxt9hHc7z8t8 JgiLq29uTbvmmmvC7x/CLO20005zKwoddxUSkAdvFZ40dVkEREAEREAERKBhCSCm8QPO4uhSOxNw +OaLBiuttJK/K3UdcWqVVVYJ8lj8QzbwAMLYR558zZ+MyWaPz7dsU803cuTI2ENDJGzsIff8MLfz Tae22267wKOKSfx4gcAwXV/oj+14xNu1Ia63pHai6XhDM3mPL54igMYJF9GyAwYMcGeffXb4eeed d4IsJlZzHEw4R8zpNEMYN2PSNDM/hiXewWlm553Z3P04w+aJx8SLGCIqw9bNo87KpdXdEPvyuecR pPEeYzh3muVTF+UvueSSYIIlm8QurU7tEwERmE3gww8/DCfEZCTBwgsvHOzYcsstg/AHbNhka3HM eJlkhkdtXNxX2+8ved4xCaSF1fD3RdcnT54cxIk1cXebbbYJPPcl7kZJpW8Tb5fvMDMmwBVDo6Fl NRCQB281nCX1UQREQAREQAREoMEI4GljP4KY6Oy7774LJlqyCU1oCC9M4rT5tsYaawQ/mBBH8vWo sfJ4D+ItyKRaZogtbdu2DYafW1o+S4Zu8gORIZeFCH/51F2teTg3ccZ5KsTbOq6OQtPwxkZE3Gqr rcKiDCOPDiXnBzj9Q0iN8+Bs6Ost7Iy3gncX8W2xWbNmOYbx423mT0rIPoYU52N4Ucd5UudT1vJM mjQpnDgIz2c/Pu5//vOfcBKtXJOt2SSGCLxMFIRQ/MADDwQed4TEsCHVNikcISN4IWDlrD+lWvr3 LgI0L5Q4XrxrieNMDE57JuGFvv3222e9OPD7hZeZGS+R8FgmPxNMfvPNN4Gobtffu+++G4QEueKK K6yIliIgAikE7FlBluiIkJNOOsnhyYslTbbmC7xxz/qUpvPedc4552Tl5YXcl19+6RSLOgtL6sb4 8eMdk9WZ4QHdrVs329RSBKqCgATeqjhN6qQIiIAIiIAIzD0E8CB8//33s2KQ5nv0eOOZZ2xSmTfe eMPxSTLEFjwIEYaiZrNpR9NzbTMknI9vCDHRH4v+/qR1BETfqzEp39yUjuhN7E2bBIdjh68/aV5j 8sCzC6+vM888M4yFGG1/xIgRjg9D5hFQu3fvHs0Szt5eZ0eOhLjrLa4I3sRpE5YhriIM5itKcP/5 oU14sVGo+efwsMMOyypOTGN+cONVhdF34szGmYVAsTjIxGVG4OWYGfqMdyxmsS7Nq87KxdXZkGmI sDxjeMmz3nrrZVVNCAueQ4RmsFAVXB9Jnrx48A4ZMsQR67NTp05Zzy5iEO+www6BqGv3w//+978g fqgfTiSrA9oQAREICBAGyUYL8J3CiAzf9t1331DgJZwKMa/J59u4cePCTf9lTJhYghVegBGTnvA4 7dq1K0ELTatKnp2E3rDnLeeJUR6FhM9qWkR0NNVKQAJvtZ459VsEREAEREAEmigBxF2GMRZjTKwz cODA1KL8477qqqs6fnSZh5wVQFzq3LmzbWpZJQQQ5x588MEg9iheqQiTiKz5hBUo1SHiPclELRMm TAh+ZOPB/fHHHwexX6MesmeddZZbffXVyyLcI/JNmzYtnOHdeBD7lrASJnxaetqSoa3mEUs+hEW8 5U1kTStr+5hozOyTTz7JCptCOh73Zky2dtFFF4XhFSydpd3b9qIGD1nufdJPOOGEICvPGROk7Ye8 lfPrKsU6L6LM8y+ufsJ8IESbAP3UU0/FZQvTcsWJxMOPZ6PFHSa2pwTeEJ9WRCCWgMX8ZifPkrgX SvZcIQ/evqeeempWXf4oBLxqS2U843gOMKGbPcd4Kf3555/n/ZKuVH2r5HoRdxlNw+gGM767V1tt NdvUUgSqhoAE3qo5VeqoCIiACIiACMwdBCxeZzFHm0/8TEQTPGdra2sDT2EEXRPc+GHGDyTFXCuG fvnLMNt4MV7Rpew5MZOjfZo4cWLgfXrdddeFHkMM9W1sz2xEXIYVY7zwQPi0ofx4xxKmZIsttiga z+abbx4IvL6HKh5xeJzGCceIjyZA0miuMAKIGHGTrRFuwswEXgRcwmEgCpv558WfeIxRBPnGtbW6 SrHcddddw2o5VrzLot6BYYYcK/DmWWd8R48enaOEdouACNgkapDA+5+XcWkWN9kacdnNSnXf4fH/ 6KOPBiFeiN3LNl68GM9xPHnL+cLTjr/Slibuvv3222HXGA2x7bbbhttaEYFqIqBJ1qrpbM3FffXn nqmEf7jn4lOhQxcBERCBkhOwCUyKaaiQScf4sYMHnz+MnB9wp59+ejFNq4wIBASef/75IK7tyy+/ nEiE+Ml4VNqEX2REvMPbt1yGVztDjH2vzoMPPthNnz696C4xaSFxfS3UwnPPPRd4wRGCIM6YUKhQ s+HTfjn/JZEJvOw/5phjwmx43RG2wcw8eNn2y9v+ciwRnX1BlxcD9TF/8r+vv/66PlWprAg0eQI8 kxFNC7G4ydb8F1zU+dFHHxVSZV55eRlkL6l4thGyyJ4djKIo5tmaV8NVnIlzQYgcX9wdNGhQ8JK/ ig9LXZ/LCciDdy6/ACru8BMmEc+4msCTwsRdlrbOMfjrFXdM6pAIiIAIiEBBBJgxmqHZxQhLNty6 kAbXX3/9YCi6iT99+/Z1xNXzJ0QrpD7lLQ8BJufiRy0/yLkOunTp4rbeems3zzzzNGqHTjnllCAU A+E+EGzTXljgJYToxosFDC9aPH7LZUxId//994cT8xCntnfv3kEYhGL7ZCID5UeNGhVUQ71Tpkxx SyyxRFgtk5uZdy1lCMUQ5+VLATz1EcnxasVLjdAXvjDtC7R+eIh//vOf7s033wzi7xLCY/nllw/b jwq8/naYqZFXmNAREcKMeLr1MRupQB3ES87XmCTq+uuvz5qADtGKieCakhF/mRc0vOjA+B5g0qVi J2pkaDyhYywOKuE2fG/OQtg1dN8Kabux81bK9ea/gCN0zH//+99EFFdddVX4cpjnGOFpzPgfwzde 7jHyoJTGy+4bbrgh+B6knRNPPNERwmrxxRcvZbONVnefPn2C577fIM8jX0z390XXea4yqaXFYmc/ nru5Qt1E69G2CFQaAQm8lXZG5vb+bP4vN6vDjm6ewS+EJGrnn99NPGS/Pv+a0wAAIABJREFUUODF 48oEXgm7ISatiIAIiECTIpDvP+kNddAMYWQCJjxdMIauIxrhCSOrfAKIg3iFmhhG3ER+3DIxFROY NaYhNGOIj4jNeMEmGf/T0HezSvjxzQRtF154YTiRGfEc99prL4c4Wl8jPIPZzJkzbTVY4t0LMwyP 3yRxl/0IbryQYbIwjJcyfmxMX+D1PXjJS9gIPlHz8/nlo/kac9ufVA1BNu1lQa5+/frrr1mTtG22 2Wa5ioT7Ea+ik/E1xVjlRx55ZCjucvC8pOFFAC8R0q7HEJS3wveH76nOdwsTKuIhyPD5Qq0h+1Zo 242dv1KuN3vhxPHvvffeqRgOOuigUODlf4lrr7029KDl/wgmX+PlH0YYHGJqM6lXmjEZLCGl/vOf /xQVvocXCttss00wmSfPVkLe8MKu2u2rr75yp512Wp3DIMxRPkZYBuIV++Iu93g0LAMvVZgslcku G/tFcT7HoTwiEEdAIRriqCitfASaN3ez7rzezfj37LeetQvM78Zd1cv93qpl8GDl4cqPIfuY0Fu+ DqtlERABERCBpkCA7xWLRcrx4FGJl42sOgggxJi46/eYEAHEWm5M871SDznkEPfiiy8mNo8XkvWb iXga+8VGUseIM4nQa8bEab44a+kNuUSkNcNzMpfxEsYMIYYf42a+QOt78Nr+uGVjCryIrUx4xkiF JEPc8SdhSxOY3nvvPffss88Gns1x9cHm+OOPD2ONkycqZsSVszRemEStqYWywbvZPHf9Y+U8IPIU atzbcRYVyuPyRNMaum/R+ittuxKuN+4pi1eN52uu8E+MOkDkNWOyNd+6deuWNcpg9913d5deemns 9xPnm3t/q622cgMGDEj1HPbbiK7zO9mPY37JJZeEo0Wieatp22IL+33mpQmjv3IZoz+YUM3OLeI7 ozrinoedOnUKYtCfd955uarVfhGoGALy4K2YU6GOhGJt8+buz1uudrUndndT9tjF/bnxBm7ev/4K vXZ5g+4LvWE5IRQBERABESg7ATxXRo4cGcaw9GeMZuirzV5PrDiGouNxUahnVL4HyURLxOf89NNP gz5ZOcQgYq7hkYhwZcbwZ7w+EUIwhiQjFJHO0D++b8yIK0o9Js6xbfbSSy+Fx0nadtttF0xuZPvj lnh1MYzXvBqpw4wfFzaUHA8+JoLzh71bvlItK+mcJh2jzz+ah3O44IILRpNLtr3UUktl1c0s5hdd dFHgCcg1x/XONcn15YsA0ZnX/Uoa4np78sknHdeVH3vVrlXCHeARZWEJEDv79esXeC7RD34MI3Js sskmwT1LPjzUfvzxR4cAZsZLknfeecc26yxfeeWVOmk8F4YOHRpO7kYGxF6EWTxtoxPPUQf58cIy wzvtgAMOcB07dnTc9/xgN0P8nzp1qltzzTXdySefnHUfc79xnJyPESNGWBHHPYdYwDnx7/swQz1X zj777OBZQzWElmjXrl3wPGLW9mnTpgXH58cWxns3SWQYP358EEvcusR5wuOMc8V5RCzC05mlGcfM Oc/Hxo4dW0cUwvstzgs6n/oqNY953sf1j3NSqCXFS/av23zrbOi+5dtuOfKV+3rjmcbEajbZJAyI mcv/LtyfPGdWWmmlEA3Pnv79+zvCcVgIGnZa/HGEWl7e8Ty7/fbbA49aK9yjR4/gxTKhAnihRl08 u3hZ45v/codnFt8d3M+I0Gb0gdAWPE/8F0OEKUKotOPB857797jjjsv7GWBtFLLke5d+8nyyl4Ov vfZaWAWeyfbMXWSRRdymm24ahEQJM6SsxL00hWU+xiR4fsxdmPt8/TosdFLaizg/v9ZFoCIIZGQi UCEEamtrMzNnzsxMnz49M23atMwPP/yQ+eabbzKff/555qOPPsp8+OGHweeTTz7JfPHFF5nx48dn Jk+enPntt98yf/31V2bWrFkVciTqhgiIgAjMnQR4HjvnCvoMHTq0ZLDefvvtnH2ZMGFCVvt8D7Vt 27ZOuXfffTcr39VXX10nT9qxZxWO2UgrG913ww03xNRQN2ns2LFZfaybI3dKY53TG2+8MezroYce mrtjkRxDhgwJy/u8jjjiiEjO0m927Ngxti9+v6Lr9JP/g5KsIa63aJvR7YEDB9Zp/vzzz69zLNdd d13mgQceqJMerS/X9qRJk4L2Fl100dS6pk6dmtWvVVZZJTV/WrtvvfVWVl2vvvpqal2jRo3Kym8b d999d1hu7733tuS8l9dff31YPq2/7FtuueUy0eeP3xD3KHly1WP7jz32WL94zvV+/frVqXvYsGE5 y1Vbhp9++qnOccJsrbXWysyYMaPgw+nZs2dsfQMGDCi4robuW8EdKKBA586dw+Pu379/ASVnZy33 9eZ/F9k94y/PPffcrGO65557wuP189l6jx49svJ//PHHmZYtW6aWsbIsuY7862/EiBE5y44ZM6ZO m36drPOdkmT1fb5Rb9J3crQf/vYvv/yS1KWs9Ojzjv/Z8rVWrVrl5Of3ifXjjz8+3+qz8tX3Xsiq TBsikCcBhWioCJldnfAJ4CnBUFk8XHjbifcBnl7+knXfk7cU3hV+n7QuAiIgAiKQmwBxMfEUyddK PSSd4e60kWR4zfjD6cnHCBEmViFunRl14P3nG3EZ843Pu//++/tFY9fzyUNB2sQ7r7Gs0s5p0nEz Mcp1112XNXEUTJO8HpPqaYh0f7Iv/zqKq5u8TLaDZ1fa/zINcb2lXWN4iMYNb4WfP7EQ11+rVq2C a7A+XuR4rNqQ5yTvKXjBLzrBVVrsV4bZRu9V446H3KqrrmqbwXKjjTYKJrnLSvx7I+6+j8tXTBoe dtdcc03q84l6GU2Ad3Fa/GP44NGW69nL8TCJEJ5zhZjFJbcynJPtt9/eNpvMEs97QgO0bds2PCau U0IqFDPKhPjfeIzb9wRLYrDmE34k7MDfKw3dt2j9lbRd7uuNsAh2zqJcSMfT1Lctttgi8RlCfp6X vjHJHl66XB9pz1CuFSbdJB66f/0xgSgTcyZZ69at69RLm9RjRr8KicFt5QpZwint/69oXYy+yCfG +JgxY8KRU1ZHIeG0jj32WCuW95IYyDIRqBYCNQjB1dJZ9bNpE+BS5MPQOoaf8GHiEYZ1sE4MPX78 8OObLzpEXgRg1vkgCqf9OGra9HR0IiACIiACIpBNgCGchJcwq+R/+RCdiFGIETaDIeTF2jfffOMQ RBj2WQ6zIfG8PGCCMoaqMjSViWEYrkq/ECHXWGONYFgu/9fIqosAcTFt8jwE6kceeaToA2DIPjFe +bBO6AQEmfXXXz8UwfOtnP+hEUAIqcFQd/43RrynPp4FvlCUb52Eh7FQNJR55plnglAY+ZavxnwM 08eWXXbZenef3zCERVl99dWL4h/tQEP2LVp3Q2x36dIleElKXYQNsPsk37rntuuNUB6jR48O7lvu fURR7tV8xM58mRaaryGfb4W2nSs//xscfvjhYTYE7bfeeivcrqSV+t4LlXQs6kv1EFAM3uo5V02+ pybO8s8oP3b4IYqAa6Ku/TA1717+SSWfhN0mf2noAEVABERABEQgbwLESSyn8QPdj5+KhyUexjIR iCOw5JJLBnG6idVdX+P/YkYuNNRkfXgP++Iu3og777xzfbtZ8eUbQti1g+T3iv+izdKLXTZk34rt Q6nKzY3XG6IuH31H5HdV+fMTUKIco3Ty66lyiUB5CEjgLQ93tZpCAEHXRF5bx3vXF3htvy/wmkCc UrV2iYAIiIAIiIAIiIAIiIAI5EFg+PDhWbkYCq3/t7OQaKMBCeh6a0CYTbAqtADCqJgR4miXXXax TS1FQASccxJ4dRlUFAH7pxEBF4sKvGzbhzx8rExFHYg6IwIiIAIiIAIVRuCWW24JekRce34UpcX/ a4yuP//888FM4LQ1dOjQxmhSbYhAgxMgtILdW3jj7rHHHsHcEQ3eUBkqHDlyZNgqoR5yxfkNM2tl riEwffr0II74lClTgmMeNWpU0ceu661odCUrWEnPt++++y5rREHPnj0DLaBkB19gxQ15LxTYtLKL QEhAAm+IQiuVQsAEWxNveVtngi99tP0m9NqyUvqvfoiACIiACIhAJRCw70vriz+5CJP/XH311bar 0ZcTJkxwHTp0aPR21aAINAQB/9767LPPnH9vDRw40O25554N0UzZ6+A4mMCNY+zdu3cQGq3snVIH KorAoEGDXNeuXWP75N8nsRkiibreIkDKtOmft0p6vhGehPi7ffv2dXjvpk3QWQ50DXkvlKP/arNp EJDA2zTOY5M7CvtiYWmhGfyDtP2k+et+Hq2LgAiIgAiIwNxMgEm8DjroIDdixIhg0lJjQUzYHXfc 0TbLssR7GG9AvIOYUNWMydEOPPBA29RSBCqSQLt27VybNm3cl19+mdU/ruuWLVtmpVXzxr///W9H XFQmf8M7WSYCUQLEZebjx2omDxNJFvo9o+stSrc825X6fGP00Z133umuv/76cNL18hCKb7Uh74X4 FpQqArkJ1GTi1LPc5ZRDBBqVgH+ZStBtVPRqTAREQAREQAREQAREQAREQAREQAREQAREoIIJyIO3 gk+OujaHgETdOSy0JgIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAJGYPZMVralpQiIgAiIgAiIgAiI gAiIgAiIgAiIgAiIgAiIgAiIQNUQkMBbNadKHRUBERABERABERABERABERABERABERABERABERCB bAISeLN5aEsEREAEREAEREAEREAEREAEREAEREAEREAEREAEqoaABN6qOVXqqAiIgAiIgAiIgAiI gAiIgAiIgAiIgAiIgAiIgAhkE5DAm81DWyIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiJQNQTm rZqeqqNVR6D2zJ7O/fprbL9rjjrU1fyzZey+XImlqjdXu9ovAiIgAiIgAiIgAiIgAiIgAiIgAiIg AiIgApVGoCaTyWQqrVPqT9MgMGuxVRIPpNmAW11Np10S96ftKFW9aW1qnwiIgAiIgAiIgAiIgAiI QMMT+O6779yff/4ZVrzUUku5JZZYItwuxcrvv//uJk6cGFTdrFkzt+qqq7p55pmnFE0VXOcff/zh JkyYEJZbaKGF3AorrBBua0UEREAEREAE4gjIgzeOitIalsDqqzr3j7Xm1Mk/Ty03mrNd6NqO22eX mPaLc2+/m52mLREQAREQAREQAREQAREQgYomcPDBB7sBAwZk9XGVVVZx48aNy0pryI2PP/7YtWjR IqvK8847z/Xq1SsrrRwbHPdqq61Wp+m33nrLtW7duk56U0z4+uuv3UsvveReeOEF9+WXX7q77rrL /eMf/2iKh6pjKjOB8ePHu0GDBrmhQ4e6119/3W211Vauffv2btddd3UrrrhimXun5kWgcAISeAtn FpTIjP7YuVm1zjWrcTUbZ/+DUGSVLvPteOd+mpxcfKGFnFtjVVfTvHlinsxnY5z7Y3ri/tQdyy3j alZcwWWmTHXu63r8U7Xxhq6m2ZzwzjV77OqaXXROatP+zsxvv7vMXfc6N3OWq9lmC1ez2T/93W6e x+7N2s6MfM/VttstK00bIiACIiACIiACIiACIlBpBGbOnOk+//xzx9KspqbG4bWKlybepBhC39Sp U50/2BIP03XXXdfNO2/T+QkXJ+Ry3KW0n3/+uU71cWl1MjVCQlI/Ss2kPof2/fffux9++CGrisUX XzxWqM7K5G28/fbb7r777nNPPvmk++KLL7w9zo0cObJogfebb74J7iO/wuWXX94tt9xyflJVrk+b Ni3w9P7rr7/q9H/JJZd0vCgp1hA+R40a5d577z33ySefOOpbffXV3bbbbus222yzQID/6quv3D77 7OM412Y//vhj6BlvaSx5rq200kpBPWzHXTM8B9dZZx03//zz+0XrrMeVLfR6o9KxY8e6rbfeOuva ffjhhx0fro833njDrbnmmnXaT0toytdb2nFrX+UQaDr/HTQS08ykn1ztcac699wLYYvNPn/X1Sxf /y+J2m6nOffSq2G9sSt4v669pqs5/ihXc8j+jgehb7Vtdi5e4N2to5vn3ttd5q77XKZnb7/agtab vT7EuRYbFFTGMme+G+9quxzq3Icfz07q1aOOwGt5tRQBERABERABERABEZi7CUyePNkttthiVSN6 7rHHHu7pp5+OPWl9+vRxp5xyiuvdu7c799xzY/PsueeebuDAgbH7qjHxlltuccOGDXMIm5dccon7 5ZdfSn4YiDqIiYiKV199dcnbK6SBli1bukcffdThxYpn4YsvvlhI8UbPi2fxFltsEdsufd9hhx1i 9/mJhKTYfPPN/aQGWccLuF27drF1Id4l9Tu2QIUlEsIDwTTN7r//frfffvulZamzj3oPO+wwN3jw 4Dr7LGHRRRcN71NeQB155JHBLoT5tdde27LFLqdMmeIQQbnO46xVq1bunXfeidsVpDXE9UZF3F9t 27bNEncRde1FBcvtttvOvfbaa0H4lsQOeTua8vXmHaZWK5zAHDfLCu9oJXQv8+Irrnar9lnibtCv hgpjnE89s2Y599kYlzmxu6tt38nh7Zpl9YmoHLZfn0qcc2E9WT1L3eDLITP4BVe7w25zxN3UEtop AiIgAiIgAiIgAiIwNxKYNWtW4OnHD/Cll17arbfeeq62trYqUCBwJJl5acZ55FmZb7/91labxJJz d/TRR7uzzjqrYG+5YgHgINO1a1d33HHHFVtFScvttddegdDPMPFKt08//TSxi7k8Ma3gfPPNF4af QOA79dRTg2Hytr/YZVr7af0utr3GLJfP8+6cc84p6Ln47LPPBs/SNHGXY/RfwhA/28xPt7ToctKk SY7410nG6IY0Sztvaec7WichWexZuuGGGwaiM57BCL9sY+zv2bNntGjidlr7af1OrFA7RKAIAvLg zQNa5q+/XKbX5S5z3a155G6YLDUH7efcOt4bsJkznPtqnMsMe9W5b/7+x+6td13m3ItczdWXho3W nN/duajoi+Y68CnnPv5kdr7dOrqaTerGwK3ZaPbDrKZtG+fOPSOsM1z5eYrL3Hj77M3FF3M1Jxwd 7spaWbWw4SC1t/ZzmVv7Ojfmy6xqtCECIiACIiACIiACIiACRmD69OmB5+Xll1/uPvvsM0t2DAtG 8LDwBuGOCly588473csvvxyImta9G2+8MRj+jGCN4cXL0OBff/3VnXDCCZbN9e3b122/fWQuinCv VkSgvASIXcr1jeHlme9EeYQewTOTsCUWfuSyyy5zQ4YMqdcB4amNZ7gJj0cccUS966xXhxqw8Mor rxzEjUU45Nn3zDPPOARa3/Co5VmTjxc13uK77TYn5OFaa63lrrvuuiAcAyEtxowZE8REvvjii0Nh lLZ8oXmTTTZxjz/+uCO8A96shDrAOnXq5Bi5sNFGGwUevtR9zz33uAMPPDDsLmmMWuCc5WvFXm+M +vDjfjMigkkWMeJfs73++usH28R/ZmQFISpyWVO+3nIdu/ZXDgEJvDnORebPP13tTp2cGzV6Ts5O uzj31jvOTZg98+qcHQ23VnPUIa5m043rVEh/Mj16uczt/YN9mTsHuMxxR7madWZPYtas21F1ypBQ O+47l/lb4G22756uZvf/xOYjkXZj254wcY7Au/JKrtmZJyXWUciOzBnnzcm+8ELO7bSDc0/ED12b k1FrIiACIiACIiACIiACcwMBRJrbb7/dXXXVVeEQWjtuhmDzA9yEIUuv1CUeq+a1Sh+Jkxn1JEUY O/TQQ4NDQMw2TzOGTucyRLKPPvooEFnwCMYbGNECASVu8q5ofZSfMWNGkIxnJeIbRtro0aODuhnK vMEGG4SiSLSOXNt4YNOvBRdcMFfWxP3UgbcfYhIfvOfWWGONQEAinjHDwIkdyvVR6LVBfQwTx9OQ 4yTu8QILLJDYl7gdDPFmMjc8tvkQI5Th60wWthDzqtTTENb+/PPPrFo4zuYpc7VYZsrieYk4yCRm yy67bHBN0j/OebFGqBQTyoqpo9DzlE8b3EsmNNsyn3LVkGfHHXd0fLBXX50T5vG0004LnpWk33HH HTkF3t9++80de+yx4SETBqZfv35ZsXW5bvnsvvvuwbViorkfS5wKEHMx7m0TeHfeeefwecY+rtsH H3wwyMcf7i/CeSBaF2LFXm+ErjA75JBDguOxbZY8n0nv33+23kL+6DPaz++vN+XrzT9OrVcuAYVo yHVumLDMxN0FF3A1113u5hlwq3OLLzanZCQO7pwdDb9WM//8ruayC5xbb52w8syoD8P1ql2B4b/b uWbDB7tmB3Su2sNQx0VABERABERABERABBqGACLdmWeeGUxA1r179yxxd//99w8mX3rhhRccnmNz u+Fhd8ABBwQC36abbur+85//BGEIECrw4GOCJNLShkD36tUrKI8AyQfBDbHzf//7XyD8MXz+oIMO ch06dAjEYtrDGy4fQ+zEG5lJmqiX+lu0aBHE+0yKSRxXL4LSzTffHIhCiK8IXPSpS5cuQRxXQnYg MnK89BPv6HyNSaW4lhCaELKIX8o2dQ0dOjSvaogpzHHh9Qh3xDKEecIuUBcT6ZEnKozlVfnfmeCF kGTnyZaIs5yrJMMDHg9MRHvEfjwg//vf/wZ9ZFg6IjnhEZi8SxZPgPPGtXD++ecHS3sZEp+7cVJ/ +ukn99BDDwWNcc336NEjbJhY0xZXNkyMrOAtbS+ReHlz7733Zom7fvYVV1zRnXHGnJG+hV7HvDTh XnjqqaeCarnu8DIuVNz1+1Touh/DvGPHjrHFd9lllzCdmNgyEagWAvLgzfdMtdjANbvrJlfjCav5 Fm3ofDXNm7ua7bZ2mU//jlHzf8mxjxq67VLUV9PjNFez396uZo3Vguozn48tRTOqUwREQAREQARE QAREoAoIfPDBB4FXrnlQ+V0mfAFCYaGzm/t1NLV1RCYECT9sRdwxMoR7+PDhwXBrhJyovfvuu9Gk YKiyeetFdyIe4SXL8Hrz9I3mQQC69tpr3emnnx7dFXi4IvwyDBqvQwTIXIZgTbtpZmIVeehfPnbD DTc4PnGGQIYYyrBzJmZKsgceeCDLEzIuHyzxlpw4caK74IIL4rLkTCMkSdI5GTlyZGx5JotCCGfY fpox6RwCH4zNOzQt/9y0jxitTA7mC6aEooAt4QfKZeYpS/t4/uPBzpL7CiMcAsJ9nDE6AtHfDLE3 l2f9PvvsE8amxfs7X8NTmBceFnqDF0bE+11mmWXyraJB8n311VdhPUkhbyxcDhn9/GFBrYhAhRKQ B2+uE4PX7vndXbNhgypC3A2728w7dY3oQRy234Arzc46JRR3G7BaVSUCIiACIiACIiACIlBFBBim i5cpno6+uIsYifCApxrhGCTuZp9Uhtz74i4iFIIpnmqIKRdeeGFYAGGQWJdxdskllwSiI0OmzUxI 3GabbdwVV1zhrr/++qwJsBCF7777bsteZ9mtW7c64i5ee3jOEZ7CjPAb/jFYur/E088Xd3v37u3e fvvtYMg3oQYQWKPCtR8j1K8raR3BDm/xW2+9NVj6+U466SRHaIgkw+PcjHr23nvvgBfCMB6WMDTj nIwdW5xTyxZbbGHVhEu8jZNEagRvhsn74i4vSvBERQBH9PevEQRMhDgJWyHeYOWmm27KEndJ5P7g viinEb7GzOLoMnGhGV7sSfdBdPIvXgLkMjznYWHe/Lnysx9OTBpo4m7r1q2D66+xxV364t8HSQK1 n+7nz+dYlUcEyklAHrw56AchEU6bM7lBbPZMJja5VImZ2lqXGfHmnOrXXGPOutZEQAREQAREQARE QAREoIoIIDIdeeSRbsSIEVm9Rmg866yzglADhcZAzaqogjeIk4vHZJKxP5cxtB5x/P3333c77bST 23jj7Hk8SENcZIk98cQT7rbbbqtTLcIrQ8+JGeuLrQiHxKCs+dupBNH2xBNPDD1eqS8uPjACot8O 8TkJT0CYAjM8TvHKxZM3l/lxRq+55hqH4GpG/F0+eDIzmZYNWS/kuoERorgvEhMKhBcOGJ7liJ7E qo0zwh1wLlZaaaWgH4RO8A3BFw9gO45XXnklsS6/nL8OU4a4m9E/zk/SJFAI0vA1oZ5jw+PUPwZi jnLsBx98sEM8RuAlf9euXYO+liI2rvW/mpavv/56bHfTwp7EFmjAxA8//NCZ5/3hhx/uFl544aD2 Lbfc0nE/c18hUCZNtvZ///d/YW/wqM33XOOF7sftDSuJWSGMCy907PnOtcakcMTQbWzj2WbGS5ik kQdM2Ml+u2/wdE66x6w+LUWgEghI4K2Es1BAHzKzZrnMRf9zbvTf/wQRrqHtnLfBBVSlrCIgAiIg AiIgAiIgAiJQdgIIBfbj3zrDrO6IAvzQbsqGgODPJl/ssRLvlU+SMdwewRzhFgGPOKv5CCyIpQi6 viH09uzZMxR4fZHI8hGawRd9O3fuHIquloflZpttFoR4wOs4l6ec7z2LkBpniyyySCCYM8wcL/BC wgwgCvviLvXTL3+4O57Cvjjq94G4uL7o7O9jnWv55JNPDgVeX0SP5o3bJvawP9kTXsaIymnGfYX4 b4ZAnNR/BHKG+9uw9TfeeCMQCGEgcwE380D1eeyxxx7+ZqOuE37BLPoc4Vo0T96kydb8e5dJ1Eph 55xzTla13AfcR/biJGtniTcIb2Lme+lamr8k3rAJvDwzJfD6dLReqQQk8Fbomcncda/LrLH6nN7V znLum29d5tXXnfNi1NYcuK+rWXmlOfm0JgIiIAIiIAIiIAIiIAJVRKBNmzZu2LBhWT2+9NJLg+1i RV4mHZs0aVJWnflsMDlWtYaAeOedd1zfvn2DYfd4mppgSigExBRfUESwyEfgxes0zhBHEEOpx6/X 8hJ+wI+Fi8dtkuF1iHjJBFFphhhsxkuBjz76yG299dbBhGYcCwIl2XxtAAAgAElEQVQrfWKd+KMM XW/evLkVSV3SNp63ccakdWYTJkyw1djlr7/+6gYMGBAMRf/666+DSe0QifAGXGeddbLim+aqy28A sdzniQck90YuI4SFGZ6THCOhTpIMr0/fcxHvUAm8s2khVBJv2jxmScXr1UTUJKalSif2NvcNxnXv x40lbd999w37RmgT4itHX2CMGzcu7B7nvTEMD3buKSbIbNeuXWM0Gbbhvxj666+/wvS4FSaEM8sV l9jyaSkC5SYggbdEZyDz3FCXeeud9NrXWM01O7hrbJ5M3zlv42IzkLjrzq7m0vMTd2uHCIiACIiA CIiACIiACFQ6gV69egWenMQBNfEEz0NiNuJ1irCCWOH/OM91TIhpxVqmEcOvIarYMcf1FwHJvMji 9pM2fvx4d8ABB9QRyS0/wqAvDpKe7zGmid0Ixwi8ceaHXDBhMS6fpaVNXmZ5ELBs2DlpSTFnYYrX LTFCifWZj6VdL36c0DRuiOt46MadL9Ki5zkpLmpcf/3zx/ERBzUfe/PNOWH9uKf8Y8mnPGEpZLMJ cL3zEoW4tYRr4LpOu25KzY0Jyuxam2+++dyVV15Zp0muFcsTN9naWmutFZbBq7ZUxiSFhIhhQjfr D971hLcoledw3LH4Ard/T8Xl9ff75eLyKk0EKoWABN4SnYnM44Nc5r5H0mtv2cK5BIE3vaBzzR67 19XsuH2ubNovAiIgAiIgAiIgAiIgAhVPYPfdd3d88Oq6/PLLw8l48A4lhugZZ5wRxOMlzuTiiy9e 8ceTbwc5ljSBg/0miMTVycz0hGbwvWgRohg2zhBjPM8QYRH3LPZrXD1JaRZ3N2l/Uro/9HvVVVdN yhamI1AhNpnXcbjDW0GsYog8x+Z7pnpZglV4MRkcHyblY0Kx+lg+YUKIQ0w4C9+Y8GqjjTZyeDv/ 8ccfgZiF522SKO6XTVvn+BDHEBlzCU/1nSht9dW9EaVpnZqL9hGzmE+5DS91M8RI4pWnGZOt8QLC v579FwWjR49OK170PuJiP/roo8ELOjzv2bZn0VFHHRU88/0+Fd1QHgWJye2L3n/++Wfsi0PSzchf SCxvK6elCJSDgATeUlH/exKC1OrnmSdxd80N/3M1m8yZICHzznsuc/LZc/IvtOCcda2JgAiIgAiI gAiIgAiIQBMggHDFB085Zqe3ybIQxU499dRgErATTjghiAubNKQeDP6P+EKwUK6ajHAAvrj72GOP BUJ5nGCCR6sfs7OUx+nHq8xnojhi9qaJu9ZXzjnD5JkobPjw4Y5JppgACQGVIdUIXb7nHdcMoQzW X399q6IkSz8WLpPJER4iLsYn3p/F9MXq5CUIsXFhxXERXzfthQce2CaGUwee3vkYk23h7ctkXbLK I8DzENG0EOOaiU625gvV1EnYkxYtWhRSbc68jMSw0Rc8X3lG4YlPe4TmufvuuwOP+5wVNVAG7gnz TMeDmJcwUSPEj1naKAbLo6UIVAoBCbwlOhM1l13oao5PD3rvlloysfWalhu5mk3mPGxYn/XMEOee nx0kv7ZHL9fsxafC2WwTK9IOERABERABERABERABEagyAv/617/cgw8+6Hr37h14YVqsSbwXL7nk kuCDqIZ3Zpxg9sknnzh/Qp18Dz9NNM63jsbMx6RZZoQISJvw6fvvv7esJV8i4JghxCK+LrTQQpZU Z4lomcsQXe68887gBQDDvYm/G2d4IiJ+mtCLwBl3jcSVLSaNdhCrMLynH3nkEYdAGmfFxIWmnuOP Pz4QjJ9++mlHzGpCYBDygfONV3BSjFDi59pLEkR3JruTFU8AQZDnksWP3WefffIOl1F8q3VLMhme Wa7J9q666ip3+umnB9lvu+22rMkYo/cF4XAef/xxq7oky6WXXjoIr9KlS5eg/hNPPNHtueeeqS8q GrIj3BMm8D7//POxAi/hL8zKMRmcta2lCBRKoGlPS1sojQbMX7P4Yq6mxQbpnxVXKKjFZhee7Zx5 Br/zvss88kRB5ZVZBERABERABERABERABKqJAOELbrrppiDObI8ePQLPXOs/YgVDjInhGzWEWn6Y F/qJ87qM1l1J2yYs0id/uHW0j3i8Et6gsczvC6L8eeedl9g0kx3lM1FVv3793GWXXeb22muvUFCN qxSPPN9TlQnfSml+/RtvvHGiuMtx/u9//6tXV5ZaaimHKIWQjOEBybHiAR1nvnciQ/p9z8S4/JY2 ZcoU991339mmls4FojoxwbmW4d6zZ8/AExXRvbGNZ59Z0kSIth/PfbMHHngg697Bo5bJ18wINfLU U0/ZZuKSFzIHH3ywo75iDGGcGMYYzwdGazSW+TwGDhwY26yfToggmQhUCwEJvNVyppybLRZ3nTOT beaCS11m+vQqOgJ1VQREQAREQAREQAREQAQKJ0A8Wbx5v/nmm0Ak82OPnn/++S7XjOiFt1gdJXwh lZizM2bMyOo4MXqZjMzElKydJdzg/PhhC4iFS4xQf2Z6midGLN62/qRsSd2aNm1asAtBiDJ+nF+/ DAzwGjZbfvnlbbUkS38I97PPPhuEkIg29N577wWTTCGg1ddWXnllh+e2hRNhyPsxxxwTO3EenPBY NGOywqTJtJj0jdioXbt2dXj7IiITAkQ2mwDXcJzhVd6YxrVkHqh4vuIRm2bci76oGQ3T0q1bt0Co tjoIA3LppZe6uEkACfPAy5itttoquDb8e9zK57Mktrcv6jIqwzzu8ylfnzyEALIXJMQmZ+SDb2yT jpGPGOcyEagWAvFjR6ql93NhP2vOOcNlHn3KOQJ/j/vOZW6+09Wc0m0uJKFDFgEREAEREAEREAER mNsILLHEEsFwY0QJvMcQtzbffHPHJF3VYMTAfO6558KuImoQUxixDrFkjTXWcHiEMkz666+/zhI9 TjvttCC+7vbbz5lomeH65s133333Bd53ePStvfbagZDHUG4E0agxFJs8DPHfYostgt0IR4MGDQqG /Ft+vBURCJnkzuJo4kHKEHWGq5txDAz35ryY4W3LcZiXMZPn4YVLn/GwJoxGnFcx/aU+wnQceuih Vl3WkvAEhIHo3r17kI91xGMESrzvTKChELFnfZs+fXoQ6sEPC0GYA0RNBLN//vOfQfYJEyY4vF4R bc1gTZxSBFUTdplEDiHIBCp4tm7dOphMij7RF78/VtdLL70UhBiBBaFGCOuAqIbHOtfAK6+8Ylnr LImdCmsYY4iMcGZSNLyITXjjvkCktWHmcGMyO0I+wJd+EzYCwZB8dgzWoD/ZlKU19JI2eDkxfvz4 8AUFHudm8DB+iyyyiNt0000dQnVj28SJE2ObJAZ0YxghZ7ge/ZcEXIvcK6uttlrgye2HmOE+6t+/ f3Cfjho1Kuwi9yHhWhBquRaaN28exIz2XwIxWuKOO+4I7lXuf+p68803s+4FKvS9h/Ei5zwiAvMs MaMPvIzhHvU99Qmxwr1px0P4kPbt27vjjjvOrbBCYSOdra18lvPMM4876aSTgmca+ZkcEbYcPy+G zj57zrxHPHPj4pnn047yiEBZCGRkRRGY2XqHzMxFVw4+tRMmFlVHtNDM3fadU+d7H0R3h9uzzukV 5pu58vqZ2kk/hfuSVmYdf0ZYpvaJp5OypabXjp8Q1jFzix1T87LT+Mw69+Kcef0Mtc8OmVP26hv9 XbHrtW+/G+avfXxQbB4lioAIiIAIiIAIiIAIiEC5Cay77roZ51zs55RTTgm6d8wxx8Tup1yrVq2y DmHWrFmZDh06JOa3tlq3bp3Zf//96+Rr06ZNWN8uu+xSZ7+VHzx4cJhvueWWS8w3ZsyYMB8rI0aM yKTlt/rPPPPM2DonTZoU1gcfy5/vsm/fvmF5W+FYksp37NjRsmX69OmTmM/OlWV+5ZVXEvP6bV18 8cWx+V566aWgqtGjR8fuHzZsmDUVLCdMmBCbz9qaMmVKVv6HH344s+iii6aWsbK27NGjR2b69OlZ 9UQ37r777rDOvffeO7o7r+0hQ4aEdVjbuZa//PJLXnX7mTp37hy2079/f39XXus9e/YMy/v9GzBg QF7l65vpxhtvjG3f+nLuuedmNXHPPfek5uf8+vbxxx9nWrZsmVrG2mIJjxkzZoRVcK/7++PWo88H 2ozmu/rqq8M6oysNcb1RJ8/NI444ok7bfl94DpOvWKvv9VZsuyo3dxNQiIayyOr1a7TmtBOcW3yx 2ZVM+8VlLrmqfhWqtAiIgAiIgAiIgAiIgAiIQMkJ4CEaZ3hSbrvttsEuJhDzQ1D4+bfbbjt/M/Au YxKtM888MyvdNvDQw6sOj8gLL7ywTr0777yzZXXMdh9n9MW8Vdnftm3buGyBt180HAJeenjq+kPE /cJ4Bz755JOBJ2r0mPGow6vWjPinZuyL5rd9LDt06BB44x122GF+crCOByi84wzvYrNWrVrZatYS b2s7V7aDcnjk4qUYZ7vttpv77LPPHJ7T0XPFObJjI+a0H1KBuugrffYNT3Yr46ezTliGxRb7+7fi 3zuJeUpoBjyP0wwPSjx5p06dGoREMa/ttDL13cexwSBf4/gWXnjhfLM3WD68xU8++eQwNAbXAZ7X jeVNTFgEC8sRPSjSo9cInuRJ1zn5o9c34V7w0uU40+4tjnncuHHB88SfTHCdddZJbI/+4tUerZc2 eS6Z0a/NNtvMNku2xCs3bXK6Y489NghtI+/dkp0CVVwiAjXo2yWqu0lXO2un3Z17691g0rNmX4xy NUsvVe/jndX5EOcGvxDU0+zNF1zNBusl1ll7zU0u0/OS2fvnndc1++YjV7NI8hdd7ennusxtd82u +4n7Xc0Oc/55SWwksiMz6SdXu/amznHJbLGZm2dI+gybsxab/Y9TzUnHumYXnROpLXkz89xQV9tl 9nCsmj6XuGZHHpycmddsI99zte12C/I0G3Crq+m0S2p+7RQBERABERABERABERCBpkZg8uTJgYjI 8Gsm42KoPkJgpRhxkhF7CT2BcEvYgCTBKq7PDAEnrMIyyywThIMgD2EUqO+nn34Khpqzj+HqLMth 9JHwCkxmhjiEcIloy7DwSjHCQBCKAcH5119/DePtIgYWKugiBjPZFsZw/UceeaRSDrNOP7p06eII WYIRNsD6XSdjjgTOMdcc4TB8gTNHsarbTUiK0aNHB9cyIRO4lgnrUg5x3eCV4noj/AQhQLhneWnC SylCgdTXGup6q28/VH7uIqAYvEWe73mGPllkyeRi8zzcP3lnZE+zk49zjk+e1uzKi53jUw+rWWZp N8/UcQXXkPnsc1f7SPaEAjVbtXY1K68UW1fNzju5eaZ9G7uPxMyIN1xmwvdz9r/7/px1rYmACIiA CIiACIiACIjAXEgAUXfLLbes2CMnHizeqVEP1Xw7jJgW9Zxl8j0+lWL0kfi4fCrVEJ4RwfnICifA OUbobOqGqMuHEQVN2XjJ5I9kaMrHqmNr+gQk8Db9c1z+I3x2qMs8OzSrHzUDbnUuQeDNyhizUdtx n5hUJYmACIiACIiACIiACIiACIiACIiACIiACIjA3EdAAu/cd84r44hrakrTj1LVW5reqlYREAER EAEREAEREAEREAERqHoCH374obvllluC4yAExx577FFwyIeGhDB9+nT3+OOPuylTpgTVjho1qiGr V11lJqDrrcwnQM1XJAEJvBV5WppGp9LCLNTnCEtVb336pLIiIAIiIAIiIAIiIAIiIAIiMDcRqPGc a4jpy+RUZgMHDnRJkwpanlIuBw0a5Lp27RrbhN/v2AxKrEgC/nnT9VaRp0idKjMBCbxlPgFqXgRE QAREQAREQAREQAREQAREQASqjUC7du1cmzZt3JdffpnV9eWWW67oWMtZFdVjo1WrVo7PDz/8kFXL mmuu6XbcccesNG1UBwFdb9VxntTL8hGoyWQymfI1r5ZFQAREQAREQAREQAREQAREQAREQAREQARE QAREQASKJdCs2IIqJwIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiUF4CEnjLy1+ti4AIiIAI iIAIiIAIiIAIiIAIiIAIiIAIiIAIiEDRBCTwFo1OBUVABERABERABERABERABERABERABERABERA BESgvAQk8JaXv1oXAREQAREQAREQAREQAREQAREQAREQAREQAREQgaIJSOAtGp0KioAIiIAIiIAI iIAIiIAIiIAIiIAIiIAIiIAIiEB5CUjgLS9/tS4CIiACIiACIiACIiACIiACIiACIiACIiACIiAC RROQwFs0OhUUAREQAREQAREQAREQAREQAREQAREQAREQAREQgfISkMBbXv5qXQREQAREQAREQARE QAREQAREQAREQAREQAREQASKJiCBt2h0KigCIiACIiACIiACIiACIiACIiACIiACIiACIiAC5SUg gbe8/NW6CIiACIiACIiACIiACIiACIiACIiACIiACIiACBRNQAJv0ehUUAREQAREQAREQAREQARE QAREQAREQAREQAREQATKS0ACb3n5q3UREAEREAEREAEREAEREAEREAEREAEREAEREAERKJqABN6i 0amgCIiACIiACIiACIiACIiACIiACIiACIiACIiACJSXgATe8vJX6yIgAiIgAiIgAiIgAiIgAiIg AiIgAiIgAiIgAiJQNAEJvEWjU0EREAEREAEREAEREAEREAEREAEREAEREAEREAERKC8BCbzl5a/W RUAEREAEREAEREAEREAEREAEREAEREAEREAERKBoAhJ4i0angiIgAiIgAiIgAiIgAiIgAiIgAiIg AiIgAiIgAiJQXgISeMvLX62LgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIQNEEJPAWjU4FRUAE REAEREAEREAEREAEREAEREAEREAEREAERKC8BCTwlpe/WhcBERABERABERABERABERABERABERAB ERABERCBoglI4C0anQqKgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIQHkJSOAtL3+1LgIiIAIi IAIiIAIiIAIiIAIiIAIiIAIiIAIiIAJFE5DAWzQ6FRQBERABERABERABERABERABERABERABERAB ERCB8hKQwFte/mpdBERABERABERABERABERABERABERABERABERABIomIIG3aHQqKAIiIAIiIAIi IAIiIAIiIAIiIAIiIAIiIAIiIALlJSCBt7z81boIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAI FE1AAm/R6FRQBERABERABERABERABERABERABERABERABERABMpLQAJvefmrdREQAREQAREQAREQ AREQAREQAREQAREQAREQAREomoAE3qLRqaAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIlJeA BN7y8lfrIiACIiACIiACIiACIiACIiACIiACIiACIiACIlA0AQm8RaNTQREQAREQAREQAREQAREQ AREQAREQAREQAREQAREoLwEJvOXlr9ZFQAREQAREQAREQAREQAREQAREQAREQAREQAREoGgCEniL RqeCIiACIiACIiACIiACIiACIiACIiACIiACIiACIlBeAhJ4y8tfrYuACIiACIiACIiACIiACIiA CIiACIiACIiACIhA0QQk8BaNTgVFQAREQAREQAREQAREQAREQAREQAREQAREQAREoLwEJPCWl79a FwEREAEREAEREAEREAEREAEREAEREAEREAEREIGiCUjgLRqdCoqACIiACIiACIiACIiACIiACIiA CIiACIiACIhAeQlI4C0vf7UuAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAkUTkMBbNDoVFAER EAEREAEREAEREAEREAEREAEREAEREAEREIHyEpDAW17+al0EREAEREAEREAEREAEREAEREAEREAE REAEREAEiiYggbdodCooAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAiIgAuUlIIG3vPzVugiIgAiI gAiIgAiIgAiIgAiIgAiIgAiIgAiIgAgUTUACb9HoVFAEREAERKAUBL799lv36aeflqJq1SkCIiAC IiACIiACIiACIiACIiACTY7AvE3uiHRAIiACIiACVUvgxBNPdNdff33Q/0suucSdffbZVXss6rgI iEDpCfz888+OT9QWXnhht/zyy0eTtS0CIlCBBL777jv3559/hj1baqml3BJLLBFul2Ll999/dxMn TgyqbtasmVt11VXdPPPMU4qmCq7zjz/+cBMmTAjLLbTQQm6FFVYIt7UiAiIgAiIgAnEEJPDGUVGa CIiACIhAWQgMHjw4bPe9994L17VSHQRqa2vd8OHD3ddff+0ymUxip/kxvfXWW7u11lorMY92iEAu Ak8++aTr1KlTYrZRo0a5li1bJu6v1h0ffPCBe/bZZ93zzz/vvvrqK/fvf//btWvXzu2yyy4OIUgm AtVE4OCDD3YDBgzI6vIqq6zixo0bl5XWkBsff/yxa9GiRVaV5513nuvVq1dWWjk2OO7VVlutTtNv vfWWa926dZ10JYiACIiACIiAEZDAayS0FAEREAERSCSAhxyhE4qxZZZZxq244ooFF505c2bBZVSg vAReffVV17Zt27w6sdxyyzm8tuadt7r+Ffniiy/cb7/9ltcx+pnwDFtvvfUqxkPM71u1rpv3XVL/ p02blrSratOffvppt+uuu2b1/5ZbbnF82rdv75544gm34IILZu0v1QYvctIYc2/PP//8Ll9vzMmT JwfPhGL6y/PE99jmZdPnn3/u/vrrr4Kr415dd911S/Zs4ruNvvnfcTU1NQEnvDR5AYYh9E2dOjXr ZVmp+1YwrAYoECfkctyltDiv/7i0UvYhqe6kfpSaSVJ/lC4CIiACIlA9BKrrV1X1cFVPRUAERKDJ EJg0aZJbdtll63U877zzjmvVqlXOOhDAPvvssyDfGmuskTO/MlQWAYa85msMQZ01a1bJRJR8+1FI viuvvNKdccYZhRTJynvooYe6fv36ZaVpo3gC+++/f+Cx+v3334fDu5977jnHi4amaHjsRsXdRRdd 1P3yyy/B4Q4ZMsTtvffe7rHHHguE1VIyePjhh12XLl3ybgJv/aOOOsodccQRsd8n33zzjVt99dXz ri8uI3UwzB7r1q1bIHrH5csn7dhjj3U33XRTPlkLzrPHHns4hPo469OnjzvllFNc79693bnnnhuX xe25555u4MCBsfuqMZGXE8OGDQtCrRCaya7nUh4LI0juu+8+9/bbb7urr766lE0VXDejDh599NFg JMygQYPciy++WHAdKiACIiACIjB3EpDAO3eedx21CIiACORN4Ndff807b1JGhkPmI/DeeeedjmHV Sy65pNtkk02SqlN6FRA46KCD3FZbbRXbU7z6tt9++5KLULGN1yMxzVsxn2oZYitrOAKLLLKIO/DA A7MqxBOyKQq8eHtyT5nxsuCaa65xiy++uBsxYoTbdtttg12Ebrj//vsd+0tphXrG4vlOTHVecLzx xhvBM97v3yeffOJvFrXO5Jwm8PJSsT5GGIxS2ZQpUxKrNi/NNL7FjqZJbLTMO3ixywfj2i0leztU nhNdu3YNQh5UmsBLH/faay/rqgTekIRWREAEREAEchGQwJuLkPaLgAiIwFxOAE/aZ555JvAmee21 18JYeQzFx1ssycaOHRsIEOxPi8fql8dTeKeddvKTtF6lBHbffXe3zz77VGnv47vNJIAM3UagQRRA tMK6d+/uiBmZZJdffnnRIU6S6lT63EVg6NCh7ocffggOesMNN3Q33nhjGG93m222cffcc08oduN5 WmqBd99993XrrLOO++mnn9z5558feELSuVtvvdWtvPLKQT9toig8i5966qkgjREaxE1+6aWXssKV TJ8+PdjPHzyz/ZdDeHfi0YjhvUq8YbM333wzOHa2/Tpswi48nPEK9e2EE04IN21ST0vo0aNH4EFa Si9SXmS+/PLL7uijj7Zmg/OJB/N2220XpOHFu+aaazpesPr97du3b/ByLCyoFREQAREQAREQARH4 m4AEXl0KIiACIiACOQl07NgxyEMsXZsMhR+ixx9/fGJZJknDwyyXzZgxIysWIfmJ3di8efNcRXPu J1bqwgsvXCcfwgOGF88CCyyQtR9hgPiNGJ6mFg/Rz+TnSctnZaw9246rd/To0YFgiJfov/71L7f+ +usH/bMySUtCaCCa8IHZBhtsEIiQeDfKGpYA8aTNYxTBzQTeI4880v3jH/9IbAxxKs3rDm89wlWY zTfffFniF+l4cHKv+BZ3Hfn7WR8zZkwwEReiNGIRcUoZLr/22munhsewa9buEcJv4BWJlyTC3hZb bBHeO8RSxiuTPExchPd9dDZ6v/9cp9HYy7wEos1KmSQM1pxf7itms+dFF16GeIjGPROi3Bt6+447 7girJExIlBOi6KmnnhqIwAw7xwuylBPMcf4233zzoE933XVXKPAy4Vs0vA4CJeElOnToEOTHw5pR HRtvvHF4TCbIkkAIg86dO4f7eIabwEuIisMPPzzcR8xaxG3MF3htne+s6PfURRddFHAibm90H4Iv 4q6VDxtqwBXzWDWBl5dDxx13XFYLSyyxRCjS+y+IDjvssKx8cRvcax999JEbP358EMOX5wuTdnHf x03eFa3Dv1f9ZxH3BN9T1A07vmvMYzpaR65tnnf0qz7xoqmDWMYcJx+eh1x7PNuI+0zIDjzDeSEQ fd7k6h/18bzjmWbfqdH/FXLVwQsZrnOevXzwtqdvfFdE799cdcXt5/8U/74hT77/O1GW5zbP8y+/ /DIIm8J1Sf845zIREAEREIEqJZCRiYAIiIAIiECeBB5//PEMDrl8evbsmVrq3XffDfPefffdsXnP P//8MI/Va8shQ4bElklLnDlzZubWW2/N7LbbbpnlllsuqMk++EkAACAASURBVHvRRRfNdOzYMdO/ f/8M+7fZZpusNtu3bx9W2aFDh6x9W265ZbjPVqJ56G/Lli1td9Zy8uTJmVVWWSWrTvK3bds2zHf/ /fdnNtxwwzp56D8Mk+yhhx6Krdv47bLLLpkxY8YkFS9J+jPPPBMex8MPP9zgbUybNi1z3333ZXr1 6pXKpsEbjqmwU6dO4bF+/vnnMTnmJLVr1y7Iy3n27dlnn008h5xfs2OOOSZsy84vS66RH3/80bKF y6lTp2a6d+8e3gN+GVtfd911M3H3GGXXWmutrPa4XslvZa3t77//PnPyySdnpbOP+49zZTZgwIA6 eV5//fXMr7/+mrn44ouD+5P7lLLcL3vuuWfmhhtuyMyYMcOqyHt5ySWXhG29+uqreZezjOPHj88c dNBBYR3+MbNOP3nG8CxpLPvzzz+z+vPtt9/GNn3ccceF+Xr37h2bpxSJXbp0Cdv98ssvE5vo3Llz mO+WW27JyudfI4MGDcra17dv37DcnXfembWPvHaOqMPMnrutWrWypHBp3w0so0Z+uw6j+xp62/pN X9PMjoX8acZzaP/99w95WP3+ku/Czz77LLGaCy+8sE757777LnPFFVfUSade2vvpp58S6/N3fPTR R5njjz8+6zuYZ+Khhx6asXPOdyn1cp8lGc+Fm266qc5zyj9On9k111yTVFUGZlaOvr3//vvB97ml 2ZJrJe55GVfxzTffHPudbnVxbOTJ5/nWp0+fsH9++/CyZ6bVa0vOVZL98ccfmYsuuiis08r4y1NO OSXD94BMBERABESg+gik/6dQfcejHouACIiACJSQQJrAO3To0OAHl4m5/g8nX6zyuxcnltoPjX79 +vlZc66PHTs206ZNm9QfLq1bt47dj4DCjy1r21/6DUeFFj8fYlXUPv7449g6EdB+//33VCGJuo84 4oholZlx48Zl0rj5fWKdH4iNZb7A+8ADD2TefvvtDOcR0Q1RDFHvl19+Kao7gwcPrsMSMSaOe1EN FFgoTeBFIESoQBjBLK8v7JN+1VVX1TkmO3/+uY8KrpaHZZyImSQI++VsnfvWN+4j21ef5aWXXhpW i9gcrevMM89MFWjIz/kdPXp0WE8+K/UReO+4445E0STaf54laWJmPn3NNw+CrrWP0J5kjz76aJjv 2GOPTcrW4On5Crynnnpq2D9eDPh2++23h/ui12SawPvCCy+E5ajDzMQvXuhFLU3gtReAaQJjtL5i t+2cNoTA+9dff9V5CWP1R5ccGy9n4syeVX4ZY+mn+evcp2kvPPhuvfLKK8Pz5Jf110877bTwGNL4 5xKx/TpZ53mYZP7/KdFycdsvvfRSUlVBOi9s48rFpfGCO5clCbx8r8bVSRr3Y5yNGDEi5zPX6uQe id6HcXUqTQREQAREoLIIKERDlXpeq9siIAIiUGkEiLPIkOYnnngimAyI4aAMhWVYePv27WO7e9VV VwXhCGw4OBOsFTNjNENqmbTLHwZP7EWGizPE0iZtYeiybxdeeKFjNm0bkkisYYYP33DDDbEzeZPP Zt6mHmaStzajw+fZz9BOJhX66quvHKEXbDIXmDDBC6zMiEu52GKLuccffzxsmzANvjF0lqHLDIc3 oxwz0xOvkeGahMY455xzwnidDNvmXJCvMW2//faLbY7zQpxOjr8Q69WrV53s7777rnvooYdcPsOW 6xQuUQLnwMKYcN2ttNJKweRSDBXv0qVLVqsHH3xwcH8Q7sGfGIzh9v7xcs0RG9S/N4jRycSFXL9R Y8itGUOpd9tttyC2J8OzCTnAfWnXLUPDGXJtQ5i5Vvr37x+kXXHFFVZNMCSb64wh2hZP1XbSxkkn nRQMo+ecYMSIPeuss4J1Yhdz3gcPHhwep183mRimzrBl+mdGXRtttFEwzNomYbJ9Db1kcjJCbZjR 3wsuuMBtueWWbumllw5ikDMBFOEIMJ4lnM/hw4eHzw8r29DLiRMnhlUSpzXJCFdgZufXtsu9ZDi9 f41Hwzj4Q83jwuok9d8f6u6HObEYuoWGquEZXI3GkHv/3iE8B9+7xGfmWiZ+PrGSMdice+657rbb bqtzqMQr/uc//xl8z1l9xpK6+B4hrMKTTz7p+M7HuE/vvvvuxOdwt27d6rRFHGmu5Q8//DB8FvH/ QC4jdjHPQ7PevXs7woJwvIRVICYzzxuLV00+C7lkZXIt4cVzkWch/9MQIsOM5xzHGw1BY/sJC2FG PfSN+Qp4jv3444/u2muvDSZFJA//fzBxImERCjVC5ESN71wmW4x+z5CP58HOO+8c/m9BGt8hu+yy S/DsJdTTCy+8EF4j8CPeNd9h0Xs12q62RUAEREAEKohAZenN6o0IiIAIiEAlE/A9ePHaOeuss8KP DeHGA6hY871fCvHgZWileZ7g+XPPPfdkamtrw24wjD067BqvyCTzQyYk5SHdH3L8888/p2UN9hkj 6ytLhrN//fXXYVm8nRh+OXDgwAwew74RmsAva8Na/Tys//bbbxlCT1hemOD5W2rzPXit7aRlmldV tJ94pyXVc95550WzN8q27+nGEGO7F/yQBU888URefZk+fXoQlsCOkfM1cuTIsCye4KTZ/qTzbgXw Srv88sszeDfGedb98MMPWfXFDdmmnLXHctSoUVZ91nXPPoZeY5TxvY25Dn3Di9uvk3V4EcrEjDJ4 //r58KqMOw4r4y+L8eDFm9Hny72T5GkevcbxTi61cb6Nx3777ZfYnD9igOdzY1kuD95JkyZl/PAR HAtD4X3zQzREPaPTPHjJa2z8sDA2RN/3hLf20jx4yU99aZ7SVk99l9Zvrj2+s5I+/rWZ1uaLL74Y jNj44IMPYrPhkWltwiDN/OcYZQiZ4n+nsu5/7yZ97xNWwNpkSb4JEyZkNc1ID/87l3wcc5z54QWS Qi9w7/rX5IknnhhXVZAW9eDlWRP1bubZ5x9DWugj/g+gX4xaij7/aHDWrFlZI424ttMszoMXpv41 gUez/wyN1sez08IEcRyc+6Rj4H6y+4O8hKnKJ5REtE1ti4AIiIAIlIeAQjSUh7taFQEREIGqJOAL vP4PHn896YdePgdcjMDrD1+mH4QBSDKEOOtrJQi8iJP84MvHiJ1nfWcZjWEZrQNR2/8RyA/0Upsf dxmBiXiODGnlR/Rjjz1W50f8U089lXeXfOHQ58Cw03KYL/D6/fHX8xV46T8iti9KcO7efPPNIF6m /4PbF7Hqc9yIHtZXRMuo+QIvcTt984cHR+8j/x7zX1xQPirwEkczyXwxin7m+8KnGIHXF404nlzx J/38nKd87+GkY82V7gucCKVJRkgQO6e5BLykOopJ969b4icjkvIh3UIeWL9Yxh0Dzzeu7biQI/7x R2Pw0l9iWfNCjDrMeOmAYIq4HDW7n+IYIT5yrSGWl9p8Jvmu17dP/kvGtOvcF3jjRHL6wYsi63ec II4waEI7+XghmmSE2vGf8dxXcXbBBReEbRLHNslo+5BDDgnypj2HowKvhdWJ1us/1/xYuNF8+Wz7 oVR4MZhmUYGXZ6YxZ8kzNZe9/PLLWWWSXgBYPdH8/ss9y6OlCIiACIhAZRJQiIYK8qZWV0RABESg mggwpHqTTTYJu/zKK69kDf8Ld5R4hSGeZgwhZ0h1kvXp0yccYp2Up7HSe/bsGQzRzLc9CzNh+ZlN /qeffrLNOsuamppgeKjNPh8NT1GnQAMkbLzxxkF4AmZWJ2SGb8wc3qFDh2DYJ0P1Mc4XM3lbeAA/ f3SdsA4HHHBA1tDbQw89NDZEQbRsqbcZusys9xgzw9vQ5ULabd68ubv33nuDmeAJ8cCwaIbhMszX hkiTvs8+++RVLUNyb7/99mAmeEI2MJs7RjgFwh3A3ez777+31byWhHow22mnnWw1WC655JLh9tSp U8P16ArMjj766GhyuL3jjju6Y4891t18881BGkOzOd+lMD/kCeExCLeSdm917NjRnXfeeUFXODcM 4+b6LpUtsMACYdV+KIMw8e8VP0yMhZ2J5iEcDs+STAbNJ39r1qxZMAze70tc6cceeywuOUw788wz HcPqo0a9+V7b0bIMPY8aIQD4FGqEuSjVdVZoX4rJ/84777i+ffsGYU0IDcS1idn3tYVdII1h+PmE pNh7771ju7LssssGzxPq8eu1zGPHjg3DL5B2zTXX2K46S8JycK/zHZFmm222Wbib5wPhZQhTs/zy ywfHwnOYZxzHRTgVnoE8W/Mx2iakTpxtuummYfKECRPC9bgVQjDxrOZ74Ouvv3aff/558AznWb7O OusEIS6sXK66LB9LQhH5oVcIKcWzKJf53/08dznGtOcb943/vUNICkJgyERABERABCqfgATeyj9H 6qEIiIAIVCSBww8/PEugJNYrMWYRAhrTiAlqFheP1PaxRHwibik/WMpp/Ngm/l4hNnLkyKzs1FGI +T/yCilXSF6E2gMPPDCxCLEbEWotph/CACJAPvFVERL5MYwYh2iBqLPMMsskttWYOxASTOBD4J1/ /vmD5pPiNCb1DX7EbEacu/POO4NsJu4SLzONrdWJyEcMyltuucWSspYw5+NboWKfX5Y4075xjs3S 6t1jjz1yPivIYwJvqe5Z4nPycsrs4osvdnwKMUQmO/+FlMs3rx9bd/LkyYnFpkyZEu5LitV7xx13 BNdHmLGAleuvv94df/zxqSWIW4pYay8U/MyIgAhcsmwCiGlp1zffWfYcyC45Z4v4s7wAGzZs2JxE bw1h0BcH2ZV2f3pFg/ju/ra/zvdQ9Hli+/1rwIRF2xe3JFZtLttuu+0C4d7qJl4+n6jBFKGeGLet W7eO7o7dTrs2/e+aNG6I6yeffHLs+eIcRs9zIfGB/fPH8UWfvbEH5VwQl9j2jRgxouDvzejLZatL SxEQAREQgcojIIG38s6JeiQCIiACVUmAiVmwxvb0wFvGzBeXLC26zCdPtExDbyd516W1M27cuLTd Ofel/XjNWbgBMyA88UPehAh+qOcj8NIFXh4g4ucS8huwuwVXxbm1lwhMfGfGZH/+hFCWHl0iCuMd agKv7fe95S0tbolXtE3yxn6EgL322isQaRZffPFgsj9EBiZsyyUaxdUfTcNTvBjz2SSV90VKRAbE kIZ+gcTzo74c8FgvpeGdaJYkprHfF3+T+jR9+nSrquAl13AuY6ImXuDgaYyHIdee2RlnnOHw8C32 mrF6mtqS+zLtBQH7067R3377ze2www5ZXrQIr7wgYXJHvvO4bhD3/Inu8uVY7Pn6v//7v7CJpOsx zOBc8GLLJjbz0/11nmd4xnJsaS8t4cULCT6M3GFCsfpYPs8dJk3l+esbE1wywRreznjP483LfZF2 H/vlk9Y5PkY5vP7664HHclI+0vHkro/5z+H61KOyIiACIiACpScggbf0jNWCCIiACMwVBPCUYYgj wyMb09Zff/2wuVGjRrmuXbuG29GVmTNnBsOTo+nFbhfifVNsG1bO/5HFj+DLLrvMdqUu+WHKj+LN N988NV9j7jQPXtosZIhqY/axPm3xoxsxzMI2XHDBBYHHNp61zKKeZnjitWvXrk4WwjUg0KSJ23iz ++Jur1693Omnn541JNgqRkA+8sgjbbPRl/m8sPDz8FzJR2Qp9EAYys39YQIaoVMQZPIxPLURruzl Vj5lisnje/AidM+aNcvFeYf7w+RXXnnl2KYWWWSR2PR8Ev3wG7nyw2bPPfcMrke+GzAEsHvuuSfw qsxVXvvzJ8A97597RPTdd9899n7hXHAOGsP86yUtXIv1he9nCylhaXFLQgy89dZb7rXXXnPDhw93 hGn6+eefAwGV527UW5nRRYQy8P9XiKu3vmn//e9/wyo6deoUhIdA2I3ap59+WlRfrE7OrY1k4bh4 WcdLgCTjZZqJ4dSBp3c+xogSPJfTwl7lU4/yiIAIiIAINB4BCbyNx1otiYAIiECTJ9DY4i5A/TiL l19+uTvmmGPCEABR4FdeeWUo5ET3+dt+TFh+mCb9ePI9lPzypVhv0aJFWC1eh507dw63q23lk08+ Cbu87rrrhutpK4jp/Kh94IEHAjED8QgvLt+7Ma18Y+7Di9f30rYYr4gRaUYsXDzxTOQgVunEiRMD LzTKMcyZWLQMU44z9pkh5FicWEvzl/X1IPPrKmYdLzaGMqeZH8sYgbtUxhBuRBJs7bXXrrh7C6GM ZyvnDCEaD+y4YedPPfVUiMh/LoaJzrmjjjoquI7Shpn7+W2dZ2K+Q8KtDEvCitCvhx56KEju1q2b a9++vfNFaz+/1gsnMHTo0LAQIQJ4LiZZofG2k+rJJ92/Bnn25RrFYM/JtLrHjBkTjG7Ae5WwPUkv vHjZhfhpYQ0QOEsp8NKOPVPxnn7kkUcSY8tPmjQp7RAT9xEeBcH46aefdm3atAnCoPAs4HzzPE0a ncSoKrv/eJZU8/8OiXC0QwREQAREICDQuIESBV0EREAEREAEGpgAPyL9sBB4qPgTr9EcHm/EJD37 7LPzat0fTpok4uJJZ3EA86q0npl8cYUfkg8++GBeNRITFsEQBpVgcPN/yPvCdVr/8DhF4GTILZO0 IeQTdsJ+wKeVLfc+mxgrbXg8P/rx3DVPvO7du7sePXoEHr+nnXZaeAhMXmdiZJj494o/cQ4T3iUZ XtM33XRT0u5GSUe8ZVK5JGOyqCuuuCLc7U+uFCY20Iof/uKqq65yaefJbxLx3Q+L4O9ryHWGyPve gQg8UZs2bVog/Fi6HxrB0lgi1PK85Jj/v72zC9miaAPw4+eXdOJJgkfhgYEHHUQUgqCdCCEqHYT9 IYR1VqKQRCplhGZFKEKF9CNEpniQGpaCWgdWKEpUvkIW9EOEaImRlYpW2sa1cD/Ns+48P/m+un7f dcP77u7szOy9187MPnvPzD2D/FFP/+0Iauoso6QRDNS9/Pim+rrfm0AYFomZvieqKRnxmnaaVM8P 93GqC8+9W4cT76luiy6GbvgoZ/YK5Tu97zgfW0bhpyNV8fU+kpLmT9ubdhKn1+U+V61alQYNvH/d dde13nvvvXLhPBLj7oh7ZQR0naQzEvAXj5G8H8Gnd7oYZz9pjCMBCUhAAleWgAbeK8vfq0tAAhKQ wCUS4EOKj5YQDIgYMJjGuHTp0tb8+fPLY1bc7lcYxRfCNPcw0EUYH0iXexQMUyVTwwgj8dLFoUK3 2DINlBXrScf9pAaiiDOcWwzIfHRiRMgZk3E/ENO1uTajEPER2UvIr84lBUaDbdu29Ure+PMYCRmR Fh0GGK+fe+65Um+Me4w8TzsniAvrqqR+lllMqzpSDI4YB1kRvgmGcUZ3Pv300y2MHiGM1GYUIiOZ Qxi9unDhwjgc9m1ar2g/4I/BtE7wo7l58+bWtGnTyrI7bty4vg0mdfn1GzZv3rx2VBZorHZipfeA H9BwD9JOdAV3eH6pT+mtW7e2+FOGh0BqSMWYzkKLqeCjl4XI6CC7nMJzT987+MLlnVz15YyPWEbb RvvXTceol7T9pMl1wMIgnTEx0jM9Up/iO3fuLF1IVO/j4MGD5ahjXJVcquCChZHb0XGCWw7arbqR +XBKO8Hvvffe1nfffVerAu0vfppxdcVoX0Yjp25/ahMZKAEJSEACjSGgi4bGPAoVkYAEJNBMAnww MNqPafXpBxhTENPRa/iF7XchEwx9GKBOnDjRcdP40A3hPKP4UsGY++CDD3Z8rHAeH5gYENIFTpgW nE5ZJl6vBVziWkwhfvHFF8tDPtb4OJo7d24Lf52HDx/uMFZEGu6d0cT4PI1FaTDC7dq1q/3BHaMz GVFbZ7DCGMtCRLnFuDD6YdDEOMcHLqM5GbGM7+NY2Ihr8GzC517o1++oxIg/6JYPzDB682HPR+Wt t95aLh4ED54lLjTQO+TNN9+M3Z7bcFtQjYjvxcslGM3Xr19f3gN+dkOeeOKJrr6nq+U40n3yySfl 1FpGY6d1i493Rk+FD0tGqlV9p/LMMZZg2At/q+m0fcoB03lnz55dTmNm1C7TeOs4Unco16Tn458P +qGhoVCzfHZciynR/KXCKFzcmFDuq+V25cqVrVmzZpWr2adp0n183vLHwnQIixClZYQw9AsWaVpG 5aN3KmmnB50CqeGFeNRhOj5Styu0C+SFgQThGb/99tvlPbEAINemzaLzAhchVf1yI+dSvS51n0W4 qFO0RwjTsil31HsMzqkRpp+RkJeqD1P9X3vttXIUZSyYSJ50ROAjlXYpdSVC24BbFdoJhHYcAxxG x7vuuqtDHQxh1AkMkwjHIRj/45gRxRi+o+xEnHTL+2vt2rUt6m5IjPxkm7bD1CPKxr8dqRz599ri SoX3QgjtOXpgrMMgyjNlRCht/ffff9/RGcNofjovaftDmK7Ps0A2bdpUvvfmzJlTduxhyKN8VMss cSk/dP5RlsIFCmx37NhRthWRPyNveQfybsK3MsK7jQX1qK8h3ANuEHDDEUId5D6COe8ARuGiM+WE 3xV1o4rRl/x4hzzwwAORXccW9wS8c5ntQDz2MR5joKT+4rM8hPKYCu9D2pV0NgntI3Wdchp+tWk3 6UCOekcesKbdob2I9oVZPxhDo+MMnrSntL/ohC6pPqHLnj17yt9NsOA3BL9xMLLym4sykLZnkSa2 tE2wjs5P7gfO+OtnFHEY13EXRPsQMxXgRpvHuwNu6E1nIJ1bxIt7iOtUO7gj3K0EJCABCTSQQKFI QAISkIAEuhD44osvilar1dfft99+2yWnf06tWLGir/zqrnv//ff/k1Fl76uvviqmT59em/fcuXOL X375pbj++uvL8xMnTqyk7jzM5RM6jR8/vvY6n332WTujsWPH1saJPOq2O3fubKev2zl06FBx0003 DZTvnDlzih9++KEuu2EL477r7icXtmHDhoGuPXXq1Nr8v/nmm4HyuZTIDz/8cK0OuXushvPcUpk0 aVI2v+XLl7ejLlu2LBvv8ccfb8dj59lnn83GDX0ou4899lhtvC+//LI2nLSkQ/bv339RnO3bt5fn nnnmmYvO/frrr+W5V199tX3u+eefLyZPntw+Dt3SLdd79913y7TVf4cPH+6aNs2nuv/WW29Vsysu XLhQPPnkkwPliX4bN268KK+RCvj555+LW265pauOg9arf6vrmjVruupB2a7KsWPHiro28a+//uqI escdd3TNO32ed955Z0fa6gHtZRq/1/7Q0FA1i2E/7lbvFy1aVF7voYceyupNGUiFsjtjxoxs/Lhn 6hvvwTiO7W233dbObvbs2Redj3i7d+9ux6PsR3h1W22T9+3bV7Yd1XjV48WLF9fm+dNPP7WvC59q ul7Hr7/+ejt97HAvuXQzZ86MaEW3ch7PKiJ/9NFH2TzTa61cubI23p49e8qsPv/889rzH3zwQVyq 3PJOT/Ot7vN7J5XNmzfX1r9quvSY98u5c+fSbNyXgAQkIIEGE2AqhyIBCUhAAhLIEjhz5kzR7YM0 PgYwXvX7IfDhhx8O/KER11m7dm1W1zhx9uzZgg/1999/v8AQ9Oeff8ap9gdRnQGiHakoilOnThWP PvpoO35cn+2CBQsKjC1Vw9uNN95YnDx5sp3N/Pnza9OneaX7GJ+//vrrdvrczh9//FF+eNYZSyI/ dFm9enVx5MiRXDbDHr5jx46eRjsM5xjiBxXS3HfffW2ePL9XXnll0GwuKf6WLVva1w/Og2zp2Egl Z1CkHMAyhPpCh0T1Wjz/aofA+fPni3Xr1tXWL+IvXLiwLKPUiSlTpnTkiXGHspXrQJg3b16pEoaD 1MDDfpTbTz/9tOMcxqMw4KUG3nfeeaf4/fffi5dffrkg32hjyAs9MHBTx3JCu5TTs8opPSZ/jH45 ob24/fbbO7ik6dmnkwkDUdqu5PIb7vATJ04Uuc6OOkPWcF8/8sPI3639eeSRRyJqx/bAgQPtTjZY 3n333R3nOaCNrzLPHfd6H/z222/tspXLI8KpY8QfaVmyZEnt/VHvt27dWl6etiatY6Ej2zq2dKLk DKTc10svvVSWV+ppNV86ZUKoj+m1Yp80abt9zz331MajvvPurAp1mXoT+aVb6jEdObQTVd0o6xiw Q1L9OFeNn+aL0Xvv3r2RtGN7/PjxjnKYpqOTLASjanou9in78awiLluMtLx7I166peMiGFafFc/o 6NGjZVb8jqq2bZSNqsGW3znRbqbXYR8jdbS7qX4Yy7t1HpCW9o+OouiYS9O7LwEJSEACzSYwCvUa OLBYlSQgAQlIQALDToDp/CxQgjDlNHUJkbsYUzmZ5soCVrhQYKp0bgGVXB4jGc7USqbjMzWTKfJM t2S6aPjmG8lr5/LGTym+EeHL1HamxTOdFF+R6BcuLHLpu4UzdRf3BelCeN3i/7+eY1ow06eZbjt6 9Ohyym64crhSTJjaHO4D8EPJVPNUcHXQlLqFD0/cWeBvmynTuLugzOHLswk6Uq+Yvk2bhosCplo3 Qa/0ebp/+QngNon3AS40eNcxVb9J/pjxt41bBlxP4A4BtwGDvKtoI3CrwLsYdxAIbhTIj3f0Nddc U56bMGFCub38T6BVLnaGewXaDtx94A6B3w20w00R2jTeDZSV06dPl8+CdzN/4YajKbqqhwQkIAEJ 9E9AA2//rIwpAQlIQAJXOQF8vsZiRfjZrVuo6iq/RdWXQGMJ9DLwNlZxFZOABCQgAQlIQAISkEDD Cfyn4fqpngQkIAEJSGBYCDCalEVlQqZMmRK7biUgAQlIQAISkIAEJCABCUhAAlctgf9etZqruAQk IAEJSKCGwAsvvFCu7j1u3LhyOjUrQLOCeroKNslYAVuRgARGngDTqpkKPDQ01L7Y/v37y+nUEcAq 8rHKe4S5lYAEJCABCUhAAhKQgAT6I6CLhv44GUsCEpCABK4CAhhywy9fTt3x48e33njjjdbMmTNz UQyXgASGkcBTTz3VWrFiRc8cP/7449bkyZN7xjOCqR+y8wAAAzhJREFUBCQgAQlIQAISkIAEJNBJ QBcNnTw8koAEJCCBq5gAi0hNmjSp9g4IX7BgQbnAi8bdWkQGSmBECIwZM6avfFnQUJGABCQgAQlI QAISkIAEBifgCN7BmZlCAhKQgAQaTODChQulEffHH39ssWI3q2nfcMMNrWuvvbbBWquaBP53CeAm BZcMrNaeEzpnbr755taoUaNyUQyXgAQkIAEJSEACEpCABDIENPBmwBgsAQlIQAISkIAEJCABCUhA AhKQgAQkIAEJSKDpBHTR0PQnpH4SkIAEJCABCUhAAhKQgAQkIAEJSEACEpCABDIENPBmwBgsAQlI QAISkIAEJCABCUhAAhKQgAQkIAEJSKDpBDTwNv0JqZ8EJCABCUhAAhKQgAQkIAEJSEACEpCABCQg gQwBDbwZMAZLQAISkIAEJCABCUhAAhKQgAQkIAEJSEACEmg6AQ28TX9C6icBCUhAAhKQgAQkIAEJ SEACEpCABCQgAQlIIENAA28GjMESkIAEJCABCUhAAhKQgAQkIAEJSEACEpCABJpOQANv05+Q+klA AhKQgAQkIAEJSEACEpCABCQgAQlIQAISyBDQwJsBY7AEJCABCUhAAhKQgAQkIAEJSEACEpCABCQg gaYT0MDb9CekfhKQgAQkIAEJSEACEpCABCQgAQlIQAISkIAEMgQ08GbAGCwBCUhAAhKQgAQkIAEJ SEACEpCABCQgAQlIoOkENPA2/QmpnwQkIAEJSEACEpCABCQgAQlIQAISkIAEJCCBDAENvBkwBktA AhKQgAQkIAEJSEACEpCABCQgAQlIQAISaDoBDbxNf0LqJwEJSEACEpCABCQgAQlIQAISkIAEJCAB CUggQ0ADbwaMwRKQgAQkIAEJSEACEpCABCQgAQlIQAISkIAEmk5AA2/Tn5D6SUACEpCABCQgAQlI QAISkIAEJCABCUhAAhLIENDAmwFjsAQkIAEJSEACEpCABCQgAQlIQAISkIAEJCCBphPQwNv0J6R+ EpCABCQgAQlIQAISkIAEJCABCUhAAhKQgAQyBDTwZsAYLAEJSEACEpCABCQgAQlIQAISkIAEJCAB CUig6QT+BicxBrpf60GeAAAAAElFTkSuQmCC --00000000000015c61c0582e05f74-- From nobody Wed Feb 27 07:53:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E02130FE9 for ; Wed, 27 Feb 2019 07:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fvrL4yEo3C6B for ; Wed, 27 Feb 2019 07:53:33 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740130.outbound.protection.outlook.com [40.107.74.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746081200B3 for ; Wed, 27 Feb 2019 07:53:32 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=5+bMQhBxVQ3HT19dx4d/cvkT2J8BdcfE+RkiMDuOv9o=; b=XDD3qmKSUWYPsRlSchrA9q9bauU8VDCK3jAg+ppMLvhgsyswKKhEyjqSSlI+s+CxD9B7YPROKtXCsTSlwOPmte4EzaVQk/dJniTbnWu6xIzszOL2TDBhIW6jOzoFaLQkid9DueMftxTNPYuV0RM5k+QeXmM2XvrfQ+ze0WJ9qCE= Received: from CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.3; Wed, 27 Feb 2019 15:53:30 +0000 Received: from CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46]) by CY4PR21MB0854.namprd21.prod.outlook.com ([fe80::ccd2:aa1d:e646:fa46%3]) with mapi id 15.20.1686.004; Wed, 27 Feb 2019 15:53:30 +0000 From: Nick Banks To: =?utf-8?B?5YiY5b2m5qKF?= , "quic@ietf.org" Subject: RE: QUIC Example 0-RTT Handshake Thread-Topic: QUIC Example 0-RTT Handshake Thread-Index: AQHUzqKgDbFI6VBs9UqI0LoSDQkX0KXzy5ow Date: Wed, 27 Feb 2019 15:53:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-02-27T15:53:28.2453228Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=025af48c-589f-49e9-9f49-d26630f48c1b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [2001:4898:80e8:0:4da:f819:baff:9ac5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: faf5d9fb-4596-452b-7f83-08d69ccbb820 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(49563074)(7193020); SRVR:CY4PR21MB0504; x-ms-traffictypediagnostic: CY4PR21MB0504: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTRQUjIxTUIwNTA0OzIzOktSd1Q3OVFNVjZXT0dnSEJXVFVEeFdZNFh3?= =?utf-8?B?a2hhbEhWWkpINnVmY2gwN2JGUUkydCszL0NLcUJZVEgrSkRNSXBiNE5hVnlT?= =?utf-8?B?a3FWOUZSTTl5UlhMNnlrMUNvMExLRjI5bE9kYVZEWlFsNVZCTDFXbmNIbkx5?= =?utf-8?B?Wmc4YUtFdEdEajlKYW9JN3dneUcrMnlpNm5xSTdhZUd1RUN6bXBuUWl2WFN6?= =?utf-8?B?bndoblEvSnZaMlBBcVVKdmwrbHNEVWlOWGs0U3ZseXZ4R2EraUJOQWMzNE9z?= =?utf-8?B?eWdTcmNUOW5PaXVaYlR6TGo3M1hvdzdIWkM4NFdYM2RQZ1JuQlZJaUU1cDQz?= =?utf-8?B?bGlzNVBoNXBYdzF0YzBQUjFGWHNlaDdDdTE2WmV2Rkc5RUt3bW16YTA1MzV3?= =?utf-8?B?Mld2RWtnQlNuallDbEM0cjgxVFEwa1NrWUxJTXIrL2p1d2QzaW85cWhDOVBk?= =?utf-8?B?UjdoUkRlbFlSVkg1S0tseVhuTnV6cytoWmZLVk81ZzlvYlNXMTlZOUdSWWt2?= =?utf-8?B?VEhPckEvWmMzKysvT1A1Y1UxVG1ZbFhJNDAvZ3AxcFp0dW11a2Z1U0NIR3l5?= =?utf-8?B?LzR0R3p3VVlud3VDenJqa1dCSGtIem45RTRZcjFZeVl5ME1XQWFEOUUzWW5o?= =?utf-8?B?c1JQaW1DLzhIRjhLdGZXZTZnTmtEbWI3NzVTc21IZnowT0R4b1NlcGhFMDVq?= =?utf-8?B?OFBka1hBM3VqZXpTR2JnS2dWRVZRS2ZvSVNlcFNtNWdzMXEySE1CYTNIMkw5?= =?utf-8?B?NUpxN0E5ZU9TWDY2RFRocmtVZll2WWtkVFQ5MW1PYTZSdjM2T2pEQUNhakh6?= =?utf-8?B?YXhvaGZYdnY4aXV3RmtqbENuREp4S09pbWc3akJzc1dsSmZPM21paXlHeE45?= =?utf-8?B?QWs4YUFHc0xpSjdWdk9lTUF5MTNtbzl6LzVkTW9hQ2k2elBuSVYyb2pwbmxG?= =?utf-8?B?eW1LbDlNT0xWYU5rdUR2SzUrV1hFSWp1eTkzblowRzhQc0FNSkFXSk9kdVR3?= =?utf-8?B?cDdBY2Jma2U2L3R3S3dnWC9NV1NiLzlyNjdhN2pnc2xYOHZhR214d29ac3FU?= =?utf-8?B?ZkdwMnd1VnVvSlVqTTVVRTVydTMyQnJXK2t1VjVPSlhHeU9lK2ZDcFR0MXVn?= =?utf-8?B?MUtkdHRxejlvditRYmFJbGJ3dXVydXJqdEc4MG5OQlpOZ09UNEVCZ0FYeDBC?= =?utf-8?B?d2h2Y0d4akQzZzByZmZGN2NwY2pidklVOFdTc0IzM0VCSnZRSlNUQkswOW9m?= =?utf-8?B?WkZFY09LTkt1NTRydENPdnU0cDJNR3ZWV2pWbGR0UlQzSGtpWXM2RHRaTVpF?= =?utf-8?B?SXhxNXNrNERkakpsTUl5Y0NaeTdKV3JvNWJ2d2hUVlI2RGlyYmk5YWpvU1Vu?= =?utf-8?B?d2hQcTA1QWU3MVdSbnI3ZUlQSkgyZm9BSVh5TkxBbEZ4aG1wakJFa3ZSekhk?= =?utf-8?B?VXFaZ3BGc1drQlJPTW9TUmlWaXdab2hIV0EyVldXMVhHeHpVVDhacjVTNXoy?= =?utf-8?B?RGNEejVnbjdnNlJMVGJMRXZJWjN4WmczOXFrUWkwMno3NTFtQUVoRlNkM2RX?= =?utf-8?B?OFZMSzZHZStpUUdacGJWYnY2SWc1c3pSZjFnVmt0cEcrQnNabzlPU0l4SWhC?= =?utf-8?B?Qyt0anlHczhBekpvcWFaTWUvVkhrWUpiZjdQbDIzNFo4QXo1UVhzamFMb2Rr?= =?utf-8?B?Z2thVWluTWpIU0RyRjZoTXQxZ0tBd0ZIY1ZpWi9icU52VldZUmIrSkFscG9K?= =?utf-8?B?VXBsdUJWaU9tSmxHZ1djOVZXYmhGZTdmc1JuUXpmM2VEaFBsVGloUlh5dVF4?= =?utf-8?B?Tld0aUFIemU3dWJKZkRvdGZsaklVTno5Sm5RZVVrQjRkNHNUOEZiVGZ6a2Fx?= =?utf-8?B?SlVOYTA2N1VURmRrTW1QdFU0NzN4YlU1L01IVnhrUGZ0RWtTcitQT09KNm0x?= =?utf-8?B?UGdjYmVXOGF0YWRXTVFzN2hwTEEzcmZaSXd6NjRxUGtBTXFHYVg1djZZaW4z?= =?utf-8?B?Tk5vQ0RwMHFlckc1MTJ4cHRpZTladjVQNVc2dz09?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39860400002)(396003)(346002)(366004)(199004)(189003)(11346002)(105586002)(76176011)(476003)(486006)(8936002)(8676002)(6436002)(53936002)(733005)(81156014)(7696005)(81166006)(7736002)(446003)(10090500001)(316002)(256004)(2906002)(4744005)(86612001)(5660300002)(110136005)(22452003)(2501003)(86362001)(52536013)(99286004)(71200400001)(6346003)(6506007)(606006)(8990500004)(46003)(68736007)(102836004)(53546011)(10290500003)(25786009)(33656002)(790700001)(71190400001)(106356001)(99936001)(966005)(478600001)(74316002)(54896002)(6306002)(54556002)(9686003)(236005)(229853002)(55016002)(14454004)(6246003)(186003)(6116002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0854.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: P2sXwt8AV2nl4kC0Vi+6PjdRAOGTfzzpAeIV3fwrPnBbd/Tl7eaki/KcmByT41irJfBVzsqQ/435yLjPyT4kpbN1HLHW0zE1COVcaTnNXCj8g1724DqS5xBXWV1cIGS2OunfZoJC4ZCJiHvb8ColhyD1shBMDAp4T5FHmzLhiB7NR6BHNPZOifvWQlsdhj8ZBbM7feO0/oWZZOco7L+akrTKNX/laUeEwjbxojWtVUraENaezBBvORhHkzRtIdIgdAoV0xYglN1gMteKw0/jwiBgs49ITe7bP4/ApVMZU/ImvPXym3sc8hH25QKRoH6KbXd+Z0aqqclqwtp3Df6RqZq2e5GA/0126QP7rnt4NMHJ6c6q8PW1jObCpv2P16CtCFwTl7P0UpVFje1DLOi0xcCeYM2xjbfVWqM8QgciMHg= Content-Type: multipart/related; boundary="_004_CY4PR21MB0854C26DEDFDA2C253BF548BB3740CY4PR21MB0854namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: faf5d9fb-4596-452b-7f83-08d69ccbb820 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 15:53:29.9424 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 15:53:35 -0000 --_004_CY4PR21MB0854C26DEDFDA2C253BF548BB3740CY4PR21MB0854namp_ Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0854C26DEDFDA2C253BF548BB3740CY4PR21MB0854namp_" --_000_CY4PR21MB0854C26DEDFDA2C253BF548BB3740CY4PR21MB0854namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBoYXMgYWxyZWFkeSBiZWVuIGNvcnJlY3RlZCBpbiB0aGUgRWRpdG9y4oCZcyBjb3B5IG9m IHRoZSBkcmFmdDogaHR0cHM6Ly9xdWljd2cub3JnL2Jhc2UtZHJhZnRzL2RyYWZ0LWlldGYtcXVp Yy10cmFuc3BvcnQuaHRtbCNyZmMuc2VjdGlvbi43LjENCg0KQnV0LCBpdCBpcyBzdGlsbCB2YWxp ZCBmb3IgYSBzZW5kZXIgdG8gc2tpcCBwYWNrZXQgbnVtYmVycywgc28gdGhhdCBzZXF1ZW5jZSB3 YXMgc3RpbGwgdmFsaWQuDQoNClRoYW5rcywNCi0gTmljaw0KDQpGcm9tOiBRVUlDIDxxdWljLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiA/Pz8NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgMjcsIDIwMTkgNTo0NCBBTQ0KVG86IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFFVSUMgRXhh bXBsZSAwLVJUVCBIYW5kc2hha2UNCg0KSW4gZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0xOCwN CnNlY3Rpb24gNy4xLiBFeGFtcGxlIEhhbmRzaGFrZSBGbG93cw0KW2ltYWdlLnBuZ10NClNob3Vs ZCB0aGlzIDEtUlRUIHBhY2tldCBudW1iZXIgYmUgWzFdID8NCkJlY2F1c2UgdGhlIHByZXZpb3Vz IGNsaWVudCAwLVJUVCBwYWNrZXQgbnVtYmVyIGlzIDAuDQo= --_000_CY4PR21MB0854C26DEDFDA2C253BF548BB3740CY4PR21MB0854namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGhhcyBhbHJlYWR5IGJlZW4gY29ycmVjdGVkIGlu IHRoZSBFZGl0b3LigJlzIGNvcHkgb2YgdGhlIGRyYWZ0Og0KPGEgaHJlZj0iaHR0cHM6Ly9xdWlj d2cub3JnL2Jhc2UtZHJhZnRzL2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQuaHRtbCNyZmMuc2Vj dGlvbi43LjEiPg0KaHR0cHM6Ly9xdWljd2cub3JnL2Jhc2UtZHJhZnRzL2RyYWZ0LWlldGYtcXVp Yy10cmFuc3BvcnQuaHRtbCNyZmMuc2VjdGlvbi43LjE8L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJ1dCwgaXQgaXMgc3RpbGwgdmFsaWQgZm9yIGEgc2VuZGVyIHRvIHNraXAgcGFja2V0IG51 bWJlcnMsIHNvIHRoYXQgc2VxdWVuY2Ugd2FzIHN0aWxsIHZhbGlkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIE5p Y2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgJmx0O3F1aWMtYm91 bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCj8/Pzxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI3LCAyMDE5IDU6NDQgQU08YnI+DQo8Yj5Ubzo8L2I+ IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUVVJQyBFeGFtcGxlIDAtUlRUIEhh bmRzaGFrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiZu YnNwO2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMTgsJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWN0aW9uJm5ic3A7PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj43LjEuIEV4YW1wbGUgSGFuZHNoYWtlIEZsb3dzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp bWcgYm9yZGVyPSIwIiB3aWR0aD0iNTEyIiBoZWlnaHQ9IjI0MiIgc3R5bGU9IndpZHRoOjUuMzMz M2luO2hlaWdodDoyLjUyMDhpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6aW1hZ2UwMDEu cG5nQDAxRDRDRTcxLjg2NjZGRTMwIiBhbHQ9ImltYWdlLnBuZyI+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZCB0aGlzIDEt UlRUIHBhY2tldCBudW1iZXIgYmUgWzFdID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlY2F1c2UgdGhlIHByZXZpb3VzIGNsaWVudCAw LVJUVCBwYWNrZXQgbnVtYmVyIGlzIDAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0854C26DEDFDA2C253BF548BB3740CY4PR21MB0854namp_-- --_004_CY4PR21MB0854C26DEDFDA2C253BF548BB3740CY4PR21MB0854namp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=38844; creation-date="Wed, 27 Feb 2019 15:53:29 GMT"; modification-date="Wed, 27 Feb 2019 15:53:29 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAgAAAADyCAYAAAA7vX3BAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAJc8SURBVHhe 7d0DlCXJtgbg6B7btm3btm3dsW3b5h3buuOZO7bu2Lat7n75xUzUy845VecUuqcQe62zqrtOZmTE H1mx/43YMWi/QkKWjEBGICOQEcgIZAR6FAKD9qjR5sFmBDICGYGMQEYgIxARyAQgvwgZgYxARiAj kBHogQhkAtADJz0POSOQEcgIZAQyApkA5HcgI5ARyAhkBDICPRCBTAB64KTnIWcEMgIZgYxARiAT gPwOZAQyAhmBjEBGoAcikAlAD5z0POSMQEYgI5ARyAhkApDfgYxARiAjkBHICPRABDIB6IGTnoec EcgIZAQyAhmBTADyO5ARyAhkBDICGYEeiEAmAD1w0vOQMwIZgYxARiAjkAlAfgcyAhmBjEBGICPQ AxHoUALwzTffhBFHHLEJxp9++ikcf/zx4fvvvw/TTz99WHvttf8G8TPPPBPWX3/9cNttt4Vxxhmn B05BHnJGICOQEejZCHz++edh5JFHDoMMMkjPBmIgj75DCMBZZ50V/v3vfwcKf4ghhggzzDBD8Lve vXvHCX366afDLbfcUpMAmPRJJpkkDDpoh3Ql9O3bN6yzzjrh0EMPDRNPPPFAhjM/LiOQEcgIZAQa ReDBBx8M++yzT2A8Oph2tNFGCzfddFMYaqihGm0iX9cOBNqtdc8888yw++67hwsvvDBMNdVU8d+X XHJJOP3008OQQw4Z9thjjzDXXHOFvfba62/dfP7558N7770XDjzwwDDGGGP87fs77rgjvPTSS2Gy ySYLyyyzTPz+o48+Ci+88EL83ZNPPhl+++23sOqqq0biQfljkvfee29sd/TRR48kZOihh24HRPnW jEBGICOQEehoBCh9xtqOO+4Y1lhjjXDZZZeFXXbZJZKBRAAef/zx8Nhjj4VRRhklrLzyylGnkPvu uy+u/QsssEB46623AiIx88wzhzHHHDO8+OKL8ZrZZpst6oN33303/PHHH2HWWWeNBOPTTz8Nt956 a/j555/DIossEqaYYop4vXbom2mnnTbqoyuvvDI+j+4ZdthhO3r4naK9dhEAoFLehx9+eFh++eXj gE455ZRw4oknhl69ejUN8Icffqg52EceeSScd9554c033wyvv/56GGmkkeJ1v/76awwLvPrqq2H+ +ecPF1xwQTjnnHPCFVdcET744IOw1lprhT59+kRigQzcfPPN8eXxomy//fbh66+/Dttuu22cNN4F 3onBBhusUwCeO5ERyAhkBDICIfz444/hiy++iJ7ascYaK+y0005hscUWa9IDe++9d7j00kvD0ksv HV555ZVw3HHHRe+Aa6+//vq4rs8+++zhyy+/jGRAO9pYaqmlovH38MMPh5dffjl6nocbbrhw//33 h/fffz+SjRlnnDEMP/zw0VN8xBFHhPXWWy9eu+eee0ZPBM+00PXHH38cxhtvvDD33HN3yylrFwEA znfffRfmnHPOJnDGHnvscOSRRzYE1hZbbBGWXXbZyOJMYJLLL788XHPNNXHCTOobb7wR5ptvvnDx xReHjTfeOCyxxBIx3OAlkEOAoXkJMMBzzz03LLfccnFip5566sgkOyq80NCg8kUZgYxARiAjUBcB OV8HHHBAXNMpbNY7pT/ddNOFp556Khx22GHRs4wUUMaUvet5nU844YTwzjvvRCORNT/RRBNFXUSp H3zwwdFY9Lvxxx8/EgZ6YfLJJ49eAD8ZqcLTLPxNNtkkrLTSSlGPMFxXWGGFeD0jFEkZfPDB646l q17QLgLAwk5u95YAKHsDqtex5H3PVZ+EVS+ZEJHgPTABlD5WRtzjZSAmF7vjzuEmovSFA4QIJp10 0q46L7nfGYGMQEagWyNAuW622WZR0T766KPh7rvvjtY7a5+n17rPEOQBpqwZmpR3EkYji52iJ5Q/ 2WqrrWLy+XPPPRc/PMuMTJ5lRitvMNLBg+0ZK664Yvw3QSJ4nfWJDDPMMN16DtpFAAALrP333z8C TPGKr9x4441h3XXXbYrjALms4MuIJnZVTvpg9XPDXHTRRU2Tyr1P2ZMyoUjtptjQ77//HknDZ599 FnMS5AyIA0lMzJIRyAhkBDICnQMBIWBeYDF7VrePNf+1116LxhtDjyd3mmmmiR2WM1bWI/5dS68w Htdcc82w3377hU8++STmGBCKn85CJBAEQjcgHCnGz1vckzzG7SIAAOSOEaMxSRQu1w03y4YbbhgT KnbbbbeYkAdkVrzkivPPPz/G/HfeeeeY8MHFz20vWU+cx73XXnttjPGLvXDziN1ggt9++23cUSA5 BHuUc+CF4S04+uijo0vHi7TpppvG5I5nn302/v/UU0/tHG997kVGICOQEcgIxPVe4t1MM80UQ8F2 i1mzKWhKfPPNN486Y/HFF4+GHKIgmVyY2drPY0CPCA27f5tttmlCVTLhhBNOGD0Gq6++evw9snDs scdG/eK5PAZICLIhnOw7OWn01ZJLLhn7QL+NMMII3Xa22k0AJphggqiMr7vuujhJO+ywQ8ysJDIu JVdgXhSzOI5JZ8Gn70yKuA+rXThh1FFHjZ4DOwC0aaIWXHDBsOiii0by8OGHH8aEP9dqC/lAFMqT RNnzQvBGYIEpXNBtZzEPLCOQEcgIdDEEppxyyrhd3HrPWKSo7QpI1vhpp50Wd3gx4uaZZ55o7FHW QgcS+7jxhQF8quFeeumqq66KtWXKFj1C8dBDD4Xbb7898BYjErzYZN55542EgVeaPuLRTp7lLgZt w91tNwHwJHESLv+qUPIyLmuJeH5z37keSbDtoyomtFwwqJyAmK5NiRwNo5AvzAhkBDICGYGBigAd QAG3JAsvvHDwKQt9s8oqq9TtK/JQS4SYt9xyy799hWT0NOkQAtDTQMvjzQhkBDICGYGMQFdHIBOA rj6Duf8ZgYxARiAjkBFoAwKZALQBtHxLRiAjkBHICGQEujoCmQB09RnM/c8IZAQyAhmBjEAbEMgE oA2g5VsyAhmBjEBGICPQ1RHIBKCrz2Duf0YgI5ARyAhkBNqAQCYAbQAt35IRyAhkBDICGYGujkAm AF19BnP/MwIZgYxARiAj0AYEMgFoA2j5loxARiAjkBHICHR1BDIB6OozmPufEcgIZAQyAhmBNiCQ CUAbQMu3ZAQyAhmBjEBGoKsjkAlAV5/B3P+MQEYgI5ARyAi0AYFMANoAWr4lI5ARyAhkBDICXR2B TAC6+gzm/mcEMgIZgYxARqANCGQC0AbQ8i0ZgYxARiAjkBHo6ghkAtDVZzD3PyOQEcgIZAQyAm1A 4B8nAJ9++mm4+uqrw/rrrx+GG264hofQp0+fcO6554b55psvTDXVVA3d9/3334d33nknDDHEEGGc ccYJwwwzTEP3pYv++OOP8NNPP4Xhhx++VfflizMCGYGMQEYgI9DZEGg3AXjttdfCrbfeGoYccsgw 6KCDBkp21llnjYq5EXH/NttsE5Zaaqn+CMAnn3wS7rvvvrDmmmvWbOa3334L2223XTjllFMaJgBP Pvlk2GuvvcKbb74Z9t5777D99tv31/Z3330Xrr/++vDVV1+F1VdfPYw99thN3z/22GNh8803Dz/8 8EO8z7OTICOXXHJJ+OWXX8L8888fppxyykaGXveau+++O9x8881h8MEHj21qu2/fvuGee+4JvXv3 jn1BRpZddtkwxhhjhM8//zxce+21keDMNddccU5c26tXr7DccsuFW265JSAxP/74Y2xzuummC3PP PXfsh2e9+OKLcQ7dB4sRRhghrLjiimGkkUYKX3/9dTjzzDPD22+/HRZaaKG/zcsDDzwQnn/++TDp pJOGJZZYor+xGcMdd9wR59f3iy22WHz+TTfdFPuzwAILhJdeeik+A+beBWKebrzxxjDmmGOGlVZa KfYrS0YgI5ARyAh0DALtJgBffvlleOaZZwIF+dlnn4Wll146jD766LF3/fr1i8qHfPPNN2HEEUf8 W69nmWWW8Oqrr4YJJ5ywv+8++uijsOeeezZLACgQCoclX0v0Zdhhhw1DDz1009cLLrhguPfee8MG G2wQPv7447/dhiBstNFGUblTTEmQjQ033DCSgkUXXTQqqHnmmSfoexLK+JBDDgkrrLBCOP3009s9 OwcccEA4+eSTw2abbRaQoaOOOiocd9xx8fknnnhi+Pbbb8PKK68cnn322XDEEUc0kYITTjghvPLK K+GJJ56I+G+88cZhkUUWiUrXtccff3xYeOGFI3HYf//9o+flyCOPjGOGJQL33HPPhVVXXTWSifHH Hz+OE6GYYIIJwmyzzRZ23333cOedd0YPTJKtt9464r3rrrv2N/YddtghXHPNNRHz119/PRx22GGR LCGI2hl11FHDzDPPHPt28MEHR4KWCADcvRs77bRTJCdTTz11u3HNDWQEMgIZgYzAnwi0mwBQDD4U y6OPPhouvvjiJmwpA5bhWGONFd54442odK644oow3njjxWsotMsuuywqnksvvbRJWbNUKRekYdtt t40kgsJdY4014n08A5QHK/iMM84IM8wwQ9Mz//vf/0aPAmuRRU55UOpEO37P9e/eqvz+++9hkkkm iWMpy//+97+A6Oy2227xXhYrpZYIwCCDDBK22mqrOFZtVOU///lPtL7XXXfdMOecc9Z9955++ulw 6KGHhgcffDDMMccc8XqhB8qZ1b7OOuuEDz74IBIEos9XXnll2HnnncNdd90Vr0GQWPrCI6xoRAje CJCfMNM+ZUt5GwPMX3jhhXDssceGCy+8MLz//vtxDo4++ug47ttvvz0+b5NNNgmTTTZZJGeIBUE2 kAmWehLeh9NOOy22Ofnkk8dfa884vAOICSKAVPjAVBtJ9F1fhYh4WbJkBDICGYGMQMch0G4CkLry 66+/9mc1+/3aa68dlcmWW24ZWLSsaJZsUlwUOkVAAbGgk7WelDSlxP1MuZTj9TPNNFN0/bOAuYnL BIC7mDKmPB555JHo6mfNlvMLuNFrCYLgO31hzSZ57733oos99W/iiSeOrvCqUP61iAXLVl8osUYI wG233RYVbFL+nnP22Wc34QsPSpVi5ymhVBMGyNQuu+wS1ltvvdgXXpTUb3NkfFztP//8c/SgIApC Bssss0zEmOs/KdvFF188jpv73twlmWiiicLss88evQCJAHgWklIW4ZR55523Sfn7DuFLGHn2RRdd FN59992IuRBGVdHrK0mepI579XNLGYGMQEagZyPQYQSgFoxcxtNOO23Yd999oxeAwmfdJqGsxLWr oQGW4SijjBLdwgcddNDfmhabZjHWcv+//PLL0WKk6ChKSo9yaU2CYfWBiEhZMWnX7xqVs846Kwgv UKiNCEVKOZbFmJNQ2IgPcnX//fdHK1toIAlPhXg9fBCBJBSvvvOQwJwlLlyBNB1++OHxMni5hiAP hBIeaqih+usPUuHaliTlGpSvGXnkkZv+6zmIlpCRMaX+NYJRviYjkBHICGQE2odAhxEAVvtggw3W X28s6Bb2pCwptWrmvaQz11Uz68W46ykYVmHZUrejgAuZ8uOeRja4uMt5ADqoH61JKGPxa1ufKE7x aIlwjQovBgVeVerN3c9LIFbOzT/uuOPGyxAQlj5iJDbO1X7qqadG7wb3Py9LEpiK81d3R5gf34mz S/4Tf6/2CVauKcs000wTvQCbbrppU19gWyYXtcaC3P3rX/+KuCUCw0uCkMFEnsUqq6wSPTbkhhtu aBWxahT/fF1GICOQEcgI/B2BdhMA2+rEvsWeJXldcMEFYfrppw/c9OLxlKWfMtVZq7L+JbWxKGWB f/jhh+Gtt96KSpt1uOSSS4bRRhstKj4uYTFgykPuAIUj/s21zFUt2U2imoQ+7nIKjfi9RLPzzjsv tuF6xECyoni+BDk5CTwUYtNyGFoSyWdTTDFFkNBG8WtH7kGjos8woKRZ6/UEaeEFkWuw3377RUUp 8Y8bHrERx4ehzHneBQmUkgWPOeaYSGyMV1KmGD7lLTGTR+Sqq66K+Os/IlHe5cAaN4fuNWdc89z7 vAPCKMYtyRFWcgJ4F1ZbbbUWh8Ljo9/CAHvssUdU/P7PQ4HASDZEapZffvnw1FNPxXl7+OGHO2wX RT2c8/cZgYxARqAnI9BuAiA+TrGwLrn7k/sdAZDBTflQ8KxAyolVSmFT9ixXQgHYhka49hEAiW2U mw/rl+KhhPzbtjKKnZKkCD2TB4FSOf/886OCQkooKGREshsCIOaNMLDoKTz3ccuXCQCvAq9FWXgo EAquc/2RLIcQVIWnI7nPy99RzizetdZaq6F3TTusYcof0dAnyhSBkGgpnGG8FChyIhdAbsUXX3wR sTNGOFP6EhARCpY3Kx7Bkj8gzGBXRDm2jgBQ0hIuzam8AgRAvN9WT14JiYByABCEsmfFuKseoLQN EYGQ92FcvAgIEQKGnJhP+RRImfeAp6Us5iLH/xt6bfJFGYGMQEagVQi0mwBw8/rUEpn6ZWHFl4Xi akko8FpWJsu+OZEY6FNLWNDlZLbqNZSRGgAsa/vuy0SA0pPJX0soP8l4vBnVWLnrKTyf1gjlyqKv ChJUDT9Q5D5Jqjj7PWXcEm6UrO2AzQlvhE9zYscFRW63BO9CEiEToYqqICgIWJJadSOQFHPBS9Bc 4mZrMM3XZgQyAhmBjMD/I9BuAtCdwKTkWfZc1CeddFJNK7/WeBEHe/FZz40WQOpOuBmLEI8wh7BK tcBSW8cqXGP3CA9Nqi3R1rbyfRmBjEBGICPQPwKZAJTwYPWLQYu5VxPhWnpxXKsAT2t2BnS3F1Gu Rkdb6UIPwhatmYvuhmseT0YgI5ARGFAIZAJQA9m2KJyerPwThLVqILTnxRWWaMtctOeZ+d6MQEYg I9BTEMgEoKfMdCccp9yJxx9/PCZlyp9QdEi9iAEpElB9FKCyg8W5FTnJcEAintvOCGQEOisCHUIA LKTivjL9bRWz7aslsfDbisZlLNHLAiz+nva8KzxjB4E6APb5i61LyJM45qfYsCIzsuHdz/K0a0DG OtEPW8pkvosfl61zuwMUJrK10Ja08hkE2rR9TuKaDPXqboC2TqJMfFsk5RfI0lf73jZGRYskzxmj Z8uiF4YwXkmF8PG9e+ywILLk7apgGRs7LPXTITuuc5/vJSPCk1Il2pf9T8Gq70/sGpC4B3tbKD0P 7nZW6EdZGascqLSzgkYy+VNNgLZi4j59d9iQgkZyLuzUSDUB2tNuS/fa5igp0Q4LuR7mpbx7QX0D mMMz5x0MqFnI7WYEMgKdAYF2EwAJcLaoUc6Ky6QDasp7zKsDtfDbSnfOOedEZSjjncJW9U+dednv atGz0hAFWwptN0QyKCvFZWx/o4ySwlQHwNY0orqdmLy+qNefMvNZfgrnqJkvu9wOA9vqEkGQwW7b nfoEFEX1VLvWThgCQlHarkf5H3jggTEbn7Wr7oEzB1i/9sDbcqd/9vlLJHSID1wQEUQBqUq1+m0r 1NcZZ5wxjs33ttDZaseido4AbIzd/xEkyt48pQN2kCdbNClApYcRAFsr0yFHtu6VCQDl/9BDD8VD g9RDkOyXygC3Fpd0vX4hW56NkA2MY5aRLVsybUP17OrWRWTNe2kOvIPtEVs57bxI9SPa01a+NyOQ EcgIdDQC7SYALCYWpyI/LFFb0OxDt2e+ObHwU1YWWzXuWbcWWwslAsAqpeQoHYpRzXlWoprxxL52 yp5y9JMCLB/gQ9khBNWiOw6b4SVg+bHykAnKV7IZYRmrTUC5KZNbFfvkFdepni3Q3Djtbdcej4SK e5QyxUoU5HFWArKjGJEtkerkG6vteCr5sUJ5VCh7hMqJemofIEL249ubz+J3ABOSQVjUPCiIDBzS 3n9jclIhS1tdBIRN/yjxdOYAwuKDQHl2Eh4J/VPkyRZEpMI17SUA2mf1G785HRin/XmGUx0RL1UI q2J+4Oadaq/AFcHcYostIplysJV3J0tGICOQEegMCLSbACjowtWc3OWUMuu6nsi0Z3lzObN0VZ9j mRHtcenzFHB1+0kh+bc95klRpAQx1zs8J0lzBXlS8RnXscQtyp6fCEC6H0GpJrTZi54UHku1lvKo jpn7HS6IzXLLLReJTjpRDxFJpyKmMVJKSAlhmXLFC6/ARn9SGWVWbDoLgKeCstd+Eicr2pbIe4IE Kf5DuPHVbGDxIwz29ZfDHCnpDjkqC8+E8EAiBUhZe63j1H46bwBGA0N4RdIpjkJBtSS9d+3tTzpj AalQWMkBVgifMSNjWTICGYGMwD+JQLsJAIuxnKlN+aYjcVmf3OkpycrCSsnvs88+TYrdmfSsWGIf OWH1UoBq4buH8uUaF25IbXFl+451LfQglFBPkI6yy1db1eN7a1Xy0y7lS6nqk+c1IkgMDOxlZ7Wz LLn2VSoUg4YV6z6N0V76dGAQUkS5c7sLj1Dy6STBdMiRfIDPPvsshhfSHCA58hgQB+PlUUAkKCOe AWEPBMFzFWqqpcirGMAdAUihkkRYGsGgK17T3DtQaywKR3kvkKvye65sdSKWCJt3xt+CjznKkhHI CGQE/mkE2k0AWLEsxCRc5NzXRKybC7S8MFJElAmLliJRYpeCKlfvSwfUsNJdl35WrfJ02JBnNXLQ Djc665dY5CnElBBXbyIQB6V4Kc5GM9W5yil9rnrPu+eee2JeAbe3EsWkPMZyGWIKRRjEUcnKI6dj cd1DIcuLUP538803j+3yCOifEIzERlUL4aOvQgSOCJZUyYoXejBn2lDauJ5ILqT8zRMMhWiq8Xr9 FQ5KCZT12mz0e54K+QHlZM10L++Nd6l66JHvESDksHxUdKPPbM11MBVKESYxf4k88LqYJ+c2SDZF 4lj95qnRd641/cjXZgQyAhmB1iLQbgJAOVE0YsKscNanojBko402ip9aIkzAgrUwSk5znUXTgikm LCEtKVA/bddKWdk8AmLorqF0uNrTDoKWAOAmZ60hJRSLxTtZ1fWAkxNA0fBWUK4S6OoJLCTNGZOk MkqSJyGdYIgcOJ/AT0qEOx5B8n8KjAIR8pDnkE73047EPUrYbght8RTwBDgLgcufZe+5hLeFx2GZ ZZaJ+QvwchogYf37nU8KR9QaUwq7aOfggw+OuQA8N2VR1hex4e7mwekI4RFS4ljCojyTdNiTtil/ CaBEiKScP+D9EH+HCQ9MR+QqNDceBMv81hK5MNz9vFcSC9OOjI7AJreREcgIZATai0C7CQAFJKN9 p512itaPTP56VhfFxnql7BAHyk3WPoXmwBkH+qTYNutTrJY1LPufSDikiIQTKDwKzHPLUmtv93TT TRfd8ZLpfG9RLh8n7H6/r3UvCxgJoXgbteDkJVBaEiJZzKxE4xTrJzwDkvKM0bgpULFwioNrmSKT eIhsUOSuYfE7OAmGdhjoK2LhGZSw8fACIAPCG7wDrHLz4x5tU0gUF5z1S3JkOQZfq6iREASiJsmQ F0MooyxIEY9OmqP2vpjuhx1PCeu/eqSzfnOxe2aZGLjP7xBT4ZpG56rc344qaOS9lmRafcc6Apvc RkYgI5ARaC8C7SYAOiCD2zY1FnV1Ma7VQQrGljY/uXCT0mXxUVKEcqNkXFOO/fuOJU8pWuhrlZ8V +5bI5r6qMqMIKVrWNsuyKnILKNTUj/Q9BWRbV2tExrxscuEJngNWdkrk00463rg6RmOn6MuxaITH NkJY8ZZQUsaZEtaS+xkR0Hff+526BwlnvyvjjVyk3+mP78xhNQnQd5ITeU54baohEPUIrrvuutiv RjwxjWIooTTtbqjeow88LLWEwnViZFsEnubfe9BeQbyyZAQyAhmBzopAhxAAg6NMaynU5gaeFHPV 2kq/p7zSv6tKvFwitpa1xsKWW2BLIctVnL0szZEUbncxd5ZzR7hrkYyUZV9rj3tzY0xjqnoiqr+v lslN15fxquJcxiv9O/1EcsYZZ5yYS8DbYMthWVJOQXVOEZF11103bq/s6sLbJFGvkV0eXX2suf8Z gYxAz0agwwhAZ4KR9cxLwKJtTTU/CW4StljpHUEAOhMmjfRFrJ9VLQeh0URH7SI3PDrdQZAfxLE1 4+8O485jyAhkBHoeAt2SAMjYb0vsl6u+XACn570OIVbI8+mpwgOSJSOQEcgI9AQEuiUB6AkTl8eY EcgIZAQyAhmB9iCQCUB70Mv3ZgQyAhmBjEBGoIsikAlAF5243O2MQEYgI5ARyAi0B4FMANqDXr43 I5ARyAhkBDICXRSBTAC66MTlbmcEMgIZgYxARqA9CGQC0B708r0ZgYxARiAjkBHooghkAtBFJy53 OyOQEcgIZAQyAu1BIBOA9qCX780IZAQyAhmBjEAXRSATgC46cbnbGYGMQEYgI5ARaA8CmQC0B718 b0YgI5ARyAhkBLooApkAdNGJy93OCGQEMgIZgYxAexDIBKA96OV7MwIZgYxARiAj0EURyASgi05c 7nZGICOQEcgIZATag0AmAO1BL9+bEcgIZAQyAhmBLopAJgBddOJytzMCAxuBvn37hkUXXTSsu+66 YeONN27V44866qjw0EMPhRtuuKGh+/74449w/PHHh88//zxMNdVUYcMNNwy9evVq6F4Xvfvuu+HG G28M8847b5hpppkavq+9F37zzTdhxBFHbG8zHXL/d999F4YZZpgwyCCDtKo995Hhhx8+9OvXr1W4 t+pBDV78448/xjEMOeSQDd5R/7Krr746/PDDD/FdHnTQnqsGe+7I678j+YqMQLdC4Ouvv46KlJKy oPbp0ydMMskk4fTTTw9DDDFE3bH27t07TDTRRDUV3Kabbhq22WabMOOMM9ZsZ6yxxgrjjDNO3Wek Cyh7C/Prr78errzyyrD22mv/rY+77757ePrpp8Oyyy4btt9++6a23bPYYouFCSecMBx66KHhkksu CYssskjT99ddd10444wzwmijjRbOPffchsZer+NnnXVW+Pe//x1++umn2N4ss8wSjjzyyLD11luH Dz74II6FMp1gggkCMjTKKKOE3XbbLTz88MNh1llnjf3cbrvtwssvvxz222+/OEf6CAe4DzbYYJF0 rb766uG+++4LBx54YOyS77WLnC233HJhl112CR9//HF87ltvvRWf676tttqqaQiPPvpo2GeffaKC N/djjDFG/O6XX34JMH3wwQdjez577rlnWHPNNeP9L7zwQlhooYXCzDPPHMmZts8888z4DiFsO+64 Y3jppZfiO7beeuvVgyx+r91XX301/P777+GII44Ic889d9N9X3zxRdhhhx3i97/99lvs77777hvG HHPM+Hv9W3XVVWM/YD/11FPH+YTXM888E3bdddcw1FBDhVNPPTWMP/74Te3uvPPO4frrr4/teRd8 3EPMH+zee++9+E4tv/zyDY2jq16UCUBXnbnc74xAKxEYdthhw0477RRefPHFsNdee8XFn5KkXCx4 FtrJJpssPPLII1GxpMXVYyzGFMNGG23Un0VtEf7+++/jd0suuWSYdNJJ470sT+L7e++9NyAAnlkV z3Tvzz//HL0LU045ZbwEQaFQllpqqaj8tVMVxGC11VYLa6yxRn9fHXbYYWH66aePHgDKlBJ7/PHH m65ZYIEFAjJE+Zx88sl/IwCUL8XRCCnSKOVP8V588cXRW0Gx+7e29Z0CpaBgQnFvscUWgQW60kor RUU6xxxzxO8+++yzwNqdYYYZ4ni18dFHH0XF+NRTT0VrdbzxxgvPPvtsVJiU4frrrx/H+M4774Tb b789YoYQUZKXX355nNN11lknmHvXkueeey688sor4bbbbgsjjzxyEy5HH310bOOWW26JZGDppZcO jz32WOy/cV1zzTVNhOG0006LxGPsscdumi/vlmdot1ECsPnmm4dtt902vgOeTxkTCt/zeVMuuOCC iA0Sd//994c99tgjvqf+be633HLL8OGHH0ZilbxEiAic7rrrriaCo12kCEnwPiAucLrzzjvDEkss EZ/Ly+A9XWWVVaLHKhOAVi4y+fKMQEagcyJA0VN+rHhW0corr9yk5N5444246LGmZp999mhB3X33 3eHss8+Og7HAsvb++9//RmWWlC6r0CKOQLAqjzvuuGjdXnbZZVHp8DJce+21UamwiimRJIgDa2vo oYcOo48+elR0lDYLM0lyR9dClJJm9VnEy6JP2iWs4osuuiha1Mk1T+nxVIwwwgh/a5ZioEBZjIjL cMMN1+JksnwPPvjgaMEnZUE5nnDCCU1Y8nxoc/DBB48W/oknnhiV51xzzRVce9JJJ0WlTFkLkSBL ROhipJFGCosvvnj83HrrrbFP5lH/KS0eBYqSYnvttdfi/Lz55pvhgQceiLgiVAgQbBMBQK48Y9pp p+1vbEiE3/MImDvvwJdffhmv8TyYeHdYy5NPPnkcnzkgFK/vEMrWuNQRC+/ITTfdFD1IMJhiiini +wIrxBMRM8+IljHpm9CO784///wYJkKQkidDf/TBe1H1SJlf75r+E+8kj0oiAMaGXCBarRlH5/yL r9+r7AGoj1G+IiPQrRBgZbIwxUCTlbvwwguH+eefPypvFhfrihXnWtYpq/Q///lPtMjdl4SCoWCR BxbgfPPNFxVd8gBQVsiG+5N1l+6lXPfff//oNqZAWGI+ZQLQEvDuYSmWxbh+/fXXqDiJZ7gOkSjH 5l1TS1i+xtfc99V7uNu5jcuua0qU+59ox7NXXHHFiDklzXJPlupmm20Wrrjiioi9EACFmIQycj13 NWUs3HHIIYdERWxekA8f1jGycMABB0TSNu6440ZFmYSHATFLc+nZtTwq+mUep5tuuogbYsG7QJAG Ctl7wko2Z5tsssnfINQfc96o8HIYJ4KECCGZ+mqs+lH2wpSf5x1DGpBL4YCy8k/PTmGM5N73+2+/ /baJtKT3AzmsClLSmpyTRsfb2a7LBKCzzUjuT0ZgACOQFrbqAscqnXPOOePTWa2UCAWblHlZMaV/ W4hZTK7lUvWpJdouL8SusYBzWbOELeCUDAVSlub62hxEnkFppEWd0vPsepZ8ao8iFrPnHWgkeY41 mpRwc+PWH96BSy+9NJKjagIlBeZ3wghloWglM1KSyAvvCA9OkkRSPJ9Xw0d8v0zQXAsLStmzWxJz KCcB2eA+F0p5//33Yw6FZ0088cTx38aDLMC2vcIjhOQgFrxQPggAK/2TTz5ptnlEjbcBaZBzwKIX Cqgn4v7uTcILZVw9VTIB6Kkzn8fdYxGwgFOs1azqlFAGmKSsq3Fw11QtPApWTF28mnDJCglwrybh Tq0SAIs3wsGDQLi3q9JcX1uaPC7km2++OWywwQYxps0bkDwC9SadK51CZsVz1dfLPNcuAsP6liDn ehY5q12+BBc5vP71r39FRYVYCRfsvffeTV2h7Fj11ZAERS7uTenWkoRNeY6ECvQfWUghCXkG+lbP Mmf9s8QlApoXxIGLnSR3fyJ4Eigb9ZI0hzllL2FT2MI7hIBwxfM0yT/hERFugiMRz0d25Jqw7s2z f59zzjkx10KCJA9WS+KdTO8nzJ9//vkYeuipkglAT535PO4ehwD3Jyvp7bffju5c7nxxYC56SVjc 7+LAkr7EsCWKUR6SoiySFmyxZTFmVqkFl+WKFKywwgox65qVy31L4Vx44YVReVHw7kEQLNgWXvFc 98vIprT07dNPP42LuX5xY8stkHvAGpUgyMI95ZRTonXYkkgScz2FhlQkJdbIhMOFZ4IyEjevRwC0 yW29zDLLRCy58FnQs802W0y+S1nuxippET4wgBlc4UzJUURw4HIX34ad/AvWKqUsebBMqMyVMANs hBE8iweBgj722GMj+dEn8wnbY445pu7wub1hJ0mUpay/2iJ2JIifC0EIKegzUmD+yhn2dR/y1wXC IvrsnRIaggVseByEnsyD8XvvvGsUvtwO8w8r3gneEYmWkgjhzTsidFVObKz2h6fAXJiDUUcdNUwz zTRN8f9G+96drssEoDvNZh5LRqAFBCgzyXsyyLn1WZjJNW4RF09libFaZdenRZKyYk2yCFllwgI+ 5Xi1DGxuXIuyLPgUExf7pyhYqSxQz6RcCMXluVzAlIqENi5syVv6RUHwGuiP+9zP5Z6EUijHutPv KeJ77rknJpLZysWtXxXtG2tVWKAsTSSjUa+BflOOFBnCAiPbEPWPMqOMPYuC1T6LNyWYwQkGxsgd rS0ipo8MGT9Xe3ULpd0WCJK8CzsoEKYklCavBPKDiJnzKm61whvc+pL+jAHx4EWREEo8yy4EoQjY nHfeeZHEpLlMzxZmqJVfUMXZdfI/yp4o79NVV10V74ePraXeC3Opv54p0VD/7BjwPiQyKOlU+CIR thRyqnqd9MPuF6QQrrwLtTwjftfIOLr6gpMJQFefwdz/jECDCFDCLPVaQgmVLTlWaFlSlnRLj0IY qkIZV7PNq+2W2y73DwlpSSzQrERuX16Dssga96klTzzxRLS8KdyqgqB4yjUDGoQ2EhGEpSzaZoVX pUxIKNikZMvXSYDzaU4oQp/mhLeg7DEoX2eMPAc8HDxCKfRQxbB8Tzn3wO+ruR7mgoK+4447YvJg PaGoq9chPdWiTbVwQIaqhAgRkGiZBGGQqGiHBi9MOTSAdKSwQrWfwhreKZ6ugVlAqh5eA+r7TAAG FLK53YxARmCAIiCHQM0ClnVrhLKiwOwHbzQ5sDXtd/ZrhRoOP/zw6AnqSIEr74OQxT8tSFba+VDL 09NS/1wvFKJOQ3eXTAC6+wzn8WUEuikCPAeNeCaqw+dW9umpwnoWu+9I4e0QJugsYleJZMjWCi+Z nIKeIpkA9JSZzuPMCGQEMgIZgYxACYFMAPLrkBHoQARUa+OSXnDBBVt0L0tAskWNK1qiXGtEUpTi M55RTu5qTRvNXSu578knn4zZ0bUq5XXEM3IbGYGMQOdAIBOAzjEPuRcDAQExYxnnkt1UrLPVSkKU JKFyRnt7umJ7lq1JlHSt7PPUtixrW76UHLXvuTUiu9t2LIlK1WS9RtpJtdBlitubnsT+aNn+MsHh IqvdXuskErzUsFc4xZa/RgrluBcWtv3ZH+9eyVXK0to7Lw6NzHAhS1rjRpakZYubLWG2bckGl7Dm ftXg/B7OrnO/BC/jUJVQgp8tajLjxfdT20oC+8BdYpjdBu6TRZ+KH+mrLWYp+97WOyRIbQC7HGSG p+I3xi7DHl7pjINUdEi/JK/ZgdCeanKSFM2zbYWInkx/uNsOZ6siSUVt7CLwPOVxbZvzXAltku1g 48AhuzjUIHCNpEVEFeEzx9qtlTHfyPvkGtv5zBGs1FCwm8G8ybjXR4RSLQSZ/94vW/WUjq5XnKjW 8z3LtsbyfOi7efTMVCHQGFNlSOcv2F3ivdI3tQ6UALZ7QB8kQ0oa9d6Yd7tO7ODo7qGiTAAafcPz dd0CAbXXZSsrZGK/s21rEn6IBTHVH7cYpC1G9iz7WEDcY8GoEgaKxsJq3zwlZCFJYi+2ffAWcNvv HKBC+di3rfa7/e+pcE55EfZMmczEPuekcCkwnoakPL/66qvYd2Qi3W8PvzK1MvCNtSy2UFEI1ex8 C7gEKHXpbdGjHG2lS2LhtDWO4lZrv5EEOgVxbIOjJHk7LLwOi6HI7cNGgig5/bfwUu7+T0GYF9db yG3Ng6M+uRb5URRGHQLKHKFTD55XxXcy8vVTUhoMkQIEwC4DeNvypl6B7XraTgs9kkMp2NuflBPl az4RRv21Fc5+c6TAeQpwsC9dcR/xdcVtJNkhM7W2KTbyh+R9QjDgbQzGaH7stPAMBEj/PEPcmmKj eI3b++fdQGxtT5QnwatDqSF/MEXIEOF55pknFjzSTqPbHqv9R6oRUVio7GiLnfFTxpQ1gpuOgUYA zS+F3FbCkYidw44QGv93aJE58Ezvu79Pf+e+s+/fT/NoCyFSgvR4//2NeG9gQhBfY4GdezIBaORt zddkBLoAArYdWQCT1WthoCzSliKLEqvA9ioKW018ioVSYL1Q3JQwRXTQQQc1JQtRDJQXxaQ8qUUm LfyK7NhWZOGzCKuYZ1GUpMQ6c+KYrGlKnIK0ULLmtGFblnbSXngWedp3zcLTH4VaPNu1Cre4lvKm BBACyojVVbb0tWl7GhJQFp4F4/R8WFDcFFEai0VTkSDjbSSzmhKSiJUUuWfBh+I0du0rFFRefM0P BWEMiAjCxWJkvRp/OsSFUmNZqjlAhFGQIv2FhWeqsc/KpOAVmYG1veJIH4KhUJB/Iydq6BP4IX+U WRJEEC5IlXYRGO8IS9M4JI3BRL95O1i7yFujHpJafzoUNKLinSGIi3dS/4wVOaCgWP3GrfYAcqlf vjM/lLqP/ho37HwPb2Mx/4gcnHgv2koAkCleHcWCiF0GPCPaU7gHeU1b6vw9KR3Ngm/rYTv+dozr f//7X/RcIKnmLO3n5wnwMbfmzjVJ/M3z8vib8H6x/JG9VEdBG/4ejaWtBKULLIVNXcwegK40W7mv 7UKAO5CFyeqzeFpAyoe4WAxYWL5jwVi8LFi2A7GaLSYUFmVii5GF3yLC6uA2tn8caaB00mJkvzll oj3P44FIlmXahqU9ip3VYqHWjkWORZMKyFCWyEraV05Js2RYeJQPBeF3lJAFn0VE2bKC7Hm2IKaj dpEHirIsyAuLOh2qwoqiYCmyshVbrTPf0oTwalDc5b39lI7xEn1AiCzQMFEXvnyMLOtOmEIoRb5D 2RrTV9YbMmVPO6KDZFG+ye1rTOrJOxoYNgrwwKBcKY6iokRdS2HDpnoegb763kl1vAiUvHnyfhDe AePwHbJBoXof2iMIiWqGZdFuKk7D6kf4zL9QAQySUKyUIkKg6qOxw9HPVPY2za32eFXKByW1pt/e T33wzifRN1Y/LJEAxFb4zbvp78E8ttUzkp6R5sP8eRYrHmkqixBIue6/75Aq7yPCnaoa1toO6R1o T/imNRj+k9dmAvBPop+fPVAR8EdN0VKIXPBipWmBsDBwGVsYKHrKJSkKisGCxXpwP7epBY1YaBVy SUetsia5JpOiZJ2zkFTZswBTEql2OwVIMbOICOWVjl/lddAfCzNCog9lpW3h5rpFYNRBT8I17XoW oespAx4O4YmWJFk7CQ+LZyMHyNRrE+bVE/vKll8iIyx/BKisSMTfKSyhkuo5AcZorEIJ2mBRInZp 0U6HAVHOrE/WL2u6qtzTqW/1Fntj4HERfknHD3tXvCPapGzNM6+LeU7ftfUFr863dvQxeRXMLVc1 T4n3LXkc9CONhfJHDhGrdOBNKoCTiKV5b+QQnZbGUYtQlq1n3iTKlucBQUqegrZi4z7vZ5oPJKOR ks3uS+PmheIp0U57yUh7xvFP35sJwD89A/n5Aw0BViaFmhSmBTIpFm567mZJTITLNx1u4/+UVlp8 /TtZ+OLYQgKsCL/jdkQmEnmgYMSUKQVKmIeBFcrStViXlaF/p8x7i6XKZhQO4eIsH/qCALAA1dnX VjpQR5xTbJflTzxff5o7pS+BbxFHFBTWUTqWVUfJttUy1K5+iEvzeiTrzAIsns0iNX6LtzAJbwpL PR05nPrF3e144Gr9f0QFPs1Z2vptvso7GZQq5lUxx0kh8ujwStRz95o/bTlf3rsCH6RPuVyk0Nyk qn7wFl7gmncfEbP3HriHN6Oe8PQgcYgoDIlcBsqKZ8fYzJcx+XhfYClE4V0U7uJ18j4gpbxYZZLj byH1rdoXmDobAqFp5L1RJZBSR9bSM5AtGPs78GzeHHPMs8SrVhanL+orItzo3n04wN37wetWKyRl TqrEwP/hg8QpbSynY6211qo3Hd32+0wAuu3U5oFVEeBC5bJnLYpTiv0JCVD0lI8sc+5gVriFnVJg ZVr4/aSguRwtOOKILC8xcXF4C1E6jEQ7FB7FZkG22PrJSrPoWhjFXFlnFK7QAIVm0XWfEICMeO27 jnuX+5nLn5Lh4qdEWcwSrngzjINVY7FHMvzUJ23qq+z95krjJpy4gp3CZmGFjThpPcXY0ltGSRkP rweMJV1RipS50+qQGxntFmE5Fbwl4q9CBEgIfHyEM8wLSxV5kgtgLikbuPp9qqGvP0Il7jPXwgvm SFlhisdiL6RAucJF2+a2JYEt4kDpU2KUiLbNJw8DRekaoSDEQ/6GkERZJPAJHTSq4ORsmDPkR2Kf UAavEGwQGO+n9yrVvEdkFPcxJvX0eSXkQghVyd1g7WrPO0zZeockQfJsuC+FpVjEEvnMO3d9I8K6 9+4jR4iHXQvIivEiAIgesgYDYZOqt4UXDUn0fSMitORaz0E6vCtlUiER1HsmR8OzeYOQfn9TvCGI vr93niVJuwhIT5VMAHrqzPfAcVMSLBGWEgvaokRJWQQpdgrWomULl8XBIpuEkkrWOqtIOywMylLi oMVSHNjiytL3bwud/4tTW2yJBUgIQdyWoqeM0oLI5Z8WdVsJ09Y3iVoyzNOxqTwNns8S9G+LvGca E4LAq8GK80yub/eWlX868Kf6CnChy5anYCljXpCqWFBbIxQPksNqpiS5oFMGuMQr40gu2D333DMq 14SzueEpYOHCK+Hk91zf/k8BV60/3/PMUEwIVNnLgjAhNxICXYMAlM+D11at5DRhBH3RDyKOnfJH uP3NM0Lgfu1RhMn6dBqf57E4KZ5GxLxS0kikPnrPKEoJdbwJyW2fwkLmCsnxHpTd/N5RCpGHKOUP eMcQIN6h6kE4iI3wlb+FRr0/PBH66J21IwBp4RHwfiZB4HiUyuGq9B1ljSi0pgKfZ8Af5lVCYf68 U94RY0auE5HlWfFO+j9sEMlaBAAujSS6NjKXnfmaTAA68+zkvnUoAhbgsrBYysKVXk5CK39fLtZj YSkLF61tWLUk5QZUv7MYpuz39J3FPUlS8uX70iE11UNnWGxlQWDkBzQnlAZrstZBKxIWyxnw5TaE TGzro9BaI56TcibK96X98+XflcdSHWe6DllLZ93X6gfFUE7urF6DgPjUEgrDVlDKl6KgJCh4Horm hAegJeHBYVlX57sehhQbC7d6Xj2i5lNLhF0ox7LwACBDSVJYqdb9yCOPUnPvbXN9dg8C25xwudea b+SblwpBaDQWb4wtzYe/k+YOdKqWQK5ex3OCaPOkyMnp7pIJQHef4Ty+jEAFAXuceS1sFWzpxLkq cLaOcZ8KFbTWE9BVJoHS5zkRomDxl/Mu2joGikRYoqVTEdvadkffJwQkPNaoMm7v81nrSGVrq2G2 97nN3S8/gKdFcm6tkxwH1HP/qXYzAfinkM/PzQj8Qwhw//q0VsSUWzoytrXtdcbrxYnTNsWO6p9Q Q1sqNnbU81vTTr2kv9a01ci1XPHVpMBG7htQ18jREVLrKZIJQE+Z6TzOjEBGICOQEcgIlBDIBCC/ DhmBToCAGHFHuJsH9FAkN7a1YtyA7ltnb18yWqP71euNRfKjbYW2FEowlFhaTmasd39bvrfzxA4X yX1CQV15+5y/N+7+jj5Mqy24/pP3ZALwT6Kfn91lEZBB3d4iIjLK7S6wDU3WeEvJWQkoWe22fImd yoCWLGgfe6qSJ+NeVTQiTi9hT8KhxD6H/agwZ+HzO9+J9UqESq5f+7flBkjasn+7LLL0ZU0rwGKb XVnh2PYmduo7ldY6gszYTy8L3rY62/8ks0n+s8VMopYEMls0bfPiuhWztUVOJroxpmIxdnvIfBfb NzZu53RwD4zsMph00knjbgVby2BSPitBlrikQLF8eQFE4ppkQdsWJYFSyHZPUJD6WMbGVkhZ+PoA o44gAfovoc2uBrs8JH0OaAKgTDX8zK/tfGUCIHkyFdaysyVVnaz3B56KGKX5K1dpdK9dObbzec9t exUugJ8dOv4GvLfuRUj81CfJk3ZDuMa7IaGx3K427Tjw/sCuXCbb77zbxN+F0sndWTIB6M6zm8fW 4QhYUGyVU7mO8lYdsK2Szg6QXEdpNSKylCWUsf7saqDkZKGLW1rIUiEYik1GtwVRcR3byFiKKrEp uCLxynfaojTTHmyZ2hReNWObcrO1y/2UjSx629GS6IdFWG1+dQ3Kpwg2Mq7qNfa9K4UrSZHiVePA tjTK1b9tO/N72yptLTMOtQZsg7T3n2Lwb1v+KEnKS3U+46Q8ES4Y+b0aC2o5IBwIDkJm21/aumls 8PATiaIk9E1sX8IcQYDsIFGjvlpalpWJoMHcvR1BABA4ZMsHAakqzrZgXu8eRXyUiva8dH5GuseW OYQWvvJEqmV5m2vbFllbRO3th7FtoUlk+ts9or6C90E5bu+5uhLeRX8z5guurpOcquYDAiDJ1W4d JKlc/dEWR38nfu8dtXWS9yRV40RkeLns6rH91nbY7iyZAHTn2c1j6zAELPysHhYL65jyb2krWiMP ptBsf7Itj+XZiLB4LZKULcVGeA4SAdCW4iYUAsuH5alQCqVuEbVI2l5nq5hkN4uuanNJLJYsvOqW SQstwiBJjtUkqY3CTGcHyHC3aLKUq+V2KUSLN/KEoDSirChhfVYoiFjYES+ivyw4JESdAx4RfaKE LdisRMTMGCh7Chi+lDZMzKXCMzwJFFkq28xTYMseBWc/PLLjHmRCcSUWLi+B8SEDtuKlAkR+p66B eahW2ENQbPGETUftLedhQbZS9bx0SFIj71Bbr7FDQj0J1j3lWBa1F/xOsaRq6eeWnqf0M0zhi8zx Mpkv+JtLnpbkdeFlQTJ4a7zH6geoq+CdUpyrvHXRO0fBV4sLIcHE3x1BIhGIdGAQcubf3r9aZwS0 FbvOel8mAJ11ZnK/Og0C3NAUJVex8rsdvWVJbLheLfoyGJQ89z3lbrHkIk373lmkFBhlnwq/cMly D1ukKYpUNMhCjQiUzwngHq8eoOLZlHEKM7B8WaBc84kAuCbV36+OxXUUNEEuWFz1BNHgMmdN6r9t Wck6VHWOIqLIKVTjcH2ySj2f8k5eD31M32mT54K1jkS5rlxfn6dDmIQFqxhOOpAHJvqONAkRIH9p vMbimfrCeqxVYle4pqPFAVFkYMXi04l+nlku8lMel7lorsRwrfHz3PDMCI1Q9P6+HPFcDbm415wk cuk9FeoSFlC0q1q3wPfef59yNUuehnKBI++F8t1VofzbUwWzo+d6QLWXCcCAQja3220QoFBZehQl y4Rlkdy4FG2yNJPiowi45bmZ2yrK8CrWU25TXFq1NUqMZYsAUGYUKouWJCXp6FhiAUzWWtrCx/Il lJJ9340IJZkIRa2FtaU2FG7hamc1c8s3Iqxu1iQlTEnzIMCTpZfCE6ncLjJULl4kNuxeCoIHwb8T AbCwm09eAgSi7I3gNhaOQfhgRCmZc4SHYudSZm1yuzuEKJ2/0Mh48jW1EeC9oYC9t+ZDaA0BQLiq eSTlcx0oZ8RS3od54CGqV+paD8rvsf8Lw/UERd/c+5cJQP7LzAjUQYBy4R4Wd6ccxKApfQrBIiVO zT2ZrEDNqYzWqCATqRZ7ugfh4GkoEwCuT5JO+EMQWP8WP8qwHHdPJwjWWtwspBbCRku9eiaLT3U0 ItaOgFDsjYg+iB+nMrqN3MPdztORKixS4rwcavKn5xqHtqvjsKgL0Qh9cJE7iTFVWYSncIVYPSUu R0C/WJGUkdABouIauQH6oX5/cikLt3ie+UqEqJHxpPkoK7F0HwVoHrmzeTs6QmCn9r8ktuo+e2Px nb5wvZffEeRV8pz3OSVPdkR/arUBZ+5/f0feJyWMxfYpdgl4KgsqH60SI0nxeX9b5phHzrkHalrw AEhgrSeIJY9D8gzAvrmqivXa6g7fZwLQHWYxj2GAI2CRFDv3USVO7X/KxalvYu5tEZarBD1ZyVzs FBCXM5c1K8inKhZNeQgsVISE+xdBcV9SdNyqXKmSpJwKaKFMLluLJMuWhwCZsfg1YjlxN3OB+7jP At1ILF//nZaYQhT61khRHMpX+Vq4cw1zvVu80zPF9MWAtZ3GIZ4rOVDyHoKzxBJLROvQsykRypWV 77Anip0Sl1cgvCA27BnmVXyYIkR4KCHeA3j7PhEStfd97/ct4acdHgzPlfAmj0R/yuV6eW+QypR9 3pZ3qXqPnA3vD7KCsJXd8saaavJ778oJffqYclts+0thn47oU7kNoQKeHDspvKNCOJS9ZD5EwN+Y +RPu4Q2jsM0N4m1c3mH5GoihOD9SKHaPoLWUZOldQiAQPoQa2ajudunosXbm9jIB6Myzk/vWKRFI tehbYwHWGggXPEtMHJ8SobR5E8px9ep9LDthCO5wCzkCIIvaommLFktX4pRYJ+Uupm2hSwSAcuQa t32NYqIYqwcF1ToMB4mg/JykaLHlmq8Kb0itXAbWv6Q9fW+0HK5QAaJA6VIQThBEcNK+bYs/ZW/x FrOXgIcAUAhCJeaGdWfBRxD8Xk4AhYhEwJoIByA1sEOkKD1Z5ym8YNzCF8iD9pA2JAyJkBQnZJDw M/Za2x/1D1EQgnEwD2VcJgB+x1KvdVBOW/8AkAzeDFhUFaIkPpnwMDU3ZZHgqlQ0L4H4emsF8Wok 0ZGHIW2ZhC8CwKMFZ8/2Ha8IksArAFvhKuEspCGFk8yrd0V+AALFk5DGizxWPWBIH+KM5Hl/EEEh nao0Oo7W4tPZrs8EoLPNSO5Pl0GgvbFDyhcBaI0owsNTUBYLnkUtiUzq5oTr26c5YZkhDxZgCqIs FINPLaHcKTmJcVViZLtdrcOAWhq3rV4+RJ+qIRKEJ516V24H0aieKlfud3V3Q7qXMi8f1esgKO7l 5qT6XXJPw4DSTRY3xdXSMbesXoTO6Y0pGbE170Nz1woH8QLUEko+7aiofi9UgTC1Vih9ngYWdXWL YK22hB+qORRCMj5lkftRFWQBsS1L9RAryYJyCnjBkKvyqYdIKFJWS8wjr0g6vrq1OHS16zMB6Goz lvubERiACIgJIyUsfK7XRoVLXiIXl3GVODTaRnPXVZV/e9sbEPfzJLDq5R5QWkhAI4IcqavQkdZ/ I8/t6GsoTkciS5bsDGNBgHiqbBf0Lqc8gnrjlnzovUdoGk1YrddmZ/4+E4DOPDu5bxmBgYyA7Xrc ro24cctd43IWUqgVPhjIQ/hHHseNLM7P8myNJS8c0ZaDmf6RQbbwUGNGZFoz9gE5BgRMWEeyYGv6 ZItnR3tjBuQ429t2JgDtRTDfnxHoZghwW7emLoHhu76nKv/y9PdkDFqjaAfWn0xb+tSWewbWeDr6 OZkAdDSiub2MQEYgI5ARyAh0AQQyAegCk5S7mBHICGQEMgIZgY5GIBOAjkY0t5cRyAhkBDICGYEu gEAmAF1gknIXMwIZgYxARiAj0NEIZALQ0Yjm9jICGYGMQEYgI9AFEMgEoAtMUu5iRiAjkBHICGQE OhqBTAA6GtHcXkYgI5ARyAhkBLoAApkAdIFJyl3MCGQEMgIZgYxARyOQCUBHI5rbywhkBDICGYGM QBdAIBOALjBJuYsZgYxARiAjkBHoaAQyAehoRHN7GYGMQEYgI5AR6AIIZALQBSYpdzEjkBHICGQE MgIdjUAmAB2NaG4vI5ARyAhkBDICXQCBf5wAOK7xyy+/DKOOOmro3bt3qyD74osvwrDDDhuGHHLI Vt2XL84IZAQyAhmBjEBPR6DdBOC3334LX3/9dTxzmQL3/+GGGy4MM8wwDWH76KOPhoUWWii8+uqr YaKJJmq65/fffw/ffPNNGG200Wq289NPP4XJJ588HHfccWHDDTds6FkPP/xwOPzww2M/t9xyy7Dk kkv+7b5vv/02/Pjjj/G5gw02WNP3r7zySvjvf/8b9Gubbbbp7z5np3/++eexXed7t5bI1Or8d999 F7HUhxFGGKHm+F588cXYnwknnDBeN9RQQ4WvvvoqzoXP4IMPHn7++ed4tvtII43UdMSrto1xlFFG idckcZb5McccE958882w0047hammmqq/5xqjY1+11ZOOzGzo5coXZQQyAhmBLoZAuwnAvffeG/bd d99AcVJGlMPaa68ddt5554agmGGGGcIhhxwSFWdZXnrppbDddttFpVtLhh566HDAAQeEWWaZpaHn uGj88ccP6667bjjssMPCfffd9zcC8Mwzz4RVVlklEpGTTz45TD311E1tn3jiieHOO++MyrRKAChO fbnrrrvCpptuGnbbbbeG+9TchUcccUS44YYbwieffBL22WefsOOOOzZd+s4770TSQ4n/8ssv4eOP P47PXGuttcKyyy4bPSobbLBBmGyyycL2228fZppppnD99deHEUccMSAyroHF0Ucf3R9+O+ywQ8R7 jjnmCEsssUR47LHHwlhjjRWfa9xw+89//hPWWGONcOCBB7Z7jLmBjEBGICOQEfjnEGg3AVhggQXC ddddF44//vhAgV5wwQVh+OGHjyO69NJLIzFgTd99991h+umnj5Z3kltuuSU8/fTTUdHyGiSh9HgG 3njjjfD4449Hi3r00UePSosgB5dffnn8/zjjjNMfeu4977zz4r1IxbbbbhsmmGCCeM24444blZe+ sGSr4l4K9bLLLvub5+H0008P99xzT1SolGH5ftY3wkCxvvzyy39rlyeD4kV2WOmNyN577x0VO1Jh PHAT6vj111/DSiutFKaYYopwzjnnBCGUhRdeODz55JNh1113jcSLokbKtthii0hmzjrrrCYvgrAJ D8D5558fxhtvvKaufPrpp3HcCJ15mn322eM1e+65Z7zGeHkHPvzww/C///2vkSHkazICGYGMQEag EyPQbgJAKVHCY445ZlS4lGwSyobCpOAXXXTR6FamSP71r3/FSyiz559/PrB233vvveiSJqzVk046 KbqzWb4U7oorrthkWbO4Wbk8B4jB8ssv3/RMipAVu9RSS4WHHnooWsX+X3bnc63XIgDc2kIXyEit 7z23OXGv+8rPSddutNFGcUwU9FFHHdXQ6zDooIOGF154Idx0001hs802iyTLWIzprbfeiopa/gOh 4D/66KPYZ0qdFwZu7777biRS5RwJZIr3pDrG119/PRI3XgMy77zzRnJWljRGnocsGYGMQEYgI9C1 EWg3AUjDpxz79u3bHxobb7xxOOGEE6IngPU7xBBDROs7EYCVV145LLjggmHOOecMZeXqe/H9rbfe Oio6iq2sWFmop556anjqqaf6u8/DtSWfgJucgvRvOQqIQiOCbLCqa4nvWpLq+NO1whQffPBBq8IV vCMIEFI13XTTRSWPAFDUEia588vtp1AInLjuEaH55pvvb3OS7qmOkVLnnUixff/+/vvv/zbc5sbY CLb5moxARiAjkBHoPAh0GAFISYDlof3www9RUSXly8LnQi5LsiarlrPkNNZqOUmtChtlxFJOIjGQ N8BzeAwoUIq0qri125ZEPc9CRmp5B1qaUjF8pIbiblSuvPLKqIzXX3/9mFvBG/DZZ5+FaaaZJoYG eECSx6TcJu/GpJNOGkMHPAfuv/rqq+s+dowxxohEiVcG5hL+eHWyZAQyAhmBjED3RKDdBIAlSWlQ 9jLOKXSWPmWZfu874iclnRSyeLscgfSTq9qHctYGRSc0wKVNkYvlzzXXXPF6z/VTm57pPkrxkUce Cc8++2z0OPASUGquI7wM+qSf+uE+yq6W27463RSrvrqfZcyN3mgm/C677BK9IBL1JNrVk9deey08 8MADMemQMofHIossEkMePCoU8+abbx7OPffc2P9LLrkkxvXF//URdvIjLrroorhDQBhhueWWa/Gx PC5wuPbaa8Nqq60WbrzxxrjDIktGICOQEcgIdE8E2k0AKCkJZ5LIKNb5558/ZqDL4Jc5z+I/7bTT ovKTuEchS+xjDXNpU8R+x2KnzCS2Ud7c/DLRF1988agAWfsUEmtYpj5yIMa9//77h2OPPTbGvO0+ WG+99WK+Aa8DRSmLfauttgo333xz7IckRX2ivOUGrLDCCmG//fbrb3arFr5niuNzrbPCjdH4/K4R cY/+IhH1xDXaholM+yuuuCJa8LbmCXmw6G+//faYCDjrrLNGzBAcGLz99ttB8iDSJHyCAJkboZgH H3wwJg4mqY4RobErAImAM6KFCGTJCGQEMgIZge6JQLsJwDzzzBMtzeSyZyGnLX2S3li8LEsK/447 7oju87TH/sILL4zKnfWe9quzWAkrVlb6c889F5X/tNNOG9vhPZBxTymLU1OYvAHa1JY2n3jiiajg Z5555hgGkIXvuQgHQqFt7WijHEv3HL+v1jDw3EMPPTR6ENLe+lrufM+slT/AUqfMy3UOmnudPEu8 n6S2WP88AsbguXIb7LgQ5zeG2WabLWIBQ5Z7mgttyOK382HssceObTY3Rt+5DvmyG8LujuYSJZvL keiefyJ5VBmBjEBGoHsi0G4CIJt8yimnrIlO2kOevqwqwObuKzdGIZWFUpp44olbnA0KMQkykggJ ktBcYSHXU/yS9dZcc824la78nERMaj0YMTj44IPDbbfdFusAVIVSb0T5u8/40nbH1I4QiE9ZtMlK LwsSIGRQlfI4WPq8Neuss04MKVSL/ZiTWvOCONitYTcD70OWjEBGICOQEejaCLSbAHTt4fffe8SB l4LXoKpwWxony5/FbO98awoT/RPY8aQI20jya01SImLC2yM0o7BQloxARiAjkBHo2ghkAlCaP6EI iry1QjkqxtMVRHjA9sDWijG2BZvWPidfnxHICGQEMgIDB4FMAAYOzvkpGYGMQEYgI5AR6FQIdHoC YJvfkUceGavUyWwXw25OFP/597//HRP9uKsbFYmEsuglANpN0Gi53kbbl7AniU+NgpZyCRptr5Hr 5CXYYZHKMjdyz4C8RiJmOeFyQD6rM7adtq42ekhWI2O49dZbY86KfI6ObLeRZ+drMgIZga6PQLsI ACWzySabxKp7yyyzTEx0s/WMkradL2WetwcmGe8UtO1sq666aovJdGoP2DanBHFrCID+2dsvyc1h QdUkvHr9t/NBoR/leCUBlrfPOT9AUqFkOyRDjkF5Ox68JNbNOOOMcRteewWJkZBIOdgVgMwgHrYC 2p5p14CcBUl9thEedNBBTQWHKBP1AlxrO6WaAnZcGINtlMIA7jUnyjrbDum8AJ9UIMnzfZA1ONjF 4Vo1GoQf9tprr7jlM4n5sutBHQI1DuzQcI6Dsw9SdUi7O+w8kH+gRPQ111wTTjnllP6g8gwY6rv8 DVtOVZ2UzEkkPHonjF/flFNWS2H11VdvL+Rx66Utot5T212dCZEEgbUbRlllJAB2nj/33HPHvx1j XHrppeOW1TPOOCP+zdhV429IH53nADckWP5GEiWlYaH0s+vldZRLPttK6swM20Z9smQEMgIZgSoC 7SIAlIGMcYuPvfl2BDgUiKWXqtQpXWsPuoXQsb9pEXMGAKWguI9yv84QsO+/LOoFUEK77757fEba fmahdVKe/fwy3CWzWVDTYT+y3GXk286W+qVd9zsSmFJiMSlF7KhdC6xaALbQUTYK8Vh8XZPi5fbl U4L6Q/FRRkkUFHIvZVPNBaAcKBoKSM0B16hFkET/1DNQ+a8WAYARhdZo5UKKEKGgFMyDrY+UrGJE FA3FYXul8bjW2JEAWFDY+mrujN9c2VVAGSk25JwApxCaC0SBgrn//vvjWRB2BiA/nssLk05bVJMB qXKCouqEnqH+gvkirkPYzj777KaCTJSg+2ClBgLF5l1wGJH3S7Kl7Y3wQmS8Hyok6retn8Zo94gt qK5V3CjtbEASKWkEx3vXEQRA/QlHM3sn9ScRAP/WvvEhOYiiMyqcqAhvGBi3IlHG6pAl7wsSRLwX yBfvUXknhyRVWJhXf1O8SghP+VhsY1cJEuHMBCAv/BmBjEAtBNpFAFh9FloWM+XL8qMwWCUWMQue hZ/y8rvDDz88Wm+2rznURoEe9zksyCLHQmb5UfAWM7+j3LmyfVizFlVKjcWeFntWnUI7Fnfb4ygh Cuz999+PylbhHIpOIR2WOqWAHPBSUEraVUlPP1loLHbXWkQRAIs7xWVstjZarC3ULDkCB652Fmi5 PC/Sw6pOhxXxYFSr67H8KK9aoQ0LvGc4L+Gqq66qW4KYB4IVabwO8yFqECBDxm/c5gqBIRSjyon6 r29OTvQc1/gdRY7UGRsPhvuRCB+ERb0FmEkORAAUZUIMnIgIe9fYgklpk0kmmSSSB54WhImYL+9A daui2gfmh5fCT++Mg6XSgUfeJ+P0Pgj5JPFOmAf1IBAS2CN8aV7cbx6NsZEKkI0sG+aPUnZg0x57 7BHfW+8NbHkhKPJUVpnCVxgqJZwixyo18iDoJ4ySINj6DfdyyWtloc1J2gaKBGinTADgySOXz25o ZAbzNRmBnolAuwgAyCxMLBeLkAXV4sSyJEjAAQccEE/8oyhYXBY7CxdFnyrPUXL+zRLye4skRSF2 TjlQIBSuZ1nQtGOhFftccsklo8JJCyRrnBJg+fAEWJxVyON2pxhYu37PklfcR4U9lq7+ITAsNpaz 36cQhrwAiozb2Zgs5ogNUlA+ZAjhKYtnwCSd2seSR1yqxwk3dzphKp3MTVy9p9bryttC0Ze9E5SH TyIqDkfidUB4KGkhiCRCB65lpSIS5SOa4UOhUbxIk7EifxSNcSFg5obHAplAyhAlmJfFYU0IWhIK uVZhIb/Tpjn2Lni2OS8L3KoKjiL2DP00bzwatZSg9lt7pkNzS4Qy1amaJe8L7BAA7713qHymAuzL Cp5HihcE6Swr/3SNeRfKKc+FMSIHyeWvtoXqj1Xx3jRarrpnLn951BmBno1AuwnAz0VcU/z20sKt PGixKG1fWM3pFDkL95aFlU+pWAgtun/8ddJen0JZsHpnn2OOOAMTF5ZPOmvPgsiiTEcLb17EQc84 88zoBXBozZmFO/WIwptw+umnh77FAklh/VQskkMXlvzvxaI361+FgEYoFDn39C+//nkWwB6F25g1 PH+xOFPMQxbXJ6WNQHxXKGeegTkLglLOX0AGEADxWIoNCWDp1quIx0pzfTrwCCFABhpVPGLEntPo SYbCGTDynFoJdxSCccALEWJds7STuF95Y5Y/F3lZjJkb3pjNAdd0ubgRkkUo5WTNm19eibJQlMnF 3dKfnnkxBzwS5rlWMmOtg5n8zvsnLGB8yEZZeTb6594I4UptCVPw9Aj/GK8aC+ad4jdeBKRWCAdW LHx4824IQ5mXemJu0xkcsBRiyEmA9VDL32cEMgJVBNpMACjrXsXnx0EHCb8NPVSYsIjlk0FGGjF8 +5cqP/nCC8L4000bLi3ix2zjOx57NHzdp7Bmi3//UViUX/frG77769rvisa+Lz4OFJ567rmi6/r9 778Low03fDjvmqvDax9+EHqPPFJs554nnwhnX3lFGKtQEK++8kpYaOZZwrpbbRnmnW768OMgvcNP v/0aW/1liMHjM/oWbmwH/J5x2aXRnbz20suEZ95+K5xz9VXhp8EHi/3+vriv73DDhkeKtnkkFl99 tSLGemUYqVAo3P7cxpLdCAXrwKF6xYIoHkqAN0KRIW5v4Y5GhdXLKmfRSoKsRxzEubm2eUsuvvji +BjeEYpbAiBrUEiFa1wYgFeE27pc2Y/SrVVNkDcCAXJWQC0RRtG/8g4K1i6yoQ9CCCxZGAr91BOK jdKk2OQv1BLjqWLCA0Kx+s4pjLwR5aS8es81V7AWN08hnpbu4fFgxQtHIHfm3LjPO++82Ia+SOCT s0Bci2TKAUhVH+W+yLGQpOieWviX+8CrZVeFxELeNCEHiYZZMgIZgYxAaxBomAD0+7E4xe+G4mjd p58rtPwg8RkW6EmLOPB2r7wbPt106zDM0MOEle56KC7a/XofFHZ+6+Pw6uuvhZdXWiu6m9d45qkw 7Zc/hV/67Bkt1b0++DKMuv8RoV/hSp68yAnY5uV3wvdb7xy2KyzVYV99Lzw/72LRlVtkjYWjfukV +m1ZhBYKZTz+cSeF92+6K0y5+GJh3A8/CicOO2qY4qSzw++FK3qJW+4KfxTW1++D7RN+KVyle7z3 eRh8xz1Dr6mnCaeFocJwux8QXj7n4vDsI4+GAz7/Pv6/z3TThZ8KK3+fj74OExx5UrhqtPHDSaee GG79ZNEw19FHhBPOPSestNjiUZmxfsVrWdKSAsuZ17WAFwKxqFus5T3wijQq4roSxliVlFk9AqAv wiiy7FXrQ1zE6VnzrEShGX2XBCdRTj4CRSRWL5zBamZxe56ERd9zS8vdMFbKy0f2Oc9KEhassA1F z2Mhz4LrXiKfvAJeBkpOXxCgFCJqDge7SmSxC1dogydE3kcSuQueJ0+DpS5pk7K2EwXB8Bzuf6Gj OQoPU/UI6pbwR5wQJmOsJ5S7ufV8+RpyWMwXd7z+8wj4vSRIv0dOhLVY+a4xD+L+/s/6R1bcY95b 2onC5Y9EST5E4nhHyvjU63f+PiOQEcgIQKAhAtDvnvtD3y13CL1eezkMEv50pyeZPQwRZg9DFtlm pxe/6hfWCsPGn+HFp8ICYejiUzzi+qvCVMXPxXsNE8JLrxafpwtV3CtsHUYI4dabis+1YZ6inXm0 c5ojaAcNu/YaLoTnC7Lx/FNh+lDc13vwEC67sPiuT9gzjFi08XJsZ9Li2u1ce47n9wkrupZv4thD w5jFz60844Zri8+VYUP//viTEF54puhP8azexec/Nxef68IUxcim0PdjDgmDFW3uo83CsvppyZXD xMceHu4uFN/dN98Ufv3l16jcKLWyW5ciquVqppRkh7PmLfSst6ogTLXi1BZ517OeG90FQOHxTsi1 4KlAQIRguMUpHCQhWemUpLaTspFMx6IUHkHQ0hkKkvymK0gStzPXdtUdL+eCUjcOnoLyGJEIGDi4 SL6GHIsykTHuajIeF7d4v77qd3n7G+y0L+EteRL0lSLULuudYk5tUsASQqtCGVcxF3agqBE9ONYT YSOueyQniYx8XibCI4AQGTvPghCMPBKeGoSM0jcX6b1xWqWkwYRvCkPUeq/SuyRPAsGrdY0xmq8s GYGMQEagFgL1CUCh2PoefWKh/J8JfcaeInw575yhT0xK46zvvtKvWNxHeP6lMMyrL4Sf9zkkjDB/ kbj4ry1rDpjikVQnu52LPCXdpYtl5Kes/GoDXMdnFvkNtfIJKFQZ960VXorqoUQURK1DfCjlJOV8 gPIz05a95vohGbB6aFP5Wu021zYlyuK1Tc4efv9HAFo6cIiyL9dSKD9rscUW66+btpn6JKGEKWiK tmo1c81TurwtjQhSVt6B4B6EqnrAku2TPmURiuF9KQvFXx63MIZ8ArUTJMdGb1hJnN5YSxAbXhn5 LtX+NTKufE1GICPQMxCoSwD6Pf9isVn7gdBvxHHDmwftET6ee/bQu7CULE69C8XXXaVvYT0N/fpb Ycrt9wxDvfla+OTya8JbW20Sxhpq6GiZlq1YCzfrzXbB1m67cr1tfuL8PVHsVZfk2Frc2oqVeaPk bfFM2zNTW8IadrGUs/bb+pyOuI/XxS4N3gJ9blTSGO2AaE3+Q6Pt5+syAhmB7oFAfQJQuMx7//J9 +GX88cKXU00eBvvu+zBS4docurBOByksoG4rhaL4bc7Zwu/TTBmGfvN/IRS5BnYJjNSrd8xiLxMA lqBtXG0R7mafnipyAlqTGNlenBBX1nQt4X3oLMpf/+zKaCRhsjoW72atY6nbi12+PyOQEeheCNQl AIWWL0Y8SOj3R5FH/3NRynTMMYIkJC7lFJe24Ii5+lndC98SXEmJ1rJuaiW8peta+i49L1lB1efr Z+q3WHH12U19sj+9UBaDDPInRP0KJe96MdXmtnV1r1cjjyYjkBHICGQEujMCdQkAz+Ofjv5+heLs Fa1fiUvVA3MUJxEHH1iH3bR1UhAUWd7czs3FkVPbshz6/uXlQAwofrH61rhj29rPznifeLQ6/cIV 9XYkNNJ/eEpMtANBTF4CooJSA1IUkVKKWGKi/fuKQZWr7A3IZ3d023ZLCA+od5AlI5ARyAi0FoG6 BKDaYLX4ikVcFrSsc1vGLLD1xD0WXiVRKWQK1b0yqhELC7R69SxumdQK6bDcZX5LnrK9y55y38kA 1ydu9JRUJePevmqFaGRLp6162hUXFbOX8MUVLMEqie1iBx54YLxvxyKrfYJiT3051dFzGs3GT22K KTsHQLa25DwZ7Erm2o5ny5oDYnhTjJEikpjGy6CiHFwSBvbgSy4zNuWNXWvsBDaSxyT0UaS29fmd TPZU0MfYbOeTjAZnIkNeAp7kO9sGYSqR0TZAWJcPVLK1zrYzGCB5tuKlCof15ru577UFAwrMeCX/ DWgCYKuiuvni66kGf7l/tvIhObYtlg8tammMtgxqF+YKKcGyLJI8VQs0l95zc2Uu1Xgwj6olejck 7Xn/vS/eWRUr1RCws0ItBAW3kiipbReHTH81HdQdKEuqeOlvorkEzEbnTZEn7305mbLRe/N1GYGM QOdFoNUEoBYhoLQUkKEUGhELv2InFKFkLNnNFjBKxsKmepsFVQazxVBWtmx57VtAbamSPGbLF4VO YakWlwiANmzncrpctYa6xC9lh5WzpTApyJRdLevelje/m6/4iQAksQBabMWQG60hT+l7HnwoBsrF om/c9tsbr6IxtoMp5PLoo4/G/e3+b4xCLQr4qIwou53nAgFSmVCZWdYzJYzssASNxz0IluQxv0eM 3GNsnuf3+mTMxqmYkXaIojYUhz6W9/kjIkiDLW2+o7AlPab7GpnzWtd4Dyg12xA9jxIc0MLzgwSJ 9VNo1VK5CjZ5f2DcKAFQEdF8IlO2HKqZkEQ9AO+tssjIHiKHCKjDYIujZyHNikTBFAFLJPOVosgV suudKBedQvwof3NlLo0HATc/SXhTvFOe0V4CgDh7J9Vk8PdaLjU9oOcrt58RyAgMOAQ6hADY4mbP OSuuEbHwU4qsbfvHlfydZZZZopIjqpxR5rbUWVgpTFa7BZGiUyyF8uElULwGWVD9rqysWVXlBdF3 5cpurM3q4u939vhb7PoXx9H2jc/4+q23Y633lra9pXvV5md5qwJHUbMqHVJDWHfc0L6jqO3X95N1 KjRh65394hSGD68EAkApwY6lCB/KRqKYojnE4sxCN1a/Y2GzHo1NfXpYKUbkGazMVDffvebFdQrX lEM5PDUKOVFEiASMWKvtJQCeeeKJJ0ZrGMmrbnNr5F1q7TWsZeRTuWIn6lXF995nOzoaFe+ZbYyU unfDKYkSG52RgZiqA5DeF9a88sAUugJH3gMEyzzCtHoiJkJXTejTLpKgcJD3yt8Nwlt+3/3OdtR0 pHKjY6l1HW+QWg9qGHgmz5K/26qnoz3PyPdmBDICAx+BdhOA1GXWTVVSvfJysh+lK4+Am9vixIpH AFi8aV8zVzOrkLLXhp+UF4UoM9oimuLxFlAWUFm5e15LBVBYUJ5lAa4qHYuxtvuPcQ9SuMd/in3s 88WX8XS3RggAS5lCoeD824KZSumKe6sDry/p4BvXpNwKnguWoxAJhcLzwTpNipq1ybpXYRDRSLsQ XI9EsAgpMSGOVEpXDF8hHgTA/XAWR65KOssh/Z5nQB9TYSDenhR+aO8rm8aEAA4M4QFIZys0t/US hq3JcVAdUWU/FrfKflz+iA2PjmqM5XeF4kxK2btm/oRavItV5Z8SWc1HudCP8JW/oRSC8Q47i6Aq qSRyI7jqSwrHla9PW14RSyRHno++IgSKPPFEZMkIZAS6JgIdRgBqDf/kk0+Ors+yUB4WzFQ7nmLh /mRhKpVLkiufoiWUTTXRKe02ELdmrTaafOh6HgT94HJtTP6sfidpbLhiN4T7GxFjZNmxzoyNu5eV L/6f9qBTymmM4tI+SSgAVjwvCDdscssjW0iFPAoYJ0LEevcceQcWZgpAqIDrn6LlpUEUnLPg95QU l349oQQQN+2lvuZT5v4fNfMjb4DnRHliShK25j9hVsY4haUQTWTA34jQjNBX9RCmWnOjXQrbvdoy /8JT7RGeIe91tR6DPiViooyxvxmEk1ciFxlqD+L53ozAP49AhxEA1kg1m1rskeIsewBYMmkfPSUi xul3vAAsirJbmZvUNbUO3dGG73gEGhULsxr3LECkA7FIHomW2/hzBwBF+vtnn0dPRDlG3ty9ksy4 dS2iXPdCGeLxasenaoFpjNXT+3gwWOusdwu90riIEzF27bDCVHwTVkjV9ORSUP5CCOk8eSTBNcmK l7QGC+78RlzErFhtKTEsbq4f6cS/NHZjkuOAaHTUHnQ7S8TE5QaIpZdzL8wdFz6cvDNlC9lcGTOr GH4DMrcAfnI0uP71jwKHv6S/lGOC+KVjgIVT9Mvc+XtR5lgYSEhGMqb3s9bJh+V3zPsHG94b4Qzv JY9SewQhhnXyfqUyxPqHLAqLIZaUvtBbtdphe56d780IZAT+GQTaTQBYOJQ4K1esU7KYxUgctWrR piFaZMRLWbcWdhapzHZlb8U2LdqS/ihObmzZ+uLOqWCOWLjYNoVk8WTVsr7qiXYs1mLvQgCSrzyn fixz0CKZ6odw2L4nF0cM/hrzFZorw1ruA0vd4TKpZKwcCYu3D3Gkru+NUXIVlzwFoE/wlPEv8Qo+ PBxwddAOFzOLjaKhRCQ06hO3Pw+DHAGZ5hQ+QsALQXHff//9cbeBswkoTJjCUqihWpa2PA4WJ+Vk rszxrbfeGncblMWOAi7iRmro15un9L3xS9gk5resyFncCBWBSzkxTcgCnkQIppoL0ujz612HfHin vIfc9HIxhABY5A4JojD1X9+FjxA3XiQJrNz2/gaM0RzBV9Kq2D1y2hJpER5DLswfoifZ1PPaIwio WH8t0UdEA6kaGHka7RlHvjcjkBFoHIF2EwCPYh1aaFkHLMtGtsqxPrk+kQGKknK3EKbYsjYtdK6x uJZdztpn+XOBu77qeWC91MrUZ4VTFPrIcqMkxNbLkrb69b/X/49CYQ4bDiwW7H5ffd2w65OVTyno OyvQs1jfycIzDtnoxkhppDHqA2Wb8hxcT4FQvARWQgjuIf6NOMiHgAlSxkJEAIROZIQbD0uZ0kIC uIxtSXQ9xVSWWtv7WIASEVmDthlWY/b6xitg10JHiXcKueRtSXH71DYSxeqGYfWAJbkKvC/waEsG PDwaqfVgnjzb/KWcEwmsdqaYu7R9j3WP/JkX8y+RTsiLt0RuS3pXeXMQ2/Tslg4DkpBpF4B8AN4G XpqqmONGPDz15kt/fbJkBDIC3QuB+gQg1SBX979G7X+LTHPntTcHlUW71lnrtsolYfn61BJKraXi JxQfRcVKVWc/KdZ6blJEg1Uu96BJAcQxF4mBRZus5ElHGbXheGuq5d4cDvrmUxVEqhpfLY+5JaVW LSucrORafSjXQPC9MVNgyAovQjXM0dw8y2rnGRDH7sjcAF6KZMnXUm52R9QSfWjr8bjyM4Q4kJ16 gnhWk+BsI/UpCw9E1QvBkqbAy4IgVnMy5IggMyz+lITpHl4ZdR1qiXl8oDjJ0pxUT1KsN6b8fUYg I9BzEKhPACIWRRngYhtc38EGDX2HKJKN2plwNKDhXX61VcMHxcJ5y113hvmKPIRBGnzgt7/8HK4r rKl1CnfszOk42MKSQwB6FYtq3MLVe5AYf2/Ey9HgYzvNZXYlyFIXFpAh30ieg87z5vBQ8DR0dREi 4n6vRxYHxjjVSJBxz8LncSkTgJaejwDY6YFQNBKqGhhjyc/ICGQEOh8C9QnA1FOGPmONH4b84P0w 7oVXhp82Wz/0+a1P6FMs+p31MMAFppkuLHBuURmtyNjv9/kXoW+DJ6mNW9T9P//kU8Q0bD0IfS69 OvS6577Qb/CRwvdTFefN/217YOeb0Pb0iFUpka+1wgs0oCv4tbZPbb1eXYnOItz6ji5urSCnjezu aG27+fqMQEageyFQlwD0G2+c0Gf5pcMgZ54QJjj7ovDbLXeGXoXrkzR+QOnABa1PmZlUlX/Td3/1 vjSIPvHQg7+OOC7OPej1wUeh92/FGQczzRO+nmWGMNzvf/x5DHJ3PgVx4E5VflpGICOQEcgI/EMI 1CUA3Oe/7rlj+Llf3zDkzbeHwT/6JIRCOTYpyn+o4219bJ+hiz3UgxZK/Nff4qdZ6Vt4OYrM6C8W WzC8t8aKRdhj0DB0kRxWPQq4rf3I92UEMgIZgYxARuCfRKAuAaDqB59g/PD9yUeFT9dfI/zx0iuF Z72Ii/9lKP+TnW/ts/sWiV1j3nR7GPTLL8Ln880dfi68G4MWWfGx4lqlMe7+30YbNfw4yYQxh2Ck QQYLIxY7DxCA7AFoLfL5+oxARiAjkBHobAjUJQA6PGjhRh+xb3Ec8LTThG8nnTj0LarpybTvW/yu a0i/0K8oVDRkQV5Gvv+hMMTnX4YhP/osPHdascd8nLHCUI48HqR3/zGNguAMWoxx1ILsDKXsapGR Liu90YOAugYuuZcZgYxARiAj0FMRaIgAsJBZviMV8e9hi2pnvw85VCQAjeyV7hTASuor+j3s0aeE wT/9LPQZbvgwXHGw0CRnXhA+OXL/MNqgg4Uhi/FV67+nmgCUvkQ3275aUyO+U4w9dyIjkBHICGQE MgI1EGiIALiP4qMIfSj+LqP8db5I2ut37oWh1+13hr7DDh9h6Dv0sGH0628JPyyzWOi34rJhuMEG D4PV2N6YFH5W/PnvJyOQEcgIZAS6EwINE4DyoCnDLqUQP/w49DmgKJrSu7DgkZe/svgHKZIARz/h jPDRHLOG4ccdJzhOpVfO8O9O73ceS0YgI5ARyAg0g0CbCEBXQ7PPngcWW/reDL9PMEX4Y9hhwtBv vBW+nHySMMJ7H4YRnn4mfPPvS8JXe+4UhihKtTr5LktGICOQEcgIZAS6OwLdngD0vebGEC6+PPQO Q4ZPll4kDFEo/WFefD58NM/sBRl4MYz5yONhjHMvCe8uskD4fs7ZwqB/DPq3swW6+0uQx5cRyAhk BDICPQ+B7k0AJCoee3Lh9v81/FZUM3y/iPdPdtzpMgBCsacvvL/SMmHMx54OQ37+YRj+/MILMP00 Yeii1K9iP10qxNHz3ts84oxARiAjkBFoJwLdmgD0k/0/5hiF9f9L+GTJRcKPE4xX7Pv/o4CsXxiy iP9/sfhC4fsLrgjDvfh46PPzL+H7b74NPxflgIf4K+O/ndjm2zMCGYGMQEYgI9BpEejWBADqfXba Onw/yQRR2Q9bVC/68+jgfmEQRwYXR/x+tt+u4fMvisJARU7A4OobFMcEZ8kIZAQyAhmBjEB3R6Bb E4BYrHDeucIvc80Whv3gwzBc8Ys/C/mo/FNsa/zt9xDmnzv0VuOgOAZ38IIg5FK/3f2Vz+PLCGQE MgIZAQh0awIQB1iU9B2hUPRDjTxyUdN4sCYPQJz+YsvfkEWlv+GLQkD9RvnziF8Ff3Kp3/zHkRHI CGQEMgLdHYFuTwAoc1v7hihmsq+TAOM+//8vYex7Vn+q8peT/7r7K5/HlxEYuAh8+OGH4fPPPw/j jDNOeOutt8Icc8wxwDvw+OOPhwknnDB89NFHYdRRRw3jjjvuAH9mfkDXQ6DbEwBTEgsX+Vl8+jsq +K/5QgKy1d/1Xt6O7vHTTz8dLrnkkmDBPvHEE8MYY4xR9xFvvvlm+KLIIVEa+9dffw2jjz56mGaa aeJ9/v/CCy+E77//PgwzzDDh9+LgqT+KHJMJJpggjD/++PG7L7/8MgxdHFLl/t+KOhRjjjlmmGKK KeL9rn/xxRfDV199FWaZZZYwQnEYVZLbbrstXH/99dFjdcIJJ/zt/aUAtKmtkXm/OkCeffbZcP/9 90dlQqlQZIjz888/H7799tv+xmh8o402WnjmmWciwYaBcU477bRh2OJcDjjA29/dz3+dLeLvFOZT TjllxOLJJ5+M7TuDY6qppmoaAdzcP8MMM8S/bf/2O0TfveTTTz8Nb7zxRnzmTDPN1HTvvffeGy68 8MLwyy+/FGeZ9A3LLLNMWH/99eP3zz33XDj55JPDDz/8ECudzj777GHnnXduN3KXX355uOyyy8JO O+0Udt111/DBBx8M8F1Gq666ajjssMPieFZeeeWw++67N43D+2QuRxlllDgfdj21R2BprryLww8/ fNMclNuE7aOPPhrfe3PsbwQ5+eyzzyLW4403XnxHvvvuu9ivSSaZJN6ur6+++mp8T8xHMtDM0fnn nx8efvjhsOyyy4a11167oSF4r84555xw1VVXxevhsuSSSzbd61167LHH4nvnnTOe7iw9ggB05wnM Y+s4BP73v/+F9957L9x5553h66+/bogA3HfffWGvvfaKCwVlS2EvsMACcXF65JFHwvLLLx9mnnnm qAjHHnvsMNRQQ0XFaGFebLHF4j0vvfRSVJ5jjTVWXBApVP+3SM8777xRSR166KH9EQALLmvy7bff Dscee+zfCABycPHFF4fVV189HHPMMe0G6fTTT4/tzDrrrHFBtqAjP5S38Rqjflu8ERXK+IILLgi7 7bZbgOt8880XF3OLvMWXdXrggQeGu+66KyohhMJ3lIL2LfBHH310uPvuu+PvKY9kOZ966qnhjDPO CJdeemlYa621wmmnnRa23377sPfee4dDDjkkjnWXXXaJ92yyySb9EYDrrrsu9n3dddeNBM2cJPnv f/8b515bvtPHjpCRRhop+BgjMjYwvIyeYy7Ss8vjeP/99yNpRIa8o/Bvj5hX7ydy+NNPP4Wnnnoq vg9JkJ5rrrkmkljYv/766+Hll1+Oz0awEDx/L+bP74477riw4447xtuPPPLIOM/rrbdemG222Zqw Q7oRSMoaoWiUANx+++1hzz33jO/Mxx9/HFZbbbWALCeCiSBcccUVAWnz7nqPurNkAtCdZzePrVUI bLDBBmGdddaJliXruRGhYCgNViZrggKbdNJJo7WHREw//fQBSVhwwQXDVlttFf9P+bz77ruRCFA6 lNh0000XFY9nJ2v6xx9/jNby1Vdf/TcFv88++8QFcKONNqp5Lgfr75NPPomu56q89tpr8bkISCNK zqJ4wAEHxEVzlVVWic2xuljQrFkkxhj9boUVVghLLbVUmH/++aMVhzRsu+224dZbb433+d5CTxGf e+65kTxYlFmP77zzTjAHxs+TQikk6+ykk06K3hnimjPPPDMu1LC79tpro2JIlrxreFZYwXvsscff xr/IIovEaynksrBE55prrtg+paRPHSHm1lzCQ38Hhqy55prxPURAvXNl8Y7BktLTr/YKEoVsmneW OnL773//OzZ75ZVXBnNH8fPOeCcRDsrXu2vuYW6+zT/Fu8YaazR1iaL3t+N9Lov39rzzzgvbbbdd fA8bFSQSUeWFI0cddVQk2okA8Bjpr78R71B3l0wAuvsM5/G1CgFK24LSGivNzhKK3wLG0ncvS5/y TotvcrOyyihM31MMJIWfWP1+l65NoSlWlbaqwl3akhjHn9te+xdEQwiBVcUdXk+0QZmwzLhILeA3 33xzvI0HgkIpj2PEEUeM11Co+sBFzFvgXh4WlhzRrt/xLiAQlDLFwWollMdEE00Ujj/++HgPjCkb SoHSYKUjCZ4HN5ZoEm3XUgwUuwX+gQceiEro8MMPb7Ie4c9SNSbfwakjQgD6nsbMWzQwJBGfySab rObjeG46MvRJcXPr8wSYG3OEYPECsc5TaEaICxmceOKJY7/M3S233BLn4ayzzoqEpSzm0Tw3J77z t9SoIBpJPA+5RUJrSXtDI4326Z+8rucRgGJRipJ+/pPo52d3CQQodsqPQqPc089tttkmTD755HEB oqwsbOLOlJiF1yKXFhfKiCJn9bNckAYxTZLi//4tVlw9j6KjT97ccssto2Ll7WhEKApj4w5liXEh 83hY9BdeeOGmMRoHZY+scPOn47ThxyIVtmDRw5LAxNgoC54Kz5lxxhmbusSq5N7lUmapwoZCFh7Q f9hvvPHGMRzAoqXUylILN6SHpYqYUU6bb755HAPFxCOCGAlzICTCJ35XtaAbwayzX9PR7xQseTgQ YJaz+feeIdTlHAy4pPfev70jDz30UJxnpLJKAAYUjnfccUfYYostohepHAYaUM/rrO32PAJQJFbF UsB91QLorNOS+/VPIcAFSBGVrQoKRzy5SgCSy5kVwlrk2mfpfVPUlCAsiGRF+CkZjqSfycXMyvmz PkVo1WFUiELautoavJZbbrmoPJNVVu9eClpOwdlnnx0vZR1T1IiMsEd5jGlMaYxIwdRTTx0tbspb nDh5M4yb1X3EEUdE4sCC33///WO4AcngNZBwKFQgfoxkaSORMK56MWOKmiegEaVWHrPQhHgwrwQC wC2cXMNCFf4tubBMAPQpEaByUmY9DFv63vvC5QzTatgBqeGyZl1XvUCwFQZCNHmWOkoQNh/jbiSB 9JVXXoneGQTAXHGzi9sjAN6ze+65529dQ/5SAqhYu5AZt755ppgblfLfTvUemOqXNnl+kgjZCTMg Ld6dniw9jgD022Ct8NNXX4bvF5ovDP7bH+3OgO3JL093G7t4tsWMwnviiSeii1p2Mne2RKFaItvc YknhsWIoxaWXXjq6zP1EDngFKE0JghRIynDmfpQQRQEhABYs99XbkULRaUfskuWsbyxi3oVGBHFh XfNgiNfWExbdZpttFhMUJWdx25MUQ6ek9MdiK7nLeI3D+IxZ3BemXO/GzgrnBZDsp83//Oc/0YUP ByRjhx12iK5k2FPssJEoSSHJHYA3rCReutccUMqevdBCCzUbvoEbIsPik41+yimnRAKir0RbSBXC 4jl2gyTXve8pXN4Dz5KA2VEEgIvcsw866KCw77779jcdlKN+ipd7t8oikY9XRoxcQl9HiTwPlrw5 rUcAeLX0m/L2TiGD3ktKl2tfKAKeQh/eO3MssQ/JE3c3l/7O/P3I69hwww1jCKGe18VzzYFcGvd6 PxCh5D3zd8fb5O/DOBIBkPuy+OKLx/wQobj99tsvvjM+PVF6FAFg8Pdda9Xw7fzzhMF/+SkMXngB LC6tiff2xJekp4zZ9qCbbropKlJWqWQxmegtCauUgpSNbBGmICx6kvQszBa4TTfdNL5j2qYkWUn+ jxRIDOQmZcm5zyLKC1GWaiyS9WQBpVzFULXB2pKQWJbmiARrkiK2SDciKW9BzPSGG26I1jqllTwg FmIEwaILA4sulzxCJRxi8YWjrZUUMOtL+ODBBx+MJEJYwRgRi3nmmScqct+xhhEC45MHwJrUjnFR ALBixQsBsI6FKYQEkvem1vjtOpB4lq4xf0nJIVIIh7aQF/NUjqEjHQibxDM7NjpKkB+kqVY2PiXV 3FzxUOgfhdlaaS6+TaGm5FKksp7wTlD4lLB8EkQFqdRv8+Kdt5ODh0x+BRK10korxbAAQoMYev+F XChl7w2CkBI+Pb/WPJqLf/3rX/E9ILwG3rVE5pBLuRz+pspxf2EomCEF3l+hJTttqtJTdEKPIgAm edBC6Q83yshhsB/+rPhnIahncdX7I8jfdw8EWAMsMIujhaqRRWDrrbeOSqjsfpbQxIL1XlnUxTjL SWmpXQu4xdF3KWGuvDBT9JQqhVsmBa7hvkwxdoqzFklgmafQQnmGLIosy0bfe0qaC59ipNRZ3uUa CQiF79M4EhYsMi56z0kJedzcFmf/h53vYJ3CK2kcXO/Gl+6jTHznOp9ym+ZM6CC1YawUuPGXf6c9 Wwi53JE2Cq6MgTZY1IgZ70MKYyTsWLSko7eGUXjemVrzwUuDANX6jsK0x7/ReSy/A94p71Y1UVJs nAiNNCLc/Yhoea6QNn1K7wHrGlGAq3eH14WYf2Sq/LfD81Luk1oY5jGFDFKfvEfpnfM771A54RVR JYhHWYSQUmJn+d0oX5NyWZKnqxEcuuo1PY4ADELpF1b/EMVe5bSANrLQd9UJzv1uHIHyQtpoBnC6 p/oOldtKC1OthTp95/7qM1neCKo4Jes5FRgyovK11Ux/i6WFj7uTlVRLWqs0Unihuazy8jjKWKTn VJ9XD+vURroujTcW9VLRs5Bq2+Xn6qftgdz0XNRl4TXxqSXlkED1e3kCBx98cCQHHS0tzUdbv2uu j9z7wizmLO24SNfyhvBeNTfP1TZbmuvq30TVa1Ke03K75fHyfvAo6C8vUPm9L5Pb6t+AqotIuDlr Tmqt+zwKiAlSU96O2NHz3Vna63EEIC2ejS7wnWWicj96HgK8B4ro2BffGqVjAWXhs3Q60lXdlWbA /m75ClUrvj1jkOTZHYR7XrgLOSq7x41N/D/VeugMY+VtsVvFO92aNVsoqC0ih4AnSJGqnvC30yMJ QFtejHxPRmBgI8BCsUBXF+lG+tEawtBIe13tGp6TtNe8q/V9QPdXOKlRC39A96Ve+whcI8Wq6rXT 6PeIxsB8XqP9GlDXdWsC0O+5F0KRKhrC8IW7f8Ei0aNS87rfY0+GIqgZilM6Qq/ZitKV7ayJPaAm KbebEcgIZAQyAhmBjkZg4BOAP4oSq0UCShj2z0SQv8lPRTEP5SmVYpUsMtxfFdC+/+HP36tsRlEX R/yG3kUs0Pe+Uw5S6U732aY0/HCh3677hn6//Rx6LTD/nwSA/PpbCN98G8IYo4V+jzwRik2qod+7 H4VB7isSfEYasaPxze1lBDICnQQBCWVqOsiRsDMhJZelA4c6opv2mKdzHiSHtiSus2vCNr/WFKOR WClp0I4Tuz/aIjLvJQLyLiXXuqQ4Gf2S6+QG2K5ZFrjZtml3hu87IndKQqZku3SQUK2x6JN4v7g+ F735EhbzfPfpv7H4fzm3Q9ti+sZYzhGQ+S8/QCVN2xPL2MPAGFN+RGtzZdoyF//kPQOVAPS778HQ d8utQ6/Flgi9Tzqq5rj77rJ36HdXsafVSWxffBV6LTRvvLbvhZeHfmefUyj/opiKrR8KOxRKvte2 W4R+p5wZwrffh/Bd8Rmm2ELV5/fQa6vNQxhh+NB7jwNCr1n+LFXa7+HHQt+tdwy95vuzzd47FH88 G68b+i6/pqPX/sl5yM/OCGQEWkDA1kDb8mypbLSAUbU5FQVtX6Q0KF1bzVT+S0mWHTEBc845Zyxp KwGxHgGwDVPCnQJIrSEAdi9QiDfeeGObCICaAxLd7M+XC5AS5RAixELRK+GTKgGgMGXt2yZIgXZE kpw8DSf62Q4It3L+gWRFW1uN1bNdY97kMDhTgSJXQCj12/5+lf0QAgmwagoIddiVkAo8mWPvAAIk xq9WgPGmXTYIQzpIym6Z6tbajnhHOlMbA40A9LvrvtB3m+JkpZGKo0k//6JZDPq9+XbovXZRnWnz jUJ4/8PQd7X1Q98Zpw+911sj9Ft28RDuuDf0O/GM0OuKoijGoMUe/sJq7zdzoeALy7/vUquE3ltv GsIiC4ZeIw4f+t5QHEDy85/7RMNb74S+hUegeJuc0/r/z0cmZBX/lVncmSYn9yUj0NMRUA9AASH7 t5VVrleYpiW8lPi1m8G2tEUXXTQWorHtLB3QQykgGciGLY+sa2SDgrF9kJJ2MiEFaPvdEkss0fQ4 yZqUvqx1pW5VPEyi7oD6BxST7ZMUle1zc889d9zZQSFTUixc2e6pGiDLF0mh+ChrhIIFTGFTXLwN tqxRirY1ql6YajvYJmr7KcUmIa5cWEcxHrF15XrLZaddqy6C/fTlffhpHKzriy66KO6bt4++Kqko lpMAa20/rTU3ihnBH8bGkQiAuXAKphLSSAlrPp2q6QQ/iYG2LNoiCQu1ELwnyZuhiBNr3pykbYee 71Ai75T+Gw8yZctgegdc6x3wfqg10N1loBGAMPqooffNV4Zw139Dvzvubh7XIgkjTDZJ6DV2sX2j +PSavShW8sLLf1r73PrjjfvnvyeasKmNXimcIBxQfN9rgr+26QgH/FX6P4xRuLpuuzb0u+TK6Alo knwmQHd/x/P4uhgCFm6FYez9V8xFrX5KIFVQbOtwuHURAJYjRcCqlCyYyuiqPUCpUOy2ga244orx HAJKhdJ3rK0yyixHBIArnmKlZChZJyCyZrnQU017dR5Y0ixm1qXSydzXCACXeqqQqD0FkRAMWw2J wkYKSSko5SRGRaRshSPasqdexUqkgbLUX9ixWhWmYq0r0oRwUOz6R1IJ5uYO0Wlp/zviQElWt915 LgLiuUIb6hc0IhS/wlFIEmxZ47wolDJ80rkRiJNCQ1zyPio56r/CQ+aU5V8Wc6af1fLJ6hEICaRQ gZ02yGX5lEYEzL2NkphGxtlZrxloBKDX9H+eOd336j8LNEQpYvH9PvrkT+u7+OPsNelEoVfhwu93 +TWh3+fFUYyffR76PfVs4arf6v/v4aqntMX8kYWy+H3ZlV+26oUGyI9/WfyddUZyvzICGYFw7LHH xlKytvNRvGVRUEZ9+fLZDJQCS7Ceh4ACo1xYd5QtyzLFsilzSoh1SMGxlD1LdTlKlUXO7U4QAsre PbZb2naZTvqjzNN5EBScokT6x4qnyFPlvlTwxmmIjlLm2qaokyARqZS0YkwUVZJUBll1PdX23E8o OBY8MsH9rXqiqosqR5Zr8rd0bkK9MxWa+57iNqZyvYp6rzKPApGT4dwHWGhHxcVU1S+1oTJnEvOI rFH0CiLVklRcqxzHR5zK5y1op3qIlLbqYVBvXF3l+4FGAJoAKSnlfvfeH/oecHjhli+S90YdOQxy bXHedzEhSEGv194I/U4/LfQ69aTQa945uwqeuZ8ZgYxAOxGgkK+++up4Ohy3rpK/4rmsPZYbFz2r t7xIu4dLvB4BkATIta/SHSWtDG9SFFzLrF/WoIRByp6LnSAL5Tg9r0GqRsiT4NyHJFzkLFriNEHK lxLmptcOb4Hwgz7bi8/1T/Q91S0wRpa7PjmPwDMoxSSejaSIbSMiiQBwfWvDtdrwDG51HodGhVJt bYKf67nz5TPUm4NyP5AXSlmNBWPkMYE54pIOn6rVb0obLt4TyZDi9sccc0zdISYPULpQf1tDWOo+ oItdMPAJQAmgXssuGQZZ6E+3VBiksOaHGjL0+/qb0LuI//facO3Qd5ihQr+rrg9hq826GKy5uxmB jEB7EBCbZtn5WOQpFwqBxSuGzzVe9QA0ci58Kq2sb5S9/1M4foqZi9VT2k6zS5nyrpVlTkG5loIU RqDMKWI1Fw455JCYUEfJi2WncAVvg3ADMqF/e++9dwxtICBpVwJSQvykDI2Lh4HnwLhdhwx5vj5T /MIBzk2QmzDDDDPE32mTMvNv3pB00h0yUi3529zcwEE/jFdf0omT9eZSn4U6eBn0uZFT9uyAMI/C LIgQbJX4hY86/cIIkvyERPTf73lCEEHkjXtfKMBcybuQ3CdPoCXhXTCv8gCQDImG5q6nysAnAM7s lq1PJOSNOEL/2PuuYGWk9x47hT6TzBj6nlrUlt76LxJQ/FHEbXy1xO9tDyxL8ZL0J55v22CSYqdA DEHkXICe+jeQx93JEUhEQHyYAmBtlhO7Gu2++LQ4Pxe/ePhll10WlR23PE+DA2UoLhY5C19BGCWV JcSl5EAEQQxZO+L3PBNc7uLflA9Xtj5S+giFfjpgSPhA7oDQQzrxT6xcmIESTxn5rHYkh0dBGASR oOjc66AeMXHKXZ/F/W3H02dKUt6Ce52qJ7seEUFSKPJU/74lrFjDvB/OakA2YKRdFnYjYvuckEkj NfQpYcrdT/kRSAM89EEVPnhKjuQZkAuBYCBeSKBDm5TGTvciVQgDb4l3pHwqZtWTwYvjeuNEyPyU jNlTZaATgF7LF66y2Zo/haz3bjsUCX7j/zkfxaE9va86vyAM/6+we8n4P2ivv8f/EYZD9g29Zpr+ /+dSjsE554V+Cy0Yeq9UxMi4tpYudhLMMWu8pt+dxY6Cwn3W78OP/vRAZMkIZAQ6LQKst/ZISvhi TVISLEBlX1NCG+VK4bBEk9udUqPwEQAi9p6OvKWU/N/JdpQvUoA8UDIOTUIEeAic9EcJa0tcntVK Nthgg7iVzjUsYGECCkubFLtkQsTB892Xsvd9b5tbUnRyDyT8JStfhrxERv1BHoy7nO3fnDdAH5AR fYAJN3sKT5Rx930KjaTf+x1yZIyNVNIzBjswjD0paVjIe9A/BExOAFx5Q2AujOEnUuNUx3SMsD7w DvAmpOS+NMZaoQzEQ2Kl8fGi1BL9qo6xPe9eZ7134BMACrwF6bV8/2yz12IL93/1RBMUBGGCmi30 WmPl/n7fa9P1Q7/nngrhjaIaYHEKYCjqB4Xi+X8eJVLI2+8WWxI/Db0237AoTFTxFHTWGcv9yghk BNqEAGu87DlIZ8SXGyu7kCkpH5KUdrq2eq//l4/lLSvB5nYvVEs8VxWnvpYVVLkP5TLHYu7VuDvy QcnVEn1FDhzh7NjrtAuCcq0m3pXv5xVgPfOk1HLx20bYiPLXpmdVr61V8hoG8803X3/D0P8q/tor 44z4yINAsoyxWte/uVABUsBDg2ClXRNtetm6yE0DnQAMTFx6bbJeoez7r2ZVfj7F3ysUyj9LRiAj kBHoIQgIHdhhQdk1kjeRYJFcKBwg4VDMvTOLraNyH3gLqlsBW+q3rX9yQOw44AXq7tKtCUB3n7w8 voxARiAj0FoEWM8K3bRWEIDybofW3j8wr+c5QAJaK8IK5QJPrb2/q12fCUBXm7Hc34xARiAjkBHI CHQAApkAdACIuYmMQEYgI5ARyAh0NQQyAehqM5b7mxHICGQEMgIZgQ5AIBOADgAxN5ERyAhkBDIC GYGuhkAmAF1txnJ/MwIZgYxARiAj0AEIZALQASDmJjICGYGMQEYgI9DVEMgEoKvNWO5vRiAjkBHI CGQEOgCBTAA6AMTcREYgI5ARyAhkBLoaApkAdLUZy/3NCGQEMgIZgYxAByCQCUAHgJibyAhkBDIC GYGMQFdDIBOArjZjub8ZgYxARiAjkBHoAAQyAegAEHMTGYGMQEYgI5AR6GoIZALQ1WYs9zcjkBHI CGQEMgIdgEAmAB0AYm4iI5ARyAhkBDICXQ2BTAC62ox1wf46d3yHHXYIG2+8cZhjjjk67QicHf7N N9+Efv36hV69eoUxxhgjDD744J22v23p2D333BM+/fTTOLYFFlggDDLIIG1ppuY9Tz31VBhppJHC xBNP3GFtdrWG3nzzzfDss8+GKaaYIkw77bQtdv/xxx8Pn332WTx7fqihhmp4qO+//35w75RTThmm mWaahu/LF2YEqghkApDfiXYhcOWVV4b77rsvKs1ff/01tjXkkEOGjTbaKMw222zx/717947XLLXU Uu161oC+ed111w0vvPBC7L8+n3HGGWGeeeZp82MfeOCBcMkll0QliwSRwQYbLKy66qphscUWa3O7 7bnx/vvvD3fffXd45ZVXwosvvhhGH3309jTXdO/mm28e2/UOHHPMMWHNNddssV1E68ADDwx//PFH +OmnnyJGs8wyS9AO8nXZZZfF9vzbfPzwww9h6KGHDrvuumugAC+++OJ4r3PffeesevPX0nyZ2zPP PDP06dMnbLDBBuHee+8NH3zwQZh66qnDVltt1SE4fPzxx7GP2rz55ptbbPPRRx8NO+64Y3jmmWfC 9NNP3/DzP/nkk7D77ruHGWaYIVxzzTUN35cvzAhkApDfgQ5FYKyxxgp33nlnGH744cP6668fLeYT TzwxLswIgMWZxXnLLbeECSaY4G/Ptoh/+OGHYbzxxgvfffdd+PHHH6MV+eWXX4bRRhstLv7vvPNO VJyeRTFr75dffmlq78knn4zXjj/++FFhEIuqZ1MqFEc96du3b/joo4/CSSedFOabb76oJIYddth6 t7X4/aijjhpeeumlwCrceeedIyb//ve/o5dh0UUXjeM2nhFHHDE+jwcCHrAwDni4n8CSkvQ71+kv 65ESeO6558I444wTxhxzzPDee++F4YYbLmJIUWrb/5MccMABYcstt4wE5Lfffvtb/ymXl19+ObY3 +eSTNzT+//znP+Gqq64Kr732WnwXjHXZZZdtET8Ke5RRRokk4JBDDonj928K+eCDDw6nn3567MMI I4wQMdtvv/0iIZtrrrnCgw8+GJ9lnlx7+OGHB0QUli0RAG25juXMA2J+9txzz3Dqqac2jdP4tQ2z mWaaKf4e1rAceeSR43v31ltvhRlnnDGSjrK4ZtZZZw177713xCPJ77//Hi32QQcdNM6ROdGX7bbb LhIZ8/n000/H/niHkyDVr776akAqJp100vhepHcBxnfccUck3t4DJEr/tEu0yRNhHPqaJSNQC4Hs AcjvRbsQsAhTZha27bffPioA7n6KjDz88MNhjz32iMr1xhtvDLPPPnvT8yzk//rXv6JSG3vsseMi qz33r7jiitGSYiEJHVggXc+tSjmcc845YYklloiLo4WOC9VPiy3r86uvvoqLn+dSHAsttFBD47zt tttiOwsvvHBUNmW59NJLw2mnnRbWWWedqETryVRTTRVWW221wOreaaed4vi33XbbqPhZyiussEIc 11133RW+/fbbsMoqq8R+Uqhff/11WHzxxSN5odiMj0X5yCOPhPXWWy8SLWNlwSNLlAqLFmaUDYVB kbsX/mULN3lqEllK4zjhhBMiAZpsssnC22+/HfH1u3phApjpNxJmDPvss08kYOayOTGeDTfcMFx+ +eXRmiUU5Pnnnx+VOkULKyQBwdltt92ix+KLL76I411rrbXCZpttFsyJ8VGAr7/+eotTQoEihDxR E044Ydh0000j+UieKR4b2E400UTxOXPOOWc466yzYtu8C4io99z7StneeuutkWghpMaCrPk9vCaZ ZJLYl3fffTfe613kBeIJ80wkAelBwtyLHCJvCMHSSy8d791///0jHt4jpIRnBb7E3Hu29wZR8vfj 72KZZZaJ75m/oTQOxPuiiy5qIgf13tv8fc9BIBOAnjPXA2ykFu4LLrggWiSspYceeqjpWeKbFBMF YVFNwjrnhl1jjTWicrKYbrHFFnHRt/CKT1NCFNgNN9wQcwfS/RZPCvKUU06JC/R5550XWG4s9tVX Xz1aP9zHFlWKlxLWVtkSroLhOWLXFmEKEgFAHPQxCUVtbKy0RghAUmop/PG///0vLuTJI8F9q7/X XXdd9HBY+OHIsqRMDzvssGjhJZd1akfcd8EFFwwzzzxzHBvX9sorrxx/Ui4sd+0iSUgTz4x7YEq0 WRXXIQ+wphApM2SL9bjJJpu0+O4gW+OOO268Rt8pd/NBEEFKLpENzzZWH0rePHouQgMPCpjAlwJ7 4403orJzn7Gy3ClvChaR8r5R0MgK67ue6BuS4530nnz++ecRXzLddNOFY489Nvafst9ll12i5wFx QES9C9dff318NjwRtbXXXjv+Xh8QCO8o8kopE3NmXpAxJO2oo46KBIvAhDcIYUWaWPW8Z4kA+L0+ eW/N5cknn9xEAOCFXMAJGeI98f7CHeHQnncfvuYQSUIQsmQEyghkApDfh3YjYCGn4C1YrFTKNAlr iFvSolq2OLlRLd6HHnpo/L3Yr/hsEsqbkiAWwLLy9nvPkGeQlBPLjLJhUbvWwkzx+CRLqSUC4Dni 9cgMoeQt1mUCwPpHVuold5UBpRhcb5wUD+JD4egLRYZQCHPAwidhdPvttwfu+uTCh6N7Ex4sfAqS 0vNv4RHPggvldOSRR8ZrWX+sSMo1EYBaE44A6AfSQwlS5BQd5V5PKCOhG2IMlHUiObxC3O5lAsAz cO2110ZL2e/1+9xzz42WLnJHzC1h9ROYCSuQlFuSLH7PbjRXw7uKTCJFPAk8FYkAsJIpWljqm/cs jSvlKPAgEBhT3sYrBIUMeGd8kFhkmOizfAbeJPjCdMkll4zfeV+9m/5ukFd/Q55PzDUCiDDqD++Y MFsSfx///e9/Y9/NXUq8fP7552OfJXvyxnmfU+ii3jzm73seApkA9Lw57/ARWxxZSeLKzSW3uaas gFlIFrmzzz47Kllucgt6Oes+Lb4sQJZNim8agIWNlVwWys/9lAE3ssWRNU+JsRzrSVL+rrPYJmWW lBermAVIYc0///z1movf6w83PWudIrbAIynIBBG/Xn755eOzhEMSCeIWZ0kaB6EcU8wZlvoKl0SS UkKc74RFuM3lByBAEv7K84JUuM7PJBSRto4//vg4dmPm2qY86gllyHNBxPDFpPWXsE6NPZFC5KDs LfBcMXhKUyIcT1CygNM8GGt5blJ/9F+72mhUPN/7IbxC9tprr6h8EQP/FpLgRucJEq6iaAnsy33w 7xSe0Qdho0RMzG/K6melIxu+465HAoW0eAW8GzBPIRZtpjmGg7wZHgXfH3300dE7k8TcL7fcctHa 5xlxrZwFWOgPr4r5N15egFr4NYpZvq77IpAJQPed24EyMguVhckiSmGL1YrbEv8Xt7SIiUuzgrmn xTEpUJYm1ypXvgXNwpWUrdAB6x5poHgtyFz9rHKuUFZlyq5nVVEg7reIc30iC5KqWNKIxk033dSi MmNpbb311jH8oF19o5zLXgtWteeyGhshAE888URU+Kw347QIw8szxJGN7+qrr455EhSGBVyoAp4s e8oIhpSL/gl3EJYfxb7NNtsEmeQ+Fnr47LvvvpH4sCpTgiAlLt6trSOOOCK6txEE4zVX8BKKYf0L wyAengc7FjkF1pLIiZArIKnNVkA5IckinXfeeYNPVcwJtzVFyM1+0EEHxf9TauL6+nPhhRdG61mb +govZIKYT9dJsJQLQBF6Z1oSBBPWSIo+GR8s4Cxm7t2kaFnOMEaAzDkSJjbvd3IwKFmEVQiB8qVs kbfHHnsszqs5hSsMWeS8Gdz75kMf0tY9XhnvCPLE28MDwXI3n7w65th77SfPGiIrXAQDfwO8O/6W 4MQzoZ9c/XJL3AcXIQ7kgCfC31+WjEAZgUwA8vvQLgQoSG5xCijFalODvmPlsKIs8pKgXJMsHorF YkW5c3NyzabMdC58ljZryr8pBC5XbVKkyfWvzXI2thiyhCiLMEuUpWeRrmfJ8mBYJBEVY5F5brte WShXViol1aistNJKsb/Jm6Evxszil42OZFAorqGcjd93SBEXsDFQfhQxpeM7ChuuYsn65F7fyzHw HH1kyVNwFB0PCyJF6brPWOUKpJCCsbCmKR+KhcLlBfDvRpIneVcomeOOOy4+z1zXExhTYJRSChfI yOcmT9aq9wQREjKgbMvJiP6NZMCo+l1Lz6asvYMESXS/8JH2kDtjMAd+Up4UNsx5A3g1kEz/11fv Is+LNnm05J3oLzKAaCBiwi6IjT7KO0CuEDfC+jd+RBUexslToH1KHsFBBrUt0dIneVK8Q4mEUvZp t0saBw8TogpP70bZq1JvbvL3PQeBTAB6zlwPkJFKGGtuf7+F3ULZkoifspq4gSmvcoIUC6aWUIAt CUuwnjVYvZ8FLl7dkojltyb+bzFPbuFa7Sb3fvouZcOn/1cttjQmSiQJj0cS37MibR2DKWs+eWNc w0uDMDQniEgjyrvW/ZLVkKZGBSEp9z3dx1OShGehOaHQWqvUvFspx0C7+lwWnqTylsDyd7wbZbHP vyxIqk8SSaRJmsNU6McniaTDslDyPknK2/l4DJLwuPgkQRISyWh0PvJ1PROBTAB65rx3ilGzerg0 WSqsHFZkNa7fKTraRTrBGpWJrgqdLWSIWT0C1kWGlruZEcgIDAAEMgEYAKDmJhtDgAuVqztLxyDA dZ7yBDqmxdxKRiAj0J0RyASgO89uHltGICOQEcgIZASaQSATgPxqZAQyAhmBjEBGoAcikAlAD5z0 POSMQEYgI5ARyAhkApDfgYxARiAjkBHICPRABDIB6IGTnoecEcgIZAQyAhmBTADyO5ARyAhkBDIC GYEeiMD/AQBpwq2UAdF5AAAAAElFTkSuQmCC --_004_CY4PR21MB0854C26DEDFDA2C253BF548BB3740CY4PR21MB0854namp_-- From nobody Wed Feb 27 08:22:12 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1814130FF9 for ; Wed, 27 Feb 2019 08:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnWqR-wFaLME for ; Wed, 27 Feb 2019 08:22:08 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 3F9B2130FF4 for ; Wed, 27 Feb 2019 08:22:08 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id l5so18646083wrw.6 for ; Wed, 27 Feb 2019 08:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rubzp6333Qedw0C9hT9rP5BL6SdyKA29csm59fDshXs=; b=gfsPSsIiNWao3YtFWFiReHFKv5VTnwjcHyPskj3Sj9dQ6WyrKeOO5EeeXnqZbfeEFZ CUJIBwamA5qupvoBRt159AG4Wjm0XLGhcpBHec1/iXr5soGApOCDqfzdHp37oSA1U+u2 +s8aiGAJX39t5kWteBg3tPi6p2Fx2xtlCZSOsstTqKSVDmjrTqhxxRtZaZgxaJvqp7Hh HcKvSNdB0rci4s6nbLSrmRjkhw6/AFf/jkZSE0r2NoRwK1pgE2y6krmVpqJ8OGqx3aSK 92vW5CYL4iEIbIdguuzak+oCqOj6TJSJvOS+MRYCVXma9CIOFmYcH5pwLsCd+2TZowP8 v0Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rubzp6333Qedw0C9hT9rP5BL6SdyKA29csm59fDshXs=; b=NTzuV75wGT4aFUz9YjoF/I6/7k3OR9hPXLDQJkpIj3jiC/zimMTNcTQv6E6kw2vJsO VSRZVPk8esEGebeZr5H9oAB9nzv7GW5Xm1Ef5cjuiSLG24OztDgrb7rtwQg/5Ofn4xGx Gd64CUrhEZ1U7Fy4aywxITQszycuhRev08vyMe1jPL0l1B4sShjN0z03qVE4LzV/+5eM qfr6nzTpgP7BY6mml+9/eTLJn52LNtEiduq7vVuDGLbWftld1nY/hSpzvXGvFhGZXLC1 MG6Hp35wpgPbSSV39njoHR+bvHa5Q+CRemcj95C3CAo3Z3S/GP8IGxUdUFXng2MrIRBj HXUw== X-Gm-Message-State: APjAAAWkVr2VcyXeYGv7njv+OVn0ACkhi5Bl3ycmPzB2swHaq4bJaEBb UfCljRmVjf8xctuqCqaQTYvLk75FnBIQXDNvA1SO9w== X-Google-Smtp-Source: APXvYqzptXSQWYKSwjCPtsIhw0SLoY9Y3enQ5L8DdXSkxdQGFCI2OGWDmWI+HFhSy93mEQ0V1lIFgpNbnxKE5Xlxjlg= X-Received: by 2002:adf:fa51:: with SMTP id y17mr3180972wrr.233.1551284526353; Wed, 27 Feb 2019 08:22:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 27 Feb 2019 11:21:54 -0500 Message-ID: Subject: Re: Unit test proposal To: Dirkjan Ochtman Cc: Kenneth McMillan , QUIC WG Content-Type: multipart/alternative; boundary="00000000000023df890582e2937e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 16:22:11 -0000 --00000000000023df890582e2937e Content-Type: text/plain; charset="UTF-8" This would be interesting, but I'm a bit unclear on exactly what the unit test interface would be. And are you thinking of interfacing at the QUIC transport layer, the HTTP layer, or both? Agreed that logging and replay is extremely important in debugging. The closest work I can think of is QUIC-Tracker, which I believe is somewhat different than what you have in mind: https://github.com/QUIC-Tracker/quic-tracker On Thu, Feb 21, 2019 at 3:22 AM Dirkjan Ochtman wrote: > On Wed, Feb 20, 2019 at 2:05 AM Kenneth McMillan 40microsoft.com@dmarc.ietf.org> wrote: > >> Please let me know if you think this seems worthwhile, or if it's >> redundant with any existing work. >> > > It sounds useful to me. On the other hand, I'm not sure a > language-independent API is the best form here? It seems that languages are > sufficiently different that a single API might be hard to implement > sanely/simply across different languages. Maybe it would make more sense to > define a file format, similar to what's already been done for QPACK (I > believe it's called QIF)? It could probably be based on how Wireshark pcaps > are defined. > > Regards, > > Dirkjan > --00000000000023df890582e2937e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This would be interesting, but I'm a = bit unclear on exactly what the unit test interface would be.=C2=A0 And are= you thinking of interfacing at the QUIC transport layer, the HTTP layer, o= r both?

Agreed that logging and replay is extremely impo= rtant in debugging.

The closest work I can think o= f is QUIC-Tracker, which I believe is somewhat different than what you have= in mind:=C2=A0htt= ps://github.com/QUIC-Tracker/quic-tracker

On Thu, Feb 21, 20= 19 at 3:22 AM Dirkjan Ochtman <dir= kjan@ochtman.nl> wrote:
On Wed, Feb 20, 2019 at 2:= 05 AM Kenneth McMillan <kenmcmil=3D40microsoft.com@dmarc.ietf.org> wrote= :
Please let me know if= you think this seems worthwhile, or if it's redundant with any existin= g work.

=C2=A0It sounds useful = to me. On the other hand, I'm not sure a language-independent API is th= e best form here? It seems that languages are sufficiently different that a= single API might be hard to implement sanely/simply across different langu= ages. Maybe it would make more sense to define a file format, similar to wh= at's already been done for QPACK (I believe it's called QIF)? It co= uld probably be based on how Wireshark pcaps are defined.

Regards,

Dirkjan
--00000000000023df890582e2937e-- From nobody Wed Feb 27 08:45:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7071310D7 for ; Wed, 27 Feb 2019 08:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uhasselt.be 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 i0CeARuLP63u for ; Wed, 27 Feb 2019 08:45:33 -0800 (PST) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 687E41310CD for ; Wed, 27 Feb 2019 08:45:27 -0800 (PST) Received: by mail-lj1-x242.google.com with SMTP id g80so14554622ljg.6 for ; Wed, 27 Feb 2019 08:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4k68dAKCLV6ZJnv14YyXLQitw4WShqSNTUiT1Slq2Ek=; b=jvsVKIN7LVXnnICM/so1ttJx9dMbdOBWw2rOfOFPFHwMlcaCq4pNpAs8MxF4Nt9EnG 5R10lRG4LZ8y1aOxrm6cA9WBUZKFR/MBiQhZGDugub1F5R9UGTeTkRZ+OTZDHzOND1Xh lIVbwjLzv8p1uhn+oRZnyb7vo6EaU/EsNmI3Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4k68dAKCLV6ZJnv14YyXLQitw4WShqSNTUiT1Slq2Ek=; b=UVNIe8HOz1MPL8DXRaAJkTz+EqeWagiXvgLfbUfc7PSTmpl6RD8QRhx2HMGGlJyuEO 0thR8682Kr1OW71QKZ7OJq3uj15xJ7DyCuyidfI2fI8iRneQWYghgxoPT7k5UXYrIrqv AqvEmKdBadMFiVsDmTRzEWYpRsMxpTEqw3/V8tJOu/Bml6InDg9tfsbp9BttKUeWFlX3 +K3McpD1XzNdytpNgj7PrRyPtUi2gtljgkKXujkJInec+2tmCUsh4xs4Awz51MgtrVX2 FlmxYk87+ZxzzLkph6uFIYPjE+jpxD0Vacv2wesAKksOw7Nepecpxj9Fre3GXIawwX9n tDYA== X-Gm-Message-State: APjAAAXlYK4KlrgzyYRYJ9YMNiLpkcG0gLSRbJdK7mcJb/g/7D0mVIIG 6U91tOd337GfYp3nw8r++q+6nnk3LTj/yyprpNXkkQBJNhY= X-Google-Smtp-Source: APXvYqxOFRmT4KlD8TZjGUjIqA+gIB4DsJn9qju4c6TbcewwpihRDLzTJh69uRERvzaynAL5It+dsx7jr8pF/XWh2fk= X-Received: by 2002:a2e:9cda:: with SMTP id g26mr1961176ljj.48.1551285925094; Wed, 27 Feb 2019 08:45:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robin MARX Date: Wed, 27 Feb 2019 17:45:13 +0100 Message-ID: Subject: Re: Unit test proposal To: Ian Swett Cc: Dirkjan Ochtman , QUIC WG , Kenneth McMillan Content-Type: multipart/alternative; boundary="00000000000082d7a10582e2e64f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 16:45:41 -0000 --00000000000082d7a10582e2e64f Content-Type: text/plain; charset="UTF-8" Hello Ken, We are working on trying to get a standardized logging format for QUIC set up (see https://quic.edm.uhasselt.be/). The idea would be that this allows implementations to log endpoint-specific information (that would not be visible on the wire) in a machine processable way. One of the envisioned use cases would be to have a testing client execute various scenarios (e.g., what QUIC-tracker is doing) and then validate the expected behavior based on the server-side log output. I have also talked about this to the people from RWTH Aachen who are doing symbolic execution analysis (this paper https://dl.acm.org/authorize?N664187 ). He thought the logs might be used to obtain what I think is called "belief states" (I'm not at all into symbolic execution) and use that in their analysis as well. This is certainly far from a full-fledged unit testing setup and doesn't offer all the features you mentioned (though I think replay would be interesting/possible to add if we optionally log full packet dumps as well). However, I do see some synergies. If you agree, feel free to contact us. *switches hats* I am also working on a JavaScript based QUIC implementation (yes, I know) that has only limited testing atm. >From that viewpoint, generic unit testing would certainly be interesting, though I have a hard time imagining how that might look/work in practice. With best regards, Robin On Wed, 27 Feb 2019 at 17:22, Ian Swett wrote: > This would be interesting, but I'm a bit unclear on exactly what the unit > test interface would be. And are you thinking of interfacing at the QUIC > transport layer, the HTTP layer, or both? > > Agreed that logging and replay is extremely important in debugging. > > The closest work I can think of is QUIC-Tracker, which I believe is > somewhat different than what you have in mind: > https://github.com/QUIC-Tracker/quic-tracker > > On Thu, Feb 21, 2019 at 3:22 AM Dirkjan Ochtman > wrote: > >> On Wed, Feb 20, 2019 at 2:05 AM Kenneth McMillan > 40microsoft.com@dmarc.ietf.org> wrote: >> >>> Please let me know if you think this seems worthwhile, or if it's >>> redundant with any existing work. >>> >> >> It sounds useful to me. On the other hand, I'm not sure a >> language-independent API is the best form here? It seems that languages are >> sufficiently different that a single API might be hard to implement >> sanely/simply across different languages. Maybe it would make more sense to >> define a file format, similar to what's already been done for QPACK (I >> believe it's called QIF)? It could probably be based on how Wireshark pcaps >> are defined. >> >> Regards, >> >> Dirkjan >> > -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --00000000000082d7a10582e2e64f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Ken,

We are working on trying to get a standardized logging format for QUI= C set up (see=C2=A0https://quic.e= dm.uhasselt.be/).
The idea would be that this allows implemen= tations to log endpoint-specific information (that would not be visible on = the wire) in a machine processable way.=C2=A0

One = of the envisioned use cases would be to have a testing client execute vario= us scenarios (e.g., what QUIC-tracker is doing) and then validate the expec= ted behavior based on the server-side log output.=C2=A0
I have al= so talked about this to the people from RWTH Aachen who are doing symbolic = execution analysis (this paper=C2=A0https://dl.acm.org/authorize?N664187).
He thought t= he logs might be used to obtain what I think is called "belief states&= quot; (I'm not at all into symbolic execution) and use that in their an= alysis as well.=C2=A0

This is certainly far from a= full-fledged unit testing setup and doesn't offer all the features you= mentioned (though I think replay would be interesting/possible to add if w= e optionally log full packet dumps as well).
However, I do see so= me synergies. If you agree, feel free to contact us.

*switches hats*
I am also working on a JavaScript based QUIC i= mplementation (yes, I know) that has only limited testing atm.
Fr= om that viewpoint, generic unit testing would certainly be interesting, tho= ugh I have a hard time imagining how that might look/work in practice.=C2= =A0

With best regards,
Robin
=

On Wed, 27 Feb 2019 at 17:22, Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:=
This would be interesting, but I'm a bit unclear on = exactly what the unit test interface would be.=C2=A0 And are you thinking o= f interfacing at the QUIC transport layer, the HTTP layer, or both?
Agreed that logging and replay is extremely important in debugg= ing.

The closest work I can think of is QUIC-Track= er, which I believe is somewhat different than what you have in mind:=C2=A0= = https://github.com/QUIC-Tracker/quic-tracker

On Thu, Feb 21,= 2019 at 3:22 AM Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
On We= d, Feb 20, 2019 at 2:05 AM Kenneth McMillan <kenmcmil=3D40microsoft.com@dmarc.i= etf.org> wrote:
Please let me know if you think this seems worthwhile, or if it= 9;s redundant with any existing work.

=C2=A0It sounds useful to me. On the other hand, I'm not sure a = language-independent API is the best form here? It seems that languages are= sufficiently different that a single API might be hard to implement sanely= /simply across different languages. Maybe it would make more sense to defin= e a file format, similar to what's already been done for QPACK (I belie= ve it's called QIF)? It could probably be based on how Wireshark pcaps = are defined.

Regards,

Dir= kjan


--

<= td style=3D"font-family:Verdana,Geneva,sans-serif">Agoralaan Gebouw D - = B-3590 Diepenbeek --00000000000082d7a10582e2e64f-- From nobody Wed Feb 27 11:10:35 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB7D13102A for ; Wed, 27 Feb 2019 11:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.111 X-Spam-Level: * X-Spam-Status: No, score=1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122] autolearn=no 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 5Ml67bk4F3fH for ; Wed, 27 Feb 2019 11:10:31 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810098.outbound.protection.outlook.com [40.107.81.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1605212D4EB for ; Wed, 27 Feb 2019 11:10:31 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=rLwesXS/b7JrhmpoCqYeQW5otaT1Lb8O4yXbQTlkRbM=; b=jptju5LXI8Mokb65KlMPdWeNkzxCDs/uNkHGnq3x9O7Im5Z4pOW+ZLCX4GPFmAV0cyPkp8XF/zH/l26wy/vV161IpsX3ToIeRbM5ip04NA+Eg1sI6SZM+Z64AtrVxO/kjk0aH6FGdVpervgpU1dpre92xc/CvGP7ZwimV3fMHFU= Received: from MW2PR2101CA0033.namprd21.prod.outlook.com (2603:10b6:302:1::46) by DM5PR21MB0762.namprd21.prod.outlook.com (2603:10b6:3:a3::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1686.3; Wed, 27 Feb 2019 19:10:29 +0000 Received: from BL2NAM06FT010.Eop-nam06.prod.protection.outlook.com (2a01:111:f400:7e55::206) by MW2PR2101CA0033.outlook.office365.com (2603:10b6:302:1::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.3 via Frontend Transport; Wed, 27 Feb 2019 19:10:28 +0000 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 157.58.196.96 as permitted sender) receiver=protection.outlook.com; client-ip=157.58.196.96; helo=mail.exchange.microsoft.com; Received: from mail.exchange.microsoft.com (157.58.196.96) by BL2NAM06FT010.mail.protection.outlook.com (10.152.106.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1686.0 via Frontend Transport; Wed, 27 Feb 2019 19:10:28 +0000 Received: from CYS-E16DFM04.exchange.corp.microsoft.com (10.221.226.71) by CYS-E16DFM05.exchange.corp.microsoft.com (10.221.226.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 27 Feb 2019 11:10:27 -0800 Received: from CYS-E16DFM04.exchange.corp.microsoft.com ([fe80::42:8cff:fe36:8759]) by CYS-E16DFM04.exchange.corp.microsoft.com ([fe80::42:8cff:fe36:8759%17]) with mapi id 15.01.1713.004; Wed, 27 Feb 2019 11:10:27 -0800 From: Kenneth McMillan To: Robin MARX , Ian Swett CC: Dirkjan Ochtman , QUIC WG Subject: Re: Unit test proposal Thread-Topic: Unit test proposal Thread-Index: AQHUyLDljBly2P/KJkCJ6nDqOPEc3KXqcbIAgAn0IwCAAAaDgP//nO9P Date: Wed, 27 Feb 2019 19:10:27 +0000 Message-ID: <9e7a831999494f63abcbcbcaf25ce4df@CYS-E16DFM04.exchange.corp.microsoft.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.255.3] Content-Type: multipart/alternative; boundary="_000_9e7a831999494f63abcbcbcaf25ce4dfCYSE16DFM04exchangecorp_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:157.58.196.96; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(136003)(346002)(2980300002)(189003)(199004)(110136005)(6246003)(236005)(478600001)(126002)(7116003)(8936002)(476003)(7736002)(10290500003)(229853002)(517774005)(446003)(486006)(11346002)(561944003)(7066003)(440504004)(7696005)(606006)(966005)(53936002)(86612001)(733005)(86362001)(14454004)(5070765005)(53376002)(53366004)(81166006)(81156014)(55016002)(5660300002)(6306002)(8676002)(54896002)(53386004)(3846002)(14444005)(53546011)(26005)(71190400001)(186003)(84326002)(336012)(24736004)(4326008)(108616005)(97736004)(102836004)(6116002)(2906002)(356004)(6346003)(3480700005)(76176011)(106466001)(316002)(10090500001)(19627405001)(68736007)(426003)(22452003)(106002)(16586007)(93886005)(54906003)(15974865002)(10090945008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0762; H:mail.exchange.microsoft.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e743e7e1-01ed-4c47-80f2-08d69ce73c53 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7193020); SRVR:DM5PR21MB0762; X-MS-TrafficTypeDiagnostic: DM5PR21MB0762: X-MS-Exchange-PUrlCount: 5 X-O365-Sonar-Daas-Pilot: True X-Microsoft-Exchange-Diagnostics: 1; DM5PR21MB0762; 20:GtZEcgpPIz2/FBpS/E4uXlHOsbIhdrPrzpR1q67ViFyhKTluPkFOxRXS5ugJ2mh2wVKFNdSlQVbOu/VwaRabHufaBF7Dsh6xa7HBvbTwFlRiz5KmwibrvD1kJQP0fKpbyiUYcyjiNBEXuGulW8wk+ruA3sAq6RiaJQX/sZCQ15JolXKzHVAbQp8URrIKI9QiCZtXgCjJXICbzQOeFCwYk5rqpEnZr0hPUhE1ETZgL7PMOYCrV575cUeGQaohfGLOyGGPjn9GYLYUBMMWcNYX/JKZ+U5Ko2+3vzw4T3ExFBYepUrWQE8YXIkV8P7weVPt17YL7lYi2R2PReoRhzmj+h0AfSZJAuUbGyjhN2wk8k1g1hyB+y4ulOKK56KSzOB7IEeLoRAgizIWitOSnsmmKRRAr+b8W1XhMqLfhv90dixVFcPqsnZ+D/oAvLZSoXSOqldrU41GsCw8J3/KcwOdQkqYoNfxZ9FokPb9s5bL5sdn9fjrnHvzzkejOe8gbB6/ X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0961DF5286 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR21MB0762; 23:JRWnBPl2NUkEJBvx6uaUejNwQwFCBVE6N66Mif8TJ?= =?us-ascii?Q?lMJ0/071sefmA56m7Zy7Df/Xv1NqaNI0Qm37zbEpD6YUA8OQjc3vR9m8Skb4?= =?us-ascii?Q?NUb9/v9zl1XXU1ZJH/rEVL0yXyGDPbB4wzo8pve6K2MvRgIwXbdkRAIPgGgv?= =?us-ascii?Q?dd3lN3yNQ1ZHP3ra+EOtpV98FKfFg8EJVNUzjnl5LQEs7t65kzG9uTRBHjH8?= =?us-ascii?Q?vsSyRx4MN7wD/K6QTppDtm2Fer6xuNl68YFeaPi0Ozwgx7KZXMqX7TF2Q6VH?= =?us-ascii?Q?bBr6/uYCEteSOEd8J1bBXnAxh/DuA6i5ZEtpozDk1FRdoeLoCeoNmoM3GvR5?= =?us-ascii?Q?UCzF1i0ez83k8I7Z2ekj9EhmgJTx+t/+Q2pM38WLkhE0vxCj2Xlvf0J/2Qy+?= =?us-ascii?Q?P5f+bymUsQjJiypRn08ACdLOzvczW96ZzJ0Z2RKPFCPJ1wrvQFHFecGTwOes?= =?us-ascii?Q?9W5Ufqw6fXs2HQLq1iI/Cp42Pbg8yvKpN+Hv0EWyFJQUC8wn8Iib0olFaH4O?= =?us-ascii?Q?mhWCMNKXdQ3firxR3JMKys8j0UtD9OGpbTjGPRmfPiNVBFF0xRc4ZI2wpewG?= =?us-ascii?Q?obophjOIclOCn2mhfV0BEa4g0gvjQfDWmO8jEBuHuwMe8WhDuCRSFjsGpzb1?= =?us-ascii?Q?Vw1UXbcW4gd7PVXYWULe1Sfq+aFqEq2dR7Bmxx38lqrBrsgxfzOPfI5d+rW5?= =?us-ascii?Q?Ct0W7U92ysvR23Li78kdGefCDsiLwYdEXqirjp/ALrCLlkjbkRngqM08L8vp?= =?us-ascii?Q?orHJOPzsgFzBff06DkNgMIwQ8atyEJSAGmleCQ/kfRspEtt0sFAurmijJues?= =?us-ascii?Q?2hmko3Ek8Bhd/2YdQb3TPTNdtrvromFs1PI7IBV/tcH/g5FN/JD3fDk2FNOz?= =?us-ascii?Q?waf31RqgWgzTtUokyJqOIIKDK/jefmKwHT9WYC2p8GvEWNmPzTyENjPC/wCE?= =?us-ascii?Q?QUawTfRZq2FgzCmsdC5EF87hlvLHM421THFZwaTxs5CN5FgDTlDCy1GWf6hH?= =?us-ascii?Q?NaS6Dj+vEfwZyOXRRFHCH6rQZ0xunIvBkIpQ3p7TUpCAaUhTBJX8kzYf2yDp?= =?us-ascii?Q?WwNUc53zdZQRUzzllARDtaoUexySOIN1OKqWVjQTDIBspPM4xRGb5RG6McLN?= =?us-ascii?Q?UqgOdT5/ixbzlU2JHuhs0a7CSQThsuta/e8obz+i32xttPpODBUZLTAyYaqM?= =?us-ascii?Q?NqW0Tn5Z20TPfXVVUKc+xroLg2uMzdM1A2RZ/CAxl/zFqU96usQbMcuJ8WTY?= =?us-ascii?Q?XcDKMnwrvkKXYFe7lGmpY0uyOQf1sdvpDzUvNwyhJsi+1GQ34Wy4Nt7rgPfh?= =?us-ascii?Q?4KxW/JgYG7cuqYyExyrAYKbinaWYAPP4YG+I37snubb9vUvg7/PYdpTOn9OV?= =?us-ascii?Q?heXpBE/c53OzReIGG1EeMlINXTnkvVptYSLwWNM/i/ZhXaU/7j1K7dqs6xSm?= =?us-ascii?Q?gxn7g4q10XBdcWAzRfNe8NS8iZfG9yzgh5rLPyuxSEAj7eNYBghD3YS/ZCwN?= =?us-ascii?Q?1X1+h5wno7769QIsMIWSLePIy/LawSK0nNgWxNPZzTzsfqnsOIOslgwdKi3q?= =?us-ascii?Q?lDgLoXRyV1oA6uFnMGpGILskgHLHNqEeLWGbNL9N6j1O2e2tmKlpVzwZWixQ?= =?us-ascii?Q?Zz0aE5nICZmJY5bzejsfCMEgY4Z3LOLukDeyFH0K+J5RUJZa3AAGJzLf0DqA?= =?us-ascii?Q?ewOjHROzlvfjiKzItkCy+2dgViOwRPkj95El1gZzVq9mGs=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: V7iQ89h9VVaa4mGMqndVBf8HJeXUQ3XsEqy5Z1ikb32iQhhiRueBVXyJa/aTO6Hq/8E1JbGhrkSRPmkUseYmPsaeLsNJ6Eb+kF7jJJJFSziEu0ghN0+mWMHCx7uMpyBmLqK4bkcH/G4mXS5R3R7zHeDUz4s0e7kanqHECTSkTsyuT9UD+i3zdKxFH98sYv4hV6Bh8EBu4rqZlApzG4Usx+c0h2sLttAR5sQJ/+pEtEmfdgWHYzQt4zhejg3TvwTd5RmiDIT8ta1q8fMW5bKJ5pJn+8qG1GZWmwSve9zjah5zzVPTC0ewqzfzjgcW6iHs8asCjOqnlUHIsnvHSascbAmLeVvsig7nJhH/x48BlWR6LcZOkVhFh8moAnmOv2JbKZyXDsdahzkhZbKFVIx7jFiy1MKeMAxZlZcb8ekEu5U= X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2019 19:10:28.1936 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e743e7e1-01ed-4c47-80f2-08d69ce73c53 X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[157.58.196.96]; Helo=[mail.exchange.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0762 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 19:10:34 -0000 --_000_9e7a831999494f63abcbcbcaf25ce4dfCYSE16DFM04exchangecorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robin, There's definitely some synergy. A real-time log in a standard format would= be very helpful for on-line test generation, since the tester could make d= ecisions based on internal server events that aren't visible on the wire. O= f course, what I want to do is actually *drive* the interfaces of the serve= r or client. I do have a generic tester for QUIC servers, based on a formal specificatio= n. If you're interested in using it, perhaps for generating logs for your v= isualization tools, let me know. Best--Ken Sent from Outlook ________________________________ From: Robin MARX Sent: Wednesday, February 27, 2019 8:45:13 AM To: Ian Swett Cc: Dirkjan Ochtman; QUIC WG; Kenneth McMillan Subject: Re: Unit test proposal Hello Ken, We are working on trying to get a standardized logging format for QUIC set = up (see https://quic.edm.uhasselt.be/). The idea would be that this allows implementations to log endpoint-specific= information (that would not be visible on the wire) in a machine processab= le way. One of the envisioned use cases would be to have a testing client execute v= arious scenarios (e.g., what QUIC-tracker is doing) and then validate the e= xpected behavior based on the server-side log output. I have also talked about this to the people from RWTH Aachen who are doing = symbolic execution analysis (this paper https://dl.acm.org/authorize?N66418= 7). He thought the logs might be used to obtain what I think is called "belief = states" (I'm not at all into symbolic execution) and use that in their anal= ysis as well. This is certainly far from a full-fledged unit testing setup and doesn't of= fer all the features you mentioned (though I think replay would be interest= ing/possible to add if we optionally log full packet dumps as well). However, I do see some synergies. If you agree, feel free to contact us. *switches hats* I am also working on a JavaScript based QUIC implementation (yes, I know) t= hat has only limited testing atm. >From that viewpoint, generic unit testing would certainly be interesting, t= hough I have a hard time imagining how that might look/work in practice. With best regards, Robin On Wed, 27 Feb 2019 at 17:22, Ian Swett > wrote: This would be interesting, but I'm a bit unclear on exactly what the unit t= est interface would be. And are you thinking of interfacing at the QUIC tr= ansport layer, the HTTP layer, or both? Agreed that logging and replay is extremely important in debugging. The closest work I can think of is QUIC-Tracker, which I believe is somewha= t different than what you have in mind: https://github.com/QUIC-Tracker/qui= c-tracker On Thu, Feb 21, 2019 at 3:22 AM Dirkjan Ochtman > wrote: On Wed, Feb 20, 2019 at 2:05 AM Kenneth McMillan > wrote: Please let me know if you think this seems worthwhile, or if it's redundant= with any existing work. It sounds useful to me. On the other hand, I'm not sure a language-indepen= dent API is the best form here? It seems that languages are sufficiently di= fferent that a single API might be hard to implement sanely/simply across d= ifferent languages. Maybe it would make more sense to define a file format,= similar to what's already been done for QPACK (I believe it's called QIF)?= It could probably be based on how Wireshark pcaps are defined. Regards, Dirkjan -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 [https://www.uhasselt.be/images/nieuwsbrief/dcm/UHasselt-liggend.jpg] --_000_9e7a831999494f63abcbcbcaf25ce4dfCYSE16DFM04exchangecorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robin,


There's definitely some synergy. A real-time log in a standard format wo= uld be very helpful for on-line test generation, since the tester coul= d make decisions based on internal server events that aren't visible on the= wire. Of course, what I want to do is actually *drive* the interfaces of the server or client.


I do have a generic tester for QUIC servers, based on a formal specifica= tion. If you're interested in using it, perhaps for generating logs for you= r visualization tools, let me know.


Best--Ken






Sent from Outlook=

From: Robin MARX <robin.= marx@uhasselt.be>
Sent: Wednesday, February 27, 2019 8:45:13 AM
To: Ian Swett
Cc: Dirkjan Ochtman; QUIC WG; Kenneth McMillan
Subject: Re: Unit test proposal
 
Hello Ken,

We are working on trying to get a standardized logging format for QUIC= set up (see htt= ps://quic.edm.uhasselt.be/).
The idea would be that this allows implementations to log endpoint-spe= cific information (that would not be visible on the wire) in a machine proc= essable way. 

One of the envisioned use cases would be to have a testing client exec= ute various scenarios (e.g., what QUIC-tracker is doing) and then validate = the expected behavior based on the server-side log output. 
I have also talked about this to the people from RWTH Aachen who are d= oing symbolic execution analysis (this paper https://dl.acm.org/aut= horize?N664187).
He thought the logs might be used to obtain what I think is called &qu= ot;belief states" (I'm not at all into symbolic execution) and use tha= t in their analysis as well. 

This is certainly far from a full-fledged unit testing setup and doesn= 't offer all the features you mentioned (though I think replay would be int= eresting/possible to add if we optionally log full packet dumps as well).
However, I do see some synergies. If you agree, feel free to contact u= s.

*switches hats*
I am also working on a JavaScript based QUIC implementation (yes, I kn= ow) that has only limited testing atm.
From that viewpoint, generic unit testing would certainly be interesti= ng, though I have a hard time imagining how that might look/work in practic= e. 

With best regards,
Robin

On Wed, 27 Feb 2019 at 17:22, Ian Swe= tt <ianswett=3D40google.c= om@dmarc.ietf.org> wrote:
This would be interesting, but I'm a bit unclear on exactl= y what the unit test interface would be.  And are you thinking of inte= rfacing at the QUIC transport layer, the HTTP layer, or both?

Agreed that logging and replay is extremely important in debugging.

The closest work I can think of is QUIC-Tracker, which I believe is so= mewhat different than what you have in mind: http= s://github.com/QUIC-Tracker/quic-tracker

On Thu, Feb 21, 2019 at 3:22 AM Dirkj= an Ochtman <dirk= jan@ochtman.nl> wrote:
On Wed, Feb 20, 2019 at 2:05 AM Kenneth McMillan <kenmc= mil=3D4= 0microsoft.com@dmarc.ietf.org> wrote:
Please let me know if you think this seems worthwhile, or if it's redundant= with any existing work.

 It sounds useful to me. On the other hand, I'm not sure a langua= ge-independent API is the best form here? It seems that languages are suffi= ciently different that a single API might be hard to implement sanely/simpl= y across different languages. Maybe it would make more sense to define a file format, similar to what's already b= een done for QPACK (I believe it's called QIF)? It could probably be based = on how Wireshark pcaps are defined.

Regards,

Dirkjan


--

Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for Digita= l Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 9= 4
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
3D""
Robin Marx
PhD researcher - web pe= rformance
Expertise centre for Di= gital Media
 
T +32(0)11 26 84 79 - GSM +32(0)= 497 72 86 94
 
www.uhasselt.be
Universiteit Hasselt - = Campus Diepenbeek
Agoralaan Gebouw D - B-= 3590 Diepenbeek
Kantoor EDM-2.05
 
=3D""
--_000_9e7a831999494f63abcbcbcaf25ce4dfCYSE16DFM04exchangecorp_-- From nobody Wed Feb 27 11:57:53 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D4B1310AC for ; Wed, 27 Feb 2019 11:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ZuhNLqeMYvwb for ; Wed, 27 Feb 2019 11:57:48 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820113.outbound.protection.outlook.com [40.107.82.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD870128766 for ; Wed, 27 Feb 2019 11:57:47 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=2pPhbFnkCezT4nf9yXkYIQNd0lxyxg9rWpFfFSEl0P4=; b=iPnfeyCWbXlISVgPpgPIJlfsJ+jtnb6xn1sFWt3JVlWhwGjdtM4ccntMi17Y++Y2OLT7VEj12YC/y486XMgTwWT33wzcGGZ2YZZ8RngEUOF/vsDiJLa1zhLDVdiHMEiqswUKfYKQfmgYRNHjqZ1EHx0Hg+7S6YS7TPTo0MvGZuk= Received: from SN6PR2101CA0024.namprd21.prod.outlook.com (2603:10b6:805:106::34) by MW2PR2101MB0938.namprd21.prod.outlook.com (2603:10b6:302:4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.2; Wed, 27 Feb 2019 19:57:45 +0000 Received: from BL2NAM06FT008.Eop-nam06.prod.protection.outlook.com (2a01:111:f400:7e55::202) by SN6PR2101CA0024.outlook.office365.com (2603:10b6:805:106::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1686.3 via Frontend Transport; Wed, 27 Feb 2019 19:57:45 +0000 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 157.58.196.103 as permitted sender) receiver=protection.outlook.com; client-ip=157.58.196.103; helo=mail.exchange.microsoft.com; Received: from mail.exchange.microsoft.com (157.58.196.103) by BL2NAM06FT008.mail.protection.outlook.com (10.152.106.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1686.0 via Frontend Transport; Wed, 27 Feb 2019 19:57:45 +0000 Received: from CYS-E16DFM04.exchange.corp.microsoft.com (10.221.226.71) by CYS-E16DFM04.exchange.corp.microsoft.com (10.221.226.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 27 Feb 2019 11:57:44 -0800 Received: from CYS-E16DFM04.exchange.corp.microsoft.com ([fe80::42:8cff:fe36:8759]) by CYS-E16DFM04.exchange.corp.microsoft.com ([fe80::42:8cff:fe36:8759%17]) with mapi id 15.01.1713.004; Wed, 27 Feb 2019 11:57:44 -0800 From: Kenneth McMillan To: Ian Swett , Dirkjan Ochtman CC: QUIC WG Subject: Re: Unit test proposal Thread-Topic: Unit test proposal Thread-Index: AQHUyLDljBly2P/KJkCJ6nDqOPEc3KXqcbIAgAn0IwD//6lhrw== Date: Wed, 27 Feb 2019 19:57:44 +0000 Message-ID: <0d0a01a4a7e04b408885dc9ccb7a980f@CYS-E16DFM04.exchange.corp.microsoft.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.255.3] Content-Type: multipart/alternative; boundary="_000_0d0a01a4a7e04b408885dc9ccb7a980fCYSE16DFM04exchangecorp_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:157.58.196.103; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(136003)(346002)(2980300002)(189003)(199004)(110136005)(6246003)(236005)(478600001)(126002)(476003)(7116003)(8936002)(7736002)(10290500003)(229853002)(446003)(486006)(11346002)(561944003)(7066003)(440504004)(7696005)(606006)(517774005)(966005)(86612001)(86362001)(53936002)(14454004)(5070765005)(53366004)(53376002)(81156014)(8676002)(81166006)(55016002)(5660300002)(6306002)(54896002)(3846002)(14444005)(53546011)(3480700005)(26005)(186003)(71190400001)(336012)(84326002)(24736004)(4326008)(97736004)(108616005)(356004)(6116002)(102836004)(2906002)(6346003)(76176011)(106466001)(316002)(10090500001)(19627405001)(426003)(68736007)(22452003)(106002)(16586007)(10090945008); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0938; H:mail.exchange.microsoft.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c41a89e9-6561-4544-7400-08d69cedd776 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7193020); SRVR:MW2PR2101MB0938; X-MS-TrafficTypeDiagnostic: MW2PR2101MB0938: X-MS-Exchange-PUrlCount: 2 X-O365-Sonar-Daas-Pilot: True X-Microsoft-Exchange-Diagnostics: 1; MW2PR2101MB0938; 20:BpszMalC/eTeriCZwBJPC/J+UkgXN/Wuo+i0pkEm2GhzMxhcuc1rc7N2WSJI0Z9mxNu38YxqSty+VXAgjX1a7BIzhfn0s2Od4JBfYXGDgpDLLWoLR5yBassN46X2KfVdRmg9R0v/xPvFDX7GvoPqPqinPG8CUM6qBzJgExW9hkmBg8qhwFbWi5KodMjtF0sbu5AMA8FNMYgHc9dTPG6LXV5Y3zyf/yVQ1wH8ZdGXM+6edv5HBXjT0S+145Qmbl4P8ZSOf4to1Rlr6spM9CvxML8tdy7wHtNYXf8bUqnK2O6J4Zo6/RVi0dHKNXv7YHnR1OnKeL7LrpO/sF9ZqlME1tmGO07HwM4pOhLNxrUdrLaI6HkRMpzVxEAEtqjfN1S7r+Cc1QVEevb5X6Q40SJFzmwAIsBB1MFIZ4NPRw8awX1+QDjU9cLtXXb2iCmyb/sEwPDLi8aip81AImAY45xX+EZS2KshNYfKtTcDIu/PzUJUOhtGxK2cnjQUstNLgskt X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0961DF5286 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MW2PR2101MB0938; 23:3qBk5OHjIYXpcoEuaIt2B0U3rmPduXPrpQ9xXt+?= =?us-ascii?Q?x5WE/qIrCJJRqtRiv/6mg5ZM0egUgDHigWQFuDBb5XKr6OIId7uvocpEZEu0?= =?us-ascii?Q?DBFpSH7orB7oLojl+PEgOA8N6f52BwmGjkyF4w3vhLDU22HdkjyF8p0md08L?= =?us-ascii?Q?TbmWMHCLKCsQgwrellb2qjDmeoG2oc0RyafHKfwr3JWXO4yA8k7tRu9WMPv2?= =?us-ascii?Q?CvC6UV5XTmQ8pE4y23xM1SzDpRS1eFcFy8zh+wOFJEr+fzcxRFe6VhW9sUUQ?= =?us-ascii?Q?GJ1bBHDbotRwky6XsyEm+e+PrmlXtG+DAS6Fs27X5t6op6fyJCTLmERhnL+8?= =?us-ascii?Q?AvM8azuUFcSdepXOJ++Lw0Yz1ldkvIe7NOQKgFamUvtBRQljoLnHe2z+La+F?= =?us-ascii?Q?TlmfygWw9SELZK+VolhvsekQNh4nnkUiYgE4ARevun/7wm69aQuz+qHLekzF?= =?us-ascii?Q?ckU/eTaYzu0jpcxdtBxnz+9VmK3GV8ZBUzEqyAOWi6QFUYYFmwyw2/54P/lV?= =?us-ascii?Q?NsHx+78cuARqARcJqRYcQGuRyEwwuFYs9VKhF1zf8M2Hra5NTprCwL7pcUWT?= =?us-ascii?Q?8KH559b9YAILh4SHCDHKme82xT43PUtJCkDPoN0E8MhTxc/wIi/KMbIDJqqc?= =?us-ascii?Q?C1+allHwE1Ho90EHdO3g0zzmF7gbEhxJ3jOMWwezrSwwf78ZwLtN5TW/Z8TV?= =?us-ascii?Q?wDglLT1jUUGb0hKISnJOVx8Oe2avCP3ncaOjgtYto7IfN4vhAnWIwA0T0C96?= =?us-ascii?Q?rzlglKm3PmR2hXREAMAAddioKRWrIn9+1f/vV2O6ka/Q4BEcCNoj/zMh9Jbb?= =?us-ascii?Q?m2nZphohidl+0ZBhii5fqq8kGrxZADOhBoZv+8jlRXoYepyiL48/6N/a3AUa?= =?us-ascii?Q?9u/TkyaVRn2vtEYEBd+hzN3BQtw3NpkOXiJtMaVRoVxrL//p36PX22eZMQXF?= =?us-ascii?Q?BwPWHS/7EdNZ6xeRpSv2n0DjJtGiHi7vUQC+0+6k1UtuUhjgT41P+J1lajd7?= =?us-ascii?Q?DYclLRg5nBjl43VDGGw9UhCF2WoRkww1EAkIAtgoSBq7BtJCcFrZi1zjGqfX?= =?us-ascii?Q?C5Qdhsf3F2k4fvYajsQ523NODT819CjQI1se0HmBVi9wIQ1iMIw+OED19A2A?= =?us-ascii?Q?ltXVhq5ivQEiREpNCgUD+grnov26DaM7w6EeExhb5bhsxhjpGs+HDlnedwRy?= =?us-ascii?Q?ssRTPZ8DOm1wPP1DbL7g1d1gP/sgLV0HIW7PXtW2vSANQIPkjsNVEYSyTO9E?= =?us-ascii?Q?cMCtOgyRdtbO3AtYSD/MI0pZTraw2agWlLpCHFPuNgyNWjt71cGXihgX7Cu8?= =?us-ascii?Q?Zo1sYbMd0hGCTSlewIQ7ymjY9O5hF9v3mMi1kgfziaGaPjT/NL3D7D1gnQ0l?= =?us-ascii?Q?UqISlmTjDebin2Om/3n/Kref8GLXFVVf4IomkpQQeSV00L3QbMPEl1YRNRHH?= =?us-ascii?Q?d5AKYRh6dAwZa3ebAOGj3udwHahL4lx2NxX4tffdghG1uF0dYxj1Sfiz8BLx?= =?us-ascii?Q?46e4Slczbt2lYo1LYKGpw0e+vbwy+oz9400GQFvjSlQFbZSDOfvtbAWtsy6y?= =?us-ascii?Q?6mcdRCWAuojtpGFtlyoW0iFrtoHC+MkwbN+BWJ6cZlhDGWOKaRaGGkrdzeY9?= =?us-ascii?Q?y?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: FZzbWV5Em1m35U0wlO9LvhXuuwvfJUpA9LS9VidI6QmMaTBg8rnMBu5mplOd3ljaUQhTzmpEp2+CYDI3fcjI+GnqmsezLQBMPu+pEtWY3nU3DaA886F4GO5Bxun0AtL4sJ5IQ4qEFIuYxA4qggu+Wk9S75Kp/u7KaQzc+fiRN9RnmDewSJkrVs59t9RpEsY+q/wgTgTuDAW2TVKDANkn1UspAe6sc6InI+FUn3kDwZyYaH7vxoEwdcxOmtFehqOji6rsulGD/G/sMpfvmxW+SXfMtHuyyj2W0K6nCvkGoiylGrZzATlVJjyXXKGgnYN+2Pph7bUp4iDsE/Abrg7FRDTznh0d+HAJ+d7yiHaKz5zJE4+yqrymtPJuMAMMznyLU04HYD4kn5d2YtDplFdguzogPLlC0cdqWgjTHJgVUdY= X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2019 19:57:45.4481 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c41a89e9-6561-4544-7400-08d69cedd776 X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[157.58.196.103]; Helo=[mail.exchange.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0938 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 19:57:53 -0000 --_000_0d0a01a4a7e04b408885dc9ccb7a980fCYSE16DFM04exchangecorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ian, I'm thinking of doing just QUIC for now and not HTTP/3. So the upper inter= face would have operations like "listen", "connect", "open stream", "send/r= eceive" and so on. The lower interface would have operations like "datagram= send/receive", "sleep", "random bytes" and so on. I'm also thinking of an = interface for cooperative multitasking. This would have two calls: "block" = would be called by a thread when it is about to do an operation that might = block, like taking a lock, and "unblock" would be called when the operation= completes. This would give the test harness the ability to schedule thread= s, which would allow deterministic replay, as well as exploring thread sche= dules. The interface would be defined in terms of simple C-style calls and callbac= ks, with basic serializable data structures and opaque pointers or ID's. Th= is makes logging and replay possible. One option is to use an IDL (for exam= ple, gRPC) to make the interface language-independent and also generate a l= ot of boilerplate code automatically. Dirkjan makes a good point that it may be difficult to capture all the func= tionality of the various implementations in different languages. On the other hand, a lot of the com= plexity of interfaces is for efficiency purposes, and we are not concerned with efficiency here. We can = make the interface very simple and the adapters as inefficient as we like, since this code is only for fu= nctional testing purposes. Bets -- Ken Sent from Outlook ________________________________ From: Ian Swett Sent: Wednesday, February 27, 2019 8:21 AM To: Dirkjan Ochtman Cc: Kenneth McMillan; QUIC WG Subject: Re: Unit test proposal This would be interesting, but I'm a bit unclear on exactly what the unit t= est interface would be. And are you thinking of interfacing at the QUIC tr= ansport layer, the HTTP layer, or both? Agreed that logging and replay is extremely important in debugging. The closest work I can think of is QUIC-Tracker, which I believe is somewha= t different than what you have in mind: https://github.com/QUIC-Tracker/qui= c-tracker On Thu, Feb 21, 2019 at 3:22 AM Dirkjan Ochtman > wrote: On Wed, Feb 20, 2019 at 2:05 AM Kenneth McMillan > wrote: Please let me know if you think this seems worthwhile, or if it's redundant= with any existing work. It sounds useful to me. On the other hand, I'm not sure a language-indepen= dent API is the best form here? It seems that languages are sufficiently di= fferent that a single API might be hard to implement sanely/simply across d= ifferent languages. Maybe it would make more sense to define a file format,= similar to what's already been done for QPACK (I believe it's called QIF)?= It could probably be based on how Wireshark pcaps are defined. Regards, Dirkjan --_000_0d0a01a4a7e04b408885dc9ccb7a980fCYSE16DFM04exchangecorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ian,


I'm thinking of doing just QUIC for now and not HTTP/3.  So the upp= er interface would have operations like "listen", "connect&q= uot;, "open stream", "send/receive" and so on. The lowe= r interface would have operations like "datagram send/receive", &= quot;sleep", "random bytes" and so on. I'm also thinking of an interface for cooperative m= ultitasking. This would have two calls: "block" would be called b= y a thread when it is about to do an operation that might block, like takin= g a lock, and "unblock" would be called when the operation completes. This would give the test harness the ability to sched= ule threads, which would allow deterministic replay, as well as exploring t= hread schedules.


The interface would be defined in terms of simple C-style calls and call= backs, with basic serializable data structures and opaque pointers or ID's.= This makes logging and replay possible. One option is to use an IDL (for e= xample, gRPC) to make the interface language-independent and also generate a lot of boilerplate code automatic= ally. 


Dirkjan makes a good point that it may be = difficult to capture all the functionality  of the various

implementations in different languages. On= the other hand, a lot of the complexity of interfaces is for=

efficiency purposes, and we are not concer= ned with efficiency here. We can make the interface very simple

and  the adapters as inefficient as w= e like, since this code is only for functional testing purposes.


Bets -- Ken








 


Sent from Outlook=



From: Ian Swett <iansw= ett=3D40google.com@dmarc.ietf.org>
Sent: Wednesday, February 27, 2019 8:21 AM
To: Dirkjan Ochtman
Cc: Kenneth McMillan; QUIC WG
Subject: Re: Unit test proposal
 
This would be interesting, but I'm a bit unclear on exactl= y what the unit test interface would be.  And are you thinking of inte= rfacing at the QUIC transport layer, the HTTP layer, or both?

Agreed that logging and replay is extremely important in debugging.

The closest work I can think of is QUIC-Tracker, which I believe is so= mewhat different than what you have in mind: https://github.com/QUIC-Tracker/quic-tracker

On Thu, Feb 21, 2019 at 3:22 AM Dirkj= an Ochtman <dirkjan@ochtman.nl= > wrote:
On Wed, Feb 20, 2019 at 2:05 AM Kenneth McMillan <kenmc= mil=3D4= 0microsoft.com@dmarc.ietf.org> wrote:
Please let me know if you think this seems worthwhile, or if it's redundant= with any existing work.

 It sounds useful to me. On the other hand, I'm not sure a langua= ge-independent API is the best form here? It seems that languages are suffi= ciently different that a single API might be hard to implement sanely/simpl= y across different languages. Maybe it would make more sense to define a file format, similar to what's already b= een done for QPACK (I believe it's called QIF)? It could probably be based = on how Wireshark pcaps are defined.

Regards,

Dirkjan
--_000_0d0a01a4a7e04b408885dc9ccb7a980fCYSE16DFM04exchangecorp_-- From nobody Thu Feb 28 16:30:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDCF130EB1 for ; Thu, 28 Feb 2019 16:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_iB5PCwqSDU for ; Thu, 28 Feb 2019 16:30:35 -0800 (PST) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 6530B12D7F8 for ; Thu, 28 Feb 2019 16:30:35 -0800 (PST) Received: by mail-pf1-x441.google.com with SMTP id a3so10516188pff.11 for ; Thu, 28 Feb 2019 16:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fpl0ucVfmhOK2JGr9udBZ3eYRqfjEMB9H+aE6kwpV8o=; b=onkyXOChzqd9ttk3A3xWH0pRLA6VowiJzOoggVQrIUj+R8Wggklu9jqtoj69/ZMu5Y CBaU/ivzqNoTJbPiPP3Yl9bt7o1SaNa9RqOz+zifl7xWYByxa+jmBg8trbpsQea8kNlP gpEaThCGKEuhPuY+fQa7Lw1kmbuFSerK5Bhcz4IoUQU77XNKB+iWR3o0Zfgpx+E4VFDU JMJfn3IClqXF/qj9gvSBk6vw/oONf9HjTvqq24Iz6fIjYfGbtlO8Y32C4F65y5oP2n2T LexPqSXt/PZk2fe5dNavZ0qUfIylxGgWTP3LkgmIDUcSLeF9qCKoLXaW58H3vRFPtvJu G2dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fpl0ucVfmhOK2JGr9udBZ3eYRqfjEMB9H+aE6kwpV8o=; b=oCpnC/rv2zlOFofj5ZWtgbY0k+/pJMbQhJp3WrwT1/XIegEASobd9HhU8i/pejxPJy xMn+Xo9Ov8Uy6jw6nhr/yiPO0bCpPzkLzbcN9KM/jDzefxV3jYXkOh/vHTXbGjG4YMdG LFfR00nJoc8+lYelDboF4GnNYCicpIG1Hp/vvu+mM94eljTG1450ca6UzcOTfT7inmJi 4ThmIlaJ6+sOKpasFoVQU7pr7vkahjMb6Z7okpfKZEIbvtfcBWX3co5d6EC6ddAE221a yRl5Z0Q4ygIxAHQQ8bfCVD6TOXerYDRwL5gCvprHOUrd6dfl7ASx8+RkcnSq9G4HlQd2 QQOA== X-Gm-Message-State: APjAAAVVIj9a+BQsBGeh3pjI81gJ7tS5z9tq8Tzs99BlVo8uZ2LM/ymw M1Aky7Iw9lu8C0eX7PtKvrHUq84NWoWbAY0c/UA= X-Google-Smtp-Source: AHgI3IaE21Ry9VkvTR1VdfdUqY5ZPMWotiSyuyhUDt/sW2X8E4LPfD3Upm2oulRyiX5vKAhKUW4NoqIBBW/2O80nbfQ= X-Received: by 2002:a62:ee0e:: with SMTP id e14mr2505488pfi.201.1551400234699; Thu, 28 Feb 2019 16:30:34 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> <045bbf5b-04e4-4f9f-886b-f7ff9254bdab@www.fastmail.com> In-Reply-To: From: David Schinazi Date: Thu, 28 Feb 2019 16:30:22 -0800 Message-ID: Subject: Re: KEYS_READY To: Kazuho Oku Cc: Martin Thomson , Jana Iyengar , Ryan Hamilton , Marten Seemann , Mike Bishop , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Content-Type: multipart/alternative; boundary="000000000000e4ce6c0582fd83b3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 00:30:39 -0000 --000000000000e4ce6c0582fd83b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since this conversation has quieted down for two weeks, I went ahead and wrote up the RETIRE_KEYS proposal: https://github.com/quicwg/base-drafts/pull/2492 I believe this is simpler to reason about than the KEYS_ACTIVE proposal and safer as it makes less assumptions about the handshake protocol. Please let me know what you think, and I believe we should keep the discussion here instead of on the PR. David On Thu, Feb 14, 2019 at 5:51 PM Kazuho Oku wrote: > 2019=E5=B9=B42=E6=9C=8815=E6=97=A5(=E9=87=91) 9:18 David Schinazi : > > > > > > > > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson > wrote: > >> > >> On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote: > >> > This means that the server sends KEYS_ACTIVE(1-RTT) not when the 1-R= TT > >> > keys are active, > >> > but instead when the handshake finishes, which is when the server ha= s > >> > received the client finished. > >> > Those are two different moments in time. > >> > >> Yes, because the keys aren't active when the server starts sending > 1-RTT packets. They are only active when the server starts reading 1-RTT= . > The server can't activate its 1-RTT reading keys until the handshake is > complete. > > > > > > Ah, thanks. Looking at it this way it makes sense to me - we may want t= o > make the text clearer in case I'm not the only one who was confused. > > > >> > >> That's why I chose to name this KEYS_ACTIVE(this), not > RETIRE_KEYS(prev), but I don't really mind what it is called. > > > > > > I don't feel strongly about names either as long as they make sense - > and now KEYS_ACTIVE also makes sense to me - so either name is fine by me= . > > > >> > >> > My proposal is to have the client decide when it is done with the > >> > handshake keys by having the client > >> > delay sending RETIRE_KEYS(Handshake) instead of the server delaying > >> > sending KEYS_ACTIVE(1-RTT). > >> > >> This requires that the client send more Handshake packets. And it add= s > a lot of delay because the client has to wait until all its packets are > acknowledged. We previously agreed that any such signal from the server = is > more direct and effective. > > > > > > I don't think it means more handshake packets. And it's still a direct > signal between endpoints. The only difference is that the client-to-serve= r > RETIRE_KEYS message is delayed by one RTT compared to its KEYS_ACTIVE > message so the server will wait one RTT before throwing away handshake > keys. But it has the advantage of not requiring any implicit ACKs. So the > tradeoff we're facing is between allowing the server to throw away keys > sooner at the cost of making implicit decisions. This implicitness means > KEYS_ACTIVE does not allow the client to be able to send anything in > Handshake after the ClientFinished. I'm worried that might prevent protoc= ol > changes down the road. > > > > I'm still in favor of paying the one RTT before key deletion to make th= e > protocol more explicit. > > I share the same view. > > Admittedly, it means that then the frame would no longer be useful for > dropping the Initial keys, assuming that we want to drop them ASAP as > we do now. > > But even with that downside, I think it makes sense to delay when the > handshake and each generation of 1-RTT keys are dropped. After all, we > can argue that the requirement for when to drop the Initial keys is > exceptional due to security concerns. > > Hence something like > https://mailarchive.ietf.org/arch/msg/quic/NNOzxNWldmfiUN9avCdiQMNVXMw. > > -- > Kazuho Oku > --000000000000e4ce6c0582fd83b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since this conversation = has quieted down for two weeks, I went ahead and wrote up the RETIRE_KEYS p= roposal:

<= div>I believe this is simpler to reason about than the KEYS_ACTIVE proposal= and safer as it makes less assumptions about the handshake protocol.

Please let me know what you think, and I believe we= should keep the discussion here instead of on the PR.

=
David

On Thu, Feb 14, 2019 at 5:51 PM Kazuho Oku &l= t;kazuhooku@gmail.com> wrote:=
2019=E5=B9=B42= =E6=9C=8815=E6=97=A5(=E9=87=91) 9:18 David Schinazi <dschinazi.ietf@gmail.com>= :
>
>
>
> On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson <mt@lowentropy.net> wrote:
>>
>> On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote:
>> > This means that the server sends KEYS_ACTIVE(1-RTT) not when = the 1-RTT
>> > keys are active,
>> > but instead when the handshake finishes, which is when the se= rver has
>> > received the client finished.
>> > Those are two different moments in time.
>>
>> Yes, because the keys aren't active when the server starts sen= ding 1-RTT packets.=C2=A0 They are only active when the server starts readi= ng 1-RTT.=C2=A0 The server can't activate its 1-RTT reading keys until = the handshake is complete.
>
>
> Ah, thanks. Looking at it this way it makes sense to me - we may want = to make the text clearer in case I'm not the only one who was confused.=
>
>>
>> That's why I chose to name this KEYS_ACTIVE(this), not RETIRE_= KEYS(prev), but I don't really mind what it is called.
>
>
> I don't feel strongly about names either as long as they make sens= e - and now KEYS_ACTIVE also makes sense to me - so either name is fine by = me.
>
>>
>>=C2=A0 > My proposal is to have the client decide when it is don= e with the
>> > handshake keys by having the client
>> > delay sending RETIRE_KEYS(Handshake) instead of the server de= laying
>> > sending KEYS_ACTIVE(1-RTT).
>>
>> This requires that the client send more Handshake packets.=C2=A0 A= nd it adds a lot of delay because the client has to wait until all its pack= ets are acknowledged.=C2=A0 We previously agreed that any such signal from = the server is more direct and effective.
>
>
> I don't think it means more handshake packets. And it's still = a direct signal between endpoints. The only difference is that the client-t= o-server RETIRE_KEYS message is delayed by one RTT compared to its KEYS_ACT= IVE message so the server will wait one RTT before throwing away handshake = keys. But it has the advantage of not requiring any implicit ACKs. So the t= radeoff we're facing is between allowing the server to throw away keys = sooner at the cost of making implicit decisions. This implicitness means KE= YS_ACTIVE does not allow the client to be able to send anything in Handshak= e after the ClientFinished. I'm worried that might prevent protocol cha= nges down the road.
>
> I'm still in favor of paying the one RTT before key deletion to ma= ke the protocol more explicit.

I share the same view.

Admittedly, it means that then the frame would no longer be useful for
dropping the Initial keys, assuming that we want to drop them ASAP as
we do now.

But even with that downside, I think it makes sense to delay when the
handshake and each generation of 1-RTT keys are dropped. After all, we
can argue that the requirement for when to drop the Initial keys is
exceptional due to security concerns.

Hence something like
https://mailarchive.ietf.org/a= rch/msg/quic/NNOzxNWldmfiUN9avCdiQMNVXMw.

--
Kazuho Oku
--000000000000e4ce6c0582fd83b3-- From nobody Thu Feb 28 19:37:31 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA29B130F5F for ; Thu, 28 Feb 2019 19:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=j6mhtZSX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q5t+AjlF 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 3STftZo7Q3tX for ; Thu, 28 Feb 2019 19:37:27 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393C0130F15 for ; Thu, 28 Feb 2019 19:37:27 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4C46A22291 for ; Thu, 28 Feb 2019 22:37:26 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 28 Feb 2019 22:37:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type:content-transfer-encoding; s=fm1; bh=M8kxfLSOxVtKy j0ZaToFy4Nkkp31PlPJfwqndOtz59Y=; b=j6mhtZSXzv9wUKYtN1/g5hyroRoVn OHXwVz61ZsSUjxspVOmCebAs/1sYBHfvcfTrX2EXCaDR1Bt5zSQ+qp7g6r75EBfL q245I7G0QAc7iPQ3l/Hw9p4wztPF8ij+u97Ubm1l5hn9tSXnb1IMmwZWrue5PeiS Zlp625zUl4R0gsrwFzLi+cUVO1QTx6a2KS2ugpqkrXPbEPS1xw5G8oNTDlczgDNI eMHcpkVQQqv+wUo0qL+W8wr/PdrkIWxdum8Zes85VCPJaDSB5rUShBE5YUR9cGnE 1fha+/5kREylG7j/xyK6T97j+E1ijS0ka7r2FV0ZV840Mq/RViApDef3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=M8kxfLSOxVtKyj0ZaToFy4Nkkp31PlPJfwqndOtz59Y=; b=q5t+AjlF 0fA67eRVoqvTe/duQdb/raFeQfPOylcOhZg1s8A12UXkg40KoTbd4wstvL6BdYbc 6Aux9/v7Pia+2S9BPPpMQUp4JxvTsv4aJ+WeOEtHXkRpMogWnAD6+qKgxoQwx66m tEfWnpLtX66rYQ4JruCpki8VEoiNbUAUtuFe0kwtx/cRRtI2WTFSR33AIo1jGw7u qc4Gr0YpVe0Pga9ZrlwHWlBYuFN1o/ttifQMFwiL1gOSA+xZPSxrpwwrQaZH9Ugv mRtl2GtTuFpQ7KAQRzLx1Zuy3WWebVfp+Uq/4YP+V4dzi6lqxSnC3Eek2QzuTSIh oKO3GH2U9lw0oQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrvdeggdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtgfesthhqre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD42F7C1EB; Thu, 28 Feb 2019 22:37:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 92534000 Message-Id: <7879ac68-5a8e-4b5e-a81f-03b851be8328@www.fastmail.com> In-Reply-To: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> <045bbf5b-04e4-4f9f-886b-f7ff9254bdab@www.fastmail.com> Date: Thu, 28 Feb 2019 22:37:25 -0500 From: "Martin Thomson" To: quic@ietf.org Subject: Re: KEYS_READY Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 03:37:30 -0000 I don't get it. This is the same proposal. With fewer editorial change= s, perhaps. On Fri, Mar 1, 2019, at 11:30, David Schinazi wrote: > Since this conversation has quieted down for two weeks, I went ahead=20= > and wrote up the RETIRE_KEYS proposal: > https://github.com/quicwg/base-drafts/pull/2492 >=20 > I believe this is simpler to reason about than the KEYS_ACTIVE proposa= l=20 > and safer as it makes less assumptions about the handshake protocol. >=20 > Please let me know what you think, and I believe we should keep the=20= > discussion here instead of on the PR. >=20 > David >=20 > On Thu, Feb 14, 2019 at 5:51 PM Kazuho Oku wrote= : > > 2019=E5=B9=B42=E6=9C=8815=E6=97=A5(=E9=87=91) 9:18 David Schinazi : > > > > > > > > > > > > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson wrote: > > >> > > >> On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote: > > >> > This means that the server sends KEYS_ACTIVE(1-RTT) not when t= he 1-RTT > > >> > keys are active, > > >> > but instead when the handshake finishes, which is when the ser= ver has > > >> > received the client finished. > > >> > Those are two different moments in time. > > >> > > >> Yes, because the keys aren't active when the server starts sendi= ng 1-RTT packets. They are only active when the server starts reading 1-= RTT. The server can't activate its 1-RTT reading keys until the handshak= e is complete. > > > > > > > > > Ah, thanks. Looking at it this way it makes sense to me - we may = want to make the text clearer in case I'm not the only one who was confu= sed. > > > > > >> > > >> That's why I chose to name this KEYS_ACTIVE(this), not RETIRE_KE= YS(prev), but I don't really mind what it is called. > > > > > > > > > I don't feel strongly about names either as long as they make sen= se - and now KEYS_ACTIVE also makes sense to me - so either name is fine= by me. > > > > > >> > > >> > My proposal is to have the client decide when it is done with = the > > >> > handshake keys by having the client > > >> > delay sending RETIRE_KEYS(Handshake) instead of the server del= aying > > >> > sending KEYS_ACTIVE(1-RTT). > > >> > > >> This requires that the client send more Handshake packets. And i= t adds a lot of delay because the client has to wait until all its packe= ts are acknowledged. We previously agreed that any such signal from the = server is more direct and effective. > > > > > > > > > I don't think it means more handshake packets. And it's still a d= irect signal between endpoints. The only difference is that the client-t= o-server RETIRE_KEYS message is delayed by one RTT compared to its KEYS_= ACTIVE message so the server will wait one RTT before throwing away hand= shake keys. But it has the advantage of not requiring any implicit ACKs.= So the tradeoff we're facing is between allowing the server to throw aw= ay keys sooner at the cost of making implicit decisions. This implicitne= ss means KEYS_ACTIVE does not allow the client to be able to send anythi= ng in Handshake after the ClientFinished. I'm worried that might prevent= protocol changes down the road. > > > > > > I'm still in favor of paying the one RTT before key deletion to m= ake the protocol more explicit. > >=20 > > I share the same view. > >=20 > > Admittedly, it means that then the frame would no longer be useful = for > > dropping the Initial keys, assuming that we want to drop them ASAP = as > > we do now. > >=20 > > But even with that downside, I think it makes sense to delay when t= he > > handshake and each generation of 1-RTT keys are dropped. After all,= we > > can argue that the requirement for when to drop the Initial keys is= > > exceptional due to security concerns. > >=20 > > Hence something like > > https://mailarchive.ietf.org/arch/msg/quic/NNOzxNWldmfiUN9avCdiQMNVX= Mw. > >=20 > > --=20 > > Kazuho Oku From nobody Thu Feb 28 21:21:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2AA1311D0 for ; Thu, 28 Feb 2019 21:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmRuS1dAHO5x for ; Thu, 28 Feb 2019 21:21:24 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::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 AABC61311E2 for ; Thu, 28 Feb 2019 21:21:24 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id s16so18536596oih.9 for ; Thu, 28 Feb 2019 21:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AF1MJMefBzD1UzwltJIxXsl7yqt7M5YqdT/zsUoKrs0=; b=o9EMeQSw5enV8WxeoDnaUzZ91WGt/wfbPgvFO6p7gQqr5417Y1CQZ9SlvWXHwSmqAq yPQCa4L1Fy6TSaKiPhgRo324550AFEYnc01NCKvv3FkqqlUeHzwfX4n6GSwBC7n3LsKE gRLRTqa0+lftxXWIACHr0kimD/rXckn2hZmD7UozpI8HboGCIOguVsDyNZDo9CgS5KLE qTKDZNZ9nYp+rBIJJCzGfXhBZhrXpGPtVTX+uZW5eldgEP3TMNAWk7d1Iay6HbTMZS8C BjEbnB2QpUn+oEsMUCBS4KYxTNlPXwMlIxIyGptF9Y8ckoxsT6CLBI5/yjk++WAQadHO iXpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AF1MJMefBzD1UzwltJIxXsl7yqt7M5YqdT/zsUoKrs0=; b=f1mdO/Ya4pa+MYWXXv2h6ZGexzFMV9oNWYMxd8++HNO4BJvLNIBilUoKpn0lzvlXY2 yM9JzWtVIWYBn7iRVo9xSaVY3wFy/ie3Bi1QsFNn6HBse2hfTsmvvHZXbxRESNZnqD7i qvTBYdya7Y3YPsVJqylnQAGrP/Y8E51oyo6DKwz6FEHxDVZfGZhzNJ46mU1p1Mf7yOpY r92t/o+B1FLxOEMJUz8LJQVHyw25vRzqWXNP06aO2dyl0JuqIwETwpnO+j2l3i99OzUt 9YVUcrkZdccapWIz5fsLov6NbeG4kKYQlRRjwUEZ/frTgiG6T+pijsov0EfvUr7BQ15T Lvrg== X-Gm-Message-State: APjAAAW+4/qORrP8s+XbyCzQI4BTDqITl65CqoUFKQmaiqgTsU3a15hk 1Yd8uMFH4L90wF3nsU92dhlCB9tmuzh7gmPwqL6LdCgbBbE= X-Google-Smtp-Source: AHgI3IbRmCGYb7RKNR/PkLJkCvLejmfNMvy7msCHYkaDPDlOvXi7GMJk0cb69l6iwLSwaJeqxL2pYK+HhwrIXaOaDpM= X-Received: by 2002:aca:4a10:: with SMTP id x16mr2102324oia.73.1551417683224; Thu, 28 Feb 2019 21:21:23 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> <045bbf5b-04e4-4f9f-886b-f7ff9254bdab@www.fastmail.com> <7879ac68-5a8e-4b5e-a81f-03b851be8328@www.fastmail.com> In-Reply-To: <7879ac68-5a8e-4b5e-a81f-03b851be8328@www.fastmail.com> From: Nick Harper Date: Thu, 28 Feb 2019 21:21:11 -0800 Message-ID: Subject: Re: KEYS_READY To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e87dba058301935e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 05:21:36 -0000 --000000000000e87dba058301935e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is one difference between the RETIRE_KEYS and KEYS_ACTIVE PRs (besides the name of the new frame): With RETIRE_KEYS, the client doesn't send it until the Client Finished has been ACKed. With KEYS_ACTIVE, the client MUST send it in its first 1-RTT packet, while the server MUST NOT process that 1-RTT packet until it has received the Client Finished. Even though they do basically the same thing, I think it's much easier to understand the logic in the RETIRE_KEYS PR. The logic for RETIRE_KEYS is "I send RETIRE_KEYS when I don't need to send or receive anything more at the previous encryption level." After re-reading the KEYS_ACTIVE PR, I don't see a similar underlying principle for when it's sent, just a set of rules to follow. On Thu, Feb 28, 2019 at 7:37 PM Martin Thomson wrote: > I don't get it. This is the same proposal. With fewer editorial changes= , > perhaps. > > On Fri, Mar 1, 2019, at 11:30, David Schinazi wrote: > > Since this conversation has quieted down for two weeks, I went ahead > > and wrote up the RETIRE_KEYS proposal: > > https://github.com/quicwg/base-drafts/pull/2492 > > > > I believe this is simpler to reason about than the KEYS_ACTIVE proposal > > and safer as it makes less assumptions about the handshake protocol. > > > > Please let me know what you think, and I believe we should keep the > > discussion here instead of on the PR. > > > > David > > > > On Thu, Feb 14, 2019 at 5:51 PM Kazuho Oku wrote: > > > 2019=E5=B9=B42=E6=9C=8815=E6=97=A5(=E9=87=91) 9:18 David Schinazi : > > > > > > > > > > > > > > > > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson > wrote: > > > >> > > > >> On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote: > > > >> > This means that the server sends KEYS_ACTIVE(1-RTT) not when th= e > 1-RTT > > > >> > keys are active, > > > >> > but instead when the handshake finishes, which is when the > server has > > > >> > received the client finished. > > > >> > Those are two different moments in time. > > > >> > > > >> Yes, because the keys aren't active when the server starts sendin= g > 1-RTT packets. They are only active when the server starts reading 1-RTT. > The server can't activate its 1-RTT reading keys until the handshake is > complete. > > > > > > > > > > > > Ah, thanks. Looking at it this way it makes sense to me - we may > want to make the text clearer in case I'm not the only one who was confus= ed. > > > > > > > >> > > > >> That's why I chose to name this KEYS_ACTIVE(this), not > RETIRE_KEYS(prev), but I don't really mind what it is called. > > > > > > > > > > > > I don't feel strongly about names either as long as they make sens= e > - and now KEYS_ACTIVE also makes sense to me - so either name is fine by = me. > > > > > > > >> > > > >> > My proposal is to have the client decide when it is done with t= he > > > >> > handshake keys by having the client > > > >> > delay sending RETIRE_KEYS(Handshake) instead of the server > delaying > > > >> > sending KEYS_ACTIVE(1-RTT). > > > >> > > > >> This requires that the client send more Handshake packets. And it > adds a lot of delay because the client has to wait until all its packets > are acknowledged. We previously agreed that any such signal from the serv= er > is more direct and effective. > > > > > > > > > > > > I don't think it means more handshake packets. And it's still a > direct signal between endpoints. The only difference is that the > client-to-server RETIRE_KEYS message is delayed by one RTT compared to it= s > KEYS_ACTIVE message so the server will wait one RTT before throwing away > handshake keys. But it has the advantage of not requiring any implicit > ACKs. So the tradeoff we're facing is between allowing the server to thro= w > away keys sooner at the cost of making implicit decisions. This > implicitness means KEYS_ACTIVE does not allow the client to be able to se= nd > anything in Handshake after the ClientFinished. I'm worried that might > prevent protocol changes down the road. > > > > > > > > I'm still in favor of paying the one RTT before key deletion to > make the protocol more explicit. > > > > > > I share the same view. > > > > > > Admittedly, it means that then the frame would no longer be useful f= or > > > dropping the Initial keys, assuming that we want to drop them ASAP a= s > > > we do now. > > > > > > But even with that downside, I think it makes sense to delay when th= e > > > handshake and each generation of 1-RTT keys are dropped. After all, = we > > > can argue that the requirement for when to drop the Initial keys is > > > exceptional due to security concerns. > > > > > > Hence something like > > > https://mailarchive.ietf.org/arch/msg/quic/NNOzxNWldmfiUN9avCdiQMNVXM= w > . > > > > > > -- > > > Kazuho Oku > > --000000000000e87dba058301935e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is one difference between the RETIRE_KEYS and KEYS_A= CTIVE PRs (besides the name of the new frame):

With RETI= RE_KEYS, the client doesn't send it until the Client Finished has been = ACKed. With KEYS_ACTIVE, the client MUST send it in its first 1-RTT packet,= while the server MUST NOT process that 1-RTT packet until it has received = the Client Finished.

Even though they do basically= the same thing, I think it's much easier to understand the logic in th= e RETIRE_KEYS PR. The logic for RETIRE_KEYS is "I send RETIRE_KEYS whe= n I don't need to send or receive anything more at the previous encrypt= ion level." After re-reading the KEYS_ACTIVE PR, I don't see a sim= ilar underlying principle for when it's sent, just a set of rules to fo= llow.

On Thu, Feb 28, 2019 at 7:37 PM Martin Thomson <mt@lowentropy.net> wrote:
I don't get it.=C2=A0 This is = the same proposal.=C2=A0 With fewer editorial changes, perhaps.

On Fri, Mar 1, 2019, at 11:30, David Schinazi wrote:
> Since this conversation has quieted down for two weeks, I went ahead <= br> > and wrote up the RETIRE_KEYS proposal:
> https://github.com/quicwg/base-drafts/pull/2492<= /a>
>
> I believe this is simpler to reason about than the KEYS_ACTIVE proposa= l
> and safer as it makes less assumptions about the handshake protocol. >
> Please let me know what you think, and I believe we should keep the > discussion here instead of on the PR.
>
> David
>
> On Thu, Feb 14, 2019 at 5:51 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
> > 2019=E5=B9=B42=E6=9C=8815=E6=97=A5(=E9=87=91) 9:18 David Schinazi= <dschinaz= i.ietf@gmail.com>:
> >=C2=A0 >
> >=C2=A0 >
> >=C2=A0 >
> >=C2=A0 > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson <mt@lowentropy.net&g= t; wrote:
> >=C2=A0 >>
> >=C2=A0 >> On Fri, Feb 15, 2019, at 09:47, David Schinazi wro= te:
> >=C2=A0 >> > This means that the server sends KEYS_ACTIVE(= 1-RTT) not when the 1-RTT
> >=C2=A0 >> > keys are active,
> >=C2=A0 >> > but instead when the handshake finishes, whic= h is when the server has
> >=C2=A0 >> > received the client finished.
> >=C2=A0 >> > Those are two different moments in time.
> >=C2=A0 >>
> >=C2=A0 >> Yes, because the keys aren't active when the s= erver starts sending 1-RTT packets. They are only active when the server st= arts reading 1-RTT. The server can't activate its 1-RTT reading keys un= til the handshake is complete.
> >=C2=A0 >
> >=C2=A0 >
> >=C2=A0 > Ah, thanks. Looking at it this way it makes sense to m= e - we may want to make the text clearer in case I'm not the only one w= ho was confused.
> >=C2=A0 >
> >=C2=A0 >>
> >=C2=A0 >> That's why I chose to name this KEYS_ACTIVE(th= is), not RETIRE_KEYS(prev), but I don't really mind what it is called.<= br> > >=C2=A0 >
> >=C2=A0 >
> >=C2=A0 > I don't feel strongly about names either as long a= s they make sense - and now KEYS_ACTIVE also makes sense to me - so either = name is fine by me.
> >=C2=A0 >
> >=C2=A0 >>
> >=C2=A0 >> > My proposal is to have the client decide when= it is done with the
> >=C2=A0 >> > handshake keys by having the client
> >=C2=A0 >> > delay sending RETIRE_KEYS(Handshake) instead = of the server delaying
> >=C2=A0 >> > sending KEYS_ACTIVE(1-RTT).
> >=C2=A0 >>
> >=C2=A0 >> This requires that the client send more Handshake = packets. And it adds a lot of delay because the client has to wait until al= l its packets are acknowledged. We previously agreed that any such signal f= rom the server is more direct and effective.
> >=C2=A0 >
> >=C2=A0 >
> >=C2=A0 > I don't think it means more handshake packets. And= it's still a direct signal between endpoints. The only difference is t= hat the client-to-server RETIRE_KEYS message is delayed by one RTT compared= to its KEYS_ACTIVE message so the server will wait one RTT before throwing= away handshake keys. But it has the advantage of not requiring any implici= t ACKs. So the tradeoff we're facing is between allowing the server to = throw away keys sooner at the cost of making implicit decisions. This impli= citness means KEYS_ACTIVE does not allow the client to be able to send anyt= hing in Handshake after the ClientFinished. I'm worried that might prev= ent protocol changes down the road.
> >=C2=A0 >
> >=C2=A0 > I'm still in favor of paying the one RTT before ke= y deletion to make the protocol more explicit.
> >
> >=C2=A0 I share the same view.
> >
> >=C2=A0 Admittedly, it means that then the frame would no longer be= useful for
> >=C2=A0 dropping the Initial keys, assuming that we want to drop th= em ASAP as
> >=C2=A0 we do now.
> >
> >=C2=A0 But even with that downside, I think it makes sense to dela= y when the
> >=C2=A0 handshake and each generation of 1-RTT keys are dropped. Af= ter all, we
> >=C2=A0 can argue that the requirement for when to drop the Initial= keys is
> >=C2=A0 exceptional due to security concerns.
> >
> >=C2=A0 Hence something like
> > https://mailarchive.= ietf.org/arch/msg/quic/NNOzxNWldmfiUN9avCdiQMNVXMw.
> >
> >=C2=A0 --
> >=C2=A0 Kazuho Oku

--000000000000e87dba058301935e-- From nobody Thu Feb 28 22:15:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7321311F6 for ; Thu, 28 Feb 2019 22:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=i8SVAWrE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xvGLbk2I 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 Oc_kXHuts_rB for ; Thu, 28 Feb 2019 22:15:36 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67E41311F5 for ; Thu, 28 Feb 2019 22:15:35 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AE7883559; Fri, 1 Mar 2019 01:15:34 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Fri, 01 Mar 2019 01:15:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:cc:subject :content-type:content-transfer-encoding; s=fm1; bh=uTxyQG7d+3OkC 2ujheVngw5FfTEBDmDIKylD1GCqI44=; b=i8SVAWrEacHuwGQrxyPtaAPn71pEb kFG8MJ79pHiRAwv1sn5S0YysLluv1pi7AuTovDB0pFnxbWD4r9NscCnudKcs7Sz9 H26M+/uzIVdTXXpEWeJeLw8CMW8Gs1U7MD6LoCsKJufsOp+8HcCx0cC1elivQtPo RmgUXAW92gciYRkw0dZ+H0PuFk/tSvJbtWB8t2Y9Onfi59hqg9vdP1hnJ47YMUvi jAi8pmdTP2xHSWsw3OQWGxuVd0Cqs7d21aZPCfwNNzXC+Smqc1rpWuTNCiaPIVf/ kebHgMHZRCEM5AIYyoEzXbAJk+PuxPAo5WUeIyX9wcHF/JPodweyU0WvA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=uTxyQG7d+3OkC2ujheVngw5FfTEBDmDIKylD1GCqI44=; b=xvGLbk2I YM9FJIiD6DbpbLu8vj8qrLscqhGAXZTrCIVvNnmkWy7KU4QqtMr7LsdveXngkSKx EfD71OjJGTLD0EPiulUFqBd2h/7gQPHJG9TG1yQk6+MleAsUPw9LK8HdNUNYpJ1G U4cMchLDK35684rgvwcUobnaaxGNH0CcWFkUk+rikY5m6NcLbv3TwlBZWgApqbmG 3mORfumlr9BkPc/q8wbJfUfqYLUeg35HthZ+WD5+oj4Kk4DxjQwypANfYuP05mUz Wuz4wexd6Az7y+VGVFajZYBpqbAZTW2K/bqtMd+45Mr6Q6xwU7Dt3799tVR7W3RW 1dN09UHWjSrbVQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrvdeggdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucffoh hmrghinhepghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghi lhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C52AF7C1EB; Fri, 1 Mar 2019 01:15:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> <045bbf5b-04e4-4f9f-886b-f7ff9254bdab@www.fastmail.com> <7879ac68-5a8e-4b5e-a81f-03b851be8328@www.fastmail.com> Date: Fri, 01 Mar 2019 01:15:33 -0500 From: "Martin Thomson" To: "Nick Harper" Cc: "IETF QUIC WG" Subject: Re: KEYS_READY Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 06:15:38 -0000 I see. That's not clear. It might have helped to explain that in the e= mail announcing the proposal, because the PR contains errors that are qu= ite confusing. The PR never really defines what "done with keys" means = either. If that is the only difference then we can talk about the implications o= f driving state based on ACK frames, which we've not done in the past. = Leaving the ugly exception for Initial aside, I suspect that this is muc= h harder to implement, because you have to track where data was first se= nt in order to send the frame at the right time. That's easy enough for= CRYPTO frames, which are basically all you have during the handshake, b= ut in order to implement it for key updates you need visibility into whi= ch packets are still outstanding. That requires a new type of access to= the loss recovery module. I see quite a few omissions and mistakes in the PR. For instance, this = doesn't address the concerns about retransmissions of the frame across k= ey updates. It also shows the server sending the frame in Handshake pac= kets before it could have received ACKs. Hence my confusion. On Fri, Mar 1, 2019, at 16:21, Nick Harper wrote: > There is one difference between the RETIRE_KEYS and KEYS_ACTIVE PRs=20= > (besides the name of the new frame): >=20 > With RETIRE_KEYS, the client doesn't send it until the Client Finished= =20 > has been ACKed. With KEYS_ACTIVE, the client MUST send it in its first= =20 > 1-RTT packet, while the server MUST NOT process that 1-RTT packet unti= l=20 > it has received the Client Finished. >=20 > Even though they do basically the same thing, I think it's much easier= =20 > to understand the logic in the RETIRE_KEYS PR. The logic for=20 > RETIRE_KEYS is "I send RETIRE_KEYS when I don't need to send or receiv= e=20 > anything more at the previous encryption level." After re-reading the=20= > KEYS_ACTIVE PR, I don't see a similar underlying principle for when=20= > it's sent, just a set of rules to follow. >=20 > On Thu, Feb 28, 2019 at 7:37 PM Martin Thomson wro= te: > > I don't get it. This is the same proposal. With fewer editorial chan= ges, perhaps. > >=20 > > On Fri, Mar 1, 2019, at 11:30, David Schinazi wrote: > > > Since this conversation has quieted down for two weeks, I went ah= ead=20 > > > and wrote up the RETIRE_KEYS proposal: > > > https://github.com/quicwg/base-drafts/pull/2492 > > >=20 > > > I believe this is simpler to reason about than the KEYS_ACTIVE pr= oposal=20 > > > and safer as it makes less assumptions about the handshake protoc= ol. > > >=20 > > > Please let me know what you think, and I believe we should keep t= he=20 > > > discussion here instead of on the PR. > > >=20 > > > David > > >=20 > > > On Thu, Feb 14, 2019 at 5:51 PM Kazuho Oku = wrote: > > > > 2019=E5=B9=B42=E6=9C=8815=E6=97=A5(=E9=87=91) 9:18 David Schina= zi : > > > > > > > > > > > > > > > > > > > > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson wrote: > > > > >> > > > > >> On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote: > > > > >> > This means that the server sends KEYS_ACTIVE(1-RTT) not wh= en the 1-RTT > > > > >> > keys are active, > > > > >> > but instead when the handshake finishes, which is when the= server has > > > > >> > received the client finished. > > > > >> > Those are two different moments in time. > > > > >> > > > > >> Yes, because the keys aren't active when the server starts s= ending 1-RTT packets. They are only active when the server starts readin= g 1-RTT. The server can't activate its 1-RTT reading keys until the hand= shake is complete. > > > > > > > > > > > > > > > Ah, thanks. Looking at it this way it makes sense to me - we = may want to make the text clearer in case I'm not the only one who was c= onfused. > > > > > > > > > >> > > > > >> That's why I chose to name this KEYS_ACTIVE(this), not RETIR= E_KEYS(prev), but I don't really mind what it is called. > > > > > > > > > > > > > > > I don't feel strongly about names either as long as they make= sense - and now KEYS_ACTIVE also makes sense to me - so either name is = fine by me. > > > > > > > > > >> > > > > >> > My proposal is to have the client decide when it is done w= ith the > > > > >> > handshake keys by having the client > > > > >> > delay sending RETIRE_KEYS(Handshake) instead of the server= delaying > > > > >> > sending KEYS_ACTIVE(1-RTT). > > > > >> > > > > >> This requires that the client send more Handshake packets. A= nd it adds a lot of delay because the client has to wait until all its p= ackets are acknowledged. We previously agreed that any such signal from = the server is more direct and effective. > > > > > > > > > > > > > > > I don't think it means more handshake packets. And it's still= a direct signal between endpoints. The only difference is that the clie= nt-to-server RETIRE_KEYS message is delayed by one RTT compared to its K= EYS_ACTIVE message so the server will wait one RTT before throwing away = handshake keys. But it has the advantage of not requiring any implicit A= CKs. So the tradeoff we're facing is between allowing the server to thro= w away keys sooner at the cost of making implicit decisions. This implic= itness means KEYS_ACTIVE does not allow the client to be able to send an= ything in Handshake after the ClientFinished. I'm worried that might pre= vent protocol changes down the road. > > > > > > > > > > I'm still in favor of paying the one RTT before key deletion = to make the protocol more explicit. > > > >=20 > > > > I share the same view. > > > >=20 > > > > Admittedly, it means that then the frame would no longer be use= ful for > > > > dropping the Initial keys, assuming that we want to drop them A= SAP as > > > > we do now. > > > >=20 > > > > But even with that downside, I think it makes sense to delay wh= en the > > > > handshake and each generation of 1-RTT keys are dropped. After = all, we > > > > can argue that the requirement for when to drop the Initial key= s is > > > > exceptional due to security concerns. > > > >=20 > > > > Hence something like > > > > https://mailarchive.ietf.org/arch/msg/quic/NNOzxNWldmfiUN9avCdi= QMNVXMw. > > > >=20 > > > > --=20 > > > > Kazuho Oku > >