From nobody Mon Oct 2 13:31:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B94D13487A for ; Mon, 2 Oct 2017 13:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8xJeAjYE0XK for ; Mon, 2 Oct 2017 13:31:29 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 AE09F13485B for ; Mon, 2 Oct 2017 13:31:29 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id u67so6503457qkg.6 for ; Mon, 02 Oct 2017 13:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=elx1seIYYbPow1zAPdI/Syb7HspAdV75J0GY89Cyiaw=; b=CYm1qdzixkgGACFEeH8F33fzmFJ6rq1//O6Jn5QUcEMFvlUainJbcnFHNiajPiy1Kb r640uW0qvuLNcK9XrrG7GZyDXuNCk3+uHiiT/kRAhc1JaLTiWSigu3T7SmRxFIF3cd/p JRNNcAmNruofSVZqVIAVG7Gap+u8JDGUAgcO5wi0S5YSqWsBuBHMU+3+w/mDzBSPuqXn L/lMMneuYqQh/DAwY8bo7CK3LNeCbUyI978t4XfKLL01a3Mf6AshugoFjRJk5ifCj0iD WfP0RGoHsyGXsglc2tGPW3oqMdpbHgZ3be7U5D8SfXhSokxQAn1FeIBdznv2Y8a2EIII c9oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=elx1seIYYbPow1zAPdI/Syb7HspAdV75J0GY89Cyiaw=; b=UW/xfuelz5Vo4rMnYbc1U5cQ88Jno7mdWEy5J8kN1ptwyk2KpNL9wzPBy55Mq4ih2j gQ3eZYGXbIPCEUuL8ImTyvaD5lxBAn73JeKL9Ugdv6JRuCBgAqQN48CG/iNpKW97W4dD 8DCkDKZxXtbLuSFSGDXz8Q9vMeA1dDqRTnpd1sjygcNHsAbVkILEcFI+u8Bq1YphhwJA fY80PxN2Q75Sa9ICACm8Phjde7LkN2jLLC93XHfXsopE4n9FqXx1YjKNrlGigJuXgPOm a7yVBWh0vu1yR8Oa6rWczkkRrXYMZPCRQZGXSQbnEe0wqJ5a+TukoxuOS8b/wFRW9Vl5 32Ww== X-Gm-Message-State: AMCzsaVoIKDYu+OfU27xbVQKLnTCCLFIH5C4+sZSRa3L6PQru8COL+7t 9Du/qpWQgOXOLd9wTpWHiKnms5WZ X-Google-Smtp-Source: AOwi7QDEkBxd/cVgjIIApdU07ARbupRyAw8l6P3Czd1be82hxqM3zuJs6ZAAt07be7OcafUH6It5Ig== X-Received: by 10.55.39.145 with SMTP id n139mr6348937qkn.70.1506976288702; Mon, 02 Oct 2017 13:31:28 -0700 (PDT) Received: from ?IPv6:2620:15c:6:fd00:492f:46b3:8a8:5f2f? ([2620:15c:6:fd00:492f:46b3:8a8:5f2f]) by smtp.gmail.com with ESMTPSA id j19sm6921628qkh.38.2017.10.02.13.31.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Oct 2017 13:31:28 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> Date: Mon, 2 Oct 2017 16:31:22 -0400 To: tls@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 20:31:31 -0000 We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS = extension defined in this I-D takes into account what we heard from the = discussion regarding TLS visibility and = draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it = provides an opt-in capability for both the TLS client and server and = makes it clear on the wire that visibility will be enabled for the = session. The new mechanism does not depend on static handshake or = session keys. =20 - Ralph and Russ From nobody Mon Oct 2 14:23:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58D01348D1 for ; Mon, 2 Oct 2017 14:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 sVb1onR-9mku for ; Mon, 2 Oct 2017 14:23:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511CF133187 for ; Mon, 2 Oct 2017 14:23:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 88171BF6B; Mon, 2 Oct 2017 22:23:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S39r_MU5HokJ; Mon, 2 Oct 2017 22:23:07 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DAA19BF66; Mon, 2 Oct 2017 22:23:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1506979387; bh=OAWisZrXCEg4Q2Ajd6ufbzzpdy/vsh6S5cSJDs+QVo8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bJKDq9TBQAqVLCaZcuBlLJyPD5HI/cwfXPJbEzIARQUIiMQ+Y7+9HMoXvh0+IKoJ/ HaqpRsS++XPz0GsIqYw3x+KxZn0PzEav8MKthqEUwpY11+mVzvPReTyKUIt/iVE5as vE//1N8K/Tw6V4uUwUvN/f5y0Ve0AnKeZN2H2fiA= To: Ralph Droms , tls@ietf.org References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> Date: Mon, 2 Oct 2017 22:23:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h2FWh2AFckpf84pu0sPtIpDj67HWIhkHM" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 21:23:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h2FWh2AFckpf84pu0sPtIpDj67HWIhkHM Content-Type: multipart/mixed; boundary="ksnfbLLvVwTv7JV0Nu5jIJNfdKoPUIul8"; protected-headers="v1" From: Stephen Farrell To: Ralph Droms , tls@ietf.org Message-ID: <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> In-Reply-To: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> --ksnfbLLvVwTv7JV0Nu5jIJNfdKoPUIul8 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Sigh:-( IMO the WG shouldn't touch this terrible proposal with a bargepole. And it remains outside the WG's charter I think. (It would be a good idea if the chairs would clarify that a re-charter would be needed were the WG to go bonkers and adopt a terrible idea like this.) I guess I'll need to update [1] too. I'll get back when I've had a chance to do that but will happily accept PRs as before and will keep an eye on the list. For starters, though, I'd be interested answers from the authors to two quick questions, though I suspect I can guess 'em: 1. TLS1.3 has had significant formal analysis. Did the authors or other proponents here do any such work and if so can you send a pointer to your results? If not, then I believe the onus is on the folks who want to break TLS to do that work themselves if they want to make a serious proposal and it is not ok IMO to try put that work onto the community who have been working hard for years to make TLS stronger. 2. Which of the hundreds of applications making use of TLS did you analyse before proposing this? If only a handful, then same comment wrt where the onus ought lie. S. [1] https://github.com/sftcd/tinfoil#latest On 02/10/17 21:31, Ralph Droms wrote: > We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS ex= tension defined in this I-D takes into account what we heard from the dis= cussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-0= 0 in Prague. Specifically, it provides an opt-in capability for both the = TLS client and server and makes it clear on the wire that visibility will= be enabled for the session. The new mechanism does not depend on static= handshake or session keys. =20 >=20 > - Ralph and Russ >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --ksnfbLLvVwTv7JV0Nu5jIJNfdKoPUIul8-- --h2FWh2AFckpf84pu0sPtIpDj67HWIhkHM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ0q46AAoJEC88hzaAX42iVegIAKoERKNnIP11O2jIm1ReXDM4 JRns4lOA2gXsD0g/2ysCprFR1w0bR4bLEOOJZqG4n4AtqUS7Nr4ruERbxvA6L1KL ++ed/RmhNvyYLE+j5hlTQMD8Uf2nQEHxQ+OrVrbN9oUXeuVEtIsIuq05c02vao9g vRI51bRyQgYvQDPVHZ2b5dZIGsJfAGuU6XAsNu+Qt4zyaGnbgqaiD8b+Ix6urZvL 3RN5HEcbgS/fib2WklWWLdPypEFqCpMTCJce15F8YKvUqmcRwfryk9LhC0HP8fkW edldO95hJQj+6AY9mNuS2N73XuyaftVWwdrW/zLaPKalslDHjKXUdW8g2OEYokc= =jUM1 -----END PGP SIGNATURE----- --h2FWh2AFckpf84pu0sPtIpDj67HWIhkHM-- From nobody Mon Oct 2 14:43:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992111348D8 for ; Mon, 2 Oct 2017 14:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 YoqcM7Q2Xv5G for ; Mon, 2 Oct 2017 14:43:43 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414D813421C for ; Mon, 2 Oct 2017 14:43:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9272C30058D for ; Mon, 2 Oct 2017 17:43:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XUkqvYbKNOTJ for ; Mon, 2 Oct 2017 17:43:41 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6DC953004BC; Mon, 2 Oct 2017 17:43:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> Date: Mon, 2 Oct 2017 17:43:40 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 21:43:44 -0000 > For starters, though, I'd be interested answers from the authors > to two quick questions, though I suspect I can guess 'em: >=20 > 1. TLS1.3 has had significant formal analysis. Did the authors > or other proponents here do any such work and if so can you send > a pointer to your results? If not, then I believe the onus is on > the folks who want to break TLS to do that work themselves if they > want to make a serious proposal and it is not ok IMO to try put > that work onto the community who have been working hard for years > to make TLS stronger. I would be willing to work with the people that did the formal analysis = to show the impact of including the extension, and making changes to the = extension that are indicated by that analysis. > 2. Which of the hundreds of applications making use of TLS did > you analyse before proposing this? If only a handful, then same > comment wrt where the onus ought lie. Just like TLS 1.3 has been implemented and tested with many applications = during its development, I would expect the same to happen in those = environments where there is interest in making use of this extension. Russ From nobody Mon Oct 2 14:51:55 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F5B1348E2 for ; Mon, 2 Oct 2017 14:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aipbbVzRjr4A for ; Mon, 2 Oct 2017 14:51:51 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4251348E3 for ; Mon, 2 Oct 2017 14:51:51 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id k4so11085769wmc.1 for ; Mon, 02 Oct 2017 14:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=szkx6sqCkOROEc+ZlVjVSRIBGelfsPkFyezp8t0YvII=; b=2NrT/AO4LHbZWovJQfzMB7koy9sBvhXaLJhLEuWXNlnzJcgd0+I1mnaYbsU0kGvz4E cVRV045irzllee2CHi3R4eaxERyQzDRgIvtRCgZ47Dq2UYTq9P2j2z988Sagkj1ah0Xx jOWFgWBI+Sj28ubzDHb/AJafz24p0dGO+MY6CEJVjXoEscFAGnLsfPXHVJroRs7cXJx1 QEnZxAGI+td5Ro1ZsKpmMZpemziNQ3B4uObG29HU+BDFQK3udRSC/mgJ/68BjRzWW4rX PovxWzLceCwPgVDuMeY7SzwY1TKOQ4cBP85H/lcveFXSCZIs6Kwq5+jZMZyUSZaJoh7H KBww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=szkx6sqCkOROEc+ZlVjVSRIBGelfsPkFyezp8t0YvII=; b=QLDblJBvjtCfPg0AeT2friWNoC4XgzkhEg/YaXTWfeA/yoUPCbDCW2VkVmc0ghAkhg z/wFxYmJCdrFpKTaYwVjuZYmjvN4k1S5ZPPUaJdGlCafz8YNhu3XsifEnPzLf/WtcgQY 5w3T30PQvpWm+A4e3m0AMCqeoZ0VvbvWnspM/ne+PTVlqjJtgIsAOXzsVx+y64Dj+K8o KZ9f8DokO5L/9URKA+kriYesiPD2Q8cIEhr+9yZIaJKA6CKMwnVsmAbMrxUhkhEdbR8R jPOJAAH7k5B2VzPOuNOYWnV19E1bkSyq6fvK5W8DWRqKyWe2WBTnnbJZyFLQyWl+hxjV juNA== X-Gm-Message-State: AMCzsaU3hATEx99uOZlEeasfMT3yAGizbfB8QRNzYALzcbC49KOJtJgs AWGsTlZiaMbP2EjavWqbNoTG0b0rAxaZ65SXe39Nzw== X-Google-Smtp-Source: AOwi7QArNoZn4SM5IoUR59d9R6JwI2w7ph7MHTF/6OwS0zTu/2tSU8q04RaTVQ5iisxx3TScjbItVltQXISpP2WgbWA= X-Received: by 10.28.11.195 with SMTP id 186mr10691204wml.41.1506981109921; Mon, 02 Oct 2017 14:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.210 with HTTP; Mon, 2 Oct 2017 14:51:49 -0700 (PDT) In-Reply-To: <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> From: Richard Barnes Date: Mon, 2 Oct 2017 17:51:49 -0400 Message-ID: To: Russ Housley Cc: Stephen Farrell , IETF TLS Content-Type: multipart/alternative; boundary="001a11442254bd8f05055a976102" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 21:51:54 -0000 --001a11442254bd8f05055a976102 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 2, 2017 at 5:43 PM, Russ Housley wrote: > > For starters, though, I'd be interested answers from the authors > > to two quick questions, though I suspect I can guess 'em: > > > > 1. TLS1.3 has had significant formal analysis. Did the authors > > or other proponents here do any such work and if so can you send > > a pointer to your results? If not, then I believe the onus is on > > the folks who want to break TLS to do that work themselves if they > > want to make a serious proposal and it is not ok IMO to try put > > that work onto the community who have been working hard for years > > to make TLS stronger. > > I would be willing to work with the people that did the formal analysis to > show the impact of including the extension, and making changes to the > extension that are indicated by that analysis. > If you're feeling enterprising, at least one model for TLS 1.3 is open source. https://github.com/tls13tamarin/TLS13Tamarin I'm told that it takes a good part of an hour to run, though, so be prepared. --Richard > > 2. Which of the hundreds of applications making use of TLS did > > you analyse before proposing this? If only a handful, then same > > comment wrt where the onus ought lie. > > Just like TLS 1.3 has been implemented and tested with many applications > during its development, I would expect the same to happen in those > environments where there is interest in making use of this extension. > > Russ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11442254bd8f05055a976102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 2, 2017 at 5:43 PM, Russ Housley <housley@vigilsec.com<= /a>> wrote:
= > For starters, though, I'd be interested ans= wers from the authors
> to two quick questions, though I suspect I can guess 'em:
>
> 1. TLS1.3 has had significant formal analysis. Did the authors
> or other proponents here do any such work and if so can you send
> a pointer to your results? If not, then I believe the onus is on
> the folks who want to break TLS to do that work themselves if they
> want to make a serious proposal and it is not ok IMO to try put
> that work onto the community who have been working hard for years
> to make TLS stronger.

I would be willing to work with the people that did the formal analy= sis to show the impact of including the extension, and making changes to th= e extension that are indicated by that analysis.
=

If you're feeling enterprising,= at least one model for TLS 1.3 is open source.

https://github.c= om/tls13tamarin/TLS13Tamarin

I'm told that= it takes a good part of an hour to run, though, so be prepared.
=
--Richard


=C2=A0
> 2. Which of the hundreds of applications making use of TLS did
> you analyse before proposing this? If only a handful, then same
> comment wrt where the onus ought lie.

Just like TLS 1.3 has been implemented and tested with many applicat= ions during its development, I would expect the same to happen in those env= ironments where there is interest in making use of this extension.

Russ

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a11442254bd8f05055a976102-- From nobody Mon Oct 2 15:48:50 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C37F1342AD for ; Mon, 2 Oct 2017 15:48:48 -0700 (PDT) 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 qyEph0Ii9U_1 for ; Mon, 2 Oct 2017 15:48:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CE4132D51 for ; Mon, 2 Oct 2017 15:48:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EDEDFBF66; Mon, 2 Oct 2017 23:48:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 927Hr-Y1v-uJ; Mon, 2 Oct 2017 23:48:42 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B5437BF65; Mon, 2 Oct 2017 23:48:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1506984522; bh=xvlhPlzomEsB7oxb05Hqpt47ANVgex14sP73mMxMloA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pMF/6wfad6mNC/lgH575b4a5MT6RuBk505nJBq5pYckjuFYWf0Pv+nCsJGINI3olI De3KKRrlQKsyfEWaAVwDfFmAgsZVx1r8VREtcnXSPjeMiLwdFtpBJ1UmpRexk0fzSx Yoom7L8rV0xJ14x2oSCDQgURXqPV1mvcHG1cLbrM= To: Russ Housley Cc: IETF TLS References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2f8c1e4e-5997-de8a-c10e-c409dff3fc13@cs.tcd.ie> Date: Mon, 2 Oct 2017 23:48:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KW7JQK7o1oAcLh84GivLmDp39N2nQRRBF" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 22:48:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KW7JQK7o1oAcLh84GivLmDp39N2nQRRBF Content-Type: multipart/mixed; boundary="U3mMbHR6KgkWn924plPX10TLiAUGsj7wT"; protected-headers="v1" From: Stephen Farrell To: Russ Housley Cc: IETF TLS Message-ID: <2f8c1e4e-5997-de8a-c10e-c409dff3fc13@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> In-Reply-To: <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> --U3mMbHR6KgkWn924plPX10TLiAUGsj7wT Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Russ, On 02/10/17 22:43, Russ Housley wrote: >> For starters, though, I'd be interested answers from the authors to >> two quick questions, though I suspect I can guess 'em: >>=20 >> 1. TLS1.3 has had significant formal analysis. Did the authors or >> other proponents here do any such work and if so can you send a >> pointer to your results? If not, then I believe the onus is on the >> folks who want to break TLS to do that work themselves if they want >> to make a serious proposal and it is not ok IMO to try put that >> work onto the community who have been working hard for years to >> make TLS stronger. >=20 > I would be willing to work with the people that did the formal > analysis to show the impact of including the extension, and making > changes to the extension that are indicated by that analysis. >=20 IMO, that's not a good answer. When improving the security properties of the protocol it may suffice. When weakening the protocol, I strongly believe the onus is on you to have done that work ahead of time, so that the damage you are proposing the Internet suffers is clear and known and not discovered years later. >> 2. Which of the hundreds of applications making use of TLS did you >> analyse before proposing this? If only a handful, then same comment >> wrt where the onus ought lie. >=20 > Just like TLS 1.3 has been implemented and tested with many > applications during its development, I would expect the same to > happen in those environments where there is interest in making use of > this extension. The TLS WG has spent an awful lot of effort on (I think) every single semantic difference between TLS1.2 and TLS1.3. (Ortt for example.) You are now asking that everyone else do work to figure out how your proposal damages their uses of TLS so that this supposed use case is dealt with. I think you and other proponents of breaking TLS need to spend that effort yourselves. (This is because as you know there is no way to limit the damage of your proposal to only the use-cases that are the claimed targets for this bad idea.) So yes, those answers are as I expected and are just as unsurprisingly, utterly unsatisfactory. S. >=20 > Russ >=20 >=20 --U3mMbHR6KgkWn924plPX10TLiAUGsj7wT-- --KW7JQK7o1oAcLh84GivLmDp39N2nQRRBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ0sJKAAoJEC88hzaAX42izYQH/0PNceqDd7t6b+TjrBynyOIZ uZ0GKWhp/esA6HWIR8NiqMAoAb+g03pZnWxJs95vBfC4NgVw7u6DPQ+nuYAwjc9w BRg8nFYkLzmb/RltZbSIXx+bPL7Z6MXORSKMO6VWm8rLHTpSzTVdmXSaPwALTVrX 82oCXuL8L+f0ZRyIAaXpko4rytIO1dU/XMualKqHiAj3phc+rU9Uq0v3QzEu0S7L 5MM356zeOfbHjJHDpQa0mjDHjEaR5o6cff+kl4DkGZEsouGQtGKf23EgTSy14Nyb 0JitQfMdxmoNWwAQBJ7bRVeDRkVfSMfGlN/3sL4EEHeWuKerZLTPaGMxUr4bKpc= =P3KD -----END PGP SIGNATURE----- --KW7JQK7o1oAcLh84GivLmDp39N2nQRRBF-- From nobody Tue Oct 3 15:54:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC1513421C for ; Tue, 3 Oct 2017 15:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 momUYFVZzZTt for ; Tue, 3 Oct 2017 15:54:08 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FB5132992 for ; Tue, 3 Oct 2017 15:54:08 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id i82so17365633wmd.3 for ; Tue, 03 Oct 2017 15:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=WMC/nIQLhhWLKGlF6GDDC41Eir2i8w8iz81RU4WMV7k=; b=dUTPK6CFIclV61M+Q9RFTc2zoQL4sZNYvkkrBnqKT0AqG89omEsjAzxta+HrJqp/XH hu+KWfSK4hpv1pD9MGG3XMdKZRWB2MNFHDtkg3p67HfCwh+oM+AdKipXQ6aTTOgP03Re WQfcmcTt8zAmhRiW7WApbPcb++hb+cO1LrsPk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=WMC/nIQLhhWLKGlF6GDDC41Eir2i8w8iz81RU4WMV7k=; b=owQPu2/bZV22qMI7K+6/NydCoA2EdWpk2FXaVeiPHxvLgWfp6cZqYHrjiimJZIkY7m dAGQPqH5hDAXjXcsu8Bobp8lLy+TrfJ0AsZxXSL7SMJD5skSyEUAR+FT7VtXdLiisOnO ABH7w59ksYmnT9iVGETYe+zt/60llPjOQrERxgTOhUJyM1AC6+WwFXfa50vv/sDzXoL2 FF76ZFwiGwS2ME7vFT4z6lrP0YgAlGI7fhIjHX1ldFE6V2NuuhQ57SHwRL2Sryb42zuN Y8iECuwiF/ldT5guiujNr/AHS/FQyV+rGvYWXq6/d4oS7WLnFlvuHbH9qlmjGcQC4GCQ 8TWw== X-Gm-Message-State: AHPjjUhX0GqSNdfe6tS8opt1zVJ+jGVD8Gg/XL7bGFdSiVemgswA5Dol bzRwMvyFHIgp8SX3vwItfLbY8AaKp6A= X-Google-Smtp-Source: AOwi7QDuEwwFmbyRPj+9vxXUznv86D7/oA0Cp/Xlb4D+5xP9XN86u4yQlc4T0VbZE+uhHUv2jgnUHw== X-Received: by 10.80.170.46 with SMTP id o43mr26768391edc.40.1507071246656; Tue, 03 Oct 2017 15:54:06 -0700 (PDT) Received: from [5.5.33.167] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id j6sm7891356edj.58.2017.10.03.15.54.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2017 15:54:05 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 3 Oct 2017 15:53:59 -0700 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 22:54:10 -0000 In the IANA registries draft = (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates), we=E2=80=99= ve added a recommended column to the Cipher Suites (CSs) registry (and = some others). Right now, the criteria for getting a recommended mark is = AEAD ciphers with strong authentication standards track ciphers. While = that=E2=80=99s great generally, the list we=E2=80=99ve got five CSs that = gave Joe and I pause: TLS_DHE_RSA_WITH_AES_128_CCM_8 TLS_DHE_RSA_WITH_AES_256_CCM_8 TLS_PSK_DHE_WITH_AES_128_CCM_8 TLS_PSK_DHE_WITH_AES_256_CCM_8 TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 The CCM_8 CSs have a significantly truncated authentication tag that = represents a security trade-off that may not be appropriate for general = environment. In other words, this might be great for some IoT device = but we should not generally be recommending these. We=E2=80=99re recommending that these five suites be dropped from the = recommended list. Please let us know what you think. J&S (editor hats on)= From nobody Tue Oct 3 18:55:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE29132153 for ; Tue, 3 Oct 2017 18:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 Nww26EcvWYhj for ; Tue, 3 Oct 2017 18:55:38 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6548D1201F8 for ; Tue, 3 Oct 2017 18:55:38 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1507082135; h=from:subject:to:date:message-id; bh=yKG9sLcZ41NKHtXPy2aa6SzTrxzgljGe65h5Iv9m1bA=; b=VXsKpMLlcSz9zv33Cc9FqYvn1aqO2I6uyf1ITn6g2nol/XDtMv42aANGgQTNchszBcBsyjGAtC0 qrb5wmIc2YYLXqM8suv7UlgzT6+6KFz6jss7CabtcPl8e5cKL59ryM+mkMWzEs9/XEC6z4RjwpNon xWD+YpPW/4QaQD+3uu7PKbAB5JZDWNlL/PjXA0mVhBbiwTiqywdLCTOhMagiNYHH1ayAlWEJQfYjh 8CLYMTNcfoRwuCq7yvI/9Iwy98MnRQYe0LTkAkD1xxetOlnz6usciy1aQxTLfe/FxtaHP9Uj4v53i i6GgDjJ9KyxFQzvQSOxUIYmCkcVn8/oXRkqg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 3 Oct 2017 18:55:35 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 3 Oct 2017 18:54:42 -0700 From: Jim Schaad To: 'Sean Turner' , References: In-Reply-To: Date: Tue, 3 Oct 2017 18:55:28 -0700 Message-ID: <01aa01d33cb3$dbbaeeb0$9330cc10$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGOfyxPf0jr8kCELZhEZc0qlZrQtqNcaOqw X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 01:55:40 -0000 How much of a problem with people are we going to get into if the IoT = profiles for the IETF go and say "You MUST use this algorithm which the = IETF does not recommend?" I think that this is very likely to get some strong push back from = people I that is the case. Reluctantly I think that we need to keep the = recommendation on this algorithms. > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sean Turner > Sent: Tuesday, October 3, 2017 3:54 PM > To: > Subject: [TLS] Should CCM_8 CSs be Recommended? >=20 > In the IANA registries draft = (https://github.com/tlswg/draft-ietf-tls-iana- > registry-updates), we=E2=80=99ve added a recommended column to the = Cipher Suites > (CSs) registry (and some others). Right now, the criteria for getting = a > recommended mark is AEAD ciphers with strong authentication standards > track ciphers. While that=E2=80=99s great generally, the list = we=E2=80=99ve got five CSs that > gave Joe and I pause: >=20 > TLS_DHE_RSA_WITH_AES_128_CCM_8 > TLS_DHE_RSA_WITH_AES_256_CCM_8 > TLS_PSK_DHE_WITH_AES_128_CCM_8 > TLS_PSK_DHE_WITH_AES_256_CCM_8 > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 >=20 > The CCM_8 CSs have a significantly truncated authentication tag that > represents a security trade-off that may not be appropriate for = general > environment. In other words, this might be great for some IoT device = but we > should not generally be recommending these. >=20 > We=E2=80=99re recommending that these five suites be dropped from the > recommended list. Please let us know what you think. >=20 > J&S > (editor hats on) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Oct 3 19:55:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369E8126BF3 for ; Tue, 3 Oct 2017 19:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agKTeEx1AXoa for ; Tue, 3 Oct 2017 19:55:24 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 6D06E1321A1 for ; Tue, 3 Oct 2017 19:55:24 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id f15so16772079qtf.7 for ; Tue, 03 Oct 2017 19:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vBWTfD/gOAuZS8MQUIwdg9fRGY8YAUBmpqR+jDp50tQ=; b=CnN9E8d0YcMaiSrFidHudrxEjfdxzXfYRwCk5J8773GmkzpQkb/Upo9T9HJNwYl2PP 8iZrZp3vqM7PasTMNDr7M+E24KbqugTQtXXN9yVcb2OyE4mVQSbiwNdqAs9KK6/z8HIF /wMsrMOI1ZcKMOscWZMzFQ3QNBEkNTGdfsNxd+eivY8piX/d9zprEQ562z90eQ7tXzXn u5ti8oZ9CIKwajpnsk1DJOLh5QbOprzh+Gic1YPmojVhwPmVN1HT+1GnLLjFkOYv6FNx 7hmGg29FIkSWbmGVk3f0ZTKa6HzrAQGq5vFC8CmNArc7OHMylxjdeN0mw+a8qdDA29M5 VXfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vBWTfD/gOAuZS8MQUIwdg9fRGY8YAUBmpqR+jDp50tQ=; b=Rx0SHNilBmw5Sb3IsZE8ZMDTpbj0OrMMEb17BpAsOo1GB2I0jE7DIWyobHGUZZOkv9 9DBALadlIyUbdGA0lxYSVKMUNTolrRixpR8OZlXCrrz2S1k+HP2Gn+stVl+M+8V5ubU2 5S1vm4Jq9wt2ICDjSN7wL2HdCaw+BF4x+FeaKyDfTqB2jA1sROTFTFRzs+OzPoyXM4TJ yBrBs39azJCZnIX0GROizum4nQFAt+hsDOBxSDQyeZf01i/zLO3gwuUBnfTb6NIHkbNQ ZZHeVG7m57BBc3j2lkIIv7xb8awU6bxat0o7nyk2sXAr7x+0CoIYMWGw6wW99H/3gsWL w70A== X-Gm-Message-State: AMCzsaVePDszdKefACKADgnmNYJCpPa8EKkO492lyju4h9mHz/Zn4y8w gVaP0/PKLTctsm6dRtPhGr4s9y8hBOHJpyk3H/n6QkyK X-Google-Smtp-Source: AOwi7QCTJ4yKivzh5z+pp+khXCO5PEzGqDM5DHkMxDEWj9/zh1Zq83x6holqjxQsxT1CIogK5AsND6Me1p+CgyovzNk= X-Received: by 10.37.132.73 with SMTP id r9mr2981339ybm.165.1507085723475; Tue, 03 Oct 2017 19:55:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Tue, 3 Oct 2017 19:54:42 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 3 Oct 2017 19:54:42 -0700 Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary="089e0826fee431bbf0055aafbdda" Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 02:55:26 -0000 --089e0826fee431bbf0055aafbdda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Generally I tend to agree we should remove these, but as Jim said, there are reasons where I guess they make sense. Could we add a "Special Circumstances" marking? -Ekr On Tue, Oct 3, 2017 at 3:53 PM, Sean Turner wrote: > In the IANA registries draft (https://github.com/tlswg/ > draft-ietf-tls-iana-registry-updates), we=E2=80=99ve added a recommended = column > to the Cipher Suites (CSs) registry (and some others). Right now, the > criteria for getting a recommended mark is AEAD ciphers with strong > authentication standards track ciphers. While that=E2=80=99s great gener= ally, the > list we=E2=80=99ve got five CSs that gave Joe and I pause: > > TLS_DHE_RSA_WITH_AES_128_CCM_8 > TLS_DHE_RSA_WITH_AES_256_CCM_8 > TLS_PSK_DHE_WITH_AES_128_CCM_8 > TLS_PSK_DHE_WITH_AES_256_CCM_8 > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 > > The CCM_8 CSs have a significantly truncated authentication tag that > represents a security trade-off that may not be appropriate for general > environment. In other words, this might be great for some IoT device but > we should not generally be recommending these. > > We=E2=80=99re recommending that these five suites be dropped from the rec= ommended > list. Please let us know what you think. > > J&S > (editor hats on) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e0826fee431bbf0055aafbdda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Generally I tend to agree we should remove these, but as J= im said, there are reasons where I guess they make sense. Could we add a &q= uot;Special Circumstances" marking?

-Ekr
=

O= n Tue, Oct 3, 2017 at 3:53 PM, Sean Turner <sean@sn3rd.com> wro= te:
In the IANA registries draft (https://github.com/tlswg/draft-ietf-tls-i= ana-registry-updates), we=E2=80=99ve added a recommended column to= the Cipher Suites (CSs) registry (and some others).=C2=A0 Right now, the c= riteria for getting a recommended mark is AEAD ciphers with strong authenti= cation standards track ciphers.=C2=A0 While that=E2=80=99s great generally,= the list we=E2=80=99ve got five CSs that gave Joe and I pause:

TLS_DHE_RSA_WITH_AES_128_CCM_8
TLS_DHE_RSA_WITH_AES_256_CCM_8
TLS_PSK_DHE_WITH_AES_128_CCM_8
TLS_PSK_DHE_WITH_AES_256_CCM_8
TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256

The CCM_8 CSs have a significantly truncated authentication tag that repres= ents a security trade-off that may not be appropriate for general environme= nt.=C2=A0 In other words, this might be great for some IoT device but we sh= ould not generally be recommending these.

We=E2=80=99re recommending that these five suites be dropped from the recom= mended list.=C2=A0 Please let us know what you think.

J&S
(editor hats on)
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--089e0826fee431bbf0055aafbdda-- From nobody Wed Oct 4 00:30:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C06413318B for ; Wed, 4 Oct 2017 00:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdCsVK-vA10X for ; Wed, 4 Oct 2017 00:30:32 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 AFD0513295C for ; Wed, 4 Oct 2017 00:30:31 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id i82so18758156wmd.3 for ; Wed, 04 Oct 2017 00:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kEgP6j8TwiTBjHBes1YPKdkq7aoZ8r17T1x3B7r7ZBI=; b=IT3+wq0hW9ILTEeDO4FHSZvnjMhXqNZxNWbcbP7JO05uge45gAr2LVSwCIwB/PmDUH YoJ3BmSmai/uAPjJ5VN9gd94HpWdVNC9tM4NZCafH0FZv0KvwO3bIlqThMTuvJvMKrIg Xi3Nlf0J8n/b8p4g8ra5jRXzPH4QTCo7ajJEjqoTr4AbbyaXrBjx0F3KlWxaM+uKwGYQ dq48ok/6JI5RNwPzcoCvfIwwC0gZqdSrc7q1KNIdbZ+Tj/Bj/yuhrG9NWv8X1k+oUx8F yZPI/SipU1gDKk9pYsvzDUbSgHtSgV9HjM7INTLy12kFRESoJwtPwV+O0p2s0wnhsSEU 3wJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kEgP6j8TwiTBjHBes1YPKdkq7aoZ8r17T1x3B7r7ZBI=; b=bIt/J6DMOW1sg9n7NNuMdq8ldH/QLiro2fzO+/BNckf20kKeIAWfxVC8nsuu6iObf4 6YTQY4gq7ItmVSoIs6pV0xIhuswPnKVnPGnn7VsenmCiN3MLW7noO6R8rBAX3ILrTp1Y Ty3kUST1F8Z52lB/Cgz/OFX4CJ6lsbw1t4ZquI8/4Hhfiii/qkUjdM+ylMOQCLvLmf2q I4YJOAKKedEX8/Rllvnr+m8DLRLdyfejDGpbvPEfmq1RlMX3KNAOyy0ypjyP/+HRjhU0 1/VA85tCtCPoNzFI2xF7jThj20Ko0UUocnIFBUdT5A3f2Mc17FIiRThRx3buvLdLLx/E BUkA== X-Gm-Message-State: AHPjjUiOk0pDIoWickz/psuJGMLG9ZiU2up2ZjguzVb62CJkOlsEie1k CEivv+FpR/9d7nq7Qhww+sXhi6GX X-Google-Smtp-Source: AOwi7QBqb7r8drIdY880A122/6bFoqQT/gGYjNpIWunPzYwF1NCB+huFjcJ0Vr01EPwPtSe1t79H8w== X-Received: by 10.80.183.231 with SMTP id i36mr26763888ede.262.1507102230075; Wed, 04 Oct 2017 00:30:30 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m1sm13261498edd.56.2017.10.04.00.30.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 00:30:28 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D98D95DF-A554-4FC7-90FB-5C6F2F15ECBF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 4 Oct 2017 10:30:26 +0300 In-Reply-To: Cc: Sean Turner , "" To: Eric Rescorla References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 07:30:34 -0000 --Apple-Mail=_D98D95DF-A554-4FC7-90FB-5C6F2F15ECBF Content-Type: multipart/alternative; boundary="Apple-Mail=_B8022342-124B-4B1C-90FE-46656FF639E0" --Apple-Mail=_B8022342-124B-4B1C-90FE-46656FF639E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What we did in IPsec in RFC-tp-be 8221 is the following. This = (including the IoT marker) is also going to appear in the IANA registry: +-------------------------+------------+---------+----------------+ | Name | Status | AEAD | Comment | +-------------------------+------------+---------+----------------+ | ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED | | ENCR_DES | MUST NOT | No | [RFC2405] | | ENCR_3DES | SHOULD NOT | No | [RFC2451] | | ENCR_BLOWFISH | MUST NOT | No | [RFC2451] | | ENCR_3IDEA | MUST NOT | No | UNSPECIFIED | | ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED | | ENCR_NULL | MUST | No | [RFC2410] | | ENCR_AES_CBC | MUST | No | [RFC3602][1] | | ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309](IoT) | | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] | +-------------------------+------------+---------+----------------+ [1] - This requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at the MAY level. (IoT) - This requirement is for interoperability with IoT. Only 128-bit keys are at the given level. IPsec sessions may have very long lifetime and carry multiple packets, so there is a need to move to 256-bit keys in the long term. > On 4 Oct 2017, at 5:54, Eric Rescorla wrote: >=20 > Generally I tend to agree we should remove these, but as Jim said, = there are reasons where I guess they make sense. Could we add a "Special = Circumstances" marking? >=20 > -Ekr >=20 >=20 > On Tue, Oct 3, 2017 at 3:53 PM, Sean Turner > wrote: > In the IANA registries draft = (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates = ), = we=E2=80=99ve added a recommended column to the Cipher Suites (CSs) = registry (and some others). Right now, the criteria for getting a = recommended mark is AEAD ciphers with strong authentication standards = track ciphers. While that=E2=80=99s great generally, the list we=E2=80=99= ve got five CSs that gave Joe and I pause: >=20 > TLS_DHE_RSA_WITH_AES_128_CCM_8 > TLS_DHE_RSA_WITH_AES_256_CCM_8 > TLS_PSK_DHE_WITH_AES_128_CCM_8 > TLS_PSK_DHE_WITH_AES_256_CCM_8 > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 >=20 > The CCM_8 CSs have a significantly truncated authentication tag that = represents a security trade-off that may not be appropriate for general = environment. In other words, this might be great for some IoT device = but we should not generally be recommending these. >=20 > We=E2=80=99re recommending that these five suites be dropped from the = recommended list. Please let us know what you think. >=20 > J&S > (editor hats on) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_B8022342-124B-4B1C-90FE-46656FF639E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 What we did in IPsec in RFC-tp-be 8221 is the following. =  This (including the IoT marker) is also going to appear in the = IANA registry:
    =
+-------------------------+------------+---------+----------------+
    | Name                    | Status     | AEAD    | Comment        |
    +-------------------------+------------+---------+----------------+
    | ENCR_DES_IV64           | MUST NOT   | No      | UNSPECIFIED    |
    | ENCR_DES                | MUST NOT   | No      | [RFC2405]      |
    | ENCR_3DES               | SHOULD NOT | No      | [RFC2451]      |
    | ENCR_BLOWFISH           | MUST NOT   | No      | [RFC2451]      |
    | ENCR_3IDEA              | MUST NOT   | No      | UNSPECIFIED    |
    | ENCR_DES_IV32           | MUST NOT   | No      | UNSPECIFIED    |
    | ENCR_NULL               | MUST       | No      | [RFC2410]      |
    | ENCR_AES_CBC            | MUST       | No      | [RFC3602][1]   |
    | ENCR_AES_CCM_8          | SHOULD     | Yes     | [RFC4309](IoT) |
    | ENCR_AES_GCM_16         | MUST       | Yes     | [RFC4106][1]   |
    | ENCR_CHACHA20_POLY1305  | SHOULD     | Yes     | [RFC7634]      |
    +-------------------------+------------+---------+----------------+

   [1] - This requirement level is for 128-bit and 256-bit keys. 192-bit
   keys remain at the MAY level.

   (IoT) - This requirement is for interoperability with IoT.  Only
   128-bit keys are at the given level.

   IPsec sessions may have very long lifetime and carry multiple
   packets, so there is a need to move to 256-bit keys in the long term.

On 4 Oct 2017, at 5:54, Eric Rescorla <ekr@rtfm.com> = wrote:

Generally I tend to agree we should remove these, = but as Jim said, there are reasons where I guess they make sense. Could = we add a "Special Circumstances" marking?

-Ekr


On Tue, Oct 3, 2017 at 3:53 PM, Sean Turner <sean@sn3rd.com> wrote:
In the IANA registries = draft (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates), = we=E2=80=99ve added a recommended column to the Cipher Suites (CSs) = registry (and some others).  Right now, the criteria for getting a = recommended mark is AEAD ciphers with strong authentication standards = track ciphers.  While that=E2=80=99s great generally, the list = we=E2=80=99ve got five CSs that gave Joe and I pause:

TLS_DHE_RSA_WITH_AES_128_CCM_8
TLS_DHE_RSA_WITH_AES_256_CCM_8
TLS_PSK_DHE_WITH_AES_128_CCM_8
TLS_PSK_DHE_WITH_AES_256_CCM_8
TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256

The CCM_8 CSs have a significantly truncated authentication tag that = represents a security trade-off that may not be appropriate for general = environment.  In other words, this might be great for some IoT = device but we should not generally be recommending these.

We=E2=80=99re recommending that these five suites be dropped from the = recommended list.  Please let us know what you think.

J&S
(editor hats on)
_______________________________________________
TLS mailing list
TLS@ietf.org
= https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_B8022342-124B-4B1C-90FE-46656FF639E0-- --Apple-Mail=_D98D95DF-A554-4FC7-90FB-5C6F2F15ECBF 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlnUjhIACgkQuEkLFQpY zJkkAggArbBqmA4NWYRuybvGZYcn25/PP4Ed2Xo464JX/Oe0e2krbSWIYyeaB+U+ E6hr18r8N245ldYwm0z2UqOov4z/k3Yt1pHSwNpCEr/ynFnlWYR6ac/fhm2kXSmL tEbtzIfNfEm9IjX/PHFgut2rCg1IzCFzigmLdpj2ERTgYtCeg1C2bkjjAph9hs+k HdUFesDUunCw3LEVl/H5yHKcDCy2DDWzMYYU9E8/3m++YFf5ikd8sKo+cMneD51X hY/ezVxbrka0zaue8CjWlP5Eb4lfVKsi5hC19S8o8Dph6x0HcoTcDg2r9TKo3v72 0Vg3h55U+8kC63AWeKnYnlLxn298Kg== =hQAr -----END PGP SIGNATURE----- --Apple-Mail=_D98D95DF-A554-4FC7-90FB-5C6F2F15ECBF-- From nobody Wed Oct 4 04:58:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCDC1243F6 for ; Wed, 4 Oct 2017 04:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=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 5kYgQmwfS8vl for ; Wed, 4 Oct 2017 04:58:28 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 7008D132397 for ; Wed, 4 Oct 2017 04:58:28 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v94BvTi8016575; Wed, 4 Oct 2017 12:58:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=RYjd8QJXrHWJr0NYh80NIAu9UVKpJ92FyTg7RHMn2Cw=; b=YWmH9SYYmoh/sH/zP6u9QsG9Dz7s6c30W+jLFNUu3g7CTsoHti6oMEdw5/I9lRJk0yrO rWNfvG1OfRIui55N6UQy+t9wFsFy0hubYsdBWGldgVNblTekCu9S94Mh5deGmXNd35Dk glVoY57tV/TyDiAMMhwsY29arWcIJq2yXn//56lZuIAxNcqC0YwUA7y0syX1MSUeLWxA 6lwJJIXfROWCBujlmo8txe/2C2GZSfCBjPva0ahaaY10gEvbYZprNQYWcTKAYKz3vzlf +7scgFeTvg3rNr6guZgwnZ4nWpiaGIb5FUiuNlRvgUOuFtf+n5tfkfp88qjVpkNZTDot pg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2da3ah3abj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Oct 2017 12:58:26 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v94BuQLO015605; Wed, 4 Oct 2017 07:58:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dcksmhess-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Oct 2017 07:58:25 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Oct 2017 06:58:24 -0500 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.1263.000; Wed, 4 Oct 2017 06:58:24 -0500 From: "Salz, Rich" To: Sean Turner , "" Thread-Topic: [TLS] Should CCM_8 CSs be Recommended? Thread-Index: AQHTPJqL5DOxVoyYS0CQv5KHiX0PRaLT6sSA Date: Wed, 4 Oct 2017 11:58:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.242] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710040172 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710040172 Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 11:58:29 -0000 4p6iICBXZeKAmXJlIHJlY29tbWVuZGluZyB0aGF0IHRoZXNlIGZpdmUgc3VpdGVzIGJlIGRyb3Bw ZWQgZnJvbSB0aGUgcmVjb21tZW5kZWQgbGlzdC4gIFBsZWFzZSBsZXQgdXMga25vdyB3aGF0IHlv dSB0aGluay4NCiAgICANCg0KRG9lcyDigJxyZWNvbW1lbmRlZOKAnSBtZWFuIGZvciBnZW5lcmFs IHVzZSwgaW4gdGhlIHB1YmxpYyBJbnRlcm5ldD8gIE9yIGlzIGl0IOKAnEkga25vdyBpdCB3aGVu IEkgc2VlIGl04oCdIGtpbmQgb2YgdGhpbmc/DQoNCkVpdGhlciB3YXksIEkgc3VwcG9ydCB1bi1y ZWNvbW1lbmRpbmcgdGhlbQ0KDQo= From nobody Wed Oct 4 06:29:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306C0132031 for ; Wed, 4 Oct 2017 06:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=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 6WxCow_xjDH6 for ; Wed, 4 Oct 2017 06:29:33 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD65C126DFE for ; Wed, 4 Oct 2017 06:29:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1D01B3002AD for ; Wed, 4 Oct 2017 09:29:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 77zGzCuJIdbi for ; Wed, 4 Oct 2017 09:29:31 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9994530058D; Wed, 4 Oct 2017 09:29:31 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_81FFC99B-EAAC-45D8-8BDF-EE56E8FD7116" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 4 Oct 2017 09:29:30 -0400 In-Reply-To: Cc: IETF TLS To: Yoav Nir References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 13:29:35 -0000 --Apple-Mail=_81FFC99B-EAAC-45D8-8BDF-EE56E8FD7116 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 4, 2017, at 3:30 AM, Yoav Nir wrote: >=20 > (IoT) - This requirement is for interoperability with IoT. Only > 128-bit keys are at the given level. If the IoT environment is willing to accept lower integrity protection = in order to save a few bits on the wire/ether, I do not see why the = specification also forces them from using a larger key size. Russ --Apple-Mail=_81FFC99B-EAAC-45D8-8BDF-EE56E8FD7116 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Oct 4, 2017, at 3:30 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

   (IoT) - This requirement is for interoperability with IoT.  Only
   128-bit keys are at the given level.
If the IoT environment is willing to accept lower integrity protection in order to save a few bits on the wire/ether, I do not see why the specification also forces them from using a larger key size.

Russ

--Apple-Mail=_81FFC99B-EAAC-45D8-8BDF-EE56E8FD7116-- From nobody Wed Oct 4 06:49:07 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C48132697 for ; Wed, 4 Oct 2017 06:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itw5IMPXgpS6 for ; Wed, 4 Oct 2017 06:49:04 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6EE132199 for ; Wed, 4 Oct 2017 06:49:03 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id i82so20866593wmd.3 for ; Wed, 04 Oct 2017 06:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XZmHD2T9UQV64MyXPODR7hzHpy6CL4rXHp9NJoLN9qY=; b=thXQHbASUaoRsqPDL4/aFbOneEIzaA9XfcogSPb/Or01v8BYEtdaeOxMXDN7v1bt+W tufANwY0/Yf4AIAP7rXiuAdjJWITXs2/L81i3y0feFGfWnwyorHxX4CeA5uk5O3HoMri lu81dTnTHTwotVi6hxHrHePVsPyrqMqMx31Y1Aj8Lh9K5Us4BX2lL9FV5n+XvnYMl8R1 g5d3dqjIEOUaCF+2+6aA4+e+GO/E54LUhl/PWJ5Yoijw6zQZm3bgGtAjMUaq1hoTfWkW 0Vf1OJcM/Lz6y/Hfjl1IFDxKJgHFMafAef5J/FclHjC86R2NoV5+z+2RP1rz6bMoimv5 RPoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XZmHD2T9UQV64MyXPODR7hzHpy6CL4rXHp9NJoLN9qY=; b=MYCe4VzLRNYcb60nIPjEXapkLjILQjmgsj+GndNmZxXTdQ0O5yMTRRMk7bhkaRlBrJ oj8UikepgEMImcG5iMYV09S7T36S+hDEb4eaBeBTztnQyHrSGmcf9FWXhgl0jH+PCacX qgC5ovdxb6+L69bLZv5Amo4/cjGK9mLQm4W8HEWSgKTsWfKSIvGWVh4gk7oDhvXOI6zS gNzbXvf0+wGwDR2vpzQB2oInvam61PgBtJBmSZd14kz5Hr8DVPah98iY2YwiIrba4E6J f9A2uxvl66lRuLDm/7VoMf3cEPNks+IcP/Khf1ltpeg/ccHNeABd9ZZBvHCUzUPyDI5y o9mA== X-Gm-Message-State: AMCzsaUW4I3g+Bi5Ae40nICFsQG/S3I2kuKZiZpV6zxcU8SZD/cSI293 GHsHSJ0bsUqo1uuT8mIDBvCNjAsM X-Google-Smtp-Source: AOwi7QB7n8iGtZOnSh5RVCjAy60QMVmf6DjJBCBo410nexPMZL4gUoimur3Maaasx2XAJoVZCiufCA== X-Received: by 10.80.135.228 with SMTP id 33mr6805536edz.210.1507124942265; Wed, 04 Oct 2017 06:49:02 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id w20sm12150398edl.2.2017.10.04.06.49.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 06:49:01 -0700 (PDT) From: Yoav Nir Message-Id: <64D6B075-F0E9-47BD-85CE-055E777F4931@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_17B56CCE-5C8C-4767-ACFE-126E64860E48"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 4 Oct 2017 16:48:59 +0300 In-Reply-To: Cc: IETF TLS To: Russ Housley References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 13:49:06 -0000 --Apple-Mail=_17B56CCE-5C8C-4767-ACFE-126E64860E48 Content-Type: multipart/alternative; boundary="Apple-Mail=_84C9C5F7-3D8C-4600-9D43-B9319773B946" --Apple-Mail=_84C9C5F7-3D8C-4600-9D43-B9319773B946 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Oct 2017, at 16:29, Russ Housley wrote: >=20 >=20 >> On Oct 4, 2017, at 3:30 AM, Yoav Nir > wrote: >>=20 >> (IoT) - This requirement is for interoperability with IoT. Only >> 128-bit keys are at the given level. > If the IoT environment is willing to accept lower integrity protection = in order to save a few bits on the wire/ether, I do not see why the = specification also forces them from using a larger key size. >=20 > Russ >=20 Maybe to save a few cycles in addition to the few bits? They claimed = that the one AEAD cipher they needed was AES_CCM_8 with a 128-bit key, = because that was all that their hardware supports. What we are saying is that if you want your (in that case IPsec, but = it=E2=80=99s no different for TLS) to work with IoT devices, you need = that AEAD cipher. Yoav --Apple-Mail=_84C9C5F7-3D8C-4600-9D43-B9319773B946 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 Oct 2017, at 16:29, Russ Housley <housley@vigilsec.com> wrote:


On Oct 4, 2017, at 3:30 AM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

   (IoT) - This requirement is for interoperability with IoT. =
 Only
   128-bit keys are at the given level.
If = the IoT environment is willing to accept lower integrity protection in = order to save a few bits on the wire/ether, I do not see why the = specification also forces them from using a larger key size.

Russ


Maybe to save a few cycles in addition to the = few bits?  They claimed that the one AEAD cipher they needed was = AES_CCM_8 with a 128-bit key, because that was all that their hardware = supports. 

What we are saying is that if you want your (in that case = IPsec, but it=E2=80=99s no different for TLS) to work with IoT devices, = you need that AEAD cipher.

Yoav

= --Apple-Mail=_84C9C5F7-3D8C-4600-9D43-B9319773B946-- --Apple-Mail=_17B56CCE-5C8C-4767-ACFE-126E64860E48 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlnU5ssACgkQuEkLFQpY zJlH6QgAtknep6t3uPnX+1PpVCUgS9y6XuWkmak66HKhcaV97vqufylD/Jl4LukY DMp/IqIY0PWGjFKyUT/pmRViczILrBzSpsvTivaLMvWXgTQhP1EjcEVn0JiUtgZo Knf4tV9l1Ftu0q63J5uGJbyvpP3bZMRsCS+j1WS2ieIh8hnlG+XzjM85dAULH1hE 3hmWsvSqdfeTDNgNN1pd1PDlD4Owyn7ZrJ45oGzgwaA/LRd04BjObgxKeEUftJzx VH22UKrfrqXwd/KOgnZvNCGXbuh2hP7zJVQSeWzsKUXxv4OrMRJiGOBQJW+XQ8OB XZopeDpsPSHrKMy1XLFLBrxcRc1m0Q== =kg18 -----END PGP SIGNATURE----- --Apple-Mail=_17B56CCE-5C8C-4767-ACFE-126E64860E48-- From nobody Wed Oct 4 06:56:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82903126B6E for ; Wed, 4 Oct 2017 06:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CunN6MMJOYbU for ; Wed, 4 Oct 2017 06:56:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6111241F3 for ; Wed, 4 Oct 2017 06:56:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7F37A3005AD for ; Wed, 4 Oct 2017 09:56:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9C7zH-xG9o1P for ; Wed, 4 Oct 2017 09:56:54 -0400 (EDT) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id A09B3300563; Wed, 4 Oct 2017 09:56:54 -0400 (EDT) From: Russ Housley Message-Id: <2926B125-E1C5-4784-9048-FDDE068AB892@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BBE30700-ABAD-4D66-BCEF-39B0B5D15909"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 4 Oct 2017 09:56:51 -0400 In-Reply-To: <64D6B075-F0E9-47BD-85CE-055E777F4931@gmail.com> Cc: IETF TLS To: Yoav Nir References: <64D6B075-F0E9-47BD-85CE-055E777F4931@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 13:56:58 -0000 --Apple-Mail=_BBE30700-ABAD-4D66-BCEF-39B0B5D15909 Content-Type: multipart/alternative; boundary="Apple-Mail=_057C7057-665C-4806-A38A-993E934D60E2" --Apple-Mail=_057C7057-665C-4806-A38A-993E934D60E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 4, 2017, at 9:48 AM, Yoav Nir wrote: >=20 >=20 >> On 4 Oct 2017, at 16:29, Russ Housley > wrote: >>=20 >>=20 >>> On Oct 4, 2017, at 3:30 AM, Yoav Nir > wrote: >>>=20 >>> (IoT) - This requirement is for interoperability with IoT. Only >>> 128-bit keys are at the given level. >> If the IoT environment is willing to accept lower integrity = protection in order to save a few bits on the wire/ether, I do not see = why the specification also forces them from using a larger key size. >=20 > Maybe to save a few cycles in addition to the few bits? They claimed = that the one AEAD cipher they needed was AES_CCM_8 with a 128-bit key, = because that was all that their hardware supports. >=20 > What we are saying is that if you want your (in that case IPsec, but = it=E2=80=99s no different for TLS) to work with IoT devices, you need = that AEAD cipher. Right, but is there any reason to restrict CCM_8 to 128-bit keys in the = IANA registry entry? I can't see one. Russ --Apple-Mail=_057C7057-665C-4806-A38A-993E934D60E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 4, 2017, at 9:48 AM, Yoav Nir <ynir.ietf@gmail.com>= wrote:


On 4 Oct 2017, at 16:29, Russ Housley <housley@vigilsec.com> wrote:


On Oct 4, 2017, at 3:30 AM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

   (IoT) - This requirement is for interoperability with IoT. =
 Only
   128-bit keys are at the given level.
If = the IoT environment is willing to accept lower integrity protection in = order to save a few bits on the wire/ether, I do not see why the = specification also forces them from using a larger key = size.

Maybe = to save a few cycles in addition to the few bits?  They claimed = that the one AEAD cipher they needed was AES_CCM_8 with a 128-bit key, = because that was all that their hardware supports. 

What we are saying is = that if you want your (in that case IPsec, but it=E2=80=99s no different = for TLS) to work with IoT devices, you need that AEAD = cipher.

Right, = but is there any reason to restrict CCM_8 to 128-bit keys in the IANA = registry entry?  I can't see one.

Russ


= --Apple-Mail=_057C7057-665C-4806-A38A-993E934D60E2-- --Apple-Mail=_BBE30700-ABAD-4D66-BCEF-39B0B5D15909 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----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlnU6KYACgkQiuTu0PWcEcvYKQCgy0IF2DUK0MHrAeWFMagZ6r1L 7zYAoKo+9txpzdjD7RBLoscaTvNCrp1r =9plA -----END PGP SIGNATURE----- --Apple-Mail=_BBE30700-ABAD-4D66-BCEF-39B0B5D15909-- From nobody Wed Oct 4 07:46:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E9F132D45 for ; Wed, 4 Oct 2017 07:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5guNsV4CEacH for ; Wed, 4 Oct 2017 07:46:46 -0700 (PDT) Received: from nm15-vm10.access.bullet.mail.bf1.yahoo.com (nm15-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.41]) (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 809001321DF for ; Wed, 4 Oct 2017 07:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1507128405; bh=irPK2BhzJlOupB411g7ZMVgcWX4Lz0FRVvYxlhCigBs=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=ztCjHzKKKnZOugy+Ciwr8aMqjLlHSBaUcyl5kILp7vHE77tAVLWduZZx+EODxh72ZICK3jadAh687G8/ftb0CqMOxtpvl6mee1W7adPKSwl/HIDixXs8Z7448cynOeoTpRTtBV/MfniX+E1aRtmJ3SCVtYL1s3UlDthFnAbq360= Received: from [66.196.81.158] by nm15.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Oct 2017 14:46:45 -0000 Received: from [98.139.244.52] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Oct 2017 14:46:45 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.bf1.yahoo.com with NNFMP; 04 Oct 2017 14:46:45 -0000 X-Yahoo-Newman-Id: 628244.61621.bm@smtp114.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: o6iIzAcVM1kctkjNwmfFPEL9uUACBjzhSZvn384dMJxVXL7 WPMUq80VbOUv4U9lsdbanRfufzy8Hybbb9UcX4GQMPEHxUT4V.TmVJ8pmArU WMHJg8l9suQPv3X0qRMigsaBiNPMGZVGIVTRJduVvIkU2BVF7T_wdKTet3i7 YpYlx5GRAQ_V24rhOU5VPBe92QZS_IGwyhdaJrRPN.ME4nMsHZ9pqdJ7DTCv p_cQqNqagqij5Q6ywor5lfUavZ9rzTekte82PiXRcqbTB251iJYkoT7IFkKP CcELZfzXdEXeK2plmtoSC3ixsrjh94F62C3MrichmO.39RLAHyAA3n1Q_JJN dDw2PvxYh9VtgpEvrXTnh3bUv7UhHY.dtKd8sWfCHYDU1_lMjwyfv1MmeNxY CaE5VEMXZEmD5OrAbTFROtVIDHqf7osrdiLHs11e5WnniMYzBUknF8oWgvQV VHc8fVSqZerswtt6vyxPfb9eBiqlJ29p2eeaiqXBaC7nFC25EaDm3HEsbTA- - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- User-Agent: Microsoft-MacOutlook/14.7.3.170325 Date: Wed, 04 Oct 2017 07:46:41 -0700 From: Don Sturek To: Russ Housley , Yoav Nir CC: IETF TLS Message-ID: Thread-Topic: [TLS] Should CCM_8 CSs be Recommended? References: <64D6B075-F0E9-47BD-85CE-055E777F4931@gmail.com> <2926B125-E1C5-4784-9048-FDDE068AB892@vigilsec.com> In-Reply-To: <2926B125-E1C5-4784-9048-FDDE068AB892@vigilsec.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3589948005_175008" Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 14:46:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3589948005_175008 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Russ, At the upcoming IEEE 802.15 meeting in Orlando, we (vendors using IEEE 802.15.4) plan a presentation on support for AES-256 in an upcoming version of the 802.15.4 standard. In the Wi-SUN Alliance, we are using TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8 now= . It would be great to at least not prevent support for a longer key version of that going forward. Don Sturek From: TLS on behalf of Russ Housley Date: Wednesday, October 4, 2017 at 6:56 AM To: Yoav Nir Cc: IETF TLS Subject: Re: [TLS] Should CCM_8 CSs be Recommended? > On Oct 4, 2017, at 9:48 AM, Yoav Nir wrote: >=20 >=20 >> On 4 Oct 2017, at 16:29, Russ Housley wrote: >>=20 >>=20 >>> On Oct 4, 2017, at 3:30 AM, Yoav Nir wrote: >>>=20 >>> (IoT) - This requirement is for interoperability with IoT. Only >>> 128-bit keys are at the given level. >> If the IoT environment is willing to accept lower integrity protection i= n >> order to save a few bits on the wire/ether, I do not see why the >> specification also forces them from using a larger key size. >=20 > Maybe to save a few cycles in addition to the few bits? They claimed tha= t the > one AEAD cipher they needed was AES_CCM_8 with a 128-bit key, because tha= t was > all that their hardware supports. >=20 > What we are saying is that if you want your (in that case IPsec, but it=B9s= no > different for TLS) to work with IoT devices, you need that AEAD cipher. Right, but is there any reason to restrict CCM_8 to 128-bit keys in the IAN= A registry entry? I can't see one. Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --B_3589948005_175008 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Russ,

At the upcoming IEEE 802.15 meeting in Orlando, we (vendors using IEE= E 802.15.4) plan a presentation on support for AES-256 in an upcoming versio= n of the 802.15.4 standard.

In the Wi-SUN Alliance,= we are using TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8 now.  It would be grea= t to at least not prevent support for a longer key version of that going for= ward.

Don Sturek



From: TLS <tls-bounces@ietf.org> on behalf of Russ H= ousley <housley@vigilsec.com>= ;
Date: Wednesday, October 4, 2017= at 6:56 AM
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: IETF TLS <tls= @ietf.org>
Subject: Re: [TL= S] Should CCM_8 CSs be Recommended?


On Oct 4, 2017, at 9:48 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:


<= div class=3D"">
On 4 Oct 2017, a= t 16:29, Russ Housley <hou= sley@vigilsec.com> wrote:

=

On Oct 4, 2017, at 3:30 AM, = Yoav Nir <ynir.ietf@gmail.c= om> wrote:

<= pre class=3D"" style=3D"font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; text= -indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-w= idth: 0px; word-wrap: break-word; white-space: pre-wrap;"> (IoT) - This re= quirement is for interoperability with IoT. Only 128-bit keys are at the given level.
If th= e IoT environment is willing to accept lower integrity protection in order t= o save a few bits on the wire/ether, I do not see why the specification also= forces them from using a larger key size.
Maybe to save a few cycles in addition to the few bi= ts?  They claimed that the one AEAD cipher they needed was AES_CCM_8 wi= th a 128-bit key, because that was all that their hardware supports. 

What we are saying is tha= t if you want your (in that case IPsec, but it’s no different for TLS)= to work with IoT devices, you need that AEAD cipher.

Right, but is there any reason to restrict C= CM_8 to 128-bit keys in the IANA registry entry?  I can't see one.

Russ


_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/ma= ilman/listinfo/tls --B_3589948005_175008-- From nobody Wed Oct 4 11:42:14 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF2A134468 for ; Wed, 4 Oct 2017 11:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJDVx9Zx609v for ; Wed, 4 Oct 2017 11:42:10 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 50079134460 for ; Wed, 4 Oct 2017 11:42:10 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id u12so6697338pfl.4 for ; Wed, 04 Oct 2017 11:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X5h+e6pxPo805o9g/MC2hGfDqhJJdK72fhupi8nxzFc=; b=djy/msq46ROAeCBkZkGJkQ89P5+UMSehCl5jaK8PWtchBcgtsa5InuBwuSHR1D2Uzg W/OZN1ShFO8B0p6/8Tt9S6ZyYvudzz7i5eB0/ZPEHYpaWYPo8PU3iMz5FdvUYgsLRWu0 sfLuXKuaTWy53toaIt9NvLDP/IKKBd7KIRjcRDMpJTxsVDi1go8JslVNCKGqVwBaAIgq AVmHnBOLXdxo395/Xov02myHbgdDNm1M6chaU1xbOedP/8mksOMBWsuyU2udZave1n0Y lpx+MfSD2L8lEM9BhC3lWUzbzC0prlBdwlRdGQGXJfpVrzk73PF9y19NcVTerwEn1q2Z rW9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X5h+e6pxPo805o9g/MC2hGfDqhJJdK72fhupi8nxzFc=; b=rD0PVFVNYPp13Kj0J96uKEf6Kxmxe6oxxNpcqLs9nPcFfxX8+HDyIsZdE1Dglm/GBY fKDmLkFCQ/HCxXX/AlK48DHEm4Vu1ilna1iHUwyS72B9n/dDkjWZnF87UV8oEW5YLimI 1w5iAoUiU9+7HuN5FB+UpRDfXcQz0rxY/yiiRfUgRegEepZ94j/hmFLhCK+W4ZSEyds5 FzG0q/aoBsjBjNXrAOfNNboBiXAklV6NuYay1oHnV/RHb1OK90umZAG32khxFhAlDxBq 6knqbXObuHS4FpqP/sLhPDwjszcO4aJljEajxklWCIChInG4B14c0dI9dNOdXgSdWzed TbRg== X-Gm-Message-State: AHPjjUhw9mcXI1Ae+ep42s+nkMiALaDbbNYoHVnSHOMd53D4aYDtKxgU OvkHPCzTqnnKbVXwF/Ti493Sbk77kb7HC/8j/I7Asg== X-Google-Smtp-Source: AOwi7QD5YIAuX+0mTlCMW7kXqsJD7Wple+6qvkqrDh7PGFE7KndsdGRfG1pNxS99PhXnX/J8SnmiClthGcjp/2BAHOA= X-Received: by 10.84.174.197 with SMTP id r63mr20382446plb.235.1507142529836; Wed, 04 Oct 2017 11:42:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.71 with HTTP; Wed, 4 Oct 2017 11:41:49 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Wed, 4 Oct 2017 11:41:49 -0700 Message-ID: To: "Salz, Rich" Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary="94eb2c11aca81dfc57055abcf7aa" Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:42:12 -0000 --94eb2c11aca81dfc57055abcf7aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The current editor's copy of the draft has the following text about the recommended column: The instructions in this document add a recommended column to many of the TLS registries to indicate parameters that are generally recommended for implementations to support. Adding a recommended parameter to a registry or updating a parameter to recommended status requires standards action. Not all parameters defined in standards track documents need to be marked as recommended. If an item is marked as not recommended it does not necessarily mean that it is flawed, rather, it indicates that either the item has not been through the IETF consensus process or the item has limited applicability to specific cases. On Wed, Oct 4, 2017 at 4:58 AM, Salz, Rich wrote: > =E2=9E=A2 We=E2=80=99re recommending that these five suites be dropped f= rom the > recommended list. Please let us know what you think. > > > Does =E2=80=9Crecommended=E2=80=9D mean for general use, in the public In= ternet? Or is it > =E2=80=9CI know it when I see it=E2=80=9D kind of thing? > > Either way, I support un-recommending them > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c11aca81dfc57055abcf7aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current editor's copy of the draft has the followi= ng text about the recommended column:

The instructions in this doc= ument add a recommended column to many of the TLS registries to indicate pa= rameters that are generally recommended for implementations to support. Add= ing a recommended parameter to a registry or updating a parameter to recomm= ended status requires standards action. Not all parameters defined in stand= ards track documents need to be marked as recommended.

If an item is mark= ed as not recommended it does not necessarily mean that it is flawed, rathe= r, it indicates that either the item has not been through the IETF consensu= s process or the item has limited applicability to specific cases.


On = Wed, Oct 4, 2017 at 4:58 AM, Salz, Rich <rsalz@akamai.com> wr= ote:
=E2=9E=A2=C2=A0 We=E2=80=99re recomm= ending that these five suites be dropped from the recommended list.=C2=A0 P= lease let us know what you think.


Does =E2=80=9Crecommended=E2=80=9D mean for general use, in the public Inte= rnet?=C2=A0 Or is it =E2=80=9CI know it when I see it=E2=80=9D kind of thin= g?

Either way, I support un-recommending them

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c11aca81dfc57055abcf7aa-- From nobody Wed Oct 4 12:11:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F17132F65 for ; Wed, 4 Oct 2017 12:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 7CqIjYp5_5z8 for ; Wed, 4 Oct 2017 12:11:52 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0090.outbound.protection.outlook.com [104.47.42.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 574691321C9 for ; Wed, 4 Oct 2017 12:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wtwd3KeXEVlY968QppbvV6vwiRQQ4amuure/k3yv87s=; b=RRCgFUc9QBYersA/UkW8Tuv45zYg6Zi9JW+DrPVTOrjLO4zGsjy7nsoDXhOsZfNeploLBxldBSofYBTKm/LEL2rIX3MIlvc1PEfQs/5Tz2GddyOX3EPLp88sLFxM8RpkV82AACkfm/SqBkW9rIPljnWqUbRuOqBblLCyVLaX0v0= Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) by CY4PR21MB0694.namprd21.prod.outlook.com (10.175.121.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.122.0; Wed, 4 Oct 2017 19:11:09 +0000 Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0098.003; Wed, 4 Oct 2017 19:11:09 +0000 From: Andrei Popov To: Joseph Salowey , "Salz, Rich" CC: "" Thread-Topic: [TLS] Should CCM_8 CSs be Recommended? Thread-Index: AQHTPJqPT+GHjzxlpkeYJKt8a1yd1qLTlvOAgABwt4CAAAdIUA== Date: Wed, 4 Oct 2017 19:11:08 +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: [2001:4898:80e8:8::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0694; 6:WKZWFHvTyIWNOOvqwRqv6NoqJlP38OYO+uITEEKz4HNMNmuas1ZC3k2I2ZkbbSiIfI/h7lhiIZdJklOyBv4oh1GsgvSfKA1coKDreX7UQb62XBJoRD1XzQQjwpBiGbenCqfOnILvJCxoRt5aoNrhJZy1LxWyCMWDF/JF7xjpgh8Lygj2Y8fan2C/3IZ555HXh/6mM06QvLPa6RJROV09PsGgZEDJFoY3VNNjtEi6OIlGwnLj9J/59XviU3Vmm+Nw6irpl5yx8IADVuflWdXi0SY/FajQHiMRrH6wpM7wbCIFXqCms2z1eYdOsvzz7dyUJok5s/LVmpcgWzh8nyVSAQ==; 5:84cmN7jc6kuXp7HPBikIQn65tQYZcTabr8ZfzSM+b7D+/g5B/nPeavPxE0q/vM8n2iq5DdwOLhOVxchSxonifYeS3TODHc5NvQVWMPTIzptciZbbCEQQVDjotLPL/loxll1LeR1e8fsT2tnCdE1SQw==; 24:v9x5r3S57ExAD2CnnxToXyUEOt4Dpw+K0JwG1n2AaQ+hW5rxO5oZLvP2HQ1kQXzVWBRVguF3pZJDWkbpq6hclH2J1AmeSqYpvg02Av8u9ow=; 7:SVlsud1g0FKjLnaCaaqV0NxyA2fjhrpCvKAEXT8lX+bHfcPjK9B8FdbaXiKSbS+C8jiDEnX8sMo+mZgEaEB76i7BjxBDySk0DsGYCI0gfw/vzPZvrmn2ADkNOjPkXgSA8vB/s7hRLlU4SCa1ZIxrr/j+64DfiqQY1AyXK9IIyxb4PYezqqHEXAvHj9WIIVxuQaPuBUCAIVgtMzgk9Q1MFxHqhp96h+Xi8IlP2RrrLQ4= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d2ac9a11-fda3-49f6-2ad1-08d50b5bab8d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0694; x-ms-traffictypediagnostic: CY4PR21MB0694: x-exchange-antispam-report-test: UriScan:(189930954265078)(100405760836317)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(12181511122)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0694; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0694; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(47760400005)(199003)(377454003)(24454002)(189002)(76104003)(7736002)(97736004)(2950100002)(76176999)(50986999)(54356999)(7696004)(19609705001)(106356001)(3280700002)(10290500003)(3660700001)(8936002)(53936002)(6306002)(54896002)(4326008)(966005)(33656002)(606006)(9686003)(2900100001)(105586002)(5660300001)(8676002)(55016002)(102836003)(74316002)(86362001)(72206003)(236005)(316002)(189998001)(229853002)(22452003)(14454004)(77096006)(99286003)(478600001)(6116002)(53546010)(10090500001)(6436002)(2906002)(68736007)(81166006)(25786009)(110136005)(790700001)(8990500004)(81156014)(6506006)(101416001)(6246003)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0694; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0120E62327D33AD536BDD72E8C730CY4PR21MB0120namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: d2ac9a11-fda3-49f6-2ad1-08d50b5bab8d X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2017 19:11:08.9003 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0694 Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 19:11:55 -0000 --_000_CY4PR21MB0120E62327D33AD536BDD72E8C730CY4PR21MB0120namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdGhhdCBDQ01fOCBmYWxscyBpbiB0aGUg4oCcbGltaXRlZCBhcHBsaWNhYmlsaXR5 4oCdIGJ1Y2tldC4gSG93ZXZlciwgdGhlcmXigJlzIG5vdGhpbmcgd3Jvbmcgd2l0aCBJb1Qgc3Bl Y3MgcmVxdWlyaW5nIHRoZXNlIGNpcGhlcnMgaW4gdGhlaXIgVExTIHByb2ZpbGVzLg0KDQpDaGVl cnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpvc2VwaCBTYWxvd2V5DQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgNCwg MjAxNyAxMTo0MiBBTQ0KVG86IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb20+DQpDYzogPHRs c0BpZXRmLm9yZz4gPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBTaG91bGQgQ0NN XzggQ1NzIGJlIFJlY29tbWVuZGVkPw0KDQpUaGUgY3VycmVudCBlZGl0b3IncyBjb3B5IG9mIHRo ZSBkcmFmdCBoYXMgdGhlIGZvbGxvd2luZyB0ZXh0IGFib3V0IHRoZSByZWNvbW1lbmRlZCBjb2x1 bW46DQoNCg0KVGhlIGluc3RydWN0aW9ucyBpbiB0aGlzIGRvY3VtZW50IGFkZCBhIHJlY29tbWVu ZGVkIGNvbHVtbiB0byBtYW55IG9mIHRoZSBUTFMgcmVnaXN0cmllcyB0byBpbmRpY2F0ZSBwYXJh bWV0ZXJzIHRoYXQgYXJlIGdlbmVyYWxseSByZWNvbW1lbmRlZCBmb3IgaW1wbGVtZW50YXRpb25z IHRvIHN1cHBvcnQuIEFkZGluZyBhIHJlY29tbWVuZGVkIHBhcmFtZXRlciB0byBhIHJlZ2lzdHJ5 IG9yIHVwZGF0aW5nIGEgcGFyYW1ldGVyIHRvIHJlY29tbWVuZGVkIHN0YXR1cyByZXF1aXJlcyBz dGFuZGFyZHMgYWN0aW9uLiBOb3QgYWxsIHBhcmFtZXRlcnMgZGVmaW5lZCBpbiBzdGFuZGFyZHMg dHJhY2sgZG9jdW1lbnRzIG5lZWQgdG8gYmUgbWFya2VkIGFzIHJlY29tbWVuZGVkLg0KDQpJZiBh biBpdGVtIGlzIG1hcmtlZCBhcyBub3QgcmVjb21tZW5kZWQgaXQgZG9lcyBub3QgbmVjZXNzYXJp bHkgbWVhbiB0aGF0IGl0IGlzIGZsYXdlZCwgcmF0aGVyLCBpdCBpbmRpY2F0ZXMgdGhhdCBlaXRo ZXIgdGhlIGl0ZW0gaGFzIG5vdCBiZWVuIHRocm91Z2ggdGhlIElFVEYgY29uc2Vuc3VzIHByb2Nl c3Mgb3IgdGhlIGl0ZW0gaGFzIGxpbWl0ZWQgYXBwbGljYWJpbGl0eSB0byBzcGVjaWZpYyBjYXNl cy4NCg0KT24gV2VkLCBPY3QgNCwgMjAxNyBhdCA0OjU4IEFNLCBTYWx6LCBSaWNoIDxyc2FsekBh a2FtYWkuY29tPG1haWx0bzpyc2FsekBha2FtYWkuY29tPj4gd3JvdGU6DQrinqIgIFdl4oCZcmUg cmVjb21tZW5kaW5nIHRoYXQgdGhlc2UgZml2ZSBzdWl0ZXMgYmUgZHJvcHBlZCBmcm9tIHRoZSBy ZWNvbW1lbmRlZCBsaXN0LiAgUGxlYXNlIGxldCB1cyBrbm93IHdoYXQgeW91IHRoaW5rLg0KDQoN CkRvZXMg4oCccmVjb21tZW5kZWTigJ0gbWVhbiBmb3IgZ2VuZXJhbCB1c2UsIGluIHRoZSBwdWJs aWMgSW50ZXJuZXQ/ICBPciBpcyBpdCDigJxJIGtub3cgaXQgd2hlbiBJIHNlZSBpdOKAnSBraW5k IG9mIHRoaW5nPw0KDQpFaXRoZXIgd2F5LCBJIHN1cHBvcnQgdW4tcmVjb21tZW5kaW5nIHRoZW0N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBt YWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZ0bHMmZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWlj cm9zb2Z0LmNvbSU3Q2Q0NWQ1OWVjZDAwYTQyZWQ1ZDhjMDhkNTBiNTdhNGNlJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjQyNzM5MzQxMTcwMDUwNSZzZGF0 YT1oSFFGRk9WeFl4cHowdWliaDFFUWpoek9aVmxoSUU1blc4Y1g1VXZkM0JvJTNEJnJlc2VydmVk PTA+DQoNCg== --_000_CY4PR21MB0120E62327D33AD536BDD72E8C730CY4PR21MB0120namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5v c2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNlZW1zIHRoYXQgQ0NNXzggZmFsbHMgaW4gdGhlIOKA nGxpbWl0ZWQgYXBwbGljYWJpbGl0eeKAnSBidWNrZXQuIEhvd2V2ZXIsIHRoZXJl4oCZcyBub3Ro aW5nIHdyb25nIHdpdGggSW9UIHNwZWNzIHJlcXVpcmluZyB0aGVzZSBjaXBoZXJzIGluIHRoZWly IFRMUyBwcm9maWxlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbmRyZWk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5K b3NlcGggU2Fsb3dleTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgNCwgMjAx NyAxMTo0MiBBTTxicj4NCjxiPlRvOjwvYj4gU2FseiwgUmljaCAmbHQ7cnNhbHpAYWthbWFpLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBTaG91bGQgQ0NNXzggQ1NzIGJl IFJlY29tbWVuZGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGN1cnJlbnQg ZWRpdG9yJ3MgY29weSBvZiB0aGUgZHJhZnQgaGFzIHRoZSBmb2xsb3dpbmcgdGV4dCBhYm91dCB0 aGUgcmVjb21tZW5kZWQgY29sdW1uOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEy LjBwdDttYXJnaW4tbGVmdDowaW47Ym94LXNpemluZzpib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMyNDI5MkUiPlRoZSBpbnN0cnVjdGlvbnMgaW4gdGhpcyBkb2N1bWVudCBhZGQgYSByZWNv bW1lbmRlZCBjb2x1bW4gdG8gbWFueSBvZiB0aGUgVExTIHJlZ2lzdHJpZXMgdG8gaW5kaWNhdGUg cGFyYW1ldGVycyB0aGF0IGFyZSBnZW5lcmFsbHkgcmVjb21tZW5kZWQgZm9yIGltcGxlbWVudGF0 aW9ucyB0byBzdXBwb3J0LiBBZGRpbmcgYSByZWNvbW1lbmRlZA0KIHBhcmFtZXRlciB0byBhIHJl Z2lzdHJ5IG9yIHVwZGF0aW5nIGEgcGFyYW1ldGVyIHRvIHJlY29tbWVuZGVkIHN0YXR1cyByZXF1 aXJlcyBzdGFuZGFyZHMgYWN0aW9uLiBOb3QgYWxsIHBhcmFtZXRlcnMgZGVmaW5lZCBpbiBzdGFu ZGFyZHMgdHJhY2sgZG9jdW1lbnRzIG5lZWQgdG8gYmUgbWFya2VkIGFzIHJlY29tbWVuZGVkLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMjQyOTJFIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbjtib3gtc2l6aW5n OmJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzI0MjkyRSI+SWYgYW4gaXRlbSBpcyBtYXJr ZWQgYXMgbm90IHJlY29tbWVuZGVkIGl0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCBp dCBpcyBmbGF3ZWQsIHJhdGhlciwgaXQgaW5kaWNhdGVzIHRoYXQgZWl0aGVyIHRoZSBpdGVtIGhh cyBub3QgYmVlbiB0aHJvdWdoIHRoZSBJRVRGIGNvbnNlbnN1cyBwcm9jZXNzIG9yIHRoZSBpdGVt DQogaGFzIGxpbWl0ZWQgYXBwbGljYWJpbGl0eSB0byBzcGVjaWZpYyBjYXNlcy48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzI0MjkyRSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE9j dCA0LCAyMDE3IGF0IDQ6NTggQU0sIFNhbHosIFJpY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyc2Fs ekBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+cnNhbHpAYWthbWFpLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssc2Fucy1z ZXJpZiI+4p6iPC9zcGFuPiZuYnNwOyBXZeKAmXJlIHJlY29tbWVuZGluZyB0aGF0IHRoZXNlIGZp dmUgc3VpdGVzIGJlIGRyb3BwZWQgZnJvbSB0aGUgcmVjb21tZW5kZWQgbGlzdC4mbmJzcDsgUGxl YXNlIGxldCB1cyBrbm93IHdoYXQgeW91IHRoaW5rLjxicj4NCjxicj4NCjxicj4NCkRvZXMg4oCc cmVjb21tZW5kZWTigJ0gbWVhbiBmb3IgZ2VuZXJhbCB1c2UsIGluIHRoZSBwdWJsaWMgSW50ZXJu ZXQ/Jm5ic3A7IE9yIGlzIGl0IOKAnEkga25vdyBpdCB3aGVuIEkgc2VlIGl04oCdIGtpbmQgb2Yg dGhpbmc/PGJyPg0KPGJyPg0KRWl0aGVyIHdheSwgSSBzdXBwb3J0IHVuLXJlY29tbWVuZGluZyB0 aGVtPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K VExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0Bp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnRscyZhbXA7ZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9z b2Z0LmNvbSU3Q2Q0NWQ1OWVjZDAwYTQyZWQ1ZDhjMDhkNTBiNTdhNGNlJTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjQyNzM5MzQxMTcwMDUwNSZhbXA7c2Rh dGE9aEhRRkZPVnhZeHB6MHVpYmgxRVFqaHpPWlZsaElFNW5XOGNYNVV2ZDNCbyUzRCZhbXA7cmVz ZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB0120E62327D33AD536BDD72E8C730CY4PR21MB0120namp_-- From nobody Wed Oct 4 12:37:34 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593E2132026 for ; Wed, 4 Oct 2017 12:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 e99bVPkk4e6M for ; Wed, 4 Oct 2017 12:37:32 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FF61270AB for ; Wed, 4 Oct 2017 12:37:32 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v94JaWVt005867; Wed, 4 Oct 2017 20:37:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=hgYNWxjAAIqZ3Yr/ekCp3/VLoV+s6lWxtt2tMPGn3c0=; b=ap5WZD6KYLu6G22tzIQn14lDP7AYanpEzSTg36W6iPVO83+Nvp8lvzzg8HrQRfdfcU5K Be5JXOWNeiRXfYJH57urrO3mvkFjj7rJ63pkxcriC8+9gAQaqP2BP8SLu02wNaRIdroD D94yJotiJjNAY7eRjWFwq79lv507P9fS0pILskrEzxNGeu9YqUp58NYCh3wDg4XzHfuJ lWNBtzFlPLnUrVr0Zzu2170md80AlSjANexQzk+2EfYtd/W13x8DYZcF8eR2P1OKgXjc 4xSpYAo1txExURzm34maspJn5MKpvPwIZ1R94P5ZL/H5zXzwR1/NK4yMT62AJdaRSQih Zw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2dc77hhkf5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Oct 2017 20:37:30 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v94JZpop002718; Wed, 4 Oct 2017 15:37:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dcksnam83-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Oct 2017 15:37:29 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Oct 2017 14:37:07 -0500 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.1263.000; Wed, 4 Oct 2017 14:37:07 -0500 From: "Salz, Rich" To: Joseph Salowey CC: "tls@ietf.org" Thread-Topic: [TLS] Should CCM_8 CSs be Recommended? Thread-Index: AQHTPJqL5DOxVoyYS0CQv5KHiX0PRaLT6sSAgABwuICAAA9yAA== Date: Wed, 4 Oct 2017 19:37:07 +0000 Message-ID: <1B6398D7-695F-492D-889F-2E006C596F33@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/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.111] Content-Type: multipart/alternative; boundary="_000_1B6398D7695F492D889F2E006C596F33akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710040272 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710040272 Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 19:37:33 -0000 --_000_1B6398D7695F492D889F2E006C596F33akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSWYgYW4gaXRlbSBpcyBtYXJrZWQgYXMgbm90IHJlY29tbWVuZGVkIGl0IGRvZXMgbm90 IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCBpdCBpcyBmbGF3ZWQsIHJhdGhlciwgaXQgaW5kaWNhdGVz IHRoYXQgZWl0aGVyIHRoZSBpdGVtIGhhcyBub3QgYmVlbiB0aHJvdWdoIHRoZSBJRVRGIGNvbnNl bnN1cyBwcm9jZXNzIG9yIHRoZSBpdGVtIGhhcyBsaW1pdGVkIGFwcGxpY2FiaWxpdHkgdG8gc3Bl Y2lmaWMgY2FzZXMuDQpQZXJoYXBzIGNoYW5nZSB0aGUgbGlzdCDigJx0b+KAnSB0byDigJxpbnRl bmRlZCBmb3LigJ0gPw0K --_000_1B6398D7695F492D889F2E006C596F33akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2DF09064685EB845A755C80B1D514186@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Om1vbm9zcGFjZTsNCglwYW5vc2UtMTow IDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDoxMzE5MTk0NDU0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMzYxMDUwNDc2IDEyOTg0MzQzNzQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNl cmlmO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBzdHlsZT0iY29sb3I6IzI0MjkyRTttYXJnaW4t dG9wOjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7bW9ub3NwYWNlJnF1b3Q7LHNlcmlmIj5JZiBhbiBpdGVtIGlzIG1hcmtlZCBhcyBub3Qg cmVjb21tZW5kZWQgaXQgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbiB0aGF0IGl0IGlzIGZsYXdl ZCwgcmF0aGVyLCBpdCBpbmRpY2F0ZXMgdGhhdCBlaXRoZXIgdGhlIGl0ZW0gaGFzIG5vdCBiZWVu IHRocm91Z2ggdGhlIElFVEYgY29uc2Vuc3VzIHByb2Nlc3Mgb3IgdGhlIGl0ZW0gaGFzIGxpbWl0 ZWQNCiBhcHBsaWNhYmlsaXR5IHRvIHNwZWNpZmljIGNhc2VzLjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhhcHMgY2hhbmdlIHRoZSBsaXN0IOKAnHRv4oCdIHRvIOKA nGludGVuZGVkIGZvcuKAnSA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_1B6398D7695F492D889F2E006C596F33akamaicom_-- From nobody Wed Oct 4 18:10:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B055C1344F8 for ; Wed, 4 Oct 2017 18:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsu-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dezb4OiKlQPE for ; Wed, 4 Oct 2017 18:10:49 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 C3C8B1344F7 for ; Wed, 4 Oct 2017 18:10:48 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id a43so16761520qta.0 for ; Wed, 04 Oct 2017 18:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=UHqvjDlQcdGlqskor5zDdUWGTM37Qdn4uU+gFsuE81U=; b=RAB+bgcGccDFxt3NXJtxPl9gB81Lk/547rh7S0whqampuR837ZbCiSntXBGGMPfks/ n5DJ/SAu3JfRKZ25YzB45dSeTkUu5zriXLQ5jjBKC2WTSr6NV635/omipQKxcsh+Lsyd 92txHuJmoB5tc+IROiK4uHeTCWY2OhVJDdWeq4eLY8ioquqGIcZ5vX2cl3d5HB/adMol SflDp3z0SKnQqoYeYRzfBEFoZ+j6SkBVcC8Jh+tNqQbzqwW2UenvyhJzgHYWz9AOHl+N pI4jYQFOm5YXqozjBZmh4eGvrhVXZedHomvbxrzbCquFqz0tDRJjtYl33wU9ZpEinwmM 8gqA== 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=UHqvjDlQcdGlqskor5zDdUWGTM37Qdn4uU+gFsuE81U=; b=JTuraGp8zCmF8gX4NiWo6BQAKE6k5BNJKY0gXZRgYyrzOawm0s8ufWe9+2xOi8f3JT LHYJif8VRRjoTB/CeO0l1H1snCOma1iD40Yb/EQfvKtxODqn+RRLjFRCin8ag9cZr/qU Lwt8hKifPdVapSF1SgiVuGmr1jx/kzL3nAPA45CApQejKhRMzd8c6bYhGj9c9rrx0N00 WLyFbTsQ2Tk+h9XCGjudA9EBh3l0i0i9FMfPvjvaZw2vUfwEvTBEveSqxs7/BvtqtgjZ +k1ehjtDHMTfE/fzaFLam6uzVolH2pallztaC26FeJ6BaZKB1zwSkJz4zf5oR5tSpNTR McyA== X-Gm-Message-State: AMCzsaUSn/I81Qb1q7thT68o8snjHucyBzNP7IOnx6VK1kXt97kHnGWg MGE52GN/MdWc2U/Rw2EZfk1mCGNA7rk1q/ms2mhOu5vI X-Google-Smtp-Source: AOwi7QDsmJekU75hztRXOqRY5eLQM8fCNfvaX1LnpgusZXs57URiVbCuOKuFJ+axjEKgA34HJniSwFx58LX2ecdLoc4= X-Received: by 10.37.182.17 with SMTP id r17mr5454177ybj.261.1507165847668; Wed, 04 Oct 2017 18:10:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.211.20 with HTTP; Wed, 4 Oct 2017 18:10:47 -0700 (PDT) From: Neetish Pathak Date: Wed, 4 Oct 2017 21:10:47 -0400 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="f403045e8a44f7fdfe055ac26479" Archived-At: Subject: [TLS] TLS 1.3 research papers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 01:10:50 -0000 --f403045e8a44f7fdfe055ac26479 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could you please suggest few research papers (apart from TLS 1.3 draft) on TLS 1.3 that may be helpful to understand TLS 1.3 implementation and performance. Is there any research available on TLS 1.3 performance benchmarking? Some papers which I am referring right now are: 1. A Cryptographic Analysis of the TLS 1.3 Handshake Protocol Candidates 2) Automated Analysis and Verification of TLS 1.3: 0-RTT, Resumption and Delayed Authentication Any suggestions will be appreciated Thanks BR, Neetish --f403045e8a44f7fdfe055ac26479 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Could you please suggest f= ew research papers (apart=C2=A0from TLS 1.3 draft) on TLS 1.3 that may be h= elpful to understand TLS 1.3 implementation and performance. Is there any r= esearch=C2=A0available on TLS 1.3 performance benchmarking?

Some papers= which I am referring right now are:

Any suggestions will be appreciated

Thanks<= /span>
BR,
Neetish
--f403045e8a44f7fdfe055ac26479-- From nobody Thu Oct 5 01:54:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0391331F5 for ; Thu, 5 Oct 2017 01:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQkxvsS7XoEf for ; Thu, 5 Oct 2017 01:54:16 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 ABAAA12ECEC for ; Thu, 5 Oct 2017 01:54:15 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id p10so8531255wrc.6 for ; Thu, 05 Oct 2017 01:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=isjZX55oYxT4q4js+A1fVb/r9s5VVRiuAeYpRpTLGtI=; b=jGttYrjXQuP7fj5Mhz9AGD9ELYo6acpfJuafKU9Z0eq+AiuqQpz/5816tvsHmdxLn9 euKYYuj0r7zAQZtzXxAfju3pO3DTYlkW0pmnIzD9jOEhNDw2nQGE2BFJzykQf3wZjChr ffxz+vckwy/bz8QSfICatrCN8hDuGW10ndAngP3G/iMumY+zXNiVA+GTkhqPM8qCbFVB 7Vhd+fzeTBg9YF172NB6OLt3TvvezOWaxoxJIq452yqPyXyd+94U6nGjQ0ztWfTrQvVM 4MCXLtS3sNhgfJNay/0W6wID2umLHpx45jlcO8/soVG7M92BXyMdIqrJZRsr+9jO6wVo XEqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=isjZX55oYxT4q4js+A1fVb/r9s5VVRiuAeYpRpTLGtI=; b=tluzK3Wmp9wsuckOpvN1jaLYG/UzMxwOzyQl4VRev4fFXX/bWCpwVZvNCFhqL4v1TI btUG89mVFfkD5aDEhz4C1j8dkJ400Wogb/d0AcLUukPEcJm7yWa61gwfIczVKETjD3on BIlU73xZUKsAp4OoxB2BQVq3JOX9jmGzhkkY36Pp+Sgh9SgmgBr/5FyR3RqoCuR3pdW0 aMSz2ANKqnLAzjUCb9HsaIRGaqzXb1Xuub0oOEJ15MiNw/DT3d8hSuqq2fF2sVLJMcB5 OGaknVosP4cbwp+vRZTVzVMM1/es+ih0n0depMGXb0Rb1r8eKcbCE2V9xFktT80ivfzt gSOQ== X-Gm-Message-State: AHPjjUivH4A6oL95ITTHFC5RbEtuLdAGXnw3ov05iys/Uq5sk4GUJPzq MJmtltOVOq1e42wh8kdctYxWQqki X-Google-Smtp-Source: AOwi7QD8fJtCJiuX3/bEOzNQz1hhxlUCsCD35vTq809ZSTe/P2qdNxZSdbSwDhutanPeNMe8I3P+/Q== X-Received: by 10.223.132.163 with SMTP id 32mr21635110wrg.267.1507193654065; Thu, 05 Oct 2017 01:54:14 -0700 (PDT) Received: from [192.168.0.23] (81-67-195-114.rev.numericable.fr. [81.67.195.114]) by smtp.gmail.com with ESMTPSA id z10sm34094043wre.6.2017.10.05.01.54.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 01:54:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Arnaud Taddei In-Reply-To: <2f8c1e4e-5997-de8a-c10e-c409dff3fc13@cs.tcd.ie> Date: Thu, 5 Oct 2017 10:54:12 +0200 Cc: Russ Housley , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> <2f8c1e4e-5997-de8a-c10e-c409dff3fc13@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 08:54:18 -0000 Being new to this community, can I actually ask for the analysis of the = =E2=80=98hundred=E2=80=99s of applications=E2=80=99 which lead to the = evolution of TLS 1.3 the way it is today? Was it captured somewhere or = shall I reconstruct this history from all the discussions in the mailing = lists? Thank you in advance > Le 3 oct. 2017 =C3=A0 00:48, Stephen Farrell = a =C3=A9crit : >=20 >=20 > Russ, >=20 > On 02/10/17 22:43, Russ Housley wrote: >>> For starters, though, I'd be interested answers from the authors to >>> two quick questions, though I suspect I can guess 'em: >>>=20 >>> 1. TLS1.3 has had significant formal analysis. Did the authors or >>> other proponents here do any such work and if so can you send a >>> pointer to your results? If not, then I believe the onus is on the >>> folks who want to break TLS to do that work themselves if they want >>> to make a serious proposal and it is not ok IMO to try put that >>> work onto the community who have been working hard for years to >>> make TLS stronger. >>=20 >> I would be willing to work with the people that did the formal >> analysis to show the impact of including the extension, and making >> changes to the extension that are indicated by that analysis. >>=20 >=20 > IMO, that's not a good answer. When improving the security > properties of the protocol it may suffice. When weakening > the protocol, I strongly believe the onus is on you to have > done that work ahead of time, so that the damage you are > proposing the Internet suffers is clear and known and not > discovered years later. >=20 >>> 2. Which of the hundreds of applications making use of TLS did you >>> analyse before proposing this? If only a handful, then same comment >>> wrt where the onus ought lie. >>=20 >> Just like TLS 1.3 has been implemented and tested with many >> applications during its development, I would expect the same to >> happen in those environments where there is interest in making use of >> this extension. >=20 > The TLS WG has spent an awful lot of effort on (I think) > every single semantic difference between TLS1.2 and TLS1.3. > (Ortt for example.) You are now asking that everyone else > do work to figure out how your proposal damages their uses > of TLS so that this supposed use case is dealt with. I think > you and other proponents of breaking TLS need to spend that > effort yourselves. (This is because as you know there is no > way to limit the damage of your proposal to only the use-cases > that are the claimed targets for this bad idea.) >=20 > So yes, those answers are as I expected and are just as > unsurprisingly, utterly unsatisfactory. >=20 > S. >=20 >>=20 >> Russ >>=20 >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 5 02:12:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285FE1332F2 for ; Thu, 5 Oct 2017 02:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 MKW7QKtuCkJm for ; Thu, 5 Oct 2017 02:12:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E6D134557 for ; Thu, 5 Oct 2017 02:12:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A01A1BDD8; Thu, 5 Oct 2017 10:12:15 +0100 (IST) 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 TvxwGJDWYwnW; Thu, 5 Oct 2017 10:12:15 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5ADB4BDCC; Thu, 5 Oct 2017 10:12:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507194735; bh=/+m2N5I5MMOfQuuC4kamNFRxBtzqBgxPvi8RMUVBT+w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BTAK9hhogpOB2yHSt+/xHH4DzyUKyhXvFEp6rxSatoGSIYTD6WXrOHjCxyKFWbLVi Dl6O2QGSvN+gUOIUgB+wj/6tROPhghe+gDhUJqeuVzd5Qc51F5XR611uFTV0W10ogX l+8NePLlqo4lfBvJZYjv+RASgL3sVQmXPAO49xAg= To: Arnaud Taddei Cc: Russ Housley , IETF TLS References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> <2f8c1e4e-5997-de8a-c10e-c409dff3fc13@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 5 Oct 2017 10:12:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9DOK8IvOW2aHvLgoX5U7ncRdhwrKjwBEo" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 09:12:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9DOK8IvOW2aHvLgoX5U7ncRdhwrKjwBEo Content-Type: multipart/mixed; boundary="Lv8UiwsUrrbPPGpuGrGwxef2roVk4vRNr"; protected-headers="v1" From: Stephen Farrell To: Arnaud Taddei Cc: Russ Housley , IETF TLS Message-ID: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> <2f8c1e4e-5997-de8a-c10e-c409dff3fc13@cs.tcd.ie> In-Reply-To: --Lv8UiwsUrrbPPGpuGrGwxef2roVk4vRNr Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 05/10/17 09:54, Arnaud Taddei wrote: > Being new to this community, can I actually ask for the analysis of > the =E2=80=98hundred=E2=80=99s of applications=E2=80=99 which lead to t= he evolution of TLS > 1.3 the way it is today? Was it captured somewhere or shall I > reconstruct this history from all the discussions in the mailing > lists? It's more the latter. But, and it's a big but, tls1.3 is almost entirely (0rtt aside) aiming to provide the same services as earlier versions, just to do it better, so the need for that kind of broad survey of uses of tls is far less. WRT 0rtt, people did, and are doing, a bunch of work to figure out when it's (un)safe to use that. When it comes to breaking tls (as in this proposal), since that'd change the security model (from an essentially two party security protocol to an N-party model), a lot more work would need to be done, and has never been done, by any of the people proposing to break tls, at least afaik. S. >=20 > Thank you in advance >=20 >> Le 3 oct. 2017 =C3=A0 00:48, Stephen Farrell >> a =C3=A9crit : >>=20 >>=20 >> Russ, >>=20 >> On 02/10/17 22:43, Russ Housley wrote: >>>> For starters, though, I'd be interested answers from the >>>> authors to two quick questions, though I suspect I can guess >>>> 'em: >>>>=20 >>>> 1. TLS1.3 has had significant formal analysis. Did the authors >>>> or other proponents here do any such work and if so can you >>>> send a pointer to your results? If not, then I believe the onus >>>> is on the folks who want to break TLS to do that work >>>> themselves if they want to make a serious proposal and it is >>>> not ok IMO to try put that work onto the community who have >>>> been working hard for years to make TLS stronger. >>>=20 >>> I would be willing to work with the people that did the formal=20 >>> analysis to show the impact of including the extension, and >>> making changes to the extension that are indicated by that >>> analysis. >>>=20 >>=20 >> IMO, that's not a good answer. When improving the security=20 >> properties of the protocol it may suffice. When weakening the >> protocol, I strongly believe the onus is on you to have done that >> work ahead of time, so that the damage you are proposing the >> Internet suffers is clear and known and not discovered years >> later. >>=20 >>>> 2. Which of the hundreds of applications making use of TLS did >>>> you analyse before proposing this? If only a handful, then same >>>> comment wrt where the onus ought lie. >>>=20 >>> Just like TLS 1.3 has been implemented and tested with many=20 >>> applications during its development, I would expect the same to=20 >>> happen in those environments where there is interest in making >>> use of this extension. >>=20 >> The TLS WG has spent an awful lot of effort on (I think) every >> single semantic difference between TLS1.2 and TLS1.3. (Ortt for >> example.) You are now asking that everyone else do work to figure >> out how your proposal damages their uses of TLS so that this >> supposed use case is dealt with. I think you and other proponents >> of breaking TLS need to spend that effort yourselves. (This is >> because as you know there is no way to limit the damage of your >> proposal to only the use-cases that are the claimed targets for >> this bad idea.) >>=20 >> So yes, those answers are as I expected and are just as=20 >> unsurprisingly, utterly unsatisfactory. >>=20 >> S. >>=20 >>>=20 >>> Russ >>>=20 >>>=20 >>=20 >> _______________________________________________ TLS mailing list=20 >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 >=20 --Lv8UiwsUrrbPPGpuGrGwxef2roVk4vRNr-- --9DOK8IvOW2aHvLgoX5U7ncRdhwrKjwBEo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ1fdkAAoJEC88hzaAX42iiKUIAI88nGZDGJok6Ou9fQiwt1Y1 ePg1PvNGR4GwCOqzz17YX/FYgHvdvBPYmkkWFKCVwQPjgRnT/8oSgM2p3KMytEJy CJV0HO4usvEtq/MW+9vfsWdjsNzY5z+cwXMjtFrTk3RTsTW3OmafVAIRl7KURIc2 B5oKfiM9JKEEt//TxOrxeK7vKMEWh5wPYOql5C2reIuqY0vdoBTG6ULzxs5FYV0f QPhxArVYpM31GOMC7p5feXcdby3dSiVlv0wuWv0EMLY3EHLbNrxRlnYmj3ljCeHp XMKpRVvkoL1Kc0puCUBUw8R9EUbsdgfo8tKLaQsUbNQ5jNz2jpIeXHJV5m3UWO8= =NwCF -----END PGP SIGNATURE----- --9DOK8IvOW2aHvLgoX5U7ncRdhwrKjwBEo-- From nobody Thu Oct 5 02:14:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEEE13292A for ; Thu, 5 Oct 2017 02:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cnmOo8P2Qdk for ; Thu, 5 Oct 2017 02:14:28 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D3212ECEC for ; Thu, 5 Oct 2017 02:14:27 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id i124so805982wmf.3 for ; Thu, 05 Oct 2017 02:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N67+A+qcpFxCbbu3qOl6+YWFfUKao28YopVeEmlJW5U=; b=ebYkCR4u+oSvdJS75JxgwLgD4dxG74O4D98ALLH6Ky09ZRbvFXC22nAXoPYYHPzgPN k7ny4xANQ/GH99Xk/LKcnVYIaIThDwDr4oGEcZRQGc2PR+geCOS9DeNYqypGxnHQD7cS 6wbye/NlTXEP9tyCka3w/rESpG8anzyHHlR20M4jpHenFwnCZAbYNf+GNOGW/eAW3Y9k CUWR8ZbVVqoUdRiaIx6QeCvzHIZqbiAqugsGxwPK6eeURK5vDWQy21nxGdBnhJXvcYJL 3iN1F8Jn/TixLgsSrd/Lm7wInjXC+SvuIE9gAb//1/G0QA3pdQDbwTDBFFEr4zUpZK/q 0w2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N67+A+qcpFxCbbu3qOl6+YWFfUKao28YopVeEmlJW5U=; b=n3+zUWDXnqRA1SCrU9Ksty/8p1y9bd0/6gOUIUE9nhYw66MMYPr6xVwVn0BDK4f7uc zfDHFlMAXINL9cZYU0q79OkIpVOfhYNQb8YkyVJA+VFsqEk9Yesg5A/a9w8j0HQcWeKW /jvp6HnHxMC7fK0Ye1+6vPbiGbBTwDbNdVvBqNQvVOWqCejuOGYd+ywRhdJJ3EMW2W/L 8swE7xueXgUi2SM6O37q25kk8PBQGkDE1vsow5DOJ3EB4XSF1cok0A+lhhpWH1lNvbJL LQdegaLiL/PpwAsd7p5lDrrQYk1a246KLNmjDZk5zAXScUcEaWDRatQChGd1DwL7pRL5 GoPw== X-Gm-Message-State: AMCzsaXrU8chvyXRhHqqjSNwRz8truVdqBL1w+lXyDttKLTJEJLK4E5j 4F0DHJewygJ8ZcKIzCrPXM8= X-Google-Smtp-Source: AOwi7QBBdD+3WtTiNi05YZy4wJJ452ullTLVQ21L4lPVR92150wrQYkvzvInwuuZPuh+gso5yOLIgg== X-Received: by 10.28.199.139 with SMTP id x133mr5358554wmf.145.1507194866092; Thu, 05 Oct 2017 02:14:26 -0700 (PDT) Received: from [192.168.0.23] (81-67-195-114.rev.numericable.fr. [81.67.195.114]) by smtp.gmail.com with ESMTPSA id n191sm248445wmd.7.2017.10.05.02.14.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 02:14:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Arnaud Taddei In-Reply-To: Date: Thu, 5 Oct 2017 11:14:25 +0200 Cc: Russ Housley , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <90C8C6CB-3F08-4966-A6BB-656167D9C863@gmail.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> <2f8c1e4e-5997-de8a-c10e-c409dff3fc13@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 09:14:30 -0000 I see, thank you, it seems that there is a lot of archeological work to = be done.=20 Ok at least I can organize my work as perhaps a good first step home = work before being in a position to comment further > Le 5 oct. 2017 =C3=A0 11:12, Stephen Farrell = a =C3=A9crit : >=20 >=20 >=20 > On 05/10/17 09:54, Arnaud Taddei wrote: >> Being new to this community, can I actually ask for the analysis of >> the =E2=80=98hundred=E2=80=99s of applications=E2=80=99 which lead to = the evolution of TLS >> 1.3 the way it is today? Was it captured somewhere or shall I >> reconstruct this history from all the discussions in the mailing >> lists? >=20 > It's more the latter. But, and it's a big but, tls1.3 > is almost entirely (0rtt aside) aiming to provide the > same services as earlier versions, just to do it better, > so the need for that kind of broad survey of uses of > tls is far less. WRT 0rtt, people did, and are doing, > a bunch of work to figure out when it's (un)safe to > use that. >=20 > When it comes to breaking tls (as in this proposal), > since that'd change the security model (from an > essentially two party security protocol to an N-party > model), a lot more work would need to be done, and > has never been done, by any of the people proposing > to break tls, at least afaik. >=20 > S. >=20 >=20 >>=20 >> Thank you in advance >>=20 >>> Le 3 oct. 2017 =C3=A0 00:48, Stephen Farrell = >>> a =C3=A9crit : >>>=20 >>>=20 >>> Russ, >>>=20 >>> On 02/10/17 22:43, Russ Housley wrote: >>>>> For starters, though, I'd be interested answers from the >>>>> authors to two quick questions, though I suspect I can guess >>>>> 'em: >>>>>=20 >>>>> 1. TLS1.3 has had significant formal analysis. Did the authors >>>>> or other proponents here do any such work and if so can you >>>>> send a pointer to your results? If not, then I believe the onus >>>>> is on the folks who want to break TLS to do that work >>>>> themselves if they want to make a serious proposal and it is >>>>> not ok IMO to try put that work onto the community who have >>>>> been working hard for years to make TLS stronger. >>>>=20 >>>> I would be willing to work with the people that did the formal=20 >>>> analysis to show the impact of including the extension, and >>>> making changes to the extension that are indicated by that >>>> analysis. >>>>=20 >>>=20 >>> IMO, that's not a good answer. When improving the security=20 >>> properties of the protocol it may suffice. When weakening the >>> protocol, I strongly believe the onus is on you to have done that >>> work ahead of time, so that the damage you are proposing the >>> Internet suffers is clear and known and not discovered years >>> later. >>>=20 >>>>> 2. Which of the hundreds of applications making use of TLS did >>>>> you analyse before proposing this? If only a handful, then same >>>>> comment wrt where the onus ought lie. >>>>=20 >>>> Just like TLS 1.3 has been implemented and tested with many=20 >>>> applications during its development, I would expect the same to=20 >>>> happen in those environments where there is interest in making >>>> use of this extension. >>>=20 >>> The TLS WG has spent an awful lot of effort on (I think) every >>> single semantic difference between TLS1.2 and TLS1.3. (Ortt for >>> example.) You are now asking that everyone else do work to figure >>> out how your proposal damages their uses of TLS so that this >>> supposed use case is dealt with. I think you and other proponents >>> of breaking TLS need to spend that effort yourselves. (This is >>> because as you know there is no way to limit the damage of your >>> proposal to only the use-cases that are the claimed targets for >>> this bad idea.) >>>=20 >>> So yes, those answers are as I expected and are just as=20 >>> unsurprisingly, utterly unsatisfactory. >>>=20 >>> S. >>>=20 >>>>=20 >>>> Russ >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ TLS mailing list=20 >>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >=20 From nobody Thu Oct 5 09:44:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779F2132D96 for ; Thu, 5 Oct 2017 09:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 4D5R3e__Exyi for ; Thu, 5 Oct 2017 09:44:23 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AB1133210 for ; Thu, 5 Oct 2017 09:43:08 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id m16so5520629iod.1 for ; Thu, 05 Oct 2017 09:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m6F/H9SFCy7QhF0uguNtc/r2G9wevrHs/BGouwhUr7M=; b=bvxVTFAA74nFFACTlgyz2+mMoq489ec+vK6f9sIPkDoDaolY4Lt1Sal0u+Ya7RXetF YyJ+C2oY21miK3ohSLnC4oOhQnlEqHC2lK2PY/In/VEUh2Ig++SF8yAhKlJXMQ4Lw28P GXHCQO8EeJSsU1omALYJp9NSHDRfjonSWunX8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m6F/H9SFCy7QhF0uguNtc/r2G9wevrHs/BGouwhUr7M=; b=bDUoaecJ92EXhK2NFr0pexX/l0dV5BWiNtsuvL9YOVZH7sAVlzEaqxUiepLbGREqfn zz9m6lCS0l2OYWP0Vd/UhK6sPUnHPjn4IWaVB+igsvMbg4kpWVpGXr/ihrlwGDeVBSmL 9RKIB1PG1DKK3fzHJJQuspvIp410NFN2TRIPvvQVzw/86QkIHVvba9nBKqbv6x3b6E2F hnfmUbF6s+e7xOYdLB+FJihqFLEnCgClpXPJFy6etNuB/siXvTWnjbSBsSoEfPE7ZXuG C2A9liHr0YzuH+Nn9UTMHJYTgdNl+EjfwIA59zUM0H+DgsGZrpcLh4glyuNkYIZXyvz2 300g== X-Gm-Message-State: AMCzsaXBeqORxvHu6rQ2CrJsC5XSCnWTLi8RpvI/42zCG7nL83JYteOL xUEU5mPZVuoapKngA2lV7D0Djg== X-Google-Smtp-Source: AOwi7QB57vRHINQ3uTtxV8N37eltNgGiT/Yy5g+WyoJNxu9Jejot5CkxWU+WhwFKeu3iQZ3YiQaDtg== X-Received: by 10.107.84.3 with SMTP id i3mr38387083iob.52.1507221787813; Thu, 05 Oct 2017 09:43:07 -0700 (PDT) Received: from [5.5.33.173] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id 77sm8601182iok.41.2017.10.05.09.43.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 09:43:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <1B6398D7-695F-492D-889F-2E006C596F33@akamai.com> Date: Thu, 5 Oct 2017 09:43:01 -0700 Cc: Joe Salowey , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <860D5B0C-6700-463C-837E-CB7098440E74@sn3rd.com> References: <1B6398D7-695F-492D-889F-2E006C596F33@akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 16:44:25 -0000 I put this in a PR: = https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/46/file= s spt > On Oct 4, 2017, at 12:37, Salz, Rich wrote: >=20 > Perhaps change the list =E2=80=9Cto=E2=80=9D to =E2=80=9Cintended = for=E2=80=9D ? From nobody Thu Oct 5 09:45:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBA2132F3F for ; Thu, 5 Oct 2017 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 e9V6dZoZpJPS for ; Thu, 5 Oct 2017 09:45:42 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DBE132949 for ; Thu, 5 Oct 2017 09:45:42 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id y138so2130902itc.5 for ; Thu, 05 Oct 2017 09:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zhEWzrGhSRLh+8dj/oF174MtA9FbXCffjNbgx6sFgYE=; b=H1EOvPES4+BoLMQ/aUuD6Mr2ErRVkjvP1dKm1XEoVJo9RdLnWAIYdEUc9aJSVCZDHb E4+PV1mU6mY3S9gl16tbfmNAslMIUNnB0+mMFbRpV8jbyjsKqLHywzHvZPZZACtX/2QS phEnyUG1Ogf+TDmiqB5gcbim4d3iNy8lXExi4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zhEWzrGhSRLh+8dj/oF174MtA9FbXCffjNbgx6sFgYE=; b=ck1LlZpsCzh7MPYl6qPN5twrwhhmKLhXeN+XKg9Cg+F5neTIqMYVA7MbHuWGBAKJL0 NNkqKoVhMLowvHQ9/b4h7WCOQlWyAsYDe/e4W2795TGql82NLccbzRSbg/B+DXUJfOVa /Dihj8FLDhj6pNzpRDO78/rIpGINjF85ps/NH1wAn7u/qU4rTu6zn8ogkcrska5JxcAB Hdh0n7Ib878Y8oBqJ6v0+7TrH7tapojevCjkphZtYUt2gl64jdr6wRX1YKs6F0v8cJg2 0GQ5dG06JB8wuogNNVQuG7dwaGH2AFIfxZ5CNyPcWJnFHEFteBEjOuTCB1xpiiVmUuqw L3OA== X-Gm-Message-State: AMCzsaWD42Oqyvt/OLElAJlaVgTwWXg69kRCXbP25E+3k8OWuwKZ84Cf 68NGPMT/U1Z+LsHkvjFcPKPT6A== X-Google-Smtp-Source: AOwi7QAa2+WOVgyzH+xe5eNY1mxxeYKpsCZJaYDTVPlcJZtPF0AfNhJHK3LSRF/uYG8ZgPVIEIPRuA== X-Received: by 10.36.140.77 with SMTP id j74mr31154334itd.95.1507221941483; Thu, 05 Oct 2017 09:45:41 -0700 (PDT) Received: from [5.5.33.173] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p125sm77346itb.29.2017.10.05.09.45.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 09:45:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Thu, 5 Oct 2017 09:45:38 -0700 Cc: Joe Salowey , Rich Salz , "" Content-Transfer-Encoding: quoted-printable Message-Id: <04B47032-A6C6-4DDE-9C6E-E8A51303A320@sn3rd.com> References: To: Andrei Popov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 16:45:44 -0000 This is exactly how I think about it. spt > On Oct 4, 2017, at 12:11, Andrei Popov = wrote: >=20 > It seems that CCM_8 falls in the =E2=80=9Climited applicability=E2=80=9D= bucket. However, there=E2=80=99s nothing wrong with IoT specs requiring = these ciphers in their TLS profiles. > =20 > Cheers, > =20 > Andrei > =20 > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey > Sent: Wednesday, October 4, 2017 11:42 AM > To: Salz, Rich > Cc: > Subject: Re: [TLS] Should CCM_8 CSs be Recommended? > =20 > The current editor's copy of the draft has the following text about = the recommended column: > =20 > The instructions in this document add a recommended column to many of = the TLS registries to indicate parameters that are generally recommended = for implementations to support. Adding a recommended parameter to a = registry or updating a parameter to recommended status requires = standards action. Not all parameters defined in standards track = documents need to be marked as recommended. >=20 > If an item is marked as not recommended it does not necessarily mean = that it is flawed, rather, it indicates that either the item has not = been through the IETF consensus process or the item has limited = applicability to specific cases. >=20 > =20 > On Wed, Oct 4, 2017 at 4:58 AM, Salz, Rich wrote: > =E2=9E=A2 We=E2=80=99re recommending that these five suites be = dropped from the recommended list. Please let us know what you think. >=20 >=20 > Does =E2=80=9Crecommended=E2=80=9D mean for general use, in the public = Internet? Or is it =E2=80=9CI know it when I see it=E2=80=9D kind of = thing? >=20 > Either way, I support un-recommending them >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > =20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 5 09:58:06 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A76126D0C for ; Thu, 5 Oct 2017 09:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=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 EcbalXmWaH0r for ; Thu, 5 Oct 2017 09:58:01 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 1478C133344 for ; Thu, 5 Oct 2017 09:58:01 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id n140so15397544lfn.4 for ; Thu, 05 Oct 2017 09:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bthB8iBdtB1Z5G3AcZWrzXcQsyPj71/5Y8L8td++5yo=; b=bJ6xani5RZ23JE/Bq0SgYWzZU4veCLbqRvE1JPr7tUG4i3SSgYbs4FbywJWO9Gch4w d6QhAbihmgFcT4ljWO3Mt691FfCVjk1U4kxeq7gK1ZjHXWAJLI+6cEwUKLPjl7kcS5Mf yFZvEVNP2ni+r54gKIVLsF/ANTIKcEitj7KxQ8U6FjaXR3gZ2Lkbq9hBOarmTywFMB94 lAAF/ZSxdqqxjgsUHwNt14OmX+FoehVNVGL8B5fHTaeNANmE7Ty85oM4P42r3YBD8K1N lfeXRUkey5rbh4EnMyp1LQOJ1vBjg2wcjXyuAsvhZCBlwYCcjytyvu5zaLpw72XinLRZ urnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:from:date:message-id:subject:to:cc; bh=bthB8iBdtB1Z5G3AcZWrzXcQsyPj71/5Y8L8td++5yo=; b=LtYK1meE3OZUAGTgGgnSNbTgh4AHGprUiWJmYYL9TEzrciAudar4qMdfZc1z9yfz7e 3Fz6YXqS1iz7D0S1hq2iz9FD5FtLijAouITYWLm+MqfQ7UEuz9oYRNN20nS3DVFp4ylR EJDJbcmf8DA9UWc8E5pWLrt93ZycMV+diOpDTS63eYNiK7p7llaQ+rYnxL4x5M0y2ah0 EybVsMHfXmKpozxYt4a4JtTTx57URiA/UR0PrTiPs88RoiwjlVb6l5mG7bEtY2fWZLm8 +EZ0iyu3gomVwX/rWUsmgMHEcn8yquJVnphlX5gJA3ulmmRMKzXzCD6VpfCGmAGzn39j lkQQ== X-Gm-Message-State: AHPjjUjvI/zAWP+kU0wP/pLI5x+1kdGxH4eI/FEhHB8N0fwUo+nrAsi6 pPqEYt9IfCI4nRHSLrldUvTUwbDjn+3sJDhLLDGFgA== X-Google-Smtp-Source: AOwi7QCfbF8iG4LVKlLnn+q5m05vXLEACAz/eqvZuDviWYS0LkFjn4p9ybAduWcrzL9kikMEw9bhAmKuiLSfe+GWeWo= X-Received: by 10.46.23.25 with SMTP id l25mr11269924lje.178.1507222679288; Thu, 05 Oct 2017 09:57:59 -0700 (PDT) MIME-Version: 1.0 Reply-To: robert.cragie@gridmerge.com Sender: robert.cragie@gmail.com Received: by 10.25.20.25 with HTTP; Thu, 5 Oct 2017 09:57:58 -0700 (PDT) In-Reply-To: <04B47032-A6C6-4DDE-9C6E-E8A51303A320@sn3rd.com> References: <04B47032-A6C6-4DDE-9C6E-E8A51303A320@sn3rd.com> From: Robert Cragie Date: Thu, 5 Oct 2017 17:57:58 +0100 X-Google-Sender-Auth: wdf_oaEl2FlmkvDPwlGUBfNS64Y Message-ID: To: Sean Turner Cc: Andrei Popov , "" Content-Type: multipart/alternative; boundary="94eb2c1a62b6657ebd055acfa05a" Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 16:58:05 -0000 --94eb2c1a62b6657ebd055acfa05a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The original requirement for the truncated (_8) authentication tags was purely to save bytes. It makes very little difference re. processing as a 16 octet tag is always computed in AES-CCM-128 anyway. I agree with the assessment that it is "limited applicability" in the grand scheme of things although it may be more ubiquitous in IoT applications. Robert On 5 October 2017 at 17:45, Sean Turner wrote: > This is exactly how I think about it. > > spt > > > On Oct 4, 2017, at 12:11, Andrei Popov > wrote: > > > > It seems that CCM_8 falls in the =E2=80=9Climited applicability=E2=80= =9D bucket. > However, there=E2=80=99s nothing wrong with IoT specs requiring these cip= hers in > their TLS profiles. > > > > Cheers, > > > > Andrei > > > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey > > Sent: Wednesday, October 4, 2017 11:42 AM > > To: Salz, Rich > > Cc: > > Subject: Re: [TLS] Should CCM_8 CSs be Recommended? > > > > The current editor's copy of the draft has the following text about the > recommended column: > > > > The instructions in this document add a recommended column to many of > the TLS registries to indicate parameters that are generally recommended > for implementations to support. Adding a recommended parameter to a > registry or updating a parameter to recommended status requires standards > action. Not all parameters defined in standards track documents need to b= e > marked as recommended. > > > > If an item is marked as not recommended it does not necessarily mean > that it is flawed, rather, it indicates that either the item has not been > through the IETF consensus process or the item has limited applicability = to > specific cases. > > > > > > On Wed, Oct 4, 2017 at 4:58 AM, Salz, Rich wrote: > > =E2=9E=A2 We=E2=80=99re recommending that these five suites be dropped= from the > recommended list. Please let us know what you think. > > > > > > Does =E2=80=9Crecommended=E2=80=9D mean for general use, in the public = Internet? Or is > it =E2=80=9CI know it when I see it=E2=80=9D kind of thing? > > > > Either way, I support un-recommending them > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1a62b6657ebd055acfa05a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The original requirement for the truncated (_8) authentica= tion tags was purely to save bytes. It makes very little difference re. pro= cessing as a 16 octet tag is always computed in AES-CCM-128 anyway.
I agree with the assessment that it is "limited applicabil= ity" in the grand scheme of things although it may be more ubiquitous = in IoT applications.

Robert

On 5 October 2017 at 17:45, Sean Tur= ner <sean@sn3rd.com> wrote:
T= his is exactly how I think about it.

spt

> On Oct 4, 2017, at 12:11, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
>
> It seems that CCM_8 falls in the =E2=80=9Climited applicability=E2=80= =9D bucket. However, there=E2=80=99s nothing wrong with IoT specs requiring= these ciphers in their TLS profiles.
>
> Cheers,
>
> Andrei
>
> From: TLS [mailto:tls-bounces@= ietf.org] On Behalf Of Joseph Salowey
> Sent: Wednesday, October 4, 2017 11:42 AM
> To: Salz, Rich <rsalz@akamai.co= m>
> Cc: <tls@ietf.org> <tls@ietf.org>
> Subject: Re: [TLS] Should CCM_8 CSs be Recommended?
>
> The current editor's copy of the draft has the following text abou= t the recommended column:
>
> The instructions in this document add a recommended column to many of = the TLS registries to indicate parameters that are generally recommended fo= r implementations to support. Adding a recommended parameter to a registry = or updating a parameter to recommended status requires standards action. No= t all parameters defined in standards track documents need to be marked as = recommended.
>
> If an item is marked as not recommended it does not necessarily mean t= hat it is flawed, rather, it indicates that either the item has not been th= rough the IETF consensus process or the item has limited applicability to s= pecific cases.
>
>
> On Wed, Oct 4, 2017 at 4:58 AM, Salz, Rich <rsalz@akamai.com> wrote:
> =E2=9E=A2=C2=A0 We=E2=80=99re recommending that these five suites be d= ropped from the recommended list.=C2=A0 Please let us know what you think.<= br> >
>
> Does =E2=80=9Crecommended=E2=80=9D mean for general use, in the public= Internet?=C2=A0 Or is it =E2=80=9CI know it when I see it=E2=80=9D kind of= thing?
>
> Either way, I support un-recommending them
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c1a62b6657ebd055acfa05a-- From nobody Fri Oct 6 05:43:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37EB1349A5 for ; Fri, 6 Oct 2017 05:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYy8MCs9hU0H for ; Fri, 6 Oct 2017 05:43:28 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 A61ED132D18 for ; Fri, 6 Oct 2017 05:43:27 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id k7so1957500wre.2 for ; Fri, 06 Oct 2017 05:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yp1RIJVak+Tq85LPq5BSylAoHWBc7OM9aPza80odD3g=; b=FkSmNLTUwgNAaG00Ks7exljAJazf5QchUGW+avTxmpAeEZhhn+72BdYFlptuowgo8r Th45/jND+JOKwduHcKlzTZfOZW/kfTJXwcy3XQyD1iL7y7XJHzvfA5N57RAVqZ46K419 kCh8wOQh7CeosqzZXtLSs49HNCWtZ2JbPyb+xcbW41IQYKNoy5oWdcCjkQGcab41Fm/W lP1EDIXtndFzk5QF1CuqIQTRo0Jzzlg2U90wyH30sQwBa0AhTQ9WRLBUlYFZ+jawQw8d F47JRRdcLKIIvjhikUrV5630L/gvz4OZ+/fMxlGDEjU133vOfq4rcIS32wPdxgBO9Ujl QG0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yp1RIJVak+Tq85LPq5BSylAoHWBc7OM9aPza80odD3g=; b=YtHQDgJltRNZlSURtEJAZYRYdmqJGsE3+Su5ZZ1v7/vxHI93ixlkdr/6wUSYZWHDrn GStUm6DSmb6O7mb3WWBvjE7omSKTy6wr4e6C4f5wJxud1iAuxMHui7g0URaBH3/UuQ3a NZ9d6V4tNz363Lhe2KMlHq9GyLcv3nqGS7cck5GH/9WWPci7VrtGuixuogCIoWqmxYrB Pv/eL/u7corYciyLl2NMqri0C6zh5vcFoe4q8qENubxMhyKy5kL0dZTWFo4H+MQHoAnP du/eLQTMoD+LrZQqO5cGHHg3yj6b6xmY0NNucnZ29IqBSnV5wr8wF6jwHqrEGpIq62C7 sQ1Q== X-Gm-Message-State: AMCzsaVk4+mERYS/ns35/Amoxhrfwj/H8RwQbY3Ki2zUvEX2DhFgzXNs Kogo9fmAxV8g3yy7xR2Sf1V7tqzRO3eHtRjqfVq7YA== X-Google-Smtp-Source: AOwi7QD1zIQaUc2AoTKNND73f9Ru/AyEaCpdvqOqsIGg/v4PwyNFJ+r1OXJ8O5SJXzKeLhkcFQFTX8jJeNmy8bF/US0= X-Received: by 10.223.176.156 with SMTP id i28mr1932142wra.45.1507293806000; Fri, 06 Oct 2017 05:43:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.210 with HTTP; Fri, 6 Oct 2017 05:43:25 -0700 (PDT) In-Reply-To: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> From: Richard Barnes Date: Fri, 6 Oct 2017 08:43:25 -0400 Message-ID: To: Ralph Droms Cc: "" Content-Type: multipart/alternative; boundary="001a1141af52e10fce055ae02f61" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 12:43:30 -0000 --001a1141af52e10fce055ae02f61 Content-Type: text/plain; charset="UTF-8" Hi Ralph, Russ, Thanks for the update here. I agree that this is an improvement over draft-green-tls-static-dh-in-tls13, in particular because (1) it has a mechanism for mutual consent and (2) it only touches the outputs of the handshake, not the inputs. A couple of points to consider: Like sftcd, I would like to see some modeling to verify that this has the expected properties. (Unlike sftcd, I'm not sure this needs to be done at the start vs. before it's finished.) It seems straightforward enough that I don't expect major issues, but it would be good to check. It's worth noting that the approach here is all-or-nothing, in contrast to designs like mcTLS (https://mctls.org/). The entity to whom the keys are exfiltrated can make modifications to the session in addition to reading it. I think this is probably the right trade-off of simplicity vs. solving the problem, but maybe it's worth considering, say, a cipher suite with AEAD plus an additional integrity check, so that you could exfil the AEAD key and not the integrity key. That's pretty much what we've done in the PERC WG with draft-ietf-perc-double to allow middleboxes to make some changes to an SRTP packet. I don't think the spec is quite interoperably implementable in its current state, since it's missing important details on how the wrapping is done (what AEAD algorithm? how do you make an IV?). This is obviously something that can get worked out in WG, should we decide to adopt this draft. --Richard On Mon, Oct 2, 2017 at 4:31 PM, Ralph Droms wrote: > We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS > extension defined in this I-D takes into account what we heard from the > discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 > in Prague. Specifically, it provides an opt-in capability for both the TLS > client and server and makes it clear on the wire that visibility will be > enabled for the session. The new mechanism does not depend on static > handshake or session keys. > > - Ralph and Russ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1141af52e10fce055ae02f61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ralph, Russ,

Thanks for t= he update here.=C2=A0 I agree that this is an improvement over draft-green-= tls-static-dh-in-tls13, in particular because (1) it has a mechanism for mu= tual consent and (2) it only touches the outputs of the handshake, not the = inputs.=C2=A0 A couple of points to consider:

Like sftcd, I would like to see some modeling to verify that this has the = expected properties.=C2=A0 (Unlike sftcd, I'm not sure this needs to be= done at the start vs. before it's finished.)=C2=A0 It seems straightfo= rward enough that I don't expect major issues, but it would be good to = check.

It's worth noting that the approach= here is all-or-nothing, in contrast to designs like mcTLS (https://mctls.org/).=C2=A0 The entity to whom the keys = are exfiltrated can make modifications to the session in addition to readin= g it.=C2=A0 I think this is probably the right trade-off of simplicity vs. = solving the problem, but maybe it's worth considering, say, a cipher su= ite with AEAD plus an additional integrity check, so that you could exfil t= he AEAD key and not the integrity key.=C2=A0 That's pretty much what we= 've done in the PERC WG with draft-ietf-perc-double to allow middleboxe= s to make some changes to an SRTP packet.

I do= n't think the spec is quite interoperably implementable in its current = state, since it's missing important details on how the wrapping is done= (what AEAD algorithm? how do you make an IV?).=C2=A0 This is obviously som= ething that can get worked out in WG, should we decide to adopt this draft.=

--Richard



On Mon,= Oct 2, 2017 at 4:31 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
We are about to publish draft= -rhrd-tls-tls13-visibility-00.=C2=A0 The TLS extension defined in this= I-D takes into account what we heard from the discussion regarding TLS vis= ibility and draft-green-tls-static-dh-in-tls13-00 in Prague. Specifica= lly, it provides an opt-in capability for both the TLS client and server an= d makes it clear on the wire that visibility will be enabled for the sessio= n.=C2=A0 The new mechanism does not depend on static handshake or session k= eys.

- Ralph and Russ


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1141af52e10fce055ae02f61-- From nobody Fri Oct 6 13:17:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CBF132195 for ; Fri, 6 Oct 2017 13:17:20 -0700 (PDT) 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=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsAY4ydH76qr for ; Fri, 6 Oct 2017 13:17:18 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC7A134C8F for ; Fri, 6 Oct 2017 13:17:18 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id k1so22622491qti.2 for ; Fri, 06 Oct 2017 13:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6692tIeuoSA0pdAD1SkU3jiTWzgz2NF292CtVyWylno=; b=cNcV4i/Px3J+5dtly4/K/H72fZCRqsNHHHMVPNcJY3GSKCC+J/jPKTsL9DAA79cys+ KWxzg6C0se7SqdjpuuvysN2HZcbzcfzDt+JrPWcLsV1xrsCX1OTeIyvjhC+Io0qm+Ak/ uooA4QcsxL8RB2VGKvnb0bbKl2DVoenCBmuAmntdaiGJHeDuva89t8XdWKzlZPfu3G7P cGQkNq8be7yle7xVHA2bf0FgIFXw8ecDpJWU82yBx45vdEyye/NFhaHoN0gCVGlE2aUq I4+KlBa4EbWXkX6Le+/QiLKuxfU7QxgweJCnjfkUPHTwJr1PrTuASq0P3if/Nprm6Zp7 bLjQ== 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=6692tIeuoSA0pdAD1SkU3jiTWzgz2NF292CtVyWylno=; b=jTZbf53BhZx9cAz0zQj6Z3kM9x9TQ46wModHk6UeTDE4JB3Ij1MCAjlLcCkRmJewqi yjcnTdn0YbsvyNpEE4JSLHjD5Ah1cY+F/rzlKRXM/FLf2DCJ3E3QsclmozC8PgNpDnE1 pWMMfTX+72RF0HFSKF8nEXGtGfKedSHboFhGCjwR64ltFRwKDPSoqgEp7He2gqm77W+5 CRa6UkfeqSr5Dyv7Yf+jlimBjsPECTVxxaZNtjfVxg0zjhc1e+2lQsutP0evtMtmbOIP MmeE1hxseZ8ze5AgebVdrsrc6RBjtcxs735wHFxkn3JS5APfh8FD/XT99W4PkJt0sR9Z rrvg== X-Gm-Message-State: AMCzsaWa224LNFzMhPDYDi1ODSY8dioqMKiVSjEAdyfhlTnrd5eKpvzV Fgk+EJsINqKjMZv9jI8+q5w1zv5OzODWfNe2+pkTVMn7 X-Google-Smtp-Source: AOwi7QDRFvswS6H2izJ6NwbQIxLZFxNn/0hyidOS5RNmGhtpmKgP/fS52aT+ZKzuDVKvctys5EUUfBkYdDgNr95k/zY= X-Received: by 10.37.105.203 with SMTP id e194mr2553410ybc.71.1507321037644; Fri, 06 Oct 2017 13:17:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 6 Oct 2017 13:16:37 -0700 (PDT) From: Eric Rescorla Date: Fri, 6 Oct 2017 13:16:37 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c14ebc80301ff055ae687bc" Archived-At: Subject: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 20:17:20 -0000 --94eb2c14ebc80301ff055ae687bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi folks, In Prague I mentioned that we were seeing evidence of increased failures with TLS 1.3 which we believed were due to middleboxes. In the meantime, several of us have done experiments on this, and I wanted to provide an update. The high-order bit is that *negotiating* TLS 1.3 seems to cause increased failures with a variety of middleboxes (it=E2=80=99s generally sa= fe to offer TLS 1.3 to servers which don=E2=80=99t support it). The measured incremental error rates vary quite a bit, ranging from minimal (Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using a slightly different methodology (organic versus forced traffic) and different populations (mobile, desktop, enterprise, etc), but it does seem like there is a nontrivial failure rate. At this point, we have two options: - Fall back to TLS 1.2 (as we have unfortunately done for previous releases= ) - Try to make small adaptations to TLS 1.3 to make it work better with middleboxes. The Chrome team has been working on angle #2 and has been having success with an approach of trying to make TLS 1.3 connections look more like TLS 1.2. Their current experiments get them down to about 1% incremental failures and they are currently measuring some changes they hope will shave that down more. These changes are a bit annoying but basically superficial; they do not affect the cryptography. Separately, Firefox and Facebook have been experimenting with the new content type described in PR#1051 (Google=E2=80=99s and Facebook=E2=80=99s = results conflict, so this is a bit of a mystery). We hope to have results from both sets of experiments by end of October, at which point we should be able to discuss the best way forward as a group. -Ekr --94eb2c14ebc80301ff055ae687bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

In Prague I mentio= ned that we were seeing evidence of increased
failures with TLS 1= .3 which we believed were due to middleboxes. In
the meantime, se= veral of us have done experiments on this, and I
wanted to provid= e an update.

The high-order bit is that *negotiati= ng* TLS 1.3 seems to cause
increased failures with a variety of m= iddleboxes (it=E2=80=99s generally safe
to offer TLS 1.3 to serve= rs which don=E2=80=99t support it). The measured
incremental erro= r rates vary quite a bit, ranging from minimal
(Facebook) to ~1.5= % (Firefox) and ~3.4% (Chrome). Each of us is using
a slightly di= fferent methodology (organic versus forced traffic) and
different= populations (mobile, desktop, enterprise, etc), but it does
seem= like there is a nontrivial failure rate. At this point, we have
= two options:

- Fall back to TLS 1.2 (as we have un= fortunately done for previous releases)
- Try to make small adapt= ations to TLS 1.3 to make it work better with middleboxes.

The Chrome team has been working on angle #2 and has been having
success with an approach of trying to make TLS 1.3 connections loo= k
more like TLS 1.2. Their current experiments get them down to a= bout 1%
incremental failures and they are currently measuring som= e changes
they hope will shave that down more. These changes are = a bit annoying
but basically superficial; they do not affect the = cryptography.

Separately, Firefox and Facebook hav= e been experimenting with the new
content type described in PR#10= 51 (Google=E2=80=99s and Facebook=E2=80=99s results
conflict, so = this is a bit of a mystery). We hope to have results from
both se= ts of experiments by end of October, at which point we should
be = able to discuss the best way forward as a group.

-= Ekr


--94eb2c14ebc80301ff055ae687bc-- From nobody Fri Oct 6 18:02:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB5F132199 for ; Fri, 6 Oct 2017 18:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bqA3WFh_d6PP for ; Fri, 6 Oct 2017 18:02:02 -0700 (PDT) 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 31E33132143 for ; Fri, 6 Oct 2017 18:02:02 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9711ioE029592; Sat, 7 Oct 2017 02:01:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=h9Dg+9xvYLBpa0NVMnCgj15I/S4w37Py0mbtW6/ISE4=; b=eQMXqVHP6JxsLMPJSMQJrfqZD+5cx4i41Ob3P5f5z0EqgM/Gac40HkpfcY5WIikeigWW TVD3dNJLFdda8vnlB9Q2DQgad/RsAMJ5ZGyQq8uF3YMUD6B7YTpQWmNhtCqbDkrQolkd tMg0ZhJhIeHDa4utJ7veUpgEL4pYte62k5toLwgp9EUKO4JNKCG3hPRCq+2uBadNPa3n /msvAc44vm9uqJQeXFrCRFLiVWOXZkbl8k3XwAE8Xv0VvCFQoDAeWpRqijpoIy6JX+hB +AahNggguLYOaEd870pZsyrNeDY8zSTKxTZFtSisRAjXYGxnw7DHtbMcPvhK2oEwy9qX IQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2ddb2f4u28-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Oct 2017 02:01:59 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v97117Mm010040; Fri, 6 Oct 2017 21:01:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dckspupak-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 Oct 2017 21:01:58 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 6 Oct 2017 20:01:57 -0500 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.1263.000; Fri, 6 Oct 2017 20:01:58 -0500 From: "Salz, Rich" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Update on TLS 1.3 Middlebox Issues Thread-Index: AQHTPuAhbOGtBHBWK0qNw6DkAAvXEKLX5dCA Date: Sat, 7 Oct 2017 01:01:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.95] Content-Type: multipart/alternative; boundary="_000_EAD84CE141A940FEB88218F077FFD691akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-06_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710070013 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-06_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710070013 Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 01:02:04 -0000 --_000_EAD84CE141A940FEB88218F077FFD691akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlIHVwZGF0ZS4NCg0KVGhlcmUgaXMgYSB0aGlyZCBvcHRp b24sIG5hbWUgdGhlIGRldmljZXMgd2hpY2ggYXJlIGtub3duIHRvIGNhdXNlIHByb2JsZW1zLCBh bmQgbW92ZSBmb3J3YXJkIHdpdGggdGhlIGRyYWZ0IGFzLWlzLg0KDQoNCg== --_000_EAD84CE141A940FEB88218F077FFD691akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyB2ZXJ5IG11Y2gg Zm9yIHRoZSB1cGRhdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIGEgdGhpcmQg b3B0aW9uLCBuYW1lIHRoZSBkZXZpY2VzIHdoaWNoIGFyZSBrbm93biB0byBjYXVzZSBwcm9ibGVt cywgYW5kIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBkcmFmdCBhcy1pcy48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EAD84CE141A940FEB88218F077FFD691akamaicom_-- From nobody Fri Oct 6 20:27:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4984132125 for ; Fri, 6 Oct 2017 20:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cem.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGhbV_njr3iR for ; Fri, 6 Oct 2017 20:27:24 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 25B29132076 for ; Fri, 6 Oct 2017 20:27:24 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id h63so10590202vka.4 for ; Fri, 06 Oct 2017 20:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RuUVmFCjuiOtwEdwEG0Lb4jnd/uTcR4AYE/MnABp6Es=; b=WBaFxBw5j59YJd/I7jpD9bwQFEGuOFy5GWbf/lHZRBeXlJYNySeLrxj6uf0goC1JO4 9d51jhDdORnsXgk8gJ2AdvehS2U8OQ+IlyvQITnagcNSIrV18wkbXnN/CkY8/0JcADXw /wHfhe/qaTSSApqxMS7HsRJXJDzRA/ByYxC2M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RuUVmFCjuiOtwEdwEG0Lb4jnd/uTcR4AYE/MnABp6Es=; b=XuOft6+gx1emlRrVJ08sravB+p7Dqss3bUV8DU9v3Kq1xtYx8fiF/uCM/I8cOEj6qI Vee9zDLUICIch7JMYZ2vOjswe0IEvFCZ3o/cu80KnoEoEmXYWBxlzGgJIIVdMv3sbVEf sABlX19LGVo0wUb1ID4LW5oabA8wFI6NFwS17CErf1JGwiXT6gdRLome/sMzDmDQQDgw WVHMZipE/C/AFsDiXa9Xp0ESIOt7Y5a8aAcRHPwCruYa80Q8+YYk76W6TXEdmxfZcUYy n+aUy1CSbrivFyje1oo6z9bvOS2otfH/YI4qU9obmpOhRgGOYO+zDHdKd32yGmm39O5q /j5Q== X-Gm-Message-State: AMCzsaWWth36Hf2rBSsDIhgEkF2ysyUb6VopfUfLK/3G1A58uByBcZId W+VYz/p2lERShSRtttmgPle3ShHqKj8bJ9mQwvqKeZZb X-Google-Smtp-Source: AOwi7QBy2jMXKyo72Fudwv6GmnzXIORivbcpRxafRRrL36rDFXZh+xVVZK90feGam4L0iICOsD+OivoFBphMbesjqRg= X-Received: by 10.31.16.232 with SMTP id 101mr1982592vkq.158.1507346842991; Fri, 06 Oct 2017 20:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.10.144 with HTTP; Fri, 6 Oct 2017 20:27:22 -0700 (PDT) X-Originating-IP: [2600:100c:b004:99d4:3af8:7484:4a2b:286c] Received: by 10.176.10.144 with HTTP; Fri, 6 Oct 2017 20:27:22 -0700 (PDT) In-Reply-To: References: From: Carl Mehner Date: Fri, 6 Oct 2017 22:27:22 -0500 Message-ID: To: "Salz, Rich" Cc: Eric Rescorla , IETF TLS Content-Type: multipart/alternative; boundary="001a114365c4215214055aec8926" Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 03:27:26 -0000 --001a114365c4215214055aec8926 Content-Type: text/plain; charset="UTF-8" I think this third option is a good idea, it's worked in the past with at least 2 different load balancers and (to an extent) with a certain color of proxy. People that work in "Enterprises" do follow this list and can help open tickets with vendors and get the work prioritized. On Oct 6, 2017 8:02 PM, "Salz, Rich" wrote: Thanks very much for the update. There is a third option, name the devices which are known to cause problems, and move forward with the draft as-is. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --001a114365c4215214055aec8926 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this third option is a good idea, it's w= orked in the past with at least 2 different load balancers and (to an exten= t) with a certain color of proxy.

People that work in "Enterprises" do follow this list a= nd can help open tickets with vendors and get the work prioritized.


On Oct 6, 2017 8:02 PM, "Salz, Rich" <rsalz@akamai.com> wrote:

Thanks very much for the update.

=C2=A0

There is a third option, name the devices which are = known to cause problems, and move forward with the draft as-is.

<= /u>=C2=A0

=C2=A0


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a114365c4215214055aec8926-- From nobody Sat Oct 7 00:17:35 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E168F132153 for ; Sat, 7 Oct 2017 00:17:33 -0700 (PDT) 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=[BAYES_50=0.8, 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 qRjIJkUHwbTd for ; Sat, 7 Oct 2017 00:17:31 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CD41321DE for ; Sat, 7 Oct 2017 00:17:30 -0700 (PDT) Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 07 Oct 2017 09:17:28 +0200 id 0000000000000087.0000000059D87F88.00002E40 Date: Sat, 7 Oct 2017 09:17:20 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20171007091720.012fdb7b@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 07:17:34 -0000 Alternative proposal: 1. Identify the responsible vendors. 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh, it's your customers who don't update? Seems you don't have any reasonable update system. Call your customers, send some support staff to them. Fix this. Now." 3. Call for a boycott of the vendors who are not able to fix this. Seriously... If only 2 or 3 of the large companies that are involved here would do this I am sure we don't have such problems any more in the future. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Sat Oct 7 02:57:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF9134793 for ; Sat, 7 Oct 2017 02:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 TaA_n28VU2is for ; Sat, 7 Oct 2017 02:57:30 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A881013479C for ; Sat, 7 Oct 2017 02:57:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id E3DF9B5184; Sat, 7 Oct 2017 12:57:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id GT7lXalkkHWs; Sat, 7 Oct 2017 12:57:26 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 33BAF2316; Sat, 7 Oct 2017 12:57:24 +0300 (EEST) Date: Sat, 7 Oct 2017 12:57:23 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20171007095723.qyuxo3sm6gmqaemn@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 09:57:32 -0000 On Fri, Oct 06, 2017 at 01:16:37PM -0700, Eric Rescorla wrote: > Hi folks, > > In Prague I mentioned that we were seeing evidence of increased > failures with TLS 1.3 which we believed were due to middleboxes. In > the meantime, several of us have done experiments on this, and I > wanted to provide an update. > > The high-order bit is that *negotiating* TLS 1.3 seems to cause > increased failures with a variety of middleboxes (it’s generally safe > to offer TLS 1.3 to servers which don’t support it). The measured > incremental error rates vary quite a bit, ranging from minimal > (Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using > a slightly different methodology (organic versus forced traffic) and > different populations (mobile, desktop, enterprise, etc), but it does > seem like there is a nontrivial failure rate. At this point, we have > two options: > > - Fall back to TLS 1.2 (as we have unfortunately done for previous releases) > - Try to make small adaptations to TLS 1.3 to make it work better with > middleboxes. What you think is acceptable failure rate? That is, if we can't get the rate below that, don't bother with adaptation? > The Chrome team has been working on angle #2 and has been having > success with an approach of trying to make TLS 1.3 connections look > more like TLS 1.2. Their current experiments get them down to about 1% > incremental failures and they are currently measuring some changes > they hope will shave that down more. These changes are a bit annoying > but basically superficial; they do not affect the cryptography. > > Separately, Firefox and Facebook have been experimenting with the new > content type described in PR#1051 (Google’s and Facebook’s results > conflict, so this is a bit of a mystery). We hope to have results from > both sets of experiments by end of October, at which point we should > be able to discuss the best way forward as a group. Has there been attempts at figuring out what exactly the middleboxes are intolerant to? Here are some candidates that come to mind: 1) Handshake seemingly cutting short (quite annoying to fix) 2) Server version seemingly ahead of client version (annoying to fix) 3) Second byte of ServerVersion is >3 (annoying to fix). 4) Unknown extension negotiated (very annoying to fix). 5) Two missing fields in TLS 1.3 ServerHello throwing off parser (not difficult to fix) 6) First byte of ServerVersion != 3 (no issue, non-representative test, as per -21, the final TLS 1.3 will have ServerVersion 3,4). I guess the reason Google's and Facebook's results conflict is that they tend to hit different kinds of middleboxes. I guess Google hits more enterprise middleboxes (more strict) and Facebook hits more carrier middleboxes (less strict). This could explain the conflict, because if carrier middlebox loses the handshake without parse error (which is what the Facebook's hack does), it probably will let things through. Whereas enterprise middleboxes tend to more deeply inspect the handshake and probably error out if the handshake isn't as expected. Fooling the latter might not be easy. Then there is the question what on earth are those carrier middleboxes trying to do? Why they seemingly try to parse ServerHello? Looking at the extension list, the only even remotely sensible to me candidates are session resumption, certificate types and ALPN (and the latter two are much more dubious than the first). For more strict Enterprise middleboxes, parsing the ServerHello makes some sense, even up to the point of failing on unknown extensions. If one wants to do variant tests, I would try to test: Variant 0) Stock TLS 1.2 (for baseline) Variant 1) TLS 1.2 with unknown extension (no effect) negotiated. Variant 2) TLS 1.2 ServerHello, with KeyShare extension and TLS 1.3 ciphersuite, with rest of handshake from TLS 1.3. Variant 3) Variant 2, but with ServerVersion of 3,x (x>3). Variant 4) Variant 3, with the two dummy fields removed and server version of 3.4 (essentially final TLS 1.3 as of current draft). -Ilari From nobody Sat Oct 7 04:33:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6CA1348AB for ; Sat, 7 Oct 2017 04:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 eb6Tmcc9ctUb for ; Sat, 7 Oct 2017 04:33:42 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D3B134318 for ; Sat, 7 Oct 2017 04:33:42 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id u138so12249821wmu.5 for ; Sat, 07 Oct 2017 04:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/pNdTaW7cRZx8PwmMTKvvBwWLJqD/Uga0U8pKqgVNAw=; b=WCB2EGotrraY4sdpzYg2v1FkGcQI2Jzwf0TRoNNSTcd7aOtIbZraEL11CQ2KUTCmOV oywTXWO206X5UifZmI6m8ZjBO9I7kyY+AaSDEOQbdMjEb5PPbGn2hlh2D5hlz4E4jEPp 6LZwsjVkchNFalVujuP1wTqmJDOo0WqjR807EeyWABhOeYzQ9pTCGvNb6VF3b/oweaKT 2xsLXWH//YK/sxzkqR4wDe2VvMoyMdigjUzk1a/7ig2LJohkXMB2nRYhnQ58bt2XnrTo 7Hv4nMUTjp+M7JYCoJfm9DjLBVBeSTsRvSWzS4iBqxM+3EJqkzJ5SGH/ifGEQmhM8VAE vAOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/pNdTaW7cRZx8PwmMTKvvBwWLJqD/Uga0U8pKqgVNAw=; b=D5LsqeSIDM1xFMgwywFnl6+7ld40TNmYeyNtE1kwewDWnvLHtE3+3DAwBAvFB8b9mT hIESCfF+cZ5wpW6hUpgfjOL/cQI4CT6U/rCyvn1c7COg7d12Ra6XVYuiZvPb8VstizI1 ZKIdHiTvbxB/t7uazAyhko4bgpO3kwjQ2yRfoK4bg2Q7kwxZyK/8vZOrnd5G7H4I+7Yk XblU57fl/jfm5IKRg57tCcU1P22wBzHc4Cm3hx2bQfH+45S1hk26XQQwXmXWiK1RxWdn 1LpfNoBtDWd99MlKtvbcZB03Oxl8p3fKSF0i7OCWKM75LHzdmDXGGc3/P1tFf7slo4Yb krxg== X-Gm-Message-State: AMCzsaXap8loUsUY6Yl1uzGTJE+BlVGI/cO9oX7Z+3P5b4y7c0p04uWD nFhO+znG1s8Yq1XM7PIas9qydufh X-Google-Smtp-Source: AOwi7QCIjMt8xE95CI71jx/A5mag8hSpDRFrNKjU+TdZVkhgqp1cp9sSGe96uNs9oyyeo7Ivzdmixg== X-Received: by 10.80.136.14 with SMTP id b14mr3460448edb.78.1507376020879; Sat, 07 Oct 2017 04:33:40 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id b30sm4882814ede.1.2017.10.07.04.33.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Oct 2017 04:33:40 -0700 (PDT) From: Yoav Nir Message-Id: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9C3D0505-06C8-459F-98BE-3893FFD7232D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 7 Oct 2017 14:33:37 +0300 In-Reply-To: Cc: Eric Rescorla , "tls@ietf.org" To: Rich Salz References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 11:33:44 -0000 --Apple-Mail=_9C3D0505-06C8-459F-98BE-3893FFD7232D Content-Type: multipart/alternative; boundary="Apple-Mail=_5727D1EB-9148-454B-9666-FBD34BC64331" --Apple-Mail=_5727D1EB-9148-454B-9666-FBD34BC64331 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Oct 2017, at 4:01, Salz, Rich wrote: >=20 > Thanks very much for the update. >=20 > There is a third option, name the devices which are known to cause = problems, and move forward with the draft as-is. +1. I like this third option. > 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh, > it's your customers who don't update? Seems you don't have any > reasonable update system. Call your customers, Vendor: Hello customer. We have an update for you that will make TLS 1.3 = work. Customer: No way. We=E2=80=99re in the middle of the year-end = processing. We=E2=80=99re not making any configuration changes until the = second week of January. Vendor: But it=E2=80=99s a simple fix. It will make things work better. = You=E2=80=99ll need it for Chrome to work with Google. Customer: What part of =E2=80=9Cnot making any configuration changes=E2=80= =9D was not clear to you!? --Apple-Mail=_5727D1EB-9148-454B-9666-FBD34BC64331 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 7 Oct 2017, at 4:01, Salz, Rich <rsalz@akamai.com> = wrote:

Thanks very much for = the update.
 
There is a third option, name the devices which are known to = cause problems, and move forward with the draft = as-is.

+1. =  I like this third option.

2. Tell all = those vendors "You have 1 month to fix this. Fix it. Oh,
it's your customers who don't update? Seems you don't have = any
reasonable update system. Call your customers, =

Vendor: Hello customer. We = have an update for you that will make TLS 1.3 work.

Customer: No way. We=E2=80=99re in the = middle of the year-end processing. We=E2=80=99re not making any = configuration changes until the second week of January.

Vendor: But it=E2=80=99s = a simple fix. It will make things work better. You=E2=80=99ll need it = for Chrome to work with Google.

Customer: What part of =E2=80=9Cnot = making any configuration changes=E2=80=9D was not clear to = you!?
= --Apple-Mail=_5727D1EB-9148-454B-9666-FBD34BC64331-- --Apple-Mail=_9C3D0505-06C8-459F-98BE-3893FFD7232D 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlnYu5EACgkQuEkLFQpY zJkdYwgAykmO0Ps15mINRajxnoHbLpYXCebSJ96bzkiu9sZ2nkflJiDAil6946zU I8pI7Kac7zc7oEY0G2d5taMy2djiUVeiFHcpWqupOvFJS6kDbKOW7DQByCs2rt4k ZaJkYE0gZ/sP7425T0bG1LOgTR8CODFXgxAUCwVxa45NTrpboMKjFC2ufkeCZYIq +sTvZXNd+rCI1RryFn67/1cnv9YhDIAfzpbadWCBv/o3qzREAhGoesWrzgOi0ojU bUXvC49qvk7d4Qxf3Gaoni5TSHhAe7I8cQsmzCezAzgU6lQBW5Wl6ouXQNhrORVP zxWfIWvPzNc3LuQIWnb71aEgouxaSw== =ZtVb -----END PGP SIGNATURE----- --Apple-Mail=_9C3D0505-06C8-459F-98BE-3893FFD7232D-- From nobody Sat Oct 7 07:08:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34E3134579 for ; Sat, 7 Oct 2017 07:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MSV8Uk4PWJI for ; Sat, 7 Oct 2017 07:08:42 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 589F1134575 for ; Sat, 7 Oct 2017 07:08:42 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id k31so795160qta.6 for ; Sat, 07 Oct 2017 07:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jjR2+cctQLdqx9sgQjd4A/guvl7gRaGRk3CQMfq/bT0=; b=R1H6ztRlv+BvVQcVB9OmCxuUfXywvWaujGnl9Y70JMUujL7Yjj2aN8zYlTQVyIPn8c 82Vw1uzFj5X77axJnHI6ij2vf5VnEjl4sOqTTdVx3ETfL8O4j5OCTuNPGaFkE/EXXVnN VUCGKeY6l9d4DoPl3otp6PP1EdCE2bBRtLm2Wjr6m8FzxdtbuLOnQhrnshEH0r4yhSva cTO6cYNQdw/fKRMMuOYZRFVp/ihGeMBF2GyBItqPwQNVcsshpE3Lwx1PtPnNiPvvJFQx R67W+mPBjjP2i+zkhBL0FqLJAprkk/wOZaO94+sb+iFHtrnWHe+p1OsoIVq4oVmyC2nL 42sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jjR2+cctQLdqx9sgQjd4A/guvl7gRaGRk3CQMfq/bT0=; b=O1mkJKtvs23g4Sau99Xbfpr5WYaNCzXniahQjMs0wJiu1XSFeWY3V75Y0KzyvqsSR7 TsQi7m9pVhv3d3m3SsWmZ+m+7LdXUjmeULTJCw2/FlcAZNos9FfEiRwjd/RU1jkXCW4f rxJhVwr+E7LqjdH5FQYCz1RD7QkI3fW6AVkroxkD+be4m4yuhKK9pNeeC7cGpANLOw7M Dq0fsMPcDa5dytdp4K9HOk7IyNHNieSa6fp24WoHtHLRk3vbks82PXivLbX+4pWd9Fh9 uMTI1SfU/vAhhCSWaIEgM62o3+UutIcpqtwyMWysRhapPAm1TBXP63S5GjBYAEgD735Y wzqw== X-Gm-Message-State: AMCzsaXxf1AV5TPUZu6dn7m8L+ggFwRZ4VdtWV+dHfzpWBxjtkyL6ttP T4TcdS2NBYBm3vcQcfqDADCH3/ph3BknMPG2AqTTjO+y X-Google-Smtp-Source: AOwi7QBSDVzX1FKn/H7zK2vknJA2Ef4XMTxWdgcImcGRPoKH5C87nhWnfWBFfVvkVVIcryj8h3ERBxS8Js2vs6Vp8pg= X-Received: by 10.37.45.110 with SMTP id s46mr4097960ybe.400.1507385321504; Sat, 07 Oct 2017 07:08:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sat, 7 Oct 2017 07:08:01 -0700 (PDT) In-Reply-To: <20171007095723.qyuxo3sm6gmqaemn@LK-Perkele-VII> References: <20171007095723.qyuxo3sm6gmqaemn@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 7 Oct 2017 07:08:01 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f4030435adeca0faa0055af57ee8" Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 14:08:44 -0000 --f4030435adeca0faa0055af57ee8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 7, 2017 at 2:57 AM, Ilari Liusvaara wrote: > On Fri, Oct 06, 2017 at 01:16:37PM -0700, Eric Rescorla wrote: > > Hi folks, > > > > In Prague I mentioned that we were seeing evidence of increased > > failures with TLS 1.3 which we believed were due to middleboxes. In > > the meantime, several of us have done experiments on this, and I > > wanted to provide an update. > > > > The high-order bit is that *negotiating* TLS 1.3 seems to cause > > increased failures with a variety of middleboxes (it=E2=80=99s generall= y safe > > to offer TLS 1.3 to servers which don=E2=80=99t support it). The measur= ed > > incremental error rates vary quite a bit, ranging from minimal > > (Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using > > a slightly different methodology (organic versus forced traffic) and > > different populations (mobile, desktop, enterprise, etc), but it does > > seem like there is a nontrivial failure rate. At this point, we have > > two options: > > > > - Fall back to TLS 1.2 (as we have unfortunately done for previous > releases) > > - Try to make small adaptations to TLS 1.3 to make it work better with > > middleboxes. > > What you think is acceptable failure rate? That is, if we can't get > the rate below that, don't bother with adaptation? > I'm not precisely sure. I think it would depend on the client profile, but at this existing rate, Firefox, at least, would have to do fallback. That's what Firefox Beta currently does. > > The Chrome team has been working on angle #2 and has been having > > success with an approach of trying to make TLS 1.3 connections look > > more like TLS 1.2. Their current experiments get them down to about 1% > > incremental failures and they are currently measuring some changes > > they hope will shave that down more. These changes are a bit annoying > > but basically superficial; they do not affect the cryptography. > > > > Separately, Firefox and Facebook have been experimenting with the new > > content type described in PR#1051 (Google=E2=80=99s and Facebook=E2=80= =99s results > > conflict, so this is a bit of a mystery). We hope to have results from > > both sets of experiments by end of October, at which point we should > > be able to discuss the best way forward as a group. > > Has there been attempts at figuring out what exactly the middleboxes > are intolerant to? Yes, there has been some of that, but mostly by the Google team and I don't want to speak for them. Best, -Ekr --f4030435adeca0faa0055af57ee8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 7, 2017 at 2:57 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Fri, Oct 06, 2017 at 01:16:37PM -0700, Eric Rescorla wrote:
> Hi folks,
>
> In Prague I mentioned that we were seeing evidence of increased
> failures with TLS 1.3 which we believed were due to middleboxes. In > the meantime, several of us have done experiments on this, and I
> wanted to provide an update.
>
> The high-order bit is that *negotiating* TLS 1.3 seems to cause
> increased failures with a variety of middleboxes (it=E2=80=99s general= ly safe
> to offer TLS 1.3 to servers which don=E2=80=99t support it). The measu= red
> incremental error rates vary quite a bit, ranging from minimal
> (Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using<= br> > a slightly different methodology (organic versus forced traffic) and > different populations (mobile, desktop, enterprise, etc), but it does<= br> > seem like there is a nontrivial failure rate. At this point, we have > two options:
>
> - Fall back to TLS 1.2 (as we have unfortunately done for previous rel= eases)
> - Try to make small adaptations to TLS 1.3 to make it work better with=
> middleboxes.

What you think is acceptable failure rate? That is, if we can't = get
the rate below that, don't bother with adaptation?

I'm not precisely sure. I think it would depend on the = client profile, but at this existing rate, Firefox, at least, would have to= do fallback. That's what Firefox Beta currently does.


> The Chrome team has been working on angle #2 and has been having
> success with an approach of trying to make TLS 1.3 connections look > more like TLS 1.2. Their current experiments get them down to about 1%=
> incremental failures and they are currently measuring some changes
> they hope will shave that down more. These changes are a bit annoying<= br> > but basically superficial; they do not affect the cryptography.
>
> Separately, Firefox and Facebook have been experimenting with the new<= br> > content type described in PR#1051 (Google=E2=80=99s and Facebook=E2=80= =99s results
> conflict, so this is a bit of a mystery). We hope to have results from=
> both sets of experiments by end of October, at which point we should > be able to discuss the best way forward as a group.

Has there been attempts at figuring out what exactly the middleboxes=
are intolerant to?

Yes, there has been some= of that, but mostly by the Google team and I don't want to speak for t= hem.

Best,
-Ekr


--f4030435adeca0faa0055af57ee8-- From nobody Sat Oct 7 07:17:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF6213320C for ; Sat, 7 Oct 2017 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 KcEkeROsivBg for ; Sat, 7 Oct 2017 07:17:50 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E53F1331BA for ; Sat, 7 Oct 2017 07:17:50 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id t69so12818355wmt.2 for ; Sat, 07 Oct 2017 07:17:50 -0700 (PDT) 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=1QgmwBYqvxOdjueJIpaI3OC6DBvOIG+8gsBs+9EHMCs=; b=RJaJ/YAwhKUlTRtmvFRoCyMpUOj5A+oSqiP+fwTTZY2Rx7iDjm41Hrk58+UaHuonlh LGYcGpgE/oTA3RF5dznukd9Wz8a1LAXHP0T/TN6K7wjlbcB1Yr3UJkOi1HdRzJ+QxQ1p EJbr/hspFEgTCzdVxyljY6hgj1sG0p3VraEVk8p5iKz0+6Mm5qz5NBykP4+6J6fDbWP0 MqQu9IDIZTD7fk+Ayf9fk36PaAYWgAPc/lmAxvgzadw7Em3I6Tg0N8ZCNYCnvWDPIlTT eLgcMhBqPnVu13oixqcTMpQyT6DJiCag0QgCiIMoheLPPQ3j9WM7Ij/N5DQ5Bbuc9v4H QQwg== 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=1QgmwBYqvxOdjueJIpaI3OC6DBvOIG+8gsBs+9EHMCs=; b=VUnuraEwiqv5xv2h8Ux/njwsvuPddOdyjSZgEiKLc6l+YYXiJZrnHDVkhuJZbMmty0 5nyNEByB9/cMbEEnilFWATtHHBJOn43+/6JR+ug0SprjJIqtq8QRYX0vGCyIXDZ5rY1h H6h/DisEYNN/Wx3hiczJyKGaxaG4vTZtiOMsVz7Vhq5T0WuFR3SCmnsSF4gA973m1T8E 9b9vhbwIMmt0MzytXQhHz9c6he3GWhHh74YPy/u9Xe8+GgEWRNzny65mgC1XbN5cFZXR gS1zV8lyMUKCHyPTrBuvYB1qBTiwjeIN7Z82cwv9nAicLjczmW8H4Mjo64komHJBZx+O AEqw== X-Gm-Message-State: AMCzsaU0dvTKPLimg01KqipNxCqfnYTvetmrFY32vZ4Hv2zz0txu20VR pfsKZIlIwpdMLzh1Kot33/PLKjQLxyHSNuj+T0E= X-Google-Smtp-Source: AOwi7QBRInIBEGRx/42YVwc6Ighx3oc13kYdrdtTvg4TtyHxYQB9DgOWl3bER/7Nr/4b36juDwIEvCe+HPAt38MmNs0= X-Received: by 10.28.111.203 with SMTP id c72mr4685860wmi.42.1507385869073; Sat, 07 Oct 2017 07:17:49 -0700 (PDT) MIME-Version: 1.0 References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> In-Reply-To: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> From: Nick Sullivan Date: Sat, 07 Oct 2017 14:17:37 +0000 Message-ID: To: Rich Salz , Yoav Nir Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114779fa44016a055af59fb0" Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 14:17:53 -0000 --001a114779fa44016a055af59fb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yoav, Let me make a correction to your scenario:. Instead of: "You=E2=80=99ll need it for Chrome to work with Google." it's: "You=E2=80=99ll need it for Chrome to work with Google, Facebook, and most = of the 10% of Alexa top million sites that are using Cloudflare." TLS 1.3 (in on draft version or another) is very widely deployed on the server side. Enabling it by default in a major browser would break enough of the Internet that both middlebox vendors and enterprises/ISP who use them will take notice. The browser vendors will have to do their own calculus around whether or not the ecosystem benefits of accelerating the deployment of TLS 1.3 compatibility by deploying no-downgrade TLS 1.3 defaults outweigh the business costs associated with the potential harm to their relationships with enterprises. For example, Chrome has a history of making large bets that break a portion of the internet in order to force ecosystem changes (see SHA-1, SSLv3). However, these have been projects with gradual changes and long lead times. Also, the failure rates introduced by such changes were well below 2% of all connections. Furthermore, these changes typically revolved around server changes (updating certs, changing configurations) not software/firmware updates to devices. I don't want to speak for browser vendors, but history suggests that Option 3) may not be a viable one for browsers with a significant market share. Nick On Sat, Oct 7, 2017 at 1:33 PM Yoav Nir wrote: > On 7 Oct 2017, at 4:01, Salz, Rich wrote: > > Thanks very much for the update. > > There is a third option, name the devices which are known to cause > problems, and move forward with the draft as-is. > > > +1. I like this third option. > > 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh, > it's your customers who don't update? Seems you don't have any > reasonable update system. Call your customers, > > > Vendor: Hello customer. We have an update for you that will make TLS 1.3 > work. > > Customer: No way. We=E2=80=99re in the middle of the year-end processing.= We=E2=80=99re > not making any configuration changes until the second week of January. > > Vendor: But it=E2=80=99s a simple fix. It will make things work better. Y= ou=E2=80=99ll > need it for Chrome to work with Google. > > Customer: What part of =E2=80=9Cnot making any configuration changes=E2= =80=9D was not > clear to you!? > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114779fa44016a055af59fb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yoav,

Let me make a correction to y= our scenario:. Instead of:
"You=E2=80=99ll need it fo= r Chrome to work with Google."
it's:=
"You=E2=80=99ll need it for Chrome= to work with Google, Facebook, and most of the 10% of Alexa top million si= tes that are using Cloudflare."

TLS 1.3 (in on draft version or another) is very widely= deployed on the server side. Enabling it by default in a major browser wou= ld break enough of the Internet that both middlebox vendors and enterprises= /ISP who use them will take notice.

The browser vendors will have to do their own calculus around w= hether or not the ecosystem benefits of accelerating the deployment of TLS = 1.3 compatibility by deploying no-downgrade TLS 1.3 defaults outweigh the b= usiness costs associated with the potential harm to their relationships wit= h enterprises.

For examp= le, Chrome has a history of making large bets that break a portion of the i= nternet in order to force ecosystem changes (see SHA-1, SSLv3). However, th= ese have been projects with gradual changes and long lead times. Also, the = failure rates introduced by such changes were well below 2% of all connecti= ons. Furthermore, these changes typically revolved around server changes (u= pdating certs, changing configurations) not software/firmware updates to de= vices.

I don't want = to speak for browser vendors, but history suggests that Option 3) may not b= e a viable one for browsers with a significant market share.

Nick

On S= at, Oct 7, 2017 at 1:33 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
On 7 Oct 2017, at 4:01, Salz, Rich <rsalz@akamai.com> wrote:

Thanks very muc= h for the update.
=C2=A0
There is a third option, name the devices which are known to cause = problems, and move forward with the draft as-is.

+1.= =C2=A0 I like this third option.

2. Tell all those vendor= s "You have 1 month to fix this. Fix it. Oh,
it's your customer= s who don't update? Seems you don't have any
reasonable update s= ystem. Call your customers,

Vendor: Hello customer. We have an update for = you that will make TLS 1.3 work.

Customer: No way. We=E2= =80=99re in the middle of the year-end processing. We=E2=80=99re not making= any configuration changes until the second week of January.

=
Vendor: But it=E2=80=99s a simple fix. It will make things work = better. You=E2=80=99ll need it for Chrome to work with Google.
Customer: What part of =E2=80=9Cnot making any configuration c= hanges=E2=80=9D was not clear to you!?
_________________________= ______________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a114779fa44016a055af59fb0-- From nobody Sat Oct 7 07:43:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFAA13456D for ; Sat, 7 Oct 2017 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 VakHhriJqAKs for ; Sat, 7 Oct 2017 07:43:20 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 29A121329F9 for ; Sat, 7 Oct 2017 07:43:20 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v97EfVOF018073; Sat, 7 Oct 2017 15:43:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=mXjl2YWYw1DxV3YUXPORNZDb/YGxytCbnNKCtJVvuEg=; b=n90BSVro68pALaq8PWvuvoi45/eIXDmxw7rKhx9AnHvSy1etdWewfBsOF8KsGt4RNI68 7AQSsCvOTlYhERXcQyjwFn9gsBBHCxfWLvO4zDpIgADPMlRUZ1bxhzv7WGmrtpPqdE/S CVFtHfVxtL4Oh5l4gHNb8CvriRF8PhRoxPbMgtnIRWC8utA2VXS/ZO/MGA22Rh2DcidB WRhV7qF81RcHo40j5ZFghImtsbG3AsvE+WwQp3B7DbLfusd7V9g14CR7rqTZ3pbVshjw VcuX+zTOGRPy6NZUoDAs06gP0e0MQSoS/zf7+FnNml8tXSPXRRgBTWcBZFLtzmggZ2GN nQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2depye1bka-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Oct 2017 15:43:15 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v97EfUZl028883; Sat, 7 Oct 2017 10:43:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2det8vgrwr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 07 Oct 2017 10:43:14 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 7 Oct 2017 09:43:14 -0500 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.1263.000; Sat, 7 Oct 2017 09:43:14 -0500 From: "Salz, Rich" To: Nick Sullivan , Yoav Nir CC: "tls@ietf.org" Thread-Topic: [TLS] Update on TLS 1.3 Middlebox Issues Thread-Index: AQHTPuAhbOGtBHBWK0qNw6DkAAvXEKLX5dCAgACwfICAAC3SgIAABykA Date: Sat, 7 Oct 2017 14:43:13 +0000 Message-ID: References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.89] Content-Type: text/plain; charset="utf-8" Content-ID: <41BABA93E98B9E4FA8D02F7DA57FBD00@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-07_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710070207 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-07_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710070207 Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 14:43:21 -0000 DQrinqIgSSBkb24ndCB3YW50IHRvIHNwZWFrIGZvciBicm93c2VyIHZlbmRvcnMsIGJ1dCBoaXN0 b3J5IHN1Z2dlc3RzIHRoYXQgT3B0aW9uIDMpIG1heSBub3QgYmUgYSB2aWFibGUgb25lIGZvciBi cm93c2VycyB3aXRoIGEgc2lnbmlmaWNhbnQgbWFya2V0IHNoYXJlLg0KDQpUaGV5IGNhbiBkbyB3 aGF0IHRoZXkgd2FudCwgYnV0IGlmIHRoZXnigJlyZSDigJxpbiB0aGUgcm91Z2jigJ0gb24gdGhl IGNvbnNlbnN1cyBjYWxsLCBJIGhvcGUgdGhleeKAmWxsIGdvIGFsb25nLg0KDQpBcyBmb3IgeW9h duKAmXMgcG9pbnQgYWJvdXQg4oCcbm90IGR1cmluZyBRNOKAnSBmcmVlemU7IHRoYXQgaGFwcGVu cyB0byBib3RoIGNsaWVudHMgYW5kIHNlcnZlcnMgOikNCg0KSSBhc2sgdGhhdCBldmVyeW9uZSB3 aG8gaXMgaW52b2x2ZWQgaW4gdGhlc2Ug4oCcbWlkZGxlYm94IGZhaWx1cmUgZXhwZXJpbWVudHMs 4oCdIGNvbGxlY3RpdmVseSBvciBpbmRpdmlkdWFsbHksIHdvcmsgb24gYSBwcmVzZW50YXRpb24g Zm9yIFNpbmdhcG9yZS4gIFVubGVzcyB0aGVyZSBhcmUgc29tZSBiaWcgc3VycHJpc2VzLCBJIGFt IGdvaW5nIHRvIGFzayBmb3IgYSBjb25zZW5zdXMgY2FsbCBvbiBqdXN0IG1vdmluZyBpdCBmb3J3 YXJkLg0KDQoNCg0KDQo= From nobody Sat Oct 7 07:44:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67337133039 for ; Sat, 7 Oct 2017 07:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl4ebaqg6rKn for ; Sat, 7 Oct 2017 07:44:25 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91F61329F9 for ; Sat, 7 Oct 2017 07:44:24 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id q190so10936546vkd.13 for ; Sat, 07 Oct 2017 07:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nFGcXsX33FBhxCGvCcv1E7MDHPRttBYc+DwhJNWTKsI=; b=IuP5/oAnhF64O1UNx4Fyjy5WtGPQadK5F0P02RpABOtqse5NERk4XwgZOv0/DOskFp DSLBaW3PjTk9N9pN99BuXq/qxPx5JRrg3DCQ2Pjob+y3WFTfsOO3Qu8wUaR1lS7XZz4m jc/GZ7Sa9u/v/a3p/tPCgrxIFl5cUhTr3rV45/tsurUoxUTcB4602runG7uuoXO89o3f 5FhnCXEQ73EoyPiRKdu41+unVOaVTARpPmjQELfBsCBdenf4tcixmdZhfSfylh/pYQXj +LB4duPT0vLrp/kBWRpqw6yj2NcX0I1bUg430fd4+BZIpKVSZr+TvZUh0cWKvX/n0sed wARQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nFGcXsX33FBhxCGvCcv1E7MDHPRttBYc+DwhJNWTKsI=; b=uQrbRETFu1hXQhZMxhy28e9fNy2zfoqwHJXVpxW4ffJfb1NsZCMvH+1EV19i1C/BhW SRNU5ectYgSAR2OOZEu4hW1CD/pNRyI/iRB+VrtujpD8rLGNZypP25xzPuW+edCT9TlH YxVvHga0D5ImIXbn8R1RdXz8cFjToS2rTFgf4s4zQwowvpDMvxz0nYxnmIfJal19iya6 dS0Dw3YkbGPju+6PtF2dgNQnPNk2y+lcaET329Ngc745dMp9q6rW8xHnrFaW+wwGXTkJ ai3BrwFyEOzw0K4vV7J6RgelEnhtf3VKGh9q+/PaULPRnlUITkA+IgqwhWpzZwbokgLM GoAQ== X-Gm-Message-State: AMCzsaXPKUXr1mGiKWwyC8M7L4//bTPY3Zcx9s/PMmBYpX45mJ1n+lpP igE8jx9gU+yV9tuTL3N6hlKcsN30NE1XC3J9cms= X-Google-Smtp-Source: AOwi7QAFtFX8NMZXfDzC2z0Uc/ETrny2br5OBW4Hp90RDm5t7ceY9SpDx4VvKXsEzaxzPsMD12dikb66fII7YAIklMo= X-Received: by 10.31.8.77 with SMTP id 74mr2464970vki.25.1507387463870; Sat, 07 Oct 2017 07:44:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.48.129 with HTTP; Sat, 7 Oct 2017 07:44:23 -0700 (PDT) In-Reply-To: References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> From: Watson Ladd Date: Sat, 7 Oct 2017 07:44:23 -0700 Message-ID: To: Nick Sullivan Cc: Rich Salz , Yoav Nir , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 14:44:26 -0000 On Sat, Oct 7, 2017 at 7:17 AM, Nick Sullivan wrote: > Yoav, > > Let me make a correction to your scenario:. Instead of: > "You=E2=80=99ll need it for Chrome to work with Google." > it's: > "You=E2=80=99ll need it for Chrome to work with Google, Facebook, and mos= t of the > 10% of Alexa top million sites that are using Cloudflare." Personally, if we can make the final version work better with a few minor changes to negotiation we should, even if that means dropping the version negotiation mechanism and using extensions instead. If we end up needing more flights, that's going to be sad and we'll just have to wait for QUIC. Sincerely, Watson Ladd From nobody Sat Oct 7 07:57:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62927134292 for ; Sat, 7 Oct 2017 07:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZvd7to-Zlat for ; Sat, 7 Oct 2017 07:57:19 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7891321F5 for ; Sat, 7 Oct 2017 07:57:18 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id m72so5942485wmc.0 for ; Sat, 07 Oct 2017 07:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h0wfIaGzqLvRg6adU9Ud5T0hDcqwBmfZk5/V817eZZg=; b=z1KWnjmL+sxjR2aE5ejFutof6SQynp6lh09mcd/OqNmCl0tFZ7BPkCTN0se92qpOnO 8qkYMh14smNOdYhuScuEkLqSrclu5WbTa29Ne9c1Fw1yRuZ06V2e5c79D50edFXQ7HM1 +BNcoOdwhmD+qoqbGCE/Rlaf+OJ4/nsBn52TSVnsZ/R7oavnORbtwSyy8vMKfERoB+hl +W5lyGEE4i46k0qmBsVGNPsY6mM38HC3+12S4bSTq+wo8axxFsDIviqV962bb95aBvVv hNc1F3JiHyTF73ZuKvtWgQp2Ga0vWGmvdHSyOmVk+YcwT8kFAT/wQMymermLuHILTIuP O+Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h0wfIaGzqLvRg6adU9Ud5T0hDcqwBmfZk5/V817eZZg=; b=XCEUas+exWVGOttF3Ze9KPhQnUbamm1T8WyBmg8gP2LI8v+c52jwykUXFhETfYPf96 fwJXZT0kk/PhPq4iKjY14AwMWep+RsDVWRRlqa7D9NPIODgKcTxUKo+jkDExeXzEJBvd cf3SjVTSdZmP5qxS9k/d5mfCcMMFOOJlhSt2Yb6D4qT6D/VK02IZPWDhCQ80PI6YqyHo l+4sPIsmZFO16s9iHLkJ80Mj1MgRzpgwwz7yjs7uElWcKDmNvDQx2HBb54So9tA77TdI 5o4Hj0HJNYKl2X5RyU6/Qc1rPep95gmPAUOTpUWZhqY/ucgPolNxR2HfcOCLR1fr6oAH opDA== X-Gm-Message-State: AMCzsaVi49Axa9rmVD79AXpOZb2cL+8zYfJoPxPRf4jngh/0kdXXx24b QvX8rg9tAUv5nIhoI/rcvP40kWEwnSShJffFSFe30A== X-Google-Smtp-Source: AOwi7QD4GGH8r1mBbYgDDY1E3yOjkKqfAgftolAtxZGX7JfTEMqCYB0bbyBfwJtjx6foSVjn82XzSAc2sXDiAU0gfSw= X-Received: by 10.28.21.10 with SMTP id 10mr1822626wmv.41.1507388236977; Sat, 07 Oct 2017 07:57:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.210 with HTTP; Sat, 7 Oct 2017 07:57:15 -0700 (PDT) Received: by 10.28.184.210 with HTTP; Sat, 7 Oct 2017 07:57:15 -0700 (PDT) In-Reply-To: References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> From: Richard Barnes Date: Sat, 7 Oct 2017 10:57:15 -0400 Message-ID: To: "Salz, Rich" Cc: "" , Nick Sullivan , Yoav Nir Content-Type: multipart/alternative; boundary="001a1145a932676e7e055af62c80" Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 14:57:20 -0000 --001a1145a932676e7e055af62c80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Oct 7, 2017 10:43, "Salz, Rich" wrote: =E2=9E=A2 I don't want to speak for browser vendors, but history suggests t= hat Option 3) may not be a viable one for browsers with a significant market share. They can do what they want, but if they=E2=80=99re =E2=80=9Cin the rough=E2= =80=9D on the consensus call, I hope they=E2=80=99ll go along. Rich, I think you may be forgetting that IETF standards are voluntary. They may be in the rough with regard to Publishing an RFC, but if they can't ship that RFC, they won't, and publishing an RFC that can't be shipped doesn't do much good. Better to take the time to figure out how to make this deployable (with a blend of 1/2 and 3). We're still a decade ahead of the 1.2 roll out timeline. --Richard As for yoav=E2=80=99s point about =E2=80=9Cnot during Q4=E2=80=9D freeze; t= hat happens to both clients and servers :) I ask that everyone who is involved in these =E2=80=9Cmiddlebox failure experiments,=E2=80=9D collectively or individually, work on a presentation = for Singapore. Unless there are some big surprises, I am going to ask for a consensus call on just moving it forward. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --001a1145a932676e7e055af62c80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Oct 7, 2017 10:43, "Salz, Rich" <rsalz@akamai.com> wrote:

=E2=9E=A2 I don't want to speak for browser vendors, but history sugges= ts that Option 3) may not be a viable one for browsers with a significant m= arket share.

They can do what they want, but if they=E2=80=99re =E2=80=9Cin the rough=E2= =80=9D on the consensus call, I hope they=E2=80=99ll go along.

Rich, I= think you may be forgetting that IETF standards are voluntary.=C2=A0 They = may be in the rough with regard to Publishing an RFC, but if they can't= ship that RFC, they won't, and publishing an RFC that can't be shi= pped doesn't do much good.=C2=A0

Better to take the time to figure out how to make this deploya= ble (with a blend of 1/2 and 3).=C2=A0 =C2=A0We're still a decade ahead= of the 1.2 roll out timeline.=C2=A0

--Richard

<= div class=3D"gmail_extra">

As for yoav=E2=80=99s point about =E2=80=9Cnot during Q4=E2=80=9D freeze; t= hat happens to both clients and servers :)

I ask that everyone who is involved in these =E2=80=9Cmiddlebox failure exp= eriments,=E2=80=9D collectively or individually, work on a presentation for= Singapore.=C2=A0 Unless there are some big surprises, I am going to ask fo= r a consensus call on just moving it forward.




_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1145a932676e7e055af62c80-- From nobody Sat Oct 7 08:02:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74691321F5 for ; Sat, 7 Oct 2017 08:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9TWuRyP2Dvk for ; Sat, 7 Oct 2017 08:02:15 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 2FDA4132355 for ; Sat, 7 Oct 2017 08:02:15 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id i13so36307333qtc.11 for ; Sat, 07 Oct 2017 08:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yCgp5KJ3kRrF515bAwpe5Y4JqYFPlxhacCYjxSsWgG8=; b=HL/3iSu32TH9+br37ZIQy212vgpViM8TSuI1asTJzpmWD/nQIFHiaa5ZUn99O9xwfo gSBle/U1L9BgYG1AB+OTKrb6FXXDuFI31TZu+aXg2y3R2ImYe/QZfUwGDQ/qbiTVgzxk NU6wJ9reJpnmDVkKpmVsjwi98P4TjOmpQTcvZqO0njFiKNPm4yLT9ue/JqChm192ppDx JGOicHcCLaTf1Qf95dUrh9rSMMw+RWE2nYwegKnItNxZIozcmPlQRss8KbmtmOXaHW1A FV9brzBaMwHndnn5SgnmQuSMdlk5z905paqOLTzFmqIbGIgnkYfTyLxLUf8+ZzHPxxr5 1pFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yCgp5KJ3kRrF515bAwpe5Y4JqYFPlxhacCYjxSsWgG8=; b=MSp1kilvV8hLGy8Xd/aA/TKtcMUlemL5zEGOMQ5fj7lhGosNHn8PILDJd4j2aOY2Mp FZ9oakDq/cxkXZ9ciaR4gy/Or77gAPim2wqt3FJR6YaKZ2MF79p+4pfbFBc/R/7hHE3I g2W+xD+yYRQtoIs+wK1lL2hIuGoUv9QflADdpnanHKJ7/sWNdsfELU2kqSQbUVJ6ygzN BUln498CQQ3Ug13zgcLlHHmF8Lnn/tl4thFEZN0+FTRH7neTEt/xxlXoSOyDgvxRC1mc O08kIZndwfjZrejolX88eN6YYo9YrpvZN5M9yGbwT7DP44HQclQFNfSH7TacDC5aKFgG IVCg== X-Gm-Message-State: AMCzsaWgHan2aVwR48ivb3ug0ePrzxQptRawQ7p7wjlmWEOEWi8qLi9n 8D/Aixj7aalCScxy/OQKn83OaTIV9aIHy7Sn3d5OmA== X-Google-Smtp-Source: AOwi7QBLHqO0a47NpQZo5MOtFdBjj1ffav5RsIdMlRqmfMsEdUYfw/loVrKJ8hSMIMKG4xUVz0IxRTLyzlk2NCWZ2kU= X-Received: by 10.37.45.110 with SMTP id s46mr4200537ybe.400.1507388534334; Sat, 07 Oct 2017 08:02:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sat, 7 Oct 2017 08:01:33 -0700 (PDT) In-Reply-To: References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> From: Eric Rescorla Date: Sat, 7 Oct 2017 08:01:33 -0700 Message-ID: To: Watson Ladd Cc: Nick Sullivan , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f4030435adec20ba86055af63e20" Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:02:17 -0000 --f4030435adec20ba86055af63e20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 7, 2017 at 7:44 AM, Watson Ladd wrote: > On Sat, Oct 7, 2017 at 7:17 AM, Nick Sullivan > wrote: > > Yoav, > > > > Let me make a correction to your scenario:. Instead of: > > "You=E2=80=99ll need it for Chrome to work with Google." > > it's: > > "You=E2=80=99ll need it for Chrome to work with Google, Facebook, and m= ost of the > > 10% of Alexa top million sites that are using Cloudflare." > > Personally, if we can make the final version work better with a few > minor changes to negotiation we should, even if that means dropping > the version negotiation mechanism and using extensions instead. If we > end up needing more flights, that's going to be sad and we'll just > have to wait for QUIC. > None of the changes anyone is contemplating involve more flights. -Ekr > > Sincerely, > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f4030435adec20ba86055af63e20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 7, 2017 at 7:44 AM, Watson Ladd <watsonbladd@gmail.com= > wrote:
O= n Sat, Oct 7, 2017 at 7:17 AM, Nick Sullivan
<nicholas.sullivan@gmail.= com> wrote:
> Yoav,
>
> Let me make a correction to your scenario:. Instead of:
> "You=E2=80=99ll need it for Chrome to work with Google."
> it's:
> "You=E2=80=99ll need it for Chrome to work with Google, Facebook,= and most of the
> 10% of Alexa top million sites that are using Cloudflare."

Personally, if we can make the final version work better with a few<= br> minor changes to negotiation we should, even if that means dropping
the version negotiation mechanism and using extensions instead. If we
end up needing more flights, that's going to be sad and we'll just<= br> have to wait for QUIC.

None of the chan= ges anyone is contemplating involve more flights.

= -Ekr
=C2=A0

Sincerely,
Watson Ladd

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--f4030435adec20ba86055af63e20-- From nobody Sat Oct 7 08:03:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46D91345FC for ; Sat, 7 Oct 2017 08:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT2lU_CIFq9U for ; Sat, 7 Oct 2017 08:03:09 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 B8AE7132355 for ; Sat, 7 Oct 2017 08:03:09 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 6so27210508qtw.3 for ; Sat, 07 Oct 2017 08:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s/OedvQ5ZfcFWXJFgmbh9zJx+KspJc8b01Iu6qqOJO4=; b=bIxsM1cngZRKYy7MpGrqvg6UYksbBpZ/ZSo45qswTsrRNsBMXCPEU/1uz6vNImU6oa KbVU3SqCkIu31rJ3+/pshZHjuEtlITnW8xoQ/rPwNS+zZJYMSTL5eHIGnDk8QtBXCopU T00vaNelwrdCkcep83zF65myBEUtb5oHQAQfEDLE7WdzN5VGVaPHBvfH9jQXQhkRHgxy BRqnPeixJb1K1yLkNayVoPrXAl+LGM8hFE4gWqzASPgM9yaicZT5iEK3Bc8zMVmvQ/yi 2futJEzqxLI0OWizihVU9zShVsVpXCYOJfShoANwhPZ3SGv2WZ6vGfyCloxC0nw5VQIA tPNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s/OedvQ5ZfcFWXJFgmbh9zJx+KspJc8b01Iu6qqOJO4=; b=PU4msIDxURz0J9XgBjD4M42uHIdlIG91x0U5ao9hCDeGibKQn2evGOtP4HBdw2gLNL jkUiINSSLi0HVOoV+Vb/+9rzURmoo/+UeAzsHaFkfqYINtpbWgcALCswLDHt3qNBVp/K 0ES74BLQNlvgLZUooKpqQi2e6aIPXMym6WbhTyOPsYuxKSo5RM/NaLmVsqMfpUeBFf15 +Jqo/pitw2kvYcWuu+6YTAzKfbN9mhmO8EqG6h310MFCN5T6GiIn2ycay7U9yXnVDExB oqKiPnS69ErF835RcF1D/tvYuvx7Ge3QNI5OaRNC4LgvohseAUKsJeVnStfmyExw6gDm ZAFw== X-Gm-Message-State: AMCzsaXISoBi3gtLOdV8m9VAGiQaeFZUodqKHTDFkjjArrYy5A2PW6Wa 0GUgQBuXykN11Yx6IEFcDN4tf8HO7F5aR1WTT9itmho/ X-Google-Smtp-Source: AOwi7QC5aKQPrsMWvtPeXeOnGmw0mc2Ej+LVKXMt7LWip+k4LZ4rCq93DT0XvADOtJjmPqEFlZvRPtEpRNXwHBbPsTs= X-Received: by 10.129.232.4 with SMTP id a4mr4324388ywm.294.1507388588928; Sat, 07 Oct 2017 08:03:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sat, 7 Oct 2017 08:02:28 -0700 (PDT) In-Reply-To: References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> From: Eric Rescorla Date: Sat, 7 Oct 2017 08:02:28 -0700 Message-ID: To: Richard Barnes Cc: "Salz, Rich" , "" Content-Type: multipart/alternative; boundary="089e082230a461c34f055af6411c" Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:03:12 -0000 --089e082230a461c34f055af6411c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I suggest we not have this debate now. We'll have a lot more data towards the end of the month and we can have an informed discussion then. -Ekr On Sat, Oct 7, 2017 at 7:57 AM, Richard Barnes wrote: > > > On Oct 7, 2017 10:43, "Salz, Rich" wrote: > > > =E2=9E=A2 I don't want to speak for browser vendors, but history suggests= that > Option 3) may not be a viable one for browsers with a significant market > share. > > They can do what they want, but if they=E2=80=99re =E2=80=9Cin the rough= =E2=80=9D on the consensus > call, I hope they=E2=80=99ll go along. > > > Rich, I think you may be forgetting that IETF standards are voluntary. > They may be in the rough with regard to Publishing an RFC, but if they > can't ship that RFC, they won't, and publishing an RFC that can't be > shipped doesn't do much good. > > Better to take the time to figure out how to make this deployable (with a > blend of 1/2 and 3). We're still a decade ahead of the 1.2 roll out > timeline. > > --Richard > > > As for yoav=E2=80=99s point about =E2=80=9Cnot during Q4=E2=80=9D freeze;= that happens to both > clients and servers :) > > I ask that everyone who is involved in these =E2=80=9Cmiddlebox failure > experiments,=E2=80=9D collectively or individually, work on a presentatio= n for > Singapore. Unless there are some big surprises, I am going to ask for a > consensus call on just moving it forward. > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e082230a461c34f055af6411c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I suggest we not have this debate now. We'll have a lo= t more data towards the end of the month and we can have an informed discus= sion then.

-Ekr


On Sat, Oct 7, 2017 at 7:57 AM,= Richard Barnes <rlb@ipv.sx> wrote:

=
On Oct 7, 2017 10:43, "Salz, Rich"= <rsalz@akamai.com= > wrote:

=E2=9E=A2 I don't want to speak for browser vendors, but history sugges= ts that Option 3) may not be a viable one for browsers with a significant m= arket share.

They can do what they want, but if they=E2=80=99re =E2=80=9Cin the rough=E2= =80=9D on the consensus call, I hope they=E2=80=99ll go along.

= Rich, I think you may be forgetting that IETF standards are voluntary.=C2= =A0 They may be in the rough with regard to Publishing an RFC, but if they = can't ship that RFC, they won't, and publishing an RFC that can'= ;t be shipped doesn't do much good.=C2=A0

Better to take the time to figure out how to make thi= s deployable (with a blend of 1/2 and 3).=C2=A0 =C2=A0We're still a dec= ade ahead of the 1.2 roll out timeline.=C2=A0
<= font color=3D"#888888">

--Rich= ard


As for yoav=E2=80=99s point about =E2=80=9Cnot during Q4=E2=80=9D freeze; t= hat happens to both clients and servers :)

I ask that everyone who is involved in these =E2=80=9Cmiddlebox failure exp= eriments,=E2=80=9D collectively or individually, work on a presentation for= Singapore.=C2=A0 Unless there are some big surprises, I am going to ask fo= r a consensus call on just moving it forward.




_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--089e082230a461c34f055af6411c-- From nobody Sat Oct 7 08:25:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C762132355 for ; Sat, 7 Oct 2017 08:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Nio-DfCqNF51 for ; Sat, 7 Oct 2017 08:25:34 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 ED59413209C for ; Sat, 7 Oct 2017 08:25:33 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v97FM1TI013636; Sat, 7 Oct 2017 16:25:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=lGpPHbufuo0rMNvY9Z6NkQmz2IlPSzCi/aHjM3Qd23U=; b=GxGj91YC4rvKcL6gACvhHBI5LJTLb6l9qbr8zUue0pEdmP0LEmLNQ8glypr3CjgKkyo2 vXPYL3sJWi1KfkO7hk9yoM33Scz0a/cAvDqnDrsTN8T1QWYAfRhEs+g2FRYfd10pRmHC r9fFw0JXMipkjqvodPYEN3APuNq2TxNiH86a/UsIXkcirJqqZWR6Qk/hbZaI4ctwY6uE CWzgVEmE5ptxIOR/so+jk3V78AnsmTItmAzIjS3LqOMnOwDMJ+ms3fmq0xnZml3PVB68 ktUdpy/HKx2Wm3qGwyb36ojMooaSbnHrHzIoea6DcCKyLCpY5Xc5Ffijj1BTmSTX6NDO zw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2depye1e2d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Oct 2017 16:25:31 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v97FKZlx028505; Sat, 7 Oct 2017 11:25:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2det8vgup5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 07 Oct 2017 11:25:30 -0400 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.1263.5; Sat, 7 Oct 2017 10:25:29 -0500 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.1263.000; Sat, 7 Oct 2017 10:25:30 -0500 From: "Salz, Rich" To: Eric Rescorla , Richard Barnes CC: "" Thread-Topic: [TLS] Update on TLS 1.3 Middlebox Issues Thread-Index: AQHTPuAhbOGtBHBWK0qNw6DkAAvXEKLX5dCAgACwfICAAC3SgIAABykAgAAD6oCAAAF1AIAABnAA Date: Sat, 7 Oct 2017 15:25:29 +0000 Message-ID: References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.89] Content-Type: multipart/alternative; boundary="_000_C7396C839F024BF8B4904EA8DB9798B1akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710070217 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710070217 Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:25:35 -0000 --_000_C7396C839F024BF8B4904EA8DB9798B1akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+IEkgc3VnZ2VzdCB3ZSBub3QgaGF2ZSB0aGlzIGRlYmF0ZSBub3cuIFdlJ2xsIGhhdmUgYSBs b3QgbW9yZSBkYXRhIHRvd2FyZHMgdGhlIGVuZCBvZiB0aGUgbW9udGggYW5kIHdlIGNhbiBoYXZl IGFuIGluZm9ybWVkIGRpc2N1c3Npb24gdGhlbi4NCg0KDQpUaGF0IGlzIHdoYXQgSSBhbSBhc2tp bmcgZm9yLiAgTW9yZSBpbmZvcm1hdGlvbiBzbyB0aGF0IHRoZSBlbnRpcmUgV0cgY2FuIG1ha2Ug YW4gaW5mb3JtZWQgZGVjaXNpb24uICBBbmQgSSB3YXMgb25seSBsYXlpbmcgb3V0IGFuIG9wdGlv biB0aGF0IGRvZXMgbm90IHNlZW0gdG8gaGF2ZSBiZWVuIGNvbnNpZGVyZWQgYmVmb3JlLg0K --_000_C7396C839F024BF8B4904EA8DB9798B1akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyBJIHN1Z2dlc3Qgd2Ugbm90IGhhdmUgdGhpcyBkZWJhdGUgbm93LiBXZSds bCBoYXZlIGEgbG90IG1vcmUgZGF0YSB0b3dhcmRzIHRoZSBlbmQgb2YgdGhlIG1vbnRoIGFuZCB3 ZSBjYW4gaGF2ZSBhbiBpbmZvcm1lZCBkaXNjdXNzaW9uIHRoZW4uDQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIHdoYXQgSSBhbSBhc2tpbmcgZm9yLiZu YnNwOyBNb3JlIGluZm9ybWF0aW9uIHNvIHRoYXQgdGhlIGVudGlyZSBXRyBjYW4gbWFrZSBhbiBp bmZvcm1lZCBkZWNpc2lvbi4mbmJzcDsgQW5kIEkgd2FzIG9ubHkgbGF5aW5nIG91dCBhbiBvcHRp b24gdGhhdCBkb2VzIG5vdCBzZWVtIHRvIGhhdmUgYmVlbiBjb25zaWRlcmVkIGJlZm9yZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C7396C839F024BF8B4904EA8DB9798B1akamaicom_-- From nobody Sat Oct 7 08:33:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF163134931 for ; Sat, 7 Oct 2017 08:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 vO-nz3esNis2 for ; Sat, 7 Oct 2017 08:33:35 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BEC13492C for ; Sat, 7 Oct 2017 08:33:34 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id f3so33795575oia.2 for ; Sat, 07 Oct 2017 08:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6ORM95akjaCNEWSJn9aCNCZYK2e+3Hg1Rer/5rziWl8=; b=Xi92fwpNCdXLOYksc6swD4+H40Ax5wjtFI1nB2Xfxe0ciCJ1mZVc+ZYYtnvCVcree8 LcqzUUfhlIDzFjbG8zNtBYGDg447kc7RwbWy4EVezqX6KpM9oUu9j8hlVPYrIH5qQ1AN FQP5xXIFdel2Bw7mPrhbEQd02PKPvfli+dbVLaIfGMTJIBx27xz63SZ5ZUfxEikhvjX0 wWs+kALdXU0cxq4s5etjpFRRQAXRD49rViUwS+C+jwvYjbZh1rjSNgl96nE/TsZ+7oSy Ruo8BN0DftAg/ii0is7eoRaqYj6RWpGV+IU3Ak2b47lUm/FTup6AP0k4Q5kObKU6j1E8 q8vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=6ORM95akjaCNEWSJn9aCNCZYK2e+3Hg1Rer/5rziWl8=; b=C7BkBPF/PTLR4ZMENp7bIVACtggHRnqq8HmG8ETv/VnNRPpCmYTQVyJhgBgSUmlrmT l0S/+3nTZ4W6IXdzNeBIQqQNAGYdNofBlSUFPPPvMZ6IM0JincrFJemqB6B9L2wGhT1x pmGNd8iI4QYgWLsBWPCz53BpbCxOGcNwP8kh9SddfcRRGcdQF2svm4Jumj4dQRKGYuOY 2Z0UJovM6Ooy2vf4S8A1oo2JNe1vXVmlhz3C5lLbYj2ey9hQVB2r//38fPv3vkHNUOPQ PZqatFXXkJyvSthZNQW6CqTjwFHJ6fXJo3G5+d1NM3MX1vcDD5o70acXVKYx63rfdGvY hdOw== X-Gm-Message-State: AMCzsaXYlb9Nr8bii/bau6TfwRF7ZFp+nmNt/jHzaoEHVqXPrr0+lINJ i/fo8wim4Vh6l2FRYiSfpl8kZM7IX8qBYsk83RU= X-Google-Smtp-Source: AOwi7QB0Q4J5pVbglpUbEX9Y2Tirt4TUNXWutsbai0PKDEFP00tzDgyhA0Vg7LMXhCWmC+TvQo8d2ldYGCqkAVr7Mw8= X-Received: by 10.202.71.151 with SMTP id u145mr2623690oia.133.1507390414352; Sat, 07 Oct 2017 08:33:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.19.199 with HTTP; Sat, 7 Oct 2017 08:33:33 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> From: Jeffrey Walton Date: Sat, 7 Oct 2017 11:33:33 -0400 Message-ID: To: "Salz, Rich" Cc: Eric Rescorla , Richard Barnes , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:33:37 -0000 On Sat, Oct 7, 2017 at 11:25 AM, Salz, Rich wrote: > > >> I suggest we not have this debate now. We'll have a lot more data towards >> the end of the month and we can have an informed discussion then. > > That is what I am asking for. More information so that the entire WG can > make an informed decision. And I was only laying out an option that does > not seem to have been considered before. The group (or the IETF) might also consider a policy to answer Ilari Liusvaara's question, "What you think is acceptable failure rate?" That is a governance issue. It should probably be [nearly] written in stone and applied equally to all problems and decisions. As an example, the US's IRS used to have a policy to support any browser with 3% market share or more. I don't know what it is nowadays. Jeff From nobody Sat Oct 7 08:35:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43D613457D for ; Sat, 7 Oct 2017 08:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddjPqnLogcPZ for ; Sat, 7 Oct 2017 08:35:50 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09D213490F for ; Sat, 7 Oct 2017 08:35:50 -0700 (PDT) Received: from pc1 ([::ffff:82.214.239.4]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 07 Oct 2017 17:35:47 +0200 id 0000000000000033.0000000059D8F454.00006B01 Date: Sat, 7 Oct 2017 17:35:30 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20171007173530.34cfc216@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:35:53 -0000 Hi, On Fri, 6 Oct 2017 13:16:37 -0700 Eric Rescorla wrote: > - Fall back to TLS 1.2 (as we have unfortunately done for previous > releases) Thinking about this I honestly hope nobody is considering this seriously. This would be an unfixable security design flaw. And it also quite significantly differs from previous fallbacks. There were workarounds in the past for version intolerance by using SCSV and early versions of 1.3 used some trick with the server random value. However that was for nonconformant servers that allowed conformant servers and clients to prevent downgrade attacks. Such workarounds won't work if we talk about middleboxes, because what's proposed here is to fallback to TLS 1.2 even if both the server and the client speak TLS 1.3. In other words: It's a proposal to make all security advantages of TLS 1.3 irrelevant, as we have a universal downgrade to 1.2. Given that this would also mean there's no visible incentive to fix things it would very likely mean keeping this broken workaround for many years to come. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Sat Oct 7 08:36:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D97134937 for ; Sat, 7 Oct 2017 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nAhVab9WeHm for ; Sat, 7 Oct 2017 08:36:17 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 CC685134936 for ; Sat, 7 Oct 2017 08:36:16 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id x54so36346831qth.12 for ; Sat, 07 Oct 2017 08:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BBxkyQlyE7YC5Zes330Upyhe5Ljdt4PutpGdS33Ld88=; b=ll65uLfYWUFnEKXGV3HmYVGWY/SqzE23xRwO9Wtbp+9mRd3QM+qaAxW7+MHplEInOp O3En2nPQFhyXhCTOIYqEmQXCAMFWgqgHG6aHmquHWa6bml5TkVEy1zppOrCVP3+7ebhM MM7BXUfWcv9ZOXX14604wvz9fM3PckJ+cV8p9RCnVFdIpGp1/yuTCpX+vDC7gTv/ZySG j/n9/w8ATO4nSjBS0x54q5ZttZH4jhgpRvRHSIEuuZo7L75W1nBf5PE2lUEnE8BPh3Y4 vZAGIT9cHWr4dgl0RD3lVJ7o3M/1eYEmpuC8syH+dB5lGmKTaISPpz22uIk6MOjQFWGT W7qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BBxkyQlyE7YC5Zes330Upyhe5Ljdt4PutpGdS33Ld88=; b=QnGgFWPL3NsGraAcPmKlHN951DUUiZnMOIFErbEJfTwvEAoPanFt5mp+FQhoTtYJv6 x/oFzxiQoh1/rvAYoCQPOlaFa4wgw/0ZQFrlnj5q7u290EnfAcTkaXFLlAMZQDPCxNXS gq0SbiR7eyVDG1HPXHFwUL6DNwHptu7h2ZvCVfHN4yA4WVHT56QZHG87tD12KxT/ziq8 u1mcBUqlDN/LpE9vzEfNKhOZ49cNfooUCjh+0tc9XpahhxGFv+cZ5e5dqXpvsgRnnqpC q7ralemeBBoAfKEKnXNZPnf32IaTXhFLpx7T8uT6qsMMCbqYOJ4U7U4El1kwlki6eNZG JYOg== X-Gm-Message-State: AMCzsaVlcmZSlc0GWLW3VUHKFkbOMy1Uxc3N5aE8af4Axld2LAt9RO7M Ejb9BzvCawBAjVyzdpxEzcdAC2AbVv4UHgexVHLzqg== X-Google-Smtp-Source: AOwi7QC+D3cP/0sq87yEElQMaI30AGaAovgen9CMEio9dsigT1Q+zvdJ8n6Od43xjG8tCuHmYTQwk9sFWBfy0bhGRnE= X-Received: by 10.37.83.66 with SMTP id h63mr470031ybb.397.1507390575967; Sat, 07 Oct 2017 08:36:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sat, 7 Oct 2017 08:35:35 -0700 (PDT) In-Reply-To: References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> From: Eric Rescorla Date: Sat, 7 Oct 2017 08:35:35 -0700 Message-ID: To: "Salz, Rich" Cc: Richard Barnes , "" Content-Type: multipart/alternative; boundary="001a113e688ed191b6055af6b73c" Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:36:18 -0000 --001a113e688ed191b6055af6b73c Content-Type: text/plain; charset="UTF-8" On Sat, Oct 7, 2017 at 8:25 AM, Salz, Rich wrote: > > > > I suggest we not have this debate now. We'll have a lot more data > towards the end of the month and we can have an informed discussion then. > > > > > > That is what I am asking for. More information so that the entire WG can > make an informed decision. > I didn't intend to be arguing with you. I'm happy to present what I have in Singapore and while I can't speak for others, I expect they would be as well. -Ekr > And I was only laying out an option that does not seem to have been > considered before. > --001a113e688ed191b6055af6b73c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 7, 2017 at 8:25 AM, Salz, Rich <rsalz@akamai.com><= /span> wrote:

=C2=A0

> I suggest we not have this debate now. We'l= l have a lot more data towards the end of the month and we can have an info= rmed discussion then.

=C2=A0

=C2=A0

That is what I am asking for.=C2=A0 More information= so that the entire WG can make an informed decision.=C2=A0


I didn't intend to be arguing w= ith you. I'm happy to present what I have in Singapore and while I can&= #39;t speak for others, I expect they would be as well.

-Ekr
=C2=A0

And I was only laying out an option that does not seem to have been = considered before.


--001a113e688ed191b6055af6b73c-- From nobody Sat Oct 7 08:55:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B0613498C for ; Sat, 7 Oct 2017 08:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 SXltP2zxjJAR for ; Sat, 7 Oct 2017 08:55:42 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 A40A1134987 for ; Sat, 7 Oct 2017 08:55:42 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v97FrRwe020935; Sat, 7 Oct 2017 16:55:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ZFF22WU60NNZhZ9Xa10qP0mODZh2zDKqzOyet71xhpw=; b=HVATkxZLmP1/xnXXhJmIkPZvNH8FKipUQFXOXpD5hazSJa4oH+I8Ko15DgjGbLOOv+Dq GjOIqXQfMgJt6qWdL5tQFwciN3O7c9j+edLW6fl8U7c1V8xEsKPygBQ5atE2J4btkRn8 b2/mh4GolpMsxAMNAvayoL48oFOIPgVrfoLF0c6W+j85Tgo5xSY76U/Rc0s9duw2I3yf bcxjri/HlkSXNXK345QoooVVs3YmQFf4N0tSrMe8mqfSKGjuGC17OssXMBY8ygnKr/CE hUkjhXPnBx2TtfhablhZZoAQ2gn75EfvOUUwHHds44DptjUAuBPO9a7y8KW/9HSl1eqE KA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2dep649k0k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Oct 2017 16:55:40 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v97Fp3Ne009521; Sat, 7 Oct 2017 11:55:39 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2det8u0p0x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 07 Oct 2017 11:55:39 -0400 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.1263.5; Sat, 7 Oct 2017 10:55:38 -0500 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.1263.000; Sat, 7 Oct 2017 10:55:38 -0500 From: "Salz, Rich" To: Eric Rescorla CC: Richard Barnes , "" Thread-Topic: [TLS] Update on TLS 1.3 Middlebox Issues Thread-Index: AQHTPuAhbOGtBHBWK0qNw6DkAAvXEKLX5dCAgACwfICAAC3SgIAABykAgAAD6oCAAAF1AIAABnAAgAAC0YCAAAWZgA== Date: Sat, 7 Oct 2017 15:55:37 +0000 Message-ID: <0D3ACAC6-F79F-43B0-BAC1-D910BCF3DE1A@akamai.com> References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.89] Content-Type: multipart/alternative; boundary="_000_0D3ACAC6F79F43B0BAC1D910BCF3DE1Aakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710070223 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710070223 Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:55:44 -0000 --_000_0D3ACAC6F79F43B0BAC1D910BCF3DE1Aakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+IEkgZGlkbid0IGludGVuZCB0byBiZSBhcmd1aW5nIHdpdGggeW91LiBJJ20gaGFwcHkgdG8g cHJlc2VudCB3aGF0IEkgaGF2ZSBpbiBTaW5nYXBvcmUgYW5kIHdoaWxlIEkgY2FuJ3Qgc3BlYWsg Zm9yIG90aGVycywgSSBleHBlY3QgdGhleSB3b3VsZCBiZSBhcyB3ZWxsLg0KDQoqSSoga25vdyB5 b3UgbWVhbnQgZXZlcnlvbmUgZWxzZSBvbiB0aGlzIHRocmVhZCwgYW5kIG5vdCBtZS4NCg0KRkIg YW5kIEdvb2dsZSBmb2xrcywgd2lsbCB5b3UgcHJlc2VudCBhdCBTaW5nYXBvcmU/DQo= --_000_0D3ACAC6F79F43B0BAC1D910BCF3DE1Aakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <959F2CA242745445BD28EA2B9EEE9165@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4mZ3Q7IDwvc3Bhbj48L2I+SSBkaWRuJ3QgaW50ZW5kIHRvIGJlIGFyZ3Vpbmcgd2l0 aCB5b3UuIEknbSBoYXBweSB0byBwcmVzZW50IHdoYXQgSSBoYXZlIGluIFNpbmdhcG9yZSBhbmQg d2hpbGUgSSBjYW4ndCBzcGVhayBmb3Igb3RoZXJzLCBJIGV4cGVjdCB0aGV5IHdvdWxkIGJlIGFz IHdlbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPio8Yj5JPC9iPioga25vdyB5b3UgbWVhbnQg ZXZlcnlvbmUgZWxzZSBvbiB0aGlzIHRocmVhZCwgYW5kIG5vdCBtZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RkIgYW5kIEdvb2dsZSBmb2xrcywgd2lsbCB5b3UgcHJlc2VudCBhdCBTaW5nYXBv cmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0D3ACAC6F79F43B0BAC1D910BCF3DE1Aakamaicom_-- From nobody Sat Oct 7 09:38:29 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D162D134CF1 for ; Sat, 7 Oct 2017 09:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 pMwrqw0Nb-1U for ; Sat, 7 Oct 2017 09:38:26 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::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 23B6D134CF0 for ; Sat, 7 Oct 2017 09:38:26 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id m28so19423684pfi.0 for ; Sat, 07 Oct 2017 09:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=LvCQJVffhwEynUIiVToygkgMG0xZixBX0Lz3RAtUhXY=; b=by+2cALRc8oDwlMTwbTDe3UBOuauYcrWO48TAIqQ+Gs6omhNLH1B1cd+bfL9pfwust fpR9SPu+GHMC98C5laoD0pw+AipXhZO2gQDoboVFPCk3QnKSlPoz+IAyh1nbT381Nec3 Dv2XjZQ2qXQlilxSOeqgt2t7jt3/URHVJeHwwdst5lYTegEulwhtQFXNH8HhZIo4TOLs nFrpqOZR3GiWSP0ZUTIXx1SV5iGmNNjLtg9zhzGD3FtvnFSh1oSnc9hINDnbYs/IX3Zf DffQSzGWkg26J4gEOIJlB0ykKM8oT5wncSMY5hIGmYRvAlFfdCXM5wf55pNOGmJLCu7i JYlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=LvCQJVffhwEynUIiVToygkgMG0xZixBX0Lz3RAtUhXY=; b=jSGdp4ipstMZ/groOsdnHcCyDVd7kU4wOufb05UKeIxKuJlxNTNAS/YdIl9+/0OSBv lN4CS6cETWifV2iGFcmRoBn9fnMiaPPW+k28XaZv6lk82ZYfsi5vUBILu6lmVwMnFSgo zaS0oWps79Ultn7CKCYcGR1lGLXmFfXeG5EkQUvI6tHlKyTzO6OJdiD8ka7fgG0CwCif hn0G8ltxcsqs9Wv38J89NJihbEbhSAbrJpjBwPAGYKEc8nJH0fB/ncuHOIzNEOqWaQbW G517YG6BbqEjEdUFecvGy01C6XV8nSy/XwRFXI5DrcOTMaHAFII8kazxI7fzhDagOvAl mL8Q== X-Gm-Message-State: AMCzsaX5FLMwo9NVLOBsGhrv7OzmnAGVGc7Vm5TrPVxwQXPXfcYsQBex 8dglld7v4ECIMsBL2PTM0wEpH+QK0X/8dUz2AhdQfL3t X-Google-Smtp-Source: AOwi7QCDncUWQIgtSVkPDHNSqlXbYAwj82rhYHL1aWCmYGm73snfQ8UnxO1CdmciTHm0DmFHMz7/WeG6AfAlVyk1Ud0= X-Received: by 10.84.235.6 with SMTP id o6mr4965892plk.295.1507394305447; Sat, 07 Oct 2017 09:38:25 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.100.165.194 with HTTP; Sat, 7 Oct 2017 09:38:24 -0700 (PDT) In-Reply-To: <20171007091720.012fdb7b@pc1> References: <20171007091720.012fdb7b@pc1> From: Adam Langley Date: Sat, 7 Oct 2017 09:38:24 -0700 X-Google-Sender-Auth: m9cK_D-uu85y32qdtOTV0r8qRvs Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 16:38:28 -0000 On Sat, Oct 7, 2017 at 12:17 AM, Hanno B=C3=B6ck wrote: > Alternative proposal: > > 1. Identify the responsible vendors. > 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh, > it's your customers who don't update? Seems you don't have any > reasonable update system. Call your customers, send some support staff > to them. Fix this. Now." > 3. Call for a boycott of the vendors who are not able to fix this. In the past, Chrome has both steam-rollered over intolerance issues and used "naming and shaming" when it appeared useful. Naming and shaming can be an effective strategy when there is a small percentage of aberrant actors, but that doesn't appear to be the case here. It's not a single vendor, it's several, and we likely don't have a complete list because it's very difficult to get vendor/model/version information from the field. These issues vary across devices, across firmware versions (for which the active range is large), and across configurations (similarly large). As for the steam-roller: while /we/ may understand the issues in sufficient depth to know where the fault lies, the operating heuristic in IT is that the last thing that changed is to blame. That makes steam-rollering expensive. Sometimes we do it anyway, but the levels of breakage measured for the current TLS 1.3 wire-format are too high to be viable. There would have to be a fallback, and fallbacks are terrible. We've only recently gotten out of the last lot of them and should not do that again. I understand the share the justifiable anger at companies that are making profits by handicapping the internet that they depend on; we are paying their externalities right now. But the problem here is too widespread for either of the above strategies to be effective. We're still testing, but it appears that a few, security-inconsequential changes to TLS 1.3 make it significantly more viable to deploy. That has got to be preferable to behaviours like fallback, which is very security-consequential. This has taken time because getting good exposure needs changes to both our frontends and to Chrome Stable, which makes the iteration time long. We can iterate much faster with local middleboxes (and we've bought several), but the diversity of firmware versions and configurations means that we can't get great testing coverage from that approach. This looks, overwhelmingly, like the best path for TLS 1.3. For the future, I think we need to ponder changes in the way that we build and defend protocols. I think that GREASE (https://tools.ietf.org/html/draft-ietf-tls-grease-00) demonstrates the sort of change in thinking that is needed, but that we need to go further. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Sat Oct 7 10:28:34 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978E6134A9F for ; Sat, 7 Oct 2017 10:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbDnq2D-Pvtd for ; Sat, 7 Oct 2017 10:28:30 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CA3134AA1 for ; Sat, 7 Oct 2017 10:28:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 076C44189C; Sat, 7 Oct 2017 20:28:27 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id sGi5dhfKqzAt; Sat, 7 Oct 2017 20:28:26 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2C12F21C; Sat, 7 Oct 2017 20:28:22 +0300 (EEST) Date: Sat, 7 Oct 2017 20:28:22 +0300 From: Ilari Liusvaara To: Adam Langley Cc: Hanno =?utf-8?B?QsO2Y2s=?= , "tls@ietf.org" Message-ID: <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> References: <20171007091720.012fdb7b@pc1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 17:28:32 -0000 On Sat, Oct 07, 2017 at 09:38:24AM -0700, Adam Langley wrote: > On Sat, Oct 7, 2017 at 12:17 AM, Hanno Böck wrote: > > Alternative proposal: > > > > 1. Identify the responsible vendors. > > 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh, > > it's your customers who don't update? Seems you don't have any > > reasonable update system. Call your customers, send some support staff > > to them. Fix this. Now." > > 3. Call for a boycott of the vendors who are not able to fix this. > We're still testing, but it appears that a few, > security-inconsequential changes to TLS 1.3 make it significantly more > viable to deploy. That has got to be preferable to behaviours like > fallback, which is very security-consequential. This has taken time > because getting good exposure needs changes to both our frontends and > to Chrome Stable, which makes the iteration time long. We can iterate > much faster with local middleboxes (and we've bought several), but the > diversity of firmware versions and configurations means that we can't > get great testing coverage from that approach. Yes, and with local testing, one can't get the relative importances right, only to guide what to test on field. And even in field tests, there is issue of survivorship bias. I think that is the cause for seeming conflicts between the results. And even if the changes might not be directly consequential to security, the changes to get through some more annoying middleboxes might be quite annoying to implement. E.g. there probably are several different middeboxes that have a configuration that actually checks that the handshake looks valid, which includes checks for things like ChangeCipherSpec being present in both directions, even for resumption; while the non- resumption mode might even verify the authentication signatures in the handshake and not letting server send non-handshake messages before sending its 2nd flight. Ugh, getting around those would be pretty nasty. -Ilari From nobody Sat Oct 7 11:38:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F82B1321A2 for ; Sat, 7 Oct 2017 11:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 5Aw5crQA-Qtg for ; Sat, 7 Oct 2017 11:38:01 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67414134B1F for ; Sat, 7 Oct 2017 11:37:40 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id u138so14374648wmu.4 for ; Sat, 07 Oct 2017 11:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bCM72/NQzakRimCPfVqna9qpb6VsY+fCkhvqJPhQPrM=; b=cXyyQTjAoulkFHm9kO2pxlLoiLiavvTvy5GMeN1b5Lb3J/xuQV/SjW9Ctv5phS3itX 2F4/C/fSQy6dhwf3jUWXV9FKVSF3IggKBPODaQcRKqILFGo13fP04rJ/+veJuWm61S/8 ADMt/Gml9VF3wykz/wC/nqGCAQ747aEmQsUKgaTjGTwQP+KiQi+MUkTy6R6txrRO0UUa O2dT+GRKPJW1EikeW1TMoOLE2qlpyIUix6yOliOgFii8H9uSplB3Fv4/uN7bXf5ri17V BjFWzihZJMsizBZp3AdBI2gLwP9OwJE43M228/YM0w3/+Zx1xo+Jrx2nP9wqGSwUmzA2 EjkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bCM72/NQzakRimCPfVqna9qpb6VsY+fCkhvqJPhQPrM=; b=XOt1k2f3Uy371Vh9WPmM3Ludwri/jeg8hSk4Z55fbU9iG7FjkXqA3Md+OzdGXRgGHZ 5Nyv1wwRVky6ToJe9ytloHY4/6jhcvaBBzYbT1FjHZSbAFMDSftZXc+1NDGYj52vB6xQ 2aIHXMmuq7Kjhi+fBgES5FJ4EbcpSV3Y+Noks2uJik48SC92ulPUN9JHM6JpZrBxM1M3 nOgU+pGaKTMotlc8l6OCgmWij+WcdubXNBTHtqy3rBZf550q0IC8GPQWOAA7SBhASRie E5o07lGROKiaNFlVNDR8YZW5bk5UF6g4lUx417fIRFixz6Ao3LDOCLKL1IFGNZX3aX/Z sshQ== X-Gm-Message-State: AMCzsaViGN6TLP6KsCRqPEYLsxm5fUtDqrIUIFFd09qv5AMYtY2Z0lFc xbc11/UGXW+tVjSSz8qoXdM= X-Google-Smtp-Source: AOwi7QChTpVWqFQ1SrE7YmsZO2rZHVVB4Od88uGK8wUJYEdVmgryoT1M9ze0uOYBJw86+BvUk0svUA== X-Received: by 10.80.173.130 with SMTP id a2mr7678963edd.234.1507401458915; Sat, 07 Oct 2017 11:37:38 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id x14sm5782309edd.10.2017.10.07.11.37.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Oct 2017 11:37:37 -0700 (PDT) From: Yoav Nir Message-Id: <7412F908-CF35-4239-8F16-A8F30F3F5ABF@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8A33CCBA-A95F-4F83-8AD3-435040128DC6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 7 Oct 2017 21:37:35 +0300 In-Reply-To: Cc: Rich Salz , "tls@ietf.org" To: Nick Sullivan References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 18:38:03 -0000 --Apple-Mail=_8A33CCBA-A95F-4F83-8AD3-435040128DC6 Content-Type: multipart/alternative; boundary="Apple-Mail=_7E8E5C67-D1E0-4E9D-95C1-524E78DFE359" --Apple-Mail=_7E8E5C67-D1E0-4E9D-95C1-524E78DFE359 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Oct 2017, at 17:17, Nick Sullivan = wrote: >=20 > Yoav, >=20 > Let me make a correction to your scenario:. Instead of: > "You=E2=80=99ll need it for Chrome to work with Google." > it's: > "You=E2=80=99ll need it for Chrome to work with Google, Facebook, and = most of the 10% of Alexa top million sites that are using Cloudflare.=E2=80= =9D What part of =E2=80=9Cnot making any configuration changes until the = second week of January=E2=80=9D is not clear to you? Seriously, I=E2=80=99ve had this conversation with administrators. Because if they go to their bosses, they get asked if they can guarantee = that the update will cause no outage. Of course they can=E2=80=99t. Then they get asked if Edge has the same problem. Let=E2=80=99s assume = the answer is yes. Then they get asked if they can turn off TLS 1.3 in Edge using GPO (or = whatever the remote configuration of Microsoft Windows is called these = days). In all likelihood, the answer is yes. Problem sovled, no? But, they=E2=80=99ll protest, more than half our employees use Chrome. So tell them not to use Chrome, says the manager. Because for the manager the decision to update the middlebox is all risk = with no rewards. Yoav --Apple-Mail=_7E8E5C67-D1E0-4E9D-95C1-524E78DFE359 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 7 Oct 2017, at 17:17, Nick Sullivan <nicholas.sullivan@gmail.com> wrote:

Yoav,

Let me make a correction to your scenario:. = Instead of:
"You=E2=80=99ll need it for Chrome to work with = Google."
it's:
"You=E2=80=99ll need it for Chrome to work with Google, = Facebook, and most of the 10% of Alexa top million sites that are using = Cloudflare.=E2=80=9D

What part of =E2=80=9Cnot making any = configuration changes until the second week of January=E2=80=9D is not = clear to you?

Seriously, I=E2=80=99ve = had this conversation with administrators. 

Because if they go to their bosses, they get asked = if they can guarantee that the update will cause no outage. Of course = they can=E2=80=99t.

Then they get = asked if Edge has the same problem. Let=E2=80=99s assume the answer is = yes.

Then they get asked if they can = turn off TLS 1.3 in Edge using GPO (or whatever the remote configuration = of Microsoft Windows is called these days). In all likelihood, the = answer is yes.

Problem sovled, = no?

But, they=E2=80=99ll protest, = more than half our employees use Chrome. 

So tell them not to use Chrome, says the = manager.

Because for the manager the = decision to update the middlebox is all risk with no = rewards.

Yoav

= --Apple-Mail=_7E8E5C67-D1E0-4E9D-95C1-524E78DFE359-- --Apple-Mail=_8A33CCBA-A95F-4F83-8AD3-435040128DC6 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlnZHu8ACgkQuEkLFQpY zJkB4gf/WalMnAVWtahpOLtuOw4CpUvqTFQF6nuwGz9jzd21DSAhpS0FlosZw1kO 9GtNC+YMY28H0ToOdgGTWCsRRP2/jzZYdL69MSAOd2SU00l33IKT07rX+SuP6Uh/ mCaS/iB3XKt/at3NjOSfMARi6pTT1zcmu24WkiDZsDN3Rq4sNuPcsFoqZ/88G++v X6PO9Uqq0G3FG0KW8hXfezUGB62CUpwkOScko39dkxyvjXBYpuyw0mZgH8fS3cbU x295rTUNZryL1Lg6XE/x+mW+f0OjmlC5uN6d0DaZhI6hDb893AcFMroQH+kRDATf yV21mWVtrjfpNrEy1pjyEMw14RfX6Q== =UEgs -----END PGP SIGNATURE----- --Apple-Mail=_8A33CCBA-A95F-4F83-8AD3-435040128DC6-- From nobody Sun Oct 8 01:09:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538D2134DF1 for ; Sun, 8 Oct 2017 01:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 6dfnCmiYC0cT for ; Sun, 8 Oct 2017 01:09:30 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC49C134DA9 for ; Sun, 8 Oct 2017 01:09:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 666B6B518C; Sun, 8 Oct 2017 11:09:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id GIRtoYq1GlPn; Sun, 8 Oct 2017 11:09:25 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 82FF32313; Sun, 8 Oct 2017 11:09:22 +0300 (EEST) Date: Sun, 8 Oct 2017 11:09:22 +0300 From: Ilari Liusvaara To: Jeffrey Walton Cc: "Salz, Rich" , "" Message-ID: <20171008080922.pqhnj6rw26vo42sy@LK-Perkele-VII> References: <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 08:09:32 -0000 On Sat, Oct 07, 2017 at 11:33:33AM -0400, Jeffrey Walton wrote: > On Sat, Oct 7, 2017 at 11:25 AM, Salz, Rich wrote: > > > > > >> I suggest we not have this debate now. We'll have a lot more data towards > >> the end of the month and we can have an informed discussion then. > > > > > That is what I am asking for. More information so that the entire WG can > > make an informed decision. And I was only laying out an option that does > > not seem to have been considered before. > > The group (or the IETF) might also consider a policy to answer Ilari > Liusvaara's question, "What you think is acceptable failure rate?" > > That is a governance issue. It should probably be [nearly] written in > stone and applied equally to all problems and decisions. > Unfortunately, things are actually more complicated than that. I suspect that none of the figures "minimal", 1.5% nor 3.4% are actually accurate, due to "survivorship bias" (survive to be tested). This is both due to large variance in results, and Google and FB disagreeing on impact of the record type hack. I think Attributing the differences to survivorship bias (or other similar statistical bias) makes much more sense than attributing the differences to random chance (I presume the sample sizes are large enough to easily resolve even 0.1% differences) or a testing mistake. If asked to guess which result is the closest to the true value, I would guesss Google's (which is also the largest value). But I do not have any idea even which direction the true value is (often in studies it is rather easy to guess the direction of the true value, even if one can not guess the correction magnitude). The nasty issue in testing is that there are several classes of connections, with quite widely varying properties: 1) Residential wired 2) Wireless Mobile 3) Enterprise (includes some schools) 4) Satellite (most probably of minimal use). I would expect that with residential wired, the failure rates are minimal, whereas with Enterprise, the failure rates would be pretty substantial. With wireless mobile in the middle. I have no idea how satellite would stack up. I suspect the main factor in differences was proportion of enterprise networks that were tested. Which would imply that the enterprise failure rate is much higher than 3.4%. And even getting the failure rate reduced to 1%, the enterprise failure rate would still be substantially higher than 1%. And analyzing individual middleboxes to determine the kind of intolerance is only useful for guiding what kind of modifications to test on the field, since estimating any useful statistics from just the devices or software behavior is virtually impossible. -Ilari From nobody Sun Oct 8 14:42:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B800134954 for ; Sun, 8 Oct 2017 14:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, 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 rTs3O_hqE6XU for ; Sun, 8 Oct 2017 14:42:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 F41DB1332CD for ; Sun, 8 Oct 2017 14:42:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1e1JKz-0002Rl-Cs; Sun, 08 Oct 2017 21:42:17 +0000 Date: Mon, 09 Oct 2017 06:42:15 +0900 Message-ID: From: Randy Bush To: Rich Salz Cc: Transport Layer Surveillance WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 21:42:21 -0000 there are a lot of us lurkers out here a bit horrified watching this wg go off the rails. it would help if vendors of devices which break privacy would stop speaking for 'datacenters' and let datacenters speak for themselves. i have not seen any doing so. my $dayjob has >10 medium sized datacenters serving everything from banks to telcos to scaled cloud services. i can not find folk in our datacenter groups who see a need to break e2e encryption. if the interception proposals ensured that user is notified and able to prevent session interception, then i would believe this. but if they do not, then let's face it, this is all about selling surveillance gear to snooping enterprises and repressive regiemes where people with guns take you away at 3am because your session was decoded. can we please provide real end to end privacy or call this wg something else? randy From nobody Sun Oct 8 15:23:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2698134959 for ; Sun, 8 Oct 2017 15:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb8IEpU2xCvA for ; Sun, 8 Oct 2017 15:23:15 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 2EF3E13302A for ; Sun, 8 Oct 2017 15:23:15 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id i13so40094976qtc.11 for ; Sun, 08 Oct 2017 15:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YgjDgu+WcTf+FpnBBNgWSZ/thqMxYJWY8HwPL5PWO24=; b=NB7uDt0FzKI7aafQNfFrS+9o+rQgW9yCRRnJHJOmFqPUew72rJYHBUxL2tGkk56BeE Ke8zIvXPLcUedex9L+2pgUmDPSUdLEOe2J8eXEcebspw1RT0SIcrEB7IX3BMh5ZGEzO2 3nv4yZhtAvZFqpJmzaPUp5ZBL5iNPcQHVetDRWbj62lIUoYBeR17QEdXuVZoP5rPXYPk 7EfdSuZrdD3sFmy9zV9CVnhdeATIVpYvQW3GxTjRm3IKQHmCZTnIXZ197nnshymyYqFU zexLysq3xwyMHbSjDuVMk9vBwTTqP9VTkrdQkKXSNIjLCTABwwnTuVFBLDmCb8eC1h2U vBRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YgjDgu+WcTf+FpnBBNgWSZ/thqMxYJWY8HwPL5PWO24=; b=MJQhv1adZdiLc1XR2KN1Bp7zSiOMCOwOrnTx7Bf613aB/F5cd9bN2LD0wUvaf7XJQF VQ5tBkDvzs0CNJVn5ETF66ajqs7Nbm5F9AaU5gWFRdb2wloBeAcbNuuK3/sxWceOrUc1 hgRN03Nd977V5STUBYpdhcujIYXJi5PCU2HkB4HMY32kA9dOe8ZIqHJBqYegskpi7C2V RvR0UhrYkE9ZZBGVd/TjVJ6Estg2k4WD8XvIv2+excwTZXRXTFwqcgtFid3yQGcxNUd0 jIh/lCqydPaJIgTZ+JVpJapDLUfNXD53ZN4DWJ71YF/Bog2p/My2FaUirMn6fB0y0VxG q/RQ== X-Gm-Message-State: AMCzsaXTXkayhdd9vuR4RrCvTr5PZpdybNjIt2T9ZLkIFpmrhkCQ4tR9 K1cClkpFhk1j+ExXvjtPGZzxjLuCeebfoCiZsstKruC+ X-Google-Smtp-Source: AOwi7QA4/KuVUhVCczMkljXBIHXM5xqmGDkVoN6wl1OWvqoOAiM1fcHUGKYJmyezrOTpjbVa/g9KZINlir7EVxTZu3E= X-Received: by 10.129.232.4 with SMTP id a4mr7201323ywm.294.1507501394278; Sun, 08 Oct 2017 15:23:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sun, 8 Oct 2017 15:22:33 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 8 Oct 2017 15:22:33 -0700 Message-ID: To: Randy Bush Cc: Rich Salz , Transport Layer Surveillance WG Content-Type: multipart/alternative; boundary="089e082230a41ad45d055b1085ea" Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 22:23:17 -0000 --089e082230a41ad45d055b1085ea Content-Type: text/plain; charset="UTF-8" You seem to be responding to some other thread. As both Adam Langley and I mentioned, none of the changes that anyone is investigating for reducing middlebox-induced breakage affect the cryptographic properties of TLS. -Ekr On Sun, Oct 8, 2017 at 2:42 PM, Randy Bush wrote: > there are a lot of us lurkers out here a bit horrified watching this wg > go off the rails. > > it would help if vendors of devices which break privacy would stop > speaking for 'datacenters' and let datacenters speak for themselves. i > have not seen any doing so. my $dayjob has >10 medium sized datacenters > serving everything from banks to telcos to scaled cloud services. i can > not find folk in our datacenter groups who see a need to break e2e > encryption. > > if the interception proposals ensured that user is notified and able to > prevent session interception, then i would believe this. but if they do > not, then let's face it, this is all about selling surveillance gear to > snooping enterprises and repressive regiemes where people with guns take > you away at 3am because your session was decoded. > > can we please provide real end to end privacy or call this wg something > else? > > randy > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e082230a41ad45d055b1085ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You seem to be responding to some other thread. As both Ad= am Langley and I mentioned, none of the changes that anyone is investigatin= g for reducing middlebox-induced breakage affect the cryptographic properti= es of TLS.

-Ekr

=
On Sun, Oct 8, 2017 at 2:42 PM, Randy Bush <= span dir=3D"ltr"><ran= dy@psg.com> wrote:
there ar= e a lot of us lurkers out here a bit horrified watching this wg
go off the rails.

it would help if vendors of devices which break privacy would stop
speaking for 'datacenters' and let datacenters speak for themselves= .=C2=A0 i
have not seen any doing so.=C2=A0 my $dayjob has >10 medium sized datace= nters
serving everything from banks to telcos to scaled cloud services.=C2=A0 i c= an
not find folk in our datacenter groups who see a need to break e2e
encryption.

if the interception proposals ensured that user is notified and able to
prevent session interception, then i would believe this.=C2=A0 but if they = do
not, then let's face it, this is all about selling surveillance gear to=
snooping enterprises and repressive regiemes where people with guns take you away at 3am because your session was decoded.

can we please provide real end to end privacy or call this wg something
else?

randy

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--089e082230a41ad45d055b1085ea-- From nobody Sun Oct 8 15:32:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E926134964 for ; Sun, 8 Oct 2017 15:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 1wHELP4TDbJY for ; Sun, 8 Oct 2017 15:32:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD201345A4 for ; Sun, 8 Oct 2017 15:32:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 80CE5BE47; Sun, 8 Oct 2017 23:32:51 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuTeh8OhMPOa; Sun, 8 Oct 2017 23:32:49 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ACFDFBE2F; Sun, 8 Oct 2017 23:32:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507501969; bh=zeoF891gPDq7Y372A4QkQPbpDTRlnXGq+d3mQInd++4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XzKbxzvycPvO2DM2N/A6ec2bxC5MHMsu7wSDazEHlFcxPpFOc/6p8t4RjcveAuBcs 9lGuGKItfc8UXFU439EyKSCmLhcnlSSwyFUidLlwonDtQ2urs4qnN2HwfNwu+15H+2 Gj1IxW1Ds7q2kyCVHJXX8v4EK2Mn2BDsmwrVcEB0= To: Eric Rescorla , Randy Bush Cc: Transport Layer Surveillance WG References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1854f9e7-7264-bd1a-9ae4-0407b682b731@cs.tcd.ie> Date: Sun, 8 Oct 2017 23:32:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jwnfrqNK3xhqM05kPWbKiWSM7gU1Chwr9" Archived-At: Subject: [TLS] draft-rhrd (Was: Re: Update on TLS 1.3 Middlebox Issues) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 22:32:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jwnfrqNK3xhqM05kPWbKiWSM7gU1Chwr9 Content-Type: multipart/mixed; boundary="vx7APRXFk2dKb2skkefcCwcUREI0rXoD4"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , Randy Bush Cc: Transport Layer Surveillance WG Message-ID: <1854f9e7-7264-bd1a-9ae4-0407b682b731@cs.tcd.ie> Subject: draft-rhrd (Was: Re: [TLS] Update on TLS 1.3 Middlebox Issues) References: In-Reply-To: --vx7APRXFk2dKb2skkefcCwcUREI0rXoD4 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/10/17 23:22, Eric Rescorla wrote: > You seem to be responding to some other thread.=20 Yep. I changed the subject line. Randy's substantive message however is crystal clear. And is one that WG participants ought take to heart IMO. Pretending that some changes to TLS would magically be limited in scope to so-called "data centres" is BS. I'm really really puzzled that some otherwise sensible folks appear unable to see that. S > As both Adam Langley and I > mentioned, none of the changes that anyone is investigating for reducin= g > middlebox-induced breakage affect the cryptographic properties of TLS. >=20 > -Ekr >=20 >=20 > On Sun, Oct 8, 2017 at 2:42 PM, Randy Bush wrote: >=20 >> there are a lot of us lurkers out here a bit horrified watching this w= g >> go off the rails. >> >> it would help if vendors of devices which break privacy would stop >> speaking for 'datacenters' and let datacenters speak for themselves. = i >> have not seen any doing so. my $dayjob has >10 medium sized datacente= rs >> serving everything from banks to telcos to scaled cloud services. i c= an >> not find folk in our datacenter groups who see a need to break e2e >> encryption. >> >> if the interception proposals ensured that user is notified and able t= o >> prevent session interception, then i would believe this. but if they = do >> not, then let's face it, this is all about selling surveillance gear t= o >> snooping enterprises and repressive regiemes where people with guns ta= ke >> you away at 3am because your session was decoded. >> >> can we please provide real end to end privacy or call this wg somethin= g >> else? >> >> randy >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --vx7APRXFk2dKb2skkefcCwcUREI0rXoD4-- --jwnfrqNK3xhqM05kPWbKiWSM7gU1Chwr9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ2qeRAAoJEC88hzaAX42inlwH+wZogYw9sFi+i648qm5CxnWE uYfS2X77thHnLfiknwxf9kVlNm7dWejG6yJbWTAmr2DJ05kmBuXCmFA0Fe7y1fIu C5Kg07pQfTMf2ry+3TgQn/PCPxLY8HaOQLyjr/kD5W5ly08ojMauXcpieivhDDJk PdSgftZu0+Xx9sfvLW5uy0esaYmS31EEzhmOT/O4wsIXA36ZOAfARLXAg6oyMnhd CwVGo8BvfoUUIhsejJysBcukIL8mEAzGGZsbFYebwQoKGJVsMMieAYpRiXAybuAL A282PPb7N3ui/lJymLWGRstOibO4abDo7FO54tLAdsjNpMh0HtHqal8bmsJ5pQU= =V/3+ -----END PGP SIGNATURE----- --jwnfrqNK3xhqM05kPWbKiWSM7gU1Chwr9-- From nobody Sun Oct 8 15:38:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51A6134654 for ; Sun, 8 Oct 2017 15:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 lq_npWEIh0yb for ; Sun, 8 Oct 2017 15:38:43 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1A9133061 for ; Sun, 8 Oct 2017 15:38:42 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v98MccjU023320; Sun, 8 Oct 2017 18:38:40 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Stephen Farrell CC: Eric Rescorla , Randy Bush , "Transport Layer Surveillance WG" Thread-Topic: [TLS] draft-rhrd (Was: Re: Update on TLS 1.3 Middlebox Issues) Thread-Index: AQHTQIWKSfKQiJJn7kaUAa5dNa4k+KLazYGA Date: Sun, 8 Oct 2017 22:35:32 +0000 Message-ID: References: <1854f9e7-7264-bd1a-9ae4-0407b682b731@cs.tcd.ie> In-Reply-To: <1854f9e7-7264-bd1a-9ae4-0407b682b731@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-227D29BA-6CAE-452A-973F-4A3C1105A486"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710080333 Archived-At: Subject: Re: [TLS] draft-rhrd (Was: Re: Update on TLS 1.3 Middlebox Issues) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 22:38:46 -0000 --Apple-Mail-227D29BA-6CAE-452A-973F-4A3C1105A486 Content-Type: multipart/alternative; boundary=Apple-Mail-33CF7ED5-2837-412B-BE4E-EBB3625E9306 Content-Transfer-Encoding: 7bit --Apple-Mail-33CF7ED5-2837-412B-BE4E-EBB3625E9306 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 to Stephen. Regards, Uri Sent from my iPhone > On Oct 8, 2017, at 18:34, Stephen Farrell wrot= e: >=20 >=20 >=20 >> On 08/10/17 23:22, Eric Rescorla wrote: >> You seem to be responding to some other thread.=20 >=20 > Yep. I changed the subject line. >=20 > Randy's substantive message however is crystal clear. And is > one that WG participants ought take to heart IMO. Pretending > that some changes to TLS would magically be limited in scope > to so-called "data centres" is BS. I'm really really puzzled > that some otherwise sensible folks appear unable to see that. >=20 > S >=20 >=20 >> As both Adam Langley and I >> mentioned, none of the changes that anyone is investigating for reducing >> middlebox-induced breakage affect the cryptographic properties of TLS. >>=20 >> -Ekr >>=20 >>=20 >>> On Sun, Oct 8, 2017 at 2:42 PM, Randy Bush wrote: >>>=20 >>> there are a lot of us lurkers out here a bit horrified watching this wg >>> go off the rails. >>>=20 >>> it would help if vendors of devices which break privacy would stop >>> speaking for 'datacenters' and let datacenters speak for themselves. i >>> have not seen any doing so. my $dayjob has >10 medium sized datacenters= >>> serving everything from banks to telcos to scaled cloud services. i can= >>> not find folk in our datacenter groups who see a need to break e2e >>> encryption. >>>=20 >>> if the interception proposals ensured that user is notified and able to >>> prevent session interception, then i would believe this. but if they do= >>> not, then let's face it, this is all about selling surveillance gear to >>> snooping enterprises and repressive regiemes where people with guns take= >>> you away at 3am because your session was decoded. >>>=20 >>> can we please provide real end to end privacy or call this wg something >>> else? >>>=20 >>> randy >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-33CF7ED5-2837-412B-BE4E-EBB3625E9306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPisxIHRvIFN0ZXBo ZW4uPGJyPjxicj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlJlZ2FyZHMsPGRpdj5Vcmk8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48L2Rpdj48 ZGl2Pjxicj5PbiBPY3QgOCwgMjAxNywgYXQgMTg6MzQsIFN0ZXBoZW4gRmFycmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiPnN0ZXBoZW4uZmFycmVsbEBj cy50Y2QuaWU8L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxkaXY+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPk9uIDA4LzEw LzE3IDIzOjIyLCBFcmljIFJlc2NvcmxhIHdyb3RlOjwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4+WW91IHNlZW0gdG8gYmUgcmVzcG9uZGluZyB0byBzb21lIG90aGVyIHRo cmVhZC4gPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5ZZXAu IEkgY2hhbmdlZCB0aGUgc3ViamVjdCBsaW5lLjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48 c3Bhbj5SYW5keSdzIHN1YnN0YW50aXZlIG1lc3NhZ2UgaG93ZXZlciBpcyBjcnlzdGFsIGNsZWFy LiBBbmQgaXM8L3NwYW4+PGJyPjxzcGFuPm9uZSB0aGF0IFdHIHBhcnRpY2lwYW50cyBvdWdodCB0 YWtlIHRvIGhlYXJ0IElNTy4gUHJldGVuZGluZzwvc3Bhbj48YnI+PHNwYW4+dGhhdCBzb21lIGNo YW5nZXMgdG8gVExTIHdvdWxkIG1hZ2ljYWxseSBiZSBsaW1pdGVkIGluIHNjb3BlPC9zcGFuPjxi cj48c3Bhbj50byBzby1jYWxsZWQgImRhdGEgY2VudHJlcyIgaXMgQlMuIEknbSByZWFsbHkgcmVh bGx5IHB1enpsZWQ8L3NwYW4+PGJyPjxzcGFuPnRoYXQgc29tZSBvdGhlcndpc2Ugc2Vuc2libGUg Zm9sa3MgYXBwZWFyIHVuYWJsZSB0byBzZWUgdGhhdC48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48 YnI+PHNwYW4+Uzwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkFzIGJvdGggQWRhbSBMYW5nbGV5IGFuZCBJPC9z cGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+bWVudGlv bmVkLCBub25lIG9mIHRoZSBjaGFuZ2VzIHRoYXQgYW55b25lIGlzIGludmVzdGlnYXRpbmcgZm9y IHJlZHVjaW5nPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PHNwYW4+bWlkZGxlYm94LWluZHVjZWQgYnJlYWthZ2UgYWZmZWN0IHRoZSBjcnlwdG9ncmFwaGlj IHByb3BlcnRpZXMgb2YgVExTLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPi1Fa3I8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3Bhbj5PbiBTdW4sIE9jdCA4LCAyMDE3IGF0IDI6NDIgUE0sIFJhbmR5IEJ1c2ggJmx0Ozxh IGhyZWY9Im1haWx0bzpyYW5keUBwc2cuY29tIj5yYW5keUBwc2cuY29tPC9hPiZndDsgd3JvdGU6 PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9z cGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+dGhlcmUgYXJlIGEgbG90IG9mIHVzIGx1cmtlcnMgb3V0IGhlcmUg YSBiaXQgaG9ycmlmaWVkIHdhdGNoaW5nIHRoaXMgd2c8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PHNwYW4+Z28gb2ZmIHRoZSByYWlscy48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPml0IHdvdWxkIGhlbHAgaWYgdmVu ZG9ycyBvZiBkZXZpY2VzIHdoaWNoIGJyZWFrIHByaXZhY3kgd291bGQgc3RvcDwvc3Bhbj48YnI+ PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5zcGVha2luZyBmb3IgJ2RhdGFjZW50ZXJzJyBhbmQgbGV0 IGRhdGFjZW50ZXJzIHNwZWFrIGZvciB0aGVtc2VsdmVzLiAmbmJzcDtpPC9zcGFuPjxicj48L2Js b2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPmhhdmUgbm90IHNlZW4gYW55IGRvaW5nIHNvLiAmbmJzcDtteSAk ZGF5am9iIGhhcyAmZ3Q7MTAgbWVkaXVtIHNpemVkIGRhdGFjZW50ZXJzPC9zcGFuPjxicj48L2Js b2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPnNlcnZpbmcgZXZlcnl0aGluZyBmcm9tIGJhbmtzIHRvIHRlbGNv cyB0byBzY2FsZWQgY2xvdWQgc2VydmljZXMuICZuYnNwO2kgY2FuPC9zcGFuPjxicj48L2Jsb2Nr cXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPm5vdCBmaW5kIGZvbGsgaW4gb3VyIGRhdGFjZW50ZXIgZ3JvdXBzIHdo byBzZWUgYSBuZWVkIHRvIGJyZWFrIGUyZTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2tx dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh bj5lbmNyeXB0aW9uLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+aWYgdGhlIGludGVyY2VwdGlvbiBwcm9wb3NhbHMgZW5z dXJlZCB0aGF0IHVzZXIgaXMgbm90aWZpZWQgYW5kIGFibGUgdG88L3NwYW4+PGJyPjwvYmxvY2tx dW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4+cHJldmVudCBzZXNzaW9uIGludGVyY2VwdGlvbiwgdGhlbiBpIHdvdWxk IGJlbGlldmUgdGhpcy4gJm5ic3A7YnV0IGlmIHRoZXkgZG88L3NwYW4+PGJyPjwvYmxvY2txdW90 ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+bm90LCB0aGVuIGxldCdzIGZhY2UgaXQsIHRoaXMgaXMgYWxsIGFib3V0IHNl bGxpbmcgc3VydmVpbGxhbmNlIGdlYXIgdG88L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+c25vb3BpbmcgZW50ZXJwcmlzZXMgYW5kIHJlcHJlc3NpdmUgcmVnaWVtZXMgd2hlcmUgcGVv cGxlIHdpdGggZ3VucyB0YWtlPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPnlvdSBh d2F5IGF0IDNhbSBiZWNhdXNlIHlvdXIgc2Vzc2lvbiB3YXMgZGVjb2RlZC48L3NwYW4+PGJyPjwv YmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmNh biB3ZSBwbGVhc2UgcHJvdmlkZSByZWFsIGVuZCB0byBlbmQgcHJpdmFjeSBvciBjYWxsIHRoaXMg d2cgc29tZXRoaW5nPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmVsc2U/PC9zcGFu Pjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj5yYW5keTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwv YmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+VExTIG1haWxpbmcg bGlzdDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48YSBocmVmPSJtYWlsdG86VExT QGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxz cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48L3NwYW4+PGJyPjwv YmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PHNwYW4+VExTIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0Bp ZXRmLm9yZzwvYT48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PC9zcGFuPjxi cj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48 L2Jsb2NrcXVvdGU+PHNwYW4+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+VExTIG1haWxpbmcgbGlzdDwvc3Bhbj48 YnI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjwv c3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90bHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjwv c3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --Apple-Mail-33CF7ED5-2837-412B-BE4E-EBB3625E9306-- --Apple-Mail-227D29BA-6CAE-452A-973F-4A3C1105A486 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcxMDA4MjIzNTMxWjAjBgkqhkiG9w0BCQQxFgQUYyWZbyWZ3s4R/3ztHb8AWtIdzCUwbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBABRO6VBiRTu44PazRIzDr/RTiOf3cxliqqRfLtZX+exISLVDkcUulTVYjDdTCoz6 OI8Q77Pt0odnN/L34aJSDBsW51yqWNGj1kQ1zb1lcYKEYjZf8vxgBPMDgVVC2oqIxu3yKrHNTvtz DvI56Zsq4rG/9dvYpD+A/4sD6+XPUBIKWfRsP78ncXITuFPLrDrZAn1D3wiwpKExcJZQ81k++xky PObJP26p686Dn1gA9RPtUe0kyFW4AfWTUUBdRCnb4t458c5x2tP+i72EH0Y5G1FPxNXDQQMCdSsw aJoKWveclrPgrhplh2T12LyD5D5j52YUQf4T7cuECH3vCwrmmUgAAAAAAAA= --Apple-Mail-227D29BA-6CAE-452A-973F-4A3C1105A486-- From nobody Sun Oct 8 15:39:29 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96DC133061 for ; Sun, 8 Oct 2017 15:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Yy-Lz0GDha2m for ; Sun, 8 Oct 2017 15:39:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 8778413495E for ; Sun, 8 Oct 2017 15:39:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1e1KEF-0002aq-IU; Sun, 08 Oct 2017 22:39:24 +0000 Date: Mon, 09 Oct 2017 07:39:21 +0900 Message-ID: From: Randy Bush To: Eric Rescorla Cc: Rich Salz , Transport Layer Surveillance WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 22:39:28 -0000 > You seem to be responding to some other thread. As both Adam Langley and I > mentioned, none of the changes that anyone is investigating for reducing > middlebox-induced breakage affect the cryptographic properties of TLS. my apologies. i can only plead low caffeine (6:45 am tokyo time). the proper threads would have been draft-green-tls-static-dh-in-tls13 draft-rhrd-tls-tls13-visibility etc etc etc it's getting to be that you can smell a red herring by the word 'datacenter' when it's really vendors of surveillance gear and three letter agencies. > On Sun, Oct 8, 2017 at 2:42 PM, Randy Bush wrote: ^^^^^^^ that's your clock, not mine :) > >> there are a lot of us lurkers out here a bit horrified watching this wg >> go off the rails. >> >> it would help if vendors of devices which break privacy would stop >> speaking for 'datacenters' and let datacenters speak for themselves. i >> have not seen any doing so. my $dayjob has>10 medium sized datacenters >> serving everything from banks to telcos to scaled cloud services. i can >> not find folk in our datacenter groups who see a need to break e2e >> encryption. >> >> if the interception proposals ensured that user is notified and able to >> prevent session interception, then i would believe this. but if they do >> not, then let's face it, this is all about selling surveillance gear to >> snooping enterprises and repressive regiemes where people with guns take >> you away at 3am because your session was decoded. >> >> can we please provide real end to end privacy or call this wg something >> else? randy From nobody Sun Oct 8 16:22:34 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A43134317 for ; Sun, 8 Oct 2017 16:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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=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 89m9yxgm6K2H for ; Sun, 8 Oct 2017 16:22:31 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 B58EF13318C for ; Sun, 8 Oct 2017 16:22:31 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v98NMSKC011017; Mon, 9 Oct 2017 00:22:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3mTPHZALnskbrJ1rR2cTqHA9zRoXFinVMIUBmOZUujo=; b=CbCVoBin//6/lxT0G7CzGXRRwDMv9V6F8QN0ZppPVTXNGoqbZPb90rJlRrTluq+6oSqv M9+MVAxd/q7B8xp507mbFeWVEOCGNDTM0k8InIAw9w+jMlp0L04Y4ikQZB2HreaFgSPj MUoFiS7wg99grjgwp8dsHUBfN3ht2l6nT5KaG6PxuzB9hWOVU6AaQ1765ilSieZGbDEE 6kBbcUKvk0ij5WESOgit2S+jIwhCGtxw3+XDQZokNFVjG5t/ShHSnSz5v1Ztnjx5dw2S vh08lxHak5QIzAYACl1nHt4wXleh2BLdI0E9gQgDBoKMtiGZonGc6CvUbY9bVE/aIrAe PA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2depye4vxt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Oct 2017 00:22:28 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v98NLIcO028524; Sun, 8 Oct 2017 19:22:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2det8vm3bx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 08 Oct 2017 19:22:27 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 8 Oct 2017 16:22:26 -0700 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.1263.000; Sun, 8 Oct 2017 18:22:27 -0500 From: "Salz, Rich" To: Randy Bush CC: Transport Layer Surveillance WG Thread-Topic: [TLS] Update on TLS 1.3 Middlebox Issues Thread-Index: AQHTQH5ObOGtBHBWK0qNw6DkAAvXEKLa628A Date: Sun, 8 Oct 2017 23:22:26 +0000 Message-ID: <22144D8B-85C0-4E82-A6F3-CD32A916EBD6@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/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.178] Content-Type: text/plain; charset="utf-8" Content-ID: <20C6FCC8EC49654C8870F970CF58AAAD@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710080345 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710080345 Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 23:22:33 -0000 SXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlIElFVEYgaGFkIGEgbWVjaGFuaXNtIHRvIHB1dCBzb21l dGhpbmcgb24taG9sZC4gIFRvIHJlcGVhdCB3aGF0IEkgc2FpZCBhdCDigJk5OSwgd2UgbmVlZCB0 byBwdXQgdGhpcyBvbiBob2xkIGZvciBhIHllYXIgb3IgdHdvIGFmdGVyIFRMUyAxLjMgaXMgZG9u ZS4NCg0KDQoNCg== From nobody Mon Oct 9 10:00:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270521346E9 for ; Mon, 9 Oct 2017 10:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwS6JgdHOiq7 for ; Mon, 9 Oct 2017 10:00:07 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8269F134575 for ; Mon, 9 Oct 2017 10:00:06 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3y9mh36tYLz1HPX; Mon, 9 Oct 2017 19:00:03 +0200 (CEST) X-purgate-ID: 152705::1507568403-000040CA-FFFE44E8/0/0 X-purgate-size: 627 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3y9mh33ghJzGp8Q; Mon, 9 Oct 2017 19:00:03 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 70327404A; Mon, 9 Oct 2017 19:00:03 +0200 (CEST) In-Reply-To: References: To: Eric Rescorla Date: Mon, 9 Oct 2017 19:00:03 +0200 (CEST) CC: "tls@ietf.org" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171009170003.70327404A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 17:00:09 -0000 Eric Rescorla wrote: > > two options: > > - Try to make small adaptations to TLS 1.3 to make it work better with > middleboxes. Return to the proper TLSv1.2 record format with true ContentTypes (hiding them doesn't add any security anyways). With the needlessly broken ContentTypes, we will be unable to support TLSv1.3 in our current apps. The needless changes break streaming of layered IO and end-of-communication discovery for long-running requests, because it is not possible to reliably distinguish a warning-level closure alert from a pipelined continuation of app data. -Martin From nobody Mon Oct 9 10:21:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D1813471E for ; Mon, 9 Oct 2017 10:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHzc5OhQJbpT for ; Mon, 9 Oct 2017 10:21:11 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A714134718 for ; Mon, 9 Oct 2017 10:21:03 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3y9n8G0Kmxz1HP5; Mon, 9 Oct 2017 19:21:02 +0200 (CEST) X-purgate-ID: 152705::1507569662-00007EC7-CC93D4B8/0/0 X-purgate-size: 1019 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3y9n8F5r1szGpS3; Mon, 9 Oct 2017 19:21:01 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id BD9C8404A; Mon, 9 Oct 2017 19:21:01 +0200 (CEST) In-Reply-To: <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> References: <20171007091720.012fdb7b@pc1> <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> To: Ilari Liusvaara Date: Mon, 9 Oct 2017 19:21:01 +0200 (CEST) CC: Adam Langley , "tls@ietf.org" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 17:21:14 -0000 Ilari Liusvaara wrote: > > And even if the changes might not be directly consequential to > security, the changes to get through some more annoying middleboxes > might be quite annoying to implement. > > E.g. there probably are several different middeboxes that have a > configuration that actually checks that the handshake looks valid, > which includes checks for things like ChangeCipherSpec being > present in both directions, even for resumption; while the non- > resumption mode might even verify the authentication signatures in > the handshake and not letting server send non-handshake messages > before sending its 2nd flight. Ugh, getting around those would be > pretty nasty. Fixing the backwards-incompatibilities in the TLS record layer would be terribly useful for streaming-optimized IO layers as well, i.e. ensure the the TLS record properly identifies ContentType, and that a TLSv1.3 handshake ends with CCS followed by 1 Handshake message. -Martin From nobody Mon Oct 9 10:33:17 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33391134725 for ; Mon, 9 Oct 2017 10:33:15 -0700 (PDT) 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 F9xqrSp1mLJq for ; Mon, 9 Oct 2017 10:33:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2CB13471C for ; Mon, 9 Oct 2017 10:33:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC16BBE53; Mon, 9 Oct 2017 18:33:10 +0100 (IST) 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 juJfM_P71gGb; Mon, 9 Oct 2017 18:33:10 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AC53BBE50; Mon, 9 Oct 2017 18:33:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507570390; bh=KGeXEmqB6tJKymLot3YOMzBY9Gdb/lCmo+jcf/dU3u0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eT1QHhrSUKAunlSKMTJacabPmgit1MtFoaZPmpTvJnNL9SIC3Ko472GWK3/c5/fcf KVemYNciZ2JKiytAXFXSM09QCR3qoRmE9smo9ianDRl/PS/mMC4aOYl5Pol4IoSrW4 n0SbLaY2ESbMS5V4sdf/LO7ophzSUaa+/7cch+tA= To: "Blumenthal, Uri - 0553 - MITLL" Cc: Eric Rescorla , Randy Bush , Transport Layer Surveillance WG References: <1854f9e7-7264-bd1a-9ae4-0407b682b731@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57bda69d-f54e-9fd3-ae2c-72cf06409730@cs.tcd.ie> Date: Mon, 9 Oct 2017 18:33:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CdGbax250Hdoj9t5xFXor0dSqlHvxvVKw" Archived-At: Subject: Re: [TLS] draft-rhrd (Was: Re: Update on TLS 1.3 Middlebox Issues) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 17:33:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CdGbax250Hdoj9t5xFXor0dSqlHvxvVKw Content-Type: multipart/mixed; boundary="K6UNLVOPilSdLVgw0tnPgvhwD4sHhG6hB"; protected-headers="v1" From: Stephen Farrell To: "Blumenthal, Uri - 0553 - MITLL" Cc: Eric Rescorla , Randy Bush , Transport Layer Surveillance WG Message-ID: <57bda69d-f54e-9fd3-ae2c-72cf06409730@cs.tcd.ie> Subject: Re: [TLS] draft-rhrd (Was: Re: Update on TLS 1.3 Middlebox Issues) References: <1854f9e7-7264-bd1a-9ae4-0407b682b731@cs.tcd.ie> In-Reply-To: --K6UNLVOPilSdLVgw0tnPgvhwD4sHhG6hB Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I did a bit of an update to [1]. As before PRs are welcome and I (still) wonder if the WG would benefit from documenting bits of this stuff as a work item to save time and repetition in future. S. [1] https://github.com/sftcd/tinfoil On 08/10/17 23:35, Blumenthal, Uri - 0553 - MITLL wrote: > +1 to Stephen. >=20 > Regards, > Uri >=20 > Sent from my iPhone >=20 >> On Oct 8, 2017, at 18:34, Stephen Farrell = wrote: >> >> >> >>> On 08/10/17 23:22, Eric Rescorla wrote: >>> You seem to be responding to some other thread.=20 >> >> Yep. I changed the subject line. >> >> Randy's substantive message however is crystal clear. And is >> one that WG participants ought take to heart IMO. Pretending >> that some changes to TLS would magically be limited in scope >> to so-called "data centres" is BS. I'm really really puzzled >> that some otherwise sensible folks appear unable to see that. >> >> S >> >> >>> As both Adam Langley and I >>> mentioned, none of the changes that anyone is investigating for reduc= ing >>> middlebox-induced breakage affect the cryptographic properties of TLS= =2E >>> >>> -Ekr >>> >>> >>>> On Sun, Oct 8, 2017 at 2:42 PM, Randy Bush wrote: >>>> >>>> there are a lot of us lurkers out here a bit horrified watching this= wg >>>> go off the rails. >>>> >>>> it would help if vendors of devices which break privacy would stop >>>> speaking for 'datacenters' and let datacenters speak for themselves.= i >>>> have not seen any doing so. my $dayjob has >10 medium sized datacen= ters >>>> serving everything from banks to telcos to scaled cloud services. i= can >>>> not find folk in our datacenter groups who see a need to break e2e >>>> encryption. >>>> >>>> if the interception proposals ensured that user is notified and able= to >>>> prevent session interception, then i would believe this. but if the= y do >>>> not, then let's face it, this is all about selling surveillance gear= to >>>> snooping enterprises and repressive regiemes where people with guns = take >>>> you away at 3am because your session was decoded. >>>> >>>> can we please provide real end to end privacy or call this wg someth= ing >>>> else? >>>> >>>> randy >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 --K6UNLVOPilSdLVgw0tnPgvhwD4sHhG6hB-- --CdGbax250Hdoj9t5xFXor0dSqlHvxvVKw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ27LWAAoJEC88hzaAX42i6aIIAJ71O7KUaRQ2kIFbjOMR4PTD WOFGu9yBio5UVbm9As6cMFmU6hkb032yS5RncOWs7RvFeF8bXgzqkskVQ1mTDcD7 YnlMrrqst934xGqj+hHzOrvkViA0Kq0gYQBjV9mO3HABKyaJWCSfcPryEgAaS8Vo 94uF1LFHfoy4bu18iWFW9r0bcr/ODJhg6iJed4jpeMQe4kRZm30xgpjyfLA0MxnQ 1Cckh0pANSP1lzQ1EBPYAB2MR3F1B6GwgGd/AUN8zcryrO9G9qdPfE0I3xos7Gj4 arm1BhDllrgc3fgvoKIe/gVBnEYHlp+vv/C9H6qIMC3+Xn2Fc0HUpgrZfJEJCwI= =CZfo -----END PGP SIGNATURE----- --CdGbax250Hdoj9t5xFXor0dSqlHvxvVKw-- From nobody Mon Oct 9 11:16:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D8513475B for ; Mon, 9 Oct 2017 11:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 O7CZxPkfYrnB for ; Mon, 9 Oct 2017 11:16:38 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19417134670 for ; Mon, 9 Oct 2017 11:16:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 6A9CEB514F; Mon, 9 Oct 2017 21:16:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id rlWaV-_uvFm7; Mon, 9 Oct 2017 21:16:35 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 8FD482313; Mon, 9 Oct 2017 21:16:31 +0300 (EEST) Date: Mon, 9 Oct 2017 21:16:31 +0300 From: Ilari Liusvaara To: Martin Rex Cc: Adam Langley , "tls@ietf.org" Message-ID: <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII> References: <20171007091720.012fdb7b@pc1> <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 18:16:40 -0000 On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote: > Ilari Liusvaara wrote: > > > > And even if the changes might not be directly consequential to > > security, the changes to get through some more annoying middleboxes > > might be quite annoying to implement. > > > > E.g. there probably are several different middeboxes that have a > > configuration that actually checks that the handshake looks valid, > > which includes checks for things like ChangeCipherSpec being > > present in both directions, even for resumption; while the non- > > resumption mode might even verify the authentication signatures in > > the handshake and not letting server send non-handshake messages > > before sending its 2nd flight. Ugh, getting around those would be > > pretty nasty. > > > Fixing the backwards-incompatibilities in the TLS record layer > would be terribly useful for streaming-optimized IO layers as well, > i.e. ensure the the TLS record properly identifies ContentType, > and that a TLSv1.3 handshake ends with CCS followed by 1 Handshake message. Unfortunately, doing that would do really bad things to security. And the middleboxes I am talking about actually parse every cleartext handshake message. Change anything in any message and they fail. And fixing some known vulnerabilities in TLS 1.2 is not possible without changing the structures around. In fact, I think the record layer changes in TLS 1.3 actually _reduce_ intolerance, not _increase_ it. If your middlebox is not as anal as I described above, it probably falls into copying data back and forth when it loses the handshake. However, the changes into ServerHello could easily cause trouble even with such middleboxes. Here what might work getting around those really annoying middleboxes (and this is pretty nasty): - Add back the session field, echo field from client - Add dummy zero into place of compression method, so TLS 1.2 parsers can parse the message. - Fix ServerVersion at TLS 1.2, send true version in supported_versions extension. - If the version is TLS 1.3, the session id is non-empty and 0-RTT was not accepted, insert fake ChangeCipherSpec message immediately after ServerHello and change outer content-type of the next record to 22 (instead of 23). The client can do the same. This might be able to make the middlebox think that first part of the handshake is actually TLS 1.2 stateful session resumption. But as said, blech at the hack. Hmm... Ciphersuites could cause problems still. With less annoying middleboxes, the following would also work: - Add two zeros into ServerHello so the message can be parsed the same way as TLS 1.2. And with slightly more annoying than that: - Add two zeros into ServerHello so the message can be parsed the same way as TLS 1.2. - Fix ServerVersion at TLS 1.2, send true version in supported_versions extension. -Ilari From nobody Mon Oct 9 13:49:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF64E1342F1 for ; Mon, 9 Oct 2017 13:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 DDYSe8gbW19i for ; Mon, 9 Oct 2017 13:49:19 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4A41332D4 for ; Mon, 9 Oct 2017 13:49:19 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id k4so26774945wmc.1 for ; Mon, 09 Oct 2017 13:49:18 -0700 (PDT) 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; bh=8dXzSR90jlDCiGoZbQZ+uE4upulFjijyjA/sjq3giU4=; b=Z7QvcdCOVtgLeiv5PtHAs7ofEvSzCTPtkVAshZ5xnIn0gEGtR370aO0gH3ko2Zlamy Yd26HzN2LQXn8kzEVqMWaIm+Bi6g+CC33r9MUgk0LShtisB5/OZvs3AdybmVxDNIVrkD /PeEX3L7SlzgEUF8LpvlsJyR1FyDlGnmeC5OgegZSX0H+fnpgw6Sq9hIMi2hihtkVZZJ FqKLLWC7oEVNTXX4kNiONJXWJSBPLjv4VK8hke1ZPoywEyst2Bm9Q1yEIEDAmCORoRt5 IoB+Eb0AegmA9ZnCrgANvy45ROiMMeyUCjMebkbVxBDbJlOvbl+P33C+jbv1QHkhIiiU QlMQ== 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; bh=8dXzSR90jlDCiGoZbQZ+uE4upulFjijyjA/sjq3giU4=; b=OrOyy0NOeGlzCplLO92loUGBW5tcVaiEdvS+2QrjucJ/YGlKEf8YMN+VdSAi/72VNk 504nHilbezsYB8/3Gxhc+FOEyMUw4IyXk5ItzvqhdHUQBGlTVFt1qTLGTwAb66mE1Rau QNnnFjC9NoX+8H4AS2Qz6T7catt755Eo9FancATeeUo+lrxa9hLRyqzT94Zpho8KY8ls t0OTe+wGz5912jr0BhFBcF88izn9YJbk5h+LHHkaPp1+vWYzlYbNZ4/WqJPv3k6yax6x bjGcvwSZNLkqlAjqYgRlY+Rp2xvbxtR9hH03id+yZ4VULqa6R1JuMfP5+shki5ksICYF XZ3A== X-Gm-Message-State: AMCzsaVoe44cvb0U+iZPWmfYFRw7je9GiHNN5Aia4y6SZMOX7aCan8p9 ImPQDZGarSNdAvNPQFwgeTX9s9r/ly3QgYWnisI= X-Google-Smtp-Source: AOwi7QC+IjLaiLxMF78IU3tzG0XTFdrmXa1+6z6h9uOBU3KHiUflCakFJOE+WNfmGeIMmKGImIU1xo59BExVuT+Qj9A= X-Received: by 10.223.186.20 with SMTP id o20mr12413586wrg.3.1507582157544; Mon, 09 Oct 2017 13:49:17 -0700 (PDT) MIME-Version: 1.0 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> In-Reply-To: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> From: Nick Sullivan Date: Mon, 09 Oct 2017 20:49:05 +0000 Message-ID: To: Ralph Droms , tls@ietf.org Content-Type: multipart/alternative; boundary="089e08246c84f86009055b235263" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 20:49:22 -0000 --089e08246c84f86009055b235263 Content-Type: text/plain; charset="UTF-8" Ralph and Russ, This draft addresses the two main concerns I had with draft-green: 1) Client opt-in 2) On-the wire visibility There are clearly some details missing from this draft (such as how Ke is used as a symmetric key), but generally I think this approach is more explicit and therefore less likely to unintentionally impact the broader internet if used in the datacenter setting. Nick On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms wrote: > We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS > extension defined in this I-D takes into account what we heard from the > discussion regarding TLS visibility and > draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides > an opt-in capability for both the TLS client and server and makes it clear > on the wire that visibility will be enabled for the session. The new > mechanism does not depend on static handshake or session keys. > > - Ralph and Russ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e08246c84f86009055b235263 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ralph and Russ,

This draft addresses= the two main concerns I had with draft-green:
1) Client opt-in
2) On-the wire = visibility

There are clearly some details missing from this draft (suc= h as how Ke is used as a symmetric key), but generally I think this approac= h is more explicit and therefore less likely to unintentionally impact the = broader internet if used in the datacenter setting.

Nick
On Mon, Oct 2, 2017 at 1:31 PM= Ralph Droms <rdroms.ietf@gmail= .com> wrote:
We are about to= publish draft-rhrd-tls-tls13-visibility-00.=C2=A0 The TLS extension define= d in this I-D takes into account what we heard from the discussion regardin= g TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. Speci= fically, it provides an opt-in capability for both the TLS client and serve= r and makes it clear on the wire that visibility will be enabled for the se= ssion.=C2=A0 The new mechanism does not depend on static handshake or sessi= on keys.

- Ralph and Russ


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--089e08246c84f86009055b235263-- From nobody Mon Oct 9 16:05:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B1713263F for ; Mon, 9 Oct 2017 16:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 phkzlz1R8oQ9 for ; Mon, 9 Oct 2017 16:05:27 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 C82DF132195 for ; Mon, 9 Oct 2017 16:05:26 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id z50so41292558qtj.4 for ; Mon, 09 Oct 2017 16:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=PX+53snbb/Jl+DH1utx4Xai3oO9/QfmqMQFeUJHMb1o=; b=MfRMjTcRipMs5RgQSyaziZFLk/OxtN6T98vNrDCEiL34J9xbfmjmx9PNPvsWWf4eus /Vvx3tWGRwqlRpenuBlcGiaPklhzQWbw+5iiYYL2yld2XYprbyVbaIdun7alY8SSXC13 K/PJks9qwMKhs1++iC4DSIfj2uGcene6bSj6o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=PX+53snbb/Jl+DH1utx4Xai3oO9/QfmqMQFeUJHMb1o=; b=WcAI27F6suwsXjLlrzvEL72ceY6w/zyI645rvuTAyIf2JQmy3gY4EL4sSKL9nYyLeq bfbIQzNMkFSNd9ZMVx2HUaPZ/HO3TBjUKVSV6IQaf+ZyWiSMzWkCrtyWZxcRZZqIwgsx b5zkzg3pMkHvCrFMlgXk2iE3dVrPdRPBAsWrXdJ63ksLA6l3BuyzBMpXd3/mgtjhfWxP 5jI/YBAHrmGhqxZyYxru8ZOtuyTgIt0WkulGrSnQRxBhv12j8UHR1jp1OYS3Lhaoi0fB i6pw2G0024L6mcadOw7eu6xN5ZEc4vcCjOsPPBoesZYXpvbEw6oqaIPEghQGu5NlBvzQ LlQg== X-Gm-Message-State: AMCzsaVtX4Sk079iBDBL03+JOh5A8358T7Flhha4XFRdC+c57nWy/lCW cydZUHkeHs/vqNLUy4fcx4QUvAXljGQ= X-Google-Smtp-Source: AOwi7QCdETvvg25F9r+zAvwjtHs7QMWuRkigdAWdQitaxaTIxb5aCaSwALAg9DCPpmJsU8fbmLSHBw== X-Received: by 10.200.47.187 with SMTP id l56mr7092784qta.319.1507590325831; Mon, 09 Oct 2017 16:05:25 -0700 (PDT) Received: from [172.16.0.18] ([96.231.228.225]) by smtp.gmail.com with ESMTPSA id y31sm5663272qta.83.2017.10.09.16.05.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 16:05:24 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 9 Oct 2017 19:05:23 -0400 References: To: "" In-Reply-To: Message-Id: <4EDF7DF9-D9C9-4A5B-AA9C-5A39823FA250@sn3rd.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 23:05:28 -0000 Anybody else has thoughts on this? spt > On Oct 3, 2017, at 18:53, Sean Turner wrote: >=20 > In the IANA registries draft = (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates), we=E2=80=99= ve added a recommended column to the Cipher Suites (CSs) registry (and = some others). Right now, the criteria for getting a recommended mark is = AEAD ciphers with strong authentication standards track ciphers. While = that=E2=80=99s great generally, the list we=E2=80=99ve got five CSs that = gave Joe and I pause: >=20 > TLS_DHE_RSA_WITH_AES_128_CCM_8 > TLS_DHE_RSA_WITH_AES_256_CCM_8 > TLS_PSK_DHE_WITH_AES_128_CCM_8 > TLS_PSK_DHE_WITH_AES_256_CCM_8 > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 >=20 > The CCM_8 CSs have a significantly truncated authentication tag that = represents a security trade-off that may not be appropriate for general = environment. In other words, this might be great for some IoT device = but we should not generally be recommending these. >=20 > We=E2=80=99re recommending that these five suites be dropped from the = recommended list. Please let us know what you think. >=20 > J&S > (editor hats on) From nobody Mon Oct 9 16:11:02 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF51132D22 for ; Mon, 9 Oct 2017 16:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEvBOsg36s9o for ; Mon, 9 Oct 2017 16:10:58 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 9CCA0120720 for ; Mon, 9 Oct 2017 16:10:58 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id 8so610800qtv.1 for ; Mon, 09 Oct 2017 16:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=99Bkwa6zuy0xUQe199+FYxAwqh8FbgtHgvZgtzcElBg=; b=1j1muLJuGB0n4I8anzJyWjORklP0/hzqtwZRljbgA/FmKsjM+C7FCqA6dPcyNPI7iE Evl/zRTjQNMoZMDI+pB9/myMeNEICRsH2F9wTRkJedcQpmRJcVfEEduaqNdFRjJ6EdpK HMcOlq835z9loTTdaakZKpcvFJvBb74oSLPkBYdbc762V4V5jxWqkKANzFTVVShlWtR2 Blmu6z859RtSVnfDtIiFc0k93O5YciVqXi0eef6d7zL7/wfF3l9MZfE/KZgsdHLqlgBZ sANRtH2k/izIqBiUALi0R6w5tNVXuzbvfbVDBuTQ5aMEh1vTA1irssqsoFvZfJLvueZS 6+DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=99Bkwa6zuy0xUQe199+FYxAwqh8FbgtHgvZgtzcElBg=; b=YVeSLA/TSBm4/MFpnimU/g/jbEIhmtcg8D6cEUAC53xU3H1IcFRC3X9YpzQQ2Ucaly mb2xZACNXG+++mnCKjFsL0LXi9YcDILOUVzSjFQuMN1Xiei2YXCVuoMlqum10WWW+WyI LDyjDphkcSVr7kGwWGUmisr5ncrnRtMNygHTC4WME3tv3LR5GS7bN/2QO8U/xISDpLxl WFY9PTRcPRmihtHYYlpnhaihB5wQVkM4o4RRyYkh0qiFBFKSIYdPdOtd27wda6ZBT8F+ 2Ckm1a9QBeDFbtwX/L75dMolshefRGYtVFdHd6+DvaD7E5CM7i/6fUE3UQtupnCjVrep VywQ== X-Gm-Message-State: AMCzsaWqUrfVJGl+iI088N1ph/jap24XL9z5iFIpMuYsFlOG100FPEqH HcXbQ8EbJM5MRrz2Mu17fNN6aHsZOyaGDh2VLo/Uzw== X-Google-Smtp-Source: AOwi7QAwfdqcGtM77Lr6vOFZLEkPLiOE3XaHBnR0i994xoMClm+EjM+RQRiB09iXwXv6TukMiBWXmGQLy2xWJu1a04Q= X-Received: by 10.129.232.4 with SMTP id a4mr943521ywm.294.1507590657805; Mon, 09 Oct 2017 16:10:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 9 Oct 2017 16:10:17 -0700 (PDT) In-Reply-To: <4EDF7DF9-D9C9-4A5B-AA9C-5A39823FA250@sn3rd.com> References: <4EDF7DF9-D9C9-4A5B-AA9C-5A39823FA250@sn3rd.com> From: Eric Rescorla Date: Mon, 9 Oct 2017 16:10:17 -0700 Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary="089e082230a4a024f0055b254df1" Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 23:11:00 -0000 --089e082230a4a024f0055b254df1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this text is good. I suggest "Not Recommended" with a note, and if the IoT groups want to publish their own document updating that note, that would work. -Ekr On Mon, Oct 9, 2017 at 4:05 PM, Sean Turner wrote: > Anybody else has thoughts on this? > > spt > > > On Oct 3, 2017, at 18:53, Sean Turner wrote: > > > > In the IANA registries draft (https://github.com/tlswg/ > draft-ietf-tls-iana-registry-updates), we=E2=80=99ve added a recommended = column > to the Cipher Suites (CSs) registry (and some others). Right now, the > criteria for getting a recommended mark is AEAD ciphers with strong > authentication standards track ciphers. While that=E2=80=99s great gener= ally, the > list we=E2=80=99ve got five CSs that gave Joe and I pause: > > > > TLS_DHE_RSA_WITH_AES_128_CCM_8 > > TLS_DHE_RSA_WITH_AES_256_CCM_8 > > TLS_PSK_DHE_WITH_AES_128_CCM_8 > > TLS_PSK_DHE_WITH_AES_256_CCM_8 > > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 > > > > The CCM_8 CSs have a significantly truncated authentication tag that > represents a security trade-off that may not be appropriate for general > environment. In other words, this might be great for some IoT device but > we should not generally be recommending these. > > > > We=E2=80=99re recommending that these five suites be dropped from the > recommended list. Please let us know what you think. > > > > J&S > > (editor hats on) > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e082230a4a024f0055b254df1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this text is good. I suggest "Not Recommended= " with a note, and if the IoT groups want to publish their own documen= t updating that note, that would work.

-Ekr


On Mon, Oct 9, 2017 at 4:05 PM, Sean Turner <sean@sn3rd.com> = wrote:
Anybody else has thoughts on this?=

spt

> On Oct 3, 2017, at 18:53, Sean Turner <sean@sn3rd.com> wrote:
>
> In the IANA registries draft (http= s://github.com/tlswg/draft-ietf-tls-iana-registry-updates), w= e=E2=80=99ve added a recommended column to the Cipher Suites (CSs) registry= (and some others).=C2=A0 Right now, the criteria for getting a recommended= mark is AEAD ciphers with strong authentication standards track ciphers.= =C2=A0 While that=E2=80=99s great generally, the list we=E2=80=99ve got fiv= e CSs that gave Joe and I pause:
>
> TLS_DHE_RSA_WITH_AES_128_CCM_8
> TLS_DHE_RSA_WITH_AES_256_CCM_8
> TLS_PSK_DHE_WITH_AES_128_CCM_8
> TLS_PSK_DHE_WITH_AES_256_CCM_8
> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256
>
> The CCM_8 CSs have a significantly truncated authentication tag that r= epresents a security trade-off that may not be appropriate for general envi= ronment.=C2=A0 In other words, this might be great for some IoT device but = we should not generally be recommending these.
>
> We=E2=80=99re recommending that these five suites be dropped from the = recommended list.=C2=A0 Please let us know what you think.
>
> J&S
> (editor hats on)

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--089e082230a4a024f0055b254df1-- From nobody Mon Oct 9 18:22:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC87C133221 for ; Mon, 9 Oct 2017 18:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_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 Vl6PyDv9v4JE for ; Mon, 9 Oct 2017 18:22:13 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0117.outbound.protection.outlook.com [104.47.36.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 CD3C4133044 for ; Mon, 9 Oct 2017 18:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b/lLpfFLeiPyvX+rTW0+OScgKvLN7WPWO/RLqvzXQ94=; b=ijtHdovJ6VHkoTtcVCT1cN0nN9Cx/60fzVSf6H7hkMUD6IwolnXZaUI1xlbpWlsMyuhiO1rrXrY++zNgg84PV79IpNWkqJNIkfDtJ6Eutg/q15KaGbx8bEQSEpUzKMs1GpdBl12OJ2VPYz3zAQqOOgpYJSnxjxCRwlIOZ5lwpFs= Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) by CY4PR21MB0743.namprd21.prod.outlook.com (10.173.189.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.156.0; Tue, 10 Oct 2017 01:22:11 +0000 Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0156.001; Tue, 10 Oct 2017 01:22:11 +0000 From: Andrei Popov To: "" Thread-Topic: Labels in the TLS 1.3 key schedule Thread-Index: AdNBZZFet5hTIw0iRN6U8hbIN5dYzw== Date: Tue, 10 Oct 2017 01:22:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:e::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0743; 6:FOSQcW7fS6Gb79N0d++IwnnzaXW9GNJAz4ZSk8xdy9dp7VKak/MuedML3Sk+ZgZjezGbZ2gjNIR7ttUeMU/7Wpbp63cOFchZ6JulnoIPhN5Pb0H+yrLrcL7wjOmlwjctiQeOIpvCqSvggsmtX5sFRGFURg7BfogB4iMU9ZQ92uGTGYHBKa7SYsochXmY7i0RQaUFsmFUc8cuhy1vAIlFqX+A4hzeA0oXQr5DUEqPmebUNm5rkJOu2TBFOO2V3e4NQGVtCPBpwR/4YZXUdVTqMO/5yP3Du75GUOHVpbH9cLYIEsPwlDrXrSSJH/BI/a53lSNn3+BU675pXhjw2NuIwA==; 5:w+GSk2VCCilE3H/ePWZCL3IScPxT8RuRs4EhZrjCz6Arx5TcFyGbbcZvKhU1tkCXPFEAit2GbBjBgIOzDADUWCStKZ1OwLZ5BvajCigKvofW6+mX/kV0OixMXBxaEHLi0iq08YBR6tYCJDhZWxFddA==; 24:PnZcut6VvdNeoTY2Mp/uionj3LhHGRLGdsYAbIZpYE9xJKLeYRz7Zu/l3oET2ZK++VRzJEGnQr+EYxIa0T1SuRjN6sEtOYk95o9XYc4M/E4=; 7:3/keDDBQ1wLiXJyUXccm4vhoFb26a1gMrZjE6p4/d4ewYRbTlz2sJCeYYWkPF/LS7EaGi3bRKt9PYMBpt9ka6QNBbUml3FbjiH5anOlXcS3QD6nw1C+DiYXJ0im85l6KCNtWSyljgtdGhPREgisaaH4KG3NZXuj+TA2+yFjkKTai779fYHQ2yO3JIu5aylWDFjbt0zY3r3ZGHZ3C5JXV3hRUFE5wXjAwrgLz/mrSGtw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c4896c6c-0510-4742-5bc6-08d50f7d5509 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0743; x-ms-traffictypediagnostic: CY4PR21MB0743: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0743; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0743; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(47760400005)(189002)(199003)(7736002)(97736004)(72206003)(478600001)(10090500001)(6116002)(102836003)(10290500003)(790700001)(8676002)(106356001)(86362001)(68736007)(105586002)(8936002)(86612001)(81166006)(81156014)(25786009)(6506006)(6436002)(50986999)(2900100001)(5660300001)(189998001)(77096006)(74316002)(558084003)(53936002)(3660700001)(9686003)(54896002)(101416001)(55016002)(99286003)(6306002)(14454004)(7696004)(316002)(2906002)(8990500004)(3280700002)(54356999)(22452003)(33656002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0743; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB012070DC2B0AD20603DBDD2F8C750CY4PR21MB0120namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4896c6c-0510-4742-5bc6-08d50f7d5509 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 01:22:11.3887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0743 Archived-At: Subject: [TLS] Labels in the TLS 1.3 key schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:22:15 -0000 --_000_CY4PR21MB012070DC2B0AD20603DBDD2F8C750CY4PR21MB0120namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgaWYgSSBtaXNzZWQgc29tZSB0ZXh0IGluIHRoZSBUTFMgMS4zIHNwZWMsIGJ1dCBhcmUg dGhlIHZhcmlvdXMgbGFiZWxzIHVzZWQgaW4gdGhlIGtleSBzY2hlZHVsZSBBU0NJSSBhbmQgbnVs LXRlcm1pbmF0ZWQ/DQoNClRoYW5rcywNCg0KQW5kcmVpDQo= --_000_CY4PR21MB012070DC2B0AD20603DBDD2F8C750CY4PR21MB0120namp_ 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 by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5IGlmIEkgbWlzc2VkIHNvbWUgdGV4dCBpbiB0aGUgVExT IDEuMyBzcGVjLCBidXQgYXJlIHRoZSB2YXJpb3VzIGxhYmVscyB1c2VkIGluIHRoZSBrZXkgc2No ZWR1bGUgQVNDSUkgYW5kIG51bC10ZXJtaW5hdGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHJlaTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB012070DC2B0AD20603DBDD2F8C750CY4PR21MB0120namp_-- From nobody Tue Oct 10 01:21:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B89134A58 for ; Tue, 10 Oct 2017 01:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNA5V8LzGpBF for ; Tue, 10 Oct 2017 01:21:41 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B73134A19 for ; Tue, 10 Oct 2017 01:21:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id B96A15371B; Tue, 10 Oct 2017 11:21:36 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id wS1FUsxkOGfF; Tue, 10 Oct 2017 11:21:35 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 93E80C4; Tue, 10 Oct 2017 11:21:33 +0300 (EEST) Date: Tue, 10 Oct 2017 11:21:33 +0300 From: Ilari Liusvaara To: Andrei Popov Cc: "" Message-ID: <20171010082133.j4tk2epdijrfhawv@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Labels in the TLS 1.3 key schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 08:21:43 -0000 On Tue, Oct 10, 2017 at 01:22:11AM +0000, Andrei Popov wrote: > Sorry if I missed some text in the TLS 1.3 spec, but are the various > labels used in the key schedule ASCII and nul-terminated? The labels _are_ ASCII, but _not_ NUL-terminated. Instead, the labels have explicit length field. Constructing some examples of raw HKDF info blocks (for draft-21), I hope these are correct: Example 1) SHA-256, server handshake traffic secret: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |00 20|12|ASCII(tls13 s hs traffic) | +--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+ | |20| Handshake hash up to and | +--+--+--+--+--+--+ + | including ServerHello | + +--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+ Total 54 bytes, exactly fills one SHA-256 block after HKDF to HMAC lowering and SHA-256 padding (not a coincidence). The byte immediately before the boxed 0x20 contains ASCII 'c'. Example 2) SHA-384 client application traffic secret: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |00 30|12|ASCII(tls13 c ap traffic) | +--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+ | |30| Handshake hash up to and | +--+--+--+--+--+--+ + | including ServerFinished | + + | | + +--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+ Total 70 bytes, fits into one SHA-384 compression, even after lowering to HMAC and SHA-384 padding. The byte immediately before the boxed 0x30 contains ASCII 'c'. Example 3) SHA-256, the "derived" stages (which are just before injecting raw DHE result and just before injecting block of zeroes): +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |00 20|0d|ASCII(tls13 derived) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |20|e3 b0 c4 42 98 fc 1c 14 9a fb f4 c8 99 6f b9| +--+ + |24 27 ae 41 e4 64 9b 93 4c a4 95 99 1b 78 52 b8| + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |55| +--+ Total of 49 bytes. Note e3...55 is SHA-256 of empty input. Another place that uses similar construction is the per-exporter key derivation. Byte 15, immedately before boxed 20 contains ASCII 'd'. Example 4) SHA-384, traffic key update: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |00 30|11|ASCII("tls13 traffic upd") | +--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+ | |00| +--+--+--+--+--+ Total of 21 bytes. Note, no hash of empty input, as this uses hkdf-expand-label as opposed to derive-secret. The byte immediately before boxed 0x20 contains ASCII 'd'. Example 5) SHA-256, inner exporter derivation for label "EXPORTER: teap session key seed": +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |00 20|25|ASCII(tls13 EXPORTER: teap session key| +--+--+--+ + | seed) | + +--+--+--+--+--+--+--+--+ | |20|e3 b0 c4 42 98 fc 1c| +--+--+--+--+--+--+--+--+--+ + |14 9a fb f4 c8 99 6f b9 24 27 ae 41 e4 64 9b 93| + +--+--+--+--+--+--+--+ |4c a4 95 99 1b 78 52 b8 55| +--+--+--+--+--+--+--+--+--+ Total of 73 bytes. Note, this blows SHA-256 block (this exporter inner hash is the only place in current spec that might blow out SHA-256 block, However, if another hash function is defined, that might have its block blown in other places too). The byte immedately before the boxed 0x20 contains ASCII 'd'. Also note that the way the label is split, there is a space between words "key" and "seed". Without the empty hash, this would blow blocks less (e.g., would not blow with this example label), but still could blow them, as the maximum label is 249 bytes, giving 259+ byte raw info block, which exceeds the blocksize of any known hash function). Example 6) SHA-384, deriving IV for Chacha20-Poly1305: +--+--+--+--+--+--+--+--+--+--+--+--+ |00 0c|08|ASCII(tls13 iv) |00| +--+--+--+--+--+--+--+--+--+--+--+--+ Total of 12 bytes (this is the shortest of these blocks). The output is truncated to 12 bytes. The byte immedately before the boxed 0x00 contains ASCII 'v'. Example 7) SHA-256, final exporter derivation step for 64-byte output (exporter label is not material): +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |00 40|0E|ASCII(tls13 exporter) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |00| +--+--+ Note that HKDF lowers into HMAC two times here, since there is 33 to 64 bytes of output, but SHA-256 only produces 32 bytes of output. The empty box in the last row contains ASCI 'r', as the label overflows to byte 16. -Ilari From nobody Tue Oct 10 01:52:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D3D134AE7 for ; Tue, 10 Oct 2017 01:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h55fhwMu5pU6 for ; Tue, 10 Oct 2017 01:52:29 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC43134AEC for ; Tue, 10 Oct 2017 01:52:28 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3yB9py4pK0z25WN; Tue, 10 Oct 2017 10:52:26 +0200 (CEST) X-purgate-ID: 152705::1507625546-00007EC7-6FC01518/0/0 X-purgate-size: 4816 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3yB9py2m3szGpJK; Tue, 10 Oct 2017 10:52:26 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 54FF5404A; Tue, 10 Oct 2017 10:52:26 +0200 (CEST) In-Reply-To: <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII> References: <20171007091720.012fdb7b@pc1> <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII> To: Ilari Liusvaara Date: Tue, 10 Oct 2017 10:52:26 +0200 (CEST) CC: Martin Rex , Adam Langley , "tls@ietf.org" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171010085226.54FF5404A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 08:52:32 -0000 Ilari Liusvaara wrote: [ Charset UTF-8 unsupported, converting... ] > On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote: >> >> Fixing the backwards-incompatibilities in the TLS record layer >> would be terribly useful for streaming-optimized IO layers as well, >> i.e. ensure the the TLS record properly identifies ContentType, >> and that a TLSv1.3 handshake ends with CCS followed by 1 Handshake message. > > Unfortunately, doing that would do really bad things to security. Nope, none at all. I'm _not_ asking for protocol changes, just that the TLS handshake continues to end with CCS + HS, and ContentTypes remain visible. Contents of all handshake messages, and whether and how that content is protected, remains subject to negotiated protocol version which may vary significantly. > > And the middleboxes I am talking about actually parse every cleartext > handshake message. Change anything in any message and they fail. And > fixing some known vulnerabilities in TLS 1.2 is not possible without > changing the structures around. Changing the contents of TLS handshake messages _other_ than ClientHello+ServerHello is fine with me. I also don't care which of the handshake messages are clear vs. encrypted. What I'm mainly asking for is keeping TLS record ContentType visible (Handshake, AppData, CCS, Alert), and having a CCS before the final Handshake record of a TLS handshake. I'm really looking *ONLY* at the TLS record layer semantics. I have an issue with the borked TLS record layer protocol at the *ENDPOINT*, because TLSv1.3 is never going to work as a drop-in replacement for us with the current TLS record layer breakage. This is about (a) streaming-optimized IO for the handshake phase (b) CCS to recognize the final step of the handshake phase (c) and Content-Type visible Alerts to distinguish End-of-Connection alerts (both fatal error or warning-level close_notify) from next AppData record -- so that the body of an AppData record can be left in the network receive buffers and be visible through "network readable" socket event(s). Having to redesign the entire application network read event model in order to juggle around with an unprotected-but-not-yet-processible AppData record would be a royal PITA, as much as not being able to recognize premature client-side termination of a longrunning request (which Web Browser navigation and complex page designs cause all the time). > > In fact, I think the record layer changes in TLS 1.3 actually _reduce_ > intolerance, not _increase_ it. If your middlebox is not as anal as I > described above, it probably falls into copying data back and forth > when it loses the handshake. However, the changes into ServerHello > could easily cause trouble even with such middleboxes. I personally hate network middleboxes other than plain NAT, and I'm violently opposed to MITMs (aka TLS-inspecting network middleboxes). I will certainly not mind if those latter break. Broken non-malicious middleboxes are obnoxious, too, and create a significant & needless support load. A lot of our customers use some kind of totally broken transparent internet proxies, which let TCP connect through, but silently close the network connection after TLS ClientHello was sent. Such behaviour is indistinguishable from a choking TLS implementation, such as Microsoft IIS with SChannel (receiving SSLv3 ClientHello with ClientHello.client_version=(3,3) or a Win2012+ IIS receiving ClientHello without the optional TLS extension SNI). And when telling customers to check their firewall rules, they often come back saying: "but telnet connects". Yup, braindead firewall. > > Here what might work getting around those really annoying middleboxes > (and this is pretty nasty): > > - Add back the session field, echo field from client > > - Add dummy zero into place of compression method, so TLS 1.2 parsers > can parse the message. > > - Add two zeros into ServerHello so the message can be parsed the same > way as TLS 1.2. You mean for ServerHello? Yes, it would be highly preferable to make ServerHello fully backwards compatible (with respect to the PDU parser) so that you don't have to change horses midway while parsing ServerHello. > - Fix ServerVersion at TLS 1.2, send true version in supported_versions > extension. wfm. > - If the version is TLS 1.3, the session id is non-empty and 0-RTT was > not accepted, insert fake ChangeCipherSpec message immediately after > ServerHello and change outer content-type of the next record to 22 > (instead of 23). The client can do the same. fake CCS before the final HS of a TLS handshake would make me happy. :) -Martin From nobody Tue Oct 10 02:00:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CEC134B0F for ; Tue, 10 Oct 2017 02:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77UEzDM71Qca for ; Tue, 10 Oct 2017 02:00:49 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 E15AF134B06 for ; Tue, 10 Oct 2017 02:00:47 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id c77so41956974oig.0 for ; Tue, 10 Oct 2017 02:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M/mTtskQ1e0pjApl5qT02I/gfJlRP50zc6vNE3koq3Q=; b=rWUB4xunHvCAiEhE+oq+9uqvS0CJHkAePrB9WYKo4S0mQ8LFJgqiZSmU9c13dolKhJ MRMS4syemL8Pzu5E9xGnkDfOV0owXBzaZsX7km5+YuE5wrR6tpfL7J0Q8rlDdqO93Y+z CMVQ6TjZLGgHqsf1kW1fRB5HoX8gM0yUCT8wasFkA3mxYo0sdKvjOuvutdwEBrqax69K 2prE7jgMz8lfFsJmM93QxN9u6fO8LRUCsE7+1ZeebKrct6hHu8asbqF2OvUwUF78hcfc /LjiDT8nqlHzjqbrtjSG+y3QREZ+MMx+89vo9OPh5l4ols2vFC55bHsoPCh2ETfkiN/B 8C6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M/mTtskQ1e0pjApl5qT02I/gfJlRP50zc6vNE3koq3Q=; b=eyVoUvMq5hS1zKCdN8xiqqQfQxRGlTqADjEYIzl75rGl+tYpcHGZpLlVu5xdMUKPr2 Dpt2tf9FZCYCQ/7QJ6b1nzXzy21eNHV3YYWKsj7ds1/bEErPk/lWOUQZ/7QqjgL5Zbhr N3UCeXU4WuL6THPuBz32P/TnNbRMLP5NV75sj+Q1/ehc+rqL0rVOilzzLNCMohI002xc b3qjPpCbF9cJbTHGQhaXvYFd6sxWXgMRdhARnPT4NNyfrR66VQ2HSCoC4+5x2uTMlxhH TBW8JG5Y6YV74S5EFDxAp5MlZOk+jlsfYT405Gtl5S+m0GmV9c4OcMK1YE2lkqtxSwnm uBUQ== X-Gm-Message-State: AMCzsaUOrG/OGVlz6CN8TxHGiFr+rfdkQvps8NxDUUN/hGWeQfEE355/ D3mVKE0cokHWVQG1dnWdLd/lVoGHAAgzj/HsA/8= X-Google-Smtp-Source: AOwi7QD4DgQV6LHaRoP57K94dkgXxeHGVZqyugpQg5mTQjNlRXgaEWVldywGOLdhNOWqJ1pZ96y+WquUa0M7sbDeTmo= X-Received: by 10.157.87.75 with SMTP id x11mr1182134oti.112.1507626047219; Tue, 10 Oct 2017 02:00:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Tue, 10 Oct 2017 02:00:46 -0700 (PDT) In-Reply-To: <20171010082133.j4tk2epdijrfhawv@LK-Perkele-VII> References: <20171010082133.j4tk2epdijrfhawv@LK-Perkele-VII> From: Martin Thomson Date: Tue, 10 Oct 2017 20:00:46 +1100 Message-ID: To: Ilari Liusvaara Cc: Andrei Popov , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Labels in the TLS 1.3 key schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:00:52 -0000 On Tue, Oct 10, 2017 at 7:21 PM, Ilari Liusvaara wrote: > Constructing some examples of raw HKDF info blocks (for draft-21), I > hope these are correct: You can see other examples at https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-02 e.g. info (54 octets): 002012746c733133 2073206873207472 6166666963208ac5 1822361c59632de3 c6b259e5808ce52b 8278a6493de2a976 f441abbadc8c Which matches the length of your example. From nobody Tue Oct 10 02:12:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2F134B21 for ; Tue, 10 Oct 2017 02:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 o-LaFSIESMT6 for ; Tue, 10 Oct 2017 02:12:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 75B5F1321DE for ; Tue, 10 Oct 2017 02:12:07 -0700 (PDT) Received: from [192.168.91.203] ([80.92.122.248]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M5IdH-1d46rV07mZ-00zSaN; Tue, 10 Oct 2017 11:12:02 +0200 To: mrex@sap.com, Ilari Liusvaara Cc: Adam Langley , "tls@ietf.org" References: <20171007091720.012fdb7b@pc1> <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII> <20171010085226.54FF5404A@ld9781.wdf.sap.corp> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 10 Oct 2017 11:11:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171010085226.54FF5404A@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:afYPd0Lo9zwGfxipEqDHrTxmOWnKvSgy/I7wE87JlQOeo98AoOR 9FoJ38U/EDrDhlmNrBNK1sQfOiF6ppi7w+rVnVjHJQYcv2H8d/T+qIHTynPzOZGHOhL9Abo px9uAJ5tAgMMY+aAFECaxw7vpgYdUHGOErvk0K/lXDtVQ9b12uOQIfypauzCC5t3irgFS7M LUftkhTihRtejUnfiV3pw== X-UI-Out-Filterresults: notjunk:1;V01:K0:KhV9dEA47/I=:ZGfwcTbze3Qgkar42TSTXV Gktfs5+BMo3oEKp2mHxpmwqBWkEvUrXj6ACBnAE+EAFKUFwgX+nr+Df9MUiTEKeJcdmlC3abN Flu9Ci4SzsfT/pkY/yP9SjexJk+DHQbCqt+RMxL5XWQ27wA/o/5DuJSliA8XGSPU9AKQnxrfU CEKoZoRsTGguVc+IMyRQTK4SmQ207SzyvZC4Rbm5MheReKstJ92p01dZ4J8weRFVoluxRdatH Y23rtn/uE5ZjzKnGESYpM3OzNDTD8JmAhkM8x4oVIyX7rwSKmxYsCk/+M2+Y1wEax+UYeOsOr XnItFKS3D/FpiG0TLTAQIUZyi1Zz7382VZnGxH4hbDY5sn6AzZO12pLTmXfIptWjb+dpfiNBG O/xdf5FJxprJnRRp0sqXNQL5qrJvyq3dgBXKVxQQhksJCKBpaQWjt+zMhmfmI4BqgKUEdW/FS b2XIXzCEMQPzqOqkkpfucXW+QRXrLWWKZQffndNtRtSZtQyh5RcN7b0/108c37Rd2bazgZ3fq ZnO9z1GncWw1oiE1ZHYd4nHe9GVTzKA3fNkY8BVzmN2tYUNOyoWNLIxg+tW3urhjMeOowAhUM wUeDBdHo4SZ9HEJKlGF7N8+ubvzVQ4JG4lpHMJKo+GaLLMfbe837WfSLDwDLxlsVpa6AQhtGx MrgvlfgaLjLzKD9fw5xVG+sQJYquckCqWPzNI59fVvCXRTioqNX8JFXXd7zRhw9FfvwdEiSOO Q5KgxbxkXDTcauiwlGiYOKgYpwIVMDj6rNiML9LaaKvcxKlk0Xt1oTgEttnvSutxVYhfBj9gZ m5UZLj+13gDz1ziLSAXMcS7At5or3zOgQLgh4TvbwJNBRVQeIQ= Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:12:09 -0000 Hi Martin, On 10/10/2017 10:52 AM, Martin Rex wrote: > Nope, none at all. I'm _not_ asking for protocol changes, just that > the TLS handshake continues to end with CCS + HS, and ContentTypes > remain visible. Contents of all handshake messages, and whether > and how that content is protected, remains subject to negotiated > protocol version which may vary significantly. FWIW: Making the ContentType visible is a protocol change since the current version of the TLS / DTLS 1.3 protocol encrypts them. Ciao Hannes PS: I think sending fake ChangeCipherSpec messages around is a terrible idea. From nobody Tue Oct 10 02:42:14 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3E2134BD9 for ; Tue, 10 Oct 2017 02:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 u4rCKucu2dlV for ; Tue, 10 Oct 2017 02:42:05 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA6E134BB7 for ; Tue, 10 Oct 2017 02:41:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E8D5997A0E; Tue, 10 Oct 2017 12:41:51 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id DJwGgHfS8Bup; Tue, 10 Oct 2017 12:41:51 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 17A8521C; Tue, 10 Oct 2017 12:41:47 +0300 (EEST) Date: Tue, 10 Oct 2017 12:41:47 +0300 From: Ilari Liusvaara To: Martin Rex Cc: Adam Langley , "tls@ietf.org" Message-ID: <20171010094147.4hi674k66uapr5cq@LK-Perkele-VII> References: <20171007091720.012fdb7b@pc1> <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII> <20171010085226.54FF5404A@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20171010085226.54FF5404A@ld9781.wdf.sap.corp> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:42:13 -0000 On Tue, Oct 10, 2017 at 10:52:26AM +0200, Martin Rex wrote: > Ilari Liusvaara wrote: > [ Charset UTF-8 unsupported, converting... ] Lol. > > On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote: > >> > >> Fixing the backwards-incompatibilities in the TLS record layer > >> would be terribly useful for streaming-optimized IO layers as well, > >> i.e. ensure the the TLS record properly identifies ContentType, > >> and that a TLSv1.3 handshake ends with CCS followed by 1 Handshake message. > > > > Unfortunately, doing that would do really bad things to security. > > Nope, none at all. I'm _not_ asking for protocol changes, just that > the TLS handshake continues to end with CCS + HS, and ContentTypes > remain visible. Contents of all handshake messages, and whether > and how that content is protected, remains subject to negotiated > protocol version which may vary significantly. Visible content-types cause problems with post-handshake authentication. > > And the middleboxes I am talking about actually parse every cleartext > > handshake message. Change anything in any message and they fail. And > > fixing some known vulnerabilities in TLS 1.2 is not possible without > > changing the structures around. > > Changing the contents of TLS handshake messages _other_ than > ClientHello+ServerHello is fine with me. I also don't care which > of the handshake messages are clear vs. encrypted. > > What I'm mainly asking for is keeping TLS record ContentType visible > (Handshake, AppData, CCS, Alert), and having a CCS before the final > Handshake record of a TLS handshake. I'm really looking *ONLY* at > the TLS record layer semantics. Well, these annoying middleboxes do care about that. > I have an issue with the borked TLS record layer protocol at the *ENDPOINT*, > because TLSv1.3 is never going to work as a drop-in replacement for us with > the current TLS record layer breakage. This is about > (a) streaming-optimized IO for the handshake phase > (b) CCS to recognize the final step of the handshake phase > (c) and Content-Type visible Alerts to distinguish > End-of-Connection alerts (both fatal error or warning-level > close_notify) from next AppData record -- so that the body > of an AppData record can be left in the network receive buffers > and be visible through "network readable" socket event(s). > > Having to redesign the entire application network read event model > in order to juggle around with an unprotected-but-not-yet-processible > AppData record would be a royal PITA, as much as not being able to > recognize premature client-side termination of a longrunning request > (which Web Browser navigation and complex page designs cause all the time). For that, even more annoying than the invisbile content-types is record padding (actual security improvment). If the content-type was always in fixed place, one could usually (at least for GCM and POLY1305 modes) compute the masking value pretty fast, but that does not work because of padding. > > In fact, I think the record layer changes in TLS 1.3 actually _reduce_ > > intolerance, not _increase_ it. If your middlebox is not as anal as I > > described above, it probably falls into copying data back and forth > > when it loses the handshake. However, the changes into ServerHello > > could easily cause trouble even with such middleboxes. > > I personally hate network middleboxes other than plain NAT, and I'm > violently opposed to MITMs (aka TLS-inspecting network middleboxes). > I will certainly not mind if those latter break. Broken non-malicious > middleboxes are obnoxious, too, and create a significant & needless > support load. A lot of our customers use some kind of totally broken > transparent internet proxies, which let TCP connect through, but > silently close the network connection after TLS ClientHello was sent. > > Such behaviour is indistinguishable from a choking TLS implementation, > such as Microsoft IIS with SChannel (receiving SSLv3 ClientHello with > ClientHello.client_version=(3,3) or a Win2012+ IIS receiving ClientHello > without the optional TLS extension SNI). > > And when telling customers to check their firewall rules, they often > come back saying: "but telnet connects". Yup, braindead firewall. Unfortunately, what breaks is mostly not MITM boxes, since ones that are not especially badly coded know not to try to forward unknown extensions (which could, e.g., trigger TLS 1.3). This is about "non-malicious" middleboxes. I put that in quotes, because I have real problems trying to come up with any sort of "legit" reason why these middleboxes try to parse ServerHello (reverse-proxy middleboxes are different story, but the problematic middleboxes appear to be forward proxies). > > Here what might work getting around those really annoying middleboxes > > (and this is pretty nasty): > > > > - Add back the session field, echo field from client > > > > - Add dummy zero into place of compression method, so TLS 1.2 parsers > > can parse the message. > > > > - Add two zeros into ServerHello so the message can be parsed the same > > way as TLS 1.2. > > > You mean for ServerHello? Yes, it would be highly preferable to > make ServerHello fully backwards compatible (with respect to the PDU parser) > so that you don't have to change horses midway while parsing ServerHello. Aargh, The last point is wrong in this context (trying to disguise TLS 1.3 handshake as TLS 1.2 stateful session resumption). The dummy zeros for compatiblity would form dummy session and compression fields. Of course you do not want to insert those if you got session and compression fields already. The two dummy zeros are needed in less annoying compatiblity hack. > > - If the version is TLS 1.3, the session id is non-empty and 0-RTT was > > not accepted, insert fake ChangeCipherSpec message immediately after > > ServerHello and change outer content-type of the next record to 22 > > (instead of 23). The client can do the same. > > fake CCS before the final HS of a TLS handshake would make me happy. :) Well, if there is no client certificate, the final client CCS followed by encrypted handshake record would be end-of-handshake (since the next message would be Client Finished, which always ends the handshake in TLS 1.3). However, if there is client certificate, it would not be, since it would then tag the first record of client certificate. (On the server side, the CCS would be between ServerHello and EncryptedExtensions, and EncryptedExtensions would get tagged as handshake). If dealing with this most annoying kind of middlebox, moving when this fake CCS is inserted is not an option, since trying to move it makes the middlebox choke. -Ilari From nobody Tue Oct 10 02:42:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A56D134BD3 for ; Tue, 10 Oct 2017 02:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMxXa0_Up1ob for ; Tue, 10 Oct 2017 02:42:50 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9D0134BBE for ; Tue, 10 Oct 2017 02:42:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D1D8797A43; Tue, 10 Oct 2017 12:42:47 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id JLcOvjmfYn-H; Tue, 10 Oct 2017 12:42:47 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 0849021C; Tue, 10 Oct 2017 12:42:42 +0300 (EEST) Date: Tue, 10 Oct 2017 12:42:42 +0300 From: Ilari Liusvaara To: Hannes Tschofenig Cc: mrex@sap.com, Adam Langley , "tls@ietf.org" Message-ID: <20171010094242.ciuhjrtbvra74h7g@LK-Perkele-VII> References: <20171007091720.012fdb7b@pc1> <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII> <20171010085226.54FF5404A@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:42:52 -0000 On Tue, Oct 10, 2017 at 11:11:59AM +0200, Hannes Tschofenig wrote: > > PS: I think sending fake ChangeCipherSpec messages around is a terrible > idea. Oh, me too. That was just thinking what it would take to get around some really annoying middleboxes. -Ilari From nobody Tue Oct 10 04:16:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE11C13449C for ; Tue, 10 Oct 2017 04:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 9XaXqlZ1x2oP for ; Tue, 10 Oct 2017 04:16:05 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC05134CA6 for ; Tue, 10 Oct 2017 04:15:56 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3yBF0W1lx0z1HHQ; Tue, 10 Oct 2017 13:15:55 +0200 (CEST) X-purgate-ID: 152705::1507634155-0000088F-F65F4C40/0/0 X-purgate-size: 1872 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3yBF0V4c25zGp0k; Tue, 10 Oct 2017 13:15:54 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9652B404A; Tue, 10 Oct 2017 13:15:54 +0200 (CEST) In-Reply-To: References: <20171007091720.012fdb7b@pc1> <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII> <20171010085226.54FF5404A@ld9781.wdf.sap.corp> To: Hannes Tschofenig Date: Tue, 10 Oct 2017 13:15:54 +0200 (CEST) CC: mrex@sap.com, Ilari Liusvaara , Adam Langley , "tls@ietf.org" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171010111554.9652B404A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 11:16:08 -0000 Hannes Tschofenig wrote: > > On 10/10/2017 10:52 AM, Martin Rex wrote: >> Nope, none at all. I'm _not_ asking for protocol changes, just that >> the TLS handshake continues to end with CCS + HS, and ContentTypes >> remain visible. Contents of all handshake messages, and whether >> and how that content is protected, remains subject to negotiated >> protocol version which may vary significantly. > > FWIW: Making the ContentType visible is a protocol change since the > current version of the TLS / DTLS 1.3 protocol encrypts them. I haven't looked at DTLS 1.3, but from what I remember TLS 1.3 has _two_ ContentTypes, one in the clear in the original TLS record structure, and one encrypted, and the cleartext ContentTypes is IIRC specified to contain bogus/misleading information. Since hiding of the ContentType provides ZERO[*] security value, fixing the cleartext ContentType to carry the true value is not really a protocol change. Conceptually, for the TLS *ENDPOINTS*, I prefer a code layering approach with a transport-free TLS implementation by a huge margin. Falling up and down huge callstacks with arbitrarily incomplete TLS records results in huge amounts of complex, poor and inefficent code. And the IO middleware layer should not have to bother with TLS protocol versions. -Martin [*] the security value of the hidden ContentType is zero, because when capturing an entire TLS session, one will be able to identify the real content types context-free heuristically in 99.5% of the time looking at all records, and when knowing the server, one can determine all the content types in 99,9999% of the time. The hiding of the content type is only sufficiently awkward to break streaming IO of communication layers above TLS, as well as efficient connection state management. From nobody Tue Oct 10 09:48:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F62135001 for ; Tue, 10 Oct 2017 09:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA9Uu73qtNxB for ; Tue, 10 Oct 2017 09:48:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6DA1351A9 for ; Tue, 10 Oct 2017 09:37:21 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EA4F2C04B303; Tue, 10 Oct 2017 16:37:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EA4F2C04B303 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B75B418224; Tue, 10 Oct 2017 16:37:20 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 10 Oct 2017 18:37:13 +0200 Message-ID: <2926423.LMfl7UB4Dy@pintsize.usersys.redhat.com> In-Reply-To: <7412F908-CF35-4239-8F16-A8F30F3F5ABF@gmail.com> References: <7412F908-CF35-4239-8F16-A8F30F3F5ABF@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3446746.eohApETHFC"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 10 Oct 2017 16:37:21 +0000 (UTC) Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 16:48:21 -0000 --nextPart3446746.eohApETHFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 7 October 2017 20:37:35 CEST Yoav Nir wrote: > > On 7 Oct 2017, at 17:17, Nick Sullivan > > wrote: > >=20 > > Yoav, > >=20 > > Let me make a correction to your scenario:. Instead of: > > "You=E2=80=99ll need it for Chrome to work with Google." > > it's: > > "You=E2=80=99ll need it for Chrome to work with Google, Facebook, and m= ost of the > > 10% of Alexa top million sites that are using Cloudflare.=E2=80=9D > What part of =E2=80=9Cnot making any configuration changes until the seco= nd week of > January=E2=80=9D is not clear to you? >=20 > Seriously, I=E2=80=99ve had this conversation with administrators. >=20 > Because if they go to their bosses, they get asked if they can guarantee > that the update will cause no outage. Of course they can=E2=80=99t. >=20 > Then they get asked if Edge has the same problem. Let=E2=80=99s assume th= e answer is > yes. >=20 > Then they get asked if they can turn off TLS 1.3 in Edge using GPO (or > whatever the remote configuration of Microsoft Windows is called these > days). In all likelihood, the answer is yes. >=20 > Problem sovled, no? >=20 > But, they=E2=80=99ll protest, more than half our employees use Chrome. >=20 > So tell them not to use Chrome, says the manager. >=20 > Because for the manager the decision to update the middlebox is all risk > with no rewards. also the middlebox vendor will say that "we do not support TLS1.3", after y= ou=20 spell out that proper TLS1.2 support infers TLS1.3 support... =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3446746.eohApETHFC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZ3Pc5AAoJEJKo0bgB0vX1Xq4P/23cn34LAX9aXFo6sRfJM3xz UOegoSUZMMqy+AlMNBMqJleNPNr/l7RxQhq0i+DJD6qQ3woV9cfPvopHg21dlZm2 gwELqN2O0PH8nOcEuAtHNFBLN97ESa28xfmKGxCeQuy6thG+1IpnfDwIWuE3u+Xb 7fDjEXwBKq9PWrIldvLdwrOfMrO3szXhbxzwU374O43PxX4NrxEJTeCIk1ybz5// PpXncEKEMuDMgfvWD9iQuhJ3WWcGp5hTtUH6LgNKs8tbY6nCmDI7fRIf8mtIABPP BVVKou25MWeVMnz9TR25u4z50HmCbk98nANOoGIJZIsEIQFrkt5J7V70TgkLfjKJ xJ9wWnubTqyIe3szo0SPTncd0R2Xd0uKAjaxT1FFmZSAY/KVpoiF7ZLxyQHLtP+N apJB+ckTa5Uo7IDTERSzylXH1xBAaDqPYKphBRHc5yu0hQOysCMg71CAj7v8geec c0fuZJpeMovjrv+w2faKwfMGmaEG1NWwKZGqehPfBtRgMfsbTEesWhTRZTfvPWXw dOI5h8ULpMtdT3GJBQnrHRmAREctifrPbaGtlMtsa4oP2kt/F3p9d8v1bizsRRi3 InXpWTcAe4K8/enDlIzyZnfK/CGDHbzj9kL6hBQvxNWCBvyqhep+ej2lgh2wAwBl GEMSKDkgI2M6Otr5Cd+g =KgPH -----END PGP SIGNATURE----- --nextPart3446746.eohApETHFC-- From nobody Tue Oct 10 10:03:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C78134E6A for ; Tue, 10 Oct 2017 10:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 v1zupepYGI0J for ; Tue, 10 Oct 2017 10:03:55 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0117.outbound.protection.outlook.com [104.47.42.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 D1606134EFB for ; Tue, 10 Oct 2017 09:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LexxdMpMICneSqw1CZLicCb4cY9mVZObfl1Vaa0Vj7k=; b=QJYhIK2lb/2+C9eM617/UjEjaGJTPzdAkUcwRysQJZzQ+6U5wLxDxbJ+zJpDNnexPvU1qprqaqIvkea7+34VxjBPskprL8gH9DxaMpBgbzPpHtBkQ01/+ho9NHCcMtq3RwFoXRPnFRafB3HEl5QdWleDfF/fpfXbwdIw7dtvEKM= Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) 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.156.0; Tue, 10 Oct 2017 16:57:31 +0000 Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0156.001; Tue, 10 Oct 2017 16:57:31 +0000 From: Andrei Popov To: "ilariliusvaara@welho.com" CC: "" Thread-Topic: [TLS] Labels in the TLS 1.3 key schedule Thread-Index: AdNBZZFet5hTIw0iRN6U8hbIN5dYzwAOzaiAABHfK1A= Date: Tue, 10 Oct 2017 16:57:31 +0000 Message-ID: References: <20171010082133.j4tk2epdijrfhawv@LK-Perkele-VII> In-Reply-To: <20171010082133.j4tk2epdijrfhawv@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:e::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0773; 6:Isjd6nP3lo1Cq6s3pvTr5u8PKmOLx45u6doJEOM9f485fMgCrNfiuUCiEcoKpt6n2oS9lmAH6AxoD1oWVFM4JMegJJe36ROgOuxvOtxeffPpVuxO74WKLs5tQ3qk2fGYwI5N3Pwi1y0eUzXRozSryc1W8nUzpZbrtjK6DPZnMBLwrXGNTl5vLjTQX+L0xBhDENBcMrwhErzV7NqoX93c26faTDXDtNJ2fVtI01f5wPYzZoMT2reMFkXypojHZHiM3oZsHsRaQzKhdNpU9/EUy7AiGstwsLed4DE6RJDnIehBMvsy9AjAngCyJ8tNwh/nB3TEokvHlhV9JP50j7PTJg==; 5:28nj5nwP9Hv1wYfxIdtkwOIaHlQAjlZV9WL5cMatSSu0NBah56SeUckgg0kBViE9w2gZDGPEKDWnicGPEqB7nzltLRWS/VHpCpPzaLvL5tQ99pQDDp5a9Ssj/bu6Zy4rsgeXc66G8a8m89zR1MsCjl5ys7lS4RTB6mxatZEMdvg=; 24:MT5etAm1kWOcmk1bdCyoZLJEWsCll/MwRPdmIbPSPKJ7kOcHu36AqLs6ax0zCUqrqpn9OZIZ+cFUWuDNx4j0kJM3cPXJ73TLqGc9UynwKLk=; 7:dVkRGTilnOf/oXIPHBPn2wjJ+eIAd3Pf10VGhrMbqUkrV/9WfVsNKX5H7V5HwnSvXiIP+tOT/OF1j/Qnxu2VNMIiO0M7Lm8XCRN0rW0Z2CLulrQMEeWysRQ5w0AlH38lQGy6FJhyTlxHiNUhpkjVyFXU+JNkD+FI/NM2AF1o5BHKOrEmacdyh4JhZwP9j3RNA3yNglCiha1S9Q416WjKLioLl6ixEg+IMbH6nN+nFdE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e03ae1af-92aa-4161-2890-08d50fffff3d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0773; x-ms-traffictypediagnostic: CY4PR21MB0773: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0773; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0773; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(376002)(39860400002)(346002)(47760400005)(189002)(199003)(6436002)(22452003)(478600001)(106356001)(5640700003)(105586002)(305945005)(7736002)(74316002)(6116002)(102836003)(68736007)(229853002)(8936002)(9686003)(316002)(5660300001)(55016002)(558084003)(6506006)(77096006)(81166006)(4326008)(8676002)(1730700003)(81156014)(10290500003)(97736004)(2351001)(8990500004)(3280700002)(50986999)(76176999)(54356999)(6246003)(86362001)(189998001)(2906002)(7696004)(25786009)(2950100002)(6916009)(14454004)(72206003)(99286003)(2501003)(2900100001)(101416001)(33656002)(10090500001)(3660700001)(86612001)(53936002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0773; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e03ae1af-92aa-4161-2890-08d50fffff3d X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 16:57:31.3886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0773 Archived-At: Subject: Re: [TLS] Labels in the TLS 1.3 key schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 17:03:56 -0000 PiBUaGUgbGFiZWxzIF9hcmVfIEFTQ0lJLCBidXQgX25vdF8gTlVMLXRlcm1pbmF0ZWQuDQoNClRo YW5rczsgSSBjYW4ndCBmaW5kIGFueSBtZW50aW9uIG9mIGNoYXJhY3RlciBzZXQgb3IgbnVsLXRl cm1pbmF0aW9uIGluIGRyYWZ0LTIxLiBQZXJoYXBzIGl0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIHRv IGNsYXJpZnkuDQoNCkNoZWVycywNCg0KQW5kcmVpDQo= From nobody Wed Oct 11 15:24:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0D8132D17 for ; Wed, 11 Oct 2017 15:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS0vIAE49dbM for ; Wed, 11 Oct 2017 15:24:42 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807EF1326DF for ; Wed, 11 Oct 2017 15:24:40 -0700 (PDT) From: Ion Larranaga Azcue To: Nick Sullivan , Ralph Droms , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO72INxjGwk0f70e0hZ2DWWm8J6Lb99iAgAM9PuA= Date: Wed, 11 Oct 2017 22:24:36 +0000 Message-ID: <1507760676870.14256@s21sec.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com>, In-Reply-To: Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.15] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: multipart/alternative; boundary="_000_150776067687014256s21seccom_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 22:24:45 -0000 --_000_150776067687014256s21seccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm a newcomer here, so I may be wrong in some aspects (I apologize in adva= nce for that) but at least I'd like to give my opinion... I really don't feel confortable with the approach taken in this draft. Most= of the proponents of these kind of "tapping" limit their scope to datacent= ers, but I agree with others in that it should be treated as if it will be = used on the internet as a whole (as the specification does not prevent this= kind of use, and we can't know how users and hosting companies will react = to this functionality being available). It's true that with this approach the client has to opt-in but once it has = opted-in, the client has no control over which third party the encryption k= eys are passed to. Imagine a client opts-in because he knows there is an IP= S within the network and the company hosting the server asks him to (I know= at least one of our clients would certainly consider this). But some time = later a malicious third party manages to coerce the hosting company to prov= ide the keys to them instead (or in addition to) the IPS. From the point of= view of the client, he wouldn't notice anything different (only a change i= n the key identifier but could be due to key renewal)... I think a way to solve this would be involving the client more in the visib= ility negotiation. For me, the client not only has to opt-in to the tapping= , but should also have the possibility to unambiguosly identify the tapping= third-party and accept or reject the connection accordingly. I had some na= ive idea for this but I was unable to accomodate it in the handshake as it = is currently defined (in fact, I don't think this kind of control for the c= lient can be provided without major changes to the handhsake protocol). I also don't like the way security so greatly depends on SSWrapDH1 (as addr= essed in point 6 of Security Considerations). I expect many administrators = will create long-lived keys in order to avoid the work to have to redistrib= ute them, leaving connections open to attack during months after they take = place (until SSWrapDH1 key renewal)... Anyway, I think key life length could be addressed in later drafts, but the= inability of the client to identify (and possibly reject) the tapping thir= d party is a "no go" for me... Ion ________________________________ De: TLS en nombre de Nick Sullivan Enviado: lunes, 9 de octubre de 2017 22:49 Para: Ralph Droms; tls@ietf.org Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Ralph and Russ, This draft addresses the two main concerns I had with draft-green: 1) Client opt-in 2) On-the wire visibility There are clearly some details missing from this draft (such as how Ke is u= sed as a symmetric key), but generally I think this approach is more explic= it and therefore less likely to unintentionally impact the broader internet= if used in the datacenter setting. Nick On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms > wrote: We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS extens= ion defined in this I-D takes into account what we heard from the discussio= n regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Pra= gue. Specifically, it provides an opt-in capability for both the TLS client= and server and makes it clear on the wire that visibility will be enabled = for the session. The new mechanism does not depend on static handshake or = session keys. - Ralph and Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_150776067687014256s21seccom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm a newcomer here, so I may be wrong in some aspects (I apologize in a= dvance for that) but at least I'd like to give my opinion...


I really don't feel confortable with the approach taken in this draft.&n= bsp;Most of the proponents of these kind of "tapping" limit their= scope to datacenters, but I agree with others in that it should = be treated as if it will be used on the internet as a whole (as the specification does not prevent this kind of use, and we = can't know how users and hosting companies will react to this fun= ctionality being available).


It's true that with this approach the client has to opt-in but once= it has opted-in, the client has no control over which third party&nbs= p;the encryption keys are passed to. Imagine a client opts-in because = he knows there is an IPS within the network and the company hosting the server asks him to (I know at least one of our clients= would certainly consider this). But some time later a malicious third part= y manages to coerce the hosting company to provide the keys to them in= stead (or in addition to) the IPS. From the point of view of the client, he wouldn't notice anything different (on= ly a change in the key identifier but could be due to key renewal)...


I think a way to solve this would be involving the client more= in the visibility negotiation. For me, th= e client not only has to opt-in to the tapping, but should also have the possibility to&nb= sp;unambiguosly identify the tapping third-party a= nd accept or reject the connection accordingly. I had some naive idea for this b= ut I was unable to accomodate it in the handshake as it is currently define= d (in fact, I don't think this kind of control for the client can be provided without major changes to th= e handhsake protocol).


I also don't like the way security so greatly depends on SSWrapDH1 = (as addressed in point 6 of Security Considerations). I expect many ad= ministrators will create long-lived keys in order to avoid the work to= have to redistribute them, leaving connections open to attack during months after they take place (until SSWrap= DH1 key renewal)... 


Anyway, I think key life length could be addressed in later drafts,= but the inability of the client to identify (and possibly reject) the tapp= ing third party is a "no go" for me...


   Ion


De: TLS <tls-bounces@iet= f.org> en nombre de Nick Sullivan <nicholas.sullivan@gmail.com> Enviado: lunes, 9 de octubre de 2017 22:49
Para: Ralph Droms; tls@ietf.org
Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00<= /font>
 
Ralph and Russ,

This draft addresses the two main concerns I had with draft-green:
1) Client opt-in
2) On-the wire visibility

There are clearly some details missing from this draft (such as how Ke is u= sed as a symmetric key), but generally I think this approach is more explic= it and therefore less likely to unintentionally impact the broader internet= if used in the datacenter setting.

Nick

On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms <rdroms.ietf@gmail.com> wrote:
We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS e= xtension defined in this I-D takes into account what we heard from the disc= ussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 i= n Prague. Specifically, it provides an opt-in capability for both the TLS client and server and makes it clear on= the wire that visibility will be enabled for the session.  The new me= chanism does not depend on static handshake or session keys.

- Ralph and Russ


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--_000_150776067687014256s21seccom_-- From nobody Thu Oct 12 05:57:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F5C1344BF for ; Thu, 12 Oct 2017 05:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9R1H2_TsRyn for ; Thu, 12 Oct 2017 05:57:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397AC13305F for ; Thu, 12 Oct 2017 05:57:40 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D3FC8C04AC46; Thu, 12 Oct 2017 12:57:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D3FC8C04AC46 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 50BAC62940; Thu, 12 Oct 2017 12:57:38 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Thu, 12 Oct 2017 14:57:28 +0200 Message-ID: <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> In-Reply-To: <1507760676870.14256@s21sec.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <1507760676870.14256@s21sec.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3026514.Y3xAIzhxBm"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 12 Oct 2017 12:57:40 +0000 (UTC) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 12:57:42 -0000 --nextPart3026514.Y3xAIzhxBm Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 12 October 2017 00:24:36 CEST Ion Larranaga Azcue wrote: > I'm a newcomer here, so I may be wrong in some aspects (I apologize in > advance for that) but at least I'd like to give my opinion... >=20 >=20 > I really don't feel confortable with the approach taken in this draft. Mo= st > of the proponents of these kind of "tapping" limit their scope to > datacenters, but I agree with others in that it should be treated as if it > will be used on the internet as a whole (as the specification does not > prevent this kind of use, and we can't know how users and hosting compani= es > will react to this functionality being available). >=20 >=20 > It's true that with this approach the client has to opt-in but once it has > opted-in, the client has no control over which third party the encryption > keys are passed to. Imagine a client opts-in because he knows there is an > IPS within the network and the company hosting the server asks him to (I > know at least one of our clients would certainly consider this). But some > time later a malicious third party manages to coerce the hosting company = to > provide the keys to them instead (or in addition to) the IPS. From the > point of view of the client, he wouldn't notice anything different (only a > change in the key identifier but could be due to key renewal)... >=20 >=20 > I think a way to solve this would be involving the client more in the > visibility negotiation. For me, the client not only has to opt-in to the > tapping, but should also have the possibility to unambiguosly identify the > tapping third-party and accept or reject the connection accordingly. I had > some naive idea for this but I was unable to accomodate it in the handsha= ke > as it is currently defined (in fact, I don't think this kind of control f= or > the client can be provided without major changes to the handhsake > protocol). >=20 >=20 > I also don't like the way security so greatly depends on SSWrapDH1 (as > addressed in point 6 of Security Considerations). I expect many > administrators will create long-lived keys in order to avoid the work to > have to redistribute them, leaving connections open to attack during mont= hs > after they take place (until SSWrapDH1 key renewal)... >=20 >=20 > Anyway, I think key life length could be addressed in later drafts, but t= he > inability of the client to identify (and possibly reject) the tapping thi= rd > party is a "no go" for me... yes, a three-way DH with two certificates (one IPS one EE server) does seem= =20 like a much better approach, especially if IPS certs need to have special=20 flags that make them useless for anything else and cannot be set by CAs in= =20 public CA programs. > Ion >=20 >=20 > ________________________________ > De: TLS en nombre de Nick Sullivan > Enviado: lunes, 9 de octubre de 2017 22:49 > Para: Ralph Droms; tls@ietf.org > Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 >=20 > Ralph and Russ, >=20 > This draft addresses the two main concerns I had with draft-green: > 1) Client opt-in > 2) On-the wire visibility >=20 > There are clearly some details missing from this draft (such as how Ke is > used as a symmetric key), but generally I think this approach is more > explicit and therefore less likely to unintentionally impact the broader > internet if used in the datacenter setting. >=20 > Nick >=20 > On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms > > wrote: We are about > to publish draft-rhrd-tls-tls13-visibility-00. The TLS extension defined > in this I-D takes into account what we heard from the discussion regarding > TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. > Specifically, it provides an opt-in capability for both the TLS client and > server and makes it clear on the wire that visibility will be enabled for > the session. The new mechanism does not depend on static handshake or > session keys. >=20 > - Ralph and Russ >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3026514.Y3xAIzhxBm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZ32a4AAoJEJKo0bgB0vX1G40P/jCfMUjsESf7LjnFC1sj6PBl Iuz/YRiVR6d4VBeQAJsSvfAc9n7U2hgB7NCaWW2ui5tM8hvWcuhhq1kUta4+YZ62 5bN7HDBBJ5SdwWOWie+mARSr8WF4mHbCY7RGjLC356g1TTlqLV/wADg/wIvAnVJC Kykdo2ED6gu0vLQyDLqxntWVXpowqBPZ3Vn4kBhJSvgNtHlVt05hBpAuYBEoiYbB yhUAehDwHUAUoKl1+eSDVYONqvQDe9LXQ6wSO3jay36Zh9/w3KSdKwnVkOGTsLVD buFONJLht8MSjLLkY+JCXjgvwrmSsaw/jpl+xLiZ+Jo4u0P4TDyDs4zXrXuq17v6 rvUZ8oYEXh7+KMGfExObhuR6ScjR79sYp109Xq9rpSXov6rHdSPjkkCLRorSwyak Gsfosr18XYqtiktgIYfPDQfZdZ/IDuP1sjiXJsH/eIdh1tN7ZwVvIHvYBYftxI2f WkqhexpCcCp6atofc773W6d/NtV+lZHLy5hZxWJJWpffpHZNgpvDBCrjvc9oxw+2 UKggVK29yRTpiEF7wYAzYNfmhi3LbmOhQTrJQGKOi+/ig/wYe4GopLBIwyr9Hj45 HrMIk+OzR4E87F/eZhkwFcj0e4UZUb+uUnuyZWJ6lO3FpxlDe+yRqh5+1A1vfz20 JpQfBX8pWtPZxZkz0Aq6 =Fisv -----END PGP SIGNATURE----- --nextPart3026514.Y3xAIzhxBm-- From nobody Thu Oct 12 06:16:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA50F1344DE for ; Thu, 12 Oct 2017 06:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 3UH3QarCMHqM for ; Thu, 12 Oct 2017 06:16:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D64134211 for ; Thu, 12 Oct 2017 06:16:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C98B3BE38; Thu, 12 Oct 2017 14:16:08 +0100 (IST) 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 FSSXBdWU5ejY; Thu, 12 Oct 2017 14:16:08 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8927ABE2F; Thu, 12 Oct 2017 14:16:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507814168; bh=guBg46Xg3Sv1OdKTVxo1dAFTyMOf/3ps8zodQ2UC5qI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vuao7zjZWhCtVDsQ+1MbzhWozqIHlMMNPCxZlsdO7daKWjqowlGAvF8BtSlhomBl3 qJsQdd0quIIv2r8lVDe50mdUBEZySzidMLDvfuOIHI5woMuprPY/VXOhJCcDHgTbLG 6g1EmuzaPjYmVzQLrn+Hf6ss4bMPp12OiU/GOPu8= To: Hubert Kario , tls@ietf.org References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <1507760676870.14256@s21sec.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 12 Oct 2017 14:16:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5AVM2QvW00rJ3LbuUMvd81aBcR3tUnXjC" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 13:16:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5AVM2QvW00rJ3LbuUMvd81aBcR3tUnXjC Content-Type: multipart/mixed; boundary="tVknJiCGf18RxRVo7SpTcOBlBLd0KD3qi"; protected-headers="v1" From: Stephen Farrell To: Hubert Kario , tls@ietf.org Message-ID: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <1507760676870.14256@s21sec.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> In-Reply-To: <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> --tVknJiCGf18RxRVo7SpTcOBlBLd0KD3qi Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable (With the obvious caveat that I hate the whole idea... :-) On 12/10/17 13:57, Hubert Kario wrote: >> >> Anyway, I think key life length could be addressed in later drafts, bu= t the >> inability of the client to identify (and possibly reject) the tapping = third >> party is a "no go" for me... > yes, a three-way DH with two certificates (one IPS one EE server) does = seem=20 > like a much better approach, especially if IPS certs need to have speci= al=20 > flags that make them useless for anything else and cannot be set by CAs= in=20 > public CA programs. >=20 But... even if one did add names/certs for the wiretapper or IPS or whatever then there could be more than one of those who'd like to be able to interfere with the TLS session, and there's no way I can see that makes sense for the client and server to negotiate which wiretappers they allow/like. This is all just squaring-the-circle, TLS is meant to be a 2-party protocol (ignoring CAs) and I don't see any way to make TLS a multi-party protocol that works. S. --tVknJiCGf18RxRVo7SpTcOBlBLd0KD3qi-- --5AVM2QvW00rJ3LbuUMvd81aBcR3tUnXjC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ32sYAAoJEC88hzaAX42i6sMH/i6X+tQKOFYJalz5/otuvAjH 7tPGp20U7LArzMsiNVYspno4gUpB3M4oI5tnX7tbqQzzyS2ZJ5X4zlBPCwRYAqCG Wqoo0eHsix+MY8Taqwsv9YvFoVyDE15CCulpPo7rTgLouyApVlOpDAGpActb1aDi JRvzXI5BMBuHrpyZPMSOzFTFfuvIEQP9Agg0BifQtCwcnHj4RnJNtnH6X/Tb2MY+ Ii34GS0oMDiNcWQsZt0f5tz+ZjI1y4o6ab6dyWcT8rE5PCGVXtsW1vFdFBw1AWWk z18PKqvgb/qsLm8mOhUuOW/+aVqOeAJguKpt7DRE/WBqrq8D0eNnhgmmY1iaBEc= =XmAB -----END PGP SIGNATURE----- --5AVM2QvW00rJ3LbuUMvd81aBcR3tUnXjC-- From nobody Thu Oct 12 13:21:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBF513208E for ; Thu, 12 Oct 2017 13:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RrfZ5u290S2m for ; Thu, 12 Oct 2017 13:21:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B35126B6E for ; Thu, 12 Oct 2017 13:21:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9FB9C3005A6 for ; Thu, 12 Oct 2017 16:21:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id He_Z-bo8ld5E for ; Thu, 12 Oct 2017 16:21:19 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 4A0DC30050A for ; Thu, 12 Oct 2017 16:21:19 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 12 Oct 2017 16:21:18 -0400 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> To: IETF TLS In-Reply-To: Message-Id: <569477A1-424E-4787-809F-296676D868D1@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 20:21:23 -0000 Richard: > Thanks for the update here. I agree that this is an improvement over = draft-green-tls-static-dh-in-tls13, in particular because (1) it has a = mechanism for mutual consent and (2) it only touches the outputs of the = handshake, not the inputs. Thanks. > A couple of points to consider:=20 >=20 > Like sftcd, I would like to see some modeling to verify that this has = the expected properties. (Unlike sftcd, I'm not sure this needs to be = done at the start vs. before it's finished.) It seems straightforward = enough that I don't expect major issues, but it would be good to check. I agree. I'd like to confirm that the extension has the expected = properties, but I'm more willing to do that work if the TLS WG adopts = the draft. This is the order that was done for the TLS 1.3 = specification. > It's worth noting that the approach here is all-or-nothing, in = contrast to designs like mcTLS (https://mctls.org/). The entity to whom = the keys are exfiltrated can make modifications to the session in = addition to reading it. I think this is probably the right trade-off of = simplicity vs. solving the problem, but maybe it's worth considering, = say, a cipher suite with AEAD plus an additional integrity check, so = that you could exfil the AEAD key and not the integrity key. That's = pretty much what we've done in the PERC WG with draft-ietf-perc-double = to allow middleboxes to make some changes to an SRTP packet. I watched the video of the presentation, and the granularity comes at a = pretty high cost. In fact, mcTLS was designed with TLS 1.2, and the = cost would be higher for TLS 1.3 because of the AEAD. The current = extension targets a more simple approach, where after client opt-in the = session secrets are shared with other parties that are in the same = administrative domain as the server. > I don't think the spec is quite interoperably implementable in its = current state, since it's missing important details on how the wrapping = is done (what AEAD algorithm? how do you make an IV?). This is = obviously something that can get worked out in WG, should we decide to = adopt this draft. I am willing to work on adding those important details. Russ From nobody Thu Oct 12 13:23:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC9F1320DC for ; Thu, 12 Oct 2017 13:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 47v8-n9fDLCz for ; Thu, 12 Oct 2017 13:23:51 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B22C126B6E for ; Thu, 12 Oct 2017 13:23:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DB1923005A6 for ; Thu, 12 Oct 2017 16:23:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tZNUzXHgbuoY for ; Thu, 12 Oct 2017 16:23:49 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2E74D3002AD; Thu, 12 Oct 2017 16:23:49 -0400 (EDT) From: Russ Housley Message-Id: <5F766523-2316-41AD-AEB2-AFCC63CE9435@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_89FC27B1-6B56-4015-ACC0-741457E9DE92" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 12 Oct 2017 16:23:48 -0400 In-Reply-To: Cc: Ralph Droms , IETF TLS To: Nick Sullivan References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 20:23:53 -0000 --Apple-Mail=_89FC27B1-6B56-4015-ACC0-741457E9DE92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nick: Thanks for the review. I am willing to work on the missing details = about the use of Ke. Russ > On Oct 9, 2017, at 4:49 PM, Nick Sullivan = wrote: >=20 > Ralph and Russ, >=20 > This draft addresses the two main concerns I had with draft-green: > 1) Client opt-in > 2) On-the wire visibility >=20 > There are clearly some details missing from this draft (such as how Ke = is used as a symmetric key), but generally I think this approach is more = explicit and therefore less likely to unintentionally impact the broader = internet if used in the datacenter setting. >=20 > Nick --Apple-Mail=_89FC27B1-6B56-4015-ACC0-741457E9DE92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Nick:

Thanks for the review.  I am willing to work on the = missing details about the use of Ke.

Russ


On Oct 9, 2017, at 4:49 PM, = Nick Sullivan <nicholas.sullivan@gmail.com> wrote:

Ralph and Russ,

This draft addresses the two main concerns I had with = draft-green:
1) Client opt-in
2) On-the wire visibility

There are clearly some details missing from this draft (such = as how Ke is used as a symmetric key), but generally I think this = approach is more explicit and therefore less likely to unintentionally = impact the broader internet if used in the datacenter setting.

Nick

= --Apple-Mail=_89FC27B1-6B56-4015-ACC0-741457E9DE92-- From nobody Thu Oct 12 16:14:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D2813219E for ; Thu, 12 Oct 2017 16:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJmNv9-URBfF for ; Thu, 12 Oct 2017 16:14:23 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 EEB811326ED for ; Thu, 12 Oct 2017 16:14:22 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id k31so16572989qta.6 for ; Thu, 12 Oct 2017 16:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=u3fzO28eVzlplGQP4wHa3AkL44rt1LgB/QRWjxSw6GI=; b=b8loUHgC+B+2sA6VsRuqyQqcX/1GWCyoafRQWKbKxKow0jFC5fYcgVTJaiWiM79pMF NoGb3YCCJ4kurx2NB3CfjImM1N5Cnf2CZhpyc7tTOecROdJxUl/pOjKAqRUfw093Daew UpAx9BXQPsWxr78hkm/dpglndbNfi2jIiwL1UmktyHPF8+KxMF7BVDkr2cJzpOk1gOcJ FH8x2wSq7whtZOmKaDtkpleswshWVTeEYbyqlSNdWeiLuYuLw+lPVsFmTMAZl4F5hAjx kNVtFz4kx4tpTDvKBo2w12wbhL/WswCUqERfhze30F6pZB/AvYYwT5534aDK2qyb1gYg DGqw== 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=u3fzO28eVzlplGQP4wHa3AkL44rt1LgB/QRWjxSw6GI=; b=SzBCNh6EattAXY14Rn6rr+B5t6QlbU2pzzFVGVBOBs7n0YlS8u6bW4c7lYcI/r9Ytc 6gXyYZlIrnFgQ57uTyf3WCLnDGTM/NUpme6YjU/4IwdAQojXHBvSHWexwIUaIfoQ7pfs 9i3yDMJkGTT6UNP71pAbYGcIVdcaWAmoJFObn3kuy7Ri+iOVwvk/1FyvdIX/GKG53Grs UJCpfCw0AF5XazFGxX77mTt60RIIDqnl7bc88My/YZOOD9rE6bftSDcLPOydlX/4KsfK PsL3+psstTduRbJ/8EeSvDHym2aln87ypdRpVOOgwgtCLJrorOsI83yn2e1Uo+F42nzO 86gQ== X-Gm-Message-State: AMCzsaVov1k72ZsBuSCtYK8JFTOg8HixLskihTw9oJRUhhG1vz90oKnD VUEqt4V003xA34TY+6cVADbiERVcFRhfLUgqbYgUs9WTC+I= X-Google-Smtp-Source: AOwi7QCg+OioImulsATIij/xYH0nR4DIVdTT796uYMQaXTYVRk9PKPcDv7eJJcXtAwzGSYFA+LhOqAUoN7orNQLZ3zM= X-Received: by 10.13.192.196 with SMTP id b187mr2838013ywd.416.1507850061968; Thu, 12 Oct 2017 16:14:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Thu, 12 Oct 2017 16:13:41 -0700 (PDT) From: Eric Rescorla Date: Thu, 12 Oct 2017 16:13:41 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114edd4851b4b8055b61b3b1" Archived-At: Subject: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 23:14:24 -0000 --001a114edd4851b4b8055b61b3b1 Content-Type: text/plain; charset="UTF-8" Hi folks, I have just posted a first cut at a connection ID draft. https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 Comments welcome. -Ekr --001a114edd4851b4b8055b61b3b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I have just posted a first cu= t at a connection ID draft.

Comm= ents welcome.

-Ekr



--001a114edd4851b4b8055b61b3b1-- From nobody Thu Oct 12 16:33:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549ED132D17 for ; Thu, 12 Oct 2017 16:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn_M6RNkbTYz for ; Thu, 12 Oct 2017 16:33:08 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 EE441132403 for ; Thu, 12 Oct 2017 16:33:07 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id m198so10962869oig.5 for ; Thu, 12 Oct 2017 16:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6r+cmQXt0Vi9Z6qTH3KgG/wYtH/Z3uo9Mni6npuV71A=; b=Rv8arvElspwvX/VRLtsaRl3XhJWqVqy5yMaehLwjOTl7nK9uxY2V93R2Wq1ZWfDiRJ 0YQ8PKuJSbEsS84hQ/m2MrLd8iB0e1VHYUxirG064bUHvZAyAND8e6+16DMYQxmYg+SH GvBUQP7bDt247kqs6PTC1tmtTLmYacRH4pjJkhQMtGJ9zrsvv6rvAvYhY8Rd5fUJE+Pb SRTsoXO/VprXlY4RvFf9i2wc6g88RUCZ/8WObSUfNtTKanCB5ggas5hqr4exc6aUca74 a9JIjpG346gKbHf5KcfvPbhvYrD1IR66Oi1TiuKq16THW2W5tQCvuuYoJ1kdBQSA3EYM fohA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6r+cmQXt0Vi9Z6qTH3KgG/wYtH/Z3uo9Mni6npuV71A=; b=V+NK5sxXDQvSOERAkpCzGqNrlBfG5Op1HcmZzcf7meNsoooBDNhtO68RfwC+5ZpPy/ rITUPKqrJVY+NK9v/ASX89MkuWIFUat8elF+Re7EcQloixXw/2MCDk8BogJdmbG488n2 I+QYB1jlPR1DfgGRWDOAP1cyhjckaaGIqQwV3Vfa6rC/3PrMwG9oQpc2G4YE2tf9brcv DXcoT1lSL6SvwXo61F/uVEM+twN34RevYX6xXbmwjASVrIwCPPr+BzUK4BdqbOyhvwdM u6B1oY8Z4/JKIBTJT2wFaIVNtLj7ttEADfMzndZAvIfWF06n+pjNbeczYNKm2JbVPkgX duRQ== X-Gm-Message-State: AMCzsaXbHYqqmyTJkPfuZ/FNnTq3jGSgOjkfyd5BVmPpZhEvXBCe7i5T G/LyEoOPZVidAEUapvWGEoR4Iwe0R2Nfz0dRRW19Uw== X-Google-Smtp-Source: AOwi7QCw3nTk3hZpuUwDPa7ZIjlBEVDnmi20dXh7K2kLXngWF1W4OK0eQOUz9Lfuf8uMOkeJg4k2ls6jpq9+mLFlXm8= X-Received: by 10.202.75.140 with SMTP id y134mr1922680oia.3.1507851187250; Thu, 12 Oct 2017 16:33:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Thu, 12 Oct 2017 16:33:06 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 13 Oct 2017 10:33:06 +1100 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 23:33:09 -0000 This seems like a pretty solid design. (Better in many ways to the QUIC design, but then I might concede that the constraints are different.) The example shows the connection ID only being used after the handshake completes (that is, on epoch=3), but handshake records (epoch=2) use the same record format and we already know the preference of the peer when sending them. I can see why you opted for this design (there is no way for the server to signal that it intends to use the connection ID before it starts to send it), but that could be addressed by moving the extension to the ServerHello. The value is sent on every subsequent record, so there is no real gain in having the extension in EncryptedExtensions. There is value in having record construction be consistent. The design for new connection IDs is clearly to handle the linkability issue, but the draft doesn't propose a solution for linking based on the monotonic increase of sequence numbers, or acknowledge the problem. We had comments about the length of the connection ID and the value being used as a covert channel. That issue should at least be addressed in the security considerations. On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla wrote: > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > Comments welcome. > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Oct 12 16:50:06 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8730D1326DF for ; Thu, 12 Oct 2017 16:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB8fddi0TQwO for ; Thu, 12 Oct 2017 16:50:02 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 3FCFB13219E for ; Thu, 12 Oct 2017 16:50:02 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id q4so16704360qtq.8 for ; Thu, 12 Oct 2017 16:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2ZBhGLZk6bMK6mD2nLjQ6W7GdsqicTfV3HSNVFAvO98=; b=VG4DXH9OFUfggtay0P3dzvPERywmt73iGxugVi7t64n3cTHG+kgfvVHq0/BqxzxYHY 9NhwzNWf1UkCpNh0BRExtbtqjUHX6TgywT9PNOy/jc9KZvmWnpXUKdnD9s7BIzsHpRmH R4O6Qq45MMkN0l8sWNRwStjoV3FUVxESxFOTCWzjINpzePd3uRrbtAn8tycjH7XFIJuA xBDr2V1V1OlkEYyj7nU48AUoPIMBu7+8cBgyy7S8C8DagcVIcO0XY8XApbRcVufQww7Q HrYLnmahwWJGzKhDjZaYGblpzdON4NcCvSWlk16/hp6tCoxtv8iOYzP0jVPaXo4D4ym0 YXeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2ZBhGLZk6bMK6mD2nLjQ6W7GdsqicTfV3HSNVFAvO98=; b=OCaJxRKHAZS5ocKA0pFCJUjcezT+ryuXyAIUmxPC4Sybv7NlwYvXJLxtHI2fbWp3ti 4n5y6jXGYagpw1ncshicr8eSyqtVnvxaA1QwdU6DatVvMMiv/GbrJ4Ihd1NKtkNBiJhj MfQm7qk6dae3iMIu0oj2vHITl8uNRd1/pNPsEzUmdQUHEiw6M8SrypNjHc3FsCMa6ONS q90EwHW9e4DR4Eq67tfDu0Bxn3te47zyYTS9cG87dN1SIN7ZzG2VCwHitMRKylbdS4Bo JIt1rjPl3Cte36/8HjuqXknavZ8bhIMFrEMjWAmA+XzKrP+K0/YHIJfwoP8B6M22sQrG JhuQ== X-Gm-Message-State: AMCzsaV4GOOQyQra7IcccrRORsTIri3daoEfEaPDos6O9BxEoH+tl58j fr2MNK7zT2/p8uxd5O4OyGxprSk4HdPIIA8FmgUZ2iPxHQs= X-Google-Smtp-Source: AOwi7QDPiYln+XaJfDQZ6XMvmc99uvp3wsRynKNDqHw+eQKbZshW+iXMgeYVzy1dbSY7KXBGjyUjv4o5mDbU+evL0ko= X-Received: by 10.37.1.7 with SMTP id 7mr2828451ybb.419.1507852201302; Thu, 12 Oct 2017 16:50:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Thu, 12 Oct 2017 16:49:20 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 12 Oct 2017 16:49:20 -0700 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113cfcacd55433055b623281" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 23:50:04 -0000 --001a113cfcacd55433055b623281 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 12, 2017 at 4:33 PM, Martin Thomson wrote: > > The example shows the connection ID only being used after the > handshake completes (that is, on epoch=3), but handshake records > (epoch=2) use the same record format and we already know the > preference of the peer when sending them. I can see why you opted for > this design (there is no way for the server to signal that it intends > to use the connection ID before it starts to send it), but that could > be addressed by moving the extension to the ServerHello. The value is > sent on every subsequent record, so there is no real gain in having > the extension in EncryptedExtensions. There is value in having record > construction be consistent. > Oops. It *is* in the ServerHello. This is an inconsistency because an early draft had it in EncryptedExtensions and I just didn't update the example right. "enables encryption early in the handshake phase the connection ID will be enabled earlier. For this reason, the connection ID needs to go in the DTLS 1.3 ServerHello. " It's fixed in the draft. The design for new connection IDs is clearly to handle the linkability > issue, but the draft doesn't propose a solution for linking based on > the monotonic increase of sequence numbers, or acknowledge the > problem. > Sorry, that's a good point that somehow didn't make it from my head into the draft. In DTLS, it's actually pretty easy to handle this in DTLS b/c you don't need contiguous ranges except for anti-replay, so the sender can just jump forward and then the receiver can keep a per-connid table. I've filed https://github.com/ekr/dtls-conn-id/issues/2 to address this. We had comments about the length of the connection ID and the value > being used as a covert channel. That issue should at least be > addressed in the security considerations. > I filed: https://github.com/ekr/dtls-conn-id/issues/3 That said, I'm not sure that any plausible length CID can avoid this. -Ekr > > > On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla wrote: > > Hi folks, > > > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > > Comments welcome. > > > > -Ekr > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --001a113cfcacd55433055b623281 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 12, 2017 at 4:33 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
The example shows the connection ID only being used after the
handshake completes (that is, on epoch=3D3), but handshake records
(epoch=3D2) use the same record format and we already know the
preference of the peer when sending them.=C2=A0 I can see why you opted for=
this design (there is no way for the server to signal that it intends
to use the connection ID before it starts to send it), but that could
be addressed by moving the extension to the ServerHello.=C2=A0 The value is=
sent on every subsequent record, so there is no real gain in having
the extension in EncryptedExtensions.=C2=A0 There is value in having record=
construction be consistent.

Oops. It *i= s* in the ServerHello. This is an inconsistency because an early draft
had it in EncryptedExtensions and I just didn't update the exampl= e right.

"enables encryption early in the han= dshake phase the connection ID will
be enabled earlier. For this = reason, the connection ID needs to go in
the DTLS 1.3 ServerHello= .
"

It's fixed in the draft.


The design for new connection IDs is clearly to handle the linkability
issue, but the draft doesn't propose a solution for linking based on the monotonic increase of sequence numbers, or acknowledge the
problem.

Sorry, that's a good point= that somehow didn't make it from my head into the
draft. In = DTLS, it's actually pretty easy to handle this in DTLS b/c you don'= t
need contiguous ranges except for anti-replay, so the sender ca= n just jump
forward and then the receiver can keep a per-connid t= able. I've filed=C2=A0

We had comments about the length of the connection ID and the value
being used as a covert channel.=C2=A0 That issue should at least be
addressed in the security considerations.

I filed:

That said, I'm not sure that any plausible length CID can avoid = this.

-Ekr
=C2=A0


On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> Hi folks,
>
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html= /draft-rescorla-tls-dtls-connection-id-00
>
> Comments welcome.
>
> -Ekr
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113cfcacd55433055b623281-- From nobody Thu Oct 12 17:07:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA872132403 for ; Thu, 12 Oct 2017 17:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpFKZwztGXWr for ; Thu, 12 Oct 2017 17:07:08 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA0F13219E for ; Thu, 12 Oct 2017 17:07:08 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id v9so11078537oif.13 for ; Thu, 12 Oct 2017 17:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xixHViOHUmN9e0efrS+5hwxcgT/NGKHbW96/PEXDW20=; b=XpLkeNE3nZeWH4ayIG9oD609zHcZiPTuzJNOEvXwLMUkH0KbXn19yhgEqc7+gcurl4 EJI7GZqgp7xH73O76LgctMT5KHTxa50sp7kBpctNjHT57zlnG8KeYhBS29jfPR7qLS2o iglw5R+gv297Ft/3HM/Wc/ZifHf7nFynHAyqn8ePX+lXje3bcHvS0VMoa07lu0hoMAp+ bgdqNPzLOSuUhRqd9bbL6CRZp8hq6ILXiDWg0qkRSVf9bW/tULTdq3Ozh7JAsxOwib09 Fqx6cVJri8OfVluJqP7Zr8z4Q4Ik6drY5mbEhzEp1FQLpB4Geg+/qBEZOFMgDBQtYyTZ Lf5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xixHViOHUmN9e0efrS+5hwxcgT/NGKHbW96/PEXDW20=; b=XIDkX+rVrceRcczK+JWVa37aSOWTsstomxzewR1myHcaj3TrPsR7zJ85YPaFWDgpQY pRDd+xtRAqTylyjrTx6EGtSGr5tvKpdt4fsBlwHjA5l6WsC/grl+mAy0WIWTL0U3+i68 YnBVtrbRN2rbuN2BoKYk/K4Gnyx0uCzNyPt2uGQkntE9a1sOSagEJU9wzbEiaIID+ezZ dCHByR/X9NTuKsYljtfeLVj5BGNbCIpl2+Zs7xPjkw/vws0acyy+EWTrZeCEfS/rafjp 5CfYQo1LLkxuaxyAzOCcq8h/owl4nWXt282irZqGn6hkMWgGtPflD+pEgnJjGaQKXW6/ EGqQ== X-Gm-Message-State: AMCzsaVtFo7S7NUEC2TIgO3wXZxAMfo4a25veKsnmEbDWGCxhtkLI0Vx l1as7OxlsPCOFG/oDP4Uan5Yd1pyw1Tuu9z5kao= X-Google-Smtp-Source: ABhQp+QyQPh+g3AkwkhpHlHM6gYS4NNpNsIewoCgInBH7EsVo9KKxCIYQ2Ar1YH++hxtvxbWyQxCWmLhbE8RWLMgTQQ= X-Received: by 10.157.52.53 with SMTP id v50mr2898371otb.35.1507853227667; Thu, 12 Oct 2017 17:07:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Thu, 12 Oct 2017 17:07:07 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 13 Oct 2017 11:07:07 +1100 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 00:07:10 -0000 On Fri, Oct 13, 2017 at 10:49 AM, Eric Rescorla wrote: >> The design for new connection IDs is clearly to handle the linkability >> issue, but the draft doesn't propose a solution for linking based on >> the monotonic increase of sequence numbers, or acknowledge the >> problem. > > Sorry, that's a good point that somehow didn't make it from my head into the > draft. In DTLS, it's actually pretty easy to handle this in DTLS b/c you > don't > need contiguous ranges except for anti-replay, so the sender can just jump > forward and then the receiver can keep a per-connid table. I've filed > https://github.com/ekr/dtls-conn-id/issues/2 to address this. That only true if we don't truncate the sequence number. >> We had comments about the length of the connection ID and the value >> being used as a covert channel. That issue should at least be >> addressed in the security considerations. > > > I filed: > https://github.com/ekr/dtls-conn-id/issues/3 > > That said, I'm not sure that any plausible length CID can avoid this. I agree. Anything too short is going to be useless for the use cases we care about, but anything long enough to be useful is ripe for abuse. We can acknowledge the problem though; and maybe suggest that endpoints that care about this could at least disable the extension. From nobody Thu Oct 12 17:22:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E2C132F76 for ; Thu, 12 Oct 2017 17:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGDwssjKND7V for ; Thu, 12 Oct 2017 17:21:57 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BFA13219E for ; Thu, 12 Oct 2017 17:21:57 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 1so16811851qtn.3 for ; Thu, 12 Oct 2017 17:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R6fhd3AJhhm+JcaA3H+yeQ7rVPviluOWEXW031i5cOg=; b=Rk4w29Oe+o21uJrWhVL5//yMQA7T5xtd7EjQNK8ugyVxfta/pkwzB5dDIcCbTPwUDW 0lp6Zw1ePYGbIrCgzRPoXkS4MTesxThlqdrCZmBWZIOl8lErVi2JzZQIe3+OccE7A2aE VjDRdaQlnqRlvIEHZQ34ye3OqRdx19bkBpiZ6ygd40oq0k4UtlmBgHUKy61017Evcywl KMpYE1z8WWYXGIXwmFSZv+TfKvw579v5Ja8NFA2HNKjA+9ZNKbjCDSltRGRQfEx2nTwx FFqumusKUPNAsq/Ta/lDhTjCFh1Bi44hp8f5CrHDcrz9g5Zo6NNLCgAHCsUew/hlQQww 2zng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R6fhd3AJhhm+JcaA3H+yeQ7rVPviluOWEXW031i5cOg=; b=r41Q4dO4TyGgYNOM+h1kjDbYEeSNcP66EEObj1Fdz1qVI7xPYYBZAZ7qwWyMrEdVlm ywDm/xFy+RSwfC2J+APNclyfX3S+oc/KTnsaJPPCgj3NMPGci00lq0mL2XTdUCSCmVu3 LoO6WORS/NEjZkjNG6uPdrb4GBxQ/KhjrL9/jp5bXGYQcwMGv1Uam4rrA1m4iBCD/LOC 2zDxeQFWeLFohE8atYoGQdirt5AXIEr4yJb92rqUnnJoHLuPb0M2iT89wAMTkyPyWxEs sjazhkm1RRV5FYN09J23S0pp1LrqMb3Sz1SeEyu2zHh2+o1u7+Yej4CZ3y36we1K39Vd 7KMA== X-Gm-Message-State: AMCzsaX/1OISZugGFGSgppktIQOgohz7z7KUB/WeQ2HH7eZd0Z6WxQrm FmJczizGeh9nBZ3oHE424PRI+P376wuWaCizEANFWQ== X-Google-Smtp-Source: AOwi7QCQuRSUhHtyyOnueqpnf0NjehcxRycCnkiJTfnUcz+5pKj+eJFdALSgBWGOkaohTkrQcF3jam2DXQ3wBtX9wFg= X-Received: by 10.129.173.99 with SMTP id l35mr2945425ywk.132.1507854116670; Thu, 12 Oct 2017 17:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Thu, 12 Oct 2017 17:21:16 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 12 Oct 2017 17:21:16 -0700 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045e8bdeff6549055b62a453" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 00:21:59 -0000 --f403045e8bdeff6549055b62a453 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 12, 2017 at 5:07 PM, Martin Thomson wrote: > On Fri, Oct 13, 2017 at 10:49 AM, Eric Rescorla wrote: > >> The design for new connection IDs is clearly to handle the linkability > >> issue, but the draft doesn't propose a solution for linking based on > >> the monotonic increase of sequence numbers, or acknowledge the > >> problem. > > > > Sorry, that's a good point that somehow didn't make it from my head into > the > > draft. In DTLS, it's actually pretty easy to handle this in DTLS b/c you > > don't > > need contiguous ranges except for anti-replay, so the sender can just > jump > > forward and then the receiver can keep a per-connid table. I've filed > > https://github.com/ekr/dtls-conn-id/issues/2 to address this. > > That only true if we don't truncate the sequence number. > Maybe I'm missing something, but I don't think that that's correct. as long as you're willing to (a) restrict the jump to the same size as the transmitted part of the sequence number and (b) do a little trial decryption. We could, of course, also adopt the sequence number hopping scheme that we use for QUIC, which works without trial decryption. >> We had comments about the length of the connection ID and the value > >> being used as a covert channel. That issue should at least be > >> addressed in the security considerations. > > > > > > I filed: > > https://github.com/ekr/dtls-conn-id/issues/3 > > > > That said, I'm not sure that any plausible length CID can avoid this. > > I agree. Anything too short is going to be useless for the use cases > we care about, but anything long enough to be useful is ripe for > abuse. We can acknowledge the problem though; and maybe suggest that > endpoints that care about this could at least disable the extension. > --f403045e8bdeff6549055b62a453 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 12, 2017 at 5:07 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On Fri, Oct 13, 2017 at 10:49 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> The design for new connection IDs is clearly to handle the linkabi= lity
>> issue, but the draft doesn't propose a solution for linking ba= sed on
>> the monotonic increase of sequence numbers, or acknowledge the
>> problem.
>
> Sorry, that's a good point that somehow didn't make it from my= head into the
> draft. In DTLS, it's actually pretty easy to handle this in DTLS b= /c you
> don't
> need contiguous ranges except for anti-replay, so the sender can just = jump
> forward and then the receiver can keep a per-connid table. I've fi= led
> https://github.com/ekr/dtls-conn-id/issues/2 to address this.

That only true if we don't truncate the sequence number.

Maybe I'm missing something, but I don'= ;t think that that's correct. as long as you're
willing t= o (a) restrict the jump to the same size as the transmitted part of the seq= uence
number and (b) do a little trial decryption.

=
We could, of course, also adopt the sequence number hopping sche= me that we

--f403045e8bdeff6549055b62a453-- From nobody Thu Oct 12 17:44:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432F31330B3 for ; Thu, 12 Oct 2017 17:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RejmVmgF-OMC for ; Thu, 12 Oct 2017 17:44:28 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 64733132397 for ; Thu, 12 Oct 2017 17:44:24 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id g125so11421844oib.12 for ; Thu, 12 Oct 2017 17:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8tATlEHvKlQij4F+4DB2WIpLGfAyMTZHpWa2UpnApxY=; b=RU8993U1MVTZS17cB62dGLUUM5B/hXzkdZmSjLqeegMxfarwzj98xpRP4YMhaX8+Ej lrbr3yTU9vyZlLe9FVf6//RLSnjROE8Uk0rSenulNzh9md67tMHU3DhK8B2L3c919ErL E04x0WI+K+9AtLIFvPtclQPJga5f4Ag3QPSupCHE4JOgMoxcumPRfkeZNyhrhu2yxNha sWnrmO9/xKKyrb20Am9dmP1Yo5lukEVfPznj6hXs4w7BbbXAZpv3bBcHNR0HoAde+leE yArjz7HTpc+oeN3MvLVd46Qdz9Rr3Cg6PT+zzhIAs+K5k+uf8iBiGslGTKJGYyURV2Zz +xhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8tATlEHvKlQij4F+4DB2WIpLGfAyMTZHpWa2UpnApxY=; b=jnAI+2DgVmuoy/KocK6KuzksGDbQ7sEvGljE7bGpMmlvIbNQFBkFswNSiiUsBbwo5U 0fDODblJQWrPGMtluYDphNTf4QPU9Kt9/71Gn5JJ5/AGAYdoCCvKrOBHTfIPhYSS6iH2 zmgvKpBd+DwXOEleMGCx6kvnSZPwB52RHuI2sF2aJ0X9zzDzPPVns9veom8t+1lpJ8+U nFpUH+Ex0bacR586Qwqprsfod7wEIVXmjiAPi+OHxk7CJ2EEtePqU2ISGRqynZKgBVCJ Gjo7Scyb+Zr2p+qfv9x3YGkIYwHTNHPHYAURrkImG+tHh8MmY9q4CDYKCxTWlyT3Nfd7 BHTQ== X-Gm-Message-State: AMCzsaW4oJm1XNB5VmPPQRhdj2Xkuj/0tUfAPoV1zPLDBjN9iLWXaJWl 0s8AjSxmxMPONaLKvDRPqUJ1jiWl3MWi+jBEhzI= X-Google-Smtp-Source: ABhQp+RX0uAKIw5PkcIed3zyLdrwP2yqZ3+oUsltDmUBpdR7SX/XYIXBVqetUSkZ5LdmvX4nzQN6A+KV3rnNeTA3CeY= X-Received: by 10.157.51.146 with SMTP id u18mr2493610otc.98.1507855463799; Thu, 12 Oct 2017 17:44:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Thu, 12 Oct 2017 17:44:23 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 13 Oct 2017 11:44:23 +1100 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 00:44:29 -0000 On Fri, Oct 13, 2017 at 11:21 AM, Eric Rescorla wrote: > Maybe I'm missing something, but I don't think that that's correct. as long > as you're > willing to (a) restrict the jump to the same size as the transmitted part of > the sequence > number and (b) do a little trial decryption. > > We could, of course, also adopt the sequence number hopping scheme that we > use for QUIC, which works without trial decryption. Either works for me (I was operating on the assumption that we would avoid trial decryption). From nobody Thu Oct 12 18:00:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB81A1344B0 for ; Thu, 12 Oct 2017 18:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SXKRh86GY7e for ; Thu, 12 Oct 2017 18:00:33 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 6A9D9133057 for ; Thu, 12 Oct 2017 18:00:33 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id f15so16907830qtf.7 for ; Thu, 12 Oct 2017 18:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=He5RaWXkRfcVgve/IXp+Rw0WbFl3Wuds7MFYEpH/NzU=; b=yx+un5i3F3IdbpBpOO9DKHSWki6OxQhVQ3MrFC8eMlgoJMKF6ScqS0OvfjV5I6vbHP ZYDw0ohscqle5UEHybBkb8hv/miC0vRGqz50EF+oLwdw2iaXlhHmldB7rD5ziZpLdyox 2dUAIwSbt7niv/xFZDnQW2gRrFU0wwwvmLyG05hVLUKjZVKOuYOGjRx61KM6mRfKFOJ/ 5F/yMiBWdKw+k3lZDCXEgkKQexxVSWwt2QinWkH6P4SLOBdcLdZGEVyMKMDSjKE54vLF ZYBEm3n0JffUBjK6/qUgUnnm/zEDGoNfFaiM0W2zwxrK2zkj+xfMKOMNHvHCxC0KlMAp SaSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=He5RaWXkRfcVgve/IXp+Rw0WbFl3Wuds7MFYEpH/NzU=; b=iVXvOLHxjmiMxJs11+mCcswz+apuGJTMV0HMTDQZK8i/3lM/T6tg7PLGid4+lwImgE QifxB7tpJQl56VPut71l57T+i3vGIub2FGZUEJ7nSZu2q5eAvif2QznEJqmBnCORyG3l RtY7eFHWKmGVJ2jZ3HTyef4Gi5DKb6AFo7DE0trYsqLL+nblXqner5Mn7DjtUFp9t4Tx EXyIxsgW1b7rUriwr7suz21fPxAuUDBUJcfxVZoQ/W5U0zXKPNkRZ7WfL1RghORM3C8K QbXOXPvMBwjo2TlKH+mCYLhco5Re4o2B9K2m6ptf06dSjf/nGpugvCvTjU6kfb62/gAs aZIQ== X-Gm-Message-State: AMCzsaVU5kkTnFXlNasw2kJpDjPxmVL5cc+Y8Ymx+PAukVf/g9M1RVYx pW2irr0Y9b+15g2x5sJ8N2dDL0P0CSs2ZlTb/S0FVXHi X-Google-Smtp-Source: AOwi7QA/Nlq+QcymnmkTK54ari2WP9XejYlrtAbOX7bHPCIyN3Vad4xerLqS1aCSIpO/RAuwWmTZb733G0ZgTH6YrJE= X-Received: by 10.129.108.3 with SMTP id h3mr2986143ywc.327.1507856432537; Thu, 12 Oct 2017 18:00:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Thu, 12 Oct 2017 17:59:51 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 12 Oct 2017 17:59:51 -0700 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114d9a2808b8b6055b632ff0" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 01:00:35 -0000 --001a114d9a2808b8b6055b632ff0 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 12, 2017 at 5:44 PM, Martin Thomson wrote: > On Fri, Oct 13, 2017 at 11:21 AM, Eric Rescorla wrote: > > Maybe I'm missing something, but I don't think that that's correct. as > long > > as you're > > willing to (a) restrict the jump to the same size as the transmitted > part of > > the sequence > > number and (b) do a little trial decryption. > > > > We could, of course, also adopt the sequence number hopping scheme that > we > > use for QUIC, which works without trial decryption. > > Either works for me (I was operating on the assumption that we would > avoid trial decryption). > Yeah, I think we should probably import the scheme from QUIC. -Ekr --001a114d9a2808b8b6055b632ff0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 12, 2017 at 5:44 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On Fri, Oct 13, 2017 at 11:21 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> Maybe I'm missing something, but I don't think that that's= correct. as long
> as you're
> willing to (a) restrict the jump to the same size as the transmitted p= art of
> the sequence
> number and (b) do a little trial decryption.
>
> We could, of course, also adopt the sequence number hopping scheme tha= t we
> use for QUIC, which works without trial decryption.

Either works for me (I was operating on the assumption that we would=
avoid trial decryption).

Yeah, I think = we should probably import the scheme from QUIC.

-E= kr
=C2=A0

--001a114d9a2808b8b6055b632ff0-- From nobody Thu Oct 12 23:21:14 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC4F1345A7 for ; Thu, 12 Oct 2017 23:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELlCE8UCXQbn for ; Thu, 12 Oct 2017 23:21:11 -0700 (PDT) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) (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 088C2134519 for ; Thu, 12 Oct 2017 23:21:10 -0700 (PDT) Received: by mail-wm0-f53.google.com with SMTP id l68so18728437wmd.5 for ; Thu, 12 Oct 2017 23:21:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=GhdR2Ym9zuU6vjUlDr1LdLRnYIkVZxkjbBrOdlo2PX4=; b=RNxe/7Udd3ev/ASAlTQin2bYm8NJ9KXeuhmnYUcG/5vWJkF573ZGxuO/3vaJyqdPjd /mfSe5VvYobDKXHNVvewGoWtkr8cGN6P+KDiEsGCHrYpuls9CKbRXcroaHoIWq+378mC hpWDZAEaqlbu+o3fcidmjnIa5eznAuFUfPDOxc4yWulDMdA5jdSnWvihFj9O40G/DdVN h8a3Q6/t2HTfhbGJgLvUNncwo6Hv8tJ3/wWSjMpt6SMkxEE7EP9d0GLxpB40/7xtAZRI 3T1mhUpbeCkF/2hqy7IXwIvMCB7rs+BaMStKPWcusJT6InQtCuD0CAYhx1eh5IouGLPO odFQ== X-Gm-Message-State: AMCzsaUDxCA3azOqLbkL1pX5OLCL1CwSStt8hZaVAQaAJwaj24+T4inm YJaUEiGsRLFtepl/3sHpwOkCVUCbcJo= X-Google-Smtp-Source: ABhQp+RNQcp45vY2BKfYP1TrWYl0zkSatqojTCWnzfe/cHDHfyqflnQfXthgI4XZJWK/z0Rl0uC5KA== X-Received: by 10.28.111.206 with SMTP id c75mr508340wmi.123.1507875669184; Thu, 12 Oct 2017 23:21:09 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com ([2a02:214d:8007:2600:c819:dbd5:903d:344d]) by smtp.gmail.com with ESMTPSA id r1sm565551wrr.56.2017.10.12.23.21.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 12 Oct 2017 23:21:08 -0700 (PDT) Message-ID: <1507875665.3178.19.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla , "tls@ietf.org" Date: Fri, 13 Oct 2017 08:21:05 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 06:21:13 -0000 On Thu, 2017-10-12 at 16:13 -0700, Eric Rescorla wrote: > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 I believe the major issue with that is the fact that the record packet format changes, but there is no way for a party in between to be able to determine the record packet format without keeping session state. Think not only of middle boxes, but of super-servers which may receive of a stray udp packet which they have to forward to the appropriate server [0]. With that change, they cannot figure whether the packet contains the CID or not in a deterministic way for a random CID. One can hack around that limitation by providing a CID which starts with 0xffff which is an illegal size currently for TLS or DTLS, but would have to worry with future extensions to the protocol which may increase the maximum size. Another worrying feature is that the client can make the server send up to 255 verbatim bytes on the wire of his choice. Why was this feature added? Are there use cases related with it (intro doesn't mention any), or it was only thought as a make it as generic as possible approach? If it is the latter, I'd recommend to provide a simple approach that covers the described use cases. The same argument applies to the server being able to set such a long sequence of verbatim bytes to each of the client packets. regards, Nikos [0]. That was exactly my use case for introducing the CID info, as in openconnect server, the super-server receives the stray UDP packets arriving after a NAT disassociates existing connections. From nobody Thu Oct 12 23:31:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C368D132924 for ; Thu, 12 Oct 2017 23:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 bGiq1x9NnHQP for ; Thu, 12 Oct 2017 23:31:18 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0102.outbound.protection.outlook.com [104.47.0.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB90B12421A for ; Thu, 12 Oct 2017 23:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nPTYmQsN80phnvIm57e9CwUB0tENsc378Y5XUBc3QbA=; b=bIdQgRtR/zFt+OZLdIDkVJ0qfvP51z6m8uI/wQGUT8sZQxhhKy4WE45EsYEdYQ5+LzGMtCkWg12GmYR7I1Le+/d9oRmWU6vhv8SdHjC2/x8IeCV6gGAI68cC/RaXLck9OckKYi+fQdfgbNroMVEgY8lQB+GvpPzX7//mC5HZ7Yw= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 13 Oct 2017 06:31:14 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::c0d1:2c07:79aa:1d9e]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::c0d1:2c07:79aa:1d9e%14]) with mapi id 15.20.0077.018; Fri, 13 Oct 2017 06:31:14 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AQHTQ6/ei1Eh6DPTUUK7WLQddJSSYqLhYyGA Date: Fri, 13 Oct 2017 06:31:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [2.96.101.129] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1102; 6:0gb4nRypyMJlPe3lGlUXCeI8nAeoUV6YdVUeXoVKMzs4aUbVvCPeiOJgDq3C/xpb5wUC5fa3usBX6SUHVZIrYX1bZRWMkd7tYG4CIZUz3tXnFZby158azzlkQvjchARMita+FIl7GlrdRp4aX8kwLJHS8sO10LZdnxe3b6R3rXSFhedpwcYJRgK8tcKjhvEqK3N1TbuvUY/yU229M1rXu5QSwCZHYOac4ondOlCxQIcN+A5S+5lhZiFMavs/Y2HCQ/BixLxBekWxvi25c9NKCuGTEigNfRWpW1th5nY1FcFLB9IAK2EhmT23mYwToYdyjWaZX4xjoL0w6BmB89gBtQ==; 5:EV9SISz9W5VFuQwsKls/lgqvrc2le0evIP+tyPkzERR9TpJ+vrIeS+lN648T/Ghwv3vICx/NApPQs5ngPva9YS8v+VWQI1T+10sKOIMQUFUIM25msiy/KQisAAfVHshZ6Wsi3PDxeEH/3NRjhh51TQ==; 24:e1q0B6pV8sv2FCd/tVTZCqN6iro6RpSa/PZdYrMRB6vL64hSa3Jl5pDzZ2F3REnajWUI0KFqQrLgug31jcko774DmTW9Et/yXNAAywAOb/E=; 7:tDV9Uh0kjnvpLdEjXz/o8zKj1+WFOF95DKSrGWbws6muOcHEddsCTjtQhlyQukjMXLyJ0IyGZG3D2RRlA/UTmyxehiMhG2uedAx+MxqWcSrIdm11aeDrMEsEr5nDFDZlGTCrOKL5jPiVlv/DlDXe+MRijpddz89SlXI2hJ77nEkY79m+v+jL6jNyF6xxFPAE6d5w/Z76xMuHSE1gcRHnSGZCGiGaM8ykjLqH8QN1+zs= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(199003)(24454002)(51914003)(189002)(6436002)(6486002)(101416001)(8936002)(8676002)(81156014)(229853002)(81166006)(3660700001)(82746002)(966005)(3280700002)(6506006)(68736007)(106356001)(76176999)(50986999)(25786009)(58126008)(105586002)(66066001)(54356999)(97736004)(7736002)(5660300001)(3846002)(14454004)(99286003)(316002)(2501003)(2950100002)(110136005)(53546010)(83716003)(33656002)(606006)(2906002)(86362001)(2900100001)(189998001)(478600001)(6306002)(83506001)(6116002)(4326008)(54896002)(107886003)(236005)(6512007)(36756003)(5250100002)(53936002)(6246003)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1102; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 452fc65c-9cf7-4847-a1ff-08d512040088 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1102; x-ms-traffictypediagnostic: VI1PR07MB1102: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1102; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1102; x-forefront-prvs: 04599F3534 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B286EFDE24D34B50A0DE1A87563A962Enokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 06:31:13.9354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1102 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 06:31:22 -0000 --_000_B286EFDE24D34B50A0DE1A87563A962Enokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rmlyc3QsIHRoYW5rcyBmb3IgdGhlIGRyYWZ0Lg0KDQpBcyBkaXNjdXNzZWQgb2ZmLWxpc3QsIHdy dCBmcmFtaW5nIC8gd2lyZSBmb3JtYXQsIHdlIHByb2JhYmx5IGhhdmUgYW4gb3Bwb3J0dW5pdHkg dG8gZG8gc2xpZ2h0bHkgYmV0dGVyIHRoYW4gdGhpcywgYXQgbGVhc3QgZm9yIDEuMi4NCg0KVGhl IHRoaW5nIGlzIHRoYXQsIHNpbmNlIHRoZXJlIGlzIG5vIGZsYWcgaW4gdGhlIHJlY29yZCB0aGF0 IHNheXM6ICJJJ20gY2FycnlpbmcgYSBDSUQiLCBhIHJlY2VpdmVyIGhhcyBubyBleHBsaWNpdCB3 YXkgdG8ga25vdyB3aGV0aGVyIGEgcmVjb3JkIGlzIGNvbWluZyBmcm9tIGEgQ0lELWVuYWJsZWQg c2Vzc2lvbiBvciBhIGxlZ2FjeS1EVExTLg0KDQpUaGlzIGFtYmlndWl0eSBjb21wbGljYXRlcyB0 aGUgZGVjb2RlciBiZWNhdXNlIHRoZSByZWNlaXZpbmcgZW5kIG5vdyBuZWVkcyB0byBpbXBsZW1l bnQgYSBoZXVyaXN0aWMgbGlrZToNCg0KLSAgICAgICAgICBsZXQncyBmaXJzdCBhc3N1bWUgYXQg b2Zmc2V0ICsxMSB3ZSBoYXZlIGEgQ0lEDQoNCi0gICAgICAgICAgYW5kIHRoZW4gbG9va3VwIHRo ZSBTQXMgc3RvcmUgdXNpbmcgdGhpcyAibWF5YmUiIENJRA0KDQotICAgICAgICAgIGlmIGZvdW5k LCBPSyAoKiksIGdvIG9uIHdpdGggdGhlIHBhcnNpbmcNCg0KLSAgICAgICAgICBpZiBub3QsIGZh bGwgYmFjayB0byBhc3N1bWluZyBhdCBvZmZzZXQgKzExIHdlIGhhdmUgdGhlIGxlbmd0aCBmaWVs ZCBhbmQgZ28gb24gcGFyc2luZw0KDQpUaGlzIGlzIG5vdCBpZGVhbCBmb3IgYSBidW5jaCBvZiBy ZWFzb25zOg0KICAgIDEuIEZvciBldmVyeSBpbmNvbWluZyByZWNvcmQsIHRoZSByZWNlaXZlciBu ZWVkcyB0byBsb29rdXAgdGhlIENJRCBzdG9yZSBqdXN0IHRvIHBhcnNlIHRoZSByZWNvcmQ7DQog ICAgMi4gVGhlIGltcGxlbWVudGF0aW9uIGlzIG1vcmUgY29tcGxpY2F0ZTsNCiAgICAzLiBIZXVy aXN0aWNzIGFyZSBpbnRyaW5zaWNhbGx5IGZyYWdpbGUgYW5kIGFyZSBrbm93biB0byBkZWFsIGJh ZGx5IHdpdGggY29ybmVyIGNhc2VzICh0aGluayB0aGUgbWFueSBjcmVhdGl2ZSB3YXlzIHRoZSBt YW55IG1vdmluZyBwYXJ0cyBjYW4gY29uc3BpcmU6IDUtdHVwbGUgcmVzaHVmZmxpbmcgYmVjYXVz ZSBvZiBOQVQgcmViaW5kaW5nLCBsb3N0IHN0YXRlIGR1ZSB0byByZWJvb3QvcmVzdGFydCBvZiBv bmUgb3IgbW9yZSBub2RlcywgY28tZXhpc3RpbmcgQ0lEIGFuZCBsZWdhY3kgRFRMUyk7DQogICAg NC4gV2lyZXNoYXJrICYgY28gd2lsbCBjaG9rZSBiZWNhdXNlIHRoZXkgdHlwaWNhbGx5IGRvbid0 IGhhdmUgZW5vdWdoIGNvbnRleHQgdG8gaGFuZGxlIHRoZSB0d28gZGlmZmVyZW50IGZyYW1pbmdz Ow0KDQpUbyBzb2x2ZSB0aGlzLCB3ZSdkIG5lZWQgYSBwbGFjZSBpbiB0aGUgd2lyZSBpbWFnZSBv ZiB0aGUgcmVjb3JkIHdpdGggc2VtYW50aWNzOiAiSSdtIGNhcnJ5aW5nIGEgQ0lELiINCg0KSW4g MS4yLCB3ZSBjb3VsZCB1c2UgQ1Qgb3IgdmVyc2lvbi4gIChJbiAxLjMsIHRoYXQgd291bGQgbm90 IGJlIHBvc3NpYmxlIGJlY2F1c2UgdGhlIGRpZXQgaGVhZGVyIGRvZXNuJ3QgaGF2ZSB0aGVtIC0g dG9vIGJhZC4pICBUbyBtZSBpdCdkIG1ha2Ugc2xpZ2h0bHkgbW9yZSBzZW5zZSB0byB1c2UgdGhl IHZlcnNpb24uIChJIGhhZCBwcmV2aW91cyBkaXNjdXNzaW9ucyBvbiB0aGlzIHRvcGljIHdpdGgg Tmlrb3MgYW5kIGhlIHRvbGQgbWUgdGhhdCB0aG91Z2ggYW55Y29ubmVjdCBkb2VzIHRoaXMgdmVy c2lvbiBvdmVycmlkZSBmb3Igc29tZSByZWFzb25zLCB0aGVyZSBpcyBubyByZXBvcnRlZCBjb25m bGljdCB3aXRoIG1pZGRsZS1ib3hlcy4pICBBbHNvLCB0aGVyZSB3b3VsZCBiZSBvbmx5IG9uZSBj b2RlLXBvaW50IHRvIGFsbG9jYXRlLCBpbnN0ZWFkIG9mIHNlcGFyYXRlIGNvZGUtcG9pbnRzIGZv ciBlYWNoIENJRC1lbmFibGVkIGNvbnRlbnQgdHlwZSB2YXJpYW50LiAgSSdtIGhhcHB5IHRvIGJl IGNvbnZpbmNlZCBvZiB0aGUgb3Bwb3NpdGUsIHRob3VnaC4NCg0KSSBndWVzcyBteSBtYWluIHBv aW50IGhlcmUgaXMgdG8gbWFrZSBzdXJlIHdlIGRvIGFzIG11Y2ggYXMgd2UgY2FuIHRvIGFsbG93 IHNpbXBsZSwgZWZmaWNpZW50LCByb2J1c3QgaW1wbGVtZW50YXRpb25zLCB3aGljaCBhcmUgYWxz bywgZW4gcGFzc2FudCwgV2lyZXNoYXJrLWZyaWVuZGx5LCBhbmQgbGVhdmUgaGV1cmlzdGljcy1i YXNlZCBhcHByb2FjaGVzIG9ubHkgZm9yIHdoZW4gdGhlcmUgaXMgbm8gcmVhbCBhbHRlcm5hdGl2 ZS4NCg0KQ2hlZXJzLCB0DQoNCigqKSBhc3N1bWluZyBDSUQgaXMgZW50cm9waWMgZW5vdWdoLCB3 aGljaCBtYXkgb3IgbWF5IG5vdCBiZSB0aGUgY2FzZS4NCg0KDQpPbiAxMy8xMC8yMDE3LCAwMDox MywgIlRMUyBvbiBiZWhhbGYgb2YgRXJpYyBSZXNjb3JsYSIgPHRscy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGVrckBydGZtLmNvbTxt YWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQoNCkhpIGZvbGtzLA0KDQpJIGhhdmUganVzdCBw b3N0ZWQgYSBmaXJzdCBjdXQgYXQgYSBjb25uZWN0aW9uIElEIGRyYWZ0Lg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1kdGxzLWNvbm5lY3Rpb24taWQtMDAN Cg0KQ29tbWVudHMgd2VsY29tZS4NCg0KLUVrcg0KDQoNCg0K --_000_B286EFDE24D34B50A0DE1A87563A962Enokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJv dHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEwMDc5NDkzMTg7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjUyNTIyMTg3 MCAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgw NzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlz dC1pZDoyMDU3MTkyNjYwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczoxNzU3NzE3MDc4IC0yMDg3Mjg5NzIwIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3 NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwx OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkZpcnN0LCB0aGFua3MgZm9yIHRoZSBkcmFmdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBkaXNjdXNzZWQgb2ZmLWxpc3QsIHdydCBmcmFtaW5nIC8g d2lyZSBmb3JtYXQsIHdlIHByb2JhYmx5IGhhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gZG8gc2xpZ2h0 bHkgYmV0dGVyIHRoYW4gdGhpcywgYXQgbGVhc3QgZm9yIDEuMi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5UaGUgdGhpbmcgaXMgdGhhdCwgc2luY2UgdGhlcmUgaXMgbm8gZmxhZyBpbiB0aGUgcmVj b3JkIHRoYXQgc2F5czogJnF1b3Q7SSdtIGNhcnJ5aW5nIGEgQ0lEJnF1b3Q7LCBhIHJlY2VpdmVy IGhhcyBubyBleHBsaWNpdCB3YXkgdG8ga25vdyB3aGV0aGVyIGEgcmVjb3JkIGlzIGNvbWluZyBm cm9tDQogYSBDSUQtZW5hYmxlZCBzZXNzaW9uIG9yIGEgbGVnYWN5LURUTFMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+VGhpcyBhbWJpZ3VpdHkgY29tcGxpY2F0ZXMgdGhlIGRlY29kZXIgYmVjYXVz ZSB0aGUgcmVjZWl2aW5nIGVuZCBub3cgbmVlZHMgdG8gaW1wbGVtZW50IGEgaGV1cmlzdGljIGxp a2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5s ZXQncyBmaXJzdCBhc3N1bWUgYXQgb2Zmc2V0ICYjNDM7MTEgd2UgaGF2ZSBhIENJRDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+YW5kIHRoZW4gbG9v a3VwIHRoZSBTQXMgc3RvcmUgdXNpbmcgdGhpcyAmcXVvdDttYXliZSZxdW90OyBDSUQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmlmIGZvdW5kLCBP SyAoKiksIGdvIG9uIHdpdGggdGhlIHBhcnNpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmlmIG5vdCwgZmFsbCBiYWNrIHRvIGFzc3VtaW5nIGF0 IG9mZnNldCAmIzQzOzExIHdlIGhhdmUgdGhlIGxlbmd0aCBmaWVsZCBhbmQgZ28gb24gcGFyc2lu ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoaXMgaXMgbm90IGlkZWFsIGZvciBhIGJ1bmNoIG9m IHJlYXNvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEuIEZvciBldmVyeSBpbmNvbWlu ZyByZWNvcmQsIHRoZSByZWNlaXZlciBuZWVkcyB0byBsb29rdXAgdGhlIENJRCBzdG9yZSBqdXN0 IHRvIHBhcnNlIHRoZSByZWNvcmQ7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIuIFRoZSBp bXBsZW1lbnRhdGlvbiBpcyBtb3JlIGNvbXBsaWNhdGU7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IDMuIEhldXJpc3RpY3MgYXJlIGludHJpbnNpY2FsbHkgZnJhZ2lsZSBhbmQgYXJlIGtub3du IHRvIGRlYWwgYmFkbHkgd2l0aCBjb3JuZXIgY2FzZXMgKHRoaW5rIHRoZSBtYW55IGNyZWF0aXZl IHdheXMgdGhlIG1hbnkgbW92aW5nIHBhcnRzIGNhbiBjb25zcGlyZTogNS10dXBsZQ0KIHJlc2h1 ZmZsaW5nIGJlY2F1c2Ugb2YgTkFUIHJlYmluZGluZywgbG9zdCBzdGF0ZSBkdWUgdG8gcmVib290 L3Jlc3RhcnQgb2Ygb25lIG9yIG1vcmUgbm9kZXMsIGNvLWV4aXN0aW5nIENJRCBhbmQgbGVnYWN5 IERUTFMpOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyA0LiBXaXJlc2hhcmsgJmFtcDsgY28g d2lsbCBjaG9rZSBiZWNhdXNlIHRoZXkgdHlwaWNhbGx5IGRvbid0IGhhdmUgZW5vdWdoIGNvbnRl eHQgdG8gaGFuZGxlIHRoZSB0d28gZGlmZmVyZW50IGZyYW1pbmdzOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPlRvIHNvbHZlIHRoaXMsIHdlJ2QgbmVlZCBhIHBsYWNlIGluIHRoZSB3aXJlIGltYWdl IG9mIHRoZSByZWNvcmQgd2l0aCBzZW1hbnRpY3M6ICZxdW90O0knbSBjYXJyeWluZyBhIENJRC4m cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JbiAxLjIsIHdlIGNvdWxkIHVzZSBDVCBvciB2 ZXJzaW9uLiZuYnNwOyAoSW4gMS4zLCB0aGF0IHdvdWxkIG5vdCBiZSBwb3NzaWJsZSBiZWNhdXNl IHRoZSBkaWV0IGhlYWRlciBkb2Vzbid0IGhhdmUgdGhlbSAtIHRvbyBiYWQuKSZuYnNwOyBUbyBt ZSBpdCdkIG1ha2Ugc2xpZ2h0bHkgbW9yZQ0KIHNlbnNlIHRvIHVzZSB0aGUgdmVyc2lvbi4gKEkg aGFkIHByZXZpb3VzIGRpc2N1c3Npb25zIG9uIHRoaXMgdG9waWMgd2l0aCBOaWtvcyBhbmQgaGUg dG9sZCBtZSB0aGF0IHRob3VnaCBhbnljb25uZWN0IGRvZXMgdGhpcyB2ZXJzaW9uIG92ZXJyaWRl IGZvciBzb21lIHJlYXNvbnMsIHRoZXJlIGlzIG5vIHJlcG9ydGVkIGNvbmZsaWN0IHdpdGggbWlk ZGxlLWJveGVzLikmbmJzcDsgQWxzbywgdGhlcmUgd291bGQgYmUgb25seSBvbmUgY29kZS1wb2lu dCB0bw0KIGFsbG9jYXRlLCBpbnN0ZWFkIG9mIHNlcGFyYXRlIGNvZGUtcG9pbnRzIGZvciBlYWNo IENJRC1lbmFibGVkIGNvbnRlbnQgdHlwZSB2YXJpYW50LiZuYnNwOyBJJ20gaGFwcHkgdG8gYmUg Y29udmluY2VkIG9mIHRoZSBvcHBvc2l0ZSwgdGhvdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkkgZ3Vlc3MgbXkgbWFpbiBwb2ludCBoZXJlIGlzIHRvIG1ha2Ugc3VyZSB3ZSBkbyBhcyBtdWNo IGFzIHdlIGNhbiB0byBhbGxvdyBzaW1wbGUsIGVmZmljaWVudCwgcm9idXN0IGltcGxlbWVudGF0 aW9ucywgd2hpY2ggYXJlIGFsc28sIGVuIHBhc3NhbnQsIFdpcmVzaGFyay1mcmllbmRseSwNCiBh bmQgbGVhdmUgaGV1cmlzdGljcy1iYXNlZCBhcHByb2FjaGVzIG9ubHkgZm9yIHdoZW4gdGhlcmUg aXMgbm8gcmVhbCBhbHRlcm5hdGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVlcnMsIHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4oKikgYXNzdW1pbmcgQ0lEIGlzIGVudHJvcGljIGVub3Vn aCwgd2hpY2ggbWF5IG9yIG1heSBub3QgYmUgdGhlIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAxMy8xMC8yMDE3LCAwMDox MywgJnF1b3Q7VExTIG9uIGJlaGFsZiBvZiBFcmljIFJlc2NvcmxhJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmciPnRscy1ib3VuY2VzQGlldGYub3JnPC9hPiBv biBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPkhpIGZvbGtzLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPkkgaGF2ZSBqdXN0IHBvc3RlZCBhIGZpcnN0IGN1dCBhdCBhIGNvbm5lY3Rp b24gSUQgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC0wMCI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1kdGxzLWNvbm5l Y3Rpb24taWQtMDA8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPkNvbW1lbnRzIHdlbGNvbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_B286EFDE24D34B50A0DE1A87563A962Enokiacom_-- From nobody Fri Oct 13 01:11:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBF2126B7E for ; Fri, 13 Oct 2017 01:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Y6SLJQIFlD5T for ; Fri, 13 Oct 2017 01:11:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C169126B71 for ; Fri, 13 Oct 2017 01:11:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQO33679; Fri, 13 Oct 2017 08:11:41 +0000 (GMT) Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 13 Oct 2017 09:11:39 +0100 Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.186]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0301.000; Fri, 13 Oct 2017 16:11:38 +0800 From: yinxinxing To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AdND9UCTy0qV4eX+RfS1VDVqmNEmOw== Date: Fri, 13 Oct 2017 08:11:37 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022C7A77E2dggemi508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59E0753F.0011, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.186, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f4e239171d64f650785ae4a1845856df Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 08:11:52 -0000 --_000_DBDF9AE44733284D808F0E585E1919022C7A77E2dggemi508mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWtyLA0KDQpUaGFua3MgZm9yIHlvdXIgZWZmb3J0LiBUaGUgZHJhZnQgbG9va3MgZ29vZC4g QSBmZXcgY29tbWVudHMgYXJlIGxpc3RlZCBiZWxvdy4NCg0KDQoxLiAgICAgICBCYXNlZCBvbiB0 aGUgZHJhZnQsIGZvciBlaXRoZXIgRFRMUzEuMiBvciAxLjMsIHNlcnZlciBjYW7igJl0IGRpZmZl cmVudGlhdGUgd2hldGhlciB0aGUgcGFja2V0IGZyb20gY2xpZW50IGlzIGEg4oCcY29ubmVjdGlv biBJROKAnSBwYWNrZXQgb3IgYSBzdGFuZGFyZCBEVExTIDEuMi8xLjMgcGFja2V0LiAoSSBzYXcg VGhvbWFzIEZvc3NhdGkgYW5kIE5pa29zIGFsc28gaW50cm9kdWNlZCB0aGlzIHByb2JsZW0pDQoN Ck1heWJlIHdlIGNhbiBhZGQgYSBuZXcg4oCcQ29udGVudFR5cGXigJ0gaW4gdGhlIERUTFMgcmVj b3JkIGZvcm1hdCB0byBoZWxwIHNlcnZlciBpZGVudGlmeSB0aGUg4oCcY29ubmVjdGlvbiBJROKA nSBwYWNrZXQuIEluIGFkZGl0aW9uLCB5b3Ugc2VlIHRoZSBsZW5ndGggb2YgdGhlIHJlY29yZCBw YXlsb2FkIGlzIGxpbWl0ZWQgYnkgMl4xNC0xLCB0aGlzIG1lYW5zIHRoZSBmaXJzdCB0d28gYml0 cyBvZiDigJxsZW5ndGjigJ0gaXMgemVyby4gV2UgY291bGQgdXRpbGl6ZSB0aGlzIGZlYXR1cmUg YW5kIHNldCB0aGUgZmlyc3QgdHdvIGJpdHMgb3IgbW9yZSBiaXRzIG9mIENJRCBiZWluZyBvbmUs IGUuZy4sIDExMTHigKYuKGJ1dCB0aGUgQ0lEIG11c3QgYmUgcHV0IGJldHdlZW4gc2VxdWVuY2Ug bnVtYmVyIGFuZCBsZW5ndGgpLiBXaGVuIHNlcnZlciBmaW5kcyAxMTExIGFmdGVyIHNlcXVlbmNl IG51bWJlciwgaXQga25vd3MgdGhpcyBpcyBhIOKAnGNvbm5lY3Rpb24gSUTigJ0gcGFja2V0LiBI b3dldmVyLCBJIGRvbuKAmXQga25vdyB3aGV0aGVyIGl0IGlzIHByb3BlciB0byB1c2Ugc3VjaCBt YWdpYyBudW1iZXIuIEluIG15IHZpZXcsIGFkZGluZyBuZXcgY29udGVudHR5cGUgbWF5IGJlIGEg Y2hvaWNlLg0KDQoNCg0KMi4gICAgICAgIEZvciBEVExTIDEuMiwgdGhlcmUgaXMgbm8gTmV3Q29u bmVjdGlvbklEIGFuZCBSZXF1ZXN0Q29ubmVjdGlvbklEIG1lc3NhZ2UuIERUTFMgMS4yIHNlcnZl ciBhbmQgY2xpZW50IGFsc28gaGFzIHRoZSByZXF1aXJlbWVudCB0byByZXF1ZXN0IGZvciBhIG5l dyBDSUQsIGFuZCBhdCBwcmVzZW50LCBtYW55IHByb2R1Y3RzIHN0aWxsIHVzZSBEVExTMS4yIGFu ZCBJIGJlbGlldmUgaXQgd2lsbCBjb250aW51ZSB0byBiZSB1c2VkIGZvciBhIGxvbmcgdGltZSBl dmVuIGlmIFRMUy9EVExTMS4zIGlzIHB1Ymxpc2hlZC4gTXkgcG9pbnQgaXMgdGhhdCB3ZSBuZWVk IGEgY29ycmVzcG9uZGluZyBtZXRob2QgZm9yIHVwZGF0aW5nIENJRCBmb3IgRFRMUzEuMiB0b28u DQoNCkkgZG9u4oCZdCBxdWl0ZSB1bmRlcnN0YW5kIHRoZSBmb2xsb3dpbmcgc2VudGVuY2VzDQoN CuKAnEluIERUTFMgMS4yLCBjb25uZWN0aW9uIGlkcyBhcmUgZXhjaGFuZ2VkIGF0IHRoZSBiZWdp bm5pbmcgb2YgdGhlDQoNCiAgIERUTFMgc2Vzc2lvbiBvbmx5LiAgVGhlcmUgaXMgbm8gZGVkaWNh dGVkICJjb25uZWN0aW9uIGlkIHVwZGF0ZSINCg0KICAgbWVzc2FnZSB0aGF0IGFsbG93cyBuZXcg Y29ubmVjdGlvbiBpZHMgdG8gYmUgZXN0YWJsaXNoZWQgbWlkLXNlc3Npb24sDQoNCiAgIGJlY2F1 c2UgRFRMUyAxLjIgaW4gZ2VuZXJhbCBkb2VzIG5vdCBhbGxvdyBwb3N0LWhhbmRzaGFrZSBtZXNz YWdlcw0KDQogICB0aGF0IGRvIG5vdCB0aGVtc2VsdmVzIGJlZ2luIG90aGVyIGhhbmRzaGFrZXMu 4oCdDQoNCkJlc2lkZXMsIGZvciBDSUQgaW4gRFRMUzEuMywgSSB0aGluayB0aGUgY29ycmVzcG9u ZGluZyByZXNwb25kaW5nIG1lc3NhZ2VzIG9mICBOZXdDb25uZWN0aW9uSUQgYW5kIFJlcXVlc3RD b25uZWN0aW9uSUQgYXJlIGFsc28gbmVlZGVkIHRvIGVuc3VyZSB0aGF0IHRoZSBwZWVyIGhhcyBy ZWNlaXZlZCBDSUQuDQoNCg0KMy4gICAgICAgV2UgaGF2ZSBhIHByYWN0aWNhbCB1c2VjYXNlIGlu IElvVC4gVGhlIElPVCBkZXZpY2UsIGxpa2UgaW50ZWxsaWdlbnQgd2F0ZXIgbWV0ZXIsIHNlbmRz IG9uZSBtZXNzYWdlIHBlciBkYXksIGFuZCBnb2VzIHRvIHNsZWVwLiBJdCB3YWtlcyB1cCBpbiB0 aGUgc2Vjb25kIGRheSBhbmQgc2VuZHMgYSBtZXNzYWdlIGFuZCB0aGVuIGdvZXMgdG8gc2xlZXAu IElmIGl0IGFsd2F5cyAob3IgZm9yIGEgbG9uZyB0aW1lKSB1c2UgdGhlIHNhbWUgQ0lELCB0aGVy ZSBtYXkgYmUgYSByaXNrIG9mIHRyYWNpbmcgSU9UIGRldmljZSBvciB0aGUgb3duZXIgb2YgdGhp cyBkZXZpY2UuIFRoZXJlZm9yZSwgaXQgaXMgaW1wb3J0YW50IHRvIHJlY29tbWVuZCB1c2VyIHRv IHVwZGF0ZSBDSUQgb25jZSBpdCBmaW5pc2hlcyBzZW5kaW5nIG1lc3NhZ2UuIEZvciB0aGUgQ0lE IGluIERUTFMxLjIsIHRoaXMgYmVjb21lcyB3b3JzZS4NCg0KDQoNCjQuICAgICAgIFRoZSBnZW5l cmF0aW9uIG9mIENJRCBzaG91bGQgYmUgbW9yZSBjb25jcmV0ZS4gRm9yIGV4YW1wbGUsIHVzaW5n IHJhbmRvbSBudW1iZXIgb3IgYSBjb3VudGVyPw0KDQoNClJlZ2FyZHMsDQpZaW4gWGlueGluZw0K DQrlj5Hku7bkuro6IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggRXJp YyBSZXNjb3JsYQ0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0MTDmnIgxM+aXpSA3OjE0DQrmlLbku7bk uro6IHRsc0BpZXRmLm9yZw0K5Li76aKYOiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0DQoNCkhp IGZvbGtzLA0KDQpJIGhhdmUganVzdCBwb3N0ZWQgYSBmaXJzdCBjdXQgYXQgYSBjb25uZWN0aW9u IElEIGRyYWZ0Lg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRs cy1kdGxzLWNvbm5lY3Rpb24taWQtMDANCg0KQ29tbWVudHMgd2VsY29tZS4NCg0KLUVrcg0KDQoN Cg0K --_000_DBDF9AE44733284D808F0E585E1919022C7A77E2dggemi508mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6 MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkw LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY5OTU1MzI0MjsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTUwNTAxMjk5MiAtNjQ1 NTAxNTIwIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlMlwp IjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NDIuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJbWFyZ2luLWxlZnQ6NjMuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo4NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRleHQ6IiU1XCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMDUuMHB0Ow0KCXRl eHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MTI2LjBwdDsNCgl0ZXh0LWlu ZGVudDotMjEuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTQ3LjBw dDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJThcKSI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjE2OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJn aW4tbGVmdDoxODkuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRWtyLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgZWZmb3J0LiBUaGUgZHJhZnQgbG9v a3MgZ29vZC4gQSBmZXcgY29tbWVudHMgYXJlIGxpc3RlZCBiZWxvdy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CYXNlZCBvbiB0 aGUgZHJhZnQsIGZvciBlaXRoZXIgRFRMUzEuMiBvciAxLjMsIHNlcnZlciBjYW7igJl0IGRpZmZl cmVudGlhdGUgd2hldGhlciB0aGUgcGFja2V0IGZyb20gY2xpZW50IGlzIGEg4oCcY29ubmVjdGlv biBJROKAnSBwYWNrZXQNCiBvciBhIHN0YW5kYXJkIERUTFMgMS4yLzEuMyBwYWNrZXQuIChJIHNh dyBUaG9tYXMgRm9zc2F0aSBhbmQgTmlrb3MgYWxzbyBpbnRyb2R1Y2VkIHRoaXMgcHJvYmxlbSk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWF5YmUgd2UgY2FuIGFkZCBhIG5l dyDigJxDb250ZW50VHlwZeKAnSBpbiB0aGUgRFRMUyByZWNvcmQgZm9ybWF0IHRvIGhlbHAgc2Vy dmVyIGlkZW50aWZ5IHRoZSDigJxjb25uZWN0aW9uDQogSUTigJ0gcGFja2V0LiBJbiBhZGRpdGlv biwgeW91IHNlZSB0aGUgbGVuZ3RoIG9mIHRoZSByZWNvcmQgcGF5bG9hZCBpcyBsaW1pdGVkIGJ5 IDJeMTQtMSwgdGhpcyBtZWFucyB0aGUgZmlyc3QgdHdvIGJpdHMgb2Yg4oCcbGVuZ3Ro4oCdIGlz IHplcm8uIFdlIGNvdWxkIHV0aWxpemUgdGhpcyBmZWF0dXJlIGFuZCBzZXQgdGhlIGZpcnN0IHR3 byBiaXRzIG9yIG1vcmUgYml0cyBvZiBDSUQgYmVpbmcgb25lLCBlLmcuLCAxMTEx4oCmLihidXQg dGhlIENJRCBtdXN0DQogYmUgcHV0IGJldHdlZW4gc2VxdWVuY2UgbnVtYmVyIGFuZCBsZW5ndGgp LiBXaGVuIHNlcnZlciBmaW5kcyAxMTExIGFmdGVyIHNlcXVlbmNlIG51bWJlciwgaXQga25vd3Mg dGhpcyBpcyBhIOKAnGNvbm5lY3Rpb24gSUTigJ0gcGFja2V0LiBIb3dldmVyLCBJIGRvbuKAmXQg a25vdyB3aGV0aGVyIGl0IGlzIHByb3BlciB0byB1c2Ugc3VjaCBtYWdpYyBudW1iZXIuIEluIG15 IHZpZXcsIGFkZGluZyBuZXcgY29udGVudHR5cGUgbWF5IGJlIGEgY2hvaWNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTguMHB0O3RleHQtaW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Rm9yIERU TFMgMS4yLCB0aGVyZSBpcyBubyBOZXdDb25uZWN0aW9uSUQgYW5kIFJlcXVlc3RDb25uZWN0aW9u SUQgbWVzc2FnZS4gRFRMUyAxLjIgc2VydmVyIGFuZCBjbGllbnQgYWxzbyBoYXMgdGhlIHJlcXVp cmVtZW50IHRvIHJlcXVlc3QNCiBmb3IgYSBuZXcgQ0lELCBhbmQgYXQgcHJlc2VudCwgbWFueSBw cm9kdWN0cyBzdGlsbCB1c2UgRFRMUzEuMiBhbmQgSSBiZWxpZXZlIGl0IHdpbGwgY29udGludWUg dG8gYmUgdXNlZCBmb3IgYSBsb25nIHRpbWUgZXZlbiBpZiBUTFMvRFRMUzEuMyBpcyBwdWJsaXNo ZWQuIE15IHBvaW50IGlzIHRoYXQgd2UgbmVlZCBhIGNvcnJlc3BvbmRpbmcgbWV0aG9kIGZvciB1 cGRhdGluZyBDSUQgZm9yIERUTFMxLjIgdG9vLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1p bmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgZG9u4oCZdCBxdWl0ZSB1bmRlcnN0YW5kIHRoZSBmb2xsb3dpbmcgc2VudGVu Y2VzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxJbiBEVExTIDEuMiwgY29ubmVjdGlvbiBpZHMg YXJlIGV4Y2hhbmdlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyBEVExTIHNlc3Npb24gb25seS4mbmJzcDsgVGhlcmUgaXMgbm8gZGVkaWNh dGVkICZxdW90O2Nvbm5lY3Rpb24gaWQgdXBkYXRlJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UgdGhhdCBhbGxvd3MgbmV3IGNvbm5lY3Rpb24gaWRzIHRvIGJl IGVzdGFibGlzaGVkIG1pZC1zZXNzaW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyBiZWNhdXNlIERUTFMgMS4yIGluIGdlbmVyYWwgZG9lcyBub3QgYWxsb3cgcG9zdC1oYW5kc2hh a2UgbWVzc2FnZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IHRoYXQgZG8gbm90IHRoZW1zZWx2ZXMgYmVnaW4gb3RoZXIgaGFuZHNoYWtlcy7igJ08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzaWRlcywgZm9yIENJRCBpbiBEVExT MS4zLCBJIHRoaW5rIHRoZSBjb3JyZXNwb25kaW5nIHJlc3BvbmRpbmcgbWVzc2FnZXMgb2YgJm5i c3A7TmV3Q29ubmVjdGlvbklEDQogYW5kIFJlcXVlc3RDb25uZWN0aW9uSUQgYXJlIGFsc28gbmVl ZGVkIHRvIGVuc3VyZSB0aGF0IHRoZSBwZWVyIGhhcyByZWNlaXZlZCBDSUQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgaGF2 ZSBhIHByYWN0aWNhbCB1c2VjYXNlIGluIElvVC4gVGhlIElPVCBkZXZpY2UsIGxpa2UgaW50ZWxs aWdlbnQgd2F0ZXIgbWV0ZXIsIHNlbmRzIG9uZSBtZXNzYWdlIHBlciBkYXksIGFuZCBnb2VzIHRv IHNsZWVwLiBJdCB3YWtlcw0KIHVwIGluIHRoZSBzZWNvbmQgZGF5IGFuZCBzZW5kcyBhIG1lc3Nh Z2UgYW5kIHRoZW4gZ29lcyB0byBzbGVlcC4gSWYgaXQgYWx3YXlzIChvciBmb3IgYSBsb25nIHRp bWUpIHVzZSB0aGUgc2FtZSBDSUQsIHRoZXJlIG1heSBiZSBhIHJpc2sgb2YgdHJhY2luZyBJT1Qg ZGV2aWNlIG9yIHRoZSBvd25lciBvZiB0aGlzIGRldmljZS4gVGhlcmVmb3JlLCBpdCBpcyBpbXBv cnRhbnQgdG8gcmVjb21tZW5kIHVzZXIgdG8gdXBkYXRlIENJRCBvbmNlIGl0IGZpbmlzaGVzDQog c2VuZGluZyBtZXNzYWdlLiBGb3IgdGhlIENJRCBpbiBEVExTMS4yLCB0aGlzIGJlY29tZXMgd29y c2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40LjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGUgZ2VuZXJhdGlvbiBvZiBDSUQgc2hvdWxkIGJlIG1vcmUgY29uY3JldGUuIEZvciBleGFt cGxlLCB1c2luZyByYW5kb20gbnVtYmVyIG9yIGEgY291bnRlcj88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+WWluIFhpbnhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFu PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7ku6PooaggPC9zcGFuPg0KPC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RXJpYyBSZXNj b3JsYTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+5Y+R 6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiAyMDE3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+ 5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjEzPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiA3 OjE0PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+IHRsc0BpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBbVExTXSBD b25uZWN0aW9uIElEIERyYWZ0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGZv bGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSBqdXN0 IHBvc3RlZCBhIGZpcnN0IGN1dCBhdCBhIGNvbm5lY3Rpb24gSUQgZHJhZnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZXNj b3JsYS10bHMtZHRscy1jb25uZWN0aW9uLWlkLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtcmVzY29ybGEtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC0wMDwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNvbW1lbnRzIHdlbGNvbWUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tRWtyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBDF9AE44733284D808F0E585E1919022C7A77E2dggemi508mbxchi_-- From nobody Fri Oct 13 02:49:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89D0133054 for ; Fri, 13 Oct 2017 02:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 ZZu5cRxFQ1bB for ; Fri, 13 Oct 2017 02:49:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 E348A1321C9 for ; Fri, 13 Oct 2017 02:49:15 -0700 (PDT) Received: from [192.168.91.203] ([80.92.116.99]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MS5xC-1dfOOw3Fww-00TBOS; Fri, 13 Oct 2017 11:49:13 +0200 To: Sean Turner , "" References: <4EDF7DF9-D9C9-4A5B-AA9C-5A39823FA250@sn3rd.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Fri, 13 Oct 2017 11:49:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <4EDF7DF9-D9C9-4A5B-AA9C-5A39823FA250@sn3rd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:S/RcmbNurIjFBLmgqjouoNORi6gHjrwhY4gYJTxRHBo49sNTa67 Z8Js2bhsjRET21WXxDXOzCVx6tZhgrip1eTkVzxHFDVFO5EyGaCicGR//5Fln5LmaWnDglo AhM6WKXpmeMb0S+7PGnhaN85Y6xg4NWVaFQ6/GpK5Ts6xe19wXKi4b1vGxaTsL5GUJTKO+a se54byXHI+uhgg0AMvFzw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SKS36iBL6iU=:VIiCKXde0b/uqCjw741bNB jxLED3PRfkVeejRpbvh94bbMqQp+aW5jiPS06//9GlVTBnHW71EGEx1Gia6jp/LsZRjrz2Gvp eo+PM803Bd9kLK+ZWOJvL7owFAIUhlAqW37dIt6Mw6fQpx9Goy/bLvkj3GTkLE9pxsAu8lQ1N o70pwTWpv+Oob9F0dh5Poj295CYHz7IosNSHMOUsN49WhjpRob3jj6ywN/n34X4t/WdJVLml6 R0OgY432zYYZXJCFUzTAzwERQTmzw4EXpmGKwQvi4BfjvVCUh/hnkYia3SRgNItlUwm0sy8sA rPWOq4NJ2B8+EbCuGTq9x6m9Hp3m8e3wA0ypkEXlZB1kKvWKuJSZ0IpjmligX2jJzpjxil/t9 jGHVX5Z63eom765Gsr/LIbdS2VbNPIHktgqvayhUSeIuoE7BvUBuH9b/ELSbVKoY9iHb194E9 tPJ+qhYbrhaJeBHXyULE3ybrhyS9++ud9BRhgzHYXpq1l/XYYq23c2Kme1jii8sP4n7ADlXRH SFQd2Zycd7uIidd1cCwoD8R6iAVFywnf6J5LN3M4BxeqvnPm9veY/ZLH6fgsEcBWZPxjdo5AB +eAip5Q7BNvPjBQcLKjV8/yLQeZeJMlC9QZmptnlnw89clsAHOgin4XWptmpBCymrTwSnnR4A gP7wwL9IOdWFgjZbL6cCNDT7lJTS+nL+YeOu8h0EVSYl2iIHGOEXj+r5WZorkW7cWLXM/ipcl Lcj7webjoLD3ARrzjdfCRdF2Q9sYhEGXAp5aOqWtukDfunR8EUq13Kf3rKXFG8JVe00QPMx6t I4X4Dhwn8cIFw9Sf5kezO5zn8dZpdht8+/b0YgOhiw6fJTMhWY= Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 09:49:18 -0000 CCM_8 is used in the IoT space because some SDOs believed that they need to optimize the transmission overhead. Clearly, this is not meant for general purpose use but rather for IoT only. Is it a good idea to truncate the authentication tag? I don't have an opinion about that but that's what the specifications make you use and that's also what is now in hardware. On 10/10/2017 01:05 AM, Sean Turner wrote: > Anybody else has thoughts on this? > > spt > >> On Oct 3, 2017, at 18:53, Sean Turner wrote: >> >> In the IANA registries draft (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates), we’ve added a recommended column to the Cipher Suites (CSs) registry (and some others). Right now, the criteria for getting a recommended mark is AEAD ciphers with strong authentication standards track ciphers. While that’s great generally, the list we’ve got five CSs that gave Joe and I pause: >> >> TLS_DHE_RSA_WITH_AES_128_CCM_8 >> TLS_DHE_RSA_WITH_AES_256_CCM_8 >> TLS_PSK_DHE_WITH_AES_128_CCM_8 >> TLS_PSK_DHE_WITH_AES_256_CCM_8 >> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 >> >> The CCM_8 CSs have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environment. In other words, this might be great for some IoT device but we should not generally be recommending these. >> >> We’re recommending that these five suites be dropped from the recommended list. Please let us know what you think. >> >> J&S >> (editor hats on) > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Oct 13 04:05:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0313239C for ; Fri, 13 Oct 2017 04:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZYDrj9x8CY1 for ; Fri, 13 Oct 2017 04:05:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291D3132026 for ; Fri, 13 Oct 2017 04:05:37 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 527BD80468; Fri, 13 Oct 2017 11:05:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 527BD80468 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1AC2360A99; Fri, 13 Oct 2017 11:05:35 +0000 (UTC) From: Hubert Kario To: Stephen Farrell Cc: tls@ietf.org Date: Fri, 13 Oct 2017 13:05:34 +0200 Message-ID: <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> In-Reply-To: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2761183.O94gRuIYnI"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 13 Oct 2017 11:05:36 +0000 (UTC) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 11:05:38 -0000 --nextPart2761183.O94gRuIYnI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote: > (With the obvious caveat that I hate the whole > idea... :-) to be clear: me too =20 > On 12/10/17 13:57, Hubert Kario wrote: > >> Anyway, I think key life length could be addressed in later drafts, but > >> the > >> inability of the client to identify (and possibly reject) the tapping > >> third > >> party is a "no go" for me... > >=20 > > yes, a three-way DH with two certificates (one IPS one EE server) does > > seem > > like a much better approach, especially if IPS certs need to have speci= al > > flags that make them useless for anything else and cannot be set by CAs= in > > public CA programs. >=20 > But... even if one did add names/certs for the wiretapper > or IPS or whatever then there could be more than one of > those who'd like to be able to interfere with the TLS > session, and there's no way I can see that makes sense for > the client and server to negotiate which wiretappers they > allow/like. my point is, that I may be forced to disclose contents of all my=20 communications to a specific entity, so I effectively have to trust it=20 (willingly or not), but that doesn't mean that I have to allow for wiretapp= ing=20 for arbitrary parties > This is all just squaring-the-circle, TLS is meant to be > a 2-party protocol (ignoring CAs) and I don't see any way > to make TLS a multi-party protocol that works. 1. Alice sends a share to Bob: g^a 2. Bob sends Alice's and his share to Carol: g^a, g^b, g^ab 3. Carol replies to Bob with her share added to Alice's and his: g^ac, g^bc 4. Bob sends the Carol's reply to Alice as a Server Key Share: g^bc 5. Alice calculates the shared secret g^bca 6. Bob calculates the shared secret: g^acb 7. Carol calculates the shared secret: g^abc so it doesn't look to me like it requires a lot of chamfer to fit that squa= re=20 peg in the round hole, only the 2 and 3 need to happen out-of band. of course, I haven't analysed how Carol would be authenticated in that=20 communication (if signing just the SKS by Carol is enough, transferred in t= he=20 encrypted extensions, with server signature of the handshake in certificate= =20 verify being sufficient for integrity) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2761183.O94gRuIYnI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZ4J3+AAoJEJKo0bgB0vX10AoP/0Nx7itqsIGQH8Cayxh2qwj8 SgpZyrpaci50tld6pbu/QGNDo02tyw7wxHIiQbONFa9hPCO8xPOOXceCFDxw1jYQ c0FZzeIMxXhKV/EmiSgakWNRlut3h4w+SSqWTtDllOru4xmjUNHOcfDpR0UqhUyH skFdKSisqHE8pJjX42QbfLY9UnWIiqLMND93elZXjRWA0486KY8KbRf8AWwZ3K6p 4Vi4gCTrGnrYShluo+dyDkI6v+XBFLJmtJyq4bYwEbFwcdDl8tw/endYrwYOj0X0 8l4Hsr8tNvrGyTWSixmhYzjywcb5uVlcgrDH3VmwXfGhJT7P48xN6kSBSrk04GxF uOP56f8vWdoJ099V5SsooALDE8COd0TJk6+yFJmXiIB6+VKqTcmPurflKuKu1McI aY7yr0kYYjW36Peq0C8Yr2rLuwhsfVzc+34qUWcM7koPZTdprjKyn42zD2Zqzx93 nKA36WT6kXNTg74+Q29Yebv2xpWHYtjOL3+IZvhl8AuvoCUwOBvtMYsetlrdZ/PE aBX4A2OneQ7njbc9qURFZILrIYH1vA0wbEFCpnkdRCIwIEdqXnEZr9XBg38nZtRD LmE7agwzXnc1ElEVCrYqA1+273ri3oxVpTsgIQtgkYraWTSZGo0Vb04ZDMH7E/l3 yf8VdCFMT1tF65iXY3bF =gpeD -----END PGP SIGNATURE----- --nextPart2761183.O94gRuIYnI-- From nobody Fri Oct 13 05:46:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F82133068 for ; Fri, 13 Oct 2017 05:46:19 -0700 (PDT) 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 3if2dsW3Fg8F for ; Fri, 13 Oct 2017 05:46:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BA2133053 for ; Fri, 13 Oct 2017 05:45:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A5502BE38; Fri, 13 Oct 2017 13:45:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR5Ke5dDlrsf; Fri, 13 Oct 2017 13:45:36 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 42FE7BE2E; Fri, 13 Oct 2017 13:45:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507898736; bh=epaqyVRHujv8yt2wyohSj9N/Bodf0HjYlH2xv0KHAJM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jSG2U0aihhyhsF3vzWi0SaA2UalqAYayGVed2piZXyaRJy36kWw2ffL49hZFBGHvD VZ5joswpdpKMNz2JSM4qKHSKfJ/kvf2KvUBuQFbfnHNAIxuijt0erwT+6TK9Dc8g5w kA+zyc1po9aO3AyTJIDiOYO6FIn0ooS/+0OdGOv4= To: Hubert Kario Cc: tls@ietf.org References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> Date: Fri, 13 Oct 2017 13:45:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="A0o2M8vFOJHb7gblqQUlkALGccnwSsSxe" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 12:46:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A0o2M8vFOJHb7gblqQUlkALGccnwSsSxe Content-Type: multipart/mixed; boundary="Sa6X1LMQusOQdDlLU2qJp6k7OvBJkpOjJ"; protected-headers="v1" From: Stephen Farrell To: Hubert Kario Cc: tls@ietf.org Message-ID: <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> In-Reply-To: <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> --Sa6X1LMQusOQdDlLU2qJp6k7OvBJkpOjJ Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 13/10/17 12:05, Hubert Kario wrote: > On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote: >> (With the obvious caveat that I hate the whole >> idea... :-) >=20 > to be clear: me too IMO the more we hear of that the better > 1. Alice sends a share to Bob: g^a > 2. Bob sends Alice's and his share to Carol: g^a, g^b, g^ab > 3. Carol replies to Bob with her share added to Alice's and his: g^ac, = g^bc > 4. Bob sends the Carol's reply to Alice as a Server Key Share: g^bc > 5. Alice calculates the shared secret g^bca > 6. Bob calculates the shared secret: g^acb > 7. Carol calculates the shared secret: g^abc >=20 > so it doesn't look to me like it requires a lot of chamfer to fit that = square=20 > peg in the round hole, only the 2 and 3 need to happen out-of band. >=20 > of course, I haven't analysed how Carol would be authenticated in that = > communication (if signing just the SKS by Carol is enough, transferred = in the=20 > encrypted extensions, with server signature of the handshake in certifi= cate=20 > verify being sufficient for integrity) So the problems with that are numerous but include: - there can be >1 carol, (and maybe all the carols also need to "approve" of one another), if we were crazy enough to try do this we'd have at least: - corporate outbound snooper - data-centre snooper (if you buy those supposed use-cases) - government snooper(s) in places where they don't care about doing that openly ...port 80 would suddenly be quicker than 443 again;-( - carol is quite likely to only have a name like: 2001:db8::bad:1dea or your.friendly-listener.bigcdn.example.net and authenticating those is essentially meaningless to the endpoints in most TLS contexts whether or not those endpoints have humans associated with them - the TLS endpoints can't handle the semantics of allowing in Carol(s) as those endpoints were designed to use TLS and not bolloxed-TLS (be that mcTLS or draft-rehired) So I think this ends up as bad as the design in draft-rehired. Which of them is more obviously bad is another question. Cheers, S. --Sa6X1LMQusOQdDlLU2qJp6k7OvBJkpOjJ-- --A0o2M8vFOJHb7gblqQUlkALGccnwSsSxe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ4LVvAAoJEC88hzaAX42iCsAIAIH1mgRnhcc88fZFaNRbQkwS b2L3UTBoC65eR2G5XTx2xpYQiwKEh+S40fBgFFBkBhTyEWxASmRmEvR1fSK6C6OX iHh4EZ6KZ6qEXlszxstu/UrxSKCvrPm9UMHYngNyXfVtlDyGpJ4TCUYrBq5tjXkV Gk9X71sodM/BgARGvJQ3ko2HFWDSvck3CW9iJSo71MskFVZ0tlz7aecg+t9ujsUd 1r6EQ2Qfu2cgXDZ4zshcloYutRZV+wE5jjcGPHItb1EXtVHtcjSpi4k6ciLATmT5 nHN4P+jeVyJleSMOintGNTL5rmWdsRNVh1yBMp18DwlFISjlibXp4NWdDq4fcvQ= =+PK1 -----END PGP SIGNATURE----- --A0o2M8vFOJHb7gblqQUlkALGccnwSsSxe-- From nobody Fri Oct 13 05:54:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31449133080 for ; Fri, 13 Oct 2017 05:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buu2YOjEeWco for ; Fri, 13 Oct 2017 05:53:57 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 18D0213207A for ; Fri, 13 Oct 2017 05:53:57 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id 8so19357319qtv.1 for ; Fri, 13 Oct 2017 05:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DE2fOSYid0M1oehKBoJY3VOgtGsgDaS8mNoS7C/RuxU=; b=yGFjhylgHNyPegHkUqIB6UX6Ndt55jz/J+sihSrHbuDqNcqz55JvihGfc6jHWs8Lxk Jdnq67c3hUitYERmMFKqKQdw8nUa3N3Ym0mwxe5c9LgnCEZATgkOorWIvnFPhawun1BZ 4XO9nkduvGRT1OGPeMLeQ6azqXyrDiCvd4AMdS4vQmO6sQpITijMXI9izOHo+u+Hu81d PxW6rcvRJtZeSeQ4DImNwnj22owUsqPGpcpr6qjZ3KcZnJOHxCBjesVJQKSPsGik9Yio mhw9B49t33R/IZGZWmQsRM6WQVygHGdzo466n3lY3i8tAxgFEKzhoI/72guurYDgU846 dRwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DE2fOSYid0M1oehKBoJY3VOgtGsgDaS8mNoS7C/RuxU=; b=fHbHSvsaH3oQDvh7ORj3pznIwAJi792MeGnC7xpmbegAt9JrrmsuYeazbdngj1tSCc 8U17eyFmX+k64zIxQxYluVAgTPBYM0SgBTSoeHFPyRRWsd4NlhGn5pPaTDSNNUHpVimI XxEPJ2iWTszj3S175/8NzIAzPVAmcDKPKTjuhgLAP2/dUo85p1WIqYxkRUv6oyPSwlxE Xwv4Q/qL2yuVFnsDYYgbxc1KFN8qOQiYq+aEwEERC5brWJcHEkBxZxXtOlQi5gApMRow exldqahPemNhR1Wqf8nNSyxyuyymLipqbwiMACtEiuklRPV13oYISOLu/3/+OacTBmdB 5XjA== X-Gm-Message-State: AMCzsaU9DBdxfToSVkqQFycZUeQKfMznRV38obg0Db+QKFPDp2MWPVs6 bRc1poZxfMc5PorGeD4l0bCiFs8GFHCbKWd6PTEX+g== X-Google-Smtp-Source: AOwi7QDNGsVme7+/5q7elbjDN9WKuUx57DazKmvGuKV6aamVsFgUCKE8Ij5KtqSK0rSM9DeC+rO9cTZJBGXLRfbSH6Q= X-Received: by 10.129.167.66 with SMTP id e63mr868427ywh.294.1507899235988; Fri, 13 Oct 2017 05:53:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 13 Oct 2017 05:53:15 -0700 (PDT) In-Reply-To: <1507875665.3178.19.camel@redhat.com> References: <1507875665.3178.19.camel@redhat.com> From: Eric Rescorla Date: Fri, 13 Oct 2017 05:53:15 -0700 Message-ID: To: Nikos Mavrogiannopoulos Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c079026518fbe055b6d26b2" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 12:53:59 -0000 --94eb2c079026518fbe055b6d26b2 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 12, 2017 at 11:21 PM, Nikos Mavrogiannopoulos wrote: > On Thu, 2017-10-12 at 16:13 -0700, Eric Rescorla wrote: > > Hi folks, > > > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > I believe the major issue with that is the fact that the record packet > format changes, but there is no way for a party in between to be able > to determine the record packet format without keeping session state. > Think not only of middle boxes, but of super-servers which may receive > of a stray udp packet which they have to forward to the appropriate > server [0]. With that change, they cannot figure whether the packet > contains the CID or not in a deterministic way for a random CID. > > One can hack around that limitation by providing a CID which starts > with 0xffff which is an illegal size currently for TLS or DTLS, but > would have to worry with future extensions to the protocol which may > increase the maximum size. Yes, Thomas raised this issue as well. Unfortunately, we need to take the structure of existing TLS records as it is, and at least in DTLS 1.3 we're going to effort to shorten the header and I'm not eager to make everyone pay on the wire whether they want to use connection ids or not. In DTLS 1.2, as you say, it seems most straightforward to just provide what would be an illegal length, as it seems pretty unlikely that any future DTLS extension is going to allow 65k-sized packets. In DTLS 1.3, we could probably steal one code point for this if we had to. Another worrying feature is that the client can make the server send up > to 255 verbatim bytes on the wire of his choice. Why was this feature > added? Are there use cases related with it (intro doesn't mention any), > or it was only thought as a make it as generic as possible approach? If > it is the latter, I'd recommend to provide a simple approach that > covers the described use cases. > Well, any connection ID feature of this type involves forcing the other side to send a certain amount of fixed verbatim data, so we're really just debating how long that value ought to be. There are good reasons to allow at least 16 octets (in the super-server case you suggest, you might want the connection ID to to be an encrypted label for the actual server, and it's much more convenient to encrypt 16-byte quantities because that's AES's block size and many of those machines will have AES-NI). And once you're carrying 16 bytes, I don't see a big point in minimizing it below that. If people want an upper limit that is greater than 16 (32?) I would be fine with that. -Ekr The same argument applies to the server being able to set such a long > sequence of verbatim bytes to each of the client packets. > > regards, > Nikos > > [0]. That was exactly my use case for introducing the CID info, as in > openconnect server, the super-server receives the stray UDP packets > arriving after a NAT disassociates existing connections. > > --94eb2c079026518fbe055b6d26b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 12, 2017 at 11:21 PM, Nikos Mavrogiannopoulos <nmav@redhat.c= om> wrote:
On Thu, 2017-10-12 at 16:13 -0700, Eric Rescorla wrote:
> Hi folks,
>
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html= /draft-rescorla-tls-dtls-connection-id-00

I believe the major issue with that is the fact that the record pack= et
format changes, but there is no way for a party in between to be able
to determine the record packet format without keeping session state.
Think not only of middle boxes, but of super-servers which may receive
of a stray udp packet which they have to forward to the appropriate
server [0]. With that change, they cannot figure whether the packet
contains the CID or not in a deterministic way for a random CID.

One can hack around that limitation by providing a CID which starts
with 0xffff which is an illegal size currently for TLS or DTLS, but
would have to worry with future extensions to the protocol which may
increase the maximum size.

Yes, Thomas rais= ed this issue as well. Unfortunately, we need to take the
structu= re of existing TLS records as it is, and at least in DTLS 1.3 we're
going to effort to shorten the header and I'm not eager to make = everyone
pay on the wire whether they want to use connection ids = or not.

In DTLS 1.2, as you say, it seems most str= aightforward to just provide
what would be an illegal length, as = it seems pretty unlikely that any
future DTLS extension is going = to allow 65k-sized packets. In DTLS 1.3,
we could probably steal = one code point for this if we had to.


Another worrying feature is that the client can make the server send up
to 255 verbatim bytes on the wire of his choice. Why was this feature
added? Are there use cases related with it (intro doesn't mention any),=
or it was only thought as a make it as generic as possible approach? If
it is the latter, I'd recommend to provide a simple approach that
covers the described use cases.

Well, a= ny connection ID feature of this type involves forcing the other side to
send a certain amount of fixed verbatim data, so we're really j= ust debating
how long that value ought to be. There are good reas= ons to allow at least
16 octets (in the super-server case you sug= gest, you might want the connection ID
to to be an encrypted labe= l for the actual server, and it's much more convenient
to enc= rypt 16-byte quantities because that's AES's block size and many of=
those machines will have AES-NI). And once you're carrying 1= 6 bytes,
I don't see a big point in minimizing it below that.= If people want an upper
limit that is greater than 16 (32?) I wo= uld be fine with that.

-Ekr


The same argument applies to th= e server being able to set such a long
sequence of verbatim bytes to each of the client packets.

regards,
Nikos

[0]. That was exactly my use case for introducing the CID info, as in
openconnect server, the super-server receives the stray UDP packets
arriving after a NAT disassociates existing connections.


--94eb2c079026518fbe055b6d26b2-- From nobody Fri Oct 13 06:00:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE9413207A for ; Fri, 13 Oct 2017 06:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4PhoIDYjy1N for ; Fri, 13 Oct 2017 06:00:20 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE694133047 for ; Fri, 13 Oct 2017 06:00:19 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id p1so19383940qtg.2 for ; Fri, 13 Oct 2017 06:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D6w9M6np3SCOIh7XIok5PeBJTr5oZGSzx//XA9dTAss=; b=ttISO1BxJMwCGIRz9EfYdM1E74XDCCh0j3hmZgNS69l50jStePXB6NhMhAg+qNJfzW vWl3fF/UvR10UqeMv8azb5Z+o2BmWWcYvI+THbpTPMvULTGYwIebeMVnwYQiD1hIz2hi KlPE6UEXh/urfhZbSEGacBKhhvWuerhxHIkJ7dKvXoWcKdhlrpNP9Rdk4DuU1N3VB2QI ygHoJKMLwWDlkWrbi/mNY8po0/gyDH1/jKE0iem5gyaGIXJp0cZgUnB3d4GDo0SvfIKg I58z2em6vsG17jlMhaFit52lSUuNHMHaIwnSfmUPzTW428J02muLwEI7YMy96XVQejBT dPhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D6w9M6np3SCOIh7XIok5PeBJTr5oZGSzx//XA9dTAss=; b=LlAcxQFiIBgGCD5oGL4piZWzBJQsUPb9SMv4WljHrD2DT9nJe1YdNwscC/994aPia+ anTTsohNQYbJawE2FoXwtpihrUOqizeNNltf40UslJXrVcqMIQqbDWdtU3SD3Pr+9flC dBXcTzZDxZy1bf4Hy1vJBcXHcQ1SEfsmGhFwHw9Sfw9QXCyfzD/JanYKRhwo1TNc4vrB npmGGVCRgzviKON0SSGcgUr1MuzMKIfxoa8kb7iIIxP+773Qwi52hFR3auLfsVhz81wq 6hkjBk9bbcFnwLO4Wm4W3OUevzbWAIigbJaSz7OVuktR9uhxlwWaf8a0VPpGNAWL201w siMw== X-Gm-Message-State: AMCzsaUN+9dkYNpFG3t1pJgefXxlJFRqjt8Nl0yJ4gowJXCR+gSvH0iC 0myrYbM/WMheSiFAy79uKm7NFqHUq520n1f4CxnVZQ== X-Google-Smtp-Source: AOwi7QDFP9alBjtROMwqhY1T8slUQGUXVYYaLVPqcIczL7VvBK2OXcbzVulakX2WikUGRgLAvyDtedzSXshA410jTjw= X-Received: by 10.37.20.195 with SMTP id 186mr862357ybu.339.1507899618791; Fri, 13 Oct 2017 06:00:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 13 Oct 2017 05:59:38 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 13 Oct 2017 05:59:38 -0700 Message-ID: To: yinxinxing Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113e798822b0ca055b6d3d31" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 13:00:22 -0000 --001a113e798822b0ca055b6d3d31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing wrote: > Hi Ekr, > > > > Thanks for your effort. The draft looks good. A few comments are listed > below. > > > > 1. Based on the draft, for either DTLS1.2 or 1.3, server can=E2=80= =99t > differentiate whether the packet from client is a =E2=80=9Cconnection ID= =E2=80=9D packet or > a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also > introduced this problem) > > Maybe we can add a new =E2=80=9CContentType=E2=80=9D in the DTLS record f= ormat to help > server identify the =E2=80=9Cconnection ID=E2=80=9D packet. In addition, = you see the length > of the record payload is limited by 2^14-1, this means the first two bits > of =E2=80=9Clength=E2=80=9D is zero. We could utilize this feature and se= t the first two > bits or more bits of CID being one, e.g., 1111=E2=80=A6.(but the CID must= be put > between sequence number and length). When server finds 1111 after sequenc= e > number, it knows this is a =E2=80=9Cconnection ID=E2=80=9D packet. Howeve= r, I don=E2=80=99t know > whether it is proper to use such magic number. In my view, adding new > contenttype may be a choice. > As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID that would not be a valid length field. This can actually just have the leading bit set. As we're revising the DTLS 1.3 record format, we would need to do something different for that. 2. For DTLS 1.2, there is no NewConnectionID and RequestConnectionID > message. DTLS 1.2 server and client also has the requirement to request f= or > a new CID, and at present, many products still use DTLS1.2 and I believe = it > will continue to be used for a long time even if TLS/DTLS1.3 is published= . > My point is that we need a corresponding method for updating CID for > DTLS1.2 too. > In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really that excited about putting a lot of effort into enhancing TLS 1.2. The basic extension works fine for them, but if they want to change CIDs, then they should adopt DTLS 1.3. I don=E2=80=99t quite understand the following sentences > > =E2=80=9CIn DTLS 1.2, connection ids are exchanged at the beginning of th= e > > DTLS session only. There is no dedicated "connection id update" > > message that allows new connection ids to be established mid-session, > > because DTLS 1.2 in general does not allow post-handshake messages > > that do not themselves begin other handshakes.=E2=80=9D > The only post-handshake messages allowed in DTLS 1.2 are ClientHello and HelloRequest. > Besides, for CID in DTLS1.3, I think the corresponding responding message= s > of NewConnectionID and RequestConnectionID are also needed to ensure tha= t > the peer has received CID. > No, you use the ACK for these ( https://tools.ietf.org/html/draft-ietf-tls-dtls13-01#section-7). This is one reason why there is not a straightforward port to DTLS 1.2 for these messages. > 4. The generation of CID should be more concrete. For example, > using random number or a counter? > I explicitly did not want to do that, because there are a lot of valid ways to generate CID. This is also what we did in QUIC. -Ekr > > > > Regards, > > Yin Xinxing > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* TLS [mailto:tls-bounces@ietf.org] *=E4=BB= =A3=E8=A1=A8 *Eric Rescorla > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B410=E6=9C=8813=E6=97= =A5 7:14 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* tls@ietf.org > *=E4=B8=BB=E9=A2=98:* [TLS] Connection ID Draft > > > > Hi folks, > > > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > > Comments welcome. > > > > -Ekr > > > > > > > --001a113e798822b0ca055b6d3d31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing <yinxinxing@huawei.com= > wrote:

Hi Ekr,

=C2=A0=

Thanks for your effort. The= draft looks good. A few comments are listed below.

=C2=A0=

1.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Based on the draft, fo= r either DTLS1.2 or 1.3, server can=E2=80=99t differentiate whether the pac= ket from client is a =E2=80=9Cconnection ID=E2=80=9D packet or a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also in= troduced this problem)

Maybe we can add a new = =E2=80=9CContentType=E2=80=9D in the DTLS record format to help server iden= tify the =E2=80=9Cconnection ID=E2=80=9D packet. In addition, you see the length of the record payload = is limited by 2^14-1, this means the first two bits of =E2=80=9Clength=E2= =80=9D is zero. We could utilize this feature and set the first two bits or= more bits of CID being one, e.g., 1111=E2=80=A6.(but the CID must be put between sequence number and length). When server finds 1111 after s= equence number, it knows this is a =E2=80=9Cconnection ID=E2=80=9D packet. = However, I don=E2=80=99t know whether it is proper to use such magic number= . In my view, adding new contenttype may be a choice.


As I said to Nikos, for DTLS 1.2, you can= use a specially-constructed CID that would not be a valid length field. Th= is can actually just have the leading bit set. As we're revising the DT= LS 1.3 record format, we would need to do something different for that.

2.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0For DTLS 1.2, th= ere is no NewConnectionID and RequestConnectionID message. DTLS 1.2 server = and client also has the requirement to request for a new CID, and at present, many products still use DTLS1.2 and I belie= ve it will continue to be used for a long time even if TLS/DTLS1.3 is publi= shed. My point is that we need a corresponding method for updating CID for = DTLS1.2 too.

In general, the WG is = working on TLS 1.3, not TLS 1.2, so I'm not really that excited about p= utting a lot of effort into enhancing TLS 1.2. The basic extension works fi= ne for them, but if they want to change CIDs, then they should adopt DTLS 1= .3.

<= div lang=3D"ZH-CN">
<= p class=3D"gmail-m_-651360533313825043MsoListParagraph" style=3D"margin-lef= t:18pt">

I don=E2=80=99t quite und= erstand the following sentences

=E2=80=9CIn DTLS 1.2, connection ids are = exchanged at the beginning of the

=C2=A0=C2=A0 DTLS session only.=C2=A0 The= re is no dedicated "connection id update"

=C2=A0=C2=A0 message that allows new conn= ection ids to be established mid-session,

=C2=A0=C2=A0 because DTLS 1.2 in general = does not allow post-handshake messages

=C2=A0=C2=A0 that do not = themselves begin other handshakes.=E2=80=9D


The only post-handshake messages allowed in DTLS 1.= 2 are ClientHello and HelloRequest.
=C2=A0

Besides, for CID in DTLS1= .3, I think the corresponding responding messages of =C2=A0NewConnectionID and RequestConnectionID are also needed to ensure that the peer has receiv= ed CID.


No, you use = the ACK for these (https://tools.ietf.org/html/draft-ietf-tls-dtls13-01#sec= tion-7). This is one reason why there is not a straightforward port to = DTLS 1.2 for these messages.
=C2=A0

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The generation of CID should = be more concrete. For example, using random number or a counter?
=

I explicitly did not want to do that, bec= ause there are a lot of valid ways to generate CID. This is also what we di= d in QUIC.

-Ekr

=C2=A0=

=C2=A0=

Regards,

Yin Xinxing

=C2=A0=

=E5=8F=91=E4=BB=B6=E4=BA=BA: TLS [mai= lto:tls-bounces@i= etf.org] =E4=BB=A3=E8=A1=A8 Eric Rescorla
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B410=E6=9C=8813=E6=97=A5 7:14
=E6=94=B6=E4=BB=B6=E4=BA=BA: tls@ietf= .org
=E4=B8=BB=E9=A2=98: [TLS] Connection ID Draft

=C2=A0

Hi folks,<= /p>

=C2=A0

I have just posted a first cut = at a connection ID draft.

=C2=A0

Comments welcome.=

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0


--001a113e798822b0ca055b6d3d31-- From nobody Fri Oct 13 06:15:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F4313295C for ; Fri, 13 Oct 2017 06:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 6EFHZLXCzE7y for ; Fri, 13 Oct 2017 06:15:06 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8736313207A for ; Fri, 13 Oct 2017 06:15:06 -0700 (PDT) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 8F1031679 for ; Fri, 13 Oct 2017 14:15:04 +0100 (BST) Received: by mail-it0-f50.google.com with SMTP id l196so10517653itl.4 for ; Fri, 13 Oct 2017 06:15:04 -0700 (PDT) X-Gm-Message-State: AMCzsaWIP7XM4PFbIdGLONFGRYcDPRlUioun6ZtBQ/yltsx2cCY2ynL/ zVs/GCBTn/LNm8M4bDwVEUWfJzQUOkoueSmE5qA= X-Google-Smtp-Source: ABhQp+RcT1F/2t563QhXoLURMXfonWjN/gpDYzO97OkIue0gonJdHDJXxCit7PSGefMRfnDYXMH9cjv8ojpM0METP8Y= X-Received: by 10.36.206.65 with SMTP id v62mr535949itg.104.1507900503004; Fri, 13 Oct 2017 06:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.44.200 with HTTP; Fri, 13 Oct 2017 06:15:02 -0700 (PDT) In-Reply-To: References: From: Matt Caswell Date: Fri, 13 Oct 2017 14:15:02 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 13:15:08 -0000 On 13 October 2017 at 07:31, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > To solve this, we'd need a place in the wire image of the record with > semantics: "I'm carrying a CID." > > In 1.2, we could use CT or version. (In 1.3, that would not be possible > because the diet header doesn't have them - too bad.) To me it'd make > slightly more sense to use the version. (I had previous discussions on this > topic with Nikos and he told me that though anyconnect does this version > override for some reasons, there is no reported conflict with middle-boxes.) > Also, there would be only one code-point to allocate, instead of separate > code-points for each CID-enabled content type variant. I'm happy to be > convinced of the opposite, though. Recently I met with Yin Xinxing and we have had much the same conversation about what a Connection ID draft would need to do, and how we could detect its use on the wire. Mechanisms we talked about included setting something in the "length" field, using ContentType or using version. IMO using "length" is just horrible. I'm also not keen on version - it further complicates the "is this version greater than, equal to, or less than this other version" question. It's already slightly complicated in code that implements both TLS and DTLS due to DTLS versions being high and decrementing for a new version. I foresee lots of subtle bugs and problems from reusing "version". In my mind ContentType is the way to go. > I guess my main point here is to make sure we do as much as we can to allow > simple, efficient, robust implementations, which are also, en passant, > Wireshark-friendly, and leave heuristics-based approaches only for when > there is no real alternative. I fully agree here! It does occur to me that we could go further along that road by swapping the order of the "length" and "cid" fields in the new record header format, so that the new fields appear at the end. Middlebox/wireshark code would then still be able to interpret it because the beginning of the header is identical. The length would be wrong of course (too short by cid_length bytes), but it would still be parseable. That could be fixed (by adding the cid_length to the payload length) but I'm not sure if its worth it. Matt From nobody Fri Oct 13 06:37:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B9B132F69 for ; Fri, 13 Oct 2017 06:37:20 -0700 (PDT) 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 qT2QWh31LGmr for ; Fri, 13 Oct 2017 06:37:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226721286C7 for ; Fri, 13 Oct 2017 06:37:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5D376BE2E; Fri, 13 Oct 2017 14:37:16 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHlaqwISAHrS; Fri, 13 Oct 2017 14:37:10 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8DE4BBE38; Fri, 13 Oct 2017 14:37:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507901830; bh=//2H47wP5xAtOLFKmDT7YWJf1kYcY+BwBatQxPZSRKA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JKO5QBuI0tcdlJy53bvLWCmH4RAkgyxUBSFM8zmQgbGG9ML4vSn7yY6ymyKphHIgj aDcMqQEGPMdp4WH+RbLqibu8+QDzFLCV4r9U66egGbgUy5BSdg+b4I6bIn8pLS2Dh5 /l1G3K/0Rz6q/8zMoZU8JX/omJh4aX9rZWlqpvEI= To: Eric Rescorla , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> Date: Fri, 13 Oct 2017 14:37:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BaKXiGI8f6hUCLoC4W16QAqWAUvnaswfF" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 13:37:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BaKXiGI8f6hUCLoC4W16QAqWAUvnaswfF Content-Type: multipart/mixed; boundary="KbjOCDflp2AAEdu3xcm1JvDivBWTfNWJo"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , "tls@ietf.org" Message-ID: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> Subject: Re: [TLS] Connection ID Draft References: In-Reply-To: --KbjOCDflp2AAEdu3xcm1JvDivBWTfNWJo Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 13/10/17 00:13, Eric Rescorla wrote: > Hi folks, >=20 > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 >=20 > Comments welcome. As a near-nit, I don't think "dismissed" is a good way to describe the analysis of some of the ideas that came up earlier. In particular, I still think there's merit in some use of a hash chains, to decrease linkability, even if that's not done for every packet. For example, considering a client that might detect an occasional change of 5-tuple, it could use something like id_n=3DH(foo||id_(n-1)) where foo is something dependent on the TLS session secrets (exporter-like) That way the TLS stacks can pre-calculate the next id (or a bunch of those) and then only lookups are needed (though the tables are bigger of course) just as with a static connection id. I'd argue that such designs not be dismissed. I accept that the design needs to end up being efficient enough to get used but I don't think that we need to go for the simplest possible design, if that exposes 5-tuple linkages in ways that setting up new TLS sessions would not. Cheers, S. >=20 > -Ekr >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --KbjOCDflp2AAEdu3xcm1JvDivBWTfNWJo-- --BaKXiGI8f6hUCLoC4W16QAqWAUvnaswfF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ4MGGAAoJEC88hzaAX42io9oH/01YxNyd95rxF/F06E3179jY qsWoQneuupEYynVHq2x/8dLJ5Bs8NbP5oQ1jIcIy/re6u8ccO1eEIS2GfHibLM/G 9dqFiGVrktnbj+IYK9K+tA/Ppu9Z5pcQlsySMReB0FKqkb5P1jJ3BIctFsRH8npp Yj5V7uV6nLiOGlV8rKowbl0rlu9Q9MRqGyvuJNPO8v8UO3E1JGAXBzzpeQ7G8LPe y1Xaq8H92jdVzhaKJ6LUY33h/o2ussR3wTeI62uamj+re1vaiN7bWypM4QqgiHVX D3folMbOteHhNcnG5pbaZS0DD7IdgaUz/DMZNKeoXPrdHuLK5FbOiJOlWd4UMwY= =C9O3 -----END PGP SIGNATURE----- --BaKXiGI8f6hUCLoC4W16QAqWAUvnaswfF-- From nobody Fri Oct 13 06:57:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB31133068 for ; Fri, 13 Oct 2017 06:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhNEJyoZwe76 for ; Fri, 13 Oct 2017 06:57:28 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44787132CE7 for ; Fri, 13 Oct 2017 06:57:28 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id n61so19682588qte.10 for ; Fri, 13 Oct 2017 06:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JQdOWzlwLBZdKbdL/AmYnWt6gIi5Qku3F1vcH17wRVo=; b=VWZdlwmPi7G2PQ0qRdmSMMd/yZvc3HcHYE9Wy26c92f8gDuohxL8E+6Wq1AlUPZ94v GL9599xoun0qVkY53q9H5z2meFMUmZUkAPAwjUZUwJeRinMPwxR1P3rBX7r3eh3qTcgC eab/AyW5ljiXiQh1lTAixri7Hv96jSJmpWdZ38XWAzKe+ibFD7qyGaYosGbmOAJv3J0X Uhf2iXIY1REqRUiium4RXZcLXxPM4zmEU5H8mzd3/0qVhwy9V3i/j5W1sIYMVBDHjkAx W73/1yAlrrMThZc0ugp9fQKqY2g0VFCOKfXumpf3nTAu5VVPSmcpkSHC9pwcg/RbFt/k 4tDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JQdOWzlwLBZdKbdL/AmYnWt6gIi5Qku3F1vcH17wRVo=; b=elmMzJqHG8LCbgs34Ru6D0zDotnIuIDhNvZgWL/TkwxPsbnWVqPqIkLuY4o+hXQv1N Aiaqn4/dcwLzJc6gUVhhiiUFtI+DU0U6qMK7fd8QgC5OdglqhDhYxzbimxyc3TNBjcJ3 5B7VyPtAC1z4ykWzgDz8CR5duywPSpmrcuZmc87GAtJ13kj63NZKlGJ5mTXtZ3LRJWK8 Ote732UQJTVBOuRwaBiE0VNoNVuFGnILn0aCOI9i9/tfWLLyV41UCYobIo9XB50Zla9C qcUBKhBQamH+tpxlblvYUfkheTYd2bSX9aijDd5GRagy3Qe4w1R0EGotnelbRCw1aveB 33oA== X-Gm-Message-State: AMCzsaVZcFRiXRIGa7dQSzqRoy1BoVKM3vwY3C4pMaV73dBTLGnjjtpV crahLpzzWyEi5jxALNm9Lb/iuVDqJqJz6J8b9rhAYA== X-Google-Smtp-Source: AOwi7QB84m2MGxquF/3OYwM3LkJQkpJ5P6vfA9gttSXQxeXqGoKG7Th1f0zRE60oKVkqvLCItx2PLArpVM0s89znT+Y= X-Received: by 10.129.36.1 with SMTP id k1mr994994ywk.485.1507903047432; Fri, 13 Oct 2017 06:57:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 13 Oct 2017 06:56:46 -0700 (PDT) In-Reply-To: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> From: Eric Rescorla Date: Fri, 13 Oct 2017 06:56:46 -0700 Message-ID: To: Stephen Farrell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1142e4cc7f8d90055b6e096e" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 13:57:32 -0000 --001a1142e4cc7f8d90055b6e096e Content-Type: text/plain; charset="UTF-8" On Fri, Oct 13, 2017 at 6:37 AM, Stephen Farrell wrote: > > > On 13/10/17 00:13, Eric Rescorla wrote: > > Hi folks, > > > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > > Comments welcome. > > As a near-nit, I don't think "dismissed" is a good way > to describe the analysis of some of the ideas that came > up earlier. > > In particular, I still think there's merit in some use > of a hash chains, to decrease linkability, even if that's > not done for every packet. > > For example, considering a client that might detect an > occasional change of 5-tuple, it could use something like > > id_n=H(foo||id_(n-1)) where foo is something dependent > on the TLS session secrets (exporter-like) > > That way the TLS stacks can pre-calculate the next id > (or a bunch of those) and then only lookups are needed > (though the tables are bigger of course) just as with a > static connection id. > > I'd argue that such designs not be dismissed. > I've seen a number of designs like these, but in general they have quite poor scaling properties. Can you describe the precise design you have in mind so that we can analyze it. -Ekr > > I accept that the design needs to end up being efficient > enough to get used but I don't think that we need to go > for the simplest possible design, if that exposes 5-tuple > linkages in ways that setting up new TLS sessions would > not. > > Cheers, > S. > > > > > > -Ekr > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > --001a1142e4cc7f8d90055b6e096e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Oct 13, 2017 at 6:37 AM, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:


On 13/10/17 00:13, Eric Rescorla wrote:
> Hi folks,
>
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html= /draft-rescorla-tls-dtls-connection-id-00
>
> Comments welcome.

As a near-nit, I don't think "dismissed" is a good way=
to describe the analysis of some of the ideas that came
up earlier.

In particular, I still think there's merit in some use
of a hash chains, to decrease linkability, even if that's
not done for every packet.

For example, considering a client that might detect an
occasional change of 5-tuple, it could use something like

=C2=A0 =C2=A0id_n=3DH(foo||id_(n-1)) where foo is something dependent
=C2=A0 =C2=A0on the TLS session secrets (exporter-like)

That way the TLS stacks can pre-calculate the next id
(or a bunch of those) and then only lookups are needed
(though the tables are bigger of course) just as with a
static connection id.

I'd argue that such designs not be dismissed.

=
I've seen a number of designs like these, but in general the= y
have quite poor scaling properties. Can you describe the precis= e
design you have in mind so that we can analyze it.
-Ekr
=C2=A0

I accept that the design needs to end up being efficient
enough to get used but I don't think that we need to go
for the simplest possible design, if that exposes 5-tuple
linkages in ways that setting up new TLS sessions would
not.

Cheers,
S.


>
> -Ekr
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


--001a1142e4cc7f8d90055b6e096e-- From nobody Fri Oct 13 06:59:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F050613295C for ; Fri, 13 Oct 2017 06:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 h3tdjbwamqMq for ; Fri, 13 Oct 2017 06:59:35 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11FE1286C7 for ; Fri, 13 Oct 2017 06:59:34 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9DDvHEa008937; Fri, 13 Oct 2017 14:59:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+1C18yrSQYS5PSqRDlSlZa2ghvvFqgRV6DXpd26L2Ak=; b=kVGUBL42t/sjTJ5JMPqEYCJsQcaDf/B6LkcoBpuPPZ0dF/SlR7hxfLHufejxLXB200+Z Cs/p5341FgwWRJ0SeBIGrsPu0ZVEQO5rF3U3SnP+Vvn/TXv6zdd7IaayU1ZWJcdvVH9s 4LjZCyryU72/k7DoTc3KAmH8uYP+TCCBAMp0qPwexbhzIPoAiiB3UUibTqmaHRuFEQZQ YGEL9OdyvWJSmA7Jk6ld9AFchDl4pFGj3khQYXhH8tYNlPPStubVbrAk0sJrax/Ouq1Q HSXWA8nzCnyFiLiQ8qsevXPB9qDU+JRPLWSI8AnkDeBakaaQXPWR36nSeOXJt8Hauz1e Fg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2djffstm28-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Oct 2017 14:59:30 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9DDuIX3000990; Fri, 13 Oct 2017 09:59:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2det8w4jur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 13 Oct 2017 09:59:29 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 13 Oct 2017 08:59:28 -0500 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.1263.000; Fri, 13 Oct 2017 08:59:28 -0500 From: "Salz, Rich" To: Stephen Farrell , Hubert Kario CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LcXG2AgAM/WgCAAPPgAIAABTcAgAFt2gCAABvygIAAFKOA Date: Fri, 13 Oct 2017 13:59:28 +0000 Message-ID: <213140BD-E889-47A1-A423-7E889F1FE869@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> In-Reply-To: <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.134] Content-Type: text/plain; charset="utf-8" Content-ID: <5BE049A8EAD2A0499BC51B720E80DCB9@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-13_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710130194 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-13_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710130194 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 13:59:36 -0000 SSBhbSBvcHBvc2VkIHRvIHRoZSBiYXNpYyBjb25jZXB0IG9mIGluamVjdGluZyBhIHRoaXJkLXBh cnR5IGludG8gdGhlIEUyRSBUTFMgcHJvY2Vzcy4NCg0KV2UgZG9u4oCZdCBldmVuIGhhdmUgYSBU TFMgMS4zIFJGQyB5ZXQuICBXZSBoYXZlIG5vIGRlcGxveW1lbnRzIHlldC4gIFdlIGhhdmUgbm8g aW5zaWdodCBpbnRvIHdoZXRoZXIgb3Igbm90IHRoZXJlIGlzIGFuIGFjdHVhbCBuZWVkIGZvciB0 aGlzLiAgSG93IGNhbiB3ZSBwdXQgdGhpcyBvbi1ob2xkIGZvciwgc2F5LCB0d28geWVhcnMuIA0K DQo= From nobody Fri Oct 13 07:17:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6271013308D for ; Fri, 13 Oct 2017 07:17:42 -0700 (PDT) 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 Sh8YKIusQvOl for ; Fri, 13 Oct 2017 07:17:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF1E13307D for ; Fri, 13 Oct 2017 07:17:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6E66ABE55; Fri, 13 Oct 2017 15:17:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX6cd_hlJFgF; Fri, 13 Oct 2017 15:17:37 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A7369BE53; Fri, 13 Oct 2017 15:16:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507904192; bh=fuugNg1HjgoiNDP/W0tYajfgsE2kl2Qv9FS20iqve20=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZLNfaXN9jbDy75jJsjdcO644fc6bK5tNBZy5CXcktJbD81DihNC2rdGILaHOVWUYs zmQEUMp1Lm0kmudupYx4zqUHdA8/P+uosTIfSlQmC7Kju2+0+YBvmBBabzfgkJ3rPr b3wwSqE9Ez7ie945LCCIDrFWYiVFXSeeJSb5iusU= To: Eric Rescorla Cc: "tls@ietf.org" References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> Date: Fri, 13 Oct 2017 15:16:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QwVAqfipiiLJHAWEDo5Wts4qNmrimfRp6" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 14:17:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QwVAqfipiiLJHAWEDo5Wts4qNmrimfRp6 Content-Type: multipart/mixed; boundary="TgBth7ngssAF78hSPnE3vME3EAI5hGBhQ"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> Subject: Re: [TLS] Connection ID Draft References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> In-Reply-To: --TgBth7ngssAF78hSPnE3vME3EAI5hGBhQ Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 13/10/17 14:56, Eric Rescorla wrote: > I've seen a number of designs like these, but in general they > have quite poor scaling properties. Can you describe the precise > design you have in mind so that we can analyze it. Sure, I can try... What I'm suggesting is that we define a way that a TLS node can change the connection ID to a new value that is hard to link to the old, as a function that can be used when the implementation chooses to use it. I'm not currently arguing that the ids should be changed for each packet. E.g. if a node is able to detect that the 5-tuple has just changed, it could use this then. If a node sends one packet per day over say an nb-IoT network where it might have a different IP address each time (not that we know how nb-IoT will operate, so I'm guessing:-) then it might make sense to do this for every packet. I assume ids are initialised in some reasonable way. To change an id, pick a value foo that depends on the TLS session, e.g. like an extractor, and that is not visible to the network. Then set next-id to H(foo||prev-id) or some similar construct. Receivers can store a set of ids calculated when the session is established. I'd guess storing two (current and next) might be a sensible thing to do. The inefficiently compared to simply incrementing the id value is to add another column to the lookup table I guess. I don't know if that's a big scaling deal or not. Cheers, S. --TgBth7ngssAF78hSPnE3vME3EAI5hGBhQ-- --QwVAqfipiiLJHAWEDo5Wts4qNmrimfRp6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ4Mq/AAoJEC88hzaAX42iHF4IAL0rhHT6tlL0QbKHLAEU1s8E E7YM+bPtI8JsrK16ymaC4TWSgu/P09ZtvoiHhIPNziO1W69IgFRe/a+IrcTDav/S 1zmojlr43a/SkH8mI8LobV6lvXW7IjFTP7jBCHRqUunURbpfodkjl5hDANCJJu/2 vvusDaqyb4M0j/m7rGcoFKfNn2eRlAVCbLiNsY/1+0DFEPs7fhFZK8mMtPe2UFC4 SpEUx0kx39c8rgsVAyLbKJk1xF3rQrNic5IhTmu7McsUm9TulTKigzUI/FGHOmqd Ue+q+QX6IECSMXUto0tOQmA97ZQxH70/VJasPSRL5vznc1f+pad1bs0QdE0DI7s= =Ui/o -----END PGP SIGNATURE----- --QwVAqfipiiLJHAWEDo5Wts4qNmrimfRp6-- From nobody Fri Oct 13 07:30:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E046A132F2E for ; Fri, 13 Oct 2017 07:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmU4Wt8KNWC9 for ; Fri, 13 Oct 2017 07:29:59 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAEF5120720 for ; Fri, 13 Oct 2017 07:29:58 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id z19so19893381qtg.11 for ; Fri, 13 Oct 2017 07:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OK/UQSpUWCMQL3SKvlHuc8OjjYZJURU3OfmO5l8M9Es=; b=CemsPhOTu0XNMv1RnedSvWqYgUj7nldS8dJCaDrwQOH07CrSfTGxbqipdcGZPZwdzM 9Q/5BZWimaLnJS/SxYo4TlM6IDjYNrLO0U+LnQ8sIvBXEnsn72jaTG8LLH68hUj9jAHM WVKgwbqqIiaa+2RAF1wmPQf5NZ6i8NIchMuwbFJ87cTudIRHYHTD1uEf93iNhR+c7sVW 16zN/7NWpXfxbwmUEl7IvA8GJyi3h1oTasgf+OdZ3y7xlhT0F6V1oTodxk90Ag9bobp3 JR4wPxa8FJh4FK3ertLTN1RtjdZD5x1CJ8n7I64rQiG0wd2CnX6zLbTMHlf6VmEOMUHB SnhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OK/UQSpUWCMQL3SKvlHuc8OjjYZJURU3OfmO5l8M9Es=; b=cI13ItcVia9ifvtj09uFn5JX2Eluf7knO0piAYzhYNyg4J1/SyhW3vo5DYlncIx23T Q8YhenAU8qwCc/HGw7Aicc/EZLGy+7zzdFDCLlEEVGQj2zo9t2KSdKGys2kxnJLIiHbx QW3d6498yzgTMDHiTzsZ7oEli4uAxsWs/dJunyDsYFhqMofuaz7ZMATj86u1iEmoqLBi yjRpAnpXtryYdodOLnIxMAdY/ia4XkvadCT0XwWs3VhvVbrZnUsU2f23XIZM0S6m8dvS 575A+cTKg4o3fO8TZBHTMGnnk2uaatOVSIqJhvqYhF9vNkMCzww8vtv3tStlSqldS45Y LKLg== X-Gm-Message-State: AMCzsaUS2o4yIucVcAoAA0Hja0v0VYiX2dTTuXz9TXqx5ok68uN/sXYN SvbTV1L2Vd5TsHNouWWzhzpcKLPpI9ZczBcERkSpqQ== X-Google-Smtp-Source: ABhQp+SMar09gxrytahNVX8Ulun2/NMXm06p2F5AqcLiG8sClnBDrevOix2pQ8CYX8g8GRDYkF3OSR4qls5zqIq9B+U= X-Received: by 10.37.51.68 with SMTP id z65mr1095535ybz.353.1507904998028; Fri, 13 Oct 2017 07:29:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 13 Oct 2017 07:29:17 -0700 (PDT) In-Reply-To: <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> From: Eric Rescorla Date: Fri, 13 Oct 2017 07:29:17 -0700 Message-ID: To: Stephen Farrell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1148aa62c379b3055b6e7dfb" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 14:30:01 -0000 --001a1148aa62c379b3055b6e7dfb Content-Type: text/plain; charset="UTF-8" On Fri, Oct 13, 2017 at 7:16 AM, Stephen Farrell wrote: > > Hiya, > > On 13/10/17 14:56, Eric Rescorla wrote: > > I've seen a number of designs like these, but in general they > > have quite poor scaling properties. Can you describe the precise > > design you have in mind so that we can analyze it. > > Sure, I can try... > > What I'm suggesting is that we define a way that a TLS > node can change the connection ID to a new value that > is hard to link to the old, as a function that can be > used when the implementation chooses to use it. > > I'm not currently arguing that the ids should be changed > for each packet. E.g. if a node is able to detect that the > 5-tuple has just changed, it could use this then. If a > node sends one packet per day over say an nb-IoT network > where it might have a different IP address each time (not > that we know how nb-IoT will operate, so I'm guessing:-) > then it might make sense to do this for every packet. > > I assume ids are initialised in some reasonable way. > > To change an id, pick a value foo that depends on the TLS > session, e.g. like an extractor, and that is not visible > to the network. Then set next-id to H(foo||prev-id) or > some similar construct. > > Receivers can store a set of ids calculated when the > session is established. I'd guess storing two (current > and next) might be a sensible thing to do. > > The inefficiently compared to simply incrementing the > id value is to add another column to the lookup table I > guess. I don't know if that's a big scaling deal or not. > There are a number of cases where this is actually much harder to implement than a design where one side dictates the connection ID. For instance, consider a design where you have a pool of servers P1, P2, ... P_n with a load balancer in front. Each server i generates connection IDs of the form i || Random. The load balancer then just looks at the first byte and routes to the appropriate load balancer [0]. In this design, the LB can be totally stateless, whereas in the design you propose, it has to (a) have a back-channel to the server to get the initial conn-id (b), do crypto (c) store state for all the live connections. In addition, consider what happens when you get a CID you don't recognize. It might be nonsense but it might be that there was a cryptic CID change (e.g., the client did two changes but you missed a packet). You need to decide the number of changes you're willing to tolerate and then the table has to be that big times the number of connections (or you need to fill it in whenever you get an unknown CID, which the attacker can send you at any time). -Ekr [0] This has non-ideal topology-hiding properties, but there are obvious extensions with better properties. --001a1148aa62c379b3055b6e7dfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 13, 2017 at 7:16 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya,

On 13/10/17 14:56, Eric Rescorla wrote:
> I've seen a number of designs like these, but in general they
> have quite poor scaling properties. Can you describe the precise
> design you have in mind so that we can analyze it.

Sure, I can try...

What I'm suggesting is that we define a way that a TLS
node can change the connection ID to a new value that
is hard to link to the old, as a function that can be
used when the implementation chooses to use it.

I'm not currently arguing that the ids should be changed
for each packet. E.g. if a node is able to detect that the
5-tuple has just changed, it could use this then. If a
node sends one packet per day over say an nb-IoT network
where it might have a different IP address each time (not
that we know how nb-IoT will operate, so I'm guessing:-)
then it might make sense to do this for every packet.

I assume ids are initialised in some reasonable way.

To change an id, pick a value foo that depends on the TLS
session, e.g. like an extractor, and that is not visible
to the network. Then set next-id to H(foo||prev-id) or
some similar construct.

Receivers can store a set of ids calculated when the
session is established. I'd guess storing two (current
and next) might be a sensible thing to do.

The inefficiently compared to simply incrementing the
id value is to add another column to the lookup table I
guess. I don't know if that's a big scaling deal or not.

There are a number of cases where this is actuall= y much harder to implement than a design where one side dictates the connec= tion ID. For instance, consider a design where you have a pool of servers P= 1, P2, ... P_n with a load balancer in front.
Each server i gener= ates connection IDs of the form i || Random. The load balancer then just lo= oks at the first byte and routes to the appropriate load balancer [0]. In t= his design, the LB can be totally stateless, whereas in the design you prop= ose, it has to (a) have a back-channel to the server to get the initial con= n-id (b), do crypto (c) store state for all the live connections.

In addition, consider what happens when you get a CID you d= on't recognize. It might be nonsense but it might be that there was a c= ryptic CID change (e.g., the client did two changes but you missed a packet= ). You need to decide the number of changes you're willing to tolerate = and then the table has to be that big times the number of connections (or y= ou need to fill it in whenever you get an unknown CID, which the attacker c= an send you at any time).

-Ekr

[0] This has non-ideal topology-hiding properties, but there are obvi= ous extensions with better properties.


=
--001a1148aa62c379b3055b6e7dfb-- From nobody Fri Oct 13 07:53:04 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC35133079 for ; Fri, 13 Oct 2017 07:53:03 -0700 (PDT) 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 mRSXfhkvEfmL for ; Fri, 13 Oct 2017 07:53:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DDF13306C for ; Fri, 13 Oct 2017 07:53:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F21A7BE49; Fri, 13 Oct 2017 15:52:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03975mUJ9Ho1; Fri, 13 Oct 2017 15:52:56 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 23362BE50; Fri, 13 Oct 2017 15:52:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507906375; bh=o+qJsboZLe/0+OaUtO13o9iwdvTPpA3267aLQ5/DxJ0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Zfm98Qafa2ncprEwGH+p1MrJEqmYm5JYCU0pLcyi8KqBOEmNMSZUeUixX2Z5Q/eMy DEOFS7+XhwMTB7cjI943lsAZe3fYajWpWTfxbwAvgSOrjws9SscTmjpskOTacVpFjp JO/IOgPm1LduI3anyWHUQygTZ4WDsKfHJpEQhLIM= To: Eric Rescorla Cc: "tls@ietf.org" References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> Date: Fri, 13 Oct 2017 15:52:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rJrfoRXdCGkeJfVFIaIgD8VXHKwbtgcOJ" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 14:53:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rJrfoRXdCGkeJfVFIaIgD8VXHKwbtgcOJ Content-Type: multipart/mixed; boundary="oLjrRMn265Vmsm4RiSb6IA4fk3vcpaHCq"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> Subject: Re: [TLS] Connection ID Draft References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> In-Reply-To: --oLjrRMn265Vmsm4RiSb6IA4fk3vcpaHCq Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 13/10/17 15:29, Eric Rescorla wrote: > There are a number of cases where this is actually much harder to imple= ment > than a design where one side dictates the connection ID. For instance, > consider a design where you have a pool of servers P1, P2, ... P_n with= a > load balancer in front. > Each server i generates connection IDs of the form i || Random. The loa= d > balancer then just looks at the first byte and routes to the appropriat= e > load balancer [0]. In this design, the LB can be totally stateless, whe= reas > in the design you propose, it has to (a) have a back-channel to the ser= ver > to get the initial conn-id (b), do crypto (c) store state for all the l= ive > connections. Pre-pending a fixed length (known to both sides) load-balancer ID would be fine, sure. That'd change the function to something like: next-id =3D lb-id || H(foo||prev-id) So long as each load balancer is busy enough that still has the hard-to-link property I think. The length of the lb-id could be fixed or part of the negotiation, with zero being a fine length when there's no lb-id needed. I think this'd work ok regardless of who controls the initial id value, so long as we don't need ids to work like tickets (where the id value would be the ciphertext of some state info). >=20 > In addition, consider what happens when you get a CID you don't recogni= ze. > It might be nonsense but it might be that there was a cryptic CID chang= e > (e.g., the client did two changes but you missed a packet). You need to= > decide the number of changes you're willing to tolerate and then the ta= ble > has to be that big times the number of connections (or you need to fill= it > in whenever you get an unknown CID, which the attacker can send you at = any > time). Yes, schemes like this can be worse when packets go missing around the time of an id change. However, I think with this scheme (which isn't even on a napkin yet, just these mails:-), the sending side would just make the change when they want, and wouldn't signal that it's changed the id. So, in some cases (say if receivers store current and next, and id changes and packet losses are infrequent) a single packet drop would be just that and the id change wouldn't affect things at all. In the putative nb-IoT case I mentioned before then it could be a good bit worse unless the receiver stores a bunch of future ids. (I agree some work is needed to figure out if there's an acceptable scheme here, so for now I'm arguing that we not preclude such schemes when adopting your draft.) In figuring this out, I'd argue that we ought be comparing ideas like this against two things: 1) the simplest solution that does allow linkabillity and 2) the costs of setting up a new TLS session to avoid linkability. While this or similar schemes will look bad compared to (1), they will likely look pretty good compared to (2). Of course, how one evaluates such comparisons will depend on how serious a threat one considers linkabillity. I'd argue that many devices that'll need connections ids will be devices where the possibility of linkability could be a significant threat and where new TLS session establishment will be rare, so we therefore ought provide some good method of avoiding linkability. Cheers, S. --oLjrRMn265Vmsm4RiSb6IA4fk3vcpaHCq-- --rJrfoRXdCGkeJfVFIaIgD8VXHKwbtgcOJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ4NNGAAoJEC88hzaAX42iokEIAI8C6Mqe1BVEviDky5vmCmNa BxUIF23hIQiDcorL63+BfpHA7OIpcieDXhvoJo0wXyx/dxEwuogKSBAJTowOyqTa pyNpdOYTLW1B762qKDJJd5YlIGI0xlIz4ZTzgK5Zz2frBa9qOUH/rFaHHZwvlrsQ 8dVzyQQYjw8mDTH5UMHvkhwIYAIXyi4en+Lg1+jz9rt2TAp1HMxyeNiFMb83tTRi rHguDQByNMot37wVirLwO5KUE1H8tmo0A7S2Ml4pnFNtzr1OnO6xODBKdN266akc 8Ps2VvkISW0citVbkpAU4C5jA8b8XPvXP7JLBkwiIzFsie9TkpoMUVENTJhhLw4= =tvtG -----END PGP SIGNATURE----- --rJrfoRXdCGkeJfVFIaIgD8VXHKwbtgcOJ-- From nobody Fri Oct 13 08:41:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55898126E64 for ; Fri, 13 Oct 2017 08:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1wNJm91uy-y for ; Fri, 13 Oct 2017 08:41:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 4900A126B71 for ; Fri, 13 Oct 2017 08:41:00 -0700 (PDT) Received: from [192.168.91.203] ([80.92.116.99]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LnkiR-1dcBqx0hnL-00hvaN; Fri, 13 Oct 2017 17:40:48 +0200 To: yinxinxing , Eric Rescorla , "tls@ietf.org" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <9800fbbc-f23f-139d-b5a9-ef6515123f73@gmx.net> Date: Fri, 13 Oct 2017 17:40:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:V/REjixbURmfn7tIe4XeoWH/GYMK2TKIqvX5jpoYGVrDigUDbH9 v3uYvX/cV/i1yYt4TyHz8eZNJYBQep+389U7icuuHXeM5eChduqUbddZzEF8JjCTYgsI45F WJ/XiPsVka8ISHsM+5nENI2BBcjjefTs6IWWuHPH6ikbEodIyggur/wJldSyOBtJWmfQPgC MPXy6pactgfv9qGxM2mVg== X-UI-Out-Filterresults: notjunk:1;V01:K0:bA5C/zqWaC0=:Iri4QCgh6oTGOkUSJ5Apca QccYUwyrU3mzkSS4p8r2G4zliweL/XCrUhBPDbPbgoztXkZQXGyBuTXhGFA2i2+OWqnXPop2p BRrmj1H9sdMDDPUPw2DqTPIsUxvlxK9BRMNwJWCiV3eZxyYprPEnfhTc+sU4Pjp8VZfLMY8Bi AprWKigp1vfQF2reetPARg8BAv1T7zlrKhXF0AfvwmxtJeMhy7/ZQzzOqE7kWKRE5wLaphiNR uBp6efQTn2qrtmkuf+A7KKmP/JHX1LnEQ9h7d+c2ihVbQCE10yzfXJiaJTVCDbruFK7lgzLrF YbWAhicCLJTH4L0VJiXDLwRh8JCkeQyebvN3tDCKgDpZ3AwQnp90nvdNElM85xIS7eiw6vba8 cTTAN5RgnZysdgoXPvIvxvpUVZ+Mu9QX+XvRrvqs8iRyTTaozuvYoV1hTdirN9VNQDdRHbrQg Ij/ZeyC5GjDQQcrIzCLwDSqWogQO+I1lXuj5Bo+M1W2diRbRh3n6ENygXJHBtNwPspOcrXGp5 IDg4oJZ3bmDzQoHqxS4qNFAlp28nubDfXI8RpNPFhVxSTe7NV2Fe9AW+YkvwU8LVJ2IpF3hXQ onGjvbl6a5b2lNtd6jAr+ewSmeEOTrrsbXEamqWoB0Nce+8p1AS8zDI656w+UUqnJFoNqGlw5 9s0a0ixk1nsTZIk5GdCvVN5jD3TBYWqdXAmF3EftNoHPXL8xlK+D/lvu0l+MToT7Hognc5E/N H8y31wtk/c/WZUfsd+eWFOxOvbPUCheu2NjtBbQbXUNcw/DaOTqCcLvkDge1eITEQcIYCHP/3 t9DT7WZ81LrgMtxbPp1QbO8H2i+/yF57JdRRiHlc9esDhZfA3M= Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 15:41:03 -0000 I would like to focus on one of the points raised below: > 3.       We have a practical usecase in IoT. The IOT device, like > intelligent water meter, sends one message per day, and goes to sleep. > It wakes up in the second day and sends a message and then goes to > sleep. If it always (or for a long time) use the same CID, there may be > a risk of tracing IOT device or the owner of this device. Therefore, it > is important to recommend user to update CID once it finishes sending > message. For the CID in DTLS1.2, this becomes worse. The user is typically not doing anything. Without this CID extension you would send a full exchange or use session resumption. This would allow someone in the middle to see the handshake. In DTLS/TLS 1.2 this would reveal the client certificate. With DTLS 1.3 and this extension you would hide the certificate and you could echange new CIDs and switch between them every day. The source IP address will most likely still reveal the subscriber (if you consider some cooperation with the ISP). So, you actually get pretty good privacy properties with DTLS 1.3 & CID (unless some of the data center folks destroy it again with their fancy extensions). With DTLS 1.2 there is only a performance benefit but the privacy properties remain the same IMHO. Ciao Hannes > >   > > Regards, > > Yin Xinxing > >   > > *å‘件人:*TLS [mailto:tls-bounces@ietf.org] *代表 *Eric Rescorla > *å‘é€æ—¶é—´:*2017å¹´10月13æ—¥7:14 > *收件人:*tls@ietf.org > *主题:*[TLS] Connection ID Draft > >   > > Hi folks, > >   > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > >   > > Comments welcome. > >   > > -Ekr > >   > >   > >   > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Oct 13 08:59:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA49126B71 for ; Fri, 13 Oct 2017 08:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtDEbAGkAbGN for ; Fri, 13 Oct 2017 08:59:06 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 7834A126E64 for ; Fri, 13 Oct 2017 08:59:06 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id 8so20446602qtv.1 for ; Fri, 13 Oct 2017 08:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pk7ZHhTfBkbKe2P7GHbLX+m/OPOpxBOrOsHqgTKnD40=; b=hrPInjA6S0VydltjtANsgQWFApDyWDSQ68KidFnBVawpPJXbUwTHpYn603IrXKc/d6 DOhFlcoMQBJM6GvIbCUdiIabNs6tnBLDQBBQ6Hz7trR8LimnfaP/EcN+ktngRKO5+98G zQWBG47F+5M60QXyaDfsXQWqBRQXfORIrYqDyVzGL/4W+gSx0Tov5u8maP6CTsyOwwzl 5VcgyRmy3wxmY5kPDb5UxJEKxwIsR29ae6W17L6S3pSl68sX8duqCDAm1KMZZUgPxk+6 OUXH/Q64UEhGwBzYRhPQ2T12gk9KoLx8hQ/Jv9ldx4oAFr/6G0ZKmOdHmr3gYTCIdcA3 WSgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pk7ZHhTfBkbKe2P7GHbLX+m/OPOpxBOrOsHqgTKnD40=; b=NwNj/5L9qk1QYqug4NQBWmz3gOfRPYrqLkP7AwUIZ+gLCpmYvAilIjOJxY+oIUbcHR NmB925UIVZT4Uo7SXJz/HMQi+eEEMKySNaxnlbtjHZjEj2Xl/yKP3TPJ2PVXAnFXaU4L 8mqft/Itpa69o6CXZ7EVRjJUND/6kiStEvoYojS70yWNWuvyhevxZ8J6UIPpMYXeJ2Pm hNbTEr8TFJq+rHBkWLlovF7scBGCgV3m+IZBoDc6EgMN1xy7/wxfVfGZv0Sc5+kUBxu4 XfB7DdxgoRByzhAyo+mlAwTviEX7MU2NmxD6s5Wki1PCj351/AA++g2cpuAnyNdR1jvG 3cug== X-Gm-Message-State: AMCzsaXNhpV6z/xaU3c/C56mTpkbvLC8ZqvkLDeRcvOHCGYDGq2PImDJ Uu/hGl/WA3eFhrDDiZnbvk+PcKMRsOzU5m7tdKfGqQ== X-Google-Smtp-Source: AOwi7QAiRGNzFzTuY+im2OgFoKZ7YTuR8RrDLsPuqPPdjBV6rhvNJhMt+xIwOjTGj1IjcItR+DAn5sz8YMb28xVB69g= X-Received: by 10.129.86.212 with SMTP id k203mr1231976ywb.155.1507910345517; Fri, 13 Oct 2017 08:59:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 13 Oct 2017 08:58:24 -0700 (PDT) In-Reply-To: <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> From: Eric Rescorla Date: Fri, 13 Oct 2017 08:58:24 -0700 Message-ID: To: Stephen Farrell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11431f927f8ce5055b6fbcfd" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 15:59:09 -0000 --001a11431f927f8ce5055b6fbcfd Content-Type: text/plain; charset="UTF-8" On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell wrote: > > Hiya, > > On 13/10/17 15:29, Eric Rescorla wrote: > > There are a number of cases where this is actually much harder to > implement > > than a design where one side dictates the connection ID. For instance, > > consider a design where you have a pool of servers P1, P2, ... P_n with a > > load balancer in front. > > Each server i generates connection IDs of the form i || Random. The load > > balancer then just looks at the first byte and routes to the appropriate > > load balancer [0]. In this design, the LB can be totally stateless, > whereas > > in the design you propose, it has to (a) have a back-channel to the > server > > to get the initial conn-id (b), do crypto (c) store state for all the > live > > connections. > > Pre-pending a fixed length (known to both sides) load-balancer > ID would be fine, sure. That'd change the function to something > like: > next-id = lb-id || H(foo||prev-id) > > So long as each load balancer is busy enough that still has the > hard-to-link property I think. The length of the lb-id could be > fixed or part of the negotiation, with zero being a fine length > when there's no lb-id needed. > Well, this is a lot more complicated for the client and unless you place very strict limits on lb-id, it ends up with the server just dictating an identifier to the client so you have the scheme in this draft. > I think this'd work ok regardless of who controls the initial id > value, so long as we don't need ids to work like tickets (where > the id value would be the ciphertext of some state info). > That's actually a design that people consider quite often and has been discussed for QUIC. > In addition, consider what happens when you get a CID you don't recognize. > > It might be nonsense but it might be that there was a cryptic CID change > > (e.g., the client did two changes but you missed a packet). You need to > > decide the number of changes you're willing to tolerate and then the > table > > has to be that big times the number of connections (or you need to fill > it > > in whenever you get an unknown CID, which the attacker can send you at > any > > time). > > Yes, schemes like this can be worse when packets go missing > around the time of an id change. > > However, I think with this scheme (which isn't even on a napkin > yet, just these mails:-), Sure but we contemplated a number of these designs for QUIC, so we're not starting from scratch here. > he sending side would just make the > change when they want, and wouldn't signal that it's changed the > id. So, in some cases (say if receivers store current and next, > and id changes and packet losses are infrequent) a single packet > drop would be just that and the id change wouldn't affect things > at all. In the putative nb-IoT case I mentioned before then it > could be a good bit worse unless the receiver stores a bunch of > future ids. (I agree some work is needed to figure out if there's > an acceptable scheme here, so for now I'm arguing that we not > preclude such schemes when adopting your draft.) > > In figuring this out, I'd argue that we ought be comparing ideas > like this against two things: 1) the simplest solution that does > allow linkabillity and 2) the costs of setting up a new TLS > session to avoid linkability. While this or similar schemes will > look bad compared to (1), they will likely look pretty good > compared to (2). > > Of course, how one evaluates such comparisons will depend on how > serious a threat one considers linkabillity. I'd argue that many > devices that'll need connections ids will be devices where the > possibility of linkability could be a significant threat and where > new TLS session establishment will be rare, so we therefore ought > provide some good method of avoiding linkability. > I'd say three things here: 1. First, as I said we considered a lot of different designs for providing better unlinkability than the design in this draft, and none of the ones that did significantly better had reasonable scaling properties. 2. The precise point of designing this as an extension is that if we had a better design we could drop it in with a new extension code point, so accepting this design doesn't preclude anything. 3. You seem to be claiming that your design has better linkability properties than the design in this draft, but as far as I can tell that's not correct. In both cases, either side can occasionally change conn-ids (you can't change in each packet for the scaling reasons I indicated). In your design one side does so unilaterally, but there are packet loss concerns, and in the draft, you have to solicit new conn-ids from the peer but as long as you have one you can change unilaterally. The primary difference in your design is that the IDs are opaque rather than containing data contributed by the other side, but that difference is immediately weakened as soon as you try to introduce structure to handle things like the server topology and also comes at the cost of needing a much larger ID space in each packet to avoid hash collisions. -Ekr > Cheers, > S. > > > > > --001a11431f927f8ce5055b6fbcfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya,

On 13/10/17 15:29, Eric Rescorla wrote:
> There are a number of cases where this is actually much harder to impl= ement
> than a design where one side dictates the connection ID. For instance,=
> consider a design where you have a pool of servers P1, P2, ... P_n wit= h a
> load balancer in front.
> Each server i generates connection IDs of the form i || Random. The lo= ad
> balancer then just looks at the first byte and routes to the appropria= te
> load balancer [0]. In this design, the LB can be totally stateless, wh= ereas
> in the design you propose, it has to (a) have a back-channel to the se= rver
> to get the initial conn-id (b), do crypto (c) store state for all the = live
> connections.

Pre-pending a fixed length (known to both sides) load-balancer
ID would be fine, sure. That'd change the function to something
like:
=C2=A0 =C2=A0 next-id =3D lb-id || H(foo||prev-id)

So long as each load balancer is busy enough that still has the
hard-to-link property I think. The length of the lb-id could be
fixed or part of the negotiation, with zero being a fine length
when there's no lb-id needed.

Well,= this is a lot more complicated for the client and unless you place
very strict limits on lb-id, it ends up with the server just dictating a= n
identifier to the client so you have the scheme in this draft.<= /div>

=C2=A0
I think= this'd work ok regardless of who controls the initial id
value, so long as we don't need ids to work like tickets (where
the id value would be the ciphertext of some state info).
<= div>
That's actually a design that people consider quite = often and has been discussed
for QUIC.

<= br>

> In addition, consider what happens when you get a CID you don't re= cognize.
> It might be nonsense but it might be that there was a cryptic CID chan= ge
> (e.g., the client did two changes but you missed a packet). You need t= o
> decide the number of changes you're willing to tolerate and then t= he table
> has to be that big times the number of connections (or you need to fil= l it
> in whenever you get an unknown CID, which the attacker can send you at= any
> time).

Yes, schemes like this can be worse when packets go missing
around the time of an id change.

However, I think with this scheme (which isn't even on a napkin
yet, just these mails:-),=C2=A0

Sure but we= contemplated a number of these designs for QUIC, so we're not
starting from scratch here.


=C2= =A0
he sending side would just make the=
change when they want, and wouldn't signal that it's changed the id. So, in some cases (say if receivers store current and next,
and id changes and packet losses are infrequent) a single packet
drop would be just that and the id change wouldn't affect things
at all. In the putative nb-IoT case I mentioned before then it
could be a good bit worse unless the receiver stores a bunch of
future ids. (I agree some work is needed to figure out if there's
an acceptable scheme here, so for now I'm arguing that we not
preclude such schemes when adopting your draft.)

In figuring this out, I'd argue that we ought be comparing ideas
like this against two things: 1) the simplest solution that does
allow linkabillity and 2) the costs of setting up a new TLS
session to avoid linkability. While this or similar schemes will
look bad compared to (1), they will likely look pretty good
compared to (2).

Of course, how one evaluates such comparisons will depend on how
serious a threat one considers linkabillity. I'd argue that many
devices that'll need connections ids will be devices where the
possibility of linkability could be a significant threat and where
new TLS session establishment will be rare, so we therefore ought
provide some good method of avoiding linkability.

=
I'd say three things here:

1. First= , as I said we considered a lot of different designs for providing
better unlinkability than the design in this draft, and none of the
=
ones that did significantly better had reasonable scaling properties.<= /div>

2. The precise point of designing this as an exten= sion is that if we
had a better design we could drop it in with a= new extension code point,
so accepting this design doesn't p= reclude anything.

3. You seem to be claiming that = your design has better linkability
properties than the design in = this draft, but as far as I can tell that's
not correct. In b= oth cases, either side can occasionally change
conn-ids (you can&= #39;t change in each packet for the scaling reasons
I indicated).= In your design one side does so unilaterally, but there
are pack= et loss concerns, and in the draft, you have to solicit new
conn-= ids from the peer but as long as you have one you can change
unil= aterally.

The primary difference in your design is= that the IDs are opaque
rather than containing data contributed = by the other side, but that
difference is immediately weakened as= soon as you try to introduce
structure to handle things like the= server topology and also comes
at the cost of needing a much lar= ger ID space in each packet to
avoid hash collisions.
<= br>
-Ekr


Cheers,
S.





--001a11431f927f8ce5055b6fbcfd-- From nobody Fri Oct 13 09:28:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2277133080 for ; Fri, 13 Oct 2017 09:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un7OmxaeRXle for ; Fri, 13 Oct 2017 09:28:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5901613307E for ; Fri, 13 Oct 2017 09:28:37 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A178B7F7A9; Fri, 13 Oct 2017 16:28:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A178B7F7A9 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4664E6047F; Fri, 13 Oct 2017 16:28:35 +0000 (UTC) From: Hubert Kario To: Stephen Farrell Cc: tls@ietf.org Date: Fri, 13 Oct 2017 18:28:28 +0200 Message-ID: <2421126.h5uzTUJ9N8@pintsize.usersys.redhat.com> In-Reply-To: <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2191384.m66Y9dbkKa"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 13 Oct 2017 16:28:37 +0000 (UTC) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 16:28:39 -0000 --nextPart2191384.m66Y9dbkKa Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 13 October 2017 14:45:35 CEST Stephen Farrell wrote: > On 13/10/17 12:05, Hubert Kario wrote: > > On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote: > >> (With the obvious caveat that I hate the whole > >> idea... :-) > >=20 > > to be clear: me too >=20 > IMO the more we hear of that the better >=20 > > 1. Alice sends a share to Bob: g^a > > 2. Bob sends Alice's and his share to Carol: g^a, g^b, g^ab > > 3. Carol replies to Bob with her share added to Alice's and his: g^ac, > > g^bc > > 4. Bob sends the Carol's reply to Alice as a Server Key Share: g^bc > > 5. Alice calculates the shared secret g^bca > > 6. Bob calculates the shared secret: g^acb > > 7. Carol calculates the shared secret: g^abc > >=20 > > so it doesn't look to me like it requires a lot of chamfer to fit that > > square peg in the round hole, only the 2 and 3 need to happen out-of > > band. > >=20 > > of course, I haven't analysed how Carol would be authenticated in that > > communication (if signing just the SKS by Carol is enough, transferred = in > > the encrypted extensions, with server signature of the handshake in > > certificate verify being sufficient for integrity) >=20 > So the problems with that are numerous but include: >=20 > - there can be >1 carol, (and maybe all the carols also need to > "approve" of one another), if we were crazy enough to try do > this we'd have at least: > - corporate outbound snooper > - data-centre snooper (if you buy those supposed use-cases) true > - government snooper(s) in places where they don't care about > doing that openly out of scope and directly against the WG agenda > ...port 80 would suddenly be quicker than 443 again;-( well, that would be an argument for making the server report the encryption= =20 keys to the middlebox instead of this squaring of the hole > - carol is quite likely to only have a name like: 2001:db8::bad:1dea > or your.friendly-listener.bigcdn.example.net and authenticating > those is essentially meaningless to the endpoints in most TLS contexts > whether or not those endpoints have humans associated with them not a problem, you need to trust the organisation (internal CA), not specif= ic=20 machines > - the TLS endpoints can't handle the semantics of allowing in Carol(s) > as those endpoints were designed to use TLS and not bolloxed-TLS (be > that mcTLS or draft-rehired) which is the entire point of it - we don't want this to be something=20 clandestine or invisible to the client =20 > So I think this ends up as bad as the design in draft-rehired. Which > of them is more obviously bad is another question. "draft-rehired"? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2191384.m66Y9dbkKa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZ4OmsAAoJEJKo0bgB0vX1wrUP/1l3RlGtPYy1HeAQvYYvokCc qyIrI9Md479idRZsirejMYsmSBQJg6oaPN62zWpZ5JX+4ZC+mjiZLTpsPWTaAV8+ ZosSRVH5MvvqxI3+F8fzHAUdw+gDpwei3nLxrMaJU1RUp/RP3GLBKqUDkNGXYqzS JP17QZeEdKzYHu3vd5icTk0Xlw/0IeqWMaQkl35FYCpgE9pYsKs5VNeUVybVFbI8 EgwlFUIHaRmSNTzfl9OcIs10HbO8BkUS5AkGMYSXodEwH4KDFEW4lszm1G27mesT rIYcB7+Cyf8onXWhB9Gm5OM/uL8QvNR/o7f9pO1+aFg3yYUp39/LhlJAOzDZT9CZ J+rgTb33xkjajBPLLLMxTgqN4ViyP2XUT4GccYriVY39TnzrHptNWyv5Qg/pLSR4 xtPhUym06mHxz9nmXgyQ+w3wGIexi3wqG9cyATm6ozSvoKbfarQ86QSQ1sZ9NuP3 4885XG06nsbV/wmXySYlZWbUDPRi2NIKwTrSQf676W2GVJkFyNqKDTfywYhRE31R opnuvsR7mgSzh7pAOGUWxPXbvoedCXSKsTn+Zyx5eMIx+lkR/GD8m2WfvSaaqmwh CIFoLtaRBNiBl38vQVG96yNtaeBooTNfcpXmlts53donARSvQugmBcVGUm4n6GAK CqFQj3xhEXK7+ryMaYhg =CfS6 -----END PGP SIGNATURE----- --nextPart2191384.m66Y9dbkKa-- From nobody Fri Oct 13 19:00:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567041320CF for ; Fri, 13 Oct 2017 19:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kHuuvab-vapJ for ; Fri, 13 Oct 2017 19:00:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C101241F3 for ; Fri, 13 Oct 2017 19:00:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXR67195; Sat, 14 Oct 2017 02:00:13 +0000 (GMT) Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Oct 2017 03:00:12 +0100 Received: from DGGEMI508-MBS.china.huawei.com ([169.254.3.228]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0301.000; Sat, 14 Oct 2017 10:00:03 +0800 From: yinxinxing To: Stephen Farrell , Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AQHTQ6/jzwfbCTuMF0C4wkI09eDpT6LhQz+AgAAFfACAAAWEgIABSPsg Date: Sat, 14 Oct 2017 02:00:02 +0000 Message-ID: References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> In-Reply-To: <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59E16FAD.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.228, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4be5258770b575f21713cf51650b7029 Archived-At: Subject: [TLS] =?utf-8?b?562U5aSNOiAgQ29ubmVjdGlvbiBJRCBEcmFmdA==?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 02:00:17 -0000 SSBhZ3JlZSB3aXRoIFN0ZXBoZW4uIEl0IGlzIGVzc2VudGlhbCB0byBlbnN1cmUgdGhlIG5ldyBj b25uZWN0aW9uIElEIGNvdWxkbid0IGJlIGxpbmtlZCB0byB0aGUgb2xkIG9uZSB0byBhdm9pZCB0 cmFja2luZyByaXNrLg0KDQpIb3dldmVyLCBpdCBpcyBzb21lIHNvcnQgb2YgaW1wbGVtZW50YXRp b24gaXNzdWVzLCBhbmQgdGhlcmUgYXJlIG1vcmUgd2F5cyB0byBkbyB0aGF0KG5vdCBvbmx5IGhh c2ggbWV0aG9kKS4gTWF5YmUgd2UgY2FuIGF0IGxlYXN0IGdpdmUgc3VnZ2VzdGlvbnMgb3Igd2Fy bmluZyBpbiB0aGUgZHJhZnQuDQoNClJlZ2FyZHMsDQpZaW4gWGlueGluZyANCg0KLS0tLS3pgq7k u7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9y Z10g5Luj6KGoIFN0ZXBoZW4gRmFycmVsbA0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0MTDmnIgxM+aX pSAyMjoxNw0K5pS25Lu25Lq6OiBFcmljIFJlc2NvcmxhDQrmioTpgIE6IHRsc0BpZXRmLm9yZw0K 5Li76aKYOiBSZTogW1RMU10gQ29ubmVjdGlvbiBJRCBEcmFmdA0KDQoNCkhpeWEsDQoNCk9uIDEz LzEwLzE3IDE0OjU2LCBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPiBJJ3ZlIHNlZW4gYSBudW1iZXIg b2YgZGVzaWducyBsaWtlIHRoZXNlLCBidXQgaW4gZ2VuZXJhbCB0aGV5IGhhdmUgDQo+IHF1aXRl IHBvb3Igc2NhbGluZyBwcm9wZXJ0aWVzLiBDYW4geW91IGRlc2NyaWJlIHRoZSBwcmVjaXNlIGRl c2lnbiB5b3UgDQo+IGhhdmUgaW4gbWluZCBzbyB0aGF0IHdlIGNhbiBhbmFseXplIGl0Lg0KDQpT dXJlLCBJIGNhbiB0cnkuLi4NCg0KV2hhdCBJJ20gc3VnZ2VzdGluZyBpcyB0aGF0IHdlIGRlZmlu ZSBhIHdheSB0aGF0IGEgVExTIG5vZGUgY2FuIGNoYW5nZSB0aGUgY29ubmVjdGlvbiBJRCB0byBh IG5ldyB2YWx1ZSB0aGF0IGlzIGhhcmQgdG8gbGluayB0byB0aGUgb2xkLCBhcyBhIGZ1bmN0aW9u IHRoYXQgY2FuIGJlIHVzZWQgd2hlbiB0aGUgaW1wbGVtZW50YXRpb24gY2hvb3NlcyB0byB1c2Ug aXQuDQoNCkknbSBub3QgY3VycmVudGx5IGFyZ3VpbmcgdGhhdCB0aGUgaWRzIHNob3VsZCBiZSBj aGFuZ2VkIGZvciBlYWNoIHBhY2tldC4gRS5nLiBpZiBhIG5vZGUgaXMgYWJsZSB0byBkZXRlY3Qg dGhhdCB0aGUgNS10dXBsZSBoYXMganVzdCBjaGFuZ2VkLCBpdCBjb3VsZCB1c2UgdGhpcyB0aGVu LiBJZiBhIG5vZGUgc2VuZHMgb25lIHBhY2tldCBwZXIgZGF5IG92ZXIgc2F5IGFuIG5iLUlvVCBu ZXR3b3JrIHdoZXJlIGl0IG1pZ2h0IGhhdmUgYSBkaWZmZXJlbnQgSVAgYWRkcmVzcyBlYWNoIHRp bWUgKG5vdCB0aGF0IHdlIGtub3cgaG93IG5iLUlvVCB3aWxsIG9wZXJhdGUsIHNvIEknbSBndWVz c2luZzotKSB0aGVuIGl0IG1pZ2h0IG1ha2Ugc2Vuc2UgdG8gZG8gdGhpcyBmb3IgZXZlcnkgcGFj a2V0Lg0KDQpJIGFzc3VtZSBpZHMgYXJlIGluaXRpYWxpc2VkIGluIHNvbWUgcmVhc29uYWJsZSB3 YXkuDQoNClRvIGNoYW5nZSBhbiBpZCwgcGljayBhIHZhbHVlIGZvbyB0aGF0IGRlcGVuZHMgb24g dGhlIFRMUyBzZXNzaW9uLCBlLmcuIGxpa2UgYW4gZXh0cmFjdG9yLCBhbmQgdGhhdCBpcyBub3Qg dmlzaWJsZSB0byB0aGUgbmV0d29yay4gVGhlbiBzZXQgbmV4dC1pZCB0byBIKGZvb3x8cHJldi1p ZCkgb3Igc29tZSBzaW1pbGFyIGNvbnN0cnVjdC4NCg0KUmVjZWl2ZXJzIGNhbiBzdG9yZSBhIHNl dCBvZiBpZHMgY2FsY3VsYXRlZCB3aGVuIHRoZSBzZXNzaW9uIGlzIGVzdGFibGlzaGVkLiBJJ2Qg Z3Vlc3Mgc3RvcmluZyB0d28gKGN1cnJlbnQgYW5kIG5leHQpIG1pZ2h0IGJlIGEgc2Vuc2libGUg dGhpbmcgdG8gZG8uDQoNClRoZSBpbmVmZmljaWVudGx5IGNvbXBhcmVkIHRvIHNpbXBseSBpbmNy ZW1lbnRpbmcgdGhlIGlkIHZhbHVlIGlzIHRvIGFkZCBhbm90aGVyIGNvbHVtbiB0byB0aGUgbG9v a3VwIHRhYmxlIEkgZ3Vlc3MuIEkgZG9uJ3Qga25vdyBpZiB0aGF0J3MgYSBiaWcgc2NhbGluZyBk ZWFsIG9yIG5vdC4NCg0KQ2hlZXJzLA0KUy4NCg0K From nobody Fri Oct 13 19:28:50 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A3B132944 for ; Fri, 13 Oct 2017 19:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4GOLeE-TiaTB for ; Fri, 13 Oct 2017 19:28:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63D21241F3 for ; Fri, 13 Oct 2017 19:28:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXR69321; Sat, 14 Oct 2017 02:28:44 +0000 (GMT) Received: from DGGEMI403-HUB.china.huawei.com (10.3.17.136) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Oct 2017 03:28:43 +0100 Received: from DGGEMI508-MBS.china.huawei.com ([169.254.3.228]) by dggemi403-hub.china.huawei.com ([10.3.17.136]) with mapi id 14.03.0301.000; Sat, 14 Oct 2017 10:28:34 +0800 From: yinxinxing To: Hannes Tschofenig , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AdND9UCTy0qV4eX+RfS1VDVqmNEmOwAAVQkAACcLt3A= Date: Sat, 14 Oct 2017 02:28:33 +0000 Message-ID: References: <9800fbbc-f23f-139d-b5a9-ef6515123f73@gmx.net> In-Reply-To: <9800fbbc-f23f-139d-b5a9-ef6515123f73@gmx.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59E1765C.0029, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.228, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4be5258770b575f21713cf51650b7029 Archived-At: Subject: [TLS] =?utf-8?b?562U5aSNOiAgQ29ubmVjdGlvbiBJRCBEcmFmdA==?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 02:28:48 -0000 SGkgSGFubmVzLA0KDQoiZXhjaGFuZ2UgbmV3IENJRHMgYW5kIHN3aXRjaCBiZXR3ZWVuIHRoZW0g ZXZlcnkgZGF5IiBtYXkgbm90IGJlIGEgZ29vZCBjaG9pY2UgZm9yIHBvd2VyIGNvbnN0cmFpbmVk IElPVCBkZXZpY2VzLiBGcm9tIHRoZSBwb2ludCBvZiBzYXZpbmcgYmF0dGVyeSwgaXQgaXMgYmV0 dGVyIHRvIHRyYW5zZmVyIHRoZSBuZXcgQ0lEIHRvIHRoZSBvdGhlciBwZWVyIGluIHRoZSBhcHBs aWNhdGlvbiByZXNwb25kaW5nIG1lc3NhZ2UgaW4gcGFzc2luZywgaW5zdGVhZCBvZiBzZW5kaW5n IGFuIGluZGVwZW5kZW50IHVwZGF0aW5nIENJRCBtZXNzYWdlLiANCg0KSW4gYWRkaXRpb24sIGxp a2Ugd2hhdCBTdGVwaGVuIG1lbnRpb25lZCwgaXQgaXMgZXNzZW50aWFsIHRvIGF2b2lkIGxpbmth YmlsaXR5IGJldHdlZW4gbmV3IENJRCBhbmQgb2xkIENJRC4gVGhpcyBpcyBub3QgY292ZXJlZCBp biB0aGlzIGRyYWZ0Lg0KDQpGb3IgMS4yLCBpbiB0aGlzIGRyYWZ0LCB0aGVyZSBpcyBubyBOZXdD b25uZWN0aW9uSUQgYW5kIFJlcXVlc3RDb25uZWN0aW9uSUQgbWVzc2FnZSwgaG93IGNhbiB0aGUg Q0lEIGJlIHVwZGF0ZWQuIFRoaXMgaXMgd2hhdCBJIG1lYW4gIndvcnNlIi4NCg0KUmVnYXJkcywN CllpbiBYaW54aW5nDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogSGFubmVz IFRzY2hvZmVuaWcgW21haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0XSANCuWPkemAgeaX tumXtDogMjAxN+W5tDEw5pyIMTPml6UgMjM6NDENCuaUtuS7tuS6ujogeWlueGlueGluZzsgRXJp YyBSZXNjb3JsYTsgdGxzQGlldGYub3JnDQrkuLvpopg6IFJlOiBbVExTXSBDb25uZWN0aW9uIElE IERyYWZ0DQoNCkkgd291bGQgbGlrZSB0byBmb2N1cyBvbiBvbmUgb2YgdGhlIHBvaW50cyByYWlz ZWQgYmVsb3c6DQo+IDMuwqDCoMKgwqDCoMKgIFdlIGhhdmUgYSBwcmFjdGljYWwgdXNlY2FzZSBp biBJb1QuIFRoZSBJT1QgZGV2aWNlLCBsaWtlIA0KPiBpbnRlbGxpZ2VudCB3YXRlciBtZXRlciwg c2VuZHMgb25lIG1lc3NhZ2UgcGVyIGRheSwgYW5kIGdvZXMgdG8gc2xlZXAuDQo+IEl0IHdha2Vz IHVwIGluIHRoZSBzZWNvbmQgZGF5IGFuZCBzZW5kcyBhIG1lc3NhZ2UgYW5kIHRoZW4gZ29lcyB0 byANCj4gc2xlZXAuIElmIGl0IGFsd2F5cyAob3IgZm9yIGEgbG9uZyB0aW1lKSB1c2UgdGhlIHNh bWUgQ0lELCB0aGVyZSBtYXkgDQo+IGJlIGEgcmlzayBvZiB0cmFjaW5nIElPVCBkZXZpY2Ugb3Ig dGhlIG93bmVyIG9mIHRoaXMgZGV2aWNlLiANCj4gVGhlcmVmb3JlLCBpdCBpcyBpbXBvcnRhbnQg dG8gcmVjb21tZW5kIHVzZXIgdG8gdXBkYXRlIENJRCBvbmNlIGl0IA0KPiBmaW5pc2hlcyBzZW5k aW5nIG1lc3NhZ2UuIEZvciB0aGUgQ0lEIGluIERUTFMxLjIsIHRoaXMgYmVjb21lcyB3b3JzZS4N Cg0KDQpUaGUgdXNlciBpcyB0eXBpY2FsbHkgbm90IGRvaW5nIGFueXRoaW5nLg0KDQoNCldpdGhv dXQgdGhpcyBDSUQgZXh0ZW5zaW9uIHlvdSB3b3VsZCBzZW5kIGEgZnVsbCBleGNoYW5nZSBvciB1 c2Ugc2Vzc2lvbiByZXN1bXB0aW9uLiBUaGlzIHdvdWxkIGFsbG93IHNvbWVvbmUgaW4gdGhlIG1p ZGRsZSB0byBzZWUgdGhlIGhhbmRzaGFrZS4NCkluIERUTFMvVExTIDEuMiB0aGlzIHdvdWxkIHJl dmVhbCB0aGUgY2xpZW50IGNlcnRpZmljYXRlLg0KDQpXaXRoIERUTFMgMS4zIGFuZCB0aGlzIGV4 dGVuc2lvbiB5b3Ugd291bGQgaGlkZSB0aGUgY2VydGlmaWNhdGUgYW5kIHlvdSBjb3VsZCBlY2hh bmdlIG5ldyBDSURzIGFuZCBzd2l0Y2ggYmV0d2VlbiB0aGVtIGV2ZXJ5IGRheS4gVGhlIHNvdXJj ZSBJUCBhZGRyZXNzIHdpbGwgbW9zdCBsaWtlbHkgc3RpbGwgcmV2ZWFsIHRoZSBzdWJzY3JpYmVy IChpZiB5b3UgY29uc2lkZXIgc29tZSBjb29wZXJhdGlvbiB3aXRoIHRoZSBJU1ApLg0KDQpTbywg eW91IGFjdHVhbGx5IGdldCBwcmV0dHkgZ29vZCBwcml2YWN5IHByb3BlcnRpZXMgd2l0aCBEVExT IDEuMyAmIENJRCAodW5sZXNzIHNvbWUgb2YgdGhlIGRhdGEgY2VudGVyIGZvbGtzIGRlc3Ryb3kg aXQgYWdhaW4gd2l0aCB0aGVpciBmYW5jeSBleHRlbnNpb25zKS4gV2l0aCBEVExTIDEuMiB0aGVy ZSBpcyBvbmx5IGEgcGVyZm9ybWFuY2UgYmVuZWZpdCBidXQgdGhlIHByaXZhY3kgcHJvcGVydGll cyByZW1haW4gdGhlIHNhbWUgSU1ITy4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KPiANCj4gwqANCj4g DQo+IFJlZ2FyZHMsDQo+IA0KPiBZaW4gWGlueGluZw0KPiANCj4gwqANCj4gDQo+ICrlj5Hku7bk uro6KlRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSAq5Luj6KGoICpFcmljIFJlc2Nv cmxhDQo+ICrlj5HpgIHml7bpl7Q6KjIwMTflubQxMOaciDEz5pelNzoxNA0KPiAq5pS25Lu25Lq6 Oip0bHNAaWV0Zi5vcmcNCj4gKuS4u+mimDoqW1RMU10gQ29ubmVjdGlvbiBJRCBEcmFmdA0KPiAN Cj4gwqANCj4gDQo+IEhpIGZvbGtzLA0KPiANCj4gwqANCj4gDQo+IEkgaGF2ZSBqdXN0IHBvc3Rl ZCBhIGZpcnN0IGN1dCBhdCBhIGNvbm5lY3Rpb24gSUQgZHJhZnQuDQo+IA0KPiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC0w MA0KPiANCj4gwqANCj4gDQo+IENvbW1lbnRzIHdlbGNvbWUuDQo+IA0KPiDCoA0KPiANCj4gLUVr cg0KPiANCj4gwqANCj4gDQo+IMKgDQo+IA0KPiDCoA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGluZyBsaXN0 DQo+IFRMU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Rscw0KPiANCg== From nobody Fri Oct 13 19:37:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2FF1321F5 for ; Fri, 13 Oct 2017 19:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuGak_Mtrfvr for ; Fri, 13 Oct 2017 19:37:24 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 1BAC71241F3 for ; Fri, 13 Oct 2017 19:37:24 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id z28so20389340qtz.13 for ; Fri, 13 Oct 2017 19:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UEi/Kv/U873+MpCM+eaCI1p2eicbUyTrP7BD3X1DmX8=; b=DtHZm1iu3M1VtF6eA/qHKrimrUnZizrw7QuHFGcmUXSf8UFSLc/nQNxnpb+B56LgoY BW5ttGRzSF/KoGc9aQi53AQVjH3CTNwVpzKE7yX8+pqQQaYmPYMrAE9jXX0LOn9k5n/8 MLtauvnPHvpn9hKl5VCoEi4kmLE7Q8ibR1O+/FkJo/NTQqPFNS6b6tblmxaHAOtuiqux OVEn/O+jCXHuWGjDjUV3fzm2LZnFtU/8meiErsLYndY3fS9zuxy+leCP/Asm8AbWqbHd F/wIO0AAa1efcX/NuMEwCIQPyLJ3lQ4NyseCdTtWcU/RvAxxKmyE/xttXMwHNnt9USEq 4LVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UEi/Kv/U873+MpCM+eaCI1p2eicbUyTrP7BD3X1DmX8=; b=jgk+MAWvj5MxUOPxQDy2T2/btR0hgZCEKDQ8Iec+SgiaQ9RpiWXnKVZjl6t8y5pPjN DFfNrWRjGMFjCDeIdYvR491rwTqhiLUlj5MBe0grrNeIx2R4ecnRFRGiLYAbm/z8Z9O3 ATEBXCIqxz+LabSOuODc3Ezry8NOBw3mXre4F+zXHG/KrDFkVcyG1uBL5hb2YY7ZyTzt GojJ5qcIuDUE1uTTHVPz40FBzgIlsHb4zYZPOHcwVIcTdgGx8SZNIKO2UlLlx4tuz9o8 lB6K+dD5JG92Qk/dxFgXRfrjy/+jKrOeDjj2/zJqdIDKaKUp5NvTgooIt+xcCxzqq0GZ 5mqA== X-Gm-Message-State: AMCzsaX8gYU2RkWdFOUfZmnjW53SS/dFwBRPOWOShFGO/BOkEwbe2MHo +virgAOq3NUuHdRY/C/qhLPtWko+ktOSwW54+k2b/6dL X-Google-Smtp-Source: ABhQp+QqvRbE9pA9vEKZWLb0YFoktNCE2LPsSua8gNfoJ/0B2hbUU0I/TRnj6a+OD62vZQllAtI36bhT0Gd9jeITRsM= X-Received: by 10.37.45.83 with SMTP id s19mr11050ybe.400.1507948643168; Fri, 13 Oct 2017 19:37:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 13 Oct 2017 19:36:42 -0700 (PDT) In-Reply-To: References: <9800fbbc-f23f-139d-b5a9-ef6515123f73@gmx.net> From: Eric Rescorla Date: Fri, 13 Oct 2017 19:36:42 -0700 Message-ID: To: yinxinxing Cc: Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f4030435b0103749a0055b78a71b" Archived-At: Subject: Re: [TLS] =?utf-8?b?562U5aSNOiAgQ29ubmVjdGlvbiBJRCBEcmFmdA==?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 02:37:26 -0000 --f4030435b0103749a0055b78a71b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 13, 2017 at 7:28 PM, yinxinxing wrote: > Hi Hannes, > > "exchange new CIDs and switch between them every day" may not be a good > choice for power constrained IOT devices. From the point of saving batter= y, > it is better to transfer the new CID to the other peer in the application > responding message in passing, instead of sending an independent updating > CID message. > Well, that's obviously something you could do but it's not part of TLS, though of course you could use the connection ID in TLS. > > In addition, like what Stephen mentioned, it is essential to avoid > linkability between new CID and old CID. This is not covered in this draf= t. > New security considerations text welcome. For 1.2, in this draft, there is no NewConnectionID and RequestConnectionID > message, how can the CID be updated. This is what I mean "worse". > Yes. As I said, I'm not really trying to fix TLS 1.2, though I'm happy to have the extension used both places. -Ekr > Regards, > Yin Xinxing > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Hannes Tschofenig [mailto:hannes.tschofenig@= gmx.net] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B410=E6=9C=8813=E6=97=A5= 23:41 > =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing; Eric Rescorla; tls@ietf.org > =E4=B8=BB=E9=A2=98: Re: [TLS] Connection ID Draft > > I would like to focus on one of the points raised below: > > 3. We have a practical usecase in IoT. The IOT device, like > > intelligent water meter, sends one message per day, and goes to sleep. > > It wakes up in the second day and sends a message and then goes to > > sleep. If it always (or for a long time) use the same CID, there may > > be a risk of tracing IOT device or the owner of this device. > > Therefore, it is important to recommend user to update CID once it > > finishes sending message. For the CID in DTLS1.2, this becomes worse. > > > The user is typically not doing anything. > > > Without this CID extension you would send a full exchange or use session > resumption. This would allow someone in the middle to see the handshake. > In DTLS/TLS 1.2 this would reveal the client certificate. > > With DTLS 1.3 and this extension you would hide the certificate and you > could echange new CIDs and switch between them every day. The source IP > address will most likely still reveal the subscriber (if you consider som= e > cooperation with the ISP). > > So, you actually get pretty good privacy properties with DTLS 1.3 & CID > (unless some of the data center folks destroy it again with their fancy > extensions). With DTLS 1.2 there is only a performance benefit but the > privacy properties remain the same IMHO. > > Ciao > Hannes > > > > > > > > > > Regards, > > > > Yin Xinxing > > > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:*TLS [mailto:tls-bounces@ietf.org] *=E4=BB= =A3=E8=A1=A8 *Eric Rescorla > > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2017=E5=B9=B410=E6=9C=8813=E6=97= =A57:14 > > *=E6=94=B6=E4=BB=B6=E4=BA=BA:*tls@ietf.org > > *=E4=B8=BB=E9=A2=98:*[TLS] Connection ID Draft > > > > > > > > Hi folks, > > > > > > > > I have just posted a first cut at a connection ID draft. > > > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > > > > > > Comments welcome. > > > > > > > > -Ekr > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --f4030435b0103749a0055b78a71b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 13, 2017 at 7:28 PM, yinxinxing <yinxinxing@huawei.com= > wrote:
Hi Hannes,

"exchange new CIDs and switch between them every day" may not be = a good choice for power constrained IOT devices. From the point of saving b= attery, it is better to transfer the new CID to the other peer in the appli= cation responding message in passing, instead of sending an independent upd= ating CID message.

Well, that's obv= iously something you could do but it's not part of TLS, though of cours= e you could use the connection ID in TLS.
=C2=A0

In addition, like what Stephen mentioned, it is essential to avoid linkabil= ity between new CID and old CID. This is not covered in this draft.

New security considerations text welcome.


For 1.2, in this draft, there is no NewConnectionID and RequestConnectionID= message, how can the CID be updated. This is what I mean "worse"= .

Yes. As I said, I'm not really tr= ying to fix TLS 1.2, though I'm happy to have the extension used both p= laces.

-Ekr


Regards,
Yin Xinxing

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B410=E6=9C=8813=E6=97=A5 2= 3:41
=E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing; Eric Rescorla; tls@ietf.org
=E4=B8=BB=E9=A2=98: Re: [TLS] Connection ID Draft=

I would like to focus on one= of the points raised below:
> 3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We have a practical usecase in = IoT. The IOT device, like
> intelligent water meter, sends one message per day, and goes to sleep.=
> It wakes up in the second day and sends a message and then goes to
> sleep. If it always (or for a long time) use the same CID, there may > be a risk of tracing IOT device or the owner of this device.
> Therefore, it is important to recommend user to update CID once it
> finishes sending message. For the CID in DTLS1.2, this becomes worse.<= br>

The user is typically not doing anything.


Without this CID extension you would send a full exchange or use session re= sumption. This would allow someone in the middle to see the handshake.
In DTLS/TLS 1.2 this would reveal the client certificate.

With DTLS 1.3 and this extension you would hide the certificate and you cou= ld echange new CIDs and switch between them every day. The source IP addres= s will most likely still reveal the subscriber (if you consider some cooper= ation with the ISP).

So, you actually get pretty good privacy properties with DTLS 1.3 & CID= (unless some of the data center folks destroy it again with their fancy ex= tensions). With DTLS 1.2 there is only a performance benefit but the privac= y properties remain the same IMHO.

Ciao
Hannes


>
> =C2=A0
>
> Regards,
>
> Yin Xinxing
>
> =C2=A0
>
> *=E5=8F=91=E4=BB=B6=E4=BA=BA:*TLS [mailto:tls-bounces@ietf.org] *=E4=BB=A3=E8=A1=A8 *Eric Rescorla > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2017=E5=B9=B410=E6=9C=8813=E6= =97=A57:14
> *=E6=94=B6=E4=BB=B6=E4=BA=BA:*tls@ietf= .org
> *=E4=B8=BB=E9=A2=98:*[TLS] Connection ID Draft
>
> =C2=A0
>
> Hi folks,
>
> =C2=A0
>
> I have just posted a first cut at a connection ID draft.
>
> https://tools.ietf.org/html= /draft-rescorla-tls-dtls-connection-id-00
>
> =C2=A0
>
> Comments welcome.
>
> =C2=A0
>
> -Ekr
>
> =C2=A0
>
> =C2=A0
>
> =C2=A0
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f4030435b0103749a0055b78a71b-- From nobody Fri Oct 13 19:40:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9911321F5 for ; Fri, 13 Oct 2017 19:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwkgzIDRalxN for ; Fri, 13 Oct 2017 19:40:00 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 D8CFB132397 for ; Fri, 13 Oct 2017 19:39:59 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id j58so11767542qtj.0 for ; Fri, 13 Oct 2017 19:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qxhv+D62ID+URkpSAbD9qq7dcIVQjSfGK54BRgcagXk=; b=KSR2wFFEXXPd7pFKQtt2/i7bhGpRBWbGEkL7tQKga+FBICRxb4aGOnjrW5F6F9qDhi 3XJ6KwzMftpgBYNYk1UAb4eIMcqcF9AlnAQ17Ij86Ok3whqKuHCC9vcJiA5eKGPoDHlf r6Sv7uaUR5RKJbUlOeFX7Y7n7JYsrFNh3Dxxjw6XoUTwNJIudCVINR5cvjWnr6PB9NBS Yd0F0ueMzWUjQ9e8/kbeBYfSp4fV/gm/QXvJfi3dyT9gmju5Vos8QrBrLSFAq5BTbU0K mwA0lCyp9gegiB2HyDSDv6jZnJ1c4NYOEdbsRwzKmg6AbuiGiK8HZ3MVam99Gt9v0x4F KiBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qxhv+D62ID+URkpSAbD9qq7dcIVQjSfGK54BRgcagXk=; b=Sp9Vk7FuiYlve22lqnsU0sBq3jWDZLRmCQafXQyJUqfvqh2g8lpLNamvciC15OPLoh +n7p92rl9py6eSXa2zXmp2XYaNJh2fErrj5sX8vwVwNq62HbXX8GjIjuiTHfZG6z4iZ0 w2lhKuSyge5NF72Xb1W2CIo7r9dZ+89qMuC8TVBto4xcS2YCisxXPklCFVzKESCg1gbW 5zobdTj1Kk+yxC3x09ZemzWczMzx+1MeM6Y9+cxXCbahrcnPdEQChgs8FnVwdyTZj+03 gZzB4x9kBm7H/a0PfC5I54tlKBYWbTFMxW9hWGPgKyOCIZ3XlUCs2yxpjWPCqI0ZDPE8 kRpA== X-Gm-Message-State: AMCzsaWqKRgSYEdgoM6R2B/fPiBlSfOkfOI2jn8YV+V5ZrCwkl5GsUkY NECSITB+SFVhKVtX8QpfWtt7ECJ3Lwer/24hqVLV5Q== X-Google-Smtp-Source: AOwi7QDU20koQJ2QlFv0r/QH0HaptyLonyyOYyitmLDLx/s7/Wa/k1MTSF7nHuPZv6hiNBr3eXBXMNiyIK9raTdHCZM= X-Received: by 10.129.26.208 with SMTP id a199mr2096789ywa.280.1507948798989; Fri, 13 Oct 2017 19:39:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 13 Oct 2017 19:39:18 -0700 (PDT) In-Reply-To: References: <9800fbbc-f23f-139d-b5a9-ef6515123f73@gmx.net> From: Eric Rescorla Date: Fri, 13 Oct 2017 19:39:18 -0700 Message-ID: To: yinxinxing Cc: Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1142d0d480ee58055b78b03a" Archived-At: Subject: Re: [TLS] =?utf-8?b?562U5aSNOiAgQ29ubmVjdGlvbiBJRCBEcmFmdA==?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 02:40:02 -0000 --001a1142d0d480ee58055b78b03a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 13, 2017 at 7:36 PM, Eric Rescorla wrote: > > > On Fri, Oct 13, 2017 at 7:28 PM, yinxinxing wrote= : > >> Hi Hannes, >> >> "exchange new CIDs and switch between them every day" may not be a good >> choice for power constrained IOT devices. From the point of saving batte= ry, >> it is better to transfer the new CID to the other peer in the applicatio= n >> responding message in passing, instead of sending an independent updatin= g >> CID message. >> > > Well, that's obviously something you could do but it's not part of TLS, > though of course you could use the connection ID in TLS. > > >> >> In addition, like what Stephen mentioned, it is essential to avoid >> linkability between new CID and old CID. This is not covered in this dra= ft. >> > > New security considerations text welcome. > > > For 1.2, in this draft, there is no NewConnectionID and >> RequestConnectionID message, how can the CID be updated. This is what I >> mean "worse". >> > > Yes. As I said, I'm not really trying to fix TLS 1.2, though I'm happy to > have the extension used both places. > With that said, it's not like it's impossible; it's just work. But the WG policy has been to focus on TLS 1.3 and not on retrofitting TLS 1.3 improvements to 1.2. -Ekr > > -Ekr > > >> Regards, >> Yin Xinxing >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Hannes Tschofenig [mailto:hannes.tschofenig= @gmx.net] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B410=E6=9C=8813=E6=97= =A5 23:41 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing; Eric Rescorla; tls@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [TLS] Connection ID Draft >> >> I would like to focus on one of the points raised below: >> > 3. We have a practical usecase in IoT. The IOT device, like >> > intelligent water meter, sends one message per day, and goes to sleep. >> > It wakes up in the second day and sends a message and then goes to >> > sleep. If it always (or for a long time) use the same CID, there may >> > be a risk of tracing IOT device or the owner of this device. >> > Therefore, it is important to recommend user to update CID once it >> > finishes sending message. For the CID in DTLS1.2, this becomes worse. >> >> >> The user is typically not doing anything. >> >> >> Without this CID extension you would send a full exchange or use session >> resumption. This would allow someone in the middle to see the handshake. >> In DTLS/TLS 1.2 this would reveal the client certificate. >> >> With DTLS 1.3 and this extension you would hide the certificate and you >> could echange new CIDs and switch between them every day. The source IP >> address will most likely still reveal the subscriber (if you consider so= me >> cooperation with the ISP). >> >> So, you actually get pretty good privacy properties with DTLS 1.3 & CID >> (unless some of the data center folks destroy it again with their fancy >> extensions). With DTLS 1.2 there is only a performance benefit but the >> privacy properties remain the same IMHO. >> >> Ciao >> Hannes >> >> >> > >> > >> > >> > Regards, >> > >> > Yin Xinxing >> > >> > >> > >> > *=E5=8F=91=E4=BB=B6=E4=BA=BA:*TLS [mailto:tls-bounces@ietf.org] *=E4= =BB=A3=E8=A1=A8 *Eric Rescorla >> > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2017=E5=B9=B410=E6=9C=8813=E6= =97=A57:14 >> > *=E6=94=B6=E4=BB=B6=E4=BA=BA:*tls@ietf.org >> > *=E4=B8=BB=E9=A2=98:*[TLS] Connection ID Draft >> > >> > >> > >> > Hi folks, >> > >> > >> > >> > I have just posted a first cut at a connection ID draft. >> > >> > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 >> > >> > >> > >> > Comments welcome. >> > >> > >> > >> > -Ekr >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> > > --001a1142d0d480ee58055b78b03a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 13, 2017 at 7:36 PM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Fri, Oc= t 13, 2017 at 7:28 PM, yinxinxing <yinxinxing@huawei.com> wrote:
Hi Hannes,

"exchange new CIDs and switch between them every day" may not be = a good choice for power constrained IOT devices. From the point of saving b= attery, it is better to transfer the new CID to the other peer in the appli= cation responding message in passing, instead of sending an independent upd= ating CID message.

Well, that= 9;s obviously something you could do but it's not part of TLS, though o= f course you could use the connection ID in TLS.
=C2=A0

In addition, like what Stephen mentioned, it is essential to avoid linkabil= ity between new CID and old CID. This is not covered in this draft.

New security considerations text welcom= e.


For 1.2, in this draft, there is no NewConnectionID and RequestConnectionID= message, how can the CID be updated. This is what I mean "worse"= .

Yes. As I said, I'm not re= ally trying to fix TLS 1.2, though I'm happy to have the extension used= both places.

With = that said, it's not like it's impossible; it's just work. But t= he WG policy has been to focus on TLS 1.3 and not on retrofitting TLS 1.3 i= mprovements to 1.2.

-Ekr
=C2=A0

-Ekr


Regards,
Yin Xinxing

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B410=E6=9C=8813=E6=97=A5 2= 3:41
=E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing; Eric Rescorla; tls@ietf.org
=E4= =B8=BB=E9=A2=98: Re: [TLS] Connection ID Draft

I would like to focus on one of the points raised below: > 3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We have a practical usecase in = IoT. The IOT device, like
> intelligent water meter, sends one message per day, and goes to sleep.=
> It wakes up in the second day and sends a message and then goes to
> sleep. If it always (or for a long time) use the same CID, there may > be a risk of tracing IOT device or the owner of this device.
> Therefore, it is important to recommend user to update CID once it
> finishes sending message. For the CID in DTLS1.2, this becomes worse.<= br>

The user is typically not doing anything.


Without this CID extension you would send a full exchange or use session re= sumption. This would allow someone in the middle to see the handshake.
In DTLS/TLS 1.2 this would reveal the client certificate.

With DTLS 1.3 and this extension you would hide the certificate and you cou= ld echange new CIDs and switch between them every day. The source IP addres= s will most likely still reveal the subscriber (if you consider some cooper= ation with the ISP).

So, you actually get pretty good privacy properties with DTLS 1.3 & CID= (unless some of the data center folks destroy it again with their fancy ex= tensions). With DTLS 1.2 there is only a performance benefit but the privac= y properties remain the same IMHO.

Ciao
Hannes


>
> =C2=A0
>
> Regards,
>
> Yin Xinxing
>
> =C2=A0
>
> *=E5=8F=91=E4=BB=B6=E4=BA=BA:*TLS [mailto:tls-bounces@ietf.org] *=E4=BB=A3=E8=A1=A8= *Eric Rescorla
> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2017=E5=B9=B410=E6=9C=8813=E6= =97=A57:14
> *=E6=94=B6=E4=BB=B6=E4=BA=BA:*tls@ietf.org
> *=E4=B8=BB=E9=A2=98:*[TLS] Connection ID Draft
>
> =C2=A0
>
> Hi folks,
>
> =C2=A0
>
> I have just posted a first cut at a connection ID draft.
>
> https://tools.ietf.org/html= /draft-rescorla-tls-dtls-connection-id-00
>
> =C2=A0
>
> Comments welcome.
>
> =C2=A0
>
> -Ekr
>
> =C2=A0
>
> =C2=A0
>
> =C2=A0
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


--001a1142d0d480ee58055b78b03a-- From nobody Fri Oct 13 19:41:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E533E132397 for ; Fri, 13 Oct 2017 19:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV8w33dz5sEB for ; Fri, 13 Oct 2017 19:41:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8032D1321F5 for ; Fri, 13 Oct 2017 19:41:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQP51084; Sat, 14 Oct 2017 02:41:29 +0000 (GMT) Received: from DGGEMI403-HUB.china.huawei.com (10.3.17.136) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 14 Oct 2017 03:41:28 +0100 Received: from DGGEMI508-MBS.china.huawei.com ([169.254.3.228]) by dggemi403-hub.china.huawei.com ([10.3.17.136]) with mapi id 14.03.0301.000; Sat, 14 Oct 2017 10:41:21 +0800 From: yinxinxing To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AdND9UCTy0qV4eX+RfS1VDVqmNEmO///1aMA//6VX+A= Date: Sat, 14 Oct 2017 02:41:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022C7ABC6Fdggemi508mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.59E17959.00C6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.228, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3f2f08e943ce735b91974006c73b3226 Archived-At: Subject: [TLS] =?utf-8?b?562U5aSNOiAgQ29ubmVjdGlvbiBJRCBEcmFmdA==?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 02:41:35 -0000 --_000_DBDF9AE44733284D808F0E585E1919022C7ABC6Fdggemi508mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEVrci4NCg0KRm9yIOKAnEkgZXhwbGljaXRseSBkaWQgbm90IHdhbnQgdG8gZG8gdGhh dCwgYmVjYXVzZSB0aGVyZSBhcmUgYSBsb3Qgb2YgdmFsaWQgd2F5cyB0byBnZW5lcmF0ZSBDSUQu IFRoaXMgaXMgYWxzbyB3aGF0IHdlIGRpZCBpbiBRVUlDLuKAnSwgdGhlIGtleSBwb2ludCBvZiBk ZXNjcmliaW5nIHRoZSBnZW5lcmF0aW9uIG9mIENJRCBpcyB0byBhdm9pZCBsaW5rYWJpbGl0eSBi ZXR3ZWVuIG5ldyBDSUQgYW5kIG9sZCBvbmVzLCBhbHRob3VnaCB0aGVyZSBhcmUgbG90cyBvZiB2 YWxpZCB3YXlzLg0KDQpSZWdhcmRzLA0KWWluIFhpbnhpbmcNCg0K5Y+R5Lu25Lq6OiBFcmljIFJl c2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0MTDmnIgx M+aXpSAyMTowMA0K5pS25Lu25Lq6OiB5aW54aW54aW5nDQrmioTpgIE6IHRsc0BpZXRmLm9yZw0K 5Li76aKYOiBSZTogW1RMU10gQ29ubmVjdGlvbiBJRCBEcmFmdA0KDQoNCg0KT24gRnJpLCBPY3Qg MTMsIDIwMTcgYXQgMToxMSBBTSwgeWlueGlueGluZyA8eWlueGlueGluZ0BodWF3ZWkuY29tPG1h aWx0bzp5aW54aW54aW5nQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIEVrciwNCg0KVGhhbmtzIGZv ciB5b3VyIGVmZm9ydC4gVGhlIGRyYWZ0IGxvb2tzIGdvb2QuIEEgZmV3IGNvbW1lbnRzIGFyZSBs aXN0ZWQgYmVsb3cuDQoNCg0KMS4gICAgICAgQmFzZWQgb24gdGhlIGRyYWZ0LCBmb3IgZWl0aGVy IERUTFMxLjIgb3IgMS4zLCBzZXJ2ZXIgY2Fu4oCZdCBkaWZmZXJlbnRpYXRlIHdoZXRoZXIgdGhl IHBhY2tldCBmcm9tIGNsaWVudCBpcyBhIOKAnGNvbm5lY3Rpb24gSUTigJ0gcGFja2V0IG9yIGEg c3RhbmRhcmQgRFRMUyAxLjIvMS4zIHBhY2tldC4gKEkgc2F3IFRob21hcyBGb3NzYXRpIGFuZCBO aWtvcyBhbHNvIGludHJvZHVjZWQgdGhpcyBwcm9ibGVtKQ0KDQpNYXliZSB3ZSBjYW4gYWRkIGEg bmV3IOKAnENvbnRlbnRUeXBl4oCdIGluIHRoZSBEVExTIHJlY29yZCBmb3JtYXQgdG8gaGVscCBz ZXJ2ZXIgaWRlbnRpZnkgdGhlIOKAnGNvbm5lY3Rpb24gSUTigJ0gcGFja2V0LiBJbiBhZGRpdGlv biwgeW91IHNlZSB0aGUgbGVuZ3RoIG9mIHRoZSByZWNvcmQgcGF5bG9hZCBpcyBsaW1pdGVkIGJ5 IDJeMTQtMSwgdGhpcyBtZWFucyB0aGUgZmlyc3QgdHdvIGJpdHMgb2Yg4oCcbGVuZ3Ro4oCdIGlz IHplcm8uIFdlIGNvdWxkIHV0aWxpemUgdGhpcyBmZWF0dXJlIGFuZCBzZXQgdGhlIGZpcnN0IHR3 byBiaXRzIG9yIG1vcmUgYml0cyBvZiBDSUQgYmVpbmcgb25lLCBlLmcuLCAxMTEx4oCmLihidXQg dGhlIENJRCBtdXN0IGJlIHB1dCBiZXR3ZWVuIHNlcXVlbmNlIG51bWJlciBhbmQgbGVuZ3RoKS4g V2hlbiBzZXJ2ZXIgZmluZHMgMTExMSBhZnRlciBzZXF1ZW5jZSBudW1iZXIsIGl0IGtub3dzIHRo aXMgaXMgYSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldC4gSG93ZXZlciwgSSBkb27igJl0IGtu b3cgd2hldGhlciBpdCBpcyBwcm9wZXIgdG8gdXNlIHN1Y2ggbWFnaWMgbnVtYmVyLiBJbiBteSB2 aWV3LCBhZGRpbmcgbmV3IGNvbnRlbnR0eXBlIG1heSBiZSBhIGNob2ljZS4NCg0KQXMgSSBzYWlk IHRvIE5pa29zLCBmb3IgRFRMUyAxLjIsIHlvdSBjYW4gdXNlIGEgc3BlY2lhbGx5LWNvbnN0cnVj dGVkIENJRCB0aGF0IHdvdWxkIG5vdCBiZSBhIHZhbGlkIGxlbmd0aCBmaWVsZC4gVGhpcyBjYW4g YWN0dWFsbHkganVzdCBoYXZlIHRoZSBsZWFkaW5nIGJpdCBzZXQuIEFzIHdlJ3JlIHJldmlzaW5n IHRoZSBEVExTIDEuMyByZWNvcmQgZm9ybWF0LCB3ZSB3b3VsZCBuZWVkIHRvIGRvIHNvbWV0aGlu ZyBkaWZmZXJlbnQgZm9yIHRoYXQuDQoNCg0KMi4gICAgICAgIEZvciBEVExTIDEuMiwgdGhlcmUg aXMgbm8gTmV3Q29ubmVjdGlvbklEIGFuZCBSZXF1ZXN0Q29ubmVjdGlvbklEIG1lc3NhZ2UuIERU TFMgMS4yIHNlcnZlciBhbmQgY2xpZW50IGFsc28gaGFzIHRoZSByZXF1aXJlbWVudCB0byByZXF1 ZXN0IGZvciBhIG5ldyBDSUQsIGFuZCBhdCBwcmVzZW50LCBtYW55IHByb2R1Y3RzIHN0aWxsIHVz ZSBEVExTMS4yIGFuZCBJIGJlbGlldmUgaXQgd2lsbCBjb250aW51ZSB0byBiZSB1c2VkIGZvciBh IGxvbmcgdGltZSBldmVuIGlmIFRMUy9EVExTMS4zIGlzIHB1Ymxpc2hlZC4gTXkgcG9pbnQgaXMg dGhhdCB3ZSBuZWVkIGEgY29ycmVzcG9uZGluZyBtZXRob2QgZm9yIHVwZGF0aW5nIENJRCBmb3Ig RFRMUzEuMiB0b28uDQpJbiBnZW5lcmFsLCB0aGUgV0cgaXMgd29ya2luZyBvbiBUTFMgMS4zLCBu b3QgVExTIDEuMiwgc28gSSdtIG5vdCByZWFsbHkgdGhhdCBleGNpdGVkIGFib3V0IHB1dHRpbmcg YSBsb3Qgb2YgZWZmb3J0IGludG8gZW5oYW5jaW5nIFRMUyAxLjIuIFRoZSBiYXNpYyBleHRlbnNp b24gd29ya3MgZmluZSBmb3IgdGhlbSwgYnV0IGlmIHRoZXkgd2FudCB0byBjaGFuZ2UgQ0lEcywg dGhlbiB0aGV5IHNob3VsZCBhZG9wdCBEVExTIDEuMy4NCg0KDQpJIGRvbuKAmXQgcXVpdGUgdW5k ZXJzdGFuZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlcw0KDQrigJxJbiBEVExTIDEuMiwgY29ubmVj dGlvbiBpZHMgYXJlIGV4Y2hhbmdlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZQ0KDQogICBEVExT IHNlc3Npb24gb25seS4gIFRoZXJlIGlzIG5vIGRlZGljYXRlZCAiY29ubmVjdGlvbiBpZCB1cGRh dGUiDQoNCiAgIG1lc3NhZ2UgdGhhdCBhbGxvd3MgbmV3IGNvbm5lY3Rpb24gaWRzIHRvIGJlIGVz dGFibGlzaGVkIG1pZC1zZXNzaW9uLA0KDQogICBiZWNhdXNlIERUTFMgMS4yIGluIGdlbmVyYWwg ZG9lcyBub3QgYWxsb3cgcG9zdC1oYW5kc2hha2UgbWVzc2FnZXMNCg0KICAgdGhhdCBkbyBub3Qg dGhlbXNlbHZlcyBiZWdpbiBvdGhlciBoYW5kc2hha2VzLuKAnQ0KDQpUaGUgb25seSBwb3N0LWhh bmRzaGFrZSBtZXNzYWdlcyBhbGxvd2VkIGluIERUTFMgMS4yIGFyZSBDbGllbnRIZWxsbyBhbmQg SGVsbG9SZXF1ZXN0Lg0KDQoNCkJlc2lkZXMsIGZvciBDSUQgaW4gRFRMUzEuMywgSSB0aGluayB0 aGUgY29ycmVzcG9uZGluZyByZXNwb25kaW5nIG1lc3NhZ2VzIG9mICBOZXdDb25uZWN0aW9uSUQg YW5kIFJlcXVlc3RDb25uZWN0aW9uSUQgYXJlIGFsc28gbmVlZGVkIHRvIGVuc3VyZSB0aGF0IHRo ZSBwZWVyIGhhcyByZWNlaXZlZCBDSUQuDQoNCk5vLCB5b3UgdXNlIHRoZSBBQ0sgZm9yIHRoZXNl IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtZHRsczEzLTAxI3Nl Y3Rpb24tNykuIFRoaXMgaXMgb25lIHJlYXNvbiB3aHkgdGhlcmUgaXMgbm90IGEgc3RyYWlnaHRm b3J3YXJkIHBvcnQgdG8gRFRMUyAxLjIgZm9yIHRoZXNlIG1lc3NhZ2VzLg0KDQoNCjQuICAgICAg IFRoZSBnZW5lcmF0aW9uIG9mIENJRCBzaG91bGQgYmUgbW9yZSBjb25jcmV0ZS4gRm9yIGV4YW1w bGUsIHVzaW5nIHJhbmRvbSBudW1iZXIgb3IgYSBjb3VudGVyPw0KSSBleHBsaWNpdGx5IGRpZCBu b3Qgd2FudCB0byBkbyB0aGF0LCBiZWNhdXNlIHRoZXJlIGFyZSBhIGxvdCBvZiB2YWxpZCB3YXlz IHRvIGdlbmVyYXRlIENJRC4gVGhpcyBpcyBhbHNvIHdoYXQgd2UgZGlkIGluIFFVSUMuDQoNCi1F a3INCg0KDQoNClJlZ2FyZHMsDQpZaW4gWGlueGluZw0KDQrlj5Hku7bkuro6IFRMUyBbbWFpbHRv OnRscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZz5dIOS7o+ih qCBFcmljIFJlc2NvcmxhDQrlj5HpgIHml7bpl7Q6IDIwMTflubQxMOaciDEz5pelIDc6MTQNCuaU tuS7tuS6ujogdGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+DQrkuLvpopg6IFtUTFNd IENvbm5lY3Rpb24gSUQgRHJhZnQNCg0KSGkgZm9sa3MsDQoNCkkgaGF2ZSBqdXN0IHBvc3RlZCBh IGZpcnN0IGN1dCBhdCBhIGNvbm5lY3Rpb24gSUQgZHJhZnQuDQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC0wMA0KDQpDb21t ZW50cyB3ZWxjb21lLg0KDQotRWtyDQoNCg0KDQoNCg== --_000_DBDF9AE44733284D808F0E585E1919022C7ABC6Fdggemi508mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5nbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0 M21zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBh cmFncmFwaCwgZGl2LmdtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaA0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdy YXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHlsZS1u YW1lOmdtYWlsLTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkw LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBFa3IuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciDigJw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPkkgZXhwbGljaXRseSBkaWQgbm90IHdhbnQgdG8gZG8gdGhhdCwgYmVjYXVzZSB0 aGVyZSBhcmUgYSBsb3Qgb2YgdmFsaWQgd2F5cyB0byBnZW5lcmF0ZSBDSUQuIFRoaXMgaXMgYWxz byB3aGF0IHdlDQogZGlkIGluIFFVSUMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdLCB0aGUga2V5IHBvaW50IG9mIGRlc2Ny aWJpbmcgdGhlIGdlbmVyYXRpb24gb2YgQ0lEIGlzIHRvIGF2b2lkIGxpbmthYmlsaXR5IGJldHdl ZW4gbmV3IENJRCBhbmQgb2xkIG9uZXMsIGFsdGhvdWdoIHRoZXJlIGFyZSBsb3RzIG9mIHZhbGlk IHdheXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZaW4gWGlueGluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRXJpYyBSZXNj b3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiAyMDE3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lubQ8c3Bh biBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjEzPC9zcGFuPuaX pTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAyMTowMDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB5aW54aW54aW5n PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IHRsc0BpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW1RMU10gQ29u bmVjdGlvbiBJRCBEcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gRnJpLCBPY3QgMTMsIDIwMTcgYXQg MToxMSBBTSwgeWlueGlueGluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlpbnhpbnhpbmdAaHVhd2Vp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlpbnhpbnhpbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBFa3IsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhhbmtzIGZvciB5b3VyIGVmZm9ydC4gVGhlIGRyYWZ0IGxvb2tzIGdvb2QuIEEgZmV3IGNv bW1lbnRzIGFyZSBsaXN0ZWQgYmVsb3cuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS02 NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu MHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+MS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QmFzZWQgb24gdGhlIGRyYWZ0LCBmb3IgZWl0aGVyIERUTFMxLjIgb3IgMS4zLCBzZXJ2ZXIg Y2Fu4oCZdCBkaWZmZXJlbnRpYXRlIHdoZXRoZXIgdGhlIHBhY2tldCBmcm9tIGNsaWVudCBpcyBh IOKAnGNvbm5lY3Rpb24gSUTigJ0gcGFja2V0IG9yIGEgc3RhbmRhcmQgRFRMUyAxLjIvMS4zDQog cGFja2V0LiAoSSBzYXcgVGhvbWFzIEZvc3NhdGkgYW5kIE5pa29zIGFsc28gaW50cm9kdWNlZCB0 aGlzIHByb2JsZW0pPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iZ21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWF5YmUgd2UgY2FuIGFkZCBhIG5ldyDigJxD b250ZW50VHlwZeKAnSBpbiB0aGUgRFRMUyByZWNvcmQgZm9ybWF0IHRvIGhlbHAgc2VydmVyIGlk ZW50aWZ5IHRoZSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldC4gSW4gYWRkaXRpb24sIHlvdSBz ZWUgdGhlIGxlbmd0aCBvZiB0aGUgcmVjb3JkIHBheWxvYWQNCiBpcyBsaW1pdGVkIGJ5IDJeMTQt MSwgdGhpcyBtZWFucyB0aGUgZmlyc3QgdHdvIGJpdHMgb2Yg4oCcbGVuZ3Ro4oCdIGlzIHplcm8u IFdlIGNvdWxkIHV0aWxpemUgdGhpcyBmZWF0dXJlIGFuZCBzZXQgdGhlIGZpcnN0IHR3byBiaXRz IG9yIG1vcmUgYml0cyBvZiBDSUQgYmVpbmcgb25lLCBlLmcuLCAxMTEx4oCmLihidXQgdGhlIENJ RCBtdXN0IGJlIHB1dCBiZXR3ZWVuIHNlcXVlbmNlIG51bWJlciBhbmQgbGVuZ3RoKS4gV2hlbiBz ZXJ2ZXIgZmluZHMgMTExMQ0KIGFmdGVyIHNlcXVlbmNlIG51bWJlciwgaXQga25vd3MgdGhpcyBp cyBhIOKAnGNvbm5lY3Rpb24gSUTigJ0gcGFja2V0LiBIb3dldmVyLCBJIGRvbuKAmXQga25vdyB3 aGV0aGVyIGl0IGlzIHByb3BlciB0byB1c2Ugc3VjaCBtYWdpYyBudW1iZXIuIEluIG15IHZpZXcs IGFkZGluZyBuZXcgY29udGVudHR5cGUgbWF5IGJlIGEgY2hvaWNlLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIEkgc2FpZCB0byBOaWtvcywgZm9yIERUTFMgMS4y LCB5b3UgY2FuIHVzZSBhIHNwZWNpYWxseS1jb25zdHJ1Y3RlZCBDSUQgdGhhdCB3b3VsZCBub3Qg YmUgYSB2YWxpZCBsZW5ndGggZmllbGQuIFRoaXMgY2FuIGFjdHVhbGx5IGp1c3QgaGF2ZSB0aGUg bGVhZGluZyBiaXQgc2V0LiBBcyB3ZSdyZSByZXZpc2luZyB0aGUgRFRMUyAxLjMgcmVjb3JkIGZv cm1hdCwgd2Ugd291bGQNCiBuZWVkIHRvIGRvIHNvbWV0aGluZyBkaWZmZXJlbnQgZm9yIHRoYXQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLW0tNjUxMzYwNTMz MzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw O0ZvciBEVExTIDEuMiwgdGhlcmUgaXMgbm8gTmV3Q29ubmVjdGlvbklEIGFuZCBSZXF1ZXN0Q29u bmVjdGlvbklEIG1lc3NhZ2UuIERUTFMgMS4yIHNlcnZlciBhbmQgY2xpZW50IGFsc28gaGFzIHRo ZSByZXF1aXJlbWVudCB0byByZXF1ZXN0IGZvciBhIG5ldyBDSUQsIGFuZA0KIGF0IHByZXNlbnQs IG1hbnkgcHJvZHVjdHMgc3RpbGwgdXNlIERUTFMxLjIgYW5kIEkgYmVsaWV2ZSBpdCB3aWxsIGNv bnRpbnVlIHRvIGJlIHVzZWQgZm9yIGEgbG9uZyB0aW1lIGV2ZW4gaWYgVExTL0RUTFMxLjMgaXMg cHVibGlzaGVkLiBNeSBwb2ludCBpcyB0aGF0IHdlIG5lZWQgYSBjb3JyZXNwb25kaW5nIG1ldGhv ZCBmb3IgdXBkYXRpbmcgQ0lEIGZvciBEVExTMS4yIHRvby48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGdlbmVy YWwsIHRoZSBXRyBpcyB3b3JraW5nIG9uIFRMUyAxLjMsIG5vdCBUTFMgMS4yLCBzbyBJJ20gbm90 IHJlYWxseSB0aGF0IGV4Y2l0ZWQgYWJvdXQgcHV0dGluZyBhIGxvdCBvZiBlZmZvcnQgaW50byBl bmhhbmNpbmcgVExTIDEuMi4gVGhlIGJhc2ljIGV4dGVuc2lvbiB3b3JrcyBmaW5lIGZvciB0aGVt LCBidXQgaWYgdGhleSB3YW50IHRvIGNoYW5nZSBDSURzLCB0aGVuDQogdGhleSBzaG91bGQgYWRv cHQgRFRMUyAxLjMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9ImdtYWls LW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgZG9u4oCZdCBxdWl0ZSB1bmRlcnN0YW5kIHRoZSBmb2xsb3dpbmcgc2VudGVu Y2VzDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxJbiBEVExTIDEuMiwgY29ubmVjdGlvbiBpZHMgYXJl IGV4Y2hhbmdlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNjUxMzYwNTMzMzEz ODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyBEVExTIHNlc3Npb24gb25seS4mbmJzcDsgVGhlcmUgaXMgbm8gZGVkaWNhdGVkICZx dW90O2Nvbm5lY3Rpb24gaWQgdXBkYXRlJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS02NTEzNjA1MzMzMTM4MjUw NDNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IG1lc3NhZ2UgdGhhdCBhbGxvd3MgbmV3IGNvbm5lY3Rpb24gaWRzIHRvIGJlIGVzdGFibGlz aGVkIG1pZC1zZXNzaW9uLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBiZWNhdXNlIERU TFMgMS4yIGluIGdlbmVyYWwgZG9lcyBub3QgYWxsb3cgcG9zdC1oYW5kc2hha2UgbWVzc2FnZXM8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdGhhdCBkbyBub3QgdGhlbXNlbHZlcyBiZWdp biBvdGhlciBoYW5kc2hha2VzLuKAnTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlRoZSBvbmx5IHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzIGFsbG93ZWQgaW4gRFRMUyAx LjIgYXJlIENsaWVudEhlbGxvIGFuZCBIZWxsb1JlcXVlc3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc2lkZXMsIGZvciBDSUQgaW4gRFRM UzEuMywgSSB0aGluayB0aGUgY29ycmVzcG9uZGluZyByZXNwb25kaW5nIG1lc3NhZ2VzIG9mICZu YnNwO05ld0Nvbm5lY3Rpb25JRCBhbmQgUmVxdWVzdENvbm5lY3Rpb25JRCBhcmUgYWxzbyBuZWVk ZWQgdG8gZW5zdXJlIHRoYXQgdGhlIHBlZXIgaGFzIHJlY2VpdmVkDQogQ0lELjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vLCB5b3UgdXNlIHRoZSBBQ0sgZm9yIHRo ZXNlICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMt ZHRsczEzLTAxI3NlY3Rpb24tNyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdGxzLWR0bHMxMy0wMSNzZWN0aW9uLTc8L2E+KS4gVGhpcyBpcyBvbmUgcmVhc29uIHdoeSB0 aGVyZSBpcyBub3QgYSBzdHJhaWdodGZvcndhcmQNCiBwb3J0IHRvIERUTFMgMS4yIGZvciB0aGVz ZSBtZXNzYWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i Z21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+NC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIGdlbmVyYXRpb24gb2YgQ0lEIHNob3VsZCBiZSBtb3JlIGNvbmNyZXRl LiBGb3IgZXhhbXBsZSwgdXNpbmcgcmFuZG9tIG51bWJlciBvciBhIGNvdW50ZXI/PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5JIGV4cGxpY2l0bHkgZGlkIG5vdCB3YW50IHRvIGRvIHRoYXQsIGJlY2F1c2UgdGhlcmUg YXJlIGEgbG90IG9mIHZhbGlkIHdheXMgdG8gZ2VuZXJhdGUgQ0lELiBUaGlzIGlzIGFsc28gd2hh dCB3ZSBkaWQgaW4gUVVJQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPi1Fa3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJk cyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5ZaW4gWGlueGluZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+5Y+R5Lu25Lq6PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIFRMUyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0 bHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRscy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+5Luj6KGo IDwvc3Bhbj4NCjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkVyaWMgUmVzY29ybGE8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gMjAxNzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+5bm0PHNwYW4gbGFuZz0iRU4t VVMiPjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xMzwvc3Bhbj7ml6U8c3BhbiBsYW5n PSJFTi1VUyI+DQogNzoxNDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YSBocmVmPSJtYWlsdG86dGxzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0bHNAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxi PuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ IFtUTFNdIENvbm5lY3Rpb24gSUQgRHJhZnQ8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgZm9sa3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSBqdXN0IHBvc3RlZCBhIGZpcnN0 IGN1dCBhdCBhIGNvbm5lY3Rpb24gSUQgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1kdGxz LWNvbm5lY3Rpb24taWQtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC0wMDwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Db21tZW50cyB3 ZWxjb21lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPi1Fa3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_DBDF9AE44733284D808F0E585E1919022C7ABC6Fdggemi508mbschi_-- From nobody Fri Oct 13 19:47:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E3A132939 for ; Fri, 13 Oct 2017 19:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XC0t4LUH00Z for ; Fri, 13 Oct 2017 19:47:26 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD121321F5 for ; Fri, 13 Oct 2017 19:47:26 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id o52so22855647qtc.9 for ; Fri, 13 Oct 2017 19:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Czf8rVcM0Mmxwp0XmNPLSYMpHyQPQT6MuSCwISjVfA=; b=DXKJcIdB1v/nuCj0a/7u7rZLTLx5mrKkYG/2TTrKHzQVS2yCAoiJMDHdBvEtiUktgq CSToLFI04Af9BjyJjSt1/dDzwMFZ8lLiJE89IIFNrOsuBdb2hp8c0MLNBa2HAF6NOPto QGxBcNbRJhXSyeX+YC0lEKuVW1gPxF0SAGj2/gMQeArQXLoUDnAmqo1TIOkI4pK84zaY E3F4o8JRxSgrxc4YYQvS+9ruxze4w6zgxRPY+9SE1JADvBbCCTiQvJZZEBzupWtgI8R4 7p6pjtW7aGbG8T6yKR/ONfPSfCoY7zH0pzMClMDTUxGztI+kNFRhr91YgZ5Zbo3IXQzq ZbvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+Czf8rVcM0Mmxwp0XmNPLSYMpHyQPQT6MuSCwISjVfA=; b=Z1U/6jmMAaWKBA/pFJVDkcfeOtDYB7Dnz68lamT8PtAC67xaivlkMC3Xi3mEih9n4k v6UfgB84xMJCI0B5E/8MSIgY2PbdrnbvltDphoQk+bHnGZstRHA5VERoAutnZKVePXfZ ftO2xySsclcp4sRKn7mnkADvucwdW0Ji9y9cSUYsEHZgPGWvVnboHiAXL5I7k8yOqJhp ML39R0GXWskZIij4JwFDDsOhjD//Ad2tzxXZJyZNb9FEpI5T6dx6olM7yeJK0FCUmAoP D/oFj5zeur/9r41pYU8tgvyU9vEC1W7y/z+13R0qvxJWBRl/uAotX+7gtDWCaitqiIvD lalA== X-Gm-Message-State: AMCzsaX5M5JlbCV+yPfIF1US4H5RUM/LsGS/J3noNxfNksTM78OwdaO5 QfOJ1INT3fil5cAUAg+j96uizbiYnyeDpH6TSmx6UzpT X-Google-Smtp-Source: AOwi7QA+Veds5/4BYXYqEDZcLkPusTz+W7kzQIKmWkufIdKD6TgNsttE79BmW/i66KO/2JQAa1Ik2DXvTJNIKE592EM= X-Received: by 10.37.87.198 with SMTP id l189mr2182497ybb.71.1507949245517; Fri, 13 Oct 2017 19:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 13 Oct 2017 19:46:44 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 13 Oct 2017 19:46:44 -0700 Message-ID: To: yinxinxing Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113ffca41e68e3055b78cb79" Archived-At: Subject: Re: [TLS] =?utf-8?b?562U5aSNOiAgQ29ubmVjdGlvbiBJRCBEcmFmdA==?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 02:47:29 -0000 --001a113ffca41e68e3055b78cb79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 13, 2017 at 7:41 PM, yinxinxing wrote: > Thanks Ekr. > > > > For =E2=80=9CI explicitly did not want to do that, because there are a lo= t of > valid ways to generate CID. This is also what we did in QUIC.=E2=80=9D, t= he key > point of describing the generation of CID is to avoid linkability between > new CID and old ones, although there are lots of valid ways. > I don't really get what you're proposing here. As I said, there are a lot of ways to generate connection IDs and it's not helpful to prescribe one. We might be able to require that it not be possible to distinguish whether two conn IDs are from the same connection with probability > \epsilon, but even that is notrivial if (for instance) they have a generation ID. So I'd prefer to describe the issue in the security considerations and leave the details up to implementations. -Ekr > > Regards, > > Yin Xinxing > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Eric Rescorla [mailto:ekr@rtfm.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B410=E6=9C=8813=E6=97= =A5 21:00 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* yinxinxing > *=E6=8A=84=E9=80=81:* tls@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: [TLS] Connection ID Draft > > > > > > > > On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing wrote= : > > Hi Ekr, > > > > Thanks for your effort. The draft looks good. A few comments are listed > below. > > > > 1. Based on the draft, for either DTLS1.2 or 1.3, server can=E2=80= =99t > differentiate whether the packet from client is a =E2=80=9Cconnection ID= =E2=80=9D packet or > a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also > introduced this problem) > > Maybe we can add a new =E2=80=9CContentType=E2=80=9D in the DTLS record f= ormat to help > server identify the =E2=80=9Cconnection ID=E2=80=9D packet. In addition, = you see the length > of the record payload is limited by 2^14-1, this means the first two bits > of =E2=80=9Clength=E2=80=9D is zero. We could utilize this feature and se= t the first two > bits or more bits of CID being one, e.g., 1111=E2=80=A6.(but the CID must= be put > between sequence number and length). When server finds 1111 after sequenc= e > number, it knows this is a =E2=80=9Cconnection ID=E2=80=9D packet. Howeve= r, I don=E2=80=99t know > whether it is proper to use such magic number. In my view, adding new > contenttype may be a choice. > > > > As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID > that would not be a valid length field. This can actually just have the > leading bit set. As we're revising the DTLS 1.3 record format, we would > need to do something different for that. > > > > 2. For DTLS 1.2, there is no NewConnectionID and > RequestConnectionID message. DTLS 1.2 server and client also has the > requirement to request for a new CID, and at present, many products still > use DTLS1.2 and I believe it will continue to be used for a long time eve= n > if TLS/DTLS1.3 is published. My point is that we need a corresponding > method for updating CID for DTLS1.2 too. > > In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really > that excited about putting a lot of effort into enhancing TLS 1.2. The > basic extension works fine for them, but if they want to change CIDs, the= n > they should adopt DTLS 1.3. > > > > I don=E2=80=99t quite understand the following sentences > > =E2=80=9CIn DTLS 1.2, connection ids are exchanged at the beginning of th= e > > DTLS session only. There is no dedicated "connection id update" > > message that allows new connection ids to be established mid-session, > > because DTLS 1.2 in general does not allow post-handshake messages > > that do not themselves begin other handshakes.=E2=80=9D > > > > The only post-handshake messages allowed in DTLS 1.2 are ClientHello and > HelloRequest. > > > > Besides, for CID in DTLS1.3, I think the corresponding responding message= s > of NewConnectionID and RequestConnectionID are also needed to ensure tha= t > the peer has received CID. > > > > No, you use the ACK for these (https://tools.ietf.org/html/ > draft-ietf-tls-dtls13-01#section-7). This is one reason why there is not > a straightforward port to DTLS 1.2 for these messages. > > > > 4. The generation of CID should be more concrete. For example, > using random number or a counter? > > I explicitly did not want to do that, because there are a lot of valid > ways to generate CID. This is also what we did in QUIC. > > > > -Ekr > > > > > > > > Regards, > > Yin Xinxing > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* TLS [mailto:tls-bounces@ietf.org] *=E4=BB= =A3=E8=A1=A8 *Eric Rescorla > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B410=E6=9C=8813=E6=97= =A5 7:14 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* tls@ietf.org > *=E4=B8=BB=E9=A2=98:* [TLS] Connection ID Draft > > > > Hi folks, > > > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > > Comments welcome. > > > > -Ekr > > > > > > > > > --001a113ffca41e68e3055b78cb79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 13, 2017 at 7:41 PM, yinxinxing <yinxinxing@huawei.com= > wrote:

Thanks Ekr= .

=C2= =A0

For =E2=80= =9CI explicitly did not want to do that, becaus= e there are a lot of valid ways to generate CID. This is also what we did in QUIC.=E2=80=9D, th= e key point of describing the generation of CID is to avoid linkability bet= ween new CID and old ones, although there are lots of valid ways.


I don't really get what y= ou're proposing here. As I said, there are a lot of ways to generate co= nnection IDs and it's not helpful to prescribe one. We might be able to= require that it not be possible to distinguish whether two conn IDs are fr= om the same connection with probability > \epsilon, but even that is not= rivial if (for instance) they have a generation ID. So I'd prefer to de= scribe the issue in the security considerations and leave the details up to= implementations.

-Ekr

=

=C2= =A0

Regards,

Yin Xinxin= g

=C2= =A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2017=E5=B9=B4= 10=E6=9C=8813=E6=97= =A5 21:00
=E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing
=E6=8A=84=E9=80=81: tls@ietf.org<= br> =E4=B8=BB=E9=A2=98:<= /b> Re: [TLS] Connection ID Draft=

=C2=A0

=C2=A0

=C2=A0

On Fri, Oct 13, 2017 at 1:11 AM= , yinxinxing <yinxinxing@huawei.com> wrote:

Hi Ekr,

=C2=A0

Thanks for= your effort. The draft looks good. A few comments are listed below.=

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Based on the draft, for ei= ther DTLS1.2 or 1.3, server can=E2=80=99t differentiate whether the packet = from client is a =E2=80=9Cconnection ID=E2=80=9D packet or a standard DTLS = 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also introduced this problem)

Maybe we can add a new =E2=80=9CC= ontentType=E2=80=9D in the DTLS record format to help server identify the = =E2=80=9Cconnection ID=E2=80=9D packet. In addition, you see the length of = the record payload is limited by 2^14-1, this means the first two bits of =E2=80=9Clength=E2= =80=9D is zero. We could utilize this feature and set the first two bits or= more bits of CID being one, e.g., 1111=E2=80=A6.(but the CID must be put b= etween sequence number and length). When server finds 1111 after sequence number, it knows this is a =E2=80=9Cconnection ID=E2=80=9D = packet. However, I don=E2=80=99t know whether it is proper to use such magi= c number. In my view, adding new contenttype may be a choice.

=C2=A0

As I said to Nikos, for DTLS 1.= 2, you can use a specially-constructed CID that would not be a valid length= field. This can actually just have the leading bit set. As we're revis= ing the DTLS 1.3 record format, we would need to do something different for that.

=C2=A0

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0For DTLS 1.2, there = is no NewConnectionID and RequestConnectionID message. DTLS 1.2 server and = client also has the requirement to request for a new CID, and at present, many products still use DTLS1.2 and I believe it will continue= to be used for a long time even if TLS/DTLS1.3 is published. My point is t= hat we need a corresponding method for updating CID for DTLS1.2 too.=

In general, the WG is working o= n TLS 1.3, not TLS 1.2, so I'm not really that excited about putting a = lot of effort into enhancing TLS 1.2. The basic extension works fine for th= em, but if they want to change CIDs, then they should adopt DTLS 1.3.

=C2=A0

I don=E2=80=99t quite understand = the following sentences

=E2=80=9CIn DTLS 1.2, connection = ids are exchanged at the beginning of the

=C2=A0=C2=A0 DTLS session only.= =C2=A0 There is no dedicated "connection id update"

=C2=A0=C2=A0 message that allows = new connection ids to be established mid-session,

=C2=A0=C2=A0 because DTLS 1.2 in = general does not allow post-handshake messages<= u>

=C2=A0=C2=A0 that do not themselv= es begin other handshakes.=E2=80=9D

=C2=A0

The only post-handshake message= s allowed in DTLS 1.2 are ClientHello and HelloRequest.

=C2=A0

Besides, for CID in DTLS1.3, I th= ink the corresponding responding messages of =C2=A0NewConnectionID and Requ= estConnectionID are also needed to ensure that the peer has received CID.

=C2=A0

No, you use the ACK for these (= https://tools.ietf.org/html/draft-ietf-tls-dtls13-01= #section-7). This is one reason why there is not a straightforward port to DTLS 1.2 for these messages.

=C2=A0

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The generation of CID shou= ld be more concrete. For example, using random number or a counter?<= span lang=3D"EN-US">

I explicitly did not want to do= that, because there are a lot of valid ways to generate CID. This is also = what we did in QUIC.

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

Regards,

Yin Xinxin= g

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: TLS [mailto:tls-= bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Eric Rescorla
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2017=E5=B9=B4= 10=E6=9C=8813=E6=97= =A5 7:14
=E6=94=B6=E4=BB=B6=E4=BA=BA: tls@ietf.org
=E4=B8=BB=E9=A2=98: [TLS] Connection ID Draft=

=C2=A0

Hi folks,<= /p>

=C2=A0

I have just posted a first cut = at a connection ID draft.

=C2=A0

Comments welcome.=

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--001a113ffca41e68e3055b78cb79-- From nobody Fri Oct 13 20:10:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B9D13305F for ; Fri, 13 Oct 2017 20:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pm1y7pmV1vq for ; Fri, 13 Oct 2017 20:10:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043B4132944 for ; Fri, 13 Oct 2017 20:10:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXR73416; Sat, 14 Oct 2017 03:10:03 +0000 (GMT) Received: from DGGEMI405-HUB.china.huawei.com (10.3.17.143) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 14 Oct 2017 04:10:38 +0100 Received: from DGGEMI508-MBS.china.huawei.com ([169.254.3.228]) by dggemi405-hub.china.huawei.com ([10.3.17.143]) with mapi id 14.03.0301.000; Sat, 14 Oct 2017 11:09:58 +0800 From: yinxinxing To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0?= Thread-Index: AdND9UCTy0qV4eX+RfS1VDVqmNEmO///1aMA//6VX+CAAlG3AP//eP5w Date: Sat, 14 Oct 2017 03:09:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022C7ABCA1dggemi508mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.59E1800C.0011, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.228, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0060ff0ae5330b9c7c627ad2c530435e Archived-At: Subject: [TLS] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBDb25uZWN0aW9uIElEIERyYWZ0?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 03:10:09 -0000 --_000_DBDF9AE44733284D808F0E585E1919022C7ABCA1dggemi508mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KEkgbWVhbiB0aGF0IHdlIGdpdmUgc29tZSB3YXJuaW5nIGFuZCBzdWdnZXN0aW9uIG9uIHRoZSBs aW5rYWJpbGl0eSwgYWx0aG91Z2ggdGhlcmUgYXJlIGxvdHMgb2YgdmFsaWQgd2F5cy4pDQoNCkkg bWlzcyByZWFkaW5nIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHBhcnQsIG5vdywgIEkgaGF2 ZSBzYXcgdGhlIHdhcm5pbmcgb2YgbGlua2FiaWxpdHkuIE5vIHByb2JsZW0gbm93Lg0KDQpZaW4g WGlueGluZw0KDQrlj5Hku7bkuro6IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21d DQrlj5HpgIHml7bpl7Q6IDIwMTflubQxMOaciDE05pelIDEwOjQ3DQrmlLbku7bkuro6IHlpbnhp bnhpbmcNCuaKhOmAgTogdGxzQGlldGYub3JnDQrkuLvpopg6IFJlOiDnrZTlpI06IFtUTFNdIENv bm5lY3Rpb24gSUQgRHJhZnQNCg0KDQoNCk9uIEZyaSwgT2N0IDEzLCAyMDE3IGF0IDc6NDEgUE0s IHlpbnhpbnhpbmcgPHlpbnhpbnhpbmdAaHVhd2VpLmNvbTxtYWlsdG86eWlueGlueGluZ0BodWF3 ZWkuY29tPj4gd3JvdGU6DQpUaGFua3MgRWtyLg0KDQpGb3Ig4oCcSSBleHBsaWNpdGx5IGRpZCBu b3Qgd2FudCB0byBkbyB0aGF0LCBiZWNhdXNlIHRoZXJlIGFyZSBhIGxvdCBvZiB2YWxpZCB3YXlz IHRvIGdlbmVyYXRlIENJRC4gVGhpcyBpcyBhbHNvIHdoYXQgd2UgZGlkIGluIFFVSUMu4oCdLCB0 aGUga2V5IHBvaW50IG9mIGRlc2NyaWJpbmcgdGhlIGdlbmVyYXRpb24gb2YgQ0lEIGlzIHRvIGF2 b2lkIGxpbmthYmlsaXR5IGJldHdlZW4gbmV3IENJRCBhbmQgb2xkIG9uZXMsIGFsdGhvdWdoIHRo ZXJlIGFyZSBsb3RzIG9mIHZhbGlkIHdheXMuDQoNCkkgZG9uJ3QgcmVhbGx5IGdldCB3aGF0IHlv dSdyZSBwcm9wb3NpbmcgaGVyZS4gQXMgSSBzYWlkLCB0aGVyZSBhcmUgYSBsb3Qgb2Ygd2F5cyB0 byBnZW5lcmF0ZSBjb25uZWN0aW9uIElEcyBhbmQgaXQncyBub3QgaGVscGZ1bCB0byBwcmVzY3Jp YmUgb25lLiBXZSBtaWdodCBiZSBhYmxlIHRvIHJlcXVpcmUgdGhhdCBpdCBub3QgYmUgcG9zc2li bGUgdG8gZGlzdGluZ3Vpc2ggd2hldGhlciB0d28gY29ubiBJRHMgYXJlIGZyb20gdGhlIHNhbWUg Y29ubmVjdGlvbiB3aXRoIHByb2JhYmlsaXR5ID4gXGVwc2lsb24sIGJ1dCBldmVuIHRoYXQgaXMg bm90cml2aWFsIGlmIChmb3IgaW5zdGFuY2UpIHRoZXkgaGF2ZSBhIGdlbmVyYXRpb24gSUQuIFNv IEknZCBwcmVmZXIgdG8gZGVzY3JpYmUgdGhlIGlzc3VlIGluIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBhbmQgbGVhdmUgdGhlIGRldGFpbHMgdXAgdG8gaW1wbGVtZW50YXRpb25zLg0KDQot RWtyDQoNCg0KUmVnYXJkcywNCllpbiBYaW54aW5nDQoNCuWPkeS7tuS6ujogRXJpYyBSZXNjb3Js YSBbbWFpbHRvOmVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPl0NCuWPkemAgeaXtumX tDogMjAxN+W5tDEw5pyIMTPml6UgMjE6MDANCuaUtuS7tuS6ujogeWlueGlueGluZw0K5oqE6YCB OiB0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NCuS4u+mimDogUmU6IFtUTFNdIENv bm5lY3Rpb24gSUQgRHJhZnQNCg0KDQoNCk9uIEZyaSwgT2N0IDEzLCAyMDE3IGF0IDE6MTEgQU0s IHlpbnhpbnhpbmcgPHlpbnhpbnhpbmdAaHVhd2VpLmNvbTxtYWlsdG86eWlueGlueGluZ0BodWF3 ZWkuY29tPj4gd3JvdGU6DQpIaSBFa3IsDQoNClRoYW5rcyBmb3IgeW91ciBlZmZvcnQuIFRoZSBk cmFmdCBsb29rcyBnb29kLiBBIGZldyBjb21tZW50cyBhcmUgbGlzdGVkIGJlbG93Lg0KDQoNCjEu ICAgICAgIEJhc2VkIG9uIHRoZSBkcmFmdCwgZm9yIGVpdGhlciBEVExTMS4yIG9yIDEuMywgc2Vy dmVyIGNhbuKAmXQgZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZSBwYWNrZXQgZnJvbSBjbGllbnQg aXMgYSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldCBvciBhIHN0YW5kYXJkIERUTFMgMS4yLzEu MyBwYWNrZXQuIChJIHNhdyBUaG9tYXMgRm9zc2F0aSBhbmQgTmlrb3MgYWxzbyBpbnRyb2R1Y2Vk IHRoaXMgcHJvYmxlbSkNCg0KTWF5YmUgd2UgY2FuIGFkZCBhIG5ldyDigJxDb250ZW50VHlwZeKA nSBpbiB0aGUgRFRMUyByZWNvcmQgZm9ybWF0IHRvIGhlbHAgc2VydmVyIGlkZW50aWZ5IHRoZSDi gJxjb25uZWN0aW9uIElE4oCdIHBhY2tldC4gSW4gYWRkaXRpb24sIHlvdSBzZWUgdGhlIGxlbmd0 aCBvZiB0aGUgcmVjb3JkIHBheWxvYWQgaXMgbGltaXRlZCBieSAyXjE0LTEsIHRoaXMgbWVhbnMg dGhlIGZpcnN0IHR3byBiaXRzIG9mIOKAnGxlbmd0aOKAnSBpcyB6ZXJvLiBXZSBjb3VsZCB1dGls aXplIHRoaXMgZmVhdHVyZSBhbmQgc2V0IHRoZSBmaXJzdCB0d28gYml0cyBvciBtb3JlIGJpdHMg b2YgQ0lEIGJlaW5nIG9uZSwgZS5nLiwgMTExMeKApi4oYnV0IHRoZSBDSUQgbXVzdCBiZSBwdXQg YmV0d2VlbiBzZXF1ZW5jZSBudW1iZXIgYW5kIGxlbmd0aCkuIFdoZW4gc2VydmVyIGZpbmRzIDEx MTEgYWZ0ZXIgc2VxdWVuY2UgbnVtYmVyLCBpdCBrbm93cyB0aGlzIGlzIGEg4oCcY29ubmVjdGlv biBJROKAnSBwYWNrZXQuIEhvd2V2ZXIsIEkgZG9u4oCZdCBrbm93IHdoZXRoZXIgaXQgaXMgcHJv cGVyIHRvIHVzZSBzdWNoIG1hZ2ljIG51bWJlci4gSW4gbXkgdmlldywgYWRkaW5nIG5ldyBjb250 ZW50dHlwZSBtYXkgYmUgYSBjaG9pY2UuDQoNCkFzIEkgc2FpZCB0byBOaWtvcywgZm9yIERUTFMg MS4yLCB5b3UgY2FuIHVzZSBhIHNwZWNpYWxseS1jb25zdHJ1Y3RlZCBDSUQgdGhhdCB3b3VsZCBu b3QgYmUgYSB2YWxpZCBsZW5ndGggZmllbGQuIFRoaXMgY2FuIGFjdHVhbGx5IGp1c3QgaGF2ZSB0 aGUgbGVhZGluZyBiaXQgc2V0LiBBcyB3ZSdyZSByZXZpc2luZyB0aGUgRFRMUyAxLjMgcmVjb3Jk IGZvcm1hdCwgd2Ugd291bGQgbmVlZCB0byBkbyBzb21ldGhpbmcgZGlmZmVyZW50IGZvciB0aGF0 Lg0KDQoNCjIuICAgICAgICBGb3IgRFRMUyAxLjIsIHRoZXJlIGlzIG5vIE5ld0Nvbm5lY3Rpb25J RCBhbmQgUmVxdWVzdENvbm5lY3Rpb25JRCBtZXNzYWdlLiBEVExTIDEuMiBzZXJ2ZXIgYW5kIGNs aWVudCBhbHNvIGhhcyB0aGUgcmVxdWlyZW1lbnQgdG8gcmVxdWVzdCBmb3IgYSBuZXcgQ0lELCBh bmQgYXQgcHJlc2VudCwgbWFueSBwcm9kdWN0cyBzdGlsbCB1c2UgRFRMUzEuMiBhbmQgSSBiZWxp ZXZlIGl0IHdpbGwgY29udGludWUgdG8gYmUgdXNlZCBmb3IgYSBsb25nIHRpbWUgZXZlbiBpZiBU TFMvRFRMUzEuMyBpcyBwdWJsaXNoZWQuIE15IHBvaW50IGlzIHRoYXQgd2UgbmVlZCBhIGNvcnJl c3BvbmRpbmcgbWV0aG9kIGZvciB1cGRhdGluZyBDSUQgZm9yIERUTFMxLjIgdG9vLg0KSW4gZ2Vu ZXJhbCwgdGhlIFdHIGlzIHdvcmtpbmcgb24gVExTIDEuMywgbm90IFRMUyAxLjIsIHNvIEknbSBu b3QgcmVhbGx5IHRoYXQgZXhjaXRlZCBhYm91dCBwdXR0aW5nIGEgbG90IG9mIGVmZm9ydCBpbnRv IGVuaGFuY2luZyBUTFMgMS4yLiBUaGUgYmFzaWMgZXh0ZW5zaW9uIHdvcmtzIGZpbmUgZm9yIHRo ZW0sIGJ1dCBpZiB0aGV5IHdhbnQgdG8gY2hhbmdlIENJRHMsIHRoZW4gdGhleSBzaG91bGQgYWRv cHQgRFRMUyAxLjMuDQoNCg0KSSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQgdGhlIGZvbGxvd2lu ZyBzZW50ZW5jZXMNCg0K4oCcSW4gRFRMUyAxLjIsIGNvbm5lY3Rpb24gaWRzIGFyZSBleGNoYW5n ZWQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUNCg0KICAgRFRMUyBzZXNzaW9uIG9ubHkuICBUaGVy ZSBpcyBubyBkZWRpY2F0ZWQgImNvbm5lY3Rpb24gaWQgdXBkYXRlIg0KDQogICBtZXNzYWdlIHRo YXQgYWxsb3dzIG5ldyBjb25uZWN0aW9uIGlkcyB0byBiZSBlc3RhYmxpc2hlZCBtaWQtc2Vzc2lv biwNCg0KICAgYmVjYXVzZSBEVExTIDEuMiBpbiBnZW5lcmFsIGRvZXMgbm90IGFsbG93IHBvc3Qt aGFuZHNoYWtlIG1lc3NhZ2VzDQoNCiAgIHRoYXQgZG8gbm90IHRoZW1zZWx2ZXMgYmVnaW4gb3Ro ZXIgaGFuZHNoYWtlcy7igJ0NCg0KVGhlIG9ubHkgcG9zdC1oYW5kc2hha2UgbWVzc2FnZXMgYWxs b3dlZCBpbiBEVExTIDEuMiBhcmUgQ2xpZW50SGVsbG8gYW5kIEhlbGxvUmVxdWVzdC4NCg0KDQpC ZXNpZGVzLCBmb3IgQ0lEIGluIERUTFMxLjMsIEkgdGhpbmsgdGhlIGNvcnJlc3BvbmRpbmcgcmVz cG9uZGluZyBtZXNzYWdlcyBvZiAgTmV3Q29ubmVjdGlvbklEIGFuZCBSZXF1ZXN0Q29ubmVjdGlv bklEIGFyZSBhbHNvIG5lZWRlZCB0byBlbnN1cmUgdGhhdCB0aGUgcGVlciBoYXMgcmVjZWl2ZWQg Q0lELg0KDQpObywgeW91IHVzZSB0aGUgQUNLIGZvciB0aGVzZSAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLWR0bHMxMy0wMSNzZWN0aW9uLTcpLiBUaGlzIGlzIG9u ZSByZWFzb24gd2h5IHRoZXJlIGlzIG5vdCBhIHN0cmFpZ2h0Zm9yd2FyZCBwb3J0IHRvIERUTFMg MS4yIGZvciB0aGVzZSBtZXNzYWdlcy4NCg0KDQo0LiAgICAgICBUaGUgZ2VuZXJhdGlvbiBvZiBD SUQgc2hvdWxkIGJlIG1vcmUgY29uY3JldGUuIEZvciBleGFtcGxlLCB1c2luZyByYW5kb20gbnVt YmVyIG9yIGEgY291bnRlcj8NCkkgZXhwbGljaXRseSBkaWQgbm90IHdhbnQgdG8gZG8gdGhhdCwg YmVjYXVzZSB0aGVyZSBhcmUgYSBsb3Qgb2YgdmFsaWQgd2F5cyB0byBnZW5lcmF0ZSBDSUQuIFRo aXMgaXMgYWxzbyB3aGF0IHdlIGRpZCBpbiBRVUlDLg0KDQotRWtyDQoNCg0KDQpSZWdhcmRzLA0K WWluIFhpbnhpbmcNCg0K5Y+R5Lu25Lq6OiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSDku6PooaggRXJpYyBSZXNjb3JsYQ0K5Y+R 6YCB5pe26Ze0OiAyMDE35bm0MTDmnIgxM+aXpSA3OjE0DQrmlLbku7bkuro6IHRsc0BpZXRmLm9y ZzxtYWlsdG86dGxzQGlldGYub3JnPg0K5Li76aKYOiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0 DQoNCkhpIGZvbGtzLA0KDQpJIGhhdmUganVzdCBwb3N0ZWQgYSBmaXJzdCBjdXQgYXQgYSBjb25u ZWN0aW9uIElEIGRyYWZ0Lg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2Nv cmxhLXRscy1kdGxzLWNvbm5lY3Rpb24taWQtMDANCg0KQ29tbWVudHMgd2VsY29tZS4NCg0KLUVr cg0KDQoNCg0KDQoNCg== --_000_DBDF9AE44733284D808F0E585E1919022C7ABCA1dggemi508mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tNjUxMjMxMTE3MzEyNjI5MTAzM2dtYWls LW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCwgbGkubTY1MTIzMTExNzMxMjYy OTEwMzNnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tNjUx MjMxMTE3MzEyNjI5MTAzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFw aA0KCXttc28tc3R5bGUtbmFtZTptXzY1MTIzMTExNzMxMjYyOTEwMzNnbWFpbC1tLTY1MTM2MDUz MzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJa SC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oSSBtZWFuIHRoYXQgd2UgZ2l2ZSBzb21lIHdhcm5p bmcgYW5kIHN1Z2dlc3Rpb24gb24gdGhlIGxpbmthYmlsaXR5LA0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YWx0aG91Z2ggdGhl cmUgYXJlIGxvdHMgb2YgdmFsaWQgd2F5cy4pPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgbWlzcyByZWFkaW5nIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHBh cnQsIG5vdywgJm5ic3A7SSBoYXZlIHNhdyB0aGUgd2FybmluZyBvZiBsaW5rYWJpbGl0eS4gTm8g cHJvYmxlbSBub3cuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWluIFhp bnhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bh bj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+DQo8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT Ij4xNDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTA6NDc8YnI+DQo8L3NwYW4+PGI+ 5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4geWlueGlueGluZzxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB0bHNAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+ 5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4g UmU6IDwvc3Bhbj7nrZTlpI08c3BhbiBsYW5nPSJFTi1VUyI+OiBbVExTXSBDb25uZWN0aW9uIElE IERyYWZ0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBGcmksIE9jdCAxMywgMjAxNyBhdCA3OjQxIFBNLCB5 aW54aW54aW5nICZsdDs8YSBocmVmPSJtYWlsdG86eWlueGlueGluZ0BodWF3ZWkuY29tIiB0YXJn ZXQ9Il9ibGFuayI+eWlueGlueGluZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoYW5rcyBFa3IuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9y IOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+SSBleHBsaWNpdGx5IGRpZCBub3Qgd2FudCB0 byBkbyB0aGF0LCBiZWNhdXNlIHRoZXJlIGFyZQ0KIGEgbG90IG9mIHZhbGlkIHdheXMgdG8gZ2Vu ZXJhdGUgQ0lELiBUaGlzIGlzIGFsc28gd2hhdCB3ZSBkaWQgaW4gUVVJQy48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0sIHRo ZSBrZXkgcG9pbnQgb2YgZGVzY3JpYmluZyB0aGUgZ2VuZXJhdGlvbiBvZiBDSUQgaXMgdG8gYXZv aWQgbGlua2FiaWxpdHkgYmV0d2VlbiBuZXcNCiBDSUQgYW5kIG9sZCBvbmVzLCBhbHRob3VnaCB0 aGVyZSBhcmUgbG90cyBvZiB2YWxpZCB3YXlzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkkgZG9uJ3QgcmVhbGx5IGdldCB3aGF0IHlvdSdyZSBwcm9wb3NpbmcgaGVy ZS4gQXMgSSBzYWlkLCB0aGVyZSBhcmUgYSBsb3Qgb2Ygd2F5cyB0byBnZW5lcmF0ZSBjb25uZWN0 aW9uIElEcyBhbmQgaXQncyBub3QgaGVscGZ1bCB0byBwcmVzY3JpYmUgb25lLiBXZSBtaWdodCBi ZSBhYmxlIHRvIHJlcXVpcmUgdGhhdCBpdCBub3QgYmUgcG9zc2libGUgdG8gZGlzdGluZ3Vpc2gg d2hldGhlcg0KIHR3byBjb25uIElEcyBhcmUgZnJvbSB0aGUgc2FtZSBjb25uZWN0aW9uIHdpdGgg cHJvYmFiaWxpdHkgJmd0OyBcZXBzaWxvbiwgYnV0IGV2ZW4gdGhhdCBpcyBub3RyaXZpYWwgaWYg KGZvciBpbnN0YW5jZSkgdGhleSBoYXZlIGEgZ2VuZXJhdGlvbiBJRC4gU28gSSdkIHByZWZlciB0 byBkZXNjcmliZSB0aGUgaXNzdWUgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFuZCBs ZWF2ZSB0aGUgZGV0YWlscyB1cCB0byBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tRWtyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+WWluIFhpbnhpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuWPkeS7tuS6ujwvc3Bh bj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiBFcmljIFJlc2Nv cmxhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmVrckBydGZtLmNvbTwvYT5dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ 5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xMDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xMzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4NCiAyMTowMDxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ 5pS25Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiB5aW54aW54aW5nPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij7mioTpgIE8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ DQo8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzQGlldGYu b3JnPC9hPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5Li7 6aKYPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSZTog W1RMU10gQ29ubmVjdGlvbiBJRCBEcmFmdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+T24gRnJpLCBPY3QgMTMsIDIwMTcgYXQgMToxMSBBTSwgeWlueGlueGluZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnlpbnhpbnhpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnlpbnhpbnhpbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBFa3IsPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIGVmZm9ydC4g VGhlIGRyYWZ0IGxvb2tzIGdvb2QuIEEgZmV3IGNvbW1lbnRzIGFyZSBsaXN0ZWQgYmVsb3cuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0ibTY1MTIzMTExNzMxMjYyOTEwMzNnbWFpbC1tLTY1MTM2MDUz MzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4x Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CYXNl ZCBvbiB0aGUgZHJhZnQsIGZvciBlaXRoZXIgRFRMUzEuMiBvciAxLjMsIHNlcnZlciBjYW7igJl0 IGRpZmZlcmVudGlhdGUgd2hldGhlciB0aGUgcGFja2V0IGZyb20gY2xpZW50IGlzIGEg4oCcY29u bmVjdGlvbiBJROKAnSBwYWNrZXQgb3IgYSBzdGFuZGFyZCBEVExTIDEuMi8xLjMNCiBwYWNrZXQu IChJIHNhdyBUaG9tYXMgRm9zc2F0aSBhbmQgTmlrb3MgYWxzbyBpbnRyb2R1Y2VkIHRoaXMgcHJv YmxlbSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJtNjUxMjMxMTE3MzEyNjI5MTAzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNv bGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heWJlIHdlIGNhbiBh ZGQgYSBuZXcg4oCcQ29udGVudFR5cGXigJ0gaW4gdGhlIERUTFMgcmVjb3JkIGZvcm1hdCB0byBo ZWxwIHNlcnZlciBpZGVudGlmeSB0aGUg4oCcY29ubmVjdGlvbiBJROKAnSBwYWNrZXQuIEluIGFk ZGl0aW9uLCB5b3Ugc2VlIHRoZSBsZW5ndGggb2YgdGhlIHJlY29yZCBwYXlsb2FkDQogaXMgbGlt aXRlZCBieSAyXjE0LTEsIHRoaXMgbWVhbnMgdGhlIGZpcnN0IHR3byBiaXRzIG9mIOKAnGxlbmd0 aOKAnSBpcyB6ZXJvLiBXZSBjb3VsZCB1dGlsaXplIHRoaXMgZmVhdHVyZSBhbmQgc2V0IHRoZSBm aXJzdCB0d28gYml0cyBvciBtb3JlIGJpdHMgb2YgQ0lEIGJlaW5nIG9uZSwgZS5nLiwgMTExMeKA pi4oYnV0IHRoZSBDSUQgbXVzdCBiZSBwdXQgYmV0d2VlbiBzZXF1ZW5jZSBudW1iZXIgYW5kIGxl bmd0aCkuIFdoZW4gc2VydmVyIGZpbmRzIDExMTENCiBhZnRlciBzZXF1ZW5jZSBudW1iZXIsIGl0 IGtub3dzIHRoaXMgaXMgYSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldC4gSG93ZXZlciwgSSBk b27igJl0IGtub3cgd2hldGhlciBpdCBpcyBwcm9wZXIgdG8gdXNlIHN1Y2ggbWFnaWMgbnVtYmVy LiBJbiBteSB2aWV3LCBhZGRpbmcgbmV3IGNvbnRlbnR0eXBlIG1heSBiZSBhIGNob2ljZS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QXMgSSBzYWlkIHRvIE5p a29zLCBmb3IgRFRMUyAxLjIsIHlvdSBjYW4gdXNlIGEgc3BlY2lhbGx5LWNvbnN0cnVjdGVkIENJ RCB0aGF0IHdvdWxkIG5vdCBiZSBhIHZhbGlkIGxlbmd0aCBmaWVsZC4gVGhpcyBjYW4gYWN0dWFs bHkganVzdCBoYXZlIHRoZSBsZWFkaW5nIGJpdA0KIHNldC4gQXMgd2UncmUgcmV2aXNpbmcgdGhl IERUTFMgMS4zIHJlY29yZCBmb3JtYXQsIHdlIHdvdWxkIG5lZWQgdG8gZG8gc29tZXRoaW5nIGRp ZmZlcmVudCBmb3IgdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTY1MTIzMTExNzMxMjYyOTEw MzNnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDtGb3IgRFRMUyAxLjIsIHRoZXJlIGlzIG5vIE5ld0Nvbm5lY3Rp b25JRCBhbmQgUmVxdWVzdENvbm5lY3Rpb25JRCBtZXNzYWdlLiBEVExTIDEuMiBzZXJ2ZXIgYW5k IGNsaWVudCBhbHNvIGhhcyB0aGUgcmVxdWlyZW1lbnQgdG8gcmVxdWVzdCBmb3IgYSBuZXcgQ0lE LCBhbmQNCiBhdCBwcmVzZW50LCBtYW55IHByb2R1Y3RzIHN0aWxsIHVzZSBEVExTMS4yIGFuZCBJ IGJlbGlldmUgaXQgd2lsbCBjb250aW51ZSB0byBiZSB1c2VkIGZvciBhIGxvbmcgdGltZSBldmVu IGlmIFRMUy9EVExTMS4zIGlzIHB1Ymxpc2hlZC4gTXkgcG9pbnQgaXMgdGhhdCB3ZSBuZWVkIGEg Y29ycmVzcG9uZGluZyBtZXRob2QgZm9yIHVwZGF0aW5nIENJRCBmb3IgRFRMUzEuMiB0b28uPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPkluIGdlbmVyYWwsIHRoZSBXRyBpcyB3b3JraW5nIG9uIFRMUyAxLjMsIG5v dCBUTFMgMS4yLCBzbyBJJ20gbm90IHJlYWxseSB0aGF0IGV4Y2l0ZWQgYWJvdXQgcHV0dGluZyBh IGxvdCBvZiBlZmZvcnQgaW50byBlbmhhbmNpbmcgVExTIDEuMi4gVGhlIGJhc2ljIGV4dGVuc2lv bg0KIHdvcmtzIGZpbmUgZm9yIHRoZW0sIGJ1dCBpZiB0aGV5IHdhbnQgdG8gY2hhbmdlIENJRHMs IHRoZW4gdGhleSBzaG91bGQgYWRvcHQgRFRMUyAxLjMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im02 NTEyMzExMTczMTI2MjkxMDMzZ21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHF1aXRlIHVuZGVyc3Rh bmQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZXMNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im02NTEyMzExMTczMTI2MjkxMDMzZ21haWwt bS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+4oCcSW4gRFRMUyAxLjIsIGNvbm5lY3Rpb24gaWRzIGFyZSBleGNoYW5nZWQgYXQg dGhlIGJlZ2lubmluZyBvZiB0aGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJtNjUxMjMxMTE3MzEyNjI5MTAzM2dtYWlsLW0tNjUxMzYw NTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyBEVExTIHNlc3Npb24gb25seS4mbmJzcDsgVGhlcmUgaXMgbm8gZGVkaWNh dGVkICZxdW90O2Nvbm5lY3Rpb24gaWQgdXBkYXRlJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTY1MTIzMTExNzMxMjYyOTEw MzNnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbWVzc2FnZSB0aGF0IGFsbG93cyBuZXcgY29u bmVjdGlvbiBpZHMgdG8gYmUgZXN0YWJsaXNoZWQgbWlkLXNlc3Npb24sPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTY1MTIzMTExNzMx MjYyOTEwMzNnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgYmVjYXVzZSBEVExTIDEuMiBpbiBn ZW5lcmFsIGRvZXMgbm90IGFsbG93IHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTY1MTIzMTEx NzMxMjYyOTEwMzNnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdGhhdCBkbyBub3QgdGhlbXNl bHZlcyBiZWdpbiBvdGhlciBoYW5kc2hha2VzLuKAnTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgb25seSBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBhbGxv d2VkIGluIERUTFMgMS4yIGFyZSBDbGllbnRIZWxsbyBhbmQgSGVsbG9SZXF1ZXN0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJtNjUxMjMxMTE3MzEyNjI5MTAzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1 MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc2lkZXMs IGZvciBDSUQgaW4gRFRMUzEuMywgSSB0aGluayB0aGUgY29ycmVzcG9uZGluZyByZXNwb25kaW5n IG1lc3NhZ2VzIG9mICZuYnNwO05ld0Nvbm5lY3Rpb25JRCBhbmQgUmVxdWVzdENvbm5lY3Rpb25J RCBhcmUgYWxzbyBuZWVkZWQgdG8gZW5zdXJlIHRoYXQgdGhlIHBlZXIgaGFzIHJlY2VpdmVkDQog Q0lELjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5ObywgeW91 IHVzZSB0aGUgQUNLIGZvciB0aGVzZSAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtdGxzLWR0bHMxMy0wMSNzZWN0aW9uLTciIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtZHRsczEzLTAxI3NlY3Rp b24tNzwvYT4pLg0KIFRoaXMgaXMgb25lIHJlYXNvbiB3aHkgdGhlcmUgaXMgbm90IGEgc3RyYWln aHRmb3J3YXJkIHBvcnQgdG8gRFRMUyAxLjIgZm9yIHRoZXNlIG1lc3NhZ2VzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJtNjUxMjMxMTE3MzEyNjI5MTAzM2dtYWlsLW0tNjUxMzYwNTMzMzEz ODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjQuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBnZW5l cmF0aW9uIG9mIENJRCBzaG91bGQgYmUgbW9yZSBjb25jcmV0ZS4gRm9yIGV4YW1wbGUsIHVzaW5n IHJhbmRvbSBudW1iZXIgb3IgYSBjb3VudGVyPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGV4cGxpY2l0bHkg ZGlkIG5vdCB3YW50IHRvIGRvIHRoYXQsIGJlY2F1c2UgdGhlcmUgYXJlIGEgbG90IG9mIHZhbGlk IHdheXMgdG8gZ2VuZXJhdGUgQ0lELiBUaGlzIGlzIGFsc28gd2hhdCB3ZSBkaWQgaW4gUVVJQy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4tRWty PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWluIFhpbnhpbmc8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4NCiBUTFMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8L3NwYW4+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuS7o+ihqDwvc3Bhbj48L2I+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5FcmljIFJlc2NvcmxhPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij7lj5HpgIHml7bpl7Q8L3NwYW4+PC9iPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IDIwMTc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPuW5tDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+MTA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuaciDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MTM8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+DQogNzoxNDxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+5pS25Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnRsc0BpZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gW1RMU10gQ29ubmVjdGlvbiBJRCBEcmFmdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUganVzdCBwb3N0ZWQgYSBmaXJz dCBjdXQgYXQgYSBjb25uZWN0aW9uIElEIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZXNjb3JsYS10bHMtZHRs cy1jb25uZWN0aW9uLWlkLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1kdGxzLWNvbm5lY3Rpb24taWQtMDA8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q29tbWVudHMg d2VsY29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4tRWtyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DBDF9AE44733284D808F0E585E1919022C7ABCA1dggemi508mbschi_-- From nobody Sat Oct 14 09:54:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67D5132355 for ; Sat, 14 Oct 2017 09:54:25 -0700 (PDT) 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, 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=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 ReRYfRe_um34 for ; Sat, 14 Oct 2017 09:54:24 -0700 (PDT) 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 1943A132199 for ; Sat, 14 Oct 2017 09:54:23 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9EGpVtw000826; Sat, 14 Oct 2017 17:54:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=FMXFubfPJ+FRlDST+Lu7kb1MXIPi754Orpd/1zP+te0=; b=BS9QMnbczdM3Z7JOtdmnGHVguZDTXnSj8MdfshK7bjZjYc3FhdVRT0FQQ1A5g6fLzZj3 EITOXoBzoR2MjqUXk475/axVw8V/XDBvHo42+ZnBqSR0fDcl57fU2IGY/1u0tYbqZ1tC btkNFVB047VQtXLA+X4Y1qpAziP5FjIbwWMlHAC3dnlE229DHPJHU5xvJfDaBfFkq01z YWgx/ULmvKXxP05MuPsW5b8yecTRiZnQkMTQNKzZABuQipvMZ1nuZIa8IMlhtBPgiIwQ mE812mpnaNzg45ZkmFNEQfjkopa8lJYky7d86O7Z38x8exewapEJhCyNOe+cmED4mqcT oA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2dka7sh86u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Oct 2017 17:54:22 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9EGoUNU000514; Sat, 14 Oct 2017 12:54:21 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dkdwu0v6e-1; Sat, 14 Oct 2017 12:54:21 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 0053B1FC7D; Sat, 14 Oct 2017 16:54:20 +0000 (GMT) To: Eric Rescorla , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <6622cfac-e989-f3c6-8832-12799efe28f1@akamai.com> Date: Sat, 14 Oct 2017 11:54:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6A27D254DB25E21DA58E1AFC" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-14_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710140242 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-14_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710140242 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 16:54:26 -0000 This is a multi-part message in MIME format. --------------6A27D254DB25E21DA58E1AFC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/12/2017 06:13 PM, Eric Rescorla wrote: > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > Comments welcome. > I see it already got some good comments, so I'll try to stick to just new ones. Since a participant that wants to make use of DTLS CIDs might expect to talk to many peers, some of which do and some of which do not support the CID extension, it seems like the participant might want to always use the same cid_length for all its peers that support CIDs, to ease the parsing decision and CID lookup process, and we could mention this expectation. Or am I missing some reason why the CID would be easy to pick out of the ciphertext otherwise? In the security/privacy considerations: An on-path adversary, who is able to observe the DTLS 1.2 protocol exchanges between the DTLS client and the DTLS server, is able to link the initial handshake to all subsequent payloads carrying the same connection id pair (for bi-directional communication). My first time reading this I thought that the text was only claiming that linkability was possible if the initial handshake was observed, which is not really needed. It might be better to avoid mentioning the handshake at all and just say that the attacker is able to link all observed payloads carrying the same connection id pair as being exchanges between the same client and server. -Ben --------------6A27D254DB25E21DA58E1AFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/12/2017 06:13 PM, Eric Rescorla wrote:
Hi folks,

I have just posted a first cut at a connection ID draft.

Comments welcome.


I see it already got some good comments, so I'll try to stick to just new ones.

Since a participant that wants to make use of DTLS CIDs might expect to talk to many peers, some of which do and some of which do not support the CID extension, it seems like the participant might want to always use the same cid_length for all its peers that support CIDs, to ease the parsing decision and CID lookup process, and we could mention this expectation. Or am I missing some reason why the CID would be easy to pick out of the ciphertext otherwise?

In the security/privacy considerations:

   An on-path adversary, who is able to observe the DTLS 1.2 protocol
   exchanges between the DTLS client and the DTLS server, is able to
   link the initial handshake to all subsequent payloads carrying the
   same connection id pair (for bi-directional communication).

My first time reading this I thought that the text was only claiming that linkability was possible if the initial handshake was observed, which is not really needed.  It might be better to avoid mentioning the handshake at all and just say that the attacker is able to link all observed payloads carrying the same connection id pair as being exchanges between the same client and server.

-Ben
--------------6A27D254DB25E21DA58E1AFC-- From nobody Sat Oct 14 13:40:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99A513300C for ; Sat, 14 Oct 2017 13:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iyb1DaOBzxv for ; Sat, 14 Oct 2017 13:40:53 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEB813209C for ; Sat, 14 Oct 2017 13:40:53 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id n61so25246074qte.10 for ; Sat, 14 Oct 2017 13:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YomW38q5Cx0ThguPgHyEv6GAk/+AfXOjUcedrrvSbzM=; b=MI8LmWyyOCloYD7CKoBGcZUpWFTVkshqTWsyeLDgleAArxxoETV9kk44iPR5O2W/2v 92CHiCzNSTJBTGs1mDyTytFLql74mimjIilqq7WgxuFdO1LMgffiit4LdIogOHoH4Bmn gRAPrYyQfhxjHL9NW0FNmnCeY++UCtaZrn+vDjZyAycJ3i5kBvX4Jk7uOLhTQidqtbbN Vr8J9U/BXXXWVHfw1gH482xrsdIctO8lTBsNXhCf1FXq52wo/XFvySw9/iZ7//ejuX3N WT8VFOAQv+YaJku0V9M1DRgyPcOf7C1gQ8IYcTgzkvwGRO7qPqXE2V0a05eVOVCX/OlA vGwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YomW38q5Cx0ThguPgHyEv6GAk/+AfXOjUcedrrvSbzM=; b=kEWEIS7Xm1Yi5wXdiiQ+TDCAaqsf30FJCeqvhAb9c8NvIUuqaKGVe6gCmBHHfFPwQp wo7nqp3c/OOjGQcKA+zKGycjtgH/3hAu5oIAcpOOgdpBvA6EMpQm042laqjPaS4FFu89 yQZ4GCepOMjSDTxegQghKNkQSyNkQ9DVzjp1mWyDIEVlo1HTro7jRJhok38GCfrmHg0Z 2XOCXb4rH7BMAui/yjil53E9m+RX7PkpdNHbAU316/6+XmJ5fXVlgqdn1KHlj6uSUU0D c9YEwIWRVakF54DARsh4OLE0/dhpSlFn0nOweXjlFXuC8dV2bftzq1P9QfflrA+BPIwo +pkw== X-Gm-Message-State: AMCzsaXJxLqsg6yu9WyYeT/2rwML2DSOGbGfaJJCv9oBFE+2BqV5UgWq 9+A3N10xpbiTY7qyK8nr8syaDsEhInveCmpVJFrXaA== X-Google-Smtp-Source: AOwi7QBkzVfKSO0L3DDnU5Ef6SAc8xgqTm5Q1jGQY8TPnVZuHu3BHYIELjton1G/8K4uYh+B7O9Ezk5oWAQqJg93L74= X-Received: by 10.129.108.3 with SMTP id h3mr3398250ywc.327.1508013652715; Sat, 14 Oct 2017 13:40:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sat, 14 Oct 2017 13:40:12 -0700 (PDT) In-Reply-To: <6622cfac-e989-f3c6-8832-12799efe28f1@akamai.com> References: <6622cfac-e989-f3c6-8832-12799efe28f1@akamai.com> From: Eric Rescorla Date: Sat, 14 Oct 2017 13:40:12 -0700 Message-ID: To: Benjamin Kaduk Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114d9a28163f2b055b87ca3d" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 20:40:56 -0000 --001a114d9a28163f2b055b87ca3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 14, 2017 at 9:54 AM, Benjamin Kaduk wrote: > On 10/12/2017 06:13 PM, Eric Rescorla wrote: > > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > Comments welcome. > > > I see it already got some good comments, so I'll try to stick to just new > ones. > > Since a participant that wants to make use of DTLS CIDs might expect to > talk to many peers, some of which do and some of which do not support the > CID extension, it seems like the participant might want to always use the > same cid_length for all its peers that support CIDs, to ease the parsing > decision and CID lookup process, and we could mention this expectation. O= r > am I missing some reason why the CID would be easy to pick out of the > ciphertext otherwise? > No, I think that's a good suggestion. PR Welcome :) In the security/privacy considerations: > > An on-path adversary, who is able to observe the DTLS 1.2 protocol > exchanges between the DTLS client and the DTLS server, is able to > link the initial handshake to all subsequent payloads carrying the > same connection id pair (for bi-directional communication). > > My first time reading this I thought that the text was only claiming that= linkability was possible if the initial handshake was observed, which is n= ot really needed. It might be better to avoid mentioning the handshake at = all and just say that the attacker is able to link all observed payloads ca= rrying the same connection id pair as being exchanges between the same clie= nt and server. > > Yeah, that seems like a good point. -Ekr > -Ben > > --001a114d9a28163f2b055b87ca3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 14, 2017 at 9:54 AM, Benjamin Kaduk <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
=20 =20 =20
On 10/12/2017 06:13 PM, Eric Rescorla wrote:
=20
Hi folks,

I have just posted a first cut at a connection ID draft.

Comments welcome.


 I see it already got some good comments, so I'll try to stick to just new ones.

Since a participant that wants to make use of DTLS CIDs might expect to talk to many peers, some of which do and some of which do not support the CID extension, it seems like the participant might want to always use the same cid_length for all its peers that support CIDs, to ease the parsing decision and CID lookup process, and we could mention this expectation. Or am I missing some reason why the CID would be easy to pick out of the ciphertext otherwise?

No, I think that's a good suggestion. PR = Welcome :)


In the security/privacy considerations:

   An on-path adversary, wh=
o is able to observe the DTLS 1.2 protocol
   exchanges between the DTLS client and the DTLS server, is able to
   link the initial handshake to all subsequent payloads carrying the
   same connection id pair (for bi-directional communication).

My first time reading this I thought that the text was only claiming that l=
inkability was possible if the initial handshake was observed, which is not=
 really needed.  It might be better to avoid mentioning the handshake at al=
l and just say that the attacker is able to link all observed payloads carr=
ying the same connection id pair as being exchanges between the same client=
 and server.

Yeah, that seems l= ike a good point.

-Ekr
=C2=A0
-Ben

--001a114d9a28163f2b055b87ca3d-- From nobody Mon Oct 16 06:11:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21D133347 for ; Mon, 16 Oct 2017 06:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 RkWbeeu1kyhG for ; Mon, 16 Oct 2017 06:11:15 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0134.outbound.protection.outlook.com [104.47.2.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C08132F7C for ; Mon, 16 Oct 2017 06:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ajMO5wuZX17GCAMTPEcJ1h580jG9+3/+rtA3CqJ6Cms=; b=rjjIRQFMu7YKxsCuPn6ctNiHWJ+DEjR9qb4wrD5HWB2m+GNgnxfRQAULhQhh6oKKVUx1Wv9ESMYx7P/sR9QaV0y9WMV1yIGKgAJsYYEHj9LR+DtR+hr/8K1k0TkYGDHYTjNUvhwawArDrW2+a4lvCz/NP/rigolxrpmjQovRndw= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Mon, 16 Oct 2017 13:11:12 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::c0d1:2c07:79aa:1d9e]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::c0d1:2c07:79aa:1d9e%14]) with mapi id 15.20.0077.018; Mon, 16 Oct 2017 13:11:11 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Matt Caswell , "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AQHTQ6/ei1Eh6DPTUUK7WLQddJSSYqLhYyGAgABgDQCABMatAA== Date: Mon, 16 Oct 2017 13:11:11 +0000 Message-ID: <0B2743C5-B702-4BCC-A499-FB0A62A74933@nokia.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1102; 6:wMRL3O1HH+bceFuVN41rkDRWOyxJC3xJQ8ht4XnfHi7rCZqTNGBFkD88PG5wpKl2GCz4XKZaLBKQ7DwCE/78+24Mfnq3xsdOca9JY7ZugtX1LT8KQwQ2sgVarrK28xHfcqiOPYlni4l8CS+BbrkWtCJ7Ml+asGeh6Z+oHBnsa3CiEVkHhfJ1BFD8+yKxej4LwLXbDTJ5Lq9vaxyAb4VVX4hEbQ1PR6himyh1dIbdANHxtj9RMxRyI4hOFnRvmwB49RI9oceNPY7WSjKNWFSYiBzOqFyCki7jyK25e/YTcGUYQfm3A/RKcEHUAbhk1K4CqEcuh818YdBVzI8cTPf8Rw==; 5:Uk9uF6sswwU/P2T8FmgwIqea+/sdZtQtxc/F8p1ENqHekTeXK7VnkKQMtDnvl89gaMqHGuB9hPjhMVa+/wlaaX6MVaaOOSfONohG+oc/lZGuLFbT1l7ohr6V5gAmvLZ44qYr9ooWUbNx2MKUttW8kA==; 24:rkIWDYKTtFS08vSS060teE5LhXbZLfBVDRr+bWtn7WRbCYnNXq+AUJkR7Z57U3eXDWkQ4it4uvsJxM30OWwNRos/wvH/cjGD8meytbEZkrM=; 7:BBmikGfsiuJr89TkZ4QkhoGjSUfdxXoHlRhFLIr8x305/3BKLKAO+TlJbnxDeQhZltWc9wl52SW9VMLu7uVvi0NKhWyeuKHmPYtPV/DNTxLSZuSlqPjUnf+6gGADtCe6v7I5XdbdMZweEA1Tt2LCoMy5eT1PMZo+OHYOMVyvVpONCyHV1OOGql0cFFrtFLwAL61QZV2cnjtRLpRC00Pbg9FQ4NGqY9YLeGMDQxE/SRQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(199003)(24454002)(189002)(105586002)(83716003)(53546010)(86362001)(14454004)(99286003)(5660300001)(2906002)(3846002)(2501003)(316002)(2950100002)(110136005)(53936002)(5250100002)(6246003)(107886003)(6116002)(102836003)(189998001)(2900100001)(478600001)(83506001)(6512007)(36756003)(4326008)(8936002)(81156014)(3280700002)(6506006)(3660700001)(81166006)(229853002)(106356001)(82746002)(6436002)(33656002)(101416001)(305945005)(6486002)(8676002)(66066001)(97736004)(25786009)(76176999)(54356999)(7736002)(68736007)(50986999)(58126008); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1102; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 3430f127-2023-4680-8c0c-08d514975f5a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1102; x-ms-traffictypediagnostic: VI1PR07MB1102: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1102; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1102; x-forefront-prvs: 0462918D61 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 13:11:11.3930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1102 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 13:11:17 -0000 SGkgTWF0dCwNCg0KT24gMTMvMTAvMjAxNywgMTQ6MTUsICJUTFMgb24gYmVoYWxmIG9mIE1hdHQg Q2Fzd2VsbCIgPHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBmcm9kb0BiYWdnaW5z Lm9yZz4gd3JvdGU6DQo+IFJlY2VudGx5IEkgbWV0IHdpdGggWWluIFhpbnhpbmcgYW5kIHdlIGhh dmUgaGFkIG11Y2ggdGhlIHNhbWUNCj4gY29udmVyc2F0aW9uIGFib3V0IHdoYXQgYSBDb25uZWN0 aW9uIElEIGRyYWZ0IHdvdWxkIG5lZWQgdG8gZG8sIGFuZA0KPiBob3cgd2UgY291bGQgZGV0ZWN0 IGl0cyB1c2Ugb24gdGhlIHdpcmUuIE1lY2hhbmlzbXMgd2UgdGFsa2VkIGFib3V0DQo+IGluY2x1 ZGVkIHNldHRpbmcgc29tZXRoaW5nIGluIHRoZSAibGVuZ3RoIiBmaWVsZCwgdXNpbmcgQ29udGVu dFR5cGUgb3INCj4gdXNpbmcgdmVyc2lvbi4gSU1PIHVzaW5nICJsZW5ndGgiIGlzIGp1c3QgaG9y cmlibGUuIEknbSBhbHNvIG5vdCBrZWVuDQo+IG9uIHZlcnNpb24gLSBpdCBmdXJ0aGVyIGNvbXBs aWNhdGVzIHRoZSAiaXMgdGhpcyB2ZXJzaW9uIGdyZWF0ZXIgdGhhbiwNCj4gZXF1YWwgdG8sIG9y IGxlc3MgdGhhbiB0aGlzIG90aGVyIHZlcnNpb24iIHF1ZXN0aW9uLiBJdCdzIGFscmVhZHkNCj4g c2xpZ2h0bHkgY29tcGxpY2F0ZWQgaW4gY29kZSB0aGF0IGltcGxlbWVudHMgYm90aCBUTFMgYW5k IERUTFMgZHVlIHRvDQo+IERUTFMgdmVyc2lvbnMgYmVpbmcgaGlnaCBhbmQgZGVjcmVtZW50aW5n IGZvciBhIG5ldyB2ZXJzaW9uLiBJIGZvcmVzZWUNCj4gbG90cyBvZiBzdWJ0bGUgYnVncyBhbmQg cHJvYmxlbXMgZnJvbSByZXVzaW5nICJ2ZXJzaW9uIi4gSW4gbXkgbWluZA0KPiBDb250ZW50VHlw ZSBpcyB0aGUgd2F5IHRvIGdvLg0KDQpSZTogdGhlIGxlbmd0aCBoYWNrLiAgSSBhZ3JlZSB3aXRo IHlvdSB0aGF0IGl0IGlzIG5vdCB0aGUgcmlnaHQgd2F5IHRvDQpnbyBoZXJlLg0KDQpSZTogQ1Qg dnMgdmVyc2lvbiwgYSBjb3VwbGUgb2YgcXVpY2sgdGhvdWdodHM6DQotIEknbSBzdGlsbCB1bmNv bnZpbmNlZCB0aGF0IENUIGlzIHRoZSByaWdodCBwbGFjZSB0byBzaWduaWZ5IGEgY2hhbmdlDQog IGluIHRoZSBwYXJzaW5nIGxvZ2ljcyB0aGF0IGVmZmVjdGl2ZWx5IHNwYW5zIGFsbCBDVHM7DQot IEJlc2lkZXMsIElTVE0gdGhhdCB2ZXJzaW9uIGlzIHRoZSBvbmx5IGZpZWxkIHRoYXQgd291bGQg cG90ZW50aWFsbHkNCiAgd29yayBmb3IgMS4zIGFzIHdlbGwgYXMgMS4yPw0KDQpDaGVlcnMsDQoN Cg== From nobody Mon Oct 16 06:16:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C801344E8 for ; Mon, 16 Oct 2017 06:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAHQ3-kDRN3d for ; Mon, 16 Oct 2017 06:16:33 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110C01344DD for ; Mon, 16 Oct 2017 06:16:33 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id f8so31501423qta.5 for ; Mon, 16 Oct 2017 06:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fS8dKDGfiKavpdY7+V0HiNdGGQ/dJ/Mz3B87AGnL8EY=; b=VMPHp+VXaylJmqNZ/HbqWtuIxCcaUvYDHKPOh2/qMQUM6bfjBozfiZiqOBUObxBkJs +pLbs+rfAA9irvIXRpme05CK8kWeOzy5lWkpudha7rR/0ahipV+zjtwWRnElpmkU2DSL uvqWHR4hc+jUumC6jrz49ab3tXxVjfaIzwQVH7ZQkPzrENrFaJ7Wt8U8WG15VtyDFe+C /k5Fb6ZQu17JeVZxyOTuFkvYahtNE9SoF9aodrcVRJntJK0I0CccXLJiR7u4uH8vQt4F 1WYfTYjiJH4lLJCVNO9EkBBcd8+wjSUwJnmgAet26ds2RQrU7RuOTIPBgHIiMDsaUaAi nSuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fS8dKDGfiKavpdY7+V0HiNdGGQ/dJ/Mz3B87AGnL8EY=; b=KwrAqWZ9o8VOGcb71JeiqDYrmAt8+tYqZR/kunfn51u9s8gO1waRiPVWML87J73Ysy hCguKjRqFg6aB1n5CAgvm58x8AtARzlZjJowiOyZhm4ySGxqE23KXzR1fbZAxFffc3pe oe1SQp1dZ8FB7mlhmxdsF1qQkKu+p/O5y+/RWuQxzdT6HhdqBMprLtQ/l217TQD990Cp Cu/zOz1kCp2735zXwb2nZ3EYcMikDqfh0tiwIVQ8RZM1woghL3BzQj6hTkIm3/wVyte2 mByGi0vCY4VxWDg6IOmCAQYUkRZ0QKuPXmSymcBYwdL/uH+BrF/t4KI6Z5z1KzFsJQMF hR+A== X-Gm-Message-State: AMCzsaWTtK9/PAsHPPClD7YXSylclNPH/1uN03te62NlfdBL7Bi/9Kw0 N+yOmKUjxbwEDGg9dskpGSbcw7fsv9G7wD/BF/6ang== X-Google-Smtp-Source: ABhQp+SplQz+XOO0d1KfkZNLR2XgMBen5af6SGpMgihd8CMiwhvkvU2CjCBehURWdmup1l+nLtQkoMgMuQMoXcX4mA4= X-Received: by 10.37.188.206 with SMTP id l14mr354952ybm.419.1508159792156; Mon, 16 Oct 2017 06:16:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 16 Oct 2017 06:15:51 -0700 (PDT) In-Reply-To: <0B2743C5-B702-4BCC-A499-FB0A62A74933@nokia.com> References: <0B2743C5-B702-4BCC-A499-FB0A62A74933@nokia.com> From: Eric Rescorla Date: Mon, 16 Oct 2017 06:15:51 -0700 Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: Matt Caswell , "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e08265a7cad339c055ba9d097" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 13:16:35 -0000 --089e08265a7cad339c055ba9d097 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 16, 2017 at 6:11 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > Hi Matt, > > On 13/10/2017, 14:15, "TLS on behalf of Matt Caswell" < > tls-bounces@ietf.org on behalf of frodo@baggins.org> wrote: > > Recently I met with Yin Xinxing and we have had much the same > > conversation about what a Connection ID draft would need to do, and > > how we could detect its use on the wire. Mechanisms we talked about > > included setting something in the "length" field, using ContentType or > > using version. IMO using "length" is just horrible. I'm also not keen > > on version - it further complicates the "is this version greater than, > > equal to, or less than this other version" question. It's already > > slightly complicated in code that implements both TLS and DTLS due to > > DTLS versions being high and decrementing for a new version. I foresee > > lots of subtle bugs and problems from reusing "version". In my mind > > ContentType is the way to go. > > Re: the length hack. I agree with you that it is not the right way to > go here. > > Re: CT vs version, a couple of quick thoughts: > - I'm still unconvinced that CT is the right place to signify a change > in the parsing logics that effectively spans all CTs; > - Besides, ISTM that version is the only field that would potentially > work for 1.3 as well as 1.2? > We expect to remove version in the 1.3 encrypted record format, -Ekr > > Cheers, > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e08265a7cad339c055ba9d097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 16, 2017 at 6:11 AM, Fossati, Thomas (Nokia - GB/Cambridge,= UK) <thomas.fossati@nokia.com> wrote:
Hi Matt,

On 13/10/2017, 14:15, "TLS on behalf of Matt Caswell" <tls-bounces@ietf.org on behalf of frodo@baggins.org> wrote:
> Recently I met with Yin Xinxing and we have had much the same
> conversation about what a Connection ID draft would need to do, and > how we could detect its use on the wire. Mechanisms we talked about > included setting something in the "length" field, using Cont= entType or
> using version. IMO using "length" is just horrible. I'm = also not keen
> on version - it further complicates the "is this version greater = than,
> equal to, or less than this other version" question. It's alr= eady
> slightly complicated in code that implements both TLS and DTLS due to<= br> > DTLS versions being high and decrementing for a new version. I foresee=
> lots of subtle bugs and problems from reusing "version". In = my mind
> ContentType is the way to go.

Re: the length hack.=C2=A0 I agree with you that it is not the right= way to
go here.

Re: CT vs version, a couple of quick thoughts:
- I'm still unconvinced that CT is the right place to signify a change<= br> =C2=A0 in the parsing logics that effectively spans all CTs;
- Besides, ISTM that version is the only field that would potentially
=C2=A0 work for 1.3 as well as 1.2?

We = expect to remove version in the 1.3 encrypted record format,

=
-Ekr
=C2=A0

Cheers,

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--089e08265a7cad339c055ba9d097-- From nobody Mon Oct 16 16:30:39 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5EC13202D for ; Mon, 16 Oct 2017 16:30:37 -0700 (PDT) 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 YQhKTKddfIsy for ; Mon, 16 Oct 2017 16:30:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE661270AE for ; Mon, 16 Oct 2017 16:30:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 96DFFBE64; Tue, 17 Oct 2017 00:30:35 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtHSX9FjiqxH; Tue, 17 Oct 2017 00:30:34 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 45657BE5C; Tue, 17 Oct 2017 00:30:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508196634; bh=cDHpGevv3olxK+IKfGzM1qg68EZRJLMfYU+RlfP8L5Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=wg9IOVsM3loedvauGXmC7rOzDHbdvu/FWH+L+8DFDj7ULApZLgdY2l9t1thJz0Ly9 zL8p+sV/YZio8P4NO6waet/vhxmn7qmNX+O5tW41oDR02qpjRIEVGjfioz/2Wa8osx JNI3G2KSHkhEvdAj6b0aB9aeTWqgiBYrxjBxfvBg= To: Hubert Kario Cc: tls@ietf.org References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> <2421126.h5uzTUJ9N8@pintsize.usersys.redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <4f47756b-3627-ff08-a7f6-8d6bd9e7fb5b@cs.tcd.ie> Date: Tue, 17 Oct 2017 00:30:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2421126.h5uzTUJ9N8@pintsize.usersys.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FI1QUTbgNjVNwmrc1RT01bf1mtWGaKFcc" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 23:30:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FI1QUTbgNjVNwmrc1RT01bf1mtWGaKFcc Content-Type: multipart/mixed; boundary="oIDXfx8ek7H429xxb6cWVsJjFsoguNRi0"; protected-headers="v1" From: Stephen Farrell To: Hubert Kario Cc: tls@ietf.org Message-ID: <4f47756b-3627-ff08-a7f6-8d6bd9e7fb5b@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> <2421126.h5uzTUJ9N8@pintsize.usersys.redhat.com> In-Reply-To: <2421126.h5uzTUJ9N8@pintsize.usersys.redhat.com> --oIDXfx8ek7H429xxb6cWVsJjFsoguNRi0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 13/10/17 17:28, Hubert Kario wrote: >> So I think this ends up as bad as the design in draft-rehired. Which >> of them is more obviously bad is another question. > "draft-rehired"? Apologies. That's how I've been verbalising/pronouncing draft-rhrd. (*) I think it is useful to have a name that can be pronounced, and I refuse to abuse language and talk about this as if "visibility" was even an approximately correct term;-) S. (*) I do have a weak justification:-) $ grep "^r.h.r.d" /usr/share/dict/words rehired $ --oIDXfx8ek7H429xxb6cWVsJjFsoguNRi0-- --FI1QUTbgNjVNwmrc1RT01bf1mtWGaKFcc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ5UEZAAoJEC88hzaAX42i2voIAK20dZ8UMEXFKNJRsbsaYBk+ k0BAyTAxadUlOhlAi6I/EtLx0KMrmiDmMHQR1j+Tk/r3Ug2wq4pH3CmXh1O2TAOu 9e9eG5jtB0wTSTfdMwB3Vtcja2e+j1O+mTza18yqnWTqgvv1wT1RovytuB8NAjJL Hut6dUO2PnJJyBoqziAtL97lyiHvq0T7zf9MQ2+ieGAn3osvi2VCaQyyGocAA231 2QCqsOkPOcc7qihZP3XlxVHoda0eD08xd8eMXdBYoBtdSVgtuoCOH0P2mxsKAcpd N7aIzHV+xGaQrOqvqOQ1rZxC4fRFoT7trXsiR1WiSgUlaHJAZ5flrd1HGcrHs5M= =vqez -----END PGP SIGNATURE----- --FI1QUTbgNjVNwmrc1RT01bf1mtWGaKFcc-- From nobody Mon Oct 16 16:42:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6A61321D8 for ; Mon, 16 Oct 2017 16:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_bP9Hfe7h_y for ; Mon, 16 Oct 2017 16:42:26 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 57046132397 for ; Mon, 16 Oct 2017 16:42:26 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id j126so28197298oib.8 for ; Mon, 16 Oct 2017 16:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6dj53Ax+i516RFxfPNJe2KQDY+TQI/T56sp8b2EXzYQ=; b=nviT6NIDhkKReJ0FZFlm2dkAgtqIL7HfAYkh3Wh30ZjL7TTbHosjBUT+90cczfUKox SI2CppKk9jxB0pDBy/W575R9Dz2obCJKzjLrKyaYaCWhW0qDaZgHDiMar4cS3W4E/7Kx SdsH2yrx++DfFqR7i/rJ0DbCV/MeguDFAHbzsd5Srxk+35P5zY+lF+cdsNhi7HniqBTv 0kAvo8EKag5NBOnsysU45AF2TFMFF2k/eg51LS8c2tXT1/rVt2peV42yqDdbmlOgW+iz OGk74iSgw89xVQ9IO/Vt1/M2tqLu/RAcdpRIFUeY0FKEgGl03EpRv7f2s6QhsPZwtCI4 +0bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6dj53Ax+i516RFxfPNJe2KQDY+TQI/T56sp8b2EXzYQ=; b=SsJvV0ggbBdzP8E0povZJJjfYG9ub858P6w5B+JszPGztPJ1UGUt0cLOLQA/2EIRYs NbGV+d1DlBbn5NqgAMmEb1qHDNgTW0NCz3u4Jltjyo/sTETtzAqfVG6jlWkfBujcNyO4 TxnqytR/nYV9DLf4rdtgASGBx04b0+cnFPRlyqkufRYU4xHYDdoS9v/MX+GpUoAMvqYP 9V+M9zArr4H2j0crJl0xQQhUvQjRe9S0LbIqfl9x1QAyHGLkhkz1Dw0ZZSdGjglc5PDn 3quBp6c+yJlnoVEScfdAGpf8yt5rRNOcrD49bfgp4EG+570cgHaAU21np9arJd1XYsCL TpVw== X-Gm-Message-State: AMCzsaX6HZ+J/v1R5/FQMyKoNRHXLeFML/nWFP5J4B+N8mkEcIhARwZ7 qeoHKs02BFcjVP1b48Vhm9j1EC/23KxXh0ZSjZc= X-Google-Smtp-Source: ABhQp+S1ofJ7E+SdpuZ4E5Y5JwseNSzbijl7Yhfk2S7Ub8I0/BKgxRLEtd8PxMjMnjhl1QmZ/Gtp8Xq2zCoTaXdd/ls= X-Received: by 10.157.87.75 with SMTP id x11mr1362853oti.112.1508197345507; Mon, 16 Oct 2017 16:42:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 16 Oct 2017 16:42:24 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 17 Oct 2017 10:42:24 +1100 Message-ID: To: Eric Rescorla , "Fossati, Thomas (Nokia - GB)" Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 23:42:29 -0000 Going back to the start, it seems like there is an implied problem with the draft in that connections with the identifier are hard to distinguish from connections without. Is that the main problem? I can't see how an explicit marking helps. If we admit the possibility that some connections will not support this new feature, then the recipient of packets is forced to identify those connections by 5-tuple. That's invariant. Mixed deployments have some challenges, but it's not completely unworkable. My conclusion is that peers without connection ID support monopolize the 5-tuple that they use, so that other connections can't migrate to that 5-tuple. They also cannot migrate to another 5-tuple. Otherwise, things work out. To reach that point, you have to realize that a mixed deployment has to use 5-tuple as a primary key. Packets that come in on a new 5-tuple are matched to connections opportunistically on what might or might not be a connection ID. If it is, then great (better make sure you ask for the same length ID from all peers, or match on prefixes...). If it isn't, then the ciphertext will be read as a connection ID, but even if it does identify a connection it will fail to decrypt. Thomas mentioned a heuristic, but I don't think that we need that. The only case that is difficult, and it's one that you might not care about, is one where a connection migrates to the same 5-tuple as an another connection. There, you will match to an existing connection and find that the packet doesn't decrypt. If the connection that you have associated with the 5-tuple supports and uses a connection ID, you can recover without trial decryption. Otherwise, you just have to drop the packet when it doesn't decrypt. (You could look up all the connections without connection IDs and use trial decryption, but why bother spending the effort and undermine the strength of your ciphers in that way.) You can only truly dispense with the 5-tuple mapping if you can guarantee that all of your clients support connection ID; at which point you can drop that table and route on connection ID alone. Packet inspection boxes will have maintain state, I don't see a way around that. The point here being that you need state to know how long the connection ID is, as well as how long it is. The middlebox issue is somewhat more interesting. If it is *your* middlebox, then there might be a case for routing connections with a connection ID differently. Based on the above, I would have said that it might be better to only deploy that sort of configuration when you can insist on receiving a connection ID. An explicit marking helps, but the cost is pretty high if we care about saving bits. My suggestion for the middlebox is to use a longer connection ID and include a MAC inside the connection ID. It ends up being a longer connection ID than the one QUIC uses, but it would allow the stateless routing middlebox to identify packets with and without a connection ID without any explicit marking. That doesn't require any change to the design. On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla wrote: > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > Comments welcome. > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Oct 16 19:54:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F82713304A for ; Mon, 16 Oct 2017 19:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMvTvDxid0Kx for ; Mon, 16 Oct 2017 19:54:40 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C75132949 for ; Mon, 16 Oct 2017 19:54:39 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e4I1d-0004RL-8n for tls@ietf.org; Tue, 17 Oct 2017 04:54:37 +0200 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1e4I1X-0004Ym-S2 for tls@ietf.org; Mon, 16 Oct 2017 22:54:35 -0400 Received: (qmail 8116 invoked from network); 17 Oct 2017 02:54:30 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.187]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Oct 2017 02:54:30 -0000 To: Eric Rescorla , Stephen Farrell Cc: "tls@ietf.org" References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> From: Christian Huitema Message-ID: <1deda3f5-870f-7bfa-4acb-389d7ab46be0@huitema.net> Date: Mon, 16 Oct 2017 19:54:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------98F42EE374D0D39A326BA850" Content-Language: en-US X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.32) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5k+Zo4f92G7xuSTs6mBJD8sXv9krsgRhBn0ayn6qsUc7RO6saVKtiei5 uUZjs8uJrOfHzJ6mVE7ewsipSVIfs4ZOxLzzMqsj18EIE7iDUvYlLB67TLnlh9i6Dr2tTQ7u+vvY qRKjl4d7q5m2gyZzYYWZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA/itEW1aHIJYDvx6uGLOm1Bi99Or0uXh6FskGQ3mtr4LUU/Qweyn+lg7TbDa2rNOWNaHCnN rMSSA7xor9tnUlOY8pSJo/Vkdr+FbBdda40x5B/NGyVcjXsZLVHUb2pmaEmDh4PRiBbRliPgaurB TRjstfheF24EjrGuHVHIMu1lYZhMr2sR3cQs/oU/axm99b2jdwip2wrbEvxHA2swIjN6PhFSfsse t38tyDP81cDf6vvg7iEFLP+SSY+Av5+AiC5mpw6R6T6fxWZ9NABSr2NGXbs4x/QizkoGwYIF2vLk MP/BJIXWfDOHfh6sRd9UMgGBQ5eKj6MUa9KfPAvxvWyWT4RXC/v261lNS3iZqUf5OA4U9Xw5Uo2K LQdKsYidsA0RFZ4oobg8BBg3Jq+ntzj03+ntCUYBCPpj1kdMCef1cQQQ/nsetUhuYMuf7MD+XoqO mNfYeZV2hhJL8IbQ/hmZFWaxSGfJU6M2WecjfLQquYool8X0+BvzGRRfxR+ffygb+fXMHzh3GvdL obcVeVRtcYBRSAmgD/ruOCD7mIOayLGEL8Yk8iee0Qz/7JNkz28DO2rOsK3hNn/Au26Nj+2lUGlP 9nCUO1/T3hbtM3dprmUVrBsPGnNiJ83AD/4JscDdpjPAXF36ccukK2jUdhJTBUmsltvK9h2NrJzJ uG6g9+lNC4wc2LkM7XQE4YLVklOcIA9nWuJMoxLUn/yzif+v X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 02:54:42 -0000 This is a multi-part message in MIME format. --------------98F42EE374D0D39A326BA850 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/13/2017 7:29 AM, Eric Rescorla wrote: > > > On Fri, Oct 13, 2017 at 7:16 AM, Stephen Farrell > > wrote: > > > Hiya, > > On 13/10/17 14:56, Eric Rescorla wrote: > > I've seen a number of designs like these, but in general they > > have quite poor scaling properties. Can you describe the precise > > design you have in mind so that we can analyze it. > > Sure, I can try... > > What I'm suggesting is that we define a way that a TLS > node can change the connection ID to a new value that > is hard to link to the old, as a function that can be > used when the implementation chooses to use it. > ... > To change an id, pick a value foo that depends on the TLS > session, e.g. like an extractor, and that is not visible > to the network. Then set next-id to H(foo||prev-id) or > some similar construct. > The problem with these encrypted or hashed schemes is the scaling part. When you receive a packet from a yet-uncategorized 5-tuple, you have to find the context. It can be "any of the contexts currently establish", so you end up having to try them all, or maybe 1/2 of them in average. That can be a lot of hashes or encryptions. If the sender can only send some token that the recipient already expects, the demuxing becomes much simpler. I=C2=A0 like EKR's design. But it is a scheme that can be implemented, an= d will work. There are edge cases, like controlling how many connection ID a peer is willing to provide in advance.=C2=A0 And it tends to fall in th= e "sharp knife" category of tools, i.e., you have better understand what you are doing. In particular, you need a strategy for breaking the linkability of sequence numbers, otherwise connection-id changes will not accomplish much. But there may well be other issues, like time correlation, or traffic patterns. By the way, the often considered scenario is "what happens if the NAT rebinds and the client does not know." I think a simple heuristic of changing the connection ID when coming out of long sleeps would help a lot there. NAT=C2=A0 bindings don't change much if the traffic is sustain= ed. But if the last packet was many seconds ago, the client would be wise to just rotate the connection ID before sending anything new. The other often considered scenarios are variations of the "mobile network". The NAT rebinds because the mobile router moved to a new connection, but the client does not know. I can't think of a good heuristic there, but it certainly would be helpful if the mobile router somehow informed the clients. That's probably easier to engineer than changing connection ID on every packet. --=20 Christian Huitema --------------98F42EE374D0D39A326BA850 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 10/13/2017 7:29 AM, Eric Rescorla wrote:


On Fri, Oct 13, 2017 at 7:16 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 13/10/17 14:56, Eric Rescorla wrote:
> I've seen a number of designs like these, but in general they
> have quite poor scaling properties. Can you describe the precise
> design you have in mind so that we can analyze it.

Sure, I can try...

What I'm suggesting is that we define a way that a TLS
node can change the connection ID to a new value that
is hard to link to the old, as a function that can be
used when the implementation chooses to use it.
...
To change an id, pick a value foo that depends on the TLS
session, e.g. like an extractor, and that is not visible
to the network. Then set next-id to H(foo||prev-id) or
some similar construct.

The problem with these encrypted or hashed schemes is the scaling part. When you receive a packet from a yet-uncategorized 5-tuple, you have to find the context. It can be "any of the contexts currently establish", so you end up having to try them all, or maybe 1/2 of them in average. That can be a lot of hashes or encryptions. If the sender can only send some token that the recipient already expects, the demuxing becomes much simpler.

I  like EKR's design. But it is a scheme that can be implemented, and will work. There are edge cases, like controlling how many connection ID a peer is willing to provide in advance.  And it tends to fall in the "sharp knife" category of tools, i.e., you have better understand what you are doing. In particular, you need a strategy for breaking the linkability of sequence numbers, otherwise connection-id changes will not accomplish much. But there may well be other issues, like time correlation, or traffic patterns.

By the way, the often considered scenario is "what happens if the NAT rebinds and the client does not know." I think a simple heuristic of changing the connection ID when coming out of long sleeps would help a lot there. NAT  bindings don't change much if the traffic is sustained. But if the last packet was many seconds ago, the client would be wise to just rotate the connection ID before sending anything new.

The other often considered scenarios are variations of the "mobile network". The NAT rebinds because the mobile router moved to a new connection, but the client does not know. I can't think of a good heuristic there, but it certainly would be helpful if the mobile router somehow informed the clients. That's probably easier to engineer than changing connection ID on every packet.

-- 
Christian Huitema
--------------98F42EE374D0D39A326BA850-- From nobody Tue Oct 17 03:26:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF341330C1 for ; Tue, 17 Oct 2017 03:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 2k9acCttN-wp for ; Tue, 17 Oct 2017 03:26:10 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00096.outbound.protection.outlook.com [40.107.0.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F897126BF0 for ; Tue, 17 Oct 2017 03:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=o8f4c88984S9fF0M485Cd/U80GWGEAP9DZGmWn5pUTg=; b=C8GV+6EYyM2Tip/cRf00qiOLBwmqFndmxU1gK4Ih0ZGOZnwVdcU8fKfU4hlE9gLKaFbx99dtHoS2Gb8B2e7LXsENAxelLt6QF3v6EEBbpgy8WM5fEKxOuZQMbz2fWSARyYE0PLVn5DGkQScY1Q0ChDh0RA/fEoiogLa5Wj7fEio= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1103.eurprd07.prod.outlook.com (10.163.168.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Tue, 17 Oct 2017 10:26:07 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0156.004; Tue, 17 Oct 2017 10:26:06 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Martin Thomson , Eric Rescorla CC: "tls@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AQHTQ6/ei1Eh6DPTUUK7WLQddJSSYqLnKXUAgADEnwA= Date: Tue, 17 Oct 2017 10:26:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1103; 6:hFZp1hLJDN70QRWvPjiJkeGI/TFGkSQHipHQaDhhORkK6JnEVq3wFYU00RlT++rHDXUfWoGCgZyd3yYQ+G/5x91QIv0UjsbMMaR8hYoQbtjOnCm+XvKBT3Jse69yUib62oDvgU/Z1m0ttVSOcCwMTCfgJa3Wv5DRRemRkNw21CZBUCcKqe1TBnSw7Zkr712NSfPfb+6EznLVoDzNO2KFC+Y50RVJvpFg8TW28yGrzxHIBU7Z66IQoQJGMhuzp5Eh/Mmrb1WC9n7cMsqP6jINcyZdUJWz5iOe4IDAT9oB//XmDHmPXrPHru/6Zw5yMnIKskH+jaCGnkr2XKsLPw5h8w==; 5:p0oQiEF1XY1xqCHT53m+fGc7kBaJjUu1wWZ+a1nImQR7iDCac8wk86GrbFIvkdMGqGOOGvJr1b6EbqLZBeR6Nz5mCtB5+Fhg5rY7JfiM5FOl0ewO91JxTjP2wZyZgIPKxLK9owoOgQb+rqWHolJ2pDgfBW6viXSK8RoIYecJh9A=; 24:CGbyeCtivukPyIe18+n0UqFw1bpXw7i/b0mjgPcY5N/zUuDTbbjmOZAt+5lQLiRVTr/3DkG8ab43/AItVZQX3l1CMQfbYJFY5Ci/oW6adls=; 7:MRp6HaQk7Wdfk/xuZk0RqvxQAhFDluaRezgaN3plZMYhnZWKXNo1SGa3+07iCg87egwyUKsWC5JxZ+lSknr0aIG2pCQZcsBXXkSvvGkB7O5698GksI3Su4SHx1Y/7ecwfXwE1Uu6en7JbhURyWy9jVKCy6vyGiU6cMaUatTKLcNU4nXO4jNIkjL4bzdRTsZfYn0XjsV96zQpj8/isj+8rlBkiZew8Ag/LL4BXBqfnKI= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(24454002)(2950100002)(7736002)(53936002)(4326008)(6116002)(305945005)(68736007)(102836003)(2900100001)(105586002)(106356001)(6512007)(66066001)(110136005)(99286003)(82746002)(316002)(36756003)(83716003)(58126008)(83506001)(54356999)(5250100002)(6436002)(8676002)(8936002)(76176999)(6506006)(81156014)(50986999)(53546010)(54906003)(39060400002)(86362001)(229853002)(2906002)(3660700001)(6486002)(5660300001)(6246003)(97736004)(3846002)(478600001)(3280700002)(189998001)(107886003)(25786009)(33656002)(101416001)(81166006)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1103; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: ebc5d5c3-bfcf-4ecd-c3d8-08d5154979ed x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1103; x-ms-traffictypediagnostic: VI1PR07MB1103: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1103; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1103; x-forefront-prvs: 04631F8F77 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9DAF4D0F7621F941975E18AF1856F3EB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 10:26:06.3808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1103 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 10:26:12 -0000 SGkgTWFydGluLA0KDQpPbiAxNy8xMC8yMDE3LCAwMDo0MiwgIk1hcnRpbiBUaG9tc29uIiA8bWFy dGluLnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCj4gVGhvbWFzIG1lbnRpb25lZCBhIGhldXJp c3RpYywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCB3ZSBuZWVkIHRoYXQuDQo+IFRoZSBvbmx5IGNh c2UgdGhhdCBpcyBkaWZmaWN1bHQsIGFuZCBpdCdzIG9uZSB0aGF0IHlvdSBtaWdodCBub3QgY2Fy ZQ0KPiBhYm91dCwgaXMgb25lIHdoZXJlIGEgY29ubmVjdGlvbiBtaWdyYXRlcyB0byB0aGUgc2Ft ZSA1LXR1cGxlIGFzIGFuDQo+IGFub3RoZXIgY29ubmVjdGlvbi4gIFRoZXJlLCB5b3Ugd2lsbCBt YXRjaCB0byBhbiBleGlzdGluZyBjb25uZWN0aW9uDQo+IGFuZCBmaW5kIHRoYXQgdGhlIHBhY2tl dCBkb2Vzbid0IGRlY3J5cHQuICBJZiB0aGUgY29ubmVjdGlvbiB0aGF0IHlvdQ0KPiBoYXZlIGFz c29jaWF0ZWQgd2l0aCB0aGUgNS10dXBsZSBzdXBwb3J0cyBhbmQgdXNlcyBhIGNvbm5lY3Rpb24g SUQsDQo+IHlvdSBjYW4gcmVjb3ZlciB3aXRob3V0IHRyaWFsIGRlY3J5cHRpb24uICBPdGhlcndp c2UsIHlvdSBqdXN0IGhhdmUgdG8NCj4gZHJvcCB0aGUgcGFja2V0IHdoZW4gaXQgZG9lc24ndCBk ZWNyeXB0LiAgKFlvdSBjb3VsZCBsb29rIHVwIGFsbCB0aGUNCj4gY29ubmVjdGlvbnMgd2l0aG91 dCBjb25uZWN0aW9uIElEcyBhbmQgdXNlIHRyaWFsIGRlY3J5cHRpb24sIGJ1dCB3aHkNCj4gYm90 aGVyIHNwZW5kaW5nIHRoZSBlZmZvcnQgYW5kIHVuZGVybWluZSB0aGUgc3RyZW5ndGggb2YgeW91 ciBjaXBoZXJzDQo+IGluIHRoYXQgd2F5LikNCg0KVGhlIGZvbGxvd2luZyBjYXNlIChOQVQgYm94 IHJlYm9vdCkgaXMgcHJvYmxlbWF0aWM6DQoNCjEuIEFwcGxpY2F0aW9uICcxJyBvbiBob3N0IEEg KEEuMSkgdXNlcyBEVExTK0NJRCB3aXRoIGFwcGxpY2F0aW9uICcxJyBvbg0KICAgaG9zdCBCIChC LjEpOw0KMi4gQXBwbGljYXRpb24gJzInIG9uIGhvc3QgQSAoQS4yKSB1c2VzIHBsYWluLW9sZCBE VExTIHdpdGggQi4xOw0KMy4gVGhlIE5BVCBib3ggcmVib290cyAoYWxsIHByZXZpb3VzIDUtdHVw bGUgbWFwcGluZ3MgYXJlIGxvc3QpOw0KNC4gQi4xIHJlY2VpdmVzIGEgcmVjb3JkIGZyb20gQS4x ICh3aG9zZSA1LXR1cGxlIGhhcyBjaGFuZ2VkIGluIHRoZQ0KICAgbWVhbndoaWxlKTsNCiANCkhv dyBpcyBCLjEgc3VwcG9zZWQgdG8gY29ycmVjdGx5IGludGVycHJldCB0aGUgYnl0ZXMgc3RhcnRp bmcgYXQgb2Zmc2V0DQorMTE/ICAoRm9yIHdoYXQgaXQga25vd3MsIGl0IGNvdWxkIGJlIENJRCBm cm9tIEEuMSBvciB0aGUgbGVuZ3RoIGZpZWxkDQpmcm9tIEEuMi4pDQogDQpUaGF0J3Mgd2hlcmUg dGhlIGhldXJpc3RpYyBJIG1lbnRpb25lZCBpbiB0aGUgb3RoZXIgZW1haWwgY29tZXMgaW4sDQpJ IHRoaW5rLg0KDQo+IFBhY2tldCBpbnNwZWN0aW9uIGJveGVzIHdpbGwgaGF2ZSBtYWludGFpbiBz dGF0ZSwgSSBkb24ndCBzZWUgYSB3YXkNCj4gYXJvdW5kIHRoYXQuICBUaGUgcG9pbnQgaGVyZSBi ZWluZyB0aGF0IHlvdSBuZWVkIHN0YXRlIHRvIGtub3cgaG93DQo+IGxvbmcgdGhlIGNvbm5lY3Rp b24gSUQgaXMsIGFzIHdlbGwgYXMgaG93IGxvbmcgaXQgaXMuDQoNCkkgbWlnaHQgYmUgbWlzc2lu ZyBzb21ldGhpbmcgZnVuZGFtZW50YWwgaGVyZSwgYnV0IGlzbid0IHRoZSBsZW5ndGgNCmVuY29k ZWQgaW4gdGhlIENJRCBmaWVsZCBvbiB0aGUgd2lyZT8NCg0KQ2hlZXJzDQoNCg== From nobody Tue Oct 17 05:53:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68F7132FB1 for ; Tue, 17 Oct 2017 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_Tsp3cxC8zE for ; Tue, 17 Oct 2017 05:53:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DDA134184 for ; Tue, 17 Oct 2017 05:53:17 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AFA4465DA3; Tue, 17 Oct 2017 12:53:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AFA4465DA3 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer@redhat.com Received: from oldenburg.str.redhat.com (ovpn-117-7.ams2.redhat.com [10.36.117.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9DE3977677; Tue, 17 Oct 2017 12:53:15 +0000 (UTC) To: Stephen Farrell , Hubert Kario Cc: tls@ietf.org References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> From: Florian Weimer Message-ID: Date: Tue, 17 Oct 2017 14:53:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 17 Oct 2017 12:53:17 +0000 (UTC) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 12:53:19 -0000 On 10/13/2017 02:45 PM, Stephen Farrell wrote: > So the problems with that are numerous but include: > > - there can be >1 carol, (and maybe all the carols also need to > "approve" of one another), if we were crazy enough to try do > this we'd have at least: > - corporate outbound snooper > - data-centre snooper (if you buy those supposed use-cases) > - government snooper(s) in places where they don't care about > doing that openly > ...port 80 would suddenly be quicker than 443 again;-( And any authorized eavesdropper is not allowed to be able to infer if they are the only ones listening in. I don't understand why this complicated approach is needed. Why can't the server provide an OOB interface to look up sessions keys, or maybe export them proactively? The proposed draft needs a protocol like this anyway because SSWrapDH1 keys need to be distributed, and periodic key regeneration is needed because it is the only way to implement revocation of access privileges without revealing the existence of other authorized parties. I don't buy the argument that there are too many session keys for proactive export. Obviously, you already have sufficient capacity to send these keys (or an equivalent) over the wire once, so sending another copy or two shouldn't be a problem. Thanks, Florian From nobody Tue Oct 17 08:46:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D614913303F for ; Tue, 17 Oct 2017 08:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHhOaSrc8Azw for ; Tue, 17 Oct 2017 08:46:19 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76500133032 for ; Tue, 17 Oct 2017 08:46:18 -0700 (PDT) From: Ion Larranaga Azcue To: Florian Weimer , Stephen Farrell , Hubert Kario CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO72INxjGwk0f70e0hZ2DWWm8J6Lb99iAgAM9PuCAAPX8AIAABTcAgAFt2gCAABvygIAGS3YAgAA4PXA= Date: Tue, 17 Oct 2017 15:46:15 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> In-Reply-To: Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 15:46:22 -0000 > I don't understand why this complicated approach is needed. Why can't th= e server provide an OOB=20 > interface to look up sessions keys, or maybe export them proactively? Th= e proposed draft needs a=20 > protocol like this anyway because SSWrapDH1 keys need to be distributed, = and periodic key=20 > regeneration is needed because it is the only way to implement revocation= of access privileges=20 > without revealing the existence of other authorized parties. In my opinion, the proposed draft does not define a protocol because it exp= ects that SSWrapDH1 keys will be distributed manually (I may be wrong with = this, but that's what I understood as the draft does not specify any key ex= change protocol between server and third-party). That's why I think that SS= WrapDH1 keys will be very long-lived (administrators will hate having to ma= nually distribute the new key in an hourly or even daily schedule), jeopard= izing perfect forward secrecy for a long time. The problem I see with a "server to third party" OOB look up or export of t= he keys is that the client will not be notified of this export taking place= and so will lose the chance to reject surveillance... From nobody Tue Oct 17 09:29:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647E313303A for ; Tue, 17 Oct 2017 09:29:26 -0700 (PDT) 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 0Uoo-dW47b3w for ; Tue, 17 Oct 2017 09:29:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A61126BF0 for ; Tue, 17 Oct 2017 09:29:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A375DBE3E; Tue, 17 Oct 2017 17:29:22 +0100 (IST) 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 mWEi8OeIwZGZ; Tue, 17 Oct 2017 17:29:22 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F50FBE38; Tue, 17 Oct 2017 17:29:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508257762; bh=5VLOAMIFiFwXAyCyf0528RG4zj0b/gcG6NWPxBjCMNo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jdJyXyqPs8t6XOnKmHEkNZpABw2+VxKZ0I9acskpxteTUCvdDVNWSeV/N9FN+FO7M hwNpmrovy2+fl0pAhGLQxXM8WrEpA/HYRV6NUiC6dWF+6vSautPBcd5ylKkRRKg408 mNWVGFxade1I5vQy3oFQ8dKZizoKBQrzv9H1Q6Fc= To: Ion Larranaga Azcue , Florian Weimer , Hubert Kario Cc: "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <7fb19d55-1d51-aa95-5ba5-d383be6c7c47@cs.tcd.ie> Date: Tue, 17 Oct 2017 17:29:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WmTtI3o7MwiewcOGvwM5wpH1Qs3tDouW9" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:29:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WmTtI3o7MwiewcOGvwM5wpH1Qs3tDouW9 Content-Type: multipart/mixed; boundary="0FFwPJXM0QbhH03alvAvG3SK65v323o75"; protected-headers="v1" From: Stephen Farrell To: Ion Larranaga Azcue , Florian Weimer , Hubert Kario Cc: "tls@ietf.org" Message-ID: <7fb19d55-1d51-aa95-5ba5-d383be6c7c47@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> In-Reply-To: --0FFwPJXM0QbhH03alvAvG3SK65v323o75 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17/10/17 16:46, Ion Larranaga Azcue wrote: > The problem I see with a "server to third party" OOB look up or > export of the keys is that the client will not be notified of this > export taking place and so will lose the chance to reject > surveillance... IIUC, with the draft-rehired proposal, the client can in any case not be told - the TLS protocol extensions are mere politeness and the client does not get to know what snooper(s) are involved, nor can the client influence the snooping keys. Once, any infrastructure for this was deployed, I think it'd be used without telling clients for sure. (And we would be fully complicit in helping that happen, if the WG adopted this stuff, because we know that such abuses would be inevitable.) I think this WG was correct years ago when we passed on the DNT proposal which had the same "just politeness" aspect - the web is not really such a friendly place that one can depend on the kindness of strangers. Nor are many of the many other applications using TLS. S. --0FFwPJXM0QbhH03alvAvG3SK65v323o75-- --WmTtI3o7MwiewcOGvwM5wpH1Qs3tDouW9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ5i/gAAoJEC88hzaAX42iy38H/1nsko82LnmEPL48fnXvjvoG 64S8zHZhfqRA6Vv7faHf8cV/XtwGwt5GSY3JQTggWmQLYhtYa6vpWf5P4l6T+IUL 88fpWsUAI82+YCNewR0Pt1dC0VClFaD3sK2dIjuk1ISt98x3mB9GBtKNA8WiVEEc eBNOJFAziANDj9cpXOO9jwXiCbCSJiVvPVqv69BEX91YVBll/zI+DuWx42ZrZ0gK weWZugzLteSmy5MeK6XtWNonPbENagzq4wU819Sw+kR6vWzTp+vM+14+siMNSI12 dszlA27DbNbTGUvJTw87qhQT3mqjWfy8Im4+wLKtdfJXshZpXEyrGOeruwD7siY= =TOvJ -----END PGP SIGNATURE----- --WmTtI3o7MwiewcOGvwM5wpH1Qs3tDouW9-- From nobody Tue Oct 17 11:34:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E7A1323F7 for ; Tue, 17 Oct 2017 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIzsDjfJnDcI for ; Tue, 17 Oct 2017 11:34:37 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE51126B6E for ; Tue, 17 Oct 2017 11:34:35 -0700 (PDT) From: Ion Larranaga Azcue To: Stephen Farrell , Florian Weimer , Hubert Kario CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO72INxjGwk0f70e0hZ2DWWm8J6Lb99iAgAM9PuCAAPX8AIAABTcAgAFt2gCAABvygIAGS3YAgAA4PXCAAAQkAIAAMCDB Date: Tue, 17 Oct 2017 18:34:32 +0000 Message-ID: <1508265272860.41983@s21sec.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> , <7fb19d55-1d51-aa95-5ba5-d383be6c7c47@cs.tcd.ie> In-Reply-To: <7fb19d55-1d51-aa95-5ba5-d383be6c7c47@cs.tcd.ie> Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 18:34:41 -0000 > IIUC, with the draft-rehired proposal, the client=0A= > can in any case not be told - the TLS protocol=0A= > extensions are mere politeness and the client does=0A= > not get to know what snooper(s) are involved, nor=0A= > can the client influence the snooping keys. Once,=0A= > any infrastructure for this was deployed, I think=0A= > it'd be used without telling clients for sure. (And=0A= > we would be fully complicit in helping that happen,=0A= > if the WG adopted this stuff, because we know that=0A= > such abuses would be inevitable.)=0A= =0A= Not really. The draft relies on the server sending a non-encrypted extensio= n containing critical information (the session keys encrypted using a share= d key between server and third party). The third party is expected to inter= cept this non-encrypted extension and decrypt it using Ke in order to obtai= n the session keys. Without this information the third party is unable to f= ully decrypt the TLS connection. =0A= =0A= If the extension is not sent, the client does not realize there is a third = party, but the third party does not have the session keys either, and the s= erver has to provide them in a different way (for instance, using an OOB lo= okup as Florian suggested). In any case, it's not the same scenario as the = draft proposes (the keys are shared in a different way) and can happen with= or without this draft being accepted.=0A= From nobody Tue Oct 17 11:39:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEF71323F7 for ; Tue, 17 Oct 2017 11:39:01 -0700 (PDT) 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 GODIXCDI78cr for ; Tue, 17 Oct 2017 11:39:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08549126B6E for ; Tue, 17 Oct 2017 11:38:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C3045BE38; Tue, 17 Oct 2017 19:38:57 +0100 (IST) 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 SqXfUWviNBUR; Tue, 17 Oct 2017 19:38:57 +0100 (IST) Received: from [134.226.62.25] (cswireless-25.scss.tcd.ie [134.226.62.25]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A4A9BDF9; Tue, 17 Oct 2017 19:38:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508265537; bh=bMPm52LiiO2Oonkej8Idi7hcBxkEvWLFAJH9WJQsecI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=4Opqiwp19jQRx7BJar0uxptmSUcfDMMccZHNixEGlUlsKOax/QQm1kQ8cscyz4QCQ 5iMfvbIEjvaYfyp7nX8RuheW1zoRQWdN53P1KVLrIXD5cATEe+BxIWHHVr9g6diqUp BVrkIyXaT0N5AYeV5cnbmG9VKmkaXcA4Dkub+3NU= To: Ion Larranaga Azcue , Florian Weimer , Hubert Kario Cc: "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> <7fb19d55-1d51-aa95-5ba5-d383be6c7c47@cs.tcd.ie> <1508265272860.41983@s21sec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <75f64d63-12c1-a5b3-ea4d-8a612e86d371@cs.tcd.ie> Date: Tue, 17 Oct 2017 19:38:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1508265272860.41983@s21sec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R2aUdNFcJ6J48aTWw4RJsLnLQD1p00vKH" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 18:39:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R2aUdNFcJ6J48aTWw4RJsLnLQD1p00vKH Content-Type: multipart/mixed; boundary="7pgiHArTkmSCrQelHmpfnFaW9m4Iprebn"; protected-headers="v1" From: Stephen Farrell To: Ion Larranaga Azcue , Florian Weimer , Hubert Kario Cc: "tls@ietf.org" Message-ID: <75f64d63-12c1-a5b3-ea4d-8a612e86d371@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> <7fb19d55-1d51-aa95-5ba5-d383be6c7c47@cs.tcd.ie> <1508265272860.41983@s21sec.com> In-Reply-To: <1508265272860.41983@s21sec.com> --7pgiHArTkmSCrQelHmpfnFaW9m4Iprebn Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17/10/17 19:34, Ion Larranaga Azcue wrote: > If the extension is not sent, the client does not realize there is a > third party, but the third party does not have the session keys > either, and the server has to provide them in a different way (for > instance, using an OOB lookup as Florian suggested). In any case, > it's not the same scenario as the draft proposes (the keys are shared > in a different way) and can happen with or without this draft being > accepted. I agree. My point is that if this draft were accepted, then the infrastructure for the above scenario would all be in place (the DH value for the snooper and the code to expose session information to that snooper) and the above scenario would be more likely to happen, more often. IOW, by standardising draft-rehired, we'd *also* be putting in place standard building blocks for an OOB, client is never told mechanism. S. --7pgiHArTkmSCrQelHmpfnFaW9m4Iprebn-- --R2aUdNFcJ6J48aTWw4RJsLnLQD1p00vKH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ5k4/AAoJEC88hzaAX42iJjsH/2+MEd5CKq3P/CmkFEBY5iZS 9H7ZxAIOliEkj1tSxW3JbRd7saOieR2T/LzlhLSA7D1VyqkuLLQMoxa/OoR4ny/s bZP5lEfD6bTS7QbxW6d8/7aCLMfrChMVLLFONsrFPcC7cRGvodj6BVyF733lagNQ NDOWk0D1HKvrcmOXyYjapj1uDHVMc3ajzM4xuOnGQh5IGd9Ar4SZLVKPXSoixAr1 cqrLyv1/p+rZKKvhIdbwDfPF3fWzFWLb+wvNKxLmyqUVfFyn0pp4YIsk5nNszzvQ hwBSrb3WvdFTXoaNaLE31T0qCtazfIM8VdSGOv9DJXKemdjwqSF8+i3yPoemCkk= =heyj -----END PGP SIGNATURE----- --R2aUdNFcJ6J48aTWw4RJsLnLQD1p00vKH-- From nobody Tue Oct 17 12:55:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C54F132705 for ; Tue, 17 Oct 2017 12:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8tDohAIo03n for ; Tue, 17 Oct 2017 12:55:28 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDDD13292A for ; Tue, 17 Oct 2017 12:55:27 -0700 (PDT) From: Ion Larranaga Azcue To: Stephen Farrell , Florian Weimer , Hubert Kario CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO72INxjGwk0f70e0hZ2DWWm8J6Lb99iAgAM9PuCAAPX8AIAABTcAgAFt2gCAABvygIAGS3YAgAA4PXCAAAQkAIAAMCDB///0FICAABKpwQ== Date: Tue, 17 Oct 2017 19:55:24 +0000 Message-ID: <1508270124069.56797@s21sec.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> <7fb19d55-1d51-aa95-5ba5-d383be6c7c47@cs.tcd.ie> <1508265272860.41983@s21sec.com>, <75f64d63-12c1-a5b3-ea4d-8a612e86d371@cs.tcd.ie> In-Reply-To: <75f64d63-12c1-a5b3-ea4d-8a612e86d371@cs.tcd.ie> Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 19:55:31 -0000 > I agree.=0A= > =0A= > My point is that if this draft were accepted, then the=0A= > infrastructure for the above scenario would all be in=0A= > place (the DH value for the snooper and the code to expose=0A= > session information to that snooper) and the above=0A= > scenario would be more likely to happen, more often.=0A= > IOW, by standardising draft-rehired, we'd *also* be=0A= > putting in place standard building blocks for an OOB,=0A= > client is never told mechanism.=0A= =0A= I don't see it that way... For me, using the capabilities provided by this = draft in order to get an OOB-only "no client involved" mechanism is more d= ifficult and probably less efficient than creating one from scratch...=0A= =0A= That being said... One thing that bothers me from my last emails is that I = seem to find myself on the draft-defending side of the discussion while I d= on't really like the draft itself due to the concerns I pointed out in my f= irst email... I'm not fully against adding monitoring capabilities to the p= rotocol, but I would prefer a "no-monitoring-allowed" TLS if the alternativ= e was going with an insecure tapping mechanism.=0A= =0A= From nobody Tue Oct 17 14:35:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD409132939 for ; Tue, 17 Oct 2017 14:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azIiOj1Ffjax for ; Tue, 17 Oct 2017 14:35:41 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1137613209C for ; Tue, 17 Oct 2017 14:35:41 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id c202so5597500oih.9 for ; Tue, 17 Oct 2017 14:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LZE+rSzmhwLGNjGiXEpG/ADdLJ+XcW7MT707M2LsypU=; b=GhtNwYAkLqZ470WaZSTjfkmwg8oXd/zM/1KR9HBscXipn7lXo9pz5ct0U+R8//or9k lBrWX2Vm4kb4vnyGDCXQIsaD/fFPhBBfCtSn1r+na42kuioGR0NGG+t7kiw8EwUNVVdq YQra4PGMj9cM3nwVpQ6SmpdAmRjbGXLuJul1KTbYxBsLTIg4vUGfzFyoMUtdYH7SAnes gqP0yQJKEY6yFMDYIiOnUbNeRfN/ywd04LOp3b/5skM8lPo85PWJCx24eFgjRpHNSXV5 Wfalgrs0/cTjs6Op/AHVy8XoW3l9DcVKXf+uU4FFBHDqnUIk5KtsU0h7pk9QR6PVH8cv UBKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LZE+rSzmhwLGNjGiXEpG/ADdLJ+XcW7MT707M2LsypU=; b=ibIDgDjN5DrDwKgNtqqQnU95KRhyTTPuAknVBPSNf+aN+2UvB7rxXrE+jrEQ/2tR8D Eq0AJJFFbuWn3OpdJAJ+qJQFQUPAROxJH/G4d2bRKVyKSfSL5y7h8pW/cdaield12FL1 hK5W8IOdqeOUTdkfA9jXojxt/GaDNgd/QE3jD6G5yAPn+exE1QkHQ1rbPCYq0LU2DZzy AhxoDgVXjqgvXvLXfyA+WOEZfzutMX7G2TfRldvgtY4isRJTbi2PDC9Cc/9u/RgzwaH/ izNLZ7IcLrXtMz41YpWRulXsBKl0LcgNtMaKRPwW6PWXoe8kZzrpeS5zqfNxlg+2SV36 Iv2A== X-Gm-Message-State: AMCzsaV+znhQkNrGnhiATc1vYVhUU/5HybvqtAb8WVXTiWHb/fLN3NRZ qIDBisv6GyLloTlqKGr0Rdtr0In6t0ZwgEJpIJs= X-Google-Smtp-Source: ABhQp+T4BxGpVA8qrW5Uksp0LWqABmRG3olM2xefAX7YSPKQdT1pjkDF43ljNeTa5qf+lDhflR2NdZY382K88hFiEDo= X-Received: by 10.202.67.135 with SMTP id q129mr7198392oia.390.1508276140367; Tue, 17 Oct 2017 14:35:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Tue, 17 Oct 2017 14:35:39 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 18 Oct 2017 08:35:39 +1100 Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: Eric Rescorla , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 21:35:44 -0000 On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > The following case (NAT box reboot) is problematic: > > 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on > host B (B.1); > 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; > 3. The NAT box reboots (all previous 5-tuple mappings are lost); > 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the > meanwhile); > > How is B.1 supposed to correctly interpret the bytes starting at offset > +11? (For what it knows, it could be CID from A.1 or the length field > from A.2.) I don't think that this is a problem. connection = five_tuples.lookup(packet.five_tuple) if (!connection) { connection = connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length]) } if (!connection) { // is this a ClientHello? otherwise drop it } Of course this doesn't help you with A.2, but that's why this draft exists. If the server can insist on connection IDs from all clients (in the far future perhaps, or for an entirely new protocol), then the code is more simply: connection = connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length]) if (!connection) { // is this a ClientHello? otherwise drop it } > I might be missing something fundamental here, but isn't the length > encoded in the CID field on the wire? Not by my understanding. There isn't any need (the intent is to have the CID only consumable by the entity that created it, and any others that it collaborates with, like a load balancer). From nobody Tue Oct 17 23:44:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A5A1320CF for ; Tue, 17 Oct 2017 23:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 3zYCeCs5ZKXC for ; Tue, 17 Oct 2017 23:43:57 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0090.outbound.protection.outlook.com [104.47.1.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 A6C2C132026 for ; Tue, 17 Oct 2017 23:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E+YIZtU3YZ2yleZcuduc7Bu4dtx5Lpk6e1af2/6Q/FU=; b=lvyJdRq+BRoGqTYZOrvmkKCGTcJItRQ/Py5gLJeNpLK4hYsjOHjA4PS9ntboSE7t3TVAWK+FLVMle/BGqSVPorT69SfJg4FmwPdOYOtj0a1K3YIjKKmtUpXMMBuxb/MHRkjzY+j++1PfSkwa0hI4OPpNfmgwVZy2YEAdZ0PZGG8= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1103.eurprd07.prod.outlook.com (10.163.168.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 18 Oct 2017 06:43:53 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0156.004; Wed, 18 Oct 2017 06:43:53 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Nikos Mavrogiannopoulos , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AQHTQ6/ei1Eh6DPTUUK7WLQddJSSYqLhT4aAgAfyyQA= Date: Wed, 18 Oct 2017 06:43:52 +0000 Message-ID: <12771800-934C-4542-9F26-2E07B2C8D684@nokia.com> References: <1507875665.3178.19.camel@redhat.com> In-Reply-To: <1507875665.3178.19.camel@redhat.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.109.173.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1103; 6:6/0IvKfigbFanrx163xjYnZyPHrb1TfTDEj8JbkZROcTv7U41/Hn8y+nM2egrbNBLCZpWIs3VUDYUmr9CkZjzMrdkna876F9kpBIiMkCnYONsvErX2wqzTgzJ3ct/vpPtfW7XGJKyYPT/149v83/Qny8BCnuVjt/zs67A6/7S75b1Nb217SZFDuiao2RG8DRkQcOLr0TGWMxj8JQ9vJGZLS9p/XRA29KoCLP34w80wOWBCS2gYLDuw2zwaOjIS0kT+c7pydeCh5C+SpS8hJ8BOgIvXaNFzaDx/zrGTnlTVGbf23yG1V9gpZu/4XL7Sc72pxTLCvSfBCYhrFYFAWQWA==; 5:Pbo50boyNFIHb1AxwNijHGKNOtccseiPMyDnKGGC91Rb5vJvwMBJYxWSaGsIq9l3gD/s2ciSF3RfX/IQHGF1D6G9Eoavhidr9e8kc4txMxzfKR811Jo40cvF3RLwuVcxygkQazZO1ZWl5pyBju3xpw==; 24:JZniTSas1A0FnQ+bL/CV5KzPUd/wEavxGmAZqie9F6xwWUKKtaEQZ0+xZdfe23BbuoF6LogGUcmj6cLlijSP3t9d3wf/IlOhij3Hoh7o3Xs=; 7:mRZ2TVc/X6V5EMXeMNkeQFd7pUve/4QM1afkQmPi7YRWrLTjjqMqs9fBxYuVNAlotfKaP7bkRZj2p/g05/XITWytuzjZ/O7vyj8QCkDQwnLbOtu3KA7etUkbLjlcbTlUSdPTJj2lrGs+HyS10iM8son7zpfXnR0kZtOT1DsxYIAveN53Ke0IId8LMg+ZghGxVIlPLtlL0JSZPsj8in+UTBhueai3bDgfUXiZabyO/3o= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(24454002)(50986999)(2950100002)(7736002)(53936002)(6116002)(4326008)(68736007)(102836003)(305945005)(105586002)(106356001)(2900100001)(66066001)(6512007)(316002)(83716003)(82746002)(99286003)(58126008)(83506001)(36756003)(110136005)(81156014)(54356999)(8936002)(8676002)(76176999)(229853002)(53546010)(6436002)(2906002)(3660700001)(6506006)(86362001)(5250100002)(6486002)(97736004)(5660300001)(6246003)(107886003)(478600001)(3280700002)(189998001)(3846002)(101416001)(25786009)(2501003)(33656002)(81166006)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1103; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 47d969c9-cc35-4367-28d3-08d515f398fe x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1103; x-ms-traffictypediagnostic: VI1PR07MB1103: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1103; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1103; x-forefront-prvs: 0464DBBBC4 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2017 06:43:52.9221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1103 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 06:43:59 -0000 SGkgTmlrb3MsDQoNCk9uIDEzLzEwLzIwMTcsIDA3OjIxLCAiVExTIG9uIGJlaGFsZiBvZiBOaWtv cyBNYXZyb2dpYW5ub3BvdWxvcyIgPHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBu bWF2QHJlZGhhdC5jb20+IHdyb3RlOg0KPiBBbm90aGVyIHdvcnJ5aW5nIGZlYXR1cmUgaXMgdGhh dCB0aGUgY2xpZW50IGNhbiBtYWtlIHRoZSBzZXJ2ZXIgc2VuZA0KPiB1cCB0byAyNTUgdmVyYmF0 aW0gYnl0ZXMgb24gdGhlIHdpcmUgb2YgaGlzIGNob2ljZS4gV2h5IHdhcyB0aGlzDQo+IGZlYXR1 cmUgYWRkZWQ/IEFyZSB0aGVyZSB1c2UgY2FzZXMgcmVsYXRlZCB3aXRoIGl0IChpbnRybyBkb2Vz bid0DQo+IG1lbnRpb24gYW55KSwgb3IgaXQgd2FzIG9ubHkgdGhvdWdodCBhcyBhIG1ha2UgaXQg YXMgZ2VuZXJpYyBhcw0KPiBwb3NzaWJsZSBhcHByb2FjaD8gSWYgaXQgaXMgdGhlIGxhdHRlciwg SSdkIHJlY29tbWVuZCB0byBwcm92aWRlIGENCj4gc2ltcGxlIGFwcHJvYWNoIHRoYXQgY292ZXJz IHRoZSBkZXNjcmliZWQgdXNlIGNhc2VzLg0KPiANCj4gVGhlIHNhbWUgYXJndW1lbnQgYXBwbGll cyB0byB0aGUgc2VydmVyIGJlaW5nIGFibGUgdG8gc2V0IHN1Y2ggYSBsb25nDQo+IHNlcXVlbmNl IG9mIHZlcmJhdGltIGJ5dGVzIHRvIGVhY2ggb2YgdGhlIGNsaWVudCBwYWNrZXRzLg0KDQpJJ2Qg bGlrZSB0byBnZXQgYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBvZiB5b3VyIGNvbmNlcm4gaGVyZS4N Cg0KSXMgaXQgc2l6ZT8NCg0KT3IgaXMgdGhhdCBpdCBjcmVhdGVzIGEgcG90ZW50aWFsIHN1Yi1j aGFubmVsIGZvciBzZW5kaW5nIGlkZW50aWZ5aW5nDQppbmZvcm1hdGlvbj8NCg0KSWYgdGhlIGxh dHRlciwgaXQgZG9lc24ndCBsb29rIG11Y2ggZGlmZmVyZW50IGZyb20gUmFuZG9tIChleGNlcHQg aXQncw0KbGFyZ2VyKT8gIEFuZCB0aGVuIGl0IGdldHMgaGFzaGVkIGluIHRoZSBmaW5pc2hlZCBt ZXNzYWdlLCBzbywgdGhlIHJvb20NCmZvciBhIHRoaXJkIHBhcnR5IHRvIGZpZGRsZSB3aXRoIGl0 IHNlZW1zIHJlYWxseSBsaW1pdGVkLg0KDQpFeGFjdGx5LCB3aGF0IHJpc2sgZG8geW91IGZvcmVz ZWU/DQoNCg== From nobody Tue Oct 17 23:44:14 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08424132D17 for ; Tue, 17 Oct 2017 23:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 i553iy6iR_rO for ; Tue, 17 Oct 2017 23:44:04 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30120.outbound.protection.outlook.com [40.107.3.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0CE132F2C for ; Tue, 17 Oct 2017 23:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tpXJDjTn8Ng4A1vlMjlWFQ/ufBTlzrl7Pb6FoQ54Ec4=; b=R7VmWdOcASZTINJ5A/s9urKlyB4H8pTSy44OoRtQp2i5BMGp2ctqBAbSbLN9h2N3UbLBvrcJ3GQvhYrQ1LQG70WqXDMZaUZHun+QIGamtDAnrMgosNcRJEaVhGGPEX1nJYJNpuU2Rw822t6Qg4yQtsA4OAaewmiXGyvLb44qLoI= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1103.eurprd07.prod.outlook.com (10.163.168.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 18 Oct 2017 06:44:01 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0156.004; Wed, 18 Oct 2017 06:44:00 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Martin Thomson CC: Eric Rescorla , "tls@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AQHTQ6/ei1Eh6DPTUUK7WLQddJSSYqLnKXUAgADEnwCAAKpMgIAAqfeA Date: Wed, 18 Oct 2017 06:44:00 +0000 Message-ID: <6F9A34A1-7F33-462D-96F6-92081256E83B@nokia.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.109.173.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1103; 6:W5oq7nPTYBiscnH4wl6/lIy6nGVgxlMCOA/aXYnKy8hiCf/eaNw5P+jc4FsNPBctAJmZ6b8LXS5NTmlupMnSv8pKJ6qzIyZEwhlqgfXsEXPtDO2ro/W1SievGym9WdfpmvBmRctE6QLUFrpTdilXtqE02tXwBNwXSEzhdHyc696GzkOFDeP/951nmzkpudvpRLCKgtzW03mRJh+cl5okV76AcQFFrbhmpzNMDY6hEO5K16KCQ3V7eemvXv3L22AFQNw4IbxSXqCUGFtWt0GNKrUWSTlDsDjP8uLMerRpjENjjp/KsnXESIZu0lLCiTf8zZRyNcAF/0GNrlgBJo8BnA==; 5:1f9klCQ6Nl19HIeellNVpEh9yWjMFXRu5/yyjefUovhpbYqGsgByLqJDk0Bh44Y3CIM4l2Rb8AJy0+kydShMtQo5Lv0c2w1F2/E6LdnFSep6ED77LZSOUu11MzwB0UMb8A8uuvjfq35Dq8GSKs9j7A==; 24:pi50gzcFI3rvrcZ9mOWbsorFM74W0O2KpQHzzWw1HOBw7aguCfjQWwIprk/0CrPkbgTy/QcscVzWbot8Qt4AT3nTdkdNiIElidkQG898GXM=; 7:XtTMcMtaw0duhLpXjVryvoZK/NbrsRdaR7ttqWOp/r/bVxXKOCqpShodh++zcF4yxnRSeEJFSnFaRCYW4ADKj7zPvKP+6wb/w1ASWILRJHMu1EWEdbStH7+HvGkbjYUghZ2W8VGTmY+7grnRNDVRzUyP5MSvyTgU8iXtWUbbAhwH5fMkuh6FgnCOW2bkYemSWQvw5RIunNiosNQt8gUdSM9xRGqB3xTlhaFob6JRZNw= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(24454002)(377454003)(50986999)(2950100002)(7736002)(53936002)(6116002)(4326008)(68736007)(102836003)(305945005)(105586002)(106356001)(2900100001)(66066001)(6512007)(6916009)(6306002)(316002)(83716003)(82746002)(99286003)(93886005)(58126008)(83506001)(36756003)(81156014)(54356999)(8936002)(8676002)(76176999)(229853002)(966005)(54906003)(53546010)(6436002)(2906002)(3660700001)(6506006)(86362001)(5250100002)(39060400002)(6486002)(97736004)(5660300001)(6246003)(107886003)(478600001)(3280700002)(189998001)(3846002)(101416001)(25786009)(33656002)(81166006)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1103; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 4a997d49-fce3-45c7-e775-08d515f39d7d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1103; x-ms-traffictypediagnostic: VI1PR07MB1103: x-exchange-antispam-report-test: UriScan:(82608151540597); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1103; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1103; x-forefront-prvs: 0464DBBBC4 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <10A2281F38968941A91554A84138FAA0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2017 06:44:00.4372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1103 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 06:44:06 -0000 T24gMTcvMTAvMjAxNywgMjI6MzUsICJNYXJ0aW4gVGhvbXNvbiIgPG1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT4gd3JvdGU6DQo+IE9uIFR1ZSwgT2N0IDE3LCAyMDE3IGF0IDk6MjYgUE0sIEZvc3Nh dGksIFRob21hcyAoTm9raWEgLQ0KPiBHQi9DYW1icmlkZ2UsIFVLKSA8dGhvbWFzLmZvc3NhdGlA bm9raWEuY29tPiB3cm90ZToNCj4gPiBUaGUgZm9sbG93aW5nIGNhc2UgKE5BVCBib3ggcmVib290 KSBpcyBwcm9ibGVtYXRpYzoNCj4gPg0KPiA+IDEuIEFwcGxpY2F0aW9uICcxJyBvbiBob3N0IEEg KEEuMSkgdXNlcyBEVExTK0NJRCB3aXRoIGFwcGxpY2F0aW9uDQo+ID4gICAgJzEnIG9uIGhvc3Qg QiAoQi4xKTsNCj4gPiAyLiBBcHBsaWNhdGlvbiAnMicgb24gaG9zdCBBIChBLjIpIHVzZXMgcGxh aW4tb2xkIERUTFMgd2l0aCBCLjE7DQo+ID4gMy4gVGhlIE5BVCBib3ggcmVib290cyAoYWxsIHBy ZXZpb3VzIDUtdHVwbGUgbWFwcGluZ3MgYXJlIGxvc3QpOw0KPiA+IDQuIEIuMSByZWNlaXZlcyBh IHJlY29yZCBmcm9tIEEuMSAod2hvc2UgNS10dXBsZSBoYXMgY2hhbmdlZCBpbiB0aGUNCj4gPiAg ICBtZWFud2hpbGUpOw0KPiA+DQo+ID4gSG93IGlzIEIuMSBzdXBwb3NlZCB0byBjb3JyZWN0bHkg aW50ZXJwcmV0IHRoZSBieXRlcyBzdGFydGluZyBhdA0KPiA+IG9mZnNldCArMTE/ICAoRm9yIHdo YXQgaXQga25vd3MsIGl0IGNvdWxkIGJlIENJRCBmcm9tIEEuMSBvciB0aGUNCj4gPiBsZW5ndGgg ZmllbGQgZnJvbSBBLjIuKQ0KPiANCj4gSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgYSBwcm9i bGVtLg0KPiANCj4gY29ubmVjdGlvbiA9IGZpdmVfdHVwbGVzLmxvb2t1cChwYWNrZXQuZml2ZV90 dXBsZSkNCj4gaWYgKCFjb25uZWN0aW9uKSB7DQo+ICAgY29ubmVjdGlvbiA9IGNvbm5lY3Rpb25f aWRzLmxvb2t1cChwYWNrZXRbY29ubmVjdGlvbl9pZF9vZmZzZXQ6Y29ubmVjdGlvbl9pZF9vZmZz ZXQrY29ubmVjdGlvbl9pZF9sZW5ndGhdKQ0KPiB9DQo+IGlmICghY29ubmVjdGlvbikgew0KPiAg IC8vIGlzIHRoaXMgYSBDbGllbnRIZWxsbz8gIG90aGVyd2lzZSBkcm9wIGl0DQo+IH0NCg0KVGhp cyBpcyBxdWl0ZSBzaW1pbGFyIHRvIHRoZSB0cmlhbCBhbmQgZXJyb3IgLyBoZXVyaXN0aWMgdGhh dCBJIHdhcw0KbWVudGlvbmluZyBpbiBbMV0uDQoNCk5vdGUgdGhhdCBpZiBBLjEgYW5kIEEuMidz IDUtdHVwbGVzIGFyZSBzd2FwcGVkLCB0aGUgYWxnb3JpdGhtIGZhaWxzIHRvDQpyZWNvZ25pc2Ug QS4xIGFzIENJRC1lbmFibGVkIGFuZCBzZW5kcyBpdCBmb3J3YXJkIHRvIHRoZSBjcnlwdG8gaGFu ZGxlcg0Kd2hlbiBpdCBzaG91bGRuJ3QuIA0KDQpJdCBsb29rcyBzaW1wbGUsIGJ1dCBpdCBpbnRy b2R1Y2VzIHN1YnRsZSBjb21wbGV4aXR5IGluIHRoYXQgcGFyc2luZyBpcw0Kbm90IHNlbGYtY29u dGFpbmVkIGFueW1vcmU6IGl0IGRlcGVuZHMgb24gYSBjb3VwbGUgb2YgdGhpbmdzICh0aGUNCmNv bm5lY3Rpb25faWRzIGFuZCBmaXZlX3R1cGxlcyBzdG9yZXMpIHRoYXQgaW4gcHJpbmNpcGxlIHNo b3VsZCBoYXZlDQpub3RoaW5nIHRvIGRvIHdpdGggbWFraW5nIHNlbnNlIG9mIGFuIGluY29taW5n IHJlY29yZC4NCg0KQW5kIHRoZSBhbHJlYWR5IGRpc2N1c3NlZCBsaW1pdGF0aW9uczoNCi0gRnJh Z2lsaXR5IG9uIGNvcm5lciBjYXNlcyAoZS5nLiwgdGhlIDUtdHVwbGUgc3dhcCBhYm92ZSk7DQot IEZvcmNpbmcgbWlkZGxld2FyZSB0byBrZWVwIHN0YXRlOw0KLSBCcmVha2luZyB3aXJlc2hhcmsg JiBjbyB1bmxlc3MgdGhleSBjYW4gc2VlIHRoZSB3aG9sZSBzZXNzaW9uOw0KLSAoRGVwZW5kaW5n IG9uIHRoZSB1c2UgY2FzZSwgdGhlIGNvc3Qgb2YgdGhlIHR3byBsb29rdXBzIHBlciByZWNvcmQN CiAgb24gdGhlIHBhcnNpbmcgbWlnaHQgaGF2ZSBhIHBlcmZvcm1hbmNlIGltcGFjdC4pDQoNCj4g PiBJIG1pZ2h0IGJlIG1pc3Npbmcgc29tZXRoaW5nIGZ1bmRhbWVudGFsIGhlcmUsIGJ1dCBpc24n dCB0aGUgbGVuZ3RoDQo+ID4gZW5jb2RlZCBpbiB0aGUgQ0lEIGZpZWxkIG9uIHRoZSB3aXJlPw0K PiANCj4gTm90IGJ5IG15IHVuZGVyc3RhbmRpbmcuICBUaGVyZSBpc24ndCBhbnkgbmVlZCAodGhl IGludGVudCBpcyB0byBoYXZlDQo+IHRoZSBDSUQgb25seSBjb25zdW1hYmxlIGJ5IHRoZSBlbnRp dHkgdGhhdCBjcmVhdGVkIGl0LCBhbmQgYW55IG90aGVycw0KPiB0aGF0IGl0IGNvbGxhYm9yYXRl cyB3aXRoLCBsaWtlIGEgbG9hZCBiYWxhbmNlcikuDQoNCllvdSBhcmUgcmlnaHQuICBGb3Igc29t ZSByZWFzb25zLCBJIHdhcyBpbXBseWluZyBjaWQgd2FzIGVuY29kZWQgYXMgYQ0KdmFyaWFibGUt bGVuZ3RoIGFycmF5LiAgVGhhdCBzYWlkLCBJIGRvbid0IHRoaW5rIHNhdmluZyAxIGJ5dGUgaGVy ZSBpcw0Kd29ydGggdGhlIHNlbGYtaW5mbGljdGVkIHBhaW4gb2YgbWFraW5nIHRzaGFyayB1bnVz YWJsZSA6LSkNCg0KQ2hlZXJzDQoNClsxXSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3Rscy9jdXJyZW50L21zZzI0NTc1Lmh0bWwNCg0K From nobody Wed Oct 18 01:08:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416451321AC for ; Wed, 18 Oct 2017 01:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qkg9qA0zp5W for ; Wed, 18 Oct 2017 01:08:26 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 49BEE13292F for ; Wed, 18 Oct 2017 01:08:26 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id g125so7483196oib.12 for ; Wed, 18 Oct 2017 01:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3ZUCPkWUL6pjk9euhQeUzteQwxTqmy3ucSe2ofnhvfU=; b=W3CL/mCn0IapUL4gjQQgWycTiVsgcvAOmrDJZ+KnQKppJnF+ihdjXQ6wqyBtngiLhC XtCRREwbTjUSsGe1n6osAvjkrmkwZzA1DJlkVmPqHawnlhhHos7HCMG6HWwGsXPUmFt5 5RvMK+YoONZpY4J4dcmW0JAAaQW9RPNs2WVRdHHx6V89XW9Vq4owhngqo/UAGyUJhWwX hSPUU1CtKnUn3tUhEnV4CAlzluai4goQ1b2i6uJQ5CnZnyd1qDC/Ve0x6NKeuMPmzQ3S QiGG3vPGOKuN3+fvK9NUZJt0wavygMka37guqbBPL38k0OdsPXS4uhMwuXcVLdHIfNKh zxhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3ZUCPkWUL6pjk9euhQeUzteQwxTqmy3ucSe2ofnhvfU=; b=PcbgTcpvUnWHfFACd9UK+xpDcTUaQLhpdSa5h720KtYpY1GVrgxdLYRqiUTHPMshD/ t/Qaq2NcnqNu6N3MVpWvu+OPFnOSmczuoIui/raq5ReUhQ7mQhO9bg48KwKoVsX3iAal Lv9ChAoj+qZaOuW07VjvG27ec5V9OZgEaoFKEVH825kBT9eXUieQpjBlbsPrZQYCsMKT YUxHlQOXddBs4+hVhnKNPnw/PucpDQwokSOVukiLahEi0OK4ylZwvFqyeQ5UeP3VFON5 bQYCZI/qoszu3mtoPJJ4tQg0ngaQNmXuNvTP/5laHBwcQ4vjn01NniBFq/OtwQ29DN3Y 7hTg== X-Gm-Message-State: AMCzsaU8TjQoU5vnIAxyYy8FvJbrKHyUqLHEW/TD3I5SGS8lRQJsMh0N V6j3a499vxmqwWz1qO2JDs4S1tvKejDbtSaRQYA= X-Google-Smtp-Source: ABhQp+QiWnZ8piKs+atGlHDSHoqqLzpP8AY9LvHZH//pz2IR13b57Gy7YR119gQ7cG7TxsogHrxsilX9yjRgeJm0H1U= X-Received: by 10.202.67.135 with SMTP id q129mr7740148oia.390.1508314105438; Wed, 18 Oct 2017 01:08:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Wed, 18 Oct 2017 01:08:24 -0700 (PDT) In-Reply-To: <6F9A34A1-7F33-462D-96F6-92081256E83B@nokia.com> References: <6F9A34A1-7F33-462D-96F6-92081256E83B@nokia.com> From: Martin Thomson Date: Wed, 18 Oct 2017 19:08:24 +1100 Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: Eric Rescorla , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 08:08:32 -0000 On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > This is quite similar to the trial and error / heuristic that I was > mentioning in [1]. You didn't mention 5-tuples. And it isn't trial and error: you use 5-tuple as your primary key and use connection ID to latch. > Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails to > recognise A.1 as CID-enabled and sends it forward to the crypto handler > when it shouldn't. As I said before, any connection without a connection ID monopolizes that 5-tuple making it inaccessible to other connections. I think that in this case: too bad. > And the already discussed limitations: > - Fragility on corner cases (e.g., the 5-tuple swap above); I don't see how you can avoid this in the general case. Any connection without connection ID is going to be hard to correlate if it moves. As for the connection that does have a connection ID but moves on top of a connection that doesn't, I don't think that is an acceptable loss. > - Forcing middleware to keep state; > - Breaking wireshark & co unless they can see the whole session; Both of these are acceptable to me. Unless you can describe a middlebox use case that needs access to this information and can't deal with the solution that I described. Wireshark and co will need to see the handshake if they want to decrypt and that's the only case that is important. > - (Depending on the use case, the cost of the two lookups per record > on the parsing might have a performance impact.) The second lookup only happens after a migration. I neglected to mention that successful use of a connection ID causes the 5-tuple to be assigned to that connection; there's a trick there in that you need to watch for reordering, but it saves the double lookup. From nobody Wed Oct 18 01:13:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12B0132199 for ; Wed, 18 Oct 2017 01:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWOGSPFT0ozr for ; Wed, 18 Oct 2017 01:13:08 -0700 (PDT) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (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 3B8E913292F for ; Wed, 18 Oct 2017 01:13:08 -0700 (PDT) Received: by mail-wm0-f51.google.com with SMTP id l68so8440837wmd.5 for ; Wed, 18 Oct 2017 01:13:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=brC9kWp/QTPa9+whJ5zhb6zLli13cVV1RxERdg9KG4M=; b=sO98x3CVQP8kh7HXUIvzoQRydGU4CY5VLcPF0wCUu7ks47xSYPMREodPWYFOOYGgWe TytbZMIBlLbyWb8jP8MGkXEk8C+GMXs4cWYlZqUWLAKMXZpDv+IkEwlZHwc1SS3b0Xj9 RMDBtkEDjtZ9vbabmkJFj2IObRJ/U0gNsre7PvG79zWLNo35CmsrN5wwZ9kIX/87fazO hwuGYFBPhGDLbAThd7ODIe8pV5L7SLc97fLdZMl6rmNV+odcL2m9QqBPSE6UdK6Q75ez yWcfKDNxaCoCHnBByXhtUeTNXwkzzJz2Fifr5afrifkzkpZd8y7eZvAVK2pN2WB7G6ZI xiAA== X-Gm-Message-State: AMCzsaVl8xE76zVB5trzwLm/PpYdTIJcL/ltgF2sB65a0mwPIF3sh6Dh GpA00kObN0UqCDKemPwCajoAKA== X-Google-Smtp-Source: ABhQp+SJsC0vlCgRUrk567mRbof7Ph7VK+OpgqgylL89YQF9COT1py/MkJULtGcXluNOJIFHabhlOA== X-Received: by 10.28.196.205 with SMTP id u196mr5255668wmf.120.1508314386661; Wed, 18 Oct 2017 01:13:06 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com ([2a02:214d:8007:2600:527b:9dff:fe2b:1d57]) by smtp.gmail.com with ESMTPSA id u52sm20589038wrb.23.2017.10.18.01.13.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Oct 2017 01:13:05 -0700 (PDT) Message-ID: <1508314383.2929.23.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Eric Rescorla , "tls@ietf.org" Date: Wed, 18 Oct 2017 10:13:03 +0200 In-Reply-To: <12771800-934C-4542-9F26-2E07B2C8D684@nokia.com> References: <1507875665.3178.19.camel@redhat.com> <12771800-934C-4542-9F26-2E07B2C8D684@nokia.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 08:13:10 -0000 On Wed, 2017-10-18 at 06:43 +0000, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > Hi Nikos, > > On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos" -bounces@ietf.org on behalf of nmav@redhat.com> wrote: > > Another worrying feature is that the client can make the server > > send > > up to 255 verbatim bytes on the wire of his choice. Why was this > > feature added? Are there use cases related with it (intro doesn't > > mention any), or it was only thought as a make it as generic as > > possible approach? If it is the latter, I'd recommend to provide a > > simple approach that covers the described use cases. > > > > The same argument applies to the server being able to set such a > > long > > sequence of verbatim bytes to each of the client packets. > > I'd like to get a better understanding of your concern here. > Is it size? I had in mind scenarios of using these bytes to make the peer of talk another protocol with an unsuspecting party, or using the peer to attack a middle box which parses packets, e.g, by attempting buffer overflows to it. regards, Nikos From nobody Wed Oct 18 09:40:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A6413234B for ; Wed, 18 Oct 2017 09:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpbFH111ZZEw for ; Wed, 18 Oct 2017 09:39:56 -0700 (PDT) Received: from 10.mo6.mail-out.ovh.net (10.mo6.mail-out.ovh.net [87.98.157.236]) (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 1F5B8132C2A for ; Wed, 18 Oct 2017 09:39:55 -0700 (PDT) Received: from player761.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id 9D15E118C71 for ; Wed, 18 Oct 2017 18:39:53 +0200 (CEST) Received: from [10.41.51.212] (130.163-14-84.ripe.coltfrance.com [84.14.163.130]) (Authenticated sender: contact@simonbernard.eu) by player761.ha.ovh.net (Postfix) with ESMTPSA id 4F70248009C; Wed, 18 Oct 2017 18:39:51 +0200 (CEST) To: Martin Thomson , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: "tls@ietf.org" References: From: Simon Bernard Message-ID: <9a6cbdb6-2064-b7f9-d5bf-8416e06e595a@simonbernard.eu> Date: Wed, 18 Oct 2017 18:39:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 9500624892612262129 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedttddrudeigddutdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 16:39:59 -0000 This makes me think about if this is feasible/desirable to use connection id to do load balancing. I think about use cases where you have a cluster of server behind only one IP address. Often traffic will be load balanced by IP. But with UDP and Nat environment, the IP can change. Thx to CID, if client is redirected to the same server in the cluster, even if its IP has changed it will be able to communicate without new handshake. But if its IP has changed there is little chance than load balancer will balance it on the same server and so new handshake is needed. (unless server share their connection state) Any thought about that ? Le 17/10/2017 à 23:35, Martin Thomson a écrit : > On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia - > GB/Cambridge, UK) wrote: >> The following case (NAT box reboot) is problematic: >> >> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on >> host B (B.1); >> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; >> 3. The NAT box reboots (all previous 5-tuple mappings are lost); >> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the >> meanwhile); >> >> How is B.1 supposed to correctly interpret the bytes starting at offset >> +11? (For what it knows, it could be CID from A.1 or the length field >> from A.2.) > I don't think that this is a problem. > > connection = five_tuples.lookup(packet.five_tuple) > if (!connection) { > connection = connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length]) > } > if (!connection) { > // is this a ClientHello? otherwise drop it > } > > Of course this doesn't help you with A.2, but that's why this draft exists. > > If the server can insist on connection IDs from all clients (in the > far future perhaps, or for an entirely new protocol), then the code is > more simply: > > connection = connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length]) > if (!connection) { > // is this a ClientHello? otherwise drop it > } > >> I might be missing something fundamental here, but isn't the length >> encoded in the CID field on the wire? > Not by my understanding. There isn't any need (the intent is to have > the CID only consumable by the entity that created it, and any others > that it collaborates with, like a load balancer). > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Oct 18 09:59:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62AA13234B for ; Wed, 18 Oct 2017 09:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLjaXJfZiAJk for ; Wed, 18 Oct 2017 09:59:39 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 C2431132031 for ; Wed, 18 Oct 2017 09:59:38 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l32so1131793ywh.13 for ; Wed, 18 Oct 2017 09:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y57pmKdnsX5FBMIW/Ct2nxYTHjgCEArzgLwNfDlzvSg=; b=1SrVSseIYY2/V2iHkU1vuu3+B7FJlWKZA82uMR/FSl2M/YT4Mzj5UkfEMoyedXn2kU ZzF95ETr29mnngG7TC4LcCgdpIoy+FXTwPq61YwNzCouH8z71SAqcRts3keoH8lLFziC 3NLatH13byQIQymapHeajZ10Tui0RWS5hRpimRB0E0BVyKewCMOEK5dmp/xWollvDHoD b5kvBbFZSjq/dd7bl7+wy8WQetjjd7LKg41ZWvvKKpfOoPdeJu2PG90Q5kyY2T+NZfsf 2djn9B9+A8fN3ePaTsKLN98ZSsSWgw4TEjTaNikaqikpteNMOU1zdm39Y9t4SN2ugaJh kMEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y57pmKdnsX5FBMIW/Ct2nxYTHjgCEArzgLwNfDlzvSg=; b=M1dyNDK5xEAwnUDCQvRO53aFaJu6jEYFTpxqVmxgjmtFM5I4qVybFuSC9gZ/KmdnAE VGJZS8ofpNinkfG3ncB3usoL9mN0PoZCt5Q2Itu/IBwfcjKPDUXHJdaGhCJFWZL83SAM K4NjqrrSKWadT81oBMaIm/PtzTXAcU9Mx6+0eXJN932oz3U9A9M/Nv0ildPS9XNMiAu/ woGMJXPZe/Bgz3K39C/Lpy8QfBZctAnNBRI4xSThC2YwTB3B0IBKvGz0UjZ08Aav66Cd hqpOcJRLqF2SJko42CPQKrzDYVkkdrQoUyuQ7G+JLbAVnkXebVkz7yvU9AEUPVRCz72g 0HJw== X-Gm-Message-State: AMCzsaXeDPWa0SWu1OgjW6JvIn1cTLwQg+07W/VUpd4foWkQornE0Vqr 9XO3NpRq0gdNmJYQKiBH6OgFGssPzD9e6ChNYtquAQ== X-Google-Smtp-Source: ABhQp+QJp/PzZAmOKxDoHjqbKuc2hp6ONgAiHeedQBVSKT7ik5yrgOsY+KQUw1S9f9U8+YMa7fSYjuRXWo+wbVECtHA= X-Received: by 10.13.192.196 with SMTP id b187mr1867782ywd.416.1508345978066; Wed, 18 Oct 2017 09:59:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Wed, 18 Oct 2017 09:58:57 -0700 (PDT) In-Reply-To: <9a6cbdb6-2064-b7f9-d5bf-8416e06e595a@simonbernard.eu> References: <9a6cbdb6-2064-b7f9-d5bf-8416e06e595a@simonbernard.eu> From: Eric Rescorla Date: Wed, 18 Oct 2017 09:58:57 -0700 Message-ID: To: Simon Bernard Cc: Martin Thomson , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114edd4838af6f055bd52a56" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 16:59:41 -0000 --001a114edd4838af6f055bd52a56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 18, 2017 at 9:39 AM, Simon Bernard wrote: > This makes me think about if this is feasible/desirable to use connection > id to do load balancing. > > I think about use cases where you have a cluster of server behind only on= e > IP address. Often traffic will be load balanced by IP. > But with UDP and Nat environment, the IP can change. > > Thx to CID, if client is redirected to the same server in the cluster, > even if its IP has changed it will be able to communicate without new > handshake. > But if its IP has changed there is little chance than load balancer will > balance it on the same server and so new handshake is needed. (unless > server share their connection state) > The usual procedure is for the server and load balancer to coordinate on the CID algorithm. A trivial version would be for the server to generate the connection ID as || . -Ekr > > Any thought about that ? > > > > Le 17/10/2017 =C3=A0 23:35, Martin Thomson a =C3=A9crit : > >> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia - >> GB/Cambridge, UK) wrote: >> >>> The following case (NAT box reboot) is problematic: >>> >>> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' o= n >>> host B (B.1); >>> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; >>> 3. The NAT box reboots (all previous 5-tuple mappings are lost); >>> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the >>> meanwhile); >>> >>> How is B.1 supposed to correctly interpret the bytes starting at offset >>> +11? (For what it knows, it could be CID from A.1 or the length field >>> from A.2.) >>> >> I don't think that this is a problem. >> >> connection =3D five_tuples.lookup(packet.five_tuple) >> if (!connection) { >> connection =3D connection_ids.lookup(packet[c >> onnection_id_offset:connection_id_offset+connection_id_length]) >> } >> if (!connection) { >> // is this a ClientHello? otherwise drop it >> } >> >> Of course this doesn't help you with A.2, but that's why this draft >> exists. >> >> If the server can insist on connection IDs from all clients (in the >> far future perhaps, or for an entirely new protocol), then the code is >> more simply: >> >> connection =3D connection_ids.lookup(packet[connection_id_offset:connect= ion >> _id_offset+connection_id_length]) >> if (!connection) { >> // is this a ClientHello? otherwise drop it >> } >> >> I might be missing something fundamental here, but isn't the length >>> encoded in the CID field on the wire? >>> >> Not by my understanding. There isn't any need (the intent is to have >> the CID only consumable by the entity that created it, and any others >> that it collaborates with, like a load balancer). >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114edd4838af6f055bd52a56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 18, 2017 at 9:39 AM, Simon Bernard <contact@simonbernard.eu<= /a>> wrote:
This makes me think= about if this is feasible/desirable to use connection id to do load balanc= ing.

I think about use cases where you have a cluster of server behind only one = IP address. Often traffic will be load balanced by IP.
But with UDP and Nat environment, the IP can change.

Thx to CID, if client is redirected to the same server in the cluster, even= if its IP has changed it will be able to communicate without new handshake= .
But if its IP has changed there is little chance than load balancer will ba= lance it on the same server and so new handshake is needed. (unless server = share their connection state)

The usual= procedure is for the server and load balancer to coordinate on the CID alg= orithm.
A trivial version would be for the server to generate the= connection ID as <server-id> || <random>.

=
-Ekr
=C2=A0

Any thought about that ?



Le 17/10/2017 =C3=A0 23:35, Martin Thomson a =C3=A9crit=C2=A0:
On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:
The following case (NAT box reboot) is problematic:

1. Application '1' on host A (A.1) uses DTLS+CID with application &= #39;1' on
=C2=A0 =C2=A0 host B (B.1);
2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; 3. The NAT box reboots (all previous 5-tuple mappings are lost);
4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
=C2=A0 =C2=A0 meanwhile);

How is B.1 supposed to correctly interpret the bytes starting at offset
+11?=C2=A0 (For what it knows, it could be CID from A.1 or the length field=
from A.2.)
I don't think that this is a problem.

connection =3D five_tuples.lookup(packet.five_tuple)
if (!connection) {
=C2=A0 =C2=A0connection =3D connection_ids.lookup(packet[connection_id= _offset:connection_id_offset+connection_id_length])
}
if (!connection) {
=C2=A0 =C2=A0// is this a ClientHello?=C2=A0 otherwise drop it
}

Of course this doesn't help you with A.2, but that's why this draft= exists.

If the server can insist on connection IDs from all clients (in the
far future perhaps, or for an entirely new protocol), then the code is
more simply:

connection =3D connection_ids.lookup(packet[connection_id_offset:conne= ction_id_offset+connection_id_length])
if (!connection) {
=C2=A0 =C2=A0// is this a ClientHello?=C2=A0 otherwise drop it
}

I might be missing something fundamental here, but isn't the length
encoded in the CID field on the wire?
Not by my understanding.=C2=A0 There isn't any need (the intent is to h= ave
the CID only consumable by the entity that created it, and any others
that it collaborates with, like a load balancer).

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114edd4838af6f055bd52a56-- From nobody Wed Oct 18 10:41:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EF7133079 for ; Wed, 18 Oct 2017 10:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 72bCIehQyg5t for ; Wed, 18 Oct 2017 10:41:34 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77831270AB for ; Wed, 18 Oct 2017 10:41:33 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9IHaPve031336 for ; Wed, 18 Oct 2017 18:41:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=IqQmdkfM3/gszPZeUPkDr2otzCigMr/3ELROKjciXOE=; b=pLYB2rEJ4l/2Ui2U25/S/sNRI8nx+XCpssAUoGvp2aOYLaz2pjW5EANP25H9WnYrX67G Zt+/iqW/T0gn98YJB0mb4qaGYXLZLEgBMJ/fQOjmlZS3yrLal0R7b8t694EmgunIJhMQ RRVcOw28yOues9xYunI84g2I8LVOd4Lu3iyJtFbTS2/LmiCUXOtt6YWHBuQTgUKIhpRs PsrJ2lGmxvZZbxQD1k9AkP2LxstliAZ2nvPICzUp5YN4CorsD6RGeS17lZTITopAP/Fd 3DagPhLbv/cZU8MrncU2jJXl0sN6mj27KRWDrcxXgM3Np6Ji5ejoxas7OqNXCSLv1j4J Ig== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2dpa0cra4y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 18 Oct 2017 18:41:32 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9IHf24l012595 for ; Wed, 18 Oct 2017 13:41:31 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dkdwucr9r-1 for ; Wed, 18 Oct 2017 13:41:30 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id CE7041FC71 for ; Wed, 18 Oct 2017 17:41:30 +0000 (GMT) To: tls@ietf.org References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> From: Benjamin Kaduk Message-ID: Date: Wed, 18 Oct 2017 12:41:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=13 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710180243 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=13 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710180242 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 17:41:35 -0000 On 10/02/2017 03:31 PM, Ralph Droms wrote: > We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS extension defined in this I-D takes into account what we heard from the discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides an opt-in capability for both the TLS client and server and makes it clear on the wire that visibility will be enabled for the session. The new mechanism does not depend on static handshake or session keys. > This draft does not seem to have anything to address the concern that, once a visible ClientHello extension is needed to enable wiretapping, certain parties (e.g., national border firewalls) would reject/drop *all* ClientHellos not containing that extension, thereby extorting all clients into "opting in" to the wiretapping and effectively rendering the "opt-in" requirement useless for those clients. As a more general comment, I think that this concern is so squarely at odds with the concern that the client must be able to opt-in to the wiretapping [and, optionally, be guaranteed by the key schedule to know when wiretapping is happening] that I do not see any potential for a workable solution. -Ben P.S. I agree with Rich; can we try to defer these conversations until after 1.3 is actually published? From nobody Wed Oct 18 12:23:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805E513321F for ; Wed, 18 Oct 2017 12:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 tmY29hYF68dv for ; Wed, 18 Oct 2017 12:23:22 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF28133011 for ; Wed, 18 Oct 2017 12:23:22 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9IJLVoX008488; Wed, 18 Oct 2017 20:23:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=HKxwZvTBagE70VNxBBcGfNrkPKobealo5fZuWzTxkEc=; b=ZMDmwNWXGcO6LiVkNgrAfV4LDUZc2x3syb8KH/UYFLh3t/V496dHLKT9vV8ZLhRzjTTB NPVqtlQ0ljX6l5nlchu4dOQ+4QWRqYyTE/XgtajhRifBxQ7yiGmAGWk45QVvPWlS8iTZ 72WFVfgasy0LDE72L+y/5zxrhQa2oQF/g8R2TPy4mMgHYyiawi8MAUSXwcrqkC75072Q Hdox9Haye6yWL/pcuZ9FDO+NoRH/e91q55usMEmGgilw8QBo6vg9ycmO8Ixg1grAhGC5 62FYSODeellx+dyoXIuC7puH1n86NQVlvRxK/FIO6jvVJOjN2k8JBsuFhbXKEgWszoJP Fw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2dngqcmqd3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Oct 2017 20:23:20 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9IJLRjQ026677; Wed, 18 Oct 2017 15:23:19 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dkdwud0pf-1; Wed, 18 Oct 2017 15:23:19 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 80B8A1FC8B; Wed, 18 Oct 2017 19:23:19 +0000 (GMT) To: Sean Turner , "" References: <4EDF7DF9-D9C9-4A5B-AA9C-5A39823FA250@sn3rd.com> From: Benjamin Kaduk Message-ID: <09e8dfa7-2e27-b14b-2354-d6132cc03113@akamai.com> Date: Wed, 18 Oct 2017 14:23:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4EDF7DF9-D9C9-4A5B-AA9C-5A39823FA250@sn3rd.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710180268 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-18_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710180268 Archived-At: Subject: Re: [TLS] Should CCM_8 CSs be Recommended? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 19:23:24 -0000 I agree with "everyone"; it seems like these fall into what "not recommended" is intended to encompass.  I don't have a preference for whether there's an extra annotation about IoT usage. -Ben On 10/09/2017 06:05 PM, Sean Turner wrote: > Anybody else has thoughts on this? > > spt > >> On Oct 3, 2017, at 18:53, Sean Turner wrote: >> >> In the IANA registries draft (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates), we’ve added a recommended column to the Cipher Suites (CSs) registry (and some others). Right now, the criteria for getting a recommended mark is AEAD ciphers with strong authentication standards track ciphers. While that’s great generally, the list we’ve got five CSs that gave Joe and I pause: >> >> TLS_DHE_RSA_WITH_AES_128_CCM_8 >> TLS_DHE_RSA_WITH_AES_256_CCM_8 >> TLS_PSK_DHE_WITH_AES_128_CCM_8 >> TLS_PSK_DHE_WITH_AES_256_CCM_8 >> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 >> >> The CCM_8 CSs have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environment. In other words, this might be great for some IoT device but we should not generally be recommending these. >> >> We’re recommending that these five suites be dropped from the recommended list. Please let us know what you think. >> >> J&S >> (editor hats on) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 19 06:07:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1F513305E for ; Thu, 19 Oct 2017 06:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 F9O0lG6VUmer for ; Thu, 19 Oct 2017 06:07:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36135132D18 for ; Thu, 19 Oct 2017 06:07:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F13A0BE49; Thu, 19 Oct 2017 14:07:24 +0100 (IST) 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 IuGxyfvWWNkh; Thu, 19 Oct 2017 14:07:24 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92244BE47; Thu, 19 Oct 2017 14:07:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508418444; bh=PRBcDP8lvp91iAYNO3Lnq8dc5Li2n1XAymC8RiQZXPc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=37nPHcTGaf8qz5YdIdTyzl7a3eK2P2MI0512SFZlwI3oG2G6Q55rAsHTFD2EGv2bz InMG2p4RlA8WrD8sZDKmZ/+qb0nKkXzP1BVdxi2pT0ITidIhBcEUmbva6jt+cNvPOa Gh9Oyq0BYc6PFeWHY1qrfcmS4NzVf4uaoCkQ5/v0= To: Benjamin Kaduk , tls@ietf.org References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <496c8581-bb5c-49be-fd2a-8a6369b274e2@cs.tcd.ie> Date: Thu, 19 Oct 2017 14:07:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BNeS3WOSHHG8icNqV3U3KjdtJknp94lGT" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 13:07:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BNeS3WOSHHG8icNqV3U3KjdtJknp94lGT Content-Type: multipart/mixed; boundary="oloUWh6fxl1vEoowAR02lla6f3K0kIhuN"; protected-headers="v1" From: Stephen Farrell To: Benjamin Kaduk , tls@ietf.org Message-ID: <496c8581-bb5c-49be-fd2a-8a6369b274e2@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> In-Reply-To: --oloUWh6fxl1vEoowAR02lla6f3K0kIhuN Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 18/10/17 18:41, Benjamin Kaduk wrote: > P.S. I agree with Rich; can we try to defer these conversations until > after 1.3 is actually published? FWIW, I also think it'd be a good plan if the chairs did that. I'm happy to oppose these ideas any time, but later is better than now, given this would further distract us from 1.3. S. --oloUWh6fxl1vEoowAR02lla6f3K0kIhuN-- --BNeS3WOSHHG8icNqV3U3KjdtJknp94lGT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ6KOBAAoJEC88hzaAX42iIGYH/jtGGp1VLvaJlyYNMNzDG1Us VZSKYY910yFlNtkw18ISNR+SjZexwyj3+pPwe133IS8Szswils6N1/nByBr0SFf7 bfvIacU3JKQx5mc+Xum5/yTSytxFFTbX/gFjn+UGC/RPBVQKE4fgj9M4bN3xNnft xLNXPAhjbTNCzoFQedujomPT01Sqnt8zaod+kZuGbiQWaFMy04jMeRzVgNE1ToqV cxXN9PAtfI1BnFUiBIEKcQzXX3tbHtc5jtDZfjNUBn/IvUg5j5lLNMOVRiPYcqpE VMGuS7NQ8HyJeeAX0bFKIohd2qGO7G5fwtP2LOs6luJPv2MuubamxHZZci4Z83s= =bagK -----END PGP SIGNATURE----- --BNeS3WOSHHG8icNqV3U3KjdtJknp94lGT-- From nobody Thu Oct 19 06:55:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD051342D2 for ; Thu, 19 Oct 2017 06:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke3UxtLtnR4G for ; Thu, 19 Oct 2017 06:55:28 -0700 (PDT) Received: from mail.venafi.com (unknown [34.193.116.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55CB132143 for ; Thu, 19 Oct 2017 06:55:27 -0700 (PDT) Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 07:55:25 -0600 Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG01.res.venafi.com (10.1.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 07:55:25 -0600 Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 19 Oct 2017 07:55:25 -0600 From: Paul Turner To: Benjamin Kaduk , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQDO0nP6IcKCRq1bnEFoblkG8dV0CgHq1icUpOTCoYA= Date: Thu, 19 Oct 2017 13:55:25 +0000 Message-ID: <71e75d23f4544735a9731c4ec3dc7048@venafi.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.115.210.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 13:55:30 -0000 Ben, In the scenario you outlined below, it seems the third party has significan= t control over the communications of the clients (e.g. national border fire= wall). In addition, based on your description, it seems they are intent on = ensuring that not communications occur unless they can view the communicati= ons. In addition, they must be able to coerce the server owner into providi= ng the key (because the proposed method requires opt-in by both the client = and the server). This is a significant amount of control that the third par= ty wields.=20 In this scenario, wouldn't the state firewall simply require all clients to= trust their CA so that they can reverse proxy all communications--since th= ey will likely not only be interested in one server's communications but ma= ny? It seems important to keep in mind that each server that a third party = wants to listen in on must agree to enable it (opt-in). It would seem that = a state run firewall is unlikely to get that agreement from a broad number = of servers of interest. And, as you point out, each client will know they'r= e being forced to agree that the third party can listen in on communication= s (if they choose to continue to communicate with the server). In countries= where it is possible to challenge such coercion in a court of law, the cli= ent will know they are being forced and can challenge that (or more likely = the industry can provide pressure). This method seems to protect against so= meone like the NSA secretly coercing a server owner into opting in without = the knowledge of the client (and the broader community).=20 I guess the basic question I'm asking is that if a third party is so powerf= ul that they can do what you describe, aren't they going to force an even m= ore effective method (trusting their CA so that they can terminate the conn= ection as a middle man) on clients so that they don't have to coerce every = server? Thanks, Paul -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Wednesday, October 18, 2017 13:42 To: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On 10/02/2017 03:31 PM, Ralph Droms wrote: > We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS exte= nsion defined in this I-D takes into account what we heard from the discuss= ion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in P= rague. Specifically, it provides an opt-in capability for both the TLS clie= nt and server and makes it clear on the wire that visibility will be enable= d for the session. The new mechanism does not depend on static handshake o= r session keys. =20 > This draft does not seem to have anything to address the concern that, once= a visible ClientHello extension is needed to enable wiretapping, certain p= arties (e.g., national border firewalls) would reject/drop *all* ClientHellos not containing that extension, thereby extorting all cli= ents into "opting in" to the wiretapping and effectively rendering the "opt= -in" requirement useless for those clients. As a more general comment, I think that this concern is so squarely at odds= with the concern that the client must be able to opt-in to the wiretapping= [and, optionally, be guaranteed by the key schedule to know when wiretappi= ng is happening] that I do not see any potential for a workable solution. -Ben P.S. I agree with Rich; can we try to defer these conversations until after= 1.3 is actually published? _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 19 07:15:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2BC1320D9 for ; Thu, 19 Oct 2017 07:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sjIiQ2glnERc for ; Thu, 19 Oct 2017 07:15:28 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0133D1331D9 for ; Thu, 19 Oct 2017 07:15:27 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9JEE9Ir011136; Thu, 19 Oct 2017 15:15:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=U4ttLm8/A+p/3+qNr/G5aUzT0hVa1eejxFt0DFlMKXs=; b=FQi4ABQd9l3HAOBneEFJUwYzNNO4UK94YMT59diSvQpY58MqNq2XlMFHpydXRjuXy04q 49c3M6smPRMplxx23eEiiM4df8j/jeYolelzZtcRDK+3QjgOcJuIn5/ppYvdeApfEkjF 5rJ0/lwFdTzImWI3MMidopkmNEzpagSAVd+iMK5TCESzr9ePMxUI/ACVaa9GxgNYrggE DblZPGkjzdi/xenqU4zysO2jhVEyScGp4vHh3TL/F5aemoNf+1wqwG9otq0mzuRS4fnv Ox6kbqhNxKC48wGVywlrYbtRQm9ckG3O4RIhnERqBBrZHgUmiB7uPSnkprcVuv9chgrm Mg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2dpe9daw2j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 15:15:26 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9JEBcCS016303; Thu, 19 Oct 2017 10:15:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dkdwufgpj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 10:15:24 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 10:15:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 19 Oct 2017 10:15:20 -0400 From: "Salz, Rich" To: Paul Turner , "Kaduk, Ben" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgA== Date: Thu, 19 Oct 2017 14:15:19 +0000 Message-ID: <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> In-Reply-To: <71e75d23f4544735a9731c4ec3dc7048@venafi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.65] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190196 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:15:29 -0000 DQrinqIgICAgIEkgZ3Vlc3MgdGhlIGJhc2ljIHF1ZXN0aW9uIEknbSBhc2tpbmcgaXMgdGhhdCBp ZiBhIHRoaXJkIHBhcnR5IGlzIHNvIHBvd2VyZnVsIHRoYXQgdGhleSBjYW4gZG8gd2hhdCB5b3Ug ZGVzY3JpYmUsIGFyZW4ndCB0aGV5IGdvaW5nIHRvIGZvcmNlIGFuIGV2ZW4gbW9yZSBlZmZlY3Rp dmUgbWV0aG9kICh0cnVzdGluZyB0aGVpciBDQSBzbyB0aGF0IHRoZXkgY2FuIHRlcm1pbmF0ZSB0 aGUgY29ubmVjdGlvbiBhcyBhIG1pZGRsZSBtYW4pIG9uIGNsaWVudHMgc28gdGhhdCB0aGV5IGRv bid0IGhhdmUgdG8gY29lcmNlIGV2ZXJ5IHNlcnZlcj8NCiAgICANClRoZSBzdGF0ZWQgZ29hbCBv ZiB0aGlzIHdvcmsgKGFuZCBpdHMgcHJlZGVjZXNzb3IpIGlzIHRvIGFsbG93IGVudGVycHJpc2Vz IHRvIGNhcHR1cmUgdHJhZmZpYyBmb3IgbGF0ZXIgZGVidWdnaW5nIGFuZCBhbmFseXNpcy4gIFRo ZSBjbGllbnQgY291bGQgYmUgY29taW5nIGluIHZpYSB0aGUgZ2VuZXJpYyBwdWJsaWMgSW50ZXJu ZXQsIHdpdGggYSBzdG9jayBicm93c2VyLg0KDQpZb3VyIHF1ZXN0aW9uIHBvaW50cyBvdXQgYSBk YW5nZXIgb2YgdGhpcyBtZWNoYW5pc206IGl0IGJlY29tZXMgYWxsIHRvbyBlYXN5IHRvIOKAnGVz Y2FwZeKAnSBhbmQgZW5hYmxlIG5hdGlvbndpZGUgd2lyZXRhcHBpbmcuDQoNCk1ha2Ugc2Vuc2U/ DQoNCg0K From nobody Thu Oct 19 07:16:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5184C126D0C for ; Thu, 19 Oct 2017 07:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM0PFz97V4CM for ; Thu, 19 Oct 2017 07:16:53 -0700 (PDT) Received: from mail.venafi.com (unknown [34.193.116.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5191A1320D9 for ; Thu, 19 Oct 2017 07:16:53 -0700 (PDT) Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 08:16:51 -0600 Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 19 Oct 2017 08:16:50 -0600 From: Paul Turner To: Stephen Farrell , Benjamin Kaduk , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQDO0nP6IcKCRq1bnEFoblkG8dV0CgHq1icUAhbZNVuk1BcBoA== Date: Thu, 19 Oct 2017 14:16:50 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <496c8581-bb5c-49be-fd2a-8a6369b274e2@cs.tcd.ie> In-Reply-To: <496c8581-bb5c-49be-fd2a-8a6369b274e2@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.115.210.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:16:55 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVExTIFttYWlsdG86dGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNCj4gU2VudDog VGh1cnNkYXksIE9jdG9iZXIgMTksIDIwMTcgMDk6MDcNCj4gVG86IEJlbmphbWluIEthZHVrIDxi a2FkdWtAYWthbWFpLmNvbT47IHRsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1RMU10gUHVi bGljYXRpb24gb2YgZHJhZnQtcmhyZC10bHMtdGxzMTMtdmlzaWJpbGl0eS0wMA0KPiANCj4gDQo+ IEhpeWEsDQo+IA0KPiBPbiAxOC8xMC8xNyAxODo0MSwgQmVuamFtaW4gS2FkdWsgd3JvdGU6DQo+ ID4gUC5TLiBJIGFncmVlIHdpdGggUmljaDsgY2FuIHdlIHRyeSB0byBkZWZlciB0aGVzZSBjb252 ZXJzYXRpb25zIHVudGlsDQo+ID4gYWZ0ZXIgMS4zIGlzIGFjdHVhbGx5IHB1Ymxpc2hlZD8NCj4g DQo+IEZXSVcsIEkgYWxzbyB0aGluayBpdCdkIGJlIGEgZ29vZCBwbGFuIGlmIHRoZSBjaGFpcnMg ZGlkIHRoYXQuIEknbSBoYXBweSB0bw0KPiBvcHBvc2UgdGhlc2UgaWRlYXMgYW55IHRpbWUsIGJ1 dCBsYXRlciBpcyBiZXR0ZXIgdGhhbiBub3csIGdpdmVuIHRoaXMgd291bGQNCj4gZnVydGhlciBk aXN0cmFjdCB1cyBmcm9tIDEuMy4NCg0KSSBkb24ndCB0aGluayB0aGlzIGlzIGEgZ29vZCBwbGFu Lg0KDQo+IA0KPiBTLg0KDQo= From nobody Thu Oct 19 07:18:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E16A126D0C for ; Thu, 19 Oct 2017 07:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=equio-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaJXCD25krbX for ; Thu, 19 Oct 2017 07:18:24 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAC41320D9 for ; Thu, 19 Oct 2017 07:18:24 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id p138so10383519itp.2 for ; Thu, 19 Oct 2017 07:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=equio-com.20150623.gappssmtp.com; s=20150623; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=lEIxm9xrf4x6hQOMzEhBs3RmgAcevj7CXSA8nfHya98=; b=DdXxzUMJ0Wq7EKA3REoxNp6k09GM3UPlq0M+McFSqIxlhNWV1zQdAETUgMjNGcnxJN uNFZl6qABOJ74D4XMoCH/Hr2Iq3JYkXxSLQQZeBUemJVlZuVcxf+BSa6OKYh4grIZlQw lx62KjLNsTsOPFTpAyniNgT/30K3KGZOK4vf+s5y9PloFbhXPgw7FCtr/J9lPMY5tabx /LkqL1k3OcPgw3S3Yt1W1jPNsRGFtk6FWYQCZf7T51TLgsl+CZZpzxNX0A9IPS+U5FmP pgjz6ogD3MnaWxBamAVQiERtK7tViPtl60CujbkwM13CEXntJjerahQF7hoXiX1ZwnwI cOKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=lEIxm9xrf4x6hQOMzEhBs3RmgAcevj7CXSA8nfHya98=; b=Qlnj+IkRApk8y9tQJ9BPs2EkoQolW9OAsFqTaSUBPKGKwILT7wu2sGXawsE6JKBSE3 7mgjj/kp1C+9tr8D3d2USj6+u4vHimPq9PAntcb/tQ3eUtOWsQ4qb9lGR2NU8BESr89c EPv/LwLAu9t5qcNvJH4qnK6bUyKzxy3p/cfF+HRc6MorLU1H9z/UopzvTnvG+Ib0WC3J WL3H00fFC8jvXMsxGgF3nVzDpzDM1RgFmM0C2A2E+0qRjEeQ6mTj4PDYPZl/a0Mz1v2P lHIk81bNZGUJQaG188lJeEySJ5hZinL3ToaQuBJry8j3sZnpD5qvaDr3U3z+JKofqU1G dT5Q== X-Gm-Message-State: AMCzsaUsL/k+f/OlZC7EnPaJKpSRWX0ojZcrDETeae+wfvqckFlwYmF/ 8yjYDrIX7s74/LZHQ1M2ygofuNjC X-Google-Smtp-Source: ABhQp+Tw9fJVr6t6qETHd76hLq1fE/CXKptZvSNErxlJ1sbqvnLbUvXxOv/IDoH2tLb3HvYNvPHesA== X-Received: by 10.36.57.76 with SMTP id l73mr2513754ita.17.1508422703700; Thu, 19 Oct 2017 07:18:23 -0700 (PDT) Received: from 07WKSWIN150119 ([75.115.210.166]) by smtp.gmail.com with ESMTPSA id u188sm706797itb.2.2017.10.19.07.18.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 07:18:22 -0700 (PDT) From: "Paul Turner" To: "'Salz, Rich'" , "'Paul Turner'" , "'Kaduk, Ben'" , References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> In-Reply-To: <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> Date: Thu, 19 Oct 2017 10:18:21 -0400 Message-ID: <000501d348e5$1f273450$5d759cf0$@equio.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDO0nP6IcKCRq1bnEFoblkG8dV0CgHq1icUAbogPusCZWYb+6TD0hUA Content-Language: en-us Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:18:26 -0000 > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Salz, Rich > Sent: Thursday, October 19, 2017 10:15 > To: Paul Turner ; Kaduk, Ben > ; tls@ietf.org > Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 >=20 >=20 > =E2=9E=A2 I guess the basic question I'm asking is that if a third = party is so powerful > that they can do what you describe, aren't they going to force an even = more > effective method (trusting their CA so that they can terminate the = connection > as a middle man) on clients so that they don't have to coerce every = server? >=20 > The stated goal of this work (and its predecessor) is to allow = enterprises to > capture traffic for later debugging and analysis. The client could be = coming in > via the generic public Internet, with a stock browser. >=20 > Your question points out a danger of this mechanism: it becomes all = too easy > to =E2=80=9Cescape=E2=80=9D and enable nationwide wiretapping. >=20 > Make sense? >=20 Can you explain how nationwide wiretapping is going to be easy with this = plan? Again, EVERY server owner will need to opt-in. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 19 07:21:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B987E126D0C for ; Thu, 19 Oct 2017 07:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 knyfUWpNa7kV for ; Thu, 19 Oct 2017 07:21:52 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0097.outbound.protection.outlook.com [104.47.1.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 69F781342E8 for ; Thu, 19 Oct 2017 07:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lBgoepbalpWGXpjtQT17WVBMEhutHASpVsBBlqUatsM=; b=rZfyAK3yQE6zurWoezSdXNtikvEAcUxaGo61pejJce1jye8NbxZklfVIQV+2GJMOpB63whcfIpjLvPpt4Jn5qKvUu/8zhCaMr5rMqlw4mMqHuTK9A8sOtGs/JVrhaY5omtCATyEeekACFlIv2g2y/9RTiUr9He9wUZIaEuqOCBc= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1103.eurprd07.prod.outlook.com (10.163.168.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 19 Oct 2017 14:21:49 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0156.004; Thu, 19 Oct 2017 14:21:48 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Martin Thomson CC: Eric Rescorla , "tls@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AQHTQ6/ei1Eh6DPTUUK7WLQddJSSYqLnKXUAgADEnwCAAKpMgIAAqfeAgAAG0wCAAgttgA== Date: Thu, 19 Oct 2017 14:21:48 +0000 Message-ID: <9857D745-D654-4C7D-8D05-3AB971A4B256@nokia.com> References: <6F9A34A1-7F33-462D-96F6-92081256E83B@nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1103; 6:uVUxVsiHeWxDXClwiJXSpEKxGZPpt/3vWcKkjYAXH0wfK/ZehRIbdDHYVZZU6eOPkrXfQv75Zm5BjPRFP2evCLud5Rgvh9wy1E41XZFRUAxrTzo+Le5gi+UZ71HU66Fxzw4aGjeZf6Kvt2padW8s1C0w9nr9p0aLFJwE8OxFt4rhGdJjTzWN1J+F0jtgIl8IQInw+Yr32LI8YhIkFM5xjx8U4p6AfMn0MxOPgD5jEt1nO4G2jy23sN8yyGuEH7XXCdWIA5faC1R1MceurpQGBfa/3Mnx2+UBIu9luEGsT3yNIjnu0mYmGIwK8+4NSonW3xKD8fYGanqHK+oQa3yJAw==; 5:BdQQwstqqiBKBuA6wdXYqxgkFNPfISMKXXywdbiBnuZr5KJwcPFUJem/849Hdpi6BDHgz9jDHX6/NnZPrd+fdPiAp7hp5nj0F2tev1nkHwEuxMTiVDBd+HaqVlSdWHnzaI9xIlFQZQiB2q53isz/Cg==; 24:HL/EmSLlNI6kvepc+CUGGwIoHPE1i2o9rNJlMo2gdW0H9tg8spNoQnNccUMUTgKUN26vuLgEZfJXiZZSdxkVabc1Wguy0Ld8QAk41uRb88Y=; 7:TEnvyH7hhIbBuDVnmdno7JkSQZHEz7VkgagFfHNR/Aa/zET9X0LrI70L0WlFTnoKTreZ1kbKhO1tVY49gvkudW0wH72yHlHyPikHOr7nQpEgGv2/6bvXj6uJ8jfhFGbc1ATOXkPpw6xy9HKOWgath3MOqzuVHc1Plj1xxUBK1p273SOqiZAxHsThNXdgAUIdErQhEZf5oKC0UqCWd6CWt2J+WoMEgXWQh7ASqA+3p+0= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(24454002)(189002)(199003)(39060400002)(4326008)(8676002)(229853002)(83716003)(83506001)(6246003)(107886003)(316002)(53546010)(58126008)(8936002)(189998001)(86362001)(6512007)(2950100002)(2900100001)(3280700002)(3660700001)(25786009)(6916009)(6436002)(6506006)(6486002)(66066001)(81166006)(81156014)(99286003)(82746002)(478600001)(54906003)(53936002)(106356001)(7736002)(105586002)(5250100002)(97736004)(50986999)(305945005)(5660300001)(101416001)(54356999)(76176999)(14454004)(2906002)(68736007)(33656002)(36756003)(93886005)(561944003)(6116002)(102836003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1103; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 7bfbe2a5-32a8-43d0-c183-08d516fcbc4b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1103; x-ms-traffictypediagnostic: VI1PR07MB1103: x-exchange-antispam-report-test: UriScan:(82608151540597); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1103; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1103; x-forefront-prvs: 0465429B7F received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <341DB7A3EF7BD64A9C3117FADEF3233E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 14:21:48.8975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1103 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:21:55 -0000 SGkgTWFydGluLA0KDQpzb3JyeSBmb3IgdGFraW5nIHNvIGxvbmcgdG8gcmVwbGF5Lg0KDQo+IE9u IDE4LzEwLzIwMTcsIDA5OjA4LCAiTWFydGluIFRob21zb24iIDxtYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20+DQo+IHdyb3RlOg0KPiANCj4gT24gV2VkLCBPY3QgMTgsIDIwMTcgYXQgNTo0NCBQTSwg Rm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtDQo+IEdCL0NhbWJyaWRnZSwgVUspIDx0aG9tYXMuZm9z c2F0aUBub2tpYS5jb20+IHdyb3RlOg0KPiA+IFRoaXMgaXMgcXVpdGUgc2ltaWxhciB0byB0aGUg dHJpYWwgYW5kIGVycm9yIC8gaGV1cmlzdGljIHRoYXQgSSB3YXMNCj4gPiBtZW50aW9uaW5nIGlu IFsxXS4NCj4gDQo+IFlvdSBkaWRuJ3QgbWVudGlvbiA1LXR1cGxlcy4gIEFuZCBpdCBpc24ndCB0 cmlhbCBhbmQgZXJyb3I6IHlvdSB1c2UNCj4gNS10dXBsZSBhcyB5b3VyIHByaW1hcnkga2V5IGFu ZCB1c2UgY29ubmVjdGlvbiBJRCB0byBsYXRjaC4NCg0KV2Ugc2VlbSB0byBoYXZlIGEgc2xpZ2h0 bHkgZGlmZmVyZW50IG9waW5pb24gb24gdGhlIG1lYW5pbmcgb2YgdHJpYWwgYW5kDQplcnJvciA6 LSkgIEJ1dCBtb3JlIGltcG9ydGFudGx5LCB3ZSBzZWVtIHRvIGRpc2FncmVlIG9uIHdoZXRoZXIg cGFyc2luZw0KYSBiaW5hcnkgaGVhZGVyIGlzIG9ydGhvZ29uYWwgdG8gY29udGV4dCBsb29rdXAg KGVpdGhlciB2aWEgNS10dXBsZSBvcg0KQ0lEKSBvciBub3QuDQoNCj4gPiBOb3RlIHRoYXQgaWYg QS4xIGFuZCBBLjIncyA1LXR1cGxlcyBhcmUgc3dhcHBlZCwgdGhlIGFsZ29yaXRobSBmYWlscw0K PiA+IHRvIHJlY29nbmlzZSBBLjEgYXMgQ0lELWVuYWJsZWQgYW5kIHNlbmRzIGl0IGZvcndhcmQg dG8gdGhlIGNyeXB0bw0KPiA+IGhhbmRsZXIgd2hlbiBpdCBzaG91bGRuJ3QuDQo+IA0KPiBBcyBJ IHNhaWQgYmVmb3JlLCBhbnkgY29ubmVjdGlvbiB3aXRob3V0IGEgY29ubmVjdGlvbiBJRCBtb25v cG9saXplcw0KPiB0aGF0IDUtdHVwbGUgbWFraW5nIGl0IGluYWNjZXNzaWJsZSB0byBvdGhlciBj b25uZWN0aW9ucy4gIEkgdGhpbmsNCj4gdGhhdCBpbiB0aGlzIGNhc2U6IHRvbyBiYWQuDQoNCkkn bSBub3Qgc3VyZSBJIGFncmVlIHdpdGggdGhhdC4gIENJRCBzaG91bGQgYmUgdGhlIHRpZSBicmVh a2VyIGV4YWN0bHkNCmluIHRoZXNlIHNpdHVhdGlvbnMuICBXaGVuIHNvbWV0aGluZyBsaWtlIHRo YXQgaGFwcGVucywgaWYgeW91cg0KaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgQ0lEIGl0IHNob3Vs ZCB3aW4vc3Vydml2ZSBvdmVyIG9uZSB0aGF0IGRvZXNuJ3QuDQoNCj4gPiBBbmQgdGhlIGFscmVh ZHkgZGlzY3Vzc2VkIGxpbWl0YXRpb25zOmkNCj4gPiAtIEZyYWdpbGl0eSBvbiBjb3JuZXIgY2Fz ZXMgKGUuZy4sIHRoZSA1LXR1cGxlIHN3YXAgYWJvdmUpOw0KPiANCj4gSSBkb24ndCBzZWUgaG93 IHlvdSBjYW4gYXZvaWQgdGhpcyBpbiB0aGUgZ2VuZXJhbCBjYXNlLiAgQW55DQo+IGNvbm5lY3Rp b24gd2l0aG91dCBjb25uZWN0aW9uIElEIGlzIGdvaW5nIHRvIGJlIGhhcmQgdG8gY29ycmVsYXRl IGlmDQo+IGl0IG1vdmVzLiAgQXMgZm9yIHRoZSBjb25uZWN0aW9uIHRoYXQgZG9lcyBoYXZlIGEg Y29ubmVjdGlvbiBJRCBidXQNCj4gbW92ZXMgb24gdG9wIG9mIGEgY29ubmVjdGlvbiB0aGF0IGRv ZXNuJ3QsIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyBhbg0KPiBhY2NlcHRhYmxlIGxvc3MuDQoNCkkg dGhpbmsgeW91IG1lYW4gIkkgZG8gdGhpbmsgdGhhdCBpcyBhbiBhY2NlcHRhYmxlIGxvc3MiLCBv ciAiSSBkb24ndA0KdGhpbmsgdGhhdCBpcyBhbiB1bmFjY2VwdGFibGUgbG9zcyIsIHJpZ2h0Pw0K IA0KPiA+IC0gRm9yY2luZyBtaWRkbGV3YXJlIHRvIGtlZXAgc3RhdGU7DQo+ID4gLSBCcmVha2lu ZyB3aXJlc2hhcmsgJiBjbyB1bmxlc3MgdGhleSBjYW4gc2VlIHRoZSB3aG9sZSBzZXNzaW9uOw0K PiANCj4gQm90aCBvZiB0aGVzZSBhcmUgYWNjZXB0YWJsZSB0byBtZS4gIFVubGVzcyB5b3UgY2Fu IGRlc2NyaWJlIGENCj4gbWlkZGxlYm94IHVzZSBjYXNlIHRoYXQgbmVlZHMgYWNjZXNzIHRvIHRo aXMgaW5mb3JtYXRpb24gYW5kIGNhbid0DQo+IGRlYWwgd2l0aCB0aGUgc29sdXRpb24gdGhhdCBJ IGRlc2NyaWJlZC4gIFdpcmVzaGFyayBhbmQgY28gd2lsbCBuZWVkDQo+IHRvIHNlZSB0aGUgaGFu ZHNoYWtlIGlmIHRoZXkgd2FudCB0byBkZWNyeXB0IGFuZCB0aGF0J3MgdGhlIG9ubHkgY2FzZQ0K PiB0aGF0IGlzIGltcG9ydGFudC4NCg0KRm9yIGRpYWdub3N0aWNzLCBpdCdkIGJlIHByZXR0eSB1 c2VmdWwgaWYgb25lIGNvdWxkIGZpbHRlciBhIGNhcHR1cmUgYnkNCkNJRCBhbmQgZm9sbG93ICp0 aGF0KiBzZXNzaW9uIGFtb25nIGxvdHMgb2Ygb3RoZXJzLiAgSXJyZXNwZWN0aXZlIG9mDQp3aGF0 J3MgaW4gdGhlIGVuY3J5cHRlZCBwYXlsb2FkcyAod2hpY2ggb25lIGNhbiBwcm9iYWJseSBnZXQg ZnJvbSB0aGUNCmVuZHBvaW50LCBpZiBuZWVkZWQpLiAgVGhpcyBpcyBvbmUgdXNlIGNhc2UgdGhh dCBzZWVtcyB2ZXJ5IHVzZWZ1bCB0byBtZQ0KYW5kIGRvZXNuJ3QgcmVxdWlyZSB3aXJlc2hhcmsg dG8ga2VlcCBzdGF0ZS4gIEknbSBub3Qgc2F5aW5nIHRoYXQgdGhlcmUNCmFyZSBubyB3b3JrLWFy b3VuZHM6IHdlIGtub3cgaG93IHRvIG1ha2UgZG8gd2l0aCBwY2FwIGZpbHRlcnMuICBCdXQgSSdk DQpwcmVmZXIgdG8gZGVzaWduIHNvbWV0aGluZyB0aGF0IGlzIHNpbXBsZSBhbmQgY2hlYXAgdG8g aW1wbGVtZW50IGFuZCB1c2UNCmluIHRoZSBmaXJzdCBwbGFjZSwgaWYgcG9zc2libGUuDQoNCldo YXQgSSdtIGFza2luZyBmb3IgaXMgYSBjb2RlcG9pbnQgYW5kIGFuIGV4cGxpY2l0IGxlbmd0aCBm b3IgdGhlIENJRCwNCmkuZS4sIGEgdG90YWwgKzEgYnl0ZSBwZXIgMS4yIHJlY29yZCBvbiB0aGUg d2lyZS4gIEknbSBub3Qgc3VyZSB0aGUNCnRpbnkgc2F2aW5nIHdlIGdldCB3aXRoIHRoZSBjdXJy ZW50IHByb3Bvc2FsIGp1c3RpZmllcyB0aGUgaW5jcmVhc2UgaW4NCmNvbXBsZXhpdHkuDQoNCj4g PiAtIChEZXBlbmRpbmcgb24gdGhlIHVzZSBjYXNlLCB0aGUgY29zdCBvZiB0aGUgdHdvIGxvb2t1 cHMgcGVyIHJlY29yZA0KPiA+ICAgb24gdGhlIHBhcnNpbmcgbWlnaHQgaGF2ZSBhIHBlcmZvcm1h bmNlIGltcGFjdC4pDQo+IA0KPiBUaGUgc2Vjb25kIGxvb2t1cCBvbmx5IGhhcHBlbnMgYWZ0ZXIg YSBtaWdyYXRpb24uDQoNCkluIHRoZSBJb1QgdXNlIGNhc2VzLCByZS1iaW5kaW5nIGR1cmluZyBh IHNsZWVwIGN5Y2xlIGlzIHRoZSBjb21tb24NCnBhdHRlcm4sIHNvIHRoZSBzZWNvbmQgbG9va3Vw IGlzIGdvaW5nIHRvIGJlIGZhaXJseSBjb21tb24uDQoNCj4gSSBuZWdsZWN0ZWQgdG8gbWVudGlv biB0aGF0IHN1Y2Nlc3NmdWwgdXNlIG9mIGEgY29ubmVjdGlvbiBJRCBjYXVzZXMNCj4gdGhlIDUt dHVwbGUgdG8gYmUgYXNzaWduZWQgdG8gdGhhdCBjb25uZWN0aW9uOyB0aGVyZSdzIGEgdHJpY2sg dGhlcmUNCj4gaW4gdGhhdCB5b3UgbmVlZCB0byB3YXRjaCBmb3IgcmVvcmRlcmluZywgYnV0IGl0 IHNhdmVzIHRoZSBkb3VibGUNCj4gbG9va3VwLg0KDQpUaGUgdGhpbmcgdGhhdCBtYWtlcyBtZSBz bGlnaHRseSBuZXJ2b3VzIGlzIHRoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQNCmRvaW5nIHRyaWFs ICYgZXJyb3JzIChhdCBsZWFzdCBpbiBteSBkZWZpbml0aW9uIG9mIHRoZSB0ZXJtKSBhbmQgb3Ro ZXINCmltcGxlbWVudGF0aW9uIHRyaWNrcyB0byBhY2hpZXZlIHRoZSB2ZXJ5IHRyaXZpYWwgdGFz ayBvZiBwYXJzaW5nIGENCmJpbmFyeSBoZWFkZXIuICBUaGlzIGlzIHdoYXQgbWFrZXMgcmVkIGZs YWdzIHBvcCB1cCBhbmQgbWFrZXMgbWUNCnRoaW5rIHRoYXQgd2UgY2FuIGRvIGJldHRlci4NCg0K Q2hlZXJzDQoNCg== From nobody Thu Oct 19 07:22:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EF81342FD for ; Thu, 19 Oct 2017 07:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 HaZcVQX3_iHm for ; Thu, 19 Oct 2017 07:22:25 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC851342F1 for ; Thu, 19 Oct 2017 07:22:22 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9JEMJip031139; Thu, 19 Oct 2017 15:22:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+7FVhLKnkJmQPBVVVZ8cDruI6I+JmVYRP5hxqkVJRuk=; b=IbWjsFR6ynIS5XcXuhYy839zmvnNgr2xRYsmtXMjt2nHm3W9bDglIgBX1DoAG8siQ9kc r6abCjDL1A2KumLZ7AyRp7/kihzdJ9L16p97pI/JzYiQaYQq26jireG24EFTmKQcLonC lhd/djF0moaURxrzP9lJbcK6oFCmLdnIET7oxFw08klm9I2NFizF+MC48olA9fjGRR1S xRIC9yM91StaFO0FPGhzmf9FqBsrcyPUa7oywHW/9MbqUYKdKFirV9WIWVEmds5DYwmw h/G685SZWLSfYJXiUj1Wwmq2ww/9MiOi7wgjOpO2XbqJ4dMOqOb/dS+WiNVzNqKGpfiL KQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2dpa0cun9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 15:22:18 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9JEL39u032367; Thu, 19 Oct 2017 10:22:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dkdwufhsq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 10:22:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 10:22:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 19 Oct 2017 10:22:14 -0400 From: "Salz, Rich" To: Paul Turner , 'Paul Turner' , "Kaduk, Ben" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQA= Date: Thu, 19 Oct 2017 14:22:14 +0000 Message-ID: <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> In-Reply-To: <000501d348e5$1f273450$5d759cf0$@equio.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.65] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190198 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190198 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:22:27 -0000 PiAgICAgQ2FuIHlvdSBleHBsYWluIGhvdyBuYXRpb253aWRlIHdpcmV0YXBwaW5nIGlzIGdvaW5n IHRvIGJlIGVhc3kgd2l0aCB0aGlzIHBsYW4/IEFnYWluLCBFVkVSWSBzZXJ2ZXIgb3duZXIgd2ls bCBuZWVkIHRvIG9wdC1pbi4NCiAgIA0KSSBkaWRu4oCZdCBzYXkgZWFzeSwgSSBzYWlkIOKAmGVh c2llcuKAmQ0KDQoNCg== From nobody Thu Oct 19 07:23:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21345126D0C for ; Thu, 19 Oct 2017 07:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnYR-jy2xQXg for ; Thu, 19 Oct 2017 07:23:06 -0700 (PDT) Received: from mail.venafi.com (unknown [34.193.116.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E281342F1 for ; Thu, 19 Oct 2017 07:23:06 -0700 (PDT) Received: from SLC-EXG02.res.venafi.com (10.1.110.18) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 08:23:04 -0600 Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 08:23:03 -0600 Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 19 Oct 2017 08:23:03 -0600 From: Paul Turner To: "Salz, Rich" , Paul Turner , "Kaduk, Ben" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQDO0nP6IcKCRq1bnEFoblkG8dV0CgHq1icUpOTCoYCAAG+9gIAAANmAgAABFgD//5uPgA== Date: Thu, 19 Oct 2017 14:23:03 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> In-Reply-To: <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.115.210.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:23:07 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2FseiwgUmljaCBbbWFp bHRvOnJzYWx6QGFrYW1haS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE5LCAyMDE3 IDEwOjIyDQo+IFRvOiBQYXVsIFR1cm5lciA8cHR1cm5lckBlcXVpby5jb20+OyBQYXVsIFR1cm5l cg0KPiA8UEFVTC5UVVJORVJAdmVuYWZpLmNvbT47IEthZHVrLCBCZW4gPGJrYWR1a0Bha2FtYWku Y29tPjsNCj4gdGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbVExTXSBQdWJsaWNhdGlvbiBv ZiBkcmFmdC1yaHJkLXRscy10bHMxMy12aXNpYmlsaXR5LTAwDQo+IA0KPiA+ICAgICBDYW4geW91 IGV4cGxhaW4gaG93IG5hdGlvbndpZGUgd2lyZXRhcHBpbmcgaXMgZ29pbmcgdG8gYmUgZWFzeSB3 aXRoIHRoaXMNCj4gcGxhbj8gQWdhaW4sIEVWRVJZIHNlcnZlciBvd25lciB3aWxsIG5lZWQgdG8g b3B0LWluLg0KPiANCj4gSSBkaWRu4oCZdCBzYXkgZWFzeSwgSSBzYWlkIOKAmGVhc2llcuKAmQ0K PiANCkNhbiB5b3UgZXhwbGFpbiBob3cgaXQgaXMgZWFzaWVyPw0KDQo= From nobody Thu Oct 19 07:26:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCD91342FB for ; Thu, 19 Oct 2017 07:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 U1fmyxqtStJ5 for ; Thu, 19 Oct 2017 07:26:39 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30301342F2 for ; Thu, 19 Oct 2017 07:26:34 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9JEMMPI032761; Thu, 19 Oct 2017 15:26:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=gw29g9jG/KS+2pbBYLK3oSbEMEhe9CLMMI+sMJxMWwE=; b=RkxvaEPBvUmutjtGmeb9IYDNHdSpYkiwAxmd1rl2xaghaDlbUqKG+ud5vQDqhJI5IkMz QptBErhaVI8aKJumP4PJeJnwHojh7iutYo8cUHb1f5crQ3fRX975aFVmXUKGB7twLqU3 fw8ILnSV13lFNzpMCu7urMkoIOwiKW5aofeyqozaRYZMmmH3FkEPChQKIPoQ7Edesyrg 53V0lodseY1ANJQ6alccZccKSL4QBi1hQCxcqXSaTIlvpUYOHgTAV6/LBQRM2zHpOrqs kAJoCQj87Wr3yK0oR7nTHIGTpPcYR8F/tt2u4u77XsTqptvhVC+6ohInSjRI0vj19XLn Ug== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2dpg7dtk9v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 15:26:33 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9JEPd9F004242; Thu, 19 Oct 2017 10:26:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dkdwwap1j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 10:26:30 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 10:26:29 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 19 Oct 2017 10:26:29 -0400 From: "Salz, Rich" To: Paul Turner , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWA Date: Thu, 19 Oct 2017 14:26:29 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@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/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.65] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190199 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190198 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:26:40 -0000 DQogICAgPiBJIGRpZG7igJl0IHNheSBlYXN5LCBJIHNhaWQg4oCYZWFzaWVy4oCZDQogICAgPiAN CiAgICBDYW4geW91IGV4cGxhaW4gaG93IGl0IGlzIGVhc2llcj8NCiAgICANClRoZXJl4oCZcyBu byB3YXkgdG8gbGltaXQgaXQgdG8gdGhlIHVzZS1jYXNlIGl0IHdhcyBwdXRhdGl2ZWx5IGludGVu ZGVkIGZvci4gIFdlIG5vdyBoYXZlIGEgc2lnbmFsaW5nIG1lY2hhbmlzbSB0aGF0IHNheXMg4oCc YWxsb3cgaW50ZXJjZXB0aW9uLuKAnSAgRmlyZXdhbGxzIGNhbiBkcm9wIGNvbm5lY3Rpb25zIHdo ZXJlIHRoZSBjbGllbnQgZG9lc27igJl0IHNlbmQgdGhhdCBleHRlbnNpb24uIFRoZXJlZm9yZSB0 aGV5IGNhbiBmb3JjZSBvbmx5IHRhcHBhYmxlIFRMUyB0cmFmZmljLiBUaGlzIG1ha2VzIHRoZSBq b2IgZWFzaWVyLg0KDQpJIHRha2UgaXQgeW91IHdhbnQgdG8gc2VlIHRoaXMgZHJhZnQgYWRvcHRl ZD8NCg0KDQo= From nobody Thu Oct 19 07:37:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B127C1342F1 for ; Thu, 19 Oct 2017 07:37:21 -0700 (PDT) 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 p4rNJBKRDA6s for ; Thu, 19 Oct 2017 07:37:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9791E1342EC for ; Thu, 19 Oct 2017 07:37:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 43368BE49; Thu, 19 Oct 2017 15:37:17 +0100 (IST) 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 KyvU4T2b8IsT; Thu, 19 Oct 2017 15:37:17 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04B6DBE47; Thu, 19 Oct 2017 15:37:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508423837; bh=ru/Kzwd0RvmW/7Y9GfIe5qdo8KnyKVBG8Wz+scZGoN0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=PveyDJEe3WqbxLzeABtH3DpZyqeU2jNmRvPmotm3fBnNevphTjP8Efz1Fa9awWDTf 9WX/leVgxJqH6q9AJWUGzK8MV7QsmfFwBPaB/AnfNUU1fowuGjouYQIgcn6GE5DgM4 FeMX+uYT4SVS4pOkGxFmBj2KUTlPbSMoMDU7DY3o= To: Paul Turner , Benjamin Kaduk , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <496c8581-bb5c-49be-fd2a-8a6369b274e2@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 19 Oct 2017 15:37:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ANhiXXBPqxWXaFFvguST5qVwH6en8wvhF" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:37:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ANhiXXBPqxWXaFFvguST5qVwH6en8wvhF Content-Type: multipart/mixed; boundary="S1cG9om7FgrPHTIb8rxgL1GfKVlto7atv"; protected-headers="v1" From: Stephen Farrell To: Paul Turner , Benjamin Kaduk , "tls@ietf.org" Message-ID: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <496c8581-bb5c-49be-fd2a-8a6369b274e2@cs.tcd.ie> In-Reply-To: --S1cG9om7FgrPHTIb8rxgL1GfKVlto7atv Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 19/10/17 15:16, Paul Turner wrote: >=20 >=20 >> -----Original Message----- >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Thursday, October 19, 2017 09:07 >> To: Benjamin Kaduk ; tls@ietf.org >> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 >> >> >> Hiya, >> >> On 18/10/17 18:41, Benjamin Kaduk wrote: >>> P.S. I agree with Rich; can we try to defer these conversations until= >>> after 1.3 is actually published? >> >> FWIW, I also think it'd be a good plan if the chairs did that. I'm hap= py to >> oppose these ideas any time, but later is better than now, given this = would >> further distract us from 1.3. >=20 > I don't think this is a good plan. Why exactly? What here is so urgent that it needs to be haggled over before TLS1.3 is done? TLS1.3 is the major work item for which this WG is chartered, and breaking TLS is something that is outside this WG's charter entirely. I think you'd need a very good argument that any WG ought prioritise out-of-scope work at the expense of the main goal of the WG. S. >=20 >> >> S. >=20 --S1cG9om7FgrPHTIb8rxgL1GfKVlto7atv-- --ANhiXXBPqxWXaFFvguST5qVwH6en8wvhF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ6LiTAAoJEC88hzaAX42i8nMH/1o0RrCwTjJRET2LruSKzWrb 9eZSlw5ZQgKKS2m+x/uJwS+QMkSa2soqOaLHf1r5VSir+HlSFY0hEu832TXB8hZs EmTY2NCz/+aNruziqpeeAJqPmzY4WI0Og2Uw2/IcaMPSFH8j2GO2GZJ+xisWI8j0 mAuq1OIjxN5xDdycYfATlK/i+TNCQj7i9L9u1P2M9DQ26IWDyxNuoDFwrJVmOXvI zR/z3rxRfS4ZHfAt0IsmLn/YGkEbeP+d19uluKF7ubl5sRSwXJhln7IWmg61q+4P ysjwDh3pXdvNfFvaN1H6HdeskXjqHGuV0rWnK/cgt/y5wiDDH+amr4BLnOjBGbI= =z6Xh -----END PGP SIGNATURE----- --ANhiXXBPqxWXaFFvguST5qVwH6en8wvhF-- From nobody Thu Oct 19 07:37:51 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0728134921 for ; Thu, 19 Oct 2017 07:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FmtNWP3GCJ9 for ; Thu, 19 Oct 2017 07:37:49 -0700 (PDT) Received: from mail.venafi.com (unknown [34.193.116.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB55D1342F1 for ; Thu, 19 Oct 2017 07:37:49 -0700 (PDT) Received: from SLC-EXG02.res.venafi.com (10.1.110.18) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 08:37:47 -0600 Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 08:37:47 -0600 Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 19 Oct 2017 08:37:47 -0600 From: Paul Turner To: "Salz, Rich" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQDO0nP6IcKCRq1bnEFoblkG8dV0CgHq1icUpOTCoYCAAG+9gIAAANmAgAABFgD//5uPgIAAZaGA//+buEA= Date: Thu, 19 Oct 2017 14:37:47 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.115.210.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:37:51 -0000 DQoNCj4gDQo+IFRoZXJl4oCZcyBubyB3YXkgdG8gbGltaXQgaXQgdG8gdGhlIHVzZS1jYXNlIGl0 IHdhcyBwdXRhdGl2ZWx5IGludGVuZGVkIGZvci4gIFdlDQo+IG5vdyBoYXZlIGEgc2lnbmFsaW5n IG1lY2hhbmlzbSB0aGF0IHNheXMg4oCcYWxsb3cgaW50ZXJjZXB0aW9uLuKAnSAgRmlyZXdhbGxz IGNhbg0KPiBkcm9wIGNvbm5lY3Rpb25zIHdoZXJlIHRoZSBjbGllbnQgZG9lc27igJl0IHNlbmQg dGhhdCBleHRlbnNpb24uIFRoZXJlZm9yZSB0aGV5DQo+IGNhbiBmb3JjZSBvbmx5IHRhcHBhYmxl IFRMUyB0cmFmZmljLiBUaGlzIG1ha2VzIHRoZSBqb2IgZWFzaWVyLg0KPiANCg0KQ2FuIHlvdSBw bGVhc2UgYmUgbW9yZSBzcGVjaWZpYyBhYm91dCB0aGUgc2NlbmFyaW8ocykgeW91J3JlIGRlc2Ny aWJpbmc/IDEpIElzIHRoaXMgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiBzZXJ2ZXJzIHdpdGhp biB0aGUgbmF0aW9uIHN0YXRlJ3MgYm91bmRhcmllcyBhbmQgZG8gdGhleSBoYXZlIGNvbXBsZXRl IGNvbnRyb2wgb3ZlciB0aGUgb3duZXJzIG9mIHRob3NlIHNlcnZlcnMgKHRvdGFsaXRhcmlhbiBz dGF0ZSkuIDIpIElzIHRoaXMgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiBzZXJ2ZXJzIHdpdGhp biB0aGUgbmF0aW9uIHN0YXRlJ3MgYm91bmRhcmllcyBhbmQgZG8gdGhleSBub3QgaGF2ZSBjb21w bGV0ZSBjb250cm9sIG92ZXIgdGhlIG93bmVycyBvZiB0aG9zZSBzZXJ2ZXJzIChhbiBhcHBhcmVu dGx5IGRlbW9jcmF0aWMgc3RhdGUpLiAzKSBJcyB0aGlzIGZvciBjb21tdW5pY2F0aW9uIGJldHdl ZW4gc2VydmVycyBvdXRzaWRlIHRoZSBuYXRpb24gc3RhdGUncyBib3VuZGFyaWVzIGFuZCBkbyBu b3QgdGhleSBub3QgaGF2ZSBjb21wbGV0ZSBjb250cm9sIG92ZXIgdGhlIG93bmVycyBvZiB0aG9z ZSBzZXJ2ZXJzIChpbnRlcm5hdGlvbmFsIHNjZW5hcmlvKS4gQW5kLCBiYXNlZCBvbiB0aGUgc2Nl bmFyaW8sIGhvdyBpcyB0aGUgdGhpcmQgcGFydHkgZ29pbmcgdG8gY29lcmNlIHRoZSBzZXJ2ZXIg dmVuZG9ycyBpbnRvIGNvb3BlcmF0aW5nIChmb3IgMSwgdGhhdCBzZWVtcyBjbGVhciwgYnV0IHRo ZW4gdGhleSBoYXZlIGNvbXBsZXRlIGFjY2VzcyB0byBhbGwgY29tbXVuaWNhdGlvbnMgYW55d2F5 cyk/IEknbSBub3QganVzdCBhc2tpbmcgdGhlc2UgcXVlc3Rpb25zIHRvIGJlIGRpZmZpY3VsdC4g SSB3b3VsZCBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBzY2VuYXJpbyBpbiB3aGljaCBh IGNsaWVudCBhbmQgc2VydmVyIGNhbiBiZSBjb2VyY2VkIHNvIHRoYXQgaXQgaXMgcG9zc2libGUg dG8ganVkZ2UgImVhc2llciIgYWdhaW5zdCB0aGUgYWx0ZXJuYXRpdmVzLg0KDQo+IEkgdGFrZSBp dCB5b3Ugd2FudCB0byBzZWUgdGhpcyBkcmFmdCBhZG9wdGVkPw0KPiANCg0KWWVzIGJ1dCBJJ20g YWxzbyBrZWVwaW5nIG15IG1pbmQgb3BlbiB0byB1bmRlcnN0YW5kIGFsbCBvZiBwZXJzcGVjdGl2 ZXMgdG8gc2VlIGlmIHNvbWV0aGluZyB3b3VsZCBjaGFuZ2UgbXkgb3Bpbmlvbi4NCg0K From nobody Thu Oct 19 07:53:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006F51342EC for ; Thu, 19 Oct 2017 07:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mxmzBHf_BXHy for ; Thu, 19 Oct 2017 07:53:03 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E445C1332CA for ; Thu, 19 Oct 2017 07:53:02 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9JEqENT006328; Thu, 19 Oct 2017 15:53:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ggeF9cczSYXdcj+liGNo136LPK2sqIMc32JWSHwwWkU=; b=ogIKKliJwYHjEJrqkMkjOvBvZ7afmRCQxKWO0XXkV38Tv0OUJ0jEZ09ykKRA2ZPBp8Uh IHojcRtBmRcg2hg/Xd0XLJ3FeNyo5MYajcLtZ+UWUgDdLyi9gVYmywuslNZzkli728Kd RXSjL9lRo66HW1m6zNypmSRU8ov21jSE5tJW7B0NkwhudhmZrvXK6cOeFnOoqh9jbMNZ 9kFdvynPcQ8rZ4Tb996BG0aJgr6CXS6ATj5Wudm2F2u6tJDVbV7n395/ZFGsm4tbZx1b fBXGY9Fn4VmPgJ9icQlGCYZt4Yw3SsijwBwGJ6Ib76bDiJOd7YJ6v9qgUbFR2zq6i1dk 5g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2dnx28wtnh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 15:53:00 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9JEkHRL022000; Thu, 19 Oct 2017 10:47:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dkdwufmku-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 10:47:59 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 10:47:58 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 19 Oct 2017 10:47:58 -0400 From: "Salz, Rich" To: Paul Turner , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgA== Date: Thu, 19 Oct 2017 14:47:58 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@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/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.65] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190203 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190205 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:53:04 -0000 V2l0aCB0aGlzIGV4dGVuc2lvbiwgYW55IG1pZGRsZWJveCBhbnl3aGVyZSBjYW4gZHJvcCB0cmFm ZmljIHRoYXQgaXMgbm90IHRhcHBhYmxlLiAgUmVnYXJkbGVzcyBvZiB3aG8gY29udHJvbHMgdGhl IGNsaWVudHMgYW5kIHNlcnZlcnMsIHdlIGFyZSBub3cgZW5hYmxpbmcgZW50aXRpZXMgdG8gYmxv Y2sgdHJhZmZpYyB1bmxlc3MgeW91IGFjcXVpZXNjZS4gRm9yIGV4YW1wbGUsIGFuIGluZmxpZ2h0 IHdpZmkgY291bGQgdXNlIHRoaXMuICBNYXliZSwgdWx0aW1hdGVseSwgbWFueS9tb3N0IG9mIHRo ZSBzZXJ2ZXJzIHRoYXQgdGhlIHBhc3NlbmdlcnMgY29ubmVjdCB0byB3aWxsIG5vdCBzdXBwb3J0 IGl0LCBidXQgc29tZSBtaWdodC4NCg0KDQoNCg== From nobody Thu Oct 19 08:06:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC54134932 for ; Thu, 19 Oct 2017 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRlNRehG-Yfm for ; Thu, 19 Oct 2017 08:06:41 -0700 (PDT) Received: from mail.venafi.com (unknown [34.193.116.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AE9134939 for ; Thu, 19 Oct 2017 08:06:40 -0700 (PDT) Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 09:06:38 -0600 Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG01.res.venafi.com (10.1.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 09:06:37 -0600 Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 19 Oct 2017 09:06:37 -0600 From: Paul Turner To: "Salz, Rich" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQDO0nP6IcKCRq1bnEFoblkG8dV0CgHq1icUpOTCoYCAAG+9gIAAANmAgAABFgD//5uPgIAAZaGA//+buECAAGpJAIAABTXQ Date: Thu, 19 Oct 2017 15:06:37 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.115.210.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 15:06:42 -0000 >=20 > With this extension, any middlebox anywhere can drop traffic that is not > tappable. Regardless of who controls the clients and servers, we are now > enabling entities to block traffic unless you acquiesce. For example, an = inflight > wifi could use this. Maybe, ultimately, many/most of the servers that th= e > passengers connect to will not support it, but some might. >=20 Can't any middlebox block traffic today if the client doesn't agree to trus= t its CA? If a middlebox drops traffic because the extension was not includ= ed, there will be no indication to the client that it was dropped because t= hey didn't include the extension. If the middlebox does display a page back= to the client saying "You have to turn on TLS-Visibility so that we can we= can look at traffic for a server that we have control over but don't want = to get the data from this directly.", how is that different than "You have = to trust our CA in order to communicate with this server so we can route yo= u through our reverse proxy. Please download our CA root from the following= location and install it."? The second seems much easier in terms of scenarios 2 and 3 from my previous= message. Paul=20 From nobody Thu Oct 19 08:16:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D67613219C for ; Thu, 19 Oct 2017 08:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sWVfXzoMQk3w for ; Thu, 19 Oct 2017 08:16:20 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE19134941 for ; Thu, 19 Oct 2017 08:16:20 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9JFC1lD003137; Thu, 19 Oct 2017 16:16:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=GouKvKxr0Q+giHK9dADXoNmkFMEHyB3kI+ZJfY9JlCM=; b=PVW2ajj2PDXr+WOEf8yD4sZ48rLv6+oxwkdDwuftcGLbQEHBQN1MZntLLgPtOdxjYy5C QhTAvDbn+9kFFNdzBnuuKMWLGr1owfpGrMLgcWgitZ4aucfj9e4Z54xidsTS3jDqzO02 C21T/ZyFGF85eUajdyTReNnLUjekcKBqsuUWFl69VJc9DEgmAMS/EqRPbVNBeJ+idVMy BPRp16LVFWDvtL0iASAhjSF23xhTE3AZnR+N7HQvzm1WDQ9KE94S3kfPZzrEwAmI8UNw pf6D9grBnjsRvOjezb0CrcW1/xv5xVYxu+bXjr4SqHzZHrpMWy5YkxZq/wJTYOW7EKOR kw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2dpa0cuug4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 16:16:19 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9JFFgfr006999; Thu, 19 Oct 2017 11:16:18 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dkdwufpwy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 11:16:18 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 11:16:17 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 19 Oct 2017 11:16:17 -0400 From: "Salz, Rich" To: Paul Turner , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4A= Date: Thu, 19 Oct 2017 15:16:17 +0000 Message-ID: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@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/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.65] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190211 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190210 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 15:16:21 -0000 VGhleSBjYW4gYWxyZWFkeSBibG9jayB0cmFmZmljIGJhc2VkIG9uIElQIGFkZHJlc3MuICBUaGF0 4oCZcyBzaW5nbGUtcG9pbnQgYmxvY2tpbmcuICBCZWluZyBhYmxlIHRvIGJsb2NrIGJhc2VkIG9u IHRoZSBjbGllbnTigJlzIHdpbGxpbmduZXNzIHRvIGxldCB0aGVpciB0cmFmZmljIGJlIGludGVy Y2VwdGlvbiBpcyBhIHdob2xlIGFkZGl0aW9uYWwgY2xhc3MgYW5kIGl0IGFsc28gaW5kaWNhdGVz IHRoYXQgdGhlIGNsaWVudCBpcyB3aWxsaW5nIHRvIGxldCB0aGVpciB0cmFmZmljIGJlIGludGVy Y2VwdGVkLiAgVGhlIHR3byB0aGluZ3MgYXJlIHZlcnkgdmVyeSB2ZXJ5IGRpZmZlcmVudC4NCg0K DQoNCg== From nobody Thu Oct 19 08:20:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A78C1342EE for ; Thu, 19 Oct 2017 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbMogaE7tUg0 for ; Thu, 19 Oct 2017 08:20:06 -0700 (PDT) Received: from mail.venafi.com (unknown [34.193.116.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415F5134211 for ; Thu, 19 Oct 2017 08:20:06 -0700 (PDT) Received: from SLC-EXG02.res.venafi.com (10.1.110.18) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 09:20:00 -0600 Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 09:19:59 -0600 Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 19 Oct 2017 09:19:59 -0600 From: Paul Turner To: "Salz, Rich" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQDO0nP6IcKCRq1bnEFoblkG8dV0CgHq1icUpOTCoYCAAG+9gIAAANmAgAABFgD//5uPgIAAZaGA//+buECAAGpJAIAABTXQgAACtID//5vkEA== Date: Thu, 19 Oct 2017 15:19:58 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> In-Reply-To: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.115.210.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 15:20:08 -0000 DQoNCj4gDQo+IFRoZXkgY2FuIGFscmVhZHkgYmxvY2sgdHJhZmZpYyBiYXNlZCBvbiBJUCBhZGRy ZXNzLiAgVGhhdOKAmXMgc2luZ2xlLXBvaW50DQo+IGJsb2NraW5nLiAgQmVpbmcgYWJsZSB0byBi bG9jayBiYXNlZCBvbiB0aGUgY2xpZW504oCZcyB3aWxsaW5nbmVzcyB0byBsZXQgdGhlaXINCj4g dHJhZmZpYyBiZSBpbnRlcmNlcHRpb24gaXMgYSB3aG9sZSBhZGRpdGlvbmFsIGNsYXNzIGFuZCBp dCBhbHNvIGluZGljYXRlcyB0aGF0IHRoZQ0KPiBjbGllbnQgaXMgd2lsbGluZyB0byBsZXQgdGhl aXIgdHJhZmZpYyBiZSBpbnRlcmNlcHRlZC4gIFRoZSB0d28gdGhpbmdzIGFyZSB2ZXJ5IHZlcnkN Cj4gdmVyeSBkaWZmZXJlbnQuDQo+IA0KDQpDYW4geW91IGV4cGxhaW4gdGhlIGNvbXBhcmlzb24g dGhhdCBJIGJyb3VnaHQgdXAgcmVnYXJkaW5nIHRydXN0aW5nIHRoZSBDQT8gVGhhdCBpcyByZWxh dGVkIHRvICIgdGhlIGNsaWVudOKAmXMgd2lsbGluZ25lc3MgdG8gbGV0IHRoZWlyIHRyYWZmaWMg YmUgaW50ZXJjZXB0ZWQiLg0KDQo= From nobody Thu Oct 19 08:35:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B60134880 for ; Thu, 19 Oct 2017 08:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 kEeMKLjKWxcJ for ; Thu, 19 Oct 2017 08:35:22 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEAA134211 for ; Thu, 19 Oct 2017 08:35:22 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9JFW7fQ022477; Thu, 19 Oct 2017 16:35:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=BRBt2x4z41SXu5tpZRD3PFRmHZZL74TvA9ZX22CpH3E=; b=cHi887HlP5nlNtJKnf/mXhgjEsDUUSn5qUMYuIjjZEz9BaSMXPeSSMemgzcNCfZHYJGV 9tf4VlorOE4zs1uLDHLjrb+YjdYH0e7S6JP59gBBtc6jCebarOQZ4nHu1/Lq1ABfipdD 5/QoQ1e/7XHypIkIaX3Kv4NvpUIeAiI0zOfEYtvqR2fZGG7Rn5mjuHd8/44XCwQVwXOj xhDZBVHBZygWhgSR7QpoYFbBNumalaWqWtqcuTmNzgxhQ+BivnrhbNTe/KW/+hMJrzye ox+WMRv6IvNJEv3qeQ1lfOX7FZbN3+qHYF2rJRhglFOA6SS/e+KQ2nLWIPizqgs5ku0M sg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2dnx5t5p6d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 16:35:20 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9JFVBpU020275; Thu, 19 Oct 2017 11:35:19 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dkdwufru7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 11:35:18 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 11:35:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 19 Oct 2017 11:35:16 -0400 From: "Salz, Rich" To: Paul Turner , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWA Date: Thu, 19 Oct 2017 15:35:16 +0000 Message-ID: <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@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/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.65] Content-Type: text/plain; charset="utf-8" Content-ID: <5DDAA38F56D5674A85810981980ECAB7@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190214 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190215 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 15:35:23 -0000 ICAgIA0K4p6iICAgICBDYW4geW91IGV4cGxhaW4gdGhlIGNvbXBhcmlzb24gdGhhdCBJIGJyb3Vn aHQgdXAgcmVnYXJkaW5nIHRydXN0aW5nIHRoZSBDQT8gVGhhdCBpcyByZWxhdGVkIHRvICIgdGhl IGNsaWVudOKAmXMgd2lsbGluZ25lc3MgdG8gbGV0IHRoZWlyIHRyYWZmaWMgYmUgaW50ZXJjZXB0 ZWQiLg0KICAgIA0KICAgIA0KU3VidmVydGluZyBvbmUgQ0EgY3V0cyBhY3Jvc3MgYSBsYXJnZSBz Y2FsZSBvZiBJbnRlcm5ldCB0cmFmZmljIGFuZCBtaWdodCBiZSBub3RpY2VkIG9yIGNhbiBiZSBy b3V0ZWQgYXJvdW5kLiAgQ2VydGlmaWNhdGUgdHJhbnNwYXJlbmN5IGhlbHBzIHByZXZlbnQgYSBz aW5nbGUgQ0EgZnJvbSBiZWluZyBjb2VyY2VkIGludG8gbWlzaXNzdWFuY2UuICBXaXRoIHRoaXMg ZXh0ZW5zaW9uLCBzb21lb25lIGRvZXNu4oCZdCBoYXZlIHRvIGNvZXJjZSBhIENBIG9yIGZvcmNl IHZpY3RpbXMgdG8gdHJ1c3QgYSBuZXcgQ0EuICBJbnN0ZWFkIHRoZXkgaGF2ZSB0byBnYWluIHRo ZSBjb29wZXJhdGlvbiBvZiB0aGUgb3JpZ2luKHMpIHRoZXkgYXJlIGludGVyZXN0ZWQgaW4uICBG dXJ0aGVyLCBpZiB5b3UgbWl4IGluIGEgY29lcmNlZC9mb3JjZS10cnVzdGVkIENBLCB5b3UgZG9u 4oCZdCBldmVuIG5lZWQgdGhlIG9yaWdpbuKAmXMgY29vcGVyYXRpb24uDQoNCg0KDQo= From nobody Thu Oct 19 10:07:26 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C437D134231 for ; Thu, 19 Oct 2017 10:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUnId-HynMAy for ; Thu, 19 Oct 2017 10:07:25 -0700 (PDT) Received: from mail.venafi.com (unknown [34.193.116.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFE3134228 for ; Thu, 19 Oct 2017 10:07:25 -0700 (PDT) Received: from SLC-EXG02.res.venafi.com (10.1.110.18) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 11:07:22 -0600 Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 11:07:21 -0600 Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 19 Oct 2017 11:07:21 -0600 From: Paul Turner To: "Salz, Rich" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQDO0nP6IcKCRq1bnEFoblkG8dV0CgHq1icUpOTCoYCAAG+9gIAAANmAgAABFgD//5uPgIAAZaGA//+buECAAGpJAIAABTXQgAACtID//5vkEAANLUoAAAM3PJA= Date: Thu, 19 Oct 2017 17:07:21 +0000 Message-ID: <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> In-Reply-To: <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.115.210.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:07:26 -0000 DQoNCj4gDQo+IFN1YnZlcnRpbmcgb25lIENBIGN1dHMgYWNyb3NzIGEgbGFyZ2Ugc2NhbGUgb2Yg SW50ZXJuZXQgdHJhZmZpYyBhbmQgbWlnaHQgYmUNCj4gbm90aWNlZCBvciBjYW4gYmUgcm91dGVk IGFyb3VuZC4gIA0KDQpXaXRoIHJlc3BlY3QgdG8gImJlIG5vdGljZWQiLCBmb3JjaW5nIGNsaWVu dHMgdG8gb3B0LWluIHNlZW1zIGxpa2UgaXQgd291bGQgY2xlYXJseSBiZSBub3RpY2VkLiBNeSB1 bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHlvdSB3ZXJlIHNheWluZyB0aGF0IHRoZSBtaWRkbGVib3gg Y291bGQgYmxvY2sgdHJhZmZpYy4gVGhhdCBzZWVtcyBpbiBjb25mbGljdCB3aXRoIHlvdXIgc3Rh dGVtZW50IHRoYXQgdGhleSBjYW4gYmUgInJvdXRlZCBhcm91bmQiLiANCg0KPkNlcnRpZmljYXRl IHRyYW5zcGFyZW5jeSBoZWxwcyBwcmV2ZW50IGENCj4gc2luZ2xlIENBIGZyb20gYmVpbmcgY29l cmNlZCBpbnRvIG1pc2lzc3VhbmNlLiAgDQoNCkl0IHNlZW1zIGxpa2UgYSBtaWRkbGVib3ggdGhh dCBpcyBhYmxlIHRvIGRlbnkgdHJhZmZpYyAoaGFzIHRoYXQgbGV2ZWwgb2YgcG93ZXIsIHdvdWxk IHNpbXBseSB1c2UgdGhlaXIgb3duIENBIGFuZCBmb3JjZSB0cnVzdCBvZiB0aGF0KQ0KDQo+V2l0 aCB0aGlzIGV4dGVuc2lvbiwgc29tZW9uZQ0KPiBkb2VzbuKAmXQgaGF2ZSB0byBjb2VyY2UgYSBD QSBvciBmb3JjZSB2aWN0aW1zIHRvIHRydXN0IGEgbmV3IENBLiAgSW5zdGVhZCB0aGV5DQo+IGhh dmUgdG8gZ2FpbiB0aGUgY29vcGVyYXRpb24gb2YgdGhlIG9yaWdpbihzKSB0aGV5IGFyZSBpbnRl cmVzdGVkIGluLiAgDQoNCkdhaW5pbmcgdGhlIGNvb3BlcmF0aW9uIG9mIHRoZSBzZXJ2ZXJzIChv cmlnaW5zKSBzZWVtcyByZWxldmFudC4gSWYgdGhleSBnZXQgdGhlIGNvb3BlcmF0aW9uIG9mIHRo ZSBzZXJ2ZXJzLCB0aGV5IGNhbiBzaW1wbHkgZ2V0IHRoZSBkYXRhIGRpcmVjdGx5IGZyb20gdGhl bS4gQnV0LCBhZ2FpbiwgdGhleSBhbHNvIGhhdmUgdG8gZ2V0IHRoZSBjb29wZXJhdGlvbiBvZiB0 aGUgY2xpZW50cy4gDQoNCklmIGEgbWlkZGxlYm94IGhhcyBzdWZmaWNpZW50IHBvd2VyIHRvIGJs b2NrIHRyYWZmaWMsIGZvcmNlIGNsaWVudHMgaW50byBvcHRpbmcgaW4sIGFuZCBjb2VyY2Ugc2Vy dmVycyBpbnRvIG9wdGluZyBpbiwgaXQgc2VlbXMgbGlrZSB0aGV5IGhhdmUgc3VmZmljaWVudCBh bHRlcm5hdGl2ZSBvcHRpb25zIHRoYXQgYXJlIG9mIGVxdWl2YWxlbnQgZWZmb3J0ICgiZWFzZSIp Lg0KDQoNCg0K From nobody Thu Oct 19 10:12:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF2D134300 for ; Thu, 19 Oct 2017 10:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 kzshaScYy8ew for ; Thu, 19 Oct 2017 10:12:16 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id C76481342FC for ; Thu, 19 Oct 2017 10:12:15 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v9JHCCTK006435; Thu, 19 Oct 2017 13:12:12 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Paul Turner CC: "Salz, Rich" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO713gKFaj/ze3UaJfDxWNuaqP6LqPDwAgAFTKoCAAAWQgIAAANiAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAFZAA== Date: Thu, 19 Oct 2017 17:12:11 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> In-Reply-To: <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-B3B25DAC-787D-4CC1-81DD-692662DAB562"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190236 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:12:30 -0000 --Apple-Mail-B3B25DAC-787D-4CC1-81DD-692662DAB562 Content-Type: multipart/alternative; boundary=Apple-Mail-6B036C2C-0171-4BD2-931B-AB1D1EF6A318 Content-Transfer-Encoding: 7bit --Apple-Mail-6B036C2C-0171-4BD2-931B-AB1D1EF6A318 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: base64 SWYgdGhvc2UgbWlkZGxlYm94ZXMgYWxyZWFkeSBoYXZlIHN1ZmZpY2llbnQgYWx0ZXJuYXRpdmUg b3B0aW9ucywgd2h5IGRvIHdlIHNwZW5kIHRpbWUgZGlzY3Vzc2luZyB0aGlzIGRyYWZ0PyBXaHkg ZG8gd2UgbmVlZCB0byBhZGQgeWV0IGFub3RoZXIgYWx0ZXJuYXRpdmUgZm9yIHRoZW0/DQoNClJl Z2FyZHMsDQpVcmkNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIE9jdCAxOSwgMjAxNywg YXQgMTM6MDgsIFBhdWwgVHVybmVyIDxQQVVMLlRVUk5FUkB2ZW5hZmkuY29tPiB3cm90ZToNCj4g DQo+IA0KPiANCj4+IA0KPj4gU3VidmVydGluZyBvbmUgQ0EgY3V0cyBhY3Jvc3MgYSBsYXJnZSBz Y2FsZSBvZiBJbnRlcm5ldCB0cmFmZmljIGFuZCBtaWdodCBiZQ0KPj4gbm90aWNlZCBvciBjYW4g YmUgcm91dGVkIGFyb3VuZC4gIA0KPiANCj4gV2l0aCByZXNwZWN0IHRvICJiZSBub3RpY2VkIiwg Zm9yY2luZyBjbGllbnRzIHRvIG9wdC1pbiBzZWVtcyBsaWtlIGl0IHdvdWxkIGNsZWFybHkgYmUg bm90aWNlZC4gTXkgdW5kZXJzdGFuZGluZyB3YXMgdGhhdCB5b3Ugd2VyZSBzYXlpbmcgdGhhdCB0 aGUgbWlkZGxlYm94IGNvdWxkIGJsb2NrIHRyYWZmaWMuIFRoYXQgc2VlbXMgaW4gY29uZmxpY3Qg d2l0aCB5b3VyIHN0YXRlbWVudCB0aGF0IHRoZXkgY2FuIGJlICJyb3V0ZWQgYXJvdW5kIi4gDQo+ IA0KPj4gQ2VydGlmaWNhdGUgdHJhbnNwYXJlbmN5IGhlbHBzIHByZXZlbnQgYQ0KPj4gc2luZ2xl IENBIGZyb20gYmVpbmcgY29lcmNlZCBpbnRvIG1pc2lzc3VhbmNlLiAgDQo+IA0KPiBJdCBzZWVt cyBsaWtlIGEgbWlkZGxlYm94IHRoYXQgaXMgYWJsZSB0byBkZW55IHRyYWZmaWMgKGhhcyB0aGF0 IGxldmVsIG9mIHBvd2VyLCB3b3VsZCBzaW1wbHkgdXNlIHRoZWlyIG93biBDQSBhbmQgZm9yY2Ug dHJ1c3Qgb2YgdGhhdCkNCj4gDQo+PiBXaXRoIHRoaXMgZXh0ZW5zaW9uLCBzb21lb25lDQo+PiBk b2VzbpJ0IGhhdmUgdG8gY29lcmNlIGEgQ0Egb3IgZm9yY2UgdmljdGltcyB0byB0cnVzdCBhIG5l dyBDQS4gIEluc3RlYWQgdGhleQ0KPj4gaGF2ZSB0byBnYWluIHRoZSBjb29wZXJhdGlvbiBvZiB0 aGUgb3JpZ2luKHMpIHRoZXkgYXJlIGludGVyZXN0ZWQgaW4uICANCj4gDQo+IEdhaW5pbmcgdGhl IGNvb3BlcmF0aW9uIG9mIHRoZSBzZXJ2ZXJzIChvcmlnaW5zKSBzZWVtcyByZWxldmFudC4gSWYg dGhleSBnZXQgdGhlIGNvb3BlcmF0aW9uIG9mIHRoZSBzZXJ2ZXJzLCB0aGV5IGNhbiBzaW1wbHkg Z2V0IHRoZSBkYXRhIGRpcmVjdGx5IGZyb20gdGhlbS4gQnV0LCBhZ2FpbiwgdGhleSBhbHNvIGhh dmUgdG8gZ2V0IHRoZSBjb29wZXJhdGlvbiBvZiB0aGUgY2xpZW50cy4gDQo+IA0KPiBJZiBhIG1p ZGRsZWJveCBoYXMgc3VmZmljaWVudCBwb3dlciB0byBibG9jayB0cmFmZmljLCBmb3JjZSBjbGll bnRzIGludG8gb3B0aW5nIGluLCBhbmQgY29lcmNlIHNlcnZlcnMgaW50byBvcHRpbmcgaW4sIGl0 IHNlZW1zIGxpa2UgdGhleSBoYXZlIHN1ZmZpY2llbnQgYWx0ZXJuYXRpdmUgb3B0aW9ucyB0aGF0 IGFyZSBvZiBlcXVpdmFsZW50IGVmZm9ydCAoImVhc2UiKS4NCj4gDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVExTIG1haWxpbmcg bGlzdA0KPiBUTFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90bHMNCg== --Apple-Mail-6B036C2C-0171-4BD2-931B-AB1D1EF6A318 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPklmIHRob3NlIG1p ZGRsZWJveGVzIGFscmVhZHkgaGF2ZSBzdWZmaWNpZW50IGFsdGVybmF0aXZlIG9wdGlvbnMsIHdo eSBkbyB3ZSBzcGVuZCB0aW1lIGRpc2N1c3NpbmcgdGhpcyBkcmFmdD8gV2h5IGRvIHdlIG5lZWQg dG8gYWRkIHlldCBhbm90aGVyIGFsdGVybmF0aXZlIGZvciB0aGVtPzxicj48YnI+PGRpdiBpZD0i QXBwbGVNYWlsU2lnbmF0dXJlIj5SZWdhcmRzLDxkaXY+VXJpPC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+PC9kaXY+PGRpdj48YnI+T24gT2N0IDE5LCAy MDE3LCBhdCAxMzowOCwgUGF1bCBUdXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpQQVVMLlRVUk5F UkB2ZW5hZmkuY29tIj5QQVVMLlRVUk5FUkB2ZW5hZmkuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxi cj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPjwvc3Bhbj48YnI+PHNw YW4+PC9zcGFuPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5TdWJ2ZXJ0aW5nIG9uZSBD QSBjdXRzIGFjcm9zcyBhIGxhcmdlIHNjYWxlIG9mIEludGVybmV0IHRyYWZmaWMgYW5kIG1pZ2h0 IGJlPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ bm90aWNlZCBvciBjYW4gYmUgcm91dGVkIGFyb3VuZC4gJm5ic3A7PC9zcGFuPjxicj48L2Jsb2Nr cXVvdGU+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5XaXRoIHJlc3BlY3QgdG8gImJlIG5vdGljZWQi LCBmb3JjaW5nIGNsaWVudHMgdG8gb3B0LWluIHNlZW1zIGxpa2UgaXQgd291bGQgY2xlYXJseSBi ZSBub3RpY2VkLiBNeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHlvdSB3ZXJlIHNheWluZyB0aGF0 IHRoZSBtaWRkbGVib3ggY291bGQgYmxvY2sgdHJhZmZpYy4gVGhhdCBzZWVtcyBpbiBjb25mbGlj dCB3aXRoIHlvdXIgc3RhdGVtZW50IHRoYXQgdGhleSBjYW4gYmUgInJvdXRlZCBhcm91bmQiLiA8 L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ Q2VydGlmaWNhdGUgdHJhbnNwYXJlbmN5IGhlbHBzIHByZXZlbnQgYTwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPnNpbmdsZSBDQSBmcm9tIGJlaW5n IGNvZXJjZWQgaW50byBtaXNpc3N1YW5jZS4gJm5ic3A7PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5JdCBzZWVtcyBsaWtlIGEgbWlkZGxlYm94IHRoYXQgaXMg YWJsZSB0byBkZW55IHRyYWZmaWMgKGhhcyB0aGF0IGxldmVsIG9mIHBvd2VyLCB3b3VsZCBzaW1w bHkgdXNlIHRoZWlyIG93biBDQSBhbmQgZm9yY2UgdHJ1c3Qgb2YgdGhhdCk8L3NwYW4+PGJyPjxz cGFuPjwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+V2l0aCB0aGlzIGV4 dGVuc2lvbiwgc29tZW9uZTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPmRvZXNu4oCZdCBoYXZlIHRvIGNvZXJjZSBhIENBIG9yIGZvcmNlIHZpY3Rp bXMgdG8gdHJ1c3QgYSBuZXcgQ0EuICZuYnNwO0luc3RlYWQgdGhleTwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmhhdmUgdG8gZ2FpbiB0aGUgY29v cGVyYXRpb24gb2YgdGhlIG9yaWdpbihzKSB0aGV5IGFyZSBpbnRlcmVzdGVkIGluLiAmbmJzcDs8 L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPkdhaW5pbmcgdGhl IGNvb3BlcmF0aW9uIG9mIHRoZSBzZXJ2ZXJzIChvcmlnaW5zKSBzZWVtcyByZWxldmFudC4gSWYg dGhleSBnZXQgdGhlIGNvb3BlcmF0aW9uIG9mIHRoZSBzZXJ2ZXJzLCB0aGV5IGNhbiBzaW1wbHkg Z2V0IHRoZSBkYXRhIGRpcmVjdGx5IGZyb20gdGhlbS4gQnV0LCBhZ2FpbiwgdGhleSBhbHNvIGhh dmUgdG8gZ2V0IHRoZSBjb29wZXJhdGlvbiBvZiB0aGUgY2xpZW50cy4gPC9zcGFuPjxicj48c3Bh bj48L3NwYW4+PGJyPjxzcGFuPklmIGEgbWlkZGxlYm94IGhhcyBzdWZmaWNpZW50IHBvd2VyIHRv IGJsb2NrIHRyYWZmaWMsIGZvcmNlIGNsaWVudHMgaW50byBvcHRpbmcgaW4sIGFuZCBjb2VyY2Ug c2VydmVycyBpbnRvIG9wdGluZyBpbiwgaXQgc2VlbXMgbGlrZSB0aGV5IGhhdmUgc3VmZmljaWVu dCBhbHRlcm5hdGl2ZSBvcHRpb25zIHRoYXQgYXJlIG9mIGVxdWl2YWxlbnQgZWZmb3J0ICgiZWFz ZSIpLjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPjwv c3Bhbj48YnI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188L3NwYW4+PGJyPjxzcGFuPlRMUyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxh IGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxz cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48L3NwYW4+PGJyPjwv ZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-6B036C2C-0171-4BD2-931B-AB1D1EF6A318-- --Apple-Mail-B3B25DAC-787D-4CC1-81DD-692662DAB562 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcxMDE5MTcxMjEwWjAjBgkqhkiG9w0BCQQxFgQUSrjIlV1CVi7Pnh2Lw5xdNKKAmFIwbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBAHC7frYa69lwDAU7IALpvoUfP69CFR0zFK5jK79nlEnRVkPy+UKDDnbG9i6GYU7D QnagFtCn6Wyz6nwvhYN8oysNBolVQpr9+05yUjEmXnn9UDu9PEoalV0b0jFbQI5cPnZgpajihPGk tZIyJGjJLmDzO/QtAAcyqyXQ7wWUQci2weOMYWhgnN9s6BY8+LmnCW46NP6iiN4cWwtPFoKtm3NR wCmiZPSDIRQ8qwpJlnf3p1mSnBhI4Naxfnx3LJv6aoEfT7OO4JfZmHQgVUtdODI7Gd2so589ISfp uR/5z33GivH2bwfBjdJ4j/+yS2uB4voVjZ48OvpvTOWZur9D+W8AAAAAAAA= --Apple-Mail-B3B25DAC-787D-4CC1-81DD-692662DAB562-- From nobody Thu Oct 19 10:15:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4369D132CE7 for ; Thu, 19 Oct 2017 10:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7GWH9BkqWIl for ; Thu, 19 Oct 2017 10:15:05 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A3B1321A7 for ; Thu, 19 Oct 2017 10:15:05 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id l194so11224239qke.13 for ; Thu, 19 Oct 2017 10:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rRhliPpaskRabGbO21CfobDrb//g/fpwY6IHH8UrLDE=; b=SEoqtZbeXc5X5kqJFsYjDf9RT9X2yKRAjy2JfnpjyJurVq0VDofmw+91vAFz9l2AxK g4NI2kf2tBt+/P1nHglYGIvtdF41q6hv1oI79DXKark9MG8KCgLM5/3q3kvcYGkoChmB 0NXGQgm9SDeha8zYH6XBEQOwvGFL352QSG9zPfuNGRV5wva0FkU1l2rFN226UDiyq1Vx /xJeeNTfmbYxvEfwH7ieFpAMpK4vDnGtmd3DJsoYdV3zc9IHCY2IrZSnD17MwOf1uXJS WUcVmnCaKHuj5KCZiJgFM8Ki/wxJKs7QXbL4813inemooIOEHSVNGE46k6V3cA0cRaDS SMFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rRhliPpaskRabGbO21CfobDrb//g/fpwY6IHH8UrLDE=; b=VldZMpqFrfDaRTn8ejgqumIZPdzQQ77s2SRfK3T+U9wDaHaX5HLaXjZVWI6W8VqJIx EEbOMYEVvbcjlXDH+/lSdggOzhMKSOYNQVqsGVcJd5r8owzKB5doo825ygiMMspS4hJ1 fHqZWLYRH7963oZX21EIzqigIYBctoHQTU7T5Gi7rqgAEsS+alTwT3Pl4uK4YAB9kOEE Zsaa2MsVKZEM3C5FEt5N7KdsbrEgt74P6pYrgBTTax7kEur0tVR9xtcah+fIIBGQ+wp7 iS462cvdmXpfapcUde65XrZuNe43x9dpqoYKSWycEEhMNhWSfIdx6khOToejUVVTN2Ti rhoQ== X-Gm-Message-State: AMCzsaWSVYucuY4+2Vs0PixwiOvDaIs2fRfF0P+7v1rheh7najZ9shyK wIQ7wfBDp8O4YpYTcXE9lr+EabNRfg4= X-Google-Smtp-Source: ABhQp+S5aygJ4kOK+XxVMm/z9YjhX7Nvbt/X54cRzNrNTjzRnZar/K0Wj8IWbDKRuCFnm58dReRaSw== X-Received: by 10.55.204.77 with SMTP id r74mr3053546qki.25.1508433304651; Thu, 19 Oct 2017 10:15:04 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id z207sm2547446qka.52.2017.10.19.10.15.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 10:15:03 -0700 (PDT) From: Ted Lemon Message-Id: <85C0030A-CD39-470E-9B19-7DD909C65D13@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6E617ABE-F8BC-43C4-84F5-8E860EEB8629" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 19 Oct 2017 13:15:02 -0400 In-Reply-To: Cc: Paul Turner , "tls@ietf.org" To: "Blumenthal, Uri - 0553 - MITLL" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:15:07 -0000 --Apple-Mail=_6E617ABE-F8BC-43C4-84F5-8E860EEB8629 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 19, 2017, at 1:12 PM, Blumenthal, Uri - 0553 - MITLL = wrote: > If those middleboxes already have sufficient alternative options, why = do we spend time discussing this draft? Why do we need to add yet = another alternative for them? Indeed, if this proposal were equivalent to CA forcing, then the = solution to the problem this proposal purports to solve would be CA = forcing. The reason this proposal is preferred is that it's easier and = less apparently invasive than CA forcing. Making less good crypto have = an obviously less good UI is a good thing. --Apple-Mail=_6E617ABE-F8BC-43C4-84F5-8E860EEB8629 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 19, 2017, at 1:12 PM, Blumenthal, Uri - 0553 - MITLL = <uri@ll.mit.edu> = wrote:
If those middleboxes already = have sufficient alternative options, why do we spend time discussing = this draft? Why do we need to add yet another alternative for = them?

Indeed, if this proposal were equivalent to CA forcing, then = the solution to the problem this proposal purports to solve would be CA = forcing. The reason this proposal is preferred is that it's easier and less apparently = invasive than CA forcing.  Making less good crypto have an = obviously less good UI is a good thing.

= --Apple-Mail=_6E617ABE-F8BC-43C4-84F5-8E860EEB8629-- From nobody Thu Oct 19 10:27:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40165132CE7 for ; Thu, 19 Oct 2017 10:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mDVRl3HsiuGn for ; Thu, 19 Oct 2017 10:26:59 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59369134302 for ; Thu, 19 Oct 2017 10:26:59 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9JHQuPL023477; Thu, 19 Oct 2017 18:26:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=u5maS+Em3MyaHWZUnGuCKsGGGKxot8axzF0hEbSmzOQ=; b=bjQQMkWw+mYqjBgzQRsB5284yrsetvcRgP1QDQ7bryXPfMsO3p8rnI+cDYU56xrGeZdv yKQJnPWNlmfZMe3bTSTlNjzEUrCQB0z6fGxwb7v/6QpaJJLTCY0hByGESozcdWFpEug+ bwlV6MKc9uEA3eeEtV2QBkfYQ//wtNBpJJlhEPYPEqmZt9qw8+iesSBlpMKiiiAnrQyZ 4LMwGMOsHMrzrxnqykyD7armVuwq5CXWu0VbdQkLFSOYxkqTF1xP/FNrQTzdw4FxWyb8 f83kN1iv6148UEpvO51r/q7V+gTR+gQLayQb3+o0/is/BEB7Zsj0G+G79PJT93VFzaoo tQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2dpe9dbhsw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 18:26:58 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9JHQBK6021138; Thu, 19 Oct 2017 13:26:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dkdwug2un-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 13:26:56 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 13:26:55 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 19 Oct 2017 13:26:55 -0400 From: "Salz, Rich" To: Paul Turner , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gA== Date: Thu, 19 Oct 2017 17:26:55 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> In-Reply-To: <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.65] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190241 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190241 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:27:03 -0000 V2UgZGlzYWdyZWUuDQoNCkJlaW5nIGFibGUgdG8gYmxvY2sgdHJhZmZpYyBpcyBtdWNoIGxlc3Mg ZWZmb3J0IHRoYW4gcHJldGVuZGluZyB0byBiZSBhbm90aGVyIGlkZW50aXR5Lg0KDQo= From nobody Thu Oct 19 15:30:26 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE9D13420D for ; Thu, 19 Oct 2017 15:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 XdxJK6FHcd53 for ; Thu, 19 Oct 2017 15:30:22 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57482132F69 for ; Thu, 19 Oct 2017 15:30:22 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id n70so6305521vkf.11 for ; Thu, 19 Oct 2017 15:30:22 -0700 (PDT) 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; bh=M/OGZvfQuk8ORo1rLAzU5FUSreUybra88xNRkF1K0ZI=; b=r5Gr/Y7lA8HLhi4LsRkaTkHbutbTpvHOmJAuuN7hx5Ioh68TOU0wpqLmkOo3HPFnKZ tX9tGdjfeglFdrB00nC0yp+gpIVlj4hRomeMbzSTBiF19Hx6I1fRKuLoEa+Hp7EnIls9 YSl/8aO1GVzpsfHbHBvW4eGR/M+oC2KEowuSipm2N0aSsK9Nj38ZUtb2Wrjj9d4cjfRz 5aGbSM3oDKJzUTX0rxE5nWxpEkiSThEKN8axI3OP0Sv2p0mfLtsa4rtHkhIq3i+1OyCL IUB6VskmAM1jKXPMUuMJSSbNdd37UHIOyLmlrjrc0CIfpKtXtNAHWLOdHCiAF7GBTFIL oW4w== 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; bh=M/OGZvfQuk8ORo1rLAzU5FUSreUybra88xNRkF1K0ZI=; b=QndGLjOc4V8FVasVUDkpEsuS1e56N1Cr+hTXr386qBbiAAmuPaDBoUyvgrxUkYjCLr HYsLEaKFDI62OSnEoWBLJJawEYNi5Ya0hl1I70W65RLFgaJ9HHHgBdtq95t94pw5mxlF EI2HeNUkQWSvA+DRv+QSaaBpC8ohK8kNfnrzfhye4asJkkuQwTaNdlShF7zrZBUxfXjy xK39WL4jTJ10+I15LIEh6FasmLRP7btiPZMrWv+XHN7nvtUjjqaLU0BFGSN6ZxcEk+NR a6f8n70w1nx0A+zeLuiYajsH4Jx5ICD8900NX0BlIYWFdRHiTxkGjLYqDe5eRTpqf/S3 SzAA== X-Gm-Message-State: AMCzsaWagMvT6Kni3dVmfKENJNnalRprjzbcIw+KjCggZ/x6YtHyD3xe LdQSKaTUWylVpfJQgAQ0AQfok9mhH/zZH224R8Q= X-Google-Smtp-Source: ABhQp+TXM02h7MDy9lj8RfZCe7RmUa920+KwxW5HwPhvnL/IWVAS0KvJke1Ztl0QP3QRUe0gCaSO4xQgxxgjt6uY4yU= X-Received: by 10.31.155.202 with SMTP id d193mr2139708vke.94.1508452221405; Thu, 19 Oct 2017 15:30:21 -0700 (PDT) MIME-Version: 1.0 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> In-Reply-To: From: Darin Pettis Date: Thu, 19 Oct 2017 22:30:10 +0000 Message-ID: To: Paul Turner , "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1140f2ded15e69055bede69a" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 22:30:24 -0000 --001a1140f2ded15e69055bede69a Content-Type: text/plain; charset="UTF-8" On Thu, Oct 19, 2017 at 12:27 PM Salz, Rich wrote: > We disagree. > > Being able to block traffic is much less effort than pretending to be > another identity. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > First I want to thank the TLS WG for all their assistance and conversation around finding the right methodology for continued visibility. The question has been raised: "Why address visibility now?" The answer is that it is critical that the visibility capability is retained. It is available today through the RSA key exchange algorithm. We understand that the issue was raised late and have fallen on the preverbal sword for being late to the party but the issue is real. That is where the "rhrd" draft has come from. A way to retain that visibility capability but with a newer and more secure protocol. We need to protect and troubleshoot data that is within each of our companies. As encryption becomes more prevalent, it becomes more and more critical to see that data. The amount of people currently voicing concern is likely small for two reasons. One is that everything is public and many of the "lurkers" are hesitant to voice their concerns. The second reason is that so many don't know that visibility will be an issue. They will either discover this as they migrate to TLS 1.3 or as they start to encrypt within their data center. There is work to rapidly raise that awareness through roundtables, conferences and other venues. It is very positive that the WG has made a number of great recommendations that have led to this solution. That is the intention. We would appreciate the WG now adopting the extension so that it can be ushered through the process. This continued visibility can continue to be available as we all have expectations that our data is safeguarded and that websites are available to us quickly. Thank you for your valued assistance! --001a1140f2ded15e69055bede69a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Oct 19, 2017 at 12:27 PM S= alz, Rich <rsalz@akamai.com> = wrote:
We disagree.

Being able to block traffic is much less effort than pretending to be anoth= er identity.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

First I want to thank the TLS WG = for all their assistance and conversation around finding the right methodol= ogy for continued visibility.

The question has been raised: "Why address visi= bility now?" =C2=A0 The answer is that it is critical that the visibil= ity capability is retained.=C2=A0 It is available today through the RSA key= exchange algorithm.=C2=A0 We understand that the issue was raised late and= have fallen on the preverbal sword for being late to the party but the iss= ue is real.=C2=A0 That is where the "rhrd" draft has come from.= =C2=A0 A way to retain that visibility capability but with a newer and more= secure protocol.=C2=A0

We need to protect and troubleshoot data that is within each of o= ur companies. =C2=A0 As encryption becomes more prevalent, it becomes more = and more critical to see that data. =C2=A0

<= /div>
The amount of people currently voicing concern i= s likely small for two reasons.=C2=A0 One is that everything is public and = many of the "lurkers" are hesitant to voice their concerns.=C2=A0= The second reason is that so many don't know that visibility will be a= n issue.=C2=A0 They will either discover this as they migrate to TLS 1.3 or= as they start to encrypt within their data center.=C2=A0 There is work to = rapidly raise that awareness through roundtables, conferences and other ven= ues.

It is very positive that the WG h= as made a number of great recommendations that have led to this solution. = =C2=A0 That is the intention.=C2=A0 We would appreciate the WG now adopting= the extension so that it can be ushered through the process. =C2=A0 This c= ontinued visibility can continue to be available as we all have expectation= s that our data is safeguarded and that websites are available to us quickl= y. =C2=A0 Thank you for your valued assistance!
--001a1140f2ded15e69055bede69a-- From nobody Thu Oct 19 15:37:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34216132F69 for ; Thu, 19 Oct 2017 15:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEHBuHHlAzPL for ; Thu, 19 Oct 2017 15:37:56 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9306132355 for ; Thu, 19 Oct 2017 15:37:56 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx1.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e5JRp-0000G5-J4 for tls@ietf.org; Fri, 20 Oct 2017 00:37:54 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1e5JRm-0007rt-S0 for tls@ietf.org; Thu, 19 Oct 2017 18:37:51 -0400 Received: (qmail 3476 invoked from network); 19 Oct 2017 22:37:23 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.162]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Oct 2017 22:37:23 -0000 To: Darin Pettis , Paul Turner , "Salz, Rich" , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> From: Christian Huitema Message-ID: <7ed40a30-196f-d280-59a5-814a5ea4676e@huitema.net> Date: Thu, 19 Oct 2017 15:37:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.33) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rLsKwGac6/FNS+KtrtQHdkXv9krsgRhBn0ayn6qsUc7RO6saVKtiei5 uUZjs8uJrOfHzJ6mVE7ewsipSVIfs4ZMcQwIvNF9SiIUaOZIhBBxLB67TLnlh9i6Dr2tTQ7u+uL8 X9+LB/dn5OT5EkgkGCohEWyJzIkwSFAW0Pw8uiKe2NqE3QwrymzzH8LWqGR1m7I2v6y+lYBzzWMa L0utsL7rCEQHM1+f3IUKUB9wWYovzx6vjqN+txcrZT5UQnqhoJ5wbg2Zp4DEfSsPKFbX0jWPj+FO ubXhT3IXOeSutdn/GgSV6Ni8cJcVFhcEOifEfOMrNv4muc5NuXwVinsIhaOgGU9UYQoAp/lNIqn2 okjxMFhQHK3JmZta3vargAm/1F2Qrqc5dpeAqckdrLFU+rptrXEpYYIuwf4B2A6gOnpwQp8yzyqN Ah52fPHg5t2q2BqZR3KVQgqF/fPYYAfEfsgGn8xxA/cQHZ75h70fe1rxVWnoUFT0/jbbUc8lhTC+ 5gthGLX+Mh4z5LJgrhCgWoz+T9qKOv0z7nCHc/5d+MbcfJlbZZh01urflxdd2g4lVOY9YUFS+gfc BkEmyHl54sn3Y80OmAux3oN13+ztUznecq8lqz6CZtC5A+RtDANVNbrGhxr0ZQNhHrBZkFm8VpZG JoR9vVlRQtWdOm/uebtwKdtfHlXpAwYSpgNf0YJ1jVFfEoXm0/FPF8PR0w363lm8+fahbqhPQ5lN 0y21zh9T32tqm2wGhHAo712k9GZBAu8VjNzz0BoRxXlr+NDM3A9YO8GG407i2mdz3zQGDuet3jR5 NeVaJQBh0uawl0Cg8rdbWpE2ux+VrvYecZwKGQXQngcHaWeBIrVwdQfI6RxMYKPh1lHgUEF4t8hJ zRZ/yYkd2x35zAiBFPp64JaIysAhPltDTcKNRvi2K+1UJ6NK X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 22:37:58 -0000 On 10/19/2017 3:30 PM, Darin Pettis wrote: > The amount of people currently voicing concern is likely small for two > reasons.  One is that everything is public and many of the "lurkers" > are hesitant to voice their concerns.  The second reason is that so > many don't know that visibility will be an issue.  They will either > discover this as they migrate to TLS 1.3 or as they start to encrypt > within their data center.  There is work to rapidly raise that > awareness through roundtables, conferences and other venues. Might it be because many of these enterprises and data centers do not in fact see encryption as a problem? Maybe they have found ways to manage their applications and servers without breaking TLS... -- Christian Huitema From nobody Thu Oct 19 18:06:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B7D13495C for ; Thu, 19 Oct 2017 18:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2cdu0k_8Xy8H for ; Thu, 19 Oct 2017 18:06:27 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8BF1321D8 for ; Thu, 19 Oct 2017 18:06:27 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9K13Mrj003480; Fri, 20 Oct 2017 02:06:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=6Gh/555SXHbahmfvWIpYkZNJaXllEP6rZIMFaj8OtpU=; b=TC+7zX6XaTIQapbTzKE0kfFZZLM2r8t2LtO98usGTQDyjiyBtfdOsNwuBaQ6oaDMl00V l79eEOT5AIB7eHwAz27Sv5HmQOe85v43E4Yl5oh6rgJAuNWKaFMvaCi9TjzySvbMWann OJM1CHpG9me5svF/cQ7U7kMBzWvelsSKyx/gY3gr38Wu4OQhyvR1AeDcgbSVTjpiVl1P HWTwdHEdWtjX8AD6M5yUJBCQUr6+iF1emx40x36VxrZxDMKogoQbobzU91lG3+3b7tqK 65rc8XRP64Dt9vLZrkoT0gApqLkYlwl0IT3645uIOivG8ZdIq7EUiGzFrFkuW4B9SVpf yA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2dpg7dvehc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 02:06:24 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9K16JPr002563; Thu, 19 Oct 2017 21:06:23 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dkdwuh50k-1; Thu, 19 Oct 2017 21:06:21 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 51AA71FC85; Fri, 20 Oct 2017 01:06:19 +0000 (GMT) To: Darin Pettis , Paul Turner , "Salz, Rich" , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> From: Benjamin Kaduk Message-ID: Date: Thu, 19 Oct 2017 20:06:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------846DA70AAC404F0FD1F44C2B" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200015 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200014 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 01:06:32 -0000 This is a multi-part message in MIME format. --------------846DA70AAC404F0FD1F44C2B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/19/2017 05:30 PM, Darin Pettis wrote: > > The question has been raised: "Why address visibility now?"   The > answer is that it is critical that the visibility capability is > retained.  It is available today through the RSA key exchange > algorithm.  We understand that the issue was raised late and have > fallen on the preverbal sword for being late to the party but the > issue is real.  That is where the "rhrd" draft has come from.  A way > to retain that visibility capability but with a newer and more secure > protocol.  > But the "rhrd" draft does not require any changes to the core TLS 1.3 protocol, and in fact I have heard several key participants say that any "visibility" changes must not require changes to the core protocol.  If the "visibility" work will be done via extensions, then there is no ordering requirement for their specification with respect to the core work, there is only an ordering requirement between them and adoption of TLS 1.3 in enterprises.  Do you want to argue that a year timescale is too slow for enterprise adoption of TLS 1.3?  If not, I continue to not see a reason to address "visibility" now. -Ben --------------846DA70AAC404F0FD1F44C2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/19/2017 05:30 PM, Darin Pettis wrote:

The question has been raised: "Why address visibility now?"   The answer is that it is critical that the visibility capability is retained.  It is available today through the RSA key exchange algorithm.  We understand that the issue was raised late and have fallen on the preverbal sword for being late to the party but the issue is real.  That is where the "rhrd" draft has come from.  A way to retain that visibility capability but with a newer and more secure protocol. 


But the "rhrd" draft does not require any changes to the core TLS 1.3 protocol, and in fact I have heard several key participants say that any "visibility" changes must not require changes to the core protocol.  If the "visibility" work will be done via extensions, then there is no ordering requirement for their specification with respect to the core work, there is only an ordering requirement between them and adoption of TLS 1.3 in enterprises.  Do you want to argue that a year timescale is too slow for enterprise adoption of TLS 1.3?  If not, I continue to not see a reason to address "visibility" now.

-Ben
--------------846DA70AAC404F0FD1F44C2B-- From nobody Fri Oct 20 03:48:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962D213304E for ; Fri, 20 Oct 2017 03:48:39 -0700 (PDT) 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 AoPkdxQeUaTp for ; Fri, 20 Oct 2017 03:48:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F21132F65 for ; Fri, 20 Oct 2017 03:48:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8C5A3BE2F; Fri, 20 Oct 2017 11:48:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKYLVwCtPJSV; Fri, 20 Oct 2017 11:48:33 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 24751BDD8; Fri, 20 Oct 2017 11:48:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508496513; bh=mv3YrCFUV4sGo05OfqBTUmmltLVdwmUKmMlGUPXKoPE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QriuomWup1iqKvj1QpVPZeLBDPoq099XNs6zrpOH0ThLQqQ/pOV/Fbg+Sjr+uNLOD s4kbwCNpHN+ldLBlp5asPrAfVDfq0XAPAxneulu8PtaA3UsWgse3HYAu/Ssg6+dt7L dMxSnIsQgXpYvhz5RqeTioAa2DfcFVisPxl422dQ= To: Darin Pettis , Paul Turner , "Salz, Rich" , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <059094a6-b803-30cf-d56b-5aedf6eb8169@cs.tcd.ie> Date: Fri, 20 Oct 2017 11:48:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FopWKLPwXHwPLoi0GUC73ljrOeN9Wtqlf" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 10:48:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FopWKLPwXHwPLoi0GUC73ljrOeN9Wtqlf Content-Type: multipart/mixed; boundary="9CSkLIBir9r4mIaRML5r6v3Q6ET7kS6fo"; protected-headers="v1" From: Stephen Farrell To: Darin Pettis , Paul Turner , "Salz, Rich" , "tls@ietf.org" Message-ID: <059094a6-b803-30cf-d56b-5aedf6eb8169@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> In-Reply-To: --9CSkLIBir9r4mIaRML5r6v3Q6ET7kS6fo Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I agree with Christian and Ben's points. I'd also add: On 19/10/17 23:30, Darin Pettis wrote: > The question has been raised: "Why address visibility now?" The answe= r is > that it is critical that the visibility capability is retained. It is > available today through the RSA key exchange algorithm.=20 That yet again ignores the fact that TLS1.2 will continue to be available, which utterly undermines your argument that we need to disrupt the work on TLS1.3 with this divisive debate S --9CSkLIBir9r4mIaRML5r6v3Q6ET7kS6fo-- --FopWKLPwXHwPLoi0GUC73ljrOeN9Wtqlf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ6dSAAAoJEC88hzaAX42ipYwH/j956zneG4+Q4U6lxhasnDow A4kS+Xq/n9zmqtHXDzhFG26gebhcEhWrqKjMdH3dKgvd1XmWczP98wlHhLz64qkN fnHMCqXa5bnrYs/R1zBb2EkoM4tp7jmSf0cFQb9dqlqGmY6XlP0SDev5NQ8BjOIf b+9iFPaAOykJtcQbxSxUnWriNnT3jTIs8IGTGyRj3a+BWhEq/eVhIfrDhtAgufq3 sTZjVj13kt/960Z8kd0K3Zji0id16CFyBuszNk+rWMk7OW4kbvFJM5ilIWHZYJzk PSZFRWrjcYD/TA9B20xWM/mWprjPV+BofTLYh+r5CFK9kd9B0gt3colNcrtur44= =UTy1 -----END PGP SIGNATURE----- --FopWKLPwXHwPLoi0GUC73ljrOeN9Wtqlf-- From nobody Fri Oct 20 04:39:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0D21326FE for ; Fri, 20 Oct 2017 04:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 XrGs8cd7Io2I for ; Fri, 20 Oct 2017 04:39:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01AA7133091 for ; Fri, 20 Oct 2017 04:39:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYD22560; Fri, 20 Oct 2017 11:39:12 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 20 Oct 2017 12:39:12 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.184]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Fri, 20 Oct 2017 19:39:07 +0800 From: yinxinxing To: Martin Thomson , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AdNJl/a2c3uKTP71RWunuMjKfcHD1g== Date: Fri, 20 Oct 2017 11:39:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.59E9E061.0053, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.184, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2bb64600e8d734ca67556d1e323aff95 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 11:39:17 -0000 SGkgTWFydGluLA0KDQpBY2NvcmRpbmcgdG8gdGhlIGNvZGUgeW91IGRlc2NyaWJlZCBpbiBwcmV2 aW91cyBlbWFpbCwgSVNUTSB5b3VyIGlkZWEgb2YgcGFyc2luZyB0aGUgc3RhbmRhcmQgcGFja2V0 IGFuZCBDSUQgcGFja2V0IGlzIHVzaW5nIHRoZSA1LXR1cGxlLiBUaGUgYmVuZWZpdCBpcyB0aGF0 IG5vIG5ldyBjb250ZW50dHlwZSBvciB2ZXJzaW9uIGlzIG5lZWRlZC4gQnV0IHRoZSBwcmVjb25k aXRpb24gZm9yIHdlbGwgd29ya2luZyBpcyB0aGF0IHRoZSA1LXR1cGxlIG9mIHRoZSBDSUQgcGFj a2V0IHdpbGwgbm90IGJlIHN1Y2Nlc3NmdWxseSBtYXRjaGVkIGluIHRoZSByZWNlaXZlcidzIDUt dHVwbGUgdGFibGUuIEhvd2V2ZXIsIHRoaXMgY29uZGl0aW9uIGlzIG5vdCBhbHdheXMgdHJ1ZS4g DQoNCklmIEkgbWlzdW5kZXJzdGFuZCB5b3VyIGlkZWEsIHBsZWFzZSBjb3JyZWN0IG1lLiBUaGFu a3MuICANCg0KWWluIFhpbnhpbmcNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IFRMUyBb bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE1hcnRpbiBUaG9tc29uDQq3osvNyrG8 5DogMjAxN8TqMTDUwjE4yNUgMTY6MDgNCsrVvP7IyzogRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAt IEdCL0NhbWJyaWRnZSwgVUspDQqzrcvNOiB0bHNAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbVExTXSBD b25uZWN0aW9uIElEIERyYWZ0DQoNCk9uIFdlZCwgT2N0IDE4LCAyMDE3IGF0IDU6NDQgUE0sIEZv c3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSA8dGhvbWFzLmZvc3NhdGlA bm9raWEuY29tPiB3cm90ZToNCj4gVGhpcyBpcyBxdWl0ZSBzaW1pbGFyIHRvIHRoZSB0cmlhbCBh bmQgZXJyb3IgLyBoZXVyaXN0aWMgdGhhdCBJIHdhcyANCj4gbWVudGlvbmluZyBpbiBbMV0uDQoN CllvdSBkaWRuJ3QgbWVudGlvbiA1LXR1cGxlcy4gIEFuZCBpdCBpc24ndCB0cmlhbCBhbmQgZXJy b3I6IHlvdSB1c2UgNS10dXBsZSBhcyB5b3VyIHByaW1hcnkga2V5IGFuZCB1c2UgY29ubmVjdGlv biBJRCB0byBsYXRjaC4NCg0KPiBOb3RlIHRoYXQgaWYgQS4xIGFuZCBBLjIncyA1LXR1cGxlcyBh cmUgc3dhcHBlZCwgdGhlIGFsZ29yaXRobSBmYWlscyANCj4gdG8gcmVjb2duaXNlIEEuMSBhcyBD SUQtZW5hYmxlZCBhbmQgc2VuZHMgaXQgZm9yd2FyZCB0byB0aGUgY3J5cHRvIA0KPiBoYW5kbGVy IHdoZW4gaXQgc2hvdWxkbid0Lg0KDQpBcyBJIHNhaWQgYmVmb3JlLCBhbnkgY29ubmVjdGlvbiB3 aXRob3V0IGEgY29ubmVjdGlvbiBJRCBtb25vcG9saXplcyB0aGF0IDUtdHVwbGUgbWFraW5nIGl0 IGluYWNjZXNzaWJsZSB0byBvdGhlciBjb25uZWN0aW9ucy4gIEkgdGhpbmsgdGhhdCBpbiB0aGlz IGNhc2U6IHRvbyBiYWQuDQoNCj4gQW5kIHRoZSBhbHJlYWR5IGRpc2N1c3NlZCBsaW1pdGF0aW9u czoNCj4gLSBGcmFnaWxpdHkgb24gY29ybmVyIGNhc2VzIChlLmcuLCB0aGUgNS10dXBsZSBzd2Fw IGFib3ZlKTsNCg0KSSBkb24ndCBzZWUgaG93IHlvdSBjYW4gYXZvaWQgdGhpcyBpbiB0aGUgZ2Vu ZXJhbCBjYXNlLiAgQW55IGNvbm5lY3Rpb24gd2l0aG91dCBjb25uZWN0aW9uIElEIGlzIGdvaW5n IHRvIGJlIGhhcmQgdG8gY29ycmVsYXRlIGlmIGl0IG1vdmVzLiAgQXMgZm9yIHRoZSBjb25uZWN0 aW9uIHRoYXQgZG9lcyBoYXZlIGEgY29ubmVjdGlvbiBJRCBidXQgbW92ZXMgb24gdG9wIG9mIGEg Y29ubmVjdGlvbiB0aGF0IGRvZXNuJ3QsIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyBhbiBhY2NlcHRh YmxlIGxvc3MuDQoNCj4gLSBGb3JjaW5nIG1pZGRsZXdhcmUgdG8ga2VlcCBzdGF0ZTsNCj4gLSBC cmVha2luZyB3aXJlc2hhcmsgJiBjbyB1bmxlc3MgdGhleSBjYW4gc2VlIHRoZSB3aG9sZSBzZXNz aW9uOw0KDQpCb3RoIG9mIHRoZXNlIGFyZSBhY2NlcHRhYmxlIHRvIG1lLiAgVW5sZXNzIHlvdSBj YW4gZGVzY3JpYmUgYSBtaWRkbGVib3ggdXNlIGNhc2UgdGhhdCBuZWVkcyBhY2Nlc3MgdG8gdGhp cyBpbmZvcm1hdGlvbiBhbmQgY2FuJ3QgZGVhbCB3aXRoIHRoZSBzb2x1dGlvbiB0aGF0IEkgZGVz Y3JpYmVkLiAgV2lyZXNoYXJrIGFuZCBjbyB3aWxsIG5lZWQgdG8gc2VlIHRoZSBoYW5kc2hha2Ug aWYgdGhleSB3YW50IHRvIGRlY3J5cHQgYW5kIHRoYXQncyB0aGUgb25seSBjYXNlIHRoYXQgaXMg aW1wb3J0YW50Lg0KDQo+IC0gKERlcGVuZGluZyBvbiB0aGUgdXNlIGNhc2UsIHRoZSBjb3N0IG9m IHRoZSB0d28gbG9va3VwcyBwZXIgcmVjb3JkDQo+ICAgb24gdGhlIHBhcnNpbmcgbWlnaHQgaGF2 ZSBhIHBlcmZvcm1hbmNlIGltcGFjdC4pDQoNClRoZSBzZWNvbmQgbG9va3VwIG9ubHkgaGFwcGVu cyBhZnRlciBhIG1pZ3JhdGlvbi4gIEkgbmVnbGVjdGVkIHRvIG1lbnRpb24gdGhhdCBzdWNjZXNz ZnVsIHVzZSBvZiBhIGNvbm5lY3Rpb24gSUQgY2F1c2VzIHRoZSA1LXR1cGxlIHRvIGJlIGFzc2ln bmVkIHRvIHRoYXQgY29ubmVjdGlvbjsgdGhlcmUncyBhIHRyaWNrIHRoZXJlIGluIHRoYXQgeW91 IG5lZWQgdG8gd2F0Y2ggZm9yIHJlb3JkZXJpbmcsIGJ1dCBpdCBzYXZlcyB0aGUgZG91YmxlIGxv b2t1cC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90bHMNCg== From nobody Fri Oct 20 06:44:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C60133341 for ; Fri, 20 Oct 2017 06:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aO0O1w0mONbx for ; Fri, 20 Oct 2017 06:44:10 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EC613330C for ; Fri, 20 Oct 2017 06:44:10 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9KDh9wG013071; Fri, 20 Oct 2017 14:44:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=o4hFtHbrGbzg8Whj2fg/QJtMmZp1B8jMDyEoK6F6rD8=; b=SW0sQgmL3ygHpz/wRD2aoAMYP7sASiQZPxAtJ8O9Wy7EzX5e2nxDyh7O2IvrY41CuYr1 J1zuOIvY/3oebtVK791f28RMTYNxC4OBrdzdTNDEDYNEibGFcs+hJ92qWSvC1dCcw7x8 brqdAPQAwNa2uSoOCcdSG+7SY3Yi3PiDjDRuMGibm4Vcjt3uZ2qK/HCI8cWx7+18o2gf KkOz9LkilFE65Ry56I21+d/p1hDHvcR+TizRDuU8B85HvuxwbpqJjMQ5cuiSabVeH8Sm nYlvglo3d010XMruIEK/8GR+rRbqcZDOYw+kqTH+/ioG87rqYxfX0tp8TssCMLNlWX7o oA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2dpg7dxfcp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 14:44:07 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9KDfBRR031747; Fri, 20 Oct 2017 09:44:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dkdwujq48-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 09:44:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 20 Oct 2017 09:44:04 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 20 Oct 2017 09:44:04 -0400 From: "Salz, Rich" To: Darin Pettis , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwA= Date: Fri, 20 Oct 2017 13:44:04 +0000 Message-ID: <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.246] Content-Type: multipart/alternative; boundary="_000_9013424B4F6D41859BFDEC454FF80F22akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200192 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200193 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 13:44:12 -0000 --_000_9013424B4F6D41859BFDEC454FF80F22akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgVGhlIHF1ZXN0aW9uIGhhcyBiZWVuIHJhaXNlZDogIldoeSBhZGRyZXNzIHZpc2liaWxp dHkgbm93PyIgICBUaGUgYW5zd2VyIGlzIHRoYXQgaXQgaXMgY3JpdGljYWwgdGhhdCB0aGUgdmlz aWJpbGl0eSBjYXBhYmlsaXR5IGlzIHJldGFpbmVkLiAgSXQgaXMgYXZhaWxhYmxlIHRvZGF5IHRo cm91Z2ggdGhlIFJTQSBrZXkgZXhjaGFuZ2UgYWxnb3JpdGhtLiAgV2UgdW5kZXJzdGFuZCB0aGF0 IHRoZSBpc3N1ZSB3YXMgcmFpc2VkIGxhdGUgYW5kIGhhdmUgZmFsbGVuIG9uIHRoZSBwcmV2ZXJi YWwgc3dvcmQgZm9yIGJlaW5nIGxhdGUgdG8gdGhlIHBhcnR5IGJ1dCB0aGUgaXNzdWUgaXMgcmVh bC4gIFRoYXQgaXMgd2hlcmUgdGhlICJyaHJkIiBkcmFmdCBoYXMgY29tZSBmcm9tLiAgQSB3YXkg dG8gcmV0YWluIHRoYXQgdmlzaWJpbGl0eSBjYXBhYmlsaXR5IGJ1dCB3aXRoIGEgbmV3ZXIgYW5k IG1vcmUgc2VjdXJlIHByb3RvY29sLg0KDQpZb3UgYWNoaWV2ZSB5b3VyIG5lZWRzIHJpZ2h0IG5v dyBieSBzaGFyaW5nIHRoZSBvcmlnaW7igJlzIFJTQSBrZXkgd2l0aCB5b3VyIGRlYnVnZ2luZyBh Z2VudHMuICBZb3UgY2FuIGFjaGlldmUgdGhlIHNhbWUgbmVlZHMgaW4gVExTIDEuMyBieSBrZWVw aW5nIHRoYXQgYXJjaGl0ZWN0dXJlLCBhbHRob3VnaCBtb3JlIGluZm9ybWF0aW9uIG11c3QgYmUg c2hhcmVkLiAgVGhpcyBwcmVzZXJ2ZXMgdGhlIGFyY2hpdGVjdHVyZSBhbmQgYmVjb21lcyDigJxq dXN04oCdIGltcGxlbWVudGF0aW9uLiAgVGhpcyBoYXMgYmVlbiBicm91Z2h0IHVwIGJlZm9yZS4N Cg0KVGhlIGZpcnN0IGRyYWZ0IHNob3dlZCBob3cgdG8gZG8gdGhpcyBwdXJlbHkgb24gdGhlIHNl cnZlciBzaWRlLiAgU29tZSBtZW1iZXJzIG9mIHRoZSBXRyByb3NlIHVwIGFuZCB3YW50ZWQgZXhw bGljaXQgb3B0LWluLiBUaGUgbmV3IGRyYWZ0IGRvZXMgdGhhdC4gIEluIHJldHJvc3BlY3QsIGl0 IHR1cm5zIG91dCB0aGF0IG9wdC1pbiBpcyB3b3JzZSwgbWFpbmx5IHRoYXQgdGhlcmUgaXMgbm8g d2F5IHRvIGd1YXJhbnRlZSB0aGF0IHRoaXMgZG9lcyBub3Qg4oCcZXNjYXBl4oCdIG9udG8gdGhl IHB1YmxpYyBJbnRlcm5ldC4gVGhpcyBtYWtlcyBzZW5zZSwgaWYgeW91IHJlcXVpcmUgb3B0LWlu IGZyb20gdGhlIGNsaWVudCwgdGhlbiBpdCBpcyBub3Qgc3VycHJpc2luZyB0aGF0LCBvdGhlciBl bnRpdGllcyBiZXNpZGVzIHRoZSB0d28gcGFydGllcyBlbmdhZ2VkIGluIHRoZSBUTFMgcHJvdG9j b2wgY291bGQsIHdlbGwsICpyZXF1aXJlKiBjbGllbnRzIHRvIG9wdC1pbi4gIEFzIEkgYW5kIG90 aGVycyBoYXZlIHRyaWVkIHRvIHNob3cgaW4gZW1haWwgZXhjaGFuZ2VycyB3aXRoIFBhdWwsIHRo aXMgaXMgYSBmdW5kYW1lbnRhbCBjaGFuZ2UgdG8gdGhlIG5hdHVyZSBvZiBob3cgVExTIGlzIHVz ZWQuDQoNCkZpbmFsbHksIGFzIGhhcyBhbHNvIGJlZW4gbWVudGlvbmVkLCBub2JvZHkgaXMgcHJl dmVudGluZyB5b3UgZnJvbSBrZWVwaW5nIHlvdXIgc2VydmVycyBhdCBUTFMgMS4yIG9yIGVhcmxp ZXIuICBUTFMgMS4yIHdhcyBkZWZpbmVkIGJ5IFJGQyA1MjQ2IGluIDIwMDguIEEgZGVjYWRlIGxh dGVyLCBQQ0ktRFNTIGlzIG9ubHkg4oCYc3Ryb25nbHkgZW5jb3VyYWdpbmfigJkgVExTIDEuMjsg dGhlIGFjdHVhbCByZXF1aXJlbWVudCBpcyBUTFMgMS4xISBXaHkgc2hvdWxkIHdlIGV4cGVjdCB0 aGF0IFRMUyAxLjMgd2lsbCBoYXBwZW4gYW55IGZhc3Rlcj8NCg0KWW91IGhhdmUgbm90IG1hZGUg eW91ciBjYXNlLg0KDQo= --_000_9013424B4F6D41859BFDEC454FF80F22akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <25A1A6EAEB0DD24884CE88F241617DF4@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlQm9keTsN CglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjg2MTE2MzY1ODsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQ5NTMxNzk1NCAyMTM2MjI3MDEwIDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTk7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2Vy aWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOiM0NTQ1NDU7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OyxzZXJpZiI+VGhlIHF1ZXN0aW9u IGhhcyBiZWVuIHJhaXNlZDogJnF1b3Q7V2h5IGFkZHJlc3MgdmlzaWJpbGl0eSBub3c/JnF1b3Q7 ICZuYnNwOyBUaGUgYW5zd2VyIGlzIHRoYXQgaXQgaXMgY3JpdGljYWwgdGhhdCB0aGUgdmlzaWJp bGl0eSBjYXBhYmlsaXR5IGlzIHJldGFpbmVkLiZuYnNwOyBJdCBpcyBhdmFpbGFibGUgdG9kYXkg dGhyb3VnaCB0aGUgUlNBIGtleSBleGNoYW5nZQ0KIGFsZ29yaXRobS4mbmJzcDsgV2UgdW5kZXJz dGFuZCB0aGF0IHRoZSBpc3N1ZSB3YXMgcmFpc2VkIGxhdGUgYW5kIGhhdmUgZmFsbGVuIG9uIHRo ZSBwcmV2ZXJiYWwgc3dvcmQgZm9yIGJlaW5nIGxhdGUgdG8gdGhlIHBhcnR5IGJ1dCB0aGUgaXNz dWUgaXMgcmVhbC4mbmJzcDsgVGhhdCBpcyB3aGVyZSB0aGUgJnF1b3Q7cmhyZCZxdW90OyBkcmFm dCBoYXMgY29tZSBmcm9tLiZuYnNwOyBBIHdheSB0byByZXRhaW4gdGhhdCB2aXNpYmlsaXR5IGNh cGFiaWxpdHkgYnV0IHdpdGggYSBuZXdlciBhbmQNCiBtb3JlIHNlY3VyZSBwcm90b2NvbC4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZv bnRUZXh0U3R5bGVCb2R5JnF1b3Q7LHNlcmlmO2NvbG9yOiM0NTQ1NDUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0 eWxlQm9keSZxdW90OyxzZXJpZjtjb2xvcjojNDU0NTQ1Ij5Zb3UgYWNoaWV2ZSB5b3VyIG5lZWRz IHJpZ2h0IG5vdyBieSBzaGFyaW5nIHRoZSBvcmlnaW7igJlzIFJTQSBrZXkgd2l0aCB5b3VyIGRl YnVnZ2luZyBhZ2VudHMuJm5ic3A7IFlvdSBjYW4gYWNoaWV2ZSB0aGUgc2FtZSBuZWVkcyBpbiBU TFMgMS4zIGJ5IGtlZXBpbmcgdGhhdA0KIGFyY2hpdGVjdHVyZSwgYWx0aG91Z2ggbW9yZSBpbmZv cm1hdGlvbiBtdXN0IGJlIHNoYXJlZC4mbmJzcDsgVGhpcyBwcmVzZXJ2ZXMgdGhlIGFyY2hpdGVj dHVyZSBhbmQgYmVjb21lcyDigJxqdXN04oCdIGltcGxlbWVudGF0aW9uLiZuYnNwOyBUaGlzIGhh cyBiZWVuIGJyb3VnaHQgdXAgYmVmb3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OyxzZXJpZjtjb2xvcjojNDU0NTQ1Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJv ZHkmcXVvdDssc2VyaWY7Y29sb3I6IzQ1NDU0NSI+VGhlIGZpcnN0IGRyYWZ0IHNob3dlZCBob3cg dG8gZG8gdGhpcyBwdXJlbHkgb24gdGhlIHNlcnZlciBzaWRlLiZuYnNwOyBTb21lIG1lbWJlcnMg b2YgdGhlIFdHIHJvc2UgdXAgYW5kIHdhbnRlZCBleHBsaWNpdCBvcHQtaW4uIFRoZSBuZXcgZHJh ZnQgZG9lcyB0aGF0LiZuYnNwOw0KIEluIHJldHJvc3BlY3QsIGl0IHR1cm5zIG91dCB0aGF0IG9w dC1pbiBpcyB3b3JzZSwgbWFpbmx5IHRoYXQgdGhlcmUgaXMgbm8gd2F5IHRvIGd1YXJhbnRlZSB0 aGF0IHRoaXMgZG9lcyBub3Qg4oCcZXNjYXBl4oCdIG9udG8gdGhlIHB1YmxpYyBJbnRlcm5ldC4g VGhpcyBtYWtlcyBzZW5zZSwgaWYgeW91IHJlcXVpcmUgb3B0LWluIGZyb20gdGhlIGNsaWVudCwg dGhlbiBpdCBpcyBub3Qgc3VycHJpc2luZyB0aGF0LCBvdGhlciBlbnRpdGllcyBiZXNpZGVzDQog dGhlIHR3byBwYXJ0aWVzIGVuZ2FnZWQgaW4gdGhlIFRMUyBwcm90b2NvbCBjb3VsZCwgd2VsbCwg KjxiPnJlcXVpcmU8L2I+KiBjbGllbnRzIHRvIG9wdC1pbi4mbmJzcDsgQXMgSSBhbmQgb3RoZXJz IGhhdmUgdHJpZWQgdG8gc2hvdyBpbiBlbWFpbCBleGNoYW5nZXJzIHdpdGggUGF1bCwgdGhpcyBp cyBhIGZ1bmRhbWVudGFsIGNoYW5nZSB0byB0aGUgbmF0dXJlIG9mIGhvdyBUTFMgaXMgdXNlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9u dFRleHRTdHlsZUJvZHkmcXVvdDssc2VyaWY7Y29sb3I6IzQ1NDU0NSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LHNl cmlmO2NvbG9yOiM0NTQ1NDUiPkZpbmFsbHksIGFzIGhhcyBhbHNvIGJlZW4gbWVudGlvbmVkLCBu b2JvZHkgaXMgcHJldmVudGluZyB5b3UgZnJvbSBrZWVwaW5nIHlvdXIgc2VydmVycyBhdCBUTFMg MS4yIG9yIGVhcmxpZXIuJm5ic3A7IFRMUyAxLjIgd2FzIGRlZmluZWQgYnkgUkZDIDUyNDYgaW4g MjAwOC4NCiBBIGRlY2FkZSBsYXRlciwgUENJLURTUyBpcyBvbmx5IOKAmHN0cm9uZ2x5IGVuY291 cmFnaW5n4oCZIFRMUyAxLjI7IHRoZSBhY3R1YWwgcmVxdWlyZW1lbnQgaXMgVExTIDEuMSEgV2h5 IHNob3VsZCB3ZSBleHBlY3QgdGhhdCBUTFMgMS4zIHdpbGwgaGFwcGVuIGFueSBmYXN0ZXI/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1 b3Q7LHNlcmlmO2NvbG9yOiM0NTQ1NDUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OyxzZXJpZjtjb2xvcjojNDU0NTQ1 Ij5Zb3UgaGF2ZSBub3QgbWFkZSB5b3VyIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LHNlcmlmO2NvbG9yOiM0NTQ1NDUi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_9013424B4F6D41859BFDEC454FF80F22akamaicom_-- From nobody Fri Oct 20 06:54:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C0A1286C7 for ; Fri, 20 Oct 2017 06:54:06 -0700 (PDT) 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 JVLM037IaV3c for ; Fri, 20 Oct 2017 06:54:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCF91270AE for ; Fri, 20 Oct 2017 06:54:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3F987BE3E; Fri, 20 Oct 2017 14:54:03 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD0dnypL0NuP; Fri, 20 Oct 2017 14:54:02 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 52192BE24; Fri, 20 Oct 2017 14:54:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508507641; bh=8Y8IPFSLR58TGkrVvVxI2TYyiS+IeRezYcMgNmRuICk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=xWqk/ReD5nhxZuR/qtTZGXQHrqQcfx1GkpqTH4lG3ixGlsITzyLguULZ5HpoJ/7k9 k9VqWdFLG5m8XO7C8e3Sbr1NpNN3JajVFvSaQyY0nukSifD4DfKmr0JkJD/hYfg8c5 0ReKsaQwRIblyf9+uomFahDi+jrDrne9b5bk30uA= To: "Salz, Rich" , Darin Pettis , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 20 Oct 2017 14:54:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8kNeK43BQ8E8EHVosI3AqQOwLt68VEWB5" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 13:54:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8kNeK43BQ8E8EHVosI3AqQOwLt68VEWB5 Content-Type: multipart/mixed; boundary="CLqvWIpG7TIC4ali3Gibi6JPmBrwev7O1"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Darin Pettis , "tls@ietf.org" Message-ID: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> In-Reply-To: <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> --CLqvWIpG7TIC4ali3Gibi6JPmBrwev7O1 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Minor clarification... On 20/10/17 14:44, Salz, Rich wrote: > Some members of the WG rose up and wanted explicit opt-in I don't think "wanted" is quite right. Some WG participants (e.g. me) wanted nothing like this to ever be done in the IETF. Others did comment that the lack of client opt-in was a bad aspect of draft-green, but I'm not sure that anyone clearly said "I do want draft-green snooping, but with client opt-in." S. --CLqvWIpG7TIC4ali3Gibi6JPmBrwev7O1-- --8kNeK43BQ8E8EHVosI3AqQOwLt68VEWB5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ6f/4AAoJEC88hzaAX42iErUH+wYVOROJRDCsrov9hDvZgaBk //+cH01fDvtcT2xHljqf6ns5YY3tMEmtnF/xa2+ynzCA+/AjsEFh8deqQD2DUuNQ YZRTMAy+DTDRmIyklTnsWimzfyTQvSokKWTWlaLjqDBp4/Uc2V2bZTTnTfXTCpCF A99Ad7HIVzqOynF0iSDkOStbH3KdpoBG+J16CgL64a0GYR0XqqnskkrP+ZAXBC9U 2eIB/4tBDZ5s3151qxIC+cQeiGfb1WnSRoaVenPgvRnOrElTCL/+OtVDZqp+zxyA iqhMWR7EsCfthdKuw9FldWk04KSmQh7f0CFLRbXqVVJfJwREmiSWnbawCYM+z4Y= =tGBa -----END PGP SIGNATURE----- --8kNeK43BQ8E8EHVosI3AqQOwLt68VEWB5-- From nobody Fri Oct 20 07:08:55 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF3313339A for ; Fri, 20 Oct 2017 07:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6t5WgqiTZx4 for ; Fri, 20 Oct 2017 07:08:48 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2C1132C3F for ; Fri, 20 Oct 2017 07:08:48 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id b15so14428876qkg.9 for ; Fri, 20 Oct 2017 07:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=N2YGfET3HehIYcjSpYN13KPcooV1/Ogi7w/JdTRDk+Y=; b=QDDwM7+M9jPbXXYD0ZTEh9btfK7xurI/OPMgKMZDA9z5iu5aeIkVE1p0JU7WBFQmwq KpIqJTn++nio6XC8vHT13gFAvc+jbQZvt2VvtVkYKjVlkjBrA/BFSCFO9gVC2R5PthcV sFkGOyrr88JEkpnIzJsGSSOTQXjQ+2RtFMRRTYnL/E4BLPvmjXk83QTgjCrjua0kNFHl jzGSaZkrSf5Dd8ekyKkcIYLfJ3W9q2wa9l6rZg8UxrdHflaE8ds3MPvkvE4o6NswZtYJ Q7SUqNFz8Uepho+HseOtBsPhljwdmc6i9k8mQqbLyLjn9YhQMY/c3/Nr2q6extU0PBYp fEoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=N2YGfET3HehIYcjSpYN13KPcooV1/Ogi7w/JdTRDk+Y=; b=U91p1KGYEJlJARoBKBbMRTzCyQhT4rOd0vnl2fMtVR7DbmTNoRADlI18sKA6vF+ZMy B3aKq7//OXJufm45vLzg3cNi3DM/D9gGzLlTflSiuT2147aKtRJ85X01FLRiCjl30iLJ wJHXbNZOWePoVX2cxw7/FyS85Ydb984VrI6EjGWyFdwcvfVzC1funZXXEkg3RKMa3W1O UWYJrrkMibjQO7fxcocHNy/YUlHjZYb8D7lfRXV4xkpN3T4Tmm/IUIkfvVMvcqSwnLzn HF+ewoGCtCGw6hCgCE93RDJwrAfdUA9HIe7Gry+RqXezcnuWlw/aorHDTu+BaLMBd4/R WTCg== X-Gm-Message-State: AMCzsaW2iiQYxI2z1WTLd0b7rRICPHCtWzLtwcoi6WI8VPmEDJWnPg+I CgSkKRhEP6r03TXzt/Ye5jxWtw== X-Google-Smtp-Source: ABhQp+SqGYdP4hiIEkngD/iz+fIJQzCA2E3GVNIq1qngaTTpBq0SRJZnHrPeFgaQhnyQbfbKR30tIA== X-Received: by 10.55.179.198 with SMTP id c189mr7250892qkf.211.1508508527540; Fri, 20 Oct 2017 07:08:47 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id v30sm639387qtg.88.2017.10.20.07.08.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 07:08:46 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E291C3C7-0089-4B6E-9D28-2C1ED3111FB5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 20 Oct 2017 10:08:44 -0400 In-Reply-To: Cc: "Salz, Rich" , Darin Pettis , "tls@ietf.org" To: Stephen Farrell References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 14:08:50 -0000 --Apple-Mail=_E291C3C7-0089-4B6E-9D28-2C1ED3111FB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 20, 2017, at 9:54 AM, Stephen Farrell = wrote: > Others did > comment that the lack of client opt-in was a > bad aspect of draft-green, but I'm not sure > that anyone clearly said "I do want draft-green > snooping, but with client opt-in." I can say for myself that there was a really strong hard sell on the = notion of doing this in Prague. Not being sufficiently paranoid, my = general sympathy for people facing hard problems led me to consider what = they were proposing, but each time they came up with something, someone = with more paranoia fu than I have pointed out a hole in it. During = that period there were several periods when I was reluctantly willing to = consider some less-bad version of draft-green. This is a long way from = "want," and even a pretty long way from "support." My personal feeling having been peeled off the herd and hard-sold like = this is that there is some really powerful motivated reasoning going on = here, and that the working group should just stop entertaining this = process. Weakening TLS is not the right way to approach the problem = that has been described here. I hasten to add that I don't think the people doing the hard sell are = bad people, or that they didn't have good reason for trying to do it. = My point is simply that we've been collectively sucked close to a black = hole here, and we need to take a step back from it. In the same sense = that LEOs who want key escrow have good reason for wanting it and are = not bad people for wanting it, so too with the people pushing this = proposal. But like key escrow, this proposal is not beneficial for = end-users or for security as a whole. In order for it to make sense to go forward with this proposal, two = things would have to be true that I don't think are true. First, we = would have to agree that user security is not a primary goal. And = second, we would have to agree that overall network security is not a = primary goal. Discussing the details of how much security we are = willing to give up, what attack surfaces that we could remove we are = willing to leave in, only makes sense if we are willing to drop those = two primary goals. Watching this conversation has been a really good learning experience = for me, so I don't regret it, but I think we should stop. --Apple-Mail=_E291C3C7-0089-4B6E-9D28-2C1ED3111FB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 20, 2017, at 9:54 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
Others did
comment that the = lack of client opt-in was a
bad aspect of = draft-green, but I'm not sure
that anyone clearly = said "I do want draft-green
snooping, but with = client opt-in."

I can say for myself that there was a really strong hard sell = on the notion of doing this in Prague.   Not being sufficiently = paranoid, my general sympathy for people facing hard problems led me to = consider what they were proposing, but each time they came up with = something, someone with more paranoia fu than I have pointed out a hole = in it.   During that period there were several periods when I was = reluctantly willing to consider some less-bad version of draft-green. =   This is a long way from "want," and even a pretty long way from = "support."

My = personal feeling having been peeled off the herd and hard-sold like this = is that there is some really powerful motivated reasoning going on here, = and that the working group should just stop entertaining this process. =   Weakening TLS is not the right way to approach the problem that = has been described here.

I hasten to add that I don't think the people doing the hard = sell are bad people, or that they didn't have good reason for trying to = do it.   My point is simply that we've been collectively sucked = close to a black hole here, and we need to take a step back from it. =   In the same sense that LEOs who want key escrow have good reason = for wanting it and are not bad people for wanting it, so too with the = people pushing this proposal.   But like key escrow, this proposal = is not beneficial for end-users or for security as a whole.

In order for it to make = sense to go forward with this proposal, two things would have to be true = that I don't think are true.   First, we would have to agree that = user security is not a primary goal.   And second, we would have to = agree that overall network security is not a primary goal.   = Discussing the details of how much security we are willing to give up, = what attack surfaces that we could remove we are willing to leave in, = only makes sense if we are willing to drop those two primary = goals.

Watching = this conversation has been a really good learning experience for me, so = I don't regret it, but I think we should stop.

= --Apple-Mail=_E291C3C7-0089-4B6E-9D28-2C1ED3111FB5-- From nobody Fri Oct 20 07:28:48 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C95134222 for ; Fri, 20 Oct 2017 07:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 bB_vkUtPCxNG for ; Fri, 20 Oct 2017 07:28:40 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 69EA01331D9 for ; Fri, 20 Oct 2017 07:28:40 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v9KESNJT035552 for ; Fri, 20 Oct 2017 10:28:39 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO713gKFaj/ze3UaJfDxWNuaqP6LqPDwAgAFTKoCAAAWQgIAAANiAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAAAh1AA== Date: Fri, 20 Oct 2017 14:14:21 +0000 Message-ID: <13808499-9C0D-44DE-A41C-E58579683D95@ll.mit.edu> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> In-Reply-To: <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-originating-ip: [172.25.177.12] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3591339260_12856504" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200203 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 14:28:43 -0000 --B_3591339260_12856504 Content-type: multipart/alternative; boundary="B_3591339260_159244428" --B_3591339260_159244428 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable +1 to Rich. =20 -- Regards, Uri Blumenthal =20 From: TLS on behalf of Rich Salz Date: Friday, October 20, 2017 at 09:59 To: Darin Pettis , "tls@ietf.org" Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 =20 =C3=98 The question has been raised: "Why address visibility now?" The answe= r is that it is critical that the visibility capability is retained. It is = available today through the RSA key exchange algorithm. We understand that = the issue was raised late and have fallen on the preverbal sword for being l= ate to the party but the issue is real. That is where the "rhrd" draft has = come from. A way to retain that visibility capability but with a newer and = more secure protocol.=20 =20 You achieve your needs right now by sharing the origin=E2=80=99s RSA key with you= r debugging agents. You can achieve the same needs in TLS 1.3 by keeping th= at architecture, although more information must be shared. This preserves t= he architecture and becomes =E2=80=9Cjust=E2=80=9D implementation. This has been brough= t up before. =20 The first draft showed how to do this purely on the server side. Some memb= ers of the WG rose up and wanted explicit opt-in. The new draft does that. = In retrospect, it turns out that opt-in is worse, mainly that there is no wa= y to guarantee that this does not =E2=80=9Cescape=E2=80=9D onto the public Internet. Thi= s makes sense, if you require opt-in from the client, then it is not surpris= ing that, other entities besides the two parties engaged in the TLS protocol= could, well, *require* clients to opt-in. As I and others have tried to sh= ow in email exchangers with Paul, this is a fundamental change to the nature= of how TLS is used. =20 Finally, as has also been mentioned, nobody is preventing you from keeping = your servers at TLS 1.2 or earlier. TLS 1.2 was defined by RFC 5246 in 2008= . A decade later, PCI-DSS is only =E2=80=98strongly encouraging=E2=80=99 TLS 1.2; the ac= tual requirement is TLS 1.1! Why should we expect that TLS 1.3 will happen a= ny faster? =20 You have not made your case. =20 --B_3591339260_159244428 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

+1 to Rich.

 

--

Regards,

U= ri Blumenthal

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in = 0in'>

From: TLS <tls-bounces@ietf.org> on behalf of Rich Salz <rsalz@akamai.= com>
Date: Friday, October 20, 2017 at 09:59
To: Dari= n Pettis <dpp.edco@gmail.com>, "tls@ietf.org" <tls@ietf.o= rg>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visi= bility-00

 

=C3=98  The question has been raised: "Why address visibility no= w?"   The answer is that it is critical that the visibility capabi= lity is retained.  It is available today through the RSA key exchange a= lgorithm.  We understand that the issue was raised late and have fallen= on the preverbal sword for being late to the party but the issue is real.&n= bsp; That is where the "rhrd" draft has come from.  A way to = retain that visibility capability but with a newer and more secure protocol.=  

 

You achieve your needs righ= t now by sharing the origin=E2=80=99s RSA key with your debugging agents.  Yo= u can achieve the same needs in TLS 1.3 by keeping that architecture, althou= gh more information must be shared.  This preserves the architecture an= d becomes =E2=80=9Cjust=E2=80=9D implementation.  This has been brought up before.<= /span>

 

The first= draft showed how to do this purely on the server side.  Some members o= f the WG rose up and wanted explicit opt-in. The new draft does that.  = In retrospect, it turns out that opt-in is worse, mainly that there is no wa= y to guarantee that this does not =E2=80=9Cescape=E2=80=9D onto the public Internet. Thi= s makes sense, if you require opt-in from the client, then it is not surpris= ing that, other entities besides the two parties engaged in the TLS protocol= could, well, *require* clients to opt-in.  As I and others have= tried to show in email exchangers with Paul, this is a fundamental change t= o the nature of how TLS is used.

 

Finally, as has also been mentioned, nobo= dy is preventing you from keeping your servers at TLS 1.2 or earlier.  = TLS 1.2 was defined by RFC 5246 in 2008. A decade later, PCI-DSS is only =E2=80=98= strongly encouraging=E2=80=99 TLS 1.2; the actual requirement is TLS 1.1! Why shou= ld we expect that TLS 1.3 will happen any faster?

 

You have not made your case.=

 <= o:p>

--B_3591339260_159244428-- --B_3591339260_12856504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgq8kuEwZ5nrlBpm71 NIehuIqrKTjakEuxL+zenJOD9fwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcxMDIwMTQxNDIwWjANBgkqhkiG9w0BAQEFAASCAQBGd10FzBxU83vrHP2Q OZu3ToYQtK0hFK5W0gUOCjDI4GZQ5VdflRM3c5Muc3BEx+o8CVI6mAGigBDOunabXCJvLjK9 xxuUXu+eRJhYDNLoEOOihpEPPkIAPs0ObqXYiRhZiklVxUT5IrF+Q7digNFlWCmTwsVrKjwy 5VCi4XRSzIkXlNrauQDw+kwIw3+kRN9S96wIsICjXpIN78eX0fVY9+5JwRsqfKwUcjZyxx3D 73D+9LodVnz0H8BtBmEFrsDzVe+vYumHR5U38VNCKSwVTTSQcp4rWgKmMGKnFkyhIVMLFzwj yQT3h+9DRNZKj5k+8VeT63l0LnRadiY0PiTq --B_3591339260_12856504-- From nobody Fri Oct 20 09:00:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BFD1342CE for ; Fri, 20 Oct 2017 09:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 zmnS-AASUsf0 for ; Fri, 20 Oct 2017 09:00:08 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 7C1DF1342D2 for ; Fri, 20 Oct 2017 09:00:08 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id E28DF1C0AEE for ; Fri, 20 Oct 2017 11:00:07 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id E23FD1C0AA8; Fri, 20 Oct 2017 11:00:06 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93F6092065; Fri, 20 Oct 2017 12:00:06 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 45B8E9206F; Fri, 20 Oct 2017 12:00:06 -0400 (EDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (unknown [216.32.180.16]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Fri, 20 Oct 2017 12:00:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=53Di2Zt+jKGpVSQeSLXhIkhxaOfm1unpriPYCuLud1A=; b=o8wZgp8nXVZNwAi1zTxdrx5mieq/S2jX7Fl+BZeJsVaU6AUviDkwMMo8QWDkUP+eWU3c4v9hkR7tNM1vRhWM1s7MCMaqqlMzj17pWqbsv6f3SV6C2usFX99YFpwewJ+75O/MwO0Ej+qiwhzTeESI/N/iqMgsCypL0+bX8KPWxeE= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 20 Oct 2017 16:00:01 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Fri, 20 Oct 2017 16:00:01 +0000 From: "Ackermann, Michael" To: "Salz, Rich" , Darin Pettis , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAA== Date: Fri, 20 Oct 2017 16:00:01 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> In-Reply-To: <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.74] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 20:XNmo6SHLR8S2IyIciiQMMMhExBxtN5x2lIlVGIjAikN/+6ex/xe+SPKfUgIKtdV2mJf5QexbUVYyPdbF8qMRa0aqgYw+szJ/Np3mqnBhPzvfkL4HvAu3NwKa5dQ8Sy5BKQCfAulnO6l776ZoEpkULYEpJ6RrCGp7kmUL317G2zE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 50a2a135-035e-4e17-ee3a-08d517d39ee3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1365; x-ms-traffictypediagnostic: CY4PR14MB1365: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(192374486261705)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1365; x-forefront-prvs: 0466CA5A45 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(376002)(189002)(199003)(2501003)(105586002)(316002)(53546010)(110136005)(7696004)(86362001)(81156014)(81166006)(74316002)(8936002)(5660300001)(102836003)(6246003)(478600001)(106356001)(7736002)(3846002)(80792005)(93886005)(72206003)(54896002)(8676002)(790700001)(33656002)(9686003)(2950100002)(39060400002)(6306002)(66066001)(25786009)(99286003)(76176999)(229853002)(6506006)(50986999)(6116002)(55016002)(97736004)(53936002)(6436002)(101416001)(3280700002)(189998001)(77096006)(14454004)(236005)(2900100001)(68736007)(2906002)(54356999)(230783001)(3660700001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368CBA562220D9A3604F0FFD7430CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 16:00:01.2350 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 4fac1d6d-08bd-4fb2-966c-5e67cb3f3b6f X-VPM-MSG-ID: 6bb20f90-d663-46ef-875e-dcfb2bb33345 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:00:16 -0000 --_000_CY4PR14MB1368CBA562220D9A3604F0FFD7430CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhwcmVzc2x5IHJlYWN0aW5nIHRvIHRoZSB2aWFiaWxpdHkgb2YgY29udGludWluZyB0byB1 c2UgVExTMS4yIGZvcmV2ZXIuDQoNCkFzIGEgbmV0d29yayBwZXJzb24sICB0aGlzIHNvdW5k cyBhIGxpdHRsZSBsaWtlIHN1Z2dlc3RpbmcgdGhhdCBpZiB3ZSBmZWVsIHRoZXJlIGFyZSBv cGVyYXRpb25hbCAgc2hvcnRjb21pbmdzIGluIElQdjYsICB0aGVuIHdlIHNob3VsZCBqdXN0 IHBsYW4gdG8gc3RheSB3aXRoIElQdjQsIGZvcmV2ZXIuDQpBbmQgdGhhdCBhcHByb2FjaCBt YXkgZXZlbiBiZSB2aWFibGUgZm9yIHRoZSBzaG9ydCB0ZXJtIG9yIGluIGlzb2xhdGVkIHNp dHVhdGlvbnMuDQpCdXQgZm9yIHRoZSBsb25nZXIgdGVybSB1c2luZyBUTFMxLjIgaXMgbGlr ZWx5IHRvIGhhdmUgdGhlIGZvbGxvd2luZyBpc3N1ZXMgZm9yIEVudGVycHJpc2VzOg0KDQog ICogICBJbmR1c3RyeSBncm91cHMgd2lsbCBmb3JjZSB1cyB0byB1c2UgbmV3ZXIgdmVyc2lv bnMNCiAgKiAgIFBvbGljeSBzdGFuZGFyZHMgd2lsbCBldm9sdmUgaW4gc2ltaWxhciBmYXNo aW9ucy4NCiAgKiAgIExpa2VseSB0aGVyZSB3aWxsIGJlIHJlZ3VsYXRvcnkgbWFuZGF0ZXMg aW4gbWFueSBvZiB0aGUgbWFya2V0cGxhY2VzIGFuZCBidXNpbmVzcyBzZWdtZW50cyB0aGF0 IGxhcmdlIEVudGVycHJpc2VzIHBhcnRpY2lwYXRlIGluLg0KICAqICAgU29mdHdhcmUgUHJv ZHVjdHMgYW5kIEFwcGxpY2F0aW9ucyB3aWxsIGF0dGVtcHQgdG8gcmVtYWluIGN1cnJlbnQg YW5kIHdpbGwgZXZlbnR1YWxseSBzdW5zZXQgc3VwcG9ydCBmb3Igb2xkZXIgcHJvdG9jb2wg dmVyc2lvbnMNCiAgKiAgIEJ1c2luZXNzIFBhcnRuZXJzIG9yIEdvdmVybm1lbnQgYWdlbmN5 IGN1c3RvbWVycyBtYXkgcmVxdWlyZSBUTFMxLjMuDQogICogICBJbnRlcm5hbCBTZWN1cml0 eSBUZWFtcyBtYXkgcmVxdWlyZSBUTFMxLjMsIGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVy ZS4gICAgQW5kIHRoZXkgc2hvdWxkISAgICBBbmQgd2h5IHNob3VsZCB3ZSBOT1Qgd2FudCAg YW5kIGJlIGFibGUgdG8gdXRpbGl6ZSBUTFMgMS4zIHdpdGggaXTigJlzIHVwZGF0ZWQgYW5k IGVuaGFuY2VkIGNhcGFiaWxpdGllcy4gIFdlIERPIFdBTlQgVEhJUyEgICBXZSBqdXN0IHN0 aWxsIG5lZWQgdG8gcnVuIG91ciBuZXR3b3JrcyBhbmQgYnVzaW5lc3NlcyBhbmQgYXJlIGJh ZGx5IHdhbnRpbmcgdG8gd29yayB3aXRoIHRoZSBXb3JraW5nIEdyb3VwIHRvIGFzc3VyZSBv dXIgdXNlIGNhc2VzIGNhbiBiZSBhY2NvbW1vZGF0ZWQsIGlmIGF0IGFsbCBwb3NzaWJsZS4N CiAgKiAgIEFuZCB0aGlua2luZyBmdXJ0aGVyIGFoZWFkLCAgd2hhdCB3b3VsZCBiZSB0aGUg ZXh0ZW5kZWQgcHJvcG9zZWQgc3RyYXRlZ3ksICB3aGVuIFRMUyAxLjQgKG9yIHdoYXRldmVy IGNvbWVzIG5leHQpLCAgaXMgZmluYWxpemVkLiAgICAgICAgQWRvcHRpbmcgc3VjaCBhIOKA nFN0YXkgd2l0aCB0aGUgb2xkIHByb2R1Y3QgZm9yZXZlcuKAnSAgd291bGQgc2VlbSB0byBi ZSB0YW50YW1vdW50IHRvIGhvcGluZyB0aGF0IFRMUyAxLjMgKGFuZCAxLjQsIGV0Yy4pLCAg bmV2ZXIgZ2V0IGRlcGxveWVkLiAgIEZvciBWRVJZIFNlY3VyaXR5IGZvY3VzZWQgaW5kdXN0 cmllcywgIHN1Y2ggYXMgaGVhbHRoY2FyZSBhbmQgZmluYW5jZSwgIHRoaXMgaXMgZGlyZWN0 bHkgb3Bwb3NpdGUgb2Ygd2hhdCB3ZSB3YW50LCBuZWVkIGFuZCBzdXBwb3J0LiAgIFdlIG5l ZWQgc2VjdXJpdHkgcHJvdG9jb2xzIHRvIGNvbnRpbnVlIHRvIGV2b2x2ZSwgaW1wcm92ZSBh bmQgYmVjb21lIGFzIGVmZmVjdGl2ZSBhcyBwb3NzaWJsZSwgIGJ1dCB0aGV5IG5lZWQgdG8g bW92ZSBmb3J3YXJkIHdpdGggdGhlIHVuZGVyc3RhbmRpbmcgIHRoYXQgb3BlcmF0aW9uYWwg cGVyc3BlY3RpdmVzIGFyZSBpbXBvcnRhbnQgYXMgd2VsbC4NCg0KDQoNCg0KRnJvbTogVExT IFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTYWx6LCBSaWNo DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjAsIDIwMTcgOTo0NCBBTQ0KVG86IERhcmluIFBl dHRpcyA8ZHBwLmVkY29AZ21haWwuY29tPG1haWx0bzpkcHAuZWRjb0BnbWFpbC5jb20+Pjsg dGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10g UHVibGljYXRpb24gb2YgZHJhZnQtcmhyZC10bHMtdGxzMTMtdmlzaWJpbGl0eS0wMA0KDQoN CiAgKiAgIFRoZSBxdWVzdGlvbiBoYXMgYmVlbiByYWlzZWQ6ICJXaHkgYWRkcmVzcyB2aXNp YmlsaXR5IG5vdz8iICAgVGhlIGFuc3dlciBpcyB0aGF0IGl0IGlzIGNyaXRpY2FsIHRoYXQg dGhlIHZpc2liaWxpdHkgY2FwYWJpbGl0eSBpcyByZXRhaW5lZC4gIEl0IGlzIGF2YWlsYWJs ZSB0b2RheSB0aHJvdWdoIHRoZSBSU0Ega2V5IGV4Y2hhbmdlIGFsZ29yaXRobS4gIFdlIHVu ZGVyc3RhbmQgdGhhdCB0aGUgaXNzdWUgd2FzIHJhaXNlZCBsYXRlIGFuZCBoYXZlIGZhbGxl biBvbiB0aGUgcHJldmVyYmFsIHN3b3JkIGZvciBiZWluZyBsYXRlIHRvIHRoZSBwYXJ0eSBi dXQgdGhlIGlzc3VlIGlzIHJlYWwuICBUaGF0IGlzIHdoZXJlIHRoZSAicmhyZCIgZHJhZnQg aGFzIGNvbWUgZnJvbS4gIEEgd2F5IHRvIHJldGFpbiB0aGF0IHZpc2liaWxpdHkgY2FwYWJp bGl0eSBidXQgd2l0aCBhIG5ld2VyIGFuZCBtb3JlIHNlY3VyZSBwcm90b2NvbC4NCg0KWW91 IGFjaGlldmUgeW91ciBuZWVkcyByaWdodCBub3cgYnkgc2hhcmluZyB0aGUgb3JpZ2lu4oCZ cyBSU0Ega2V5IHdpdGggeW91ciBkZWJ1Z2dpbmcgYWdlbnRzLiAgWW91IGNhbiBhY2hpZXZl IHRoZSBzYW1lIG5lZWRzIGluIFRMUyAxLjMgYnkga2VlcGluZyB0aGF0IGFyY2hpdGVjdHVy ZSwgYWx0aG91Z2ggbW9yZSBpbmZvcm1hdGlvbiBtdXN0IGJlIHNoYXJlZC4gIFRoaXMgcHJl c2VydmVzIHRoZSBhcmNoaXRlY3R1cmUgYW5kIGJlY29tZXMg4oCcanVzdOKAnSBpbXBsZW1l bnRhdGlvbi4gIFRoaXMgaGFzIGJlZW4gYnJvdWdodCB1cCBiZWZvcmUuDQoNClRoZSBmaXJz dCBkcmFmdCBzaG93ZWQgaG93IHRvIGRvIHRoaXMgcHVyZWx5IG9uIHRoZSBzZXJ2ZXIgc2lk ZS4gIFNvbWUgbWVtYmVycyBvZiB0aGUgV0cgcm9zZSB1cCBhbmQgd2FudGVkIGV4cGxpY2l0 IG9wdC1pbi4gVGhlIG5ldyBkcmFmdCBkb2VzIHRoYXQuICBJbiByZXRyb3NwZWN0LCBpdCB0 dXJucyBvdXQgdGhhdCBvcHQtaW4gaXMgd29yc2UsIG1haW5seSB0aGF0IHRoZXJlIGlzIG5v IHdheSB0byBndWFyYW50ZWUgdGhhdCB0aGlzIGRvZXMgbm90IOKAnGVzY2FwZeKAnSBvbnRv IHRoZSBwdWJsaWMgSW50ZXJuZXQuIFRoaXMgbWFrZXMgc2Vuc2UsIGlmIHlvdSByZXF1aXJl IG9wdC1pbiBmcm9tIHRoZSBjbGllbnQsIHRoZW4gaXQgaXMgbm90IHN1cnByaXNpbmcgdGhh dCwgb3RoZXIgZW50aXRpZXMgYmVzaWRlcyB0aGUgdHdvIHBhcnRpZXMgZW5nYWdlZCBpbiB0 aGUgVExTIHByb3RvY29sIGNvdWxkLCB3ZWxsLCAqcmVxdWlyZSogY2xpZW50cyB0byBvcHQt aW4uICBBcyBJIGFuZCBvdGhlcnMgaGF2ZSB0cmllZCB0byBzaG93IGluIGVtYWlsIGV4Y2hh bmdlcnMgd2l0aCBQYXVsLCB0aGlzIGlzIGEgZnVuZGFtZW50YWwgY2hhbmdlIHRvIHRoZSBu YXR1cmUgb2YgaG93IFRMUyBpcyB1c2VkLg0KDQpGaW5hbGx5LCBhcyBoYXMgYWxzbyBiZWVu IG1lbnRpb25lZCwgbm9ib2R5IGlzIHByZXZlbnRpbmcgeW91IGZyb20ga2VlcGluZyB5b3Vy IHNlcnZlcnMgYXQgVExTIDEuMiBvciBlYXJsaWVyLiAgVExTIDEuMiB3YXMgZGVmaW5lZCBi eSBSRkMgNTI0NiBpbiAyMDA4LiBBIGRlY2FkZSBsYXRlciwgUENJLURTUyBpcyBvbmx5IOKA mHN0cm9uZ2x5IGVuY291cmFnaW5n4oCZIFRMUyAxLjI7IHRoZSBhY3R1YWwgcmVxdWlyZW1l bnQgaXMgVExTIDEuMSEgV2h5IHNob3VsZCB3ZSBleHBlY3QgdGhhdCBUTFMgMS4zIHdpbGwg aGFwcGVuIGFueSBmYXN0ZXI/DQoNCllvdSBoYXZlIG5vdCBtYWRlIHlvdXIgY2FzZS4NCg0K CgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBo aWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGly ZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUg b3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25l LCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1l c3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGllcy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNo aWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJl IG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0 aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uCg== --_000_CY4PR14MB1368CBA562220D9A3604F0FFD7430CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlQm9keTt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTc3 MjQ3NDg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi01MzIxMDMwNzIgLTMyNzY0Nzg0MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM4NjM7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjMzMzkyMTc5MjsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MjAxODgyNTAwMDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjg2 MTE2MzY1ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTQ5NTMxNzk1NCAyMTM2MjI3MDEwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwy OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTk7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxODk2NzQ0NDY1Ow0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTE1Nzc0MzA0Njt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RXhwcmVzc2x5IHJlYWN0aW5nIHRvIHRoZSB2aWFiaWxpdHkgb2YgY29udGludWluZyB0 byB1c2UgVExTMS4yIGZvcmV2ZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg YSBuZXR3b3JrIHBlcnNvbiwmbmJzcDsgdGhpcyBzb3VuZHMgYSBsaXR0bGUgbGlrZSBzdWdn ZXN0aW5nIHRoYXQgaWYgd2UgZmVlbCB0aGVyZSBhcmUgb3BlcmF0aW9uYWwmbmJzcDsgc2hv cnRjb21pbmdzIGluIElQdjYsJm5ic3A7IHRoZW4gd2Ugc2hvdWxkIGp1c3QgcGxhbiB0byBz dGF5IHdpdGggSVB2NCwgZm9yZXZlci4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5kIHRoYXQgYXBwcm9hY2ggbWF5IGV2ZW4gYmUgdmlhYmxlIGZv ciB0aGUgc2hvcnQgdGVybSBvciBpbiBpc29sYXRlZCBzaXR1YXRpb25zLg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgZm9yIHRoZSBsb25nZXIgdGVybSB1 c2luZyBUTFMxLjIgaXMgbGlrZWx5IHRvIGhhdmUgdGhlIGZvbGxvd2luZyBpc3N1ZXMgZm9y IEVudGVycHJpc2VzOiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5JbmR1c3RyeSBncm91 cHMgd2lsbCBmb3JjZSB1cyB0byB1c2UgbmV3ZXIgdmVyc2lvbnM8bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzMiPlBvbGljeSBzdGFuZGFyZHMgd2lsbCBldm9sdmUgaW4gc2ltaWxh ciBmYXNoaW9ucy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPkxpa2VseSB0aGVy ZSB3aWxsIGJlIHJlZ3VsYXRvcnkgbWFuZGF0ZXMgaW4gbWFueSBvZiB0aGUgbWFya2V0cGxh Y2VzIGFuZCBidXNpbmVzcyBzZWdtZW50cyB0aGF0IGxhcmdlIEVudGVycHJpc2VzIHBhcnRp Y2lwYXRlIGluLiZuYnNwOw0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5Tb2Z0 d2FyZSBQcm9kdWN0cyBhbmQgQXBwbGljYXRpb25zIHdpbGwgYXR0ZW1wdCB0byByZW1haW4g Y3VycmVudCBhbmQgd2lsbCBldmVudHVhbGx5IHN1bnNldCBzdXBwb3J0IGZvciBvbGRlciBw cm90b2NvbCB2ZXJzaW9ucw0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5CdXNp bmVzcyBQYXJ0bmVycyBvciBHb3Zlcm5tZW50IGFnZW5jeSBjdXN0b21lcnMgbWF5IHJlcXVp cmUgVExTMS4zLiZuYnNwOw0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5JbnRl cm5hbCBTZWN1cml0eSBUZWFtcyBtYXkgcmVxdWlyZSBUTFMxLjMsIGF0IHNvbWUgcG9pbnQg aW4gdGhlIGZ1dHVyZS4mbmJzcDsmbmJzcDsmbmJzcDsgQW5kIHRoZXkgc2hvdWxkISZuYnNw OyZuYnNwOyZuYnNwOyBBbmQgd2h5IHNob3VsZCB3ZSBOT1Qgd2FudCZuYnNwOyBhbmQgYmUg YWJsZSB0byB1dGlsaXplIFRMUyAxLjMgd2l0aCBpdOKAmXMgdXBkYXRlZCBhbmQgZW5oYW5j ZWQgY2FwYWJpbGl0aWVzLiZuYnNwOw0KIFdlIERPIFdBTlQgVEhJUyEmbmJzcDsmbmJzcDsg V2UganVzdCBzdGlsbCBuZWVkIHRvIHJ1biBvdXIgbmV0d29ya3MgYW5kIGJ1c2luZXNzZXMg YW5kIGFyZSBiYWRseSB3YW50aW5nIHRvIHdvcmsgd2l0aCB0aGUgV29ya2luZyBHcm91cCB0 byBhc3N1cmUgb3VyIHVzZSBjYXNlcyBjYW4gYmUgYWNjb21tb2RhdGVkLCBpZiBhdCBhbGwg cG9zc2libGUuJm5ic3A7DQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPkFuZCB0 aGlua2luZyBmdXJ0aGVyIGFoZWFkLCZuYnNwOyB3aGF0IHdvdWxkIGJlIHRoZSBleHRlbmRl ZCBwcm9wb3NlZCBzdHJhdGVneSwmbmJzcDsgd2hlbiBUTFMgMS40IChvciB3aGF0ZXZlciBj b21lcyBuZXh0KSwmbmJzcDsgaXMgZmluYWxpemVkLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBBZG9wdGluZyBzdWNoIGEg4oCcU3RheSB3aXRoIHRoZSBv bGQgcHJvZHVjdCBmb3JldmVy4oCdJm5ic3A7DQogd291bGQgc2VlbSB0byBiZSB0YW50YW1v dW50IHRvIGhvcGluZyB0aGF0IFRMUyAxLjMgKGFuZCAxLjQsIGV0Yy4pLCZuYnNwOyBuZXZl ciBnZXQgZGVwbG95ZWQuJm5ic3A7Jm5ic3A7IEZvciBWRVJZIFNlY3VyaXR5IGZvY3VzZWQg aW5kdXN0cmllcywmbmJzcDsgc3VjaCBhcyBoZWFsdGhjYXJlIGFuZCBmaW5hbmNlLCZuYnNw OyB0aGlzIGlzIGRpcmVjdGx5IG9wcG9zaXRlIG9mIHdoYXQgd2Ugd2FudCwgbmVlZCBhbmQg c3VwcG9ydC4mbmJzcDsmbmJzcDsgV2UgbmVlZCBzZWN1cml0eSBwcm90b2NvbHMgdG8NCiBj b250aW51ZSB0byBldm9sdmUsIGltcHJvdmUgYW5kIGJlY29tZSBhcyBlZmZlY3RpdmUgYXMg cG9zc2libGUsJm5ic3A7IGJ1dCB0aGV5IG5lZWQgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhl IHVuZGVyc3RhbmRpbmcgJm5ic3A7dGhhdCBvcGVyYXRpb25hbCBwZXJzcGVjdGl2ZXMgYXJl IGltcG9ydGFudCBhcyB3ZWxsLg0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENv bXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFRMUyBb PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86dGxzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TYWx6LCBSaWNoPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAyMCwgMjAxNyA5OjQ0IEFNPGJyPg0KPGI+ VG86PC9iPiBEYXJpbiBQZXR0aXMgJmx0OzxhIGhyZWY9Im1haWx0bzpkcHAuZWRjb0BnbWFp bC5jb20iPmRwcC5lZGNvQGdtYWlsLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnRs c0BpZXRmLm9yZyI+dGxzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1RMU10gUHVibGljYXRpb24gb2YgZHJhZnQtcmhyZC10bHMtdGxzMTMtdmlzaWJpbGl0eS0w MDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiM0NTQ1NDU7 bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm82Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlQm9keSI+ VGhlIHF1ZXN0aW9uIGhhcyBiZWVuIHJhaXNlZDogJnF1b3Q7V2h5IGFkZHJlc3MgdmlzaWJp bGl0eSBub3c/JnF1b3Q7ICZuYnNwOyBUaGUgYW5zd2VyIGlzIHRoYXQgaXQgaXMgY3JpdGlj YWwgdGhhdCB0aGUgdmlzaWJpbGl0eSBjYXBhYmlsaXR5IGlzIHJldGFpbmVkLiZuYnNwOyBJ dCBpcyBhdmFpbGFibGUgdG9kYXkgdGhyb3VnaCB0aGUgUlNBIGtleSBleGNoYW5nZQ0KIGFs Z29yaXRobS4mbmJzcDsgV2UgdW5kZXJzdGFuZCB0aGF0IHRoZSBpc3N1ZSB3YXMgcmFpc2Vk IGxhdGUgYW5kIGhhdmUgZmFsbGVuIG9uIHRoZSBwcmV2ZXJiYWwgc3dvcmQgZm9yIGJlaW5n IGxhdGUgdG8gdGhlIHBhcnR5IGJ1dCB0aGUgaXNzdWUgaXMgcmVhbC4mbmJzcDsgVGhhdCBp cyB3aGVyZSB0aGUgJnF1b3Q7cmhyZCZxdW90OyBkcmFmdCBoYXMgY29tZSBmcm9tLiZuYnNw OyBBIHdheSB0byByZXRhaW4gdGhhdCB2aXNpYmlsaXR5IGNhcGFiaWxpdHkgYnV0IHdpdGgg YSBuZXdlciBhbmQNCiBtb3JlIHNlY3VyZSBwcm90b2NvbC4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVCb2R5 O2NvbG9yOiM0NTQ1NDUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu MHB0O2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlQm9keTtjb2xvcjojNDU0NTQ1Ij5Z b3UgYWNoaWV2ZSB5b3VyIG5lZWRzIHJpZ2h0IG5vdyBieSBzaGFyaW5nIHRoZSBvcmlnaW7i gJlzIFJTQSBrZXkgd2l0aCB5b3VyIGRlYnVnZ2luZyBhZ2VudHMuJm5ic3A7IFlvdSBjYW4g YWNoaWV2ZSB0aGUgc2FtZSBuZWVkcyBpbiBUTFMgMS4zIGJ5IGtlZXBpbmcgdGhhdCBhcmNo aXRlY3R1cmUsDQogYWx0aG91Z2ggbW9yZSBpbmZvcm1hdGlvbiBtdXN0IGJlIHNoYXJlZC4m bmJzcDsgVGhpcyBwcmVzZXJ2ZXMgdGhlIGFyY2hpdGVjdHVyZSBhbmQgYmVjb21lcyDigJxq dXN04oCdIGltcGxlbWVudGF0aW9uLiZuYnNwOyBUaGlzIGhhcyBiZWVuIGJyb3VnaHQgdXAg YmVmb3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0 eWxlQm9keTtjb2xvcjojNDU0NTQ1Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250 LWZhbWlseTpVSUNURm9udFRleHRTdHlsZUJvZHk7Y29sb3I6IzQ1NDU0NSI+VGhlIGZpcnN0 IGRyYWZ0IHNob3dlZCBob3cgdG8gZG8gdGhpcyBwdXJlbHkgb24gdGhlIHNlcnZlciBzaWRl LiZuYnNwOyBTb21lIG1lbWJlcnMgb2YgdGhlIFdHIHJvc2UgdXAgYW5kIHdhbnRlZCBleHBs aWNpdCBvcHQtaW4uIFRoZSBuZXcgZHJhZnQgZG9lcyB0aGF0LiZuYnNwOyBJbiByZXRyb3Nw ZWN0LA0KIGl0IHR1cm5zIG91dCB0aGF0IG9wdC1pbiBpcyB3b3JzZSwgbWFpbmx5IHRoYXQg dGhlcmUgaXMgbm8gd2F5IHRvIGd1YXJhbnRlZSB0aGF0IHRoaXMgZG9lcyBub3Qg4oCcZXNj YXBl4oCdIG9udG8gdGhlIHB1YmxpYyBJbnRlcm5ldC4gVGhpcyBtYWtlcyBzZW5zZSwgaWYg eW91IHJlcXVpcmUgb3B0LWluIGZyb20gdGhlIGNsaWVudCwgdGhlbiBpdCBpcyBub3Qgc3Vy cHJpc2luZyB0aGF0LCBvdGhlciBlbnRpdGllcyBiZXNpZGVzIHRoZSB0d28gcGFydGllcw0K IGVuZ2FnZWQgaW4gdGhlIFRMUyBwcm90b2NvbCBjb3VsZCwgd2VsbCwgKjxiPnJlcXVpcmU8 L2I+KiBjbGllbnRzIHRvIG9wdC1pbi4mbmJzcDsgQXMgSSBhbmQgb3RoZXJzIGhhdmUgdHJp ZWQgdG8gc2hvdyBpbiBlbWFpbCBleGNoYW5nZXJzIHdpdGggUGF1bCwgdGhpcyBpcyBhIGZ1 bmRhbWVudGFsIGNoYW5nZSB0byB0aGUgbmF0dXJlIG9mIGhvdyBUTFMgaXMgdXNlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTpVSUNURm9udFRl eHRTdHlsZUJvZHk7Y29sb3I6IzQ1NDU0NSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7 Zm9udC1mYW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVCb2R5O2NvbG9yOiM0NTQ1NDUiPkZpbmFs bHksIGFzIGhhcyBhbHNvIGJlZW4gbWVudGlvbmVkLCBub2JvZHkgaXMgcHJldmVudGluZyB5 b3UgZnJvbSBrZWVwaW5nIHlvdXIgc2VydmVycyBhdCBUTFMgMS4yIG9yIGVhcmxpZXIuJm5i c3A7IFRMUyAxLjIgd2FzIGRlZmluZWQgYnkgUkZDIDUyNDYgaW4gMjAwOC4gQSBkZWNhZGUN CiBsYXRlciwgUENJLURTUyBpcyBvbmx5IOKAmHN0cm9uZ2x5IGVuY291cmFnaW5n4oCZIFRM UyAxLjI7IHRoZSBhY3R1YWwgcmVxdWlyZW1lbnQgaXMgVExTIDEuMSEgV2h5IHNob3VsZCB3 ZSBleHBlY3QgdGhhdCBUTFMgMS4zIHdpbGwgaGFwcGVuIGFueSBmYXN0ZXI/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy4wcHQ7Zm9udC1mYW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVCb2R5O2NvbG9yOiM0 NTQ1NDUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OlVJQ1RGb250 VGV4dFN0eWxlQm9keTtjb2xvcjojNDU0NTQ1Ij5Zb3UgaGF2ZSBub3QgbWFkZSB5b3VyIGNh c2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVC b2R5O2NvbG9yOiM0NTQ1NDUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQoKCjxCUj4KPGh0bWw+CiA8cD5UaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29u ZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJp YnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkg dW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0 aG91dCBtYWtpbmcgYW55IGNvcGllcy48L3A+CiA8cD5CbHVlIENyb3NzIEJsdWUgU2hpZWxk IG9mIE1pY2hpZ2FuIGFuZCBCbHVlIENhcmUgTmV0d29yayBvZiBNaWNoaWdhbiBhcmUgbm9u cHJvZml0IGNvcnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRlbnQgbGljZW5zZWVzIG9mIHRoZSBC bHVlIENyb3NzIGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lhdGlvbi48L3A+CiAgPC9odG1sPgoK --_000_CY4PR14MB1368CBA562220D9A3604F0FFD7430CY4PR14MB1368namp_-- From nobody Fri Oct 20 09:14:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E321342DB for ; Fri, 20 Oct 2017 09:14:31 -0700 (PDT) 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 HQs0lgTmadF9 for ; Fri, 20 Oct 2017 09:14:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8DEA1342C0 for ; Fri, 20 Oct 2017 09:14:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 98092BE39; Fri, 20 Oct 2017 17:14:28 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLqUaFe3DNkb; Fri, 20 Oct 2017 17:14:22 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8327ABE2F; Fri, 20 Oct 2017 17:14:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508516062; bh=IimbJrm3zwjhHRsO80mryvM/YP6RsS1mmpLcow60CjQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=u00Y5s80l2ghmSSL2lqjeovAl8lcFXtbwIU70m+1dTkrBTG1RMc2k87EY7nF1aaJd s+usZZKg5stqKtiy4fZB6dqanHZ+5ZcVJL2b0X57Bf2CPyoPUF1jLymwbp70DZ2653 j+sGGz1pPYPU2f45n8yEE7EFXoErrC3YXRkgJ7LY= To: "Ackermann, Michael" , "Salz, Rich" , Darin Pettis , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> Date: Fri, 20 Oct 2017 17:14:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cTQ3dbi806e5Q1Bth18Auvtr7tj3OCX6X" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:14:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cTQ3dbi806e5Q1Bth18Auvtr7tj3OCX6X Content-Type: multipart/mixed; boundary="koarx3q7Cludr7p9GsbujmE78kJ0HPMNc"; protected-headers="v1" From: Stephen Farrell To: "Ackermann, Michael" , "Salz, Rich" , Darin Pettis , "tls@ietf.org" Message-ID: <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> In-Reply-To: --koarx3q7Cludr7p9GsbujmE78kJ0HPMNc Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 20/10/17 17:00, Ackermann, Michael wrote: > Expressly reacting to the viability of continuing to use TLS1.2 forever= =2E Sorry, that's just misquoting. Rich asked "why do the WG need to debate this now" Darin said "we must, because we need snooping..." I said "no, you can use TLS1.2 and debate this after TLS1.3 is done." That is nothing like saying "use TLS1.2 forever." Please don't misquote like that. S --koarx3q7Cludr7p9GsbujmE78kJ0HPMNc-- --cTQ3dbi806e5Q1Bth18Auvtr7tj3OCX6X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ6iDeAAoJEC88hzaAX42ibrwIAIWLYHA8mmd1i/qZHlAHbf+u 2f8BxAIYdR9gZlh9YptKtIQ5MS+8T0JnYj/afaN0bYfwgwb89oEB+LTpxdNyLVgk TIda93LCcHKU2RfwrIRTvAywb7Uacu/yqM9dvzO1dS3oYNX/pHjSh3K4hUE6m5B1 08OlsLQv6yOlFJ86i/40zlAyQrdOUnGumHtBlPAdeFuE9OxPEDmzGKlNaD0uK6qz biBE6N/C7C8SQ48RaMEwharZRlkWYv2jIp1o64qoN7K1BLyUkFr5g8snNMnU6QDr 7GPlOqMWTmtjNitVeA/AA5bxAKbWfTJSatFiPuYPf8kwnXaQEJQhNWfOI+Z5g7A= =c5YF -----END PGP SIGNATURE----- --cTQ3dbi806e5Q1Bth18Auvtr7tj3OCX6X-- From nobody Fri Oct 20 09:24:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5275613331E for ; Fri, 20 Oct 2017 09:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 G1pAvKKoxAK5 for ; Fri, 20 Oct 2017 09:23:58 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D361332F2 for ; Fri, 20 Oct 2017 09:23:58 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9KGMPjY009961; Fri, 20 Oct 2017 17:23:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=kQ6ZoA8APpICN8yob9UCldXwZNkq2tLsox888CEu9h8=; b=AOc5cPJ0wupBM90VmZSCH4wGnaffrixqPRwBiHTAfYAdPUAyHHZKC441ggeTZ2FqgMcn r87B6vHCi/29IC0ITxIxsHbZvBUdEBn4EVOdiH50NXU0UuQFksZYH2ltLP7bhZAzuBwb DyHJsnUVYPUJZ5YPSA4X7tpxD2WCjWFuGUoH54sLSS6ukpgV0wVdRJbkUGvNSV6FS62K SmJR7FdhfRiWNbEfgngbFctiMz9PG+gYJ0gSnU/+UYAGik2T1exhZ7Zyk2+en/PBwg34 rYqYuFmXbuXVNI0WqTPCL7fcWEnTVd0nNiJb9DDLKwK5f3vlPTjzUvAGGoCX3/0kR3/p lw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2dngpbtxce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 17:23:53 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9KGKpcm008773; Fri, 20 Oct 2017 12:23:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dkdwwev5p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 12:23:52 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 20 Oct 2017 12:23:51 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 20 Oct 2017 12:23:51 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 20 Oct 2017 12:23:50 -0400 From: "Salz, Rich" To: "Ackermann, Michael" , Darin Pettis , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABqaA Date: Fri, 20 Oct 2017 16:23:50 +0000 Message-ID: <1A894D0A-9B72-4649-A6E3-E9BC0C4F96AA@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@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/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.173] Content-Type: multipart/alternative; boundary="_000_1A894D0A9B724649A6E3E9BC0C4F96AAakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200227 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200228 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:24:00 -0000 --_000_1A894D0A9B724649A6E3E9BC0C4F96AAakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIEV4cHJlc3NseSByZWFjdGluZyB0byB0aGUgdmlhYmlsaXR5IG9mIGNvbnRpbnVp bmcgdG8gdXNlIFRMUzEuMiBmb3JldmVyLg0KDQpOb2JvZHkgaGFzIHNhaWQgdGhhdCwgeW91IGFy ZSBhcmd1aW5nIGEgc3RyYXdtYW4uDQoNCg0KICAqICAgSW5kdXN0cnkgZ3JvdXBzIHdpbGwgZm9y Y2UgdXMgdG8gdXNlIG5ld2VyIHZlcnNpb25zDQogICogICBQb2xpY3kgc3RhbmRhcmRzIHdpbGwg ZXZvbHZlIGluIHNpbWlsYXIgZmFzaGlvbnMuDQogICogICBMaWtlbHkgdGhlcmUgd2lsbCBiZSBy ZWd1bGF0b3J5IG1hbmRhdGVzIGluIG1hbnkgb2YgdGhlIG1hcmtldHBsYWNlcyBhbmQgYnVzaW5l c3Mgc2VnbWVudHMgdGhhdCBsYXJnZSBFbnRlcnByaXNlcyBwYXJ0aWNpcGF0ZSBpbi4NCg0KTm9u ZSBvZiB0aG9zZSBldmVuIHJlcXVpcmUgVExTIDEuMiB5ZXQsIGFuZCBpdCBpcyBhIGRlY2FkZSBv bGQuICBEbyB5b3UgdGhpbmsgYW55IG9mIHRoZW0gd2lsbCBqdW1wIGZyb20gMS4xIHRvIDEuMz8g IFdoYXQgdGltZXRhYmxlIGRvIHlvdSB0aGluayB0aGF0IHdpbGwgaGFwcGVuPyAgQSBkZWNhZGU/ ICBGaXZlIHllYXJzPw0KDQoNCiAgKiAgIFNvZnR3YXJlIFByb2R1Y3RzIGFuZCBBcHBsaWNhdGlv bnMgd2lsbCBhdHRlbXB0IHRvIHJlbWFpbiBjdXJyZW50IGFuZCB3aWxsIGV2ZW50dWFsbHkgc3Vu c2V0IHN1cHBvcnQgZm9yIG9sZGVyIHByb3RvY29sIHZlcnNpb25zDQoNCkFnYWluLCB3aGF0IHRp bWV0YWJsZSBkbyB5b3UgdGhpbmsgdGhhdCB3aWxsIGhhcHBlbj8NCg0KDQogICogICBCdXNpbmVz cyBQYXJ0bmVycyBvciBHb3Zlcm5tZW50IGFnZW5jeSBjdXN0b21lcnMgbWF5IHJlcXVpcmUgVExT MS4zLg0KDQrigJxNYXku4oCdICBEbyB5b3UgaGF2ZSBhbnkgaW5kaWNhdGlvbiB0aGF0IHRoaXMg aXMgYSByZXF1aXJlbWVudD8gIEdvdmVybm1lbnQgdGVuZHMgdG8gd29yayBlaXRoZXIgZmFyIGlu IGFkdmFuY2UgKGxpa2UgTklTVCBwb3N0LXF1YW50dW0gY3J5cHRvKSBvciB0byB0cmFjayBpbmR1 c3RyeS4NCg0KDQogICogICBJbnRlcm5hbCBTZWN1cml0eSBUZWFtcyBtYXkgcmVxdWlyZSBUTFMx LjMsIGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVyZS4gICAgQW5kIHRoZXkgc2hvdWxkISAgICBB bmQgd2h5IHNob3VsZCB3ZSBOT1Qgd2FudCAgYW5kIGJlIGFibGUgdG8gdXRpbGl6ZSBUTFMgMS4z IHdpdGggaXTigJlzIHVwZGF0ZWQgYW5kIGVuaGFuY2VkIGNhcGFiaWxpdGllcy4gIFdlIERPIFdB TlQgVEhJUyEgICBXZSBqdXN0IHN0aWxsIG5lZWQgdG8gcnVuIG91ciBuZXR3b3JrcyBhbmQgYnVz aW5lc3NlcyBhbmQgYXJlIGJhZGx5IHdhbnRpbmcgdG8gd29yayB3aXRoIHRoZSBXb3JraW5nIEdy b3VwIHRvIGFzc3VyZSBvdXIgdXNlIGNhc2VzIGNhbiBiZSBhY2NvbW1vZGF0ZWQsIGlmIGF0IGFs bCBwb3NzaWJsZS4NCg0KWW91ciB1c2UtY2FzZXMgY2FuIGJlIGFjY29tbW9kYXRlZC4gIFlvdSBq dXN0IG5lZWQgdG8gc3BlbmQgc29tZSBtb3JlIG1vbmV5IG9uIHNlcnZlci1zaWRlIHJ1bnRpbWVz IGFuZCBrZXkgbWFuYWdlbWVudC4gIEluc3RlYWQsIHlvdSBwcm9wb3NlIHRvIGZvcmNlIGFsbCBj bGllbnRzIGludG8gYSB3ZWFrZXIgc2VjdXJpdHkgcG9zdHVyZS4gIEkgYW0gc29ycnkgdG8gYmUg aGFyc2gsIGJ1dCBhcyBJIGV4cGxhaW5lZCBpbiBlbWFpbCBtZXNzYWdlcyB5ZXN0ZXJkYXksIGlm IHlvdSBmb3JjZSBjbGllbnRzIHRvIGluZGljYXRlIHRoYXQgdGhleSBhcmUgd2lsbGluZyB0byBo YXZlIHRyYWZmaWMgYmUgaW50ZXJjZXB0ZWQsIHRoZW4gYW55IG1pZGRsZWJveCBjYW4gY2F0ZWdv cml6ZSwgYW5kIGRlbnkgb3Igc3VidmVydCwgc3VjaCB0cmFmZmljLiAgQWdhaW4sIGRvbuKAmXQg dGhpbmsgb2YganVzdCBuYXRpb25hbC1zY2FsZSBhZHZlcnNhcmllcywgYnV0IHlvdXIgSVNQIG9y IElQLWluLWFpcnBsYW5lIHByb3ZpZGVyLg0KDQpUaGUgcHJvcG9zYWwgZnVuZGFtZW50YWxseSBj aGFuZ2VzIHRoZSB3YXkgVExTIHdvcmtzLiAgQW5kIHdpdGggdGhlIHBvc3RlZCB1c2UtY2FzZXMs IGl0IHNlZW1zIGNvbXBsZXRlbHkgb2J2aW91cyB0byBtZSB0aGF0IGl0ICp3ZWFrZW5zKiB0aGUg cHJvdGVjdGlvbiBhZmZvcmRlZCB0byB0aGUgZ2VuZXJhbCBwb3B1bGF0aW9uLg0KDQpJIGJlbGll dmUgSSBrbm93IHdoeSBwZW9wbGUgd2FudCB0aGlzIG5vdy4gVGhleSBhcmUgd29ycmllZCB0aGF0 IGlmIFRMUyAxLjMgZ29lcyBvdXQgd2l0aG91dCBzb21ldGhpbmcgbGlrZSB0aGlzLCB0aGVuIHRo ZSBtYXJrZXQgKHN0YW5kYXJkIHdpZGVseSBhdmFpbGFibGUgYnJvd3NlcnMpIHdpbGwgbm90IGlt cGxlbWVudCBpdC4gTGV0IG1lIGFzc3VyZSB5b3UgdGhhdCB0aGlzIGlzbuKAmXQgYW4gaXNzdWUu IFRoZSBleHRlbnNpb24gd291bGQgKm5ldmVyIGV2ZXIqIG1ha2UgaXQgdG8gdGhlIE1VU1Qgc3Rh dGUsIGFuZCB0aGUgYnJvd3NlcnMgd291bGQgYmUgdW5saWtlbHkgdG8gZXZlciBpbXBsZW1lbnQg aXQgYW55d2F5Lg0KDQpJIGhhdmUgYW4gYWx0ZXJuYXRlIHN0cmF0ZWd5IHByb3Bvc2FsLiAgQ29u ZmlndXJlIHlvdXIgc2VydmVycyB0byBvbmx5IHVzZSBUTFMgMS4yIG9yIGVhcmxpZXIsIHByb2Jh Ymx5IGZvciBhdCBsZWFzdCBmaXZlIHllYXJzLiBEdXJpbmcgdGhhdCB0aW1lLCBtb2RpZnkgdGhl IHNlcnZlci1zaWRlIGFuZCBhbmFseXNpcyB0b29scyB0byByZWNvcmQgYW5kIHVzZSB0aGUgZXh0 cmEga2V5IG1hdGVyaWFsIHlvdeKAmWxsIG5lZWQgZm9yIFRMUyAxLjMuDQoNCg== --_000_1A894D0A9B724649A6E3E9BC0C4F96AAakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExNzcyNDc0ODsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTUzMjEwMzA3 MiAtMzI3NjQ3ODQwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtc3RhcnQtYXQ6Mzg2MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NzU3 MTY4NzkzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5 MDc5NzEyMTggMTAxOTkwMTg1MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLXN0YXJ0LWF0OjE5Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30N CkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDE6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlz dC1pZDo3Nzc5ODkyNDE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzIwMTg3OTAwO30NCkBs 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 b2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6ODYxMTYzNjU4Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDk1MzE3OTU0IDIxMzYyMjcwMTAgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxOTsN Cgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IixzZXJpZjt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0 IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjE1NzAzODc4NDA7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xMjM0Mjk1OTQ0O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMSBsZXZlbDEgbGZvNyI+RXhwcmVzc2x5IHJlYWN0aW5nIHRvIHRoZSB2aWFiaWxpdHkg b2YgY29udGludWluZyB0byB1c2UgVExTMS4yIGZvcmV2ZXIuDQo8bzpwPjwvbzpwPjwvbGk+PC91 bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Tm9ib2R5IGhhcyBzYWlkIHRoYXQsIHlvdSBhcmUgYXJndWluZyBhIHN0cmF3 bWFuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8zIj5JbmR1c3RyeSBncm91cHMgd2lsbCBmb3JjZSB1cyB0byB1c2UgbmV3ZXIgdmVyc2lvbnM8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPlBvbGljeSBzdGFuZGFyZHMgd2lsbCBldm9sdmUg aW4gc2ltaWxhciBmYXNoaW9ucy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPkxpa2VseSB0 aGVyZSB3aWxsIGJlIHJlZ3VsYXRvcnkgbWFuZGF0ZXMgaW4gbWFueSBvZiB0aGUgbWFya2V0cGxh Y2VzIGFuZCBidXNpbmVzcyBzZWdtZW50cyB0aGF0IGxhcmdlIEVudGVycHJpc2VzIHBhcnRpY2lw YXRlIGluLiZuYnNwOw0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vbmUgb2YgdGhv c2UgZXZlbiByZXF1aXJlIFRMUyAxLjIgeWV0LCBhbmQgaXQgaXMgYSBkZWNhZGUgb2xkLiZuYnNw OyBEbyB5b3UgdGhpbmsgYW55IG9mIHRoZW0gd2lsbCBqdW1wIGZyb20gMS4xIHRvIDEuMz8mbmJz cDsgV2hhdCB0aW1ldGFibGUgZG8geW91IHRoaW5rIHRoYXQgd2lsbCBoYXBwZW4/Jm5ic3A7IEEg ZGVjYWRlPyZuYnNwOyBGaXZlIHllYXJzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0 eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5Tb2Z0d2FyZSBQcm9kdWN0cyBhbmQgQXBwbGljYXRp b25zIHdpbGwgYXR0ZW1wdCB0byByZW1haW4gY3VycmVudCBhbmQgd2lsbCBldmVudHVhbGx5IHN1 bnNldCBzdXBwb3J0IGZvciBvbGRlciBwcm90b2NvbCB2ZXJzaW9ucw0KPG86cD48L286cD48L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFnYWluLCB3aGF0IHRpbWV0YWJsZSBkbyB5b3UgdGhpbmsgdGhhdCB3 aWxsIGhhcHBlbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMyI+QnVzaW5lc3MgUGFydG5lcnMgb3IgR292ZXJubWVudCBhZ2VuY3kgY3VzdG9t ZXJzIG1heSByZXF1aXJlIFRMUzEuMy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnE1heS7igJ0mbmJzcDsgRG8geW91IGhhdmUgYW55IGlu ZGljYXRpb24gdGhhdCB0aGlzIGlzIGEgcmVxdWlyZW1lbnQ/Jm5ic3A7IEdvdmVybm1lbnQgdGVu ZHMgdG8gd29yayBlaXRoZXIgZmFyIGluIGFkdmFuY2UgKGxpa2UgTklTVCBwb3N0LXF1YW50dW0g Y3J5cHRvKSBvciB0byB0cmFjayBpbmR1c3RyeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+SW50ZXJuYWwgU2VjdXJpdHkgVGVhbXMgbWF5 IHJlcXVpcmUgVExTMS4zLCBhdCBzb21lIHBvaW50IGluIHRoZSBmdXR1cmUuJm5ic3A7Jm5ic3A7 Jm5ic3A7IEFuZCB0aGV5IHNob3VsZCEmbmJzcDsmbmJzcDsmbmJzcDsgQW5kIHdoeSBzaG91bGQg d2UgTk9UIHdhbnQmbmJzcDsgYW5kIGJlIGFibGUgdG8gdXRpbGl6ZSBUTFMgMS4zIHdpdGggaXTi gJlzIHVwZGF0ZWQgYW5kIGVuaGFuY2VkIGNhcGFiaWxpdGllcy4mbmJzcDsNCiBXZSBETyBXQU5U IFRISVMhJm5ic3A7Jm5ic3A7IFdlIGp1c3Qgc3RpbGwgbmVlZCB0byBydW4gb3VyIG5ldHdvcmtz IGFuZCBidXNpbmVzc2VzIGFuZCBhcmUgYmFkbHkgd2FudGluZyB0byB3b3JrIHdpdGggdGhlIFdv cmtpbmcgR3JvdXAgdG8gYXNzdXJlIG91ciB1c2UgY2FzZXMgY2FuIGJlIGFjY29tbW9kYXRlZCwg aWYgYXQgYWxsIHBvc3NpYmxlLiZuYnNwOw0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PllvdXIgdXNlLWNhc2VzIGNhbiBiZSBhY2NvbW1vZGF0ZWQuJm5ic3A7IFlvdSBqdXN0IG5lZWQg dG8gc3BlbmQgc29tZSBtb3JlIG1vbmV5IG9uIHNlcnZlci1zaWRlIHJ1bnRpbWVzIGFuZCBrZXkg bWFuYWdlbWVudC4mbmJzcDsgSW5zdGVhZCwgeW91IHByb3Bvc2UgdG8gZm9yY2UgYWxsIGNsaWVu dHMgaW50byBhIHdlYWtlciBzZWN1cml0eSBwb3N0dXJlLiZuYnNwOyBJIGFtIHNvcnJ5IHRvIGJl IGhhcnNoLCBidXQgYXMgSSBleHBsYWluZWQNCiBpbiBlbWFpbCBtZXNzYWdlcyB5ZXN0ZXJkYXks IGlmIHlvdSBmb3JjZSBjbGllbnRzIHRvIGluZGljYXRlIHRoYXQgdGhleSBhcmUgd2lsbGluZyB0 byBoYXZlIHRyYWZmaWMgYmUgaW50ZXJjZXB0ZWQsIHRoZW4gYW55IG1pZGRsZWJveCBjYW4gY2F0 ZWdvcml6ZSwgYW5kIGRlbnkgb3Igc3VidmVydCwgc3VjaCB0cmFmZmljLiZuYnNwOyBBZ2Fpbiwg ZG9u4oCZdCB0aGluayBvZiBqdXN0IG5hdGlvbmFsLXNjYWxlIGFkdmVyc2FyaWVzLCBidXQgeW91 ciBJU1Agb3INCiBJUC1pbi1haXJwbGFuZSBwcm92aWRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIHByb3Bvc2FsIGZ1bmRhbWVudGFsbHkgY2hhbmdlcyB0aGUgd2F5IFRMUyB3b3Jrcy4m bmJzcDsgQW5kIHdpdGggdGhlIHBvc3RlZCB1c2UtY2FzZXMsIGl0IHNlZW1zIGNvbXBsZXRlbHkg b2J2aW91cyB0byBtZSB0aGF0IGl0ICo8Yj53ZWFrZW5zPC9iPiogdGhlIHByb3RlY3Rpb24gYWZm b3JkZWQgdG8gdGhlIGdlbmVyYWwgcG9wdWxhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBiZWxpZXZlIEkga25vdyB3aHkgcGVvcGxlIHdhbnQgdGhpcyBub3cuIFRoZXkgYXJlIHdvcnJp ZWQgdGhhdCBpZiBUTFMgMS4zIGdvZXMgb3V0IHdpdGhvdXQgc29tZXRoaW5nIGxpa2UgdGhpcywg dGhlbiB0aGUgbWFya2V0IChzdGFuZGFyZCB3aWRlbHkgYXZhaWxhYmxlIGJyb3dzZXJzKSB3aWxs IG5vdCBpbXBsZW1lbnQgaXQuIExldCBtZSBhc3N1cmUgeW91IHRoYXQgdGhpcyBpc27igJl0IGFu IGlzc3VlLiBUaGUNCiBleHRlbnNpb24gd291bGQgKjxiPm5ldmVyIGV2ZXI8L2I+KiBtYWtlIGl0 IHRvIHRoZSBNVVNUIHN0YXRlLCBhbmQgdGhlIGJyb3dzZXJzIHdvdWxkIGJlIHVubGlrZWx5IHRv IGV2ZXIgaW1wbGVtZW50IGl0IGFueXdheS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZl IGFuIGFsdGVybmF0ZSBzdHJhdGVneSBwcm9wb3NhbC4mbmJzcDsgQ29uZmlndXJlIHlvdXIgc2Vy dmVycyB0byBvbmx5IHVzZSBUTFMgMS4yIG9yIGVhcmxpZXIsIHByb2JhYmx5IGZvciBhdCBsZWFz dCBmaXZlIHllYXJzLiBEdXJpbmcgdGhhdCB0aW1lLCBtb2RpZnkgdGhlIHNlcnZlci1zaWRlIGFu ZCBhbmFseXNpcyB0b29scyB0byByZWNvcmQgYW5kIHVzZSB0aGUgZXh0cmEga2V5IG1hdGVyaWFs IHlvdeKAmWxsDQogbmVlZCBmb3IgVExTIDEuMy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_1A894D0A9B724649A6E3E9BC0C4F96AAakamaicom_-- From nobody Fri Oct 20 09:41:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB05F132D67 for ; Fri, 20 Oct 2017 09:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 KHHEkhhHgS4W for ; Fri, 20 Oct 2017 09:41:10 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 DEF3A132F30 for ; Fri, 20 Oct 2017 09:41:08 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 33BE2C1445 for ; Fri, 20 Oct 2017 11:41:08 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 1B0C6C0E80; Fri, 20 Oct 2017 11:41:07 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CF8B192071; Fri, 20 Oct 2017 12:41:06 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9861F920C7; Fri, 20 Oct 2017 12:41:06 -0400 (EDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (unknown [216.32.181.177]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Fri, 20 Oct 2017 12:41:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JCG6pNpIAgzzRiiGY47APu2lbuwvBZZizhYFjvOppuk=; b=QPvEtCZzY5bCv6oTg+tHnAxpWJQSwXY3X3ihLQ0V0PgjsflaHVANTuUEMfQwvJhtfYDNUxlx/5MN+f/EZPDikPv4H5RPPnvQ3j+dq2AOVZPn2Lvt3fvCkIU58WAMJ6qj40bnTafi5tbYOW/6gXH2cFIqOiQDNPjqj/rydx6J9Ew= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1367.namprd14.prod.outlook.com (10.172.158.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 20 Oct 2017 16:41:04 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Fri, 20 Oct 2017 16:41:04 +0000 From: "Ackermann, Michael" To: Stephen Farrell , "Salz, Rich" , Darin Pettis , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmA= Date: Fri, 20 Oct 2017 16:41:04 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> In-Reply-To: <2741e833-c0d1-33ca-0ad3-b71122220bc5@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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.74] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1367; 20:1vC1lU32XTRtGv4txtxWrDTKHb0eFMtnu5ULCs661kWMTuEDp/IhRcbsraqxgqJMyLEvofij9Kz1NFsLVsAeRRJYKWpynao8DBNGpPl9My2LiSkTs3dPqxMkS/DowOaiiKS/0KnQh4lIuDzXd4TZZEPQ2YTt0wqk22/AfRHnaqM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c23cdc7e-54ac-4237-a750-08d517d95b35 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1367; x-ms-traffictypediagnostic: CY4PR14MB1367: x-exchange-antispam-report-test: UriScan:(32856632585715)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(3231020)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1367; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1367; x-forefront-prvs: 0466CA5A45 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(189002)(24454002)(199003)(13464003)(53546010)(81156014)(66066001)(54356999)(6436002)(39060400002)(6506006)(99286003)(105586002)(5660300001)(101416001)(93886005)(3846002)(102836003)(33656002)(50986999)(77096006)(76176999)(7696004)(106356001)(6116002)(189998001)(25786009)(316002)(229853002)(86362001)(81166006)(478600001)(305945005)(3660700001)(9686003)(72206003)(3280700002)(74316002)(230783001)(97736004)(110136005)(8676002)(2906002)(14454004)(2501003)(68736007)(80792005)(7736002)(8936002)(55016002)(2950100002)(53936002)(6246003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1367; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 16:41:04.7128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1367 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 9fe708a3-d59d-430b-8346-4496bb29ccb7 X-VPM-MSG-ID: ba501849-a338-4b59-96df-3723f4738218 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:41:12 -0000 U28gaXQgc291bmRzIGxpa2Ugd2UgYXJlIGluIGFncmVlbWVudCB0aGF0IGNvbnRpbnVpbmcg dG8gdXNlIFRMUyAxLjIgaXMgbm90IGEgdmlhYmxlIGxvbmcgdGVybSAgYWx0ZXJuYXRpdmUu ICANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJy ZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gDQpTZW50OiBGcmlkYXks IE9jdG9iZXIgMjAsIDIwMTcgMTI6MTQgUE0NClRvOiBBY2tlcm1hbm4sIE1pY2hhZWwgPE1B Y2tlcm1hbm5AYmNic20uY29tPjsgU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT47IERh cmluIFBldHRpcyA8ZHBwLmVkY29AZ21haWwuY29tPjsgdGxzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW1RMU10gUHVibGljYXRpb24gb2YgZHJhZnQtcmhyZC10bHMtdGxzMTMtdmlzaWJp bGl0eS0wMA0KDQoNCg0KT24gMjAvMTAvMTcgMTc6MDAsIEFja2VybWFubiwgTWljaGFlbCB3 cm90ZToNCj4gRXhwcmVzc2x5IHJlYWN0aW5nIHRvIHRoZSB2aWFiaWxpdHkgb2YgY29udGlu dWluZyB0byB1c2UgVExTMS4yIGZvcmV2ZXIuDQoNClNvcnJ5LCB0aGF0J3MganVzdCBtaXNx dW90aW5nLg0KDQpSaWNoIGFza2VkICJ3aHkgZG8gdGhlIFdHIG5lZWQgdG8gZGViYXRlIHRo aXMgbm93Ig0KRGFyaW4gc2FpZCAid2UgbXVzdCwgYmVjYXVzZSB3ZSBuZWVkIHNub29waW5n Li4uIg0KSSBzYWlkICJubywgeW91IGNhbiB1c2UgVExTMS4yIGFuZCBkZWJhdGUgdGhpcyBh ZnRlcg0KVExTMS4zIGlzIGRvbmUuIg0KDQpUaGF0IGlzIG5vdGhpbmcgbGlrZSBzYXlpbmcg InVzZSBUTFMxLjIgZm9yZXZlci4iDQoNClBsZWFzZSBkb24ndCBtaXNxdW90ZSBsaWtlIHRo YXQuDQoNClMNCg0KCgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVu aWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmlj YXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcs IGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJv aGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwg b3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhl IG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGllcy4KIAogQmx1ZSBD cm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2Yg TWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxp Y2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24u Cg== From nobody Fri Oct 20 09:57:35 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FB1132D17 for ; Fri, 20 Oct 2017 09:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MkE28_ctaWFr for ; Fri, 20 Oct 2017 09:57:32 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F4B13235C for ; Fri, 20 Oct 2017 09:57:32 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9KGvGWF016284; Fri, 20 Oct 2017 17:57:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Z4BUeJfDLAX/94RLPAaFJOtHrmnJjOPsnVBBzBrMh3c=; b=GdvqU/SpivUES06shQAgtrY2LkEA1JCF4XC6lIHBQi8jEKdz05ZJ2rVqrE3ktGQdjGGk MFIlo/Oh66hVw9oLe3LlyRCO6eSSoxwD4w274HR8C+yafKz7HkzmD8EzBX9P2xrLadK+ DLRP88JcIWArfq6RHZL8fBhnJUfh/GK3IUxx12wto4h/pxIvcyShCAnH6MSyZ5TuttuR bLt1SO5f2Ve2XLipg2vkacGF6GY+azTR4t/VU4dZb8PbpKna54QUUa/KELPQF4+PrjJU nZLKuOrHAAZc7SLbqRLChN0XV9SDvnzmTQBH9toyPgUpt63j9b1LaT0+hVQz7kIO/dwh ug== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2dpa0cyvde-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 17:57:22 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9KGv06D023817; Fri, 20 Oct 2017 12:57:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dkdwuk804-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 12:57:21 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 20 Oct 2017 12:57:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 20 Oct 2017 12:57:20 -0400 From: "Salz, Rich" To: "Ackermann, Michael" , Stephen Farrell , Darin Pettis , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABAMAgAAHdQCAAASJAA== Date: Fri, 20 Oct 2017 16:57:19 +0000 Message-ID: <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.173] Content-Type: text/plain; charset="utf-8" Content-ID: <5A3A98B047106440A468C320A6F0706A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200236 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200236 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:57:34 -0000 DQoNCiAgICBTbyBpdCBzb3VuZHMgbGlrZSB3ZSBhcmUgaW4gYWdyZWVtZW50IHRoYXQgY29udGlu dWluZyB0byB1c2UgVExTIDEuMiBpcyBub3QgYSB2aWFibGUgbG9uZyB0ZXJtICBhbHRlcm5hdGl2 ZS4gIA0KICAgIA0KDQpMb25nLXRlcm0gaXMgYSBzdWJqZWN0aXZlIHRlcm0sIGFuZCB1c2luZyBp dCBjYW4gbGVhZCB0byBtaXN1bmRlcnN0YW5kaW5ncy4NCg0KQmFzZWQgb24gY3VycmVudCBhbmQg cHJldmlvdXMgYWN0aW9ucyBhcm91bmQgU1NMIGFuZCBUTFMgdmVyc2lvbnMsIHlvdSBjYW4gdXNl IFRMUyAxLjIgZm9yIGF0IGxlYXN0IGZpdmUsIGxpa2VseSBhdCBsZWFzdCAxMCwgeWVhcnMuDQoN Cg0KDQo= From nobody Fri Oct 20 10:51:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C7F1342FF for ; Fri, 20 Oct 2017 10:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_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 bIgTPUB00SCN for ; Fri, 20 Oct 2017 10:51:21 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0A41342FC for ; Fri, 20 Oct 2017 10:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NqMJPpmIjdNzbduD7cG1B4Bzq0UX4rSzn/x/PiF/0us=; b=BGGCjRsCzesoOJruZoRqh0iJUCTtJfBWDaeEyqCV1V+tj/O6lacwogrkZ5VlDPc2U8WKgH+tnIOq876eyKWtBoa30Mw5LzKcH4fucb2Wo+W0IowKvnsDx+7J3AcjTLps1nNzxL9sMuN3eJ19ASbvX5noOoEA4KI7bwfL2XNyayw= Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) by CY4PR21MB0775.namprd21.prod.outlook.com (10.173.192.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.178.1; Fri, 20 Oct 2017 17:51:19 +0000 Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0178.002; Fri, 20 Oct 2017 17:51:19 +0000 From: Andrei Popov To: "Ackermann, Michael" , "Salz, Rich" , Darin Pettis , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO72LWJ5lngjBEkeD6AR8/saqpaLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA6gIAAAPaAgAADKICAAALZAIAABTWAgAACtICAAAEHAIAABEcAgAAZuoCAAAV4gIAAVLoAgAD/VwCAACX8gIAAD5oQ Date: Fri, 20 Oct 2017 17:51:19 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> 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:e::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0775; 6:Rne4y8zQZMJizi1wcDh6wjP6tSl8Pak7Jbp8Pd35IEl8OVLW7XS85QCqWCl9TRCmQ+ZfNYOaAMtZFwVBrlunH6zyTrXM9WofqQJ8Ybl1cSGAbZBUChlWgPLWDaeXDXQ+HWcwx1M6p+mfGm8KRMC+c91PclfwgLKHv1cjDSL19YnzIQ+FubygPCuRh5onJHfYl0Gi5GkBjRf8ezGVASbQfmgEchEsXzNjdLPAFienryoafqqxKhavk7bMyEtIOFOND/PzYLSjF6VaIyQA4hxDab622te6ZhTpFkxEtB+RFepOe/8f+g41PoHFU9Ja5WGAd1D5fBPfxlo4OK0cZliOZH0pltEXFBBQiepuVv/Yvv8=; 5:4zYGF1QP0S/TiehZWGWe2K7Ri/8VP0y3ZFzxoCWAdyRHXjBAg7G+z2OEAkL91CmiHOXu+1n+IHylkC0aJoCKbQUwazSupG7mPPshuwy8FLMpXFlc8d9lvdrhc3XKyDCuPg4ZdGN2VW5jAZjrpUOSqOEIgeDb56WyTlcjMgu2Q34=; 24:RrAlD6v7mJrpunDZkSPFchrEYtsONo5yb+h1Z5C5Cgah2AV1sYXwOEgXfrdmOFYbW04wCyKXCAn3T0uJARAQZYfJX28Jpe0CHx7J0zWrH1M=; 7:5Fm4woJKKrmobwJ6zeo1IBCFwrCd0rfI6vgOkH6Z8GsrspVSv7h5aHlzY169N65yS7sMr2krzACaONtJtUmqrJ+gJaoUottq1Y5IirBIKsH0FUBMw9Ax2hLWakvyGkVYuVWFoMIJoKNJ6sS9RZgvwkIoBTuhhvjFm0raaQap3OqPlW0dVegIJXcn5ddPBuPT/n00xTDYDo8qeSig1MaBGNKiTKS9ZbxvsvsGsGfhozqIezxtH0uE+vkRMmI7Wh9d x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2bcf1930-cd68-4bd9-6a1a-08d517e32b7a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:CY4PR21MB0775; x-ms-traffictypediagnostic: CY4PR21MB0775: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231020)(100000703101)(100105400095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0775; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0775; x-forefront-prvs: 0466CA5A45 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(47760400005)(199003)(189002)(76176999)(22452003)(8990500004)(6436002)(6246003)(316002)(6506006)(101416001)(54356999)(229853002)(110136005)(2501003)(3280700002)(39060400002)(77096006)(2906002)(86612001)(50986999)(86362001)(478600001)(3660700001)(10290500003)(189998001)(25786009)(10090500001)(14454004)(105586002)(230783001)(106356001)(8936002)(6306002)(5660300001)(93886005)(53936002)(2950100002)(7696004)(33656002)(81166006)(790700001)(99286003)(97736004)(6116002)(55016002)(72206003)(7736002)(54896002)(81156014)(8676002)(68736007)(74316002)(102836003)(2900100001)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0775; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0120CD17B02F87D1B5871BB48C430CY4PR21MB0120namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2bcf1930-cd68-4bd9-6a1a-08d517e32b7a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 17:51:19.5459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0775 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 17:51:24 -0000 --_000_CY4PR21MB0120CD17B02F87D1B5871BB48C430CY4PR21MB0120namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSW5kdXN0cnkgZ3JvdXBzIHdpbGwgZm9yY2UgdXMgdG8gdXNlIG5ld2VyIHZlcnNpb25z DQogICogICBMaWtlbHkgdGhlcmUgd2lsbCBiZSByZWd1bGF0b3J5IG1hbmRhdGVzIGluIG1hbnkg b2YgdGhlIG1hcmtldHBsYWNlcyBhbmQgYnVzaW5lc3Mgc2VnbWVudHMgdGhhdCBsYXJnZSBFbnRl cnByaXNlcyBwYXJ0aWNpcGF0ZSBpbi4NCiAgKiAgIEJ1c2luZXNzIFBhcnRuZXJzIG9yIEdvdmVy bm1lbnQgYWdlbmN5IGN1c3RvbWVycyBtYXkgcmVxdWlyZSBUTFMxLjMuDQoNClRoZXNlIG1hbmRh dGVzL3JlcXVpcmVtZW50cyBhcmUgdHlwaWNhbGx5IG1vdGl2YXRlZCBieSB0aGUgcmVhbGl6YXRp b24gdGhhdCBUTFMgVm4gaXMgbW9yZSBzZWN1cmUgdGhhbiBUTFMgVm4teC4NCk9uZSBvZiB0aGUg aW1wb3J0YW50IHJlYXNvbnMgVExTIDEuMyBtYXkgYmUgbW9yZSBzZWN1cmUgdGhhbiBUTFMgMS4y IGFuZCBiZWxvdyBpcyB0aGF0IGl0IGRvZXMgbm90IG9mZmVyIG5vbi1QRlMgb3B0aW9ucy4NClRo ZW4gZGVwbG95aW5nIGEgd2Vha2VuZWQgY29uZmlndXJhdGlvbiBvZiBUTFMgMS4zICh3aXRob3V0 IFBGUykgd291bGQgbm90IG1lZXQgdGhlIGludGVudCBvZiB0aG9zZSBmdXR1cmUgbWFuZGF0ZXMv cmVxdWlyZW1lbnRzLg0KVGhlbiBkbyB3ZSBnYWluIGFueXRoaW5nIGJ5IHN0YW5kYXJkaXppbmcg YSB3ZWFrZW5lZCBjb25maWd1cmF0aW9uIG9mIFRMUyAxLjM/DQoNCkNoZWVycywNCg0KQW5kcmVp DQo= --_000_CY4PR21MB0120CD17B02F87D1B5871BB48C430CY4PR21MB0120namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIz DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTc3MjQ3NDg7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01MzIxMDMwNzIg LTMyNzY0Nzg0MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXN0YXJ0LWF0OjM4NjM7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjg2MTE2MzY1ODsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQ5NTMxNzk1NCAyMTM2MjI3MDEw IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MTk7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+D mDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs Mg0KCXttc28tbGlzdC1pZDo4ODE4NjUzOTQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjE3MjQ2NDk1MjAgLTIwMzY4NTAxNCA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE0MjQxODY3NzM7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0yMTYzNDAyNTI7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNA0KCXttc28t bGlzdC1pZDoyMTI3MjM0MDU2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODMyMjg1NjE0O30N CkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzciPkluZHVzdHJ5IGdyb3VwcyB3aWxsIGZv cmNlIHVzIHRvIHVzZSBuZXdlciB2ZXJzaW9uczxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwx IGxmbzciPkxpa2VseSB0aGVyZSB3aWxsIGJlIHJlZ3VsYXRvcnkgbWFuZGF0ZXMgaW4gbWFueSBv ZiB0aGUgbWFya2V0cGxhY2VzIGFuZCBidXNpbmVzcyBzZWdtZW50cyB0aGF0IGxhcmdlIEVudGVy cHJpc2VzIHBhcnRpY2lwYXRlIGluLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzci PkJ1c2luZXNzIFBhcnRuZXJzIG9yIEdvdmVybm1lbnQgYWdlbmN5IGN1c3RvbWVycyBtYXkgcmVx dWlyZSBUTFMxLjMuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNlIG1hbmRhdGVz L3JlcXVpcmVtZW50cyBhcmUgdHlwaWNhbGx5IG1vdGl2YXRlZCBieSB0aGUgcmVhbGl6YXRpb24g dGhhdCBUTFMgVm4gaXMgbW9yZSBzZWN1cmUgdGhhbiBUTFMgVm4teC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvZiB0aGUgaW1wb3J0YW50IHJlYXNvbnMgVExTIDEu MyBtYXkgYmUgbW9yZSBzZWN1cmUgdGhhbiBUTFMgMS4yIGFuZCBiZWxvdyBpcyB0aGF0IGl0IGRv ZXMgbm90IG9mZmVyIG5vbi1QRlMgb3B0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZW4gZGVwbG95aW5nIGEgd2Vha2VuZWQgY29uZmlndXJhdGlvbiBvZiBUTFMg MS4zICh3aXRob3V0IFBGUykgd291bGQgbm90IG1lZXQgdGhlIGludGVudCBvZiB0aG9zZSBmdXR1 cmUgbWFuZGF0ZXMvcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlbiBkbyB3ZSBnYWluIGFueXRoaW5nIGJ5IHN0YW5kYXJkaXppbmcgYSB3ZWFrZW5l ZCBjb25maWd1cmF0aW9uIG9mIFRMUyAxLjM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVy cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kcmVpPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0120CD17B02F87D1B5871BB48C430CY4PR21MB0120namp_-- From nobody Fri Oct 20 11:23:06 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D00134220 for ; Fri, 20 Oct 2017 11:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oMg0N8Yz19r for ; Fri, 20 Oct 2017 11:23:04 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E89413234B for ; Fri, 20 Oct 2017 11:23:04 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id f199so15390926qke.2 for ; Fri, 20 Oct 2017 11:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pM8s+SSElXG0ScgwSOWQysFCyIvsWH2BYGfk/itPHgI=; b=ndS5cmTgqgv5X+/qxj4+DslvEuCTi5JVMde5km/3w23KcMHXhKZHiijblzb9kAZZdM 8raZck8d2jKGtgNTbRPB97FSKNg1nOUXoIeIfHyLAar6SVWy1P5+mubN/qfBlWnd5XZ4 YwPe3c/MWo1jDKW7fVjHu+9n1E9APVAYZSBI3/k4wp3SFvlP3pquCwRt1nqj/K3xFois 9ldITCR2uN6/rvGrBDdqzFdxhszOuOimYiuckhoPdJ7wP+7hjXeTZhZwVhmMR4qp9G/R Sd9/WVsd+joSNLA0oSKHHPJzk2kj2MDgSxWSYhLWr4DiX0oA0OseNqrdrZKr49CxKk6U x12Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pM8s+SSElXG0ScgwSOWQysFCyIvsWH2BYGfk/itPHgI=; b=Wx2fs9hDp18MiEi13xMvkvHp7h2OLUQy5HlpnDjVkKeYHF+yq8X9EMg6Oh7fQa/siH RuMEr9ksjQYYSCpOKQvxzMltZPTZjl9iukO4oawHH/cFRyptf5GmT4cfJYJg7fDF8gxy eq1ANgCuPPb2a77a+yIwidkAXGF17dFa3dTkUGpR85VV2I4yTT155E5ULiuS+81Ahlrh 3wQJbbE4+ODQG3kHCJjzOLVkXb1Th2EbE4hJtLUJ0GIy37Aiec7yTI1L3Ibe+bFpKOCl mUxqMfTTOrPOs8n5oL1qLdm63t61MB+0AYDIM5Ko0GgfdfONTevixMYYvubQO6RGPkqR OwMQ== X-Gm-Message-State: AMCzsaVPKvhoG/Fh28UCDpnGNzi2TabR47TxyrFOEUDttniMHTquGctJ zGdDdSHq5KUnTxNElVkGXBvbFEVyBV3FWLD5bFI= X-Google-Smtp-Source: ABhQp+Q3L3cx9CHgI8Cx290c6rnRsAc9ubSyLc/8zkS1RpNxRzrVtkH47JRk94M0KjlImIyQn9XKzALdmQBnmJUmgE4= X-Received: by 10.55.23.99 with SMTP id i96mr7807752qkh.278.1508523783261; Fri, 20 Oct 2017 11:23:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.11 with HTTP; Fri, 20 Oct 2017 11:22:42 -0700 (PDT) In-Reply-To: <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> From: Tony Arcieri Date: Fri, 20 Oct 2017 11:22:42 -0700 Message-ID: To: "Salz, Rich" Cc: Darin Pettis , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1146e2483ca1e1055bfe906d" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 18:23:06 -0000 --001a1146e2483ca1e1055bfe906d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 20, 2017 at 6:44 AM, Salz, Rich wrote: > > - A decade later, PCI-DSS is only =E2=80=98strongly encouraging=E2=80= =99 TLS 1.2; the > actual requirement is TLS 1.1! Why should we expect that TLS 1.3 will > happen any faster? > > It's worse than that. PCI-DSS presently only requires TLS 1.0. The deadline to switch to 1.1 or higher is 30 June 2018: https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-= goodbye-to-ssl-early-tls --=20 Tony Arcieri --001a1146e2483ca1e1055bfe906d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 20, 2017 at 6:44 AM, Salz, Rich <rsalz@akamai.com> wr= ote:
  • A decade later, PCI-DSS is only =E2=80=98stron= gly encouraging=E2=80=99 TLS 1.2; the actual requirement is TLS 1.1! Why sh= ould we expect that TLS 1.3 will happen any faster?
<= /div>
It's worse than that. PCI-DSS presently only req= uires TLS 1.0. The deadline to switch to 1.1 or higher is 30 June 2018:


--
Tony Arcieri
--001a1146e2483ca1e1055bfe906d-- From nobody Fri Oct 20 11:27:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D242C134308 for ; Fri, 20 Oct 2017 11:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 wM87nG3dOh6K for ; Fri, 20 Oct 2017 11:27:35 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAF31329B5 for ; Fri, 20 Oct 2017 11:27:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7473DB5208; Fri, 20 Oct 2017 21:27:32 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id OSS1EjeXlD-3; Fri, 20 Oct 2017 21:27:32 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5A3EC2318; Fri, 20 Oct 2017 21:27:26 +0300 (EEST) Date: Fri, 20 Oct 2017 21:27:25 +0300 From: Ilari Liusvaara To: "Ackermann, Michael" Cc: Stephen Farrell , "Salz, Rich" , Darin Pettis , "tls@ietf.org" Message-ID: <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 18:27:37 -0000 On Fri, Oct 20, 2017 at 04:41:04PM +0000, Ackermann, Michael wrote: > So it sounds like we are in agreement that continuing to use TLS 1.2 > is not a viable long term alternative. If one looks at long time horizon... TLS 1.2 will very probably remain viable until quantum computers come and demolish its security, unfortunately. Yes, quantum computers will demolish TLS 1.3 as it is currently, but adding PQC into 1.3 is much easier than adding it into 1.2. With TLS 1.3, the biggest problems is choosing the PQC algorithm, not integrating it, whereas TLS 1.2 requires would require very nontrivial integration work too. Oh, and come quantum computers, you will find that PQC schemes are much less well-behaved than the pre-quantum schemes in use. Thus many tricks that worked no longer work. So you would be better just adapting, because come QC, you don't have choice but to, potentially very quickly. Also, with regards to support, I would be much more concerned about software dropping support of, or regulations mandating disabling of, RSA key exchange than TLS 1.2 as whole. There are already TLS libraries that lack RSA key exchange, despite the fact it is MTI. Furthermore, that sort of thing is much more feasible on server side, as client support for ECDH (or at least DH-2k) is just about universal. -Ilari From nobody Fri Oct 20 12:16:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC78134308 for ; Fri, 20 Oct 2017 12:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GUYYbB3L0x1T for ; Fri, 20 Oct 2017 12:16:29 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68ADA133049 for ; Fri, 20 Oct 2017 12:16:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C5E72300572 for ; Fri, 20 Oct 2017 15:16:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vF7OVpbdY5Vm for ; Fri, 20 Oct 2017 15:16:27 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 33D1330026A; Fri, 20 Oct 2017 15:16:27 -0400 (EDT) From: Russ Housley Message-Id: <52709DEA-6820-4C88-8663-C6D403C1C638@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_03148C8E-404C-41C9-A611-4B2AE046429A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 20 Oct 2017 15:16:26 -0400 In-Reply-To: Cc: IETF TLS To: Benjamin Kaduk References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 19:16:30 -0000 --Apple-Mail=_03148C8E-404C-41C9-A611-4B2AE046429A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 19, 2017, at 9:06 PM, Benjamin Kaduk wrote: >=20 > On 10/19/2017 05:30 PM, Darin Pettis wrote: >>=20 >> The question has been raised: "Why address visibility now?" The = answer is that it is critical that the visibility capability is = retained. It is available today through the RSA key exchange algorithm. = We understand that the issue was raised late and have fallen on the = preverbal sword for being late to the party but the issue is real. That = is where the "rhrd" draft has come from. A way to retain that = visibility capability but with a newer and more secure protocol.=20 >>=20 >=20 > But the "rhrd" draft does not require any changes to the core TLS 1.3 = protocol, and in fact I have heard several key participants say that any = "visibility" changes must not require changes to the core protocol. If = the "visibility" work will be done via extensions, then there is no = ordering requirement for their specification with respect to the core = work, there is only an ordering requirement between them and adoption of = TLS 1.3 in enterprises. Do you want to argue that a year timescale is = too slow for enterprise adoption of TLS 1.3? If not, I continue to not = see a reason to address "visibility" now. Ben: I do not see the visibility extension taking any resources away from the = completion of TLS 1.3, so I do not see any reason to make it wait. Russ --Apple-Mail=_03148C8E-404C-41C9-A611-4B2AE046429A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Oct 19, 2017, at 9:06 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:

On 10/19/2017 05:30 PM, Darin Pettis wrote:

The question has been raised: "Why address visibility now?"   The answer is that it is critical that the visibility capability is retained.  It is available today through the RSA key exchange algorithm.  We understand that the issue was raised late and have fallen on the preverbal sword for being late to the party but the issue is real.  That is where the "rhrd" draft has come from.  A way to retain that visibility capability but with a newer and more secure protocol. 


But the "rhrd" draft does not require any changes to the core TLS 1.3 protocol, and in fact I have heard several key participants say that any "visibility" changes must not require changes to the core protocol.  If the "visibility" work will be done via extensions, then there is no ordering requirement for their specification with respect to the core work, there is only an ordering requirement between them and adoption of TLS 1.3 in enterprises.  Do you want to argue that a year timescale is too slow for enterprise adoption of TLS 1.3?  If not, I continue to not see a reason to address "visibility" now.

Ben:

I do not see the visibility extension taking any resources away from the completion of TLS 1.3, so I do not see any reason to make it wait.

Russ

--Apple-Mail=_03148C8E-404C-41C9-A611-4B2AE046429A-- From nobody Fri Oct 20 12:21:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3C3132320 for ; Fri, 20 Oct 2017 12:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 E_8Ap0ZNcbJP for ; Fri, 20 Oct 2017 12:21:40 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9F5132026 for ; Fri, 20 Oct 2017 12:21:40 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9KJGpuS010209; Fri, 20 Oct 2017 20:21:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=S4v9JV7aZXc8pw8CKlUM7PKc+qAl5dlyTdR0o9QtU0E=; b=SfMNxW/pC0l+w0/k6IaXZmTjUEnz9MLwzxFLVIjkG0oycERh9SchsoWvZIZ7pNntvF6e 3JXh6gQiXidgV92F+we4QEESQdOgD5kgOW0QfkHzpVhe5m3Dbji2ynQF7Bue6wfu3z5Q PjJkAh394fZxI61zXvxpSsbKJZqmKQZZv1BFNeh4jn6jqprBmya2ANeWQt39vBVNtS80 Wmybfd2DHdYrMbFySBCXMRhqi7EmE52NTPr4dgijv0xUHlW0Xf/PHZCEt7+TNX3dzQTl 14E2a2Wfk1IU6VCwH3uqV9/KTMlzmw4GNKdVus5qWIY21lW5PIOUi5mOYNdDZae6jjRM /g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2dnx5t9s51-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 20:21:39 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9KJFMAg032317; Fri, 20 Oct 2017 15:21:38 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dkdwukk7v-1; Fri, 20 Oct 2017 15:21:38 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 6ABC31FC7D; Fri, 20 Oct 2017 19:21:38 +0000 (GMT) To: Russ Housley Cc: IETF TLS References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <52709DEA-6820-4C88-8663-C6D403C1C638@vigilsec.com> From: Benjamin Kaduk Message-ID: Date: Fri, 20 Oct 2017 14:21:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <52709DEA-6820-4C88-8663-C6D403C1C638@vigilsec.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200268 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200269 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 19:21:41 -0000 On 10/20/2017 02:16 PM, Russ Housley wrote: > > > Ben: > > I do not see the visibility extension taking any resources away from > the completion of TLS 1.3, so I do not see any reason to make it wait. > At risk of sounding overly self-important, there are a couple of old emails sitting in my inbox waiting to get translated into pull requests against the spec.  The time I am spending on this thread is time that I am not able to spend improving the TLS 1.3 document. -Ben From nobody Fri Oct 20 15:02:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8E2132CE7 for ; Fri, 20 Oct 2017 15:02:35 -0700 (PDT) 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 u_MH6nmDMc_9 for ; Fri, 20 Oct 2017 15:02:34 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 640FB12ECEC for ; Fri, 20 Oct 2017 15:02:34 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id z50so20192014qtj.4 for ; Fri, 20 Oct 2017 15:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dqaVCHAsGKA1MxlrtCdCXFvN8we5908I37NdOxe2yrI=; b=jw7mx47Skv7zn1ieeoPIAqkNaoIdB+JMVqTMRq2iN+mqt1DnNXN7yXVLDtdMY5eDYD 60/ddKQngZsza6+xxiybulmmiZuauq7uaq7m782QGMm5QSdHChmbnjzPDcUzA/1rcoYs P3AOWnakFnVz+IlFACX2f76BfREzpFfsDSezgGpxJjUBd/Nj4bHm1o3arV+rPypp5/4L sndH03pCZozgMj/PrwT/Jri9PpV56DPqbuCIuQc0l4Zzzo2+IPJWxtRnWwGPEGcjTE6E TNsXAmLn1iXz0523ui8SXViL6yebSBG64lgPTKobL4pEnqgThAY8LjFFCXAjWi4S4lpL fOsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dqaVCHAsGKA1MxlrtCdCXFvN8we5908I37NdOxe2yrI=; b=dJDn/oxOytHxqmYZlkWBUTeczbn5zubhIw0NFEq9BA2eIIgq/fyC3Jl1YadZW2e/tv kn2UfC42L527nn/FDJNu9vL6DHLrgQagnCdEhPVTu1CwgIhIGj0tkJHzg5enUl01oJB2 cn+ZNUbzS56iqO5ol1uTJY3dInDsOAyWnKMuHofx55E/fqt28hdiOyBmiFbDE0Om3SIB 2E05tdbrgfEzzl6Clza1TTb4o9jwfvqv5bAnGOBUF2jTsBnse68bF//4l9SZmuGOyGVp tiO4cG70heDwhkIfqg7yEvwXg+LQhkkjnwqjqEhkJeaQdSMTG9PebxpBsAVe/se7vR4c G8PA== X-Gm-Message-State: AMCzsaV95bYw9ycDzufJQJQdV2hgOE4GBc9b5op1SHM8QKOVk+0IL3eQ BTCs22z3txi5XbcMcnDnXZQCzjPlyj9q6WsAIVU= X-Google-Smtp-Source: ABhQp+Slcyexs46WGDzovkeOojOiRwrofRj0Pmotti37JV1V3ItDZ3ys2qXKbsjCgIDAug1QZTmO4MJgDiObndqtbIQ= X-Received: by 10.200.17.1 with SMTP id c1mr9042621qtj.252.1508536953455; Fri, 20 Oct 2017 15:02:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.11 with HTTP; Fri, 20 Oct 2017 15:02:12 -0700 (PDT) In-Reply-To: <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> From: Tony Arcieri Date: Fri, 20 Oct 2017 15:02:12 -0700 Message-ID: To: Ilari Liusvaara Cc: "Ackermann, Michael" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e082651683dcb21055c01a160" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 22:02:36 -0000 --089e082651683dcb21055c01a160 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 20, 2017 at 11:27 AM, Ilari Liusvaara wrote: > TLS 1.2 will very probably remain viable until quantum computers come > and demolish its security, unfortunately. As someone who has spent a lot of time working on compliance for payments systems, I have an open question to the "visibility" advocates: Can you provide a *specific citation* as to where you will be *required* to use TLS 1.3 any time in, say, the next decade? This is absolutely not the case for PCI-DSS. To my knowledge any requirement of this nature simply doesn't exist. I could be wrong but... citation needed. If there is no pressing reason for legacy systems which are dependent on "visibility"/self-MitM capability because their observability story is so poor and they can't use endpoint agents to solve the same problems, what is the case for trying to add MitM mechanisms now? The answer is simple: stay on TLS 1.2 (or earlier) until you can improve your observability story, or *specific* requirements which *mandate* use of TLS 1.3 actually manifest. From previous experience: such mandates will not be a fire drill, but will be years in the making, and repeatedly delayed due to "industry" requirements / shortcomings. -- Tony Arcieri --089e082651683dcb21055c01a160 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 20, 2017 at 11:27 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
TLS 1.2 will v= ery probably remain viable until quantum computers come
and demolish its security, unfortunately.

A= s someone who has spent a lot of time working on compliance for payments sy= stems, I have an open question to the "visibility" advocates:

Can you provide a *specific citation* as to where you= will be *required* to use TLS 1.3 any time in, say, the next decade?
=

This is absolutely not the case for PCI-DSS.
=
To my knowledge any requirement of this nature simply doesn&= #39;t exist. I could be wrong but... citation needed.
<= br>
If there is no pressing reason for legacy systems which are d= ependent on "visibility"/self-MitM capability because their obser= vability story is so poor and they can't use endpoint agents to solve t= he same problems, what is the case for trying to add MitM mechanisms now?

The answer is simple: stay on TLS 1.2 (or earlier) = until you can improve your observability story, or *specific* requirements = which *mandate* use of TLS 1.3 actually manifest. From previous experience:= such mandates will not be a fire drill, but will be years in the making, a= nd repeatedly delayed due to "industry" requirements / shortcomin= gs.

--
Tony Arcieri
--089e082651683dcb21055c01a160-- From nobody Fri Oct 20 17:29:14 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAB6134528; Fri, 20 Oct 2017 17:24:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546484.20809.12942799502820490500.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:24 -0700 Archived-At: Subject: [TLS] tls - Requested sessions have been scheduled for IETF 100 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:25 -0000 Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:30:00) Thursday, Morning Session I 0930-1200 Room Name: Canning size: 250 --------------------------------------------- tls Session 2 (1:00:00) Monday, Afternoon Session III 1740-1840 Room Name: Padang size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 2 Length of Session(s): 2.5 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: quic rtcweb stir curdle saag uta acme cfrg httpbis tokbind perc dispatch Second Priority: dprive ace Third Priority: tcpinc lamps People who must be present: Eric Rescorla Sean Turner Joseph A. Salowey Kathleen Moriarty Resources Requested: Special Requests: If sec-dispatch ends up being a thing please don't schedule us against that. Also please don't put us up against the TEEP or FUD BOFs. --------------------------------------------------------- From nobody Sun Oct 22 08:23:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F34139823 for ; Sun, 22 Oct 2017 08:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 bWTfymvxawGd for ; Sun, 22 Oct 2017 08:23:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C1513981F for ; Sun, 22 Oct 2017 08:23:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5D294BE7B; Sun, 22 Oct 2017 16:23:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4tO6U8qSQZr; Sun, 22 Oct 2017 16:23:38 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8056FBE79; Sun, 22 Oct 2017 16:23:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508685818; bh=Cg+/TrWnxkdj3aBf14Q4wUjADb4S22yMnGmnzgh9W5M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AdAuvFk3kv14z7PAzUo+OofCASBxbEUGTfKEg9qpgkoxIJvf7+Y/5CSnpks/9zUqF rUVuZf71y0ksmn571QibSn71thzBk29lFMT88gZ1psnza6SZiJ/I5DTHAURmxhZ89i ABmiosrt/kEkFR25zXZtpQRsCnlz76p/10ZBOO9A= To: Eric Rescorla Cc: "tls@ietf.org" References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 22 Oct 2017 16:23:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5JnSNfQXKc9wCJ0mee5h4kTfTsHwqmtPU" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 15:23:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5JnSNfQXKc9wCJ0mee5h4kTfTsHwqmtPU Content-Type: multipart/mixed; boundary="onULE2QBaHMPm5d2Awp4ssWQrn49OVBtx"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] Connection ID Draft References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> In-Reply-To: --onULE2QBaHMPm5d2Awp4ssWQrn49OVBtx Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable (Sorry for the slow response...) Two things below... On 13/10/17 16:58, Eric Rescorla wrote: > On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> On 13/10/17 15:29, Eric Rescorla wrote: >>> There are a number of cases where this is actually much harder to >> implement >>> than a design where one side dictates the connection ID. For instance= , >>> consider a design where you have a pool of servers P1, P2, ... P_n wi= th a >>> load balancer in front. >>> Each server i generates connection IDs of the form i || Random. The l= oad >>> balancer then just looks at the first byte and routes to the appropri= ate >>> load balancer [0]. In this design, the LB can be totally stateless, >> whereas >>> in the design you propose, it has to (a) have a back-channel to the >> server >>> to get the initial conn-id (b), do crypto (c) store state for all the= >> live >>> connections. >> >> Pre-pending a fixed length (known to both sides) load-balancer >> ID would be fine, sure. That'd change the function to something >> like: >> next-id =3D lb-id || H(foo||prev-id) >> >> So long as each load balancer is busy enough that still has the >> hard-to-link property I think. The length of the lb-id could be >> fixed or part of the negotiation, with zero being a fine length >> when there's no lb-id needed. >> >=20 > Well, this is a lot more complicated for the client and unless you plac= e > very strict limits on lb-id, it ends up with the server just dictating = an > identifier to the client so you have the scheme in this draft. >=20 >=20 >=20 >> I think this'd work ok regardless of who controls the initial id >> value, so long as we don't need ids to work like tickets (where >> the id value would be the ciphertext of some state info). >> >=20 > That's actually a design that people consider quite often and has been > discussed > for QUIC. So, if the WG want to allow for such designs, then I think that'd be better explicitly stated as some level of requirement, e.g. to say that some aspect of the scheme needs to allow some cids to be an encrypted form of something else. (I do think allowing for such is quite reasonable.) >> In addition, consider what happens when you get a CID you don't recogn= ize. >>> It might be nonsense but it might be that there was a cryptic CID cha= nge >>> (e.g., the client did two changes but you missed a packet). You need = to >>> decide the number of changes you're willing to tolerate and then the >> table >>> has to be that big times the number of connections (or you need to fi= ll >> it >>> in whenever you get an unknown CID, which the attacker can send you a= t >> any >>> time). >> >> Yes, schemes like this can be worse when packets go missing >> around the time of an id change. >> >> However, I think with this scheme (which isn't even on a napkin >> yet, just these mails:-), >=20 >=20 > Sure but we contemplated a number of these designs for QUIC, so we're n= ot > starting from scratch here. >=20 >=20 >=20 >=20 >> he sending side would just make the >> change when they want, and wouldn't signal that it's changed the >> id. So, in some cases (say if receivers store current and next, >> and id changes and packet losses are infrequent) a single packet >> drop would be just that and the id change wouldn't affect things >> at all. In the putative nb-IoT case I mentioned before then it >> could be a good bit worse unless the receiver stores a bunch of >> future ids. (I agree some work is needed to figure out if there's >> an acceptable scheme here, so for now I'm arguing that we not >> preclude such schemes when adopting your draft.) >> >> In figuring this out, I'd argue that we ought be comparing ideas >> like this against two things: 1) the simplest solution that does >> allow linkabillity and 2) the costs of setting up a new TLS >> session to avoid linkability. While this or similar schemes will >> look bad compared to (1), they will likely look pretty good >> compared to (2). >> >> Of course, how one evaluates such comparisons will depend on how >> serious a threat one considers linkabillity. I'd argue that many >> devices that'll need connections ids will be devices where the >> possibility of linkability could be a significant threat and where >> new TLS session establishment will be rare, so we therefore ought >> provide some good method of avoiding linkability. >> >=20 > I'd say three things here: >=20 > 1. First, as I said we considered a lot of different designs for provid= ing > better unlinkability than the design in this draft, and none of the > ones that did significantly better had reasonable scaling properties. >=20 > 2. The precise point of designing this as an extension is that if we > had a better design we could drop it in with a new extension code point= , > so accepting this design doesn't preclude anything. >=20 > 3. You seem to be claiming that your design has better linkability > properties than the design in this draft, but as far as I can tell that= 's > not correct. In both cases, either side can occasionally change > conn-ids (you can't change in each packet for the scaling reasons > I indicated). In your design one side does so unilaterally, but there > are packet loss concerns, and in the draft, you have to solicit new > conn-ids from the peer but as long as you have one you can change > unilaterally. I think the design I outlined does differ somewhat from the draft. In the draft the new connection ID has to be sent explicitly, but in this design it can be inferred, which saves bandwidth. I'm not claiming that's a mega-win, but I do think it might be needed for some of the device-sends-one-message-per-day scenarios if those are also using e.g. some lpwan radio technology. Maybe the thing we could agree at this stage is that the cid scheme has to be usable in that one-message-per-day scenario and needs to provide some way that such messages aren't easily linkable based on cids. (Which is useful if/when the 5-tuples don't provide linkage.) Personally I do think a hash-chain based scheme may be needed to meet that requirement, but I may well be wrong of course, as that happens quite a lot:-) Cheers, S. >=20 > The primary difference in your design is that the IDs are opaque > rather than containing data contributed by the other side, but that > difference is immediately weakened as soon as you try to introduce > structure to handle things like the server topology and also comes > at the cost of needing a much larger ID space in each packet to > avoid hash collisions. >=20 > -Ekr >=20 >=20 >> Cheers, >> S. >> >> >> >> >> >=20 --onULE2QBaHMPm5d2Awp4ssWQrn49OVBtx-- --5JnSNfQXKc9wCJ0mee5h4kTfTsHwqmtPU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ7Lf5AAoJEC88hzaAX42i+EUIALoFLKEuMSpzP7ayx4iNXi5K YrqJuv3puVNjKR6l7VM3k54eKNqfKzPygucrmgoSeU05xMesq1q0MrlKv5MMMVJy zKpocUcNTyVbIL7H5Vi7VnuZ6ywvrVJB5sn8NyAU4UpWkgTsLTQDRjCvF+fatkVK Q8T+InnF6xcGp4GHdMdOvjogRMfONQHeHtd9DIZUGv8W+97I/DnNsGq8H9rDf4vj S7/FeLMQbVNUxRnqwAVwflKqu0oUmYCLF8ubfY26TMzf+PejoEAu/1QVzFxomInx /KEoalTyTzKHyDDL5sn0uZ0chXLo26OpJYd9aCgli81p2Vx/bNVmx/ZdXZZLBvY= =/JHX -----END PGP SIGNATURE----- --5JnSNfQXKc9wCJ0mee5h4kTfTsHwqmtPU-- From nobody Sun Oct 22 08:42:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D4A13995B for ; Sun, 22 Oct 2017 08:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpC790V3d2d1 for ; Sun, 22 Oct 2017 08:42:18 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 3BA69139956 for ; Sun, 22 Oct 2017 08:42:18 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id j4so10103785ywb.2 for ; Sun, 22 Oct 2017 08:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Us0TzpkNIbV5HyJSU2rD4kIWxQxTVncLi/Bha6tRoE=; b=fhWUW21nCXswe+9itp3roZua1A2zJ+gIIiCUfT8w1yUyLCl8yitouGl0hS41xTXAbk czbZEzlEeyIRKb4z0K4i/G3IDCKJie+k1KtTTA+IxGl0yg4tmP3UPnTF3zSt89VqDAOL hKZxEN/c8vtii0yBJP+jPcagFBDLpPdLhKaIRptK556j8r7mdgrUNRxy4Pg+angLGWHO Y0v9e2kcBeVUDL3pn7AJENTnTzz6tUdoacLj0zCEkPY3pDemggdyIhKb1QYYpGIK/lu8 E2DuDnOg4QPO82JkB6ztRGhgmVSVtph8vQN74n5dqW/a5TO+1rgVWXYqoKRfdJYBvmk6 K4Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Us0TzpkNIbV5HyJSU2rD4kIWxQxTVncLi/Bha6tRoE=; b=KI+dsMmipu9obw4TzWCMelpyBTpGQSsf8hjdwJ7aD82if5lHqXA1mj1qLpBQMo8JpA GlkykYIkMSE7c1mJmNep1SYGor/CSV0hmfv53BXomwaLo1RlsUl5WtNQYf5mBLyTknbN lFSu7RamXVBMPjxDP+RIFLzrB8ECDmfWx+I8svN0oyx+KrlVhRmkhMAByAwqUIvuuD4G at69UzX48My5DIFobtqy8ZBVf4q+WRPN6yt4/bwSJFRbSdEE1TO8nWDhwcCJXqagzl/P dtUen1Q3mqLF4ol/yOiB4lHioD7Lg+OnqZmkR1lVSEL3Q3Gwcd2/Llt0AuIYAbB+BS7v vdaA== X-Gm-Message-State: AMCzsaWhvVhoqtnqxOV+Gs0LiyDB/hyHuTets5bV0KdlaO5BXpWpAOJz XWlC9ZzsO9lG++HieKI9I5FT3rGMnl25MrMI99/gZlRmcL8= X-Google-Smtp-Source: ABhQp+Qa0XHc2merpq63s9TSLmG4GYFlrWU5WUDC03LolZZ9Sg5GfhCpdP+h+xJjNTlyYlmLO2tC2YXtYr8Br8yxuUo= X-Received: by 10.129.36.1 with SMTP id k1mr7067021ywk.485.1508686937400; Sun, 22 Oct 2017 08:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sun, 22 Oct 2017 08:41:36 -0700 (PDT) In-Reply-To: References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> From: Eric Rescorla Date: Sun, 22 Oct 2017 08:41:36 -0700 Message-ID: To: Stephen Farrell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1142e4ccfb4325055c248ce2" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 15:42:21 -0000 --001a1142e4ccfb4325055c248ce2 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 22, 2017 at 8:23 AM, Stephen Farrell wrote: > > (Sorry for the slow response...) > > Two things below... > > On 13/10/17 16:58, Eric Rescorla wrote: > > On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> On 13/10/17 15:29, Eric Rescorla wrote: > >>> There are a number of cases where this is actually much harder to > >> implement > >>> than a design where one side dictates the connection ID. For instance, > >>> consider a design where you have a pool of servers P1, P2, ... P_n > with a > >>> load balancer in front. > >>> Each server i generates connection IDs of the form i || Random. The > load > >>> balancer then just looks at the first byte and routes to the > appropriate > >>> load balancer [0]. In this design, the LB can be totally stateless, > >> whereas > >>> in the design you propose, it has to (a) have a back-channel to the > >> server > >>> to get the initial conn-id (b), do crypto (c) store state for all the > >> live > >>> connections. > >> > >> Pre-pending a fixed length (known to both sides) load-balancer > >> ID would be fine, sure. That'd change the function to something > >> like: > >> next-id = lb-id || H(foo||prev-id) > >> > >> So long as each load balancer is busy enough that still has the > >> hard-to-link property I think. The length of the lb-id could be > >> fixed or part of the negotiation, with zero being a fine length > >> when there's no lb-id needed. > >> > > > > Well, this is a lot more complicated for the client and unless you place > > very strict limits on lb-id, it ends up with the server just dictating an > > identifier to the client so you have the scheme in this draft. > > > > > > > >> I think this'd work ok regardless of who controls the initial id > >> value, so long as we don't need ids to work like tickets (where > >> the id value would be the ciphertext of some state info). > >> > > > > That's actually a design that people consider quite often and has been > > discussed > > for QUIC. > > So, if the WG want to allow for such designs, then I think that'd > be better explicitly stated as some level of requirement, e.g. to > say that some aspect of the scheme needs to allow some cids to be > an encrypted form of something else. (I do think allowing for such > is quite reasonable.) > I'd be fine with adding that sort of text. >> In addition, consider what happens when you get a CID you don't > recognize. > >>> It might be nonsense but it might be that there was a cryptic CID > change > >>> (e.g., the client did two changes but you missed a packet). You need to > >>> decide the number of changes you're willing to tolerate and then the > >> table > >>> has to be that big times the number of connections (or you need to fill > >> it > >>> in whenever you get an unknown CID, which the attacker can send you at > >> any > >>> time). > >> > >> Yes, schemes like this can be worse when packets go missing > >> around the time of an id change. > >> > >> However, I think with this scheme (which isn't even on a napkin > >> yet, just these mails:-), > > > > > > Sure but we contemplated a number of these designs for QUIC, so we're not > > starting from scratch here. > > > > > > > > > >> he sending side would just make the > >> change when they want, and wouldn't signal that it's changed the > >> id. So, in some cases (say if receivers store current and next, > >> and id changes and packet losses are infrequent) a single packet > >> drop would be just that and the id change wouldn't affect things > >> at all. In the putative nb-IoT case I mentioned before then it > >> could be a good bit worse unless the receiver stores a bunch of > >> future ids. (I agree some work is needed to figure out if there's > >> an acceptable scheme here, so for now I'm arguing that we not > >> preclude such schemes when adopting your draft.) > >> > >> In figuring this out, I'd argue that we ought be comparing ideas > >> like this against two things: 1) the simplest solution that does > >> allow linkabillity and 2) the costs of setting up a new TLS > >> session to avoid linkability. While this or similar schemes will > >> look bad compared to (1), they will likely look pretty good > >> compared to (2). > >> > >> Of course, how one evaluates such comparisons will depend on how > >> serious a threat one considers linkabillity. I'd argue that many > >> devices that'll need connections ids will be devices where the > >> possibility of linkability could be a significant threat and where > >> new TLS session establishment will be rare, so we therefore ought > >> provide some good method of avoiding linkability. > >> > > > > I'd say three things here: > > > > 1. First, as I said we considered a lot of different designs for > providing > > better unlinkability than the design in this draft, and none of the > > ones that did significantly better had reasonable scaling properties. > > > > 2. The precise point of designing this as an extension is that if we > > had a better design we could drop it in with a new extension code point, > > so accepting this design doesn't preclude anything. > > > > 3. You seem to be claiming that your design has better linkability > > properties than the design in this draft, but as far as I can tell that's > > not correct. In both cases, either side can occasionally change > > conn-ids (you can't change in each packet for the scaling reasons > > I indicated). In your design one side does so unilaterally, but there > > are packet loss concerns, and in the draft, you have to solicit new > > conn-ids from the peer but as long as you have one you can change > > unilaterally. > > I think the design I outlined does differ somewhat from the draft. > I didn't say that it didn't differ. I said I didn't think it had better linkability properties. In the draft the new connection ID has to be sent explicitly, but > in this design it can be inferred, which saves bandwidth. That's not obviously true, because the CIDs in your case need to be larger to avoid collision problems. Maybe the thing we could agree at this stage is that the cid scheme > has to be usable in that one-message-per-day scenario and needs to > provide some way that such messages aren't easily linkable based on > cids. I think that's a requirement in some cases but not others. It might be best to settle for the others. (Which is useful if/when the 5-tuples don't provide linkage.) > Personally I do think a hash-chain based scheme may be needed to > meet that requirement, but I may well be wrong of course, as that > happens quite a lot:-) > That's clearly not true in the case where messages are symmetrical, as each side can provide a new connection ID with each message it sends. In fact, we considered just such a design for QUIC before concluding it was impractical. And note that in the case where you are actually sending one un-acked message per day, then it's actually quite easy to have significant packet loss in which case you run into the scaling problems I mentioned in my previous message. Again, I really would invite you to try to produce a fully worked out proposal, as its precisely the exercise of trying to do so that led us to this design. As none of the options are really ideal, it's quite easy to find deficiencies in any particular design, especially when the alternative is something that is at the napkin stage, and so has deficiencies which are yet to be determined. -Ekr > Cheers, > S. > > > > > The primary difference in your design is that the IDs are opaque > > rather than containing data contributed by the other side, but that > > difference is immediately weakened as soon as you try to introduce > > structure to handle things like the server topology and also comes > > at the cost of needing a much larger ID space in each packet to > > avoid hash collisions. > > > > -Ekr > > > > > >> Cheers, > >> S. > >> > >> > >> > >> > >> > > > > --001a1142e4ccfb4325055c248ce2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 22, 2017 at 8:23 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

(Sorry for the slow response...)

Two things below...

On 13/10/17 16:58, Eric Rescorla wrote:
> On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hiya,
>>
>> On 13/10/17 15:29, Eric Rescorla wrote:
>>> There are a number of cases where this is actually much harder= to
>> implement
>>> than a design where one side dictates the connection ID. For i= nstance,
>>> consider a design where you have a pool of servers P1, P2, ...= P_n with a
>>> load balancer in front.
>>> Each server i generates connection IDs of the form i || Random= . The load
>>> balancer then just looks at the first byte and routes to the a= ppropriate
>>> load balancer [0]. In this design, the LB can be totally state= less,
>> whereas
>>> in the design you propose, it has to (a) have a back-channel t= o the
>> server
>>> to get the initial conn-id (b), do crypto (c) store state for = all the
>> live
>>> connections.
>>
>> Pre-pending a fixed length (known to both sides) load-balancer
>> ID would be fine, sure. That'd change the function to somethin= g
>> like:
>>=C2=A0 =C2=A0 =C2=A0next-id =3D lb-id || H(foo||prev-id)
>>
>> So long as each load balancer is busy enough that still has the >> hard-to-link property I think. The length of the lb-id could be >> fixed or part of the negotiation, with zero being a fine length >> when there's no lb-id needed.
>>
>
> Well, this is a lot more complicated for the client and unless you pla= ce
> very strict limits on lb-id, it ends up with the server just dictating= an
> identifier to the client so you have the scheme in this draft.
>
>
>
>> I think this'd work ok regardless of who controls the initial = id
>> value, so long as we don't need ids to work like tickets (wher= e
>> the id value would be the ciphertext of some state info).
>>
>
> That's actually a design that people consider quite often and has = been
> discussed
> for QUIC.

So, if the WG want to allow for such designs, then I think that= 'd
be better explicitly stated as some level of requirement, e.g. to
say that some aspect of the scheme needs to allow some cids to be
an encrypted form of something else. (I do think allowing for such
is quite reasonable.)

I'd be fine w= ith adding that sort of text.


>> In addition, consider what happens when you get a CID you don'= t recognize.
>>> It might be nonsense but it might be that there was a cryptic = CID change
>>> (e.g., the client did two changes but you missed a packet). Yo= u need to
>>> decide the number of changes you're willing to tolerate an= d then the
>> table
>>> has to be that big times the number of connections (or you nee= d to fill
>> it
>>> in whenever you get an unknown CID, which the attacker can sen= d you at
>> any
>>> time).
>>
>> Yes, schemes like this can be worse when packets go missing
>> around the time of an id change.
>>
>> However, I think with this scheme (which isn't even on a napki= n
>> yet, just these mails:-),
>
>
> Sure but we contemplated a number of these designs for QUIC, so we'= ;re not
> starting from scratch here.
>
>
>
>
>> he sending side would just make the
>> change when they want, and wouldn't signal that it's chang= ed the
>> id. So, in some cases (say if receivers store current and next, >> and id changes and packet losses are infrequent) a single packet >> drop would be just that and the id change wouldn't affect thin= gs
>> at all. In the putative nb-IoT case I mentioned before then it
>> could be a good bit worse unless the receiver stores a bunch of >> future ids. (I agree some work is needed to figure out if there= 9;s
>> an acceptable scheme here, so for now I'm arguing that we not<= br> >> preclude such schemes when adopting your draft.)
>>
>> In figuring this out, I'd argue that we ought be comparing ide= as
>> like this against two things: 1) the simplest solution that does >> allow linkabillity and 2) the costs of setting up a new TLS
>> session to avoid linkability. While this or similar schemes will >> look bad compared to (1), they will likely look pretty good
>> compared to (2).
>>
>> Of course, how one evaluates such comparisons will depend on how >> serious a threat one considers linkabillity. I'd argue that ma= ny
>> devices that'll need connections ids will be devices where the=
>> possibility of linkability could be a significant threat and where=
>> new TLS session establishment will be rare, so we therefore ought<= br> >> provide some good method of avoiding linkability.
>>
>
> I'd say three things here:
>
> 1. First, as I said we considered a lot of different designs for provi= ding
> better unlinkability than the design in this draft, and none of the > ones that did significantly better had reasonable scaling properties.<= br> >
> 2. The precise point of designing this as an extension is that if we > had a better design we could drop it in with a new extension code poin= t,
> so accepting this design doesn't preclude anything.
>
> 3. You seem to be claiming that your design has better linkability
> properties than the design in this draft, but as far as I can tell tha= t's
> not correct. In both cases, either side can occasionally change
> conn-ids (you can't change in each packet for the scaling reasons<= br> > I indicated). In your design one side does so unilaterally, but there<= br> > are packet loss concerns, and in the draft, you have to solicit new > conn-ids from the peer but as long as you have one you can change
> unilaterally.

I think the design I outlined does differ somewhat from the dra= ft.

I didn't say that it didn't= differ. I said I didn't think it had better linkability
prop= erties.


In the draft the new connection ID has to be sent explicitly, but
in this design it can be inferred, which saves bandwidth.
=
That's not obviously true, because the CIDs in your case= need to
be larger to avoid collision problems.


Maybe the thing we could agree at this stage is that the cid scheme
has to be usable in that one-message-per-day scenario and needs to
provide some way that such messages aren't easily linkable based on
cids.

I think that's a requirement in = some cases but not others. It might be
best to settle for the oth= ers.


(Which is useful if/when the 5-tuples don't provide link= age.)
Personally I do think a hash-chain based scheme may be needed to
meet that requirement, but I may well be wrong of course, as that
happens quite a lot:-)

That's clear= ly not true in the case where messages are symmetrical, as
each s= ide can provide a new connection ID with each message it sends.
I= n fact, we considered just such a design for QUIC before concluding
it was impractical.

And note that in the case w= here you are actually sending one un-acked
message per day, then = it's actually quite easy to have significant packet
loss in w= hich case you run into the scaling problems I mentioned in my
pre= vious message.

Again, I really would invite you to= try to produce a fully worked out proposal,
as its precisely the= exercise of trying to do so that led us to this design. As
none = of the options are really ideal, it's quite easy to find deficiencies i= n
any particular design, especially when the alternative is somet= hing that
is at the napkin stage, and so has deficiencies which a= re yet to be determined.

-Ekr

=



Cheers,
S.

>
> The primary difference in your design is that the IDs are opaque
> rather than containing data contributed by the other side, but that > difference is immediately weakened as soon as you try to introduce
> structure to handle things like the server topology and also comes
> at the cost of needing a much larger ID space in each packet to
> avoid hash collisions.
>
> -Ekr
>
>
>> Cheers,
>> S.
>>
>>
>>
>>
>>
>


--001a1142e4ccfb4325055c248ce2-- From nobody Sun Oct 22 08:50:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2232E1399C6 for ; Sun, 22 Oct 2017 08:50:20 -0700 (PDT) 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 jLEe_yczv4FE for ; Sun, 22 Oct 2017 08:50:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413DC1399C7 for ; Sun, 22 Oct 2017 08:50:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 08C4ABE7B; Sun, 22 Oct 2017 16:50:16 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4YyxWuZtdyi; Sun, 22 Oct 2017 16:50:14 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 99F99BE6F; Sun, 22 Oct 2017 16:50:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508687414; bh=v1LRRMeWl9IYJkR/CVkFTvXe7i9KXJ6TbCTEPIH6k4s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=J3+7CNe5EHSZY6x8Ws9b0RAjPO9/H7373LsryioWv3mZosBfIejALe5I01UjTJK7D HGAD+/RpQ0sbMr6PVRAHRMMM7b0d0PBdiBCzFlJcLuZ+seY6W5TZlRINlC/yUq15Cn 14Z0y9vELp9ZBygULpfQ1iMYUSHnGnsbkUG0jtxs= To: Eric Rescorla Cc: "tls@ietf.org" References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 22 Oct 2017 16:50:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4uaxBLOr2H8LNcKV2OReqMxBwDgIr1v1n" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 15:50:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4uaxBLOr2H8LNcKV2OReqMxBwDgIr1v1n Content-Type: multipart/mixed; boundary="0PP2qWQNaaFkPXLxiiEh3HGb5rgw9d5jJ"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] Connection ID Draft References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> In-Reply-To: --0PP2qWQNaaFkPXLxiiEh3HGb5rgw9d5jJ Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 22/10/17 16:41, Eric Rescorla wrote: >=20 >> Maybe the thing we could agree at this stage is that the cid scheme >> has to be usable in that one-message-per-day scenario and needs to >> provide some way that such messages aren't easily linkable based on >> cids. >=20 > I think that's a requirement in some cases but not others. It might be > best to settle for the others. Sorry, I'm not sure what you mean there. Are you saying that you think the above requirement can't be met by a generally usable scheme? I agree that not all scenarios need to meet the req posited above. I'd worry that if DTLS1.3 can't meet the above requirement then folks will invent something that does, which may be worse than using DTLS in a bunch of cases. OTOH, one could equally, and maybe fairly, argue that DTLS really doesn't scale down quite that far, which'd I guess argue that there's a need for some other security protocol for those situations. S. PS: I fully accept your point that purely napkin-based schemes aren't good enough and if those're the only kind of hash-chain based proposals seen, then the WG oughtn't go for one of those. --0PP2qWQNaaFkPXLxiiEh3HGb5rgw9d5jJ-- --4uaxBLOr2H8LNcKV2OReqMxBwDgIr1v1n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ7L41AAoJEC88hzaAX42iRogIAL4AIaVTvDe41kq5Lyf3JIik ABoIfu51gSlE8odXO8+/RPOw0RO0ZzR/tSbwNoSMU1/tb2J83HuDan5abAhYM5fq MszDAXTcz7BZAX6yqqOpdII3WU0mQB5nurYYqpXz1XmLzEzqSpQWcvYHslS0HkIj Xi1i/QSUTT8ChFfpTDW0e3U/spcH0Tud4posGSL8BeQwtdteHPhNPwCz69ZSd0C0 ydLyWXlYx62Ug0MvbOsJE+Ka0K/+j9440aLNiLcMAfCsDogdN96+rb0Kdhp4TL7/ N+bfaOsCXza/a8+ON6VAkBGlDywGNUP9yINJvzHg7PmZTbaG9bXUGowyCpBI9wg= =nhkt -----END PGP SIGNATURE----- --4uaxBLOr2H8LNcKV2OReqMxBwDgIr1v1n-- From nobody Sun Oct 22 09:05:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C11139B14 for ; Sun, 22 Oct 2017 09:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiTIyoSLCiLl for ; Sun, 22 Oct 2017 09:05:35 -0700 (PDT) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (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 12CC4139B0B for ; Sun, 22 Oct 2017 09:05:35 -0700 (PDT) Received: by mail-yw0-x244.google.com with SMTP id t11so10121846ywg.12 for ; Sun, 22 Oct 2017 09:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H7xnu2xwL5fkpwNCogvQPkxmBu2Pzk+zd2R3QRKVmZM=; b=rm0b8eqFMsqPwzs4IO3C1VeXVbvvVQfyNZa9EYNbC5YFhQ7bJL1Z24rw95ke6i3e1y mtoPcI/gRLarnrfjrZp3g/LbGCpYaiYdiVa/lCJT/HHJxQoqFQEyDW4732794EJ0GZlv B4ADGHPTMuVShU43ML2kbvT4aJ6Q5cV0qZu40EoPdPf8Esfbq/kMPJnEE7bfvCHSKtXc MbTHEAFw4y5/TybOKZaLu5ODqxpFfp4QEfTrkfcNKOFBJGeZifFFt4pnIjxrJK/xuKim W+6N76Q8rUFU4ThWke1CSv0TKdW5lUVazJ/IY/NZd9EprbnqlsDU3/e8MwoxZ7UiPbs6 63Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H7xnu2xwL5fkpwNCogvQPkxmBu2Pzk+zd2R3QRKVmZM=; b=uITUOTYWjeuz6WGTDCSwNzTGP8PSHTl5BETx99fg+Z+yKwqP2JMEOkrZt5MJF/n6Iy pwPBvBH9n/imNeOcbxlbYsCC7U1k3Z465UYxrhEAJ0QNbx0QgtLv3ZHLhmMi1q8Benqk Dh/t4YPrPLWkF+3TTh55WfchFgGCiQ52Bilq0a1tzGONcr19Crxh20qKAcYxuqnEF5lR iicSPr5gcml5UREhrazkp9WQGW8TY6chkXSFR+lnjCem6MI7XjyBByaekAqs1JzBX6M5 kl33cF9ShetGKqkJMCrYGAKoEEp0NoFkBAn1fMhy19/N90BVCi88E1Euf2bVftJTsUK7 0KrA== X-Gm-Message-State: AMCzsaX3TFWFvZAtXlvs/PwluAd69IbNYl4R9fLASvoaCDzfU+t8RnZz vHUM/ZX3O8aZUMfWsstHvAmBmrvOBvdu3m20/Dh/Ra2X X-Google-Smtp-Source: ABhQp+T2a2ffcXs1X34xyzfutBapXYAaShmwXU9hl8+THxuY7R8bOCFbOiTBPFfLL83bCra9B8BuWLeKosupfjZcktE= X-Received: by 10.37.45.83 with SMTP id s19mr6682787ybe.400.1508688334302; Sun, 22 Oct 2017 09:05:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sun, 22 Oct 2017 09:04:53 -0700 (PDT) In-Reply-To: References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> From: Eric Rescorla Date: Sun, 22 Oct 2017 09:04:53 -0700 Message-ID: To: Stephen Farrell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f4030435b0103e47de055c24e03c" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 16:05:36 -0000 --f4030435b0103e47de055c24e03c Content-Type: text/plain; charset="UTF-8" On Sun, Oct 22, 2017 at 8:50 AM, Stephen Farrell wrote: > > > On 22/10/17 16:41, Eric Rescorla wrote: > > > >> Maybe the thing we could agree at this stage is that the cid scheme > >> has to be usable in that one-message-per-day scenario and needs to > >> provide some way that such messages aren't easily linkable based on > >> cids. > > > > I think that's a requirement in some cases but not others. It might be > > best to settle for the others. > > Sorry, I'm not sure what you mean there. Are you saying that you think > the above requirement can't be met by a generally usable scheme? > > I agree that not all scenarios need to meet the req posited above. > > I'd worry that if DTLS1.3 can't meet the above requirement then folks > will invent something that does, which may be worse than using DTLS > in a bunch of cases. OTOH, one could equally, and maybe fairly, argue > that DTLS really doesn't scale down quite that far, which'd I guess > argue that there's a need for some other security protocol for those > situations. > It's not a matter of DTLS versus non-DTLS. I am unaware of any method of providing conn-IDs that simultaneously meets the requirements of: - Unlinkability - Being able to survive multiple conn-ID changes in one round-trip (which is implicit in both the one-packet per day and the unknown address changes scenarios) - Low bandwidth - Good receiver-side scaling (both state and computational) This is a generic problem, not one limited to DTLS. And as I said earlier, to the extent to which we either need specific schemes that meet different subsets of these requirements or we come up with a better generic scheme, the extension-based approach accommodates it. PS: I fully accept your point that purely napkin-based schemes aren't > good enough and if those're the only kind of hash-chain based proposals > seen, then the WG oughtn't go for one of those. > We've seen others, and they fail the receiver-side scaling test, IMO -Ekr --f4030435b0103e47de055c24e03c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 22, 2017 at 8:50 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:


On 22/10/17 16:41, Eric Rescorla wrote:
>
>> Maybe the thing we could agree at this stage is that the cid schem= e
>> has to be usable in that one-message-per-day scenario and needs to=
>> provide some way that such messages aren't easily linkable bas= ed on
>> cids.
>
> I think that's a requirement in some cases but not others. It migh= t be
> best to settle for the others.

Sorry, I'm not sure what you mean there. Are you saying that you= think
the above requirement can't be met by a generally usable scheme?

I agree that not all scenarios need to meet the req posited above.

I'd worry that if DTLS1.3 can't meet the above requirement then fol= ks
will invent something that does, which may be worse than using DTLS
in a bunch of cases. OTOH, one could equally, and maybe fairly, argue
that DTLS really doesn't scale down quite that far, which'd I guess=
argue that there's a need for some other security protocol for those situations.

It's not a matter of DT= LS versus non-DTLS. I am unaware of any method
of providing conn-= IDs that simultaneously meets the requirements of:

- Unlinkability
- Being able to survive multiple conn-ID changes= in one round-trip
=C2=A0 (which is implicit in both the one-pack= et per day and the unknown
=C2=A0 address changes scenarios)
- Low bandwidth
- Good receiver-side scaling (both state an= d computational)

This is a generic problem, not on= e limited to DTLS. And as I said earlier,
to the extent to which = we either need specific schemes that meet different
subsets of th= ese requirements or we come up with a better generic scheme,
the = extension-based approach accommodates it.


PS: I fully accept your point that purely = napkin-based schemes aren't
good enough and if those're the only kind of hash-chain based proposals=
seen, then the WG oughtn= 9;t go for one of those.

We've seen= others, and they fail the receiver-side scaling test, IMO

-Ekr
=C2=A0

--f4030435b0103e47de055c24e03c-- From nobody Sun Oct 22 09:59:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B5F139F3F for ; Sun, 22 Oct 2017 09:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xlj5eOnLZctJ for ; Sun, 22 Oct 2017 09:58:58 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 1FEB2139F37 for ; Sun, 22 Oct 2017 09:58:58 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id b15so19425028qkg.9 for ; Sun, 22 Oct 2017 09:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=E+LVE5n/tH9x4IUDuCJdrIeo0n+SdBG1zEFOSJzi8P8=; b=mACeip2cKDG47dYEquKzyiKwPGnwqCeM0r1hx9Veno5Y8Il5eTeqL43yzOO8nlbChc 4+RAo4ECATzicKkbX0AsYZFEBLquyWHwL6l2M58I5+3s46WKz3xacfFW9DLWaNuc/MDu gDDFYkw285JQmzG6WU6BQejkhw0CWmAjaWTBKzcntGR3ThPmL+G4NtmajIeFcb8TrDfp K0PjjtM/2nIGjdm+l53xzHTFSc8Au30QplDaa6vNlPF6RH0GRRiI0iFIgHSBAaDr0fss Cux4q602QzBUbG08LJO4veWgclx1kPou6AqKhd9/lyOiYkBoNVeHF7cnTorjPIFHQ97M jXQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=E+LVE5n/tH9x4IUDuCJdrIeo0n+SdBG1zEFOSJzi8P8=; b=p52aQ5PjsqBtTOgomTfCATeIHOfhg+dfREgAwcT/iyZ0FXVIZmg6TXz3hc+FLFl1vg LQScM0VZnttmE1BA7Dz6pW0GbPHmqmNF2GOy0LzFRofN7e5cz3+2OfAv3QwJ7l14YrM5 ukGuLptip2ItYkFdGkmvRbtzWJqLJAd8WUrdvnPxeNXn6kl3nc93j3JbHsCqkKuiZmJq gokwcFcG9vpSFeZMlaQ8HG6WisTwwp+jT9ZyXeG3Ixht1CBwcu5AVAllBaxadXKUXAG+ 1HT4X/US+byKKkyFWZ5Yzwcj5ZgJ/YBYSPNYmKT54IVerstskQoWNY2q7JYNs0PJUt2G ZtOA== X-Gm-Message-State: AMCzsaWT5T0EjF+6AT9JhSKzl8AMNJ+JMmRHwnLAGa144l41ormQ9U3f OrpN/ynHPAoTEEa33DxDWFM= X-Google-Smtp-Source: ABhQp+RlWbPGMb+Afh2bVgyL29f7A14hbRmnpH61GCWMObVaRcws3ElBOH+bpGkPLEvQt/eScWYpRA== X-Received: by 10.55.212.154 with SMTP id s26mr15532678qks.200.1508691537190; Sun, 22 Oct 2017 09:58:57 -0700 (PDT) Received: from [192.168.1.5] (pool-72-94-149-146.phlapa.fios.verizon.net. [72.94.149.146]) by smtp.gmail.com with ESMTPSA id n23sm3489258qka.1.2017.10.22.09.58.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 09:58:56 -0700 (PDT) To: "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> From: Dave Garrett Message-ID: <3e2c1097-3201-0b8b-77d5-14c81e732652@gmail.com> Date: Sun, 22 Oct 2017 12:58:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 16:59:00 -0000 Agreed; this conversation is not going to get anything to a real WG consensus without causing people to flee the WG. The hard sell just makes people more and more skeptical that this is really well intentioned. Please, let's just let this mess die. As Rich Salz has stated previously, we should just recommend those unwilling to change their ways immediately to stay on TLS 1.2 for a few years whilst they transition to something less horrible that can work with TLS 1.3. And, that less horrible thing need not suck up a billion more posts here. Dave On 10/20/2017 10:08 AM, Ted Lemon wrote: > On Oct 20, 2017, at 9:54 AM, Stephen Farrell > wrote: > I can say for myself that there was a really strong hard sell on the > notion of doing this in Prague. Not being sufficiently paranoid, my > general sympathy for people facing hard problems led me to consider what > they were proposing, but each time they came up with something, someone > with more paranoia fu than I have pointed out a hole in it. During > that period there were several periods when I was reluctantly willing to > consider some less-bad version of draft-green. This is a long way from > "want," and even a pretty long way from "support." > > My personal feeling having been peeled off the herd and hard-sold like > this is that there is some really powerful motivated reasoning going on > here, and that the working group should just stop entertaining this > process. Weakening TLS is not the right way to approach the problem > that has been described here. > > I hasten to add that I don't think the people doing the hard sell are > bad people, or that they didn't have good reason for trying to do it. > My point is simply that we've been collectively sucked close to a black > hole here, and we need to take a step back from it. In the same sense > that LEOs who want key escrow have good reason for wanting it and are > not bad people for wanting it, so too with the people pushing this > proposal. But like key escrow, this proposal is not beneficial for > end-users or for security as a whole. > > In order for it to make sense to go forward with this proposal, two > things would have to be true that I don't think are true. First, we > would have to agree that user security is not a primary goal. And > second, we would have to agree that overall network security is not a > primary goal. Discussing the details of how much security we are > willing to give up, what attack surfaces that we could remove we are > willing to leave in, only makes sense if we are willing to drop those > two primary goals. > > Watching this conversation has been a really good learning experience > for me, so I don't regret it, but I think we should stop. From nobody Sun Oct 22 10:29:07 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A7B13A0FB for ; Sun, 22 Oct 2017 10:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 TXtmAxnwCEcF for ; Sun, 22 Oct 2017 10:29:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B3C13A100 for ; Sun, 22 Oct 2017 10:29:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 402CDBE79; Sun, 22 Oct 2017 18:29:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiXErAeSeWUr; Sun, 22 Oct 2017 18:28:59 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C772BE73; Sun, 22 Oct 2017 18:28:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508693339; bh=0XtJnfpTGGGe7AJ7J5zHxV+e8xzHQbzDN71WGf0O/tc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=q+Tyz5BWNq0dztZXph9YA8V/SYW6Ru9xogZdpSZWlz1uT16Ivn/yicFKabj9fdhk3 W4O+MGXUUXj8erN288fjh0uUXWMvvgR2gmx2xvt6aeXlX4m8L+H+rSr7RV47mwJvoi W4XR2AC5jzyw+uGqU6KRfENJW6ZwmkLAlbWNL07o= To: Eric Rescorla Cc: "tls@ietf.org" References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <3de461d1-04f2-f409-5cb1-adf67ccf1091@cs.tcd.ie> Date: Sun, 22 Oct 2017 18:28:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="p5L00EvE54jAhoo3PGb7MfFigSiXNHPKl" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 17:29:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p5L00EvE54jAhoo3PGb7MfFigSiXNHPKl Content-Type: multipart/mixed; boundary="S6olsLNt87kOWaCMnhR9FQ8DHCXiLHIlP"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <3de461d1-04f2-f409-5cb1-adf67ccf1091@cs.tcd.ie> Subject: Re: [TLS] Connection ID Draft References: <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie> <016ec9b6-d59e-531a-0930-9f355edb34be@cs.tcd.ie> In-Reply-To: --S6olsLNt87kOWaCMnhR9FQ8DHCXiLHIlP Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 22/10/17 17:04, Eric Rescorla wrote: > On Sun, Oct 22, 2017 at 8:50 AM, Stephen Farrell > wrote: >=20 >> >> >> On 22/10/17 16:41, Eric Rescorla wrote: >>> >>>> Maybe the thing we could agree at this stage is that the cid scheme >>>> has to be usable in that one-message-per-day scenario and needs to >>>> provide some way that such messages aren't easily linkable based on >>>> cids. >>> >>> I think that's a requirement in some cases but not others. It might b= e >>> best to settle for the others. >> >> Sorry, I'm not sure what you mean there. Are you saying that you think= >> the above requirement can't be met by a generally usable scheme? >> >> I agree that not all scenarios need to meet the req posited above. >> >> I'd worry that if DTLS1.3 can't meet the above requirement then folks >> will invent something that does, which may be worse than using DTLS >> in a bunch of cases. OTOH, one could equally, and maybe fairly, argue >> that DTLS really doesn't scale down quite that far, which'd I guess >> argue that there's a need for some other security protocol for those >> situations. >> >=20 > It's not a matter of DTLS versus non-DTLS.=20 Not sure tbh, ISTM there's a bunch of challenges in trying to use the kind of lpwan technologies being developed with DTLS, with cid just being one of those. But time will tell I guess, and that's a different discussion. > I am unaware of any method > of providing conn-IDs that simultaneously meets the requirements of: >=20 > - Unlinkability > - Being able to survive multiple conn-ID changes in one round-trip > (which is implicit in both the one-packet per day and the unknown > address changes scenarios) > - Low bandwidth > - Good receiver-side scaling (both state and computational) >=20 Fair enough - I can buy that the last above suffers when one tries to satisfy all the rest. Maybe that means a WG draft ought have an applicability statement section that captures the scenarios where that particular cid extension is suitable. I'll be sad though if the end result is to sacrifice unlinkability which I fear will be the likely outcome in practice. > This is a generic problem, not one limited to DTLS. And as I said earli= er, > to the extent to which we either need specific schemes that meet differ= ent > subsets of these requirements or we come up with a better generic schem= e, > the extension-based approach accommodates it. Again, maybe some applicability text as per the above would make it clearer that the draft is describing one (though hopefully the most commonly useful) scheme and that others may be needed in other situations. Cheers, S. PS: In case it helps, with the additions discussed earlier and above, and with the understanding that exploring other cid schemes for cases where this one isn't fully satisfactory isn't ruled out, I think this draft would be a fine starting point for a WG document. >=20 >=20 > PS: I fully accept your point that purely napkin-based schemes aren't >> good enough and if those're the only kind of hash-chain based proposal= s >> > seen, then the WG oughtn't go for one of those. >> >=20 > We've seen others, and they fail the receiver-side scaling test, IMO >=20 > -Ekr >=20 --S6olsLNt87kOWaCMnhR9FQ8DHCXiLHIlP-- --p5L00EvE54jAhoo3PGb7MfFigSiXNHPKl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ7NVbAAoJEC88hzaAX42iwNMIAIs4sfdkdAHWkFIg046gXNP9 OaK1R6mBdxt9J5G3FNR0mSsr7v93XSKPtQdDzv9zOafItQyNkm6E8NvDVv3o7nzL tOTchQ6spLi9cjp02LGpNFZ7u1OylkIq91nGLWAA93+8uhTjxwtQ8+6YLMYtERaR rr80L4c1h2toCNbBt0oayaTyo5ap+WBgNmR0bx7Pb8WNwCJuGi0+kug491HqOl5Q TzDZMpbi/6Zr1v4AfzVTjrkPWfYmp8waXzSp0Gcc+fnWJhxxB8hW4WEldvZy8h3L 0fwiE36zKuYWenB0j0XrexcyaCK4NJ4GXsJ2nUl8TBlwkdakpRPmbrr+PQRqOkE= =Uvqj -----END PGP SIGNATURE----- --p5L00EvE54jAhoo3PGb7MfFigSiXNHPKl-- From nobody Sun Oct 22 10:54:07 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A509113A2B5 for ; Sun, 22 Oct 2017 10:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 4zgnBshlXLbg for ; Sun, 22 Oct 2017 10:54:04 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E71A13A2B1 for ; Sun, 22 Oct 2017 10:54:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 851903005A7 for ; Sun, 22 Oct 2017 13:54:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9RVh_GcJDNoR for ; Sun, 22 Oct 2017 13:54:02 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 496983004BC; Sun, 22 Oct 2017 13:54:02 -0400 (EDT) From: Russ Housley Message-Id: <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7BF365F8-DD86-4BE5-9540-1F2A86AFB132" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 22 Oct 2017 13:54:01 -0400 In-Reply-To: Cc: IETF TLS To: Tony Arcieri References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 17:54:06 -0000 --Apple-Mail=_7BF365F8-DD86-4BE5-9540-1F2A86AFB132 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tony: >=20 > Can you provide a *specific citation* as to where you will be = *required* to use TLS 1.3 any time in, say, the next decade? >=20 No one is requiring TLS 1.3 that I know about. However, there are = places that require visibility into TLS. I will let one of the people = that works in a regulated industry offer pointers to the documents. Russ --Apple-Mail=_7BF365F8-DD86-4BE5-9540-1F2A86AFB132 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Tony:

Can= you provide a *specific citation* as to where you will be *required* to = use TLS 1.3 any time in, say, the next decade?

No one is = requiring TLS 1.3 that I know about.  However, there are places = that require visibility into TLS.  I will let one of the people = that works in a regulated industry offer pointers to the documents.

Russ

= --Apple-Mail=_7BF365F8-DD86-4BE5-9540-1F2A86AFB132-- From nobody Sun Oct 22 11:31:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E03113A5D6 for ; Sun, 22 Oct 2017 11:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 q52cD40g2TJt for ; Sun, 22 Oct 2017 11:31:15 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAF213A5CC for ; Sun, 22 Oct 2017 11:31:14 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v9MIVDmK041000 for ; Sun, 22 Oct 2017 14:31:13 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: IETF TLS Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO713gKFaj/ze3UaJfDxWNuaqP6LqPDwAgAFTKoCAAAWQgIAAANiAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAACX8gIAABAIAgAAHdgCAAB23gIAAPAIAgALfU4CAAApjAA== Date: Sun, 22 Oct 2017 18:31:12 +0000 Message-ID: <57878472-6988-4417-BC2B-B9288AF8E478@ll.mit.edu> References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> In-Reply-To: <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-3D2AB148-07FB-46D0-A8DF-DCD7E01FE556"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-22_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710220267 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 18:31:17 -0000 --Apple-Mail-3D2AB148-07FB-46D0-A8DF-DCD7E01FE556 Content-Type: multipart/alternative; boundary=Apple-Mail-F2BE9FA5-F142-4980-8C24-21DC7EF45F56 Content-Transfer-Encoding: 7bit --Apple-Mail-F2BE9FA5-F142-4980-8C24-21DC7EF45F56 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable IMHO, get the TLS-1.3 standard out first, then start mucking with it. There's nothing yet to make "visibility" into. ;-) And in any case I'm against weakening the protocol, since there are other wa= ys to accomplish the perlustrator's mission. Regards, Uri Sent from my iPhone > On Oct 22, 2017, at 13:54, Russ Housley wrote: >=20 > Tony: >>=20 >> Can you provide a *specific citation* as to where you will be *required* t= o use TLS 1.3 any time in, say, the next decade? >>=20 > No one is requiring TLS 1.3 that I know about. However, there are places t= hat require visibility into TLS. I will let one of the people that works in= a regulated industry offer pointers to the documents. >=20 > Russ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-F2BE9FA5-F142-4980-8C24-21DC7EF45F56 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPklNSE8sIGdldCB0 aGUgVExTLTEuMyBzdGFuZGFyZCBvdXQgZmlyc3QsIHRoZW4gc3RhcnQgbXVja2luZyB3aXRoIGl0 LjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlcmUncyBub3RoaW5nIHlldCB0byBtYWtlICJ2aXNpYmls aXR5IiBpbnRvLiA7LSk8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkFuZCBpbiBhbnkgY2FzZSBJ J20gYWdhaW5zdCB3ZWFrZW5pbmcgdGhlIHByb3RvY29sLCBzaW5jZSB0aGVyZSBhcmUgb3RoZXIg d2F5cyB0byBhY2NvbXBsaXNoIHRoZSBwZXJsdXN0cmF0b3IncyBtaXNzaW9uLjxicj48YnI+PGRp diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5SZWdhcmRzLDxkaXY+VXJpPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+PC9kaXY+PGRpdj48YnI+T24gT2N0 IDIyLCAyMDE3LCBhdCAxMzo1NCwgUnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91 c2xleUB2aWdpbHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDsgd3JvdGU6PGJy Pjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPlRv bnk6PGJyIGNsYXNzPSIiPjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48ZGl2IGNsYXNzPSIiPjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5DYW4geW91 IHByb3ZpZGUgYSAqc3BlY2lmaWMgY2l0YXRpb24qIGFzIHRvIHdoZXJlIHlvdSB3aWxsIGJlICpy ZXF1aXJlZCogdG8gdXNlIFRMUyAxLjMgYW55IHRpbWUgaW4sIHNheSwgdGhlIG5leHQgZGVjYWRl PzwvZGl2PjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PC9kaXY+PC9ibG9j a3F1b3RlPjwvZGl2Pk5vIG9uZSBpcyByZXF1aXJpbmcgVExTIDEuMyB0aGF0IEkga25vdyBhYm91 dC4gJm5ic3A7SG93ZXZlciwgdGhlcmUgYXJlIHBsYWNlcyB0aGF0IHJlcXVpcmUgdmlzaWJpbGl0 eSBpbnRvIFRMUy4gJm5ic3A7SSB3aWxsIGxldCBvbmUgb2YgdGhlIHBlb3BsZSB0aGF0IHdvcmtz IGluIGEgcmVndWxhdGVkIGluZHVzdHJ5IG9mZmVyIHBvaW50ZXJzIHRvIHRoZSBkb2N1bWVudHMu PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5SdXNzPC9kaXY+ PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPlRMUyBtYWlsaW5nIGxpc3Q8L3Nw YW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwv YT48L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rsczwv YT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2JvZHk+PC9odG1sPg== --Apple-Mail-F2BE9FA5-F142-4980-8C24-21DC7EF45F56-- --Apple-Mail-3D2AB148-07FB-46D0-A8DF-DCD7E01FE556 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcxMDIyMTgzMTEyWjAjBgkqhkiG9w0BCQQxFgQUhN4nxrd3fJejrBdXzCmxelzt760wbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBACsaFfmYYHuv//hLdCophbhEjoFLI9mBLFKJmWAKqtdemC2oXGlz/by847k1JVdx w2YkKlEGX3gG87JVl4Co+AUl41xAjXw8DcQhOK6GeUji+GGIFEUBCzrLmBAKM3i6KR9O0NjEAh6V JRRRfWoDUPfLvuxBieoYgWNPijBVMZTMXWFldeT8LlC9aVVjyHxdG651ANyoYh5Dg7zSgdTczi0D rnhi+o3VEblmxbl8eAxwsZeGzRV2XKBG0yzV34iPF1ypEaTrfbVAYfUAqp/gHtUz5zBpVwPd8xxJ HDQxIruMBZ1fO5pJdKIAQWRYGYunjSMQZSRi+ocRS+7rXTDJrbwAAAAAAAA= --Apple-Mail-3D2AB148-07FB-46D0-A8DF-DCD7E01FE556-- From nobody Sun Oct 22 11:40:50 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1523513A665 for ; Sun, 22 Oct 2017 11:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27XWtuSBMk-k for ; Sun, 22 Oct 2017 11:40:47 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 2164113A662 for ; Sun, 22 Oct 2017 11:40:47 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id z50so23761457qtj.4 for ; Sun, 22 Oct 2017 11:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=unpneGzhNJM0uEPfGSiRCgUAk2KlIwjwu7Fl6xv4o0w=; b=LYEUkksKQT5EXGqQ6TdeSup+IWsyl+hpzbUUqYAVlOltFuUJJ1ibj8T/mBFPrNfXuD ImZUscb7qArmnxoI2GOy/x67SqLH1qb9J8jW38FDMysGwbHu1L5pBIJsCaX8KQzMLkWt KiKUjNwFv5xJotApP4XZHKXHfWmeNzzY6W3X9UYIyp53m8DcRk5xjXq8iPjZZnx4aF3n Nd4pbapT1plsU45QRuoqUrTkviEipzLeDMHHYHeECjPT5elPXJhocKNlk3jp+PQJE9hu X32pWZg64HFsMu061JU9BLadJMJiKlwinIggHBicPOh0I18la4vyBpaK+2PVcuBiF1ij eD4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=unpneGzhNJM0uEPfGSiRCgUAk2KlIwjwu7Fl6xv4o0w=; b=Oz4Ye6cpvZoLwqfXHMPVAnmW5NAPzHnmb09Tn3uHsJ3scF42rPrmVGHB8u0GPTj7WA oS838UuW6674XF74luilKkQSClhGAEZ8dsEnhLsycUXrXRhtoWUdKRnwpCgGfXJu5QYJ 4N8giBSgl6a5OcaS3ZanrRFLYiGWyLlkvJS24o+5a2TIrwePdqWY13vWjihjdhpsEN2D is/bMy+BALPVk1j62UUm/L36uxHuMsj02mdcaaPFIUN0KfyY3Q3JsrSZAUJNGTMqFyNR afP5cNbl69r2gkQ3DV13MhEsNks7X4NlUburEWM7Tw6GBjOUT6hu3JGiMM10h2atEw0F ediw== X-Gm-Message-State: AMCzsaXYrbwRMDyOZ95ph0VJyUQjEbCE9pKlV+9XhAQLggAC8UnHXpYk 6r1DGkNvyFOY26QgMP65ssS2Cg== X-Google-Smtp-Source: ABhQp+Q5BfFiomvDSA0ZjT1itwt2USAHDxVsXlTnmI9x5QLyqJuME4fCeEUGRG0ec9w4bClrfGJZwg== X-Received: by 10.200.17.146 with SMTP id d18mr16526419qtj.61.1508697646240; Sun, 22 Oct 2017 11:40:46 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id k79sm3573721qke.28.2017.10.22.11.40.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 11:40:45 -0700 (PDT) From: Ted Lemon Message-Id: <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6A015DA7-93C9-452C-A362-30B2A518BE7E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 22 Oct 2017 14:40:43 -0400 In-Reply-To: <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> Cc: Tony Arcieri , IETF TLS To: Russ Housley References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 18:40:49 -0000 --Apple-Mail=_6A015DA7-93C9-452C-A362-30B2A518BE7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 22, 2017, at 1:54 PM, Russ Housley wrote: > No one is requiring TLS 1.3 that I know about. However, there are = places that require visibility into TLS. I will let one of the people = that works in a regulated industry offer pointers to the documents. What they require is visibility into contents of the flow that they are = using encryption to protect. Right now, the protocol they are using is = TLS 1.1 or TLS 1.2. The right thing for them to do if they continue to = need this visibility and are no longer permitted to use TLS 1.2 is to = use IPsec+IKE, or some protocol that is designed for this use case, not = to take a protocol designed specifically for securing flows from on-path = eavesdropping and create a mode where it is easier to wiretap. There is no reason other than momentum for them to switch to TLS 1.3 = when it doesn't address their use case. --Apple-Mail=_6A015DA7-93C9-452C-A362-30B2A518BE7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 22, 2017, at 1:54 PM, Russ Housley <housley@vigilsec.com> wrote:
No one is requiring TLS 1.3 that I know = about.  However, there are places that require visibility into TLS. =  I will let one of the people that works in a regulated industry = offer pointers to the documents.

What they require is visibility into contents = of the flow that they are using encryption to protect.   Right now, = the protocol they are using is TLS 1.1 or TLS 1.2.   The right = thing for them to do if they continue to need this visibility and are no = longer permitted to use TLS 1.2 is to use IPsec+IKE, or some protocol = that is designed for this use case, not to take a protocol designed = specifically for securing flows from on-path eavesdropping and create a = mode where it is easier to wiretap.

There is no reason other than momentum = for them to switch to TLS 1.3 when it doesn't address their use = case.

= --Apple-Mail=_6A015DA7-93C9-452C-A362-30B2A518BE7E-- From nobody Sun Oct 22 12:24:58 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2BC13AB30 for ; Sun, 22 Oct 2017 12:24:56 -0700 (PDT) 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 sFORlQNh6R6V for ; Sun, 22 Oct 2017 12:24:55 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B8B13AB17 for ; Sun, 22 Oct 2017 12:24:54 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id d9so17048245qtd.7 for ; Sun, 22 Oct 2017 12:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bTi+b1Hh8BVmXffVoJ8Rbls2h1QCq1CNvEVDEX0IUHM=; b=Z4ZUTp1QQM5dMhwuPtw/aO8xoftF0aXSMwYwxSmBaiK/Ay5JRIvLu+HnfmgJCI08uH 0Nu4IL8PJc4V52pGjh8Lcv4sgbA3A/Ti51CalbwFaI/7rzzLTwL8iKCVPKTyTRFM1zfS SuTXSaO2X7qxgR+EqySJTRlKl/VmoNiV66BLGxXyujQ/7fy8tHEeG+CABZIgxW5pLJbB Pzq+F9anwh5Q8027cr7uflENbg41rDLpwf82u7YeqMIIEPF7Vh7qzeWTOQZdS/BELM/e 5e4Y+t94p/OsZiiMLfSeQnfsNnSigqnY1GlqvG6uhSU5i2BF07yJEBPnDYAMzscO60TV Yc6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bTi+b1Hh8BVmXffVoJ8Rbls2h1QCq1CNvEVDEX0IUHM=; b=fAyYjjA5M3buKgmKHMvTJzZo38TtR4wDgkMW0kVWd2flwH3ghc4zS/lT6+anUfPsv3 zNy1vWfDIizLZF6PwvMpar9EQsHRx62v9GBPAeWlAhjpyxuytMtMMF3xu0ao/hoEzY1B 5s2vqUgujXraWceBR9IrYSKoMtGFioBm1FZAPZ+8NykvLkC+feXRNknui6HM+mopVJfn b/9OvzAdFS/ggl8oxX7KvBdAtd2Yl0h5Bzk4nBMGyEGoanVq5y3hF2ZshYUAziQX3slk nrQapUX+M2ZnK0J5FAeUnDxXmnPHLZZhctZmKyKgunLJbhyn86Son959c6jcWEIdo7Z2 8Gyw== X-Gm-Message-State: AMCzsaVWLLSG2XSsn7nmVnDacEvtbdEPoF7Hxt7gEVdj8jTfREDhVwVI Epwl40Eh+RAPut5dTjAMG957BiqF X-Google-Smtp-Source: ABhQp+S7QTHHBmd/Vnv+L72BGF5EgTybYT3KMJs8zWTgA12ehITu3gHsV0VaOeMlDEYE1ol/Vrp1WA== X-Received: by 10.200.54.220 with SMTP id b28mr16076153qtc.186.1508700293984; Sun, 22 Oct 2017 12:24:53 -0700 (PDT) Received: from ?IPv6:2600:380:bd1d:d4a6:b94a:696e:35cb:921f? ([2600:380:bd1d:d4a6:b94a:696e:35cb:921f]) by smtp.gmail.com with ESMTPSA id k79sm3617549qke.28.2017.10.22.12.24.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 12:24:53 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-31AFBA81-6914-495B-8963-83B35F0C1692 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> Date: Sun, 22 Oct 2017 15:24:52 -0400 Cc: Russ Housley , IETF TLS Content-Transfer-Encoding: 7bit Message-Id: <86A43E91-7393-4891-9E5D-9DD385119E64@gmail.com> References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> To: Ted Lemon Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 19:24:57 -0000 --Apple-Mail-31AFBA81-6914-495B-8963-83B35F0C1692 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Oct 22, 2017, at 2:40 PM, Ted Lemon wrote: >=20 >> On Oct 22, 2017, at 1:54 PM, Russ Housley wrote: >> No one is requiring TLS 1.3 that I know about. However, there are places= that require visibility into TLS. I will let one of the people that works i= n a regulated industry offer pointers to the documents. >=20 > What they require is visibility into contents of the flow that they are us= ing encryption to protect. Right now, the protocol they are using is TLS 1= .1 or TLS 1.2. The right thing for them to do if they continue to need thi= s visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE,= or some protocol that is designed for this use case, not to take a protocol= designed specifically for securing flows from on-path eavesdropping and cre= ate a mode where it is easier to wiretap. >=20 > There is no reason other than momentum for them to switch to TLS 1.3 when i= t doesn't address their use case. With no hat, I agree. https://www.rsa.com/en-us/blog/2017-08/tls-security-and-data-center-monitori= ng-searching-for-a-path-forward Kathleen=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-31AFBA81-6914-495B-8963-83B35F0C1692 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Oct 22, 2017, at 2:40 PM, Ted Lemon <mellon@fugue.com> wrote:

On Oct 22, 2017, at 1:54 PM, Russ Housley <housley@vigilsec.com> wrote:
No o= ne is requiring TLS 1.3 that I know about.  However, there are places t= hat require visibility into TLS.  I will let one of the people that wor= ks in a regulated industry offer pointers to the documents.

What they require is visibility into contents of the flow that they a= re using encryption to protect.   Right now, the protocol they are usin= g is TLS 1.1 or TLS 1.2.   The right thing for them to do if they conti= nue to need this visibility and are no longer permitted to use TLS 1.2 is to= use IPsec+IKE, or some protocol that is designed for this use case, not to t= ake a protocol designed specifically for securing flows from on-path eavesdr= opping and create a mode where it is easier to wiretap.

There is no reason other than momentum= for them to switch to TLS 1.3 when it doesn't address their use case.
=

With no hat, I agree.
Kathleen 


_______________________________________________
TLS mailing list
TLS@ietf.= org
https://www.ietf.org/mailman/listinfo/tls
= --Apple-Mail-31AFBA81-6914-495B-8963-83B35F0C1692-- From nobody Sun Oct 22 12:38:12 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B397F13AC06 for ; Sun, 22 Oct 2017 12:38:11 -0700 (PDT) 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 XJZ5WYsLy_4B for ; Sun, 22 Oct 2017 12:38:09 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 79E7813AC09 for ; Sun, 22 Oct 2017 12:38:09 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id n61so23829630qte.10 for ; Sun, 22 Oct 2017 12:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YBkID9qE1FZgDnezjWSgfsZNTk8NRDbnZ+L0vh8Bzdg=; b=lGuep+YyYBLFbTzZyAFZTd8aJ+qst6+1qVTj4NtZPK/XKTkRWsJxXPzkpkV63xFjIJ 42rI+2663ftHEi+ygYEk0GsfyrUHNa+v4jywgTJDBkI4mafUxbpj4OoqIPOo2vJTU/Ot tC5lkD5ObRv6G18/EJcSXwcfgZRnDFJ23nh+nX3cxFRY079Wxc0Fk0g+kel6epPMZecF 807uv1YRRUObwIURAovEN97X6k+zq9wXH69JLoG4GcfHhdPzVnlmVLBt0WEq5pA4WRqX RToA9C7Qhxc0ftUzzSwLXJAS6EfFupJc+C8nZWGtPxGkY1KMWOq5W3Pg0oYhgNEdlS0N 8mtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YBkID9qE1FZgDnezjWSgfsZNTk8NRDbnZ+L0vh8Bzdg=; b=Jwzc/+xt8xLn/NaR5b7MpycQKcOZZcg9NhwzfhyPPf1kuS7jk67te4TSApuA7yKBWS j+SiWtPP5PiX2rRPKyiKcOkmxx84TQNDUQC4GTHAa46OuNPQDkT/MrJqs0dR+TkcnMtx woF094+rncpPZQ+0Y8pnF2+A4r5xXEunSXLGC87LbwXwfOp2dM24WF6Zwlrw35tB5NcQ ZwZQq8rXg47CkpEL9F4tTuArpMV8n+CVu7D/M4X7zKI4olomE4h+ZzenXnt+fCTanf1X crYjOQxeSMwL4wtcwq9XkmZL40iB7f1nC4RZhs0BXhrnaw+87YvsKpTpxZ0qvY1UaUAi cduA== X-Gm-Message-State: AMCzsaUPt1yWkhiO7EJtOdvZjrSAdJoUGZ+zrF4AGweZGhTpEGXdRAVB lWTa+Amrsv3lpSP6obi2g/c= X-Google-Smtp-Source: ABhQp+SxLI2iQ5ApGcnIP0ElyYHsQdQm4fcijLjGnHpqQg+ZwfzV6/ZyVMfvO3itS0H+p2nXFmRIKA== X-Received: by 10.200.35.173 with SMTP id q42mr16596823qtq.199.1508701088681; Sun, 22 Oct 2017 12:38:08 -0700 (PDT) Received: from ?IPv6:2600:380:bd1d:d4a6:b94a:696e:35cb:921f? ([2600:380:bd1d:d4a6:b94a:696e:35cb:921f]) by smtp.gmail.com with ESMTPSA id i27sm3861541qtc.91.2017.10.22.12.38.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 12:38:08 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-7BBC16B9-A403-4411-833F-C4708989D4E5 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <86A43E91-7393-4891-9E5D-9DD385119E64@gmail.com> Date: Sun, 22 Oct 2017 15:38:07 -0400 Cc: Russ Housley , IETF TLS Content-Transfer-Encoding: 7bit Message-Id: <57740E2D-0E53-4586-A5E3-F3E6B7DCA87E@gmail.com> References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> <86A43E91-7393-4891-9E5D-9DD385119E64@gmail.com> To: Ted Lemon Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 19:38:12 -0000 --Apple-Mail-7BBC16B9-A403-4411-833F-C4708989D4E5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Oct 22, 2017, at 3:24 PM, Kathleen Moriarty wrote: >=20 >=20 >=20 > Sent from my iPhone >=20 >> On Oct 22, 2017, at 2:40 PM, Ted Lemon wrote: >>=20 >>> On Oct 22, 2017, at 1:54 PM, Russ Housley wrote: >>> No one is requiring TLS 1.3 that I know about. However, there are place= s that require visibility into TLS. I will let one of the people that works= in a regulated industry offer pointers to the documents. >>=20 >> What they require is visibility into contents of the flow that they are u= sing encryption to protect. Right now, the protocol they are using is TLS 1= .1 or TLS 1.2. The right thing for them to do if they continue to need thi= s visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE,= or some protocol that is designed for this use case, not to take a protocol= designed specifically for securing flows from on-path eavesdropping and cre= ate a mode where it is easier to wiretap. >>=20 >> There is no reason other than momentum for them to switch to TLS 1.3 when= it doesn't address their use case. >=20 > With no hat, I agree. > https://www.rsa.com/en-us/blog/2017-08/tls-security-and-data-center-monito= ring-searching-for-a-path-forward >=20 I should note that I have not read the new draft yet. These threads keep me= busy. > Kathleen=20 >=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-7BBC16B9-A403-4411-833F-C4708989D4E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Oct 22, 2017, at 3:24 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrot= e:



Sent from my iPhone=

On Oct 22, 2017, at 2:40 PM, Ted Lemon <mellon@fugue.com> wrote:

On Oct 22, 2017, at 1:54 PM, Russ Housley <housley@vigilsec.com> wrote:
No one is requiring TLS 1.3 that I know about.  However, there a= re places that require visibility into TLS.  I will let one of the peop= le that works in a regulated industry offer pointers to the documents.

What they require is visibility into contents of the flow= that they are using encryption to protect.   Right now, the protocol t= hey are using is TLS 1.1 or TLS 1.2.   The right thing for them to do i= f they continue to need this visibility and are no longer permitted to use T= LS 1.2 is to use IPsec+IKE, or some protocol that is designed for this use c= ase, not to take a protocol designed specifically for securing flows from on= -path eavesdropping and create a mode where it is easier to wiretap.

There is no reason other t= han momentum for them to switch to TLS 1.3 when it doesn't address their use= case.

With no hat, I agree.

I should note that I h= ave not read the new draft yet.  These threads keep me busy.
Kathleen 


_______________________________________________=
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
= --Apple-Mail-7BBC16B9-A403-4411-833F-C4708989D4E5-- From nobody Sun Oct 22 13:48:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE56C13B26B for ; Sun, 22 Oct 2017 13:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 3JKLUklXefNe for ; Sun, 22 Oct 2017 13:48:37 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 3F38B13B26E for ; Sun, 22 Oct 2017 13:48:37 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id y15so3787350ita.4 for ; Sun, 22 Oct 2017 13:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=MwCxQQjkY7ubedg20sGaBmcqnY5g5Z4CsA6DGxO5Dfk=; b=A2uiJka2VFZ4k0PXH0stXsRiNYkxJqHnQy6OMrYndJlfy37J0tk0f7unSkqI/W04jP /qFlSxNKaa3COGSGUpCPMjIJZeNQip4i/MaVqNvLizDa0zSoO0b7UIfAmuQzVyt04zsn Tga06o0bU9zq9Z59VOs7xy4JpoAyH/qPWBscvRzTAc6J4uYgKerpL0kEAGBpWuk3yO3F OI6XjKrAlkmuS+X8mBggTwdyU5l1PDMh+5FK1vIstySUGqd+Oixe5yFSvRHd9Erm/fBe ynRchCli111sUxHGPqECLk5v1Z4CirGTR97BkVUQCkH9GwGZsCXATZRq4e3lIjnpPVAa 4/dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=MwCxQQjkY7ubedg20sGaBmcqnY5g5Z4CsA6DGxO5Dfk=; b=or6Agygytw6xurU0YUqTg84oYJC5qM5hlbYVfnGTVJ6kbOTmlrTg5G5vWvtsyKyU53 7BKj8EKSEurNyfFjlk7DBz+8Kd2UTxjt1EpQSWK03zouIW0E26JoTuT/blGFfDGxmnH8 2mBF2+siYsiy2VhvzDZqA9BPeRrh4aOSdV9EXvXyP3uR7VfI06sqmp3FXbFs9GLtq2V0 2TtWRJnjLv3546XdhG1ZOmz98B0u22oFq273Bk1GgweymCnxd3+Ar79qaijzq0lu+E9J 46Mmb2R2YARr48zLTa6Pfmbh2UHpaI6AjsVti+XzSsLamvzKRLiUufXVj3BPT8Kxeoca ED7g== X-Gm-Message-State: AMCzsaWVvTmcKXWUUlweMdBah+IDP9svdq9Whoy5W/YAqiKVKVdt7qTE fBtsNaddW5WLj/fIUUMPqbw= X-Google-Smtp-Source: ABhQp+ScbGz/R2WgeULNNRC36FGz42W5eEjKHTVh+bv6RTs8MCD7zR9La95ltpVGL0qa+TPaUxI9Ug== X-Received: by 10.36.252.68 with SMTP id b65mr6515303ith.151.1508705316570; Sun, 22 Oct 2017 13:48:36 -0700 (PDT) Received: from [100.108.225.203] (67.sub-174-219-17.myvzw.com. [174.219.17.67]) by smtp.gmail.com with ESMTPSA id n4sm2540329ioe.71.2017.10.22.13.48.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Oct 2017 13:48:35 -0700 (PDT) References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> In-Reply-To: <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> Cc: "Ackermann, Michael" , Stephen Farrell , Darin Pettis , "tls@ietf.org" X-Mailer: iPad Mail (11D201) From: Steve Fenter Date: Sun, 22 Oct 2017 15:48:36 -0500 To: "Salz, Rich" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 20:48:39 -0000 The main problem with not addressing the TLS visibility issue now is that no= one knows when a vulnerability will be discovered in TLS 1.2 that forces en= terprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the R= SA key exchange are going to be fine for 5 to 10 years, but nobody knows tha= t, particularly in today's security environment. I've also learned that gett= ing a solution in place through the IETF is a multi-year process, and then v= endor adoption time has to be added on top of that. Enterprises don't want t= o be caught in a position where a vulnerability is forcing us to upgrade, an= d we are starting at ground zero on a multi-year process to restore TLS visi= bility. We have to get out in front of this problem so we're not caught unpr= epared. Sent from my iPad > On Oct 20, 2017, at 11:57 AM, "Salz, Rich" wrote: >=20 >=20 >=20 > So it sounds like we are in agreement that continuing to use TLS 1.2 is= not a viable long term alternative. =20 >=20 >=20 > Long-term is a subjective term, and using it can lead to misunderstandings= . >=20 > Based on current and previous actions around SSL and TLS versions, you can= use TLS 1.2 for at least five, likely at least 10, years. >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Oct 22 14:15:50 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DE913B56F for ; Sun, 22 Oct 2017 14:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 zQjIOkCdOTSu for ; Sun, 22 Oct 2017 14:15:47 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 348A813B56E for ; Sun, 22 Oct 2017 14:15:46 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v9MLFjXR028516; Sun, 22 Oct 2017 17:15:45 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Steve Fenter CC: "Salz, Rich" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO713gKFaj/ze3UaJfDxWNuaqP6LqPDwAgAFTKoCAAAWQgIAAANiAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAACX8gIAABAIAgAAHdgCAAASKgIADZUkAgAAHkgA= Date: Sun, 22 Oct 2017 21:15:43 +0000 Message-ID: <159BA7CB-06B7-4632-90C8-814492067219@ll.mit.edu> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> In-Reply-To: <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-5520275E-E01E-4178-9920-492BDD3349F9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-22_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710220309 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 21:15:49 -0000 --Apple-Mail-5520275E-E01E-4178-9920-492BDD3349F9 Content-Type: multipart/alternative; boundary=Apple-Mail-B2AC7A60-514F-42A6-B8B5-2BE1857DEB93 Content-Transfer-Encoding: 7bit --Apple-Mail-B2AC7A60-514F-42A6-B8B5-2BE1857DEB93 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable First they have to go through this vulnerability search dance with TLS-1.1 a= nd achieve a reasonably complete move to TLS-1.2. Regards, Uri Sent from my iPhone > On Oct 22, 2017, at 16:49, Steve Fenter wrote:= >=20 > The main problem with not addressing the TLS visibility issue now is that n= o one knows when a vulnerability will be discovered in TLS 1.2 that forces e= nterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the R= SA key exchange are going to be fine for 5 to 10 years, but nobody knows tha= t, particularly in today's security environment. I've also learned that gett= ing a solution in place through the IETF is a multi-year process, and then v= endor adoption time has to be added on top of that. Enterprises don't want t= o be caught in a position where a vulnerability is forcing us to upgrade, an= d we are starting at ground zero on a multi-year process to restore TLS visi= bility. We have to get out in front of this problem so we're not caught unpr= epared. >=20 > Sent from my iPad >=20 >> On Oct 20, 2017, at 11:57 AM, "Salz, Rich" wrote: >>=20 >>=20 >>=20 >> So it sounds like we are in agreement that continuing to use TLS 1.2 is= not a viable long term alternative. =20 >>=20 >>=20 >> Long-term is a subjective term, and using it can lead to misunderstanding= s. >>=20 >> Based on current and previous actions around SSL and TLS versions, you ca= n use TLS 1.2 for at least five, likely at least 10, years. >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-B2AC7A60-514F-42A6-B8B5-2BE1857DEB93 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkZpcnN0IHRoZXkg aGF2ZSB0byBnbyB0aHJvdWdoIHRoaXMgdnVsbmVyYWJpbGl0eSBzZWFyY2ggZGFuY2Ugd2l0aCBU TFMtMS4xIGFuZCBhY2hpZXZlIGEgcmVhc29uYWJseSBjb21wbGV0ZSBtb3ZlIHRvIFRMUy0xLjIu PGJyPjxicj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlJlZ2FyZHMsPGRpdj5Vcmk8L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48L2Rpdj48ZGl2 Pjxicj5PbiBPY3QgMjIsIDIwMTcsIGF0IDE2OjQ5LCBTdGV2ZSBGZW50ZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpzdGV2ZW4uZmVudGVyNThAZ21haWwuY29tIj5zdGV2ZW4uZmVudGVyNThAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 ZGl2PjxzcGFuPlRoZSBtYWluIHByb2JsZW0gd2l0aCBub3QgYWRkcmVzc2luZyB0aGUgVExTIHZp c2liaWxpdHkgaXNzdWUgbm93IGlzIHRoYXQgbm8gb25lIGtub3dzIHdoZW4gYSB2dWxuZXJhYmls aXR5IHdpbGwgYmUgZGlzY292ZXJlZCBpbiBUTFMgMS4yIHRoYXQgZm9yY2VzIGVudGVycHJpc2Vz IHRvIHVwZ3JhZGUgdG8gVExTIDEuMy4gV2UndmUgaGFkIGd1YXJhbnRlZXMgdGhhdCBUTFMgMS4y IGFuZCB0aGUgUlNBIGtleSBleGNoYW5nZSBhcmUgZ29pbmcgdG8gYmUgZmluZSBmb3IgNSB0byAx MCB5ZWFycywgYnV0IG5vYm9keSBrbm93cyB0aGF0LCBwYXJ0aWN1bGFybHkgaW4gdG9kYXkncyBz ZWN1cml0eSBlbnZpcm9ubWVudC4gSSd2ZSBhbHNvIGxlYXJuZWQgdGhhdCBnZXR0aW5nIGEgc29s dXRpb24gaW4gcGxhY2UgdGhyb3VnaCB0aGUgSUVURiBpcyBhIG11bHRpLXllYXIgcHJvY2Vzcywg YW5kIHRoZW4gdmVuZG9yIGFkb3B0aW9uIHRpbWUgaGFzIHRvIGJlIGFkZGVkIG9uIHRvcCBvZiB0 aGF0LiAmbmJzcDtFbnRlcnByaXNlcyBkb24ndCB3YW50IHRvIGJlIGNhdWdodCBpbiBhIHBvc2l0 aW9uIHdoZXJlIGEgdnVsbmVyYWJpbGl0eSBpcyBmb3JjaW5nIHVzIHRvIHVwZ3JhZGUsIGFuZCB3 ZSBhcmUgc3RhcnRpbmcgYXQgZ3JvdW5kIHplcm8gb24gYSBtdWx0aS15ZWFyIHByb2Nlc3MgdG8g cmVzdG9yZSBUTFMgdmlzaWJpbGl0eS4gV2UgaGF2ZSB0byBnZXQgb3V0IGluIGZyb250IG9mIHRo aXMgcHJvYmxlbSBzbyB3ZSdyZSBub3QgY2F1Z2h0IHVucHJlcGFyZWQuPC9zcGFuPjxicj48c3Bh bj48L3NwYW4+PGJyPjxzcGFuPlNlbnQgZnJvbSBteSBpUGFkPC9zcGFuPjxicj48c3Bhbj48L3Nw YW4+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPk9uIE9jdCAyMCwgMjAxNywgYXQg MTE6NTcgQU0sICJTYWx6LCBSaWNoIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1haS5j b20iPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJyPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7U28gaXQgc291bmRzIGxpa2Ugd2Ug YXJlIGluIGFncmVlbWVudCB0aGF0IGNvbnRpbnVpbmcgdG8gdXNlIFRMUyAxLjIgaXMgbm90IGEg dmlhYmxlIGxvbmcgdGVybSAmbmJzcDthbHRlcm5hdGl2ZS4gJm5ic3A7PC9zcGFuPjxicj48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+TG9uZy10ZXJtIGlzIGEgc3ViamVjdGl2 ZSB0ZXJtLCBhbmQgdXNpbmcgaXQgY2FuIGxlYWQgdG8gbWlzdW5kZXJzdGFuZGluZ3MuPC9zcGFu Pjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxi cj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+QmFzZWQgb24gY3Vy cmVudCBhbmQgcHJldmlvdXMgYWN0aW9ucyBhcm91bmQgU1NMIGFuZCBUTFMgdmVyc2lvbnMsIHlv dSBjYW4gdXNlIFRMUyAxLjIgZm9yIGF0IGxlYXN0IGZpdmUsIGxpa2VseSBhdCBsZWFzdCAxMCwg eWVhcnMuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9z cGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UTFMgbWFpbGluZyBsaXN0PC9z cGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEgaHJl Zj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RsczwvYT48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48c3Bhbj48L3NwYW4+ PGJyPjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PC9zcGFuPjxicj48c3Bhbj5UTFMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVm PSJtYWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PC9zcGFuPjxicj48L2Rpdj48 L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-B2AC7A60-514F-42A6-B8B5-2BE1857DEB93-- --Apple-Mail-5520275E-E01E-4178-9920-492BDD3349F9 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcxMDIyMjExNTQyWjAjBgkqhkiG9w0BCQQxFgQU20zuD2lfrDT44nrQImmVJdYm4xkwbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBAEfnBa1iVPvcE9Oal2Gpk2aYhZNBED5u8gMv8/OLy2Dji3YOCrsLk0Yhu2+PtqNf 6qaegeLtyDF4gHd9CmFtleNFj9bBM2pvBhQGy/cttTFvwxCAE/tlWyC/TuwYwCoEN6MQx3jFpF9Z DCmIbBPT2jsDWN6BduMuYSKuHZEbygYNM1xzKzZBK7Z7NXwsaigosf0PF/UnsY+n/QcjQ51aSFFc GUy5+Ed10IYhiVHYHA9kbfxev8rdUpDWh3ruFD5byIF5wIZEdTkHFLXT7/aHB3DLwqOjDnC01YiA I5/aZu40dS9TbA8kX0YX6zdAeNoOiUU6TqRiyC/NW/7Ljvi0DAIAAAAAAAA= --Apple-Mail-5520275E-E01E-4178-9920-492BDD3349F9-- From nobody Sun Oct 22 14:17:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55E813B57B for ; Sun, 22 Oct 2017 14:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbMD4Ibl6qBe for ; Sun, 22 Oct 2017 14:17:36 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA9513B57D for ; Sun, 22 Oct 2017 14:17:35 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id z19so23990462qtg.11 for ; Sun, 22 Oct 2017 14:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nE+4XFYkYsbjRQg3Fkb1OJ7ijuUAMhY8lCosI7NFiYw=; b=Przt+h7oKJDyhvxXTqmEhux5Nxat72sdLgzHyD7bsJq1ZhzsEEHp1+7YLZ/OZ6HajK jhxDBCLmgfccyYvRhaFHQ+/gROQ1MR5cqqG97FcItpk6yRKQRxXmhfFshDxGf3S4iwia vBCuApkWh8Z6K95lJeHDNV0uDW3rYgZTcoidx1yptfs+p48ovgnFvBBjA3Udkm9yx/9K 4eozKp5IWKnW27e9WhZr/rHkvgRObrXDjB6zP7+qXbYK1DpQwn6DI09cVCmJoBA1LMgp DT0FPX5d2HDk5faImQUOnfsQZSU0fxZMGQAc6PVSUi4D1/GnNxw/Xxo2g6zAifi2xyAy 5bEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nE+4XFYkYsbjRQg3Fkb1OJ7ijuUAMhY8lCosI7NFiYw=; b=jLQkIiY3mc/x8XokQcHa7xWWFoJHHDVaR4MnrOHAG17GZonm1BYH7179nV+a068McF nzbQk02e+ACBthiSCeIqlg2P3c9mKF4c94bdemddAJUD5wUxJcH1TPC9Von7MyJfVRpg RnbuHyUPCPgJoWccn3yzgDSUaQwyK4xr3X+PbCJRa7QlbdUe6BsB486fQoqueNg9q/l1 3+xFFqzpqTnI6AtBmOVeoBiLeIgOHtMkGqiL8TrFKL3JWAPLx0OfpjBQvGrczl5NiuuN ugELHJTTT7965urD8jYAR/usaEiy2FQtthEpkWm5eN380MwiHiPXtYlKdWZic6Ec7USc CTPQ== X-Gm-Message-State: AMCzsaVJZeXwGOxr7hPlkD0oCO0E0yI/zUtDf7GRbyxaKhNhSMAcGsST Vcdmk0QAT5HpWN6Yp1KFc//PCw== X-Google-Smtp-Source: ABhQp+Q+Vxx1mgy6PvQvpvA3W0JDxWak7iVmGX8W6yayREp3w6GbuLxATdHOQ3bgx8MWfI7dS4C8Lg== X-Received: by 10.200.48.37 with SMTP id f34mr17457340qte.228.1508707054576; Sun, 22 Oct 2017 14:17:34 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id q186sm3753427qkf.26.2017.10.22.14.17.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 14:17:33 -0700 (PDT) From: Ted Lemon Message-Id: <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FECC7280-73BA-4ABD-8F5D-EAA6586CE600" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 22 Oct 2017 17:17:31 -0400 In-Reply-To: <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> Cc: "Salz, Rich" , "tls@ietf.org" To: Steve Fenter References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 21:17:38 -0000 --Apple-Mail=_FECC7280-73BA-4ABD-8F5D-EAA6586CE600 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 22, 2017, at 4:48 PM, Steve Fenter = wrote: > The main problem with not addressing the TLS visibility issue now is = that no one knows when a vulnerability will be discovered in TLS 1.2 = that forces enterprises to upgrade to TLS 1.3. We've had guarantees that = TLS 1.2 and the RSA key exchange are going to be fine for 5 to 10 years, = but nobody knows that, particularly in today's security environment. Implicit in this assertion is the claim that these organizations could = switch quickly to TLS 1.3, but in fact we know that it's been very = difficult for them to make the switch from 1.1 to 1.2, and in many cases = they haven't done it. So this isn't really at all persuasive. But = even if it were persuasive, it still wouldn't be a good argument. TLS = is a complicated protocol that does far more than is required for the = use case we are talking about. It would be better to use a simpler = protocol with a smaller attack surface. So why not get started on that now, instead of trying to weaken TLS 1.3? --Apple-Mail=_FECC7280-73BA-4ABD-8F5D-EAA6586CE600 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 22, 2017, at 4:48 PM, Steve Fenter <steven.fenter58@gmail.com> wrote:
The main problem with not addressing the = TLS visibility issue now is that no one knows when a vulnerability will = be discovered in TLS 1.2 that forces enterprises to upgrade to TLS 1.3. = We've had guarantees that TLS 1.2 and the RSA key exchange are going to = be fine for 5 to 10 years, but nobody knows that, particularly in = today's security environment.

Implicit in this assertion is the claim that = these organizations could switch quickly to TLS 1.3, but in fact we know = that it's been very difficult for them to make the switch from 1.1 to = 1.2, and in many cases they haven't done it.   So this isn't really = at all persuasive.   But even if it were persuasive, it still = wouldn't be a good argument.  TLS is a complicated protocol that = does far more than is required for the use case we are talking about. =   It would be better to use a simpler protocol with a smaller = attack surface.

So why not get started on that now, instead of trying to = weaken TLS 1.3?

= --Apple-Mail=_FECC7280-73BA-4ABD-8F5D-EAA6586CE600-- From nobody Sun Oct 22 15:26:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8389813BB88 for ; Sun, 22 Oct 2017 15:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 7CoOtn50DUTf for ; Sun, 22 Oct 2017 15:26:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12D513BB85 for ; Sun, 22 Oct 2017 15:26:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61946BE4D; Sun, 22 Oct 2017 23:26:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQqexPAU3Inj; Sun, 22 Oct 2017 23:26:33 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1C7EDBE49; Sun, 22 Oct 2017 23:26:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508711193; bh=TqHApQkYDM4CtSV2vqXTwrEUbBCHsjbVVZIREVwxagw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=u9YZ6SpgL6hGavt4sLeMX+y4diFKJxMbV9XUvbbFwl6vPoXwDjwBrf68UjAK2BTsT ibyVyF6xgAEk+GhlLhQJIT+dggG74S+oS/covgUK0+hRF2O9NT9FGZf7iIQ/+n50R5 Q7KoyGUftjxG6O+mFKDbbBo9bOQ4ifaRkWrAwzBY= To: Steve Fenter , "Salz, Rich" Cc: "Ackermann, Michael" , Darin Pettis , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 22 Oct 2017 23:26:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nUxaQPSXAX9o3TEh2XuFUV51LI9f9VOcn" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 22:26:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nUxaQPSXAX9o3TEh2XuFUV51LI9f9VOcn Content-Type: multipart/mixed; boundary="FxUn0x8OQNNseXkvMwej6iUmfD7lpb1qL"; protected-headers="v1" From: Stephen Farrell To: Steve Fenter , "Salz, Rich" Cc: "Ackermann, Michael" , Darin Pettis , "tls@ietf.org" Message-ID: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> In-Reply-To: <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> --FxUn0x8OQNNseXkvMwej6iUmfD7lpb1qL Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 22/10/17 21:48, Steve Fenter wrote: > The main problem with not addressing the TLS visibility issue now is > that no one knows when a vulnerability will be discovered in TLS 1.2 > that forces enterprises to upgrade to TLS 1.3. We've had guarantees > that TLS 1.2 and the RSA key exchange are going to be fine for 5 to > 10 years, but nobody knows that, particularly in today's security > environment. I've also learned that getting a solution in place > through the IETF is a multi-year process, and then vendor adoption > time has to be added on top of that. Enterprises don't want to be > caught in a position where a vulnerability is forcing us to upgrade, > and we are starting at ground zero on a multi-year process to restore > TLS visibility. We have to get out in front of this problem so we're > not caught unprepared. Wait. What? One of your arguments for needing snooping is that you claim a lack of competence in debugging applications that use TLS. So to solve that, you propose we introduce a rarely used, sporadically supported method of leaking keys to third parties. IOW, you add what's called a vulnerability and do so in a complex manner in code paths that'll hardly ever be used (according to the proponents, they'll only be used in the "proper" places, or at least, none of you have so far ever acknowledged the falsity of that "proper" places magical thinking). Rarely used complex code for leaking keys... hmm, now what is that likely to lead to? Oh yes, bugs. But now you claim that a well tested protocol with fairly mature implementations (TLS1.2) might have bugs that cause you to need to add your additional complex key-leaking vulnerability feature which'll magically have no bugs? I think you can fairly claim a worst argument of the year prize for that one;-) S. PS: Your claim about "guarantees" is just false afaics. I saw no such thing on the list. Please desist from inventing statements that were not made, or point me at where someone said something that is even remotely possible to confuse with such a guarantee. (Combining risible argument and false claims really isn't wise.) >=20 > Sent from my iPad >=20 >> On Oct 20, 2017, at 11:57 AM, "Salz, Rich" >> wrote: >>=20 >>=20 >>=20 >> So it sounds like we are in agreement that continuing to use TLS >> 1.2 is not a viable long term alternative. >>=20 >>=20 >> Long-term is a subjective term, and using it can lead to >> misunderstandings. >>=20 >> Based on current and previous actions around SSL and TLS versions, >> you can use TLS 1.2 for at least five, likely at least 10, years. >>=20 >>=20 >>=20 >> _______________________________________________ TLS mailing list=20 >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --FxUn0x8OQNNseXkvMwej6iUmfD7lpb1qL-- --nUxaQPSXAX9o3TEh2XuFUV51LI9f9VOcn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ7RsYAAoJEC88hzaAX42iCJAH/3QT/x0j9B+Q/9ma54nZ0TVd ItuIgNuNX/flx0KuYJ4q/5+PDxEwgtdLpYUI0DIjjgjyRCXQcOwGRYfEuBeprjMU mLmahw1sy1jIIJgcnBAFFo81YXSHAJhVTtzQjeGqus2YKXbBHk2NttGaAaTKovHR 8RNQBxuGjx6tY2YY6237Uft0QBvN9TuPKcCZcbwnTSKzOt4eofnIYD8L0gJLUzN6 UYiN44S095IUXoBd2RXOoC2+vOfIZK0g2lObSy8DnIP7tmYBX0/lH2rAi1akBOZy hbJGg420AduRRCbmesTMwyCsXPtAy1Zq3ZevQY+VTjKv9pAb78UEiokyIYS/t54= =u4IG -----END PGP SIGNATURE----- --nUxaQPSXAX9o3TEh2XuFUV51LI9f9VOcn-- From nobody Sun Oct 22 16:17:02 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C89513BEA4 for ; Sun, 22 Oct 2017 16:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 lVcgHpggl7Ei for ; Sun, 22 Oct 2017 16:16:57 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 4D35A13BEA1 for ; Sun, 22 Oct 2017 16:16:56 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 55A8F1C060B for ; Sun, 22 Oct 2017 18:16:56 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 7B4441C0605; Sun, 22 Oct 2017 18:16:55 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 41D6E92057; Sun, 22 Oct 2017 19:16:55 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E70C592053; Sun, 22 Oct 2017 19:16:54 -0400 (EDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (unknown [207.46.163.82]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Sun, 22 Oct 2017 19:16:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mQyTpjuhEBYdnzHtBBluA4P2ZaWUeBdNN5UhLt8iwYI=; b=nd9zQHd/wjuA9BrL2mAGhJJkIpSUkEbXyS+kDUo3Ug/FBZgVzhhTzvHf7D/9krzfxzEEaUfljUmbLSSnze+WtYPxWblIU9p24G8kwJRG1ST6bX0UhqoSpwFUmZSADqMNGsifuepre5cEBFKsO7fzLw9RQmc8+nK2wZaIsgQSs08= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sun, 22 Oct 2017 23:16:53 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Sun, 22 Oct 2017 23:16:52 +0000 From: "Ackermann, Michael" To: Ted Lemon , Steve Fenter CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIADZUkAgAAIFICAAB86QA== Date: Sun, 22 Oct 2017 23:16:52 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> In-Reply-To: <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.54] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 20:hzNawdUCIVwL45rJcFWMziX64i3YdKQjyXHOGTIAOXU47s8M/xdlyzipqycsfGk2mlAQ+4bl3KCASFZdnQjfOpRc6TX+U4/0LxjpmabD6IXg+ykStYs7sXHe1uhk13LAW7DosDUSmG01GEUvFq/JzohcNdxmTlcCDe4sdQsDt6I= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 63cd1b5f-be6d-42e0-0ec7-08d519a2fb06 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1368; x-ms-traffictypediagnostic: CY4PR14MB1368: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1368; x-forefront-prvs: 0468FE4A2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400002)(346002)(376002)(24454002)(189002)(199003)(790700001)(81166006)(80792005)(5660300001)(8936002)(110136005)(81156014)(14454004)(6246003)(3846002)(99286003)(236005)(316002)(102836003)(68736007)(6436002)(8676002)(66066001)(25786009)(55016002)(6116002)(54356999)(7736002)(7696004)(3280700002)(2906002)(101416001)(53936002)(86362001)(53546010)(74316002)(97736004)(50986999)(6506006)(230783001)(39060400002)(106356001)(54896002)(9686003)(105586002)(2950100002)(2900100001)(189998001)(93886005)(19609705001)(76176999)(4326008)(33656002)(72206003)(229853002)(478600001)(77096006)(6306002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB136816569A2AE2A9760C6E08D7410CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2017 23:16:52.8574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 85ec0586-31ab-47d0-b88d-a1b0b5ebbd6f X-VPM-MSG-ID: 594036f7-23e5-42d7-ac89-42e4f3996b33 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:17:01 -0000 --_000_CY4PR14MB136816569A2AE2A9760C6E08D7410CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am willing to bet that his point was not at all that Enterprises could = switch quickly, as you say in your response. We do not do ANYTHING quickly. I believe his point was that because we do not move quickly, we need to = prepare as much in advance as possible, and assure that the base protocols = we know we will be using in the future, do not put us in the position of = having to do things that are generally not possible, such as make = significant application or protocol changes. And out of curiosity, what is the simpler protocol you are recommending? = I say out of curiosity because switching to a whole different protocol = is not likely to be feasible from any perspective for large enterprises = and the complex, multi-tier protocols that are prevalent. From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Ted Lemon Sent: Sunday, October 22, 2017 5:18 PM To: Steve Fenter Cc: tls=40ietf.org Subject: Re: =5BTLS=5D Publication of draft-rhrd-tls-tls13-visibility-00 On Oct 22, 2017, at 4:48 PM, Steve Fenter = > wrote: The main problem with not addressing the TLS visibility issue now is that = no one knows when a vulnerability will be discovered in TLS 1.2 that = forces enterprises to upgrade to TLS 1.3. We've had guarantees that TLS = 1.2 and the RSA key exchange are going to be fine for 5 to 10 years, but = nobody knows that, particularly in today's security environment. Implicit in this assertion is the claim that these organizations could = switch quickly to TLS 1.3, but in fact we know that it's been very = difficult for them to make the switch from 1.1 to 1.2, and in many cases = they haven't done it. So this isn't really at all persuasive. But even = if it were persuasive, it still wouldn't be a good argument. TLS is a = complicated protocol that does far more than is required for the use case = we are talking about. It would be better to use a simpler protocol with = a smaller attack surface. So why not get started on that now, instead of trying to weaken TLS 1.3? The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB136816569A2AE2A9760C6E08D7410CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

I am willing to bet that his point was not at = all that Enterprises could switch quickly,  as you say in your = response. 

We do not do ANYTHING quickly.  =

 

I believe his point was that because we do not = move quickly,  we need to prepare as much in advance as possible, and = assure that the base protocols we know we will be using in the = future,  do not put us in the position of having to do things that are generally not possible,  such as make significant = application or protocol changes. 

 

And out of curiosity,  what is the simpler = protocol you are recommending?    I say out of curiosity = because switching to a whole different protocol is not likely to be = feasible from any perspective for large enterprises and the complex, multi-tier protocols that are prevalent. 

 

From: TLS = =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Ted Lemon
Sent: Sunday, October 22, 2017 5:18 PM
To: Steve Fenter <steven.fenter58=40gmail.com>
Cc: tls=40ietf.org
Subject: Re: =5BTLS=5D Publication of = draft-rhrd-tls-tls13-visibility-00

 

On Oct 22, 2017, at 4:48 PM, Steve Fenter = <steven.fenter58=40gmail.com= > wrote:

= The main problem with not addressing the TLS visibility issue now is that = no one knows when a vulnerability will be discovered in TLS 1.2 that = forces enterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the RSA key exchange = are going to be fine for 5 to 10 years, but nobody knows that, = particularly in today's security environment.

 

Implicit in this assertion is the claim that = these organizations could switch quickly to TLS 1.3, but in fact we know = that it's been very difficult for them to make the switch from 1.1 to 1.2, = and in many cases they haven't done it.   So this isn't really at all persuasive.   But even if it were = persuasive, it still wouldn't be a good argument.  TLS is a = complicated protocol that does far more than is required for the use case = we are talking about.   It would be better to use a simpler protocol with a smaller attack surface.

 

So why not get started on that now, instead of = trying to weaken TLS 1.3?

 


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB136816569A2AE2A9760C6E08D7410CY4PR14MB1368namp_-- From nobody Sun Oct 22 16:26:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4EC13BF50 for ; Sun, 22 Oct 2017 16:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJGiTX0VaynJ for ; Sun, 22 Oct 2017 16:26:38 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 B4D9A13BF4C for ; Sun, 22 Oct 2017 16:26:38 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 101so18343358ioj.3 for ; Sun, 22 Oct 2017 16:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=ZsAnmGqGTIHO5SuWruZf0HONWQZ0nkiswqPMts2OwTM=; b=WeN3xD4epFDAy7pRpjgR4gHgdoHTZF3xqWYLC7otAL+v6RQD5byozRsilpKs0o0BaB KokNUIqCc4+4vQlYULtWMKEAyGojtdFxr72l0kwgjD2qmF/ckpG3pKKzhpCFTFg62wMD EQg4rd441ZmTAAJWC/ftueJ1eq9JjCsPqxHZYOzU3BMNozv0M+mRO3CqI/U5rG2XkkGv yv6vEwoV3EwtOojCMFvAzk1PZjDX2DR8qYckewO2MkaX/0U+KYWlOF9VQnsnn14wpwY1 wm0+m4oADMPH0D9nh3+gln5oj20wcmYzOF859bo8Cb6axSlyq0pE4PGyKH+biDWPqFRN Lh5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=ZsAnmGqGTIHO5SuWruZf0HONWQZ0nkiswqPMts2OwTM=; b=cpHY2fJpqFWzcm2zngz82I3dKMxnKKouzF+JEJ01xmSzwxZ9UaVdthNbHv3Z8Euu7M 9OYRm+7tuoAyygq1ySCIPXbQl+aWYYHxW+dUTtm6x8aj8pj3nWiL+BO1uH0nfKYfYnwS pVCbvfYCXk5Dg9Yxn99Nc0xoK6Bw7kHV3olTMrxUmV28hGZs3z1XPH/aXZUv+XVY9Bht rMTASijTP65zHpSbcnOcWvBj9VkiHoMhRHxkPMzT3S+LjwbVP6+yUvWxArCyu5H0DJj6 tAPzLpQojdQJrTchPgX8JQdEWm83meDrGo3t05GA//fYy4OKthwux6wdhm32xYWy0s4d aQTA== X-Gm-Message-State: AMCzsaVnodHyJnBA/Ny9LYy5qxli7C4p/HWLXee95/gYMKLISEwrlb2+ /3VDhfARxRxLcO3oe8mkGZvtzQRB X-Google-Smtp-Source: ABhQp+TVWofAivaxiPvR7udcWKlxZ5bQWD3Z747wGcS+XqbEFNmIEL99ZUbiBFy4ynZiQNUXtPxrwQ== X-Received: by 10.107.148.194 with SMTP id w185mr16363608iod.259.1508714797929; Sun, 22 Oct 2017 16:26:37 -0700 (PDT) Received: from [100.108.225.203] (67.sub-174-219-17.myvzw.com. [174.219.17.67]) by smtp.gmail.com with ESMTPSA id k2sm2671706iok.43.2017.10.22.16.26.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Oct 2017 16:26:37 -0700 (PDT) References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <7ed40a30-196f-d280-59a5-814a5ea4676e@huitema.net> In-Reply-To: <7ed40a30-196f-d280-59a5-814a5ea4676e@huitema.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> Cc: Darin Pettis , Paul Turner , "Salz, Rich" , "tls@ietf.org" X-Mailer: iPad Mail (11D201) From: Steve Fenter Date: Sun, 22 Oct 2017 18:26:38 -0500 To: Christian Huitema Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:26:40 -0000 I know of a number of large enterprises in verticals including financial, he= alth care, retail, and government, across multiple countries, who are using p= acket payload inspection within their data centers. Most of these enterpris= es are reluctant to step forward in a public forum and reveal their internal= network structure and their internal security and monitoring practices. Thi= s gives the false impression that out of band decryption of TLS is not a big= deal. It is in fact mission critical to a significant number of large enter= prises. I have been saying to anyone who will listen that the IETF needs a private f= orum for enterprises, to enable them to come forward and discuss their real r= equirements. Without this input the IETF is trying to architect and engineer= solutions without knowing the complete set of requirements, at least on the= enterprise side. This results in sub-optimal design decisions (from an ent= erprise perspective), which in this case will break mission critical enterpr= ise monitoring and troubleshooting systems. We've already experienced what a rollout of TLS 1.3 will be like, at more th= an one enterprise, when certain vendors decided to move Diffie Hellman ciphe= rs to the top of their priority list on a code upgrade. This caused severity= one outages of critical monitoring systems. This means that critical appli= cations depend on these monitoring systems, and if the monitoring system is d= own the application is completely down. This is not the outcome we want when= TLS 1.3 is rolled out, but it is what we are headed for. Enterprise monitor= ing should be tested as part of the operational TLS 1.3 testing before TLS 1= .3 is approved as a standard, and TLS 1.3 should not be approved if enterpri= se monitoring breaks. The only other option being presented to enterprises is that we continue to r= un on a TLS spec that is nine years old, and then continue running it until i= t is 14 to 19 years old. It makes no sense to me to put out a TLS 1.3 standa= rd, but say that enterprises cannot upgrade to it. > On Oct 19, 2017, at 5:37 PM, Christian Huitema wrote= : >=20 >> On 10/19/2017 3:30 PM, Darin Pettis wrote: >>=20 >> The amount of people currently voicing concern is likely small for two >> reasons. One is that everything is public and many of the "lurkers" >> are hesitant to voice their concerns. The second reason is that so >> many don't know that visibility will be an issue. They will either >> discover this as they migrate to TLS 1.3 or as they start to encrypt >> within their data center. There is work to rapidly raise that >> awareness through roundtables, conferences and other venues. >=20 > Might it be because many of these enterprises and data centers do not in > fact see encryption as a problem? Maybe they have found ways to manage > their applications and servers without breaking TLS... >=20 > --=20 > Christian Huitema >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Oct 22 16:36:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6DB13C05C for ; Sun, 22 Oct 2017 16:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ba6AqT8rvhn for ; Sun, 22 Oct 2017 16:35:58 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8CF13C056 for ; Sun, 22 Oct 2017 16:35:57 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 1so24210068qtn.3 for ; Sun, 22 Oct 2017 16:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+3mGZv6bmpE2/zBhKl7umqX6xL56eGdl8z8/ByfAJFk=; b=DXtX109UtFumVNPP+mxP/Fzm3+p20BA3Cu7gevpTI+rHiNNUap1lf5+neDNzpbjwRg y+7Zyq9QZp+qmgWr60dymb3ozYS+OF187UXhXR67ud41sNWZidK4oglASyybCiSpvAKj Kp4WAyWrT/iyMRaTHuucImxp4BTms9n3GKUC2qEe+OHkseyv7QlN1VXOOw22/Bls/XpY vJGdhSKjKPG8UMO6bOsYuMCA+j/Rc7J1sN3zuFHFcQdmkK2ASNEL0LrdxjlqMyPUfgQi kKArNUUynF5GMZAda5sp1LNNsQq6BrQ5HcgiDFj6nXiD6db3oUhrp7ntKg2qhjOeFwec kbLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+3mGZv6bmpE2/zBhKl7umqX6xL56eGdl8z8/ByfAJFk=; b=LcQrFX//8MXLm2qD5PsfblXuwsN/wojSVh2pbQ8IsaY4mOw7E00DMFfGXfd+24ZfAX dFZlt2ggnZxl69C/jSxOhSGOM1DtfQpkuSrRdww4K7LLP8u4urLVY055tAJb+HV+nrIl Gs7TO3Uk11OCAuNtnaLykQxcDcgGItT3UV4RdQt6Fxh+zuoePHcEjLZbX/NlTBQKIvSs EeH6EGv3kxQ9kh6G+5Ps7H9ku4DhNvKLtUlNRTROfdgFICBW42k8GRHi9n8VZ77GU3kY gq3X4gHfaa7vsgqp7p+qrtnGUWTIELdD9uruEapKahhrpLhdxXmMu5HQHmBYB4PlLKCm 5k5g== X-Gm-Message-State: AMCzsaXUXYhMcZnSsRm2vzsoA+Da+iqj+E0hWHQ2TRhIffBdeuj143Gj vGsY78FO7EH9sEFuWO4dWQjG8A== X-Google-Smtp-Source: ABhQp+QrRhzhl5simyeuSn6hnYwA9hpKbukkILdrdtFhpVjXwNJeW9/Jv+7UTwv23BpD8N/PrP7bLA== X-Received: by 10.200.41.90 with SMTP id z26mr16180243qtz.47.1508715356872; Sun, 22 Oct 2017 16:35:56 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id j40sm4131430qtj.52.2017.10.22.16.35.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 16:35:56 -0700 (PDT) From: Ted Lemon Message-Id: <6125D547-7B3A-493E-B3C9-799CEE9E7CC5@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C77AA867-95AA-44F6-9644-558037077E0D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 22 Oct 2017 19:35:54 -0400 In-Reply-To: <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> Cc: Christian Huitema , Paul Turner , "tls@ietf.org" To: Steve Fenter References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <7ed40a30-196f-d280-59a5-814a5ea4676e@huitema.net> <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:36:00 -0000 --Apple-Mail=_C77AA867-95AA-44F6-9644-558037077E0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 22, 2017, at 7:26 PM, Steve Fenter = wrote: > I have been saying to anyone who will listen that the IETF needs a = private forum for enterprises, to enable them to come forward and = discuss their real requirements. Without this input the IETF is trying = to architect and engineer solutions without knowing the complete set of = requirements, at least on the enterprise side. This results in = sub-optimal design decisions (from an enterprise perspective), which in = this case will break mission critical enterprise monitoring and = troubleshooting systems. The reason we don't have that is that designing secure protocols in = secret isn't a trustworthy approach. Of course, you can always get = together privately. --Apple-Mail=_C77AA867-95AA-44F6-9644-558037077E0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 22, 2017, at 7:26 PM, Steve Fenter <steven.fenter58@gmail.com> wrote:
I have been saying to anyone who will = listen that the IETF needs a private forum for enterprises, to enable = them to come forward and discuss their real requirements. Without this = input the IETF is trying to architect and engineer solutions without = knowing the complete set of requirements, at least on the enterprise = side.  This results in sub-optimal design decisions (from an = enterprise perspective), which in this case will break mission critical = enterprise monitoring and troubleshooting = systems.

The= reason we don't have that is that designing secure protocols in secret = isn't a trustworthy approach.   Of course, you can always get = together privately.

= --Apple-Mail=_C77AA867-95AA-44F6-9644-558037077E0D-- From nobody Sun Oct 22 16:43:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D3913C0A7 for ; Sun, 22 Oct 2017 16:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCrYr32hzLo6 for ; Sun, 22 Oct 2017 16:43:54 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 9D8C813C0AF for ; Sun, 22 Oct 2017 16:43:54 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id x82so20016979qkb.12 for ; Sun, 22 Oct 2017 16:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FZl2hNQI3zrLMBVmfebKW3gyoyuwZJ1aXr3QuDSo9q0=; b=f583QTcmsFfukRaddYQ4sOOSHzZsS/V/4p0Albb0bEht/TdMY7n4NSd8M/iTr3mnMc b6QegLdcX8pvbheUX+us2OHkNP91d37PUP8oO/rn/LvcduuIWSU3z2ItxLRvX5oCNhC2 RYU5z1+vrkR0Ro7safe6vuzDoXrGmuMNBOKwrqO56reH5lclTI7OzTSYgzpoEAlxW0tt x4H5tKUs3z8svD3of9kkAqj+x4RLR6iOjqEsHSVX8NkBkTzZcdfKSH30i1vLB2DNd4fk sgQi5ZdBuTYkHUdfeO81kUysrkCZi/Xz2nVknxmpneJHwe1M3MtEJogut+LtE7F2lHqP ah+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FZl2hNQI3zrLMBVmfebKW3gyoyuwZJ1aXr3QuDSo9q0=; b=h4VcQ9Ea3/aMZOFeaJ9HbsH2sCOxjNx3fzzNA8wx9+8Y3XKgYMMMI1VNWSvRcEyraV j1Quoqgjp9Enoof8uv323wk25qnS0um0x9p83+qCSIsWJ0dnNYEAtWYV8AYiIvRfRdmC ROtuy4PAXcNyaO2/wW/6qir39hzeE5XM1kFg+zJpcF94lFEwMKtPVB5U9IoEo3W6UbTo blYJ/Fyef+zcHJwtNYDb0KehbRmKkWiho+K0INVqYXlc/+X0CvRkWYOgxFpyYanleNRm 3ZtDy740ie1z8JuOgM+ORScErB7VvvtFafABfaMtdpLc4nvHW2o0hHT/0HGO5Vxbm/Kh 3oTw== X-Gm-Message-State: AMCzsaVcTU9HYIX5Q0YqGxnB4KIpjYpmbNWadb5SoKJafSkjK1inqkqN qWjIYeSib2YNDfwjna1Tb+kFWA== X-Google-Smtp-Source: ABhQp+S6iCP/JcQ47QSnU03xHY0B3S4djOzTQ7D8AFjza9dKd/csV/WP15lbIOViOwxGC5fmt5xwQA== X-Received: by 10.55.39.145 with SMTP id n139mr16776415qkn.70.1508715833764; Sun, 22 Oct 2017 16:43:53 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id j19sm4075366qkh.38.2017.10.22.16.43.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 16:43:53 -0700 (PDT) From: Ted Lemon Message-Id: <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_24A83820-E9C8-45D8-82B2-74C0BC22185E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 22 Oct 2017 19:43:51 -0400 In-Reply-To: Cc: Steve Fenter , "tls@ietf.org" To: "Ackermann, Michael" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:43:56 -0000 --Apple-Mail=_24A83820-E9C8-45D8-82B2-74C0BC22185E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 22, 2017, at 7:16 PM, Ackermann, Michael = wrote: > And out of curiosity, what is the simpler protocol you are = recommending? I say out of curiosity because switching to a whole = different protocol is not likely to be feasible from any perspective for = large enterprises and the complex, multi-tier protocols that are = prevalent.=20 Perhaps you should read the article that Kathleen shared earlier today? --Apple-Mail=_24A83820-E9C8-45D8-82B2-74C0BC22185E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 22, 2017, at 7:16 PM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
And out of = curiosity,  what is the simpler protocol you are = recommending?    I say out of curiosity because switching = to a whole different protocol is not likely to be feasible from any = perspective for large enterprises and the complex, multi-tier protocols = that are prevalent. 

Perhaps you should read the article that = Kathleen shared earlier today?

= --Apple-Mail=_24A83820-E9C8-45D8-82B2-74C0BC22185E-- From nobody Sun Oct 22 16:50:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C73D13C0FD for ; Sun, 22 Oct 2017 16:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 KNtnZunVbJ25 for ; Sun, 22 Oct 2017 16:50:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF5013C0FA for ; Sun, 22 Oct 2017 16:50:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5AC39BE53; Mon, 23 Oct 2017 00:50:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM1FiZn4RmcK; Mon, 23 Oct 2017 00:50:15 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 963FABE2E; Mon, 23 Oct 2017 00:50:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508716215; bh=anXJxG2qrY/y58y4V8xl+1TimgQzOuR9tOR1nr5qSNY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=q6zxWH1XaG/oFYontbxeg0YhWTpoSLohGgp2HcEBAqSU0IzN5mkio2yFu82iVLHcR Cqo8cv0FXR9GwnJDAzynBPkSXSuw98L2pU5uruPvR+aYCnaOIUj/0Uta56BY1TYSie AEm5ZwpIcTYsoOSkxcj1VNYbjgAFTfJB3tKv5hks= To: Ted Lemon , Steve Fenter Cc: Paul Turner , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <7ed40a30-196f-d280-59a5-814a5ea4676e@huitema.net> <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> <6125D547-7B3A-493E-B3C9-799CEE9E7CC5@fugue.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <019250c3-69c2-9513-2772-ef4415146125@cs.tcd.ie> Date: Mon, 23 Oct 2017 00:50:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6125D547-7B3A-493E-B3C9-799CEE9E7CC5@fugue.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EKFuiIKaW2fjeloOGohbhEo6Lpc99COAJ" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:50:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EKFuiIKaW2fjeloOGohbhEo6Lpc99COAJ Content-Type: multipart/mixed; boundary="iqTpkkJB4LxOOALueXhD5jsv6VsXhuK6P"; protected-headers="v1" From: Stephen Farrell To: Ted Lemon , Steve Fenter Cc: Paul Turner , "tls@ietf.org" Message-ID: <019250c3-69c2-9513-2772-ef4415146125@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <7ed40a30-196f-d280-59a5-814a5ea4676e@huitema.net> <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> <6125D547-7B3A-493E-B3C9-799CEE9E7CC5@fugue.com> In-Reply-To: <6125D547-7B3A-493E-B3C9-799CEE9E7CC5@fugue.com> --iqTpkkJB4LxOOALueXhD5jsv6VsXhuK6P Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Ted, On 23/10/17 00:35, Ted Lemon wrote: > On Oct 22, 2017, at 7:26 PM, Steve Fenter > wrote: >> I have been saying to anyone who will listen that the IETF needs a >> private forum for enterprises, to enable them to come forward and >> discuss their real requirements. Without this input the IETF is >> trying to architect and engineer solutions without knowing the >> complete set of requirements, at least on the enterprise side. >> This results in sub-optimal design decisions (from an enterprise >> perspective), which in this case will break mission critical >> enterprise monitoring and troubleshooting systems. >=20 > The reason we don't have that is that designing secure protocols in > secret isn't a trustworthy approach. Of course, you can always get > together privately. Well, to be fair, that ask - for (literally!) secret handshakes does explain one part of this debacle that has puzzled me so far. We've seen the following interactions: snooping-proponents: "we need snooping, because " others: "that has all sorts of bad side-effects, e.g. A,B,C..." =2E.. =2E..silence from snooping proponents... The ask for secrecy I think demonstrates that the silence in response to explanations of derived demonstrable damage is not due to a lack of understanding, but must be down to caring only about one's own "constituency" and not at all about the Internet more broadly. I think I now understand some of this better (but deplore it more), but am left more puzzled as to the what it was that inspired draft-rehired authors. S. >=20 >=20 >=20 >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --iqTpkkJB4LxOOALueXhD5jsv6VsXhuK6P-- --EKFuiIKaW2fjeloOGohbhEo6Lpc99COAJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ7S62AAoJEC88hzaAX42iLY0H/idXNU0mFDsj3jdBnNk7ykem nfCux2f4TKIWWnywtVkaFuZvmeBeJCImfVsvnne2y3bg4VEk0v4G4vIhE012oNvD oD2j1scpVROlQppTxgrNNGeU9tuZKgfFeBHUlxfpUHTButXHQCV+QN+TlWZJWHMR 3C5ydxl1KRR7fQVf0fcR9NALUcUIjnOk9mjCcxRzG3xIJvFSJox/Bxvl7J2J+xTa a6u/WtJPn491t93lTZy0HhfprxSgYrvDizXDtTiRcBK9/0Cm0Bbf5DnDXTdcGh6z Jcd0SWOzZH4FozbIyMKdxPk9bNbBTdFQ440q4F7jZFrNAG6gLjFiphKKugSjOgA= =AX1b -----END PGP SIGNATURE----- --EKFuiIKaW2fjeloOGohbhEo6Lpc99COAJ-- From nobody Sun Oct 22 16:55:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32E413C178 for ; Sun, 22 Oct 2017 16:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 I_Zcf8F11Eb8 for ; Sun, 22 Oct 2017 16:55:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B34613C177 for ; Sun, 22 Oct 2017 16:55:16 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9MNreAf024242; Mon, 23 Oct 2017 00:55:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=cVYbvPYF10FwT3GWa6tjJM/GmcRX8dAeo9OLkLQoY0w=; b=EzOGskt42lJ8wji1C69WWzC+9Lt2YJyCH7Sj3W+2RPjowaizJswMq9gjkSLrU9gJ2ju4 jR+qRIzOUsAThICEdXiyQg4a/oESzbXShBpQKBD4f34FY50HO9HmusjYE+7Ee8GLm5jm YS/kfZIxdo2wkUXFwYbY2FO/ugNGFJ9KDeiYACt49DFBd1FMKLl24ukXOo/yLhEnPr7e tbxzs/KEzQY7Oz2G3TKs7tVKWCU8I0DRZpnXZJa91ovjut1AFGYD/pLiw0En3bl268iD k0QQ5dcVQ+5VNab15/FzslZMd1+aL1jNhiZefQ8gc71Pndrv763wTXMjGmZWHGGwEtnG NQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2dqxn6cn72-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 00:55:05 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9MNqlYO023978; Sun, 22 Oct 2017 19:55:04 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2dr1jwmh6s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 22 Oct 2017 19:55:04 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 22 Oct 2017 19:54:57 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sun, 22 Oct 2017 19:54:57 -0400 From: "Salz, Rich" To: Steve Fenter , Christian Huitema CC: Darin Pettis , Paul Turner , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAAB/4CABMTGAIAAB+gA Date: Sun, 22 Oct 2017 23:54:57 +0000 Message-ID: <4C8FA7B0-C084-4D77-85A0-29876C055982@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <7ed40a30-196f-d280-59a5-814a5ea4676e@huitema.net> <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> In-Reply-To: <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.9] Content-Type: text/plain; charset="utf-8" Content-ID: <4BA9E021A8B44347A1448D09A045A87B@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710220347 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-22_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710220347 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:55:18 -0000 DQrinqIgSSBoYXZlIGJlZW4gc2F5aW5nIHRvIGFueW9uZSB3aG8gd2lsbCBsaXN0ZW4gdGhhdCB0 aGUgSUVURiBuZWVkcyBhIHByaXZhdGUgZm9ydW0gZm9yIGVudGVycHJpc2VzLCB0byBlbmFibGUg dGhlbSB0byBjb21lIGZvcndhcmQgYW5kIGRpc2N1c3MgdGhlaXIgcmVhbCByZXF1aXJlbWVudHMu IFdpdGhvdXQgdGhpcyBpbnB1dCB0aGUgSUVURiBpcyB0cnlpbmcgdG8gYXJjaGl0ZWN0IGFuZCBl bmdpbmVlciBzb2x1dGlvbnMgd2l0aG91dCBrbm93aW5nIHRoZSBjb21wbGV0ZSBzZXQgb2YgcmVx dWlyZW1lbnRzLCBhdCBsZWFzdCBvbiB0aGUgZW50ZXJwcmlzZSBzaWRlLg0KDQpTb3JyeSwgbm8u ICBXZSBkb27igJl0IHdvcmsgdGhhdCB3YXkuICBOZXZlciBoYXZlLCBhbmQgbmV2ZXIgd2lsbC4g IEV2ZXJ5dGhpbmcgbXVzdCBiZSBkb25lIGluIHB1YmxpYy4gIFRoYXTigJlzIHJlYWxseSBqdXN0 IG5vbi1uZWdvdGlhYmxlLiAgV2l0aG91dCB0aGF0IGlucHV0LCB0aGVuIHllcywgdGhlIElFVEYg cHJvdG9jb2xzIHdpbGwg4oCcanVzdOKAnSBiZSBmb3IgdGhlIHB1YmxpYyBJbnRlcm5ldC4gIEni gJltIHN1cmUgbWFueSB3aWxsIGFjY2VwdCB0aGF0Lg0KDQrinqIgICAgIFRoZSBvbmx5IG90aGVy IG9wdGlvbiBiZWluZyBwcmVzZW50ZWQgdG8gZW50ZXJwcmlzZXMgaXMgdGhhdCB3ZSBjb250aW51 ZSB0byBydW4gb24gYSBUTFMgc3BlYyB0aGF0IGlzIG5pbmUgeWVhcnMgb2xkLCBhbmQgdGhlbiBj b250aW51ZSBydW5uaW5nIGl0IHVudGlsIGl0IGlzIDE0IHRvIDE5IHllYXJzIG9sZC4gSXQgbWFr ZXMgbm8gc2Vuc2UgdG8gbWUgdG8gcHV0IG91dCBhIFRMUyAxLjMgc3RhbmRhcmQsIGJ1dCBzYXkg dGhhdCBlbnRlcnByaXNlcyBjYW5ub3QgdXBncmFkZSB0byBpdC4NCiAgICANClllcyBpdCBtYWtl cyBzZW5zZSwgZm9yIHR3byByZWFzb25zLiAgRmlyc3QsIOKAnGVudGVycHJpc2VzLOKAnSBhcyBy ZXByZXNlbnRlZCBieSB0aG9zZSB3aG8gY2xhaW0gdG8gbmVlZCB0aGlzIHZpc2liaWxpdHksIGhh dmVu4oCZdCBldmVuIG1vdmVkIHVwIHRvIHJlcXVpcmluZyBUTFMgMS4yLiAgSXQgd2FzIGJlY2F1 c2Ugb2YgZW50ZXJwcmlzZSBwdXNoLWJhY2sgdGhhdCBQQ0kgRFNTIHdhcyBkZWxheWVkLCBhbmQg dGhhdCB3YXMgb25seSBUTFMgMS4xISAgU2Vjb25kLCDigJxlbnRlcnByaXNl4oCdIGlzIGEgc21h bGwgcGFydCBvZiB0aGUgSW50ZXJuZXQuDQoNClNvIHlvdSBuZWVkIFRMUyAxLjMsIHdpdGggdGhp cyBzZWN1cml0eS13ZWFrZW5pbmcgZmVhdHVyZSwgc28gdGhhdCBpbiBjYXNlIHNvbWVvbmUgZmlu ZHMgYSBicmVhayBpbiBUTFMgMS4xLCBvciBUTFMgMS4yLCB5b3UgY2FuIHJhcGlkbHkgdXBncmFk ZSB0byBUTFMgMS4zLiAgVGhlIHBocmFzZSB0aGF0IGNvbWVzIHRvIG1pbmQgaXMg4oCcYXJlIHlv dSAtLS0ga2lkZGluZyBtZT/igJ0NCg0KRW50ZXJwcmlzZSBtb25pdG9yaW5nLCBhcyBoYXMgYmVl biByZXBlYXRlZGx5IHNhaWQgaGVyZSwgKmRvZXMgbm90IGhhdmUgdG8gYnJlYWsuKiAgS2VlcCB5 b3VyIGFyY2hpdGVjdHVyZSBhbmQgaGF2ZSB0aGUgc2VydmVy4oCZcyB0aGF0IHlvdSBjb250cm9s IHdpdGhpbiB5b3VyIGVudGVycHJpc2Ugc2hhcmUgYWxsIHRoZSBrZXlzIHdpdGggdGhlIGxvZ2dp bmcgc3lzdGVtLg0KDQoNCg0K From nobody Sun Oct 22 19:30:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882D913CBA8 for ; Sun, 22 Oct 2017 19:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_xYnLgEQMB9 for ; Sun, 22 Oct 2017 19:30:12 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 244ED13CBA4 for ; Sun, 22 Oct 2017 19:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1508725812; x=1540261812; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JC7TvKPsCVCeCESMd2Ll+jNxVvmgLylb5RUsLS/1Yuw=; b=5gNchkE7IrmtQ690cnz1gAcxXBJUFmY+eCeqtjkhVrvp31p217plwg4k f7fbgi+8K2YkEror0GuVKPFpybs1icqnmgi4oOr/OfQYRD+ZTAyn/meo8 CP+yzEep+LlLM77oGF7kQXapkHa5gMwJIlna5h0hVPkzqrSdCI/bNMjHV ElqqEeVrF6z7tDZ52z4AKAk3LUJ73yQ21zRAfjkc10RQtEH/caM11+mu3 Hud9plUV8lqH47YNRiCm1QUXAOu0AJKeDeqXK8Ca4svKNK34E4NUALvKL mTzTJ/Iui2SXKooYQ68X0hz2NdgjrU10IDRbMDEnfUFnpsoAxnueL93mf g==; X-IronPort-AV: E=Sophos;i="5.43,420,1503316800"; d="scan'208";a="191188714" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Oct 2017 15:30:06 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.29) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 23 Oct 2017 15:30:05 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 23 Oct 2017 15:30:06 +1300 From: Peter Gutmann To: "Salz, Rich" , "Ackermann, Michael" , Darin Pettis , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTSDhUZDCwEKWrcUSgIdFpYsIOCaLqWXSAgAAFkICAAADZgIAAARUAgAAAO4CAAAD1gIAAAymAgAAC2ACAAAU2gIAAArOAgAABCACAAARGAIAAGbqAgAAFeICAAFS6AIAA/1cAgAAl/ICAAAaoAIAEp71d Date: Mon, 23 Oct 2017 02:30:05 +0000 Message-ID: <1508725793603.14160@cs.auckland.ac.nz> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> , <1A894D0A-9B72-4649-A6E3-E9BC0C4F96AA@akamai.com> In-Reply-To: <1A894D0A-9B72-4649-A6E3-E9BC0C4F96AA@akamai.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 02:30:14 -0000 Salz, Rich writes:=0A= =0A= >None of those even require TLS 1.2 yet, and it is a decade old. Do you th= ink=0A= >any of them will jump from 1.1 to 1.3? What timetable do you think that w= ill=0A= >happen? A decade? Five years?=0A= =0A= >From working with a lot of SCADA/embedded/IoT vendors, they hope to migrate= =0A= from TLS 1.0 to 1.2 within the next 5-10 years (note the "hope to ..." rath= er=0A= than "have a fixed roadmap to ...", it's sort of a general brownian motion)= .=0A= None of them, that I know of, have ever mentioned TLS 1.3. In the same way= =0A= that HTTP/2 effectively forked HTTP, so I'm expecting TLS 1.3 to fork TLS.= =0A= =0A= >Again, what timetable do you think that will happen?=0A= =0A= In SCADA, embedded, etc, I would say "never". I know that predicting the= =0A= future is always risky :-), but if I had to put money on "1-2 years", "2-5= =0A= years", "5-10 years", or "beyond ten years", I'd put it on the latter, whic= h=0A= in effect means "never".=0A= =0A= Peter.= From nobody Sun Oct 22 20:59:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E214213D288 for ; Sun, 22 Oct 2017 20:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 qVKrzrU3hWLt for ; Sun, 22 Oct 2017 20:58:58 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAC713D28B for ; Sun, 22 Oct 2017 20:58:57 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id u138so6842452wmu.5 for ; Sun, 22 Oct 2017 20:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2g5Rw2iLGGpsPcfN9UjpZtysVPE9xSchTUNre3FirXg=; b=VNA4PRHymKG76D/pVoyO6BNJLssnDUdQEKzj45gDPe1ypzHxeOiLDdAbTBGmcTCNNV fThj1wCX7KRrzSA8ALsj2UScOSUwlXQ17eRJXYBgCKEQugV4dlz2bQougOVXlCdoPRGJ DOJVQ9tOmqC43hneOnIigxfscjL//aZ84OSZTqRlMpdarbl6QJdEqyAXmbcO9+Xem9xa X+AmdQbOhmPeeRCSeG40bL/QhLUYur5m2esK7WVpslE8JiTHolw+T5bsw4j6MHPpTNl9 SzU8YeaPLFuDonDUg7orj1VclY+yv0M8YpMyw43ij3MXFWyn3d1qXKHTJb4SSqQ9YX3/ MeqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2g5Rw2iLGGpsPcfN9UjpZtysVPE9xSchTUNre3FirXg=; b=lfIjc5ekgmGhMihmmCfQ7Zm8Wr7KfIjRi2xlF3IGG5bo9vUuhZ/nwwRzBck83c6knO fMfHi15a6nm+MwywoL62tLpSTNI/ah5vi8ER3ppmQ/gwyQx5IuazE/5sGK5vw4ff0T/x 3cRagoZqNi0vZqntm0s+16bzonvNGygFNtA+o5KCiwaGMh7QXuwBVPIiVMj/C88DgIhC WjG9vGLUOFXfTaWVpXvDgcAacRIlH7VJkUoMHPnXBFmAHrPjWgU8D8amPkmQNILP2P3E qWMwjZONIvlHufoZALScfwDx9MNgqoR1dVmd/1Nu6P4k9tgqGPLFpT6anGWQEiR3pugo 3BVA== X-Gm-Message-State: AMCzsaWMgUhhOo0Cr2WbVbaNecXYv1pvOp1TkiTbeiyLOSgTRu9P1Jz1 6ua09+Cb1s94vix2BidFanST2/4p X-Google-Smtp-Source: ABhQp+QfS0Dqk1qpvDkKVhW9OwGpxP5KsQyptCoPP1BkXT7WwuDWctVzfx5BxDY1FfqMVKCTanOyLA== X-Received: by 10.80.201.12 with SMTP id o12mr14582970edh.98.1508731136408; Sun, 22 Oct 2017 20:58:56 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id s6sm6845368edd.23.2017.10.22.20.58.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 20:58:55 -0700 (PDT) From: Yoav Nir Message-Id: <1A650F4C-A6DC-418C-A693-6056F4D8F9C2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7DA8E47A-AD9E-4CF2-A13E-6AFC8670998E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Date: Mon, 23 Oct 2017 06:58:52 +0300 In-Reply-To: <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> Cc: Russ Housley , IETF TLS To: Ted Lemon References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 03:59:00 -0000 --Apple-Mail=_7DA8E47A-AD9E-4CF2-A13E-6AFC8670998E Content-Type: multipart/alternative; boundary="Apple-Mail=_768BEBCB-9623-4BD9-8DEB-51B02EDEE0DA" --Apple-Mail=_768BEBCB-9623-4BD9-8DEB-51B02EDEE0DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Oct 2017, at 21:40, Ted Lemon wrote: >=20 > On Oct 22, 2017, at 1:54 PM, Russ Housley > wrote: >> No one is requiring TLS 1.3 that I know about. However, there are = places that require visibility into TLS. I will let one of the people = that works in a regulated industry offer pointers to the documents. >=20 > What they require is visibility into contents of the flow that they = are using encryption to protect. Right now, the protocol they are = using is TLS 1.1 or TLS 1.2. The right thing for them to do if they = continue to need this visibility and are no longer permitted to use TLS = 1.2 is to use IPsec+IKE, Right, and shamelessly plugging my working group, I2NSF has recently = adopted a draft ([1]) that is aimed at enabling and automating the = deployment of IKE/IPsec in the datacenter. > or some protocol that is designed for this use case, not to take a = protocol designed specifically for securing flows from on-path = eavesdropping and create a mode where it is easier to wiretap. >=20 > There is no reason other than momentum for them to switch to TLS 1.3 = when it doesn't address their use case. [1] = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 --Apple-Mail=_768BEBCB-9623-4BD9-8DEB-51B02EDEE0DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 22 Oct 2017, at 21:40, Ted Lemon <mellon@fugue.com> = wrote:

On Oct 22, = 2017, at 1:54 PM, Russ Housley <housley@vigilsec.com> wrote:
No one is requiring TLS 1.3 that I know = about.  However, there are places that require visibility into TLS. =  I will let one of the people that works in a regulated industry = offer pointers to the documents.

What they require is visibility into contents = of the flow that they are using encryption to protect.   Right now, = the protocol they are using is TLS 1.1 or TLS 1.2.   The right = thing for them to do if they continue to need this visibility and are no = longer permitted to use TLS 1.2 is to use IPsec+IKE, =

Right, and = shamelessly plugging my working group, I2NSF has recently adopted a = draft ([1]) that is aimed at enabling and automating the deployment of = IKE/IPsec in the datacenter.

or some protocol that is designed for this = use case, not to take a protocol designed specifically for securing = flows from on-path eavesdropping and create a mode where it is easier to = wiretap.

There = is no reason other than momentum for them to switch to TLS 1.3 when it = doesn't address their use case.


= --Apple-Mail=_768BEBCB-9623-4BD9-8DEB-51B02EDEE0DA-- --Apple-Mail=_7DA8E47A-AD9E-4CF2-A13E-6AFC8670998E 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlntaPwACgkQuEkLFQpY zJnttQf7B4vWQqC+l74BStTQhBc40R8adio0tKL7/DwJWdQBMIF+ltNx7oyBfTzy o3LNMUtAvFkhUNGoyxD+YKZKwk0+Yv9XkSr2H99gkRRwzmJXW9erIX6M4c+hODtD EJFXqwW2Pt5j3c81v2b72tPcG9EZDOP8Yg0cPE9WdeuKeZ1aYwJfIlynxNqmU8ls dqKHiaj8b/MQY8sPKj4+tVB0Xthkbdb9e4ggaP7So/5qsILrke8cGnnifVpFHGac ytxfJ0VQeInumJMZfpZ4L6xp6tz8fhGUlFTGISPqpTxh1o17Tzip2X+46nXKuKiN bzdABuj0FfnLYZ6NwrQvLTx9Hn2Sog== =pwZ3 -----END PGP SIGNATURE----- --Apple-Mail=_7DA8E47A-AD9E-4CF2-A13E-6AFC8670998E-- From nobody Mon Oct 23 00:53:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD41C13EDCC for ; Mon, 23 Oct 2017 00:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 v56mu7GxNG0n for ; Mon, 23 Oct 2017 00:53:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9761213EDCB for ; Mon, 23 Oct 2017 00:53:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRD71086; Mon, 23 Oct 2017 07:53:38 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 23 Oct 2017 08:53:35 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.184]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Mon, 23 Oct 2017 15:53:32 +0800 From: yinxinxing To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AdNL0DDMc9iDHxhWQTW8k0u7S4PL/w== Date: Mon, 23 Oct 2017 07:53:32 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022D14F6FBdggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59EDA003.0031, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.184, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f4e239171d64f650785ae4a1845856df Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 07:53:44 -0000 --_000_DBDF9AE44733284D808F0E585E1919022D14F6FBdggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWtyLA0KDQpGb3IgdGhlIHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzIGluIHRoZSBkcmFmdCwg SSBoYXZlIHNvbWUgY29tbWVudHMuDQoNCg0KMS4gICAgICAgV2hlbiBvbmUgcGVlciBzZW5kcyBO ZXdjb25uZWN0aW9uSUQgbWVzc2FnZSB0byB0aGUgb3RoZXIsIGl0IHVzZXMgYSBuZXdseSBkZWZp bmVkIGhhbmRzaGFrZSB0eXBlLiBUaGlzIG5ldyBDSUQgaXMgYXR0YWNoZWQgaW4gdGhlIHBheWxv YWQgb2YgdGhlIHJlY29yZCBtZXNzYWdlLiBCdXQgdGhlcmUgbXVzdCBiZSBzb21lIGluZm9ybWF0 aW9uIGZvciB0aGUgcmVjZWl2ZXIgdG8ga25vdyB3aGljaCBDSUQgaXMgZ29pbmcgdG8gYmUgdXBk YXRlZC4gSSBtZWFuIHRoYXQgd2hlbiBzZW5kaW5nIG5ldyBDSUQgdGhyb3VnaCB0aGUgTmV3Q29u bmVjdGlvbklEIG1lc3NhZ2UsIHRoZSByZWNvcmQgaGVhZGVyIHNob3VsZCBpbmNsdWRlIHRoZSDi gJxvbGTigJ0gQ0lELCBzbyB0aGF0IHRoZSByZWNlaXZlciBrbm93cyB3aGljaCBvbmUgdG8gcmVw bGFjZS4NCg0KMi4gICAgICAgSW4gdGhlIGRyYWZ0LCBpcyB0aGUgbmV3IENJRCBlbmNyeXB0ZWQ/ IEkgc3VnZ2VzdCB0aGF0IHRoZSBuZXcgQ0lEIChmb3IgdGhlIGZpcnN0IHRpbWUgc2VuZGluZykg Y2FuIGJlIGVuY3J5cHRlZCAgdG8gbWFrZSBzdXJlIHRoYXQgYW4gYXR0YWNrZXIgY2FuIG5vdCBh c3NvY2lhdGUgYSBuZXcgQ0lEIHdpdGggYW4gb2xkIENJRC4gTGV04oCZcyBjb25zaWRlciBhIGNh c2Ugd2hlcmUgYW4gYXR0YWNrZXIgd2FudHMgdG8gdHJhY2sgYW4gSU9UIGRldmljZS4gSWYgdGhl IG5ld2x5IGdlbmVyYXRlZCBDSUQgaXMgbm90IGVuY3J5cHRlZCB3aGVuIHVwZGF0aW5nLCB0aGUg YXR0YWNrZXIgY2FuIGFzc29jaWF0ZSB0aGUgbmV3IENJRCB3aXRoIHRoZSBvbGQgb25lLiBUaGVu LCB3aGVuIHRoZSBwZWVyIHNlbmRzIG1lc3NhZ2Ugd2l0aCB0aGUgbmV3IENJRCBsYXRlciwgdGhl IGF0dGFja2VyIGtub3dzIHRoaXMgcGFja2V0IGlzIHNlbnQgZnJvbSB0aGUgdmljdGltLiBJZiB3 ZSBlbmNyeXB0IHRoZSBuZXcgQ0lEIHdoZW4gdXBkYXRpbmcsIHRoaXMgdHJhY2tpbmcgcHJvYmxl bSBjYW4gYmUgYXZvaWRlZC4NCg0KQW5vdGhlciBjb21tZW50IGlzIGFib3V0IHN5bW1ldHJpY2Fs IENJRC4NCg0KMS4gICAgICAgQ29uc2lkZXIgYSBjbGllbnQgc2VuZHMgYSBub3JtYWwgQ0lEIChD SUQgbGVuZ3RoIGlzIG5vdCB6ZXJvLCBuYW1lZCBDLUNJRCkgdG8gc2VydmVyLCBidXQgdGhlIHNl cnZlciBkb2VzbuKAmXQgd2FudHMgdG8gdXNlIGNsaWVudOKAmXMgQ0lEIGFuZCBzZW5kcyBhIENJ RCBnZW5lcmF0ZWQgYnkgdGhlIHNlcnZlciAobmFtZWQgUy1DSUQpIHRvIHRoZSBjbGllbnQuIEF0 IHRoZSBzYW1lIHRpbWUsIGNsaWVudCBuZWVkcyB0byBrbm93IHNlcnZlciBoYXMgaWdub3JlZCBD LUNJRCAod2hpY2ggbWVhbnMgdGhlIGRvd25saW5rIGFwcGxpY2F0aW9uIG1lc3NhZ2UgZnJvbSB0 aGUgc2VydmVyIHdpbGwgbm90IGluY2x1ZGUgQy1DSUQpLCBhbmQgY2xpZW50IHdpbGwgdXNlIFMt Q0lEIGluIGl0cyBhcHBsaWNhdGlvbiBtZXNzYWdlLiBXaWxsIHRoZSBkcmFmdCBjb3ZlciB0aGlz IHNjZW5hcmlvPw0KDQpZaW4gWGlueGluZw0KDQrlj5Hku7bkuro6IEVyaWMgUmVzY29ybGEgW21h aWx0bzpla3JAcnRmbS5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTflubQxMOaciDEz5pelIDIxOjAw DQrmlLbku7bkuro6IHlpbnhpbnhpbmcNCuaKhOmAgTogdGxzQGlldGYub3JnDQrkuLvpopg6IFJl OiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0DQoNCg0KDQpPbiBGcmksIE9jdCAxMywgMjAxNyBh dCAxOjExIEFNLCB5aW54aW54aW5nIDx5aW54aW54aW5nQGh1YXdlaS5jb208bWFpbHRvOnlpbnhp bnhpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgRWtyLA0KDQpUaGFua3MgZm9yIHlvdXIgZWZm b3J0LiBUaGUgZHJhZnQgbG9va3MgZ29vZC4gQSBmZXcgY29tbWVudHMgYXJlIGxpc3RlZCBiZWxv dy4NCg0KDQoxLiAgICAgICBCYXNlZCBvbiB0aGUgZHJhZnQsIGZvciBlaXRoZXIgRFRMUzEuMiBv ciAxLjMsIHNlcnZlciBjYW7igJl0IGRpZmZlcmVudGlhdGUgd2hldGhlciB0aGUgcGFja2V0IGZy b20gY2xpZW50IGlzIGEg4oCcY29ubmVjdGlvbiBJROKAnSBwYWNrZXQgb3IgYSBzdGFuZGFyZCBE VExTIDEuMi8xLjMgcGFja2V0LiAoSSBzYXcgVGhvbWFzIEZvc3NhdGkgYW5kIE5pa29zIGFsc28g aW50cm9kdWNlZCB0aGlzIHByb2JsZW0pDQoNCk1heWJlIHdlIGNhbiBhZGQgYSBuZXcg4oCcQ29u dGVudFR5cGXigJ0gaW4gdGhlIERUTFMgcmVjb3JkIGZvcm1hdCB0byBoZWxwIHNlcnZlciBpZGVu dGlmeSB0aGUg4oCcY29ubmVjdGlvbiBJROKAnSBwYWNrZXQuIEluIGFkZGl0aW9uLCB5b3Ugc2Vl IHRoZSBsZW5ndGggb2YgdGhlIHJlY29yZCBwYXlsb2FkIGlzIGxpbWl0ZWQgYnkgMl4xNC0xLCB0 aGlzIG1lYW5zIHRoZSBmaXJzdCB0d28gYml0cyBvZiDigJxsZW5ndGjigJ0gaXMgemVyby4gV2Ug Y291bGQgdXRpbGl6ZSB0aGlzIGZlYXR1cmUgYW5kIHNldCB0aGUgZmlyc3QgdHdvIGJpdHMgb3Ig bW9yZSBiaXRzIG9mIENJRCBiZWluZyBvbmUsIGUuZy4sIDExMTHigKYuKGJ1dCB0aGUgQ0lEIG11 c3QgYmUgcHV0IGJldHdlZW4gc2VxdWVuY2UgbnVtYmVyIGFuZCBsZW5ndGgpLiBXaGVuIHNlcnZl ciBmaW5kcyAxMTExIGFmdGVyIHNlcXVlbmNlIG51bWJlciwgaXQga25vd3MgdGhpcyBpcyBhIOKA nGNvbm5lY3Rpb24gSUTigJ0gcGFja2V0LiBIb3dldmVyLCBJIGRvbuKAmXQga25vdyB3aGV0aGVy IGl0IGlzIHByb3BlciB0byB1c2Ugc3VjaCBtYWdpYyBudW1iZXIuIEluIG15IHZpZXcsIGFkZGlu ZyBuZXcgY29udGVudHR5cGUgbWF5IGJlIGEgY2hvaWNlLg0KDQpBcyBJIHNhaWQgdG8gTmlrb3Ms IGZvciBEVExTIDEuMiwgeW91IGNhbiB1c2UgYSBzcGVjaWFsbHktY29uc3RydWN0ZWQgQ0lEIHRo YXQgd291bGQgbm90IGJlIGEgdmFsaWQgbGVuZ3RoIGZpZWxkLiBUaGlzIGNhbiBhY3R1YWxseSBq dXN0IGhhdmUgdGhlIGxlYWRpbmcgYml0IHNldC4gQXMgd2UncmUgcmV2aXNpbmcgdGhlIERUTFMg MS4zIHJlY29yZCBmb3JtYXQsIHdlIHdvdWxkIG5lZWQgdG8gZG8gc29tZXRoaW5nIGRpZmZlcmVu dCBmb3IgdGhhdC4NCg0KDQoyLiAgICAgICAgRm9yIERUTFMgMS4yLCB0aGVyZSBpcyBubyBOZXdD b25uZWN0aW9uSUQgYW5kIFJlcXVlc3RDb25uZWN0aW9uSUQgbWVzc2FnZS4gRFRMUyAxLjIgc2Vy dmVyIGFuZCBjbGllbnQgYWxzbyBoYXMgdGhlIHJlcXVpcmVtZW50IHRvIHJlcXVlc3QgZm9yIGEg bmV3IENJRCwgYW5kIGF0IHByZXNlbnQsIG1hbnkgcHJvZHVjdHMgc3RpbGwgdXNlIERUTFMxLjIg YW5kIEkgYmVsaWV2ZSBpdCB3aWxsIGNvbnRpbnVlIHRvIGJlIHVzZWQgZm9yIGEgbG9uZyB0aW1l IGV2ZW4gaWYgVExTL0RUTFMxLjMgaXMgcHVibGlzaGVkLiBNeSBwb2ludCBpcyB0aGF0IHdlIG5l ZWQgYSBjb3JyZXNwb25kaW5nIG1ldGhvZCBmb3IgdXBkYXRpbmcgQ0lEIGZvciBEVExTMS4yIHRv by4NCkluIGdlbmVyYWwsIHRoZSBXRyBpcyB3b3JraW5nIG9uIFRMUyAxLjMsIG5vdCBUTFMgMS4y LCBzbyBJJ20gbm90IHJlYWxseSB0aGF0IGV4Y2l0ZWQgYWJvdXQgcHV0dGluZyBhIGxvdCBvZiBl ZmZvcnQgaW50byBlbmhhbmNpbmcgVExTIDEuMi4gVGhlIGJhc2ljIGV4dGVuc2lvbiB3b3JrcyBm aW5lIGZvciB0aGVtLCBidXQgaWYgdGhleSB3YW50IHRvIGNoYW5nZSBDSURzLCB0aGVuIHRoZXkg c2hvdWxkIGFkb3B0IERUTFMgMS4zLg0KDQoNCkkgZG9u4oCZdCBxdWl0ZSB1bmRlcnN0YW5kIHRo ZSBmb2xsb3dpbmcgc2VudGVuY2VzDQoNCuKAnEluIERUTFMgMS4yLCBjb25uZWN0aW9uIGlkcyBh cmUgZXhjaGFuZ2VkIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlDQoNCiAgIERUTFMgc2Vzc2lvbiBv bmx5LiAgVGhlcmUgaXMgbm8gZGVkaWNhdGVkICJjb25uZWN0aW9uIGlkIHVwZGF0ZSINCg0KICAg bWVzc2FnZSB0aGF0IGFsbG93cyBuZXcgY29ubmVjdGlvbiBpZHMgdG8gYmUgZXN0YWJsaXNoZWQg bWlkLXNlc3Npb24sDQoNCiAgIGJlY2F1c2UgRFRMUyAxLjIgaW4gZ2VuZXJhbCBkb2VzIG5vdCBh bGxvdyBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcw0KDQogICB0aGF0IGRvIG5vdCB0aGVtc2VsdmVz IGJlZ2luIG90aGVyIGhhbmRzaGFrZXMu4oCdDQoNClRoZSBvbmx5IHBvc3QtaGFuZHNoYWtlIG1l c3NhZ2VzIGFsbG93ZWQgaW4gRFRMUyAxLjIgYXJlIENsaWVudEhlbGxvIGFuZCBIZWxsb1JlcXVl c3QuDQoNCg0KQmVzaWRlcywgZm9yIENJRCBpbiBEVExTMS4zLCBJIHRoaW5rIHRoZSBjb3JyZXNw b25kaW5nIHJlc3BvbmRpbmcgbWVzc2FnZXMgb2YgIE5ld0Nvbm5lY3Rpb25JRCBhbmQgUmVxdWVz dENvbm5lY3Rpb25JRCBhcmUgYWxzbyBuZWVkZWQgdG8gZW5zdXJlIHRoYXQgdGhlIHBlZXIgaGFz IHJlY2VpdmVkIENJRC4NCg0KTm8sIHlvdSB1c2UgdGhlIEFDSyBmb3IgdGhlc2UgKGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRscy1kdGxzMTMtMDEjc2VjdGlvbi03KS4g VGhpcyBpcyBvbmUgcmVhc29uIHdoeSB0aGVyZSBpcyBub3QgYSBzdHJhaWdodGZvcndhcmQgcG9y dCB0byBEVExTIDEuMiBmb3IgdGhlc2UgbWVzc2FnZXMuDQoNCg0KNC4gICAgICAgVGhlIGdlbmVy YXRpb24gb2YgQ0lEIHNob3VsZCBiZSBtb3JlIGNvbmNyZXRlLiBGb3IgZXhhbXBsZSwgdXNpbmcg cmFuZG9tIG51bWJlciBvciBhIGNvdW50ZXI/DQpJIGV4cGxpY2l0bHkgZGlkIG5vdCB3YW50IHRv IGRvIHRoYXQsIGJlY2F1c2UgdGhlcmUgYXJlIGEgbG90IG9mIHZhbGlkIHdheXMgdG8gZ2VuZXJh dGUgQ0lELiBUaGlzIGlzIGFsc28gd2hhdCB3ZSBkaWQgaW4gUVVJQy4NCg0KLUVrcg0KDQoNCg0K UmVnYXJkcywNCllpbiBYaW54aW5nDQoNCuWPkeS7tuS6ujogVExTIFttYWlsdG86dGxzLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPl0g5Luj6KGoIEVyaWMgUmVz Y29ybGENCuWPkemAgeaXtumXtDogMjAxN+W5tDEw5pyIMTPml6UgNzoxNA0K5pS25Lu25Lq6OiB0 bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NCuS4u+mimDogW1RMU10gQ29ubmVjdGlv biBJRCBEcmFmdA0KDQpIaSBmb2xrcywNCg0KSSBoYXZlIGp1c3QgcG9zdGVkIGEgZmlyc3QgY3V0 IGF0IGEgY29ubmVjdGlvbiBJRCBkcmFmdC4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1yZXNjb3JsYS10bHMtZHRscy1jb25uZWN0aW9uLWlkLTAwDQoNCkNvbW1lbnRzIHdlbGNv bWUuDQoNCi1Fa3INCg0KDQoNCg0K --_000_DBDF9AE44733284D808F0E585E1919022D14F6FBdggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6 MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAuZ21h aWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tLTY1MTM2 MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tLTY1MTM2MDUzMzMxMzgy NTA0M21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tNjUxMzYwNTMz MzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFu LmdtYWlsLQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzU4MTYwNzkzOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTg3MTI4MDcwOCAxNDM1NTY4OTIgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxOC4wcHQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUyXCkiOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDo0Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDo2 My4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0Ojg0LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4 dDoiJTVcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEwNS4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBw dDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgltYXJnaW4tbGVmdDoxMjYuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNDcuMHB0Ow0KCXRleHQtaW5kZW50 Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlOFwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY4 LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjE4OS4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo1NDE0Nzc0 OTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02NjQ3 NzUzMzYgOTU5ODYxNzg2IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 ZXh0OiIlMlwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NDIuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6NjMuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo4NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6 LTIxLjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiU1XCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMDUu MHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MTI2LjBwdDsN Cgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MTQ3LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJThc KSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE2OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgltYXJnaW4tbGVmdDoxODkuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRWtyLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgdGhlIHBvc3QtaGFuZHNoYWtlIG1lc3Nh Z2VzIGluIHRoZSBkcmFmdCwgSSBoYXZlIHNvbWUgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hlbiBvbmUgcGVl ciBzZW5kcyBOZXdjb25uZWN0aW9uSUQgbWVzc2FnZSB0byB0aGUgb3RoZXIsIGl0IHVzZXMgYSBu ZXdseSBkZWZpbmVkIGhhbmRzaGFrZSB0eXBlLiBUaGlzIG5ldyBDSUQgaXMgYXR0YWNoZWQgaW4g dGhlIHBheWxvYWQNCiBvZiB0aGUgcmVjb3JkIG1lc3NhZ2UuIEJ1dCB0aGVyZSBtdXN0IGJlIHNv bWUgaW5mb3JtYXRpb24gZm9yIHRoZSByZWNlaXZlciB0byBrbm93IHdoaWNoIENJRCBpcyBnb2lu ZyB0byBiZSB1cGRhdGVkLiBJIG1lYW4gdGhhdCB3aGVuIHNlbmRpbmcgbmV3IENJRCB0aHJvdWdo IHRoZSBOZXdDb25uZWN0aW9uSUQgbWVzc2FnZSwgdGhlIHJlY29yZCBoZWFkZXIgc2hvdWxkIGlu Y2x1ZGUgdGhlIOKAnG9sZOKAnSBDSUQsIHNvIHRoYXQgdGhlIHJlY2VpdmVyDQoga25vd3Mgd2hp Y2ggb25lIHRvIHJlcGxhY2UuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiB0aGUgZHJhZnQsIGlzIHRoZSBuZXcg Q0lEIGVuY3J5cHRlZD8gSSBzdWdnZXN0IHRoYXQgdGhlIG5ldyBDSUQgKGZvciB0aGUgZmlyc3Qg dGltZSBzZW5kaW5nKSBjYW4gYmUgZW5jcnlwdGVkICZuYnNwO3RvIG1ha2Ugc3VyZSB0aGF0IGFu DQogYXR0YWNrZXIgY2FuIG5vdCBhc3NvY2lhdGUgYSBuZXcgQ0lEIHdpdGggYW4gb2xkIENJRC4g TGV04oCZcyBjb25zaWRlciBhIGNhc2Ugd2hlcmUgYW4gYXR0YWNrZXIgd2FudHMgdG8gdHJhY2sg YW4gSU9UIGRldmljZS4gSWYgdGhlIG5ld2x5IGdlbmVyYXRlZCBDSUQgaXMgbm90IGVuY3J5cHRl ZCB3aGVuIHVwZGF0aW5nLCB0aGUgYXR0YWNrZXIgY2FuIGFzc29jaWF0ZSB0aGUgbmV3IENJRCB3 aXRoIHRoZSBvbGQgb25lLiBUaGVuLCB3aGVuIHRoZSBwZWVyDQogc2VuZHMgbWVzc2FnZSB3aXRo IHRoZSBuZXcgQ0lEIGxhdGVyLCB0aGUgYXR0YWNrZXIga25vd3MgdGhpcyBwYWNrZXQgaXMgc2Vu dCBmcm9tIHRoZSB2aWN0aW0uIElmIHdlIGVuY3J5cHQgdGhlIG5ldyBDSUQgd2hlbiB1cGRhdGlu ZywgdGhpcyB0cmFja2luZyBwcm9ibGVtIGNhbiBiZSBhdm9pZGVkLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFub3RoZXIgY29tbWVudCBpcyBhYm91dCBzeW1tZXRyaWNh bCBDSUQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwxIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgYSBjbGllbnQgc2VuZHMgYSBub3JtYWwgQ0lE IChDSUQgbGVuZ3RoIGlzIG5vdCB6ZXJvLCBuYW1lZCBDLUNJRCkgdG8gc2VydmVyLCBidXQgdGhl IHNlcnZlciBkb2VzbuKAmXQgd2FudHMgdG8gdXNlIGNsaWVudOKAmXMgQ0lEDQogYW5kIHNlbmRz IGEgQ0lEIGdlbmVyYXRlZCBieSB0aGUgc2VydmVyIChuYW1lZCBTLUNJRCkgdG8gdGhlIGNsaWVu dC4gQXQgdGhlIHNhbWUgdGltZSwgY2xpZW50IG5lZWRzIHRvIGtub3cgc2VydmVyIGhhcyBpZ25v cmVkIEMtQ0lEICh3aGljaCBtZWFucyB0aGUgZG93bmxpbmsgYXBwbGljYXRpb24gbWVzc2FnZSBm cm9tIHRoZSBzZXJ2ZXIgd2lsbCBub3QgaW5jbHVkZSBDLUNJRCksIGFuZCBjbGllbnQgd2lsbCB1 c2UgUy1DSUQgaW4gaXRzIGFwcGxpY2F0aW9uDQogbWVzc2FnZS4gV2lsbCB0aGUgZHJhZnQgY292 ZXIgdGhpcyBzY2VuYXJpbz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWlu IFhpbnhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+DQo8L3NwYW4+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuWPkemAgeaXtumXtDxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVO LVVTIj4xMzwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMjE6MDA8YnI+DQo8L3NwYW4+ PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4geWlueGlueGluZzxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB0bHNAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+ PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gUmU6IFtUTFNdIENvbm5lY3Rpb24gSUQgRHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIEZyaSwg T2N0IDEzLCAyMDE3IGF0IDE6MTEgQU0sIHlpbnhpbnhpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp5 aW54aW54aW5nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj55aW54aW54aW5nQGh1YXdlaS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRWtyLDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBlZmZvcnQuIFRoZSBkcmFmdCBsb29r cyBnb29kLiBBIGZldyBjb21tZW50cyBhcmUgbGlzdGVkIGJlbG93Ljwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9ImdtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkJhc2VkIG9uIHRoZSBkcmFmdCwgZm9yIGVpdGhlciBEVExTMS4y IG9yIDEuMywgc2VydmVyIGNhbuKAmXQgZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZSBwYWNrZXQg ZnJvbSBjbGllbnQgaXMgYSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldCBvciBhIHN0YW5kYXJk IERUTFMgMS4yLzEuMw0KIHBhY2tldC4gKEkgc2F3IFRob21hcyBGb3NzYXRpIGFuZCBOaWtvcyBh bHNvIGludHJvZHVjZWQgdGhpcyBwcm9ibGVtKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQz bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heWJlIHdlIGNh biBhZGQgYSBuZXcg4oCcQ29udGVudFR5cGXigJ0gaW4gdGhlIERUTFMgcmVjb3JkIGZvcm1hdCB0 byBoZWxwIHNlcnZlciBpZGVudGlmeSB0aGUg4oCcY29ubmVjdGlvbiBJROKAnSBwYWNrZXQuIElu IGFkZGl0aW9uLCB5b3Ugc2VlIHRoZSBsZW5ndGggb2YgdGhlIHJlY29yZCBwYXlsb2FkDQogaXMg bGltaXRlZCBieSAyXjE0LTEsIHRoaXMgbWVhbnMgdGhlIGZpcnN0IHR3byBiaXRzIG9mIOKAnGxl bmd0aOKAnSBpcyB6ZXJvLiBXZSBjb3VsZCB1dGlsaXplIHRoaXMgZmVhdHVyZSBhbmQgc2V0IHRo ZSBmaXJzdCB0d28gYml0cyBvciBtb3JlIGJpdHMgb2YgQ0lEIGJlaW5nIG9uZSwgZS5nLiwgMTEx MeKApi4oYnV0IHRoZSBDSUQgbXVzdCBiZSBwdXQgYmV0d2VlbiBzZXF1ZW5jZSBudW1iZXIgYW5k IGxlbmd0aCkuIFdoZW4gc2VydmVyIGZpbmRzIDExMTENCiBhZnRlciBzZXF1ZW5jZSBudW1iZXIs IGl0IGtub3dzIHRoaXMgaXMgYSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldC4gSG93ZXZlciwg SSBkb27igJl0IGtub3cgd2hldGhlciBpdCBpcyBwcm9wZXIgdG8gdXNlIHN1Y2ggbWFnaWMgbnVt YmVyLiBJbiBteSB2aWV3LCBhZGRpbmcgbmV3IGNvbnRlbnR0eXBlIG1heSBiZSBhIGNob2ljZS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBJIHNhaWQgdG8gTmlr b3MsIGZvciBEVExTIDEuMiwgeW91IGNhbiB1c2UgYSBzcGVjaWFsbHktY29uc3RydWN0ZWQgQ0lE IHRoYXQgd291bGQgbm90IGJlIGEgdmFsaWQgbGVuZ3RoIGZpZWxkLiBUaGlzIGNhbiBhY3R1YWxs eSBqdXN0IGhhdmUgdGhlIGxlYWRpbmcgYml0IHNldC4gQXMgd2UncmUgcmV2aXNpbmcgdGhlIERU TFMgMS4zIHJlY29yZCBmb3JtYXQsIHdlIHdvdWxkDQogbmVlZCB0byBkbyBzb21ldGhpbmcgZGlm ZmVyZW50IGZvciB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJn bWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDtGb3IgRFRMUyAxLjIsIHRoZXJlIGlzIG5vIE5ld0Nvbm5lY3Rpb25J RCBhbmQgUmVxdWVzdENvbm5lY3Rpb25JRCBtZXNzYWdlLiBEVExTIDEuMiBzZXJ2ZXIgYW5kIGNs aWVudCBhbHNvIGhhcyB0aGUgcmVxdWlyZW1lbnQgdG8gcmVxdWVzdCBmb3IgYSBuZXcgQ0lELCBh bmQNCiBhdCBwcmVzZW50LCBtYW55IHByb2R1Y3RzIHN0aWxsIHVzZSBEVExTMS4yIGFuZCBJIGJl bGlldmUgaXQgd2lsbCBjb250aW51ZSB0byBiZSB1c2VkIGZvciBhIGxvbmcgdGltZSBldmVuIGlm IFRMUy9EVExTMS4zIGlzIHB1Ymxpc2hlZC4gTXkgcG9pbnQgaXMgdGhhdCB3ZSBuZWVkIGEgY29y cmVzcG9uZGluZyBtZXRob2QgZm9yIHVwZGF0aW5nIENJRCBmb3IgRFRMUzEuMiB0b28uPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JbiBnZW5lcmFsLCB0aGUgV0cgaXMgd29ya2luZyBvbiBUTFMgMS4zLCBub3QgVExT IDEuMiwgc28gSSdtIG5vdCByZWFsbHkgdGhhdCBleGNpdGVkIGFib3V0IHB1dHRpbmcgYSBsb3Qg b2YgZWZmb3J0IGludG8gZW5oYW5jaW5nIFRMUyAxLjIuIFRoZSBiYXNpYyBleHRlbnNpb24gd29y a3MgZmluZSBmb3IgdGhlbSwgYnV0IGlmIHRoZXkgd2FudCB0byBjaGFuZ2UgQ0lEcywgdGhlbg0K IHRoZXkgc2hvdWxkIGFkb3B0IERUTFMgMS4zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgcXVpdGUgdW5kZXJzdGFuZCB0aGUg Zm9sbG93aW5nIHNlbnRlbmNlcw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcSW4gRFRMUyAxLjIsIGNv bm5lY3Rpb24gaWRzIGFyZSBleGNoYW5nZWQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGU8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgRFRMUyBzZXNzaW9uIG9ubHkuJm5ic3A7IFRoZXJlIGlz IG5vIGRlZGljYXRlZCAmcXVvdDtjb25uZWN0aW9uIGlkIHVwZGF0ZSZxdW90Ozwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0t NjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4 LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyBtZXNzYWdlIHRoYXQgYWxsb3dzIG5ldyBjb25uZWN0aW9uIGlk cyB0byBiZSBlc3RhYmxpc2hlZCBtaWQtc2Vzc2lvbiw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTY1MTM2MDUzMzMxMzgy NTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgYmVjYXVzZSBEVExTIDEuMiBpbiBnZW5lcmFsIGRvZXMgbm90IGFsbG93IHBvc3QtaGFu ZHNoYWtlIG1lc3NhZ2VzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHRoYXQgZG8gbm90 IHRoZW1zZWx2ZXMgYmVnaW4gb3RoZXIgaGFuZHNoYWtlcy7igJ08L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgb25seSBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBh bGxvd2VkIGluIERUTFMgMS4yIGFyZSBDbGllbnRIZWxsbyBhbmQgSGVsbG9SZXF1ZXN0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJnbWFpbC1tLTY1MTM2MDUzMzMxMzgy NTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXNpZGVz LCBmb3IgQ0lEIGluIERUTFMxLjMsIEkgdGhpbmsgdGhlIGNvcnJlc3BvbmRpbmcgcmVzcG9uZGlu ZyBtZXNzYWdlcyBvZiAmbmJzcDtOZXdDb25uZWN0aW9uSUQgYW5kIFJlcXVlc3RDb25uZWN0aW9u SUQgYXJlIGFsc28gbmVlZGVkIHRvIGVuc3VyZSB0aGF0IHRoZSBwZWVyIGhhcyByZWNlaXZlZA0K IENJRC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5ObywgeW91IHVz ZSB0aGUgQUNLIGZvciB0aGVzZSAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtdGxzLWR0bHMxMy0wMSNzZWN0aW9uLTciPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXRscy1kdGxzMTMtMDEjc2VjdGlvbi03PC9hPikuIFRoaXMgaXMg b25lIHJlYXNvbiB3aHkgdGhlcmUgaXMgbm90IGEgc3RyYWlnaHRmb3J3YXJkDQogcG9ydCB0byBE VExTIDEuMiBmb3IgdGhlc2UgbWVzc2FnZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBnZW5lcmF0aW9uIG9mIENJRCBzaG91bGQg YmUgbW9yZSBjb25jcmV0ZS4gRm9yIGV4YW1wbGUsIHVzaW5nIHJhbmRvbSBudW1iZXIgb3IgYSBj b3VudGVyPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSBleHBsaWNpdGx5IGRpZCBub3Qgd2FudCB0byBkbyB0aGF0 LCBiZWNhdXNlIHRoZXJlIGFyZSBhIGxvdCBvZiB2YWxpZCB3YXlzIHRvIGdlbmVyYXRlIENJRC4g VGhpcyBpcyBhbHNvIHdoYXQgd2UgZGlkIGluIFFVSUMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tRWtyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWluIFhpbnhpbmc8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiBUTFMgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPuS7o+ihqCA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5FcmljIFJlc2NvcmxhPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IDIwMTc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuW5 tDxzcGFuIGxhbmc9IkVOLVVTIj4xMDwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTM8L3Nw YW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDc6MTQ8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6 PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gPGEgaHJl Zj0ibWFpbHRvOnRsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdGxzQGlldGYub3JnPC9h Pjxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0PC9zcGFuPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGZvbGtz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUganVz dCBwb3N0ZWQgYSBmaXJzdCBjdXQgYXQgYSBjb25uZWN0aW9uIElEIGRyYWZ0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1y ZXNjb3JsYS10bHMtZHRscy1jb25uZWN0aW9uLWlkLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1kdGxzLWNvbm5lY3Rpb24t aWQtMDA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Q29tbWVudHMgd2VsY29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4tRWtyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DBDF9AE44733284D808F0E585E1919022D14F6FBdggeml511mbschi_-- From nobody Mon Oct 23 05:13:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2677413875A for ; Mon, 23 Oct 2017 05:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcT_r9S7BFuI for ; Mon, 23 Oct 2017 05:13:14 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAB41386F3 for ; Mon, 23 Oct 2017 05:13:14 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id q126so8878752ywq.10 for ; Mon, 23 Oct 2017 05:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=evAecY+8s+DFNpn+w9iy+rH5jug9uL7QGhkSB2/Ofuk=; b=BfEiC/Ojrb4xP7B+dcpoKqT6YsNYOaxKtnyO8XPd+K/JaUbqfTNSJgcJrcTf1iqPy/ zwL874op24w6EKRIm5Klyud0mbpxVoAa01Iu14oKXNJ/LZi8AkYVGxVq4JmUH+Oj6M+M X2Y+8wac7JQZxVYlIXLEJppwXz84BLk8EQLlsnCmF20hvCpYxGkwhy1EQSUiHCrsOgTX lvvejltHyRO0DccsJEJpXSWotnUQjRQ9bJPoxOBybK84sjUi06UsWo/janKeuV0k2km4 MA5cYE/3q+sTvtFdyMX29IK0tHp8RBfpwbxsrHnTMSQYq//koN6iNVxTCHhQrYXkRvht iKdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=evAecY+8s+DFNpn+w9iy+rH5jug9uL7QGhkSB2/Ofuk=; b=HnVQAgaoqynsUUf0BHhDiERfBI7+mpia2X6xilK0+YXHRtllV4DAaP8Tk/jdWU/0ob xlegERjshf2+9ZIJ7zvp0FOmvIgnHY/lZYI9NeKdpLMLrJhJOWL4zaq+FPXKAeeKvS7V RA5P0Uzf7yR/CWZyGUJM+HiALThVIiQYSd9yhoh5lx7C7qplmqQ7fCqBv/hzFOW6j136 i2IxQpw85FCtBJOMECVpOCcQUxwnhDAA/8UYZRZWyqhKjRl7QjDeK5+8fPCq4NHiZyYh U69QXXeVDzVfEFArc989eafnP+eSaguocnPKIyoakW/B3iZmNldBpN/5oLNroARvqSrV 4a9g== X-Gm-Message-State: AMCzsaUHvTTVitP59abcp3Kpy5jT7Hffwr1pWFQNPD/k8cnRFPIlPxyC /7/g5klRzfxj1P9ihHGJqlgibmTVb2ozP+VGRm8b+w== X-Google-Smtp-Source: ABhQp+To+BZW2/lrCg20mvmXQDA82QmuzwZs5pNidNk8VUC7NjZpHyPfLOnEqxHj2TJCL//4lRv9wTAGu8/frFxL7+M= X-Received: by 10.37.45.83 with SMTP id s19mr8008240ybe.400.1508760793475; Mon, 23 Oct 2017 05:13:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 23 Oct 2017 05:12:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 23 Oct 2017 05:12:32 -0700 Message-ID: To: yinxinxing Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f4030435b010256f42055c35bff2" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 12:13:17 -0000 --f4030435b010256f42055c35bff2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing wrote: > Hi Ekr, > > > > For the post-handshake messages in the draft, I have some comments. > > > > 1. When one peer sends NewconnectionID message to the other, it > uses a newly defined handshake type. This new CID is attached in the > payload of the record message. But there must be some information for the > receiver to know which CID is going to be updated. I mean that when sendi= ng > new CID through the NewConnectionID message, the record header should > include the =E2=80=9Cold=E2=80=9D CID, so that the receiver knows which o= ne to replace. > The way that this mechanism works is that it either replaces all of them or supplements the set. I'm not sure that this is the right dynamic, but I'd first want to see some worked through cases. 2. In the draft, is the new CID encrypted? I suggest that the new CID > (for the first time sending) can be encrypted to make sure that an > attacker can not associate a new CID with an old CID. Let=E2=80=99s consi= der a case > where an attacker wants to track an IOT device. If the newly generated CI= D > is not encrypted when updating, the attacker can associate the new CID wi= th > the old one. Then, when the peer sends message with the new CID later, th= e > attacker knows this packet is sent from the victim. If we encrypt the new > CID when updating, this tracking problem can be avoided. > TLS 1.3 post-handshake messages are always encrypted. Another comment is about symmetrical CID. > > 1. Consider a client sends a normal CID (CID length is not zero, > named C-CID) to server, but the server doesn=E2=80=99t wants to use clien= t=E2=80=99s CID > and sends a CID generated by the server (named S-CID) to the client. > No. The CID is for the client's benefit, so why would this be useful? > At the same time, client needs to know server has ignored C-CID (which > means the downlink application message from the server will not include > C-CID), and client will use S-CID in its application message. Will the > draft cover this scenario? > No. -Ekr > > > Yin Xinxing > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Eric Rescorla [mailto:ekr@rtfm.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B410=E6=9C=8813=E6=97= =A5 21:00 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* yinxinxing > *=E6=8A=84=E9=80=81:* tls@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: [TLS] Connection ID Draft > > > > > > > > On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing wrote= : > > Hi Ekr, > > > > Thanks for your effort. The draft looks good. A few comments are listed > below. > > > > 1. Based on the draft, for either DTLS1.2 or 1.3, server can=E2=80= =99t > differentiate whether the packet from client is a =E2=80=9Cconnection ID= =E2=80=9D packet or > a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also > introduced this problem) > > Maybe we can add a new =E2=80=9CContentType=E2=80=9D in the DTLS record f= ormat to help > server identify the =E2=80=9Cconnection ID=E2=80=9D packet. In addition, = you see the length > of the record payload is limited by 2^14-1, this means the first two bits > of =E2=80=9Clength=E2=80=9D is zero. We could utilize this feature and se= t the first two > bits or more bits of CID being one, e.g., 1111=E2=80=A6.(but the CID must= be put > between sequence number and length). When server finds 1111 after sequenc= e > number, it knows this is a =E2=80=9Cconnection ID=E2=80=9D packet. Howeve= r, I don=E2=80=99t know > whether it is proper to use such magic number. In my view, adding new > contenttype may be a choice. > > > > As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID > that would not be a valid length field. This can actually just have the > leading bit set. As we're revising the DTLS 1.3 record format, we would > need to do something different for that. > > > > 2. For DTLS 1.2, there is no NewConnectionID and > RequestConnectionID message. DTLS 1.2 server and client also has the > requirement to request for a new CID, and at present, many products still > use DTLS1.2 and I believe it will continue to be used for a long time eve= n > if TLS/DTLS1.3 is published. My point is that we need a corresponding > method for updating CID for DTLS1.2 too. > > In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really > that excited about putting a lot of effort into enhancing TLS 1.2. The > basic extension works fine for them, but if they want to change CIDs, the= n > they should adopt DTLS 1.3. > > > > I don=E2=80=99t quite understand the following sentences > > =E2=80=9CIn DTLS 1.2, connection ids are exchanged at the beginning of th= e > > DTLS session only. There is no dedicated "connection id update" > > message that allows new connection ids to be established mid-session, > > because DTLS 1.2 in general does not allow post-handshake messages > > that do not themselves begin other handshakes.=E2=80=9D > > > > The only post-handshake messages allowed in DTLS 1.2 are ClientHello and > HelloRequest. > > > > Besides, for CID in DTLS1.3, I think the corresponding responding message= s > of NewConnectionID and RequestConnectionID are also needed to ensure tha= t > the peer has received CID. > > > > No, you use the ACK for these (https://tools.ietf.org/html/ > draft-ietf-tls-dtls13-01#section-7). This is one reason why there is not > a straightforward port to DTLS 1.2 for these messages. > > > > 4. The generation of CID should be more concrete. For example, > using random number or a counter? > > I explicitly did not want to do that, because there are a lot of valid > ways to generate CID. This is also what we did in QUIC. > > > > -Ekr > > > > > > > > Regards, > > Yin Xinxing > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* TLS [mailto:tls-bounces@ietf.org] *=E4=BB= =A3=E8=A1=A8 *Eric Rescorla > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B410=E6=9C=8813=E6=97= =A5 7:14 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* tls@ietf.org > *=E4=B8=BB=E9=A2=98:* [TLS] Connection ID Draft > > > > Hi folks, > > > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > > Comments welcome. > > > > -Ekr > > > > > > > > > --f4030435b010256f42055c35bff2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing <yinxinxing@huawei.co= m> wrote:

Hi Ekr,=

=C2= =A0

For the po= st-handshake messages in the draft, I have some comments.

=C2= =A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When = one peer sends NewconnectionID message to the other, it uses a newly define= d handshake type. This new CID is attached in the payload of the record message. But there must be some information for the receiver= to know which CID is going to be updated. I mean that when sending new CID= through the NewConnectionID message, the record header should include the = =E2=80=9Cold=E2=80=9D CID, so that the receiver knows which one to replace.

The wa= y that this mechanism works is that it either replaces all of them or suppl= ements the set. I'm not sure that this is the right dynamic, but I'= d first want to see some worked through cases.

<= div class=3D"m_9189814412217090133WordSection1">

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In th= e draft, is the new CID encrypted? I suggest that the new CID (for the firs= t time sending) can be encrypted =C2=A0to make sure that an attacker can not associate a new CID with an old CID. Let=E2=80=99s consid= er a case where an attacker wants to track an IOT device. If the newly gene= rated CID is not encrypted when updating, the attacker can associate the ne= w CID with the old one. Then, when the peer sends message with the new CID later, the attacker knows this packet is se= nt from the victim. If we encrypt the new CID when updating, this tracking = problem can be avoided.


<= div>TLS 1.3 post-handshake messages are always encrypted.

=C2= =A0Another comment is about symmetrical CID.

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Consi= der a client sends a normal CID (CID length is not zero, named C-CID) to se= rver, but the server doesn=E2=80=99t wants to use client=E2=80=99s CID and sends a CID generated by the server (named S-CID) to the client.

No. The CID is for the client's ben= efit, so why would this be useful?
=C2=A0

At the same time, client needs to know server has ignored C= -CID (which means the downlink application message from the server will not= include C-CID), and client will use S-CID in its application message. Will the draft cover this scenario?

No.

-Ekr
=C2=A0
<= div class=3D"m_9189814412217090133WordSection1">

=C2=A0

Yin Xinxin= g

=C2= =A0

: Eric Rescorla [mailto:ekr@rtfm.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2017= =E5=B9=B410=E6=9C=8813=E6=97=A5 21:00
=E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing
=E6=8A=84=E9=80=81:<= /b> = tls@ietf.org
=E4=B8=BB=E9=A2=98: Re: [TLS] Connection ID Draft

=C2=A0

=C2=A0

=C2=A0

On Fri, Oct 13, 2017 at 1:11 AM= , yinxinxing <yinxinxing@huawei.com> wrote:

Hi Ekr,

=C2=A0

Thanks for= your effort. The draft looks good. A few comments are listed below.=

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Based on the draft, for ei= ther DTLS1.2 or 1.3, server can=E2=80=99t differentiate whether the packet = from client is a =E2=80=9Cconnection ID=E2=80=9D packet or a standard DTLS = 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also introduced this problem)

Maybe we can add a new =E2=80=9CC= ontentType=E2=80=9D in the DTLS record format to help server identify the = =E2=80=9Cconnection ID=E2=80=9D packet. In addition, you see the length of = the record payload is limited by 2^14-1, this means the first two bits of =E2=80=9Clength=E2= =80=9D is zero. We could utilize this feature and set the first two bits or= more bits of CID being one, e.g., 1111=E2=80=A6.(but the CID must be put b= etween sequence number and length). When server finds 1111 after sequence number, it knows this is a =E2=80=9Cconnection ID=E2=80=9D = packet. However, I don=E2=80=99t know whether it is proper to use such magi= c number. In my view, adding new contenttype may be a choice.

=C2=A0

As I said to Nikos, for DTLS 1.= 2, you can use a specially-constructed CID that would not be a valid length= field. This can actually just have the leading bit set. As we're revis= ing the DTLS 1.3 record format, we would need to do something different for that.

=C2=A0

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0For DTLS 1.2, there = is no NewConnectionID and RequestConnectionID message. DTLS 1.2 server and = client also has the requirement to request for a new CID, and at present, many products still use DTLS1.2 and I believe it will continue= to be used for a long time even if TLS/DTLS1.3 is published. My point is t= hat we need a corresponding method for updating CID for DTLS1.2 too.=

In general, the WG is working o= n TLS 1.3, not TLS 1.2, so I'm not really that excited about putting a = lot of effort into enhancing TLS 1.2. The basic extension works fine for th= em, but if they want to change CIDs, then they should adopt DTLS 1.3.

=C2=A0

I don=E2=80=99t quite understand = the following sentences

=E2=80=9CIn DTLS 1.2, connection = ids are exchanged at the beginning of the

=C2=A0=C2=A0 DTLS session only.= =C2=A0 There is no dedicated "connection id update"

=C2=A0=C2=A0 message that allows = new connection ids to be established mid-session,

=C2=A0=C2=A0 because DTLS 1.2 in = general does not allow post-handshake messages<= u>

=C2=A0=C2=A0 that do not themselv= es begin other handshakes.=E2=80=9D

=C2=A0

The only post-handshake message= s allowed in DTLS 1.2 are ClientHello and HelloRequest.

=C2=A0

Besides, for CID in DTLS1.3, I th= ink the corresponding responding messages of =C2=A0NewConnectionID and Requ= estConnectionID are also needed to ensure that the peer has received CID.

=C2=A0

No, you use the ACK for these (= https://tools.ietf.org/html/draft-ietf-tls-dtls13-01= #section-7). This is one reason why there is not a straightforward port to DTLS 1.2 for these messages.

=C2=A0

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The generation of CID shou= ld be more concrete. For example, using random number or a counter?<= span lang=3D"EN-US">

I explicitly did not want to do= that, because there are a lot of valid ways to generate CID. This is also = what we did in QUIC.

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

Regards,

Yin Xinxin= g

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: TLS [mailto:tls-= bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Eric Rescorla
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2017=E5=B9=B4= 10=E6=9C=8813=E6=97= =A5 7:14
=E6=94=B6=E4=BB=B6=E4=BA=BA: tls@ietf.org
=E4=B8=BB=E9=A2=98: [TLS] Connection ID Draft=

=C2=A0

Hi folks,<= /p>

=C2=A0

I have just posted a first cut = at a connection ID draft.

=C2=A0

Comments welcome.=

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--f4030435b010256f42055c35bff2-- From nobody Mon Oct 23 07:36:04 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E66513F6E5 for ; Mon, 23 Oct 2017 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 h07sPiyAAm7L for ; Mon, 23 Oct 2017 07:35:44 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 89DFD139078 for ; Mon, 23 Oct 2017 07:35:44 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id A716DC0DB0 for ; Mon, 23 Oct 2017 09:35:43 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id CD625C0D74; Mon, 23 Oct 2017 09:35:42 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8B7B092057; Mon, 23 Oct 2017 10:35:42 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5206792053; Mon, 23 Oct 2017 10:35:42 -0400 (EDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (unknown [216.32.180.21]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Mon, 23 Oct 2017 10:35:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ro1boxl6ubJIkZBFOqvOfhrMhengRvjHhtsTXWCpSHY=; b=XfZITeA7vDp+GTKTQ6Ib84xaBkInkfqYwlHBrQZrJneRtb2Zx0OQAupIKxXQXcI0hSOHkkBZ3C7aN636Ayg4HaLaCn3OwF2HbxyzbTGeorWDKFWOinCwgnfbeKuKs7IRGOf2IVr4Cypy/+rku2zn2UNmVfm/I8/Awhyg3h8jZRU= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1366.namprd14.prod.outlook.com (10.172.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 14:35:40 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Mon, 23 Oct 2017 14:35:40 +0000 From: "Ackermann, Michael" To: Ted Lemon CC: Steve Fenter , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIADZUkAgAAIFICAAB86QIAACamAgAD42jA= Date: Mon, 23 Oct 2017 14:35:40 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> In-Reply-To: <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1366; 20:YwtN337gIYQ/Euy0O5KyoM0EV1E91hTQnos8LNInmdt+myDaoxDPQfpsw8GruySnbZL81AxvzBsbrhXYNxmu9NzGAJrur3H6CT+pvUApdDxcphTLFOEbEmFw8fYFNHqbJdQhCadY1VTGuzm+/+EvhzyZ4CFTMAuY5TtRjdizJxo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0c6b3b0c-7226-4a1b-2fc7-08d51a2355a5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1366; x-ms-traffictypediagnostic: CY4PR14MB1366: x-exchange-antispam-report-test: UriScan:(21748063052155)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(3231020)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1366; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(199003)(24454002)(189002)(6306002)(6246003)(6916009)(54356999)(230783001)(55016002)(33656002)(54896002)(9686003)(6116002)(102836003)(86362001)(790700001)(76176999)(236005)(7696004)(99286003)(50986999)(53936002)(66066001)(101416001)(106356001)(3846002)(74316002)(5660300001)(478600001)(2950100002)(72206003)(6506006)(97736004)(77096006)(105586002)(14454004)(2906002)(68736007)(8676002)(2900100001)(189998001)(7736002)(80792005)(25786009)(54906003)(6436002)(4326008)(8936002)(3280700002)(81166006)(81156014)(53546010)(229853002)(19609705001)(3660700001)(39060400002)(316002)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1366; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB13684F18AD75F4AE767CE35CD7460CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 14:35:40.4141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1366 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 9b9ea136-c7f3-481e-b493-1a40c1281884 X-VPM-MSG-ID: 66e69c6c-7a57-41ea-8c8e-b8fd1fd61aca X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 14:35:50 -0000 --_000_CY4PR14MB13684F18AD75F4AE767CE35CD7460CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have. I was only asking what your opinion was, based on that statement in your = reply. From: Ted Lemon =5Bmailto:mellon=40fugue.com=5D Sent: Sunday, October 22, 2017 7:44 PM To: Ackermann, Michael Cc: Steve Fenter ; tls=40ietf.org Subject: Re: =5BTLS=5D Publication of draft-rhrd-tls-tls13-visibility-00 On Oct 22, 2017, at 7:16 PM, Ackermann, Michael = > wrote: And out of curiosity, what is the simpler protocol you are recommending? = I say out of curiosity because switching to a whole different protocol = is not likely to be feasible from any perspective for large enterprises = and the complex, multi-tier protocols that are prevalent. Perhaps you should read the article that Kathleen shared earlier today? The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB13684F18AD75F4AE767CE35CD7460CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

I have. 

I was only asking what your opinion was, based = on that statement in your reply. 

 

From: Ted Lemon = =5Bmailto:mellon=40fugue.com=5D
Sent: Sunday, October 22, 2017 7:44 PM
To: Ackermann, Michael <MAckermann=40bcbsm.com>
Cc: Steve Fenter <steven.fenter58=40gmail.com>; = tls=40ietf.org
Subject: Re: =5BTLS=5D Publication of = draft-rhrd-tls-tls13-visibility-00

 

On Oct 22, 2017, at 7:16 PM, Ackermann, Michael = <MAckermann=40bcbsm.com> = wrote:

And out of curiosity,  what is the simpler = protocol you are recommending?    I say out of curiosity = because switching to a whole different protocol is not likely to be = feasible from any perspective for large enterprises and the complex, multi-tier protocols that are prevalent. 

 

Perhaps you should read the article that = Kathleen shared earlier today?

 


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB13684F18AD75F4AE767CE35CD7460CY4PR14MB1368namp_-- From nobody Mon Oct 23 08:40:58 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB1E1393A1 for ; Mon, 23 Oct 2017 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjHxZSoT9tPJ for ; Mon, 23 Oct 2017 08:40:55 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE45139394 for ; Mon, 23 Oct 2017 08:40:55 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id b15so22478988qkg.9 for ; Mon, 23 Oct 2017 08:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JaXZ0YVExgrJDiT08IEirPLHCmZttMkqgpCBEFK8Fk0=; b=RWcams2ef3E6Hh+9PTj7G8PtYnM/9BfSQJMqnzmYgbxW9BK4ErIEnq95XtNXhHuGDo Ol40UFCW/ntuM1272lpWFGdbsIQYvvEyiEfE+83yMlmTaOfVr83qV97DcXV+avGoIoJ1 ebG2cms01H1tlPZ9KIhdNmjddrSV2a4h4tfkEv1PnWX25dXT75ak99e+QXkJXgQpP6dX g6kNHvOqbjtS6uf91pLKvmtP0MKJ7WMD1XPHP2I5lQs+CaZRDDj4zU+Yos3M7z1DLumI gN405cvPFYPPRiJsZwKROeJ+CrBIUDH/eBqXN3Noz0jWs6VZhMkpFvmDm3KvUErIy/dr YZhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JaXZ0YVExgrJDiT08IEirPLHCmZttMkqgpCBEFK8Fk0=; b=NvT9BwhyxbW9MLV4l/V77X1PY9v1Swu3uA69qqMr5M5xU2XYx2J3xAkR+nAv/QcvdP VNCAhOsbZfKAmwx1ymrT/HaXXh+T7SCp3mquVhbL/l7AXKBzNc3/f/E4R7Lnd4yBO0Ae b5bWUU0Oo+ZkZaitB2Du4bFxOC30MnD+jZXoQhYcpBSZCVt3w/CIZLaT8iovrDlA7u56 50BFM/v5f5eWV8XybrJRiiEw5/N6KF8O66E79jGxqvb93ns6sb+KvAzdSHEt8+Goz6Kj HKYcua7oDKhU5Ll14m9qDkM9kd2q+mXvLUBzi+LgXSTPJG/dcsPipDCd5JZrG8iqGYVp TQ/Q== X-Gm-Message-State: AMCzsaX3+QJF73IOnyYBoinh4kSn2dgGwRf/5fF/eSpAfP37APs3ywO1 AdDwle1qE0JZo15eoZYpmyw1fbL7x0g= X-Google-Smtp-Source: ABhQp+Quro1exyBFxUHRX127gRfIe7rhH4YRdCGNfIBxL9+iMHFg4QJjcU67houB3OSoMG5sh/6KPQ== X-Received: by 10.55.148.70 with SMTP id w67mr19654091qkd.102.1508773254233; Mon, 23 Oct 2017 08:40:54 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id i12sm4917616qkh.83.2017.10.23.08.40.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 08:40:53 -0700 (PDT) From: Ted Lemon Message-Id: <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_31B2B814-4A9C-48E9-8475-272BB62CAD49" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Oct 2017 11:40:51 -0400 In-Reply-To: Cc: Steve Fenter , "tls@ietf.org" To: "Ackermann, Michael" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 15:40:57 -0000 --Apple-Mail=_31B2B814-4A9C-48E9-8475-272BB62CAD49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2017, at 10:35 AM, Ackermann, Michael = wrote: > I was only asking what your opinion was, based on that statement in = your reply.=20 With respect, Michael, I gave my opinion in the message to which = Kathleen replied, so your assertion that you have been reading these = messages doesn't seem to be reflected in the dialog we are having.= --Apple-Mail=_31B2B814-4A9C-48E9-8475-272BB62CAD49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 23, 2017, at 10:35 AM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
I was only asking what your opinion was, based on that = statement in your reply. 

With respect, Michael, I gave my opinion in = the message to which Kathleen replied, so your assertion that you have = been reading these messages doesn't seem to be reflected in the dialog = we are having.
= --Apple-Mail=_31B2B814-4A9C-48E9-8475-272BB62CAD49-- From nobody Mon Oct 23 09:14:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C83A1394FB for ; Mon, 23 Oct 2017 09:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=gbL9rYKJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rxVhR0Oy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQg1vZBoZ1dh for ; Mon, 23 Oct 2017 09:14:50 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA555137ED6 for ; Mon, 23 Oct 2017 09:14:49 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2B12B20C8A; Mon, 23 Oct 2017 12:14:49 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 23 Oct 2017 12:14:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=MOA28yOiGFjODXW9bE7baGPWo+mN9/A57m8TAS6YaI8=; b=gbL9rYKJ jQkT9c68GYiO8WLohZjBfkmV/cS8dIFsQCJe6Ocyu+B1/qO4j9nVhAavNln48fJ7 hYtB51s6Cd5lV+hq2dWz9W8ouwvmVTEWQ353EWQms0YMZWgXIrnLlviAYrtz+GoH sp4abK1BPrHbydYbJv1ZHZXlAdIF4k/xdg+ZnIob7g7gYIkoSJTagtUfOAB3j+QH B8otptbI/EGrdBmjTP93JamYuuEuYk6J6++xqO+rpSOB3g6QWEcrhwcQuxVmS30F 5K3Zh1ehtl6FQ79Jw/nKjq3XQu7zAnh9o/skDWy14wcZWX8ogN4aKEfcMXTP/vRz cDShtacMaENypg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=MOA28yOiGFjODXW9bE7baGPWo+mN9 /A57m8TAS6YaI8=; b=rxVhR0OywuavEXqW827YzZ6y58jzqfksDieb1v/pBH3dw wcPtVoqI7yYQFunkuxr7gfiqTKGj8qZfxGIs2nVz9sxdBZMHFI5NwevTHdz3KvLx Y2y3FlDsWTreXOguWFzXiN8Wioh3P3bOOrI259WVA3x4HmWrOSe5L+lZmnWPQYZN 9DSCIrA7CV4enkieWSV8EAUunePSHn7ejJdh2UPFry3TMCaBI0DeBMVrPURCPcQi 3jov0LyE9bq3/ZFcKKiBEUBQW6mdS8N9pFrsffhFhFnTJ51WlANK1ss1e6iBZhDK EqpeHAat7pDF693oFV+/H01eDIwKeK3yiOc83bf0A== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 4D5D9248D1; Mon, 23 Oct 2017 12:14:48 -0400 (EDT) To: Steve Fenter , Christian Huitema Cc: Paul Turner , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <7ed40a30-196f-d280-59a5-814a5ea4676e@huitema.net> <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> From: Peter Saint-Andre Message-ID: <2f04f18b-5f74-55c3-e140-ebc1d2cdfaf4@stpeter.im> Date: Mon, 23 Oct 2017 10:14:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6ce0OdBTbS8jaxMIWUUSiAMoLncOBkn2f" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:14:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6ce0OdBTbS8jaxMIWUUSiAMoLncOBkn2f Content-Type: multipart/mixed; boundary="mX8bT9c60s0GLExMR0BnF6uLIha29phj2"; protected-headers="v1" From: Peter Saint-Andre To: Steve Fenter , Christian Huitema Cc: Paul Turner , "tls@ietf.org" Message-ID: <2f04f18b-5f74-55c3-e140-ebc1d2cdfaf4@stpeter.im> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <7ed40a30-196f-d280-59a5-814a5ea4676e@huitema.net> <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> In-Reply-To: <13B309B8-D380-450D-9792-81DFC22C03F0@gmail.com> --mX8bT9c60s0GLExMR0BnF6uLIha29phj2 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/22/17 5:26 PM, Steve Fenter wrote: > I know of a number of large enterprises in verticals including financia= l, health care, retail, and government, across multiple countries, who ar= e using packet payload inspection within their data centers. Most of the= se enterprises are reluctant to step forward in a public forum and reveal= their internal network structure and their internal security and monitor= ing practices. This gives the false impression that out of band decryptio= n of TLS is not a big deal. It is in fact mission critical to a significa= nt number of large enterprises. >=20 > I have been saying to anyone who will listen that the IETF needs a priv= ate forum for enterprises, to enable them to come forward and discuss the= ir real requirements. Without this input the IETF is trying to architect = and engineer solutions without knowing the complete set of requirements, = at least on the enterprise side. This results in sub-optimal design deci= sions (from an enterprise perspective), which in this case will break mis= sion critical enterprise monitoring and troubleshooting systems. The IETF doesn't run private forums behind closed doors. You'd need to do that kind of work elsewhere (these large enterprises could, of course, start their own industry forum, where they could work in ways that the IETF doesn't). > We've already experienced what a rollout of TLS 1.3 will be like, at mo= re than one enterprise, when certain vendors decided to move Diffie Hellm= an ciphers to the top of their priority list on a code upgrade. This caus= ed severity one outages of critical monitoring systems.=20 It sounds as if different internal teams might not have been communicating well about the rollout of those new cipher suites. Operational issues in large enterprises are not a problem that requires protocol work. > This means that critical applications depend on these monitoring syste= ms, and if the monitoring system is down the application is completely do= wn. This is not the outcome we want when TLS 1.3 is rolled out, but it is= what we are headed for. Enterprise monitoring should be tested as part o= f the operational TLS 1.3 testing before TLS 1.3 is approved as a standar= d, and TLS 1.3 should not be approved if enterprise monitoring breaks. Operational testing is always good, but very strong arguments need to be made for the latter claim. Among other things, you're adding a new requirement to the Internet Standards Process, which would necessitate IETF consensus on changes to RFC 2026! > The only other option being presented to enterprises is that we continu= e to run on a TLS spec that is nine years old, and then continue running = it until it is 14 to 19 years old. It makes no sense to me to put out a T= LS 1.3 standard, but say that enterprises cannot upgrade to it. There are many options, some of which Kathleen outlined in her blog post. It's not helpful to say there is just one option when we haven't fully explored either the problem space or the solution space. And by "we" I mean especially those who are claiming the need for TLS visibility= =2E Peter --mX8bT9c60s0GLExMR0BnF6uLIha29phj2-- --6ce0OdBTbS8jaxMIWUUSiAMoLncOBkn2f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlnuFXYACgkQ6gakkSvF ralolRAAotICK1MHwDrqFL4MggYucDTHBrfQzZhUU631mJyPOn9EYLqXA9nQwYIf UEtzhe3MtoKgduptlPf0yxRR7Mta7if/Mro0atbN4P2Rfx96DPd9hPaGfJIbqoag PSsy3JoAqowgRBPVdB5dO00Hvdonm6wovkBbLj/czxMLbEov4yreCojsWGVM/92Z B4PgRYn36sG7CR5F0lkUnu85qScePLhCNH5cYhXcJCUr4C6N20sNRjFe+u1yra5K 3OLQWon8KuCei65oVZILcubI/EgY+i3XjlZHOziAW9vcixHefYgfvkgKK6sZQOtT RIDs9MXxXSuMXX5lQeghM2otGLTRIpbg9h9nB/xlm+gnVVWAtPTeanKrASLF+nrv yVrKLX1IfMN+ufy3bJmrrFaikQgphmcjGmwkqzoBHkhxPAf10ep5l1IzDkmKnBc5 OMs325zzz9EBEz8SPJNY5iZW4S1JCBqiBve2zBD6HET+SAy2zFlFz0Cck5WJLlkS BpaYy0wlZ5YVnQGBhRFHdemtoq4UKEvE4KDzMXAUK8Kem7SxqPStJ4lhu2dktyVy N3+2tesIbdLGUYnUUjNdK4eUGz3Rpxw3mP1chJDWA4ejYekMwUqSIk7Hnc/s8bdl Ogux2AKStONlY1qGQ1DLf+B5d+/0qP0nzLUadFot6N44gcyiueI= =xP5E -----END PGP SIGNATURE----- --6ce0OdBTbS8jaxMIWUUSiAMoLncOBkn2f-- From nobody Mon Oct 23 09:22:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC1F13954E for ; Mon, 23 Oct 2017 09:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 DQPp8CPYYzvs for ; Mon, 23 Oct 2017 09:22:29 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 F392F137ED6 for ; Mon, 23 Oct 2017 09:22:28 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 60340C0DBC for ; Mon, 23 Oct 2017 11:22:28 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 753C7C0DA4; Mon, 23 Oct 2017 11:22:27 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2FCEEFE048; Mon, 23 Oct 2017 12:22:27 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E00DDFE066; Mon, 23 Oct 2017 12:22:26 -0400 (EDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (unknown [207.46.163.115]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 23 Oct 2017 12:22:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gHDhE4p/5MU6Ni8LM9Qwxicj7jDAlKzhNBvN1Q8RApw=; b=TT48sNi//kRGYlNwu8GtrEv33MGzTVJMZymCb+1sMScHxk8XNSfQMNIpzG+fdV/MxsG5SAn6FWeMmf2gcq5eDOVVI1ze/yMlAqQOqyrJTR6wJWXkpljQeY3qTRDLJ6wC7PedcKspNLWMA11WPnT6V9aCVFP1bV9y6pFSsaAgYZM= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 16:22:24 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Mon, 23 Oct 2017 16:22:24 +0000 From: "Ackermann, Michael" To: Ted Lemon CC: Steve Fenter , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIADZUkAgAAIFICAAB86QIAACamAgAD42jCAABKIgIAACV1A Date: Mon, 23 Oct 2017 16:22:24 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> In-Reply-To: <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 20:SbTIQMQBz0Z3Hp2Vz1AjP0P957bzwr/wafUCVMqsfhqCbPw/4zmn39AxW/rOnZ82FQRTlEiuadksIyZPYt7kzKQG+6uHc8PdsxYeiCb5juAiQPL5oKMzdGClJUAxBgB/CzMF8boZp0rgiV5rbG+b2lrzBw41WhCGUy1uPxtAT1w= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 03a679fd-ce22-4d90-f1c4-08d51a323ee0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1368; x-ms-traffictypediagnostic: CY4PR14MB1368: x-exchange-antispam-report-test: UriScan:(21748063052155)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(3231020)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1368; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(24454002)(189002)(199003)(790700001)(6436002)(81166006)(80792005)(5660300001)(8936002)(81156014)(14454004)(6246003)(54906003)(3846002)(99286003)(236005)(316002)(6116002)(68736007)(55016002)(8676002)(25786009)(66066001)(102836003)(54356999)(7736002)(3280700002)(53936002)(2906002)(86362001)(101416001)(7696004)(9686003)(53546010)(97736004)(50986999)(74316002)(6916009)(6506006)(230783001)(106356001)(54896002)(2900100001)(93886005)(2950100002)(189998001)(105586002)(33656002)(76176999)(19609705001)(4326008)(72206003)(229853002)(77096006)(39060400002)(478600001)(6306002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB13680B6D5726D940C4C51B4BD7460CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 16:22:24.7315 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 75f4f6fb-1bf6-4949-8914-b3300899b88d X-VPM-MSG-ID: b71a8560-4c77-4223-86c3-0cab818c4032 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:22:31 -0000 --_000_CY4PR14MB13680B6D5726D940C4C51B4BD7460CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am merely trying to understand if there are any constructive suggestions = amongst all these discussions, that we should consider. Your comment was =22It would be better to use a simpler protocol,=22 My question back to you was WHAT SIMPLIER PROTOCOL? If your answer to my question, is to refer to Kathleen's document, then = she discusses a few things. If I have to guess which one of those you = may be referring to, I will guess IPSEC? Is this correct? Are you suggesting we should convert to IPSEC? If that was stated in any previous correspondence, I did not see it. From: Ted Lemon =5Bmailto:mellon=40fugue.com=5D Sent: Monday, October 23, 2017 11:41 AM To: Ackermann, Michael Cc: Steve Fenter ; tls=40ietf.org Subject: Re: =5BTLS=5D Publication of draft-rhrd-tls-tls13-visibility-00 On Oct 23, 2017, at 10:35 AM, Ackermann, Michael = > wrote: I was only asking what your opinion was, based on that statement in your = reply. With respect, Michael, I gave my opinion in the message to which Kathleen = replied, so your assertion that you have been reading these messages = doesn't seem to be reflected in the dialog we are having. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB13680B6D5726D940C4C51B4BD7460CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

I am merely trying to understand if there are = any constructive suggestions amongst all these discussions, that we should = consider. 

 

Your comment was

&=238220;It would be better to use a simpler = protocol,&=238221;

 

My question back to you was WHAT SIMPLIER = PROTOCOL? 

 

If  your answer to my question,  is = to refer to Kathleen&=238217;s document,  then she discusses a few = things.   If I have to guess which one of those you may be = referring to,  I will guess IPSEC?

Is this correct?   Are you suggesting = we should convert to IPSEC? 

 

If that was stated in any previous = correspondence,  I did not see it. 

 

From: Ted Lemon = =5Bmailto:mellon=40fugue.com=5D
Sent: Monday, October 23, 2017 11:41 AM
To: Ackermann, Michael <MAckermann=40bcbsm.com>
Cc: Steve Fenter <steven.fenter58=40gmail.com>; = tls=40ietf.org
Subject: Re: =5BTLS=5D Publication of = draft-rhrd-tls-tls13-visibility-00

 

On Oct 23, 2017, at 10:35 AM, Ackermann, = Michael <MAckermann=40bcbsm.com> = wrote:

I was only asking what your opinion was, based = on that statement in your reply. 

 

With respect, Michael, I gave my opinion in the = message to which Kathleen replied, so your assertion that you have been = reading these messages doesn't seem to be reflected in the dialog we are = having.


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB13680B6D5726D940C4C51B4BD7460CY4PR14MB1368namp_-- From nobody Mon Oct 23 09:25:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F19C13954E for ; Mon, 23 Oct 2017 09:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH9gkP8ACdq4 for ; Mon, 23 Oct 2017 09:25:34 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFFB139553 for ; Mon, 23 Oct 2017 09:25:34 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id p1so26884119qtg.2 for ; Mon, 23 Oct 2017 09:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=inYFcDHwhiY+xHLjj3nWZoUjhtvTzQHW9shisSDzzSs=; b=XJD7bK9oD75iMcfUn+P2N8Nw6Y0JgtzeDe33SbKZ92nQK0Fv0fjRCp1KoGvKXG8GXv 6UyPc7X9DzJqBu8I1SExVP7V/DDBfGWKrK6NSWLS3YZCQuiWtMDVDM/TrQzAX8RwPt+o e71/Tv/KPTgBMx7sUy8sKATwKv4u9Lp83kpObV3k8kcrx6XQ2+yBqUwi2vE17HPv4LHe Bkmfa9u3uZfJZ8GgHbKGbNM1SDMxfHNJGriPbpJ72ZQkfDTm8Zjd1F+1GPb3OZSB4BGv 2k788xQgVuf2HstPYNOjXVfq+ZhedpXXTXMn3yy12Pv9R+7vVh75Cy5L30w8fR24WW9R ZcVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=inYFcDHwhiY+xHLjj3nWZoUjhtvTzQHW9shisSDzzSs=; b=sAroBLW1P1V/Hq7IWTbIAIJ9dNNMdG9n5QKqpkFQTan3OaD+bkmt/9bA5dO0+8vuIx yKiGbFlnw08VtZItintiHbiel5+42j7CKiSnA5urgragXlN3dUvi5cK4sSipEwllInjb tAbePcOzHVgCzpzXllAT8tEoWz7TQvNPTU3elGvQamm0K6hTt20UvRsU0bMc+GzAw74H ItzvAdoLuxQGxk+vE4xZ8Y7O4XIASPXh5h4QcK89EKNiZ/1hVYxjbTmtHTMgueIEGoTU tVn+e5sM7UJmCCL2AUlSdFElCty0IQUL2M8DZZe4OPIa19YQ0Hqqj4Ed7bXA325q00Me Q6Bg== X-Gm-Message-State: AMCzsaVfVF6ewR3Pk1sHKBrIK2I/6cwZP1oUpUhIz+geIpI+64Xwj4mS v/apdhbNxTlt+xQgQHSUYYzulwMO X-Google-Smtp-Source: ABhQp+TUven+HfJAJLOxnWGn4gE1IPTfuxqudcNySZ8oj5mEOZ4tT0uM4KpOk9mrvZAGjDOMniKKvw== X-Received: by 10.200.44.70 with SMTP id e6mr21134111qta.197.1508775933809; Mon, 23 Oct 2017 09:25:33 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:c167:7d58:9571:ad31? ([2601:18f:801:600:c167:7d58:9571:ad31]) by smtp.gmail.com with ESMTPSA id i12sm4976615qkh.83.2017.10.23.09.25.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 09:25:33 -0700 (PDT) From: Ralph Droms Message-Id: <90235494-D1CA-4ABF-9AAC-4F8252927DCB@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E209BEBA-4327-4BD2-BC4B-C17B8E5C4713" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Oct 2017 12:25:32 -0400 In-Reply-To: <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> Cc: IETF TLS To: Ted Lemon References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:25:36 -0000 --Apple-Mail=_E209BEBA-4327-4BD2-BC4B-C17B8E5C4713 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 22, 2017, at 2:40 PM, Ted Lemon wrote: >=20 > On Oct 22, 2017, at 1:54 PM, Russ Housley > wrote: >> No one is requiring TLS 1.3 that I know about. However, there are = places that require visibility into TLS. I will let one of the people = that works in a regulated industry offer pointers to the documents. >=20 > What they require is visibility into contents of the flow that they = are using encryption to protect. Right now, the protocol they are = using is TLS 1.1 or TLS 1.2. The right thing for them to do if they = continue to need this visibility and are no longer permitted to use TLS = 1.2 is to use IPsec+IKE, Is there running code that demonstrates the IPsec+IKE can be deployed = and operated at scale in the sort of environment the enterprise network = tips have described to us? > or some protocol that is designed for this use case, not to take a = protocol designed specifically for securing flows from on-path = eavesdropping and create a mode where it is easier to wiretap. ...assuming the necessary lead time and support from vendors to = implement another protocol. > There is no reason other than momentum for them to switch to TLS 1.3 = when it doesn't address their use case. But TLS 1.3 addresses *part* of the use case, as it does provide better = security and it represents an incremental change to the current = deployment and operation practices. =20 - Ralph >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_E209BEBA-4327-4BD2-BC4B-C17B8E5C4713 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 22, 2017, at 2:40 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Oct 22, = 2017, at 1:54 PM, Russ Housley <housley@vigilsec.com> wrote:
No one is requiring TLS 1.3 that I know = about.  However, there are places that require visibility into TLS. =  I will let one of the people that works in a regulated industry = offer pointers to the documents.

What they require is visibility into contents = of the flow that they are using encryption to protect.   Right now, = the protocol they are using is TLS 1.1 or TLS 1.2.   The right = thing for them to do if they continue to need this visibility and are no = longer permitted to use TLS 1.2 is to use = IPsec+IKE,

Is = there running code that demonstrates the IPsec+IKE can be deployed and = operated at scale in the sort of environment the enterprise network tips = have described to us?

or some protocol that is designed for this = use case, not to take a protocol designed specifically for securing = flows from on-path eavesdropping and create a mode where it is easier to = wiretap.

...assuming the necessary lead time and support from = vendors to implement another protocol.

There = is no reason other than momentum for them to switch to TLS 1.3 when it = doesn't address their use case.

But TLS 1.3 addresses *part* of the use case, as it = does provide better security and it represents an incremental change to = the current deployment and operation practices.  

- Ralph


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_E209BEBA-4327-4BD2-BC4B-C17B8E5C4713-- From nobody Mon Oct 23 09:26:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F6013954B for ; Mon, 23 Oct 2017 09:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 uwqcHkWPSweP for ; Mon, 23 Oct 2017 09:26:41 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA77913954E for ; Mon, 23 Oct 2017 09:26:40 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9NGQbaJ004804; Mon, 23 Oct 2017 17:26:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=FecKYyG+6xr4hmjgDm7eYmUv/mm5j7/tGGbveEzBuLI=; b=GuczZMoMTyHHQQyYmIuk4iaNRLKalPW3xjPxx1YhSW8HXDN+byH7Bj303Cyw0MvPaKC+ ShnMvpxWv8ae4EK14+yoRxaFOkYjPBC3yK0ZtAav8abu3yjBOex8TPi7b+XsEwMDP4WC YfiTFnXwO+XmDafp8psOj0nI3TP5gLau6C8lYoNQJr5P8MbahwYbcNMxkklZI9hYelJ5 Ehkk8JyCMeCTY/YeVMWMMctUBNr0vH+QaUGriogB2QqkHS+fZNgyXptFSR7yiq7rFf6w w2aC2m9dqn/WgdqIkbKt6wKrQUdLmyk7I7tcHNMUxayIzIltbLAKkQn6DUweCgoWeIiW Bg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2dqwvsx8bd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 17:26:36 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9NGQW19014568; Mon, 23 Oct 2017 12:26:35 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dr1judxf6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 12:26:35 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 23 Oct 2017 12:26:34 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 23 Oct 2017 12:26:34 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 23 Oct 2017 12:26:34 -0400 From: "Salz, Rich" To: "Ackermann, Michael" , Ted Lemon CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABAMAgAAHdQCAAASJAIADZUoAgAAIFICAACFZAIAAB4qAgAD5KwCAABI3gIAAC5wAgAABKIA= Date: Mon, 23 Oct 2017 16:26:33 +0000 Message-ID: <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.60] Content-Type: multipart/alternative; boundary="_000_0D75E20C135D45BCABE45C737B7491C9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230231 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230231 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:26:43 -0000 --_000_0D75E20C135D45BCABE45C737B7491C9akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBhbSBtZXJlbHkgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaWYgdGhlcmUgYXJlIGFueSBj b25zdHJ1Y3RpdmUgc3VnZ2VzdGlvbnMgYW1vbmdzdCBhbGwgdGhlc2UgZGlzY3Vzc2lvbnMsIHRo YXQgd2Ugc2hvdWxkIGNvbnNpZGVyLg0KDQpZZXMuICBUbyByZXBlYXQgbXlzZWxmLCBoZXJlIGFy ZSB0d286DQoNCg0KICAxLiAgQ29udGludWUgdG8gdXNlIHlvdXIgZXhpc3Rpbmcgc2NoZW1lcy4g WW91IHdvbuKAmXQgaGF2ZSB0byBjaGFuZ2UgdG8gVExTIDEuMyBmb3IgeWVhcnMuDQogIDIuICBN b2RpZnkgeW91ciBzZXJ2ZXJzIGFuZCBsb2dnaW5nIGluZnJhc3RydWN0dXJlIHRvIHJlcG9ydC1v dXQgdGhlIFBGUyBrZXlzIGFuZCB1c2UgdGhlbQ0KDQpEbyB5b3UgbmVlZCBtZSB0byBwb3N0IGxp bmtzIHRvIG15IG1lc3NhZ2VzPw0KDQo= --_000_0D75E20C135D45BCABE45C737B7491C9akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8F76F92FE485FE4E82FE656316A73AA7@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4 MzA1NjUxMTU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi01MDIzNDc0NjggMTEwNjU1NTY5MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlm O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE4MjU1ODE1NDk7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDUxMzYyNDMwIDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JIGFtIG1lcmVseSB0cnlp bmcgdG8gdW5kZXJzdGFuZCBpZiB0aGVyZSBhcmUgYW55IGNvbnN0cnVjdGl2ZSBzdWdnZXN0aW9u cyBhbW9uZ3N0IGFsbCB0aGVzZSBkaXNjdXNzaW9ucywgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIu Jm5ic3A7DQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLiZuYnNwOyBUbyByZXBl YXQgbXlzZWxmLCBoZXJlIGFyZSB0d286PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0 YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+Q29udGludWUgdG8gdXNlIHlv dXIgZXhpc3Rpbmcgc2NoZW1lcy4gWW91IHdvbuKAmXQgaGF2ZSB0byBjaGFuZ2UgdG8gVExTIDEu MyBmb3IgeWVhcnMuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+TW9kaWZ5IHlv dXIgc2VydmVycyBhbmQgbG9nZ2luZyBpbmZyYXN0cnVjdHVyZSB0byByZXBvcnQtb3V0IHRoZSBQ RlMga2V5cyBhbmQgdXNlIHRoZW08bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8geW91 IG5lZWQgbWUgdG8gcG9zdCBsaW5rcyB0byBteSBtZXNzYWdlcz88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_0D75E20C135D45BCABE45C737B7491C9akamaicom_-- From nobody Mon Oct 23 09:28:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E691395E9 for ; Mon, 23 Oct 2017 09:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BA8PNVoeXvVu for ; Mon, 23 Oct 2017 09:28:46 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B346313955B for ; Mon, 23 Oct 2017 09:28:46 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9NGQirr025659; Mon, 23 Oct 2017 17:28:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Ml06neIkumHdliXPdxtC+u5vYHLzdWnA/79OoqQnAPg=; b=MhgoUK9hKsm4p0vmKkvwu3vdsVtMdcuqb+ns5u3+bdAOlHNoRLQjTt4CMWH/YOfY0Ki/ JIKn8uwsldybSodLHkhLZJ2aMpWESJZTq8pWqi4RKAipAImZftAHXJQHCkKlGwVQbueG FkZuvVNKUse1CnNJjB6rrRDXYmTS4POjtPoNeJi/9h3rPhup871rPCVoo5jKjVupBOVq jBPrz5cTBLjmjvRkxXioJNqtRglL+oEFaglsB+okm/behUxtluOR1jBT8IcloZ2jtwMI hempYxWFH2NiN94w/TsHy42sYbI0UYCLsraBTYUEaAIhQuBH+DbB8ubEJQ+K+YqGRt0O OQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2dqwg4pr0g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 17:28:41 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9NGQW0x014577; Mon, 23 Oct 2017 12:28:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dr1judxn0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 12:28:40 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 23 Oct 2017 12:28:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 23 Oct 2017 12:28:39 -0400 From: "Salz, Rich" To: Ralph Droms , Ted Lemon CC: IETF TLS Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABAMAgAAHdQCAAB23gIAAPAIAgALfU4CAAA0MgIABbJAAgAAA34A= Date: Mon, 23 Oct 2017 16:28:39 +0000 Message-ID: <0B1FF177-296D-4E7E-BA37-6A4F62481FF5@akamai.com> References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> <90235494-D1CA-4ABF-9AAC-4F8252927DCB@gmail.com> In-Reply-To: <90235494-D1CA-4ABF-9AAC-4F8252927DCB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.60] Content-Type: multipart/alternative; boundary="_000_0B1FF177296D4E7EBA376A4F62481FF5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230231 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230231 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:28:48 -0000 --_000_0B1FF177296D4E7EBA376A4F62481FF5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSXMgdGhlcmUgcnVubmluZyBjb2RlIHRoYXQgZGVtb25zdHJhdGVzIHRoZSBJUHNlYytJ S0UgY2FuIGJlIGRlcGxveWVkIGFuZCBvcGVyYXRlZCBhdCBzY2FsZSBpbiB0aGUgc29ydCBvZiBl bnZpcm9ubWVudCB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrIHRpcHMgaGF2ZSBkZXNjcmliZWQgdG8g dXM/DQoNCklCTSBoYXMgc3VwcG9ydGVkIGZ1bGwtc2NhbGUgSVBzZWMvSUtFIGRlcGxveW1lbnQg b24gU3lzdGVtL3ogZm9yIGEgdmVyeSBsb25nIHRpbWUsIGFuZCBpdCBhbHNvIGhhcyBhbiBpbnRl cmVzdGluZyB3YXkgb2Ygc2hhcmluZy9lc2Nyb3dpbmcgVExTIHNlc3Npb24ga2V5cyB3aXRoIENp c2NvIGJveGVzLg0KDQpTbyBpZiB3ZSBjYW4gYXNzdW1lIHRoYXQgbWFueSBvZiB0aGVzZSBsYXJn ZSBlbnRlcnByaXNlcyBoYXZlIGEgbWFpbmZyYW1lLCB0aGVuIHRoZXkgaGF2ZSB0aGUgcHJvb2Zw b2ludHMgYmVoaW5kIHRoZWlyIG93biBmaXJld2FsbC4NCg0K --_000_0B1FF177296D4E7EBA376A4F62481FF5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4 ODYxODQ5MDg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xMDA1NDIyNzg2IDY3Njk4Njk5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JcyB0aGVyZSBydW5uaW5nIGNvZGUgdGhhdCBkZW1v bnN0cmF0ZXMgdGhlIElQc2VjJiM0MztJS0UgY2FuIGJlIGRlcGxveWVkIGFuZCBvcGVyYXRlZCBh dCBzY2FsZSBpbiB0aGUgc29ydCBvZiBlbnZpcm9ubWVudCB0aGUgZW50ZXJwcmlzZSBuZXR3b3Jr IHRpcHMgaGF2ZSBkZXNjcmliZWQgdG8gdXM/PG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSUJNIGhhcyBzdXBwb3J0ZWQgZnVsbC1zY2FsZSBJ UHNlYy9JS0UgZGVwbG95bWVudCBvbiBTeXN0ZW0veiBmb3IgYSB2ZXJ5IGxvbmcgdGltZSwgYW5k IGl0IGFsc28gaGFzIGFuIGludGVyZXN0aW5nIHdheSBvZiBzaGFyaW5nL2VzY3Jvd2luZyBUTFMg c2Vzc2lvbiBrZXlzIHdpdGggQ2lzY28gYm94ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNv IGlmIHdlIGNhbiBhc3N1bWUgdGhhdCBtYW55IG9mIHRoZXNlIGxhcmdlIGVudGVycHJpc2VzIGhh dmUgYSBtYWluZnJhbWUsIHRoZW4gdGhleSBoYXZlIHRoZSBwcm9vZnBvaW50cyBiZWhpbmQgdGhl aXIgb3duIGZpcmV3YWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0B1FF177296D4E7EBA376A4F62481FF5akamaicom_-- From nobody Mon Oct 23 09:35:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0CF138103 for ; Mon, 23 Oct 2017 09:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8x-ifvrxjnK for ; Mon, 23 Oct 2017 09:35:22 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 58FD1137E0B for ; Mon, 23 Oct 2017 09:35:22 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id 1so26925215qtn.3 for ; Mon, 23 Oct 2017 09:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1u2URdMfp7jLuAbtUwRBvGHEg08rptEuYXZ/88unbHo=; b=gAgIAwXLMfO+yf+FwddLiRY3kkKEsJwYOecDzAtcKQ3dvyOB5VpV4wmg91XLNSKF63 VHZCE4dmzpLqDWQx3YWTwF1LFZQLWdbU75l9kG30zffapgpnM91fe/geHC/HQhv3avdH EcUiftc/5p4bBBvbhvShvuMTpxjJCuLV2TQQfvT1nfLaEKG3jBg8IEZhNxesgnyupNQy xsUJMXsT3RaXnXzzee4VUXjqynLBVovVXaeYuUltp/HzeOyA8N9+tFBjvF6Tc8R5vTmU WEPq0Q4uzmjVfcX+RKw2ec666mFFAS7xDn1ryCP82kI0aSCsWNuf8BSehnQ+/XGTueTC 7w6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1u2URdMfp7jLuAbtUwRBvGHEg08rptEuYXZ/88unbHo=; b=nF6axoLI+hnjpfU1567qLxVc1BIysQPQkuX/Dujml675/Qjk5jb9x+2LRNCY8tPSk/ KhDMGDykDkpto2qfUaXoyM5n7JW23ybT523xBiybKzGVv4Jo60by08yujkx4XIyVQ1fp U7OLim8hUS5C0tsRbVbF08RHOFWkgbQ//lqOECdwto+WLBrfcJbpBigEKAC83q08hfaj yParWewT3Nd6flBnIfA54O2voW0izrIV1PkD47dEedCQu/jVIbkAn5yH8r1xfYXW/Mty 5mT2pXApO+ifffB1uAgiK2UtfY/gMYcomYCW9WeO0Kte0KqQK30ukjVVdNA9r3lj2Dmh iv3w== X-Gm-Message-State: AMCzsaW43QO3ImzLpgs6rsEAcrSVkPh0vSXnARSPOhdWpyPdUGQTj3SV lQ5rgptKxveaWCAfFSCPsFsmDA== X-Google-Smtp-Source: ABhQp+TzGJTQ6z14MJxwpMk1BCMe9B1xDFy9Vx3Su6IyerQClzBsFYdlzKym9n9LY9MfxPynGbfjVQ== X-Received: by 10.237.56.200 with SMTP id k66mr19304306qte.70.1508776521448; Mon, 23 Oct 2017 09:35:21 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id n76sm4840031qkn.85.2017.10.23.09.35.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 09:35:20 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_746D2F90-9459-4D7F-BB74-60EEF1780E04" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Oct 2017 12:35:19 -0400 In-Reply-To: Cc: Steve Fenter , "tls@ietf.org" To: "Ackermann, Michael" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:35:24 -0000 --Apple-Mail=_746D2F90-9459-4D7F-BB74-60EEF1780E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2017, at 12:22 PM, Ackermann, Michael = wrote: > My question back to you was WHAT SIMPLIER PROTOCOL? =20 This is what I actually wrote, in the message before the one Kathleen = sent: > What they require is visibility into contents of the flow that they = are using encryption to protect. Right now, the protocol they are = using is TLS 1.1 or TLS 1.2. The right thing for them to do if they = continue to need this visibility and are no longer permitted to use TLS = 1.2 is to use IPsec+IKE, or some protocol that is designed for this use = case, not to take a protocol designed specifically for securing flows = from on-path eavesdropping and create a mode where it is easier to = wiretap. --Apple-Mail=_746D2F90-9459-4D7F-BB74-60EEF1780E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 23, 2017, at 12:22 PM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
My question back to you was WHAT SIMPLIER = PROTOCOL?  

This is what I actually wrote, in the message = before the one Kathleen sent:

What they = require is visibility into contents of the flow that they are using = encryption to protect.   Right now, the protocol they are using is = TLS 1.1 or TLS 1.2.   The right thing for them to do if they = continue to need this visibility and are no longer permitted to use TLS = 1.2 is to use IPsec+IKE, or some protocol that is designed for this use = case, not to take a protocol designed specifically for securing flows = from on-path eavesdropping and create a mode where it is easier to = wiretap.


= --Apple-Mail=_746D2F90-9459-4D7F-BB74-60EEF1780E04-- From nobody Mon Oct 23 09:38:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E50137E0B for ; Mon, 23 Oct 2017 09:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdQ3J744TuyU for ; Mon, 23 Oct 2017 09:38:15 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E3413955E for ; Mon, 23 Oct 2017 09:38:15 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id d9so20134811qtd.7 for ; Mon, 23 Oct 2017 09:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=R/JqccJ+hsKNoUGTs6MbmoVKLniO/RTeNr4Pa9eO0nI=; b=zwI3Px9xlI7k0yQ4IAMABqEbydEpNvplqNd0+sZZOLxJFbV8u/4neX/q5LHrmr9dtp 6b9qBbSb9wdh8DA+2NL3kzdL+voQeotmu1sAOI9Z12hMZbcTcfNDDOnFdZ31qYrsh16J 3fIpad76JanEaM/blgDAxElttkCo52U08vOq3kG/m4lbNAZTFvSZYFwrxaef25aJgWnl A0qeAgJeRtQtTIf12XR8IOypsBVVTwv+U7mN0sxY3EwKgivKqrs2G2FlN+f4IJoalg27 6+8PaFJZXG20ika0JvAhkNMoZOXrau+q62yvkY9dFW8+2FYboO6kRSInkKBJ84Yc18jL dL+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=R/JqccJ+hsKNoUGTs6MbmoVKLniO/RTeNr4Pa9eO0nI=; b=V6LnO565jSAhqv8mf9s9TqxWiTx3hAYyYSzc8lhsGnjwxtOUtT/OnuOpqvN0RdZJtG d5tAtMVFuCizS7r6yuX8QiXHP8dLTHVPGZ1BQ4EWoCJPPKuT0hBp/xkMfDyNBEQgvDXI NdtxaoUGLb3RT7Cw3lR0TYL/gSEuf/hOp3GZr40KWvc8H5gKJgVrcqWnyz2kBrhNG6Nl SWkhjqZ5UtxxzCbTJ7XtG4xf4whs8u1eC0Rkp7wexE3d+c7Xwi8mghiyI7HoTZKzy/3c z4jtGuwoKSkECPXB8LpGwzAKBLTWLFQ1dyhHjMt/TX4ft7nZpIpKsu02TSfMGx1BU4jh FYTg== X-Gm-Message-State: AMCzsaXZIlNe1XmvUm3K7PhyIWg8FWy4+zHDDMweHsqaFDHuE/oL2KGr ZkjUUk3UNR2yV3AL3Uo0voCOJA== X-Google-Smtp-Source: ABhQp+RV8PqKGRrh3h1iWP9BZdd8KIYkBlnxxWdXWJgqrFKr3qRswFOkiZwD6fhNIsO1LLjIG8Hs9g== X-Received: by 10.200.40.202 with SMTP id j10mr19852731qtj.301.1508776694267; Mon, 23 Oct 2017 09:38:14 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id u123sm4932807qkd.71.2017.10.23.09.38.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 09:38:13 -0700 (PDT) From: Ted Lemon Message-Id: <5BC836DD-9FDB-4C13-8916-902EDBA83A1D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_78B25B39-B100-49E3-8357-68B9F7140CA9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Oct 2017 12:38:12 -0400 In-Reply-To: <90235494-D1CA-4ABF-9AAC-4F8252927DCB@gmail.com> Cc: IETF TLS To: Ralph Droms References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII> <422F0052-D5C8-48ED-ACE6-05C9C2065AF9@vigilsec.com> <3D02BAA1-D71C-4D95-99B6-BB04EF7E6E38@fugue.com> <90235494-D1CA-4ABF-9AAC-4F8252927DCB@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:38:16 -0000 --Apple-Mail=_78B25B39-B100-49E3-8357-68B9F7140CA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2017, at 12:25 PM, Ralph Droms wrote: > Is there running code that demonstrates the IPsec+IKE can be deployed = and operated at scale in the sort of environment the enterprise network = tips have described to us? Is there running code that demonstrates that = draft-rhrd-tls-tls13-visibility-00 can be deployed and operated at = scale? :) In fact, when I went looking at the state of the art for IKE/IPsec after = our conversation in Prague, I was pleasantly surprised at how usable it = is. I don't know if it currently scales up as you suggest, but it = certainly can in principle. This is why I'm suggesting that resources = be spent doing that, rather than in limiting the ability of TLS 1.3 to = address its use case, which is a different use case. --Apple-Mail=_78B25B39-B100-49E3-8357-68B9F7140CA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 23, 2017, at 12:25 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
Is there = running code that demonstrates the IPsec+IKE can be deployed and = operated at scale in the sort of environment the enterprise network tips = have described to us?

Is= there running code that demonstrates that = draft-rhrd-tls-tls13-visibility-00 can be deployed and operated at = scale?   :)

In fact, when I = went looking at the state of the art for IKE/IPsec after our = conversation in Prague, I was pleasantly surprised at how usable it is. =   I don't know if it currently scales up as you suggest, but it = certainly can in principle.   This is why I'm suggesting that = resources be spent doing that, rather than in limiting the ability of = TLS 1.3 to address its use case, which is a different use = case.


= --Apple-Mail=_78B25B39-B100-49E3-8357-68B9F7140CA9-- From nobody Mon Oct 23 09:39:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91E138105 for ; Mon, 23 Oct 2017 09:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 geG_tcoEWvoN for ; Mon, 23 Oct 2017 09:39:09 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 68EEA1380DB for ; Mon, 23 Oct 2017 09:39:09 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id EE3EEC0DA6 for ; Mon, 23 Oct 2017 11:39:08 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 0B79BC0A19; Mon, 23 Oct 2017 11:39:08 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C5405FE04E; Mon, 23 Oct 2017 12:39:07 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7E340FE048; Mon, 23 Oct 2017 12:39:07 -0400 (EDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (unknown [216.32.180.56]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 23 Oct 2017 12:39:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8+oqE1Euc7fZlfKyriVkfRLkt26Vml5vrzY09YRG8Us=; b=cPmhvQAhBHt3aci/j8VBq5fu87uR3/LUZAJdqcZTDRS8DNCq9wk9pZd87EAPbVgQ4RK83FrrFXpRuWD+JZ131E/bLgpOmQeuBk+YrrFFncXNV+OxycLaxST99oqmWWPnnhUaE7gTiCnT++J/uieyLIvf+t8cSGUgg56K3cQM1GA= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1366.namprd14.prod.outlook.com (10.172.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 16:39:05 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Mon, 23 Oct 2017 16:39:05 +0000 From: "Ackermann, Michael" To: "Salz, Rich" , Ted Lemon CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIADZUkAgAAIFICAAB86QIAACamAgAD42jCAABKIgIAACV1AgAADZ4CAAAF70A== Date: Mon, 23 Oct 2017 16:39:05 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> In-Reply-To: <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1366; 20:5jy0NdlGpmV19xwksphIZI/Nwf8E4nCPm2HrKMipr6i+xvrRpKgIEvcR2mDEFm53bZ4oO7IXUfGU/XMY/v4lHJWh1/r38MIrkU84nvdhxd4wqIJPNhSYjlRRGyAhC9nXpWV+YS8HqJqObLKFTaoKOaUHqopIgQhe+Ee0exoljNs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 01f90394-7e37-4c87-ba02-08d51a34937c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1366; x-ms-traffictypediagnostic: CY4PR14MB1366: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(3231020)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1366; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(199003)(189002)(6306002)(6246003)(54356999)(9686003)(54896002)(55016002)(33656002)(6116002)(102836003)(230783001)(86362001)(76176999)(790700001)(99286003)(7696004)(50986999)(66066001)(106356001)(3846002)(74316002)(5660300001)(2950100002)(478600001)(53936002)(6506006)(72206003)(101416001)(97736004)(77096006)(105586002)(14454004)(2906002)(68736007)(8676002)(2900100001)(189998001)(7736002)(80792005)(25786009)(53546010)(8936002)(6436002)(4326008)(3280700002)(81166006)(81156014)(110136005)(229853002)(3660700001)(316002)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1366; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368378B42A6C46B27F5EF01D7460CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 16:39:05.6589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1366 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: f1d5b9a5-9679-4b8b-ad90-5c4e202a7ca2 X-VPM-MSG-ID: 545831fd-651c-4a37-a7e9-3bb7650f9a4c X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:39:12 -0000 --_000_CY4PR14MB1368378B42A6C46B27F5EF01D7460CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFJpY2gNCkkgaGF2ZSBzZWVuIHRoZXNlIHN1Z2dlc3Rpb25zIHByZXZpb3VzbHku DQpCdXQgYXMgbnVtZXJvdXMgbWVzc2FnZXMgb24gdGhpcyBjaGFpbiwgZnJvbSB2YXJpb3Vz IHBlb3BsZSBoYXZlIGRpc2N1c3NlZCwgbmVpdGhlciAgb2YgdGhvc2Ugc3VnZ2VzdGlvbnMg YXJlIHZpYWJsZSBmcm9tIGFuIEVudGVycHJpc2UgQXJjaGl0ZWN0dXJlIHBsYW5uaW5nIHBl cnNwZWN0aXZlLg0KDQoNCiAgMS4gIElmIHN0YXlpbmcgd2l0aCBUTFMgMS4yIGluZGVmaW5p dGVseSB3YXMgY29uc2lkZXJlZCBhY2NlcHRhYmxlLCAgd291bGQgd2UgZXZlbiBiZSBoYXZp bmcgdGhlc2UgZGlzY3Vzc2lvbnM/DQogIDIuICBNb2RpZnlpbmcgU2VydmVyLCAgYXBwbGlj YXRpb24gYW5kIGxvZ2dpbmcgaW5mcmFzdHJ1Y3R1cmUgaXMgYSBodWdlLCBleHBlbnNpdmUg cHJvcG9zaXRpb24sICB0aGF0IGV4ZWN1dGl2ZSBtYW5hZ2VtZW50IHdvdWxkIG5vdCBiZSBy ZWNlcHRpdmUgdG8gYXQgYWxsLiAgIE5vdCB0byBtZW50aW9uIHRoZSBsb2dpc3RpY3MgdG8g Zm9sbG93IGlmIHRoZXkgd2VyZS4NCg0KDQpGcm9tOiBTYWx6LCBSaWNoIFttYWlsdG86cnNh bHpAYWthbWFpLmNvbV0NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMywgMjAxNyAxMjoyNyBQ TQ0KVG86IEFja2VybWFubiwgTWljaGFlbCA8TUFja2VybWFubkBiY2JzbS5jb20+OyBUZWQg TGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpDYzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1RMU10gUHVibGljYXRpb24gb2YgZHJhZnQtcmhyZC10bHMtdGxzMTMtdmlzaWJpbGl0 eS0wMA0KDQoNCiAgKiAgIEkgYW0gbWVyZWx5IHRyeWluZyB0byB1bmRlcnN0YW5kIGlmIHRo ZXJlIGFyZSBhbnkgY29uc3RydWN0aXZlIHN1Z2dlc3Rpb25zIGFtb25nc3QgYWxsIHRoZXNl IGRpc2N1c3Npb25zLCB0aGF0IHdlIHNob3VsZCBjb25zaWRlci4NCg0KWWVzLiAgVG8gcmVw ZWF0IG15c2VsZiwgaGVyZSBhcmUgdHdvOg0KDQoNCiAgMS4gIENvbnRpbnVlIHRvIHVzZSB5 b3VyIGV4aXN0aW5nIHNjaGVtZXMuIFlvdSB3b27igJl0IGhhdmUgdG8gY2hhbmdlIHRvIFRM UyAxLjMgZm9yIHllYXJzLg0KICAyLiAgTW9kaWZ5IHlvdXIgc2VydmVycyBhbmQgbG9nZ2lu ZyBpbmZyYXN0cnVjdHVyZSB0byByZXBvcnQtb3V0IHRoZSBQRlMga2V5cyBhbmQgdXNlIHRo ZW0NCg0KRG8geW91IG5lZWQgbWUgdG8gcG9zdCBsaW5rcyB0byBteSBtZXNzYWdlcz8NCg0K CgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBo aWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGly ZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUg b3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25l LCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1l c3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGllcy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNo aWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJl IG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0 aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uCg== --_000_CY4PR14MB1368378B42A6C46B27F5EF01D7460CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDo0NDg2NjQ4MTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTczODA4MTI0IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjgzMDU2NTExNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTUwMjM0NzQ2OCAxMTA2NTU1NjkwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDINCgl7bXNvLWxpc3QtaWQ6MTMxODYwNzQ0OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE3MzMyOTI5NzQ7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTgyNTU4MTU0OTsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwNTEzNjI0 MzAgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwzOmxldmVs NA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MzpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MjA1OTY3MDM2MzsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTY0ODY0MzU2Njt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0Omxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IFJpY2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzZWVu IHRoZXNlIHN1Z2dlc3Rpb25zIHByZXZpb3VzbHkuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGFzIG51bWVyb3VzIG1lc3NhZ2VzIG9uIHRoaXMg Y2hhaW4sIGZyb20gdmFyaW91cyBwZW9wbGUgaGF2ZSBkaXNjdXNzZWQsIG5laXRoZXIgJm5i c3A7b2YgdGhvc2Ugc3VnZ2VzdGlvbnMgYXJlIHZpYWJsZSBmcm9tIGFuIEVudGVycHJpc2Ug QXJjaGl0ZWN0dXJlIHBsYW5uaW5nIHBlcnNwZWN0aXZlLiZuYnNwOw0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxvbCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvNyI+SWYgc3RheWluZyB3aXRoIFRMUyAxLjIgaW5kZWZpbml0ZWx5IHdhcyBj b25zaWRlcmVkIGFjY2VwdGFibGUsJm5ic3A7IHdvdWxkIHdlIGV2ZW4gYmUgaGF2aW5nIHRo ZXNlIGRpc2N1c3Npb25zPyZuYnNwOw0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvNyI+TW9kaWZ5aW5nIFNlcnZlciwmbmJzcDsgYXBwbGljYXRpb24gYW5kIGxvZ2dp bmcgaW5mcmFzdHJ1Y3R1cmUgaXMgYSBodWdlLCBleHBlbnNpdmUgcHJvcG9zaXRpb24sJm5i c3A7IHRoYXQgZXhlY3V0aXZlIG1hbmFnZW1lbnQgd291bGQgbm90IGJlIHJlY2VwdGl2ZSB0 byBhdCBhbGwuJm5ic3A7Jm5ic3A7IE5vdCB0byBtZW50aW9uIHRoZSBsb2dpc3RpY3MNCiB0 byBmb2xsb3cgaWYgdGhleSB3ZXJlLiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvbGk+PC9v bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48bzpwPiZuYnNwOzwv bzpwPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9z ZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBTYWx6LCBSaWNoIFttYWlsdG86cnNhbHpA YWthbWFpLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAyMywgMjAx NyAxMjoyNyBQTTxicj4NCjxiPlRvOjwvYj4gQWNrZXJtYW5uLCBNaWNoYWVsICZsdDtNQWNr ZXJtYW5uQGJjYnNtLmNvbSZndDs7IFRlZCBMZW1vbiAmbHQ7bWVsbG9uQGZ1Z3VlLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW1RMU10gUHVibGljYXRpb24gb2YgZHJhZnQtcmhyZC10bHMtdGxzMTMtdmlzaWJpbGl0 eS0wMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+SSBhbSBtZXJlbHkgdHJ5aW5nIHRvIHVu ZGVyc3RhbmQgaWYgdGhlcmUgYXJlIGFueSBjb25zdHJ1Y3RpdmUgc3VnZ2VzdGlvbnMgYW1v bmdzdCBhbGwgdGhlc2UgZGlzY3Vzc2lvbnMsIHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyLiZu YnNwOw0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4mbmJzcDsgVG8g cmVwZWF0IG15c2VsZiwgaGVyZSBhcmUgdHdvOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+Q29udGludWUg dG8gdXNlIHlvdXIgZXhpc3Rpbmcgc2NoZW1lcy4gWW91IHdvbuKAmXQgaGF2ZSB0byBjaGFu Z2UgdG8gVExTIDEuMyBmb3IgeWVhcnMuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm82 Ij5Nb2RpZnkgeW91ciBzZXJ2ZXJzIGFuZCBsb2dnaW5nIGluZnJhc3RydWN0dXJlIHRvIHJl cG9ydC1vdXQgdGhlIFBGUyBrZXlzIGFuZCB1c2UgdGhlbTxvOnA+PC9vOnA+PC9saT48L29s Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5EbyB5b3UgbmVlZCBtZSB0byBwb3N0IGxpbmtzIHRvIG15IG1lc3Nh Z2VzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCgoKPEJSPgo8aHRtbD4KIDxw PlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGhp Z2hseSBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBkaXJl Y3RlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29weWluZywgZGlzY2xvc3VyZSBv ciBkaXN0cmlidXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUs IG9mIGFueSB1bmludGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVz c2FnZSB3aXRob3V0IG1ha2luZyBhbnkgY29waWVzLjwvcD4KIDxwPkJsdWUgQ3Jvc3MgQmx1 ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2Fu IGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMg b2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLjwvcD4KICA8 L2h0bWw+Cgo= --_000_CY4PR14MB1368378B42A6C46B27F5EF01D7460CY4PR14MB1368namp_-- From nobody Mon Oct 23 09:43:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67864138105 for ; Mon, 23 Oct 2017 09:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Td9h_eEW8j3k for ; Mon, 23 Oct 2017 09:43:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30AE1380DB for ; Mon, 23 Oct 2017 09:43:27 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 434FA3E80F; Mon, 23 Oct 2017 16:43:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 434FA3E80F Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DB2635DA60; Mon, 23 Oct 2017 16:43:26 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Cc: "Blumenthal, Uri - 0553 - MITLL" , Paul Turner Date: Mon, 23 Oct 2017 18:43:25 +0200 Message-ID: <4119508.X6N1ULsUAb@pintsize.usersys.redhat.com> In-Reply-To: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3075018.qsrAMWaXvh"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 23 Oct 2017 16:43:27 +0000 (UTC) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:43:29 -0000 --nextPart3075018.qsrAMWaXvh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 19 October 2017 19:12:11 CEST Blumenthal, Uri - 0553 - MITLL=20 wrote: > If those middleboxes already have sufficient alternative options, why do = we > spend time discussing this draft? Why do we need to add yet another > alternative for them? so that they benefit from standardisation, network effects and be fiscally= =20 responsible! =20 > Regards, > Uri >=20 > Sent from my iPhone >=20 >=20 > > On Oct 19, 2017, at 13:08, Paul Turner wrote: > >=20 > >=20 > >=20 > >=20 > >>=20 > >> Subverting one CA cuts across a large scale of Internet traffic and mi= ght > >> be noticed or can be routed around. > >=20 > >=20 > > With respect to "be noticed", forcing clients to opt-in seems like it > > would clearly be noticed. My understanding was that you were saying that > > the middlebox could block traffic. That seems in conflict with your > > statement that they can be "routed around".=20 =20 > >=20 > >> Certificate transparency helps prevent a > >> single CA from being coerced into misissuance. =20 > >=20 > >=20 > > It seems like a middlebox that is able to deny traffic (has that level = of > > power, would simply use their own CA and force trust of that) =20 > >=20 > >> With this extension, someone > >> doesn=E2=80=99t have to coerce a CA or force victims to trust a new CA= =2E Instead > >> they have to gain the cooperation of the origin(s) they are interested > >> in.> > >=20 > > Gaining the cooperation of the servers (origins) seems relevant. If they > > get the cooperation of the servers, they can simply get the data direct= ly > > from them. But, again, they also have to get the cooperation of the > > clients.=20 =20 > > If a middlebox has sufficient power to block traffic, force clients into > > opting in, and coerce servers into opting in, it seems like they have > > sufficient alternative options that are of equivalent effort ("ease"). =20 > >=20 > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3075018.qsrAMWaXvh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZ7hwtAAoJEJKo0bgB0vX1NTYP/i3UEONQ/N/vi3gJgMGgB9UF rVy/vpGm6utaeHEaIvd5OvBDY6NwbV+/8Qr7a2HzkkEmDHECFcjoTb7mat+8b7wd 1Daur2NUQJ7/FWLIvIvWpaLK+jkKaGdUwKcRoMejm4WXJiNvwZ69d8aXoYeDX0mO 8E+Wom6R0Ash7c9I7svw231DEE2fYxr5i51BFJGUrABiGOlxt4BceiVBCoR1P96v kzb5+NTqxKq+P7hAFyuG3qKy4Re3YhcLoCno7ApFRh682IE+8X+i75mIfjljTiUS k/dmcZVJglU9uw91ZIlvyyx20m33vLUTsfdoqS+glZcNXCP5z5XQor89YWaStioA UCaXYtzw4xPnZVyrx3ZC6I8scIxg03c7oDPZzKMCjlYEZP1bhuFSEDHNghbwJor7 aQE9MaVDq64GhEjMzYpQgzjl3yf/ahIpnWEefmM/+taaY8At15/hLZi5DDP/8Pa2 /GIcF4rRdug3FJDYDO0uSQtDI+Q8BZn50eeO5Mlj0n/FwMvbFia3wX2y7/leLUiV 1QPezR2ZpbnqNuY8rEqDEsXmxGvO5TTO7VtmpjQp2mPkQArgUWI+sFK2k9iKh7ra jXXj7rJkK9xU2dnGrAbly7gYYEDvXD/FyqdZNCG7BwUXrxRyon3PpSRVGcp/4d6O G3B0PULx2YEOje32V9f1 =yrd8 -----END PGP SIGNATURE----- --nextPart3075018.qsrAMWaXvh-- From nobody Mon Oct 23 09:43:52 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF7F139605 for ; Mon, 23 Oct 2017 09:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1HPOUtlef3x for ; Mon, 23 Oct 2017 09:43:49 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 5B34B1380DB for ; Mon, 23 Oct 2017 09:43:49 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id m189so22732553qke.4 for ; Mon, 23 Oct 2017 09:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=776zVGX2dvw1VoGg7azmk6IXd1Z+nJnx+QMbj6SGbks=; b=oh8VtDNypZRYLVbvCx6JCr6AM5CsTvIga9eJTYigGqfzSgBO4E7G7uLF9JuohytTK8 R4VmKnCG1IiCG9jRejRi39oXcmgjEIxqgF8NUidzHK5zNL1A0mp2OiR8QDy6pqFjOvAm TezzbdbixpvXHlifGatZ5SlTXfaRrB/Zdbk6Jr4/pXfFbkaxzq91mc4dIsoWSLlErCVA xXf5A+tTCjRZEvDclAU9n1XNM85uax9nbCGpbwRqzygAnncDTFYyAUFkQIWbsUWZstJw 9n3V+TFh0k786jGJKaV3Ko+Yi021iPItRZo2LwwbJUoi5VQ5Io3AqHSH1FruGIoKFJn4 ibHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=776zVGX2dvw1VoGg7azmk6IXd1Z+nJnx+QMbj6SGbks=; b=WRCOwwCei+7/KWylkgWg//4hyuAwg/tAfvgILwM1Ep3VllyY6hXsVjp38vmKF39Rk8 4aeRLeJHI+bGIRjtWT4jix7Od93omrBqVt75LJijWa3fzQg4BGanIBcFKVcSPZoNvwBt u6KO+wZTwlFxkDVeiJBmMHXoa67U7P12R1lqs0Ff0vzise+xNe2sQFQXUilWTEPp4mKK +NUgWJVbCyWxl9gtTQoMI3o4zwhJF6VsX/QM65MidDOKIRWNs4aeDu/ltlOihbpN0rrz ZMe451aZwv3qbRNMzDte+KrNOCWpixjQAQLejocEx47ofEnhCEqOj7Wn2WzsuyctUFQh 2S1g== X-Gm-Message-State: AMCzsaVYU+i7tcMz+W5/y4k/bquBctX7jk0swerd1tHGTlyrueM656aK 2H6WxzMzdWNdpHTQ7KKM2o2cNehAzn0= X-Google-Smtp-Source: ABhQp+RvSk8DqTIEwh4l2CVtjFNwDaGK1ZqkxqHwiN4ruC7mLrjaO5bbjLWhBEswtm3I91G63mgWGg== X-Received: by 10.55.137.198 with SMTP id l189mr20738375qkd.169.1508777028549; Mon, 23 Oct 2017 09:43:48 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id i8sm5142742qtb.63.2017.10.23.09.43.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 09:43:47 -0700 (PDT) From: Ted Lemon Message-Id: <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AE4580C8-236D-4DE2-A329-8E09FCC6E4FF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Oct 2017 12:43:46 -0400 In-Reply-To: Cc: "Salz, Rich" , "tls@ietf.org" To: "Ackermann, Michael" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:43:51 -0000 --Apple-Mail=_AE4580C8-236D-4DE2-A329-8E09FCC6E4FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2017, at 12:39 PM, Ackermann, Michael = wrote: > If staying with TLS 1.2 indefinitely was considered acceptable, would = we even be having these discussions?=20 This is a vacuous argument. Nobody has provided any evidence of any = kind that "enterprise" installations relying on TLS 1.2 would ever = switch to TLS 1.3, much less that they would do so in any kind of hurry. = You demonstrate why with your very next bullet point: > Modifying Server, application and logging infrastructure is a huge, = expensive proposition, that executive management would not be receptive = to at all. Not to mention the logistics to follow if they were. =20 If indeed that unmovable mountain, executive management, must be moved = in the case of switching to TLS 1.3 or in the case of switching to = something else, it seems obvious to me that it is better to switch to = something else. Can you give me a clear technical reason why that is not preferable? --Apple-Mail=_AE4580C8-236D-4DE2-A329-8E09FCC6E4FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 23, 2017, at 12:39 PM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
  1. If staying with TLS 1.2 = indefinitely was considered acceptable,  would we even be having = these discussions? 

This is a vacuous argument.   Nobody has = provided any evidence of any kind that "enterprise" installations = relying on TLS 1.2 would ever switch to TLS 1.3, much less that they = would do so in any kind of hurry.   You demonstrate why with your = very next bullet point:
  2. Modifying Server,  application and logging = infrastructure is a huge, expensive proposition,  that executive = management would not be receptive to at all.   Not to mention = the logistics to follow if they = were.  

If indeed that unmovable mountain, executive management, must = be moved in the case of switching to TLS 1.3 or in the case of switching = to something else, it seems obvious to me that it is better to switch to = something else.

Can you give me a clear technical reason why that is not = preferable?

= --Apple-Mail=_AE4580C8-236D-4DE2-A329-8E09FCC6E4FF-- From nobody Mon Oct 23 09:44:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5B013942F for ; Mon, 23 Oct 2017 09:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 YD70gXtXUw62 for ; Mon, 23 Oct 2017 09:44:18 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F051380DB for ; Mon, 23 Oct 2017 09:44:13 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9NGgHg6016335; Mon, 23 Oct 2017 17:44:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=bst8zoK9VKtGT0Lejl126DJnRxU+Tkzo1gLjz+F6li0=; b=FYWWE+wTT7t6Cuaaqrtno63bJ1Cuqe6I5Vl7TANk8wqGGIwPhY/s6p7t6AJLHOrbEv4K JObnqBTzdy1QsZEG+gURrmB7rinuQ7sr9DtWSsUE4YW5l+0N7yUPhFbEwkpeffu+pHa1 fWY/3VC0LT2AFyk0nZoyo5jdALiFTXybW86zdo3TY4m8hramHpyHbTU7YhHhypyxrNnX DzQKEPlUDnb5Af3Zb4DtyIc4OHQboRZAOWFOdvF5dA3Q/mbOmO2vMCwuoA5gYEwhJBv2 kzklKIC5RsWrlrmyygTyw9JVJhJdxQ8xsCEkMj1XLv9ucQpKV06JDJ/stydPzkkPBbWS Lw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2dqwvsx9nc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 17:44:10 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9NGfNME008495; Mon, 23 Oct 2017 12:44:09 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1ju611v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 12:44:09 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 23 Oct 2017 12:44:08 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 23 Oct 2017 12:44:08 -0400 From: "Salz, Rich" To: "Ackermann, Michael" , Ted Lemon CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABAMAgAAHdQCAAASJAIADZUoAgAAIFICAACFZAIAAB4qAgAD5KwCAABI3gIAAC5wAgAABKICAAAOBgIAAAWiA Date: Mon, 23 Oct 2017 16:44:07 +0000 Message-ID: <264A8CF4-92E3-4C1F-82F5-A7A66A3EF83A@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@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/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.60] Content-Type: multipart/alternative; boundary="_000_264A8CF492E34C1F82F5A7A66A3EF83Aakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230234 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230235 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:44:19 -0000 --_000_264A8CF492E34C1F82F5A7A66A3EF83Aakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAxLiAgSWYgc3RheWluZyB3aXRoIFRMUyAxLjIgaW5kZWZpbml0ZWx5IHdhcyBjb25zaWRlcmVk IGFjY2VwdGFibGUsICB3b3VsZCB3ZSBldmVuIGJlIGhhdmluZyB0aGVzZSBkaXNjdXNzaW9ucz8N Cg0KREFNTUlULiAgU3RvcCBzYXlpbmcgaW5kZWZpbml0ZWx5Lg0KDQpXaGF0IHBlcmNlbnRhZ2Ug b2YgaG9zdHMgd2l0aGluIHlvdXIgZW50ZXJwcmlzZSB1c2UgVExTIDEuMiBhcyB0aGUgcHJlZmVy cmVkIHByb3RvY29sPw0KDQoNCiAgMS4gIE1vZGlmeWluZyBTZXJ2ZXIsICBhcHBsaWNhdGlvbiBh bmQgbG9nZ2luZyBpbmZyYXN0cnVjdHVyZSBpcyBhIGh1Z2UsIGV4cGVuc2l2ZSBwcm9wb3NpdGlv biwgIHRoYXQgZXhlY3V0aXZlIG1hbmFnZW1lbnQgd291bGQgbm90IGJlIHJlY2VwdGl2ZSB0byBh dCBhbGwuICAgTm90IHRvIG1lbnRpb24gdGhlIGxvZ2lzdGljcyB0byBmb2xsb3cgaWYgdGhleSB3 ZXJlLg0KDQpBbmQgdGhpcyBpcyBwcm9iYWJseSB0aGUgbWFpbiBwb2ludCBiZWhpbmQgYWxsIHRo aXMuICBGb2xrcyB3YW50IHRvIG1ha2UgdGhlIGVudGlyZSBJbnRlcm5ldCBsZXNzIHNlY3VyZSAo SeKAmXZlIGV4cGxhaW5lZCB3aHkpIHNvIHRoYXQgdGhleSBjYW4gc2F2ZSB0aW1lIGFuZCBtb25l eS4NCg0KQnV0IGV2ZW4gaWYgdGhhdCB3ZXJlIG5vdCB0aGUgaXNzdWUsIGRvIHlvdSB0aGluayB0 aGlzIGRyYWZ0IHdvbuKAmXQgcmVxdWlyZSBjdXN0b20gd29yaz8NCg0K --_000_264A8CF492E34C1F82F5A7A66A3EF83Aakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxl LW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjE3NDM4MTM4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDk2MjI0NzIyO30NCkBsaXN0 IGwxDQoJe21zby1saXN0LWlkOjk1MDU4MDM3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoxNzc3MDc3ODc0IC00NzQ4MjkyMjggNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBs aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1p ZDo0NDg2NjQ4MTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0xOTczODA4MTI0IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwyOmxldmVs MQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjY4Nzc1ODIzOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTI5ODE4NDg4ODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjgzMDU2NTEx NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTUwMjM0 NzQ2OCAxMTA2NTU1NjkwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciLHNlcmlmO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxp c3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTIzNTc0ODMxOTsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTQ2MDE3NzE3NDt9DQpAbGlzdCBsNg0KCXttc28tbGlzdC1pZDoxODI1NTgx NTQ5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjA1 MTM2MjQzMCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsNjpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs NjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDY6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDY6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDY6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGw2OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGw2OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw2OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8b2wgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+SWYgc3Rh eWluZyB3aXRoIFRMUyAxLjIgaW5kZWZpbml0ZWx5IHdhcyBjb25zaWRlcmVkIGFjY2VwdGFibGUs Jm5ic3A7IHdvdWxkIHdlIGV2ZW4gYmUgaGF2aW5nIHRoZXNlIGRpc2N1c3Npb25zPyZuYnNwOw0K PG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRBTU1JVC4mbmJzcDsgU3RvcCBzYXlpbmcg aW5kZWZpbml0ZWx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHBlcmNlbnRhZ2Ugb2Yg aG9zdHMgd2l0aGluIHlvdXIgZW50ZXJwcmlzZSB1c2UgVExTIDEuMiBhcyB0aGUgcHJlZmVycmVk IHByb3RvY29sPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMiIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMiBsZXZlbDEgbGZvMyI+TW9kaWZ5aW5nIFNlcnZlciwmbmJzcDsgYXBwbGljYXRpb24gYW5k IGxvZ2dpbmcgaW5mcmFzdHJ1Y3R1cmUgaXMgYSBodWdlLCBleHBlbnNpdmUgcHJvcG9zaXRpb24s Jm5ic3A7IHRoYXQgZXhlY3V0aXZlIG1hbmFnZW1lbnQgd291bGQgbm90IGJlIHJlY2VwdGl2ZSB0 byBhdCBhbGwuJm5ic3A7Jm5ic3A7IE5vdCB0byBtZW50aW9uIHRoZSBsb2dpc3RpY3MgdG8NCiBm b2xsb3cgaWYgdGhleSB3ZXJlLiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5kIHRoaXMgaXMgcHJvYmFibHkgdGhlIG1haW4gcG9pbnQgYmVoaW5kIGFsbCB0aGlz LiZuYnNwOyBGb2xrcyB3YW50IHRvIG1ha2UgdGhlIGVudGlyZSBJbnRlcm5ldCBsZXNzIHNlY3Vy ZSAoSeKAmXZlIGV4cGxhaW5lZCB3aHkpIHNvIHRoYXQgdGhleSBjYW4gc2F2ZSB0aW1lIGFuZCBt b25leS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGV2ZW4gaWYgdGhhdCB3ZXJlIG5vdCB0 aGUgaXNzdWUsIGRvIHlvdSB0aGluayB0aGlzIGRyYWZ0IHdvbuKAmXQgcmVxdWlyZSBjdXN0b20g d29yaz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_264A8CF492E34C1F82F5A7A66A3EF83Aakamaicom_-- From nobody Mon Oct 23 10:17:26 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883D21393A8 for ; Mon, 23 Oct 2017 10:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju_8dZuROuDd for ; Mon, 23 Oct 2017 10:17:20 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16D6138DE1 for ; Mon, 23 Oct 2017 10:17:20 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id k123so22908275qke.3 for ; Mon, 23 Oct 2017 10:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:cc:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=fEcmPuu5Xdb6hJcyqOAcwwtVceHIBJfXlBK60orrh38=; b=V4Bmbxdy4iyHACPTIOtXqlMHXsnHKGPo5MSm8nOva5BEXtQY0QQ7bYf5ridHRiHcAX mtY08xoli+cfwMpouVB3RD715FMzi+ExkfIhX86NE40/SU9ULtDC6ylPwBfV9zlEBoUL ofdOG89wwCJQz9+HJof1aR2/Vwb8GaQKtRnjrt6pYi2TSPWM0xF3xrgHUDQIAokFiK3F 4vphxIUUkVq1nrjpGkUfYwXW/BxcuqqgJyPnjqX1B3R6fm+mjkr8J8PzXxe9bUKO35Md K9BRE6A2y14+++dNOcdRLxOYfnmNgnUO71U6e5jh8z2dMqsOWGizT1lYkAlSzVROY7Uy HJnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:cc:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fEcmPuu5Xdb6hJcyqOAcwwtVceHIBJfXlBK60orrh38=; b=bvS06zoVDpQiILA3Y7I8B2TiUPAjTxngItpe+de8sZtDC4IXUFAWyGV6PKaWT2cUR8 p2SVyJPosqqQF3PAyNiwxB9ln8/Mv9NZdrylHhaFWpwBP3DyKV/Yo28yG883lh0/ETKT kPibp3eEfla7ZZMNTu7W/ePRm6qUIm7AYR6J8K94SCAPi/OzRITXfXq16m5MSgIkMjjQ vqiv6qarEaBdPO6FmHDSvDRj2HT7TBsT0JzktyRR3FoWn2LFQcHdRHRokW0wdrxhGOk3 QwW/8RIbHf/65c2piiXdJvknJ2M6M+UjW5aZGtwz/r6LsqeWW3z2v0nPENV8oDezFCR0 yPJw== X-Gm-Message-State: AMCzsaXRhcSTX0JCQKUKinEs1ek9DcFyUnlWPLh/dM8GJIHODuVDEh5j MM3QxVltOxRWaZ6t9iYDd7E= X-Google-Smtp-Source: ABhQp+TA2AvL+HGWoZJ7xcjI3/OBLkU9bmgx22ownSj6QYdzyTN1QV834QXnjaFFBAnx452RwYG52Q== X-Received: by 10.55.20.29 with SMTP id e29mr19630904qkh.253.1508779039725; Mon, 23 Oct 2017 10:17:19 -0700 (PDT) Received: from [192.168.1.5] (pool-72-94-149-146.phlapa.fios.verizon.net. [72.94.149.146]) by smtp.gmail.com with ESMTPSA id i13sm4891711qke.39.2017.10.23.10.17.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 10:17:19 -0700 (PDT) References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> To: "Ackermann, Michael" , "tls@ietf.org" From: Dave Garrett Message-ID: <8e3dbc05-ab77-378d-2ee2-1071a955f98d@gmail.com> Date: Mon, 23 Oct 2017 13:17:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 17:17:24 -0000 On 10/23/2017 12:39 PM, Ackermann, Michael wrote: > 2. Modifying Server, application and logging infrastructure is a huge, > expensive proposition, that executive management would not be > receptive to at all. Not to mention the logistics to follow if > they were. I'd just like to have everyone stop and focus on this, right here. This is the crux of everything. It takes effort and resources to upgrade your systems, and you don't want to do it. Tough; this is not the TLS WG's problem. The job here is to design the most secure protocol possible, and weakening things significantly to accommodate legacy methods is not a realistic option. Organizations will *always* have to expend effort and resources to upgrade to better systems. If that can be reduced without affecting security, great, but if not, then you're just going to have to accept it. People should not be here arguing against technical improvements; they should be with their managers explaining the simple reality of the situation. Yeah, I know it's hard to explain to executive management that they are not in control here, but they aren't. I count at least 400+ messages on this list on this one topic. The answer is still "no". You're not getting a cheap drop-in replacement for your existing insecure use of static RSA keys out of this WG. Fixing devil's advocate qualms like whether or not clients have to send an extension is not enough to get even a rough consensus. Nontrivial, but very much viable, effort and resources will be required to upgrade. https://en.wikipedia.org/wiki/Technical_debt Dave From nobody Mon Oct 23 10:31:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5526E1395ED for ; Mon, 23 Oct 2017 10:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 gtfAVAFuuwxc for ; Mon, 23 Oct 2017 10:31:04 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 AA589138AEE for ; Mon, 23 Oct 2017 10:31:04 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id C20331C0B8C for ; Mon, 23 Oct 2017 12:31:03 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id DD91C1C0A98; Mon, 23 Oct 2017 12:31:02 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 99396FE063; Mon, 23 Oct 2017 13:30:57 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 53B10FE04E; Mon, 23 Oct 2017 13:30:57 -0400 (EDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (unknown [216.32.181.176]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 23 Oct 2017 13:30:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NLomHufruYmu5XqEXRl2LAjdmFyAeQoQdC7vRDWs6SQ=; b=ccvEGdo2MpLT3GNZqxDdBde7w5Tdr3wDc6/fdo+shXVler0lhRp49KHYJ6eK1GVqIktKIO/vqgevIi8tuKSEvrtWjV/bT0x1lNoZWDEJgGxqM11rVrw/07zyNahucGCf/Z5984MS59ciQg7SNeqKwXDq+gLxv5TAj2lcTuqgWO0= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 17:30:56 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Mon, 23 Oct 2017 17:30:55 +0000 From: "Ackermann, Michael" To: Ted Lemon CC: "Salz, Rich" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIADZUkAgAAIFICAAB86QIAACamAgAD42jCAABKIgIAACV1AgAADZ4CAAAF70IAAA1UAgAAA2TA= Date: Mon, 23 Oct 2017 17:30:47 +0000 Deferred-Delivery: Mon, 23 Oct 2017 17:30:00 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> In-Reply-To: <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 20:HOUMVtqBf7Lr5Foe223h0MlgmldujnwNKD/yTrvp5YeuqjBQ266OfFkImXMI+JRlYRBlazGN/eg5noqhkyuzqGrwDEj8gT+9cHJyU+qwaYSQq0B4gob8Mjl11E6Ug774heTAA0q6u/A0TsFZObKZVviI5mmUY5m1hkiO42mRpoo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 485a9819-f48d-4491-dfd0-08d51a3bd14f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1368; x-ms-traffictypediagnostic: CY4PR14MB1368: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(192374486261705)(21748063052155)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(3231020)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1368; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(24454002)(199003)(189002)(97736004)(50986999)(74316002)(9686003)(53546010)(6506006)(230783001)(6916009)(3280700002)(54356999)(7736002)(53936002)(7696004)(101416001)(2906002)(86362001)(478600001)(76176999)(77096006)(3660700001)(6306002)(2950100002)(189998001)(105586002)(33656002)(2900100001)(106356001)(54896002)(93886005)(4326008)(72206003)(229853002)(19609705001)(14454004)(54906003)(6246003)(5660300001)(81166006)(790700001)(6436002)(80792005)(81156014)(8936002)(55016002)(8676002)(6116002)(68736007)(66066001)(102836003)(25786009)(6666003)(316002)(236005)(99286003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368895DD0D72286635E4E83D7460CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 17:30:54.7671 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 52a2cebc-9468-429f-bb36-f4885c2627fe X-VPM-MSG-ID: d603c3fc-f365-4bc6-b1d7-8ec7ebf7320b X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 17:31:07 -0000 --_000_CY4PR14MB1368895DD0D72286635E4E83D7460CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WHY you ask is in the answer. It is a huge proposition requiring change to virtually every platform and = application. Not to mention all the management, monitoring and = security platforms. It would be very expensive and time consuming. And when they ask why this is necessary, it is because the new version of = the existing protocol is not backwards compatible, which is something we = have come to expect. From: Ted Lemon =5Bmailto:mellon=40fugue.com=5D Sent: Monday, October 23, 2017 12:44 PM To: Ackermann, Michael Cc: Salz, Rich ; tls=40ietf.org Subject: Re: =5BTLS=5D Publication of draft-rhrd-tls-tls13-visibility-00 On Oct 23, 2017, at 12:39 PM, Ackermann, Michael = > wrote: 1. If staying with TLS 1.2 indefinitely was considered acceptable, = would we even be having these discussions? This is a vacuous argument. Nobody has provided any evidence of any kind = that =22enterprise=22 installations relying on TLS 1.2 would ever switch = to TLS 1.3, much less that they would do so in any kind of hurry. You = demonstrate why with your very next bullet point: 1. 2. Modifying Server, application and logging infrastructure is a huge, = expensive proposition, that executive management would not be receptive = to at all. Not to mention the logistics to follow if they were. If indeed that unmovable mountain, executive management, must be moved in = the case of switching to TLS 1.3 or in the case of switching to something = else, it seems obvious to me that it is better to switch to something else. Can you give me a clear technical reason why that is not preferable? The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB1368895DD0D72286635E4E83D7460CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

The WHY you ask is in the answer.  =

It is a huge proposition requiring change to = virtually every platform and application.    Not to mention = all the management,  monitoring and security platforms. 

It would be very expensive and time consuming. =

And when they ask why this is necessary,  = it is because the new version of the existing protocol is not backwards = compatible,  which is something we have come to expect. 

 

From: Ted Lemon = =5Bmailto:mellon=40fugue.com=5D
Sent: Monday, October 23, 2017 12:44 PM
To: Ackermann, Michael <MAckermann=40bcbsm.com>
Cc: Salz, Rich <rsalz=40akamai.com>; tls=40ietf.org
Subject: Re: =5BTLS=5D Publication of = draft-rhrd-tls-tls13-visibility-00

 

On Oct 23, 2017, at 12:39 PM, Ackermann, = Michael <MAckermann=40bcbsm.com> = wrote:

  1. If staying with TLS 1.2 indefinitely was considered = acceptable,  would we even be having these = discussions? 

 

This is a vacuous argument.   Nobody has = provided any evidence of any kind that "enterprise" = installations relying on TLS 1.2 would ever switch to TLS 1.3, much less = that they would do so in any kind of hurry.   You demonstrate why with your very next bullet point:

  1.  
  2. Modifying = Server,  application and logging infrastructure is a huge, expensive = proposition,  that executive management would not be receptive to at = all.   Not to mention the logistics to follow if they were.  

 

If indeed that unmovable mountain, executive = management, must be moved in the case of switching to TLS 1.3 or in the = case of switching to something else, it seems obvious to me that it is = better to switch to something else.

 

Can you give me a clear technical reason why = that is not preferable?

 


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB1368895DD0D72286635E4E83D7460CY4PR14MB1368namp_-- From nobody Mon Oct 23 10:34:04 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F62D138BD8 for ; Mon, 23 Oct 2017 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1CzB-MLM-lVK for ; Mon, 23 Oct 2017 10:34:02 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A180138BB5 for ; Mon, 23 Oct 2017 10:34:02 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9NHWRHT009811; Mon, 23 Oct 2017 18:33:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=s3sWPxoPEWrQa3bWDsLBkIFWOlbW5vhaz4a49vDSiTQ=; b=ar2mUh2E1M549ybpKivEgMyrIt/66mFg2/i8thEWRPc/HIcpT1jZ13sgWtAAZWq/l64A O1wGLiXFtjOHmUySgMNYY0VchDN8emX/D0Mmp5q3et2rh2H2EMUk6BBTu7Ou7NUjtGbb y6vVnE2m565CcellnARnuTE8y1bKvleicSYWIr6ZP99mfrk/4lGduJTQIAOfLT3r0EYJ 4pZ3rsw/f4XSKHreRWtRNhRVMKLwtAkrT31GzxELm/i/4WFlcXr6Uc6QkzzBCapxFWOE SYDSCuypiRbeT9VdHiR0tUIdszR4pHZnhyK88rwVsK9kcDCG/w5fZEt8zxXeIMU1XIgE cg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2dqwg4pwuh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 18:33:57 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9NHWe7A018969; Mon, 23 Oct 2017 13:33:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2dr1jwqae7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 13:33:55 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 23 Oct 2017 13:33:54 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 23 Oct 2017 13:33:54 -0400 From: "Salz, Rich" To: "Ackermann, Michael" , Ted Lemon CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABAMAgAAHdQCAAASJAIADZUoAgAAIFICAACFZAIAAB4qAgAD5KwCAABI3gIAAC5wAgAABKICAAAOBgIAAAU8AgAANI4CAAADfAA== Date: Mon, 23 Oct 2017 17:33:54 +0000 Message-ID: <39B681D9-33D0-4A6C-821A-2F9F4038AAE3@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.171] Content-Type: multipart/alternative; boundary="_000_39B681D933D04A6C821A2F9F4038AAE3akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230246 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230247 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 17:34:03 -0000 --_000_39B681D933D04A6C821A2F9F4038AAE3akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSXQgaXMgYSBodWdlIHByb3Bvc2l0aW9uIHJlcXVpcmluZyBjaGFuZ2UgdG8gdmlydHVh bGx5IGV2ZXJ5IHBsYXRmb3JtIGFuZCBhcHBsaWNhdGlvbi4gICAgTm90IHRvIG1lbnRpb24gYWxs IHRoZSBtYW5hZ2VtZW50LCAgbW9uaXRvcmluZyBhbmQgc2VjdXJpdHkgcGxhdGZvcm1zLg0KDQpE byB5b3UgZXhwZWN0IHRoYXQgdGhpcyBkcmFmdCB3aWxsIHJlcXVpcmUgbm8gY2hhbmdlcyB0byBh bGwgeW91ciBtYW5hZ2VtZW50LCBtb25pdG9yaW5nLCBhbmQgc2VjdXJpdHkgcGxhdGZvcm1zPw0K DQoNCg0KICAqICAgQW5kIHdoZW4gdGhleSBhc2sgd2h5IHRoaXMgaXMgbmVjZXNzYXJ5LCAgaXQg aXMgYmVjYXVzZSB0aGUgbmV3IHZlcnNpb24gb2YgdGhlIGV4aXN0aW5nIHByb3RvY29sIGlzIG5v dCBiYWNrd2FyZHMgY29tcGF0aWJsZSwgIHdoaWNoIGlzIHNvbWV0aGluZyB3ZSBoYXZlIGNvbWUg dG8gZXhwZWN0Lg0KDQpZb3UgaGF2ZSB5ZWFycyB0byBzZXQgdGhlIHJpZ2h0IGV4cGVjdGF0aW9u Lg0K --_000_39B681D933D04A6C821A2F9F4038AAE3akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <40F94BFCCBCBD04EAB62B6F35D07E664@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox NTE3OTYzNDM1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxODEwMjE0Njg7fQ0KQGxpc3QgbDEN Cgl7bXNvLWxpc3QtaWQ6MTg2NTUxNDg5MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQwNjAz MTMxNjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwz DQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZl bDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE5ODA3MTkxNjY7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01NzcxOTY0NDA7fQ0KQGxpc3QgbDMNCgl7bXNvLWxp c3QtaWQ6MjEzMTYzMjkwODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwNjMzMTA0NTA7fQ0K QGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2 ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoyMTM1MzY5NDQ1Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0NzMzNTM1MjggMTcwMTc0 NzU1MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9 DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGw0OmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw0IGxldmVsMSBsZm83Ij5J dCBpcyBhIGh1Z2UgcHJvcG9zaXRpb24gcmVxdWlyaW5nIGNoYW5nZSB0byB2aXJ0dWFsbHkgZXZl cnkgcGxhdGZvcm0gYW5kIGFwcGxpY2F0aW9uLiZuYnNwOyZuYnNwOyZuYnNwOyBOb3QgdG8gbWVu dGlvbiBhbGwgdGhlIG1hbmFnZW1lbnQsJm5ic3A7IG1vbml0b3JpbmcgYW5kIHNlY3VyaXR5IHBs YXRmb3Jtcy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgZXhw ZWN0IHRoYXQgdGhpcyBkcmFmdCB3aWxsIHJlcXVpcmUgbm8gY2hhbmdlcyB0byBhbGwgeW91ciBt YW5hZ2VtZW50LCBtb25pdG9yaW5nLCBhbmQgc2VjdXJpdHkgcGxhdGZvcm1zPyZuYnNwOw0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvNyI+QW5kIHdoZW4gdGhleSBhc2sgd2h5 IHRoaXMgaXMgbmVjZXNzYXJ5LCZuYnNwOyBpdCBpcyBiZWNhdXNlIHRoZSBuZXcgdmVyc2lvbiBv ZiB0aGUgZXhpc3RpbmcgcHJvdG9jb2wgaXMgbm90IGJhY2t3YXJkcyBjb21wYXRpYmxlLCZuYnNw OyB3aGljaCBpcyBzb21ldGhpbmcgd2UgaGF2ZSBjb21lIHRvIGV4cGVjdC4mbmJzcDsNCjxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48YnI+DQo8L2E+WW91IGhhdmUgeWVhcnMgdG8gc2V0IHRoZSByaWdodCBleHBlY3Rh dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_39B681D933D04A6C821A2F9F4038AAE3akamaicom_-- From nobody Mon Oct 23 10:45:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F6013954B for ; Mon, 23 Oct 2017 10:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivYutelBvrj7 for ; Mon, 23 Oct 2017 10:45:18 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE4D137C4A for ; Mon, 23 Oct 2017 10:45:17 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id n61so27166930qte.10 for ; Mon, 23 Oct 2017 10:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oWzMEvOpYk1H41rTM7Zam2oSedHn/cYh639cCZT3cPw=; b=tZS+R+iGOCdJSp5+sZ+9HU8Dz9zunAHNF7Wvzv2Xtyd9qzVjnLaDWq4AahAfVks+cU rYGZ+zBR4l7SRfx4waKjpkenL7RIaTTeyxEPFEtyuxVbQnoGwUYjK5jIJX9U7XA3vfvU XAEna+VZqcSmGM7df12Le9iT3YgyqOIUA76zh/o+u+YAZeqwOdKYCiCqEpS6HMNIciPZ ThkGplBFs0fp1n8KWusOlFg9C0iIKpesvr52beyYftQmYmMLBpnyrLzZRfVdok5uqR8b vraRTlwPNt3Z1BXhpSmW2QeQuRQTLae/CDFiPYpJVsAe9eYkpO6ZS4lBaqJ7yMQsEf0u M60Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oWzMEvOpYk1H41rTM7Zam2oSedHn/cYh639cCZT3cPw=; b=azKhActtTu1DKZXj6NVd4/57u1FHtXYsnqLiFRBxagQ6HhK9ZVeeWgAEiLl9yILv0N 303hhu1/A9RgkLFTglTv7P5FnSRC8CGjEVjuaSDsy5v58jnmF/lPofqLYvzcicbcFPhc kDakf83z0Bre5qd/raA3m1+pmZj3yzSlsWau9wVECYZzFNsonBSHTOGpMwiBDEX+49/a RrGMf6bSlfVNDVW9ani+QV5cPcpapiTNesuWY6AZR69afiDvPczVPOrlnqOGGWj/xPzf 2B1rIxaPl+JSC/HjdCaW6bmwu8c2MPcrNaCrwZSuJzj0RGWQPlNIkWJMvpNofK4+wmT3 /6sQ== X-Gm-Message-State: AMCzsaWpp46C5RRkufjV9UJfFO0kkj7EUSv6MlFO0+nnbJI4GS+i8Tg3 byGSx/0h/Cd62ZVVuNGEqDTR5bE2o24= X-Google-Smtp-Source: ABhQp+Q0XX1m26LXbFbHJU7FV0y6hMXGIIoUmHWjpdjElgJgzbdjsEoL0FkvxouFwjwRWH4S0QYuSw== X-Received: by 10.200.27.221 with SMTP id m29mr21348615qtk.152.1508780716894; Mon, 23 Oct 2017 10:45:16 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id t16sm5308006qtt.92.2017.10.23.10.45.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 10:45:15 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_60254016-15EB-49C9-994F-06CC4FA809A4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Oct 2017 13:45:14 -0400 In-Reply-To: Cc: "Salz, Rich" , "tls@ietf.org" To: "Ackermann, Michael" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 17:45:20 -0000 --Apple-Mail=_60254016-15EB-49C9-994F-06CC4FA809A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 23, 2017, at 1:30 PM, Ackermann, Michael = wrote: > The WHY you ask is in the answer. =20 > It is a huge proposition requiring change to virtually every platform = and application. Not to mention all the management, monitoring and = security platforms.=20 > It would be very expensive and time consuming.=20 > And when they ask why this is necessary, it is because the new = version of the existing protocol is not backwards compatible, which is = something we have come to expect.=20 I really tried to have sympathy for you about this in Prague. I know = what it's like to get unreasonable pushes from management (not based on = recent experience, fortunately). But this exact form of reasoning is = why we're suffering from attacks on the internet like the Mirai botnet = and the Reaper botnet, the Equifax hack, et cetera. You have come to a group of people who take these issues extremely = seriously and asked them to bless you in going forward to create another = problem of the same magnitude. I know you don't think that's what = you're asking, but that really is what you are asking. It might not be = on your network=E2=80=94maybe you will operate this technology securely. = But you are asking us to create an attack surface, and it will be = used. When you make requests like this, what you are really doing is pushing = off costs your management doesn't want to pay on the users of the = Internet as a whole. 130 million Americans are now doomed for life to = suffer from attacks on their credit because of this kind of thinking. Stop asking us to take security less seriously, and start taking it more = seriously. You work for BCBS: you are responsible for protecting the = privacy of a similar number of Americans. I know this is hard, but = it's time to stop imagining that you can lay costs off on us and start = planning how you are going to migrate to a more secure architecture. --Apple-Mail=_60254016-15EB-49C9-994F-06CC4FA809A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Oct 23, 2017, at 1:30 PM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
The WHY you ask is in the answer.  
It = is a huge proposition requiring change to virtually every platform and = application.    Not to mention all the management,  = monitoring and security platforms. 
It would = be very expensive and time consuming. 
And= when they ask why this is necessary,  it is because the new = version of the existing protocol is not backwards compatible,  = which is something we have come to = expect. 

I really tried to have sympathy for you about this in Prague. =   I know what it's like to get unreasonable pushes from management = (not based on recent experience, fortunately).   But this exact = form of reasoning is why we're suffering from attacks on the internet = like the Mirai botnet and the Reaper botnet, the Equifax hack, et = cetera.

You = have come to a group of people who take these issues extremely seriously and asked them to bless you in = going forward to create another problem of the same magnitude.   I = know you don't think that's what you're asking, but that really is what = you are asking.   It might not be on your network=E2=80=94maybe you = will operate this technology securely.   But you are asking us to = create an attack surface, and it will be = used.

When you = make requests like this, what you are really doing is pushing off costs = your management doesn't want to pay on the users of the Internet as a = whole.   130 million Americans are now doomed for life to suffer = from attacks on their credit because of this kind of thinking.

Stop asking us to take = security less seriously, and start taking it more seriously.   You = work for BCBS: you are responsible for protecting the privacy of a = similar number of Americans.   I know this is hard, but it's time = to stop imagining that you can lay costs off on us and start planning = how you are going to migrate to a more secure architecture.

= --Apple-Mail=_60254016-15EB-49C9-994F-06CC4FA809A4-- From nobody Mon Oct 23 10:50:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE231397F3 for ; Mon, 23 Oct 2017 10:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz7kIR9qwOZq for ; Mon, 23 Oct 2017 10:50:44 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 D6AA0137C4A for ; Mon, 23 Oct 2017 10:50:44 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id b6so17644360pfh.7 for ; Mon, 23 Oct 2017 10:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=7sMqsXo2nKKnGrBZcW8ODReRFVA+vrVq1t1zRnB3K50=; b=dqvkx/onAyZzYAUaTDRFxG5J9HrVmDIpzaOmURzfZUCNm1G1c5HIlJawy33/NkKgo1 nqiEGnwASN5KdU9DFSeS4RFFHI9tzr8JWjlDQJhAH9P9JPgfXZPlK/TNfcwzwFBp0pXO G4/95STziDm3lqb4S4FpV3zY/fmD7O92/fgNt4zPaZMSM14kD5kIxsTXpuv9ocSMHGLr rT7CzFFA10dl77Ym4uHvILLNTJlpGvbJ0B1u73fWS/LJtLXPOoiEhOHB45ZX6VGe6elL vUv1dE1j3UmE8KPILRiftXS/9BPI4jUpKBZmmpjNkjCwCAk2yflhDiVIweARsYgjvzGy VIEg== 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=7sMqsXo2nKKnGrBZcW8ODReRFVA+vrVq1t1zRnB3K50=; b=K2CPq2Dh+ZYyALCWlrhOcm5L8CjwVznyz9rMJBeHroVBOFQaejW7Fj/j7l6pgVTOPQ 14abBkiFwnrQVQmqBGNDTdPXJx6wxUvA5FvNh805FgaY0d304fYvYVfNhSK7o2dxaBXV 1R7XwbtAlCuGNxQzBKqQwVBjQKH4V8Fd1v5LCCQsyFgF2Al12ndNqwF5LxSTUKN2Qo2F M0ga5zRMFjRKERXrSutIJwWuB333JodYBRFv/ahvbb9j6MBTc7jIEDWWS+tY7dHxCfxV WfO1oITDdXWva4V5ZcHdafOX+cYeXEgtOM8KJy0UIlPhy1upwY7fKV+gm4H7Q2Dftv3i R9VA== X-Gm-Message-State: AMCzsaX6TLED6pYvr6cFBmPI9Iv9pk+o/YDSPpKYpvAKuD8aJBpzAmFr O0fT5UE5ODm7AfUr+IJqqG2GU+2xTlzHWPe3Yeyr2D88 X-Google-Smtp-Source: ABhQp+Qd7f5/vTrSpei1pV9+Ruz6737CQXdunkK8scaoWhq2fDVTvzDkwCFRwc3R9DlgzO+TQ+Cn1GuLwP29wd1WFy8= X-Received: by 10.84.179.129 with SMTP id b1mr10689667plc.235.1508781044153; Mon, 23 Oct 2017 10:50:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.218.165 with HTTP; Mon, 23 Oct 2017 10:50:23 -0700 (PDT) From: Joseph Salowey Date: Mon, 23 Oct 2017 10:50:23 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11a71c2e5213055c3a76c9" Archived-At: Subject: [TLS] Closing PR#47 on draft-ietf-tls-iana-registry-updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 17:50:46 -0000 --94eb2c11a71c2e5213055c3a76c9 Content-Type: text/plain; charset="UTF-8" ekr proposed a PR (#47) for draft-ietf-tls-iana-registry-updates that clarified the specification required rules to include Internet Drafts. I believe this is not the intent and we should close the issue. I think the intent of specification required is to allow a community that needs a code point to make a specification available in a public location that is relevant to that community. I don't think an an I-D would be appropriate in most cases. Cheers, Joe --94eb2c11a71c2e5213055c3a76c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ekr proposed a= PR (#47) for=C2=A0=C2=A0draft-ietf-tls-iana-registry-updat= es that clarified the specification required rules to include Internet Draf= ts.=C2=A0=C2=A0

I believe this is not the intent and we should close the issue.=C2= =A0=C2=A0

I think the intent of specific= ation required is to allow a community that needs a code point to make a sp= ecification available in a public location that is relevant to that communi= ty. I don't think an an I-D would be appropriate in most cases.<= /font>

<= span style=3D"color:rgb(36,41,46)">Cheers,

Joe
--94eb2c11a71c2e5213055c3a76c9-- From nobody Mon Oct 23 10:54:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4DD138BE2 for ; Mon, 23 Oct 2017 10:54:21 -0700 (PDT) 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 3V0A269krmNR for ; Mon, 23 Oct 2017 10:54:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC3F137C4A for ; Mon, 23 Oct 2017 10:54:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94CC9BE4C; Mon, 23 Oct 2017 18:54:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEGK1FHiLIFG; Mon, 23 Oct 2017 18:54:16 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2AE35BDD8; Mon, 23 Oct 2017 18:54:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508781256; bh=mN0cfyWaz79vfuAlJpc/0xuBfmpGOouDfhhMygFRimc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GpTuQvmppGZ3RC2YlEyDpe9qsb63wsL1AqSUO78vt2mLE5g+EDhUAce/u2DWOcIov vgDkTLTt0SjLWKM+vCZ2DZeI/3CZrYqkHAp9kHLoWRgP7j2F3jAzvS0uBLYvI8EUmU Ea82aOqp16YijlnuHnfgGy8CSLv1FYgBte7e9oVI= To: "Ackermann, Michael" , Ted Lemon Cc: "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 23 Oct 2017 18:54:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kNVObNIgutn002Q1JcBKQ56q64OKUodPg" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 17:54:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kNVObNIgutn002Q1JcBKQ56q64OKUodPg Content-Type: multipart/mixed; boundary="iD9AUFDF2pWEXMQ9Ulp8LcqbRFA6GA0X5"; protected-headers="v1" From: Stephen Farrell To: "Ackermann, Michael" , Ted Lemon Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> In-Reply-To: --iD9AUFDF2pWEXMQ9Ulp8LcqbRFA6GA0X5 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 23/10/17 18:30, Ackermann, Michael wrote: > It is a huge proposition requiring change to virtually every platform > and application. Not to mention all the management, monitoring > and security platforms. It would be very expensive and time > consuming. And when they ask why this is necessary, it is because > the new version of the existing protocol is not backwards compatible, > which is something we have come to expect. All of these cost (*) arguments were raised in the draft-green iteration of this nonsense. None of them are any different when draft-green is replaced with draft-rehired. The arguments did not convince before, and will not convince now. They did not garner rough consensus before and I'm pretty happy from list discussion that they don't seem to be doing so now. Why do you insist on wasting the time of the WG? That seems disruptive to me. For the chairs: - Various people have asked you to call a halt here. - I do so again. - Pretty-please even :-) It seems clear this latest version of the same old bad idea is going nowhere but /dev/null, as is proper. Please do declare the discussion done. S. (*) The arguments here are of course all about moving the cost to someone else, they are not about reducing costs. The proponents of moving the cost elsewhere of course never seem to admit that. --iD9AUFDF2pWEXMQ9Ulp8LcqbRFA6GA0X5-- --kNVObNIgutn002Q1JcBKQ56q64OKUodPg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ7izHAAoJEC88hzaAX42i4SgH/052BoQMQvDefXYxdY8uxMZ2 MlLDbEzY/wuS9UyZsXCYf4DjlWhwv1Si5hnkjkSOudnGuiZizx8jjWPOahGkbVRX bMLrJ+tbL9HYJt48NIVptVA/2CHNHu/W25hxA1bx13MyEfgqUjy+Yn6dWAzSIh4T b+3hsoMcYxMYRv19eDMNQhahJbpPsXrhDXMZYHuwQ3xVNew+u/LqCWNsk7GoZNO0 TIIc0ux4cstyaaY2yjFDDOKvvoyx3gmXkqtpw3pi9GIGU0OMpzPAyL2t8vWcsqPQ 2QNqdJr2vE+Z8zL6i5FuMPMWvqZ7XjIe2CrY76MLmLwNwEotPBnsImogxH7yfUA= =D1uI -----END PGP SIGNATURE----- --kNVObNIgutn002Q1JcBKQ56q64OKUodPg-- From nobody Mon Oct 23 11:08:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891C11398CA for ; Mon, 23 Oct 2017 11:08:22 -0700 (PDT) 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, UNPARSEABLE_RELAY=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 oT7wcNi9n6B7 for ; Mon, 23 Oct 2017 11:08:19 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id AB63A139976 for ; Mon, 23 Oct 2017 11:08:19 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v9NI8IHR036071 for ; Mon, 23 Oct 2017 14:08:18 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO713gKFaj/ze3UaJfDxWNuaqP6LqPDwAgAFTKoCAAAWQgIAAANiAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAACX8gIAABAIAgAAHdgCAAASKgIADZUkAgAAIFICAACFZAIAAB4qAgAD5KwCAABI3gIAAC5wAgAABKICAAAOBgIAAAU8AgAANI4CAAAaOgIAAA+yA Date: Mon, 23 Oct 2017 18:08:17 +0000 Message-ID: <4A11F395-D965-4285-BF6E-AE34516A7301@ll.mit.edu> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-originating-ip: [172.25.177.12] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3591612497_855067139" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230254 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 18:08:22 -0000 --B_3591612497_855067139 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable For the chairs: I second Stephen=E2=80=99s request. Enough is enough. -- Regards, Uri Blumenthal On 10/23/17, 13:54, "TLS on behalf of Stephen Farrell" wrote: =20 On 23/10/17 18:30, Ackermann, Michael wrote: =E2=80=A6 The arguments did not convince before, and will not convince now. =20 They did not garner rough consensus before and I'm pretty happy from list discussion that they don't seem to be doing so now. =20 For the chairs: - *Various people have asked you to call a halt here*. - *I do so again*. - Pretty-please even :-) =20 It seems clear this latest version of the same old bad idea is going nowhere but /dev/null, as is proper. Please do declare the discussion done. --B_3591612497_855067139 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgR+6t+MTb6+eSeTiV 6yXfzgwScaFjdTuzE95yraA8teIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcxMDIzMTgwODE3WjANBgkqhkiG9w0BAQEFAASCAQCYe0Jn69hF2x4/d4cX a9DyhfyPKACn47344JJpMehmGJjD7VICDU9zJbw2ef4/X0Hs6B2S6WFnQ9YkmmlAlqoMuWoW niomxgg0jgA/BLe/NAsKE1hF6KDRIqSS1tQPmMDSVy6zjkoqLhnthmI7vzE7uA7pMwp7RLoS BCauoDO8uUzawh2Vow2Rm9S/X48GtOmABWFvDYY7Ry9gPHgC4mq4OG8PtbQKzjuFOA/IJ6W+ rI2EFG6XtRSyn8h/HyAKFsojFliQM4fUYo0h+hhN7ulh+Q4BXtFePzfNNHZ+upVg0Zg10X1G AJesWvZ4D47Ro9rG577xd7ijgkbxJMHGJYIe --B_3591612497_855067139-- From nobody Mon Oct 23 11:12:12 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAEB1398CA for ; Mon, 23 Oct 2017 11:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 tr2RKNi9oW6C for ; Mon, 23 Oct 2017 11:12:09 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 00F29138AEE for ; Mon, 23 Oct 2017 11:12:08 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 05B0AC0E94 for ; Mon, 23 Oct 2017 13:12:08 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 1CC32C0E8F; Mon, 23 Oct 2017 13:12:07 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D63B5FE06F; Mon, 23 Oct 2017 14:12:06 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8E8D1FE064; Mon, 23 Oct 2017 14:12:06 -0400 (EDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (unknown [207.46.163.83]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 23 Oct 2017 14:12:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mALt79yHMjnQVFT4YOB8GI1IdjKXq41J1d61wntxVC4=; b=wbp5xLMJkv62Pe8cC713Bkv8IbjAnOW4zZkvnmbOz2rMljv7xvMhz/O6R9zQruh73CJF7E/i/mgir1Fj/yjQ1HBoEadWTp/3pLCp5UPuHdrNxpXzg0XvS5BUZx/WJ1VBzpPaxU4EJIOVzQ9OrEZgYXyM6aeSoKqm8lTh6ZleV+Q= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 18:12:04 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Mon, 23 Oct 2017 18:12:04 +0000 From: "Ackermann, Michael" To: Ted Lemon CC: "Salz, Rich" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIADZUkAgAAIFICAAB86QIAACamAgAD42jCAABKIgIAACV1AgAADZ4CAAAF70IAAA1UAgAAA2TCAABBTAIAABPMA Date: Mon, 23 Oct 2017 18:12:04 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 20:HysA7/t6kSAYmVLae6WrGCypDdxgg2My0lIf+5lDycIwwj9cBg6EzJUmVLqUgg7gY3kCHYrZuWnZOZ7DFMWxLgUveEE4igGFiBW2P5E1Z3NOxIe7XEiLsSeUilOPtMU8tjzEbm1gLL6h2guUpa6VoQ6uNmfBvAS74+CL9oCXs1c= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 15b52dc1-eb3c-495a-641c-08d51a4190c1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1365; x-ms-traffictypediagnostic: CY4PR14MB1365: x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705)(21748063052155)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1365; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(199003)(24454002)(189002)(55016002)(230783001)(4326008)(97736004)(19609705001)(6916009)(3280700002)(6436002)(101416001)(53936002)(99286003)(66066001)(2950100002)(6306002)(76176999)(25786009)(50986999)(229853002)(6116002)(6506006)(3660700001)(14454004)(54356999)(189998001)(68736007)(236005)(2900100001)(2906002)(77096006)(81156014)(81166006)(8936002)(7696004)(86362001)(5660300001)(105586002)(53546010)(54906003)(6246003)(93886005)(9686003)(72206003)(74316002)(80792005)(8676002)(54896002)(478600001)(106356001)(316002)(7736002)(3846002)(33656002)(102836003)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB13687B405BA0EDC62F4371AAD7460CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 18:12:04.4864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 36adb994-9fb5-4570-a900-1309d31c8248 X-VPM-MSG-ID: 0e06e780-1f57-46b5-8830-7c9bcf708a41 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 18:12:11 -0000 --_000_CY4PR14MB13687B405BA0EDC62F4371AAD7460CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gc3VnZ2VzdCB0aGF0IEkgb3IgbXkgaW5kdXN0cnkgZG9lcyBub3QgdGFrZSBzZWN1cml0 eSBzZXJpb3VzbHksIGlzIGluYWNjdXJhdGUgYW5kIGltbWF0ZXJpYWwgdG8gdGhpcyBkaXNj dXNzaW9uLg0KDQpJIHdvdWxkIHB1dCB0aGUgY29tbWVudCAgdGhhdCBhbnlvbmUgb3IgYW55 IGluZHVzdHJ5IGlzIGF0dGVtcHRpbmcgdG8gbGF5IGNvc3RzIGZvciBhbnl0aGluZyBvZmYg b24gSUVURiwgIGluIHRoZSBzYW1lIHVuZm9ydHVuYXRlIGJ1Y2tldC4NCg0KVGhlc2UgdHlw ZXMgb2Ygc3ViamVjdGl2ZWx5IG5lZ2F0aXZlIHN0YXRlbWVudHMgYXJlIG5vdCBhdCBhbGwg Y29uc3RydWN0aXZlLCBnZXJtYW5lIG5vciB3b3J0aHkgb2YgcmVzcG9uc2UuDQoNCkZyb206 IFRlZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQpTZW50OiBNb25kYXksIE9j dG9iZXIgMjMsIDIwMTcgMTo0NSBQTQ0KVG86IEFja2VybWFubiwgTWljaGFlbCA8TUFja2Vy bWFubkBiY2JzbS5jb20+DQpDYzogU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT47IHRs c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFB1YmxpY2F0aW9uIG9mIGRyYWZ0LXJo cmQtdGxzLXRsczEzLXZpc2liaWxpdHktMDANCg0KT24gT2N0IDIzLCAyMDE3LCBhdCAxOjMw IFBNLCBBY2tlcm1hbm4sIE1pY2hhZWwgPE1BY2tlcm1hbm5AYmNic20uY29tPG1haWx0bzpN QWNrZXJtYW5uQGJjYnNtLmNvbT4+IHdyb3RlOg0KVGhlIFdIWSB5b3UgYXNrIGlzIGluIHRo ZSBhbnN3ZXIuDQpJdCBpcyBhIGh1Z2UgcHJvcG9zaXRpb24gcmVxdWlyaW5nIGNoYW5nZSB0 byB2aXJ0dWFsbHkgZXZlcnkgcGxhdGZvcm0gYW5kIGFwcGxpY2F0aW9uLiAgICBOb3QgdG8g bWVudGlvbiBhbGwgdGhlIG1hbmFnZW1lbnQsICBtb25pdG9yaW5nIGFuZCBzZWN1cml0eSBw bGF0Zm9ybXMuDQpJdCB3b3VsZCBiZSB2ZXJ5IGV4cGVuc2l2ZSBhbmQgdGltZSBjb25zdW1p bmcuDQpBbmQgd2hlbiB0aGV5IGFzayB3aHkgdGhpcyBpcyBuZWNlc3NhcnksICBpdCBpcyBi ZWNhdXNlIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZXhpc3RpbmcgcHJvdG9jb2wgaXMgbm90 IGJhY2t3YXJkcyBjb21wYXRpYmxlLCAgd2hpY2ggaXMgc29tZXRoaW5nIHdlIGhhdmUgY29t ZSB0byBleHBlY3QuDQoNCkkgcmVhbGx5IHRyaWVkIHRvIGhhdmUgc3ltcGF0aHkgZm9yIHlv dSBhYm91dCB0aGlzIGluIFByYWd1ZS4gICBJIGtub3cgd2hhdCBpdCdzIGxpa2UgdG8gZ2V0 IHVucmVhc29uYWJsZSBwdXNoZXMgZnJvbSBtYW5hZ2VtZW50IChub3QgYmFzZWQgb24gcmVj ZW50IGV4cGVyaWVuY2UsIGZvcnR1bmF0ZWx5KS4gICBCdXQgdGhpcyBleGFjdCBmb3JtIG9m IHJlYXNvbmluZyBpcyB3aHkgd2UncmUgc3VmZmVyaW5nIGZyb20gYXR0YWNrcyBvbiB0aGUg aW50ZXJuZXQgbGlrZSB0aGUgTWlyYWkgYm90bmV0IGFuZCB0aGUgUmVhcGVyIGJvdG5ldCwg dGhlIEVxdWlmYXggaGFjaywgZXQgY2V0ZXJhLg0KDQpZb3UgaGF2ZSBjb21lIHRvIGEgZ3Jv dXAgb2YgcGVvcGxlIHdobyB0YWtlIHRoZXNlIGlzc3VlcyBleHRyZW1lbHkgc2VyaW91c2x5 IGFuZCBhc2tlZCB0aGVtIHRvIGJsZXNzIHlvdSBpbiBnb2luZyBmb3J3YXJkIHRvIGNyZWF0 ZSBhbm90aGVyIHByb2JsZW0gb2YgdGhlIHNhbWUgbWFnbml0dWRlLiAgIEkga25vdyB5b3Ug ZG9uJ3QgdGhpbmsgdGhhdCdzIHdoYXQgeW91J3JlIGFza2luZywgYnV0IHRoYXQgcmVhbGx5 IGlzIHdoYXQgeW91IGFyZSBhc2tpbmcuICAgSXQgbWlnaHQgbm90IGJlIG9uIHlvdXIgbmV0 d29ya+KAlG1heWJlIHlvdSB3aWxsIG9wZXJhdGUgdGhpcyB0ZWNobm9sb2d5IHNlY3VyZWx5 LiAgIEJ1dCB5b3UgYXJlIGFza2luZyB1cyB0byBjcmVhdGUgYW4gYXR0YWNrIHN1cmZhY2Us IGFuZCBpdCB3aWxsIGJlIHVzZWQuDQoNCldoZW4geW91IG1ha2UgcmVxdWVzdHMgbGlrZSB0 aGlzLCB3aGF0IHlvdSBhcmUgcmVhbGx5IGRvaW5nIGlzIHB1c2hpbmcgb2ZmIGNvc3RzIHlv dXIgbWFuYWdlbWVudCBkb2Vzbid0IHdhbnQgdG8gcGF5IG9uIHRoZSB1c2VycyBvZiB0aGUg SW50ZXJuZXQgYXMgYSB3aG9sZS4gICAxMzAgbWlsbGlvbiBBbWVyaWNhbnMgYXJlIG5vdyBk b29tZWQgZm9yIGxpZmUgdG8gc3VmZmVyIGZyb20gYXR0YWNrcyBvbiB0aGVpciBjcmVkaXQg YmVjYXVzZSBvZiB0aGlzIGtpbmQgb2YgdGhpbmtpbmcuDQoNClN0b3AgYXNraW5nIHVzIHRv IHRha2Ugc2VjdXJpdHkgbGVzcyBzZXJpb3VzbHksIGFuZCBzdGFydCB0YWtpbmcgaXQgbW9y ZSBzZXJpb3VzbHkuICAgWW91IHdvcmsgZm9yIEJDQlM6IHlvdSBhcmUgcmVzcG9uc2libGUg Zm9yIHByb3RlY3RpbmcgdGhlIHByaXZhY3kgb2YgYSBzaW1pbGFyIG51bWJlciBvZiBBbWVy aWNhbnMuICAgSSBrbm93IHRoaXMgaXMgaGFyZCwgYnV0IGl0J3MgdGltZSB0byBzdG9wIGlt YWdpbmluZyB0aGF0IHlvdSBjYW4gbGF5IGNvc3RzIG9mZiBvbiB1cyBhbmQgc3RhcnQgcGxh bm5pbmcgaG93IHlvdSBhcmUgZ29pbmcgdG8gbWlncmF0ZSB0byBhIG1vcmUgc2VjdXJlIGFy Y2hpdGVjdHVyZS4NCg0KCgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29t bXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11 bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlp bmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMg cHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1h aWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUg dGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGllcy4KIAogQmx1 ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsg b2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50 IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRp b24uCg== --_000_CY4PR14MB13687B405BA0EDC62F4371AAD7460CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29u dmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBzdWdnZXN0IHRo YXQgSSBvciBteSBpbmR1c3RyeSBkb2VzIG5vdCB0YWtlIHNlY3VyaXR5IHNlcmlvdXNseSwg aXMgaW5hY2N1cmF0ZSBhbmQgaW1tYXRlcmlhbCB0byB0aGlzIGRpc2N1c3Npb24uJm5ic3A7 DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBwdXQgdGhlIGNvbW1lbnQg Jm5ic3A7dGhhdCBhbnlvbmUgb3IgYW55IGluZHVzdHJ5IGlzIGF0dGVtcHRpbmcgdG8gbGF5 IGNvc3RzIGZvciBhbnl0aGluZyBvZmYgb24gSUVURiwmbmJzcDsgaW4gdGhlIHNhbWUgdW5m b3J0dW5hdGUgYnVja2V0LiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZXNlIHR5cGVzIG9mIHN1YmplY3RpdmVseSBuZWdhdGl2ZSBzdGF0ZW1lbnRzIGFyZSBub3Qg YXQgYWxsIGNvbnN0cnVjdGl2ZSwgZ2VybWFuZSBub3Igd29ydGh5IG9mIHJlc3BvbnNlLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVu ZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFRl ZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIE9jdG9iZXIgMjMsIDIwMTcgMTo0NSBQTTxicj4NCjxiPlRvOjwvYj4gQWNrZXJt YW5uLCBNaWNoYWVsICZsdDtNQWNrZXJtYW5uQGJjYnNtLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IFNhbHosIFJpY2ggJmx0O3JzYWx6QGFrYW1haS5jb20mZ3Q7OyB0bHNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIFB1YmxpY2F0aW9uIG9mIGRyYWZ0LXJo cmQtdGxzLXRsczEzLXZpc2liaWxpdHktMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIE9jdCAyMywgMjAxNywgYXQgMTozMCBQTSwgQWNrZXJtYW5u LCBNaWNoYWVsICZsdDs8YSBocmVmPSJtYWlsdG86TUFja2VybWFubkBiY2JzbS5jb20iPk1B Y2tlcm1hbm5AYmNic20uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBXSFkgeW91 IGFzayBpcyBpbiB0aGUgYW5zd2VyLiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIGEgaHVnZSBwcm9wb3NpdGlvbiByZXF1aXJp bmcgY2hhbmdlIHRvIHZpcnR1YWxseSBldmVyeSBwbGF0Zm9ybSBhbmQgYXBwbGljYXRpb24u Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdCB0byBtZW50aW9uIGFsbCB0aGUgbWFuYWdlbWVudCwm bmJzcDsgbW9uaXRvcmluZyBhbmQgc2VjdXJpdHkgcGxhdGZvcm1zLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQg YmUgdmVyeSBleHBlbnNpdmUgYW5kIHRpbWUgY29uc3VtaW5nLjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB3aGVuIHRoZXkgYXNrIHdoeSB0 aGlzIGlzIG5lY2Vzc2FyeSwmbmJzcDsgaXQgaXMgYmVjYXVzZSB0aGUgbmV3IHZlcnNpb24g b2YgdGhlIGV4aXN0aW5nIHByb3RvY29sIGlzIG5vdCBiYWNrd2FyZHMgY29tcGF0aWJsZSwm bmJzcDsgd2hpY2ggaXMgc29tZXRoaW5nIHdlIGhhdmUgY29tZSB0byBleHBlY3QuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlYWxseSB0cmllZCB0byBoYXZlIHN5bXBhdGh5IGZv ciB5b3UgYWJvdXQgdGhpcyBpbiBQcmFndWUuICZuYnNwOyBJIGtub3cgd2hhdCBpdCdzIGxp a2UgdG8gZ2V0IHVucmVhc29uYWJsZSBwdXNoZXMgZnJvbSBtYW5hZ2VtZW50IChub3QgYmFz ZWQgb24gcmVjZW50IGV4cGVyaWVuY2UsIGZvcnR1bmF0ZWx5KS4gJm5ic3A7IEJ1dCB0aGlz IGV4YWN0IGZvcm0gb2YgcmVhc29uaW5nIGlzIHdoeSB3ZSdyZSBzdWZmZXJpbmcgZnJvbQ0K IGF0dGFja3Mgb24gdGhlIGludGVybmV0IGxpa2UgdGhlIE1pcmFpIGJvdG5ldCBhbmQgdGhl IFJlYXBlciBib3RuZXQsIHRoZSBFcXVpZmF4IGhhY2ssIGV0IGNldGVyYS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGhh dmUgY29tZSB0byBhIGdyb3VwIG9mIHBlb3BsZSB3aG8gdGFrZSB0aGVzZSBpc3N1ZXMgPGk+ DQpleHRyZW1lbHk8L2k+Jm5ic3A7c2VyaW91c2x5IGFuZCBhc2tlZCB0aGVtIHRvIGJsZXNz IHlvdSBpbiBnb2luZyBmb3J3YXJkIHRvIGNyZWF0ZSBhbm90aGVyIHByb2JsZW0gb2YgdGhl IHNhbWUgbWFnbml0dWRlLiAmbmJzcDsgSSBrbm93IHlvdSBkb24ndCB0aGluayB0aGF0J3Mg d2hhdCB5b3UncmUgYXNraW5nLCBidXQgdGhhdCByZWFsbHkgaXMgd2hhdCB5b3UgYXJlIGFz a2luZy4gJm5ic3A7IEl0IG1pZ2h0IG5vdCBiZSBvbiB5b3VyIG5ldHdvcmvigJRtYXliZSB5 b3Ugd2lsbA0KIG9wZXJhdGUgdGhpcyB0ZWNobm9sb2d5IHNlY3VyZWx5LiAmbmJzcDsgQnV0 IHlvdSBhcmUgYXNraW5nIHVzIHRvIGNyZWF0ZSBhbiBhdHRhY2sgc3VyZmFjZSwgYW5kIGl0 DQo8aT53aWxsIDwvaT5iZSB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuIHlvdSBtYWtlIHJlcXVlc3RzIGxpa2Ug dGhpcywgd2hhdCB5b3UgYXJlIHJlYWxseSBkb2luZyBpcyBwdXNoaW5nIG9mZiBjb3N0cyB5 b3VyIG1hbmFnZW1lbnQgZG9lc24ndCB3YW50IHRvIHBheSBvbiB0aGUgdXNlcnMgb2YgdGhl IEludGVybmV0IGFzIGEgd2hvbGUuICZuYnNwOyAxMzAgbWlsbGlvbiBBbWVyaWNhbnMgYXJl IG5vdyBkb29tZWQgZm9yIGxpZmUgdG8gc3VmZmVyIGZyb20gYXR0YWNrcyBvbiB0aGVpcg0K IGNyZWRpdCBiZWNhdXNlIG9mIHRoaXMga2luZCBvZiB0aGlua2luZy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3RvcCBhc2tp bmcgdXMgdG8gdGFrZSBzZWN1cml0eSBsZXNzIHNlcmlvdXNseSwgYW5kIHN0YXJ0IHRha2lu ZyBpdCBtb3JlIHNlcmlvdXNseS4gJm5ic3A7IFlvdSB3b3JrIGZvciBCQ0JTOiB5b3UgYXJl IHJlc3BvbnNpYmxlIGZvciBwcm90ZWN0aW5nIHRoZSBwcml2YWN5IG9mIGEgc2ltaWxhciBu dW1iZXIgb2YgQW1lcmljYW5zLiAmbmJzcDsgSSBrbm93IHRoaXMgaXMgaGFyZCwgYnV0IGl0 J3MgdGltZSB0byBzdG9wIGltYWdpbmluZw0KIHRoYXQgeW91IGNhbiBsYXkgY29zdHMgb2Zm IG9uIHVzIGFuZCBzdGFydCBwbGFubmluZyBob3cgeW91IGFyZSBnb2luZyB0byBtaWdyYXRl IHRvIGEgbW9yZSBzZWN1cmUgYXJjaGl0ZWN0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0KCgo8QlI+CjxodG1sPgogPHA+VGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5 IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9yIGRp c3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVwaG9uZSwgb2Yg YW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdl IHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuPC9wPgogPHA+Qmx1ZSBDcm9zcyBCbHVlIFNo aWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJl IG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0 aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uPC9wPgogIDwvaHRt bD4KCg== --_000_CY4PR14MB13687B405BA0EDC62F4371AAD7460CY4PR14MB1368namp_-- From nobody Mon Oct 23 11:29:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098C7139A5A for ; Mon, 23 Oct 2017 11:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Ioz1fzxTJuZt for ; Mon, 23 Oct 2017 11:29:34 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF7F137C4A for ; Mon, 23 Oct 2017 11:29:34 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9NIQohq001881; Mon, 23 Oct 2017 19:29:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=8cLm4IB61vMWHL17GIiF8OxgPTWUtlplnaDelOkOCtc=; b=nA7N3ish4yzk7r/BioFoYZSV8dPVBpDNcfzyiCD57/CNTlmV2pcfVwS+7Q+dfpgGzjSH 7SYfdp+cbsnsYFGVTNyhp0nR/rvmf4IW2PMdKQriBFPDOn/jTDpBe51T6QSGvU7EKkNh NpcOhlIZpIgy+KOdEcIOpSSOTht5shmQgn3peYyLBwn8A51+t+qiZ5eDpAwcjxGoQ1gN axxFoJT+HiZ47qFem0ZtGA+MAMcfwYARImciLbIgSubDkLw6068sKfQyLJE06H8WDz7C redLOMJBxJjGWBQDY8B4netMKYoItidxOJGDZl+uRfdkLEH94esIo0VzIPHqpSrVGnjx PA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2dqwgkqhc5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 19:29:29 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9NIQGk5012069; Mon, 23 Oct 2017 14:29:28 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dr1jue92t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 14:29:27 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 23 Oct 2017 14:29:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 23 Oct 2017 14:29:27 -0400 From: "Salz, Rich" To: "Ackermann, Michael" , Ted Lemon CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABAMAgAAHdQCAAASJAIADZUoAgAAIFICAACFZAIAAB4qAgAD5KwCAABI3gIAAC5wAgAABKICAAAOBgIAAAU8AgAANI4CAAAQJAIAAB4AAgAAE24A= Date: Mon, 23 Oct 2017 18:29:27 +0000 Message-ID: <8E5E414B-0789-4724-BCD6-04816447A401@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.171] Content-Type: multipart/alternative; boundary="_000_8E5E414B07894724BCD604816447A401akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230260 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230260 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 18:29:36 -0000 --_000_8E5E414B07894724BCD604816447A401akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSB3b3VsZCBwdXQgdGhlIGNvbW1lbnQgIHRoYXQgYW55b25lIG9yIGFueSBpbmR1c3Ry eSBpcyBhdHRlbXB0aW5nIHRvIGxheSBjb3N0cyBmb3IgYW55dGhpbmcgb2ZmIG9uIElFVEYsICBp biB0aGUgc2FtZSB1bmZvcnR1bmF0ZSBidWNrZXQuDQoNCkRvIEkgbWlzdW5kZXJzdGFuZCB3aGF0 IHlvdSBtZWFudCBieSB0aGlzIGNvbW1lbnQ/DQogICAgICAgICAgICAgICAgSXQgaXMgYSBodWdl IHByb3Bvc2l0aW9uIHJlcXVpcmluZyBjaGFuZ2UgdG8gdmlydHVhbGx5IGV2ZXJ5IHBsYXRmb3Jt IGFuZCBhcHBsaWNhdGlvbi4gICAgTm90IHRvIG1lbnRpb24gYWxsIHRoZSBtYW5hZ2VtZW50LCAg bW9uaXRvcmluZyBhbmQgc2VjdXJpdHkgcGxhdGZvcm1zLiBJdCB3b3VsZCBiZSB2ZXJ5IGV4cGVu c2l2ZSBhbmQgdGltZSBjb25zdW1pbmcuDQoNCk9yIHRoaXMgb25lPw0KTW9kaWZ5aW5nIFNlcnZl ciwgIGFwcGxpY2F0aW9uIGFuZCBsb2dnaW5nIGluZnJhc3RydWN0dXJlIGlzIGEgaHVnZSwgZXhw ZW5zaXZlIHByb3Bvc2l0aW9uLCAgdGhhdCBleGVjdXRpdmUgbWFuYWdlbWVudCB3b3VsZCBub3Qg YmUgcmVjZXB0aXZlIHRvIGF0IGFsbC4gICBOb3QgdG8gbWVudGlvbiB0aGUgbG9naXN0aWNzIHRv IGZvbGxvdyBpZiB0aGV5IHdlcmUuDQoNCk9yIHRoaXMgb25lPw0KICAgICAgICAgICAgICAgIEkg YmVsaWV2ZSBoaXMgcG9pbnQgd2FzIHRoYXQgYmVjYXVzZSB3ZSBkbyBub3QgbW92ZSBxdWlja2x5 LCAgd2UgbmVlZCB0byBwcmVwYXJlIGFzIG11Y2ggaW4gYWR2YW5jZSBhcyBwb3NzaWJsZSwgYW5k IGFzc3VyZSB0aGF0IHRoZSBiYXNlIHByb3RvY29scyB3ZSBrbm93IHdlIHdpbGwgYmUgdXNpbmcg aW4gdGhlIGZ1dHVyZSwgIGRvIG5vdCBwdXQgdXMgaW4gdGhlIHBvc2l0aW9uIG9mIGhhdmluZyB0 byBkbyB0aGluZ3MgdGhhdCBhcmUgZ2VuZXJhbGx5IG5vdCBwb3NzaWJsZSwgIHN1Y2ggYXMgbWFr ZSBzaWduaWZpY2FudCBhcHBsaWNhdGlvbiBvciBwcm90b2NvbCBjaGFuZ2VzLg0KDQoNCg== --_000_8E5E414B07894724BCD604816447A401akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <107A5E31474C8F4EBCC02A905616AFA8@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6NDc4ODA5NTI2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDc2NDc5Mzgy O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE4NzcwMzUwMjM7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTQyMzI1NjUyIC0xOTU4OTkyMzE2IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IixzZXJpZjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0 IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPkkgd291bGQg cHV0IHRoZSBjb21tZW50ICZuYnNwO3RoYXQgYW55b25lIG9yIGFueSBpbmR1c3RyeSBpcyBhdHRl bXB0aW5nIHRvIGxheSBjb3N0cyBmb3IgYW55dGhpbmcgb2ZmIG9uIElFVEYsJm5ic3A7IGluIHRo ZSBzYW1lIHVuZm9ydHVuYXRlIGJ1Y2tldC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5EbyBJIG1pc3VuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbnQgYnkgdGhpcyBjb21tZW50 PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEl0IGlzIGEgaHVnZSBwcm9wb3NpdGlvbiByZXF1aXJpbmcgY2hhbmdl IHRvIHZpcnR1YWxseSBldmVyeSBwbGF0Zm9ybSBhbmQgYXBwbGljYXRpb24uJm5ic3A7Jm5ic3A7 Jm5ic3A7IE5vdCB0byBtZW50aW9uIGFsbCB0aGUgbWFuYWdlbWVudCwmbmJzcDsgbW9uaXRvcmlu ZyBhbmQgc2VjdXJpdHkgcGxhdGZvcm1zLiZuYnNwO0l0IHdvdWxkIGJlIHZlcnkgZXhwZW5zaXZl IGFuZCB0aW1lIGNvbnN1bWluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3IgdGhpcyBvbmU/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+TW9kaWZ5aW5nIFNlcnZlciwmbmJzcDsgYXBwbGljYXRpb24gYW5kIGxvZ2dpbmcgaW5m cmFzdHJ1Y3R1cmUgaXMgYSBodWdlLCBleHBlbnNpdmUgcHJvcG9zaXRpb24sJm5ic3A7IHRoYXQg ZXhlY3V0aXZlIG1hbmFnZW1lbnQgd291bGQgbm90IGJlIHJlY2VwdGl2ZSB0byBhdCBhbGwuJm5i c3A7Jm5ic3A7IE5vdCB0byBtZW50aW9uIHRoZSBsb2dpc3RpY3MgdG8gZm9sbG93IGlmIHRoZXkg d2VyZS4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3IgdGhpcyBvbmU/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgSSBiZWxpZXZlIGhpcyBwb2ludCB3YXMgdGhhdCBiZWNhdXNlIHdlIGRvIG5v dCBtb3ZlIHF1aWNrbHksJm5ic3A7IHdlIG5lZWQgdG8gcHJlcGFyZSBhcyBtdWNoIGluIGFkdmFu Y2UgYXMgcG9zc2libGUsIGFuZCBhc3N1cmUgdGhhdCB0aGUgYmFzZSBwcm90b2NvbHMgd2Uga25v dyB3ZSB3aWxsIGJlIHVzaW5nIGluIHRoZSBmdXR1cmUsJm5ic3A7IGRvIG5vdCBwdXQgdXMgaW4g dGhlIHBvc2l0aW9uIG9mDQogaGF2aW5nIHRvIGRvIHRoaW5ncyB0aGF0IGFyZSBnZW5lcmFsbHkg bm90IHBvc3NpYmxlLCZuYnNwOyBzdWNoIGFzIG1ha2Ugc2lnbmlmaWNhbnQgYXBwbGljYXRpb24g b3IgcHJvdG9jb2wgY2hhbmdlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8E5E414B07894724BCD604816447A401akamaicom_-- From nobody Mon Oct 23 11:38:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5179F139976 for ; Mon, 23 Oct 2017 11:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaM8rFnCyrmM for ; Mon, 23 Oct 2017 11:38:32 -0700 (PDT) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::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 EA1BD139AB1 for ; Mon, 23 Oct 2017 11:38:31 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id 17so23184243qkq.8 for ; Mon, 23 Oct 2017 11:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7oMCabE5fUguAXSiNcYguTqMlc9SzZL5arsTFKZRdJQ=; b=GJGtTWVxFRaY0sDJ4cgnBNhk8KXbQitPRxYCDU0eft8Ze6QRmRaK/I7aF5y9EOYLob fEEJM+gVEgbcJm7PXU+Lf72KWo/0Djgn5WX6E/QP8V+MUSTdqjOEaVO+dQfZWoHVwgCs MduFlqcw8fg3gUCCqztpGl8F8T7USHhJZTXHgaXKPUiUGwycf3jI1f5uHRwtShe4XlPR 1G/xCxcVehwuZb4t4AQKztnHn203r8FPgDdFR0mlO3GRxSsfXVmWpInEbVwBdpYlVLRz RK3yGthaDO8w2VuahpEme9NM6eGADeBRHiKbhykwmA2WoClOCgkejKGtpcQSPFmWZEQ8 yR2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7oMCabE5fUguAXSiNcYguTqMlc9SzZL5arsTFKZRdJQ=; b=l1AdKwAaAAQqUA2mOepuq5kDLZJSjz12JyuOjs68Pi/R1LDo55pYwLvlRAIRAmN1sP rLH4Orp6b75wpt83vCLylAm+Pzz4WakbJhc7bY2b05DUoFzfi04AQml/3JFsgF3Ohiny WJc1FmDnLVRg3I/0XkJQAxuOUV7Bpx+BH180xZ/ohAKme4a9SBUy9H1zInuYqF9D4A0Z T5uE32DtQ9UrOWin+9jjNAHg7dJFpffK0tV7JQIak8Y13T5Rvtol9WhXzzCuRsNtk54s k5WGIZS2OoSL2u7ySCFVwxEYOYiV319mKdJoofDWk0FR5EB29YULSNdIcabo0HAykTAh mKyQ== X-Gm-Message-State: AMCzsaXJyPBue+zIi9I7iGAQXB3R7QkBCodkIGsHIiWdJr3LrIJfXgJZ cl4yTyupa22SiXu+4dunJ1GvfQ== X-Google-Smtp-Source: ABhQp+Scvtn88iYI7IpDrdD7DHKASuYxREtmFK3hHZTEpr9RapIg6ESgLDhiF+HSdkMpjZmVdNTVsQ== X-Received: by 10.233.232.8 with SMTP id a8mr20381099qkg.263.1508783911111; Mon, 23 Oct 2017 11:38:31 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id f12sm5374879qtk.0.2017.10.23.11.38.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 11:38:30 -0700 (PDT) From: Ted Lemon Message-Id: <2E0DDA5A-FF4C-4E90-BA1D-B74D3F0C6D84@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_29DC32DF-1AF1-4239-A16F-E2DD30DFE619" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Oct 2017 14:38:29 -0400 In-Reply-To: Cc: "Salz, Rich" , "tls@ietf.org" To: "Ackermann, Michael" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 18:38:35 -0000 --Apple-Mail=_29DC32DF-1AF1-4239-A16F-E2DD30DFE619 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2017, at 2:12 PM, Ackermann, Michael = wrote: > To suggest that I or my industry does not take security seriously, is = inaccurate and immaterial to this discussion.=20 I'm sure you take security seriously. What I'm saying is that you have = tunnel vision about it, because you are caught between a rock (the IETF) = and a hard place (management that won't listen). =20 > I would put the comment that anyone or any industry is attempting to = lay costs for anything off on IETF, in the same unfortunate bucket.=20 By "we" I mean users of the Internet, not the IETF. The IETF doesn't = have deep pockets. =20 > These types of subjectively negative statements are not at all = constructive, germane nor worthy of response. That's fine. We would all like for this conversation to end. My = "subjectively negative statements" were just explaining to you why you = aren't making any headway in the working group in trying to get the = outcome you seek. --Apple-Mail=_29DC32DF-1AF1-4239-A16F-E2DD30DFE619 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 23, 2017, at 2:12 PM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
To suggest that I or my industry does not take security = seriously, is inaccurate and immaterial to this = discussion. 

I'm = sure you take security seriously.   What I'm saying is that you = have tunnel vision about it, because you are caught between a rock (the = IETF) and a hard place (management that won't listen).
 
I would = put the comment  that anyone or any industry is attempting to lay = costs for anything off on IETF,  in the same unfortunate = bucket. 

By "we" I mean = users of the Internet, not the IETF.  The IETF doesn't have deep = pockets.
 
These types of subjectively negative statements are not at = all constructive, germane nor worthy of = response.

That's fine.   We would all like = for this conversation to end.   My "subjectively negative = statements" were just explaining to you why you aren't making any = headway in the working group in trying to get the outcome you = seek.

= --Apple-Mail=_29DC32DF-1AF1-4239-A16F-E2DD30DFE619-- From nobody Mon Oct 23 11:42:34 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF55138351 for ; Mon, 23 Oct 2017 11:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 URhPpVO4yAgI for ; Mon, 23 Oct 2017 11:42:30 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 D3DE7139AB1 for ; Mon, 23 Oct 2017 11:42:30 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 4DDECC0E84 for ; Mon, 23 Oct 2017 13:42:30 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 39FEDC0DB9; Mon, 23 Oct 2017 13:42:29 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 007C9FE04E; Mon, 23 Oct 2017 14:42:29 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BB362FE055; Mon, 23 Oct 2017 14:42:28 -0400 (EDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (unknown [216.32.181.177]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 23 Oct 2017 14:42:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L0dkmEfagAOd465do0dlIXZGtJQtXxS/i5qOrkU0o+o=; b=0QxChNCeHz+7clep0BVEfrcH859aIWCtXMmQTnoMKX/xryQUnQtXoOrrAf4z6MigfcwJwxC9Bs1NHzy/j28ZnN1ODxI6gFcyZYUCcjLA1Y2o/S77rdOkXmvbjyRMw02NZjC7JbfQdq3J5mTn3PafH/xkihmUH4enpOyCz1FwujU= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1366.namprd14.prod.outlook.com (10.172.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 18:42:26 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Mon, 23 Oct 2017 18:42:26 +0000 From: "Ackermann, Michael" To: "Salz, Rich" , Stephen Farrell , Darin Pettis , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIAAHaQw Date: Mon, 23 Oct 2017 18:42:13 +0000 Deferred-Delivery: Fri, 20 Oct 2017 21:15:00 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> In-Reply-To: <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.73] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1366; 20:daF7oJW8Al5PPezKkF//GG6q5KBly8m/K/pxje62jKRfw7Dqwaq0Wb5heJW97t1kB/2hESafZjDg0dJTrKXon6Mgd8jlQu1qp6CB5LkTBORKlJY/HkkM3kxT6X65FZfQ2ostiFpNgsnUQt3lWmJFcdXdk1QyUeoy+GYDXo/Tjxg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 09bf0e90-b911-4e45-3825-08d51a45cec1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1366; x-ms-traffictypediagnostic: CY4PR14MB1366: x-exchange-antispam-report-test: UriScan:(32856632585715)(278428928389397)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(3231020)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1366; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(199003)(13464003)(189002)(6666003)(54356999)(9686003)(55016002)(33656002)(6116002)(102836003)(230783001)(76176999)(86362001)(7696004)(99286003)(6246003)(50986999)(66066001)(106356001)(2501003)(3846002)(74316002)(2950100002)(5660300001)(478600001)(53936002)(6506006)(101416001)(72206003)(97736004)(105586002)(77096006)(14454004)(2906002)(68736007)(8676002)(305945005)(2900100001)(189998001)(7736002)(80792005)(25786009)(53546010)(8936002)(6436002)(81156014)(110136005)(81166006)(229853002)(3280700002)(3660700001)(316002)(39060400002)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1366; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 18:42:26.4284 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1366 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: c9f0677b-ec67-4caf-9876-408f0a1fcc07 X-VPM-MSG-ID: afad679e-269f-4f41-8af9-2420f9d59a45 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 18:42:32 -0000 But as stated in several previous Emails, the fact that TLS 1.2 is still = available, does not mean that we won't have applications, business units = or other entities that require TLS 1.3 and we will need to manage, monitor = and secure these, as well as older versions. =20 -----Original Message----- From: Salz, Rich =5Bmailto:rsalz=40akamai.com=5D=20 Sent: Friday, October 20, 2017 12:57 PM To: Ackermann, Michael ; Stephen Farrell = ; Darin Pettis ; = tls=40ietf.org Subject: Re: =5BTLS=5D Publication of draft-rhrd-tls-tls13-visibility-00 So it sounds like we are in agreement that continuing to use TLS 1.2 = is not a viable long term alternative. =20 =20 Long-term is a subjective term, and using it can lead to misunderstandings. Based on current and previous actions around SSL and TLS versions, you can = use TLS 1.2 for at least five, likely at least 10, years. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Mon Oct 23 12:12:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077CA139605 for ; Mon, 23 Oct 2017 12:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adamcaudill.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 sqOPWx-NOikd for ; Mon, 23 Oct 2017 12:12:10 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0891395F3 for ; Mon, 23 Oct 2017 12:12:10 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id g6so12520659pgn.6 for ; Mon, 23 Oct 2017 12:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamcaudill.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WCHV85emOvogA/TCFWu+Ftyzuo03/6AdNwkaH1hpfew=; b=YgPx0rX5FK0n2e5TVIUJSZb0CWSsh8OvH8faM+mEY7HcsTOOifLBlcZUczQ8gVlgoZ tcpuRwdyk/b2lgMlWM9MIL89zAtRvGk8aE8iIBiXlfsVNw+ACd2wK+tYMNl+oxsG1qJ+ RVt/m0vvUhUXnAAQ0HdIxRzLHtV5SfSA93S3s= 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; bh=WCHV85emOvogA/TCFWu+Ftyzuo03/6AdNwkaH1hpfew=; b=qMDnwXjwgHelwBQocDlEwl43eRsqjsHlf1fEvbMm/yQ+6tBqjDCPr2CosPum8f8p5v cN0tdZRLt8HLlVk78MtgUHi4WMxmnb0GIf8KdGZrbus7zVU5XilQYOEhyXwd7m3cbJRb hhjkfWP4EH4Tu+bmCQIdnEclL/Ad/W1w3wdmpu0gWjNAAI86xDxsYnI2cu6oRUTKZ5PI KIwt3FEwUo6+VNdE+4WFs1kR5lh1XL26R+VbsXOq0iOEofBXaSIIz5B/7LP2LqjWLYHW N5rocyibDpWz+qv3T1ZydkcRiTc7KUxIfb23457GUYhRHOybTSK5orI7vxY07lrA283K VYMg== X-Gm-Message-State: AMCzsaUVkM7Iu0B2xg82D/plrqNn5QvNu8L2HV5i9z+gAKBW+8f8Txa6 9/wo3Te6HX0UN3tMW/36H0eDztWe9PeujUsJbI12ndug X-Google-Smtp-Source: ABhQp+SXnRuXLG5OfT2Z1dG77s1ZlO8AhBk/YyGRvdcdMmdgeztwot9fDM9uGHL8rcmH6NGNGUWRVn7WMgX7HOO+dYw= X-Received: by 10.84.248.142 with SMTP id q14mr8835252pll.325.1508785929191; Mon, 23 Oct 2017 12:12:09 -0700 (PDT) MIME-Version: 1.0 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> In-Reply-To: From: Adam Caudill Date: Mon, 23 Oct 2017 19:11:58 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e082ba4945a1752055c3b99e4" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:12:12 -0000 --089e082ba4945a1752055c3b99e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To be honest, I=E2=80=99m rather surprised that this group continues to spe= nd time on this. I=E2=80=99m of the opinion that the chairs should step in and put = this discussion on hold until the work on TLS 1.3 is complete. This, and any document of the same goal, are eating up time and energy that should be directed to completing the work this group was chartered to do. There=E2=80= =99s no indication that there will be any consensus on moving forward with any such document in this group, and I don=E2=80=99t think that will change any time= soon. Those advocating for some standardized method of subverting the security properties of TLS have been offered numerous options in good faith, and continue to reject them all. I=E2=80=99m aware of extremely large enterpris= es that in fact require TLS 1.2 with PFS, as they made the investment in addressing this issue early on, and do so effectively. This can be solved without changes to the protocol or a standardized =E2=80=9Cbackdoor=E2=80=9D - and = is being done today by at least some enterprises. I understand that this complicates the work that some do, and will mean additional engineering or spending to deal with it, when they eventually move to TLS 1.3; that said, I don=E2=80=99t think their decision to take th= e easy route in traffic inspection and ignore the evolution of 1.3 till the last moment should lead to adding new risk to every other TLS user, especially those that invested in long term solutions that deal with these changes. I=E2=80=99m of the opinion that this discussion is no longer productive; th= ere=E2=80=99s no indication that there will be consensus on this or similar documents, good faith efforts have been made to offer alternatives - in multiple discussions, it=E2=80=99s distracting from the work of completing 1.3. To m= e, the most logical thing to do is move on, finish the work on 1.3, and then reevaluate (not that I expect consensus to emerge then either). --=20 --*Adam Caudill* http://adamcaudill.com --089e082ba4945a1752055c3b99e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be honest, I=E2=80=99m rather surprised = that this group continues to spend time on this. I=E2=80=99m of the opinion= that the chairs should step in and put this discussion on hold until the w= ork on TLS 1.3 is complete. This, and any document of the same goal, are ea= ting up time and energy that should be directed to completing the work this= group was chartered to do. There=E2=80=99s no indication that there will b= e any consensus on moving forward with any such document in this group, and= I don=E2=80=99t think that will change any time soon.=C2=A0

Those advocating for some standardized method of subverting the= security properties of TLS have been offered numerous options in good fait= h, and continue to reject them all. I=E2=80=99m aware of extremely large en= terprises that in fact require TLS 1.2 with PFS, as they made the investmen= t in addressing this issue early on, and do so effectively. This can be sol= ved without changes to the protocol or a standardized =E2=80=9Cbackdoor=E2= =80=9D - and is being done today by at least some enterprises.

I understand that this complicates the work that some do, and wil= l mean additional engineering or spending to deal with it, when they eventu= ally move to TLS 1.3; that said, I don=E2=80=99t think their decision to ta= ke the easy route in traffic inspection and ignore the evolution of 1.3 til= l the last moment should lead to adding new risk to every other TLS user, e= specially those that invested in long term solutions that deal with these c= hanges.=C2=A0

I=E2=80=99m of the opinion that this disc= ussion is no longer productive; there=E2=80=99s no indication that there wi= ll be consensus on this or similar documents, good faith efforts have been = made to offer alternatives - in multiple discussions, it=E2=80=99s distract= ing from the work of completing 1.3. To me, the most logical thing to do is= move on, finish the work on 1.3, and then reevaluate (not that I expect co= nsensus to emerge then either).


--

--Adam Caudill
--089e082ba4945a1752055c3b99e4-- From nobody Mon Oct 23 14:22:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79BE13A441 for ; Mon, 23 Oct 2017 14:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 BrZiBPqgw9QZ for ; Mon, 23 Oct 2017 14:22:38 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4964E13A42F for ; Mon, 23 Oct 2017 14:22:38 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9NLLYeM021762; Mon, 23 Oct 2017 22:22:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=DCdU+mlXlQI/gOAcbODFaDc7lRrOegpKkajuzsHDLA8=; b=akixM4S4apDX/w+Hkv+TwU3dTkUwqcGbhc/PnZhFRcQPFxsLoVdtJ6yIdw7qVjipHox9 j8Zyjb+0lyZ6HLYsWoZ3ZjzyzpBI4HL1XU3dLAU3RB1loXwNjFNKypY/SufOHXyRbGWV 3Blv+AxS0OiPVdEPzzS7NePQWKAmX8yGLg4O5rtwRyH3VJtPMJKyzrOg5HcQ2+N+sTTt 09MEjFgFt2s887E2s8AWF7O+GFrhdgtJ/YLGg2kZ8rOa6VRf/2wHAIyC89G1hoxhaAPh HYQq7ZEj7If112w2Qsy+tyo8wQjaSxzlCxP8/R0E9QzYM2XIlsIXmdep7ZEIELrw6zlO GA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2dquacywr9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 22:22:32 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9NLKnFL008043; Mon, 23 Oct 2017 17:22:31 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dr1jvg376-1; Mon, 23 Oct 2017 17:22:31 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 945AF201DB; Mon, 23 Oct 2017 15:22:29 -0600 (MDT) To: yinxinxing Cc: "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: Date: Mon, 23 Oct 2017 16:22:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2BA5A2AE279D4182E4889448" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230300 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230300 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 21:22:42 -0000 This is a multi-part message in MIME format. --------------2BA5A2AE279D4182E4889448 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/23/2017 07:12 AM, Eric Rescorla wrote: > >  Another comment is about symmetrical CID. > > 1.       Consider a client sends a normal CID (CID length is not > zero, named C-CID) to server, but the server doesn’t wants to use > client’s CID and sends a CID generated by the server (named S-CID) > to the client. > > No. The CID is for the client's benefit, so why would this be useful? >   > > At the same time, client needs to know server has ignored C-CID > (which means the downlink application message from the server will > not include C-CID), and client will use S-CID in its application > message. Will the draft cover this scenario? > > No. That is to say, this draft does not consider symmetrical CIDs at all. -Ben --------------2BA5A2AE279D4182E4889448 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/23/2017 07:12 AM, Eric Rescorla wrote:

 Another comment is about symmetrical CID.

1.       Consider a client sends a normal CID (CID length is not zero, named C-CID) to server, but the server doesn’t wants to use client’s CID and sends a CID generated by the server (named S-CID) to the client.

No. The CID is for the client's benefit, so why would this be useful?
 

At the same time, client needs to know server has ignored C-CID (which means the downlink application message from the server will not include C-CID), and client will use S-CID in its application message. Will the draft cover this scenario?

No.

That is to say, this draft does not consider symmetrical CIDs at all.

-Ben
--------------2BA5A2AE279D4182E4889448-- From nobody Mon Oct 23 14:26:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8D13A5BC for ; Mon, 23 Oct 2017 14:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gQuGD_H5b2j for ; Mon, 23 Oct 2017 14:26:40 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79E013A41F for ; Mon, 23 Oct 2017 14:26:40 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id y75so13358751ywg.0 for ; Mon, 23 Oct 2017 14:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0x5AVEBFoUgyjqoclyi6HIbUUBvbQidPOnqzLmb8ZCk=; b=2KRcemttail9fPVGKxrih0NDMGc/u883KFQRlC86rjbD7aAjbDclKkHzMdPZzClW8U aeLM8J4gs/gKHHrZNna0WNPe3hu1BTgyqf0HbtzRti59AJD/3soDcxaR5NuLxh4hlYXi tCgyNmNVR0XSNPAGoezVduffnUKQH4p73ejrU88CIxgQups01E8ebcrzFfclQDpZ0gmw 1Up+bdhR051uwCXd3f9yh64Bgrmx3m5l9QoyJ3AlkOLEKFtUmjri5mlA6umnyQZOmhX3 7CRvefQsEnU0Nmuhjjd7i93//uBacGn3gHsE0/eeNUKSHvl5kABbnkB+CNkjy1n3otcp bQuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0x5AVEBFoUgyjqoclyi6HIbUUBvbQidPOnqzLmb8ZCk=; b=VxF/8VnCoIranRnl8K4CpFQN3Jt8s4J1eH1vlvUBQDlKdEZGyuo/ynyAtkACDkONdP UjZ/+vnFbGqCWB2Sp8hJt4Agzq6/aRkK7srpeF4e1Co3ult154iPXrNs1YrKcnTf80jB e8DNj4VKt2iocQUQCqGraRP5OcF70gQu8Ezhmlf6EE9rcp3ysHvT8Dlw8Wkc3AT4yZDi hh37EUs56AWviej+2NJ2OVGiLBWYfQaNDczSp7mVyNvpnMulJbpD/Aoj1/0ddx9EM3jy Kxx+5Zt13IZlsbtPeSA0/Xn1MSJQmocLngmHvlAn4otBsGKikQNk//UGigHyMHTyOEds 0Q8g== X-Gm-Message-State: AMCzsaWY7EhLVtcr1377ArgwZ/Kq9fPQWbgaPdg2NSvzqVbAWA3YMFXS HBz4jzv300buHeZmzi61cRwENgP38sEjsUXFQeF2SmHH X-Google-Smtp-Source: ABhQp+SHTe5mMzuhA1+wBvPLHzu34xKWT31L/kKGX6nA27ojbDqlprtSXFJPx5+GLPzJrx/T7Ah3Zwrs0zu02kpdBBs= X-Received: by 10.129.172.75 with SMTP id z11mr9753102ywj.155.1508793999968; Mon, 23 Oct 2017 14:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 23 Oct 2017 14:25:59 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 23 Oct 2017 14:25:59 -0700 Message-ID: To: Benjamin Kaduk Cc: yinxinxing , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045e95ac686350055c3d7a94" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 21:26:42 -0000 --f403045e95ac686350055c3d7a94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 23, 2017 at 2:22 PM, Benjamin Kaduk wrote: > On 10/23/2017 07:12 AM, Eric Rescorla wrote: > > Another comment is about symmetrical CID. >> >> 1. Consider a client sends a normal CID (CID length is not zero, >> named C-CID) to server, but the server doesn=E2=80=99t wants to use clie= nt=E2=80=99s CID >> and sends a CID generated by the server (named S-CID) to the client. >> > No. The CID is for the client's benefit, so why would this be useful? > > >> At the same time, client needs to know server has ignored C-CID (which >> means the downlink application message from the server will not include >> C-CID), and client will use S-CID in its application message. Will the >> draft cover this scenario? >> > No. > > > That is to say, this draft does not consider symmetrical CIDs at all. > You could of course echo the other side's CID, but no. -Ekr > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f403045e95ac686350055c3d7a94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 23, 2017 at 2:22 PM, Benjamin Kaduk <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
=20 =20 =20
On 10/23/2017 07:12 AM, Eric Rescorla wrote:

=C2=A0Another comment is about symmetrical CID.

1.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Consider a client sends a normal CID (CID length is not zero, named C-CID) to server, but the server doesn=E2=80=99t wants to use client=E2=80=99s CID an= d sends a CID generated by the server (named S-CID) to the client.

No. The CID is for the client's benefit, so why would this b= e useful?
=C2=A0

At the same time, client needs to know server has ignored C-CID (which means the downlink application message from the server will not include C-CID), and client will use S-CID in its application message. Will the draft cover this scenario?

No.

 That is to say, this draft does not consider symmetrical CIDs at all.

You could of course echo= the other side's CID, but no.

-Ekr
=

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--f403045e95ac686350055c3d7a94-- From nobody Mon Oct 23 14:43:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC8139605 for ; Mon, 23 Oct 2017 14:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 a5oyuS5ic0mu for ; Mon, 23 Oct 2017 14:43:17 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 4B3CE138351 for ; Mon, 23 Oct 2017 14:43:17 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id k123so23897958qke.3 for ; Mon, 23 Oct 2017 14:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CZ5+LIjZvOcV/+YT3gMtgsjssvHnQO3b1dBvI8lHWyc=; b=PCdsoj7XyeIjOr+Wddrl+cdmIHYuXcUgjxWGMiCL8fZKJ1lGlamUOn9NaIj2U/7l+C +XH1iJZl7NAZOsvxFApkQ9CLobvqyEQZXTd4i95951G741x6Vuz2tWIexjorWoGqkz+W R/WVnPxHb0ryQLydtSSJNEJWF6jUXn6FPufMKxaqLW4CxfF/+XBPZTqD8EIjFl1sU9N+ pOzeYFOhkHRZUeqeDEZcvo1ESya9YBXWoNfrzPS+7riuc6F1OTHFdZ1yKTljgsylI9C3 zWOrnQ4SyZKaBcdzqyGjd7DFudliGG5LEk617lh6N4kmUZFNweiDhcju7FQo5hvc74+h QfYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CZ5+LIjZvOcV/+YT3gMtgsjssvHnQO3b1dBvI8lHWyc=; b=bKjfeZSoD4rxsJP3I/SiyObbeQYC/W0XusOrqswmWGV7jl1jhrjnwo2wFFX3nr8FfO KgS+m73jwOy3PXGA/RIAv2Od1kj9idMle6PFoEJ5riKIb23uBkZTyJRCh59QB06CC3SU a+5RoHZXqqvihD86ap1Jaf9ktcTu/VzIRbCaoyv2ayacG1ZuViUprZfccE3yteEE3wQi gCTJEu5l6KNUrAjUBc0l07YREOWBXK4k4kyNzqzAEicdeE9bGO6lPHeaPUTulHnL9BT5 uGNIBqJzKio/vkP1tcPHGlCCbwG/99ME2OLqqwe/VwH8jxKE4XYXbCOKkTviLE4gN1KN 4jdQ== X-Gm-Message-State: AMCzsaV5Q99WoeNVGFHSXEs1nOvxKeCd/Tt8I4RUfc05sQmylXDXChxR BZKr2LWgegrwuweblFEgEruNZs5MEYC8xDFumvU= X-Google-Smtp-Source: ABhQp+QaF7e8wyrYZ9zSUzWdSVn0ZIqAGZy1Ab8/DWZptw7TVxPJmTlXHxGyq6rsSAAxdxJeHiR/6JG7YeMMrmIpXQU= X-Received: by 10.55.23.99 with SMTP id i96mr19654102qkh.278.1508794996393; Mon, 23 Oct 2017 14:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.11 with HTTP; Mon, 23 Oct 2017 14:42:55 -0700 (PDT) In-Reply-To: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> From: Tony Arcieri Date: Mon, 23 Oct 2017 14:42:55 -0700 Message-ID: To: Adam Caudill Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1146e248cc8e22055c3db56b" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 21:43:19 -0000 --001a1146e248cc8e22055c3db56b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill wrote= : > Those advocating for some standardized method of subverting the security > properties of TLS have been offered numerous options in good faith, and > continue to reject them all. I=E2=80=99m aware of extremely large enterpr= ises that > in fact require TLS 1.2 with PFS, as they made the investment in addressi= ng > this issue early on, and do so effectively. This can be solved without > changes to the protocol or a standardized =E2=80=9Cbackdoor=E2=80=9D - an= d is being done > today by at least some enterprises. > Having worked (and presently working) for more than one company of this nature, in the payments business no less, I would like to restate that it's incredibly disingenuous to cite the need for self-MitM capability as an "industry" concern. I think if it were possible to ask for a hum "from industry", you'd find the field divided between those who have invested in a real observability story, and those who think passive network traffic collection is the only way to debug their systems. I think if you were to even take a straw poll of the best approaches monitoring/observability among actual industry practitioners, passive network traffic collection would rank close to the bottom of the list. I would go as far as to say that if you are among those requesting this misfeature, you are doing a terrible job securing your infrastructure, and should look into modern observability techniques as an alternative to debugging by concentrating network traffic dumps into a single point of compromise which represents a huge security liability. Yes, switching to a new approach to observability is a huge investment that will take time, but so is upgrading to a new version of TLS. The "industry" reality is that many companies do not need a self-MitM misfeature and could be actively harmed by it, and while a self-MitM capability may be standard operating practice for some, it is not true for all, and identifying those who want the self-MitM capability as "industry" is a composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF is not listening to the concerns of industry". As a member of "industry" myself, I implore the IETF: please don't make the rest of us less secure at the request of those who are running insecure infrastructures and apparently intend on keeping things that way. --001a1146e248cc8e22055c3db56b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Oct 23, 2017 at 12:11 PM, Adam Caudill <adam@adamcaudill.com>= ; wrote:
Those advocating for some standardized method of subverting the secu= rity properties of TLS have been offered numerous options in good faith, an= d continue to reject them all. I=E2=80=99m aware of extremely large enterpr= ises that in fact require TLS 1.2 with PFS, as they made the investment in = addressing this issue early on, and do so effectively. This can be solved w= ithout changes to the protocol or a standardized =E2=80=9Cbackdoor=E2=80=9D= - and is being done today by at least some enterprises.

Having worked (and presently working) for more th= an one company of this nature, in the payments business no less, I would li= ke to restate that it's incredibly disingenuous to cite the need for se= lf-MitM capability as an "industry" concern.

=
I think if it were possible to ask for a hum "from industry"= , you'd find the field divided between those who have invested in a rea= l observability story, and those who think passive network traffic collecti= on is the only way to debug their systems. I think if you were to even take= a straw poll of the best approaches monitoring/observability among actual = industry practitioners, passive network traffic collection would rank close= to the bottom of the list.

I would go as far as t= o say that if you are among those requesting this misfeature, you are doing= a terrible job securing your infrastructure, and should look into modern o= bservability techniques as an alternative to debugging by concentrating net= work traffic dumps into a single point of compromise which represents a hug= e security liability. Yes, switching to a new approach to observability is = a huge investment that will take time, but so is upgrading to a new version= of TLS.

The "industry" reality is that = many companies do not need a self-MitM misfeature and could be actively har= med by it, and while a self-MitM capability may be standard operating pract= ice for some, it is not true for all, and identifying those who want the se= lf-MitM capability as "industry" is a composition fallacy being l= everaged as a rhetorical tactic, i.e. "IETF is not listening to the co= ncerns of industry".

As a member of "ind= ustry" myself, I implore the IETF: please don't make the rest of u= s less secure at the request of those who are running insecure infrastructu= res and apparently intend on keeping things that way.
--001a1146e248cc8e22055c3db56b-- From nobody Mon Oct 23 14:46:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F92313A415 for ; Mon, 23 Oct 2017 14:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 02zxBvttp5gd for ; Mon, 23 Oct 2017 14:46:08 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09B713A8A1 for ; Mon, 23 Oct 2017 14:45:58 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9NLfrIe015868; Mon, 23 Oct 2017 22:45:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=AQRkIH8ZbaYYyC9fwYsjg0wE133ZicFuQCoNKRvRx3s=; b=cwdAFfcmC50A2fkhUwFFtwme0FaIDWF6xl2oxVgqJu0+dEFGXQzfzprjIZA2edR9uMm8 K/uOC+uTTplssFPXf/r/T/liD4Fsos/kgTfVQ4segHSTEmGAXrd6VU5uI8KMe4LeIV4P ervq4n122OyaK9NbRSZH5QqA41Sqc/kBh/H83f8Ob4t7uqdj3Zp81eTl9c7xuepAmRSb ciap3Kfb1DAiZrZbYd4H3x/P5F7AKrPT2suGbb/IhCzdlrojzMPM6egehHi66MDP3g/1 IJCOrHk26ohM1z9BtkBXJ4fDH3dtG6aKZTS8AWf97Ukd6bTJ/qMMMbDIb8z1e0yGNu5Q SA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2dqwgkr58m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 22:45:57 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9NLf5vU019901; Mon, 23 Oct 2017 17:45:56 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1ju6uhb-1; Mon, 23 Oct 2017 17:45:56 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id E1ABF1FC7E; Mon, 23 Oct 2017 21:45:55 +0000 (GMT) To: Joseph Salowey , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <055efe53-193a-b626-5324-3cd834e70fd6@akamai.com> Date: Mon, 23 Oct 2017 16:45:55 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5F35013D3B404C13A690C671" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230305 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230305 Archived-At: Subject: Re: [TLS] Closing PR#47 on draft-ietf-tls-iana-registry-updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 21:46:09 -0000 This is a multi-part message in MIME format. --------------5F35013D3B404C13A690C671 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/23/2017 12:50 PM, Joseph Salowey wrote: > ekr proposed a PR (#47) for  draft-ietf-tls-iana-registry-updates that > clarified the specification required rules to include Internet Drafts.   > > I believe this is not the intent and we should close the issue.   > > I think the intent of specification required is to allow a community > that needs a code point to make a specification available in a public > location that is relevant to that community. I don't think an an I-D > would be appropriate in most cases. > I'm inclined to agree, given that something with an explicit expiration data cannot be considered "stable". (There's also a bit of a circular dependency in that the allocation would have to point to a preexisting I-D version that could not then be updated to refer to the allocated value, though I don't expect that to actually give anyone much pause.) -Ben --------------5F35013D3B404C13A690C671 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/23/2017 12:50 PM, Joseph Salowey wrote:
ekr proposed a PR (#47) for  draft-ietf-tls-iana-registry-updates that clarified the specification required rules to include Internet Drafts.  

I believe this is not the intent and we should close the issue.  

I think the intent of specification required is to allow a community that needs a code point to make a specification available in a public location that is relevant to that community. I don't think an an I-D would be appropriate in most cases.


I'm inclined to agree, given that something with an explicit expiration data cannot be considered "stable".

(There's also a bit of a circular dependency in that the allocation would have to point to a preexisting I-D version that could not then be updated to refer to the allocated value, though I don't expect that to actually give anyone much pause.)

-Ben
 --------------5F35013D3B404C13A690C671-- From nobody Mon Oct 23 15:09:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DCA1399D2 for ; Mon, 23 Oct 2017 15:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 DThKjIB0UOpt for ; Mon, 23 Oct 2017 15:09:39 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 F1C9D139A5A for ; Mon, 23 Oct 2017 15:09:38 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 0E4AB1C0BBD for ; Mon, 23 Oct 2017 17:09:38 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 244A41C0A63; Mon, 23 Oct 2017 17:09:37 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DCF24FE055; Mon, 23 Oct 2017 18:09:36 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8B1A5FE04E; Mon, 23 Oct 2017 18:09:36 -0400 (EDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (unknown [216.32.181.178]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 23 Oct 2017 18:09:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ittGJjX5kXtf22uJYfmD/e7LyLi7WjHM6bdEwbCLurY=; b=S72MZX1UQ3Ub+VZkooUZtvzCIt/fCNxte/CJvvmxpeInosoirlsz4WG71O97wAscUhxIm/rbSZOvj8feAF9sxQad0rkw89v3InjsQ/DMWyJTykssC8KXdqMvcySzVW4EH8cWA9hP2KTBa29iSU643e3KPffMymUwGX/QvdOoQx0= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 22:09:35 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Mon, 23 Oct 2017 22:09:34 +0000 From: "Ackermann, Michael" To: Tony Arcieri , Adam Caudill CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIADZUkAgAAIFICAAB86QIAACamAgAD42jCAABKIgIAACV1AgAADZ4CAAAF70IAAA1UAgAAA2TCAABBTAIAAGDwAgAAqLYCAAAW3AA== Date: Mon, 23 Oct 2017 22:09:34 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 20:cXvJEKCIEZFD/a4aulalokCVfEybhXdRctciSQbRQzgbr97yE7U8/jfN2sBCkpqJoMNUUVE1OzC3dSlf31UCGHrZC93wBKERpZH+Ne/qo5ugJGOGkgvJQNDN6vVHm1uwXxkAagvzxj0jc6oiYNEH2FZFeY8ZXOyHhHgJErNHnGk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 39a07e55-1358-479a-0dec-08d51a62be93 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1365; x-ms-traffictypediagnostic: CY4PR14MB1365: x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3231020)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1365; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(199003)(24454002)(189002)(230783001)(55016002)(97736004)(19609705001)(4326008)(99286003)(3280700002)(53936002)(101416001)(6436002)(66066001)(2950100002)(6306002)(76176999)(39060400002)(50986999)(25786009)(229853002)(6506006)(6116002)(3660700001)(14454004)(54356999)(189998001)(236005)(68736007)(2906002)(77096006)(2900100001)(81156014)(81166006)(8936002)(7696004)(86362001)(5660300001)(105586002)(110136005)(53546010)(93886005)(6246003)(72206003)(9686003)(74316002)(80792005)(54896002)(8676002)(478600001)(106356001)(316002)(3846002)(7736002)(33656002)(102836003)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368C52236964E69E1F124FBD7460CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 22:09:34.8125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: e34113f8-33fd-4c2d-a6c7-b6716d61ec5e X-VPM-MSG-ID: de8af55c-2142-4c6d-94bb-dafd4ee263ee X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:09:42 -0000 --_000_CY4PR14MB1368C52236964E69E1F124FBD7460CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBjYW4gYmUgc29sdmVkIHdpdGhvdXQgY2hhbmdlcyB0byB0aGUgcHJvdG9jb2wgb3Ig YSBzdGFuZGFyZGl6ZWQg4oCcYmFja2Rvb3LigJ0gLSBhbmQgaXMgYmVpbmcgZG9uZSB0b2Rh eSBieSBhdCBsZWFzdCBzb21lIGVudGVycHJpc2VzLg0KDQpIYXZpbmcgd29ya2VkIChhbmQg cHJlc2VudGx5IHdvcmtpbmcpIGZvciBtb3JlIHRoYW4gb25lIGNvbXBhbnkgb2YgdGhpcyBu YXR1cmUsIGluIHRoZSBwYXltZW50cyBidXNpbmVzcyBubyBsZXNzLCBJIHdvdWxkIGxpa2Ug dG8gcmVzdGF0ZSB0aGF0IGl0J3MgaW5jcmVkaWJseSBkaXNpbmdlbnVvdXMgdG8gY2l0ZSB0 aGUgbmVlZCBmb3Igc2VsZi1NaXRNIGNhcGFiaWxpdHkgYXMgYW4gImluZHVzdHJ5IiBjb25j ZXJuLg0KDQpObyBvbmUgSSBhbSBhd2FyZSBvZiBpcyBwdXNoaW5nIGZvciBhIE1pdE0gY2Fw YWJpbGl0eSB0byBhZGRyZXNzIHRoaXMuICAgSW4gZmFjdCBpdCB3YXMgb25lIG9mIHRoZSBh bHRlcm5hdGl2ZSBzb2x1dGlvbnMgZm9yIHdoaWNoIG1hbnkgaW1wbGVtZW50YXRpb24gaXNz dWVzIHdlcmUgY2l0ZWQgYXQgdGhlIFByYWd1ZSBtZWV0aW5nIGFuZCBvbiB0aGlzIGxpc3Qu ICAgIEJ1dCBJIHdvdWxkIGxpa2UgdG8gYXNrLCAgd2hhdCBpcyB0aGUgc29sdXRpb24gdGhh dCB5b3VyIGNvbXBhbnkgYW5kIG90aGVycyB0aGF0IHlvdSByZWZlcmVuY2UsICBoYXZlIHNv bHZlZCB0aGlzIHByb2JsZW0gYnkgaW1wbGVtZW50aW5nPw0KDQoNCg0KDQpGcm9tOiBUTFMg W21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvbnkgQXJjaWVy aQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDIzLCAyMDE3IDU6NDMgUE0NClRvOiBBZGFtIENh dWRpbGwgPGFkYW1AYWRhbWNhdWRpbGwuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtUTFNdIFB1YmxpY2F0aW9uIG9mIGRyYWZ0LXJocmQtdGxzLXRsczEzLXZpc2li aWxpdHktMDANCg0KT24gTW9uLCBPY3QgMjMsIDIwMTcgYXQgMTI6MTEgUE0sIEFkYW0gQ2F1 ZGlsbCA8YWRhbUBhZGFtY2F1ZGlsbC5jb208bWFpbHRvOmFkYW1AYWRhbWNhdWRpbGwuY29t Pj4gd3JvdGU6DQpUaG9zZSBhZHZvY2F0aW5nIGZvciBzb21lIHN0YW5kYXJkaXplZCBtZXRo b2Qgb2Ygc3VidmVydGluZyB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBvZiBUTFMgaGF2ZSBi ZWVuIG9mZmVyZWQgbnVtZXJvdXMgb3B0aW9ucyBpbiBnb29kIGZhaXRoLCBhbmQgY29udGlu dWUgdG8gcmVqZWN0IHRoZW0gYWxsLiBJ4oCZbSBhd2FyZSBvZiBleHRyZW1lbHkgbGFyZ2Ug ZW50ZXJwcmlzZXMgdGhhdCBpbiBmYWN0IHJlcXVpcmUgVExTIDEuMiB3aXRoIFBGUywgYXMg dGhleSBtYWRlIHRoZSBpbnZlc3RtZW50IGluIGFkZHJlc3NpbmcgdGhpcyBpc3N1ZSBlYXJs eSBvbiwgYW5kIGRvIHNvIGVmZmVjdGl2ZWx5LiBUaGlzIGNhbiBiZSBzb2x2ZWQgd2l0aG91 dCBjaGFuZ2VzIHRvIHRoZSBwcm90b2NvbCBvciBhIHN0YW5kYXJkaXplZCDigJxiYWNrZG9v cuKAnSAtIGFuZCBpcyBiZWluZyBkb25lIHRvZGF5IGJ5IGF0IGxlYXN0IHNvbWUgZW50ZXJw cmlzZXMuDQoNCkhhdmluZyB3b3JrZWQgKGFuZCBwcmVzZW50bHkgd29ya2luZykgZm9yIG1v cmUgdGhhbiBvbmUgY29tcGFueSBvZiB0aGlzIG5hdHVyZSwgaW4gdGhlIHBheW1lbnRzIGJ1 c2luZXNzIG5vIGxlc3MsIEkgd291bGQgbGlrZSB0byByZXN0YXRlIHRoYXQgaXQncyBpbmNy ZWRpYmx5IGRpc2luZ2VudW91cyB0byBjaXRlIHRoZSBuZWVkIGZvciBzZWxmLU1pdE0gY2Fw YWJpbGl0eSBhcyBhbiAiaW5kdXN0cnkiIGNvbmNlcm4uDQoNCkkgdGhpbmsgaWYgaXQgd2Vy ZSBwb3NzaWJsZSB0byBhc2sgZm9yIGEgaHVtICJmcm9tIGluZHVzdHJ5IiwgeW91J2QgZmlu ZCB0aGUgZmllbGQgZGl2aWRlZCBiZXR3ZWVuIHRob3NlIHdobyBoYXZlIGludmVzdGVkIGlu IGEgcmVhbCBvYnNlcnZhYmlsaXR5IHN0b3J5LCBhbmQgdGhvc2Ugd2hvIHRoaW5rIHBhc3Np dmUgbmV0d29yayB0cmFmZmljIGNvbGxlY3Rpb24gaXMgdGhlIG9ubHkgd2F5IHRvIGRlYnVn IHRoZWlyIHN5c3RlbXMuIEkgdGhpbmsgaWYgeW91IHdlcmUgdG8gZXZlbiB0YWtlIGEgc3Ry YXcgcG9sbCBvZiB0aGUgYmVzdCBhcHByb2FjaGVzIG1vbml0b3Jpbmcvb2JzZXJ2YWJpbGl0 eSBhbW9uZyBhY3R1YWwgaW5kdXN0cnkgcHJhY3RpdGlvbmVycywgcGFzc2l2ZSBuZXR3b3Jr IHRyYWZmaWMgY29sbGVjdGlvbiB3b3VsZCByYW5rIGNsb3NlIHRvIHRoZSBib3R0b20gb2Yg dGhlIGxpc3QuDQoNCkkgd291bGQgZ28gYXMgZmFyIGFzIHRvIHNheSB0aGF0IGlmIHlvdSBh cmUgYW1vbmcgdGhvc2UgcmVxdWVzdGluZyB0aGlzIG1pc2ZlYXR1cmUsIHlvdSBhcmUgZG9p bmcgYSB0ZXJyaWJsZSBqb2Igc2VjdXJpbmcgeW91ciBpbmZyYXN0cnVjdHVyZSwgYW5kIHNo b3VsZCBsb29rIGludG8gbW9kZXJuIG9ic2VydmFiaWxpdHkgdGVjaG5pcXVlcyBhcyBhbiBh bHRlcm5hdGl2ZSB0byBkZWJ1Z2dpbmcgYnkgY29uY2VudHJhdGluZyBuZXR3b3JrIHRyYWZm aWMgZHVtcHMgaW50byBhIHNpbmdsZSBwb2ludCBvZiBjb21wcm9taXNlIHdoaWNoIHJlcHJl c2VudHMgYSBodWdlIHNlY3VyaXR5IGxpYWJpbGl0eS4gWWVzLCBzd2l0Y2hpbmcgdG8gYSBu ZXcgYXBwcm9hY2ggdG8gb2JzZXJ2YWJpbGl0eSBpcyBhIGh1Z2UgaW52ZXN0bWVudCB0aGF0 IHdpbGwgdGFrZSB0aW1lLCBidXQgc28gaXMgdXBncmFkaW5nIHRvIGEgbmV3IHZlcnNpb24g b2YgVExTLg0KDQpUaGUgImluZHVzdHJ5IiByZWFsaXR5IGlzIHRoYXQgbWFueSBjb21wYW5p ZXMgZG8gbm90IG5lZWQgYSBzZWxmLU1pdE0gbWlzZmVhdHVyZSBhbmQgY291bGQgYmUgYWN0 aXZlbHkgaGFybWVkIGJ5IGl0LCBhbmQgd2hpbGUgYSBzZWxmLU1pdE0gY2FwYWJpbGl0eSBt YXkgYmUgc3RhbmRhcmQgb3BlcmF0aW5nIHByYWN0aWNlIGZvciBzb21lLCBpdCBpcyBub3Qg dHJ1ZSBmb3IgYWxsLCBhbmQgaWRlbnRpZnlpbmcgdGhvc2Ugd2hvIHdhbnQgdGhlIHNlbGYt TWl0TSBjYXBhYmlsaXR5IGFzICJpbmR1c3RyeSIgaXMgYSBjb21wb3NpdGlvbiBmYWxsYWN5 IGJlaW5nIGxldmVyYWdlZCBhcyBhIHJoZXRvcmljYWwgdGFjdGljLCBpLmUuICJJRVRGIGlz IG5vdCBsaXN0ZW5pbmcgdG8gdGhlIGNvbmNlcm5zIG9mIGluZHVzdHJ5Ii4NCg0KQXMgYSBt ZW1iZXIgb2YgImluZHVzdHJ5IiBteXNlbGYsIEkgaW1wbG9yZSB0aGUgSUVURjogcGxlYXNl IGRvbid0IG1ha2UgdGhlIHJlc3Qgb2YgdXMgbGVzcyBzZWN1cmUgYXQgdGhlIHJlcXVlc3Qg b2YgdGhvc2Ugd2hvIGFyZSBydW5uaW5nIGluc2VjdXJlIGluZnJhc3RydWN0dXJlcyBhbmQg YXBwYXJlbnRseSBpbnRlbmQgb24ga2VlcGluZyB0aGluZ3MgdGhhdCB3YXkuDQoKClRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGhpZ2hseSBj b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBkaXJlY3RlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29weWluZywgZGlzY2xvc3VyZSBvciBkaXN0 cmlidXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFu eSB1bmludGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3 aXRob3V0IG1ha2luZyBhbnkgY29waWVzLgogCiBCbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9m IE1pY2hpZ2FuIGFuZCBCbHVlIENhcmUgTmV0d29yayBvZiBNaWNoaWdhbiBhcmUgbm9ucHJv Zml0IGNvcnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRlbnQgbGljZW5zZWVzIG9mIHRoZSBCbHVl IENyb3NzIGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lhdGlvbi4K --_000_CY4PR14MB1368C52236964E69E1F124FBD7460CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT5UaGlzIGNhbiBi ZSBzb2x2ZWQgd2l0aG91dCBjaGFuZ2VzIHRvIHRoZSBwcm90b2NvbCBvciBhIHN0YW5kYXJk aXplZCDigJxiYWNrZG9vcuKAnSAtIGFuZCBpcyBiZWluZyBkb25lIHRvZGF5IGJ5IGF0IGxl YXN0IHNvbWUgZW50ZXJwcmlzZXMuPG86cD48L286cD48L3U+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHU+PG86cD48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPiZu YnNwOzwvc3Bhbj48L286cD48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+SGF2 aW5nIHdvcmtlZCAoYW5kIHByZXNlbnRseSB3b3JraW5nKSBmb3IgbW9yZSB0aGFuIG9uZSBj b21wYW55IG9mIHRoaXMgbmF0dXJlLCBpbiB0aGUgcGF5bWVudHMgYnVzaW5lc3Mgbm8gbGVz cywgSSB3b3VsZCBsaWtlIHRvIHJlc3RhdGUgdGhhdCBpdCdzIGluY3JlZGlibHkgZGlzaW5n ZW51b3VzIHRvIGNpdGUgdGhlIG5lZWQgZm9yIHNlbGYtTWl0TSBjYXBhYmlsaXR5IGFzIGFu ICZxdW90O2luZHVzdHJ5JnF1b3Q7IGNvbmNlcm4uPG86cD48L286cD48L3U+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ObyBvbmUgSSBhbSBhd2FyZSBvZiBpcyBwdXNoaW5nIGZvciBhIE1pdE0gY2Fw YWJpbGl0eSB0byBhZGRyZXNzIHRoaXMuJm5ic3A7Jm5ic3A7IEluIGZhY3QgaXQgd2FzIG9u ZSBvZiB0aGUgYWx0ZXJuYXRpdmUgc29sdXRpb25zIGZvciB3aGljaCBtYW55IGltcGxlbWVu dGF0aW9uIGlzc3VlcyB3ZXJlIGNpdGVkIGF0IHRoZSBQcmFndWUgbWVldGluZyBhbmQgb24g dGhpcyBsaXN0LiZuYnNwOyZuYnNwOyZuYnNwOyBCdXQgSSB3b3VsZCBsaWtlIHRvIGFzaywm bmJzcDsNCiB3aGF0IGlzIHRoZSBzb2x1dGlvbiB0aGF0IHlvdXIgY29tcGFueSBhbmQgb3Ro ZXJzIHRoYXQgeW91IHJlZmVyZW5jZSwgJm5ic3A7aGF2ZSBzb2x2ZWQgdGhpcyBwcm9ibGVt IGJ5IGltcGxlbWVudGluZz8mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF bmRDb21wb3NlIj48bzpwPiZuYnNwOzwvbzpwPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSA8Yj5P biBCZWhhbGYgT2YNCjwvYj5Ub255IEFyY2llcmk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBPY3RvYmVyIDIzLCAyMDE3IDU6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+IEFkYW0gQ2F1ZGls bCAmbHQ7YWRhbUBhZGFtY2F1ZGlsbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB0bHNAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIFB1YmxpY2F0aW9uIG9mIGRy YWZ0LXJocmQtdGxzLXRsczEzLXZpc2liaWxpdHktMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBPY3QgMjMsIDIwMTcgYXQgMTI6 MTEgUE0sIEFkYW0gQ2F1ZGlsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1AYWRhbWNhdWRp bGwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhbUBhZGFtY2F1ZGlsbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3NlIGFkdm9jYXRpbmcgZm9yIHNvbWUgc3RhbmRh cmRpemVkIG1ldGhvZCBvZiBzdWJ2ZXJ0aW5nIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG9m IFRMUyBoYXZlIGJlZW4gb2ZmZXJlZCBudW1lcm91cyBvcHRpb25zIGluIGdvb2QgZmFpdGgs IGFuZCBjb250aW51ZSB0byByZWplY3QgdGhlbSBhbGwuIEnigJltIGF3YXJlIG9mIGV4dHJl bWVseSBsYXJnZSBlbnRlcnByaXNlcyB0aGF0IGluIGZhY3QgcmVxdWlyZQ0KIFRMUyAxLjIg d2l0aCBQRlMsIGFzIHRoZXkgbWFkZSB0aGUgaW52ZXN0bWVudCBpbiBhZGRyZXNzaW5nIHRo aXMgaXNzdWUgZWFybHkgb24sIGFuZCBkbyBzbyBlZmZlY3RpdmVseS4gVGhpcyBjYW4gYmUg c29sdmVkIHdpdGhvdXQgY2hhbmdlcyB0byB0aGUgcHJvdG9jb2wgb3IgYSBzdGFuZGFyZGl6 ZWQg4oCcYmFja2Rvb3LigJ0gLSBhbmQgaXMgYmVpbmcgZG9uZSB0b2RheSBieSBhdCBsZWFz dCBzb21lIGVudGVycHJpc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhdmluZyB3 b3JrZWQgKGFuZCBwcmVzZW50bHkgd29ya2luZykgZm9yIG1vcmUgdGhhbiBvbmUgY29tcGFu eSBvZiB0aGlzIG5hdHVyZSwgaW4gdGhlIHBheW1lbnRzIGJ1c2luZXNzIG5vIGxlc3MsIEkg d291bGQgbGlrZSB0byByZXN0YXRlIHRoYXQgaXQncyBpbmNyZWRpYmx5IGRpc2luZ2VudW91 cyB0byBjaXRlIHRoZSBuZWVkIGZvciBzZWxmLU1pdE0gY2FwYWJpbGl0eSBhcyBhbiAmcXVv dDtpbmR1c3RyeSZxdW90OyBjb25jZXJuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGlmIGl0IHdlcmUgcG9zc2li bGUgdG8gYXNrIGZvciBhIGh1bSAmcXVvdDtmcm9tIGluZHVzdHJ5JnF1b3Q7LCB5b3UnZCBm aW5kIHRoZSBmaWVsZCBkaXZpZGVkIGJldHdlZW4gdGhvc2Ugd2hvIGhhdmUgaW52ZXN0ZWQg aW4gYSByZWFsIG9ic2VydmFiaWxpdHkgc3RvcnksIGFuZCB0aG9zZSB3aG8gdGhpbmsgcGFz c2l2ZSBuZXR3b3JrIHRyYWZmaWMgY29sbGVjdGlvbiBpcyB0aGUgb25seSB3YXkgdG8gZGVi dWcgdGhlaXINCiBzeXN0ZW1zLiBJIHRoaW5rIGlmIHlvdSB3ZXJlIHRvIGV2ZW4gdGFrZSBh IHN0cmF3IHBvbGwgb2YgdGhlIGJlc3QgYXBwcm9hY2hlcyBtb25pdG9yaW5nL29ic2VydmFi aWxpdHkgYW1vbmcgYWN0dWFsIGluZHVzdHJ5IHByYWN0aXRpb25lcnMsIHBhc3NpdmUgbmV0 d29yayB0cmFmZmljIGNvbGxlY3Rpb24gd291bGQgcmFuayBjbG9zZSB0byB0aGUgYm90dG9t IG9mIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGdvIGFzIGZhciBhcyB0byBzYXkgdGhhdCBpZiB5 b3UgYXJlIGFtb25nIHRob3NlIHJlcXVlc3RpbmcgdGhpcyBtaXNmZWF0dXJlLCB5b3UgYXJl IGRvaW5nIGEgdGVycmlibGUgam9iIHNlY3VyaW5nIHlvdXIgaW5mcmFzdHJ1Y3R1cmUsIGFu ZCBzaG91bGQgbG9vayBpbnRvIG1vZGVybiBvYnNlcnZhYmlsaXR5IHRlY2huaXF1ZXMgYXMg YW4gYWx0ZXJuYXRpdmUgdG8gZGVidWdnaW5nIGJ5IGNvbmNlbnRyYXRpbmcNCiBuZXR3b3Jr IHRyYWZmaWMgZHVtcHMgaW50byBhIHNpbmdsZSBwb2ludCBvZiBjb21wcm9taXNlIHdoaWNo IHJlcHJlc2VudHMgYSBodWdlIHNlY3VyaXR5IGxpYWJpbGl0eS4gWWVzLCBzd2l0Y2hpbmcg dG8gYSBuZXcgYXBwcm9hY2ggdG8gb2JzZXJ2YWJpbGl0eSBpcyBhIGh1Z2UgaW52ZXN0bWVu dCB0aGF0IHdpbGwgdGFrZSB0aW1lLCBidXQgc28gaXMgdXBncmFkaW5nIHRvIGEgbmV3IHZl cnNpb24gb2YgVExTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgJnF1b3Q7aW5kdXN0cnkmcXVvdDsgcmVhbGl0eSBpcyB0 aGF0IG1hbnkgY29tcGFuaWVzIGRvIG5vdCBuZWVkIGEgc2VsZi1NaXRNIG1pc2ZlYXR1cmUg YW5kIGNvdWxkIGJlIGFjdGl2ZWx5IGhhcm1lZCBieSBpdCwgYW5kIHdoaWxlIGEgc2VsZi1N aXRNIGNhcGFiaWxpdHkgbWF5IGJlIHN0YW5kYXJkIG9wZXJhdGluZyBwcmFjdGljZSBmb3Ig c29tZSwgaXQgaXMgbm90IHRydWUgZm9yIGFsbCwgYW5kIGlkZW50aWZ5aW5nIHRob3NlDQog d2hvIHdhbnQgdGhlIHNlbGYtTWl0TSBjYXBhYmlsaXR5IGFzICZxdW90O2luZHVzdHJ5JnF1 b3Q7IGlzIGEgY29tcG9zaXRpb24gZmFsbGFjeSBiZWluZyBsZXZlcmFnZWQgYXMgYSByaGV0 b3JpY2FsIHRhY3RpYywgaS5lLiAmcXVvdDtJRVRGIGlzIG5vdCBsaXN0ZW5pbmcgdG8gdGhl IGNvbmNlcm5zIG9mIGluZHVzdHJ5JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhIG1lbWJlciBvZiAmcXVvdDtp bmR1c3RyeSZxdW90OyBteXNlbGYsIEkgaW1wbG9yZSB0aGUgSUVURjogcGxlYXNlIGRvbid0 IG1ha2UgdGhlIHJlc3Qgb2YgdXMgbGVzcyBzZWN1cmUgYXQgdGhlIHJlcXVlc3Qgb2YgdGhv c2Ugd2hvIGFyZSBydW5uaW5nIGluc2VjdXJlIGluZnJhc3RydWN0dXJlcyBhbmQgYXBwYXJl bnRseSBpbnRlbmQgb24ga2VlcGluZyB0aGluZ3MgdGhhdCB3YXkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0KCgo8QlI+CjxodG1sPgogPHA+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhp cyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5n LCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0 aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ry b25pYyBtYWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQg ZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMu PC9wPgogPHA+Qmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBD YXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5k IGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGll bGQgQXNzb2NpYXRpb24uPC9wPgogIDwvaHRtbD4KCg== --_000_CY4PR14MB1368C52236964E69E1F124FBD7460CY4PR14MB1368namp_-- From nobody Mon Oct 23 15:30:52 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D8C13A2B8 for ; Mon, 23 Oct 2017 15:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 23cT45gke6hr for ; Mon, 23 Oct 2017 15:30:50 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9E6139EF2 for ; Mon, 23 Oct 2017 15:30:49 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9NMRHN4003913; Mon, 23 Oct 2017 23:30:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=KIjZzkd/pLc/nTzcW9hnviu+tY9Piu8xOkwVYQY/JnI=; b=AtICGbYkn16aLAo6CZhJDvJZw0zMuJ04VVWB41LkLbngQL4DqxpFzgTlHMLQ9Vw79UDx gN/Jllip5FIsy1UE22WVwQ6NbE/Ws9edpJyPFF35cbh3eXAJnQ3j5xQmtDS1YG/kd8CB XgLz6bvD2rIUy/9GQNuSWcm7xL0t/gqhwDFj1BCe4MfVWMqkc1Aoa0GVuSoaXSl9Q71P sCIdLjwBvgc6knbamOqVi+Fq0O+0fPQPcWP8GVDpEzsuDcX19DApLMs/QtTGTDFaSgTs 7dRP8u9AshSYex5FGPHu05fjKvhrhdLaTE/2Q/v3lXl5pvU/CT+iHlB5R75AKLCQnnBs zQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2dquad02g9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 23:30:39 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9NMPpfv007522; Mon, 23 Oct 2017 18:30:38 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2dr1jwr7sr-1; Mon, 23 Oct 2017 18:30:38 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id A782F20066; Mon, 23 Oct 2017 16:30:37 -0600 (MDT) To: "Ackermann, Michael" , "Salz, Rich" , Stephen Farrell , Darin Pettis , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> From: Benjamin Kaduk Message-ID: <460ef8f8-4853-2123-5721-30ef49a7c1d1@akamai.com> Date: Mon, 23 Oct 2017 17:30:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230316 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230316 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:30:51 -0000 On 10/23/2017 01:42 PM, Ackermann, Michael wrote: > But as stated in several previous Emails, the fact that TLS 1.2 is still available, does not mean that we won't have applications, business units or other entities that require TLS 1.3 and we will need to manage, monitor and secure these, as well as older versions. This seems sufficiently hypothetical so as to be non-actionable. That is, I assume that any sufficiently large enterprise must have some sort of architecture review process before a new system is deployed (and if one does not, it seems highly unlikely to be secure).  There would need to be some resolution of the conflict between those parties "requiring" monitorability and those parties "requiring" TLS 1.3 before such a system could get approved and approach deployment, so I feel obligated to insert "require" into scare quotes and attribute no real meaning to the statement. As was stated previously, this is a case of being stuck between a rock and a hard place.  While it is reasonable to investigate changing both of the rock and the hard place, it seems unwise to presume that it is one or the other specifically that must change.  You assert in a different message that it would be very expensive and time consuming to change "virtually every platform and application, not to mention all the management, monitoring, and security platforms" (e.g., the "hard place"), and I do not disagree.  It would also be expensive and time consuming to modify the TLS 1.3 protocol (e.g., "the rock") in the way(s) being proposed; unfortunately, the error bars on this cost estimate are necessarily quite large so as to take into account the risk of catastrophic breakdown of the security of the Internet.   It seems pretty clear that various parties involved in this conversation are applying different metric functions to weight these various costs, which makes it hard to see a path that would appease everyone. In that same "different message" you also mention that you have come to expect backwards compatibility, but can you really expect backwards compatibility without limit?  Does Windows 10 run MS-DOS executables?  Can a Kerberos principal who last set their password using Kerberos 4 expect to interoperate in a modern Kerberos 5 deployment?  Can you still log into a shell server via telnet?  There are many arguments in support of backwards compatibility, but they are not universal, and history provides plenty of precedent for security eventually overriding backwards compatibility.  So where would you put the boundary on the backwards compatibility for static RSA in TLS or equivalent non-forward-secrecy mechanisms?  Would you propose infinite compatibility in this space with no bound?  Ten years from now?  When a quantum computer can quickly factor 2048-bit RSA keys?  There are no doubt folks here would claim that the writing has been on the wall for five years or more that static RSA was out and forward secrecy was on the way in, and that now is the right time to draw the line and drop the backwards compatibility.    In fact, there is already presumed WG consensus for that position, so a strong argument indeed would be needed to shift the boundary from now.  I won't say that no such argument can exist, but I don't think we've seen it yet. -Ben From nobody Mon Oct 23 15:33:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD31A13A7E0 for ; Mon, 23 Oct 2017 15:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 aWfbwe83opIV for ; Mon, 23 Oct 2017 15:33:25 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1069139EF2 for ; Mon, 23 Oct 2017 15:33:25 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9NMWMf1010215; Mon, 23 Oct 2017 23:33:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=xHaifEvI0KvT37gsqfawbrByw3BRdo7EUi8e5bhU3b8=; b=Rhx3tYRX9mJAPwLAEdS8ZJwumC+q7ZaxXCi8gVp6tfCNQ/0dDvvKZc2eQK92LFTHxVw5 OZxN1Rm/xB28UFv6m+mPQ473iFiEa4UrJT0iiC3KCwmSXlMYmSqbT+DEnFoF2r3QbevY kEmRCb/Q9fEvQAgsT1BQnmmB4kcUayi9G+VnQHRqyhFv/InposteDw3/KTrFJw6CZRwA jhLUqd8smkMh/QTdepsvawUCbECr5Er1QTf7X52jX1ByFBArg2KbXfp45eWg/f1e2u0B xKdRBzai7EKxm0lM8z3ZevAIQQdKUPwq/LEdNJgaD8d2Y42kz86UsXrEhM8oFw6W0Bax aw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2dqws2871b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 23:33:20 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9NMVlHN000392; Mon, 23 Oct 2017 18:33:19 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dr1jvg9f0-1; Mon, 23 Oct 2017 18:33:19 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 51F8F20066; Mon, 23 Oct 2017 16:33:19 -0600 (MDT) To: "Ackermann, Michael" , Tony Arcieri , Adam Caudill Cc: "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> From: Benjamin Kaduk Message-ID: <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> Date: Mon, 23 Oct 2017 17:33:18 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230317 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710230317 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:33:27 -0000 On 10/23/2017 05:09 PM, Ackermann, Michael wrote: > No one I am aware of is pushing for a MitM capability to address > this.   In fact it was one of the alternative solutions for which many > implementation issues were cited at the Prague meeting and on this > list.    But I would like to ask,  what is the solution that your > company and others that you reference,  have solved this problem by > implementing?   Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the SSWrapDH1 private key has the cryptographic capability to inject traffic and modify plaintext for the affected connections? -Ben From nobody Mon Oct 23 15:40:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E76F13AAFF for ; Mon, 23 Oct 2017 15:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6DdyO9qGQBU for ; Mon, 23 Oct 2017 15:40:46 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50D713A902 for ; Mon, 23 Oct 2017 15:40:45 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id j4so13494269ywb.2 for ; Mon, 23 Oct 2017 15:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nrwhtimb+y/KpHxNAe5ox7Hq4luIA5EKmg2w6vRnru0=; b=klCb7HLuj4Vv45tqzCkBAK71uWBEvPCY1MyIEKnaQv9iO73/WpCXJ3QdrRyhyV3jt0 MS6e0fqouqSIDEQbtxVcO3H6IH0PXQ2QQ9p5Sqqsmv4XijDsCE5pZ2tF0isU5fkhVM71 Curc1sJQhx0tDjjamfW4my/3xUTQiUw+bWFwbAXAHe1mpypyRU23lrpYqP/alKAYOYVp zq1qIZdsFPxvMxvNcX8pGc5T10lN/KnCFiJaNTZtbvowA60lB5l1po2AxqAeUORFHw+5 KeLPtbJ0sMzJY6CWmE+c1yYxZen2xnz2dxaKoX7ZubP1gam0cWBoK/yJZ0G7LAfWUKac NcxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nrwhtimb+y/KpHxNAe5ox7Hq4luIA5EKmg2w6vRnru0=; b=cqa2+qXGCLZAMAC1RUQFcGyds9wU9IB4XYiAp1qlWgxtdabbfX6qPJ7pwCyqiwqRmZ wvtxrhgggPp7b3WCMfiNbOo4i4gWhmmXyPitvcl0SFkWmyjJxH290M/eRMxLoCc695uF 0SQmNtxJGGO4oHQuQM//+PwnBPpRAn+TUoA1xytYYynzFw5X2W304aE7X8JC+9jhIQhh 0oAJ22KdL0KJxv7kZSlx2SWuRlyKJQ1Mr1K7bNxwshnKD1ygGAnPFhIbmJCqza1OfTUw DftFnKpgT1a/NPZWxgMv7g4HS5L39Ptlrts54XhsBPDpzoyXzGVknftKPDiTcvGjQhwI BkJw== X-Gm-Message-State: AMCzsaU/PFhsRuXwpNsH0dZbvOo1ojWi2cu5KGEf3uXYjYrLOjjDTSSH LyM2J+ZEvlaba6tnoMkKO0OpAR76IqrLz8GXSeVX2A== X-Google-Smtp-Source: ABhQp+SUJEV9Mq88/oPvD2GqUaATjhKIZWz3/2ZrRqxukfQGaBEvfPz25I19e5lkt5mFnokOTOeVl1j6n8H6BH/3NhM= X-Received: by 10.129.103.193 with SMTP id b184mr9851435ywc.364.1508798445106; Mon, 23 Oct 2017 15:40:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.211.68 with HTTP; Mon, 23 Oct 2017 15:40:44 -0700 (PDT) In-Reply-To: <460ef8f8-4853-2123-5721-30ef49a7c1d1@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <460ef8f8-4853-2123-5721-30ef49a7c1d1@akamai.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 23 Oct 2017 15:40:44 -0700 Message-ID: To: Benjamin Kaduk Cc: "Ackermann, Michael" , "Salz, Rich" , Stephen Farrell , Darin Pettis , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:40:47 -0000 On Mon, Oct 23, 2017 at 3:30 PM, Benjamin Kaduk wrote: > There are no doubt folks here would claim that the writing has been on the wall for > five years or more that static RSA was out and forward secrecy was on > the way in, and that now is the right time to draw the line and drop the > backwards compatibility. In fact, there is already presumed WG > consensus for that position, so a strong argument indeed would be needed > to shift the boundary from now. I won't say that no such argument can > exist, but I don't think we've seen it yet. I don't have too strong an interest in this thread, it's not going anywhere, and I don't mind that. But I do want to chime in and point out that forward secrecy is not completely on the way in. With STEK based 0-RTT, it sounds like many implementors are happy to see user's requests, cookies, passwords and other secret tokens protected only by symmetric keys that are widely shared across many machines and geographic boundaries, with no defined key schedule, usage requirements or forward secrecy. Clearly, the consensus has been willing to accept that trade-off, and there is definite wiggle room. -- Colm From nobody Mon Oct 23 16:31:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A128013AC9E for ; Mon, 23 Oct 2017 16:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 EkEgGI7Kwlhw for ; Mon, 23 Oct 2017 16:31:05 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 DB84913AB3E for ; Mon, 23 Oct 2017 16:31:04 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 06E02C0EA3 for ; Mon, 23 Oct 2017 18:31:04 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 0532AC0D6C; Mon, 23 Oct 2017 18:31:02 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8672FFE05C; Mon, 23 Oct 2017 19:31:02 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5904FFE048; Mon, 23 Oct 2017 19:31:02 -0400 (EDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (unknown [216.32.180.17]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 23 Oct 2017 19:31:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sKPNQWou+6FZenPVh1N5dA8yVV/VaKxXkAtPILFSZXg=; b=SvA+KedO68BoxIyFP9CxZzlEvlCG+cd6DPWFEhn20wU83FPEsFlCle6bd9yZRpq4eusympcUTRchj41c6WJwwZULT1O69pdiLounIY8zNmjCIbsRkgMPkJ7dqHVuihGzv9K3flw/4Ytk/7XMdT0KLwa9C6LAPLY9a15UL9bEH6M= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 23:31:00 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Mon, 23 Oct 2017 23:31:00 +0000 From: "Ackermann, Michael" To: Benjamin Kaduk , Tony Arcieri , "Adam Caudill" CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIADZUkAgAAIFICAAB86QIAACamAgAD42jCAABKIgIAACV1AgAADZ4CAAAF70IAAA1UAgAAA2TCAABBTAIAAGDwAgAAqLYCAAAW3AIAACFwAgAAOs/A= Date: Mon, 23 Oct 2017 23:31:00 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> In-Reply-To: <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 20:pK47S1MFZ20L5JTdFvfxtzKYttALgyuvg8SJ1n8kRa9J1Lmur5Mo0vR+bTiuWThbd2q26agwfnyRHqoYws9wxMqLb1Y3f+LqN9SXpovNmeMyBxnjLz3hnxt51TlTHrd+KrnhBp8pUVL7faOt5r88KcW/5ahVwwp4RBDpWBsEyIk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 597e3a88-71cc-496e-cdb1-08d51a6e1e82 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1365; x-ms-traffictypediagnostic: CY4PR14MB1365: x-exchange-antispam-report-test: UriScan:(190756311086443)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3231020)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1365; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(24454002)(199003)(189002)(13464003)(230783001)(55016002)(97736004)(4326008)(99286003)(3280700002)(53936002)(101416001)(6436002)(66066001)(2950100002)(76176999)(39060400002)(50986999)(25786009)(229853002)(6506006)(6116002)(3660700001)(14454004)(68736007)(54356999)(189998001)(2906002)(77096006)(2900100001)(81156014)(81166006)(8936002)(7696004)(86362001)(5660300001)(105586002)(110136005)(53546010)(93886005)(6246003)(72206003)(9686003)(74316002)(80792005)(305945005)(316002)(478600001)(8676002)(106356001)(3846002)(33656002)(7736002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 23:31:00.1375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: f8ae9752-61e5-4e09-8866-6f8c695bbdac X-VPM-MSG-ID: d68b120b-80f4-40ce-88be-504f228ff685 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 23:31:06 -0000 Tk8NClRoZSBvYmplY3RpdmUgaXMgdG8gYmUgcGFzc2l2ZWx5IG9ic2VydmUsIG91dCBvZiBi YW5kIGFuZCBub3QgdG8gYmUgYSBNaXRNIG9yIG1vZGlmeS9pbmplY3QgdGV4dC4gICAgSnVz dCBhcyB3ZSBhbGwgZG8gdG9kYXkuICANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEJlbmphbWluIEthZHVrIFttYWlsdG86YmthZHVrQGFrYW1haS5jb21dIA0KU2Vu dDogTW9uZGF5LCBPY3RvYmVyIDIzLCAyMDE3IDY6MzMgUE0NClRvOiBBY2tlcm1hbm4sIE1p Y2hhZWwgPE1BY2tlcm1hbm5AYmNic20uY29tPjsgVG9ueSBBcmNpZXJpIDxiYXNjdWxlQGdt YWlsLmNvbT47IEFkYW0gQ2F1ZGlsbCA8YWRhbUBhZGFtY2F1ZGlsbC5jb20+DQpDYzogdGxz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gUHVibGljYXRpb24gb2YgZHJhZnQtcmhy ZC10bHMtdGxzMTMtdmlzaWJpbGl0eS0wMA0KDQpPbiAxMC8yMy8yMDE3IDA1OjA5IFBNLCBB Y2tlcm1hbm4sIE1pY2hhZWwgd3JvdGU6DQo+IE5vIG9uZSBJIGFtIGF3YXJlIG9mIGlzIHB1 c2hpbmcgZm9yIGEgTWl0TSBjYXBhYmlsaXR5IHRvIGFkZHJlc3MgdGhpcy7CoMKgIA0KPiBJ biBmYWN0IGl0IHdhcyBvbmUgb2YgdGhlIGFsdGVybmF0aXZlIHNvbHV0aW9ucyBmb3Igd2hp Y2ggbWFueSANCj4gaW1wbGVtZW50YXRpb24gaXNzdWVzIHdlcmUgY2l0ZWQgYXQgdGhlIFBy YWd1ZSBtZWV0aW5nIGFuZCBvbiB0aGlzIA0KPiBsaXN0LsKgwqDCoCBCdXQgSSB3b3VsZCBs aWtlIHRvIGFzayzCoCB3aGF0IGlzIHRoZSBzb2x1dGlvbiB0aGF0IHlvdXIgDQo+IGNvbXBh bnkgYW5kIG90aGVycyB0aGF0IHlvdSByZWZlcmVuY2UsIMKgaGF2ZSBzb2x2ZWQgdGhpcyBw cm9ibGVtIGJ5IA0KPiBpbXBsZW1lbnRpbmc/DQoNCklzIG5vdCBkcmFmdC1yaHJkLXRscy10 bHMxMy12aXNpYmlsaXR5IGEgTWl0TSwgaW4gdGhhdCB0aGUgaG9sZGVyIG9mIHRoZQ0KU1NX cmFwREgxIHByaXZhdGUga2V5IGhhcyB0aGUgY3J5cHRvZ3JhcGhpYyBjYXBhYmlsaXR5IHRv IGluamVjdCB0cmFmZmljIGFuZCBtb2RpZnkgcGxhaW50ZXh0IGZvciB0aGUgYWZmZWN0ZWQg Y29ubmVjdGlvbnM/DQoNCi1CZW4NCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhp cyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5n LCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0 aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ry b25pYyBtYWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQg ZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMu CiAKIEJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBO ZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRl cGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFz c29jaWF0aW9uLgo= From nobody Mon Oct 23 17:42:06 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE3813AE15 for ; Mon, 23 Oct 2017 17:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 OKJZRtkleUG7 for ; Mon, 23 Oct 2017 17:42:03 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0126.outbound.protection.outlook.com [104.47.38.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB0F139438 for ; Mon, 23 Oct 2017 17:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DbpwO7eo5xJYHCE6C+2VgZqNeBzxFcM3WXuFB6flBgc=; b=SOpCi3c0U6FwSiVyiigUzfcVtR7A8RI/T/q776i+04DkG1UWaINBa3BbajAQRNU7tC78Tyg12QhmxcfL2FmxTIbxOAxsl461Q4IRi79BrqIPqe4TzwjlGYfWNl/U5dzJA/mHfdRkSdsXsUNDLfExH3X3lltlLBPB6ytwLDoa4dQ= Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) by CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.197.0; Tue, 24 Oct 2017 00:42:01 +0000 Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0197.001; Tue, 24 Oct 2017 00:42:01 +0000 From: Andrei Popov To: "'tls@ietf.org'" Thread-Topic: TLS 1.3 Record Boundaries Thread-Index: AdNMXL4noy7fkUD8Q9qPZCvybmOXqQABBraA Date: Tue, 24 Oct 2017 00:42:01 +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: [2001:4898:80e8:6::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0277; 6:rjz2+hFqo504kDRqUn1ePA0AHD2CoM6C8rqbibJqwvo0TwaoG3VntmZSx4fG56mwDKyDS4aqnYJYmu6VWwSF8WU/us+ZiEfHZtQ7stRSW5roT7UwQxQQrfQIlr/wwlhQ1JnGYoLUcoOnaQvLlcX4deD+eznqXMN5uZLY9evV6faGymtZ9b3bijhp7NN+iWPvX/xRNgEofecR8dvbPh0VdxH8UsieHwOqjGS3oUonPAnEC/bvhbs9CwcPyRVZL261eP2go5ctvmLGrNMoUViXlMFnVFWZ3akhpQsxNrK1hvA1XYMJAtNmeMk/UMkxQSFjB4eK9xn1J5KpIMkYvv0QzxKw+UzsJi/tdPMm7sRFGyM=; 5:UwHMTS4tRdeyPvgTz8G4QsaVmemGeOzwm2feo6fKxy0yeGKIa8FmkH9ZMQ+r9GU89IlOC1NjEfSnVpiIS1Sg73zy92S7MMlDjoxMFZUodOKR1FGSUXbV6Axi25acShWVgZExhaqqvsJvZzXxLPjSDGmF7XrsWG6FrHpjXAT0o30=; 24:jGVabIFTWGyOJizPkcFuvO9haOI7uDZH4PlWdOZl40QVwlTSbcM99M/EcN7AOU8zZrCYrB5UUv162XLJLfaRByk1oUZAqPjDD9yJ2kwHzr8=; 7:zPQE66+u81ZvpRtx/q4c507YKVNzEQ+4eRktOIcrFFBNQDfffEmB+u+fz4w2QLsc0MY97X6ccyOzYthuxAxMRxSAgUPmkvXeqxQ/xTY8oBXRFHpQmNO2QZV8J40wqK4OK6+s/qqJe1OaQ+7S/JAr+viZ+xqwVRR1WspyOiWEikiVWsD38T94lHS2J1f6puxhURMD27FpL+aAC/NqqE6r8LSyMiukx0Zu9yaxxZL7ippfZd+4i/XJO2aEW6Bt1HvP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c2518516-4c22-45c6-8377-08d51a780a62 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:CY4PR21MB0277; x-ms-traffictypediagnostic: CY4PR21MB0277: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(3231020)(6055026)(61426038)(61427038)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0277; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0277; x-forefront-prvs: 047001DADA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(376002)(346002)(47760400005)(189002)(199003)(478600001)(72206003)(14454004)(10290500003)(76176999)(50986999)(54356999)(8990500004)(6116002)(790700001)(102836003)(7696004)(106356001)(2906002)(105586002)(7116003)(5660300001)(7736002)(10090500001)(81166006)(3660700001)(8676002)(81156014)(101416001)(3280700002)(33656002)(8936002)(74316002)(2950100002)(6436002)(6916009)(77096006)(189998001)(316002)(22452003)(6506006)(2900100001)(86612001)(86362001)(55016002)(99286003)(54896002)(9686003)(6306002)(53936002)(2940100002)(97736004)(68736007)(25786009)(491001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0277; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0120498BA401EA25CC2E439B8C470CY4PR21MB0120namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c2518516-4c22-45c6-8377-08d51a780a62 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2017 00:42:01.3457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0277 Archived-At: Subject: [TLS] TLS 1.3 Record Boundaries X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 00:42:05 -0000 --_000_CY4PR21MB0120498BA401EA25CC2E439B8C470CY4PR21MB0120namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft-21 says: "Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary." It is not clear to me what "sending messages in alignment with a record bou= ndary" means. Does it mean that each record is either all plaintext or all encrypted with= key X? And therefore one cannot combine, e.g., ServerHello (plaintext) and= EncryptedExtensions (encrypted with the handshake traffic key) messages in= one record? Thanks, Andrei --_000_CY4PR21MB0120498BA401EA25CC2E439B8C470CY4PR21MB0120namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft-21 says:

“Handshake messages MUST NOT span key changes.=   Implementations

  MUST verify that all messages immediately pre= ceding a key change

  align with a record boundary; if not, then th= ey MUST terminate the

  connection with an "unexpected_message&q= uot; alert.  Because the 

  ClientHello, EndOfEarlyData, ServerHello= , Finished, and KeyUpdate

 messages can immediately precede a key change,= implementations

  MUST send these messages in alignment with a = record boundary.”

 

It is not clear to me what “sending messages i= n alignment with a record boundary” means.

Does it mean that each record is either all plaintex= t or all encrypted with key X? And therefore one cannot combine, e.g., Serv= erHello (plaintext) and EncryptedExtensions (encrypted with the handshake t= raffic key) messages in one record?

 

Thanks,

 

Andrei

--_000_CY4PR21MB0120498BA401EA25CC2E439B8C470CY4PR21MB0120namp_-- From nobody Mon Oct 23 18:15:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B14139EF2 for ; Mon, 23 Oct 2017 18:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K4L_4tJNE91 for ; Mon, 23 Oct 2017 18:15:15 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 883F8138BE2 for ; Mon, 23 Oct 2017 18:15:15 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id t71so13727894ywc.3 for ; Mon, 23 Oct 2017 18:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6oB+cK6jJQn/ckljqYOkrUH3NA63dpmmKmnT333rWRk=; b=vWO/Df+eWv1TeVU2+QRHGB+ffMtTe1aBUE7zvEkVBjr+Fy2jY9BK7rpw7EMV2bHrO5 dZzipsUopvTWSv0YQCXZD19RjpAQCjlfg2egG3o/XrWQiPgQMWAnXYbqpqB06cvBXZ5W IFRvoT/2FleQJdd8iTW+Gkx4LzoKwuWQ4mUrohQsu98VwbFHgZf4gnNAPD8IhYIe29lz lNHcnRfR116NUi58CVzuOeQ6klqhf9ZttdDm5+l0tX8eyqdWk+wgwJgVU0xqWLj2lbkH mYadO2g7v/yv5+6+SUu9MfXd0A5Yfx5sYg3za8fQxaAo09ZR+fgcqHRrgAQTBzP+W56u TIMg== 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=6oB+cK6jJQn/ckljqYOkrUH3NA63dpmmKmnT333rWRk=; b=Qj5UPyHsc94fAP7WMZvFtuLCZ1UqdyZYcVec7bdtEPYnkw0MNbnYrM0XRBSWGf9inA DmRbmMr42eyMjGiOIiWtjwP9IBIfA5tuGoL9Rk6RV3SGFYg4Bgcv2eZ3lnBFlrTZqsTC zO7MRl3RYTIcu2VSUt1OaUaNz4omGAdLQ37aRNLB+mtjCRSFVMpiYg/5c3TV4bBFXNtu TYU19gVUhpdUC2qQUfroXnktO86BuisCAmDNWsfX1DN9Yx42/0ZO2GQDbv+QNEWo0TnZ ez1kD8mRO3447mWvmdz2cZ562dXO2tGcR8MhuMH2umjPf0DFdgcxODn3n1mur65BDYRM tHQQ== X-Gm-Message-State: AMCzsaVmjvmqx1k+xthrPTn8C+W7aUiFReZqZLwlaRx4tDY3sCWq9zoM KmDwBGITYjhPtvWc2AMO8l9QajchhaAVego6a+sH6xGT0oM= X-Google-Smtp-Source: ABhQp+TIWHCtGT9hG3iQMj9LN4MJztLPzxhnmCJpKV0VvQZIAZOPi6Y81xuRi0/620NHP01/eh2xb3HMZbC6pbBJ9WE= X-Received: by 10.37.20.6 with SMTP id 6mr9801513ybu.339.1508807714428; Mon, 23 Oct 2017 18:15:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 23 Oct 2017 18:14:33 -0700 (PDT) From: Eric Rescorla Date: Mon, 23 Oct 2017 18:14:33 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113d2b94da6eed055c40abda" Archived-At: Subject: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 01:15:17 -0000 --001a113d2b94da6eed055c40abda Content-Type: text/plain; charset="UTF-8" We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. The one thing we ran into was the potential need to ACK in cases where you can't process *any* records (e.g., you receive what's actually EE, but you can't decrypt it). In this case, you want to send an empty ACK. See PR: https://github.com/tlswg/dtls13-spec/pull/14 This will be going into -02 modulo big objections. -Ekr --001a113d2b94da6eed055c40abda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We now have DTLS 1.3 implemented in NSS, which went p= retty cleanly.

The one thing we ran into was the p= otential need to ACK in cases where you
can't process *any* r= ecords (e.g., you receive what's actually EE, but you
can'= ;t decrypt it). In this case, you want to send an empty ACK.

=
See PR:
https://github.com/tlswg/dtls13-spec/pull/14

T= his will be going into -02 modulo big objections.
-Ekr

--001a113d2b94da6eed055c40abda-- From nobody Mon Oct 23 18:59:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBBC138BE2 for ; Mon, 23 Oct 2017 18:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 a_i_KjqIuIXF for ; Mon, 23 Oct 2017 18:59:00 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 57B75138BCD for ; Mon, 23 Oct 2017 18:58:59 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v9O1wu2I007140; Mon, 23 Oct 2017 21:58:56 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Ackermann, Michael" CC: Benjamin Kaduk , Tony Arcieri , "Adam Caudill" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO713gKFaj/ze3UaJfDxWNuaqP6LqPDwAgAFTKoCAAAWQgIAAANiAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAACX8gIAABAIAgAAHdgCAAASKgIADZUkAgAAIFICAACFZAIAAB4qAgAD5KwCAABI3gIAAC5wAgAABKICAAAOBgIAAAU8AgAANI4CAAAQJAIAAGDwAgAAqLYCAAAdyAIAABqEAgAAQHwCAAClUgA== Date: Tue, 24 Oct 2017 01:58:56 +0000 Message-ID: <029D140E-048C-4C23-A8F2-3A18C455BB50@ll.mit.edu> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-DCA66C09-E81B-44F2-B3D4-6FBC8C327C71"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240026 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 01:59:03 -0000 --Apple-Mail-DCA66C09-E81B-44F2-B3D4-6FBC8C327C71 Content-Type: multipart/alternative; boundary=Apple-Mail-A3DBE339-B1C9-4EB8-B710-CCC14FC2FF54 Content-Transfer-Encoding: 7bit --Apple-Mail-A3DBE339-B1C9-4EB8-B710-CCC14FC2FF54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Who cares about the objective? People are asking about the result. Regards, Uri Sent from my iPhone > On Oct 23, 2017, at 19:32, Ackermann, Michael wrote= : >=20 > NO > The objective is to be passively observe, out of band and not to be a MitM= or modify/inject text. Just as we all do today. =20 >=20 > -----Original Message----- > From: Benjamin Kaduk [mailto:bkaduk@akamai.com]=20 > Sent: Monday, October 23, 2017 6:33 PM > To: Ackermann, Michael ; Tony Arcieri ; Adam Caudill > Cc: tls@ietf.org > Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 >=20 >> On 10/23/2017 05:09 PM, Ackermann, Michael wrote: >> No one I am aware of is pushing for a MitM capability to address this. =20= >> In fact it was one of the alternative solutions for which many=20 >> implementation issues were cited at the Prague meeting and on this=20 >> list. But I would like to ask, what is the solution that your=20 >> company and others that you reference, have solved this problem by=20 >> implementing? >=20 > Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the > SSWrapDH1 private key has the cryptographic capability to inject traffic a= nd modify plaintext for the affected connections? >=20 > -Ben >=20 >=20 > The information contained in this communication is highly confidential and= is intended solely for the use of the individual(s) to whom this communicat= ion is directed. If you are not the intended recipient, you are hereby notif= ied that any viewing, copying, disclosure or distribution of this informatio= n is prohibited. Please notify the sender, by electronic mail or telephone, o= f any unintended receipt and delete the original message without making any c= opies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are n= onprofit corporations and independent licensees of the Blue Cross and Blue S= hield Association. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-A3DBE339-B1C9-4EB8-B710-CCC14FC2FF54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPldobyBjYXJlcyBh Ym91dCB0aGUgb2JqZWN0aXZlPyBQZW9wbGUgYXJlIGFza2luZyBhYm91dCB0aGUgcmVzdWx0Ljxi cj48YnI+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5SZWdhcmRzLDxkaXY+VXJpPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+PC9kaXY+PGRpdj48 YnI+T24gT2N0IDIzLCAyMDE3LCBhdCAxOTozMiwgQWNrZXJtYW5uLCBNaWNoYWVsICZsdDs8YSBo cmVmPSJtYWlsdG86TUFja2VybWFubkBiY2JzbS5jb20iPk1BY2tlcm1hbm5AYmNic20uY29tPC9h PiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pjxz cGFuPk5PPC9zcGFuPjxicj48c3Bhbj5UaGUgb2JqZWN0aXZlIGlzIHRvIGJlIHBhc3NpdmVseSBv YnNlcnZlLCBvdXQgb2YgYmFuZCBhbmQgbm90IHRvIGJlIGEgTWl0TSBvciBtb2RpZnkvaW5qZWN0 IHRleHQuICZuYnNwOyZuYnNwOyZuYnNwO0p1c3QgYXMgd2UgYWxsIGRvIHRvZGF5LiAmbmJzcDs8 L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08L3NwYW4+PGJyPjxzcGFuPkZyb206IEJlbmphbWluIEthZHVrIFs8YSBocmVmPSJtYWlsdG86 YmthZHVrQGFrYW1haS5jb20iPm1haWx0bzpia2FkdWtAYWthbWFpLmNvbTwvYT5dIDwvc3Bhbj48 YnI+PHNwYW4+U2VudDogTW9uZGF5LCBPY3RvYmVyIDIzLCAyMDE3IDY6MzMgUE08L3NwYW4+PGJy PjxzcGFuPlRvOiBBY2tlcm1hbm4sIE1pY2hhZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpNQWNrZXJt YW5uQGJjYnNtLmNvbSI+TUFja2VybWFubkBiY2JzbS5jb208L2E+Jmd0OzsgVG9ueSBBcmNpZXJp ICZsdDs8YSBocmVmPSJtYWlsdG86YmFzY3VsZUBnbWFpbC5jb20iPmJhc2N1bGVAZ21haWwuY29t PC9hPiZndDs7IEFkYW0gQ2F1ZGlsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1AYWRhbWNhdWRp bGwuY29tIj5hZGFtQGFkYW1jYXVkaWxsLmNvbTwvYT4mZ3Q7PC9zcGFuPjxicj48c3Bhbj5DYzog PGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+ PHNwYW4+U3ViamVjdDogUmU6IFtUTFNdIFB1YmxpY2F0aW9uIG9mIGRyYWZ0LXJocmQtdGxzLXRs czEzLXZpc2liaWxpdHktMDA8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+T24gMTAv MjMvMjAxNyAwNTowOSBQTSwgQWNrZXJtYW5uLCBNaWNoYWVsIHdyb3RlOjwvc3Bhbj48YnI+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Tm8gb25lIEkgYW0gYXdhcmUgb2YgaXMgcHVzaGlu ZyBmb3IgYSBNaXRNIGNhcGFiaWxpdHkgdG8gYWRkcmVzcyB0aGlzLiZuYnNwOyZuYnNwOyA8L3Nw YW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5JbiBmYWN0 IGl0IHdhcyBvbmUgb2YgdGhlIGFsdGVybmF0aXZlIHNvbHV0aW9ucyBmb3Igd2hpY2ggbWFueSA8 L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5pbXBs ZW1lbnRhdGlvbiBpc3N1ZXMgd2VyZSBjaXRlZCBhdCB0aGUgUHJhZ3VlIG1lZXRpbmcgYW5kIG9u IHRoaXMgPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+bGlzdC4mbmJzcDsmbmJzcDsmbmJzcDsgQnV0IEkgd291bGQgbGlrZSB0byBhc2ssJm5ic3A7 IHdoYXQgaXMgdGhlIHNvbHV0aW9uIHRoYXQgeW91ciA8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5jb21wYW55IGFuZCBvdGhlcnMgdGhhdCB5b3Ug cmVmZXJlbmNlLCAmbmJzcDtoYXZlIHNvbHZlZCB0aGlzIHByb2JsZW0gYnkgPC9zcGFuPjxicj48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+aW1wbGVtZW50aW5nPzwv c3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+SXMgbm90IGRyYWZ0 LXJocmQtdGxzLXRsczEzLXZpc2liaWxpdHkgYSBNaXRNLCBpbiB0aGF0IHRoZSBob2xkZXIgb2Yg dGhlPC9zcGFuPjxicj48c3Bhbj5TU1dyYXBESDEgcHJpdmF0ZSBrZXkgaGFzIHRoZSBjcnlwdG9n cmFwaGljIGNhcGFiaWxpdHkgdG8gaW5qZWN0IHRyYWZmaWMgYW5kIG1vZGlmeSBwbGFpbnRleHQg Zm9yIHRoZSBhZmZlY3RlZCBjb25uZWN0aW9ucz88L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+ PHNwYW4+LUJlbjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxz cGFuPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGhp Z2hseSBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBkaXJlY3RlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29weWluZywgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRp b24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFueSB1bmludGVuZGVk IHJlY2VpcHQgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRob3V0IG1ha2luZyBh bnkgY29waWVzLjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj4gQmx1ZSBDcm9zcyBC bHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4g YXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0 aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uPC9zcGFuPjxicj48c3Bh bj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48 YnI+PHNwYW4+VExTIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0ibWFpbHRv OlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1 b3RlPjwvYm9keT48L2h0bWw+ --Apple-Mail-A3DBE339-B1C9-4EB8-B710-CCC14FC2FF54-- --Apple-Mail-DCA66C09-E81B-44F2-B3D4-6FBC8C327C71 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcxMDI0MDE1ODU1WjAjBgkqhkiG9w0BCQQxFgQUQIcPEeWv2BQREGPZOUNGCGSbTMcwbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBAID0Go7hS/Vw4VB3iBEE7BRWpqLBZEnmv+1xGGcyV94OPCPTc0VZc4OTHHoc2v6M NCh1VHf+LmgfSsLM1pCQlccp4KBGGJdENg5TW1/4iaAfcfC0IoREnUHZEQMqnd+zV1PK1aFUIn+v 68pcvI7SbkyttJzRMyFhr+sRHJx1hLqnG86LiaKhUhcWbXe7+wDUT3dRhpBd8QCVZ0ZKRrcaQow0 xT1BM2jeWuNKkeuNCoGBC3Be3Ui/HASvdF/ObCxWsL8yCryCBX5DsqZWP5DiT63114SnDGsAuoPp uT4LL9pom2G7pA01XiIrZzUr7MsYum1PqIzS3vfGJeTcec4cSIgAAAAAAAA= --Apple-Mail-DCA66C09-E81B-44F2-B3D4-6FBC8C327C71-- From nobody Mon Oct 23 19:47:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E7513B133 for ; Mon, 23 Oct 2017 19:47:14 -0700 (PDT) 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 AwWHoNBGlytS for ; Mon, 23 Oct 2017 19:47:13 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 55D2213B13C for ; Mon, 23 Oct 2017 19:47:13 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id p1so28737608qtg.2 for ; Mon, 23 Oct 2017 19:47:13 -0700 (PDT) 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=4WiePUH96SiBTzagOuz9XmJhFYMrEWgdQLUAqqdxewU=; b=SspJBTRzCkmtqzJf1h8L2K/LLLSzbpsHtH2J68zgHdmzjik8fPV5fvLWY2gVqiztOx 8oJl5yYEVMUN8t5Dbo1dESpoF/dkLUApkvBgS2HLaba5XGYdGa7sreqFc/5UbzZSc0ej M/h7rJzi+dts2X32vEVOGWc15/jrf2QTxTdyZKV3JivW5aC9AgWHajPRlcT4Qk8/HCj6 xk/RkyOUNSWHFONP2LuirVNAxjjiV1gUPISMu4XeRgyF8MRD7kPcShlL4lxqvSYcIXOF fu8aKZQfM3CMGNwpqm4QTHdc71mp0JOt1/1U1w7i5YR3dHiQoSeMeTWQTepDQOAvbFRQ MpjA== 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=4WiePUH96SiBTzagOuz9XmJhFYMrEWgdQLUAqqdxewU=; b=LwNN5zsBNXGtxvLOFvLAc75/keujtGZRminTUS07IMOvkduJ57dfzlomQ4WNEg5CmB asuV1mqIRX3AX+x/SD4r6Dlx+sriiLRcE/Sf/moCP8ya8/VjRXVQfNAPhE+w97BEiZ+A 2xor+WlGKy51H8cmRbq4Y5e3Qo5YdK0c2wc8BOqcGmbuDIPacshstX0nlrRNRBRWMbjd 7xjngzPZJoslEjnyaTdzSBm2XQeaYeXw23Vx+30rxgPfSS7FKMfHn7c5culZVOOokI05 gAaEK1+YqvO4XlJQ4IEPT3npSLpB+yV4GlWGuNBnBBuORJ9pG+ZBrwXYkVOZyi4l7Fph 73Dw== X-Gm-Message-State: AMCzsaVaT1SYR/kWMbk7jvCmRpm2zCo7nTg0l0fjfsS65nMvc1/n14X8 B0DPcbpb/xnuwYOM8I42GvTnt+Fn/LZSvAX0/9nSbg== X-Google-Smtp-Source: ABhQp+TBLXazddeWrcqq7p61OdfUWxkkaoJxwet2tM81/8w0nHL8yvt45DV6E9d0jZVte6ZxtFwbnsnKEtwD+QlLmX4= X-Received: by 10.200.37.107 with SMTP id 40mr23366870qtn.85.1508813232500; Mon, 23 Oct 2017 19:47:12 -0700 (PDT) MIME-Version: 1.0 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> In-Reply-To: From: Tony Arcieri Date: Tue, 24 Oct 2017 02:47:01 +0000 Message-ID: To: "Ackermann, Michael" , Adam Caudill , Benjamin Kaduk Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113f47fac177b2055c41f4b3" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 02:47:15 -0000 --001a113f47fac177b2055c41f4b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 23, 2017 at 6:31 PM Ackermann, Michael wrote: > NO > The objective is to be passively observe, out of band and not to be a Mit= M > or modify/inject text. Just as we all do today. You seem to be confused as to the difference between an active vs passive MitM. Using the term =E2=80=9CMitM=E2=80=9D for a passive network observer,= particularly one which can decrypt traffic, is perfectly apt. > -- Tony Arcieri --001a113f47fac177b2055c41f4b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 23, 2017 at 6:31 PM Ackermann, Michael <MAckermann@bcbsm.com> wrote:
NO
The objective is to be passively observe, out of band and not to be a MitM = or modify/inject text.=C2=A0 =C2=A0 Just as we all do today.

You seem to be confused as to t= he difference between an active vs passive MitM. Using the term =E2=80=9CMi= tM=E2=80=9D for a passive network observer, particularly one which can decr= ypt traffic, is perfectly apt.
--
Tony Arcieri
--001a113f47fac177b2055c41f4b3-- From nobody Tue Oct 24 00:31:52 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE5713D2D6 for ; Tue, 24 Oct 2017 00:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 0D7VOc182i11 for ; Tue, 24 Oct 2017 00:31:48 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4449913D234 for ; Tue, 24 Oct 2017 00:31:47 -0700 (PDT) From: Ion Larranaga Azcue To: "Ackermann, Michael" , Benjamin Kaduk , Tony Arcieri , Adam Caudill CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO72INxjGwk0f70e0hZ2DWWm8J6Lp6GoAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALYAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAACX8gIAABAMAgAAHdQCAAASLgIADZUgAgAAIFICAACFZAIAAB4qAgAD5LACAABI2gIAAC5wAgAABKYCAAAOAgIAAAU8AgAANI4CAAAQJAIAAGDwAgAAqLYCAAAdyAIAABqIAgAAQHwCAAI3vkA== Date: Tue, 24 Oct 2017 07:31:43 +0000 Message-ID: <2212c90b7644461c87510ae2391e1e83@LXDOMEXC01.ssidom.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> In-Reply-To: Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 07:31:51 -0000 RXZlbiBpZiBZT1VSIG9iamVjdGl2ZSBpcyB0byBwYXNzaXZlbHkgb2JzZXJ2ZSwgeW91IGhhdmUg dG8gYWRtaXQgdGhhdCB0aGlzIG1lY2hhbmlzbSBhbGxvd3MgT1RIRVIgUEVPUExFIHVzaW5nIGl0 IHRvIG1vZGlmeSB0aGUgZW5jcnlwdGVkIGRhdGEsIGFuZCB3ZSBzaG91bGQgYWx3YXlzIGNvbnNp ZGVyIHRoZSB3b3JzdC1jYXNlIHNjZW5hcmlvLg0KDQpJbiBmYWN0LCBteSBvcGluaW9uIGEgY291 cGxlIG9mIHdlZWtzIGFnbyB3YXMgdGhhdCB3ZSBoYWQgdG8gZmluZCBzb21lIHdheSB0byBwcm92 aWRlIHZpc2liaWxpdHkgZm9yIFRMUyAxLjMsIGJ1dCBhZnRlciByZWFkaW5nIG90aGVyIHBlb3Bs ZSdzIGNvbW1lbnRzIG9uIHRoaXMgdGhyZWFkLCBJIHRoaW5rIHRoZXJlIGFyZSBsb3RzIG9mIHNv bHV0aW9ucyB0byBwcm92aWRlIHZpc2liaWxpdHkgb2YgdGhlIGVuY3J5cHRlZCBkYXRhIHdpdGhp biBpbnRlcm5hbCBuZXR3b3Jrcy4gQW5kIGlmIHRoZSB0cmFuc2l0aW9uIHJlcXVpcmVzIHdvcmsg YW5kIG1vbmV5Li4uIFdlbGwsIHNlY3VyaXR5IGFsd2F5cyBkb2VzLg0KDQpJIHNpZGUgd2l0aCB0 aGUgcGVvcGxlIHRoYXQgdGhpbmsgd2Ugc2hvdWxkIGNsb3NlIHRoaXMgdG9waWMgYW5kIG1vdmUg b24gKEkgYW0gZXZlbiB3b25kZXJpbmcgaWYgaXQgd2FzIGEgZ29vZCBpZGVhIHRvIHNlbmQgdGhp cyBtYWlsIGFuZCB0aHVzIGZ1ZWwgdGhlIGRpc2N1c3Npb24pLiBJJ20gZWFnZXIgdG8gc2VlIGEg ZmluYWwgc3BlY2lmaWNhdGlvbiBvZiBUTFMgMS4zIGFuZCBJJ20gY3VycmVudGx5IGZydXN0cmF0 ZWQgd2l0aCBiZWluZyB1bmFibGUgdG8gc2VlIHRoZSBsaWdodCBhdCB0aGUgZW5kIG9mIHRoZSB0 dW5uZWwgd2hpbGUgd2UgYXJlIGp1c3QgZ29pbmcgcm91bmQgYW5kIHJvdW5kIHRoZSBzYW1lIGRp c2N1c3Npb24uLi4NCg0KPiAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiBEZTogVExTIFtt YWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIEVuIG5vbWJyZSBkZSBBY2tlcm1hbm4sIE1pY2hh ZWwNCj4gRW52aWFkbyBlbDogbWFydGVzLCAyNCBkZSBvY3R1YnJlIGRlIDIwMTcgMTozMQ0KPiBQ YXJhOiBCZW5qYW1pbiBLYWR1ayA8YmthZHVrQGFrYW1haS5jb20+OyBUb255IEFyY2llcmkNCj4g PGJhc2N1bGVAZ21haWwuY29tPjsgQWRhbSBDYXVkaWxsIDxhZGFtQGFkYW1jYXVkaWxsLmNvbT4N Cj4gQ0M6IHRsc0BpZXRmLm9yZw0KPiBBc3VudG86IFJlOiBbVExTXSBQdWJsaWNhdGlvbiBvZiBk cmFmdC1yaHJkLXRscy10bHMxMy12aXNpYmlsaXR5LTAwDQo+IA0KPiBOTw0KPiBUaGUgb2JqZWN0 aXZlIGlzIHRvIGJlIHBhc3NpdmVseSBvYnNlcnZlLCBvdXQgb2YgYmFuZCBhbmQgbm90IHRvIGJl IGEgTWl0TSBvcg0KPiBtb2RpZnkvaW5qZWN0IHRleHQuICAgIEp1c3QgYXMgd2UgYWxsIGRvIHRv ZGF5Lg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4g S2FkdWsgW21haWx0bzpia2FkdWtAYWthbWFpLmNvbV0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVy IDIzLCAyMDE3IDY6MzMgUE0NCj4gVG86IEFja2VybWFubiwgTWljaGFlbCA8TUFja2VybWFubkBi Y2JzbS5jb20+OyBUb255IEFyY2llcmkNCj4gPGJhc2N1bGVAZ21haWwuY29tPjsgQWRhbSBDYXVk aWxsIDxhZGFtQGFkYW1jYXVkaWxsLmNvbT4NCj4gQ2M6IHRsc0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW1RMU10gUHVibGljYXRpb24gb2YgZHJhZnQtcmhyZC10bHMtdGxzMTMtdmlzaWJpbGl0 eS0wMA0KPiANCj4gT24gMTAvMjMvMjAxNyAwNTowOSBQTSwgQWNrZXJtYW5uLCBNaWNoYWVsIHdy b3RlOg0KPiA+IE5vIG9uZSBJIGFtIGF3YXJlIG9mIGlzIHB1c2hpbmcgZm9yIGEgTWl0TSBjYXBh YmlsaXR5IHRvIGFkZHJlc3MgdGhpcy4NCj4gPiBJbiBmYWN0IGl0IHdhcyBvbmUgb2YgdGhlIGFs dGVybmF0aXZlIHNvbHV0aW9ucyBmb3Igd2hpY2ggbWFueQ0KPiA+IGltcGxlbWVudGF0aW9uIGlz c3VlcyB3ZXJlIGNpdGVkIGF0IHRoZSBQcmFndWUgbWVldGluZyBhbmQgb24gdGhpcw0KPiA+IGxp c3QuwqDCoMKgIEJ1dCBJIHdvdWxkIGxpa2UgdG8gYXNrLMKgIHdoYXQgaXMgdGhlIHNvbHV0aW9u IHRoYXQgeW91cg0KPiA+IGNvbXBhbnkgYW5kIG90aGVycyB0aGF0IHlvdSByZWZlcmVuY2UsIMKg aGF2ZSBzb2x2ZWQgdGhpcyBwcm9ibGVtIGJ5DQo+ID4gaW1wbGVtZW50aW5nPw0KPiANCj4gSXMg bm90IGRyYWZ0LXJocmQtdGxzLXRsczEzLXZpc2liaWxpdHkgYSBNaXRNLCBpbiB0aGF0IHRoZSBo b2xkZXIgb2YgdGhlDQo+IFNTV3JhcERIMSBwcml2YXRlIGtleSBoYXMgdGhlIGNyeXB0b2dyYXBo aWMgY2FwYWJpbGl0eSB0byBpbmplY3QgdHJhZmZpYyBhbmQNCj4gbW9kaWZ5IHBsYWludGV4dCBm b3IgdGhlIGFmZmVjdGVkIGNvbm5lY3Rpb25zPw0KPiANCj4gLUJlbg0KPiANCj4gDQo+IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGhpZ2hseSBjb25m aWRlbnRpYWwgYW5kIGlzDQo+IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVuaWNhdGlvbg0KPiBpcyBkaXJlY3RlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZp ZWQNCj4gdGhhdCBhbnkgdmlld2luZywgY29weWluZywgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRp b24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcw0KPiBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFueQ0KPiB1bmlu dGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRob3V0IG1h a2luZyBhbnkNCj4gY29waWVzLg0KPiANCj4gIEJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWlj aGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZQ0KPiBub25wcm9maXQg Y29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3Mg YW5kIEJsdWUNCj4gU2hpZWxkIEFzc29jaWF0aW9uLg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From nobody Tue Oct 24 01:38:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14C413C2F9 for ; Tue, 24 Oct 2017 01:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 i-vL3bBQgVA3 for ; Tue, 24 Oct 2017 01:38:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEA113D1D1 for ; Tue, 24 Oct 2017 01:38:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DB745BE56; Tue, 24 Oct 2017 09:38:49 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxZ4dy0A2DxI; Tue, 24 Oct 2017 09:38:48 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CAE4DBE2E; Tue, 24 Oct 2017 09:38:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508834327; bh=JHlwbDDKYUJJa8WWF4Q5Vxnc29BFQWVuUjfRAHvlUpU=; h=Subject:References:To:From:Cc:Date:In-Reply-To:From; b=Iyx11g1NlDcBwL7UMvCUVB/8QVO+LL7K81xx8wlBjYSOE9ramVHVQ1Uo1M6rClXzJ a7oJvZW7qZT6mDJorPDD6R8oPG8aI2/b3Pgr2koBYOnbMoQLCu+pD4PrnOzS0AbaXl lvitopwmoTIp49QxndCtF7JuA74k9Lh6TtCcq8Fg= References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> To: tls chair From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Cc: "tls@ietf.org" Message-ID: <1d5f4100-ba25-4601-2f76-bd9548d56dea@cs.tcd.ie> Date: Tue, 24 Oct 2017 09:38:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="slv7PRcvCaDO6hdCf5IEPv6hGdhRMdtti" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 08:38:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --slv7PRcvCaDO6hdCf5IEPv6hGdhRMdtti Content-Type: multipart/mixed; boundary="srMNKtnw42QldxasdSFKTWAn91km4xOaD"; protected-headers="v1" From: Stephen Farrell To: tls chair Cc: "tls@ietf.org" Message-ID: <1d5f4100-ba25-4601-2f76-bd9548d56dea@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> In-Reply-To: --srMNKtnw42QldxasdSFKTWAn91km4xOaD Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Sean/Joe, this is addressed to you... On 24/10/17 00:31, Ackermann, Michael wrote: > NO The objective is to be passively observe, out of band and not to > be a MitM or modify/inject text. Just as we all do today. So from the above we see that some of the proponents of breaking TLS demonstrate a breathtaking ignorance of what they are espousing. After 18 months of this WG dealing with the "I want my static RSA" pony, I personally think we are justified in demanding more from those who've been actively engaged for some time in trying to break TLS and therefore we ought consider postings such as the above, or ones containing blatantly false/exaggerated statements (e.g. about "guarantees" or "using TLS1.2 forever") as being merely disruptive. So in addition to asking you as chairs to close down this discussion, I would also ask that you contact the folks being disruptive like that and try to educate them as to how to behave in IETF discussions and also let them know about the IETF's processes for dealing with disruptive postings. Thanks, S. PS: Your (chairs') silence on the repeated requests to close down this discussion is quite puzzling to me. >=20 > -----Original Message----- From: Benjamin Kaduk > [mailto:bkaduk@akamai.com] Sent: Monday, October 23, 2017 6:33 PM To: > Ackermann, Michael ; Tony Arcieri > ; Adam Caudill Cc: > tls@ietf.org Subject: Re: [TLS] Publication of > draft-rhrd-tls-tls13-visibility-00 >=20 > On 10/23/2017 05:09 PM, Ackermann, Michael wrote: >> No one I am aware of is pushing for a MitM capability to address >> this. In fact it was one of the alternative solutions for which >> many implementation issues were cited at the Prague meeting and on >> this list. But I would like to ask, what is the solution that >> your company and others that you reference, have solved this >> problem by implementing? >=20 > Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of > the SSWrapDH1 private key has the cryptographic capability to inject > traffic and modify plaintext for the affected connections? >=20 > -Ben >=20 >=20 > The information contained in this communication is highly > confidential and is intended solely for the use of the individual(s) > to whom this communication is directed. If you are not the intended > recipient, you are hereby notified that any viewing, copying, > disclosure or distribution of this information is prohibited. Please > notify the sender, by electronic mail or telephone, of any unintended > receipt and delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan > are nonprofit corporations and independent licensees of the Blue > Cross and Blue Shield Association.=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --srMNKtnw42QldxasdSFKTWAn91km4xOaD-- --slv7PRcvCaDO6hdCf5IEPv6hGdhRMdtti Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ7vwWAAoJEC88hzaAX42inhkH/2WSOQ9GvPnbJw1LgKEoscDF efmp1fQQMRNMKyrDVFRe5W76B14ohlGOjdGx1YJvhAYJdCjQfpaynqgXRCaiyHQo w0eZUe5lziv6PeJfYUw2gTrEppvUlT54KWlTG74gEzjAgrbBlT+ua7jZmlJ3wiKS Lx1YRA8LMvrVL8wObsp4896uYW2OU02NfNsuueC3bJw5ShcOgtDOAXUfzJGywveN 2+e8YR/epkDNcwk2B5n5uQJCAIm1ruNXUBy8K9f70DWZ1RByYnBxmq5DjYfRjong rJzP23Tc3Zxx556/3jaJ5tiDh5487jI9GPdpQCqFLxKdZ0EF/E8TFEIbXUKdxjw= =e0sU -----END PGP SIGNATURE----- --slv7PRcvCaDO6hdCf5IEPv6hGdhRMdtti-- From nobody Tue Oct 24 03:23:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F45113F6F6 for ; Tue, 24 Oct 2017 03:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=lekensteyn.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXM5PMcnqRBw for ; Tue, 24 Oct 2017 03:23:24 -0700 (PDT) Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (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 52F4313F0A8 for ; Tue, 24 Oct 2017 03:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=ia2E7Y6srbZRN6T77PDMLFXu5EMGlR9SmoNFTYBspQM=; b=KA7/3jmbh33YQ4z9J79LKlbIKz4pl4fxPtWzATpg5gMhxnTLCyqzocnZAqDl/YIRVZkhACnEP9XZfKCFR4Ng477LFofYnpGNyJVPX9dbLVGMj9W4BOR4Hdmm82mROaX3/enhusaAXpMU6DfjcfFqmIv+o98YPQXAN2QPihOvLbZgV0ChX2MDl08FXZSt36prSPsct9SwrGC+4+2AQRQG1V24I5OgFgKFwWlqFVVYiZan5uKsOPASuKakBg7AUi5847oK82oPTfO3cNEKAWWCEFJgLJdlYZ0zktBURLXnjggHEr5IGM11H1/8jAw4+MzePVzv/RKgsiSYdM3qfMD1PA==; Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e6wMf-0001pU-Dx; Tue, 24 Oct 2017 12:23:21 +0200 Date: Tue, 24 Oct 2017 11:23:15 +0100 From: Peter Wu To: Andrei Popov Cc: "'tls@ietf.org'" Message-ID: <20171024102315.GA30630@al> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [TLS] TLS 1.3 Record Boundaries X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 10:23:26 -0000 On Tue, Oct 24, 2017 at 12:42:01AM +0000, Andrei Popov wrote: > Draft-21 says: > "Handshake messages MUST NOT span key changes. Implementations > MUST verify that all messages immediately preceding a key change > align with a record boundary; if not, then they MUST terminate the > connection with an "unexpected_message" alert. Because the > ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate > messages can immediately precede a key change, implementations > MUST send these messages in alignment with a record boundary." > > It is not clear to me what "sending messages in alignment with a record boundary" means. > Does it mean that each record is either all plaintext or all encrypted with key X? Yes, where key X could be the client/server handshake, traffic secret, etc. > And therefore one cannot combine, e.g., ServerHello (plaintext) and > EncryptedExtensions (encrypted with the handshake traffic key) > messages in one record? Correct. And before you switch to a new cipher context, you MUST check that you have no more remaining data in the record. For example, no more data is allowed in the same record following the Server Hello. And the record after the Server Hello, there is an encrypted record containing Encrypted Extensions (encrypted with the server handshake secret). -- Kind regards, Peter Wu https://lekensteyn.nl From nobody Tue Oct 24 04:57:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524A913F70D for ; Tue, 24 Oct 2017 04:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 pkkdTQ7pZEiS for ; Tue, 24 Oct 2017 04:57:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AB613F705 for ; Tue, 24 Oct 2017 04:57:16 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3F7BB356E5; Tue, 24 Oct 2017 11:57:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3F7BB356E5 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.34.247.178]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C32F660A99; Tue, 24 Oct 2017 11:57:15 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 24 Oct 2017 13:57:07 +0200 Message-ID: <2354859.AHD1xRnffk@pintsize.usersys.redhat.com> In-Reply-To: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <460ef8f8-4853-2123-5721-30ef49a7c1d1@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12271674.h0V01Jgg56"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 24 Oct 2017 11:57:16 +0000 (UTC) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 11:57:18 -0000 --nextPart12271674.h0V01Jgg56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 24 October 2017 00:40:44 CEST Colm MacC=C3=A1rthaigh wrote: > On Mon, Oct 23, 2017 at 3:30 PM, Benjamin Kaduk wrote: > > There are no doubt folks here would claim that the writing has been on > > the wall for>=20 > > five years or more that static RSA was out and forward secrecy was on > > the way in, and that now is the right time to draw the line and drop the > > backwards compatibility. In fact, there is already presumed WG > > consensus for that position, so a strong argument indeed would be needed > > to shift the boundary from now. I won't say that no such argument can > > exist, but I don't think we've seen it yet. >=20 > I don't have too strong an interest in this thread, it's not going > anywhere, and I don't mind that. But I do want to chime in and point > out that forward secrecy is not completely on the way in. With STEK > based 0-RTT, it sounds like many implementors are happy to see user's > requests, cookies, passwords and other secret tokens protected only by > symmetric keys that are widely shared across many machines and > geographic boundaries, with no defined key schedule, usage > requirements or forward secrecy. Clearly, the consensus has been > willing to accept that trade-off, and there is definite wiggle room. which part of the HTTP 0-RTT usage policy does say that that is acceptable? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart12271674.h0V01Jgg56 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZ7yqTAAoJEJKo0bgB0vX1OW0QAJXw+ldezRSJ6SfPf+Wv2ANG W/bkwAbouRx1DJm0o16lZ7IgEbFrpmoci0TslUcj71zcxxBqjBK5fswM/s88JnhK TpWy7VGi4JPAfCzgaFWwsqrszqfDMT+zZNJfGjA0PJs6+uBjHXydiMJK+fJb4b+1 91HHOz34fJ87kI8sjN417jYkfMtJ5z/KramrVlFkOLKQ/eezw0ERQOxMKbiXxxRe 9gsfELb9NVuvIg501spTVLXGfIRYBMIs+DmR7AcazUVmkeAp9kHoV+rrGE9o64wp MSTHHL4lV7/9jcrkHW0q1XaIIQVemu3SZG3y7YRrhdaX7+MbHJBmFG5iB1VfLmr2 CfU4EpcorTME9suUwechct0u20yl/+miREXuaZW1sOElquBzIoj2H2HQsZGOa9ft e970yvHYH9z56h6fjkx/lo3OUnD3wJ+vBzmZ8HuSGjnMP+ZYo3i070iB46Gf4Ng1 zxBg2hyJluDmNeKflGha1/B1T0QJfkpgIyjEtLnbQioiMdwpKJ/5WjnsjENBcMED U1JwcP8wT3iHQrkPhG7RTXZGm5BHiwXjTEq+lRD6fLgYAdd2ikjy1/pQqp7ufbkn /l/LZ5+8BY5PAFxTx/XnY2OUj9JI6PZU2W052qkGLCk/qxYo57y6wAG6dHcJ027T HMuc/Uk2rDrN1EDFAXGz =OHfA -----END PGP SIGNATURE----- --nextPart12271674.h0V01Jgg56-- From nobody Tue Oct 24 05:53:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE64013E0DD for ; Tue, 24 Oct 2017 05:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 hR5w-6UIavKZ for ; Tue, 24 Oct 2017 05:53:54 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B881113846C for ; Tue, 24 Oct 2017 05:53:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 3C324B538E; Tue, 24 Oct 2017 15:53:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 4ypk29WQd0y3; Tue, 24 Oct 2017 15:53:53 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id B0D522313; Tue, 24 Oct 2017 15:53:50 +0300 (EEST) Date: Tue, 24 Oct 2017 15:53:50 +0300 From: Ilari Liusvaara To: Andrei Popov Cc: "'tls@ietf.org'" Message-ID: <20171024125350.djebfdbx4x3dc7o5@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] TLS 1.3 Record Boundaries X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 12:53:56 -0000 On Tue, Oct 24, 2017 at 12:42:01AM +0000, Andrei Popov wrote: > Draft-21 says: > "Handshake messages MUST NOT span key changes. Implementations > MUST verify that all messages immediately preceding a key change > align with a record boundary; if not, then they MUST terminate the > connection with an "unexpected_message" alert. Because the > ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate > messages can immediately precede a key change, implementations > MUST send these messages in alignment with a record boundary." Edge case: Finished is also part of post-handshake auth (*puke*), which does not trigger key change. And from some cryptographic analysis, one might get an idea to immediately send a KeyUpdate requesting reciproal update afterwards (not that I think that is actually necressary or even helpful). -Ilari From nobody Tue Oct 24 06:22:29 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3931113F554 for ; Tue, 24 Oct 2017 06:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgUaStxT4tlf for ; Tue, 24 Oct 2017 06:22:21 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868B013F505 for ; Tue, 24 Oct 2017 06:22:21 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3yLv7v3lMdz25TB for ; Tue, 24 Oct 2017 15:22:19 +0200 (CEST) X-purgate-ID: 152705::1508851339-000040CA-A4C958B1/0/0 X-purgate-size: 2433 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3yLv7v36jgzGph2 for ; Tue, 24 Oct 2017 15:22:19 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6194A404B; Tue, 24 Oct 2017 15:22:19 +0200 (CEST) To: tls@ietf.org Date: Tue, 24 Oct 2017 15:22:19 +0200 (CEST) Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171024132219.6194A404B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: [TLS] editorial error in draft-ietf-tls-rfc4492bis-17 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 13:22:28 -0000 I just noticed a strange inconsistency in section 6 of draft-ietf-tls-rfc4492bis-17 https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17#section-6 The last of the "must implement 1 of these 4" list of cipher suites at the end of section 6 is not contained in the table at the beginning of section 6 above it (instead, it appears in rfc5289 only). I believe that the last ciphersuites should be changed (which will provide consistence with the second list entry (the TLSv1.2 MTI cipher suite). -Martin +-----------------------------------------+----------------+ | CipherSuite | Identifier | +-----------------------------------------+----------------+ | TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } | | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } | | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } | | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } | | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } | | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } | | | | | TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } | | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } | | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } | | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } | | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2F } | | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x30 } | | | | | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } | | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } | | TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } | | TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } | +-----------------------------------------+----------------+ Server implementations SHOULD support all of the following cipher suites, and client implementations SHOULD support at least one of them: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 + o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 From nobody Tue Oct 24 06:30:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AA713F406 for ; Tue, 24 Oct 2017 06:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swH99vCEsIdO for ; Tue, 24 Oct 2017 06:30:35 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5F813F3F9 for ; Tue, 24 Oct 2017 06:30:29 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9ODSNFr003578; Tue, 24 Oct 2017 14:30:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=gcCl1Ydyw+e1In0zUUDgPeSK2C+v75J9BDZVaYX5rs0=; b=ix1se+i/ilCiPo+bCZmULTgv1YdqmB1iuBNRXNXgDxI3eAsf2ZYXGG4YUu7pVLsrDQ/5 QkAoYF1cFnHW6N2lzGHI2wrLZ4J3uG+c/npGUaj3/NUQJpIEpbtJcu5Ll/zTbumCcfyj uTkDloKOrD7NVvH9S3M87boTwVD7t17owQSSEfSdUf4Y+yMh9YsK7OrNArbwz05gLQtb tSmtjxdn3H7VwzYz+Onzz8sSZNBuYGIvvZZvNylTLQjngEdadQdrPWadebhffvKNsL6y tBPe5Ay5LK2iVWO8wmM0htnx1VW82Vv1UqMrIKZ+LcO8UftF8A7b7R+dZ3Md9VsYYVGi hg== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2dqwvt0y5y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 14:30:27 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9ODPdtv011555; Tue, 24 Oct 2017 09:30:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dr1jvjjet-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 09:30:24 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 09:30:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 24 Oct 2017 09:30:23 -0400 From: "Salz, Rich" To: "Ackermann, Michael" CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABAMAgAAHdQCAAASJAIADZUoAgAAIFICAACFZAIAAB4qAgAD5KwCAABI3gIAAC5wAgAABKICAAAOBgIAAAU8AgAANI4CAAAQJAIAAGDwAgAAqLYCAAAdyAIAABqEAgAAQHwCAAOqFAA== Date: Tue, 24 Oct 2017 13:30:22 +0000 Message-ID: <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@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/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.48] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240190 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240190 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 13:30:36 -0000 4p6iICAgICBUaGUgb2JqZWN0aXZlIGlzIHRvIGJlIHBhc3NpdmVseSBvYnNlcnZlLCBvdXQgb2Yg YmFuZCBhbmQgbm90IHRvIGJlIGEgTWl0TSBvciBtb2RpZnkvaW5qZWN0IHRleHQuICAgIEp1c3Qg YXMgd2UgYWxsIGRvIHRvZGF5LiAgDQogICAgDQpUaGF0IG1pZ2h0IGJlIHRoZSBvYmplY3RpdmUs IGJ1dCBpc27igJl0IEJlbiBjb3JyZWN0PyAgSWYgYSB0aGlyZC1wYXJ0eSBoYXMgdGhlIHNlc3Np b24ga2V5cywgd2hhdCBwcmV2ZW50cyB0aGVtIGZyb20gZG9pbmcgdGhhdD8gIEdvb2QgYmVoYXZp b3I/ICBPciBpcyB0aGVyZSBzb21lIHRlY2huaWNhbCBtZWFucyAodW5jbGVhciB0byBtZSkgdG8g YWN0dWFsbHkgcHJldmVudCBpdD8NCg0KQXMgSSB1c2VkIHRvIHJlYWQgaW4gdGhlIGNvbWljcyBv ZiBteSB5b3V0aCwgaHR0cHM6Ly93d3cudXJiYW5kaWN0aW9uYXJ5LmNvbS9kZWZpbmUucGhwP3Rl cm09Z29vZCUyMGxvcmQlMjElMjBjaG9rZSAgSSBhbSBnbGFkIHRoYXQgdGhpcyBjb252ZXJzYXRp b24gdGhyZWFkIGtlcHQgZ29pbmcsIGxpa2UgYSB6b21iaWUgaXQga2VlcHMgcmlzaW5nLiAgV2Ug a25vdyBoYXZlIGVub3VnaCBrbm93bGVkZ2UgdG8gZGVmaW5pdGl2ZWx5IHB1dCBhIHN0YWtlIHRo cm91Z2ggaXRzIGhlYXJ0LCBmb3JldmVyLg0KDQoNCg0K From nobody Tue Oct 24 06:59:39 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64FB13F59A for ; Tue, 24 Oct 2017 06:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RnMjtSLVoU2X for ; Tue, 24 Oct 2017 06:59:35 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574A51388A0 for ; Tue, 24 Oct 2017 06:59:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1C16653731; Tue, 24 Oct 2017 16:59:33 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id IZGRkBzIiBlT; Tue, 24 Oct 2017 16:59:32 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2FDC827B; Tue, 24 Oct 2017 16:59:29 +0300 (EEST) Date: Tue, 24 Oct 2017 16:59:29 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20171024135929.ijathkbwc3vh4635@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 13:59:38 -0000 On Mon, Oct 23, 2017 at 06:14:33PM -0700, Eric Rescorla wrote: > We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. What is the _worst_ case memory usage (both sending and receving) for handling the acknowledgements and guaranteeing forward progress in all reasonable cases? There is not much discussion in the draft about memory usage of ACK handling and how to limit it. This matters very much if using DTLS for (effectively) small devices, which are seemingly a major usecase. One strategy I see on receive side is just keeping fixed 150 RSN ack buffer on receive side, reset for every flight, and if this ever overflows, abort the connection. Maintaining this buffer needs 1201 bytes of memory (the odd byte is for occupancy count). On limited devices, one might shrink this buffer further. And then have per-byte bitmasks and unreceived count for buffered handshake message (eats n/8 + few bytes for n byte message). On sending side, one resource-limited strategy is to keep newest retransmit number and acknowledged flag for each 480 byte chunk. Unencrypted records can be special. This eats (8 bytes for each starting 480 bytes in each message in flight buffer plus about two dozen fixed bytes)... With 480-byte chunking, single-chunk packets would confortably fit in IPv4 minMTU, and double-chunk/double-length packets would comfortably fit in IPv6 minMTU. The sender-side strategy can not handle receivers that signal maximum fragment size below 512 bytes or so... Actually, I don't think maximum fragment size is actually useful in DTLS, what you want for DTLS is maximum *packet* size. Also, this strategy limits the flight size, but should be enough for anything reasonable. > The one thing we ran into was the potential need to ACK in cases where you > can't process *any* records (e.g., you receive what's actually EE, but you > can't decrypt it). In this case, you want to send an empty ACK. > > See PR: > https://github.com/tlswg/dtls13-spec/pull/14 The ACK structure definition does not seem to allow empty ACK. -Ilari From nobody Tue Oct 24 08:22:35 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FD0138C11 for ; Tue, 24 Oct 2017 08:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=FY+vYK5x; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IvVMTrqm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A8VRijeot9i for ; Tue, 24 Oct 2017 08:22:32 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6446E138BE0 for ; Tue, 24 Oct 2017 08:22:32 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A9B9220D38; Tue, 24 Oct 2017 11:22:31 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 24 Oct 2017 11:22:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=byj/PdMxmyzc0DKu9KvNlqqs3jAiTB3M0DZ6klK51LQ=; b=FY+vYK5x kvBo3XGV2nxHqY8p9fji0Ml20vdrodfYM4qd2IHDfDY/QEpYxgeUhufSfUA5QAYZ vAs5rzpuxUeqU8rWBns1wP6sAItYN7uX3onDT6KeECT6XI2tYTl79ArCo03FfWDB BPBSMZbNNHcZcf481QZHICdAnAyiIOeHdjHUyY6uIRIYgISH0jDpD5y7wgK/04m4 F7inE0yjtfPTjQKF6hsr/ZnHey5Aw7haoXmexJfEdjfVVVIEU+kC2JQ3uGTIjlbh TmXFtYpjSLpeWNNuHpQ51Rz88xVrwkaBisQWXkYlHoRIirw3lDsyKVxHhi6KPt0g aRH51onLKPks7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=byj/PdMxmyzc0DKu9KvNlqqs3jAiT B3M0DZ6klK51LQ=; b=IvVMTrqmIh7jXyYbFUbv5+0mPBcwkmVLtQ3OH7/i5VBAQ iqHkoemdu8k6HbMIIEqgq9l3bSQvOkxotN49bij5BXWx9AGg40XCGbbifSTXtbj7 Ry3p0j0VI6V6QjEGUZzr0Q0gbHLgbyn3cyrK71TVdIydlf+6s9IZwTlHpnwPC8yO emLLaxgHpPNUTmMbfVEmCMCJ4nFCChgIY+IzVkfsc7UWI1ursd2X0+29bhHDR50k WCHFcIVfOCgwC1PhNWOOfH7gjWeYtr4zA5IB8r99kwyM26th/uZA3w7GlcEvN36R qwlPCRaX6jy4IjNekhtTFOk7uCxP3u3KeghUFAHsQ== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 0FE8A24134; Tue, 24 Oct 2017 11:22:30 -0400 (EDT) To: Stephen Farrell , tls chair Cc: "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <1d5f4100-ba25-4601-2f76-bd9548d56dea@cs.tcd.ie> From: Peter Saint-Andre Message-ID: Date: Tue, 24 Oct 2017 09:22:29 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1d5f4100-ba25-4601-2f76-bd9548d56dea@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QbtFaHs7Wo72n2oWMC9RaGWRtmUPap5iE" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 15:22:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QbtFaHs7Wo72n2oWMC9RaGWRtmUPap5iE Content-Type: multipart/mixed; boundary="p3OAauSAcpG5qIFvxOm1HE6Q0puqeJMIE"; protected-headers="v1" From: Peter Saint-Andre To: Stephen Farrell , tls chair Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <1d5f4100-ba25-4601-2f76-bd9548d56dea@cs.tcd.ie> In-Reply-To: <1d5f4100-ba25-4601-2f76-bd9548d56dea@cs.tcd.ie> --p3OAauSAcpG5qIFvxOm1HE6Q0puqeJMIE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/24/17 2:38 AM, Stephen Farrell wrote: > So in addition to asking you as chairs to close down this > discussion, I would also ask that you contact the folks > being disruptive like that and try to educate them as to > how to behave in IETF discussions and also let them know > about the IETF's processes for dealing with disruptive > postings. >=20 > Thanks, > S. >=20 > PS: Your (chairs') silence on the repeated requests to > close down this discussion is quite puzzling to me. Section 2 of RFC 7282 is relevant here: "rough consensus is achieved when all issues are addressed, but not necessarily accommodated". Issues have been raised (albeit some of them seemingly not well informed about best industry practices, technical alternatives, practical implications, or IETF processes), and those issues have been considered, weighed, addressed, and (IMHO) found to be "in the rough". +1 to Stephen's request. Peter --p3OAauSAcpG5qIFvxOm1HE6Q0puqeJMIE-- --QbtFaHs7Wo72n2oWMC9RaGWRtmUPap5iE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlnvWrUACgkQ6gakkSvF rak8xBAAknkJoI7ey1HOhK+HBJW3gO/kU58cFccSi0j7EhXulystWgloGSfIlUzQ creYJHbHygHmYDcCQ9zMd691c88rNPMK+cdEZkWFMgFA9Kn/bRd5kfbSCvbZZn1b L/p+26w3wcwBMYo3g/RIVu/xu5589MepR1aOKlFB4AZJMheiugpmbFVRSQATc7Me CKOH4AMqPVDZ1rUwScZIQYmpYDQzi7S1N7ca1N+9F7myTqFJ8bhCs3v6/gy5haGs WSMx/TGe8XdJGcOYOvGZkxL8V+s2SLsKlgc59iASkjoKAvZ6Fd09bkyKOmKtwhtB l8zj56PFdx81BGVe6Xd6V3UdJVb0iF7txaklu8+9s/jiI1otn6fBpX8o3qaL9K8o TrZcQwfAl3OotbnMqQ4kr5U4QT+wfxDILsSTEpje3SWHI360LWoz93N40B/1vmje /wLGzeD48ACd37CsSXeuBagt5AZKUNu05MRK4VDD7kWfa4nMEkv/RX2VduGfZS5j +XYWSqGU4S5QaNt0mASvOA7KLO3y1GrkvBcxPa2C4Qspny569jAfyMetlUsN+xpq npaA5BRRBSiR98B1Wa/GzhS1ByYbjJSvY1wIxaEwwOosforPYl1mEfhG6zJ/C+mw nFpQKKnhsQyObnDAUFS0KYonoxM5eu/ndsOOeITWkGSKizOJqBI= =eM/d -----END PGP SIGNATURE----- --QbtFaHs7Wo72n2oWMC9RaGWRtmUPap5iE-- From nobody Tue Oct 24 09:32:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C0213946F for ; Tue, 24 Oct 2017 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 C33kPNUvLhRB for ; Tue, 24 Oct 2017 09:32:21 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECE21393AE for ; Tue, 24 Oct 2017 09:32:21 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d67so27041421qkg.5 for ; Tue, 24 Oct 2017 09:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Bn2dRyogllFRiBULKbu0PFqixQc0IJd8CSALefotcqk=; b=XlMzZxMtChUaJbfjvXDkMs3w2gb4dC5ELz7DYUwwPlAteRiUsqU41/5Hzu90Tbwhyd p1aNcR4yQJ/GMUpWzS+7J1bjtpdEDKA3pKEYvCvfq+oh4GA5gj9TLqnj1Ppd/AmLlvcp Eu2icqttnk+k4rsycju/+PNCaiIgEnNkW55zQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Bn2dRyogllFRiBULKbu0PFqixQc0IJd8CSALefotcqk=; b=s6RlbL0CLPSOfYnTy70OWF1hzks+fJ9t2GLZpLTtoCyvZ18ZSSET2b6t8aRfQR3qKD DnghunjizxKm5pNg8c4RFrQo0uXBWKY/on+GEvzljRKcriRhBWygyIfirrjmdZ2WN+Mt h/+HCX0Tk8rmQYWyrx+pl2LHIE0kxUJz08xUOr3n7+nX4eLMwHxJCp0KGxgFJgM1ik25 w1BhCoTiGn4GOXCKplofAATZjoinBriDW0X+BOq/OdD5y/nCTbXXY5xNotOlXmW+9yyQ k8tzuj4svwlMf4ZWOQW8sI+Qax+TN/jpxocpmYLbWgsPMaTWPaOlAvist3LygpgHjTQE be4g== X-Gm-Message-State: AMCzsaUoifTO+6G06a1Mnam93C2NYUNWB0Vpbky24omGxbrFtqp+ttnB ZO403PwclVmB3e6FlKn0Ue/i2WnURMA= X-Google-Smtp-Source: ABhQp+RU2pwxTdNS9v0Snl4A0iw8w4y0kBnJqxsmHLs/8vktiR5QLC+MAihbAXrlUIdD+oYHh3HP3g== X-Received: by 10.55.11.137 with SMTP id 131mr4284304qkl.321.1508862740383; Tue, 24 Oct 2017 09:32:20 -0700 (PDT) Received: from [172.16.0.18] ([96.231.228.225]) by smtp.gmail.com with ESMTPSA id w6sm491467qtc.53.2017.10.24.09.32.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 09:32:19 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> Date: Tue, 24 Oct 2017 12:32:19 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 16:32:23 -0000 All, You will have seen that the chairs requested two sessions for IETF 100 = TLS (on 20170929) and you will have also seen the that our request was = granted (on 20171020). The sessions are currently scheduled as follows: tls Session 1 (2:30:00) Thursday, Morning Session I 0930-1200 Room Name: Canning size: 250 --------------------------------------------- tls Session 2 (1:00:00) Monday, Afternoon Session III 1740-1840 Room Name: Padang size: 300 --------------------------------------------- We would like to get a sense of who wants to request agenda time so = please send in your requests by 20171029; this will give the chairs time = to upload a draft agenda due on 20171030. Along with your request = please let us know how long you would like. NOTE: Those that have already submitted requests need not do so again. J&S= From nobody Tue Oct 24 09:42:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACFD139553 for ; Tue, 24 Oct 2017 09:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 vdtHO0HkN6v5 for ; Tue, 24 Oct 2017 09:42:00 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 052661394EB for ; Tue, 24 Oct 2017 09:41:59 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id F21491C0A16 for ; Tue, 24 Oct 2017 11:41:58 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 527AB1C0750; Tue, 24 Oct 2017 11:41:58 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1B311FE064; Tue, 24 Oct 2017 12:41:58 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DAE00FE048; Tue, 24 Oct 2017 12:41:57 -0400 (EDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (unknown [216.32.180.177]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Tue, 24 Oct 2017 12:41:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ou64pP4AbE70W0620ze1LDUpWAVpww6n2bPt+NB2KYY=; b=ZZFCkP5fzTHezkve7bNLefxohnJzx1rPx7jE4HGzoNMeuST4qf68YWx8Rzql+xeeed5BP8FwfhxkFUhQiv/wd6ctTH+UKPCdIasKJvKGAPOEsFOj4l00243I3WyrqDk7A2YKv34g0t8n21ajxFMy0ITUQwkzbo8byFndtqe0Qjg= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1366.namprd14.prod.outlook.com (10.172.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 24 Oct 2017 16:41:56 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Tue, 24 Oct 2017 16:41:56 +0000 From: "Ackermann, Michael" To: "Salz, Rich" CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAIAADvYAgAAFHmCAAAbigIADZUkAgAAIFICAAB86QIAACamAgAD42jCAABKIgIAACV1AgAADZ4CAAAF70IAAA1UAgAAA2TCAABBTAIAAGDwAgAAqLYCAAAW3AIAACFwAgAAOs/CAAOvwAIAAM6OQ Date: Tue, 24 Oct 2017 16:41:56 +0000 Message-ID: References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.com> In-Reply-To: <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1366; 20:tSO+tvzAoYDKqvzzlhquHO39MddPZZB32mufL27x21lWotAogTW2pcylXr6s0ttCPw5fBzMKJHsbRrujAWOU46bX4cuYuvbUtrj1e/OgE4JuqXJ4JOnU2iY43eDrbAxai4F+Ns1NpheUP+B+l+LZGDSiKAUdi0QAodfIVT3ZzKA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c07d235c-3f36-4e22-2ea3-08d51afe238b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1366; x-ms-traffictypediagnostic: CY4PR14MB1366: x-exchange-antispam-report-test: UriScan:(190756311086443)(86572411397741)(244800015338608); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(3231020)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1366; x-forefront-prvs: 047001DADA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(13464003)(199003)(189002)(81156014)(81166006)(7696004)(5660300001)(93886005)(230783001)(66066001)(189998001)(478600001)(53936002)(8936002)(33656002)(2950100002)(16799955002)(6916009)(72206003)(7736002)(97736004)(8676002)(2906002)(25786009)(77096006)(102836003)(6116002)(3846002)(76176999)(54356999)(50986999)(86362001)(53546010)(80792005)(966005)(316002)(2900100001)(305945005)(68736007)(6306002)(55016002)(101416001)(106356001)(74316002)(229853002)(99286003)(6506006)(105586002)(3280700002)(14454004)(4326008)(3660700001)(6436002)(9686003)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1366; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-Network-Message-Id: c07d235c-3f36-4e22-2ea3-08d51afe238b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2017 16:41:56.2507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1366 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: dc40945e-ca88-4605-a5fc-37cf93d46a44 X-VPM-MSG-ID: c4a5c81a-28f3-4288-8701-12c559ba094e X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 16:42:02 -0000 T3VyIHByb3Bvc2FscyBhcmUgZm9yIHNwYW5uZWQvdGFwcGVkLCBwYXNzaXZlIHRyYWZmaWMu ICAgIFlvdSBzZWVtIHRvIGJlIHRhbGtpbmcgYWJvdXQgbW9kaWZ5aW5nIHRoZSBhY3R1YWwg IGxpdmUgZGF0YSBzdHJlYW0uICANCkFuZCBNaXRNIGlzIGFsc28gb3V0c2lkZSBvZiB3aGF0 IHdlIHdhbnQgdG8gZG8gYnV0IHdvdWxkIHNlZW0gdG8gYmUgbW9yZSBmZWFzaWJsZSBpbiB0 aGF0IHNjZXJuYXJpby4gIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog U2FseiwgUmljaCBbbWFpbHRvOnJzYWx6QGFrYW1haS5jb21dIA0KU2VudDogVHVlc2RheSwg T2N0b2JlciAyNCwgMjAxNyA5OjMwIEFNDQpUbzogQWNrZXJtYW5uLCBNaWNoYWVsIDxNQWNr ZXJtYW5uQGJjYnNtLmNvbT4NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExT XSBQdWJsaWNhdGlvbiBvZiBkcmFmdC1yaHJkLXRscy10bHMxMy12aXNpYmlsaXR5LTAwDQoN CuKeoiAgICAgVGhlIG9iamVjdGl2ZSBpcyB0byBiZSBwYXNzaXZlbHkgb2JzZXJ2ZSwgb3V0 IG9mIGJhbmQgYW5kIG5vdCB0byBiZSBhIE1pdE0gb3IgbW9kaWZ5L2luamVjdCB0ZXh0LiAg ICBKdXN0IGFzIHdlIGFsbCBkbyB0b2RheS4gIA0KICAgIA0KVGhhdCBtaWdodCBiZSB0aGUg b2JqZWN0aXZlLCBidXQgaXNu4oCZdCBCZW4gY29ycmVjdD8gIElmIGEgdGhpcmQtcGFydHkg aGFzIHRoZSBzZXNzaW9uIGtleXMsIHdoYXQgcHJldmVudHMgdGhlbSBmcm9tIGRvaW5nIHRo YXQ/ICBHb29kIGJlaGF2aW9yPyAgT3IgaXMgdGhlcmUgc29tZSB0ZWNobmljYWwgbWVhbnMg KHVuY2xlYXIgdG8gbWUpIHRvIGFjdHVhbGx5IHByZXZlbnQgaXQ/DQoNCkFzIEkgdXNlZCB0 byByZWFkIGluIHRoZSBjb21pY3Mgb2YgbXkgeW91dGgsIGh0dHBzOi8vd3d3LnVyYmFuZGlj dGlvbmFyeS5jb20vZGVmaW5lLnBocD90ZXJtPWdvb2QlMjBsb3JkJTIxJTIwY2hva2UgIEkg YW0gZ2xhZCB0aGF0IHRoaXMgY29udmVyc2F0aW9uIHRocmVhZCBrZXB0IGdvaW5nLCBsaWtl IGEgem9tYmllIGl0IGtlZXBzIHJpc2luZy4gIFdlIGtub3cgaGF2ZSBlbm91Z2gga25vd2xl ZGdlIHRvIGRlZmluaXRpdmVseSBwdXQgYSBzdGFrZSB0aHJvdWdoIGl0cyBoZWFydCwgZm9y ZXZlci4NCg0KDQoNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11 bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5p Y2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5n LCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHBy b2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWls IG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRo ZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUg Q3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9m IE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBs aWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9u Lgo= From nobody Tue Oct 24 09:45:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6EB13F81D for ; Tue, 24 Oct 2017 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 AR4Qd2noVD4a for ; Tue, 24 Oct 2017 09:45:44 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A8E1394EB for ; Tue, 24 Oct 2017 09:45:44 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9OGiLBt002703; Tue, 24 Oct 2017 17:45:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Xg18wHDqQtyKt4V5aiaRXTJ4l7Y21tYXfvocrsohA7w=; b=QO+GECID09mpK2PJtIZkDYI3+1Z7L3IyMeAVKYhprEn9mR/LVx5C/DyJJgJ8JxlhR5aN 9ShEbm2ASp6J8gvQvMVRW8O05l5x8NcwN84W7TiMHKwVUqUVwfJR2Ym29AwArcwiy3eb ZycQ5RgH9iroarABfSU+3JEPThau0pf3cq0Wf1j5ryfa2Ri6YXPGo0h525gm2XDcSFi9 jjjVHyIxXQesAOx7upsRgkqi1vZ9+Ed0zyAIRvkOPdLREsR4hVECuEJkMjD5cx5ZhsEg xXZfVYSJJXKs+y7PiazQ49qdg4rJefuugXLTy8CfNcv0tsuQ2EfCBelq7hMePnfai5A3 kA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2dqwgktrw5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 17:45:43 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9OGfQqc028217; Tue, 24 Oct 2017 12:45:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1ju9gkh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 12:45:41 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 12:45:41 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 24 Oct 2017 12:45:41 -0400 From: "Salz, Rich" To: "Ackermann, Michael" CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABAMAgAAHdQCAAASJAIADZUoAgAAIFICAACFZAIAAB4qAgAD5KwCAABI3gIAAC5wAgAABKICAAAOBgIAAAU8AgAANI4CAAAQJAIAAGDwAgAAqLYCAAAdyAIAABqEAgAAQHwCAAOqFAIAANYYAgAABCwA= Date: Tue, 24 Oct 2017 16:45:40 +0000 Message-ID: <5D88D34E-E950-40E9-9483-D65D978D2758@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <403C3386-2B86-45B4-BB6B-B627CBE85B9D@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/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.119] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240229 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240230 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 16:45:46 -0000 4p6iIE91ciBwcm9wb3NhbHMgYXJlIGZvciBzcGFubmVkL3RhcHBlZCwgcGFzc2l2ZSB0cmFmZmlj LiAgICBZb3Ugc2VlbSB0byBiZSB0YWxraW5nIGFib3V0IG1vZGlmeWluZyB0aGUgDQrinqIgYWN0 dWFsICBsaXZlIGRhdGEgc3RyZWFtLiAgDQoNClllcyBJIGFtLg0KDQrinqIgICAgIEFuZCBNaXRN IGlzIGFsc28gb3V0c2lkZSBvZiB3aGF0IHdlIHdhbnQgdG8gZG8gYnV0IHdvdWxkIHNlZW0gdG8g YmUgbW9yZSBmZWFzaWJsZSBpbiB0aGF0IHNjZXJuYXJpby4gIA0KDQpJIHRoaW5rIHRoYXQgaXMg YSBncnVkZ2luZyBhZG1pc3Npb24gdGhhdCBpdCBkb2VzLCBidXQgcGxlYXNlIGJlIGV4cGxpY2l0 LiAgRG9lcyB5b3VyIHByb3Bvc2FsIGVuYWJsZSBhbiBhdHRhY2tlciAoc3VjaCBhcyBhIGdhdGV3 YXkgb24gYW4gYWlycGxhbmUgb3IgYW55IG90aGVyIG1pZGRsZWJveCBiZXR3ZWVuIHRoZSBlbmRw b2ludHMpIHRvIG1vZGlmeSB0aGUgc3RyZWFtPyAgSWRlYWxseSB5b3VyIGFuc3dlciDigJMgb3Is IGJldHRlciB5ZXQsIGZyb20gb25lIG9mIHRoZSBJLUQgYXV0aG9ycyDigJMgaXMgeWVzLCBubywg b3IgSSBkb27igJl0IGtub3cuDQoNCg0K From nobody Tue Oct 24 09:49:58 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E78213F3CC for ; Tue, 24 Oct 2017 09:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY0pZG-_Jdx0 for ; Tue, 24 Oct 2017 09:49:54 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 72B4D139504 for ; Tue, 24 Oct 2017 09:49:54 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id n89so20078513pfk.11 for ; Tue, 24 Oct 2017 09:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=S0uUSEw6hPcwIeLA3ZKLu9XcnvXk8pPMlqMvgZp1Np8=; b=shqRSiNehoKKtcH/5a9mPJ+8y/VltiaHLUyYEre7Ez627D4jM/f6oTsGUv91sl1ZvV TLR3Rgwwyn4gnI6uW44S8r8x+rotojI5MMKHGv2VcwvPxZfxPhquXKqgXqzKPL66aX+X HqCSi6vKUXT3Nx/RN8hT/kgWSa47LTBi/7kW/+ivUyAIaqk3cyOMha25TAbdbhme8KpG FZJq7/oIoiKwm7jqns4wp4RSToMaaxL3rwCBbO0gZiuKdBpsE3s/xQpIntriPnYZ85ul PBJD+PqvbHA36R6ro+PmLMWe9vhuZkzq9WZ8JzpV6LCBn10RpB32MuN8PJCJbjxtdaAi Vx2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=S0uUSEw6hPcwIeLA3ZKLu9XcnvXk8pPMlqMvgZp1Np8=; b=Zm1bXSIJe7Ac8h7YinZZ24dgly2I2TKC7+YITMnTObjjs7NTT3plgE2OwkL9/I0xZK AJZZGyVTZn39D2D1+hcKzQzdGBZzhSn7eM8j2gbXuz+2ahKP3rpMOxZ9nHK4oFlZKKL0 v58E44kNjjLLgTMDZ3H/eWxH8392NWpqxYR7wtSnUZdCdv5kZ117VpHuUWk9ed/q2R1X q09jxiFAsW+MSuldzpCcYPBsqhVhRAD/dKu5lHpieaEn1dOOGbTdcv1ijvAczYQdVstg 43+jvOy3XRcgBNvWim3zv5XqCUb9NjSURa8HKrGks4mKX4gmM4aHL/KpS05OOM0PmZli 6tEw== X-Gm-Message-State: AMCzsaUwdz3zxW8/1PoEUCorj03GV+Re988XSPm4BZapAvUYuMUXOakN rJt0LsFvY2Szh2pubejLEALZ2e7/BrLpmDiqvHJQSiEG X-Google-Smtp-Source: ABhQp+QsdG/vdVJNX5Imn/9IGeVKlAuSKa2+h2C6KtCy8I4A6eCDoBNMz5EvBmYT9KGDD8+XpA1sKc/RfphzE5OAFks= X-Received: by 10.84.191.131 with SMTP id a3mr13182274pld.253.1508863793500; Tue, 24 Oct 2017 09:49:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.218.165 with HTTP; Tue, 24 Oct 2017 09:49:32 -0700 (PDT) In-Reply-To: <5D88D34E-E950-40E9-9483-D65D978D2758@akamai.com> References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.com> <5D88D34E-E950-40E9-9483-D65D978D2758@akamai.com> From: Joseph Salowey Date: Tue, 24 Oct 2017 09:49:32 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1880246d2d68055c4dba2f" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 16:49:56 -0000 --94eb2c1880246d2d68055c4dba2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear TLS WG, The chairs have been following the recent vigorous discussion on draft-rhrd-tls-tls13-visibility and we'd like to say a few words about process and how we intend to move forward. First, we would like to clarify that this discussion isn't delaying TLS 1.3. We've been holding final publication to resolve some middlebox issues as described in a recent message from ekr https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0 and expect to discuss this in Singapore. No one and we mean no one should delay submitting a PR related to TLS1.3 or any other WG draft because of this discussion. You=E2=80=99ll note that others have recently, you should follo= w suit. In Prague, we had a discussion of draft-green and there was neither consensus to work in this area nor to decline to work in this area. In addition to the comments that we should simply decline all such work, the authors received technical comments about their approach and draft-rhrd seems to be an attempt to address some of those comments. As is normal IETF practice, we will be giving this topic agenda time in Singapore to see if a consensus emerges one way or the other. Absolutely no decisions will be made about adoption prior to that time, nor prior to a formal call for adoption. In particular, decisions will not be made based on the volume of messages to the mailing list. It is unnecessary and unproductive to repeat points you have already made just because someone responds to you. You will not be missing out on the chance to make your argument. Finally, we would like to remind WG members to keep their messages professional and civil. We have noted a number of recent messages that do not conform to those standards and we will be reaching out to people personally to address those instances. J&S --94eb2c1880246d2d68055c4dba2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear TLS WG,


The chairs have been following the recent vigorous discussion on draft-r= hrd-tls-tls13-visibility and we'd like to say a few words about process= and how we intend to move forward.


First, we would like to clarify that this discussion i= sn't delaying TLS 1.3. We've been holding final publication to reso= lve some middlebox issues as described in a recent message from ekr<= /span>

https://mailarchive.ietf.org/arch/= msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0 and expect= to discuss this in Singapore. No one and we mean no one should delay submi= tting a PR related to TLS1.3 or any other WG draft because of this discussi= on. You=E2=80=99ll note that others have recently, you should follow suit.<= /span>


In Prague, we h= ad a discussion of draft-green and there was neither consensus to work in t= his area nor to decline to work in this area.=C2=A0 In addition to the comm= ents that we should simply decline all such work, the authors received tech= nical comments about their approach and draft-rhrd seems to be an attempt t= o address some of those comments.=C2=A0 As is normal IETF practice, we will= be giving this topic agenda time in Singapore to see if a consensus emerge= s one way or the other.


Absolutely no decisions will be made about adoption prior to that = time, nor prior to a formal call for adoption. In particular, decisions wil= l not be made based on the volume of messages to the mailing list.=C2=A0 It= is unnecessary and unproductive to repeat points you have already made jus= t because someone responds to you. You will not be missing out on the chanc= e to make your argument.


Finally, we would like to remind WG members to keep their message= s professional and civil. We have noted a number of recent messages that do= not conform to those standards and we will be reaching out to people perso= nally to address those instances.


J&S


--94eb2c1880246d2d68055c4dba2f-- From nobody Tue Oct 24 10:01:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC4D139567 for ; Tue, 24 Oct 2017 10:01:30 -0700 (PDT) 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 x7tWhk3BVdFs for ; Tue, 24 Oct 2017 10:01:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D441393AE for ; Tue, 24 Oct 2017 10:01:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A0526BE2F; Tue, 24 Oct 2017 18:01:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiqCv7smH753; Tue, 24 Oct 2017 18:01:20 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8975DBE2E; Tue, 24 Oct 2017 18:01:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508864480; bh=J34aszDNVKuP92iD6/2MFE0lFcdGXqw5n9AIHz2pWq0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GwGIFyAGk0rkDzCFBc9NKSRE/sufIrrsuisvGAg16Az7kNi5j8bSboK6gYJKPjJs6 0KlgtL8GjAYdq8Nj0912/3AErJxGkm9ZpEVJY2Oow3WIvWKm+yz96F4fxF0hK/mWIt YoGENjkOty2zdzdTD6kDopCmhMujgX4WDw7FCJec= To: Joseph Salowey , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.com> <5D88D34E-E950-40E9-9483-D65D978D2758@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <97737108-9aaa-4759-31c9-6287827f63bd@cs.tcd.ie> Date: Tue, 24 Oct 2017 18:01:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4WRhOUOHnV1bQHCUtxtgVaAw4Xu2RXSKK" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 17:01:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4WRhOUOHnV1bQHCUtxtgVaAw4Xu2RXSKK Content-Type: multipart/mixed; boundary="xbTLkbM2dNv9xBsqPmibet5MaS0w0KS5h"; protected-headers="v1" From: Stephen Farrell To: Joseph Salowey , "tls@ietf.org" Message-ID: <97737108-9aaa-4759-31c9-6287827f63bd@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.com> <5D88D34E-E950-40E9-9483-D65D978D2758@akamai.com> In-Reply-To: --xbTLkbM2dNv9xBsqPmibet5MaS0w0KS5h Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Joe, On 24/10/17 17:49, Joseph Salowey wrote: > As is normal > IETF practice, we will be giving this topic agenda time in Singapore to= see > if a consensus emerges one way or the other. I would ask that you, as chairs, reconsider that. While I do have strong opinions, the list traffic seems to me to have been extremely clear on this draft and on this overall topic. Personally, given recent traffic, and the clear lack of consensus to even discuss the basic proposition of snooping, I can't see agenda time for this as being other that a waste of time. (Again.) S. --xbTLkbM2dNv9xBsqPmibet5MaS0w0KS5h-- --4WRhOUOHnV1bQHCUtxtgVaAw4Xu2RXSKK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ73HfAAoJEC88hzaAX42ivcgH/j52x09pk8Nb6PjCCabejIUi 0fMqCYFf7tauzU/3Sr0bD+qThFOLTE6O4xJ8ViMoJ6juMtKwZ5EifbBW6lL48QpD zixQhRbDrN6oXQX8HdNh6GAxvsy0IDxLMUTKEWHFkc7sIRzhHsBThQ5EsUECYKqN iqnDZd7AeegZJ6ANSrY7SqdNli72cu7x2vfsIOGuNa7zfL+pR6oEOwVrshgyFfva s4BLGTQSotVV1eW808Gnro/rD9GqDRYuZuqnxNz7MfPxmGH5o2LNLAkUw4jI5SnL GPlNM1B/q7rpAFDkJjbmJc3PWt3rhH0SooURJraTxnD/ITez3bLFsYxWWG1N/Wk= =xULi -----END PGP SIGNATURE----- --4WRhOUOHnV1bQHCUtxtgVaAw4Xu2RXSKK-- From nobody Tue Oct 24 12:04:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6BE13985B for ; Tue, 24 Oct 2017 12:04:31 -0700 (PDT) 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 OiGja-T89CXt for ; Tue, 24 Oct 2017 12:04:29 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 9978D13962E for ; Tue, 24 Oct 2017 12:04:27 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id 15so7889883wrb.5 for ; Tue, 24 Oct 2017 12:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o1b8sDTMnO45vUAbvvm6pRCn3YtOLdxYNOcnG+85oyo=; b=qqe5eNs2SX0PZqSJAczNlugyZQZ1FvUu09nQoyZNRx3N/IuK5e261brvL0eZSdJgAu Ddqz3EPTvlO4zkJMfe/PVx2rmjMWgFcjMajZc9giEJzdNW6tk/KxwLMo/nodU1Vu24eQ bOnBox6ZVLdEaV/sxIu8I2bNjAWuahB+9ipqdUNsrdyoOaWED467qurwjH2HVLHD4M05 6mr5FVukWZDy1xQdbT08UWH0xoPRqt6hB7zKmdWbbkciOLdScN6QpB3jC5ycMlrER7wN 52w2OnRbfik92imi5yS5qbVe/SYsCCdR3B89EfvZSBNXgDTc3KjKrwYcIvkfyfcr+9io 7U/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=o1b8sDTMnO45vUAbvvm6pRCn3YtOLdxYNOcnG+85oyo=; b=nPcigrfHMaZfeF92lgY2w0T3qKEbLeu5kSXTtl818j0Ix+qFTZBzWGnPrnNfdIEGgD vhCbtwijOm6JuDv8We761aGTUf4qscpwiZrSnjNXiUsQxXxItZJjDxJd9PiYosOZhPTZ zxE0MfjUU7e80D9gViBPzVonHLMRitvRR27WmOVyd56df83chYgw+lpCj0VMXDCWahfV lRNgjb7powWDJnbPGJm9grKpgTaTQX6O3IX+N9vV1fIxrjf5JIwkzbUKfguYut7F12Ws jymKujEcmkYZwkNHEaifL/iubzza/6KnDL0gSWkEz6to5TOkCT3Scv9d/cKxAKEL8zgS ERlA== X-Gm-Message-State: AMCzsaUKD3TOhjTsnWkQeaTmQuTq4+rD6MujtHBmSA5nkoeoOfHKamz6 oiL3L1XQZiGGPIvXry118kg= X-Google-Smtp-Source: ABhQp+R0fcBiEmiLQzmCVK+y9f1hHDoPePIWXaMJkJLDOX/obT7UbdNxGcQNJ8YPOSH423aiP/fePw== X-Received: by 10.223.129.228 with SMTP id 91mr15964469wra.233.1508871866114; Tue, 24 Oct 2017 12:04:26 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id r2sm1007524wmb.38.2017.10.24.12.04.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:04:25 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D67FD347-A716-4B04-A173-39F8FA9B9AC0" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Date: Tue, 24 Oct 2017 22:04:23 +0300 In-Reply-To: <20171024132219.6194A404B@ld9781.wdf.sap.corp> Cc: tls@ietf.org To: mrex@sap.com References: <20171024132219.6194A404B@ld9781.wdf.sap.corp> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [TLS] editorial error in draft-ietf-tls-rfc4492bis-17 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:04:32 -0000 --Apple-Mail=_D67FD347-A716-4B04-A173-39F8FA9B9AC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Martin. This is correct. So there are two ways to fix this: As Martin suggests, make TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA one of the = MTI instead of the current, or Add 0xC0,0x23 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256) to the list of = ciphersuites. The first seems more consistent to me. Chairs: guidance? Note that the document is in the RFC editor queue so = we=E2=80=99ll need AD approval for the change at this late date.=20 Thanks Yoav > On 24 Oct 2017, at 16:22, Martin Rex wrote: >=20 > I just noticed a strange inconsistency in section 6 of > draft-ietf-tls-rfc4492bis-17 >=20 > https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17#section-6 >=20 > The last of the "must implement 1 of these 4" list of cipher suites at > the end of section 6 is not contained in the table at the beginning of > section 6 above it (instead, it appears in rfc5289 only). >=20 > I believe that the last ciphersuites should be changed (which will > provide consistence with the second list entry (the TLSv1.2 MTI cipher = suite). >=20 >=20 > -Martin >=20 >=20 > +-----------------------------------------+----------------+ > | CipherSuite | Identifier | > +-----------------------------------------+----------------+ > | TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } | > | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } | > | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } | > | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } | > | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } | > | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } | > | | | > | TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } | > | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } | > | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } | > | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } | > | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2F } | > | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x30 } | > | | | > | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } | > | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } | > | TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } | > | TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } | > +-----------------------------------------+----------------+ >=20 >=20 > Server implementations SHOULD support all of the following cipher > suites, and client implementations SHOULD support at least one of > them: >=20 > o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA > o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > + o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA > - o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_D67FD347-A716-4B04-A173-39F8FA9B9AC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Martin. This is correct.

So there are two ways to fix = this:
  • As = Martin suggests, make TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA one of the = MTI instead of the current, or
  • Add 0xC0,0x23 = (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256) to the list of = ciphersuites.

The first seems more consistent to me.
Chairs: guidance?  Note that the = document is in the RFC editor queue so we=E2=80=99ll need AD approval = for the change at this late date. 

Thanks

Yoav

On 24 Oct 2017, at 16:22, = Martin Rex <mrex@sap.com> wrote:

I = just noticed a strange inconsistency in section 6 of
draft-ietf-tls-rfc4492bis-17

=    https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17#sectio= n-6

The last of the "must implement 1 = of these 4" list of cipher suites at
the end of section 6 = is not contained in the table at the beginning of
section = 6 above it (instead, it appears in rfc5289 only).

I believe that the last ciphersuites should be changed (which = will
provide consistence with the second list entry (the = TLSv1.2 MTI cipher suite).


-Martin


=       +-------------------------------------= ----+----------------+
=       | CipherSuite =             &n= bsp;           &nbs= p;   | Identifier     |
=       +-------------------------------------= ----+----------------+
=       | TLS_ECDHE_ECDSA_WITH_NULL_SHA =           | { 0xC0, = 0x06 } |
      | = TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA   | { 0xC0, 0x08 } |
      | = TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA    | { 0xC0, 0x09 } = |
      | = TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA    | { 0xC0, 0x0A } = |
      | = TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } |
=       | = TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } |
=       | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp;  |
      | = TLS_ECDHE_RSA_WITH_NULL_SHA =             | = { 0xC0, 0x10 } |
      | = TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA     | { 0xC0, = 0x12 } |
      | = TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA      | { = 0xC0, 0x13 } |
      | = TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA      | { = 0xC0, 0x14 } |
      | = TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   | { 0xC0, 0x2F } |
      | = TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   | { 0xC0, 0x30 } |
      | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp;  |
      | = TLS_ECDH_anon_WITH_NULL_SHA =             | = { 0xC0, 0x15 } |
      | = TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA     | { 0xC0, = 0x17 } |
      | = TLS_ECDH_anon_WITH_AES_128_CBC_SHA      | { = 0xC0, 0x18 } |
      | = TLS_ECDH_anon_WITH_AES_256_CBC_SHA      | { = 0xC0, 0x19 } |
=       +-------------------------------------= ----+----------------+


=   Server implementations SHOULD support all of the following = cipher
  suites, and client implementations = SHOULD support at least one of
  them:

  o =  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  o =  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  o =  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+  o =  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
-  o =  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_D67FD347-A716-4B04-A173-39F8FA9B9AC0-- From nobody Tue Oct 24 12:05:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F3D13954E for ; Tue, 24 Oct 2017 12:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 1shOPp5bxRNr for ; Tue, 24 Oct 2017 12:05:37 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF661393A1 for ; Tue, 24 Oct 2017 12:05:37 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Oct 2017 15:06:59 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Tue, 24 Oct 2017 15:05:34 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9OJ4lM7011820; Tue, 24 Oct 2017 15:04:47 -0400 To: "Salz, Rich" From: "David A. Cooper" CC: Message-ID: Date: Tue, 24 Oct 2017 15:04:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:05:40 -0000
With this extension, any middlebox anywhere can drop traffic that is not tappable.  Regardless of who controls the clients and servers, we are now enabling entities to block traffic unless you acquiesce. For example, an inflight wifi could use this.  Maybe, ultimately, many/most of the servers that the passengers connect to will not support it, but some might.

Rich,

You've brought up this example of in-flight WiFi and other middleboxes on the Internet uses this extension as a means of coercing individuals into allowing their TLS traffic with servers to be intercepted, but I fail to see how the scenario is at all realistic.

Yes, any box that sits between the client and the server can drop traffic for whatever reason it wants. Such a box could today drop any traffic that is protected using TLS.

In order for a middlebox to be able to use this draft to intercept traffic that is TLS protected, it would need to:

1) get the server to agree to allow it to intercept the traffic; and

2) get the client to include the new extension in its ClientHello.

How would the middlebox get the client to include the extension. You previously said:
I believe I know why people want this now. They are worried that if TLS 1.3 goes out without something like this, then the market (standard widely available browsers) will not implement it. Let me assure you that this isn’t an issue. The extension would *never ever* make it to the MUST state, and the browsers would be unlikely to ever implement it anyway.

I partially agree with this and partially disagree. I agree that browsers (and other similar clients) would be unlikely to ever implement it. I disagree with the suggestion that proponents of this draft want for browsers to implement this or want it to be a MUST. Proponents of this draft are interested in visibility within the data center, and have no interest in using this capability in any scenario in which a browser would be the client.

So, given your agreement that browsers would be unlikely to ever implement this extension, how would the in-flight WiFi (or other middlebox) be able to get clients to include the extension if the software they are using doesn't support it? It seems that the only way would be to coerce the clients into using a browser (or other client) provided by the attacker (i.e., in order to use the Internet while in flight you must install Evil Airline's browser/app). But then, if the attacker is able to get the client to install and use its own software, then it would easily be able to intercept all traffic from the client, not just traffic to cooperating servers, so why would it bother using this draft at all in this case?



From nobody Tue Oct 24 12:17:55 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBAE138F9C for ; Tue, 24 Oct 2017 12:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxfblamTD93Y for ; Tue, 24 Oct 2017 12:17:52 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619401386F3 for ; Tue, 24 Oct 2017 12:17:52 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id z28so31847011qtz.13 for ; Tue, 24 Oct 2017 12:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zaJGYUWPDMSERfJVTYdx9yvC8vG/5cu/4FQlzP8hw3g=; b=bz9htvQMCB4vCUBnymDHLtlzmveXWRQQyASfYvGy/kwHWqS0R35KYP5tRdkMy+d7YI qAeMUNehsILTQajT2w3vQZilvwsk8/gIW4OL4Fekn+tWCtWA8PFvY4U/PLbbBKVQHLAT fiX+6jsBF/yJiVQmOdz+PrfvvG7+CZVqM0piHd1awtRkYzZ/E0gWg+Yq/1sMoQUdlgcR 9818k6ITT7m31LCRjgSFi0+c2XZWVLIa+58oi3vFBtzp9fQf5qxgksF5D0tKtnx0hW1p jmokKWh/Qj5kFjHYWiBhDdiyfyWZhal43A6RWX8N+IEwGXormqmEu4+m20Fmo0UH/CJC AfVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zaJGYUWPDMSERfJVTYdx9yvC8vG/5cu/4FQlzP8hw3g=; b=agDMCIO3Lf/6b0Krr8JnIK8oQlfBbwsZpGt7oyoKkifWL7alhowL6RM0mMTIaweGCI kxMfd5vG+jO2m/C/c3Wsci0Rtc+HZRQTF/BI/LjCyvo76qtTLIFhh9NcqZBr3gZrxGym IulPAF83WxHawePqWtu0OR1xAMydd8RIwI2+1XU2jVfA/ocZsnPyHuF/BR1F36pzGBYQ 7FIfpxFWdNHb1jHTDt6gLKSjAOojOSOtJcZYQ6yi/FsTk+i9UApQFACgRzqpg5Bso28F C+17jgIMlae8TrHyHE3OFhb7odi3qCvg+95dFjVASMoqYPilkGq9jDSv/bmb88Ni4Tzg 2rlQ== X-Gm-Message-State: AMCzsaUI0ePJVlA+RIOFoCON2ubQMabQsI7kShq2Nr79ZKUf8UnwZNr4 njr5fwdUV+1SEgZ5D8OecqkP3A== X-Google-Smtp-Source: ABhQp+Qf2EGnameYBh70GQIlFtP+Yz216n1xoY9iH91DSfvZH5lrgaVIGZ3Aj08/p7gjpnP2G6NPHA== X-Received: by 10.200.3.31 with SMTP id q31mr26147509qtg.284.1508872671470; Tue, 24 Oct 2017 12:17:51 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id a190sm677356qkg.15.2017.10.24.12.17.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:17:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: Date: Tue, 24 Oct 2017 15:17:49 -0400 Cc: "Salz, Rich" , tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <864AA57B-470C-4C1A-A44F-7F12BE57D64B@fugue.com> References: To: "David A. Cooper" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:17:55 -0000 On Oct 24, 2017, at 3:04 PM, David A. Cooper = wrote: > In order for a middlebox to be able to use this draft to intercept = traffic that is TLS protected, it would need to: >=20 > 1) get the server to agree to allow it to intercept the traffic; and >=20 > 2) get the client to include the new extension in its ClientHello. >=20 > How would the middlebox get the client to include the extension. Block all TLS connections that don't use it. >> I believe I know why people want this now. They are worried that if = TLS 1.3 goes out without something like this, then the market (standard = widely available browsers) will not implement it. Let me assure you that = this isn=E2=80=99t an issue. The extension would *never ever* make it to = the MUST state, and the browsers would be unlikely to ever implement it = anyway. >=20 > I partially agree with this and partially disagree. I agree that = browsers (and other similar clients) would be unlikely to ever implement = it. I disagree with the suggestion that proponents of this draft want = for browsers to implement this or want it to be a MUST. Proponents of = this draft are interested in visibility within the data center, and have = no interest in using this capability in any scenario in which a browser = would be the client. Let's be clear. While I may have made some statements about the = balance of concern over who pays for this, nobody is saying that the = proponents of this draft intend a nefarious use of this extension. The = concern is not that BCBS is going to invade my privacy. It is that if = BCBS gets its way, someone _else_ will use this technology to invade my = privacy, or to trojan horse some malware onto my computer, or some other = attack. > So, given your agreement that browsers would be unlikely to ever = implement this extension, how would the in-flight WiFi (or other = middlebox) be able to get clients to include the extension if the = software they are using doesn't support it? It seems that the only way = would be to coerce the clients into using a browser (or other client) = provided by the attacker (i.e., in order to use the Internet while in = flight you must install Evil Airline's browser/app). But then, if the = attacker is able to get the client to install and use its own software, = then it would easily be able to intercept all traffic from the client, = not just traffic to cooperating servers, so why would it bother using = this draft at all in this case? You've inverted the chain of causality here. The chain is (to the best = of my ability to explain it, anyway): 1. Standardize this extension 2. Someone with a service people want to use starts blocking connections = that don't enable it. 3. Browser vendors are forced to implement it, or end users are forced = to download special browser software. 4. Now an attack surface exists on the user's machine that hadn't = previously existed. 5. The user's machine is now subject to attack by a larger set of = attackers than it had been previously, using a larger set of attacks = than were available previously. None of this is a smoking gun. If everybody keeps all the plates = spinning, we won't have a problem. The problem is that everybody = keeping the plates spinning is something that pretty much doesn't happen = in the real world, as we've seen if we follow the news. And some of = the everybodies in this equation are operating infrastructure that we = really, really need to be well protected. And others are being = stalked. And still others are trying to do secure transactions online. From nobody Tue Oct 24 12:23:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0E8138F9C for ; Tue, 24 Oct 2017 12:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 MAiaJ92MyDSe for ; Tue, 24 Oct 2017 12:23:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683411386F3 for ; Tue, 24 Oct 2017 12:23:16 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9OJN56B000498; Tue, 24 Oct 2017 20:23:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=kEYZepiBAPK6lNhsF/YEhvd8laAvu/QNObfp+KD1bQU=; b=kbiDjnL5bBuYeUoAE15GL3dz2uyxOsM30bjygYx9kiPFisKsbiLfJ2CtcU/oisZoiuf+ 6AAgdXCLGMBmHzk5DkC9MxcyqOYMVwK2a2azvjtTLef+8j411LI2w3QVKIkTL6yTj06j g+X5fysa6vlNel4TXgRvjYtiBlAJqLpjr7R0mrwZ8As8P/rtybsm95ZxwIHb6UlgD4Er 7c959s93y0L58yyfZ/JeVA82/+FAF21fn3hrwtXDeqL7gBJfRdQeiQ6+JRSocbnL9RYz WiSlXLecnlO/xZvCWEIq2sAo+3cdP37zw7XLclMtGwdzbSwavQ4jIlmyxEpqWZh40C7t 1A== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2dquad30mk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 20:23:14 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9OJKXX8028206; Tue, 24 Oct 2017 15:23:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1ju9xnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 15:23:13 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 15:23:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 15:23:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 24 Oct 2017 15:23:12 -0400 From: "Salz, Rich" To: "David A. Cooper" CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgA Date: Tue, 24 Oct 2017 19:23:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.119] Content-Type: multipart/alternative; boundary="_000_FB95CAC8C967472490FBB7E609DADF45akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240265 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240265 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:23:18 -0000 --_000_FB95CAC8C967472490FBB7E609DADF45akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB1c2UgYW4gYWlycGxhbmUgYXMgYW4gZXhhbXBsZSBvZiBhIOKAnGNhcHRpdmXigJ0gcG9wdWxh dGlvbiwgc3Vic3RpdHV0ZSBhbnkgc2ltaWxhciBncm91cCB5b3Ugd2FudC4NCg0KDQoNCiAgKiAg IFllcywgYW55IGJveCB0aGF0IHNpdHMgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVy IGNhbiBkcm9wIHRyYWZmaWMgZm9yIHdoYXRldmVyIHJlYXNvbiBpdCB3YW50cy4gU3VjaCBhIGJv eCBjb3VsZCB0b2RheSBkcm9wIGFueSB0cmFmZmljIHRoYXQgaXMgcHJvdGVjdGVkIHVzaW5nIFRM Uy4NCg0KVHJ1ZSwgYnV0IHRoYXTigJlzIG5vdCB0aGUgcG9pbnQuICBUaGUgcG9pbnQgaXMgYnkg YWRkaW5nIHRoaXMgZXh0ZW5zaW9uIGludG8gdGhlIGNsaWVudEhlbGxvLCB3ZSBhcmUgcHJvdmlk aW5nIG1pZGRsZWJveGVzIHdpdGggYW5vdGhlciBrbm9iIHRvIGNvbnRyb2wgdHJhZmZpYy4gIEkg dGhpbmsgd2Ugd2FudCB0byBhdm9pZCB0aGF0LiBBbmQga2VlcCBpbiBtaW5kIGl04oCZcyBub3Qg anVzdCBIVFRQLCBidXQgKmFueSogVExTLXVzaW5nIHRyYWZmaWMsIHN1Y2ggYXMgbWFueSBWUE7i gJlzLiAgSXQgd291bGRu4oCZdCBuZWNlc3NhcmlseSBlbmFibGUgc3B5aW5nLCBidXQgaXQgY291 bGQgYmUgdXNlZCB0byBndWFyYW50ZWUgdGhhdCBhbGwgdHJhZmZpYyBpcyBhbWVuYWJsZSB0byBz cHlpbmcuDQoNCkFzIGZvciBob3cgd291bGQgc3VjaCBjbGllbnRzIGdldCBwcm9tdWxnYXRlZD8g IFNvbWUgc2ltcGxlIHNjZW5hcmlvdXMgaW5jbHVkZSDigJxzdXJmIGZvciBmcmVlIG9uIHlvdXIg ZmxpZ2h0LCBidXQgdXNlIG91ciBDaHJvbWl1bS1iYXNlZCBicm93c2VyIHRvIGRvIHNvLCBhdmFp bGFibGUgZm9yIGZyZWUgaGVyZS7igJ0gICAgSG93IG1hbnkgcGVvcGxlIG9uIHRoZSBwbGFuZSB3 b3VsZCBjbGljayBhbmQgZG93bmxvYWQ/DQoNCj4gUHJvcG9uZW50cyBvZiB0aGlzIGRyYWZ0IGFy ZSBpbnRlcmVzdGVkIGluIHZpc2liaWxpdHkgd2l0aGluIHRoZSBkYXRhIGNlbnRlciwgYW5kIGhh dmUgbm8gaW50ZXJlc3QgaW4gdXNpbmcgdGhpcyBjYXBhYmlsaXR5IGluIGFueSBzY2VuYXJpbyBp biB3aGljaCBhIGJyb3dzZXIgd291bGQgYmUgdGhlIGNsaWVudC4NCg0KSG93IGRvIHlvdSBwcm9w b3NlIHRvIGd1YXJhbnRlZSB0aGF0PyAgQXMgU3RlcGhlbiBwb2ludGVkIG91dCwgd2UgaGF2ZSBu byB3YXkgdG8gcHJldmVudCB0aGlzIGZyb20g4oCcZXNjYXBpbmfigJ0gb24gdG8gdGhlIHB1Ymxp YyBJbnRlcm5ldCwgYW5kIG5vIHdheSB0byBwcmV2ZW50IGNhcHRpdmUgYXVkaWVuY2VzIGZyb20g YmVpbmcgZm9yY2VkIHRvIGNvbXBseS4NCg0KDQo= --_000_FB95CAC8C967472490FBB7E609DADF45akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <37B6950800B3F540BFA5920A38DB94DE@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoz Mjk3OTgyNDg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjMyMDg2ODY1MiAxOTQ2Mjg4OTY2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6 Ym9sZDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVzZSBhbiBhaXJwbGFuZSBhcyBhbiBleGFtcGxl IG9mIGEg4oCcY2FwdGl2ZeKAnSBwb3B1bGF0aW9uLCBzdWJzdGl0dXRlIGFueSBzaW1pbGFyIGdy b3VwIHlvdSB3YW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxl PSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlllcywg YW55IGJveCB0aGF0IHNpdHMgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyIGNhbiBk cm9wIHRyYWZmaWMgZm9yIHdoYXRldmVyIHJlYXNvbiBpdCB3YW50cy4gU3VjaCBhIGJveCBjb3Vs ZCB0b2RheSBkcm9wIGFueSB0cmFmZmljIHRoYXQgaXMgcHJvdGVjdGVkIHVzaW5nIFRMUy48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRydWUs IGJ1dCB0aGF04oCZcyBub3QgdGhlIHBvaW50LiZuYnNwOyBUaGUgcG9pbnQgaXMgYnkgYWRkaW5n IHRoaXMgZXh0ZW5zaW9uIGludG8gdGhlIGNsaWVudEhlbGxvLCB3ZSBhcmUgcHJvdmlkaW5nIG1p ZGRsZWJveGVzIHdpdGggYW5vdGhlciBrbm9iIHRvIGNvbnRyb2wgdHJhZmZpYy4mbmJzcDsgSSB0 aGluayB3ZSB3YW50IHRvIGF2b2lkIHRoYXQuIEFuZCBrZWVwIGluIG1pbmQgaXTigJlzIG5vdCBq dXN0IEhUVFAsIGJ1dCAqPGI+YW55PC9iPioNCiBUTFMtdXNpbmcgdHJhZmZpYywgc3VjaCBhcyBt YW55IFZQTuKAmXMuJm5ic3A7IEl0IHdvdWxkbuKAmXQgbmVjZXNzYXJpbHkgZW5hYmxlIHNweWlu ZywgYnV0IGl0IGNvdWxkIGJlIHVzZWQgdG8gZ3VhcmFudGVlIHRoYXQgYWxsIHRyYWZmaWMgaXMg YW1lbmFibGUgdG8gc3B5aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBmb3IgaG93IHdv dWxkIHN1Y2ggY2xpZW50cyBnZXQgcHJvbXVsZ2F0ZWQ/Jm5ic3A7IFNvbWUgc2ltcGxlIHNjZW5h cmlvdXMgaW5jbHVkZSDigJxzdXJmIGZvciBmcmVlIG9uIHlvdXIgZmxpZ2h0LCBidXQgdXNlIG91 ciBDaHJvbWl1bS1iYXNlZCBicm93c2VyIHRvIGRvIHNvLCBhdmFpbGFibGUgZm9yIGZyZWUgaGVy ZS7igJ0mbmJzcDsgJm5ic3A7Jm5ic3A7SG93IG1hbnkgcGVvcGxlIG9uIHRoZSBwbGFuZSB3b3Vs ZCBjbGljayBhbmQgZG93bmxvYWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgUHJvcG9u ZW50cyBvZiB0aGlzIGRyYWZ0IGFyZSBpbnRlcmVzdGVkIGluIHZpc2liaWxpdHkgd2l0aGluIHRo ZSBkYXRhIGNlbnRlciwgYW5kIGhhdmUgbm8gaW50ZXJlc3QgaW4gdXNpbmcgdGhpcyBjYXBhYmls aXR5IGluIGFueSBzY2VuYXJpbyBpbiB3aGljaCBhIGJyb3dzZXIgd291bGQgYmUgdGhlIGNsaWVu dC48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBk byB5b3UgcHJvcG9zZSB0byBndWFyYW50ZWUgdGhhdD8mbmJzcDsgQXMgU3RlcGhlbiBwb2ludGVk IG91dCwgd2UgaGF2ZSBubyB3YXkgdG8gcHJldmVudCB0aGlzIGZyb20g4oCcZXNjYXBpbmfigJ0g b24gdG8gdGhlIHB1YmxpYyBJbnRlcm5ldCwgYW5kIG5vIHdheSB0byBwcmV2ZW50IGNhcHRpdmUg YXVkaWVuY2VzIGZyb20gYmVpbmcgZm9yY2VkIHRvIGNvbXBseS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FB95CAC8C967472490FBB7E609DADF45akamaicom_-- From nobody Tue Oct 24 12:24:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE621397EF for ; Tue, 24 Oct 2017 12:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YbGxfhanSOM for ; Tue, 24 Oct 2017 12:24:19 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0931393A1 for ; Tue, 24 Oct 2017 12:24:19 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id v41so31847579qtv.12 for ; Tue, 24 Oct 2017 12:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2kXiibuXBgQcURtB+5QRHlvBBWpZ1VhIxAP568UpU/8=; b=HJEPQ3qSnY3XyheMf4yI7a9Vt9qzbrlaMSQS4+4DxDjDpyPs8ePOVjZevNu1Mv/T4E GFqa4rptgc5bY5CyoaUvI/SbmAKhW8TLymcO8RQ+j1t1DvK0/6cOUFy5uXWQWb1rQJ7G /Qnmwusfaxc6iDBS1hwLD6OcGn2HBMisIgVUq2vjr5pG8fvE02BAzygoG04UCypZeBdN 9hlzjzoygEY7QFsuOjJX0WCv5791nZbRkapeVK75AppEY46jl6/EFbz3Ox5pMZcPUS8c SjmiuGcvDLivcDei06Lv4W7VddUJTSwv7NMKEz706GTKjARbr0grThc4y71iMIaVqaFE nevQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2kXiibuXBgQcURtB+5QRHlvBBWpZ1VhIxAP568UpU/8=; b=Aw5amfdKt0Jw46zjT6JDlIorh47dNNskrWZWgZdXoWBH9StZsSh3hNWbL4vSIRXY3/ kuRt3Bz/wkwXIZf/FHVDR8NOvtggpD1+YTRaOtcF5tdxJIZsw+VhbHm7Gc3UIiO3xNim EYWphQaOWNVCK0yz+InngegJQ4ExH0MAHAG9SZxwvGClSFn1gN2CM/cSnIKnW4kCb+ky KUhBqbbPN8eZkwDAs9vg8H1UpYjrk7wcivDZna2d2e+evYiZq6sK1ZzXtaE9Ibsmncjl 55XkSLUWzLI1OZpkkJ5yE/9k51+FSRJuWyv18bJkaRVxY2hj4WEKDa719WQnFF2Kefcu bWxw== X-Gm-Message-State: AMCzsaXCLQhIr4USJRMe0I9Gi60kLsECya0/6doMRSoRqHi4hlzGJHcp 5v+7d4zA828C4ONAU+CQy1Cu8Eyo X-Google-Smtp-Source: ABhQp+T7MlntvjWykPBskE8qSMDn0CoNjzAzXg9xN7v1byi70LcxHxKByyHDhM7jm7uugucpdebq+Q== X-Received: by 10.200.48.171 with SMTP id v40mr26423742qta.120.1508873058150; Tue, 24 Oct 2017 12:24:18 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:3db6:d45b:1b54:f2a3? ([2601:18f:801:600:3db6:d45b:1b54:f2a3]) by smtp.gmail.com with ESMTPSA id t18sm742831qtc.58.2017.10.24.12.24.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:24:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ralph Droms In-Reply-To: <864AA57B-470C-4C1A-A44F-7F12BE57D64B@fugue.com> Date: Tue, 24 Oct 2017 15:24:16 -0400 Cc: "David A. Cooper" , tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <89E9E608-0C97-4E2D-9BCD-D3F0837AF1D0@gmail.com> References: <864AA57B-470C-4C1A-A44F-7F12BE57D64B@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:24:21 -0000 > On Oct 24, 2017, at 3:17 PM, Ted Lemon wrote: >=20 > On Oct 24, 2017, at 3:04 PM, David A. Cooper = wrote: >> In order for a middlebox to be able to use this draft to intercept = traffic that is TLS protected, it would need to: >>=20 >> 1) get the server to agree to allow it to intercept the traffic; and >>=20 >> 2) get the client to include the new extension in its ClientHello. >>=20 >> How would the middlebox get the client to include the extension. >=20 > Block all TLS connections that don't use it. ...with the assumption that a client would automatically revert to = trying the connection with the visibility extension if it can't make a = connection without the extension. Why would that assumption be useful? = How is this situation different than the current practice of using HTTP = if HTTPS fails? >=20 >>> I believe I know why people want this now. They are worried that if = TLS 1.3 goes out without something like this, then the market (standard = widely available browsers) will not implement it. Let me assure you that = this isn=E2=80=99t an issue. The extension would *never ever* make it to = the MUST state, and the browsers would be unlikely to ever implement it = anyway. >>=20 >> I partially agree with this and partially disagree. I agree that = browsers (and other similar clients) would be unlikely to ever implement = it. I disagree with the suggestion that proponents of this draft want = for browsers to implement this or want it to be a MUST. Proponents of = this draft are interested in visibility within the data center, and have = no interest in using this capability in any scenario in which a browser = would be the client. >=20 > Let's be clear. While I may have made some statements about the = balance of concern over who pays for this, nobody is saying that the = proponents of this draft intend a nefarious use of this extension. The = concern is not that BCBS is going to invade my privacy. It is that if = BCBS gets its way, someone _else_ will use this technology to invade my = privacy, or to trojan horse some malware onto my computer, or some other = attack. Can you demonstrate how such an attack would work without the assumption = that a client (e.g., browser) would, as policy, downgrade to using the = extension if it can't connect without the extension. I understand the = general concern. >=20 >> So, given your agreement that browsers would be unlikely to ever = implement this extension, how would the in-flight WiFi (or other = middlebox) be able to get clients to include the extension if the = software they are using doesn't support it? It seems that the only way = would be to coerce the clients into using a browser (or other client) = provided by the attacker (i.e., in order to use the Internet while in = flight you must install Evil Airline's browser/app). But then, if the = attacker is able to get the client to install and use its own software, = then it would easily be able to intercept all traffic from the client, = not just traffic to cooperating servers, so why would it bother using = this draft at all in this case? >=20 > You've inverted the chain of causality here. The chain is (to the = best of my ability to explain it, anyway): >=20 > 1. Standardize this extension > 2. Someone with a service people want to use starts blocking = connections that don't enable it. > 3. Browser vendors are forced to implement it, or end users are forced = to download special browser software. > 4. Now an attack surface exists on the user's machine that hadn't = previously existed. > 5. The user's machine is now subject to attack by a larger set of = attackers than it had been previously, using a larger set of attacks = than were available previously. I still don't see how step 2 is different than forcing a connection = without using TLS at all? Why is the visibility extension more = dangerous than only allowing connections with no TLS? >=20 > None of this is a smoking gun. If everybody keeps all the plates = spinning, we won't have a problem. The problem is that everybody = keeping the plates spinning is something that pretty much doesn't happen = in the real world, as we've seen if we follow the news. And some of = the everybodies in this equation are operating infrastructure that we = really, really need to be well protected. And others are being = stalked. And still others are trying to do secure transactions online. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Oct 24 12:27:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CAB139B9F for ; Tue, 24 Oct 2017 12:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCgcAcjAgWYH for ; Tue, 24 Oct 2017 12:27:24 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832D313B482 for ; Tue, 24 Oct 2017 12:27:24 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id k123so27727484qke.3 for ; Tue, 24 Oct 2017 12:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=34xPsj+1PTucGcfjpFRdKH9WZLNXuNUziV7KuSzjzlc=; b=J4d8DWK4bFpTWEH6UHAlKj0qxWivLzBNXDUquKU4+A1+6QFbIEx0vIE8vaincatW0R WsJQh4mrOyrxmE+NfZAqnyIqFDdXfRK3sfGXsE6JpapsY7X11QSaFK2xCp3vRLakN4sK ZfEUuF5+TrQo8ZacShNbb3Lf+Z3W1N0VUs4FGk6WPyVxl11TgBlSFj7O51PLuGRnQcxh pk8S7RoORw+ZnzvuSy34s2MU9fQnZwCITUPIfkdLwxjork8LdZSiOx5opPhjhtineR8o SXO+XVc8LiVQGfEFcJ+on9Uj6H74+34nzuIG9UHat3k6B/kHdLUKFb+KkKD66eUOGyF0 1IEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=34xPsj+1PTucGcfjpFRdKH9WZLNXuNUziV7KuSzjzlc=; b=FZspXc/PaIF8HqdsMl28+SPZr6H6NKJVnwxNO4LJfDJOH9P7BOfgJrSDRU1JSxGl29 omYSBXYOY3nFQz0/tilKWBzAhZ2Y4NOnTGgk2g2OZj60TUGdL7D9BeQPN7BOkq/xDzQw bZzGcHK5Td5wUoULAhl32t/r8AqwlFtct1b0UBrHUIZ0WChXTzK+V/ntOgvC9SXBy4kc rDJI8TItsANUtOyNcbt4c5jQ83I2ckj5kN7RVXYdcMsjwAYB+mTCTO4IyBSjzyJUv/HP HyFXshLxdhfAciPzlCHny5abqfqmbCdYyN9dOBTx1fzdeYK9L/aKjMytQvuBc2b/RI1A 7pHg== X-Gm-Message-State: AMCzsaX0n1qxGMFgI6/hbmqAlmnmDJQ+leMZ2FPf944p2sqSQlZrpndP 14/Z5QVtnPkGTvUePZ6WdYUHATW0 X-Google-Smtp-Source: ABhQp+Q8BECkSTRNQzRYIHz8EMMSyxPBS29VvsEF7gpjh+HecJAs1UluXq3k2MXspuohufDBoe89Bg== X-Received: by 10.55.160.18 with SMTP id j18mr25980228qke.327.1508873243590; Tue, 24 Oct 2017 12:27:23 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:3db6:d45b:1b54:f2a3? ([2601:18f:801:600:3db6:d45b:1b54:f2a3]) by smtp.gmail.com with ESMTPSA id l207sm653507qke.97.2017.10.24.12.27.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:27:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ralph Droms In-Reply-To: Date: Tue, 24 Oct 2017 15:27:22 -0400 Cc: "David A. Cooper" , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> References: To: "Salz, Rich" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:27:26 -0000 > On Oct 24, 2017, at 3:23 PM, Salz, Rich wrote: >=20 > I use an airplane as an example of a =E2=80=9Ccaptive=E2=80=9D = population, substitute any similar group you want. > =20 > =E2=80=A2 Yes, any box that sits between the client and the = server can drop traffic for whatever reason it wants. Such a box could = today drop any traffic that is protected using TLS. >=20 > True, but that=E2=80=99s not the point. The point is by adding this = extension into the clientHello, we are providing middleboxes with = another knob to control traffic. I think we want to avoid that. And = keep in mind it=E2=80=99s not just HTTP, but *any* TLS-using traffic, = such as many VPN=E2=80=99s. It wouldn=E2=80=99t necessarily enable = spying, but it could be used to guarantee that all traffic is amenable = to spying. > =20 > As for how would such clients get promulgated? Some simple scenarious = include =E2=80=9Csurf for free on your flight, but use our = Chromium-based browser to do so, available for free here.=E2=80=9D = How many people on the plane would click and download? Just to make sure I understand, in this scenario the special-purpose = browser could just as easily, today, be a browser with no TLS at all? = That is, I don't see why this scenario is specific to the visibility = extension. > =20 > > Proponents of this draft are interested in visibility within the = data center, and have no interest in using this capability in any = scenario in which a browser would be the client. >=20 > How do you propose to guarantee that? As Stephen pointed out, we have = no way to prevent this from =E2=80=9Cescaping=E2=80=9D on to the public = Internet, and no way to prevent captive audiences from being forced to = comply. > =20 > =20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Oct 24 12:31:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F9D13F3D2 for ; Tue, 24 Oct 2017 12:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzKwvnKnfyiy for ; Tue, 24 Oct 2017 12:31:21 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 F045913B482 for ; Tue, 24 Oct 2017 12:31:20 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id y23so27722567qkb.10 for ; Tue, 24 Oct 2017 12:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oTbCcN3/lhaPQRwidrA+TCQhD0FMSYThJv+U6ANLg5c=; b=dsSy1BQhQpmpPkcRKjEGGlaEQYLDRBrRVxlFCVLTtn1odvItBb/NPk93SEWXxiBj12 8LRKzBmyPm/iQedJTomZY/X7mXn0dyjDIJL0e996Jav5LXeA+hiJ7StYBIPeo38koLyv KP1IFM04Xylpos9HsnyHhw3FswAja9RHYBsybYeNGSCpjCmut2nfQ8RbYg50YxR+SM/V 3GW8ZiufSLmcIbkzBxpKwD89m9gT4DuUA/tPH1DNKQNAlewctJea955A+OOe71LR3EGt Sx6eFpN8dKQ12kwo48L/XXdDJRDfGQw2ZLh2mvSo7L1eilrhpFnNk75KFqAWMSwf331S hYEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oTbCcN3/lhaPQRwidrA+TCQhD0FMSYThJv+U6ANLg5c=; b=SHHlcdzXPt/+U7RxOYaeju53JrtRH6ZvLR5HZmazBVvM/HeTmWIfJ9T6P/R1y8RCPn z8BtjXbUTJVwNDrHXH363uX5qAU6lc1UF+7lzb+JpbxsvELQOPq8kYA+psG+3iF2D4XF 4EJHDepVa7JcsBkGTpWXCJujGpF77yymUtvmkDc/7x4y9avEXbFCIBdEUwTMApXvN+4x xH5ySR79vgAS/mOYqOZPRxrnmwX8dapc/G9Ss/JmBjLnYlXUjVmsdpGVz3ywYoZMgM88 Ix+6D2pWciXB3Jxr4UaK8i0V2CK2gNkPXz3tl+JL8Q278twDOIrMiYsqp4TY/OapfKGY CM1Q== X-Gm-Message-State: AMCzsaXDKEvrGKHS4hftQO1W/EfzCTrbKJDphEiSPV7bdZBXdD7g9faK I0SEkOWp20P1Tdq6+NAIOm+uYA== X-Google-Smtp-Source: ABhQp+SqQvX84wWidLaI0P6cDdqfozTlGlZ28IWA5vvEElJ+QDNnqxfShJLLfTcExAlrZyRyTFAJlg== X-Received: by 10.55.79.129 with SMTP id d123mr25887108qkb.247.1508873479959; Tue, 24 Oct 2017 12:31:19 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id s6sm734366qtg.34.2017.10.24.12.31.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:31:18 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_54A50D4F-1463-4BA7-88A9-C37F4D6CE16A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 24 Oct 2017 15:31:17 -0400 In-Reply-To: Cc: "tls@ietf.org" To: Joseph Salowey References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.com> <5D88D34E-E950-40E9-9483-D65D978D2758@akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:31:23 -0000 --Apple-Mail=_54A50D4F-1463-4BA7-88A9-C37F4D6CE16A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 24, 2017, at 12:49 PM, Joseph Salowey wrote: > First, we would like to clarify that this discussion isn't delaying = TLS 1.3. We've been holding final publication to resolve some middlebox = issues as described in a recent message from ekr > https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0 = = and expect to discuss this in Singapore. No one and we mean no one = should delay submitting a PR related to TLS1.3 or any other WG draft = because of this discussion. You=E2=80=99ll note that others have = recently, you should follow suit. Perhaps not. I don't feel qualified to judge. But it's delaying = other work, because people who could be doing useful work in the IETF = are engaging on this topic instead. No discussion is without cost, so = there is value in cutting off useless discussion, and it is very much = your job to do so. E.g., this was about a half hour of my time, and I = have a bunch of other things to do before the draft submission cutoff = that I didn't do so that I could respond to this. > In Prague, we had a discussion of draft-green and there was neither = consensus to work in this area nor to decline to work in this area. In = addition to the comments that we should simply decline all such work, = the authors received technical comments about their approach and = draft-rhrd seems to be an attempt to address some of those comments. As = is normal IETF practice, we will be giving this topic agenda time in = Singapore to see if a consensus emerges one way or the other. The problem with this is that technical comments about a bad idea just = improve the bad idea. The discussion we have been trying to have with = the proponents of this idea is the question of whether or not it is a = bad idea, not about the technical details. I say this as someone who = has proposed lots of bad ideas in the past. When I propose a bad idea, = and for example Dave Oran points out something obvious that I missed = (true story), my response to this is to reconsider what I've proposed to = do and to see if there is a better way to solve the problem, not to = continue pushing for the idea that has been shown to be a bad idea. Our objection here, which I third or fourth, is that this discussion has = not progressed that way. This is clearly a bad idea. Maybe you don't = agree. But we've said why it's clearly a bad idea, and that is = something that could have been discussed. But none of the proponents = of this idea have made any attempt to address the substantive objections = that have been raised about the idea itself. So it's not really fair to say that progress is being made. Progress = is being made on refining the bad idea, but no progress has been made in = discussing ways to solve the problem that aren't a bad idea. To be = clear, I and several others have proposed ways of solving this problem = that are not bad ideas. These have been rejected on non-technical = grounds. > Absolutely no decisions will be made about adoption prior to that = time, nor prior to a formal call for adoption. In particular, decisions = will not be made based on the volume of messages to the mailing list. = It is unnecessary and unproductive to repeat points you have already = made just because someone responds to you. You will not be missing out = on the chance to make your argument. This feels like the Overton window shifting due to a false equivalence. = The issue here is not that we feel that we will miss out on the chance = to make our arguments. It's that we've been making them, and they've = been explicitly ignored. > Finally, we would like to remind WG members to keep their messages = professional and civil. We have noted a number of recent messages that = do not conform to those standards and we will be reaching out to people = personally to address those instances. I believe that I have been personally chastized by another participant = for responding in a way that was held by that participant to be = uncivil/unprofessional. If you agree with that assessment, please = communicate with me to that effect privately (or publicly, if you = prefer, but this conversation has really gone on for too long). --Apple-Mail=_54A50D4F-1463-4BA7-88A9-C37F4D6CE16A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Oct 24, 2017, at 12:49 PM, Joseph Salowey <joe@salowey.net> = wrote:
First, we would like to clarify that = this discussion isn't delaying TLS 1.3. We've been holding final = publication to resolve some middlebox issues as described in a recent = message from ekr
https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2= e-W5G0 and expect to discuss this = in Singapore. No one and we mean no one should delay submitting a PR = related to TLS1.3 or any other WG draft because of this discussion. = You=E2=80=99ll note that others have recently, you should follow = suit.

Perhaps not.   I don't feel qualified to judge. =   But it's delaying other work, because people who could be doing = useful work in the IETF are engaging on this topic instead.   No = discussion is without cost, so there is value in cutting off useless = discussion, and it is very much your job to do so.   E.g., this was = about a half hour of my time, and I have a bunch of other things to do = before the draft submission cutoff that I didn't do so that I could = respond to this.

In Prague, we had a = discussion of draft-green and there was neither consensus to work in = this area nor to decline to work in this area.  In addition to the = comments that we should simply decline all such work, the authors = received technical comments about their approach and draft-rhrd seems to = be an attempt to address some of those comments.  As is normal IETF = practice, we will be giving this topic agenda time in Singapore to see = if a consensus emerges one way or the = other.

The problem with this is that technical comments about = a bad idea just improve the bad idea.   The discussion we have been = trying to have with the proponents of this idea is the question of = whether or not it is a bad idea, not about the technical details.   = I say this as someone who has proposed lots of bad ideas in the past. =   When I propose a bad idea, and for example Dave Oran points out = something obvious that I missed (true story), my response to this is to = reconsider what I've proposed to do and to see if there is a better way = to solve the problem, not to continue pushing for the idea that has been = shown to be a bad idea.

Our = objection here, which I third or fourth, is that this discussion has not = progressed that way.   This is clearly a bad idea.   Maybe you = don't agree.   But we've said why it's = clearly a bad idea, and that is something that could have been = discussed.   But none of the proponents of this idea have made any = attempt to address the substantive objections that have been raised = about the idea itself.

So it's not = really fair to say that progress is being made.   Progress is being = made on refining the bad idea, but no progress has been made in = discussing ways to solve the problem that aren't a bad idea.   To = be clear, I and several others have proposed ways = of solving this problem that are not bad ideas.   These have been = rejected on non-technical grounds.

Absolutely no decisions = will be made about adoption prior to that time, nor prior to a formal = call for adoption. In particular, decisions will not be made based on = the volume of messages to the mailing list.  It is unnecessary and = unproductive to repeat points you have already made just because someone = responds to you. You will not be missing out on the chance to make your = argument.

This feels like the Overton window shifting due to a = false equivalence.   The issue here is not that we feel that we = will miss out on the chance to make our arguments.   It's that = we've been making them, and they've been explicitly = ignored.

Finally, we would like = to remind WG members to keep their messages professional and civil. We = have noted a number of recent messages that do not conform to those = standards and we will be reaching out to people personally to address = those = instances.

I believe that I have been personally = chastized by another participant for responding in a way that was held = by that participant to be uncivil/unprofessional.   If you agree = with that assessment, please communicate with me to that effect = privately (or publicly, if you prefer, but this conversation has really = gone on for too long).

= --Apple-Mail=_54A50D4F-1463-4BA7-88A9-C37F4D6CE16A-- From nobody Tue Oct 24 12:32:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AA013F827 for ; Tue, 24 Oct 2017 12:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 EaJvC9yNYbT8 for ; Tue, 24 Oct 2017 12:32:42 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6332A13F823 for ; Tue, 24 Oct 2017 12:32:42 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9OJVeLg028230; Tue, 24 Oct 2017 20:32:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=XMKckBZLl1y4soJgj2Twh+9NyKXp0lJa7EBuPHU5lXI=; b=F2HzDTSNamW8bq6FBh29WQAFrcKckNJZKGWXEUetEJlkih1NfoVQyJ/aC2fgRCeKT/aD Dz38ctEtGUSmSfua7fhA2ueqECKD9ob4Z+5g2+FY+TBscMDS2pTdyI/EVtWuU5hulcjW KFOHJGBJ1OmSpQOrTsGzce22W0GUYwsTDtaiFtjUkDDKRHpnMu0eQTwoRWUNEiZ1DJ8f 827rJ1lgcdo/MvWcSkLyiU3KQDEMnxyglKV7nksTQ9x42w/m5UsEUssuDoiwiDXKiKeD gUo4d1utcvDLsQ2Vl/MHUwECsIr7/ayXpPU7T9SCXxFYPOYeAx/2f4F1/PEZuchHVCJ0 6A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2dqwgkuamf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 20:32:39 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9OJURh8018523; Tue, 24 Oct 2017 15:32:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dr1juhxch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 15:32:38 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 15:32:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 24 Oct 2017 15:32:37 -0400 From: "Salz, Rich" To: Ralph Droms CC: "David A. Cooper" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAF3AA== Date: Tue, 24 Oct 2017 19:32:36 +0000 Message-ID: <9E9C2714-D708-4291-A7E2-64278C10E697@akamai.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> In-Reply-To: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.119] Content-Type: text/plain; charset="utf-8" Content-ID: <7C6CE768190DCF46874BAE82B96A5A7F@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240267 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240268 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:32:43 -0000 4p6iIEp1c3QgdG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZCwgaW4gdGhpcyBzY2VuYXJpbyB0aGUg c3BlY2lhbC1wdXJwb3NlIGJyb3dzZXIgY291bGQganVzdCBhcyBlYXNpbHksIHRvZGF5LCBiZSBh IGJyb3dzZXIgd2l0aCBubyBUTFMgYXQgYWxsPyAgIFRoYXQgaXMsIEkgZG9uJ3Qgc2VlIHdoeSB0 aGlzIHNjZW5hcmlvIGlzIHNwZWNpZmljIHRvIHRoZSB2aXNpYmlsaXR5IGV4dGVuc2lvbi4NCiAg ICANCkJlY2F1c2UgeW91IGNhbuKAmXQgZG8gdGhhdCB3aXRoIFRMUyByaWdodCBub3cuICBUaGlz IGFkZHMgdGhhdCBhYmlsaXR5LiAgIFRoZSBpZGVhIG9mIGhhdmluZyBhIHBsYWludGV4dCBzaWdu YWwgdGhhdCBhbGxvd3MgaW50ZXJtZWRpYXJpZXMgdG8gZm9yY2UgdXNlcnMgaW50byB3ZWFrZW5p bmcgdGhlaXIgc2VjdXJpdHkgc2VlbXMgdG8gZ28gYWdhaW5zdCB0aGUgdmVyeSBncmFpbiBvZiB3 aGF0IFRMUyB0cmllcyB0byBkby4NCg0KDQo= From nobody Tue Oct 24 12:36:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720561395E5 for ; Tue, 24 Oct 2017 12:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5aM2oqNMoYC for ; Tue, 24 Oct 2017 12:36:04 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995F1138A38 for ; Tue, 24 Oct 2017 12:36:04 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id m72so13410240wmc.0 for ; Tue, 24 Oct 2017 12:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=74GMhPCOEZDEod9Q/uKvUc9nIZaY1y99zB/a97QwE+c=; b=sxgCnM8I+P/qc65/vipLuJW6yWvs0laKY5cXDWjKuFXI9ZLRi3vwc7AV/Oruh2U5r0 86GcQCwWrZKf/kh4r3DsR28DbEqxFKNZKj1Y7kWZDt5D32AJMxuUrJAsdQrKDFnMZ7C5 rCcBIOScrvJAFX1kHVcPJ11GK4E8XEQgjhEtSGGfOKn16wkPLQ0KjEh80w+xNgZVZk06 29XNhI1ThPaqkfoMyhrtbssm5curCKaCtRL6fA7RibiAuTVMcRAYQUWrv++idI7qgEdz uqsUSNeBzaPpSTfSNV85BziIPAuV316INhr1LZisxnE6/NMDk6cKrJPw+3GNBlFoHtoy 1xDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=74GMhPCOEZDEod9Q/uKvUc9nIZaY1y99zB/a97QwE+c=; b=UoBi/hZzdgkvFGkNJts5JQJD2GXqdqWnJ06T2iy2xAGkGOipBq2kKpgkOA5SQcj0Ms F9OZDnPGf4L84CXhcIlV88J1QmPCzptcC2XsV7AecM+znd3cjwqefbqf/6XGoQMa83OL JmStGiFTq/8xBXMZi3jRjAMoOBBxfwK7dYf1t5qvDQy3UQK1MIl+1gdOMm87fjlKiu5l 4++KaICioioFtsdanaKM2CePQCucys+3B/FjV9Pnc5D+D0qUnvHwB2Zr9BUO5ANmHVm8 qk1yMF8NmQCyfYKhsrCX5NC319qBP2cLmp5tTeu4Xs7eHLR58NrmjOeIbBHPArUpXOFZ pijQ== X-Gm-Message-State: AMCzsaWTngQUCjyicrBp+9J9P04sAEB/Xz0+eo7rwBCZ1J/lyhE4fBep 5FWtJEGHqvqO4dssIGurvsg= X-Google-Smtp-Source: ABhQp+RGZfWcHo/35TKb2RGWijUMGOZgL4rDQ+YsCBB+uSk/IRZb6Gjx94Lzl6UTbate65+RIFQZmg== X-Received: by 10.28.66.25 with SMTP id p25mr55858wma.154.1508873763134; Tue, 24 Oct 2017 12:36:03 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id r2sm1064696wmb.38.2017.10.24.12.36.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:36:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Yoav Nir In-Reply-To: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> Date: Tue, 24 Oct 2017 22:36:00 +0300 Cc: Rich Salz , "David A. Cooper" , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:36:06 -0000 > On 24 Oct 2017, at 22:27, Ralph Droms wrote: >=20 >=20 >> On Oct 24, 2017, at 3:23 PM, Salz, Rich wrote: >>=20 >> I use an airplane as an example of a =E2=80=9Ccaptive=E2=80=9D = population, substitute any similar group you want. >>=20 >> =E2=80=A2 Yes, any box that sits between the client and the = server can drop traffic for whatever reason it wants. Such a box could = today drop any traffic that is protected using TLS. >>=20 >> True, but that=E2=80=99s not the point. The point is by adding this = extension into the clientHello, we are providing middleboxes with = another knob to control traffic. I think we want to avoid that. And = keep in mind it=E2=80=99s not just HTTP, but *any* TLS-using traffic, = such as many VPN=E2=80=99s. It wouldn=E2=80=99t necessarily enable = spying, but it could be used to guarantee that all traffic is amenable = to spying. >>=20 >> As for how would such clients get promulgated? Some simple = scenarious include =E2=80=9Csurf for free on your flight, but use our = Chromium-based browser to do so, available for free here.=E2=80=9D = How many people on the plane would click and download? >=20 > Just to make sure I understand, in this scenario the special-purpose = browser could just as easily, today, be a browser with no TLS at all? = That is, I don't see why this scenario is specific to the visibility = extension. Think of the children. We can=E2=80=99t just let them loose on the Internet, there=E2=80=99s = predators out there. So we will snoop on their traffic. To do that, we = block all traffic that isn=E2=80=99t snoopable, and we do it at the edge = router in schools. All schools in our state are required by law to = install a firewall that does this. And we get the mobile operators to do = so as well (only for handsets in schools). Now either the mobile OS vendors make a browser that works in schools = (at least with a setting), or the school recommends a third party = browser that works in school. And best of all, this is *more secure* = than regular TLS 1.3, because it also protects your children from = Internet predators. Think of the children. You can=E2=80=99t make a claim like that for an HTTP-only browser, and = worse still, it won=E2=80=99t work on much of today=E2=80=99s Internet. Yoav From nobody Tue Oct 24 12:41:29 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266CC13A039 for ; Tue, 24 Oct 2017 12:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nHy20DGlnRf for ; Tue, 24 Oct 2017 12:41:25 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 569CD139D0F for ; Tue, 24 Oct 2017 12:41:25 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id k31so31989480qta.6 for ; Tue, 24 Oct 2017 12:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JENlbG5YVMU/JIGsrJ9ZYRK6DgyGX6bmYEi9/E76j5A=; b=TxC7ioDGblj6ERtNwNvJNd+L50Np2SyPkVU7AzopHg1tIagh8EMfR7Mzhty8+cESLr OUmBdsOGB3AMDzl93x3O+YeuBl0ft5tH6NKKvcuRMXhanG4e8+xTnhSqPHKwKPi0N/C9 hn8XjwCDz7zWOG8uVCDiJarw+Ocq8133ZEdXGF57sKsVoLj8jrwWCAHtcHnxMx1CnjoS lqmBnXqWcB5AnXxFeuKxEBk2uYAaAKp1aHZQ9IFGKV4PWN90+sixYnhrgOM8O+dKUpVc hqrTeRhNm1I5BMULx65IBv8EcE3H0irmUN36UPo2VoMZ85xpeiFbIWDg64mMFb0mIQ/T G9ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JENlbG5YVMU/JIGsrJ9ZYRK6DgyGX6bmYEi9/E76j5A=; b=nZmd5Jq5E7bECTT8VLuk1nqhQ6Ffchvpqv2WbEA6Im2OrkVSwDTdv635BDbWa8JTWd bj5rCIsB/iQsHv4DrM1jrCC9QOtGQuvY2UqlSRSh4qcP9QJRGut+komaL9+oFUt3EwBo DCnd14x8yuiMYYNwWxIUVU0Yluw/niFh4vuarLzQOAc4LTgAu/52JhthJrSwRhsbO928 CtWYeoo+5yk2UZbOp+zwYRxAuP5LXo3+FtjrVCdxw/a2XPzJjyC8lC/z90CHkiabUwT2 tEFcbS6zohwQicGpaJVL4KdVI0wW6kFAAkmUDUFuR64ERlpa5ZzwMSXnlwJim4nX7IRP 5obw== X-Gm-Message-State: AMCzsaWE1p3G0AQYO2W8NQRZ2LwL5ZjMwPbywSzpGq7AYy75X806bJ5W k7QqAiNfGFMpRSwZziUL9JzQzFcL3HE= X-Google-Smtp-Source: ABhQp+TLyt9i0KDMtwzJR317kgo7pBneEWKt1fHdJjViYpPXUO1MZo3MX5yWCgAisivdpVo+k9W2jw== X-Received: by 10.200.12.193 with SMTP id o1mr26120514qti.254.1508874084486; Tue, 24 Oct 2017 12:41:24 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id t5sm731608qkl.10.2017.10.24.12.41.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:41:23 -0700 (PDT) From: Ted Lemon Message-Id: <60E804DC-11EF-4CCB-A67B-F8B0FCADD4A8@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9F8B58B9-634A-4A99-9C2A-7893E8C1DD8B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 24 Oct 2017 15:41:22 -0400 In-Reply-To: <89E9E608-0C97-4E2D-9BCD-D3F0837AF1D0@gmail.com> Cc: "David A. Cooper" , tls@ietf.org To: Ralph Droms References: <864AA57B-470C-4C1A-A44F-7F12BE57D64B@fugue.com> <89E9E608-0C97-4E2D-9BCD-D3F0837AF1D0@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:41:27 -0000 --Apple-Mail=_9F8B58B9-634A-4A99-9C2A-7893E8C1DD8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2017, at 3:24 PM, Ralph Droms wrote: > ...with the assumption that a client would automatically revert to = trying the connection with the visibility extension if it can't make a = connection without the extension. Why would that assumption be useful? = How is this situation different than the current practice of using HTTP = if HTTPS fails? More likely the client would be failed with one that just automatically = negotiates the visibility extension, because that's easier and quicker. > Can you demonstrate how such an attack would work without the = assumption that a client (e.g., browser) would, as policy, downgrade to = using the extension if it can't connect without the extension. I = understand the general concern. I don't think it's necessary to demonstrate that, because the browser = that implements this extension will just automatically negotiate it. > I still don't see how step 2 is different than forcing a connection = without using TLS at all? Why is the visibility extension more = dangerous than only allowing connections with no TLS? There's no fig leaf of security if you allow connections with no TLS. The problem with these proposals generally is that they push us in the = direction of picking and choosing who we will allow to eavesdrop on us, = and make it non-negotiable in order to access services we want. You = and I are smart enough to say "no" when presented with this choice; = unfortunately, at least at present, many people are not, and see things = like browser security warnings as annoyances. This is why UAC failed = in Windows Vista, and why Vista was widely reviled for its poor = usability. It is demonstrably the case that users will say yes to things that are = not in their self interest to get to the resources they want. Every = time I visit my mom, she has new malware installed on her Chromebook = that I removed on my previous visit. So if we do not say no to this, it's likely that ultimately not enough = people will, and a lot of end users will suffer as a result, some of = them operating things we'd like to remain secure. That is the = discussion we should be having right now. --Apple-Mail=_9F8B58B9-634A-4A99-9C2A-7893E8C1DD8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 24, 2017, at 3:24 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
...with the assumption that a client = would automatically revert to trying the connection with the visibility = extension if it can't make a connection without the extension.  Why = would that assumption be useful?  How is this situation different = than the current practice of using HTTP if HTTPS fails?

More likely the = client would be failed with one that just automatically negotiates the = visibility extension, because that's easier and quicker.

Can you demonstrate = how such an attack would work without the assumption that a client = (e.g., browser) would, as policy, downgrade to using the extension if it = can't connect without the extension.  I understand the general = concern.

I don't think it's necessary to demonstrate that, = because the browser that implements this extension will just = automatically negotiate it.

I still don't see how step 2 is different = than forcing a connection without using TLS at all?  Why is the = visibility extension more dangerous than only allowing connections with = no TLS?

There's no fig leaf of security if you allow = connections with no TLS.

The problem = with these proposals generally is that they push us in the direction of = picking and choosing who we will allow to eavesdrop on us, and make it = non-negotiable in order to access services we want.   You and I are = smart enough to say "no" when presented with this choice; unfortunately, = at least at present, many people are not, and see things like browser = security warnings as annoyances.   This is why UAC failed in = Windows Vista, and why Vista was widely reviled for its poor = usability.

It is demonstrably the = case that users will say yes to things that are not in their self = interest to get to the resources they want.   Every time I visit my = mom, she has new malware installed on her Chromebook that I removed on = my previous visit.

So if we do not = say no to this, it's likely that ultimately not enough people will, and = a lot of end users will suffer as a result, some of them operating = things we'd like to remain secure.   That is the discussion we = should be having right now.

= --Apple-Mail=_9F8B58B9-634A-4A99-9C2A-7893E8C1DD8B-- From nobody Tue Oct 24 12:49:34 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6502813A039 for ; Tue, 24 Oct 2017 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 AvkyQdicU_Ky for ; Tue, 24 Oct 2017 12:49:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D7E1397F3 for ; Tue, 24 Oct 2017 12:49:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 584B5BE2E; Tue, 24 Oct 2017 20:49:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1L0bVYG2gsP; Tue, 24 Oct 2017 20:49:22 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6EF53BE24; Tue, 24 Oct 2017 20:49:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508874562; bh=g1G6XJmCVBDimQTh6J/d49frsDi2UJ3nJ7LYB4qFqug=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NxkHXGNkRMczV/Ngq5p9DbK6gXePuMLvuyThYGXK4wBAt8o3SQkWaun/Qu6OxoDA/ lcJ/2e0bFj7fhTh5yqcktKyLUwX+ahWUdJJNfgdZ94r8rch2dlXpmn5uQVVItrsKvu IGR+pwm9bf1pVZIeK/qtezcaSu4T+cpXiEdM6xDE= To: Ralph Droms Cc: Yoav Nir , "David A. Cooper" , "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 24 Oct 2017 20:49:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nNAqpbxe6mfEEiQ0SULLj4MvXOJT1S0qg" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:49:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nNAqpbxe6mfEEiQ0SULLj4MvXOJT1S0qg Content-Type: multipart/mixed; boundary="bRxqkvCD6kagx6uOHIqcKBov8AEOjn6GQ"; protected-headers="v1" From: Stephen Farrell To: Ralph Droms Cc: Yoav Nir , "David A. Cooper" , "tls@ietf.org" Message-ID: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> In-Reply-To: <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> --bRxqkvCD6kagx6uOHIqcKBov8AEOjn6GQ Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Ralph, On 24/10/17 20:36, Yoav Nir wrote: >=20 >=20 >> On 24 Oct 2017, at 22:27, Ralph Droms wrote: >> >> >>> On Oct 24, 2017, at 3:23 PM, Salz, Rich wrote: >>> >>> I use an airplane as an example of a =E2=80=9Ccaptive=E2=80=9D popula= tion, substitute any similar group you want. >>> >>> =E2=80=A2 Yes, any box that sits between the client and the server c= an drop traffic for whatever reason it wants. Such a box could today drop= any traffic that is protected using TLS. >>> >>> True, but that=E2=80=99s not the point. The point is by adding this = extension into the clientHello, we are providing middleboxes with another= knob to control traffic. I think we want to avoid that. And keep in min= d it=E2=80=99s not just HTTP, but *any* TLS-using traffic, such as many V= PN=E2=80=99s. It wouldn=E2=80=99t necessarily enable spying, but it coul= d be used to guarantee that all traffic is amenable to spying. >>> >>> As for how would such clients get promulgated? Some simple scenariou= s include =E2=80=9Csurf for free on your flight, but use our Chromium-bas= ed browser to do so, available for free here.=E2=80=9D How many people= on the plane would click and download? >> >> Just to make sure I understand, in this scenario the special-purpose b= rowser could just as easily, today, be a browser with no TLS at all? Th= at is, I don't see why this scenario is specific to the visibility extens= ion. >=20 > Think of the children. >=20 > We can=E2=80=99t just let them loose on the Internet, there=E2=80=99s p= redators out there. So we will snoop on their traffic. To do that, we bl= ock all traffic that isn=E2=80=99t snoopable, and we do it at the edge ro= uter in schools. All schools in our state are required by law to install= a firewall that does this. And we get the mobile operators to do so as w= ell (only for handsets in schools). >=20 > Now either the mobile OS vendors make a browser that works in schools (= at least with a setting), or the school recommends a third party browser = that works in school. And best of all, this is *more secure* than regular= TLS 1.3, because it also protects your children from Internet predators.= Think of the children. >=20 > You can=E2=80=99t make a claim like that for an HTTP-only browser, and = worse still, it won=E2=80=99t work on much of today=E2=80=99s Internet. Just to note that the only substantive difference between draft-green and this is the please-screw-me extension in the ClientHello and Yoav's argument above (with or without all the obvious corollaries/variations) destroys that as a defence for your latest effort to square this circle. (This has been stated at least a couple of times/ways already.) If you Ralph or Russ have some new arguments for your draft that have not been countered already or wrt draft-green then I wish you would raise those, because I've not seen any that have survived. And if you have no such arguments then I think it'd be a fine thing to admit that truth openly. The underlying idea remains as bad as ever, for all the reasons I tried to summarise at [1] (to which I'll add Yoav's description above when I get a chance as it's a nice illustration). S. [1] https://github.com/sftcd/tinfoil >=20 > Yoav >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --bRxqkvCD6kagx6uOHIqcKBov8AEOjn6GQ-- --nNAqpbxe6mfEEiQ0SULLj4MvXOJT1S0qg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ75lBAAoJEC88hzaAX42ixtEIALmB2kpn9VaPLNH3XVc/eYcz chGnveu30/gI7krTlS69spBGQFFOVXxyKUysZzbKYSFLXVJWFm1X3L7/kXJtQedp GLwkn1+SfbkLlQSHCOpq8FIHk+EglbmbEZSmfVA01bULZ/Af+OiRY4IfAq7grUOh WXaJBWe3au2goja18wq8Gmc3nJT6jC4IpnqAqTAMQYMpnGR5it19NYSwq+yiHkH+ sqpiYfEeljoadujUVV2P2/pNb8t7IxuAwNCN4pOWsmEe14VVAzKoqrxBrgWG6IsH STfmR7V1MkfYOTCFMLJ2OyvsfXrTpeRORLGg5efjw8U4ODqbginF+gTE+5HKdmY= =YauV -----END PGP SIGNATURE----- --nNAqpbxe6mfEEiQ0SULLj4MvXOJT1S0qg-- From nobody Tue Oct 24 12:55:06 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C7B1397F3 for ; Tue, 24 Oct 2017 12:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 4fMOM19kvsy5 for ; Tue, 24 Oct 2017 12:55:01 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A32E13F49A for ; Tue, 24 Oct 2017 12:54:59 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Oct 2017 15:54:51 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Tue, 24 Oct 2017 15:54:57 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9OJsixl015832 for ; Tue, 24 Oct 2017 15:54:44 -0400 CC: "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> From: "David A. Cooper" Message-ID: <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> Date: Tue, 24 Oct 2017 15:54:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:55:05 -0000 Why would these schools settle for a half measure that only allows them to snoop on traffic between their students and servers provide the keys to their Internet traffic to the schools? If a school wants to snoop on its students' traffic, it would do so in a much easier way than using draft-rhrd-tls-tls13-visibility, in the same way that some enterprises today use middleboxes to inspect all outgoing traffic. This browser that students would be required to use would be one that has a CA controlled by the middlebox installed as a trust anchor. Whenever one of the students' clients tries to connect to an external secure site, the middlebox-controlled CA issues a certificate for that site so that the connection can be terminated at the middlebox. The middlebox then establishes a secure connection with the end server, thus setting up the middlebox as a MiTM. There are already middleboxes on the market today that do this. They work for all outgoing connections and don't require any cooperation whatsoever from the outside servers that the clients are trying to connect to, and only expert users would notice the presence of the MiTM. Given that such an effective and simple-to-implement solution is already available today, why would these schools be so anxious to use a complicated-to-implement and largely ineffective solution such as subverting draft-rhrd-tls-tls13-visibility for improper purposes? On 10/24/2017 03:36 PM, Yoav Nir wrote: >> On 24 Oct 2017, at 22:27, Ralph Droms wrote: >> >> >>> On Oct 24, 2017, at 3:23 PM, Salz, Rich wrote: >>> >>> I use an airplane as an example of a “captive†population, substitute any similar group you want. >>> >>> • Yes, any box that sits between the client and the server can drop traffic for whatever reason it wants. Such a box could today drop any traffic that is protected using TLS. >>> >>> True, but that’s not the point. The point is by adding this extension into the clientHello, we are providing middleboxes with another knob to control traffic. I think we want to avoid that. And keep in mind it’s not just HTTP, but *any* TLS-using traffic, such as many VPN’s. It wouldn’t necessarily enable spying, but it could be used to guarantee that all traffic is amenable to spying. >>> >>> As for how would such clients get promulgated? Some simple scenarious include “surf for free on your flight, but use our Chromium-based browser to do so, available for free here.†How many people on the plane would click and download? >> Just to make sure I understand, in this scenario the special-purpose browser could just as easily, today, be a browser with no TLS at all? That is, I don't see why this scenario is specific to the visibility extension. > Think of the children. > > We can’t just let them loose on the Internet, there’s predators out there. So we will snoop on their traffic. To do that, we block all traffic that isn’t snoopable, and we do it at the edge router in schools. All schools in our state are required by law to install a firewall that does this. And we get the mobile operators to do so as well (only for handsets in schools). > > Now either the mobile OS vendors make a browser that works in schools (at least with a setting), or the school recommends a third party browser that works in school. And best of all, this is *more secure* than regular TLS 1.3, because it also protects your children from Internet predators. Think of the children. > > You can’t make a claim like that for an HTTP-only browser, and worse still, it won’t work on much of today’s Internet. > > Yoav From nobody Tue Oct 24 12:58:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6298113F834 for ; Tue, 24 Oct 2017 12:58:19 -0700 (PDT) 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 PI-quFh3UAP5 for ; Tue, 24 Oct 2017 12:58:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9681F13A039 for ; Tue, 24 Oct 2017 12:58:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5FB7ABE2E; Tue, 24 Oct 2017 20:58:16 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aVYxIguYd9l; Tue, 24 Oct 2017 20:58:15 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04D5EBE24; Tue, 24 Oct 2017 20:58:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508875095; bh=Aq66nhLgkQjETfWm6nNIutiZFj4hRIVvbPABLH3H9kQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=1iGv/Jl7QgBPXky45HSyBOL/AoShk5WYDzejYHfNNmFn8l0OqKUWS1GymtrZyDEWm rQih4nsY7SvIHGNAw/BMHUTpAMsnaUtxnW6/c6M/bw7NdPA6lBmeWjA54OVY3pzWGl 7dVHYFwF60wm00liTNXjewkQeGJRoEdtHwUEjSjQ= To: Ted Lemon , Joseph Salowey Cc: "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.com> <5D88D34E-E950-40E9-9483-D65D978D2758@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <242f26d4-7f9d-4e28-afbf-2f57d39f8793@cs.tcd.ie> Date: Tue, 24 Oct 2017 20:58:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i0rB4EuQxAQWlbB3C52elOACioX0DEXg7" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:58:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i0rB4EuQxAQWlbB3C52elOACioX0DEXg7 Content-Type: multipart/mixed; boundary="r1afMW4pPquj8mCdlOBxS4VA4e1gELRXr"; protected-headers="v1" From: Stephen Farrell To: Ted Lemon , Joseph Salowey Cc: "tls@ietf.org" Message-ID: <242f26d4-7f9d-4e28-afbf-2f57d39f8793@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.com> <5D88D34E-E950-40E9-9483-D65D978D2758@akamai.com> In-Reply-To: --r1afMW4pPquj8mCdlOBxS4VA4e1gELRXr Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 24/10/17 20:31, Ted Lemon wrote: > But it's delaying other work, because people who could be doing > useful work in the IETF are engaging on this topic instead. I'm not sure of the extent to which my work in the IETF is useful or not, but it is certainly the case that these repeated proposals have consumed the cycles I have for that work. As both Ted and Ben have said this I know I'm not alone in that, and the volume of mail on the topic alone shows that others are spending valuable time rebutting the ongoing break-TLS show. Whether or not any of us would have contributed to TLS1.3 or DTLS1.3 being done sooner or better instead is another question, but the real linkage to TLS1.3 here is that if any of these bad ideas did achieve more that forcing us to oppose them, and the WG went mad and adopted any of it, then that would surely and fully muck up TLS1.3 and DTLS1.3, both in terms of timing and I believe in terms of utility. (Who'd want a new TLS version that's designed as broken?) S. --r1afMW4pPquj8mCdlOBxS4VA4e1gELRXr-- --i0rB4EuQxAQWlbB3C52elOACioX0DEXg7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ75tWAAoJEC88hzaAX42iO0AH/iBMPaS07fhSfP7BpYasPVPr e/xNdL0V0dxlWpiQCe3aZbRJzuqqL5keUdsYtj4onEEdg5Mm5QNm3WafRuwfIam/ stG1YTGQNYnjBejwAMKP5+fx+huUVmFQwjxDwRFkL2NNGePXG0w6NxnvHCIjQI6i 9bdvSPw2NCl3uJXNYKDx+XVyDaGqizNArF+loQpHcSj+7LtqtSNCEEMsjwpHi2R7 Nj7rwZ4asUuxSb6ZQFyEFP+6gt6lrym/nTlCMqIsL+XTHphGrVqFyLsdZcYNIyTh 0K98d14il+4oZK+gfSENqgEhuH6tana6/1GriHT/1oxQCXpg7viEdHVjhBk2OLQ= =DjOG -----END PGP SIGNATURE----- --i0rB4EuQxAQWlbB3C52elOACioX0DEXg7-- From nobody Tue Oct 24 12:59:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1362813F83B for ; Tue, 24 Oct 2017 12:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZonE4OVArQt6 for ; Tue, 24 Oct 2017 12:59:20 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 A27C113968C for ; Tue, 24 Oct 2017 12:59:19 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id h4so32023605qtk.8 for ; Tue, 24 Oct 2017 12:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9Ss5xs/0vqmhSwAI0nlKxlGIaY2pAoWAQY9vAwhxo48=; b=v7q2KLz4RQPt4yyIJl5WjAI9UMBVrpctxv1VnZURAApnXpIt+nfSsc6V/2ElNWqdLE sRy6FT/YLreJGDMluYxAPkl4VwFGYD2J8om7od1pbuJUnNWC8U7gur252VpJ37mBiskI 87QpBwrjHTBon538LPNFCE1/9CgOAIsvjaJ/V5KI3vr5Xm8BtDkVzjritKe8eFYb/nF9 Qa0MrjIHIKwOi7gimfy008ttS9zoxDHN2d07jsfwl9VG4WmFQuOEmono4Nl6O9gl1auS OqF43YcTrrXXTCr9S7QucsbfodS1GLyStisQPgdsPMswkRjNoUtxpChBbOPcEBuq0zAf dPKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9Ss5xs/0vqmhSwAI0nlKxlGIaY2pAoWAQY9vAwhxo48=; b=Zx5Qe3yclA9gFWK0W1qMloIf4nBKNCkbro+RBRQpeABfpJgrEVaNTV8GKdoGopNuXc IAPzOFubS0Bfiuiy7sUdRDCRY0B9W/tsoGSen6WLYMo0mVsi2O3Ph7VTh01ujLg+sYo5 00QsOsy68XVsrh92NlJGrBshH5ZxhM2aeadZ0Xd8MyqjYUkyg+zA7Pmma9YaC5NurQ9m EOYr9XrNaUZWHKd5n+PXldpeVJ/YrJizhZr0Y65w3oKaGsr589bnQMNblnnAHoUM9n1B z8SH3kNsXNgJgDQKa2VyiQJ4dC9Bht8sBMfLof36dDdQxcwAMiPUnHBwZ6tS1K7eN41p W9qw== X-Gm-Message-State: AMCzsaUtFLzLf674OSkW682Ymt/vf5WvuCtbro9rgpvMTUaBXdEF0qp7 4cYl4VzsIA/PIPtCZbg+g0I8RA== X-Google-Smtp-Source: ABhQp+Q/9rGuFYjDnna29I5O1oEpMYC9fE8kvGi0lPsXglAL8aeaQsKx1H1mRFzYPr5xjuMcdP+Bqg== X-Received: by 10.237.59.198 with SMTP id s6mr27479370qte.281.1508875158831; Tue, 24 Oct 2017 12:59:18 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id s6sm714327qkd.55.2017.10.24.12.59.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:59:18 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B13369A6-9D9D-4299-ADC6-BFE127B25D95" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 24 Oct 2017 15:59:17 -0400 In-Reply-To: <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> Cc: "tls@ietf.org" To: "David A. Cooper" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:59:21 -0000 --Apple-Mail=_B13369A6-9D9D-4299-ADC6-BFE127B25D95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2017, at 3:54 PM, David A. Cooper = wrote: > There are already middleboxes on the market today that do this. They = work for all outgoing connections and don't require any cooperation = whatsoever from the outside servers that the clients are trying to = connect to, and only expert users would notice the presence of the MiTM. They are also quite expensive because they have to generate certs on the = fly. If you look at environments where these are in use, they tend to = be either high-margin, or else low-use. So e.g. you only redirect TLS = connections that you absolutely need to intercept through the box; other = connections are terminated normally. Practically speaking, I don't see = any cash-strapped school spending money on one of these devices. --Apple-Mail=_B13369A6-9D9D-4299-ADC6-BFE127B25D95 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 24, 2017, at 3:54 PM, David A. Cooper <david.cooper@nist.gov> wrote:
There are already middleboxes on the = market today that do this. They work for all outgoing connections and = don't require any cooperation whatsoever from the outside servers that = the clients are trying to connect to, and only expert users would notice = the presence of the MiTM.

They are also quite expensive because they = have to generate certs on the fly.   If you look at environments = where these are in use, they tend to be either high-margin, or else = low-use.   So e.g. you only redirect TLS connections that you = absolutely need to intercept through the box; other connections are = terminated normally.   Practically speaking, I don't see any = cash-strapped school spending money on one of these devices.

= --Apple-Mail=_B13369A6-9D9D-4299-ADC6-BFE127B25D95-- From nobody Tue Oct 24 13:01:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90E91394FB for ; Tue, 24 Oct 2017 13:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-d3FQe-f0Ic for ; Tue, 24 Oct 2017 13:01:33 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D42137C4A for ; Tue, 24 Oct 2017 13:01:33 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id x82so27843880qkb.12 for ; Tue, 24 Oct 2017 13:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/Nr/XbwP1DiYoUqRf4g9VuJIOzFzcCw9yLqGBPZL2es=; b=jKrOQjKzcLIrauIxpOc9nuibG4Wgtmf+j+LqHkxflr8eXHyYfaXZ89B6J0KYgUAusC XZHX+R1wGjUBsfKJIC4KIE5Ragmfw+FZjP7tpU9Z/PRqzaabRUJivwgjo5g0NAAsTYU8 ZmaPu1sNJVNSG4lXcEiAUN5GERqhylWQzj8jgxcIV+aPjCT4PUl7w70VfW4d92fZ8Km8 7dOzQzI8hLkdy84ygxC59P0qRl9reaAelkISTtu8ZIxWkLlCCtwn8r7knBp1mggLOlBM RBDnUOLlBGYUYlNtiT34iHQgXBbRtRiQVOmfuWcpaIMvbYCzdv2IWyeZ3C/R5Gw1ELnl hg4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/Nr/XbwP1DiYoUqRf4g9VuJIOzFzcCw9yLqGBPZL2es=; b=pu1YvzDD2ciuc6GUg++vVnemCRFAuFYK0Q90iag0P6cVvegLp5WjuHoy/DdoYJPbJd W7LsnaEJnQMF5Z7BUR+lcwWfNwqNWlhDdXV1iewes3fkJO8mo3vIiKl6ENRYYBqlgDNo tCzvqTnpaJ7cCvED15gilCOuGdVRUT8Mfb6cEvzcSOx3j/qH6xBjThmyMTj2x98uZyKa n9LTh8DOijCo6vTkj7PLC01mcv/ceMLpVD3AOodgkdm6vYTyyqPr/jSY4PvdV79coB0M i8CxeOGGaNh4NfJfccxlNZ9CHBfLMdTXQ3nlt6WenTfBRiWUAWA+HYqp0bqOzHH0a7Vu tYpQ== X-Gm-Message-State: AMCzsaWUk2tDkRUmQy2b+qPDxk74bK1vTUfMpsTU+uoOBg7j4OqJIL47 xvUbWkGPb8Nj9rlhxEu5NlDnYA== X-Google-Smtp-Source: ABhQp+RZBBfSBj4AY763KeboN+lvZcuHbOH+u0eEOtrBo+njGKLglbx6HL7JkAO0tJHK0q4RfRCVtQ== X-Received: by 10.55.49.143 with SMTP id x137mr24483069qkx.138.1508875292180; Tue, 24 Oct 2017 13:01:32 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id b18sm749919qkj.59.2017.10.24.13.01.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 13:01:31 -0700 (PDT) From: Ted Lemon Message-Id: <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_988D4FB4-C2E9-45A6-BB83-5F97FE6C6E0B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 24 Oct 2017 16:01:30 -0400 In-Reply-To: Cc: "tls@ietf.org" To: "David A. Cooper" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:01:35 -0000 --Apple-Mail=_988D4FB4-C2E9-45A6-BB83-5F97FE6C6E0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2017, at 3:59 PM, Ted Lemon wrote: > On Oct 24, 2017, at 3:54 PM, David A. Cooper > wrote: >> There are already middleboxes on the market today that do this. They = work for all outgoing connections and don't require any cooperation = whatsoever from the outside servers that the clients are trying to = connect to, and only expert users would notice the presence of the MiTM. >=20 > They are also quite expensive because they have to generate certs on = the fly. If you look at environments where these are in use, they tend = to be either high-margin, or else low-use. So e.g. you only redirect = TLS connections that you absolutely need to intercept through the box; = other connections are terminated normally. Practically speaking, I = don't see any cash-strapped school spending money on one of these = devices. BTW, if you find this argument unconvincing, consider why these boxes = aren't being proposed for use as an alternative to = draft-rhrd-tls-tls13-visibility-00. :) --Apple-Mail=_988D4FB4-C2E9-45A6-BB83-5F97FE6C6E0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 24, 2017, at 3:59 PM, Ted Lemon <mellon@fugue.com> = wrote:
On Oct 24, 2017, at 3:54 PM, = David A. Cooper <david.cooper@nist.gov> wrote:
There are already middleboxes on the market today that do = this. They work for all outgoing connections and don't require any = cooperation whatsoever from the outside servers that the clients are = trying to connect to, and only expert users would notice the presence of = the MiTM.

They are also quite expensive because they have to generate certs = on the fly.   If you look at environments where these are in use, = they tend to be either high-margin, or else low-use.   So e.g. you = only redirect TLS connections that you absolutely need to intercept = through the box; other connections are terminated normally.   = Practically speaking, I don't see any cash-strapped school spending = money on one of these devices.

BTW, if you find this argument unconvincing, = consider why these boxes aren't being proposed for use as an alternative = to draft-rhrd-tls-tls13-visibility-00.   :)

= --Apple-Mail=_988D4FB4-C2E9-45A6-BB83-5F97FE6C6E0B-- From nobody Tue Oct 24 13:08:02 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2468313A102 for ; Tue, 24 Oct 2017 13:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mSm_WEcUXmZo for ; Tue, 24 Oct 2017 13:08:00 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C82139938 for ; Tue, 24 Oct 2017 13:07:59 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9OJv2IU016500; Tue, 24 Oct 2017 21:07:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=NLw4T8bwn0wpoxRJ3sxZ61/bns43ictpjFhDftM+E4I=; b=e6ct65iDXAGO3vyuiH+IwKBht63RccPkFMNiCIske+6nRmzkjIdmRW/6OSOctET386Ml Uaf6KiKzqSom4qX3oxrorkKWE4AJ186JDPA3et1zwMBGXJMzUm+VUzUR13SMjjEI3Q/d 1VyTqxHl2aIKksS0IFJI2NUJeAP/RtAQo44ut2s7boqM0k3LBzblL12d/O4R1XG2MHxj 1ZoACwe9YICPweYOaS85CmYJBTySzuVdWzbQkuNj15ZW8V0ovDhLTGqUSDjY3YPUF84n 6jLtmAK1JLi4aKWybMI1iqGqecDOKr7Af03zY6ZHp7dZ2Bz4DUN9zaI7sJzA64BVTOE+ hA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2dqxn6jncn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 21:07:57 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9OK6ldG004362; Tue, 24 Oct 2017 16:07:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dr1jvkvky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 16:07:56 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 16:07:54 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 24 Oct 2017 16:07:53 -0400 From: "Salz, Rich" To: "David A. Cooper" CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAADpIA= Date: Tue, 24 Oct 2017 20:07:53 +0000 Message-ID: <268446A2-8B62-4A3F-B63F-FA63A4C3A94E@akamai.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> In-Reply-To: <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.119] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240275 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240274 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:08:01 -0000 PiAgY29tcGxpY2F0ZWQtdG8taW1wbGVtZW50IGFuZCBsYXJnZWx5IGluZWZmZWN0aXZlIHNvbHV0 aW9uIHN1Y2ggYXMgDQogICAgc3VidmVydGluZyBkcmFmdC1yaHJkLXRscy10bHMxMy12aXNpYmls aXR5IGZvciBpbXByb3BlciBwdXJwb3Nlcz8NCiAgDQpUaGUgcGhyYXNlIOKAnHN1YnZlcnRpbmcg Zm9yIGltcHJvcGVyIHB1cnBvc2Vz4oCdIGlzIGluYWNjdXJhdGUsIGFuZCBwZXJoYXBzIG1pc2xl YWRpbmcuICBXZSB3b3VsZCBiZSBwcm92aWRpbmcgYW5vdGhlciBjbGVhcnRleHQgc2lnbmFsIGFu ZCB3ZSBoYXZlIHRvIGV4cGVjdCB0aGF0IHNvbWVvbmUgd2lsbCB1c2UgaXQ7IGFueXRoaW5nIGVs c2Ugd291bGQgYmUgbmHDr3ZlLiBBbGwgdGhlIGRpc2N1c3Npb25zIGFib3V0IOKAnG9zc2lmaWNh dGlvbuKAnSBpbiB0aGUgcGFzdCB0d28geWVhcnMgc2hvdWxkIG1ha2UgdGhhdCBwYWluZnVsbHkg b2J2aW91cy4NCg0KQXMgZm9yIOKAnGltcHJvcGVyIHB1cnBvc2VzLOKAnSBpdOKAmXMgc29tZXRo aW5nIGVuYWJsZWQgYnkgdGhlIHByb3RvY29sLCBldmVuIGlmIGl04oCZcyBub3Qgd2hhdCB0aGUg cHJvcG9zZXJzIGludGVuZGVkIGl0IGZvci4gIEJ1dCBpc27igJl0IHRoZSB3aG9sZSBzdG9yeSBv ZiB0aGUgSW50ZXJuZXQ/IElmIHRoZSBwdXJwb3NlcyBhcmUgcmVhbGx5IGltcHJvcGVyLCBkZWZp bmUgdGhpbmdzIGluIGEgd2F5IHRoYXQgaXQgY2FuIG9ubHkgYmUgdXNlZCBwcm9wZXJseSwgZm9y IHdoYXRldmVyIHRoYXQgZGVmaW5pdGlvbiBpcy4NCg0KU28gZmFyLCB3ZeKAmXZlIHNlZW4gdGhh dCBpdCBjYW4gYmUgdXNlZCB0byBzZWdyZWdhdGUgY2xpZW50cywgb3BlbiB0aGVtIHVwIHRvIHN0 cmVhbSBtb2RpZmljYXRpb24sIGFuZCB0aGUgb25seSBqdXN0aWZpY2F0aW9uIGhhcyBiZWVuIHRo YXQgdGhpcyBpcyBwZXJjZWl2ZWQgZWFzaWVyIHRvIGtlZXAgdmlzaWJpbGl0eSBhcyBjdXJyZW50 bHkgYnVpbHQgYnkgc2hhcmluZyBzdGF0aWMgUlNBIGtleXMuDQoNCkRvIEkgaGF2ZSB0aGF0IHJp Z2h0Pw0KDQo= From nobody Tue Oct 24 13:21:51 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737D113F7F3 for ; Tue, 24 Oct 2017 13:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, MISSING_HEADERS=1.021, 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 AdXKtQqf8Zyq for ; Tue, 24 Oct 2017 13:21:46 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7061394F2 for ; Tue, 24 Oct 2017 13:21:45 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Oct 2017 16:21:38 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Tue, 24 Oct 2017 16:21:44 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9OKLWxT018193 for ; Tue, 24 Oct 2017 16:21:32 -0400 CC: "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> From: "David A. Cooper" Message-ID: Date: Tue, 24 Oct 2017 16:21:39 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> Content-Type: text/html; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:21:49 -0000
I'm not suggesting that cash strapped schools would use one of these devices. I'm simply saying that such a solution would be simpler and far more effective than trying to use draft-rhrd-tls-tls13-visibility to snoop on outgoing traffic.

Those who are suggesting draft-rhrd-tls-tls13-visibility could be used to snoop on outgoing traffic are imagining a scenario in which the school (or other snooper) would make arrangements with each TLS-protected server that they would allow their clients to connect to receive copies of the keys that would be needed to decrypt the traffic. How effective would that be? How expensive would that be?

Besides, the scenario I described previously is just one possibility (although perhaps the easiest to implement). The software that the middlebox requires clients to use could just send the traffic in plaintext to the middlebox while falsely indicating to the client that the connection is secure. Plainly, if the attacker developed the software that the client is running, then there is no protection from the attacker.

On 10/24/2017 04:01 PM, Ted Lemon wrote:
On Oct 24, 2017, at 3:59 PM, Ted Lemon <mellon@fugue.com> wrote:
On Oct 24, 2017, at 3:54 PM, David A. Cooper <david.cooper@nist.gov> wrote:
There are already middleboxes on the market today that do this. They work for all outgoing connections and don't require any cooperation whatsoever from the outside servers that the clients are trying to connect to, and only expert users would notice the presence of the MiTM.

They are also quite expensive because they have to generate certs on the fly.   If you look at environments where these are in use, they tend to be either high-margin, or else low-use.   So e.g. you only redirect TLS connections that you absolutely need to intercept through the box; other connections are terminated normally.   Practically speaking, I don't see any cash-strapped school spending money on one of these devices.

BTW, if you find this argument unconvincing, consider why these boxes aren't being proposed for use as an alternative to draft-rhrd-tls-tls13-visibility-00.   :)


From nobody Tue Oct 24 13:24:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1897139938 for ; Tue, 24 Oct 2017 13:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThKLf7cpJFVn for ; Tue, 24 Oct 2017 13:24:23 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5838D1394F2 for ; Tue, 24 Oct 2017 13:24:23 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id n61so32084879qte.10 for ; Tue, 24 Oct 2017 13:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sIwfsVuJZTvYSFjDd987q/rA/hI+FcLerEFbAXs8tnQ=; b=pYI9wiOymI/Mumj/59Fk9EobD5qk80FXQAYBvRLIbA/zmjG/guCBhBMAsXoI7BflE/ 1tFdvnkAw+l9IhnXjD9kU+dndSStAcw/IUSkHVb8Ert3mpCmI4LvRXIlDWUrpyYgrZbJ aUFJm5bND6HN1oEAmkvlxifZ4zrMYCGnFWbywzJAaef458jE/1vt+n+P69kVuOXdd6f1 RISZxjyMraD9LHZJMMIrjD505YmsiXOJQHHLb8D3/w2e0ydHYOsYDzyir8Uc2ThkIPoU GsPy/c0qJE4q1q6QwIGrzLa7FdxmgJGkIFed22pav7TPeklBLooUsjcxLx+CDI0Mk3wV c8dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sIwfsVuJZTvYSFjDd987q/rA/hI+FcLerEFbAXs8tnQ=; b=OfvsRd3yDs7sjHuxhoXBhroJmmahtKIXob9fUb0DQYB5IUn6E1O1SdkWLaeIQEJXMG XUJ6zQwsEQgxD5uH7fAOOjsRoiTt8zsOKjK6z5VZFdrzQjdp3gjBfS05g+YXAWRii+F0 ckgESCSs4JoFZoV4i1XWkclfuY0JEiPJIZfutqx+NN7TkryDg026t1rJrpgr8EeBLc7U 9wHDHBknBqSm225nmpwqci4TZ1vrCzTGdw/KZxM8JYlJfrpk4La5oxHU5zNJTTNMhhAR 6G0WXtnk0M1KYOSPxlgWejkquZBIO1qF/toWoYNJjHkW6rP+A8C/AVfhrY151BGTk5KN 3jqA== X-Gm-Message-State: AMCzsaWXBhxo1xNJHYumC0uV5hRjtsAJjL6AWbJszzs+95ARBAuLKN4p Ykxd76ao++bDhFSZBcuFY7IJ5P/1JHQ= X-Google-Smtp-Source: ABhQp+QWw2cKenqSuNOeqP6erh41yBIoYjEJE1+0vHW659yeuDA+vVU8xTSKDUMsJtQ1OHsX1/Wj6w== X-Received: by 10.200.36.50 with SMTP id c47mr27507469qtc.274.1508876662474; Tue, 24 Oct 2017 13:24:22 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id c8sm753234qkg.4.2017.10.24.13.24.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 13:24:21 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A62C5623-54B2-4D3B-8246-9ADE55C5EAE4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 24 Oct 2017 16:24:20 -0400 In-Reply-To: Cc: "tls@ietf.org" To: "David A. Cooper" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:24:26 -0000 --Apple-Mail=_A62C5623-54B2-4D3B-8246-9ADE55C5EAE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2017, at 4:21 PM, David A. Cooper = wrote: > I'm not suggesting that cash strapped schools would use one of these = devices. I'm simply saying that such a solution would be simpler and far = more effective than trying to use draft-rhrd-tls-tls13-visibility to = snoop on outgoing traffic. Again, if that were true, then it would also be true that these devices = would nicely solve the problem that draft-rhrd-tls-tls13-visibility = solves. --Apple-Mail=_A62C5623-54B2-4D3B-8246-9ADE55C5EAE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 24, 2017, at 4:21 PM, David A. Cooper <david.cooper@nist.gov> wrote:
I'm not suggesting that cash strapped schools would use one = of these devices. I'm simply saying that such a solution would be = simpler and far more effective than trying to use = draft-rhrd-tls-tls13-visibility to snoop on outgoing traffic.

Again, = if that were true, then it would also be true that these devices would = nicely solve the problem that draft-rhrd-tls-tls13-visibility = solves.

= --Apple-Mail=_A62C5623-54B2-4D3B-8246-9ADE55C5EAE4-- From nobody Tue Oct 24 13:38:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDAE1393AF for ; Tue, 24 Oct 2017 13:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiYnoZRt8om9 for ; Tue, 24 Oct 2017 13:38:25 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 74A341390EE for ; Tue, 24 Oct 2017 13:38:25 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y39so21959686wrd.4 for ; Tue, 24 Oct 2017 13:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ju1hyBCneDji1w0NBil1mXtniRCO3YGrcO0MkGL53fI=; b=W8Al1efrtPgpMS4KgXxVh2nYnlU2SijVVWJf+dOj3nEujOeKq3dnpy8d9St46uuOoI UQhkiqOHKS4soqIksMcBwlztYF/YZfoj0I4kw86iDiAnWoYmEMqjAtSYUqAs5ZXGDWpp 9/HRpS1BUAmRZz0H26aszuYOJqfQoQMJm3m/cIFtNpQWGtWmRTge41GFekU7qp4ycsj5 oFhVKRsVXcAqQNCW+7D1F86X9/XttfrS63Ln7RKncjRPDhullCOjLxG37vrPCyt2A+9U Bo+vAzjg27011yUbLZHWlbPYsc4xzsJS5xJlrBHSUSint2WW8WlW3Yt5slHq70dsjIWK yPUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ju1hyBCneDji1w0NBil1mXtniRCO3YGrcO0MkGL53fI=; b=sDSUIhUVBNAwa3nFiZk7ll/fJP5f5D+HLgfLRm59XOMetRG5xbED8fk2D4FAuwVdxL ymN3LngU6TwNzo1bkBeiPVkzxBCgYRXTA9QbYdvHGUM2P6TvwjyuLy4oh6CiCFPWGisk 5pijUtew1ZqQJUWqK4XwwPHFTVawe9OglMYgI64L7A/le4+BjxCpcNKX6WJwov1GFchC IpY9Ie+Q7vAJndY5qD9hTPENXb1ly1bBmtzN4M/szZ25w9Bs0t+TfuEtrG/ybBCpa94q Vq4y0tm5cOfnVP8Rz6OsIQ+5FfEtO4R9ZVCvxVJr7lCzkgHXmsHTroyX+3reXFxunjWb QMKg== X-Gm-Message-State: AMCzsaXmQ0LoLZuVYqs/R/EZax3TLUmCJzoRZ5k1DoljuuGMCscZ6IYE AFzYVAIUOBGzIY5x7UrEiPljaAnc X-Google-Smtp-Source: ABhQp+Tev+50TGJrczye99qLS5CUqb2hTtdLc9CEIwlY5NMcTbr+SguVweU/NjGDmoNqzplAUpj7zg== X-Received: by 10.223.199.205 with SMTP id y13mr16242375wrg.71.1508877503931; Tue, 24 Oct 2017 13:38:23 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l80sm1212942wmb.2.2017.10.24.13.38.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 13:38:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Yoav Nir In-Reply-To: <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> Date: Tue, 24 Oct 2017 23:38:20 +0300 Cc: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> To: "David A. Cooper" X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:38:27 -0000 > On 24 Oct 2017, at 22:54, David A. Cooper = wrote: >=20 > Why would these schools settle for a half measure that only allows = them to snoop on traffic between their students and servers provide the = keys to their Internet traffic to the schools? If a school wants to = snoop on its students' traffic, it would do so in a much easier way than = using draft-rhrd-tls-tls13-visibility, in the same way that some = enterprises today use middleboxes to inspect all outgoing traffic. Yeah. I used to write such middleboxes. They=E2=80=99re a nightmare to = deploy in all but the most orderly of enterprises. You need to have all = clients trust the middlebox CA. Fine, so the Windows computers get that = installed through SMS or GPO or whatever the central configuration = feature is called these days. The people with Macs have to figure it out = for themselves, and the same goes for people with phones. Oh, and also = for people who use Firefox, because that browser comes with its own = trust store. The people on this list can probably figure it out with a = little web search. A school with a thousand students all bringing their = own devices? Good luck. > This browser that students would be required to use would be one that = has a CA controlled by the middlebox installed as a trust anchor. = Whenever one of the students' clients tries to connect to an external = secure site, the middlebox-controlled CA issues a certificate for that = site so that the connection can be terminated at the middlebox. The = middlebox then establishes a secure connection with the end server, thus = setting up the middlebox as a MiTM. It=E2=80=99s one thing to say that SchoolBrowser (conveniently located = in the app stores of all phone and computer OS-es) works in this school = (and all the others). It=E2=80=99s a totally different thing to fill = the app stores with =E2=80=9CGrizzlyBrowser for Logan High School = students=E2=80=9D and =E2=80=9CMustangBrowser for Mountain Crest High = School students" > There are already middleboxes on the market today that do this. They = work for all outgoing connections and don't require any cooperation = whatsoever from the outside servers that the clients are trying to = connect to, and only expert users would notice the presence of the MiTM. Unless they had to configure their browser themselves. The support = costs of these is tremendous. From nobody Tue Oct 24 13:41:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954731390EE for ; Tue, 24 Oct 2017 13:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, MISSING_HEADERS=1.021, 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 gCr-h5wK6O2j for ; Tue, 24 Oct 2017 13:40:57 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989EA13A102 for ; Tue, 24 Oct 2017 13:40:57 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Oct 2017 16:42:20 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Tue, 24 Oct 2017 16:40:55 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9OKeVvh019578 for ; Tue, 24 Oct 2017 16:40:32 -0400 CC: "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> From: "David A. Cooper" Message-ID: Date: Tue, 24 Oct 2017 16:40:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:40:59 -0000
On 10/24/2017 04:24 PM, Ted Lemon wrote:
On Oct 24, 2017, at 4:21 PM, David A. Cooper <david.cooper@nist.gov> wrote:
I'm not suggesting that cash strapped schools would use one of these devices. I'm simply saying that such a solution would be simpler and far more effective than trying to use draft-rhrd-tls-tls13-visibility to snoop on outgoing traffic.

Again, if that were true, then it would also be true that these devices would nicely solve the problem that draft-rhrd-tls-tls13-visibility solves.

Not at all. Visibility in the data center is a totally different problem than inspecting outgoing traffic. In the data center case the same organization controls the clients, servers, and the authorized listeners. That is very different from a scenario in which the organization that wants to listen in is different from the organizations that control the servers, and in which the organizations that control the servers are unlikely to want to grant this intermediary the ability to listen in on the traffic between it and its clients.

Also, in the data center case, there is no middlebox. Others, who know much more than I do about operational constraints in data center environments, have already argued that setting up a bunch of middleboxes would not be a viable solution.

From nobody Tue Oct 24 13:52:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFBD1390EE for ; Tue, 24 Oct 2017 13:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ippW-AKwWraD for ; Tue, 24 Oct 2017 13:51:57 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278D513A1F3 for ; Tue, 24 Oct 2017 13:51:57 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id w134so28031829qkb.0 for ; Tue, 24 Oct 2017 13:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=42lz685Mj9IMRhB7cag8rOmzekxbw8hk0HQ678229R8=; b=f1oLlmZrmZhti1KtRhn+E5zD7FBeiBf52+caH/DuDpYXSNzQ5pO/dfFUghk1J3CEMj yUD6/1asQmaHb/3I7r0PcTkbfKBtCy3/eApjLvGIgPCBjCXOdNC1EDwV499Q+r+BWThe zTEV9X1RCn6hB5mmYszRn7PuABUWwl4Kc8J/WN0BHxULKSNVYxUF/1e2Lx1M3IFEHqk4 A1DqUcwbYLsmLsjPXX5X9TRahnH81VGVaZNQy049kAos2ygFtFyImZM7mC2hG8S7E+aA UvlRTiUJBWQ8Ej1RLTMipnnHgsfl3YOK7tr2HoKjp4Ql8JNxetKUOWOuvo8Gs7GQpMS+ 4mow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=42lz685Mj9IMRhB7cag8rOmzekxbw8hk0HQ678229R8=; b=hxfmPPUCaBT82F7bWiHTiTxZhZ4uwsXY3jcPqyRR46ezPyQ4NJ/bn/sbDaxRd4xuVE aKTBZjVkjSvKkaQ5vCqFeWdIk8HFAPf98aOvNh2DyzG2JYpCZhe1BVsC37hrmagj468t l5UoSZUM4q5LSDmyRIAjQ4KKlMx8wSsT8MqZclfaCHJjou7rhNnvZ63esy2YSk4r4TqU C4KQHA+tnnapzp8XDJfJ/GT8OQqd2CnleZ2YGnnUe4Lt1WB1eaRdX+Quuc7EHc7KrdhQ pY02AhlLBXr04SLYq2rNRDvUKGHQQqPF8k/oFyHKZYAIEQ0DdH02VK8PrIlABk90nPVz 8pzw== X-Gm-Message-State: AMCzsaWhZIZONmLpex9dWtMSkw4i68ZVoMIGndxcYCyHcCqsXs3nduyh hh3H4mAB6kCMqzNxbzVBgTw= X-Google-Smtp-Source: ABhQp+SFCmAhgTxOQofN1z+8fVuwF+ecqJubeJuyQCipRcCEDw782kC0pWGidCn7GwxfI9lsdI3tmQ== X-Received: by 10.55.15.212 with SMTP id 81mr26416482qkp.262.1508878316187; Tue, 24 Oct 2017 13:51:56 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:c167:7d58:9571:ad31? ([2601:18f:801:600:c167:7d58:9571:ad31]) by smtp.gmail.com with ESMTPSA id d42sm854487qta.60.2017.10.24.13.51.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 13:51:55 -0700 (PDT) From: Ralph Droms Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_68F82366-BF24-440D-9C3D-7BFC90AAFCC4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 24 Oct 2017 16:51:55 -0400 In-Reply-To: Cc: "David A. Cooper" , "tls@ietf.org" To: Ted Lemon References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:51:59 -0000 --Apple-Mail=_68F82366-BF24-440D-9C3D-7BFC90AAFCC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 24, 2017, at 4:24 PM, Ted Lemon wrote: >=20 > On Oct 24, 2017, at 4:21 PM, David A. Cooper > wrote: >> I'm not suggesting that cash strapped schools would use one of these = devices. I'm simply saying that such a solution would be simpler and far = more effective than trying to use draft-rhrd-tls-tls13-visibility to = snoop on outgoing traffic. >=20 > Again, if that were true, then it would also be true that these = devices would nicely solve the problem that = draft-rhrd-tls-tls13-visibility solves. I think your suggestion is addressed as one of the alternative solutions = in draft-rhrd-tls-tls13-visibility. Enterprise network operators say = that deploying these devices to provide the same visibility as the = visibility extension would, at best, be highly complicated and = expensive, if not altogether impossible. - Ralph --Apple-Mail=_68F82366-BF24-440D-9C3D-7BFC90AAFCC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 24, 2017, at 4:24 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Oct 24, = 2017, at 4:21 PM, David A. Cooper <david.cooper@nist.gov> wrote:
I'm not suggesting that cash strapped schools would use one = of these devices. I'm simply saying that such a solution would be = simpler and far more effective than trying to use = draft-rhrd-tls-tls13-visibility to snoop on outgoing traffic.

Again, = if that were true, then it would also be true that these devices would = nicely solve the problem that draft-rhrd-tls-tls13-visibility = solves.

I = think your suggestion is addressed as one of the alternative solutions = in draft-rhrd-tls-tls13-visibility.  Enterprise network = operators say that deploying these devices to provide the same = visibility as the visibility extension would, at best, be highly = complicated and expensive, if not altogether impossible.

- Ralph

= --Apple-Mail=_68F82366-BF24-440D-9C3D-7BFC90AAFCC4-- From nobody Tue Oct 24 13:52:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E021394F2 for ; Tue, 24 Oct 2017 13:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy97iApDiFiR for ; Tue, 24 Oct 2017 13:52:13 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 655F313F847 for ; Tue, 24 Oct 2017 13:52:11 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id x7so20549516pfa.1 for ; Tue, 24 Oct 2017 13:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uymaoYjw/1L1PKO0jRIMfHNoGljwZBxFJjim77slsc8=; b=K3VESr2sjBU4pdkNtDpO0efKdZxEOXyXA+1O2RX3eMd5wKn2XfZmv+vKl/4WSHm2o9 ZW70Cfuh2KCvokjzvlaT8K0JYvg1/VIRg6ErCdnWwFwqs0XxNXrae91ej0ZhgayPs+2u bJbf9rGf48Fp3pHmXtlZAUqYsQKF94AbyJRLzxpjtqQkGvfYH4WMsoQlNYkiLLwzNZe/ QF6ROWO662K/3MfgClIQMYZDoSiRB+QmhN5bfT3zJTbOCr0m3BReK/+U2PEWgASSxwTT yyoBV3Ol32CHgBa27/5eqv/dx/sFnlLho3bEjJonldrPqjf4PaE92lwRnIvBIsGtFUu/ 2sqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uymaoYjw/1L1PKO0jRIMfHNoGljwZBxFJjim77slsc8=; b=DRePHePtBuBv5mfUWEkRsY4RHhNV8lZ9Ut7vEAWnvx6RwTrTwDXXcWnQoGeAVxhCqW U2yHhXAP16Ck3jdUXgCCJB02bhshY/o60MfYPezF40zAxweWfPDV5jx6Ox6CCOpFk6lj 3+vNJgaofHSCC7XYMc86PS4udawxwVIMZAbISvblvh7nkFBMsx1nj+8idMXMDqkdXNmn w/9vg5pmBVt+RWXvglgSACe7JfTs0/smpSJ6+0PPPcf/rZh9Z6DZWVSzR39SSKX9rZHs LZ0GvFaDfWUuoEAkPuvdCIrZRhmDpe1MYvgIBSPaI8DXahU1n2HCmpaJWmWHa1LjL8Pv iyDw== X-Gm-Message-State: AMCzsaUwxQuwCs10rGSvEtsrLiJ6OmSkEmHhdCIxRoHO9mMdgvvxm9Yl 2NmIEM0lQoMqzwfN8HTUQMifo+cALSCX0189hj8= X-Google-Smtp-Source: ABhQp+QdDNsC/yuBlzOaqYpZqcp7RvXyEUi1wX6JOCKSWaX+orOplqBLHr8v1lelozuDwo0j4vsTBt9sUrUXWm6dUZU= X-Received: by 10.101.91.193 with SMTP id o1mr15472180pgr.75.1508878331003; Tue, 24 Oct 2017 13:52:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Tue, 24 Oct 2017 13:51:30 -0700 (PDT) In-Reply-To: References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> From: Kathleen Moriarty Date: Tue, 24 Oct 2017 16:51:30 -0400 Message-ID: To: Ted Lemon Cc: "David A. Cooper" , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:52:15 -0000 On Tue, Oct 24, 2017 at 4:24 PM, Ted Lemon wrote: > On Oct 24, 2017, at 4:21 PM, David A. Cooper wrote: > > I'm not suggesting that cash strapped schools would use one of these > devices. I'm simply saying that such a solution would be simpler and far > more effective than trying to use draft-rhrd-tls-tls13-visibility to snoop > on outgoing traffic. > > > Again, if that were true, then it would also be true that these devices > would nicely solve the problem that draft-rhrd-tls-tls13-visibility solves. These are two different problems and although you could use a proxy solution inside a datacenter, it doesn't scale or make sense. IMO, David countered Yoav's clever scenario very well. Now, the proponents are asking for alternatives to consider and a serious look at their proposal. Can we look at this request constructively and provide a cohesive set of alternate solutions? IPsec [1] might be possible, but requires a change in tooling for intercepting traffic. In hosted environments, it also could change who is managing the encryption (TCP/application vs. IP layer). I also received a comment that you could also tie in use of IPv6 and label sessions with the IPsec approach and that makes sense. What about the experimental drafts in TCPInc? [2] This provides opportunistically encrypted TCP, so you could MiTM it. Are there other alternate solutions that have been discussed or should be? Maybe it would be helpful to list them out for comparison and evaluation by those interested - not on list as that's off-topic. [1] https://www.rsa.com/en-us/blog/2017-08/tls-security-and-data-center-monitoring-searching-for-a-path-forward [2] https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/?include_text=1 Thanks, Kathleen > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen From nobody Tue Oct 24 14:10:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792A113F84E for ; Tue, 24 Oct 2017 14:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 2T-z8ol8VUpO for ; Tue, 24 Oct 2017 14:10:22 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291BC13F847 for ; Tue, 24 Oct 2017 14:10:22 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Oct 2017 17:10:14 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Tue, 24 Oct 2017 17:09:59 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9OL9kZ4022084 for ; Tue, 24 Oct 2017 17:09:46 -0400 To: "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> From: "David A. Cooper" Message-ID: <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> Date: Tue, 24 Oct 2017 17:09:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:10:24 -0000
As difficult as what you describe below would be, using draft-rhrd-tls-tls13-visibility to snoop would be much more complicated. They would need to need to get their "special" browsers onto all of the students' devices, but then, unlike in the scenario below, that would only be the beginning of what they need to do. They would need to active cooperation of every TLS-protected server that the students could connect to and they would need an infrastructure for obtaining and managing all of the keys that they would be getting from all of these servers. [In practice, of course, there wouldn't be that many keys since practically no servers would cooperate in this scheme.]

So, yes, setting up a scheme to snoop on all outgoing TLS-protected traffic would not be easy. However, draft-rhrd-tls-tls13-visibility would not make it easier than it currently is, as implementing something based on draft-rhrd-tls-tls13-visibility would be far more difficult than using currently available methods.

And, I don't buy the idea that if this extension is standardized that it will be implemented in commonly-used browsers. We don't have to "keep all the plates spinning" in order to prevent this extension from "escaping" on to the public Internet. This isn't something that could "accidentally" be implemented in browsers if browser vendors don't take extreme precautions to prevent it from happening. Browser vendors would have to pro-actively decide to implement this, and I don't see that happening. The idea that someone would set up a service that would only work if browsers implemented this extension, and then browsers would be "forced" to implement the extension so that this service would work isn't realistic.

A server that wanted to allow third party interception of traffic between itself and its clients wouldn't require this extension and then wait for browsers to implement the extension. It would just use TLSv1.2 with RSA key exchange (or something like draft-green-tls-static-dh-in-tls13), and then set up the interception capability without the client's knowledge.

On 10/24/2017 04:38 PM, Yoav Nir wrote:
On 24 Oct 2017, at 22:54, David A. Cooper <david.cooper@nist.gov> wrote:

Why would these schools settle for a half measure that only allows them to snoop on traffic between their students and servers provide the keys to their Internet traffic to the schools? If a school wants to snoop on its students' traffic, it would do so in a much easier way than using draft-rhrd-tls-tls13-visibility, in the same way that some enterprises today use middleboxes to inspect all outgoing traffic.

Yeah. I used to write such middleboxes. They’re a nightmare to deploy in all but the most orderly of enterprises. You need to have all clients trust the middlebox CA. Fine, so the Windows computers get that installed through SMS or GPO or whatever the central configuration feature is called these days. The people with Macs have to figure it out for themselves, and the same goes for people with phones. Oh, and also for people who use Firefox, because that browser comes with its own trust store. The people on this list can probably figure it out with a little web search. A school with a thousand students all bringing their own devices? Good luck.


This browser that students would be required to use would be one that has a CA controlled by the middlebox installed as a trust anchor. Whenever one of the students' clients tries to connect to an external secure site, the middlebox-controlled CA issues a certificate for that site so that the connection can be terminated at the middlebox. The middlebox then establishes a secure connection with the end server, thus setting up the middlebox as a MiTM.

It’s one thing to say that SchoolBrowser (conveniently located in the app stores of all phone and computer OS-es) works in this school (and all the others).  It’s a totally different thing to fill the app stores with “GrizzlyBrowser for Logan High School students†and “MustangBrowser for Mountain Crest High School students"


There are already middleboxes on the market today that do this. They work for all outgoing connections and don't require any cooperation whatsoever from the outside servers that the clients are trying to connect to, and only expert users would notice the presence of the MiTM.

Unless they had to configure their browser themselves.  The support costs of these is tremendous.


From nobody Tue Oct 24 14:18:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C7F13F856 for ; Tue, 24 Oct 2017 14:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7NsLho4YwuMT for ; Tue, 24 Oct 2017 14:18:11 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B7313F853 for ; Tue, 24 Oct 2017 14:18:11 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9OLHZmp023415; Tue, 24 Oct 2017 22:18:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=gDEik8V/upW/uthi3whQ3LwQLHi/rmymqLq7w4Zhn/A=; b=oTbBII4cYoErTSzODra6PsJrhIsg9bty4bESYho3v2Lh7JKqVMdcyT8iemYo+VDte0AS bLP8gvc5V1ea4d9Tp/eHYvKaBdOlq8YOs0zQTBhA9ack0rsjmRXkNnBiSBBd7ZDFRT75 k4kAi5kl0cktXGv47i+6I2Rk3EhdSgA43vGX/qrfQYfUM32475Brawy+l5bS9wldYt/Y sA+FISvUaoxna3iTvI0/kJmKNaqi2sf9ZuBdmJUwIGHkigETD/6aAyWj7mCguGIJs7XR OtsPz+q+QYVQnMLzCeRboEf/8FAOsBNvYvZ8haunxOEx6v3k32zlXnn03bWPGiwPCq4H bA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2dqwg4tw19-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 22:18:08 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9OLGZF5003167; Tue, 24 Oct 2017 17:18:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dr1juj6tm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 17:18:07 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 17:18:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 24 Oct 2017 17:18:06 -0400 From: "Salz, Rich" To: "David A. Cooper" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjQAIAAAkoA Date: Tue, 24 Oct 2017 21:18:05 +0000 Message-ID: <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> In-Reply-To: <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.119] Content-Type: multipart/alternative; boundary="_000_7426592882524CA1B6A445296F74637Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240290 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240290 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:18:12 -0000 --_000_7426592882524CA1B6A445296F74637Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIEFuZCwgSSBkb24ndCBidXkgdGhlIGlkZWEgdGhhdCBpZiB0aGlzIGV4dGVuc2lv biBpcyBzdGFuZGFyZGl6ZWQgdGhhdCBpdCB3aWxsIGJlIGltcGxlbWVudGVkIGluIGNvbW1vbmx5 LXVzZWQgYnJvd3NlcnMuDQoNCkFuZCB0aGF0IGlzIGEgcmlzayB5b3UgYXJlIHdpbGxpbmcgZm9y IHRoZSBlbnRpcmUgcHVibGljIEludGVybmV0IHRvIHRha2U/DQoNCkFuZCB3aGF0IGFib3V0IHRo ZSBmYWN0IHRoYXQgaXQgcHJvdmlkZXMgYSBjbGVhcnRleHQgc2lnbmFsIGFzIHRvIHdoZXRoZXIg b3Igbm90IGEgY2xpZW50IGlzIHdpbGxpbmcgdG8gbGV0IGl0c2VsZiBiZSBNaVRN4oCZZCwgZG9l cyB0aGF0IGJvdGhlciB5b3U/DQoNCg== --_000_7426592882524CA1B6A445296F74637Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1ED50928D82E954D83202CDE0F615C9D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb3VyaWVyO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5t c29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE5MzY2 NzAxMDc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x NjU4MTI2NjE0IC0xNDEzNTk4NTUyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6 Ym9sZDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjx1bCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5BbmQs IEkgZG9uJ3QgYnV5IHRoZSBpZGVhIHRoYXQgaWYgdGhpcyBleHRlbnNpb24gaXMgc3RhbmRhcmRp emVkIHRoYXQgaXQgd2lsbCBiZSBpbXBsZW1lbnRlZCBpbiBjb21tb25seS11c2VkIGJyb3dzZXJz LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgdGhhdCBpcyBhIHJpc2sgeW91IGFy ZSB3aWxsaW5nIGZvciB0aGUgZW50aXJlIHB1YmxpYyBJbnRlcm5ldCB0byB0YWtlPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbmQgd2hhdCBhYm91dCB0aGUgZmFjdCB0aGF0IGl0IHByb3ZpZGVz IGEgY2xlYXJ0ZXh0IHNpZ25hbCBhcyB0byB3aGV0aGVyIG9yIG5vdCBhIGNsaWVudCBpcyB3aWxs aW5nIHRvIGxldCBpdHNlbGYgYmUgTWlUTeKAmWQsIGRvZXMgdGhhdCBib3RoZXIgeW91PzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7426592882524CA1B6A445296F74637Bakamaicom_-- From nobody Tue Oct 24 14:26:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD5C138467; Tue, 24 Oct 2017 14:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CAobuSryUlXu; Tue, 24 Oct 2017 14:26:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4828C13A292; Tue, 24 Oct 2017 14:26:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 52BEF200F1; Tue, 24 Oct 2017 17:27:10 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 40C7D81DB3; Tue, 24 Oct 2017 17:26:43 -0400 (EDT) From: Michael Richardson To: tls@ietf.org cc: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [TLS] sending full certificate chains in ClientCertificate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:26:46 -0000 --=-=-= Content-Type: text/plain In ANIMA's BRSKI enrollment protocol we use TLS to communicate across realms. ( https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > We are connecting the (prospective) device owner's realm (the Registrar) to the manufacturer's realm (the MASA). The MASA's certificate is either a webpki, or has been provided to the Registrar via some supplier agreement. In the other direction, we specify using a client certificate, and since are going cross-realm, we want to specify that the entire chain (including the trust anchor) be transmitted. We need the entire chain as we want to pin the device ownership while also permitting the Registrar's certificate to be rolled over time. In the browser space there has been pushback against including the trust anchors in the Server->Browser direction, including Google's Chrome browser complaining about unnecessary certificates, and TLS scanners. I understand that some of this is the result of some client libraries that could be confused (due to bugs) into validating a bogus chain if there was a self-signed certificate in the certificates sent from the server. What's unclear to me if there is any kind of specification that we would be violating if we state that we want the full chain in the Client's Certificate extension. Section 4.4.2 of draft-ietf-tls-tls13-21 says: a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. and there is a note about versions prior to 1.3 that the ordering wasn't always respected, but that some implementations accepted it anyway. In our document we simply want to say that the trust anchor MUST be included (MUST NOT be omitted...) which as far as I can see, is permited by tls1.3. Is there something I'm missing that would prevent us from doing this? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnvsBIACgkQgItw+93Q 3WXkkgf/auDKN2G1euhq/cy+QjNjoW/FntHRiqNsuFDQ0+/azJ9zAZN4bfsC5/TS TgXQMMfyPfQJw4Mixt1FVi9kgwQiGvnwVDncnpMGuVZ51IDSrzlqN9/qpKM/epPr ewwDf0qIdlyejD1eC8X2ukLhmcjRyMNsAUKROh9KvAKk3TKLHDCkcyfGJreJNIIa oGZb8KkkTC/7yRm6KIKA5KxIjAPn9k9TNEW/43e4BaUCmN9JvPq1DDPbUc4zTMwY MOj+k8tE+leL+lJ+qwsGhDYQY/aYHu7bVTUA65+xXcrcJ79qtvkyZyz5wH9AOJXx MtUlvnSntyeuGVnJ4hrSigMn9z1DTw== =zCW/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 24 14:29:17 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4BE13A5D2 for ; Tue, 24 Oct 2017 14:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vHZxzlhnpJm3 for ; Tue, 24 Oct 2017 14:29:13 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A505D138467 for ; Tue, 24 Oct 2017 14:29:13 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9OLRSvd014323; Tue, 24 Oct 2017 22:28:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=IeL83Q6/ajbgI5qeG54RCfq7OjbAT5I/NVVMRtAqDgM=; b=ZN72dJoWIV/XUBlf8dmD8CrnYD6nNG0PRMZvnaM0liprxyWWH/sR4C5mtONEn7qwZhWt UG67tqKJfUrmK06UAyoPEu3zrbk6+Lj/Cs+yvulcLqnFdu5PEFJIMHSzIRZOTJLcIIXG U7zoo2ep7crfKdg4sKG5H3RYouwXTM6besgLYPIDkhGSktBsX8KfdZXB46S5KWrOXdvR yF8S+8pRWmKAENltmwYh0HP+rNKZUFxleuaucnh5VMLdEx5R/iZE6rR6/5MiLr8Dsrkl wPvNTlroelARVPfiLoFgsdYHHyuW6alVRvaW68s8zq7pewifl+Uc0aGbA47P/ipql/3p og== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2dqwgkumn7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 22:28:57 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9OLPhML004456; Tue, 24 Oct 2017 17:28:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dr1jvm3yr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 17:28:56 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 17:28:54 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 24 Oct 2017 17:28:55 -0400 From: "Salz, Rich" To: Ralph Droms CC: "David A. Cooper" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAABPYCAAACfAIAABaGAgAAAwACAAAe1gIAAClSA Date: Tue, 24 Oct 2017 21:28:54 +0000 Message-ID: <9C46A5C1-27B8-45C0-A8E5-AA713597C7A9@akamai.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.119] Content-Type: multipart/alternative; boundary="_000_9C46A5C127B845C0A8E5AA713597C7A9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240292 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240293 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:29:15 -0000 --_000_9C46A5C127B845C0A8E5AA713597C7A9akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAgRW50ZXJwcmlzZSBuZXR3b3JrIG9wZXJhdG9ycyBzYXkgdGhhdCBkZXBsb3lpbmcgdGhlc2Ug ZGV2aWNlcyB0byBwcm92aWRlIHRoZSBzYW1lIHZpc2liaWxpdHkgYXMgdGhlIHZpc2liaWxpdHkg ZXh0ZW5zaW9uIHdvdWxkLCBhdCBiZXN0LCBiZSBoaWdobHkgY29tcGxpY2F0ZWQgYW5kIGV4cGVu c2l2ZSwgaWYgbm90IGFsdG9nZXRoZXIgaW1wb3NzaWJsZS4NCg0KQmFzZWQgb24gdGhlIGNvbnRh Y3RzIHlvdeKAmXZlIGhhZCwgd2hhdOKAmXMgdGhlaXIgY29zdCBlc3RpbWF0ZSBmb3IgbW9kaWZ5 aW5nIHRoZSBzZXJ2ZXJzIGFuZCBtb25pdG9yaW5nIGluZnJhc3RydWN0dXJlPyAgWmVybz8gIFRo b3VzYW5kcyBwZXIgZGV2aWNlPyAgQmFzZWQgb24gIHRoZSBjb250YWN0cyB5b3XigJl2ZSBoYWQs IGhvdyBkb2VzIHRoZSBjb3N0IG9mIG1vZGlmaWNhdGlvbnMgdG8gc3VwcG9ydCAqdGhpcyogZHJh ZnQsIGNvbXBhcmUgdG8gdGhlIGNvc3Qgb2YgbW9kaWZ5aW5nIHRoZSBzZXJ2ZXIgYW5kIG1vbml0 b3JpbmcgaW5mcmFzdHJ1Y3R1cmUgdG8gcmVwb3J0IGFuZCB1c2UgbmVnb3RpYXRpb24gUEZTIHNl c3Npb24ga2V5cz8NCg0KQW5kIGhleSwgeW914oCZcmUgYW4gYXV0aG9yLiAgRG9lcyB5b3VyIGRy YWZ0IGFsbG93IGFuIGludGVybWVkaWF0ZSBzdWNoIGFzIGEgZmlyZXdhbGwgdG8gbW9kaWZ5IHRo ZSB0cmFmZmljIHRoYXQgcGFzc2VzIHRocm91Z2g/DQo= --_000_9C46A5C127B845C0A8E5AA713597C7A9akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <9E1E5831307E71418F4D26B24E86EE08@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0Ozwvc3Bhbj48L2I+ICZuYnNwO0VudGVycHJpc2UgbmV0 d29yayBvcGVyYXRvcnMgc2F5IHRoYXQgZGVwbG95aW5nIHRoZXNlIGRldmljZXMgdG8gcHJvdmlk ZSB0aGUgc2FtZSB2aXNpYmlsaXR5IGFzIHRoZSB2aXNpYmlsaXR5IGV4dGVuc2lvbiB3b3VsZCwg YXQgYmVzdCwgYmUgaGlnaGx5IGNvbXBsaWNhdGVkIGFuZCBleHBlbnNpdmUsIGlmDQogbm90IGFs dG9nZXRoZXIgaW1wb3NzaWJsZS4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYXNl ZCBvbiB0aGUgY29udGFjdHMgeW914oCZdmUgaGFkLCB3aGF04oCZcyB0aGVpciBjb3N0IGVzdGlt YXRlIGZvciBtb2RpZnlpbmcgdGhlIHNlcnZlcnMgYW5kIG1vbml0b3JpbmcgaW5mcmFzdHJ1Y3R1 cmU/Jm5ic3A7IFplcm8/Jm5ic3A7IFRob3VzYW5kcyBwZXIgZGV2aWNlPyZuYnNwOyBCYXNlZCBv biZuYnNwOyB0aGUgY29udGFjdHMgeW914oCZdmUgaGFkLCBob3cgZG9lcyB0aGUgY29zdCBvZiBt b2RpZmljYXRpb25zIHRvIHN1cHBvcnQgKjxiPnRoaXM8L2I+Kg0KIGRyYWZ0LCBjb21wYXJlIHRv IHRoZSBjb3N0IG9mIG1vZGlmeWluZyB0aGUgc2VydmVyIGFuZCBtb25pdG9yaW5nIGluZnJhc3Ry dWN0dXJlIHRvIHJlcG9ydCBhbmQgdXNlIG5lZ290aWF0aW9uIFBGUyBzZXNzaW9uIGtleXM/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBoZXksIHlvdeKAmXJlIGFuIGF1dGhvci4mbmJzcDsg RG9lcyB5b3VyIGRyYWZ0IGFsbG93IGFuIGludGVybWVkaWF0ZSBzdWNoIGFzIGEgZmlyZXdhbGwg dG8gbW9kaWZ5IHRoZSB0cmFmZmljIHRoYXQgcGFzc2VzIHRocm91Z2g/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9C46A5C127B845C0A8E5AA713597C7A9akamaicom_-- From nobody Tue Oct 24 14:41:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4C813F86C for ; Tue, 24 Oct 2017 14:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGZyXjGzJNka for ; Tue, 24 Oct 2017 14:40:57 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C52B13F865 for ; Tue, 24 Oct 2017 14:40:57 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id c202so39806276oih.9 for ; Tue, 24 Oct 2017 14:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=se+20zQ1510N1TTjA5jP1MuRSbsgAxnN2w0eMiICZXo=; b=Rn/XQVVDlBcChDY0WnTeSV8Gi9bHs0noOI+qeidJ7Qb0XoCD3oT6awk6DWuUw0oCgN aApbwdUbpVh+zXJXPZEbyVl9AZmAfnXmSeecof4VlIWWoJ19PLdVt6OQ1tPg6ZshHs6g PEUeqZaJx/Hx+kznUNk37rUczVkuQHOH1vJj3gLzXYURERKfpZ1IZfQXxcOivLAXtG3f vAIAoB0BwgpPMOleWhIF70vpVkTB2Kkiq6uEayc3KGl6okUX3os8OiJApxZ7ffhafpjS Vg3kqPeIv5SV7TMwv7OkemqDFyMfMveEUNQ9AP7ONEToLzhjuYX6uUV+8lfjRf9YRYVi 1gTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=se+20zQ1510N1TTjA5jP1MuRSbsgAxnN2w0eMiICZXo=; b=QoCAoQwYBprWUtl4R8uZtT3yd/UISpaxOVqpaFC7BU50gT7MdELu5i46Bh6FuxOcQ/ h+2fgk07q0TBcyCykXwYTcDQZzJ/Voq5Gl1M4E017cA7trWMaB1BJpoJmlVrW0NjVYi9 UXkw712j6QTCthFXR9kHdVkwvIJORLvG/wx9kwfxVq/uPZtb5WAtFRlGED3d3mDZwr1M F3JPfNq+vuHfMRCfnSMhGOZh6a347C41XRYTatEczgpIb8CSWLRfQ0N2mGU1QMly3EnB ZOcBzwtmyxI76RzBgZVhCJMu66SxOdiG6Dh/uBwZjpOohy5Q0gaMWQXgHN9Rx4cCgL+g QRdw== X-Gm-Message-State: AMCzsaW3CvzgvCwnpHL75hhTDme/j2b8oa/78phP+Ufx5rucsosFNHXR HeSdqj+nuho/MPVX1fe1UNZFnjFStUQu8bjYt68= X-Google-Smtp-Source: ABhQp+TsLYsjFBDZrLAlVt3HqzMJcnpvDFSk3592PyXdS5w6MHvhdL4PJ9jrnUj1D/xu101ZTLRWn8e8CoFT5OMUA/0= X-Received: by 10.157.37.90 with SMTP id j26mr26993otd.401.1508881256433; Tue, 24 Oct 2017 14:40:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Tue, 24 Oct 2017 14:40:55 -0700 (PDT) In-Reply-To: <20171024135929.ijathkbwc3vh4635@LK-Perkele-VII> References: <20171024135929.ijathkbwc3vh4635@LK-Perkele-VII> From: Martin Thomson Date: Wed, 25 Oct 2017 08:40:55 +1100 Message-ID: To: Ilari Liusvaara Cc: Eric Rescorla , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:40:58 -0000 On Wed, Oct 25, 2017 at 12:59 AM, Ilari Liusvaara wrote: > On Mon, Oct 23, 2017 at 06:14:33PM -0700, Eric Rescorla wrote: >> We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. > > What is the _worst_ case memory usage (both sending and receving) for > handling the acknowledgements and guaranteeing forward progress in all > reasonable cases? Exact numbers are difficult, but in general, the sender needs to remember an entire flight, plus the records that it sends and the parts of the flight that were in those records. In our implementation, we use ~35 octets per handshake message fragment, which could be reduced, possibly by quite a bit. Worst case is with large messages and small MTU/record limit with lots of packet loss, where you might have a fairly large number of these records to track what was sent. That is in addition to whatever messages you send, which you have to remember once they are constructed (Certificate being a real wild card here, of course). As you say, you can limit this by ensuring that you limit the size of messages and the number of fragments that you have outstanding. The receiver really only needs to track the data it receives. We (currently) pretend not to receive packets if they aren't contiguous with the data we have, so our outstanding memory is at most one handshake message and a couple of status variables. Once the handshake message is complete, we process it. If we had progressive parsing and processing, that might go lower, but we don't target constrained devices. From nobody Tue Oct 24 14:55:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF13B13A8A1 for ; Tue, 24 Oct 2017 14:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2SC0z5EPJ1W for ; Tue, 24 Oct 2017 14:55:42 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2C113F855 for ; Tue, 24 Oct 2017 14:55:42 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id x82so28211540qkb.12 for ; Tue, 24 Oct 2017 14:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OZYQp8OF3BnDBl2B1//3NgrJZIFSiNlSWO5GPN+6dwg=; b=QwXzqOPs64L52eulJj8wYQjmRTjJGcjSUSPvvNcMa2gZPhwDdPOYqOvQ7YTFgB3cQZ 8Q7R13qc8+fSN8lBhUIFrlql+BzkZ5WEeged3aXuOHMTlUYvVr8a8A2XDMI13/+hH8jj 32IPevjdytGjzLnrQh+hIX4K10RMMHLhOC2E/0Kq2JKl7W7fO8haQdhnP4jkjE3qMYlx YXrX6IeDYCo9lGbXEcOJgxKIT3IbUf0AgSMZezTvxW7x4Go49vo//RRiMUpfshx3/KYN ulNANFPlMaVIbOMtiQpY0w8GGHt9O19zlghnNndep3xg5HoR5C/AIXOTLpaxAetun+wK egcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OZYQp8OF3BnDBl2B1//3NgrJZIFSiNlSWO5GPN+6dwg=; b=TDDR9nnYyhyXm2LGDZ0EFvi7L1P33vNyLQrqc9B5Z/vpXoQ8NBVoMMKlN/cD+cluvV U3SvDxi0JPJn7iNY6w/9YhtV1waEx/WweYvpgb6QJpclVgVVuwUJuT93ohCHAIGqaWuZ +ufLLIPRmuhOtl2XISq8Pub04A7mg1nT5LjSh+ruLV8YdYwtkzHj2V8XN5NN3Y1r8oam 6SXZSDtKUunR+ZrDBc8aKkh+XZoLy+4RBoyZ2df0hzHsKb96POAsKwAWrN/UBdt/pEVr ZMNZS9zjE7Mwtd6IvKdQc/khTJY5fDPbEJixZJ5g+zbkbSGxS14NYupd3S4iUjc33iF9 fEYA== X-Gm-Message-State: AMCzsaVfRmzjeHHjyOseHxKPXfKmL9uUbsGzbYA8hYIH9HSSyCXOtA4t k8i7X7iok3gbrcnLp9ZiuIyNELrv6cI= X-Google-Smtp-Source: ABhQp+QprK2UGfpX4U9ViT4CWF1RU86eRWWXrApQdvFeDPz1YSVaG6ZhLk6yiiXxl2fx844ZUsh7bg== X-Received: by 10.55.154.146 with SMTP id c140mr127835qke.131.1508882141224; Tue, 24 Oct 2017 14:55:41 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id q206sm857118qke.54.2017.10.24.14.55.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 14:55:40 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_742EDD33-5C5D-4E61-82AD-6A776FADDD3B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 24 Oct 2017 17:55:39 -0400 In-Reply-To: Cc: "tls@ietf.org" To: "David A. Cooper" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:55:44 -0000 --Apple-Mail=_742EDD33-5C5D-4E61-82AD-6A776FADDD3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2017, at 4:40 PM, David A. Cooper = wrote: > Also, in the data center case, there is no middlebox. Others, who know = much more than I do about operational constraints in data center = environments, have already argued that setting up a bunch of middleboxes = would not be a viable solution. I was not actually suggesting this as a solution. Rather, I was = pointing out that it's a lousy solution for both use cases.= --Apple-Mail=_742EDD33-5C5D-4E61-82AD-6A776FADDD3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct 24, 2017, at 4:40 PM, David A. Cooper <david.cooper@nist.gov> wrote:
Also, in the data center case, there is no middlebox. Others, = who know much more than I do about operational constraints in data = center environments, have already argued that setting up a bunch of = middleboxes would not be a viable solution.

I was = not actually suggesting this as a solution.   Rather, I was = pointing out that it's a lousy solution for both use = cases.
= --Apple-Mail=_742EDD33-5C5D-4E61-82AD-6A776FADDD3B-- From nobody Tue Oct 24 15:39:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DA513F876 for ; Tue, 24 Oct 2017 15:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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 gK_0KuuIsJjr for ; Tue, 24 Oct 2017 15:39:17 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79989138BD2 for ; Tue, 24 Oct 2017 15:39:17 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Oct 2017 18:39:09 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Tue, 24 Oct 2017 18:39:13 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9OMcwMD028663 for ; Tue, 24 Oct 2017 18:38:58 -0400 To: "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> From: "David A. Cooper" Message-ID: <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> Date: Tue, 24 Oct 2017 18:39:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 22:39:20 -0000
On 10/24/2017 05:18 PM, Salz, Rich wrote:

 

  • And, I don't buy the idea that if this extension is standardized that it will be implemented in commonly-used browsers.

 

And that is a risk you are willing for the entire public Internet to take?


I'm not taking any risk.  The ability for a server to allow a third party to have access to data it is exchanging with a client already exists, and that ability isn't going away whether this proposal (or something similar) is standardized or not. As I've already pointed out, for the scenarios people are concerned about, the "attacks" being described would be much more easily carried out by some means other than draft-rhrd-tls-tls13-visibility.

So, no I am not worried about the "risk" of creating a complicated way for servers and middleboxes to collude to do something that they can already do now in a simpler way.

And what about the fact that it provides a cleartext signal as to whether or not a client is willing to let itself be MiTM’d, does that bother you?


No. As I noted before, servers can already allow middleboxes to MiTM connections with clients with asking the client's permission. Public facing servers that want to allow this (even if as a result of coercion) won't use this extension. They'll just enable it without informing the clients.

There are also other ways a server could allow a middlebox to MiTM the connections that it has with clients that don't require the client's cooperation (or knowledge) and that wouldn't require any changes on the client side; ways that would be easier than trying to use draft-rhrd-tls-tls13-visibility.

If the only way (or the easiest way) these connections could be MiTM'd required getting clients' permission, then this might be a concern, I don't see servers that want to (or are coerced into) allowing connections to be MiTM'd asking clients whether they are willing. Given this, we aren't going to see browsers that are configurable to signal that the client is willing to "allow" the connection to be MiTM'd.

I haven't even gotten into the question of what does it mean for a connection to be MiTM'd. If Company X decides to have its web site operated by Hosting Provider Y is the connection between the client and Company X being MiTM'd? The client might think it has a secure end-to-end connection with Company X, but in reality its data is being intercepted and read by Hosting Provider Y, without the client's permission (and most likely without the client's knowledge). How does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot be standardized until it can be proven that such a scenario is impossible?


From nobody Tue Oct 24 15:47:48 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1198413F876 for ; Tue, 24 Oct 2017 15:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oHmxV4lcPkJg for ; Tue, 24 Oct 2017 15:47:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855CD13F87B for ; Tue, 24 Oct 2017 15:47:45 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B12447A330D for ; Tue, 24 Oct 2017 22:47:44 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Viktor Dukhovni In-Reply-To: <7457.1508880403@obiwan.sandelman.ca> Date: Tue, 24 Oct 2017 18:47:43 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: tls@ietf.org Message-Id: References: <7457.1508880403@obiwan.sandelman.ca> To: tls@ietf.org X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [TLS] sending full certificate chains in ClientCertificate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 22:47:47 -0000 > On Oct 24, 2017, at 5:26 PM, Michael Richardson = wrote: >=20 > In the browser space there has been pushback against including the = trust > anchors in the Server->Browser direction, including Google's Chrome = browser > complaining about unnecessary certificates, and TLS scanners. > I understand that some of this is the result of some client libraries = that > could be confused (due to bugs) into validating a bogus chain if there = was a > self-signed certificate in the certificates sent from the server. >=20 > What's unclear to me if there is any kind of specification that we = would be > violating if we state that we want the full chain in the Client's = Certificate > extension. Full chains are just fine. Indeed per RFC7671 with DANE-TA(2) the = server MUST present a full chain (including the root CA certificate) to the = client when the server's TLSA record is associated with the trust anchor = certificate. If you have a legitimate use case in which the relying party may not = have a copy of a root CA, but can validate it if received from the peer, then requiring the transmission of root CAs is fine and natural. --=20 Viktor.= From nobody Tue Oct 24 17:42:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA0E13A344 for ; Tue, 24 Oct 2017 17:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.08 X-Spam-Level: X-Spam-Status: No, score=-4.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 U1MaCTrPcerF for ; Tue, 24 Oct 2017 17:41:56 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 9E99D139689 for ; Tue, 24 Oct 2017 17:41:56 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id C7821C0D72 for ; Tue, 24 Oct 2017 19:41:55 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 3D2C3C0C9E; Tue, 24 Oct 2017 19:41:55 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 01BF792074; Tue, 24 Oct 2017 20:41:55 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9EBB292073; Tue, 24 Oct 2017 20:41:54 -0400 (EDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (unknown [216.32.181.18]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Tue, 24 Oct 2017 20:41:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hr6FeJNWdcxSMqzQ04OV5ssoLYemfQ/jsDxghXLcbLk=; b=HO8Ql0zic+igXbFiJnNuSVgZRc/19XY8Eu6HjWCQIftlbsr0kSKbYwGXGAPJ9vl3OrOWnswQV9ED8B7MFlRUIYZ8M/azm9+CgrHKCph2tdCU71efirmLGgsY2JCnTVBckmmiKu/TNhH2gKYutuDbUgu+MrgL1a+/wf8NyF/KWrw= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 25 Oct 2017 00:41:52 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Wed, 25 Oct 2017 00:41:52 +0000 From: "Ackermann, Michael" To: "David A. Cooper" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5HVvcnaInjUunozwwxCXv1qLzYRoAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjPAIAAAkyAgAAWooCAACCFcA== Date: Wed, 25 Oct 2017 00:41:52 +0000 Message-ID: References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> In-Reply-To: <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> 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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 20:resvlh+jbSU/oD0gQh7FerIR/maXHNdbMFya6JOG80081NpSnCnwOyb05gSCZP3R+ddw3JgyVP15xdE0Qmi5belov87ifZK0OMvIcvc+9cfqVI8reD+5Ml5nRSYRmU1rswKipAZ40eb+2Q/+7qbFoms/d9q1OZhLkufQA7keWDA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b2a32237-8a0a-4d6a-6e7f-08d51b412fae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1368; x-ms-traffictypediagnostic: CY4PR14MB1368: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231020)(10201501046)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1368; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(24454002)(189002)(199003)(51694002)(105586002)(80792005)(790700001)(6436002)(2950100002)(8936002)(81156014)(110136005)(14454004)(6246003)(102836003)(316002)(8656006)(3846002)(68736007)(81166006)(55016002)(8676002)(25786009)(66066001)(561944003)(5660300001)(54356999)(3280700002)(86362001)(2906002)(7696004)(101416001)(53546010)(74316002)(6116002)(50986999)(2501003)(7736002)(230783001)(6506006)(53936002)(93886005)(106356001)(97736004)(9686003)(54896002)(189998001)(99286003)(2900100001)(3660700001)(33656002)(77096006)(229853002)(72206003)(76176999)(478600001)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB13686CD4119467FEEB5AC454D7440CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2017 00:41:52.8015 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368 X-TM-AS-GCONF: 00 X-VPM-MSG-ID: 5dd6ed47-a9e3-4dfe-9ab7-c7918ca587a2 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 9f678565-5ac5-450d-a17b-df4922c31533 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 00:41:59 -0000 --_000_CY4PR14MB13686CD4119467FEEB5AC454D7440CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhjZWxsZW50IHBvaW50cy9xdWVzdGlvbnMgYW5kIEkganVzdCB3YW50ZWQgdG8gYWRkIHRo YXQgeW91ciBmaW5hbCBleGFtcGxlLCByZWdhcmRpbmcgIGhvc3RpbmcgcHJvdmlkZXJzIGFj dHVhbGx5IGJlaW5nIGEgTWl0TSwgIGlzIEVYVFJFTUVMWSBwcmV2YWxlbnQgaW4gRW50ZXJw cmlzZXMgdG9kYXkgYW5kIGlzIGEgbWFuYWdlbWVudC8gbW9uaXRvcmluZyBpc3N1ZSBzcGVj aWZpY2FsbHkgcG9pbnRlZCBvdXQgYnkgU3RldmVuIEZlbnRlciBpbiBoaXMgcHJlc2VudGF0 aW9uIHRvIHRoZSBUTFMgV0cgaW4gUHJhZ3VlLg0KV2l0aG91dCB0aGUgYWJpbGl0eSB0byBk ZWNyeXB0IHRoZXNlIHNlc3Npb25zIG91ciBhYmlsaXR5IHRvIG1hbmFnZS9tb25pdG9yL3Nl Y3VyZSBpcyBzZXZlcmVseSByZWR1Y2VkLg0KQW5kIFRMUywgYmVpbmcgYSBwb2ludCB0byBw b2ludCBwcm90b2NvbCwgIGNhbm5vdCBoZWxwIGluIGl0cyBjdXJyZW50IGZvcm0uDQoNCkZy b206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2 aWQgQS4gQ29vcGVyDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI0LCAyMDE3IDY6MzkgUE0N ClRvOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBQdWJsaWNhdGlvbiBvZiBk cmFmdC1yaHJkLXRscy10bHMxMy12aXNpYmlsaXR5LTAwDQoNCk9uIDEwLzI0LzIwMTcgMDU6 MTggUE0sIFNhbHosIFJpY2ggd3JvdGU6DQoNCg0KICAqICAgQW5kLCBJIGRvbid0IGJ1eSB0 aGUgaWRlYSB0aGF0IGlmIHRoaXMgZXh0ZW5zaW9uIGlzIHN0YW5kYXJkaXplZCB0aGF0IGl0 IHdpbGwgYmUgaW1wbGVtZW50ZWQgaW4gY29tbW9ubHktdXNlZCBicm93c2Vycy4NCg0KQW5k IHRoYXQgaXMgYSByaXNrIHlvdSBhcmUgd2lsbGluZyBmb3IgdGhlIGVudGlyZSBwdWJsaWMg SW50ZXJuZXQgdG8gdGFrZT8NCg0KSSdtIG5vdCB0YWtpbmcgYW55IHJpc2suICBUaGUgYWJp bGl0eSBmb3IgYSBzZXJ2ZXIgdG8gYWxsb3cgYSB0aGlyZCBwYXJ0eSB0byBoYXZlIGFjY2Vz cyB0byBkYXRhIGl0IGlzIGV4Y2hhbmdpbmcgd2l0aCBhIGNsaWVudCBhbHJlYWR5IGV4aXN0 cywgYW5kIHRoYXQgYWJpbGl0eSBpc24ndCBnb2luZyBhd2F5IHdoZXRoZXIgdGhpcyBwcm9w b3NhbCAob3Igc29tZXRoaW5nIHNpbWlsYXIpIGlzIHN0YW5kYXJkaXplZCBvciBub3QuIEFz IEkndmUgYWxyZWFkeSBwb2ludGVkIG91dCwgZm9yIHRoZSBzY2VuYXJpb3MgcGVvcGxlIGFy ZSBjb25jZXJuZWQgYWJvdXQsIHRoZSAiYXR0YWNrcyIgYmVpbmcgZGVzY3JpYmVkIHdvdWxk IGJlIG11Y2ggbW9yZSBlYXNpbHkgY2FycmllZCBvdXQgYnkgc29tZSBtZWFucyBvdGhlciB0 aGFuIGRyYWZ0LXJocmQtdGxzLXRsczEzLXZpc2liaWxpdHkuDQoNClNvLCBubyBJIGFtIG5v dCB3b3JyaWVkIGFib3V0IHRoZSAicmlzayIgb2YgY3JlYXRpbmcgYSBjb21wbGljYXRlZCB3 YXkgZm9yIHNlcnZlcnMgYW5kIG1pZGRsZWJveGVzIHRvIGNvbGx1ZGUgdG8gZG8gc29tZXRo aW5nIHRoYXQgdGhleSBjYW4gYWxyZWFkeSBkbyBub3cgaW4gYSBzaW1wbGVyIHdheS4NCg0K DQpBbmQgd2hhdCBhYm91dCB0aGUgZmFjdCB0aGF0IGl0IHByb3ZpZGVzIGEgY2xlYXJ0ZXh0 IHNpZ25hbCBhcyB0byB3aGV0aGVyIG9yIG5vdCBhIGNsaWVudCBpcyB3aWxsaW5nIHRvIGxl dCBpdHNlbGYgYmUgTWlUTeKAmWQsIGRvZXMgdGhhdCBib3RoZXIgeW91Pw0KDQpOby4gQXMg SSBub3RlZCBiZWZvcmUsIHNlcnZlcnMgY2FuIGFscmVhZHkgYWxsb3cgbWlkZGxlYm94ZXMg dG8gTWlUTSBjb25uZWN0aW9ucyB3aXRoIGNsaWVudHMgd2l0aCBhc2tpbmcgdGhlIGNsaWVu dCdzIHBlcm1pc3Npb24uIFB1YmxpYyBmYWNpbmcgc2VydmVycyB0aGF0IHdhbnQgdG8gYWxs b3cgdGhpcyAoZXZlbiBpZiBhcyBhIHJlc3VsdCBvZiBjb2VyY2lvbikgd29uJ3QgdXNlIHRo aXMgZXh0ZW5zaW9uLiBUaGV5J2xsIGp1c3QgZW5hYmxlIGl0IHdpdGhvdXQgaW5mb3JtaW5n IHRoZSBjbGllbnRzLg0KDQpUaGVyZSBhcmUgYWxzbyBvdGhlciB3YXlzIGEgc2VydmVyIGNv dWxkIGFsbG93IGEgbWlkZGxlYm94IHRvIE1pVE0gdGhlIGNvbm5lY3Rpb25zIHRoYXQgaXQg aGFzIHdpdGggY2xpZW50cyB0aGF0IGRvbid0IHJlcXVpcmUgdGhlIGNsaWVudCdzIGNvb3Bl cmF0aW9uIChvciBrbm93bGVkZ2UpIGFuZCB0aGF0IHdvdWxkbid0IHJlcXVpcmUgYW55IGNo YW5nZXMgb24gdGhlIGNsaWVudCBzaWRlOyB3YXlzIHRoYXQgd291bGQgYmUgZWFzaWVyIHRo YW4gdHJ5aW5nIHRvIHVzZSBkcmFmdC1yaHJkLXRscy10bHMxMy12aXNpYmlsaXR5Lg0KDQpJ ZiB0aGUgb25seSB3YXkgKG9yIHRoZSBlYXNpZXN0IHdheSkgdGhlc2UgY29ubmVjdGlvbnMg Y291bGQgYmUgTWlUTSdkIHJlcXVpcmVkIGdldHRpbmcgY2xpZW50cycgcGVybWlzc2lvbiwg dGhlbiB0aGlzIG1pZ2h0IGJlIGEgY29uY2VybiwgSSBkb24ndCBzZWUgc2VydmVycyB0aGF0 IHdhbnQgdG8gKG9yIGFyZSBjb2VyY2VkIGludG8pIGFsbG93aW5nIGNvbm5lY3Rpb25zIHRv IGJlIE1pVE0nZCBhc2tpbmcgY2xpZW50cyB3aGV0aGVyIHRoZXkgYXJlIHdpbGxpbmcuIEdp dmVuIHRoaXMsIHdlIGFyZW4ndCBnb2luZyB0byBzZWUgYnJvd3NlcnMgdGhhdCBhcmUgY29u ZmlndXJhYmxlIHRvIHNpZ25hbCB0aGF0IHRoZSBjbGllbnQgaXMgd2lsbGluZyB0byAiYWxs b3ciIHRoZSBjb25uZWN0aW9uIHRvIGJlIE1pVE0nZC4NCg0KSSBoYXZlbid0IGV2ZW4gZ290 dGVuIGludG8gdGhlIHF1ZXN0aW9uIG9mIHdoYXQgZG9lcyBpdCBtZWFuIGZvciBhIGNvbm5l Y3Rpb24gdG8gYmUgTWlUTSdkLiBJZiBDb21wYW55IFggZGVjaWRlcyB0byBoYXZlIGl0cyB3 ZWIgc2l0ZSBvcGVyYXRlZCBieSBIb3N0aW5nIFByb3ZpZGVyIFkgaXMgdGhlIGNvbm5lY3Rp b24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCBDb21wYW55IFggYmVpbmcgTWlUTSdkPyBUaGUg Y2xpZW50IG1pZ2h0IHRoaW5rIGl0IGhhcyBhIHNlY3VyZSBlbmQtdG8tZW5kIGNvbm5lY3Rp b24gd2l0aCBDb21wYW55IFgsIGJ1dCBpbiByZWFsaXR5IGl0cyBkYXRhIGlzIGJlaW5nIGlu dGVyY2VwdGVkIGFuZCByZWFkIGJ5IEhvc3RpbmcgUHJvdmlkZXIgWSwgd2l0aG91dCB0aGUg Y2xpZW50J3MgcGVybWlzc2lvbiAoYW5kIG1vc3QgbGlrZWx5IHdpdGhvdXQgdGhlIGNsaWVu dCdzIGtub3dsZWRnZSkuIEhvdyBkb2VzIFRMUywgY3VycmVudGx5LCBwcmV2ZW50IHRoaXM/ IFdoeSBpc24ndCBhbnlvbmUgZGVtYW5kaW5nIHRoYXQgVExTIGNhbm5vdCBiZSBzdGFuZGFy ZGl6ZWQgdW50aWwgaXQgY2FuIGJlIHByb3ZlbiB0aGF0IHN1Y2ggYSBzY2VuYXJpbyBpcyBp bXBvc3NpYmxlPw0KDQoNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNv bW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21t dW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5 aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlz IHByb2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBt YWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRl IHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJs dWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3Jr IG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVu dCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0 aW9uLgo= --_000_CY4PR14MB13686CD4119467FEEB5AC454D7440CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIg MiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBh bm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTgxNTU1OTYwMDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzNzEyMTQ5NDQ7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28t bGlzdC1pZDoxOTM2NjcwMTA3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTY1ODEyNjYxNCAtMTQxMzU5ODU1MiA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i Ow0KCWNvbG9yOmJsYWNrOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3Qg bDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dCI+RXhjZWxsZW50IHBvaW50cy9xdWVzdGlvbnMgYW5kIEkganVzdCB3YW50ZWQgdG8g YWRkIHRoYXQgeW91ciBmaW5hbCBleGFtcGxlLCByZWdhcmRpbmcgJm5ic3A7aG9zdGluZyBw cm92aWRlcnMgYWN0dWFsbHkgYmVpbmcgYSBNaXRNLCAmbmJzcDtpcyBFWFRSRU1FTFkgcHJl dmFsZW50IGluIEVudGVycHJpc2VzIHRvZGF5IGFuZCBpcyBhIG1hbmFnZW1lbnQvIG1vbml0 b3JpbmcNCiBpc3N1ZSBzcGVjaWZpY2FsbHkgcG9pbnRlZCBvdXQgYnkgU3RldmVuIEZlbnRl ciBpbiBoaXMgcHJlc2VudGF0aW9uIHRvIHRoZSBUTFMgV0cgaW4gUHJhZ3VlLiZuYnNwOw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPldpdGhvdXQgdGhlIGFiaWxpdHkgdG8gZGVjcnlwdCB0 aGVzZSBzZXNzaW9ucyBvdXIgYWJpbGl0eSB0byBtYW5hZ2UvbW9uaXRvci9zZWN1cmUgaXMg c2V2ZXJlbHkgcmVkdWNlZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5BbmQgVExT LCBiZWluZyBhIHBvaW50IHRvIHBvaW50IHByb3RvY29sLCZuYnNwOyBjYW5ub3QgaGVscCBp biBpdHMgY3VycmVudCBmb3JtLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4N CjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYXZpZCBBLiBDb29wZXI8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAyNCwgMjAxNyA2OjM5IFBNPGJyPg0KPGI+ VG86PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIFB1 YmxpY2F0aW9uIG9mIGRyYWZ0LXJocmQtdGxzLXRsczEzLXZpc2liaWxpdHktMDA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g MTAvMjQvMjAxNyAwNToxOCBQTSwgU2FseiwgUmljaCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPkFu ZCwgSSBkb24ndCBidXkgdGhlIGlkZWEgdGhhdCBpZiB0aGlzIGV4dGVuc2lvbiBpcyBzdGFu ZGFyZGl6ZWQgdGhhdCBpdCB3aWxsIGJlIGltcGxlbWVudGVkIGluIGNvbW1vbmx5LXVzZWQg YnJvd3NlcnMuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB0aGF0IGlz IGEgcmlzayB5b3UgYXJlIHdpbGxpbmcgZm9yIHRoZSBlbnRpcmUgcHVibGljIEludGVybmV0 IHRvIHRha2U/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpJJ20gbm90IHRha2luZyBhbnkgcmlzay4mbmJzcDsgVGhlIGFiaWxp dHkgZm9yIGEgc2VydmVyIHRvIGFsbG93IGEgdGhpcmQgcGFydHkgdG8gaGF2ZSBhY2Nlc3Mg dG8gZGF0YSBpdCBpcyBleGNoYW5naW5nIHdpdGggYSBjbGllbnQgYWxyZWFkeSBleGlzdHMs IGFuZCB0aGF0IGFiaWxpdHkgaXNuJ3QgZ29pbmcgYXdheSB3aGV0aGVyIHRoaXMgcHJvcG9z YWwgKG9yIHNvbWV0aGluZyBzaW1pbGFyKSBpcyBzdGFuZGFyZGl6ZWQgb3Igbm90LiBBcyBJ J3ZlIGFscmVhZHkNCiBwb2ludGVkIG91dCwgZm9yIHRoZSBzY2VuYXJpb3MgcGVvcGxlIGFy ZSBjb25jZXJuZWQgYWJvdXQsIHRoZSAmcXVvdDthdHRhY2tzJnF1b3Q7IGJlaW5nIGRlc2Ny aWJlZCB3b3VsZCBiZSBtdWNoIG1vcmUgZWFzaWx5IGNhcnJpZWQgb3V0IGJ5IHNvbWUgbWVh bnMgb3RoZXIgdGhhbiBkcmFmdC1yaHJkLXRscy10bHMxMy12aXNpYmlsaXR5Ljxicj4NCjxi cj4NClNvLCBubyBJIGFtIG5vdCB3b3JyaWVkIGFib3V0IHRoZSAmcXVvdDtyaXNrJnF1b3Q7 IG9mIGNyZWF0aW5nIGEgY29tcGxpY2F0ZWQgd2F5IGZvciBzZXJ2ZXJzIGFuZCBtaWRkbGVi b3hlcyB0byBjb2xsdWRlIHRvIGRvIHNvbWV0aGluZyB0aGF0IHRoZXkgY2FuIGFscmVhZHkg ZG8gbm93IGluIGEgc2ltcGxlciB3YXkuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB3aGF0IGFib3V0IHRoZSBmYWN0 IHRoYXQgaXQgcHJvdmlkZXMgYSBjbGVhcnRleHQgc2lnbmFsIGFzIHRvIHdoZXRoZXIgb3Ig bm90IGEgY2xpZW50IGlzIHdpbGxpbmcgdG8gbGV0IGl0c2VsZiBiZSBNaVRN4oCZZCwgZG9l cyB0aGF0IGJvdGhlciB5b3U/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk5v LiBBcyBJIG5vdGVkIGJlZm9yZSwgc2VydmVycyBjYW4gYWxyZWFkeSBhbGxvdyBtaWRkbGVi b3hlcyB0byBNaVRNIGNvbm5lY3Rpb25zIHdpdGggY2xpZW50cyB3aXRoIGFza2luZyB0aGUg Y2xpZW50J3MgcGVybWlzc2lvbi4gUHVibGljIGZhY2luZyBzZXJ2ZXJzIHRoYXQgd2FudCB0 byBhbGxvdyB0aGlzIChldmVuIGlmIGFzIGEgcmVzdWx0IG9mIGNvZXJjaW9uKSB3b24ndCB1 c2UgdGhpcyBleHRlbnNpb24uIFRoZXknbGwganVzdCBlbmFibGUNCiBpdCB3aXRob3V0IGlu Zm9ybWluZyB0aGUgY2xpZW50cy48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBvdGhlciB3 YXlzIGEgc2VydmVyIGNvdWxkIGFsbG93IGEgbWlkZGxlYm94IHRvIE1pVE0gdGhlIGNvbm5l Y3Rpb25zIHRoYXQgaXQgaGFzIHdpdGggY2xpZW50cyB0aGF0IGRvbid0IHJlcXVpcmUgdGhl IGNsaWVudCdzIGNvb3BlcmF0aW9uIChvciBrbm93bGVkZ2UpIGFuZCB0aGF0IHdvdWxkbid0 IHJlcXVpcmUgYW55IGNoYW5nZXMgb24gdGhlIGNsaWVudCBzaWRlOyB3YXlzIHRoYXQgd291 bGQgYmUgZWFzaWVyIHRoYW4gdHJ5aW5nDQogdG8gdXNlIGRyYWZ0LXJocmQtdGxzLXRsczEz LXZpc2liaWxpdHkuPGJyPg0KPGJyPg0KSWYgdGhlIG9ubHkgd2F5IChvciB0aGUgZWFzaWVz dCB3YXkpIHRoZXNlIGNvbm5lY3Rpb25zIGNvdWxkIGJlIE1pVE0nZCByZXF1aXJlZCBnZXR0 aW5nIGNsaWVudHMnIHBlcm1pc3Npb24sIHRoZW4gdGhpcyBtaWdodCBiZSBhIGNvbmNlcm4s IEkgZG9uJ3Qgc2VlIHNlcnZlcnMgdGhhdCB3YW50IHRvIChvciBhcmUgY29lcmNlZCBpbnRv KSBhbGxvd2luZyBjb25uZWN0aW9ucyB0byBiZSBNaVRNJ2QgYXNraW5nIGNsaWVudHMgd2hl dGhlciB0aGV5IGFyZQ0KIHdpbGxpbmcuIEdpdmVuIHRoaXMsIHdlIGFyZW4ndCBnb2luZyB0 byBzZWUgYnJvd3NlcnMgdGhhdCBhcmUgY29uZmlndXJhYmxlIHRvIHNpZ25hbCB0aGF0IHRo ZSBjbGllbnQgaXMgd2lsbGluZyB0byAmcXVvdDthbGxvdyZxdW90OyB0aGUgY29ubmVjdGlv biB0byBiZSBNaVRNJ2QuPGJyPg0KPGJyPg0KSSBoYXZlbid0IGV2ZW4gZ290dGVuIGludG8g dGhlIHF1ZXN0aW9uIG9mIHdoYXQgZG9lcyBpdCBtZWFuIGZvciBhIGNvbm5lY3Rpb24gdG8g YmUgTWlUTSdkLiBJZiBDb21wYW55IFggZGVjaWRlcyB0byBoYXZlIGl0cyB3ZWIgc2l0ZSBv cGVyYXRlZCBieSBIb3N0aW5nIFByb3ZpZGVyIFkgaXMgdGhlIGNvbm5lY3Rpb24gYmV0d2Vl biB0aGUgY2xpZW50IGFuZCBDb21wYW55IFggYmVpbmcgTWlUTSdkPyBUaGUgY2xpZW50IG1p Z2h0IHRoaW5rIGl0IGhhcw0KIGEgc2VjdXJlIGVuZC10by1lbmQgY29ubmVjdGlvbiB3aXRo IENvbXBhbnkgWCwgYnV0IGluIHJlYWxpdHkgaXRzIGRhdGEgaXMgYmVpbmcgaW50ZXJjZXB0 ZWQgYW5kIHJlYWQgYnkgSG9zdGluZyBQcm92aWRlciBZLCB3aXRob3V0IHRoZSBjbGllbnQn cyBwZXJtaXNzaW9uIChhbmQgbW9zdCBsaWtlbHkgd2l0aG91dCB0aGUgY2xpZW50J3Mga25v d2xlZGdlKS4gSG93IGRvZXMgVExTLCBjdXJyZW50bHksIHByZXZlbnQgdGhpcz8gV2h5IGlz bid0IGFueW9uZQ0KIGRlbWFuZGluZyB0aGF0IFRMUyBjYW5ub3QgYmUgc3RhbmRhcmRpemVk IHVudGlsIGl0IGNhbiBiZSBwcm92ZW4gdGhhdCBzdWNoIGEgc2NlbmFyaW8gaXMgaW1wb3Nz aWJsZT88bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQoKCjxCUj4KPGh0bWw+CiA8cD5UaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFs IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwo cykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9m IHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRl ZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtp bmcgYW55IGNvcGllcy48L3A+CiA8cD5CbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hp Z2FuIGFuZCBCbHVlIENhcmUgTmV0d29yayBvZiBNaWNoaWdhbiBhcmUgbm9ucHJvZml0IGNv cnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRlbnQgbGljZW5zZWVzIG9mIHRoZSBCbHVlIENyb3Nz IGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lhdGlvbi48L3A+CiAgPC9odG1sPgoK --_000_CY4PR14MB13686CD4119467FEEB5AC454D7440CY4PR14MB1368namp_-- From nobody Tue Oct 24 17:59:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC1E1395ED for ; Tue, 24 Oct 2017 17:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 BYAHouOhZ2FP for ; Tue, 24 Oct 2017 17:59:23 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5039C13A5BC for ; Tue, 24 Oct 2017 17:59:23 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9P0v4dJ007613; Wed, 25 Oct 2017 01:59:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=4bi0wFHTJ+a1BmSdKOLIDaKYK37dPpu7E31hG4Y6NMY=; b=XvLEp2T5W6Gk4hKNAvV7nNDMwWof9NreHn/t55p49tOyG0TmyNaIPrUoSuGwdxQLZ12d PxXPiHvPGbf7U4hCXPlIaqY6eyEvrYpXsDfYAvgcLFPaLDN6FRPgOIGTcxeSpeWqS5pl tgT+MvfJfiLK5oisHd8+ywC8U0UnYLai4nhrm3hkWL37AtIJK1JFmDtVrZKdCan9J858 BPi7JgRFG7XTao5CBgpw4rYcx907S3Y2IZpkuRS+e153vedHIbKTn7YtOVcnO4jRdSsA qckrC//P97U5aoQJChvgcis9MNjcQgE1adsc+Qx7ems/nFopQLhrsmdXDtYxBtbQZtME rA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2dquad3uc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 01:59:21 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9P0udng017863; Tue, 24 Oct 2017 20:59:20 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1juapue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 20:59:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 20:59:19 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 24 Oct 2017 20:59:19 -0400 From: "Salz, Rich" To: "David A. Cooper" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjQAIAAAkoAgAAWo4CAACJOAIAABN6A Date: Wed, 25 Oct 2017 00:59:18 +0000 Message-ID: <041E86E9-493F-4F20-8BD8-A48296E0AFBE@akamai.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.65] Content-Type: multipart/alternative; boundary="_000_041E86E9493F4F208BD8A48296E0AFBEakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250011 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 00:59:26 -0000 --_000_041E86E9493F4F208BD8A48296E0AFBEakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+IEknbSBub3QgdGFraW5nIGFueSByaXNrLiAgVGhlIGFiaWxpdHkgZm9yIGEgc2VydmVyIHRv IGFsbG93IGEgdGhpcmQgcGFydHkgdG8gaGF2ZSBhY2Nlc3MgdG8gZGF0YSBpdCBpcyBleGNoYW5n aW5nIHdpdGggYSBjbGllbnQgYWxyZWFkeSBleGlzdHMsIGFuZCB0aGF0IGFiaWxpdHkgaXNuJ3Qg Z29pbmcgYXdheSB3aGV0aGVyIHRoaXMgcHJvcG9zYWwgKG9yIHNvbWV0aGluZyBzaW1pbGFyKSBp cyBzdGFuZGFyZGl6ZWQgb3Igbm90LiBBcyBJJ3ZlIGFscmVhZHkgcG9pbnRlZCBvdXQsIGZvciB0 aGUgc2NlbmFyaW9zIHBlb3BsZSBhcmUgY29uY2VybmVkIGFib3V0LCB0aGUgImF0dGFja3MiIGJl aW5nIGRlc2NyaWJlZCB3b3VsZCBiZSBtdWNoIG1vcmUgZWFzaWx5IGNhcnJpZWQgb3V0IGJ5IHNv bWUgbWVhbnMgb3RoZXIgdGhhbiBkcmFmdC1yaHJkLXRscy10bHMxMy12aXNpYmlsaXR5Lg0KDQpZ ZXMsIHlvdSBhcmUgdGFraW5nIGEgcmlzay4gIE9yLCByYXRoZXIsIHlvdSBhcmUgcHJvdmlkaW5n IGEgd2F5IGZvciBhbnkgbWlkZGxlYm94IHRvIGZvcmNlIGNsaWVudHMgdG8gYWNxdWllc2NlLiAg WW91IG1pZ2h0IHRoaW5rIGl04oCZcyBjb21wbGljYXRlZCwgYnV0IGl04oCZcyBub3QuICBUaGVy ZeKAmXMgYSBwZXJsIHNjcmlwdCBpbiB0aGUgT3BlblNTTCBkaXN0cmlidXRpb24gdGhhdCBkb2Vz IHNvbWV0aGluZyB2ZXJ5IHNpbWlsYXIgKGxvb2sgZm9yIHRoZSBUTFMgUHJveHkpLg0KDQpTZXJ2 ZXJzIGhhdmUgYWx3YXlzIGhhZCB0aGUgYWJpbGl0eSB0byBzaGFyZSB3aGF0ZXZlciBpbmZvcm1h dGlvbiB0aGV5IHdhbnQgd2l0aCBvdGhlciBlbnRpdGllcy4gIFdlIGFyZSBub3QgdHJ5aW5nIHRv IGNoYW5nZSB0aGF0LiAgV2hhdCB0aGlzIGRyYWZ0IGRvZXMgaXMgZm9yY2UgY2xpZW50cyB0byBi ZWNvbWUgcGFydGllcyBpbiB0aGF0IGludGVyYWN0aW9uIGFuZCBzaWduYWwgaW4gdGhlIGNsZWFy IHRoYXQgdGhleSBhcmUgZG9pbmcgc28uICBUaGlzIGlzIGEgcmVhbGx5IGZ1bmRhbWVudGFsIGNo YW5nZSB0byBUTFMuDQoNCj4gU28sIG5vIEkgYW0gbm90IHdvcnJpZWQgYWJvdXQgdGhlICJyaXNr IiBvZiBjcmVhdGluZyBhIGNvbXBsaWNhdGVkIHdheSBmb3Igc2VydmVycyBhbmQgbWlkZGxlYm94 ZXMgdG8gY29sbHVkZSB0byBkbyBzb21ldGhpbmcgdGhhdCB0aGV5IGNhbiBhbHJlYWR5IGRvIG5v dyBpbiBhIHNpbXBsZXIgd2F5Lg0KDQpJIHRoaW5rIHlvdeKAmXJlIG5vdCBnZXR0aW5nIGl0LiAg U29ycnksIHByb2JhYmx5IG15IGZhdWx0IGZvciBub3QgYmVpbmcgYSB2ZXJ5IGdvb2QgZXhwbGFp bmVyLg0KDQoNCg0KDQoNCg== --_000_041E86E9493F4F208BD8A48296E0AFBEakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1C78D8ACA1B6814E9073DDAEA93DF619@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlm Ow0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFy Z2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciIsc2VyaWY7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjQxOTU2NzEwOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI5NDM1OTcxMDt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE5MzY2NzAxMDc7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjU4MTI2NjE0IC0xNDEzNTk4 NTUyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 DQoJY29sb3I6YmxhY2s7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMTps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci LHNlcmlmO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3Qg bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQomZ3Q7IEknbSBub3QgdGFraW5nIGFueSByaXNrLiZuYnNwOyBUaGUgYWJp bGl0eSBmb3IgYSBzZXJ2ZXIgdG8gYWxsb3cgYSB0aGlyZCBwYXJ0eSB0byBoYXZlIGFjY2VzcyB0 byBkYXRhIGl0IGlzIGV4Y2hhbmdpbmcgd2l0aCBhIGNsaWVudCBhbHJlYWR5IGV4aXN0cywgYW5k IHRoYXQgYWJpbGl0eSBpc24ndCBnb2luZyBhd2F5IHdoZXRoZXIgdGhpcyBwcm9wb3NhbCAob3Ig c29tZXRoaW5nIHNpbWlsYXIpIGlzIHN0YW5kYXJkaXplZCBvciBub3QuIEFzIEkndmUNCiBhbHJl YWR5IHBvaW50ZWQgb3V0LCBmb3IgdGhlIHNjZW5hcmlvcyBwZW9wbGUgYXJlIGNvbmNlcm5lZCBh Ym91dCwgdGhlICZxdW90O2F0dGFja3MmcXVvdDsgYmVpbmcgZGVzY3JpYmVkIHdvdWxkIGJlIG11 Y2ggbW9yZSBlYXNpbHkgY2FycmllZCBvdXQgYnkgc29tZSBtZWFucyBvdGhlciB0aGFuIGRyYWZ0 LXJocmQtdGxzLXRsczEzLXZpc2liaWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywg eW91IGFyZSB0YWtpbmcgYSByaXNrLiZuYnNwOyBPciwgcmF0aGVyLCB5b3UgYXJlIHByb3ZpZGlu ZyBhIHdheSBmb3IgYW55IG1pZGRsZWJveCB0byBmb3JjZSBjbGllbnRzIHRvIGFjcXVpZXNjZS4g Jm5ic3A7WW91IG1pZ2h0IHRoaW5rIGl04oCZcyBjb21wbGljYXRlZCwgYnV0IGl04oCZcyBub3Qu Jm5ic3A7IFRoZXJl4oCZcyBhIHBlcmwgc2NyaXB0IGluIHRoZSBPcGVuU1NMIGRpc3RyaWJ1dGlv biB0aGF0IGRvZXMgc29tZXRoaW5nIHZlcnkNCiBzaW1pbGFyIChsb29rIGZvciB0aGUgVExTIFBy b3h5KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VydmVycyBoYXZlIGFsd2F5cyBoYWQgdGhl IGFiaWxpdHkgdG8gc2hhcmUgd2hhdGV2ZXIgaW5mb3JtYXRpb24gdGhleSB3YW50IHdpdGggb3Ro ZXIgZW50aXRpZXMuJm5ic3A7IFdlIGFyZSBub3QgdHJ5aW5nIHRvIGNoYW5nZSB0aGF0LiZuYnNw OyBXaGF0IHRoaXMgZHJhZnQgZG9lcyBpcyBmb3JjZSBjbGllbnRzIHRvIGJlY29tZSBwYXJ0aWVz IGluIHRoYXQgaW50ZXJhY3Rpb24gYW5kIHNpZ25hbCBpbiB0aGUgY2xlYXIgdGhhdA0KIHRoZXkg YXJlIGRvaW5nIHNvLiZuYnNwOyBUaGlzIGlzIGEgcmVhbGx5IGZ1bmRhbWVudGFsIGNoYW5nZSB0 byBUTFMuPGJyPg0KPGJyPg0KJmd0OyBTbywgbm8gSSBhbSBub3Qgd29ycmllZCBhYm91dCB0aGUg JnF1b3Q7cmlzayZxdW90OyBvZiBjcmVhdGluZyBhIGNvbXBsaWNhdGVkIHdheSBmb3Igc2VydmVy cyBhbmQgbWlkZGxlYm94ZXMgdG8gY29sbHVkZSB0byBkbyBzb21ldGhpbmcgdGhhdCB0aGV5IGNh biBhbHJlYWR5IGRvIG5vdyBpbiBhIHNpbXBsZXIgd2F5Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB5b3XigJlyZSBub3QgZ2V0dGluZyBp dC4mbmJzcDsgU29ycnksIHByb2JhYmx5IG15IGZhdWx0IGZvciBub3QgYmVpbmcgYSB2ZXJ5IGdv b2QgZXhwbGFpbmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_041E86E9493F4F208BD8A48296E0AFBEakamaicom_-- From nobody Tue Oct 24 19:01:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC3F139976 for ; Tue, 24 Oct 2017 19:01:19 -0700 (PDT) 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 oXvYrMqFn2q1 for ; Tue, 24 Oct 2017 19:01:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A2613ACAB for ; Tue, 24 Oct 2017 19:01:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3CE89BE4C; Wed, 25 Oct 2017 03:01:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNqX7ZuDOqTU; Wed, 25 Oct 2017 03:01:12 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 445C0BE47; Wed, 25 Oct 2017 03:01:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508896872; bh=QBOuYS27/a5JE+X4tlTKU7TFzGARaMpmo5GI6H8HoWc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QHz9d9w/Cw9xsUszWLKXd9IHXrhe5kJrqM75UD2AOzaPS6TjnIcXuUOaHYSJwFB6v EiudBBlIzgM8TLw7b1s2eC3XGboBBMd9fhQbsO3AFpIDn2Et1mSDFF/NEyGuNp+0Xj HASyOTw7xtuHGhV27+V5+WblzpZi5OKDr5pxPgNA= To: "Ackermann, Michael" , "David A. Cooper" , "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <4ff287f3-fefa-d68a-ac56-52697d978ceb@cs.tcd.ie> Date: Wed, 25 Oct 2017 03:01:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="poxAlFAAN0pFd2NnwMT0JOssOvkwfFP3w" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 02:01:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --poxAlFAAN0pFd2NnwMT0JOssOvkwfFP3w Content-Type: multipart/mixed; boundary="mVxXnvS6MSuG1lcg7gnrNE7k4FDV7v8kN"; protected-headers="v1" From: Stephen Farrell To: "Ackermann, Michael" , "David A. Cooper" , "tls@ietf.org" Message-ID: <4ff287f3-fefa-d68a-ac56-52697d978ceb@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> In-Reply-To: --mVxXnvS6MSuG1lcg7gnrNE7k4FDV7v8kN Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Michael, What, in your message below, has not been said a number of times in this thread? (And countered effectively IMO.) I don't see anything - repeating points already countered is just disruptive noise, sorry. Thanks, S. On 25/10/17 01:41, Ackermann, Michael wrote: > Excellent points/questions and I just wanted to add that your final exa= mple, regarding hosting providers actually being a MitM, is EXTREMELY p= revalent in Enterprises today and is a management/ monitoring issue speci= fically pointed out by Steven Fenter in his presentation to the TLS WG in= Prague. > Without the ability to decrypt these sessions our ability to manage/mon= itor/secure is severely reduced. > And TLS, being a point to point protocol, cannot help in its current f= orm. >=20 > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of David A. Cooper > Sent: Tuesday, October 24, 2017 6:39 PM > To: tls@ietf.org > Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 >=20 > On 10/24/2017 05:18 PM, Salz, Rich wrote: >=20 >=20 > * And, I don't buy the idea that if this extension is standardized = that it will be implemented in commonly-used browsers. >=20 > And that is a risk you are willing for the entire public Internet to ta= ke? >=20 > I'm not taking any risk. The ability for a server to allow a third par= ty to have access to data it is exchanging with a client already exists, = and that ability isn't going away whether this proposal (or something sim= ilar) is standardized or not. As I've already pointed out, for the scenar= ios people are concerned about, the "attacks" being described would be mu= ch more easily carried out by some means other than draft-rhrd-tls-tls13-= visibility. >=20 > So, no I am not worried about the "risk" of creating a complicated way = for servers and middleboxes to collude to do something that they can alre= ady do now in a simpler way. >=20 >=20 > And what about the fact that it provides a cleartext signal as to wheth= er or not a client is willing to let itself be MiTM=E2=80=99d, does that = bother you? >=20 > No. As I noted before, servers can already allow middleboxes to MiTM co= nnections with clients with asking the client's permission. Public facing= servers that want to allow this (even if as a result of coercion) won't = use this extension. They'll just enable it without informing the clients.= >=20 > There are also other ways a server could allow a middlebox to MiTM the = connections that it has with clients that don't require the client's coop= eration (or knowledge) and that wouldn't require any changes on the clien= t side; ways that would be easier than trying to use draft-rhrd-tls-tls13= -visibility. >=20 > If the only way (or the easiest way) these connections could be MiTM'd = required getting clients' permission, then this might be a concern, I don= 't see servers that want to (or are coerced into) allowing connections to= be MiTM'd asking clients whether they are willing. Given this, we aren't= going to see browsers that are configurable to signal that the client is= willing to "allow" the connection to be MiTM'd. >=20 > I haven't even gotten into the question of what does it mean for a conn= ection to be MiTM'd. If Company X decides to have its web site operated b= y Hosting Provider Y is the connection between the client and Company X b= eing MiTM'd? The client might think it has a secure end-to-end connection= with Company X, but in reality its data is being intercepted and read by= Hosting Provider Y, without the client's permission (and most likely wit= hout the client's knowledge). How does TLS, currently, prevent this? Why = isn't anyone demanding that TLS cannot be standardized until it can be pr= oven that such a scenario is impossible? >=20 >=20 >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this comm= unication is directed. If you are not the intended recipient, you are her= eby notified that any viewing, copying, disclosure or distribution of thi= s information is prohibited. Please notify the sender, by electronic mail= or telephone, of any unintended receipt and delete the original message = without making any copies. > =20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan a= re nonprofit corporations and independent licensees of the Blue Cross and= Blue Shield Association. >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --mVxXnvS6MSuG1lcg7gnrNE7k4FDV7v8kN-- --poxAlFAAN0pFd2NnwMT0JOssOvkwfFP3w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ7/BnAAoJEC88hzaAX42iyIAIAIpDRcwrOIictz/UM+C6/1Hn EXGcmPaLF6/qiAcbXdAGVYmI8U0YnewDiAHFyhKpRE+/1xgblmyI19TT7orBOq7G ykwuoULuu1w96icEjb3k+GD3NHvfYtAE3o6EGelbzRdmekCvAt/GcUCYcFcxw5sa FI9qVBZcS7mUTp2l5Y9ay/9kG6WURASZ0bl3UORy5b3o7Jd8pp8i307Xgri9X5+Q oTfUpE/Hp6rqIpzEdSQC77Y15O7HsJ9n73PobDiRPjcw5lHaag2LlN6YKUM6MRFj iVX2ULBBW+0fN6CM4UOG3TY0yeU00hVJx7y13wRU2qA4LPQAzmAuPBZlP8QU+j4= =x8QJ -----END PGP SIGNATURE----- --poxAlFAAN0pFd2NnwMT0JOssOvkwfFP3w-- From nobody Tue Oct 24 19:13:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D08139438 for ; Tue, 24 Oct 2017 19:13:29 -0700 (PDT) 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 F5e0yp5hNmxe for ; Tue, 24 Oct 2017 19:13:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023B613942F for ; Tue, 24 Oct 2017 19:13:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A0152BE4C; Wed, 25 Oct 2017 03:13:25 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naqBigp41Nq5; Wed, 25 Oct 2017 03:13:24 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 41720BE47; Wed, 25 Oct 2017 03:13:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508897604; bh=6qzQeaEFyIHlj2biksnjKnZWInfjNRzfi/o/rjDm2EY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=0JqTitmYIqlh/86m4RQ8HCL1Y7jstg/82ClDUc8rC1en1dmHMUs48VIWI16pWTE33 uhOK3T63RFE6YZ3seYcl6DFdxPy42kX+hYgpL3I6fSGKjSQAjEQ8np4GIPvkwPppVU 4kqGPPCxmpj4k2onW6S0+R3osJpgX+vRq+vUvpzA= To: "David A. Cooper" , "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> Date: Wed, 25 Oct 2017 03:13:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DAdOLWqluNrfkUF1SWSMgD5Dm6IWp6NWP" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 02:13:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DAdOLWqluNrfkUF1SWSMgD5Dm6IWp6NWP Content-Type: multipart/mixed; boundary="KwbmXXdHD5KeAM0GcawxChrP7baSvfdMM"; protected-headers="v1" From: Stephen Farrell To: "David A. Cooper" , "tls@ietf.org" Message-ID: <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> In-Reply-To: <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> --KwbmXXdHD5KeAM0GcawxChrP7baSvfdMM Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable David, I'll go back over your mails tomorrow but was struck by this... On 24/10/17 23:39, David A. Cooper wrote: > I haven't even gotten into the question of what does it mean for a conn= ection to=20 > be MiTM'd. If Company X decides to have its web site operated by Hostin= g=20 > Provider Y is the connection between the client and Company X being MiT= M'd? The=20 > client might think it has a secure end-to-end connection with Company X= , but in=20 > reality its data is being intercepted and read by Hosting Provider Y, w= ithout=20 > the client's permission (and most likely without the client's knowledge= ). How=20 > does TLS, currently, prevent this? Why isn't anyone demanding that TLS = cannot be=20 > standardized until it can be proven that such a scenario is impossible?= That strikes me as an incredibly nihilist approach you (or NIST?) appear to be espousing, which is surprising. As a question back to you: would it be ok if NIST were to reinstate Dual-EC? If not why not? After all, (based on the above), all that'd happen is someone could do stuff that everyone knows (since 2008) can happen. (And no, with the current draft, the client does NOT know who the snooper is - it could be the NSA or the FSB and the client can't tell - and all that was already discussed on the list.) I suspect you'll say that it's better that NIST do not add Dual-EC back, (and I agree) because we're better off with honest crypto. And the same is true of TLS - it's a 2 party protocol and adding additional parties breaks all the trust models based on TLS. So it'd be equally good if NIST didn't espouse breaking TLS, at least IMO. If you can show me where you (or NIST or anyone) analysed all of the uses of TLS to check that there are no bad side effects, I'll be interested in reading that analysis. In the meantime, your personal evaluation of your risk is not something that I find convincing, sorry. S. --KwbmXXdHD5KeAM0GcawxChrP7baSvfdMM-- --DAdOLWqluNrfkUF1SWSMgD5Dm6IWp6NWP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ7/NDAAoJEC88hzaAX42ibZIH/jdp6XcX7WC7GOpgUsHZ1H/R WsSwQ02i7Q1GNws+3TA8SGTnQeLpY8tPVB647htG4aUDaJD0yngGcKkdqQsYCq+R QLyNPWcNL7DTf4owSOUnmw2AQsK8bpnpA41TYAFUrhC+Wg7Qova4tyvPRNlc/Zt9 UL2fIoeolP/BVgWNOYXZQfnQKRj+vKoyrFEpjsKRPAgZyyZlk4kHb+qqUjEJiQ/p m4oX9odesMN9fItd7ooKkPS5ZalxPTlzh49B0Od9vSBy6ma7G+uGJzypzz7gPQcK E13uGda386Ew/spZ+IG2IONnQjDsBFV5tE6a/1i5ymuNaUFgMsggzYsv1dgU0S8= =xGIG -----END PGP SIGNATURE----- --DAdOLWqluNrfkUF1SWSMgD5Dm6IWp6NWP-- From nobody Tue Oct 24 20:31:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF45013B0EA for ; Tue, 24 Oct 2017 20:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 1SRMioY2CXYz for ; Tue, 24 Oct 2017 20:31:24 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 7AC1813A092 for ; Tue, 24 Oct 2017 20:31:24 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id A04771C0987 for ; Tue, 24 Oct 2017 22:31:23 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id E131F1C0985; Tue, 24 Oct 2017 22:31:22 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A6451FE04E; Tue, 24 Oct 2017 23:31:22 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4AEACFE048; Tue, 24 Oct 2017 23:31:22 -0400 (EDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (unknown [216.32.181.24]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Tue, 24 Oct 2017 23:31:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fkVHRO2xS7wCXT8HUI6ONylXwUzz7YVLjVs9eFQuJ/g=; b=o6l1lEnE2LONslyXrUgix4k9bsChAz0fhBPGK/6aUqSKlFwzuR/9BYSZlKB6sFYySx1adAhrw2LESduV/mjb90qQJ10SINZib7ziY5KDaAMwUJTG3wgJmVj/J4Aslnw+eD6ZTdoZ2JJgpfBNEpynt3Eolle/eTpDn2PHKORWRDw= Received: from BN6PR14MB1361.namprd14.prod.outlook.com (10.172.149.135) by BN6PR14MB1364.namprd14.prod.outlook.com (10.172.149.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Wed, 25 Oct 2017 03:31:19 +0000 Received: from BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) by BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) with mapi id 15.20.0156.005; Wed, 25 Oct 2017 03:31:19 +0000 From: "Ackermann, Michael" To: Stephen Farrell , "David A. Cooper" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5HVvcnaInjUunozwwxCXv1qLzYRoAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjPAIAAAkyAgAAWooCAACCFcIAAF/KAgAAE61A= Date: Wed, 25 Oct 2017 03:30:49 +0000 Deferred-Delivery: Wed, 25 Oct 2017 03:30:00 +0000 Message-ID: References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <4ff287f3-fefa-d68a-ac56-52697d978ceb@cs.tcd.ie> In-Reply-To: <4ff287f3-fefa-d68a-ac56-52697d978ceb@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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.57] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1364; 20:7394xnP/JnvPQetOQmmwh9ye8uIFBA6ADDPfnR2N4g/PsV/yg1sGlzhGS9br4Z3T+Nmzdcgj8n3f6wDST8lu8IHXH6N6sfHffZz86jHdg313OTUgoLGfiAKfjtuwgg0NnkKN7C3vfW7uizDzAvtN8VQi4h8ekdi4gUVfG7+NEOc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0e0e5ab7-7d4c-4641-60a4-08d51b58db7b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR14MB1364; x-ms-traffictypediagnostic: BN6PR14MB1364: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(65766998875637)(72170088055959)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR14MB1364; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR14MB1364; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(85714005)(24454002)(189002)(199003)(51694002)(13464003)(966005)(2501003)(99286003)(33656002)(6246003)(50986999)(76176999)(54356999)(77096006)(230783001)(305945005)(6306002)(3660700001)(8936002)(86362001)(81166006)(7736002)(8656006)(106356001)(105586002)(81156014)(74316002)(53936002)(53546010)(55016002)(9686003)(8676002)(3280700002)(6116002)(66066001)(2906002)(110136005)(2950100002)(561944003)(97736004)(316002)(102836003)(3846002)(229853002)(72206003)(80792005)(189998001)(68736007)(5660300001)(6436002)(478600001)(7696004)(25786009)(93886005)(14454004)(6666003)(6506006)(2900100001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1364; H:BN6PR14MB1361.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e0e5ab7-7d4c-4641-60a4-08d51b58db7b X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2017 03:31:19.3504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1364 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: fceb14e5-1ff2-4bde-b9f2-3bd6a6620bfe X-VPM-MSG-ID: 5961601d-3522-467c-a5f4-d31da2b19e94 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 03:31:27 -0000 Sorry, My turn to disagree. =20 I don't believe any points stated by David or myself had been stated = previously nor =22Countered=22. =20 And if =22Countered=22 means you disagree with the assertions, then you = are saying that hosting providers are NOT doing MitM and that TLS is a = multipoint protocol. And once again I disagree. =20 But since I too deplore =22Noise=22, I will comment no further on these = aspects of the conversation and we can agree to disagree. =20 -----Original Message----- From: Stephen Farrell =5Bmailto:stephen.farrell=40cs.tcd.ie=5D=20 Sent: Tuesday, October 24, 2017 10:01 PM To: Ackermann, Michael ; David A. Cooper = ; tls=40ietf.org Subject: Re: =5BTLS=5D Publication of draft-rhrd-tls-tls13-visibility-00 Michael, What, in your message below, has not been said a number of times in this = thread? (And countered effectively IMO.) I don't see anything - repeating = points already countered is just disruptive noise, sorry. Thanks, S. On 25/10/17 01:41, Ackermann, Michael wrote: > Excellent points/questions and I just wanted to add that your final = example, regarding hosting providers actually being a MitM, is EXTREMELY = prevalent in Enterprises today and is a management/ monitoring issue = specifically pointed out by Steven Fenter in his presentation to the TLS = WG in Prague. > Without the ability to decrypt these sessions our ability to = manage/monitor/secure is severely reduced. > And TLS, being a point to point protocol, cannot help in its current = form. >=20 > From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of David A. Cooper > Sent: Tuesday, October 24, 2017 6:39 PM > To: tls=40ietf.org > Subject: Re: =5BTLS=5D Publication of draft-rhrd-tls-tls13-visibility-00 >=20 > On 10/24/2017 05:18 PM, Salz, Rich wrote: >=20 >=20 > * And, I don't buy the idea that if this extension is standardized = that it will be implemented in commonly-used browsers. >=20 > And that is a risk you are willing for the entire public Internet to take? >=20 > I'm not taking any risk. The ability for a server to allow a third = party to have access to data it is exchanging with a client already = exists, and that ability isn't going away whether this proposal (or = something similar) is standardized or not. As I've already pointed out, = for the scenarios people are concerned about, the =22attacks=22 being = described would be much more easily carried out by some means other than = draft-rhrd-tls-tls13-visibility. >=20 > So, no I am not worried about the =22risk=22 of creating a complicated = way for servers and middleboxes to collude to do something that they can = already do now in a simpler way. >=20 >=20 > And what about the fact that it provides a cleartext signal as to = whether or not a client is willing to let itself be MiTM'd, does that = bother you? >=20 > No. As I noted before, servers can already allow middleboxes to MiTM = connections with clients with asking the client's permission. Public = facing servers that want to allow this (even if as a result of coercion) = won't use this extension. They'll just enable it without informing the = clients. >=20 > There are also other ways a server could allow a middlebox to MiTM the = connections that it has with clients that don't require the client's = cooperation (or knowledge) and that wouldn't require any changes on the = client side; ways that would be easier than trying to use = draft-rhrd-tls-tls13-visibility. >=20 > If the only way (or the easiest way) these connections could be MiTM'd = required getting clients' permission, then this might be a concern, I = don't see servers that want to (or are coerced into) allowing connections = to be MiTM'd asking clients whether they are willing. Given this, we = aren't going to see browsers that are configurable to signal that the = client is willing to =22allow=22 the connection to be MiTM'd. >=20 > I haven't even gotten into the question of what does it mean for a = connection to be MiTM'd. If Company X decides to have its web site = operated by Hosting Provider Y is the connection between the client and = Company X being MiTM'd? The client might think it has a secure end-to-end = connection with Company X, but in reality its data is being intercepted = and read by Hosting Provider Y, without the client's permission (and most = likely without the client's knowledge). How does TLS, currently, prevent = this? Why isn't anyone demanding that TLS cannot be standardized until it = can be proven that such a scenario is impossible? >=20 >=20 >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. > =20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS=40ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Tue Oct 24 23:49:02 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8ED139436 for ; Tue, 24 Oct 2017 23:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEm4fXRRvTTf for ; Tue, 24 Oct 2017 23:48:59 -0700 (PDT) Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com [209.85.128.177]) (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 4759613942F for ; Tue, 24 Oct 2017 23:48:59 -0700 (PDT) Received: by mail-wr0-f177.google.com with SMTP id 15so9018012wrb.5 for ; Tue, 24 Oct 2017 23:48:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=u043i/j5piKypuo3bIJkPqunFyCL4eJSSSiexJXyOwo=; b=d++3TMNq4xWao9iqbRP4easfAakzDeTf1JMyU3ryuQrmtcQJqYTYqVFxD1hbxjYJkF OlHVHjtL4D0wVufXlZxNh3je/UsRRxCaZOmcv4lxyXM+SsOhESQlW+cX8rdEd6mtRkNX PFArxiOVNGlC3UXKSOkhS/gp5xBLlmZ8fsPy8luvvRYDS9d2e0PNl0Icrzhhu3f9HO55 YH9ZccpPU8fUvIk9QwZC8K+9lTRa4y1BODgWU1/eK6jwq6PIabCtdX7Nx1DoNfkZaMdd ji6MXBevpWp3HNvOVbKrBRERZPaIJmwNLX48+nP1BLgDJnCFQV0IUo0Hm7Db0FR0BBQs xGkg== X-Gm-Message-State: AMCzsaWMW9JfkUGLUa0rj3Qbx5rkbVH5pD3nhynvuivbRSeDNxUXDxnN sLiDS4aAqgaqnojR+wXCx+27mVJUvmI= X-Google-Smtp-Source: ABhQp+RpRu1iH/sw4KMef5HuQcSeo+o7eLuBy66o4hu0JZoyuLN62x9JQ8tLPY6dfB81zopHXFG7NA== X-Received: by 10.223.150.204 with SMTP id u70mr977848wrb.115.1508914137745; Tue, 24 Oct 2017 23:48:57 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id o20sm1930691wro.6.2017.10.24.23.48.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Oct 2017 23:48:56 -0700 (PDT) Message-ID: <1508914136.10114.41.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla , "tls@ietf.org" Date: Wed, 25 Oct 2017 08:48:56 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 06:49:01 -0000 On Mon, 2017-10-23 at 18:14 -0700, Eric Rescorla wrote: > We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. > > The one thing we ran into was the potential need to ACK in cases > where you > can't process *any* records (e.g., you receive what's actually EE, > but you > can't decrypt it). In this case, you want to send an empty ACK. > > See PR: > https://github.com/tlswg/dtls13-spec/pull/14 Would it make sense to spell out the goals (and maybe some motivation) for the DTLS 1.3 revision in the draft? The TLS WG charter contains the goals for the TLS 1.3 revision but changes in DTLS like the ACK although nice, seem to be unrelated to them. regards, Nikos From nobody Wed Oct 25 02:24:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55E13B12A for ; Wed, 25 Oct 2017 02:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm0tSJBWdO0h for ; Wed, 25 Oct 2017 02:24:35 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71383139950 for ; Wed, 25 Oct 2017 02:24:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 334A15DE7D; Wed, 25 Oct 2017 12:24:32 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Vx8Q09nsVJbL; Wed, 25 Oct 2017 12:24:31 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 547432315; Wed, 25 Oct 2017 12:24:28 +0300 (EEST) Date: Wed, 25 Oct 2017 12:24:27 +0300 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20171025092427.sxgnp56y3zpha2bt@LK-Perkele-VII> References: <1508914136.10114.41.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1508914136.10114.41.camel@redhat.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 09:24:37 -0000 On Wed, Oct 25, 2017 at 08:48:56AM +0200, Nikos Mavrogiannopoulos wrote: > On Mon, 2017-10-23 at 18:14 -0700, Eric Rescorla wrote: > > We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. > > > > The one thing we ran into was the potential need to ACK in cases > > where you > > can't process *any* records (e.g., you receive what's actually EE, > > but you > > can't decrypt it). In this case, you want to send an empty ACK. > > > > See PR: > > https://github.com/tlswg/dtls13-spec/pull/14 > > Would it make sense to spell out the goals (and maybe some motivation) > for the DTLS 1.3 revision in the draft? The TLS WG charter contains the > goals for the TLS 1.3 revision but changes in DTLS like the ACK > although nice, seem to be unrelated to them. The ACK message has two goals: The more important one: To acknowledge some flights that do not have reply messages. NewSessionTicket is especially relevant case. Also client authentication flights. The less important one: To reduce amount that needs to be retransmitted on packet loss. -Ilari From nobody Wed Oct 25 05:48:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68624138239 for ; Wed, 25 Oct 2017 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3v11r7Cbhnto for ; Wed, 25 Oct 2017 05:48:06 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1DA1377B3 for ; Wed, 25 Oct 2017 05:48:06 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9PCgjcV002463; Wed, 25 Oct 2017 13:48:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=sYqsGdrOYG6NZN5WBep5N7qesJvrkuwBvUSE50Ur1VI=; b=mCeqd5Uui3eRUn13U+57k+1SusmFwhu/281wxcEUQXogZ72koiu4QxyxumTOWnJ8spUS y+0voxDzkFRXV/XB9+JqttI99irSoESxkK2XjIc6Uz4pVOX6co2aeCC7jZTiOUS5KroH YJMIH2tUoTT06O7lB7p/cbIuMkXKhkYoqzrarbc9RZt5B4JroEKwdHWrfvyF+bj7wKFq GzqLayOEKcYMR9YAvQEIpGfGKDguyKwNCgTd62x+DyIdb+jLNz0ExVK1MhuxounbamW8 XuUmif5T3lnEdv3wS63wdQ7cr8gc2kODDeFxUZ/FEbatNpYpM/MUJgH+VqFl5gEZBxVh vw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2dquad5cun-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 13:48:03 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9PCkwiR000481; Wed, 25 Oct 2017 08:48:02 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dr1jvpcce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 08:48:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 08:48:01 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 25 Oct 2017 08:48:00 -0400 From: "Salz, Rich" To: "Ackermann, Michael" , "David A. Cooper" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjQAIAAAkoAgAAWo4CAACJOAIAAFimAgAAZC4CAAJuvAA== Date: Wed, 25 Oct 2017 12:48:00 +0000 Message-ID: <831AE1AF-C24F-4D12-A182-03EAB40F036A@akamai.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <4ff287f3-fefa-d68a-ac56-52697d978ceb@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.58] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250176 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250175 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 12:48:08 -0000 QmVmb3JlIHlvdSBsZWF2ZSwgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHF1ZXN0aW9ucyBzdGlsbCB1 bmFuc3dlcmVkLg0KDQoxIENhbiB0aGlzIGRyYWZ0IGVuYWJsZSBhbiBhY3RpdmUgYXR0YWNrZXIg dG8gbW9kaWZ5IHRyYWZmaWM/ICBJZiBub3QsIHRoZW4gdGhlbiBob3cgaXMgdGhhdCBwcmV2ZW50 ZWQ/DQoNCjIgQ2FuIHRoaXMgZHJhZnQgYmUgdXNlZCB0byBzZWdyZWdhdGUgdHJhZmZpYyBzbyB0 aGF0IG9ubHkgdGhvc2Ugd2lsbGluZyB0byBiZSBpbnRlcmNlcHRlZCBjYW4gYmUgaGFuZGxlZCBz ZXBhcmF0ZWx5IGZyb20gdGhvc2UgdW53aWxsaW5nPw0KDQozIERvIHlvdSB0aGluayB0aGF0IHRo aXMgZHJhZnQgd2lsbCByZXF1aXJlIHplcm8gY2hhbmdlcyB0byB5b3VyIGluZnJhc3RydWN0dXJl PyAgSG93IGRvZXMgdGhhdCBjb3N0IGVzdGltYXRlIGNvbXBhcmUgd2l0aCwgc2F5LCB0aGUgc2Vy dmVyIGp1c3Qgc2VuZGluZyB0aGUgUEZTIHNlc3Npb24ga2V5IHRvIHRoZSBpbmZyYXN0cnVjdHVy ZT8NCg0KNCBXaGF0IHBlcmNlbnRhZ2Ugb2YgdHJhZmZpYyBpbiB5b3VyIGVudGVycHJpc2UgaXMg VExTIDEuMiBub3c/ICAoWWVzLCB0aGF04oCZcyBhIG5ldyBxdWVzdGlvbiBJIGFkbWl0KQ0KDQo1 IFdoZW4gZG8geW91IHRoaW5rIHlvdSB3aWxsIOKAnGhhdmXigJ0gdG8gbW92ZSB0byBUTFMgMS4z LCByb3VuZCBpdCB0bywgc2F5IGZpdmUgeWVhcnMuDQoNCjYgV2hhdCBpcyB0aGUganVzdGlmaWNh dGlvbiBmb3IgdGhpcyBhcHByb2FjaCwgb3RoZXIgdGhhbiB5b3UgdGhpbmsgaXQgd2lsbCBiZSBh IOKAnGhhcmQgc2VsbOKAnSB0byBjb252aW5jZSBleGVjdXRpdmVzIHRvIGRvIHRoZSB3b3JrIG5l ZWRlZD8gIEnigJl2ZSBzZWVuIG5vIG90aGVyIHJlYXNvbnMgZGlzY3Vzc2VkIGFuZCBhbSBjdXJp b3VzIHRvIHNlZSBob3cgdGhpcyByZXNwb25zZSBhbmQgIzMgYWxpZ24uDQoNCg0KDQo= From nobody Wed Oct 25 07:23:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5720F138726 for ; Wed, 25 Oct 2017 07:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VYILzchK9AwG for ; Wed, 25 Oct 2017 07:23:44 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DB713B47F for ; Wed, 25 Oct 2017 07:23:43 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 10:23:33 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Wed, 25 Oct 2017 10:23:40 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9PENMw0009117; Wed, 25 Oct 2017 10:23:22 -0400 To: Stephen Farrell References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> CC: "tls@ietf.org" From: "David A. Cooper" Message-ID: <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> Date: Wed, 25 Oct 2017 10:23:22 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 14:23:47 -0000 Everything I have stated is my personal opinion. Note that I never suggested that I like or am espousing a certain approach, I was simply stating a fact. In many cases today, a TLS connect that appears to a client to be terminating a one place (Company X) is actually terminating somewhere else (Hosting Provider Y) without any clear indication to the client that the connection is terminating at Hosting Provider Y. Nobody has suggested that this is unacceptable or that TLS is broken if it can't prevent that. TLS is not an end-to-end protocol, it is a point-to-point protocol, and as noted in hosting company example, which you claim to find so troubling, it isn't always clear to either party what's at the other end of the connection. It might be the entity the client thinks its connecting to (Company X), it might be a hosting provider acting on behalf of Company X, or it might be something else. The best the client can hope for with things like TLS, PKIX, TRANS, etc., is that the server end of the connection is either Company X or some entity authorized by Company X to act as Company X for the purpose of being the connection endpoint (and, yes, Company X may have been coerced into authorizing some other entity to covertly act as the server endpoint). I am not saying that I like this or am "espousing" it, I am simply pointing out a fact. Similarly, the best that TLS can offer in terms of privacy is that the contents of the communication between the two endpoints is not seen by anyone else *unless* at least one of the two endpoints (client or server) chooses to provide the contents of the communication to some other entity. draft-rhrd-tls-tls13-visibility doesn't change that. It is also a fact that once a client provides data to a server, there are no technical mechanisms that would allow the client to limit what the server does with that data. As has been show over and over again, including by you, it is very frequently the case that the server that initially receives the data passes it on to others. The others may be back-end database servers or anti-virus scanners, but the client has no control over what happens to the data once the server receives it. I have not tried to argue that draft-rhrd-tls-tls13-visibility is the best solution for addressing the need for visibility within the data center. Perhaps it is, perhaps it isn't. But, I'm tired of the abusive and false suggestions that draft-rhrd-tls-tls13-visibility is a "wiretapping" draft or that it is defining a "please-screw-me extension." These suggestions have been repeated over and over again, even though they have already been countered effectively - "repeating points already countered is just disruptive noise." On 10/24/2017 10:13 PM, Stephen Farrell wrote: > David, > > I'll go back over your mails tomorrow but was struck by this... > > On 24/10/17 23:39, David A. Cooper wrote: >> I haven't even gotten into the question of what does it mean for a connection to >> be MiTM'd. If Company X decides to have its web site operated by Hosting >> Provider Y is the connection between the client and Company X being MiTM'd? The >> client might think it has a secure end-to-end connection with Company X, but in >> reality its data is being intercepted and read by Hosting Provider Y, without >> the client's permission (and most likely without the client's knowledge). How >> does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot be >> standardized until it can be proven that such a scenario is impossible? > That strikes me as an incredibly nihilist approach you > (or NIST?) appear to be espousing, which is surprising. > > As a question back to you: would it be ok if NIST were > to reinstate Dual-EC? If not why not? After all, (based > on the above), all that'd happen is someone could do > stuff that everyone knows (since 2008) can happen. (And > no, with the current draft, the client does NOT know who > the snooper is - it could be the NSA or the FSB and the > client can't tell - and all that was already discussed > on the list.) > > I suspect you'll say that it's better that NIST do not > add Dual-EC back, (and I agree) because we're better off > with honest crypto. And the same is true of TLS - it's > a 2 party protocol and adding additional parties breaks > all the trust models based on TLS. So it'd be equally > good if NIST didn't espouse breaking TLS, at least IMO. > > If you can show me where you (or NIST or anyone) analysed > all of the uses of TLS to check that there are no bad side > effects, I'll be interested in reading that analysis. In > the meantime, your personal evaluation of your risk is not > something that I find convincing, sorry. > > S. > From nobody Wed Oct 25 07:28:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D913138726 for ; Wed, 25 Oct 2017 07:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 43_xxtMoE_Dt for ; Wed, 25 Oct 2017 07:28:30 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845EC1384B2 for ; Wed, 25 Oct 2017 07:28:30 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9PEOaV6009121; Wed, 25 Oct 2017 15:28:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=KoT0ci03dAYJjojrj/Em0/wLWuNQ+2BbWPHg4OCD4/0=; b=P+U3vvx5wwaudqcDmiD1ebud00XjCO8LoTEtJ8IiPWG89XmoMvuoFr9SpLwfhEDJv4iK b6xj0cAKyloKIlqhJ2Yf4tRNYKYHKUl74ab7OKBcYQMJlAC2FnrbvWsJYn4vt2pRUVe0 KJ3qiVl2I4Se3CKj4iE6WLv81dcRjmV/ZI2nsCWK/AxiMV9Oe3YWFDhuDiaYLKkwQr4y BEV8w+zEjBqP1wSmnP3VSUge5NRZBDK+RH02dH02F4zIL+jxZqpGmqCbCHm3xHqs1aTl obpN2LqBSf/4CP/xqFyCHAoByTH9Tpj4mzcdiRevzNRObwVGv765+8jzA5qkntJE0Wdk 4Q== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2dqwvt4g42-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 15:28:25 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9PEQ98w017603; Wed, 25 Oct 2017 10:28:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dr1jvpphu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 10:28:23 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 10:28:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 10:28:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 25 Oct 2017 10:28:20 -0400 From: "Salz, Rich" To: "David A. Cooper" , Stephen Farrell CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjQAIAAAkoAgAAWo4CAADvggIAAy/QAgAABYwA= Date: Wed, 25 Oct 2017 14:28:20 +0000 Message-ID: <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> In-Reply-To: <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.23] Content-Type: text/plain; charset="utf-8" Content-ID: <1B837B59C953494CB9D1086DF11E822A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250192 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250195 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 14:28:31 -0000 DQrinqIgICAgIFNpbWlsYXJseSwgdGhlIGJlc3QgdGhhdCBUTFMgY2FuIG9mZmVyIGluIHRlcm1z IG9mIHByaXZhY3kgaXMgdGhhdCB0aGUgDQogICAgY29udGVudHMgb2YgdGhlIGNvbW11bmljYXRp b24gYmV0d2VlbiB0aGUgdHdvIGVuZHBvaW50cyBpcyBub3Qgc2VlbiBieSANCiAgICBhbnlvbmUg ZWxzZSAqdW5sZXNzKiBhdCBsZWFzdCBvbmUgb2YgdGhlIHR3byBlbmRwb2ludHMgKGNsaWVudCBv ciANCiAgICBzZXJ2ZXIpIGNob29zZXMgdG8gcHJvdmlkZSB0aGUgY29udGVudHMgb2YgdGhlIGNv bW11bmljYXRpb24gdG8gc29tZSANCiAgICBvdGhlciBlbnRpdHkuIGRyYWZ0LXJocmQtdGxzLXRs czEzLXZpc2liaWxpdHkgZG9lc24ndCBjaGFuZ2UgdGhhdC4NCiAgICANClllcyBpdCBkb2VzLiAg SXQgc2lnbmFscyBvbiB0aGUgd2lyZSB0byBhbnkgb2JzZXJ2ZXIgdGhhdCB0aGUgY2xpZW50IGFu ZCBzZXJ2ZXIgYWdyZWUgdG8gdGhpcy4gIFRMUyBuZXZlciBhdHRlbXB0ZWQgdG8gY29udHJvbCB3 aGF0IHRoZSBjbGllbnQgb3Igc2VydmVyIGNvdWxkIGRvLiBCdXQgaXQgbmV2ZXIgcHV0IGFueSBz dWNoIHNpZ25hbCBvbiB0aGUgd2lyZS4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgYW5kIGZ1bmRhbWVu dGFsIGNoYW5nZSwgYW5kIGl0IGFsbG93cyB0cmFmZmljIHRvIGJlIGNhdGVnb3JpemVkIGFuZCBo YW5kbGVkIGRpZmZlcmVudGx5Lg0KDQpEbyB5b3UgYWdyZWUgd2l0aCB0aGF0Pw0KDQo= From nobody Wed Oct 25 07:50:26 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2420413ED2D for ; Wed, 25 Oct 2017 07:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4OEmzjQ8lu0i for ; Wed, 25 Oct 2017 07:50:22 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0E013EB4D for ; Wed, 25 Oct 2017 07:50:22 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 10:51:43 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Wed, 25 Oct 2017 10:50:20 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9PEo03L011433 for ; Wed, 25 Oct 2017 10:50:00 -0400 To: "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> From: "David A. Cooper" Message-ID: Date: Wed, 25 Oct 2017 10:50:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 14:50:25 -0000 This question is based on your that belief that this protocol will "escape" onto the public Internet, that browsers and other clients used by individuals will feel forced to implement it, and that clients will then be forced to enable the extension in order to get through middleboxes that would filter traffic based on whether or not the extension is present in the ClientHello. I've already explained why I believe that scenario will never happen, and so no I do not agree that it is a "fundamental change." The idea of a client extension was added based on feedback at the Prague meeting in order to help prevent the protocol from being used over the public Internet, by preventing the protocol from being used without the client's knowledge. Obviously you believe that the method being proposed to address one concern introduces another concern. I do not share those concerns for the reasons that I've already stated. I don't plan to comment on this issue any further, and doing so would just be repeating myself, thus just adding to the noise. On 10/25/2017 10:28 AM, Salz, Rich wrote: > ➢ Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not seen by > anyone else *unless* at least one of the two endpoints (client or > server) chooses to provide the contents of the communication to some > other entity. draft-rhrd-tls-tls13-visibility doesn't change that. > > Yes it does. It signals on the wire to any observer that the client and server agree to this. TLS never attempted to control what the client or server could do. But it never put any such signal on the wire. This is an important and fundamental change, and it allows traffic to be categorized and handled differently. > > Do you agree with that? > From nobody Wed Oct 25 07:56:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F85B13F3C7 for ; Wed, 25 Oct 2017 07:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 11rQG30C-e2k for ; Wed, 25 Oct 2017 07:56:25 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D165413F3BF for ; Wed, 25 Oct 2017 07:56:24 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9PEsB1N029938; Wed, 25 Oct 2017 15:56:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=uvRQqFyANUmdX/rvbUL4c+LcjDgM5N3sAvXRe0t18NA=; b=QtKvMIxV7Yr9ePL7dy7vSLGvDN4G7rmwDJ4YHk6c3p+e/UlR1oi6Efidc2EbEbCbfsMF HOQzS8/MGkE5cAOYoiSPM3afJxRVb8PQeE/L0gFhkUcVpy+duu9D+DGxBiTHCKU/L8e2 JeFu5Zc/sGi18Z3t+OYFGjgTMDDHMiDZcL4eswY/x8DhwHWZADaCpc4DTAZJi5gz+gEZ EcajaTKU6+UOXFxfi9NZpwJ3rgXwJupqCDVtcivEOI0SGL3MFBj8a6dPSWT0m0rcyC+H JZvN5mMUZeJP+cebKffOShAI0yQgtYZ9qVltfttS+oPIjmfjTKVOENQbkrYfrAMEbUba SA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2dquad5q98-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 15:56:22 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9PEuDqO026419; Wed, 25 Oct 2017 10:56:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dr1jumfgt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 10:56:21 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 10:56:21 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 10:56:21 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 25 Oct 2017 10:56:20 -0400 From: "Salz, Rich" To: "David A. Cooper" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjQAIAAAkoAgAAWo4CAADvggIAAy/QAgAABYwCAAAYOAIAAAcUA Date: Wed, 25 Oct 2017 14:56:20 +0000 Message-ID: References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@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/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.23] Content-Type: text/plain; charset="utf-8" Content-ID: <0E35F354E61ADD41B5CDA99CA613457E@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250201 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 14:56:26 -0000 PiAgICBUaGlzIHF1ZXN0aW9uIGlzIGJhc2VkIG9uIHlvdXIgdGhhdCBiZWxpZWYgdGhhdCB0aGlz IHByb3RvY29sIHdpbGwgImVzY2FwZSIgb250byB0aGUgcHVibGljIEludGVybmV0DQoNClllcy4g IEFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91IGRvbuKAmXQgYmVsaWV2ZSB0aGF0IHRoZSBlbnRlcnBy aXNlIHZpc2liaWxpdHkgd2lsbCBzdG9wIGF0IHRoZWlyIGZpcmV3YWxsPyAgVGhhdCB0aGV5IHdp bGwgYWxsb3cg4oCYc3RvY2vigJkgVExTIDEuMyB0byB3b3JrIGNvbm5lY3RpbmcgdG8gdGhlaXIg c2l0ZXM/ICBUaGF0IHRoZSBhaXJwbGFuZS93aWZpIHByb3ZpZGVyIHdvbuKAmXQgc2F5IOKAmGRv d25sb2FkIG91ciBmcmVlIGJyb3dzZXLigJk/DQoNCkkgdGhpbmsgeW914oCZcmUgYmVpbmcgdmVy eSBuYcOvdmUgdG8gdGhpbmsgb3RoZXJ3aXNlLg0KDQoNCg== From nobody Wed Oct 25 08:18:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A68D13F3F1 for ; Wed, 25 Oct 2017 08:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5D9R7rPv2dll for ; Wed, 25 Oct 2017 08:18:16 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E830D13F3E3 for ; Wed, 25 Oct 2017 08:18:14 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 11:18:05 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Wed, 25 Oct 2017 11:18:13 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9PFI2wE014013; Wed, 25 Oct 2017 11:18:03 -0400 To: "Salz, Rich" , "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> From: "David A. Cooper" Message-ID: <4f1b6a8d-688b-a286-6d0e-46f7f6a3cdd6@nist.gov> Date: Wed, 25 Oct 2017 11:18:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 15:18:18 -0000 I've already responded to this! Why are you wasting everyone's time by asking the same questions over and over, even though I've already clearly answered them? An airplane/wifi provider might say "download our free browser," but it won't rely on draft-rhrd-tls-tls13-visibility to snoop on its customers. If the airplane/wifi provider controls the software on its customers' computers, it doesn't need the cooperation of the servers that the customers are connecting to in order to snoop, so it wouldn't go through the effort of trying to get that cooperation. And, if the airplane/wifi provider has the cooperation of the servers that the customers are connecting to it doesn't need to convince its customers to download any software or in any other way get the customers to cooperate in allowing the snooping, so it won't bother.. If you believe otherwise, then you are the one who is being very naïve. I can't guarantee that enterprise visibility will stop at the enterprise firewall. My argument is simply that use of the protocol in this draft will stop at the enterprise firewall since outside the firewall, when communicating with clients outside of the enterprise's control, the enterprises that want to enable "visibility" into such traffic will use other means that don't require the the cooperation or knowledge of the clients, since those other means would be easier and more effective. You have done nothing to suggest otherwise. On 10/25/2017 10:56 AM, Salz, Rich wrote: >> This question is based on your that belief that this protocol will "escape" onto the public Internet > Yes. Are you saying that you don’t believe that the enterprise visibility will stop at their firewall? That they will allow ‘stock’ TLS 1.3 to work connecting to their sites? That the airplane/wifi provider won’t say ‘download our free browser’? > > I think you’re being very naïve to think otherwise. > > From nobody Wed Oct 25 09:07:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0347C13AE04 for ; Wed, 25 Oct 2017 09:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 hvFownp7BDGk for ; Wed, 25 Oct 2017 09:07:02 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4545B138F83 for ; Wed, 25 Oct 2017 09:07:02 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9PFuT8G010137; Wed, 25 Oct 2017 17:07:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=nSPoZZkXTNwPG7Fud683dUJpE3WlhyOE6DdRYI6iXsc=; b=l6X6hr24sfJQ1JiONIyY4qWZFHB/7Qz0/U/yQXAQTix2X1PcfcOmZ47tzKyZ7Szsc46S Tw7ywPS5cA2Z4AhX4ReU2ByJccmOnRDrbr8ZWSJqpyws7PReriOkXjXJ0D4cbTp25fTo tVdVldWPf+fIoktZzzZ3QE7KqUAE+CuRYkhHG23sTksNYtvIXXQAud6fhIR4j8h2vMwa XiosVPVTgP4bGIw1/A5+Aff2DF6npYtiioM5QgXiTpC056gSt6pqFI3Wa6ruTq9SdYIc L6lKj9z4EfvPm6UC7TUpsCwKoDLxmLxqFF7jk9M3PFHdIuOHuW+1iBT+fuJ0W1qiJHDs uA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2dtky49mm5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 17:07:00 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9PG1ZEO007123; Wed, 25 Oct 2017 12:06:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dr1jvq1yu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 12:06:59 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 12:06:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 25 Oct 2017 12:06:46 -0400 From: "Salz, Rich" To: "David A. Cooper" CC: "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjQAIAAAkoAgAAWo4CAADvggIAAy/QAgAABYwCAAAYOAIAAAcUAgAAGEACAAA2cAA== Date: Wed, 25 Oct 2017 16:06:46 +0000 Message-ID: References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> <4f1b6a8d-688b-a286-6d0e-46f7f6a3cdd6@nist.gov> In-Reply-To: <4f1b6a8d-688b-a286-6d0e-46f7f6a3cdd6@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.95] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250213 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250211 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:07:08 -0000 PiBzaW5jZSB0aG9zZSBvdGhlciBtZWFucyB3b3VsZCBiZSBlYXNpZXIgYW5kIG1vcmUgZWZmZWN0 aXZlLiBZb3UgDQogICAgaGF2ZSBkb25lIG5vdGhpbmcgdG8gc3VnZ2VzdCBvdGhlcndpc2UuDQog IA0KUHVibGljLWtleSBwaW5uaW5nIGFuZCBDVCBzZWVtIGxpa2UgdGhleSB3b3VsZCBwcmV2ZW50 IHRob3NlIG90aGVyIG1lY2hhbmlzbXMuICBObz8NCg0K From nobody Wed Oct 25 09:11:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665D2139101 for ; Wed, 25 Oct 2017 09:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 tvNalJ9Mud0f for ; Wed, 25 Oct 2017 09:11:43 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.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 124CC138F83 for ; Wed, 25 Oct 2017 09:11:43 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 798E4C0DBF for ; Wed, 25 Oct 2017 11:11:42 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id E5070C0DAE; Wed, 25 Oct 2017 11:11:41 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AB41AFE0F0; Wed, 25 Oct 2017 12:11:41 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 50F78FE04E; Wed, 25 Oct 2017 12:11:41 -0400 (EDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (unknown [216.32.181.24]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Wed, 25 Oct 2017 12:11:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0oH2yvYiobsdYTLC8LBwJ5wU9z6g0sdjaV1k5BMGml0=; b=1ARPmKxGTuV0wlQWuTKtl38zPLjud7uG4U+4Hwl8Nq2qEjX//i/qicpET9+4czIl3M4pqmiSYLyC7SnF8zd1flL+lzRHBA7OMlbjpgeZucVIhJ6nmz8OBvCCdu0tXJ4NlLEGEibBVZDZMDzWTe8HlfJ3JRM52MpEkj7nvXoSxzA= Received: from BN6PR14MB1361.namprd14.prod.outlook.com (10.172.149.135) by BN6PR14MB1361.namprd14.prod.outlook.com (10.172.149.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Wed, 25 Oct 2017 16:11:39 +0000 Received: from BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) by BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) with mapi id 15.20.0156.005; Wed, 25 Oct 2017 16:11:39 +0000 From: "Ackermann, Michael" To: "David A. Cooper" , "tls@ietf.org" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5HVvcnaInjUunozwwxCXv1qLzYRoAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjPAIAAAkyAgAAWooCAADvggIAAy/QAgAABYwCAAAYOAIAAEo+A Date: Wed, 25 Oct 2017 16:11:39 +0000 Message-ID: References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.57] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1361; 20:3dZAiOPXN3aW9W1beYHCYEJQr1bhWS2eUPfKEXEQ/wzTlTXg8RgWaaNgqucjKep9wwJlNvo7lz1MsSmvfPAfKKfvrZeke4/OVPlTpHA2eq4n12f353HDhD5S+//3ycpbdaeQ9Pmy5n9NOA79EqK60JiyoaV07Dz8lgpNFlxSYWU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7a43dcf4-de66-459d-5393-08d51bc3132a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR14MB1361; x-ms-traffictypediagnostic: BN6PR14MB1361: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR14MB1361; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR14MB1361; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(199003)(24454002)(13464003)(189002)(53546010)(305945005)(101416001)(8936002)(68736007)(3846002)(102836003)(6436002)(8676002)(6116002)(6246003)(7696004)(81166006)(33656002)(77096006)(229853002)(230783001)(2501003)(53936002)(80792005)(74316002)(6306002)(9686003)(966005)(55016002)(97736004)(3660700001)(5660300001)(3280700002)(14454004)(316002)(25786009)(7736002)(72206003)(86362001)(2906002)(81156014)(76176999)(6506006)(2900100001)(54356999)(50986999)(105586002)(106356001)(93886005)(189998001)(478600001)(110136005)(2950100002)(66066001)(99286003)(8656006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1361; H:BN6PR14MB1361.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a43dcf4-de66-459d-5393-08d51bc3132a X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2017 16:11:39.6125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1361 X-TM-AS-GCONF: 00 X-VPM-MSG-ID: f689f2dd-3c8f-4834-897d-4f75ec785b03 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: ca4b5b37-7995-4a88-a02b-34ce30bbcb8a X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:11:45 -0000 DQoiIGlkZWEgb2YgYSBjbGllbnQgZXh0ZW5zaW9uIHdhcyBhZGRlZCBiYXNlZCBvbiBmZWVk YmFjayBhdCB0aGUgUHJhZ3VlIG1lZXRpbmcgaW4gb3JkZXIgdG8gaGVscCBwcmV2ZW50IHRo ZSBwcm90b2NvbCBmcm9tIGJlaW5nIHVzZWQgb3ZlciB0aGUgcHVibGljIEludGVybmV0LCBi eSBwcmV2ZW50aW5nIHRoZSBwcm90b2NvbCBmcm9tIGJlaW5nIHVzZWQgd2l0aG91dCB0aGUg Y2xpZW50J3Mga25vd2xlZGdlLiINCg0KUmVzcG9uZGluZyBPTkxZIHRvIHRoZSBhYm92ZSBz ZW50ZW5jZSwgIGFzIEkgYWdyZWUgd2l0aCBTdGVwaGVuIHRoYXQgdGhpcyBoYXMgIGdvdHRl biB0b28gTk9JU1kuICANCg0KQnV0IGF0IHRoZSBlbmQgb2YgdGhlIFdHIG1lZXRpbmcgaW4g UHJhZ3VlLCAgdGhlIENoYWlycyBhc2tlZCBmb3IgdGhlIHR3byBzaWRlcyB0byB3b3JrIHRv Z2V0aGVyIHRvIGZpbmQgY29tbW9uIGdyb3VuZC4gICBXZSB0cmllZCB2ZXJ5IGhhcmQgdG8g c2V0IHVwIGFzIG1hbnkgbWVldGluZ3MgYXMgd2UgY291bGQuICBWZXJ5IGZldyB3b3VsZCBt ZWV0IHdpdGggdXMuICAgVGVkIExlbW9uIHdhcyBvbmUuICAgQXMgaXMgZXZpZGVudCwgIFRl ZCBhbmQgSSBkb24ndCBhbHdheXMgYWdyZWUsICBidXQgaGUgd2VudCBvdXQgb2YgaGlzIHdh eSB0byBtZWV0IHdpdGggdXMgYW5kIGV4Y2hhbmdlIHZpZXdzLCAgd2hpY2ggd2FzIGdyZWF0 bHkgYXBwcmVjaWF0ZWQgYW5kIHRoZSB0eXBlIG9mIGVmZm9ydCBpdCB3aWxsIHRha2UgZm9y IHR3byBzaWRlcyB0aGF0IGRvIG5vdCBhZ3JlZSwgdG8gZmluZCBzb21lIGZvcm0gb2YgY29t cHJvbWlzZS4gICAgDQpUaGUgb25seSBwZXJzb24gdGhhdCBnYXZlIHVzIGNvbnN0cnVjdGl2 ZSBpZGVhcyBpbiB0aGUgY29tbW9uIGdyb3VuZCwgd2FzIE1hcnRpbiBUaG9tcHNvbiwgIHdo byB3ZSBhbGwgZ3JlYXRseSBhcHByZWNpYXRlIG1lZXRpbmcgd2l0aCB1cyBhcyB3ZWxsLiAg IE91dCBvZiB0aGF0IG1lZXRpbmcgY2FtZSB0aGUgaWRlYSB0aGF0IGhhdmluZyB0aGUgY2xp ZW50IGJlIGF3YXJlLCAgY291bGQgYWRkcmVzcyBzb21lIG9mIHRoZSBpc3N1ZXMgYnJvdWdo dCB1cCBpbiB0aGUgV0cgbWVldGluZy4gIA0KTXkgcG9pbnQgaGVyZSBpcyB0aGF0IHdlIGFy ZSB0cnlpbmcgaGFyZCB0byBmaW5kIEFOWSBjb21tb24gZ3JvdW5kIGFuZCB3YW50IHRvIHdv cmsgdG93YXJkcyB0aGlzLiAgIFRoZSBjbGllbnQgYXdhcmUgZmVhdHVyZSBiZWluZyBhZGRl ZCBpcyBOT1Qgc29tZXRoaW5nIHRoYXQgRW50ZXJwcmlzZXMgd2FudCBvciBuZWVkLCAgYnV0 IHdhcyBhbiBlZmZvcnQgdG8gY29tcHJvbWlzZSBhbmQgYXR0ZW1wdCB0byBnYWluIG11dHVh bCBjb25zZW5zdXMuICANCkFuZCBpZiB0aGlzIGlzIG5vdCBhIGZlYXR1cmUgdGhhdCBldmVy eW9uZSB3YW50cywgIHRoZW4gc28gYmUgaXQuICAgQnV0IGF0IGxlYXN0IGl0IHdhcyBhbiBh dHRlbXB0IGJ5IGEgc21hbGwgbnVtYmVyIG9mIHBlb3BsZSB0byB0cnkgdG8gZmluZCBjb21t b24gZ3JvdW5kIGFuZCBtYWtlIGFueSBmb3JtIG9mIHByb2dyZXNzLiAgDQpJZiB3ZSBjb3Vs ZCBkbyBtb3JlIG9mIHRoaXMgYW5kIGxlc3Mgb2YgdGhlIG5lZ2F0aXZlLCBkdXBsaWNhdGl2 ZSBhbmQgc29tZXRpbWVzIGluc3VsdGluZyByaGV0b3JpYyBvbiB0aGlzIGxpc3QsICBwZXJo YXBzIHdlIGNhbiBtYWtlIHByb2dyZXNzLiAgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBEYXZpZCBBLiBDb29wZXINClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyNSwgMjAx NyAxMDo1MCBBTQ0KVG86IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFB1Ymxp Y2F0aW9uIG9mIGRyYWZ0LXJocmQtdGxzLXRsczEzLXZpc2liaWxpdHktMDANCg0KVGhpcyBx dWVzdGlvbiBpcyBiYXNlZCBvbiB5b3VyIHRoYXQgYmVsaWVmIHRoYXQgdGhpcyBwcm90b2Nv bCB3aWxsICJlc2NhcGUiIG9udG8gdGhlIHB1YmxpYyBJbnRlcm5ldCwgdGhhdCBicm93c2Vy cyBhbmQgb3RoZXIgY2xpZW50cyB1c2VkIGJ5IGluZGl2aWR1YWxzIHdpbGwgZmVlbCBmb3Jj ZWQgdG8gaW1wbGVtZW50IGl0LCBhbmQgdGhhdCBjbGllbnRzIHdpbGwgdGhlbiBiZSBmb3Jj ZWQgdG8gZW5hYmxlIHRoZSBleHRlbnNpb24gaW4gb3JkZXIgdG8gZ2V0IHRocm91Z2ggbWlk ZGxlYm94ZXMgdGhhdCB3b3VsZCBmaWx0ZXIgdHJhZmZpYyBiYXNlZCBvbiB3aGV0aGVyIG9y IG5vdCB0aGUgZXh0ZW5zaW9uIGlzIHByZXNlbnQgaW4gdGhlIENsaWVudEhlbGxvLiBJJ3Zl IGFscmVhZHkgZXhwbGFpbmVkIHdoeSBJIGJlbGlldmUgdGhhdCBzY2VuYXJpbyB3aWxsIG5l dmVyIGhhcHBlbiwgYW5kIHNvIG5vIEkgZG8gbm90IGFncmVlIHRoYXQgaXQgaXMgYSAiZnVu ZGFtZW50YWwgY2hhbmdlLiINCg0KVGhlIGlkZWEgb2YgYSBjbGllbnQgZXh0ZW5zaW9uIHdh cyBhZGRlZCBiYXNlZCBvbiBmZWVkYmFjayBhdCB0aGUgUHJhZ3VlIG1lZXRpbmcgaW4gb3Jk ZXIgdG8gaGVscCBwcmV2ZW50IHRoZSBwcm90b2NvbCBmcm9tIGJlaW5nIHVzZWQgb3ZlciB0 aGUgcHVibGljIEludGVybmV0LCBieSBwcmV2ZW50aW5nIHRoZSBwcm90b2NvbCBmcm9tIGJl aW5nIHVzZWQgd2l0aG91dCB0aGUgY2xpZW50J3Mga25vd2xlZGdlLiBPYnZpb3VzbHkgeW91 IGJlbGlldmUgdGhhdCB0aGUgbWV0aG9kIGJlaW5nIHByb3Bvc2VkIHRvIGFkZHJlc3Mgb25l IGNvbmNlcm4gaW50cm9kdWNlcyBhbm90aGVyIGNvbmNlcm4uIEkgZG8gbm90IHNoYXJlIHRo b3NlIGNvbmNlcm5zIGZvciB0aGUgcmVhc29ucyB0aGF0IEkndmUgYWxyZWFkeSBzdGF0ZWQu DQoNCkkgZG9uJ3QgcGxhbiB0byBjb21tZW50IG9uIHRoaXMgaXNzdWUgYW55IGZ1cnRoZXIs IGFuZCBkb2luZyBzbyB3b3VsZCBqdXN0IGJlIHJlcGVhdGluZyBteXNlbGYsIHRodXMganVz dCBhZGRpbmcgdG8gdGhlIG5vaXNlLg0KDQpPbiAxMC8yNS8yMDE3IDEwOjI4IEFNLCBTYWx6 LCBSaWNoIHdyb3RlOg0KPiDinqIgICAgIFNpbWlsYXJseSwgdGhlIGJlc3QgdGhhdCBUTFMg Y2FuIG9mZmVyIGluIHRlcm1zIG9mIHByaXZhY3kgaXMgdGhhdCB0aGUNCj4gICAgICBjb250 ZW50cyBvZiB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSB0d28gZW5kcG9pbnRzIGlz IG5vdCBzZWVuIGJ5DQo+ICAgICAgYW55b25lIGVsc2UgKnVubGVzcyogYXQgbGVhc3Qgb25l IG9mIHRoZSB0d28gZW5kcG9pbnRzIChjbGllbnQgb3INCj4gICAgICBzZXJ2ZXIpIGNob29z ZXMgdG8gcHJvdmlkZSB0aGUgY29udGVudHMgb2YgdGhlIGNvbW11bmljYXRpb24gdG8gc29t ZQ0KPiAgICAgIG90aGVyIGVudGl0eS4gZHJhZnQtcmhyZC10bHMtdGxzMTMtdmlzaWJpbGl0 eSBkb2Vzbid0IGNoYW5nZSB0aGF0Lg0KPiAgICAgIA0KPiBZZXMgaXQgZG9lcy4gIEl0IHNp Z25hbHMgb24gdGhlIHdpcmUgdG8gYW55IG9ic2VydmVyIHRoYXQgdGhlIGNsaWVudCBhbmQg c2VydmVyIGFncmVlIHRvIHRoaXMuICBUTFMgbmV2ZXIgYXR0ZW1wdGVkIHRvIGNvbnRyb2wg d2hhdCB0aGUgY2xpZW50IG9yIHNlcnZlciBjb3VsZCBkby4gQnV0IGl0IG5ldmVyIHB1dCBh bnkgc3VjaCBzaWduYWwgb24gdGhlIHdpcmUuIFRoaXMgaXMgYW4gaW1wb3J0YW50IGFuZCBm dW5kYW1lbnRhbCBjaGFuZ2UsIGFuZCBpdCBhbGxvd3MgdHJhZmZpYyB0byBiZSBjYXRlZ29y aXplZCBhbmQgaGFuZGxlZCBkaWZmZXJlbnRseS4NCj4NCj4gRG8geW91IGFncmVlIHdpdGgg dGhhdD8NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdo b20gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2 aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGlu Zm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkg ZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlw dCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBj b3BpZXMuCiAKIEJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUg Q2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFu ZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hp ZWxkIEFzc29jaWF0aW9uLgo= From nobody Wed Oct 25 09:12:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDDD13B12A for ; Wed, 25 Oct 2017 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLw69YJhqbw9 for ; Wed, 25 Oct 2017 09:12:29 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 7876613F419 for ; Wed, 25 Oct 2017 09:12:26 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id m72so2922188wmc.1 for ; Wed, 25 Oct 2017 09:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Twb6BvHtKeCIfuOLR6hakYSpXK6Ghm3nPqggh1IYvKs=; b=N9eUHi9aVR3q+YxSq+YuaftzOjIFpWFKGJqPC3RNhQsqTH3yyQPUwfiUACYtt/T8Rj u2uT649QjOJ1z2Is/REY7I3IAbRuYt40xwhKnRLGi3bmabFJ0T+0WQzbqwrIjprV7FCS BNUmYLHwiFwv5sn8GuOpcI3Wm0UhlybRJWTOkuaMmWIOwHNeORPQDJkbBxMxAejaV09O 3vx8cv2yyJqKqv+Z43usOj4Tq12IM0MZ6tdNRJRxK2afmeDc/ZBd0vwUibe939b6dBEq MWVgKp1dnu4dhjMzXKOQ3I3NiSOXQUt2GofeECF69G8k9NAAEsXR9IntRuq1KIRcTzEP OHhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Twb6BvHtKeCIfuOLR6hakYSpXK6Ghm3nPqggh1IYvKs=; b=A501G9HUfEazoeUc6hRKtER1prPlFzZuNmVZ6U1EO4wX+3eSSnVV8Bwh0FtLeq8izc nvF5WgD/0gT2aAxIeBefWR4PhEuf14wWknEzxRzUX+If9G+3TpofQqm/FYsrsj21m6G6 aMVfZDq4ljOBO7PVJ5dEVE2TGNlUJ7kW8U9oYs2mh1v89Hm8RYoOzdMVjaGQ/0+lMDs8 ONc5DdoRQWlkQ5ihHMIv2inMhlf3l9DqSdwfojj4g1vGjREV9B+jZ6bN6XsrZaAJmVd9 YcUb6scFiE/EMSolKgTnswBFwLqTEQguPolbAYfeicL+EBPU0nKLQW4+wRoFpe7C6cLi YFBA== X-Gm-Message-State: AMCzsaXgWo8tdjixQ0KOHkqIQMxtSG5YW1Jlk9vbj2GwMsnY67Von6NC V+GluajLT0FDQT2K65bs/3fvT9vMGvhSddwttsvu3A== X-Google-Smtp-Source: ABhQp+QkAV3ASekegggO9ouYwLPtT9uK+KntuM41w3nS78wfbdq6vZWdSp8bUOSyiIdDo7Hfsa8mO4wXrHf1cZ5bhOc= X-Received: by 10.28.69.91 with SMTP id s88mr2302728wma.19.1508947944885; Wed, 25 Oct 2017 09:12:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 25 Oct 2017 09:12:23 -0700 (PDT) In-Reply-To: References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> <4f1b6a8d-688b-a286-6d0e-46f7f6a3cdd6@nist.gov> From: Richard Barnes Date: Wed, 25 Oct 2017 12:12:23 -0400 Message-ID: To: "Salz, Rich" Cc: "David A. Cooper" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0723a63d9e3a055c615243" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:12:32 -0000 --94eb2c0723a63d9e3a055c615243 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 25, 2017 at 12:06 PM, Salz, Rich wrote: > > since those other means would be easier and more effective. You > have done nothing to suggest otherwise. > > Public-key pinning and CT seem like they would prevent those other > mechanisms. No? > Remember that non-default, user-installed root certificates are exempted from those mechanisms in all current browsers. --Richard > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0723a63d9e3a055c615243 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 25, 2017 at 12:06 PM, Salz, Rich <rsalz@akamai.com><= /span> wrote:
> since= those other means would be easier and more effective. You
=C2=A0 =C2=A0 have done nothing to suggest otherwise.

Public-key pinning and CT seem like they would prevent those other m= echanisms.=C2=A0 No?

Remember that non-= default, user-installed root certificates are exempted from those mechanism= s in all current browsers.

--Richard

=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c0723a63d9e3a055c615243-- From nobody Wed Oct 25 09:21:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F26138BDB for ; Wed, 25 Oct 2017 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1wsyQ4zW9WW for ; Wed, 25 Oct 2017 09:21:41 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (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 72EA0138AED for ; Wed, 25 Oct 2017 09:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1508948499; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=guABaOm6A0h7AXWIYBhdhC8oxhcmLwV7vdz0tJjMoHE=; b=nXwmNRP1bjwvcTCuYX4IwhfWTCaB3hXiMCBbc/Y/PwiByxef3WcNwB6umrhHLMXDbU byh8NJyYrB4DCPun5v2YYblJ1MJVHxrbKMnMpbAm9+DaRoQtbuU1HL1nC74tG18hwi0O 1zZbUOPL/qfs662qCngG0wBCO5V5qXlbMonls= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1oaZ1h8oElbYgmd7hPw= X-RZG-CLASS-ID: mo00 Received: from [10.10.10.82] (p57B97B8D.dip0.t-ipconnect.de [87.185.123.141]) by smtp.strato.de (RZmta 42.8 DYNA|AUTH) with ESMTPSA id Y0538ft9PGLdTUk (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Wed, 25 Oct 2017 18:21:39 +0200 (CEST) To: tls@ietf.org References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> <4f1b6a8d-688b-a286-6d0e-46f7f6a3cdd6@nist.gov> From: Roland Zink Message-ID: <0c39a8cb-3fc9-e91b-9230-ccc3d6afe999@zinks.de> Date: Wed, 25 Oct 2017 18:21:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9A456636509F617067C0122B" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:21:44 -0000 This is a multi-part message in MIME format. --------------9A456636509F617067C0122B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit It could but RFC 7469 section 2.6 (https://tools.ietf.org/html/rfc7469#section-2.6) says: " It is acceptable to allow Pin Validation to be disabled for some Hosts according to local policy. For example, a UA may disable Pin Validation for Pinned Hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform)." and most browsers seem to follow this mitm exception. Regards, Roland Am 25.10.2017 um 18:06 schrieb Salz, Rich: >> since those other means would be easier and more effective. You > have done nothing to suggest otherwise. > > Public-key pinning and CT seem like they would prevent those other mechanisms. No? > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------9A456636509F617067C0122B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

It could but RFC 7469 section 2.6 (https://tools.ietf.org/html/rfc7469#section-2.6) says:


"  It is acceptable to allow Pin
   Validation to be disabled for some Hosts according to local policy.
   For example, a UA may disable Pin Validation for Pinned Hosts whose
   validated certificate chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying
   platform)."

and most browsers seem to follow this mitm exception.

Regards,
Roland


Am 25.10.2017 um 18:06 schrieb Salz, Rich:
since those other means would be easier and more effective. You 

    have done nothing to suggest otherwise.
  
Public-key pinning and CT seem like they would prevent those other mechanisms.  No?

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--------------9A456636509F617067C0122B-- From nobody Wed Oct 25 09:43:12 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B14C13F419 for ; Wed, 25 Oct 2017 09:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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 lZXIZjyjDRUA for ; Wed, 25 Oct 2017 09:43:07 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889C613941E for ; Wed, 25 Oct 2017 09:43:07 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 12:42:58 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Wed, 25 Oct 2017 12:43:05 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9PGgrjt021302 for ; Wed, 25 Oct 2017 12:42:53 -0400 To: "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> <4f1b6a8d-688b-a286-6d0e-46f7f6a3cdd6@nist.gov> From: "David A. Cooper" Message-ID: <3e91ea92-5d25-3467-c2b8-977a15b28daf@nist.gov> Date: Wed, 25 Oct 2017 12:42:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:43:10 -0000
No, they would not prevent those other mechanisms. Where is your evidence that they would?

If the "attacker" controls the software that the client is using, then it would set up the software to not check public-key pinning or CT, if necessary. As Richard noted, this may not even require developing custom software. It may be as simple as distributing a standard browser with its own CA added as a "user-installed" root certificate.

In the case that the "attacker" has the cooperation of the server, and the client is using unmodified software, then the data sent between the client and server (including the server's certificate) would be no different than if the server wasn't allowing the "attacker" to have access to the data. There would be no information available to the client at all that would distinguish between scenarios in which the server either is or isn't allowing another party to have access to the data being transmitted over the TLS session.

If public-key pinning and CT would prevent other mechanisms from working, please explain in detail how they would do so. Or better yet, let's end this line of discussion and work on finding mutually agreeable solutions to the underlying problem.

On 10/25/2017 12:12 PM, Richard Barnes wrote:
On Wed, Oct 25, 2017 at 12:06 PM, Salz, Rich <rsalz@akamai.com> wrote:
> since those other means would be easier and more effective. You
    have done nothing to suggest otherwise.

Public-key pinning and CT seem like they would prevent those other mechanisms.  No?

Remember that non-default, user-installed root certificates are exempted from those mechanisms in all current browsers.

--Richard

 

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Wed Oct 25 10:27:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72EE13F43E for ; Wed, 25 Oct 2017 10:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6lq1GZW8Pvv for ; Wed, 25 Oct 2017 10:27:44 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 0C21513F439 for ; Wed, 25 Oct 2017 10:27:44 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id v9so1271312oif.13 for ; Wed, 25 Oct 2017 10:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=skUJ0pz7enntknDQCnHEB3M2XlU4TL6SCFB4orzI7gc=; b=aDecblKzyrOfq7N/e8kHeIIoKcTcUz9iNRZDWmwQzSuvSycQgyaSngKsY7u1KHgJnk B0XPjR2mDQdICrvN0l2611Xoo9jaF8G5FfhienPJJWw0O+4uzNnHyPni8qUbZ2vG6eot ZTYRrxustPpRa+++R9b0Nr/gY4pftPlQMBixnJYdBU/7y/wurL6gQ9Rd/2FbJyNqxxml Kth5xB6ZA1/QoIPJEJ7hEr7sgTYgUYM8BQ9EjW/yCFwKKAwU0+NUj1E8524KHIvt0r9P tJ3A9JOB5v+xymSDocCsREjQNhZv9IMDDPg0WOHjaezBqPEfedRzZ6EZuEPA8+cu6QZx oV0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=skUJ0pz7enntknDQCnHEB3M2XlU4TL6SCFB4orzI7gc=; b=ipexcjhjIDal/l1RLS/YMUiGCZGXGkBohJFsL9yfVBrc8R0wpAx/MvMtaAxDT4ZIA1 RRo0jHq1oVoV4uZ6e2NVeoWSD2CixK9nWCMN80nldk6LJwW3S3MR0DAI6HmctOENS6o2 qfSLAQlGU7wwdTkNtAFTnZ1CkPArakUYb4ihdKDlE7i4C9oQaXLnAbz0FgIenfHWk6Uq QRNVkRwpGTjSBWZh1b48XimO8xX3biwbAZwubXk0fy0mZBNck531gErGfzc+t+LZMfdP KPRnTX5hXafjXCpPUKQwItTx+pVYLNnx+bO3UtV6k9V2xkkdUSvQhfKqUhKQDZBE4y7m ClPA== X-Gm-Message-State: AMCzsaWQJET4+nLJE2AOBgL0nfSWAYVJfKlPd1lNqYB7OUHHpgqNn3i1 DpA0YrA4FxVohuczTCQTYHD/C+Jc02I1Fn/TJe2QUw== X-Google-Smtp-Source: ABhQp+Ql2AcjS2djd+FLw8lsUlYlGxCDcmLh5ByHPN874i/49ehdGsmR7rXTilDXh3AMArw3XiTYl5+UAhV+nxxxZ0E= X-Received: by 10.157.12.174 with SMTP id b43mr1459487otb.229.1508952463473; Wed, 25 Oct 2017 10:27:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.19.87 with HTTP; Wed, 25 Oct 2017 10:27:42 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: <0c39a8cb-3fc9-e91b-9230-ccc3d6afe999@zinks.de> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> <4f1b6a8d-688b-a286-6d0e-46f7f6a3cdd6@nist.gov> <0c39a8cb-3fc9-e91b-9230-ccc3d6afe999@zinks.de> From: Jeffrey Walton Date: Wed, 25 Oct 2017 13:27:42 -0400 Message-ID: To: Roland Zink Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 17:27:46 -0000 On Wed, Oct 25, 2017 at 12:21 PM, Roland Zink wrote: > It could but RFC 7469 section 2.6 > (https://tools.ietf.org/html/rfc7469#section-2.6) says: > > " It is acceptable to allow Pin > Validation to be disabled for some Hosts according to local policy. > For example, a UA may disable Pin Validation for Pinned Hosts whose > validated certificate chain terminates at a user-defined trust > anchor, rather than a trust anchor built-in to the UA (or underlying > platform)." > > and most browsers seem to follow this mitm exception. The browsers are also complicit in the coverup. Reporting the broken pinset to the user or site is a "should not", even though organizational policies and regulations may require it. Jeff From nobody Wed Oct 25 12:34:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4EC1386A1 for ; Wed, 25 Oct 2017 12:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 5HIJ7z7cpOsS for ; Wed, 25 Oct 2017 12:34:55 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 C0118138103 for ; Wed, 25 Oct 2017 12:34:54 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id t139so4033066wmt.1 for ; Wed, 25 Oct 2017 12:34:54 -0700 (PDT) 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=4klK8FDZoRhLvaSlvZjszzh7YWcTku971iQW8G9ixk8=; b=jxn714yaRM1owq2DNqKalgDtbgGjWT8iiIsT/kpIYZoupR96z67KtbAAtlLFclQVCf 4wwF5Gito9GVTjmPpuBXVmavIuADxx4HKOO6jPu3nIBiuM+fGBokZale3aE+27OZbcum swvj3aRvqCXOp28wnI9QKv1RshMMgWIvYOllj3/JUYvNOootfluUzzt1Oe+qOydsiwpZ LlTa3Y4NAhZgB3aQKdxm3895JbPN/U4LU1D9J9ICrKinUhd5mj8Hovzw7adhqu8mukSn KP5pbS25dwBqq2AM+0yug1vtLI7Cb+0NRJ5NSqfKmnN0kgDR/yZ4txOuxbuY41u9JaOy 4JRw== 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=4klK8FDZoRhLvaSlvZjszzh7YWcTku971iQW8G9ixk8=; b=ts0bphTGHcyMp/bUdCiF47X4BPpgB1QaZ4QH2bXXj2lrmbdBL464A/BX3xRcEFzSpi tj09GVbAS27Tg1+RDP67e7y3buM2ES8uLdWLqdi4EqIV8Ty1wL636wmmkv+zh5Lfk3Wd aBoP5PxXD3ptDOP2RsDqKu2FWvCpI0ZkQX42Np5UWG2NLB9xABzjMYk38GXFIimlFNAM 3+lCNOa3vTWIfF28MPoccuq7XJ1K2RccFvPVFbigCfey+TqbNXZwJTa6BrNa5cweHmWn e7zcqdMCY0vjx+tV2WmCNe5CrtGGmqwTaLMmpfUgpGVDh36xDF/fzBiW0cCkvTzIpBL8 KkJg== X-Gm-Message-State: AMCzsaXqP1RPFDZUqsbE/M0dsjEhBRnPU24XdvCO2+sPsAIr+Wq0F8Zr NhqOrTzJh6ZlaAu+n1jEeGXy6am7ppfp24ZqnZI= X-Google-Smtp-Source: ABhQp+QG4PzYs9Y9qjKYQgSbJH2FeRWVc9cv7KnkN94jAlb3rp4tnvcXNkFXgynHwryZOl8LP+Bvw5CtszhjWtJ8mBg= X-Received: by 10.28.25.129 with SMTP id 123mr2697101wmz.17.1508960093107; Wed, 25 Oct 2017 12:34:53 -0700 (PDT) MIME-Version: 1.0 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> In-Reply-To: From: Nick Sullivan Date: Wed, 25 Oct 2017 19:34:41 +0000 Message-ID: To: "Salz, Rich" Cc: Paul Turner , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114d3cee547c64055c6426d7" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 19:34:57 -0000 --001a114d3cee547c64055c6426d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I didn't want to stick my foot in this, but here we are. The goal for an inspection service to be able to take a recording of the network and a key (or corpus of keys) and be able to decrypt any TLS connection to a server within that network. There are multiple ways of getting these keys. 1) use TLS 1.2 with RSA -> one single key 2) use TLS 1.3 with DH key derived from seed -> one single key (similar to draft-green) 3) use any version of TLS and export the session keys -> corpus of keys equal to number of connections The fundamental assumption of this draft is that that 3) is not feasible for all enterprises because rearchitecting their systems for a multi-key escrow is either too costly or that the requirement for TLS 1.3 will come too soon. Ted Lemon had some convincing arguments earlier about why enterprises should see this coming and invest in migrating to a model closer to 3), which will always be possible in a system that uses symmetric cryptography for encryption. Newer companies like the one mentioned by Tony Arcieri have managed to architect their systems this way, so it=E2=80=99s n= ot impossible. Still, it=E2=80=99s usually cheaper to adapt an existing system= rather than re-architect your network (and buy more gear). As long as 2) is possible, the moving to a model based on 3) is going to be a hard sell. Given that enterprises would rather be standards-compliant, this draft is a way to prevent enterprises from just going ahead and implementing 2), and instead implement something that has similar benefits (a single master key that can decrypt multiple connections), but with additional safeguards for the user: -the ability to opt out -visibility into the fact that their connection is part of a pool of connections protected by a single key You can do neither with 2). This is a win. To Rich=E2=80=99s argument that = network domains will force browsers to implement this by blocking connections that don=E2=80=99t advertise this support, I disagree. There are no passive fire= walls that I know of that drop TLS connections that don=E2=80=99t support escrow = (in the sense that non PFS-RSA and session ticket keys in TLS 1.2 are escrow). Shouldn=E2=80=99t these be blocked by the GFW if someone is forcing RSA esc= row? On that note, so what if some browsers opt in? Servers need to also opt-in to setting visibility keys. These will be visible by the browser, and visible by network watchdogs. Visibility is good in the situation where both parties want to be honest, and a dishonest escrow mechanism is possible. Furthermore, large services that are internet-facing that see this extension existence can simply disconnect when it's presented, applying back-pressure in the event of this "escaping" the datacenter. Until TLS is redesigned so that a single key escrow is not possible, datacenter operators will choose to do 2). For the next version of TLS, we should strive to eliminate a the ability for a server to escrow a single key. I posit that this should be a fundamental design principle for TLS going forward: *cross-connection secrecy*. Forward secrecy with respect to the long term certificate key is something that has been addressed in TLS 1.3. Forward secrecy with respect to other keys, like the session ticket key or other keys that can be generated centrally, are things that need to be looked at more closely for TLS 1.4 (or whatever=E2=80=99s next). This draft is an optional extension that allows a client and server to agree that a single key held by the server should be able to decrypt the data of multiple connections. I don=E2=80=99t think it=E2=80=99s something = that belongs on the Internet as a whole, but understood it as a lesser of two evils with respect to the options people have. To summarize: - TLS 1.3 allows single-key escrow with no client opt-in by design (because of ephemeral DH) - This is something that requires fundamental changes to TLS to fix, but should be looked into - Enterprises should look into moving to a model where session keys are exported to prepare for this eventuality - draft-rhrd allows clients to opt-in to an extension-based escrow system that doesn=E2=80=99t abuse the core protocol and it enables network watchdo= gs to observe - having such a system on the internet is a bad idea because it reduces the security of multiple connections down to a single piece of data - on the other hand using draft-rhrd is safer than allowing organizations to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with non-forward-secret cipher suites Nick On Thu, Oct 19, 2017 at 7:26 AM Salz, Rich wrote: > > > I didn=E2=80=99t say easy, I said =E2=80=98easier=E2=80=99 > > > Can you explain how it is easier? > > There=E2=80=99s no way to limit it to the use-case it was putatively inte= nded > for. We now have a signaling mechanism that says =E2=80=9Callow intercep= tion.=E2=80=9D > Firewalls can drop connections where the client doesn=E2=80=99t send that > extension. Therefore they can force only tappable TLS traffic. This makes > the job easier. > > I take it you want to see this draft adopted? > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114d3cee547c64055c6426d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I didn't want to stick my foot in this, but here we ar= e.

The goal for an inspection service to be able to take a recording= of the network and a key (or corpus of keys) and be able to decrypt any TL= S connection to a server within that network.

There are multiple way= s of getting these keys.
1) use TLS 1.2 with RSA -> one single key2) use TLS 1.3 with DH key derived from seed -> one single key (similar= to draft-green)
3) use any version of TLS and export the session keys -= > corpus of keys equal to number of connections

The fundamental a= ssumption of this draft is that that 3) is not feasible for all enterprises= because rearchitecting their systems for a multi-key escrow is either too = costly or that the requirement for TLS 1.3 will come too soon. Ted Lemon ha= d some convincing arguments earlier about why enterprises should see this c= oming and invest in migrating to a model closer to 3), which will always be= possible in a system that uses symmetric cryptography for encryption. Newe= r companies like the one mentioned by Tony Arcieri have managed to architec= t their systems this way, so it=E2=80=99s not impossible. Still, it=E2=80= =99s usually cheaper to adapt an existing system rather than re-architect y= our network (and buy more gear). As long as 2) is possible, the moving to a= model based on 3) is going to be a hard sell.

Given that enterprise= s would rather be standards-compliant, this draft is a way to prevent enter= prises from just going ahead and implementing 2), and instead implement som= ething that has similar benefits (a single master key that can decrypt mult= iple connections), but with additional safeguards for the user:
-the abi= lity to opt out
-visibility into the fact that their connection is part = of a pool of connections protected by a single key

You can do neithe= r with 2). This is a win. To Rich=E2=80=99s argument that network domains w= ill force browsers to implement this by blocking connections that don=E2=80= =99t advertise this support, I disagree. There are no passive firewalls tha= t I know of that drop TLS connections that don=E2=80=99t support escrow (in= the sense that non PFS-RSA and session ticket keys in TLS 1.2 are escrow).= Shouldn=E2=80=99t these be blocked by the GFW if someone is forcing RSA es= crow?

On that note, so what if some browsers opt in? Servers need to= also opt-in to setting visibility keys. These will be visible by the brows= er, and visible by network watchdogs. Visibility is good in the situation w= here both parties want to be honest, and a dishonest escrow mechanism is po= ssible. Furthermore, large services that are internet-facing that see this = extension existence can simply disconnect when it's presented, applying= back-pressure in the event of this "escaping" the datacenter.
Until TLS is redesigned so that a single key escrow is not possible, d= atacenter operators will choose to do 2). For the next version of TLS, we s= hould strive to eliminate a the ability for a server to escrow a single key= . I posit that this should be a fundamental design principle for TLS going = forward: cross-connection secrecy. Forward secrecy with respect to t= he long term certificate key is something that has been addressed in TLS 1.= 3. Forward secrecy with respect to other keys, like the session ticket key = or other keys that can be generated centrally, are things that need to be l= ooked at more closely for TLS 1.4 (or whatever=E2=80=99s next).

This= draft is an optional extension that allows a client and server to agree th= at a single key held by the server should be able to decrypt the data of mu= ltiple connections. I don=E2=80=99t think it=E2=80=99s something that belon= gs on the Internet as a whole, but understood it as a lesser of two evils w= ith respect to the options people have.

To summarize:
- TLS 1.3 a= llows single-key escrow with no client opt-in by design (because of ephemer= al DH)
- This is something that requires fundamental changes to TLS to f= ix, but should be looked into
- Enterprises should look into moving to a= model where session keys are exported to prepare for this eventuality
-= draft-rhrd allows clients to opt-in to an extension-based escrow system th= at doesn=E2=80=99t abuse the core protocol and it enables network watchdogs= to observe
- having such a system on the internet is a bad idea because= it reduces the security of multiple connections down to a single piece of = data
- on the other hand using draft-rhrd is safer than allowing organiz= ations to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 wi= th non-forward-secret cipher suites

Nick

On Thu, Oct 1= 9, 2017 at 7:26 AM Salz, Rich <rsalz@akamai.com> wrote:

=C2=A0 =C2=A0 > I didn=E2=80=99t say easy, I said =E2=80=98easier=E2=80= =99
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 Can you explain how it is easier?

There=E2=80=99s no way to limit it to the use-case it was putatively intend= ed for.=C2=A0 We now have a signaling mechanism that says =E2=80=9Callow in= terception.=E2=80=9D=C2=A0 Firewalls can drop connections where the client = doesn=E2=80=99t send that extension. Therefore they can force only tappable= TLS traffic. This makes the job easier.

I take it you want to see this draft adopted?


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a114d3cee547c64055c6426d7-- From nobody Wed Oct 25 13:03:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C686137ED6 for ; Wed, 25 Oct 2017 13:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rjw7ZA7zV83C for ; Wed, 25 Oct 2017 13:03:41 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AFC1386F3 for ; Wed, 25 Oct 2017 13:03:41 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id 17so1591023qkq.8 for ; Wed, 25 Oct 2017 13:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7YinkYvePlLsr/SCP/3uFcks3mQhLrP2pFIEAL42NEs=; b=UVjO9PofnDSJ+Slepw0qQ8dOtNs8idRfB4xyhgH4bKGMiBreU/v6ycyrPWGv2Z1ctF yY9J+9oI+o8NhjJxqJH4gFkI86glDHa7fkRdcjD51QF61K7ksvUiTl1I4zQkI6QtVbYl joBgvgIqJH/XxWx+KxZEjAoWastft8S3w9XWfXFHw/JcohBcbIGh9Ewc3uTXhJZP0K8y wcxS/143jwPXiCb+uzf//n2OepRUVdz6/+VS9ByGkTtqppIvuQ18jG966bqBBW4MAw/i OQPSEYN5CBMDKSN3lRZe2TENhPKog66DNIpsd9PmP5jWTNK67ZQxwwlBRqWsGMlI/kX3 pBmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7YinkYvePlLsr/SCP/3uFcks3mQhLrP2pFIEAL42NEs=; b=J77OaDeiHaxwHUIFlOiyz3PKhN84FUHFRX12Ww1owDbEj8D0gUsPq0dgsUW1uGkakn 07dhHx/AHY6FYrN73DTQJzxxOWJKaH8My5c5wDqR2KmXtYf+0makrBn30zdgSoe1kRsH rziMre2WHNM0sstklxo9UEkJR7Zf2/tZ690mobBLXbTuYy+ZSKFXr9FabDjPMxm3nLW+ k/8q7sb6rFLX3Palr1xUQOCnpiYVovRddpne0aZaR7McuSjIyAoGqvgv1rmUB1UQubFY +OILaOI9w6fwB31DcJqEC77nqNwEO5GN9MKVvC4dAQJjmzavd2RMRt7zuzLN7P4OLtwr MEzQ== X-Gm-Message-State: AMCzsaWvcbHeLwxSHSMteXV2lbGMrs21PetYfoC9a5uamonxawTyoO8m FhwC1eSUVZDxTIuLxS2KZYO92g== X-Google-Smtp-Source: ABhQp+Rd+ZAs4K9hZRNsU/Epf1W2EtgWWW8e4erFOfbYwDIZ91FUm2i8o0sLXTL7pXh4r5Vh2stPSQ== X-Received: by 10.55.158.5 with SMTP id h5mr4828960qke.209.1508961820132; Wed, 25 Oct 2017 13:03:40 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id h21sm2529321qte.72.2017.10.25.13.03.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 13:03:39 -0700 (PDT) From: Ted Lemon Message-Id: <71829AD0-E721-4C26-BF3C-43386017EC7B@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_55B59970-5B07-43D5-9552-7556F0525C4C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 25 Oct 2017 16:03:38 -0400 In-Reply-To: Cc: "Salz, Rich" , Paul Turner , "tls@ietf.org" To: Nick Sullivan References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 20:03:43 -0000 --Apple-Mail=_55B59970-5B07-43D5-9552-7556F0525C4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 25, 2017, at 3:34 PM, Nick Sullivan = wrote: > Forward secrecy with respect to other keys, like the session ticket = key or other keys that can be generated centrally, are things that need = to be looked at more closely for TLS 1.4 (or whatever=E2=80=99s next). Unless I am very much mistaken, it is literally impossible to prevent a = server from escrowing a key so that the contents of the communication = can be decrypted. > - having such a system on the internet is a bad idea because it = reduces the security of multiple connections down to a single piece of = data > - on the other hand using draft-rhrd is safer than allowing = organizations to hack single-key escrow into TLS 1.3 or continue to use = TLS 1.2 with non-forward-secret cipher suites There's no question of allowing or not allowing=E2=80=94that's outside = of IETF's sphere of influence. But the case has been (to me = convincingly) made that making it possible for an eavesdropper on the = conversation to easily tell whether a client is willing to accept key = escrow makes things worse, from a security perspective. The main sense in which it makes things worse is that such a feature = might be added to standard libraries, and thus be available at low cost, = and thus might become easy to impose as a regulatory requirement. This is why I have been advocating for simply not using TLS for this use = case. There exist solutions to this problem that do not require = breaking TLS 1.3, that are standard, and that are already allowed for = PCI compliance. It's better for everyone if these two domains are kept = separate, and I haven't yet heard a good argument for not doing so. > The fundamental assumption of this draft is that that 3) is not = feasible for all enterprises because rearchitecting their systems for a = multi-key escrow is either too costly or that the requirement for TLS = 1.3 will come too soon. Ted Lemon had some convincing arguments earlier = about why enterprises should see this coming and invest in migrating to = a model closer to 3), To be clear, I actually don't think that per-session key escrow is = feasible in the use case that we are talking about here. =46rom a = security perspective I think it's a pretty good idea, because it allows = for things like rate-limiting the number of connections that can be = monitored, but from a practical perspective, arranging to have the keys = available in a timely manner during debugging seems to me not to be = tractable, since the number of keys involved would be substantial, and = the timing would be quite exact; indeed, if the debugging process = requires debugging all active streams in order to find an ID in the = stream that is actually sought, I think it would be almost impossible, = and certainly ludicrously expensive. What I've been arguing for is to switch away from TLS for this use case. --Apple-Mail=_55B59970-5B07-43D5-9552-7556F0525C4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Oct 25, 2017, at 3:34 PM, Nick Sullivan <nicholas.sullivan@gmail.com> wrote:
Forward secrecy with respect to other keys, = like the session ticket key or other keys that can be generated = centrally, are things that need to be looked at more closely for TLS 1.4 = (or whatever=E2=80=99s next).

Unless= I am very much mistaken, it is literally impossible to prevent a server = from escrowing a key so that the contents of the communication can be = decrypted.

- having such a system on the internet is = a bad idea because it reduces the security of multiple connections down = to a single piece of data
- on the other hand using = draft-rhrd is safer than allowing organizations to hack single-key = escrow into TLS 1.3 or continue to use TLS 1.2 with non-forward-secret = cipher suites

There's no question of allowing or not allowing=E2=80=94that's = outside of IETF's sphere of influence.   But the case has been (to = me convincingly) made that making it possible for an eavesdropper on the = conversation to easily tell whether a client is willing to accept key = escrow makes things worse, from a security perspective.

The main sense in which = it makes things worse is that such a feature might be added to standard = libraries, and thus be available at low cost, and thus might become easy = to impose as a regulatory requirement.

This is why I have been advocating for = simply not using TLS for this use case.   There exist solutions to = this problem that do not require breaking TLS 1.3, that are standard, = and that are already allowed for PCI compliance.   It's better for = everyone if these two domains are kept separate, and I haven't yet heard = a good argument for not doing so.

The = fundamental assumption of this draft is that that 3) is not feasible for = all enterprises because rearchitecting their systems for a multi-key = escrow is either too costly or that the requirement for TLS 1.3 will = come too soon. Ted Lemon had some convincing arguments earlier about why = enterprises should see this coming and invest in migrating to a model = closer to 3),

To be = clear, I actually don't think that per-session key escrow is feasible in = the use case that we are talking about here.   =46rom a security = perspective I think it's a pretty good idea, because it allows for = things like rate-limiting the number of connections that can be = monitored, but from a practical perspective, arranging to have the keys = available in a timely manner during debugging seems to me not to be = tractable, since the number of keys involved would be substantial, and = the timing would be quite exact; indeed, if the debugging process = requires debugging all active streams in order to find an ID in the = stream that is actually sought, I think it would be almost impossible, = and certainly ludicrously expensive.

What I've been arguing for is to switch = away from TLS for this use case.

= --Apple-Mail=_55B59970-5B07-43D5-9552-7556F0525C4C-- From nobody Wed Oct 25 14:32:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53CE13F475 for ; Wed, 25 Oct 2017 14:32:31 -0700 (PDT) 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 bIlNHAmszpxo for ; Wed, 25 Oct 2017 14:32:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DAE513A102 for ; Wed, 25 Oct 2017 14:32:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 320FFBE58; Wed, 25 Oct 2017 22:32:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9-sROuK4pBj; Wed, 25 Oct 2017 22:32:25 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 51A32BE53; Wed, 25 Oct 2017 22:32:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508967145; bh=ZljPEeX3JGHc7Jq6nkqipalYbP3VGX4MekBtgN5MhgI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FOJbAyg9TlAZATlM2Yhcu/0OJX7LOUpoLS66TE8ixZo831ibUnZzCKBj+BrNkTunb RvmPsfg5UXyUplFSutNvAi/xk/pk3aVTj1ky3U20EgJRwXGY7WY4feuxjZDR0nOtms z4zjBCcqc8BL4+KljZlZWTS42D9Whp+jZuO7I7fg= To: Nick Sullivan , "Salz, Rich" Cc: Paul Turner , "tls@ietf.org" References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <243be89e-fcd3-f3a1-7f28-2a34daf795c5@cs.tcd.ie> Date: Wed, 25 Oct 2017 22:32:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IionCPSCEcNBwQsQ1OoM18xNet7DHBmqn" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 21:32:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IionCPSCEcNBwQsQ1OoM18xNet7DHBmqn Content-Type: multipart/mixed; boundary="tj7Q7GUEaRMAMOdN4v2qa0prDOXAmcLGh"; protected-headers="v1" From: Stephen Farrell To: Nick Sullivan , "Salz, Rich" Cc: Paul Turner , "tls@ietf.org" Message-ID: <243be89e-fcd3-f3a1-7f28-2a34daf795c5@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> In-Reply-To: --tj7Q7GUEaRMAMOdN4v2qa0prDOXAmcLGh Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Thank you Nick. On 25/10/17 20:34, Nick Sullivan wrote: > On that note, so what if some browsers opt in? Servers need to also opt= -in > to setting visibility keys. It is good to see the discussion move on from the proponents' seeming inability to envisage that anything bad could possibly happen here;-) I believe you are right that if we standardise this, it is reasonably likely to end up in some browser. (I've no idea how to estimate that probability, so we're all guessing really.) As you might expect, I disagree with your analysis as to the consequences if browsers did support this. Just as one example, I read today of reports that some people have been arrested/accused partly on the basis that they downloaded some software [1] so it is sadly far too easy to imagine that some regime somewhere would arrest people for having a browser that does not support this "standard" feature. Note, I'm not saying I accept all details of the story in [1] as such things are often badly reported, but I do assert that such issues are ones we ought be seriously considering. For me, us defining a feature like this that could be mandated, for wiretapping, or the absence of which could get folks into that kind of trouble, is just not something we ought be risking, regardless of our inability to estimate the probabilities involved. S. [1] https://www.theguardian.com/world/2017/oct/25/amnesty-turkish-chair-taner= -kilic-on-trial-over-failed-coup --tj7Q7GUEaRMAMOdN4v2qa0prDOXAmcLGh-- --IionCPSCEcNBwQsQ1OoM18xNet7DHBmqn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ8QLoAAoJEC88hzaAX42iiOQH/1HeBKriSvMQybbriGBc84rN nvdzMjL5okTd3BY0U0Z45MLEJMYm2JC9wbXKRUMzUfEING2mX1GjclPQu/pYAFUy PYth5DFJicOR6iiJ85I7fyVRtER749KnqI+vnUTRfwqFM0/XvwT8VN1+1TdXFFSG 4ahfa2K5pJSFw2elha+51VSg2DFden7eDXCGvvWGLOoiaqv5bXA60hLLo1miTM4W beBm2ojBzxxV9HqIPAExyv6gl8nluXN4gEmXUW5rHisUj6uSdciCYDom+HFkjayG OfvpOM/UG5CC6JT0uUi/JvBEE85iIc7XEGnjY8mXuQ+T4uu4OoBiwcOurVF14wU= =Rlkk -----END PGP SIGNATURE----- --IionCPSCEcNBwQsQ1OoM18xNet7DHBmqn-- From nobody Wed Oct 25 14:34:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E2713A102 for ; Wed, 25 Oct 2017 14:34:17 -0700 (PDT) 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 8xv_BVMb80_H for ; Wed, 25 Oct 2017 14:34:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC937139F44 for ; Wed, 25 Oct 2017 14:34:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A7481BE58 for ; Wed, 25 Oct 2017 22:34:15 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEBBkLA_MGHr for ; Wed, 25 Oct 2017 22:34:14 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 74D1EBE53 for ; Wed, 25 Oct 2017 22:34:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508967254; bh=MieoaApjhbhqHw0+Mr43EKeFZBny79P6Q1lySN0bmOc=; h=Subject:References:To:From:Date:In-Reply-To:From; b=EU+2hZPOcYxWFVhXMvyx0v8Om67N3upaFP6mm38sUk6+OT6Of60yZbIP/y010CyWj QgtQWkpxpHO6XqZTnnBYEtnEmBVWxhcMlOxlKpxJFMlw5LGhZ04NVPCcNzbzIzba0O +Ikn9fzbPZyh1IAX/i1XjAW8yQEmKdzf0O1R2tIg= References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> Date: Wed, 25 Oct 2017 22:34:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2DOONgNLLW5KjdU2aUjgBXFjvD50bLI0D" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 21:34:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2DOONgNLLW5KjdU2aUjgBXFjvD50bLI0D Content-Type: multipart/mixed; boundary="EeUrcLWpehgrn0uqU2F79Ip6hnSAGQWDa"; protected-headers="v1" From: Stephen Farrell To: "tls@ietf.org" Message-ID: <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> In-Reply-To: <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> --EeUrcLWpehgrn0uqU2F79Ip6hnSAGQWDa Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Replying to just a couple of bits... On 25/10/17 15:23, David A. Cooper wrote: > Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not seen by > anyone else *unless* at least one of the two endpoints (client or > server) chooses to provide the contents of the communication to some > other entity. draft-rhrd-tls-tls13-visibility doesn't change that. The above is nonsense. The draft in question clearly proposes fundamentally changing the feature set of TLS to include snooping as a standard, supported feature. > But, I'm tired of the abusive > and false suggestions that draft-rhrd-tls-tls13-visibility is a > "wiretapping" draft or that it is defining a "please-screw-me > extension."=20 Abusive of what/whom? The truth or falsity of the wiretapping description is a matter for debate. (Russ' argument that these are not witetapping features is one I find to be lawyerly nit picking based on a partial reading of 2804, but I believe he does believe that.) I'm fine that you ignore that there are other opinions. I also don't really care if the proponents of snooping as a standard feature get tired to their ideas being criticised to be honest. I am, and will remain, available to offer such criticism. And FWIW, I consider the use of euphemisms like "passive" or "visibility" here to be deceptive. Perhaps not deliberately deceptive, (I'm not saying the authors of the draft are trying to deceive), but nonetheless I find such abuses of language far more irritating than the occasional bit of robustness in debate. Such euphemisms are also more long-term damaging IMO. This draft and the one before it are proposing supporting an active attacker in the middle of TLS sessions and that is how we ought be discussing this, not as some pretend passive good-natured observer capability. S. --EeUrcLWpehgrn0uqU2F79Ip6hnSAGQWDa-- --2DOONgNLLW5KjdU2aUjgBXFjvD50bLI0D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ8QNWAAoJEC88hzaAX42igdEH/iFC/s+glJN8MOUyEzeVLbne WSc6L7LP/Rev7bPXwQRerJEoHKJmqNsJUR2sFaqA/miMdkoVbEa8a3NGXrZT9BSC wuUxGUd5rEAI4szwzhqLe2uwF1zZsNPEzEJOnfFk76YGjyIPWI4iOLYObA9lzNBY HuyCRIp+8I9T5SIskvzhq9rq0hp2AYr2RT7tMKkvGTcsaIDhEB/2rgw+LksQQcBX sOtxV6yPBLv3HxItoExgimQbPgK9Pgo+4i2a9t/GcozAE7XDYFEyjCHnpnnbKz1l DDInT4QdtnaR8gkPQv/56kG0W9YvC1cKZ6lL7hu8Vnt7O1webVtouR6RFfeS5HU= =Z2WO -----END PGP SIGNATURE----- --2DOONgNLLW5KjdU2aUjgBXFjvD50bLI0D-- From nobody Wed Oct 25 14:47:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21941390EE for ; Wed, 25 Oct 2017 14:47:54 -0700 (PDT) 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 ljnUE46SXMzm for ; Wed, 25 Oct 2017 14:47:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16B9132055 for ; Wed, 25 Oct 2017 14:47:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B2217BE58; Wed, 25 Oct 2017 22:47:50 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38AUvigLU-8D; Wed, 25 Oct 2017 22:47:49 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5CF92BE55; Wed, 25 Oct 2017 22:47:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508968069; bh=IGIUsztTpuwHh163xWj38hDiw1qS0zwYUPGLccWAEGU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=e74xDaVtA900TqFNXkBIHTavdeIiCQPXs+3pj+k3Cx2RdOHNpE+QVPVJvnFji91mq VjXpbfDUSCgnvtsoAEBQNISHFbr5x9MtUk6etZg3I+NSRdUl5Es1v8NVYQc5QXRKxt 4rmgC3ZGH4ouv/4hY0UAt2GuhjaUggJjP6MhDptQ= To: "Ackermann, Michael" , "David A. Cooper" , "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <63867733-c40d-02d3-0813-6b286dacaac3@cs.tcd.ie> Date: Wed, 25 Oct 2017 22:47:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qVl4V8mvI20EbKnX0XManV2ITmDovJNpM" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 21:47:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qVl4V8mvI20EbKnX0XManV2ITmDovJNpM Content-Type: multipart/mixed; boundary="F6OO4e0mGG81cuhTunwbxKWoW5vbbc1e0"; protected-headers="v1" From: Stephen Farrell To: "Ackermann, Michael" , "David A. Cooper" , "tls@ietf.org" Message-ID: <63867733-c40d-02d3-0813-6b286dacaac3@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> In-Reply-To: --F6OO4e0mGG81cuhTunwbxKWoW5vbbc1e0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 25/10/17 17:11, Ackermann, Michael wrote: > And if this is not a feature that everyone wants, then so be it. > But at least it was an attempt by a small number of people to try to > find common ground and make any form of progress.=20 I do not accept that there is an onus on IETF participants to acquiesce to bad ideas in the name of finding common ground. The IETF is not that kind of SDO (at least I hope not). When a thing is a sufficiently bad idea, then it is not a good plan to try meet it half-way. That is the case with the basic idea here. So, sorry, no - compromise is not a goal. OTOH, investigating non-damaging means of meeting data centre requirements that do not involve TLS is an entirely fine thing to do IMO. (Though maybe not the oft-quoted but *never* so far substantiated claims related to PCI;-). I would encourage you and others to go do that. If that calls for the development of a new multi-party security protocol that can be used in such environments, that is also just fine and could have other interesting uses. One could also do work to try make it easier for sites to evolve towards use of (closer to, but not, perfect) forward secrecy. But breaking TLS is very different to both and is not fine. S. --F6OO4e0mGG81cuhTunwbxKWoW5vbbc1e0-- --qVl4V8mvI20EbKnX0XManV2ITmDovJNpM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ8QaEAAoJEC88hzaAX42ihIAIAKNQsOhFdJ0cNe9fpynsc8kj TolNMkoOvvRZ7CIQgKeOrnTNhFCeiaHtxYOczzYxbYuhosisPYH4qRtHUC5uu0td 04x+BUlkKCfid74p4y31yYQQCbO4PCdno2OIaw7kV6JeotIeeDG/osDRI3yNG8P9 Tlc7kt7a8xnYsWx4q5MgojffeJhltILlzUq4iAEsk0QfHPVUneZaRI5stfZ8QDKO SZvjaTiH0I70rDLUt27Ayr5moWqUqtXaW63RBkaHqFj+FoxO8aABIjdQZ0mJPGTV 3gyCQjgluS0DTNTbcGl1kJx8YDTDZk18K4SlDwbzrsJd4aXfw90z0mCQcSbP6TM= =F8DP -----END PGP SIGNATURE----- --qVl4V8mvI20EbKnX0XManV2ITmDovJNpM-- From nobody Wed Oct 25 15:37:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1980513F4A8 for ; Wed, 25 Oct 2017 15:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8Ghm-G1VPGP for ; Wed, 25 Oct 2017 15:37:45 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 F234713F49F for ; Wed, 25 Oct 2017 15:37:44 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id o44so1418637wrf.11 for ; Wed, 25 Oct 2017 15:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XsOlocoLySwCmj0Vq+bo0+DsmBb0WdZwQrMeZ3eOBOg=; b=cGZ6iMR/aIJ7R5DQhJkEHuWv4CaNHYHg/GTw4JBRtoaZRfT2Y5Z4UzB4BdwSsxom8b YYsl8B8v8Rei7UHM1P2bDb/GAKlwTZtagYxf51caX9AsfM5gOI44btF+KmZVLgmTAM1S +ZJIfsfK5SOnT/9KBATK67b9fN/PjxbH86mI6FENdnXgDhdL87elyUyMf1eLZC2VGuMI 9KJOGCdPM61HhUU4f/bOP5qLho0W2O0bNtFnpAIMWH9sNNPhZZ9pv1qGQIQl6Hc9HeTI Dgd2bx8ma3wtqNL5dF9LcCg4ZEVLxFZu+XFwPytfZgZPl+2Gj2Z/cXiDQaZDB2cWDPUQ RY1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XsOlocoLySwCmj0Vq+bo0+DsmBb0WdZwQrMeZ3eOBOg=; b=YeAGEOm2JCZTQg+bZKkp2wQ9vsfym5RA40f0o60DzwrMMpcJG9pJ3W13uEjWuQR4eI opiGR4E6NPU0BG1dVmRLYZRVTtIKFlDiRweSCCN/1k8Vlo/gqNoKtBh/Wd9hnPlhtafX 5rJYJ1esjo8NDMPxyyWb2BOXA9fbFQNuzoRBtcvKsKFv6S4CS1DM/jrBF6hh530bfcZL rhuEqEDMol4JQa9e1IgrXbwpOlj/lUxwwybAsyyY8ywEE0SY3aRb5iKJnBIehiWOXz1z HOY9pTF/0F5+9rXUEfn7fjQmiMwlyLqFyqKCMSssiu7z7LfbvQo5XQicjeo16H5lOEBU KW1A== X-Gm-Message-State: AMCzsaVXkAJ4f3ZYRzkvvUep/h7O7Eb6TH9fb5lUspLHlS69XFJWokDl glNKVDDknUpsYzlyI0FMZRM3LGcjjGQcdHi5m/13Xw== X-Google-Smtp-Source: ABhQp+RK8O6k0f+a3bLJikjsrp8G1ctgIa8xAFbEyvDqxHRM3hlTi35YDH5+Pp631/M6t/5vYbbQHjzJLoDl5FExWVQ= X-Received: by 10.223.196.156 with SMTP id m28mr3772778wrf.67.1508971063104; Wed, 25 Oct 2017 15:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 25 Oct 2017 15:37:41 -0700 (PDT) Received: by 10.28.174.81 with HTTP; Wed, 25 Oct 2017 15:37:41 -0700 (PDT) In-Reply-To: References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> From: Richard Barnes Date: Wed, 25 Oct 2017 23:37:41 +0100 Message-ID: To: Stephen Farrell Cc: "" Content-Type: multipart/alternative; boundary="f403045f548631943d055c66b423" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 22:37:47 -0000 --f403045f548631943d055c66b423 Content-Type: text/plain; charset="UTF-8" On Oct 25, 2017 22:34, "Stephen Farrell" wrote: Replying to just a couple of bits... On 25/10/17 15:23, David A. Cooper wrote: > Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not seen by > anyone else *unless* at least one of the two endpoints (client or > server) chooses to provide the contents of the communication to some > other entity. draft-rhrd-tls-tls13-visibility doesn't change that. The above is nonsense. The draft in question clearly proposes fundamentally changing the feature set of TLS to include snooping as a standard, supported feature. Sorry, what? The current draft proposes an extension, literally the opposite of a standard, supported feature. It's explicitly optional. I don't really have a dog in this fight, but let's please be accurate. --Richard > But, I'm tired of the abusive > and false suggestions that draft-rhrd-tls-tls13-visibility is a > "wiretapping" draft or that it is defining a "please-screw-me > extension." Abusive of what/whom? The truth or falsity of the wiretapping description is a matter for debate. (Russ' argument that these are not witetapping features is one I find to be lawyerly nit picking based on a partial reading of 2804, but I believe he does believe that.) I'm fine that you ignore that there are other opinions. I also don't really care if the proponents of snooping as a standard feature get tired to their ideas being criticised to be honest. I am, and will remain, available to offer such criticism. And FWIW, I consider the use of euphemisms like "passive" or "visibility" here to be deceptive. Perhaps not deliberately deceptive, (I'm not saying the authors of the draft are trying to deceive), but nonetheless I find such abuses of language far more irritating than the occasional bit of robustness in debate. Such euphemisms are also more long-term damaging IMO. This draft and the one before it are proposing supporting an active attacker in the middle of TLS sessions and that is how we ought be discussing this, not as some pretend passive good-natured observer capability. S. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --f403045f548631943d055c66b423 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Oct 25, 2017 22:34, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:=

Replying to just a couple of bits...

On 25/10/17 15:23, David A. Cooper wrote:
> Similarly, the best that TLS can offer in terms of privacy is that the=
> contents of the communication between the two endpoints is not seen by=
> anyone else *unless* at least one of the two endpoints (client or
> server) chooses to provide the contents of the communication to some > other entity. draft-rhrd-tls-tls13-visibility doesn't change = that.

The above is nonsense. The draft in question clearly proposes
fundamentally changing the feature set of TLS to include snooping
as a standard, supported feature.

Sorry, what?=C2=A0 The current draft= proposes an extension, literally the opposite of a standard, supported fea= ture.=C2=A0 It's explicitly optional.=C2=A0

=
I don't really have a dog in this fight, but le= t's please be accurate.=C2=A0

--Richard


> But, I'm tired of the abusive
> and false suggestions that draft-rhrd-tls-tls13-visibility is a > "wiretapping" draft or that it is defining a "please-sc= rew-me
> extension."

Abusive of what/whom? The truth or falsity of the wiretapping
description is a matter for debate. (Russ' argument that these
are not witetapping features is one I find to be lawyerly nit
picking based on a partial reading of 2804, but I believe he
does believe that.) I'm fine that you ignore that there are
other opinions.

I also don't really care if the proponents of snooping as a
standard feature get tired to their ideas being criticised to
be honest. I am, and will remain, available to offer such
criticism.

And FWIW, I consider the use of euphemisms like "passive" or
"visibility" here to be deceptive. Perhaps not deliberately
deceptive, (I'm not saying the authors of the draft are trying
to deceive), but nonetheless I find such abuses of language
far more irritating than the occasional bit of robustness in
debate. Such euphemisms are also more long-term damaging IMO.

This draft and the one before it are proposing supporting an
active attacker in the middle of TLS sessions and that is how
we ought be discussing this, not as some pretend passive
good-natured observer capability.

S.


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--f403045f548631943d055c66b423-- From nobody Wed Oct 25 15:40:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5EA13F4AB for ; Wed, 25 Oct 2017 15:40:46 -0700 (PDT) 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 v6xjDm-h_ge6 for ; Wed, 25 Oct 2017 15:40:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95B313A1C7 for ; Wed, 25 Oct 2017 15:40:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9F242BE64; Wed, 25 Oct 2017 23:40:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0uSc5rSWT6o; Wed, 25 Oct 2017 23:40:41 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 66FCEBE5B; Wed, 25 Oct 2017 23:40:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508971241; bh=rgt6oQ5dZEW8d2ZnvkRnlgz3JVTZ6dW3/FXUT9++/N0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VfQKoOG3u/llDHnBnvrILXWoA7ajDdAFrEqo4d3jw4IhzvKXg/1WxtafX9m288UWk Aij7rIh26PAhJR6Y5kzUxk/ynIarxUMQw8VVccSyOYAydiXrZvKX1VnL0mFn/Dn986 /U3Enym9ZPNbE8X2KwoTsXCWMOa+pBoiv2cM/1lk= To: Richard Barnes Cc: "" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <59e9fc03-5a31-ce5a-443b-8c3e057e792e@cs.tcd.ie> Date: Wed, 25 Oct 2017 23:40:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H1cREtvjqtH3J8NN8VwuhAA8CSjEMcOSs" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 22:40:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H1cREtvjqtH3J8NN8VwuhAA8CSjEMcOSs Content-Type: multipart/mixed; boundary="7j65QBD3TgAh5QRQNCsiUW8lx1eE7taVD"; protected-headers="v1" From: Stephen Farrell To: Richard Barnes Cc: "" Message-ID: <59e9fc03-5a31-ce5a-443b-8c3e057e792e@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> In-Reply-To: --7j65QBD3TgAh5QRQNCsiUW8lx1eE7taVD Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 25/10/17 23:37, Richard Barnes wrote: > Sorry, what? The current draft proposes an extension, literally the > opposite of a standard, supported feature. It's explicitly optional. Optional is not the opposite of standard. See the intended status below. > I don't really have a dog in this fight, but let's please be accurate. Accuracy level is just fine I think. S. Network Working Group R. Housley Internet-Draft Vigil Security Intended status: Standards Track R. Droms Expires: April 2, 2018 Interisle Consulting September 29, 2017 TLS 1.3 Option for Negotiation of Visibility in the Datacenter draft-rhrd-tls-tls13-visibility-00 --7j65QBD3TgAh5QRQNCsiUW8lx1eE7taVD-- --H1cREtvjqtH3J8NN8VwuhAA8CSjEMcOSs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ8RLoAAoJEC88hzaAX42izSkH/3gHjqF7YwIPBaqonlg2ZReN FfQ9ee293C1PYhEIG1QA4ewR3ezLlz2u2iFt+2yL7ZvhLvo94TnipSdy8xBqY+qW 8tgGsj4Zt0Uj5FTxLuZwNeRCPU+j18nRy/px69T9kFEMItuNT5buTyoG0gjeyhgp saIgyLGDuWOqncZUC8qOOlnZzKLf2hLaISKoQ3cPWxA0e39uhXpEmScV8lSsfHIt EzyM0NyFMGGhfmhehA0p9gLB2jFrXLXAeS8cR5upW9AdZXvfvHiG5X0R/7RgfoH9 4+5m5ZyTmG54Snwrc2gCrXK+4iu4pv3GQaevbyW1G0CAxrBGCgqkVtAVZ0laQRk= =E/Vc -----END PGP SIGNATURE----- --H1cREtvjqtH3J8NN8VwuhAA8CSjEMcOSs-- From nobody Wed Oct 25 15:58:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D707413B2BE for ; Wed, 25 Oct 2017 15:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 o9QyeH15YT3b for ; Wed, 25 Oct 2017 15:58:27 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404B513B13F for ; Wed, 25 Oct 2017 15:58:27 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id k40so1696484lfi.4 for ; Wed, 25 Oct 2017 15:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cZVSgkjhy/Q3hNw7yRJHRs05s9bZgTKjP4b9a4qnUZ0=; b=bAy3bMxsYJaa69z3pMMwZg1Ijruv/WYH8qV7YOA8rVszCMNhxsb22d/ydVVhidA6Jz 3KalTAOsmEDdeqmh6pBOayJ4VZ1kXeRdn2TGdI0enibzsNi9l4Zu0EvYpcu0XHypXtjw +AbQTcsr25a+qkmJgaIPJrUpKHg+E3JfrO0kmS4B10YE75LTFyQL7TrpAaaJGBEw/SfZ 9rR/r6/Pa9habYG7U+4RKwy4cBc+afapxD/6TA/WLOw9+CasL5z9LoQrGBDJc4WQM3fY po/Df1ARHu4EUpj7sQe9PusdNdgsU22yFQC773Y6SPypBOPwVtjkDXWzWUHmL7HxIyTO e/rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cZVSgkjhy/Q3hNw7yRJHRs05s9bZgTKjP4b9a4qnUZ0=; b=pnHqHKEEw9X4kC+1Ekwzr5BTfnyjnV8/DjifwJ0DXkIj0EYbrC4xbBeBpM+kj1LNTR Ylmo1hUriS2v/71kpSKpKkQPte4+1VeBNLuGlJ6Ji11oeYnwqYYmABNLWf06Rh+jCvxS 4jGBfBkesnkE6rUGuSvXFiG8XdTkpM8wDf4uutjru/tlYlVGnYBEBLGprx8BTHcBScLS PPed0K6Tloh4itzCtscCJF34BlR50ZxHRx86itl/fJBQoFxL+m07OOylQ7FMCkTrAF6B aRoYSidlYAMjdjPDCdVAppXpSF8ftpWZ1aYiqaFQqST0p8LNGRdc6GDht+EY/CShO77e bABA== X-Gm-Message-State: AMCzsaVBjM5L0ftl45S1vk40R8R/DBd3QadizC0MYdl0/f09MLWzTChW LXpMpWIEQQsvP773lHeZsPORL6Ilbg4VYquJcvQvEE5I X-Google-Smtp-Source: ABhQp+QriXy/sgvK95hShApEMQLec//wer2oN0Ko43KDDyn44y66L3HJTkeET8+twi9k95vkwqLKk4PeVzmZk70sxFc= X-Received: by 10.46.75.26 with SMTP id y26mr9081870lja.113.1508972305532; Wed, 25 Oct 2017 15:58:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.43.149 with HTTP; Wed, 25 Oct 2017 15:58:24 -0700 (PDT) In-Reply-To: <59e9fc03-5a31-ce5a-443b-8c3e057e792e@cs.tcd.ie> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> <59e9fc03-5a31-ce5a-443b-8c3e057e792e@cs.tcd.ie> From: Peter Bowen Date: Wed, 25 Oct 2017 15:58:24 -0700 Message-ID: To: Stephen Farrell Cc: Richard Barnes , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 22:58:29 -0000 On Wed, Oct 25, 2017 at 3:40 PM, Stephen Farrell wrote: > > > On 25/10/17 23:37, Richard Barnes wrote: >> Sorry, what? The current draft proposes an extension, literally the >> opposite of a standard, supported feature. It's explicitly optional. > > Optional is not the opposite of standard. > > See the intended status below. > >> I don't really have a dog in this fight, but let's please be accurate. > > Accuracy level is just fine I think. So, to be completely clear, no one is arguing that Nick's three options (quoted below) are wrong or do not work. The objection is that the IETF should not be publishing a RFC that documents them, is that right? Nick Sullivan wrote: > 1) use TLS 1.2 with RSA -> one single key > 2) use TLS 1.3 with DH key derived from seed -> one single key (similar to draft-green) > 3) use any version of TLS and export the session keys -> corpus of keys equal to number of connections Thanks, Peter From nobody Wed Oct 25 16:10:55 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D11913F48A for ; Wed, 25 Oct 2017 16:10:54 -0700 (PDT) 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 pYLoB0DhufXE for ; Wed, 25 Oct 2017 16:10:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E3D13F46A for ; Wed, 25 Oct 2017 16:10:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CE9DBBE5B; Thu, 26 Oct 2017 00:10:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-4Tv4XP0l0M; Thu, 26 Oct 2017 00:10:47 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 077E7BE58; Thu, 26 Oct 2017 00:10:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508973047; bh=/xCBq2pvd5eC4jZStIWfE6ZemNpt4tsBGqbdhOwiNuQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NKDgs5EAtMRk3RgIcq/8NkLqC5mxU8KG9sI8nf+siu+8nAxN9ArqiP4CKe8tmbaIF aZTw2bvmTAGwHWr4hCZUWuf0AUlhTzJwt6np9qctxPv0ujElFAvOzG+2/OeJUk9XMh EmVQLECM5e65QjPsEbRMMfa6NIt+mtL0UgvSF+YA= To: Peter Bowen Cc: Richard Barnes , "" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> <59e9fc03-5a31-ce5a-443b-8c3e057e792e@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2c285c65-11fe-f5a0-4b5f-f18cfbd0aa7e@cs.tcd.ie> Date: Thu, 26 Oct 2017 00:10:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6SNdfdgoubO8QEE9JgVT33erjQ3khGIhb" Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 23:10:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6SNdfdgoubO8QEE9JgVT33erjQ3khGIhb Content-Type: multipart/mixed; boundary="vPW49wnhtOsT8FAGtRkklHicEkWUCuXNA"; protected-headers="v1" From: Stephen Farrell To: Peter Bowen Cc: Richard Barnes , "" Message-ID: <2c285c65-11fe-f5a0-4b5f-f18cfbd0aa7e@cs.tcd.ie> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> <59e9fc03-5a31-ce5a-443b-8c3e057e792e@cs.tcd.ie> In-Reply-To: --vPW49wnhtOsT8FAGtRkklHicEkWUCuXNA Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 25/10/17 23:58, Peter Bowen wrote: > So, to be completely clear, no one is arguing that Nick's three > options (quoted below) are wrong or do not work. The objection is > that the IETF should not be publishing a RFC that documents them, is > that right? No, it's not that simple. For myself, I disagree with some aspect's of Nick's analysis, which we can go into as needed. I don't think that's needed in this mail. On your second point... The IETF has a range of policies (BCPs etc) that call for use of strong and not-weakened cryptography in protocols. Some of that is mentioned in places at [1] but I'm sure a more complete job could be done. There are sound technical reasons why the IETF has consensus on a bunch of those positions. For some of those, it is also true that the consensus has always been rough, e.g. I think it's true there have always been IETFers who would actually like to MitM security protocols for what they consider good reasons. (That doesn't make those people either bad or correct.) One particular relevant RFC (2804) does explicitly envisage that people who want to do snooping might document their ways of doing that in independent stream RFCs (which are not IETF RFCs despite almost no RFC-readers grokking any difference there;-). But in this case the authors say they want standards-track. And in the previous case, from talking with Russ, he didn't see any benefit in the independent stream route (which I didn't understand at the time tbh). So the situation is actually sort-of clear, but not simple. It's true that appreciating the clarity requires quite a bit of IETF lore ;-) S. [1] https://github.com/sftcd/tinfoil --vPW49wnhtOsT8FAGtRkklHicEkWUCuXNA-- --6SNdfdgoubO8QEE9JgVT33erjQ3khGIhb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ8Rn2AAoJEC88hzaAX42iVxoH/1uD5nukkUr07ENq4R/vEy15 3hlq7epAJtKa1duI+qz7bgHwzq+6ikgt8o5yYMiDd7bKyv9XJrBLHTI4aK7u41uw EfHUglPxrfsJOjKef1XSwC4wbXd5WQeN2QJnFYvkzCfy/nDj3oVu7uUT0lMXrKr6 1dQAnY1k42AK2UrSO06oDxhLEnHOwZIlh4Axo71+o7p8wgd8Dmvf91avZ0Q7eLLz 8r6NZUdST/d8T+52SVeYpA5KXbjTYtFWyMWR+opWOUzYssTCVlGbRU8dE9+4Tfod jgXWguF8wEgR6boWL2zErJSmoPL+jRDhTUrL9TUtW4OhVob6+NFGeiEiZUQjF7Y= =NkRV -----END PGP SIGNATURE----- --6SNdfdgoubO8QEE9JgVT33erjQ3khGIhb-- From nobody Wed Oct 25 16:51:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EF113F4F0 for ; Wed, 25 Oct 2017 16:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 LpIp5RsxHND8 for ; Wed, 25 Oct 2017 16:51:18 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B872F13F4EF for ; Wed, 25 Oct 2017 16:51:18 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9PNlCfC019709; Thu, 26 Oct 2017 00:51:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=pR4Zg4J58xUgm2CV7ztLrzWBmviuY2tWL8R2kXr+ttg=; b=HoXX6BXiX0E+a2E/eKaH4xys8snL8aFcM66fb00iAmdprAlcxp4PCRZP3SgoaSq7psyX CmvCMQSO+9tAfA+dTPOn9giVVDWLv2l3dGsPlfxaaG6oxcMzFhSglDWp8QentBroZX8E vOy8d1XuhU353gb8RgrMXXuoQCd2NeNPJ4Kyx7EVAattauTSF+zepfVnzfYdyW9SlQnK pxBlLcr2Ri4U/QjLMk+JUDcUWFCGerTOTl1gWl79E17YnvllgC3jE3AKjjbU6u+GwqCT 6b45tduIamlNTQHG96PhQeXBQygycqgcIRTQ9aY8c4ZNp0n+uKa5S/NiN5ePAZ+1K17+ ZA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2dtx7xs2mt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Oct 2017 00:51:11 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9PNp1vA026318; Wed, 25 Oct 2017 19:51:10 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2dr1jx0cfg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 19:51:10 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 19:50:56 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 25 Oct 2017 19:50:56 -0400 From: "Salz, Rich" To: Peter Bowen , Stephen Farrell CC: "" Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjQAIAAAkoAgAAWo4CAADvggIAAy/QAgAB4YYD//868aoAAQ9UAgAAE9ACAAA6lgA== Date: Wed, 25 Oct 2017 23:50:55 +0000 Message-ID: <7C3AA1E9-11A4-488B-B664-4A5AD7C9D2EB@akamai.com> References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> <59e9fc03-5a31-ce5a-443b-8c3e057e792e@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.131] Content-Type: text/plain; charset="utf-8" Content-ID: <698FD8E88C66CB4FB178F80EE0E428AD@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250305 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-25_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250304 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 23:51:20 -0000 4p6iIG9wdGlvbnMgKHF1b3RlZCBiZWxvdykgYXJlIHdyb25nIG9yIGRvIG5vdCB3b3JrLiAgVGhl IG9iamVjdGlvbiBpcw0KICAgIHRoYXQgdGhlIElFVEYgc2hvdWxkIG5vdCBiZSBwdWJsaXNoaW5n IGEgUkZDIHRoYXQgZG9jdW1lbnRzIHRoZW0sIGlzDQogICAgdGhhdCByaWdodD8NCiAgICANCk5v dCBhdCBhbGwuDQoNCkJ1dCBtYXliZSBJ4oCZbSBtaXN0YWtlbjsgZG8geW91IGhhdmUgbGlua3Mg dG8gbWVzc2FnZXMgdGhhdCBzYWlkIHRoYXQ/DQoNClRoZSBkcmFmdCBpbiB0aGUgc3ViamVjdCBs aW5lIGlzIGEgZGlmZmVyZW50IGl0ZW0gYWx0b2dldGhlci4NCg0K From nobody Wed Oct 25 20:02:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6761213A2B8 for ; Wed, 25 Oct 2017 20:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-NWBPOy4W_a for ; Wed, 25 Oct 2017 20:02:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4198713ADF6 for ; Wed, 25 Oct 2017 20:02:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYL37762; Thu, 26 Oct 2017 03:02:15 +0000 (GMT) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 26 Oct 2017 04:02:13 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.184]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0301.000; Thu, 26 Oct 2017 11:02:10 +0800 From: yinxinxing To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AdNOBmh63Q3Kq988RdyuovF4uvgCJA== Date: Thu, 26 Oct 2017 03:02:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022D150360dggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.59F15037.011E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.184, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2bb64600e8d734ca67556d1e323aff95 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 03:02:21 -0000 --_000_DBDF9AE44733284D808F0E585E1919022D150360dggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWtyLA0KDQpTb3JyeSBmb3IgdGhlIGRlbGF5LiBJIGRvbuKAmXQgcXVpdGUgdW5kZXJzdGFu ZCDigJxUaGUgd2F5IHRoYXQgdGhpcyBtZWNoYW5pc20gd29ya3MgaXMgdGhhdCBpdCBlaXRoZXIg cmVwbGFjZXMgYWxsIG9mIHRoZW0gb3Igc3VwcGxlbWVudHMgdGhlIHNldC7igJ0gSSBzZWUgdGhl IG5ldyBDSUQgaXMgZW5jcnlwdGVkIGluIHRoZSBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlIGFuZCB0 cmFuc2ZlcnJlZCB0byB0aGUgcGVlci4gU28sIHRoZSByZWNvcmQgaGVhZGVyIG9mIHRoaXMgbWVz c2FnZSBuZWVkcyB0byBjb250YWluIHRoZSDigJxvbGTigJ0gQ0lELg0KDQpCZXNpZGVzLCBJIGhh dmUgc3VtbWFyaXplZCB0aGUgd2F5cyBvZiBkaXN0aW5ndWlzaGluZyB0aGUgQ0lEIHBhY2tldCBh bmQgc3RhbmRhcmQgcGFja2V0IHRoYXQgcGVvcGxlIGhhdmUgZGlzY3Vzc2VkIGluIHRoZSBtYWls aW5nIGxpc3Q6DQoNCmEpICAgICAgIEFkZGluZyBuZXcgQ29udGVudFR5cGUuDQoNCmIpICAgICAg IEFkZGluZyBuZXcgdmVyc2lvbi4gKEFzIHlvdSByZXBsaWVkLCBzaW5jZSAxLjMgaXMgZ29pbmcg dG8gcmVtb3ZlIHZlcnNpb24gZmllbGQgaW4gdGhlIHJlY29yZCBoZWFkZXIsIHNvIHRoaXMgY2hv aWNlIG1heSBub3QgYmUgcHJvcGVyLikNCg0KYykgICAgICAgVXNpbmcgc3BlY2lmaWNhbGx5LWNv bnN0cnVjdGVkIENJRC4gKEkgc2F3IHlvdSByZXBsaWVkIHRoYXQgaXQgd291bGQgYmUgYSB3YXkg Zm9yIERUTFMgMS4yLiBCdXQgZm9yIDEuMywgeW91IHdhbnQgYSBkaWZmZXJlbnQgd2F5LikNCg0K ZCkgICAgICAgQnkgY29tcGFyaW5nIHRoZSA1LXR1cGxlLiBNYXJ0aW4gbWFkZSB0aGlzLiAoSWYg SSB1bmRlcnN0YW5kIHJpZ2h0KSBIaXMgaWRlYSBpcyB0aGF0IGZpcnN0IGNoZWNrIHRoZSA1LXR1 cGxlIG9mIHRoZSBwYWNrZXQsIGlmIHRoZXJlIGlzIGEgbWF0Y2gsIHRoZW4gdXNlIHRoZSBjb3Jy ZXNwb25kaW5nIGtleS4gSWYgdGhlcmUgaXMgbm8gbWF0Y2gsIHRoZW4gdHJlYXQgdGhlIHBhY2tl dCBhcyBhIENJRCBwYWNrZXQgYW5kIGZpbmQgdGhlIENJRCBpbiB0aGUgcGFja2V0IGFjY29yZGlu ZyB0byB0aGUgbmV3IGZvcm1hdC4gQnV0LCB0aGUgcHJlY29uZGl0aW9uIGZvciB3ZWxsIHdvcmtp bmcgaXMgdGhhdCB0aGUgNS10dXBsZSBvZiB0aGUgQ0lEIHBhY2tldCB3aWxsIG5vdCBiZSBzdWNj ZXNzZnVsbHkgbWF0Y2hlZCBpbiB0aGUgcmVjZWl2ZXIncyA1LXR1cGxlIHRhYmxlLg0KDQoNCkZv ciB0aGUgYWJvdmUgY2hvaWNlcywgd2hhdCBkbyB5b3UgdGhpbms/IE9yIGRvIHlvdSBoYXZlIGFu eSBvdGhlciBnb29kIHNvbHV0aW9uIHRvIGJlIHVwZGF0ZWQgaW4gdGhlIGRyYWZ0Pw0KDQpSZWdh cmRzLA0KWWluIFhpbnhpbmcNCg0K5Y+R5Lu25Lq6OiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWty QHJ0Zm0uY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0MTDmnIgyM+aXpSAyMDoxMw0K5pS25Lu2 5Lq6OiB5aW54aW54aW5nDQrmioTpgIE6IHRsc0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW1RMU10g Q29ubmVjdGlvbiBJRCBEcmFmdA0KDQoNCg0KT24gTW9uLCBPY3QgMjMsIDIwMTcgYXQgMTI6NTMg QU0sIHlpbnhpbnhpbmcgPHlpbnhpbnhpbmdAaHVhd2VpLmNvbTxtYWlsdG86eWlueGlueGluZ0Bo dWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBFa3IsDQoNCkZvciB0aGUgcG9zdC1oYW5kc2hha2UgbWVz c2FnZXMgaW4gdGhlIGRyYWZ0LCBJIGhhdmUgc29tZSBjb21tZW50cy4NCg0KDQoxLiAgICAgICBX aGVuIG9uZSBwZWVyIHNlbmRzIE5ld2Nvbm5lY3Rpb25JRCBtZXNzYWdlIHRvIHRoZSBvdGhlciwg aXQgdXNlcyBhIG5ld2x5IGRlZmluZWQgaGFuZHNoYWtlIHR5cGUuIFRoaXMgbmV3IENJRCBpcyBh dHRhY2hlZCBpbiB0aGUgcGF5bG9hZCBvZiB0aGUgcmVjb3JkIG1lc3NhZ2UuIEJ1dCB0aGVyZSBt dXN0IGJlIHNvbWUgaW5mb3JtYXRpb24gZm9yIHRoZSByZWNlaXZlciB0byBrbm93IHdoaWNoIENJ RCBpcyBnb2luZyB0byBiZSB1cGRhdGVkLiBJIG1lYW4gdGhhdCB3aGVuIHNlbmRpbmcgbmV3IENJ RCB0aHJvdWdoIHRoZSBOZXdDb25uZWN0aW9uSUQgbWVzc2FnZSwgdGhlIHJlY29yZCBoZWFkZXIg c2hvdWxkIGluY2x1ZGUgdGhlIOKAnG9sZOKAnSBDSUQsIHNvIHRoYXQgdGhlIHJlY2VpdmVyIGtu b3dzIHdoaWNoIG9uZSB0byByZXBsYWNlLg0KVGhlIHdheSB0aGF0IHRoaXMgbWVjaGFuaXNtIHdv cmtzIGlzIHRoYXQgaXQgZWl0aGVyIHJlcGxhY2VzIGFsbCBvZiB0aGVtIG9yIHN1cHBsZW1lbnRz IHRoZSBzZXQuIEknbSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMgdGhlIHJpZ2h0IGR5bmFtaWMsIGJ1 dCBJJ2QgZmlyc3Qgd2FudCB0byBzZWUgc29tZSB3b3JrZWQgdGhyb3VnaCBjYXNlcy4NCg0KDQoy LiAgICAgICBJbiB0aGUgZHJhZnQsIGlzIHRoZSBuZXcgQ0lEIGVuY3J5cHRlZD8gSSBzdWdnZXN0 IHRoYXQgdGhlIG5ldyBDSUQgKGZvciB0aGUgZmlyc3QgdGltZSBzZW5kaW5nKSBjYW4gYmUgZW5j cnlwdGVkICB0byBtYWtlIHN1cmUgdGhhdCBhbiBhdHRhY2tlciBjYW4gbm90IGFzc29jaWF0ZSBh IG5ldyBDSUQgd2l0aCBhbiBvbGQgQ0lELiBMZXTigJlzIGNvbnNpZGVyIGEgY2FzZSB3aGVyZSBh biBhdHRhY2tlciB3YW50cyB0byB0cmFjayBhbiBJT1QgZGV2aWNlLiBJZiB0aGUgbmV3bHkgZ2Vu ZXJhdGVkIENJRCBpcyBub3QgZW5jcnlwdGVkIHdoZW4gdXBkYXRpbmcsIHRoZSBhdHRhY2tlciBj YW4gYXNzb2NpYXRlIHRoZSBuZXcgQ0lEIHdpdGggdGhlIG9sZCBvbmUuIFRoZW4sIHdoZW4gdGhl IHBlZXIgc2VuZHMgbWVzc2FnZSB3aXRoIHRoZSBuZXcgQ0lEIGxhdGVyLCB0aGUgYXR0YWNrZXIg a25vd3MgdGhpcyBwYWNrZXQgaXMgc2VudCBmcm9tIHRoZSB2aWN0aW0uIElmIHdlIGVuY3J5cHQg dGhlIG5ldyBDSUQgd2hlbiB1cGRhdGluZywgdGhpcyB0cmFja2luZyBwcm9ibGVtIGNhbiBiZSBh dm9pZGVkLg0KDQpUTFMgMS4zIHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzIGFyZSBhbHdheXMgZW5j cnlwdGVkLg0KDQogQW5vdGhlciBjb21tZW50IGlzIGFib3V0IHN5bW1ldHJpY2FsIENJRC4NCg0K MS4gICAgICAgQ29uc2lkZXIgYSBjbGllbnQgc2VuZHMgYSBub3JtYWwgQ0lEIChDSUQgbGVuZ3Ro IGlzIG5vdCB6ZXJvLCBuYW1lZCBDLUNJRCkgdG8gc2VydmVyLCBidXQgdGhlIHNlcnZlciBkb2Vz buKAmXQgd2FudHMgdG8gdXNlIGNsaWVudOKAmXMgQ0lEIGFuZCBzZW5kcyBhIENJRCBnZW5lcmF0 ZWQgYnkgdGhlIHNlcnZlciAobmFtZWQgUy1DSUQpIHRvIHRoZSBjbGllbnQuDQpOby4gVGhlIENJ RCBpcyBmb3IgdGhlIGNsaWVudCdzIGJlbmVmaXQsIHNvIHdoeSB3b3VsZCB0aGlzIGJlIHVzZWZ1 bD8NCg0KDQpBdCB0aGUgc2FtZSB0aW1lLCBjbGllbnQgbmVlZHMgdG8ga25vdyBzZXJ2ZXIgaGFz IGlnbm9yZWQgQy1DSUQgKHdoaWNoIG1lYW5zIHRoZSBkb3dubGluayBhcHBsaWNhdGlvbiBtZXNz YWdlIGZyb20gdGhlIHNlcnZlciB3aWxsIG5vdCBpbmNsdWRlIEMtQ0lEKSwgYW5kIGNsaWVudCB3 aWxsIHVzZSBTLUNJRCBpbiBpdHMgYXBwbGljYXRpb24gbWVzc2FnZS4gV2lsbCB0aGUgZHJhZnQg Y292ZXIgdGhpcyBzY2VuYXJpbz8NCk5vLg0KDQotRWtyDQoNCg0KDQpZaW4gWGlueGluZw0KDQrl j5Hku7bkuro6IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb208bWFpbHRvOmVrckBy dGZtLmNvbT5dDQrlj5HpgIHml7bpl7Q6IDIwMTflubQxMOaciDEz5pelIDIxOjAwDQrmlLbku7bk uro6IHlpbnhpbnhpbmcNCuaKhOmAgTogdGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+ DQrkuLvpopg6IFJlOiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0DQoNCg0KDQpPbiBGcmksIE9j dCAxMywgMjAxNyBhdCAxOjExIEFNLCB5aW54aW54aW5nIDx5aW54aW54aW5nQGh1YXdlaS5jb208 bWFpbHRvOnlpbnhpbnhpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgRWtyLA0KDQpUaGFua3Mg Zm9yIHlvdXIgZWZmb3J0LiBUaGUgZHJhZnQgbG9va3MgZ29vZC4gQSBmZXcgY29tbWVudHMgYXJl IGxpc3RlZCBiZWxvdy4NCg0KDQoxLiAgICAgICBCYXNlZCBvbiB0aGUgZHJhZnQsIGZvciBlaXRo ZXIgRFRMUzEuMiBvciAxLjMsIHNlcnZlciBjYW7igJl0IGRpZmZlcmVudGlhdGUgd2hldGhlciB0 aGUgcGFja2V0IGZyb20gY2xpZW50IGlzIGEg4oCcY29ubmVjdGlvbiBJROKAnSBwYWNrZXQgb3Ig YSBzdGFuZGFyZCBEVExTIDEuMi8xLjMgcGFja2V0LiAoSSBzYXcgVGhvbWFzIEZvc3NhdGkgYW5k IE5pa29zIGFsc28gaW50cm9kdWNlZCB0aGlzIHByb2JsZW0pDQoNCk1heWJlIHdlIGNhbiBhZGQg YSBuZXcg4oCcQ29udGVudFR5cGXigJ0gaW4gdGhlIERUTFMgcmVjb3JkIGZvcm1hdCB0byBoZWxw IHNlcnZlciBpZGVudGlmeSB0aGUg4oCcY29ubmVjdGlvbiBJROKAnSBwYWNrZXQuIEluIGFkZGl0 aW9uLCB5b3Ugc2VlIHRoZSBsZW5ndGggb2YgdGhlIHJlY29yZCBwYXlsb2FkIGlzIGxpbWl0ZWQg YnkgMl4xNC0xLCB0aGlzIG1lYW5zIHRoZSBmaXJzdCB0d28gYml0cyBvZiDigJxsZW5ndGjigJ0g aXMgemVyby4gV2UgY291bGQgdXRpbGl6ZSB0aGlzIGZlYXR1cmUgYW5kIHNldCB0aGUgZmlyc3Qg dHdvIGJpdHMgb3IgbW9yZSBiaXRzIG9mIENJRCBiZWluZyBvbmUsIGUuZy4sIDExMTHigKYuKGJ1 dCB0aGUgQ0lEIG11c3QgYmUgcHV0IGJldHdlZW4gc2VxdWVuY2UgbnVtYmVyIGFuZCBsZW5ndGgp LiBXaGVuIHNlcnZlciBmaW5kcyAxMTExIGFmdGVyIHNlcXVlbmNlIG51bWJlciwgaXQga25vd3Mg dGhpcyBpcyBhIOKAnGNvbm5lY3Rpb24gSUTigJ0gcGFja2V0LiBIb3dldmVyLCBJIGRvbuKAmXQg a25vdyB3aGV0aGVyIGl0IGlzIHByb3BlciB0byB1c2Ugc3VjaCBtYWdpYyBudW1iZXIuIEluIG15 IHZpZXcsIGFkZGluZyBuZXcgY29udGVudHR5cGUgbWF5IGJlIGEgY2hvaWNlLg0KDQpBcyBJIHNh aWQgdG8gTmlrb3MsIGZvciBEVExTIDEuMiwgeW91IGNhbiB1c2UgYSBzcGVjaWFsbHktY29uc3Ry dWN0ZWQgQ0lEIHRoYXQgd291bGQgbm90IGJlIGEgdmFsaWQgbGVuZ3RoIGZpZWxkLiBUaGlzIGNh biBhY3R1YWxseSBqdXN0IGhhdmUgdGhlIGxlYWRpbmcgYml0IHNldC4gQXMgd2UncmUgcmV2aXNp bmcgdGhlIERUTFMgMS4zIHJlY29yZCBmb3JtYXQsIHdlIHdvdWxkIG5lZWQgdG8gZG8gc29tZXRo aW5nIGRpZmZlcmVudCBmb3IgdGhhdC4NCg0KDQoyLiAgICAgICAgRm9yIERUTFMgMS4yLCB0aGVy ZSBpcyBubyBOZXdDb25uZWN0aW9uSUQgYW5kIFJlcXVlc3RDb25uZWN0aW9uSUQgbWVzc2FnZS4g RFRMUyAxLjIgc2VydmVyIGFuZCBjbGllbnQgYWxzbyBoYXMgdGhlIHJlcXVpcmVtZW50IHRvIHJl cXVlc3QgZm9yIGEgbmV3IENJRCwgYW5kIGF0IHByZXNlbnQsIG1hbnkgcHJvZHVjdHMgc3RpbGwg dXNlIERUTFMxLjIgYW5kIEkgYmVsaWV2ZSBpdCB3aWxsIGNvbnRpbnVlIHRvIGJlIHVzZWQgZm9y IGEgbG9uZyB0aW1lIGV2ZW4gaWYgVExTL0RUTFMxLjMgaXMgcHVibGlzaGVkLiBNeSBwb2ludCBp cyB0aGF0IHdlIG5lZWQgYSBjb3JyZXNwb25kaW5nIG1ldGhvZCBmb3IgdXBkYXRpbmcgQ0lEIGZv ciBEVExTMS4yIHRvby4NCkluIGdlbmVyYWwsIHRoZSBXRyBpcyB3b3JraW5nIG9uIFRMUyAxLjMs IG5vdCBUTFMgMS4yLCBzbyBJJ20gbm90IHJlYWxseSB0aGF0IGV4Y2l0ZWQgYWJvdXQgcHV0dGlu ZyBhIGxvdCBvZiBlZmZvcnQgaW50byBlbmhhbmNpbmcgVExTIDEuMi4gVGhlIGJhc2ljIGV4dGVu c2lvbiB3b3JrcyBmaW5lIGZvciB0aGVtLCBidXQgaWYgdGhleSB3YW50IHRvIGNoYW5nZSBDSURz LCB0aGVuIHRoZXkgc2hvdWxkIGFkb3B0IERUTFMgMS4zLg0KDQoNCkkgZG9u4oCZdCBxdWl0ZSB1 bmRlcnN0YW5kIHRoZSBmb2xsb3dpbmcgc2VudGVuY2VzDQoNCuKAnEluIERUTFMgMS4yLCBjb25u ZWN0aW9uIGlkcyBhcmUgZXhjaGFuZ2VkIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlDQoNCiAgIERU TFMgc2Vzc2lvbiBvbmx5LiAgVGhlcmUgaXMgbm8gZGVkaWNhdGVkICJjb25uZWN0aW9uIGlkIHVw ZGF0ZSINCg0KICAgbWVzc2FnZSB0aGF0IGFsbG93cyBuZXcgY29ubmVjdGlvbiBpZHMgdG8gYmUg ZXN0YWJsaXNoZWQgbWlkLXNlc3Npb24sDQoNCiAgIGJlY2F1c2UgRFRMUyAxLjIgaW4gZ2VuZXJh bCBkb2VzIG5vdCBhbGxvdyBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcw0KDQogICB0aGF0IGRvIG5v dCB0aGVtc2VsdmVzIGJlZ2luIG90aGVyIGhhbmRzaGFrZXMu4oCdDQoNClRoZSBvbmx5IHBvc3Qt aGFuZHNoYWtlIG1lc3NhZ2VzIGFsbG93ZWQgaW4gRFRMUyAxLjIgYXJlIENsaWVudEhlbGxvIGFu ZCBIZWxsb1JlcXVlc3QuDQoNCg0KQmVzaWRlcywgZm9yIENJRCBpbiBEVExTMS4zLCBJIHRoaW5r IHRoZSBjb3JyZXNwb25kaW5nIHJlc3BvbmRpbmcgbWVzc2FnZXMgb2YgIE5ld0Nvbm5lY3Rpb25J RCBhbmQgUmVxdWVzdENvbm5lY3Rpb25JRCBhcmUgYWxzbyBuZWVkZWQgdG8gZW5zdXJlIHRoYXQg dGhlIHBlZXIgaGFzIHJlY2VpdmVkIENJRC4NCg0KTm8sIHlvdSB1c2UgdGhlIEFDSyBmb3IgdGhl c2UgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRscy1kdGxzMTMtMDEj c2VjdGlvbi03KS4gVGhpcyBpcyBvbmUgcmVhc29uIHdoeSB0aGVyZSBpcyBub3QgYSBzdHJhaWdo dGZvcndhcmQgcG9ydCB0byBEVExTIDEuMiBmb3IgdGhlc2UgbWVzc2FnZXMuDQoNCg0KNC4gICAg ICAgVGhlIGdlbmVyYXRpb24gb2YgQ0lEIHNob3VsZCBiZSBtb3JlIGNvbmNyZXRlLiBGb3IgZXhh bXBsZSwgdXNpbmcgcmFuZG9tIG51bWJlciBvciBhIGNvdW50ZXI/DQpJIGV4cGxpY2l0bHkgZGlk IG5vdCB3YW50IHRvIGRvIHRoYXQsIGJlY2F1c2UgdGhlcmUgYXJlIGEgbG90IG9mIHZhbGlkIHdh eXMgdG8gZ2VuZXJhdGUgQ0lELiBUaGlzIGlzIGFsc28gd2hhdCB3ZSBkaWQgaW4gUVVJQy4NCg0K LUVrcg0KDQoNCg0KUmVnYXJkcywNCllpbiBYaW54aW5nDQoNCuWPkeS7tuS6ujogVExTIFttYWls dG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPl0g5Luj 6KGoIEVyaWMgUmVzY29ybGENCuWPkemAgeaXtumXtDogMjAxN+W5tDEw5pyIMTPml6UgNzoxNA0K 5pS25Lu25Lq6OiB0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NCuS4u+mimDogW1RM U10gQ29ubmVjdGlvbiBJRCBEcmFmdA0KDQpIaSBmb2xrcywNCg0KSSBoYXZlIGp1c3QgcG9zdGVk IGEgZmlyc3QgY3V0IGF0IGEgY29ubmVjdGlvbiBJRCBkcmFmdC4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1yZXNjb3JsYS10bHMtZHRscy1jb25uZWN0aW9uLWlkLTAwDQoNCkNv bW1lbnRzIHdlbGNvbWUuDQoNCi1Fa3INCg0KDQoNCg0KDQo= --_000_DBDF9AE44733284D808F0E585E1919022D150360dggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6 MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAubTkx ODk4MTQ0MTIyMTcwOTAxMzNtc29saXN0cGFyYWdyYXBoLCBsaS5tOTE4OTgxNDQxMjIxNzA5MDEz M21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tOTE4OTgxNDQxMjIxNzA5MDEzM21zb2xpc3RwYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLW5hbWU6bV85MTg5ODE0NDEyMjE3MDkwMTMzbXNvbGlzdHBhcmFncmFw aDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLm05MTg5ODE0NDEyMjE3MDkwMTMzZ21haWwt bS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoLCBsaS5tOTE4OTgxNDQxMjIxNzA5 MDEzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCwgZGl2Lm05MTg5 ODE0NDEyMjE3MDkwMTMzZ21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBo DQoJe21zby1zdHlsZS1uYW1lOm1fOTE4OTgxNDQxMjIxNzA5MDEzM2dtYWlsLW0tNjUxMzYwNTMz MzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyNzcwMzAyNzE7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExNTkyMDIxNzggLTYw NTQ5MDk4NCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRl eHQ6IiUyXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBw dDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgltYXJnaW4tbGVmdDo2My4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojg0LjBwdDsNCgl0ZXh0LWluZGVudDot MjEuMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTVcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEwNS4w cHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoxMjYuMHB0Ow0K CXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDoxNDcuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlOFwp IjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY4LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCW1hcmdpbi1sZWZ0OjE4OS4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBFa3IsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvcnJ5IGZvciB0aGUgZGVsYXkuIEkgZG9u4oCZ dCBxdWl0ZSB1bmRlcnN0YW5kIOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHdheSB0 aGF0IHRoaXMgbWVjaGFuaXNtIHdvcmtzIGlzIHRoYXQgaXQgZWl0aGVyIHJlcGxhY2VzIGFsbCBv ZiB0aGVtDQogb3Igc3VwcGxlbWVudHMgdGhlIHNldC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0gSSBzZWUgdGhlIG5ldyBD SUQgaXMgZW5jcnlwdGVkIGluIHRoZSBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlIGFuZCB0cmFuc2Zl cnJlZCB0byB0aGUgcGVlci4gU28sIHRoZSByZWNvcmQgaGVhZGVyIG9mIHRoaXMgbWVzc2FnZSBu ZWVkcw0KIHRvIGNvbnRhaW4gdGhlIOKAnG9sZOKAnSBDSUQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJlc2lkZXMsIEkgaGF2ZSBzdW1tYXJpemVkIHRoZSB3YXlzIG9mIGRp c3Rpbmd1aXNoaW5nIHRoZSBDSUQgcGFja2V0IGFuZCBzdGFuZGFyZCBwYWNrZXQgdGhhdCBwZW9w bGUgaGF2ZSBkaXNjdXNzZWQgaW4gdGhlIG1haWxpbmcgbGlzdDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YSk8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWRkaW5n IG5ldyBDb250ZW50VHlwZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Yik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWRkaW5nIG5ldyB2ZXJzaW9uLiAoQXMgeW91 IHJlcGxpZWQsIHNpbmNlIDEuMyBpcyBnb2luZyB0byByZW1vdmUgdmVyc2lvbiBmaWVsZCBpbiB0 aGUgcmVjb3JkIGhlYWRlciwgc28gdGhpcyBjaG9pY2UgbWF5IG5vdCBiZSBwcm9wZXIuKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5j KTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Vc2luZyBzcGVjaWZpY2FsbHktY29uc3RydWN0ZWQgQ0lELiAoSSBzYXcgeW91IHJl cGxpZWQgdGhhdCBpdCB3b3VsZCBiZSBhIHdheSBmb3IgRFRMUyAxLjIuIEJ1dCBmb3IgMS4zLCB5 b3Ugd2FudCBhIGRpZmZlcmVudCB3YXkuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5kKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CeSBjb21wYXJpbmcgdGhlIDUt dHVwbGUuIE1hcnRpbiBtYWRlIHRoaXMuIChJZiBJIHVuZGVyc3RhbmQgcmlnaHQpIEhpcyBpZGVh IGlzIHRoYXQgZmlyc3QgY2hlY2sgdGhlIDUtdHVwbGUgb2YgdGhlIHBhY2tldCwgaWYgdGhlcmUN CiBpcyBhIG1hdGNoLCB0aGVuIHVzZSB0aGUgY29ycmVzcG9uZGluZyBrZXkuIElmIHRoZXJlIGlz IG5vIG1hdGNoLCB0aGVuIHRyZWF0IHRoZSBwYWNrZXQgYXMgYSBDSUQgcGFja2V0IGFuZCBmaW5k IHRoZSBDSUQgaW4gdGhlIHBhY2tldCBhY2NvcmRpbmcgdG8gdGhlIG5ldyBmb3JtYXQuIEJ1dCwg dGhlIHByZWNvbmRpdGlvbiBmb3Igd2VsbCB3b3JraW5nIGlzIHRoYXQgdGhlIDUtdHVwbGUgb2Yg dGhlIENJRCBwYWNrZXQgd2lsbCBub3QgYmUgc3VjY2Vzc2Z1bGx5DQogbWF0Y2hlZCBpbiB0aGUg cmVjZWl2ZXIncyA1LXR1cGxlIHRhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50 OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZv ciB0aGUgYWJvdmUgY2hvaWNlcywgd2hhdCBkbyB5b3UgdGhpbms/IE9yIGRvIHlvdSBoYXZlIGFu eSBvdGhlciBnb29kIHNvbHV0aW9uIHRvIGJlIHVwZGF0ZWQgaW4gdGhlIGRyYWZ0PzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWluIFhpbnhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lj5Hk u7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpl a3JAcnRmbS5jb21dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gMjAxNzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+5bm0PHNwYW4gbGFuZz0iRU4tVVMi PjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMzwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJF Ti1VUyI+DQogMjA6MTM8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4geWlueGlueGluZzxicj4NCjwvc3Bhbj48 Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiB0bHNAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtUTFNdIENvbm5lY3Rpb24gSUQgRHJh ZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1vbiwgT2N0IDIzLCAyMDE3IGF0IDEyOjUzIEFNLCB5aW54 aW54aW5nICZsdDs8YSBocmVmPSJtYWlsdG86eWlueGlueGluZ0BodWF3ZWkuY29tIiB0YXJnZXQ9 Il9ibGFuayI+eWlueGlueGluZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIEVrciw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgdGhlIHBv c3QtaGFuZHNoYWtlIG1lc3NhZ2VzIGluIHRoZSBkcmFmdCwgSSBoYXZlIHNvbWUgY29tbWVudHMu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTkxODk4MTQ0MTIyMTcwOTAxMzNtc29saXN0cGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZW4gb25lIHBlZXIgc2VuZHMgTmV3Y29ubmVj dGlvbklEIG1lc3NhZ2UgdG8gdGhlIG90aGVyLCBpdCB1c2VzIGEgbmV3bHkgZGVmaW5lZCBoYW5k c2hha2UgdHlwZS4gVGhpcyBuZXcgQ0lEIGlzIGF0dGFjaGVkIGluIHRoZSBwYXlsb2FkIG9mIHRo ZSByZWNvcmQgbWVzc2FnZS4NCiBCdXQgdGhlcmUgbXVzdCBiZSBzb21lIGluZm9ybWF0aW9uIGZv ciB0aGUgcmVjZWl2ZXIgdG8ga25vdyB3aGljaCBDSUQgaXMgZ29pbmcgdG8gYmUgdXBkYXRlZC4g SSBtZWFuIHRoYXQgd2hlbiBzZW5kaW5nIG5ldyBDSUQgdGhyb3VnaCB0aGUgTmV3Q29ubmVjdGlv bklEIG1lc3NhZ2UsIHRoZSByZWNvcmQgaGVhZGVyIHNob3VsZCBpbmNsdWRlIHRoZSDigJxvbGTi gJ0gQ0lELCBzbyB0aGF0IHRoZSByZWNlaXZlciBrbm93cyB3aGljaCBvbmUgdG8gcmVwbGFjZS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlRoZSB3YXkgdGhhdCB0aGlzIG1lY2hhbmlzbSB3b3JrcyBpcyB0aGF0IGl0 IGVpdGhlciByZXBsYWNlcyBhbGwgb2YgdGhlbSBvciBzdXBwbGVtZW50cyB0aGUgc2V0LiBJJ20g bm90IHN1cmUgdGhhdCB0aGlzIGlzIHRoZSByaWdodCBkeW5hbWljLCBidXQgSSdkIGZpcnN0IHdh bnQgdG8gc2VlIHNvbWUgd29ya2VkIHRocm91Z2ggY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Im05MTg5ODE0NDEyMjE3MDkwMTMzbXNvbGlzdHBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiB0aGUgZHJhZnQsIGlzIHRoZSBuZXcgQ0lEIGVuY3J5 cHRlZD8gSSBzdWdnZXN0IHRoYXQgdGhlIG5ldyBDSUQgKGZvciB0aGUgZmlyc3QgdGltZSBzZW5k aW5nKSBjYW4gYmUgZW5jcnlwdGVkICZuYnNwO3RvIG1ha2Ugc3VyZSB0aGF0IGFuIGF0dGFja2Vy IGNhbiBub3QgYXNzb2NpYXRlDQogYSBuZXcgQ0lEIHdpdGggYW4gb2xkIENJRC4gTGV04oCZcyBj b25zaWRlciBhIGNhc2Ugd2hlcmUgYW4gYXR0YWNrZXIgd2FudHMgdG8gdHJhY2sgYW4gSU9UIGRl dmljZS4gSWYgdGhlIG5ld2x5IGdlbmVyYXRlZCBDSUQgaXMgbm90IGVuY3J5cHRlZCB3aGVuIHVw ZGF0aW5nLCB0aGUgYXR0YWNrZXIgY2FuIGFzc29jaWF0ZSB0aGUgbmV3IENJRCB3aXRoIHRoZSBv bGQgb25lLiBUaGVuLCB3aGVuIHRoZSBwZWVyIHNlbmRzIG1lc3NhZ2Ugd2l0aCB0aGUNCiBuZXcg Q0lEIGxhdGVyLCB0aGUgYXR0YWNrZXIga25vd3MgdGhpcyBwYWNrZXQgaXMgc2VudCBmcm9tIHRo ZSB2aWN0aW0uIElmIHdlIGVuY3J5cHQgdGhlIG5ldyBDSUQgd2hlbiB1cGRhdGluZywgdGhpcyB0 cmFja2luZyBwcm9ibGVtIGNhbiBiZSBhdm9pZGVkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRMUyAxLjMgcG9zdC1oYW5kc2hha2UgbWVzc2FnZXMgYXJlIGFsd2F5 cyBlbmNyeXB0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwO0Fub3RoZXIgY29tbWVudCBpcyBhYm91dCBzeW1tZXRyaWNhbCBDSUQuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i bTkxODk4MTQ0MTIyMTcwOTAxMzNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkNvbnNpZGVyIGEgY2xpZW50IHNlbmRzIGEgbm9ybWFsIENJRCAoQ0lEIGxlbmd0aCBpcyBu b3QgemVybywgbmFtZWQgQy1DSUQpIHRvIHNlcnZlciwgYnV0IHRoZSBzZXJ2ZXIgZG9lc27igJl0 IHdhbnRzIHRvIHVzZSBjbGllbnTigJlzIENJRCBhbmQgc2VuZHMgYSBDSUQgZ2VuZXJhdGVkDQog YnkgdGhlIHNlcnZlciAobmFtZWQgUy1DSUQpIHRvIHRoZSBjbGllbnQuIDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Tm8uIFRoZSBDSUQgaXMgZm9yIHRoZSBjbGllbnQncyBiZW5lZml0LCBzbyB3aHkgd291bGQgdGhp cyBiZSB1c2VmdWw/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05MTg5 ODE0NDEyMjE3MDkwMTMzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5BdCB0aGUgc2FtZSB0aW1lLCBjbGllbnQgbmVlZHMgdG8ga25vdyBzZXJ2ZXIgaGFzIGlnbm9y ZWQgQy1DSUQgKHdoaWNoIG1lYW5zIHRoZSBkb3dubGluaw0KIGFwcGxpY2F0aW9uIG1lc3NhZ2Ug ZnJvbSB0aGUgc2VydmVyIHdpbGwgbm90IGluY2x1ZGUgQy1DSUQpLCBhbmQgY2xpZW50IHdpbGwg dXNlIFMtQ0lEIGluIGl0cyBhcHBsaWNhdGlvbiBtZXNzYWdlLiBXaWxsIHRoZSBkcmFmdCBjb3Zl ciB0aGlzIHNjZW5hcmlvPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Tm8uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tRWtyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Im05MTg5ODE0NDEyMjE3MDkwMTMzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZaW4gWGlueGluZzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPg0KIEVyaWMgUmVzY29ybGEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWtyQHJ0 Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPl0NCjxicj4NCjwvc3Bhbj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5Y+R6YCB5pe26Ze0PC9zcGFuPjwvYj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiAyMDE3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjEwPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7m nIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEzPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7ml6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIDIxOjAwPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij7mlLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHlpbnhpbnhpbmc8YnI+DQo8L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuaKhOmAgTwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij7kuLvpopg8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IFJlOiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBGcmksIE9jdCAxMywgMjAxNyBh dCAxOjExIEFNLCB5aW54aW54aW5nICZsdDs8YSBocmVmPSJtYWlsdG86eWlueGlueGluZ0BodWF3 ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWlueGlueGluZ0BodWF3ZWkuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIEVrciw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MgZm9yIHlvdXIgZWZmb3J0LiBUaGUgZHJhZnQgbG9va3MgZ29vZC4gQSBmZXcgY29tbWVu dHMgYXJlIGxpc3RlZCBiZWxvdy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJtOTE4OTgxNDQxMjIx NzA5MDEzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkJhc2VkIG9uIHRoZSBkcmFmdCwgZm9yIGVpdGhlciBEVExTMS4y IG9yIDEuMywgc2VydmVyIGNhbuKAmXQgZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZSBwYWNrZXQg ZnJvbSBjbGllbnQgaXMgYSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldCBvciBhIHN0YW5kYXJk IERUTFMgMS4yLzEuMw0KIHBhY2tldC4gKEkgc2F3IFRob21hcyBGb3NzYXRpIGFuZCBOaWtvcyBh bHNvIGludHJvZHVjZWQgdGhpcyBwcm9ibGVtKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im05MTg5ODE0NDEyMjE3MDkwMTMzZ21haWwt bS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TWF5YmUgd2UgY2FuIGFkZCBhIG5ldyDigJxDb250ZW50VHlwZeKAnSBpbiB0aGUg RFRMUyByZWNvcmQgZm9ybWF0IHRvIGhlbHAgc2VydmVyIGlkZW50aWZ5IHRoZSDigJxjb25uZWN0 aW9uIElE4oCdIHBhY2tldC4gSW4gYWRkaXRpb24sIHlvdSBzZWUgdGhlIGxlbmd0aCBvZiB0aGUg cmVjb3JkIHBheWxvYWQNCiBpcyBsaW1pdGVkIGJ5IDJeMTQtMSwgdGhpcyBtZWFucyB0aGUgZmly c3QgdHdvIGJpdHMgb2Yg4oCcbGVuZ3Ro4oCdIGlzIHplcm8uIFdlIGNvdWxkIHV0aWxpemUgdGhp cyBmZWF0dXJlIGFuZCBzZXQgdGhlIGZpcnN0IHR3byBiaXRzIG9yIG1vcmUgYml0cyBvZiBDSUQg YmVpbmcgb25lLCBlLmcuLCAxMTEx4oCmLihidXQgdGhlIENJRCBtdXN0IGJlIHB1dCBiZXR3ZWVu IHNlcXVlbmNlIG51bWJlciBhbmQgbGVuZ3RoKS4gV2hlbiBzZXJ2ZXIgZmluZHMgMTExMQ0KIGFm dGVyIHNlcXVlbmNlIG51bWJlciwgaXQga25vd3MgdGhpcyBpcyBhIOKAnGNvbm5lY3Rpb24gSUTi gJ0gcGFja2V0LiBIb3dldmVyLCBJIGRvbuKAmXQga25vdyB3aGV0aGVyIGl0IGlzIHByb3BlciB0 byB1c2Ugc3VjaCBtYWdpYyBudW1iZXIuIEluIG15IHZpZXcsIGFkZGluZyBuZXcgY29udGVudHR5 cGUgbWF5IGJlIGEgY2hvaWNlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5BcyBJIHNhaWQgdG8gTmlrb3MsIGZvciBEVExTIDEuMiwgeW91IGNhbiB1c2UgYSBz cGVjaWFsbHktY29uc3RydWN0ZWQgQ0lEIHRoYXQgd291bGQgbm90IGJlIGEgdmFsaWQgbGVuZ3Ro IGZpZWxkLiBUaGlzIGNhbiBhY3R1YWxseSBqdXN0IGhhdmUgdGhlIGxlYWRpbmcgYml0DQogc2V0 LiBBcyB3ZSdyZSByZXZpc2luZyB0aGUgRFRMUyAxLjMgcmVjb3JkIGZvcm1hdCwgd2Ugd291bGQg bmVlZCB0byBkbyBzb21ldGhpbmcgZGlmZmVyZW50IGZvciB0aGF0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJtOTE4OTgxNDQxMjIxNzA5MDEzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlz dHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwO0ZvciBEVExTIDEuMiwg dGhlcmUgaXMgbm8gTmV3Q29ubmVjdGlvbklEIGFuZCBSZXF1ZXN0Q29ubmVjdGlvbklEIG1lc3Nh Z2UuIERUTFMgMS4yIHNlcnZlciBhbmQgY2xpZW50IGFsc28gaGFzIHRoZSByZXF1aXJlbWVudCB0 byByZXF1ZXN0IGZvciBhIG5ldyBDSUQsIGFuZA0KIGF0IHByZXNlbnQsIG1hbnkgcHJvZHVjdHMg c3RpbGwgdXNlIERUTFMxLjIgYW5kIEkgYmVsaWV2ZSBpdCB3aWxsIGNvbnRpbnVlIHRvIGJlIHVz ZWQgZm9yIGEgbG9uZyB0aW1lIGV2ZW4gaWYgVExTL0RUTFMxLjMgaXMgcHVibGlzaGVkLiBNeSBw b2ludCBpcyB0aGF0IHdlIG5lZWQgYSBjb3JyZXNwb25kaW5nIG1ldGhvZCBmb3IgdXBkYXRpbmcg Q0lEIGZvciBEVExTMS4yIHRvby48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SW4gZ2VuZXJhbCwgdGhlIFdHIGlz IHdvcmtpbmcgb24gVExTIDEuMywgbm90IFRMUyAxLjIsIHNvIEknbSBub3QgcmVhbGx5IHRoYXQg ZXhjaXRlZCBhYm91dCBwdXR0aW5nIGEgbG90IG9mIGVmZm9ydCBpbnRvIGVuaGFuY2luZyBUTFMg MS4yLiBUaGUgYmFzaWMgZXh0ZW5zaW9uDQogd29ya3MgZmluZSBmb3IgdGhlbSwgYnV0IGlmIHRo ZXkgd2FudCB0byBjaGFuZ2UgQ0lEcywgdGhlbiB0aGV5IHNob3VsZCBhZG9wdCBEVExTIDEuMy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0ibTkxODk4MTQ0MTIyMTcwOTAxMzNnbWFpbC1tLTY1MTM2MDUz MzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IGRvbuKAmXQgcXVpdGUgdW5kZXJzdGFuZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlcw0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTkx ODk4MTQ0MTIyMTcwOTAxMzNnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxJbiBEVExTIDEuMiwgY29ubmVjdGlv biBpZHMgYXJlIGV4Y2hhbmdlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im05MTg5ODE0NDEy MjE3MDkwMTMzZ21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IERUTFMgc2Vzc2lvbiBvbmx5LiZu YnNwOyBUaGVyZSBpcyBubyBkZWRpY2F0ZWQgJnF1b3Q7Y29ubmVjdGlvbiBpZCB1cGRhdGUmcXVv dDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJtOTE4OTgxNDQxMjIxNzA5MDEzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlz dHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBtZXNz YWdlIHRoYXQgYWxsb3dzIG5ldyBjb25uZWN0aW9uIGlkcyB0byBiZSBlc3RhYmxpc2hlZCBtaWQt c2Vzc2lvbiw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJtOTE4OTgxNDQxMjIxNzA5MDEzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQz bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyBiZWNhdXNlIERUTFMgMS4yIGluIGdlbmVyYWwgZG9lcyBub3QgYWxsb3cgcG9zdC1oYW5kc2hh a2UgbWVzc2FnZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJtOTE4OTgxNDQxMjIxNzA5MDEzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1 MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyB0aGF0IGRvIG5vdCB0aGVtc2VsdmVzIGJlZ2luIG90aGVyIGhhbmRzaGFrZXMu4oCdPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBvbmx5IHBvc3Qt aGFuZHNoYWtlIG1lc3NhZ2VzIGFsbG93ZWQgaW4gRFRMUyAxLjIgYXJlIENsaWVudEhlbGxvIGFu ZCBIZWxsb1JlcXVlc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05MTg5ODE0NDEyMjE3MDkwMTMz Z21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QmVzaWRlcywgZm9yIENJRCBpbiBEVExTMS4zLCBJIHRoaW5rIHRoZSBj b3JyZXNwb25kaW5nIHJlc3BvbmRpbmcgbWVzc2FnZXMgb2YgJm5ic3A7TmV3Q29ubmVjdGlvbklE IGFuZCBSZXF1ZXN0Q29ubmVjdGlvbklEIGFyZSBhbHNvIG5lZWRlZCB0byBlbnN1cmUgdGhhdCB0 aGUgcGVlciBoYXMgcmVjZWl2ZWQNCiBDSUQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPk5vLCB5b3UgdXNlIHRoZSBBQ0sgZm9yIHRoZXNlICg8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtZHRsczEzLTAxI3NlY3Rp b24tNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXRscy1kdGxzMTMtMDEjc2VjdGlvbi03PC9hPikuDQogVGhpcyBpcyBvbmUgcmVhc29uIHdo eSB0aGVyZSBpcyBub3QgYSBzdHJhaWdodGZvcndhcmQgcG9ydCB0byBEVExTIDEuMiBmb3IgdGhl c2UgbWVzc2FnZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05MTg5ODE0NDEyMjE3MDkw MTMzZ21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+NC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhlIGdlbmVyYXRpb24gb2YgQ0lEIHNob3VsZCBiZSBtb3JlIGNvbmNy ZXRlLiBGb3IgZXhhbXBsZSwgdXNpbmcgcmFuZG9tIG51bWJlciBvciBhIGNvdW50ZXI/PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPkkgZXhwbGljaXRseSBkaWQgbm90IHdhbnQgdG8gZG8gdGhhdCwgYmVjYXVzZSB0 aGVyZSBhcmUgYSBsb3Qgb2YgdmFsaWQgd2F5cyB0byBnZW5lcmF0ZSBDSUQuIFRoaXMgaXMgYWxz byB3aGF0IHdlIGRpZCBpbiBRVUlDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPi1Fa3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZaW4gWGlueGluZzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPg0KIFRMUyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnRscy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjwvc3Bhbj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5Luj6KGoPC9zcGFuPjwvYj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkVyaWMgUmVzY29ybGE8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4xMDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5pyIPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xMzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4NCiA3OjE0PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij7mlLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ dGxzQGlldGYub3JnPC9hPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGZvbGtzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUganVzdCBw b3N0ZWQgYSBmaXJzdCBjdXQgYXQgYSBjb25uZWN0aW9uIElEIGRyYWZ0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZXNj b3JsYS10bHMtZHRscy1jb25uZWN0aW9uLWlkLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1kdGxzLWNvbm5lY3Rpb24taWQt MDA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Q29tbWVudHMgd2VsY29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4tRWtyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBDF9AE44733284D808F0E585E1919022D150360dggeml511mbschi_-- From nobody Wed Oct 25 21:06:04 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6B813AF04 for ; Wed, 25 Oct 2017 21:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYSWjjbxAXVS for ; Wed, 25 Oct 2017 21:05:59 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0142C13AE0B for ; Wed, 25 Oct 2017 21:05:59 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id w2so1845409ywa.9 for ; Wed, 25 Oct 2017 21:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x4LGD+4S1ok/wgm9NMAMAKPJZ68w3y1nXdS+spksxs4=; b=sMDE9j6QH4IWNiRUOLS5AYEK33hZX9R5T//xcEEtw2KcNPMK2n6coqhpXCXtvHnKgi 1Az4XzOZ5EpgxZJHgwrK0a2J+BiRwcOSy4XbncH1eel1GVLCNx1oCp33jqmkWUxpbgY/ m0nKgQgKcN6Hx6TXXcPsqMwsXVXB8kpHXJtjybNLg5JUWcJyoIVr4pfNzt13vvJY17PW o8D5Q+p1tRfWKjCPt0Gm1Y7IDSAOOdKdXP9JsEMknajmvkCsxeP0mBoQu/iXyiT/FHoR SgAxWi++wXaLnL2nTGq40pO2dQ/0ukEJ3SYR/3n8/t8dHtEX8Wx6TTUk0j4uS8v4Q2jG t65w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x4LGD+4S1ok/wgm9NMAMAKPJZ68w3y1nXdS+spksxs4=; b=aJ0+TZFBE7CtVf92qjnPZ+y7Fl9eW87Xjn7jsxLluh/Y66scUU75/H6+k1OBAUX+qW 9g+E/Lvk8/J9vFbxKMOLMnkutY/pIVvrDhxzW/oE37+9mNciuzYPU0T50FYRg81ePc44 LNxanp1SMD6E4gtVkGlnmzme9ABvTZvpXXbTB8M5jizx3SzAnk/11/8sQBw7SVQ7kjCx 46v8DU1PAqxzSr3H2q7m50wq8ylHhauhaKhNGegxcCs7jIGbD0lroWSViJRnjCHlHVWt m+PAmwzCbmQ7oD89MoQPhinkm4VdyxChLg88Cg+W8ka5dUQU93RcEOsTi0tNEGxnuBMq S+aQ== X-Gm-Message-State: AMCzsaW0qv8xMn5BvCsmebi50wTa71+lCwIVrG9lvYsIbj7x3BKL1bUu 2OJ0K+thKsU0X3i6muDlUmyI2HDyXJ86DjvJvCNMmr8EJzE= X-Google-Smtp-Source: ABhQp+RrMnKOY6CY6Kgj6XkAth29eGOGguxxYXMWXaSAn2hr+sMY1lOGaSEEqPkCj875vQObwMIVAlhhz1ZnkJDORvk= X-Received: by 10.37.45.83 with SMTP id s19mr2587812ybe.400.1508990758186; Wed, 25 Oct 2017 21:05:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Wed, 25 Oct 2017 21:05:17 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 25 Oct 2017 21:05:17 -0700 Message-ID: To: yinxinxing Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f4030435b0101c872e055c6b4a66" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 04:06:03 -0000 --f4030435b0101c872e055c6b4a66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 25, 2017 at 8:02 PM, yinxinxing wrote: > Hi Ekr, > > > > Sorry for the delay. I don=E2=80=99t quite understand =E2=80=9CThe way th= at this > mechanism works is that it either replaces all of them or supplements the > set.=E2=80=9D I see the new CID is encrypted in the post-handshake messag= e and > transferred to the peer. So, the record header of this message needs to > contain the =E2=80=9Cold=E2=80=9D CID. > Yes. I don't understand what your question is. When you send a new CID, you can either label it as cid_immediate or cid_spare. "immediate" means "stop using all the other CIDs you have and "spare" means "this is a CID you can use in addition to the others you have= . > Besides, I have summarized the ways of distinguishing the CID packet and > standard packet that people have discussed in the mailing list: > > a) Adding new ContentType. > > b) Adding new version. (As you replied, since 1.3 is going to > remove version field in the record header, so this choice may not be > proper.) > > c) Using specifically-constructed CID. (I saw you replied that it > would be a way for DTLS 1.2. But for 1.3, you want a different way.) > > d) By comparing the 5-tuple. Martin made this. (If I understand > right) His idea is that first check the 5-tuple of the packet, if there i= s > a match, then use the corresponding key. If there is no match, then treat > the packet as a CID packet and find the CID in the packet according to th= e > new format. But, the precondition for well working is that the 5-tuple of > the CID packet will not be successfully matched in the receiver's 5-tuple > table. > > > > For the above choices, what do you think? Or do you have any other good > solution to be updated in the draft? > I think we should do neither (a) nor (b). I don't really understand (c) but I think (d) is fine, though not the only technique implementors could use. -Ekr > > > Regards, > > Yin Xinxing > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Eric Rescorla [mailto:ekr@rtfm.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B410=E6=9C=8823=E6=97= =A5 20:13 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* yinxinxing > *=E6=8A=84=E9=80=81:* tls@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: [TLS] Connection ID Draft > > > > > > > > On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing > wrote: > > Hi Ekr, > > > > For the post-handshake messages in the draft, I have some comments. > > > > 1. When one peer sends NewconnectionID message to the other, it > uses a newly defined handshake type. This new CID is attached in the > payload of the record message. But there must be some information for the > receiver to know which CID is going to be updated. I mean that when sendi= ng > new CID through the NewConnectionID message, the record header should > include the =E2=80=9Cold=E2=80=9D CID, so that the receiver knows which o= ne to replace. > > The way that this mechanism works is that it either replaces all of them > or supplements the set. I'm not sure that this is the right dynamic, but > I'd first want to see some worked through cases. > > > > 2. In the draft, is the new CID encrypted? I suggest that the new > CID (for the first time sending) can be encrypted to make sure that an > attacker can not associate a new CID with an old CID. Let=E2=80=99s consi= der a case > where an attacker wants to track an IOT device. If the newly generated CI= D > is not encrypted when updating, the attacker can associate the new CID wi= th > the old one. Then, when the peer sends message with the new CID later, th= e > attacker knows this packet is sent from the victim. If we encrypt the new > CID when updating, this tracking problem can be avoided. > > > > TLS 1.3 post-handshake messages are always encrypted. > > > > Another comment is about symmetrical CID. > > 1. Consider a client sends a normal CID (CID length is not zero, > named C-CID) to server, but the server doesn=E2=80=99t wants to use clien= t=E2=80=99s CID > and sends a CID generated by the server (named S-CID) to the client. > > No. The CID is for the client's benefit, so why would this be useful? > > > > At the same time, client needs to know server has ignored C-CID (which > means the downlink application message from the server will not include > C-CID), and client will use S-CID in its application message. Will the > draft cover this scenario? > > No. > > > > -Ekr > > > > > > Yin Xinxing > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* Eric Rescorla [mailto:ekr@rtfm.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4**:* 2017=E5=B9=B410=E6=9C=8813=E6= =97=A5 21:00 > *=E6=94=B6=E4=BB=B6=E4=BA=BA**:* yinxinxing > *=E6=8A=84=E9=80=81**:* tls@ietf.org > *=E4=B8=BB=E9=A2=98**:* Re: [TLS] Connection ID Draft > > > > > > > > On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing wrote= : > > Hi Ekr, > > > > Thanks for your effort. The draft looks good. A few comments are listed > below. > > > > 1. Based on the draft, for either DTLS1.2 or 1.3, server can=E2=80= =99t > differentiate whether the packet from client is a =E2=80=9Cconnection ID= =E2=80=9D packet or > a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also > introduced this problem) > > Maybe we can add a new =E2=80=9CContentType=E2=80=9D in the DTLS record f= ormat to help > server identify the =E2=80=9Cconnection ID=E2=80=9D packet. In addition, = you see the length > of the record payload is limited by 2^14-1, this means the first two bits > of =E2=80=9Clength=E2=80=9D is zero. We could utilize this feature and se= t the first two > bits or more bits of CID being one, e.g., 1111=E2=80=A6.(but the CID must= be put > between sequence number and length). When server finds 1111 after sequenc= e > number, it knows this is a =E2=80=9Cconnection ID=E2=80=9D packet. Howeve= r, I don=E2=80=99t know > whether it is proper to use such magic number. In my view, adding new > contenttype may be a choice. > > > > As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID > that would not be a valid length field. This can actually just have the > leading bit set. As we're revising the DTLS 1.3 record format, we would > need to do something different for that. > > > > 2. For DTLS 1.2, there is no NewConnectionID and > RequestConnectionID message. DTLS 1.2 server and client also has the > requirement to request for a new CID, and at present, many products still > use DTLS1.2 and I believe it will continue to be used for a long time eve= n > if TLS/DTLS1.3 is published. My point is that we need a corresponding > method for updating CID for DTLS1.2 too. > > In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really > that excited about putting a lot of effort into enhancing TLS 1.2. The > basic extension works fine for them, but if they want to change CIDs, the= n > they should adopt DTLS 1.3. > > > > I don=E2=80=99t quite understand the following sentences > > =E2=80=9CIn DTLS 1.2, connection ids are exchanged at the beginning of th= e > > DTLS session only. There is no dedicated "connection id update" > > message that allows new connection ids to be established mid-session, > > because DTLS 1.2 in general does not allow post-handshake messages > > that do not themselves begin other handshakes.=E2=80=9D > > > > The only post-handshake messages allowed in DTLS 1.2 are ClientHello and > HelloRequest. > > > > Besides, for CID in DTLS1.3, I think the corresponding responding message= s > of NewConnectionID and RequestConnectionID are also needed to ensure tha= t > the peer has received CID. > > > > No, you use the ACK for these (https://tools.ietf.org/html/ > draft-ietf-tls-dtls13-01#section-7). This is one reason why there is not > a straightforward port to DTLS 1.2 for these messages. > > > > 4. The generation of CID should be more concrete. For example, > using random number or a counter? > > I explicitly did not want to do that, because there are a lot of valid > ways to generate CID. This is also what we did in QUIC. > > > > -Ekr > > > > > > > > Regards, > > Yin Xinxing > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* TLS [mailto:tls-bounces@ietf.org] *=E4= =BB=A3=E8=A1=A8* Eric Rescorla > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4**:* 2017=E5=B9=B410=E6=9C=8813=E6= =97=A5 7:14 > *=E6=94=B6=E4=BB=B6=E4=BA=BA**:* tls@ietf.org > *=E4=B8=BB=E9=A2=98**:* [TLS] Connection ID Draft > > > > Hi folks, > > > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > > Comments welcome. > > > > -Ekr > > > > > > > > > > > --f4030435b0101c872e055c6b4a66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 25, 2017 at 8:02 PM, yinxinxing <yinxinxing@huawei.com= > wrote:

Hi Ekr,

=C2=A0=

Sorry for the delay. I don= =E2=80=99t quite understand =E2=80=9CThe way th= at this mechanism works is that it either replaces all of them or supplements the set.=E2=80=9D I see the= new CID is encrypted in the post-handshake message and transferred to the = peer. So, the record header of this message needs to contain the =E2=80=9Cold=E2=80=9D CID.


Yes. I don't understand what your question is.

When you send a new CID, you can either label it as=C2=A0= cid_immediate or cid_spare. "immediate" means "stop using a= ll the other CIDs you have and "spare" means "this is a CID = you can use in addition to the others you have.

=C2=A0

Besides, I have summarized = the ways of distinguishing the CID packet and standard packet that people h= ave discussed in the mailing list:

a)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Adding new ContentType= .

b)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Adding new version. (A= s you replied, since 1.3 is going to remove version field in the record hea= der, so this choice may not be proper.)

c)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Using specifically-con= structed CID. (I saw you replied that it would be a way for DTLS 1.2. But f= or 1.3, you want a different way.)

d)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 By comparing the 5-tup= le. Martin made this. (If I understand right) His idea is that first check = the 5-tuple of the packet, if there is a match, then use the corresponding key. If there is no match, then tre= at the packet as a CID packet and find the CID in the packet according to t= he new format. But, the precondition for well working is that the 5-tuple o= f the CID packet will not be successfully matched in the receiver's 5-tuple table.

=C2=A0

For the above choices, what= do you think? Or do you have any other good solution to be updated in the = draft?


I think we sh= ould do neither (a) nor (b). I don't really understand (c) but I think = (d) is fine, though not the only technique implementors could use.

-Ekr

=C2=A0

=C2=A0=

Regards,

Yin Xinxing

=C2=A0=

=E5=8F=91= =E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B410=E6=9C=8823=E6=97=A5 20:13
=E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing
=E6=8A=84=E9=80=81: tls@ietf.org<= br> =E4=B8=BB=E9=A2=98: Re: [TLS] Connection ID Draft

=C2=A0

=C2=A0

=C2=A0

On Mon, Oct 23, 2017 at 12:53 A= M, yinxinxing <yinxinxing@huawei.com> wrote:

Hi Ekr,

=C2=A0

For the post-handshake mess= ages in the draft, I have some comments.=

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When one peer sends NewconnectionID message= to the other, it uses a newly defined handshake type. This new CID is atta= ched in the payload of the record message. But there must be some information for the receiver to know which CID is g= oing to be updated. I mean that when sending new CID through the NewConnect= ionID message, the record header should include the =E2=80=9Cold=E2=80=9D C= ID, so that the receiver knows which one to replace.

The way that this mechanism wor= ks is that it either replaces all of them or supplements the set. I'm n= ot sure that this is the right dynamic, but I'd first want to see some = worked through cases.

=C2=A0

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the draft, is the new CID encrypted? I s= uggest that the new CID (for the first time sending) can be encrypted =C2= =A0to make sure that an attacker can not associate a new CID with an old CID. Let=E2=80=99s consider a case where an attacker= wants to track an IOT device. If the newly generated CID is not encrypted = when updating, the attacker can associate the new CID with the old one. The= n, when the peer sends message with the new CID later, the attacker knows this packet is sent from the victim. If = we encrypt the new CID when updating, this tracking problem can be avoided.=

=C2=A0

TLS 1.3 post-handshake messages= are always encrypted.

=C2=A0

=C2=A0Another comment is ab= out symmetrical CID.

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Consider a client sends a normal CID (CID l= ength is not zero, named C-CID) to server, but the server doesn=E2=80=99t w= ants to use client=E2=80=99s CID and sends a CID generated by the server (named S-CID) to the client. =

No. The CID is for the client&#= 39;s benefit, so why would this be useful?

=C2=A0

At the same time, clie= nt needs to know server has ignored C-CID (which means the downlink application message from the server will not include C-CID), and client wi= ll use S-CID in its application message. Will the draft cover this scenario= ?

No.

=C2=A0

-Ekr

=C2=A0

=C2=A0

Yin Xinxing

=C2=A0

=E5=8F=91=E4=BB=B6= =E4=BA=BA: Eric Rescorla [mailto:ek= r@rtfm.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4: 2017=E5= =B9=B410=E6=9C=8813=E6=97=A5 21:00
=E6=94=B6=E4=BB=B6=E4=BA=BA= : yinxinxing
=E6=8A=84=E9=80=81:<= /span> tls@ietf.org
=E4=B8=BB=E9=A2=98:<= /span> Re: [TLS] Connection ID Draft=

=C2=A0

=C2=A0

=C2=A0

On Fri, Oct 13, 2017 at 1:11 AM= , yinxinxing <yinxinxing@huawei.com> wrote:

Hi Ekr,

=C2=A0

Thanks for your effort. The= draft looks good. A few comments are listed below.

=C2=A0

1.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Based on the draft, for either DTLS1.2 or 1= .3, server can=E2=80=99t differentiate whether the packet from client is a = =E2=80=9Cconnection ID=E2=80=9D packet or a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also introduced this problem)

Maybe we can add a new =E2=80=9CContentType=E2=80= =9D in the DTLS record format to help server identify the =E2=80=9Cconnecti= on ID=E2=80=9D packet. In addition, you see the length of the record payloa= d is limited by 2^14-1, this means the first two bits of =E2=80=9Clength=E2= =80=9D is zero. We could utilize this feature and set the first two bits or= more bits of CID being one, e.g., 1111=E2=80=A6.(but the CID must be put b= etween sequence number and length). When server finds 1111 after sequence number, it knows this is a =E2=80=9Cconnection ID=E2=80=9D = packet. However, I don=E2=80=99t know whether it is proper to use such magi= c number. In my view, adding new contenttype may be a choice.

=C2=A0

As I said to Nikos, for DTLS 1.= 2, you can use a specially-constructed CID that would not be a valid length= field. This can actually just have the leading bit set. As we're revising the DTLS 1.3 record format, we would need to do= something different for that.

=C2=A0

2.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0For DTLS 1.2, there is no NewConnecti= onID and RequestConnectionID message. DTLS 1.2 server and client also has t= he requirement to request for a new CID, and at present, many products still use DTLS1.2 and I believe it will continue= to be used for a long time even if TLS/DTLS1.3 is published. My point is t= hat we need a corresponding method for updating CID for DTLS1.2 too.=

In general, the WG is working o= n TLS 1.3, not TLS 1.2, so I'm not really that excited about putting a = lot of effort into enhancing TLS 1.2. The basic extension works fine for them, but if they want to change CIDs, then they should ado= pt DTLS 1.3.

=C2=A0

I don=E2=80=99t quite understand the following sen= tences

=E2=80=9CIn DTLS 1.2, connection ids are exchanged= at the beginning of the

=C2=A0=C2=A0 DTLS session only.=C2=A0 There is no = dedicated "connection id update"

=C2=A0=C2=A0 message that allows new connection id= s to be established mid-session,<= /span>

=C2=A0=C2=A0 because DTLS 1.2 in general does not = allow post-handshake messages

=C2=A0=C2=A0 that do not themselves begin other ha= ndshakes.=E2=80=9D

=C2=A0

The only post-handshake message= s allowed in DTLS 1.2 are ClientHello and HelloRequest.

=C2=A0

Besides, for CID in DTLS1.3, I think the correspon= ding responding messages of =C2=A0NewConnectionID and RequestConnectionID a= re also needed to ensure that the peer has received CID.

=C2=A0

No, you use the ACK for these (= https://tools.ietf.org/html/draft-ietf-tls-dtls13-01= #section-7). This is one reason why there is not a straightforward port to DTLS 1.2 for= these messages.

=C2=A0

4.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The generation of CID should be more concre= te. For example, using random number or a counter?

I explicitly did not want to do= that, because there are a lot of valid ways to generate CID. This is also = what we did in QUIC.

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

Regards,

Yin Xinxing

=C2=A0

=E5=8F=91=E4=BB=B6= =E4=BA=BA: TLS [mailto:tls-= bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Eric Rescorla
=E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4: 2017=E5= =B9=B410=E6=9C=8813=E6=97=A5 7:14
=E6=94=B6=E4=BB=B6=E4=BA=BA= : tls@ietf.org
=E4=B8=BB=E9=A2=98:<= /span> [TLS] Connection ID Draft<= /u>

=C2=A0

Hi folks,<= /p>

=C2=A0

I have just posted a first cut = at a connection ID draft.

=C2=A0

Comments welcome.=

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--f4030435b0101c872e055c6b4a66-- From nobody Thu Oct 26 00:33:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EF31395ED for ; Thu, 26 Oct 2017 00:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCFHVr0AoH_v for ; Thu, 26 Oct 2017 00:33:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BBA1394E4 for ; Thu, 26 Oct 2017 00:33:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRI71241; Thu, 26 Oct 2017 07:33:49 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 26 Oct 2017 08:33:48 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.184]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Thu, 26 Oct 2017 15:33:40 +0800 From: yinxinxing To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AdNOLA0ZuCXfijEZQBGSnO4e+WkWww== Date: Thu, 26 Oct 2017 07:33:40 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022D1503BCdggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010205.59F18FDE.001B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.184, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f4e239171d64f650785ae4a1845856df Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 07:33:57 -0000 --_000_DBDF9AE44733284D808F0E585E1919022D1503BCdggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MS4gICAgICAgSSBtZWFuIHRoYXQgTmV3Y29ubmVjdGlvbklEIG1lc3NhZ2UgYW5kIHRoZSBSZXF1 ZXNDb25uZWN0aW9uSUQgbWVzc2FnZSBzaG91bGQgdXNlIHRoZSBuZXcgcmVjb3JkIGZvcm1hdCAo aW5zdGVhZCBvZiBzdGFuZGFyZCBEVExTMS4yIHJlY29yZCBmb3JtYXQpLiBCZXNpZGVzLCB0aGUg Q0lEIGluIHRoZSByZWNvcmQgaGVhZGVyIHNoYWxsIG5vdCBiZSB0aGUgbmV3IENJRC4NCg0KDQoy LiAgICAgICAoYyk6IFNpbmNlIHRoZSBmaXJzdCB0d28gYml0cyBvZiAxNi1iaXQgbGVuZ3RoIHZh cmlhYmxlIGlzIHplcm8sIHdlIGNhbiB1c2UgYSAgc3BlY2lmaWNhbGx5LWNvbnN0cnVjdGVkIENJ RCBsaWtlIOKAnDExeHh4eOKApuKAnSAob3Igb3RoZXIgcHJvcGVyIGZvcm1hdCkgdG8gaWRlbnRp ZnkgYSBDSUQgcGFja2V0Lg0KKEkgaGF2ZSBtZW50aW9uZWQgdGhpcyBpbiBwcmV2aW91cyBlbWFp bCBhbmQgeW91IGdhdmUgc29tZSBmZWVkYmFjazoNCg0KMS4gICAgICAgQmFzZWQgb24gdGhlIGRy YWZ0LCBmb3IgZWl0aGVyIERUTFMxLjIgb3IgMS4zLCBzZXJ2ZXIgY2Fu4oCZdCBkaWZmZXJlbnRp YXRlIHdoZXRoZXIgdGhlIHBhY2tldCBmcm9tIGNsaWVudCBpcyBhIOKAnGNvbm5lY3Rpb24gSUTi gJ0gcGFja2V0IG9yIGEgc3RhbmRhcmQgRFRMUyAxLjIvMS4zIHBhY2tldC4gKEkgc2F3IFRob21h cyBGb3NzYXRpIGFuZCBOaWtvcyBhbHNvIGludHJvZHVjZWQgdGhpcyBwcm9ibGVtKQ0KDQpNYXli ZSB3ZSBjYW4gYWRkIGEgbmV3IOKAnENvbnRlbnRUeXBl4oCdIGluIHRoZSBEVExTIHJlY29yZCBm b3JtYXQgdG8gaGVscCBzZXJ2ZXIgaWRlbnRpZnkgdGhlIOKAnGNvbm5lY3Rpb24gSUTigJ0gcGFj a2V0LiBJbiBhZGRpdGlvbiwgeW91IHNlZSB0aGUgbGVuZ3RoIG9mIHRoZSByZWNvcmQgcGF5bG9h ZCBpcyBsaW1pdGVkIGJ5IDJeMTQtMSwgdGhpcyBtZWFucyB0aGUgZmlyc3QgdHdvIGJpdHMgb2Yg 4oCcbGVuZ3Ro4oCdIGlzIHplcm8uIFdlIGNvdWxkIHV0aWxpemUgdGhpcyBmZWF0dXJlIGFuZCBz ZXQgdGhlIGZpcnN0IHR3byBiaXRzIG9yIG1vcmUgYml0cyBvZiBDSUQgYmVpbmcgb25lLCBlLmcu LCAxMTEx4oCmLihidXQgdGhlIENJRCBtdXN0IGJlIHB1dCBiZXR3ZWVuIHNlcXVlbmNlIG51bWJl ciBhbmQgbGVuZ3RoKS4gV2hlbiBzZXJ2ZXIgZmluZHMgMTExMSBhZnRlciBzZXF1ZW5jZSBudW1i ZXIsIGl0IGtub3dzIHRoaXMgaXMgYSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldC4gSG93ZXZl ciwgSSBkb27igJl0IGtub3cgd2hldGhlciBpdCBpcyBwcm9wZXIgdG8gdXNlIHN1Y2ggbWFnaWMg bnVtYmVyLiBJbiBteSB2aWV3LCBhZGRpbmcgbmV3IGNvbnRlbnR0eXBlIG1heSBiZSBhIGNob2lj ZS4NCkFzIEkgc2FpZCB0byBOaWtvcywgZm9yIERUTFMgMS4yLCB5b3UgY2FuIHVzZSBhIHNwZWNp YWxseS1jb25zdHJ1Y3RlZCBDSUQgdGhhdCB3b3VsZCBub3QgYmUgYSB2YWxpZCBsZW5ndGggZmll bGQuIFRoaXMgY2FuIGFjdHVhbGx5IGp1c3QgaGF2ZSB0aGUgbGVhZGluZyBiaXQgc2V0LiBBcyB3 ZSdyZSByZXZpc2luZyB0aGUgRFRMUyAxLjMgcmVjb3JkIGZvcm1hdCwgd2Ugd291bGQgbmVlZCB0 byBkbyBzb21ldGhpbmcgZGlmZmVyZW50IGZvciB0aGF0Lg0KKQ0KDQoNCjMuICAgICAgIEZvciAo ZCksIEkgaGF2ZSBzb21lIGNvbW1lbnRzIGFib3V0IGl0cyBwcmVjb25kaXRpb24uIFlvdSBzZWUg TkFUIGRldmljZSBjYW4gcmVhbGxvY2F0ZSB0aGUgcmVsZWFzZWQgcG9ydC9JUCBhZGRyZXNzIHRv IGNsaWVudCwgd2hpY2ggbWVhbnMgdGhlIHByZWNvbmRpdGlvbiBkb2VzbuKAmXQgYWx3YXlzIGhv bGQuDQoNCuWPkeS7tuS6ujogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NCuWP kemAgeaXtumXtDogMjAxN+W5tDEw5pyIMjbml6UgMTI6MDUNCuaUtuS7tuS6ujogeWlueGlueGlu Zw0K5oqE6YCBOiB0bHNAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtUTFNdIENvbm5lY3Rpb24gSUQg RHJhZnQNCg0KDQoNCk9uIFdlZCwgT2N0IDI1LCAyMDE3IGF0IDg6MDIgUE0sIHlpbnhpbnhpbmcg PHlpbnhpbnhpbmdAaHVhd2VpLmNvbTxtYWlsdG86eWlueGlueGluZ0BodWF3ZWkuY29tPj4gd3Jv dGU6DQpIaSBFa3IsDQoNClNvcnJ5IGZvciB0aGUgZGVsYXkuIEkgZG9u4oCZdCBxdWl0ZSB1bmRl cnN0YW5kIOKAnFRoZSB3YXkgdGhhdCB0aGlzIG1lY2hhbmlzbSB3b3JrcyBpcyB0aGF0IGl0IGVp dGhlciByZXBsYWNlcyBhbGwgb2YgdGhlbSBvciBzdXBwbGVtZW50cyB0aGUgc2V0LuKAnSBJIHNl ZSB0aGUgbmV3IENJRCBpcyBlbmNyeXB0ZWQgaW4gdGhlIHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2Ug YW5kIHRyYW5zZmVycmVkIHRvIHRoZSBwZWVyLiBTbywgdGhlIHJlY29yZCBoZWFkZXIgb2YgdGhp cyBtZXNzYWdlIG5lZWRzIHRvIGNvbnRhaW4gdGhlIOKAnG9sZOKAnSBDSUQuDQoNClllcy4gSSBk b24ndCB1bmRlcnN0YW5kIHdoYXQgeW91ciBxdWVzdGlvbiBpcy4NCg0KV2hlbiB5b3Ugc2VuZCBh IG5ldyBDSUQsIHlvdSBjYW4gZWl0aGVyIGxhYmVsIGl0IGFzICBjaWRfaW1tZWRpYXRlIG9yIGNp ZF9zcGFyZS4gImltbWVkaWF0ZSIgbWVhbnMgInN0b3AgdXNpbmcgYWxsIHRoZSBvdGhlciBDSURz IHlvdSBoYXZlIGFuZCAic3BhcmUiIG1lYW5zICJ0aGlzIGlzIGEgQ0lEIHlvdSBjYW4gdXNlIGlu IGFkZGl0aW9uIHRvIHRoZSBvdGhlcnMgeW91IGhhdmUuDQoNCg0KQmVzaWRlcywgSSBoYXZlIHN1 bW1hcml6ZWQgdGhlIHdheXMgb2YgZGlzdGluZ3Vpc2hpbmcgdGhlIENJRCBwYWNrZXQgYW5kIHN0 YW5kYXJkIHBhY2tldCB0aGF0IHBlb3BsZSBoYXZlIGRpc2N1c3NlZCBpbiB0aGUgbWFpbGluZyBs aXN0Og0KDQphKSAgICAgICBBZGRpbmcgbmV3IENvbnRlbnRUeXBlLg0KDQpiKSAgICAgICBBZGRp bmcgbmV3IHZlcnNpb24uIChBcyB5b3UgcmVwbGllZCwgc2luY2UgMS4zIGlzIGdvaW5nIHRvIHJl bW92ZSB2ZXJzaW9uIGZpZWxkIGluIHRoZSByZWNvcmQgaGVhZGVyLCBzbyB0aGlzIGNob2ljZSBt YXkgbm90IGJlIHByb3Blci4pDQoNCmMpICAgICAgIFVzaW5nIHNwZWNpZmljYWxseS1jb25zdHJ1 Y3RlZCBDSUQuIChJIHNhdyB5b3UgcmVwbGllZCB0aGF0IGl0IHdvdWxkIGJlIGEgd2F5IGZvciBE VExTIDEuMi4gQnV0IGZvciAxLjMsIHlvdSB3YW50IGEgZGlmZmVyZW50IHdheS4pDQoNCmQpICAg ICAgIEJ5IGNvbXBhcmluZyB0aGUgNS10dXBsZS4gTWFydGluIG1hZGUgdGhpcy4gKElmIEkgdW5k ZXJzdGFuZCByaWdodCkgSGlzIGlkZWEgaXMgdGhhdCBmaXJzdCBjaGVjayB0aGUgNS10dXBsZSBv ZiB0aGUgcGFja2V0LCBpZiB0aGVyZSBpcyBhIG1hdGNoLCB0aGVuIHVzZSB0aGUgY29ycmVzcG9u ZGluZyBrZXkuIElmIHRoZXJlIGlzIG5vIG1hdGNoLCB0aGVuIHRyZWF0IHRoZSBwYWNrZXQgYXMg YSBDSUQgcGFja2V0IGFuZCBmaW5kIHRoZSBDSUQgaW4gdGhlIHBhY2tldCBhY2NvcmRpbmcgdG8g dGhlIG5ldyBmb3JtYXQuIEJ1dCwgdGhlIHByZWNvbmRpdGlvbiBmb3Igd2VsbCB3b3JraW5nIGlz IHRoYXQgdGhlIDUtdHVwbGUgb2YgdGhlIENJRCBwYWNrZXQgd2lsbCBub3QgYmUgc3VjY2Vzc2Z1 bGx5IG1hdGNoZWQgaW4gdGhlIHJlY2VpdmVyJ3MgNS10dXBsZSB0YWJsZS4NCg0KDQpGb3IgdGhl IGFib3ZlIGNob2ljZXMsIHdoYXQgZG8geW91IHRoaW5rPyBPciBkbyB5b3UgaGF2ZSBhbnkgb3Ro ZXIgZ29vZCBzb2x1dGlvbiB0byBiZSB1cGRhdGVkIGluIHRoZSBkcmFmdD8NCg0KSSB0aGluayB3 ZSBzaG91bGQgZG8gbmVpdGhlciAoYSkgbm9yIChiKS4gSSBkb24ndCByZWFsbHkgdW5kZXJzdGFu ZCAoYykgYnV0IEkgdGhpbmsgKGQpIGlzIGZpbmUsIHRob3VnaCBub3QgdGhlIG9ubHkgdGVjaG5p cXVlIGltcGxlbWVudG9ycyBjb3VsZCB1c2UuDQoNCi1Fa3INCg0KDQoNClJlZ2FyZHMsDQpZaW4g WGlueGluZw0KDQrlj5Hku7bkuro6IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb208 bWFpbHRvOmVrckBydGZtLmNvbT5dDQrlj5HpgIHml7bpl7Q6IDIwMTflubQxMOaciDIz5pelIDIw OjEzDQrmlLbku7bkuro6IHlpbnhpbnhpbmcNCuaKhOmAgTogdGxzQGlldGYub3JnPG1haWx0bzp0 bHNAaWV0Zi5vcmc+DQrkuLvpopg6IFJlOiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0DQoNCg0K DQpPbiBNb24sIE9jdCAyMywgMjAxNyBhdCAxMjo1MyBBTSwgeWlueGlueGluZyA8eWlueGlueGlu Z0BodWF3ZWkuY29tPG1haWx0bzp5aW54aW54aW5nQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIEVr ciwNCg0KRm9yIHRoZSBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBpbiB0aGUgZHJhZnQsIEkgaGF2 ZSBzb21lIGNvbW1lbnRzLg0KDQoNCjEuICAgICAgIFdoZW4gb25lIHBlZXIgc2VuZHMgTmV3Y29u bmVjdGlvbklEIG1lc3NhZ2UgdG8gdGhlIG90aGVyLCBpdCB1c2VzIGEgbmV3bHkgZGVmaW5lZCBo YW5kc2hha2UgdHlwZS4gVGhpcyBuZXcgQ0lEIGlzIGF0dGFjaGVkIGluIHRoZSBwYXlsb2FkIG9m IHRoZSByZWNvcmQgbWVzc2FnZS4gQnV0IHRoZXJlIG11c3QgYmUgc29tZSBpbmZvcm1hdGlvbiBm b3IgdGhlIHJlY2VpdmVyIHRvIGtub3cgd2hpY2ggQ0lEIGlzIGdvaW5nIHRvIGJlIHVwZGF0ZWQu IEkgbWVhbiB0aGF0IHdoZW4gc2VuZGluZyBuZXcgQ0lEIHRocm91Z2ggdGhlIE5ld0Nvbm5lY3Rp b25JRCBtZXNzYWdlLCB0aGUgcmVjb3JkIGhlYWRlciBzaG91bGQgaW5jbHVkZSB0aGUg4oCcb2xk 4oCdIENJRCwgc28gdGhhdCB0aGUgcmVjZWl2ZXIga25vd3Mgd2hpY2ggb25lIHRvIHJlcGxhY2Uu DQpUaGUgd2F5IHRoYXQgdGhpcyBtZWNoYW5pc20gd29ya3MgaXMgdGhhdCBpdCBlaXRoZXIgcmVw bGFjZXMgYWxsIG9mIHRoZW0gb3Igc3VwcGxlbWVudHMgdGhlIHNldC4gSSdtIG5vdCBzdXJlIHRo YXQgdGhpcyBpcyB0aGUgcmlnaHQgZHluYW1pYywgYnV0IEknZCBmaXJzdCB3YW50IHRvIHNlZSBz b21lIHdvcmtlZCB0aHJvdWdoIGNhc2VzLg0KDQoNCjIuICAgICAgIEluIHRoZSBkcmFmdCwgaXMg dGhlIG5ldyBDSUQgZW5jcnlwdGVkPyBJIHN1Z2dlc3QgdGhhdCB0aGUgbmV3IENJRCAoZm9yIHRo ZSBmaXJzdCB0aW1lIHNlbmRpbmcpIGNhbiBiZSBlbmNyeXB0ZWQgIHRvIG1ha2Ugc3VyZSB0aGF0 IGFuIGF0dGFja2VyIGNhbiBub3QgYXNzb2NpYXRlIGEgbmV3IENJRCB3aXRoIGFuIG9sZCBDSUQu IExldOKAmXMgY29uc2lkZXIgYSBjYXNlIHdoZXJlIGFuIGF0dGFja2VyIHdhbnRzIHRvIHRyYWNr IGFuIElPVCBkZXZpY2UuIElmIHRoZSBuZXdseSBnZW5lcmF0ZWQgQ0lEIGlzIG5vdCBlbmNyeXB0 ZWQgd2hlbiB1cGRhdGluZywgdGhlIGF0dGFja2VyIGNhbiBhc3NvY2lhdGUgdGhlIG5ldyBDSUQg d2l0aCB0aGUgb2xkIG9uZS4gVGhlbiwgd2hlbiB0aGUgcGVlciBzZW5kcyBtZXNzYWdlIHdpdGgg dGhlIG5ldyBDSUQgbGF0ZXIsIHRoZSBhdHRhY2tlciBrbm93cyB0aGlzIHBhY2tldCBpcyBzZW50 IGZyb20gdGhlIHZpY3RpbS4gSWYgd2UgZW5jcnlwdCB0aGUgbmV3IENJRCB3aGVuIHVwZGF0aW5n LCB0aGlzIHRyYWNraW5nIHByb2JsZW0gY2FuIGJlIGF2b2lkZWQuDQoNClRMUyAxLjMgcG9zdC1o YW5kc2hha2UgbWVzc2FnZXMgYXJlIGFsd2F5cyBlbmNyeXB0ZWQuDQoNCiBBbm90aGVyIGNvbW1l bnQgaXMgYWJvdXQgc3ltbWV0cmljYWwgQ0lELg0KDQoxLiAgICAgICBDb25zaWRlciBhIGNsaWVu dCBzZW5kcyBhIG5vcm1hbCBDSUQgKENJRCBsZW5ndGggaXMgbm90IHplcm8sIG5hbWVkIEMtQ0lE KSB0byBzZXJ2ZXIsIGJ1dCB0aGUgc2VydmVyIGRvZXNu4oCZdCB3YW50cyB0byB1c2UgY2xpZW50 4oCZcyBDSUQgYW5kIHNlbmRzIGEgQ0lEIGdlbmVyYXRlZCBieSB0aGUgc2VydmVyIChuYW1lZCBT LUNJRCkgdG8gdGhlIGNsaWVudC4NCk5vLiBUaGUgQ0lEIGlzIGZvciB0aGUgY2xpZW50J3MgYmVu ZWZpdCwgc28gd2h5IHdvdWxkIHRoaXMgYmUgdXNlZnVsPw0KDQoNCkF0IHRoZSBzYW1lIHRpbWUs IGNsaWVudCBuZWVkcyB0byBrbm93IHNlcnZlciBoYXMgaWdub3JlZCBDLUNJRCAod2hpY2ggbWVh bnMgdGhlIGRvd25saW5rIGFwcGxpY2F0aW9uIG1lc3NhZ2UgZnJvbSB0aGUgc2VydmVyIHdpbGwg bm90IGluY2x1ZGUgQy1DSUQpLCBhbmQgY2xpZW50IHdpbGwgdXNlIFMtQ0lEIGluIGl0cyBhcHBs aWNhdGlvbiBtZXNzYWdlLiBXaWxsIHRoZSBkcmFmdCBjb3ZlciB0aGlzIHNjZW5hcmlvPw0KTm8u DQoNCi1Fa3INCg0KDQoNCllpbiBYaW54aW5nDQoNCuWPkeS7tuS6ujogRXJpYyBSZXNjb3JsYSBb bWFpbHRvOmVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPl0NCuWPkemAgeaXtumXtDog MjAxN+W5tDEw5pyIMTPml6UgMjE6MDANCuaUtuS7tuS6ujogeWlueGlueGluZw0K5oqE6YCBOiB0 bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NCuS4u+mimDogUmU6IFtUTFNdIENvbm5l Y3Rpb24gSUQgRHJhZnQNCg0KDQoNCk9uIEZyaSwgT2N0IDEzLCAyMDE3IGF0IDE6MTEgQU0sIHlp bnhpbnhpbmcgPHlpbnhpbnhpbmdAaHVhd2VpLmNvbTxtYWlsdG86eWlueGlueGluZ0BodWF3ZWku Y29tPj4gd3JvdGU6DQpIaSBFa3IsDQoNClRoYW5rcyBmb3IgeW91ciBlZmZvcnQuIFRoZSBkcmFm dCBsb29rcyBnb29kLiBBIGZldyBjb21tZW50cyBhcmUgbGlzdGVkIGJlbG93Lg0KDQoNCjEuICAg ICAgIEJhc2VkIG9uIHRoZSBkcmFmdCwgZm9yIGVpdGhlciBEVExTMS4yIG9yIDEuMywgc2VydmVy IGNhbuKAmXQgZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZSBwYWNrZXQgZnJvbSBjbGllbnQgaXMg YSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldCBvciBhIHN0YW5kYXJkIERUTFMgMS4yLzEuMyBw YWNrZXQuIChJIHNhdyBUaG9tYXMgRm9zc2F0aSBhbmQgTmlrb3MgYWxzbyBpbnRyb2R1Y2VkIHRo aXMgcHJvYmxlbSkNCg0KTWF5YmUgd2UgY2FuIGFkZCBhIG5ldyDigJxDb250ZW50VHlwZeKAnSBp biB0aGUgRFRMUyByZWNvcmQgZm9ybWF0IHRvIGhlbHAgc2VydmVyIGlkZW50aWZ5IHRoZSDigJxj b25uZWN0aW9uIElE4oCdIHBhY2tldC4gSW4gYWRkaXRpb24sIHlvdSBzZWUgdGhlIGxlbmd0aCBv ZiB0aGUgcmVjb3JkIHBheWxvYWQgaXMgbGltaXRlZCBieSAyXjE0LTEsIHRoaXMgbWVhbnMgdGhl IGZpcnN0IHR3byBiaXRzIG9mIOKAnGxlbmd0aOKAnSBpcyB6ZXJvLiBXZSBjb3VsZCB1dGlsaXpl IHRoaXMgZmVhdHVyZSBhbmQgc2V0IHRoZSBmaXJzdCB0d28gYml0cyBvciBtb3JlIGJpdHMgb2Yg Q0lEIGJlaW5nIG9uZSwgZS5nLiwgMTExMeKApi4oYnV0IHRoZSBDSUQgbXVzdCBiZSBwdXQgYmV0 d2VlbiBzZXF1ZW5jZSBudW1iZXIgYW5kIGxlbmd0aCkuIFdoZW4gc2VydmVyIGZpbmRzIDExMTEg YWZ0ZXIgc2VxdWVuY2UgbnVtYmVyLCBpdCBrbm93cyB0aGlzIGlzIGEg4oCcY29ubmVjdGlvbiBJ ROKAnSBwYWNrZXQuIEhvd2V2ZXIsIEkgZG9u4oCZdCBrbm93IHdoZXRoZXIgaXQgaXMgcHJvcGVy IHRvIHVzZSBzdWNoIG1hZ2ljIG51bWJlci4gSW4gbXkgdmlldywgYWRkaW5nIG5ldyBjb250ZW50 dHlwZSBtYXkgYmUgYSBjaG9pY2UuDQoNCkFzIEkgc2FpZCB0byBOaWtvcywgZm9yIERUTFMgMS4y LCB5b3UgY2FuIHVzZSBhIHNwZWNpYWxseS1jb25zdHJ1Y3RlZCBDSUQgdGhhdCB3b3VsZCBub3Qg YmUgYSB2YWxpZCBsZW5ndGggZmllbGQuIFRoaXMgY2FuIGFjdHVhbGx5IGp1c3QgaGF2ZSB0aGUg bGVhZGluZyBiaXQgc2V0LiBBcyB3ZSdyZSByZXZpc2luZyB0aGUgRFRMUyAxLjMgcmVjb3JkIGZv cm1hdCwgd2Ugd291bGQgbmVlZCB0byBkbyBzb21ldGhpbmcgZGlmZmVyZW50IGZvciB0aGF0Lg0K DQoNCjIuICAgICAgICBGb3IgRFRMUyAxLjIsIHRoZXJlIGlzIG5vIE5ld0Nvbm5lY3Rpb25JRCBh bmQgUmVxdWVzdENvbm5lY3Rpb25JRCBtZXNzYWdlLiBEVExTIDEuMiBzZXJ2ZXIgYW5kIGNsaWVu dCBhbHNvIGhhcyB0aGUgcmVxdWlyZW1lbnQgdG8gcmVxdWVzdCBmb3IgYSBuZXcgQ0lELCBhbmQg YXQgcHJlc2VudCwgbWFueSBwcm9kdWN0cyBzdGlsbCB1c2UgRFRMUzEuMiBhbmQgSSBiZWxpZXZl IGl0IHdpbGwgY29udGludWUgdG8gYmUgdXNlZCBmb3IgYSBsb25nIHRpbWUgZXZlbiBpZiBUTFMv RFRMUzEuMyBpcyBwdWJsaXNoZWQuIE15IHBvaW50IGlzIHRoYXQgd2UgbmVlZCBhIGNvcnJlc3Bv bmRpbmcgbWV0aG9kIGZvciB1cGRhdGluZyBDSUQgZm9yIERUTFMxLjIgdG9vLg0KSW4gZ2VuZXJh bCwgdGhlIFdHIGlzIHdvcmtpbmcgb24gVExTIDEuMywgbm90IFRMUyAxLjIsIHNvIEknbSBub3Qg cmVhbGx5IHRoYXQgZXhjaXRlZCBhYm91dCBwdXR0aW5nIGEgbG90IG9mIGVmZm9ydCBpbnRvIGVu aGFuY2luZyBUTFMgMS4yLiBUaGUgYmFzaWMgZXh0ZW5zaW9uIHdvcmtzIGZpbmUgZm9yIHRoZW0s IGJ1dCBpZiB0aGV5IHdhbnQgdG8gY2hhbmdlIENJRHMsIHRoZW4gdGhleSBzaG91bGQgYWRvcHQg RFRMUyAxLjMuDQoNCg0KSSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQgdGhlIGZvbGxvd2luZyBz ZW50ZW5jZXMNCg0K4oCcSW4gRFRMUyAxLjIsIGNvbm5lY3Rpb24gaWRzIGFyZSBleGNoYW5nZWQg YXQgdGhlIGJlZ2lubmluZyBvZiB0aGUNCg0KICAgRFRMUyBzZXNzaW9uIG9ubHkuICBUaGVyZSBp cyBubyBkZWRpY2F0ZWQgImNvbm5lY3Rpb24gaWQgdXBkYXRlIg0KDQogICBtZXNzYWdlIHRoYXQg YWxsb3dzIG5ldyBjb25uZWN0aW9uIGlkcyB0byBiZSBlc3RhYmxpc2hlZCBtaWQtc2Vzc2lvbiwN Cg0KICAgYmVjYXVzZSBEVExTIDEuMiBpbiBnZW5lcmFsIGRvZXMgbm90IGFsbG93IHBvc3QtaGFu ZHNoYWtlIG1lc3NhZ2VzDQoNCiAgIHRoYXQgZG8gbm90IHRoZW1zZWx2ZXMgYmVnaW4gb3RoZXIg aGFuZHNoYWtlcy7igJ0NCg0KVGhlIG9ubHkgcG9zdC1oYW5kc2hha2UgbWVzc2FnZXMgYWxsb3dl ZCBpbiBEVExTIDEuMiBhcmUgQ2xpZW50SGVsbG8gYW5kIEhlbGxvUmVxdWVzdC4NCg0KDQpCZXNp ZGVzLCBmb3IgQ0lEIGluIERUTFMxLjMsIEkgdGhpbmsgdGhlIGNvcnJlc3BvbmRpbmcgcmVzcG9u ZGluZyBtZXNzYWdlcyBvZiAgTmV3Q29ubmVjdGlvbklEIGFuZCBSZXF1ZXN0Q29ubmVjdGlvbklE IGFyZSBhbHNvIG5lZWRlZCB0byBlbnN1cmUgdGhhdCB0aGUgcGVlciBoYXMgcmVjZWl2ZWQgQ0lE Lg0KDQpObywgeW91IHVzZSB0aGUgQUNLIGZvciB0aGVzZSAoaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdGxzLWR0bHMxMy0wMSNzZWN0aW9uLTcpLiBUaGlzIGlzIG9uZSBy ZWFzb24gd2h5IHRoZXJlIGlzIG5vdCBhIHN0cmFpZ2h0Zm9yd2FyZCBwb3J0IHRvIERUTFMgMS4y IGZvciB0aGVzZSBtZXNzYWdlcy4NCg0KDQo0LiAgICAgICBUaGUgZ2VuZXJhdGlvbiBvZiBDSUQg c2hvdWxkIGJlIG1vcmUgY29uY3JldGUuIEZvciBleGFtcGxlLCB1c2luZyByYW5kb20gbnVtYmVy IG9yIGEgY291bnRlcj8NCkkgZXhwbGljaXRseSBkaWQgbm90IHdhbnQgdG8gZG8gdGhhdCwgYmVj YXVzZSB0aGVyZSBhcmUgYSBsb3Qgb2YgdmFsaWQgd2F5cyB0byBnZW5lcmF0ZSBDSUQuIFRoaXMg aXMgYWxzbyB3aGF0IHdlIGRpZCBpbiBRVUlDLg0KDQotRWtyDQoNCg0KDQpSZWdhcmRzLA0KWWlu IFhpbnhpbmcNCg0K5Y+R5Lu25Lq6OiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSDku6PooaggRXJpYyBSZXNjb3JsYQ0K5Y+R6YCB 5pe26Ze0OiAyMDE35bm0MTDmnIgxM+aXpSA3OjE0DQrmlLbku7bkuro6IHRsc0BpZXRmLm9yZzxt YWlsdG86dGxzQGlldGYub3JnPg0K5Li76aKYOiBbVExTXSBDb25uZWN0aW9uIElEIERyYWZ0DQoN CkhpIGZvbGtzLA0KDQpJIGhhdmUganVzdCBwb3N0ZWQgYSBmaXJzdCBjdXQgYXQgYSBjb25uZWN0 aW9uIElEIGRyYWZ0Lg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2Nvcmxh LXRscy1kdGxzLWNvbm5lY3Rpb24taWQtMDANCg0KQ29tbWVudHMgd2VsY29tZS4NCg0KLUVrcg0K DQoNCg0KDQoNCg0K --_000_DBDF9AE44733284D808F0E585E1919022D1503BCdggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6 MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAuZ21h aWwtbTkxMDcyODQyMDUyNjczNDEwOG1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW05MTA3Mjg0 MjA1MjY3MzQxMDhtc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbTkxMDcyODQyMDUyNjczNDEw OG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV85MTA3Mjg0MjA1MjY3 MzQxMDhtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uZ21h aWwtDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpwLmdtYWlsLW05MTA3Mjg0MjA1MjY3MzQx MDhtOTE4OTgxNDQxMjIxNzA5MDEzM21zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW05MTA3Mjg0 MjA1MjY3MzQxMDhtOTE4OTgxNDQxMjIxNzA5MDEzM21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFp bC1tOTEwNzI4NDIwNTI2NzM0MTA4bTkxODk4MTQ0MTIyMTcwOTAxMzNtc29saXN0cGFyYWdyYXBo DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fOTEwNzI4NDIwNTI2NzM0MTA4bTkxODk4MTQ0MTIy MTcwOTAxMzNtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAuZ21h aWwtbTkxMDcyODQyMDUyNjczNDEwOG05MTg5ODE0NDEyMjE3MDkwMTMzZ21haWwtbS02NTEzNjA1 MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tOTEwNzI4NDIwNTI2NzM0MTA4 bTkxODk4MTQ0MTIyMTcwOTAxMzNnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJh Z3JhcGgsIGRpdi5nbWFpbC1tOTEwNzI4NDIwNTI2NzM0MTA4bTkxODk4MTQ0MTIyMTcwOTAxMzNn bWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5h bWU6Z21haWwtbV85MTA3Mjg0MjA1MjY3MzQxMDhtOTE4OTgxNDQxMjIxNzA5MDEzM2dtYWlsLW0t NjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9 kzt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K cC5nbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0t NjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0tNjUxMzYwNTMz MzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy02NTEz NjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBw dCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTAxMzMy NjE3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NTUw MjQzMDAgMTU0MzQxMzc1NiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGV4dDoiJTJcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQyLjBwdDsNCgl0ZXh0LWluZGVudDotMjEu MHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjYzLjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6ODQuMHB0Ow0KCXRleHQtaW5kZW50 Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlNVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTA1 LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjEyNi4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjE0Ny4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiU4 XCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjguMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJbWFyZ2luLWxlZnQ6MTg5LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSBtZWFuIHRoYXQgTmV3Y29ubmVjdGlvbklEIG1lc3NhZ2UgYW5kIHRoZSBS ZXF1ZXNDb25uZWN0aW9uSUQgbWVzc2FnZSBzaG91bGQgdXNlIHRoZSBuZXcgcmVjb3JkIGZvcm1h dCAoaW5zdGVhZCBvZiBzdGFuZGFyZCBEVExTMS4yDQogcmVjb3JkIGZvcm1hdCkuIEJlc2lkZXMs IHRoZSBDSUQgaW4gdGhlIHJlY29yZCBoZWFkZXIgc2hhbGwgbm90IGJlIHRoZSBuZXcgQ0lELjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPihjKToNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNpbmNlIHRoZSBmaXJzdCB0d28gYml0cyBvZiAxNi1iaXQgbGVuZ3Ro IHZhcmlhYmxlIGlzIHplcm8sIHdlIGNhbiB1c2UgYSAmbmJzcDtzcGVjaWZpY2FsbHktY29uc3Ry dWN0ZWQgQ0lEIGxpa2Ug4oCcMTF4eHh44oCm4oCdIChvciBvdGhlciBwcm9wZXIgZm9ybWF0KSB0 byBpZGVudGlmeSBhDQogQ0lEIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPihJIGhhdmUgbWVudGlvbmVkIHRoaXMgaW4gcHJldmlvdXMgZW1haWwgYW5k IHlvdSBnYXZlIHNvbWUgZmVlZGJhY2s6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 ImdtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkJhc2VkIG9uIHRoZSBkcmFmdCwgZm9yIGVpdGhlciBEVExTMS4yIG9yIDEu Mywgc2VydmVyIGNhbuKAmXQgZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZSBwYWNrZXQgZnJvbSBj bGllbnQgaXMgYSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldCBvciBhIHN0YW5kYXJkIERUTFMg MS4yLzEuMw0KIHBhY2tldC4gKEkgc2F3IFRob21hcyBGb3NzYXRpIGFuZCBOaWtvcyBhbHNvIGlu dHJvZHVjZWQgdGhpcyBwcm9ibGVtKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlz dHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heWJlIHdlIGNhbiBhZGQg YSBuZXcg4oCcQ29udGVudFR5cGXigJ0gaW4gdGhlIERUTFMgcmVjb3JkIGZvcm1hdCB0byBoZWxw IHNlcnZlciBpZGVudGlmeSB0aGUg4oCcY29ubmVjdGlvbiBJROKAnSBwYWNrZXQuIEluIGFkZGl0 aW9uLCB5b3Ugc2VlIHRoZSBsZW5ndGggb2YgdGhlIHJlY29yZCBwYXlsb2FkDQogaXMgbGltaXRl ZCBieSAyXjE0LTEsIHRoaXMgbWVhbnMgdGhlIGZpcnN0IHR3byBiaXRzIG9mIOKAnGxlbmd0aOKA nSBpcyB6ZXJvLiBXZSBjb3VsZCB1dGlsaXplIHRoaXMgZmVhdHVyZSBhbmQgc2V0IHRoZSBmaXJz dCB0d28gYml0cyBvciBtb3JlIGJpdHMgb2YgQ0lEIGJlaW5nIG9uZSwgZS5nLiwgMTExMeKApi4o YnV0IHRoZSBDSUQgbXVzdCBiZSBwdXQgYmV0d2VlbiBzZXF1ZW5jZSBudW1iZXIgYW5kIGxlbmd0 aCkuIFdoZW4gc2VydmVyIGZpbmRzIDExMTENCiBhZnRlciBzZXF1ZW5jZSBudW1iZXIsIGl0IGtu b3dzIHRoaXMgaXMgYSDigJxjb25uZWN0aW9uIElE4oCdIHBhY2tldC4gSG93ZXZlciwgSSBkb27i gJl0IGtub3cgd2hldGhlciBpdCBpcyBwcm9wZXIgdG8gdXNlIHN1Y2ggbWFnaWMgbnVtYmVyLiBJ biBteSB2aWV3LCBhZGRpbmcgbmV3IGNvbnRlbnR0eXBlIG1heSBiZSBhIGNob2ljZS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBJIHNhaWQgdG8gTmlrb3MsIGZvciBEVExTIDEu MiwgeW91IGNhbiB1c2UgYSBzcGVjaWFsbHktY29uc3RydWN0ZWQgQ0lEIHRoYXQgd291bGQgbm90 IGJlIGEgdmFsaWQgbGVuZ3RoIGZpZWxkLiBUaGlzIGNhbiBhY3R1YWxseSBqdXN0IGhhdmUgdGhl IGxlYWRpbmcgYml0IHNldC4gQXMgd2UncmUgcmV2aXNpbmcgdGhlIERUTFMgMS4zIHJlY29yZCBm b3JtYXQsIHdlIHdvdWxkDQogbmVlZCB0byBkbyBzb21ldGhpbmcgZGlmZmVyZW50IGZvciB0aGF0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4w cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciAo ZCksIEkgaGF2ZSBzb21lIGNvbW1lbnRzIGFib3V0IGl0cyBwcmVjb25kaXRpb24uIFlvdSBzZWUg TkFUIGRldmljZSBjYW4gcmVhbGxvY2F0ZSB0aGUgcmVsZWFzZWQgcG9ydC9JUCBhZGRyZXNzIHRv IGNsaWVudCwgd2hpY2gNCiBtZWFucyB0aGUgcHJlY29uZGl0aW9uIGRvZXNu4oCZdCBhbHdheXMg aG9sZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+DQo8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuWPkemAgeaXtumXtDxzcGFu IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9 IkVOLVVTIj4yNjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTI6MDU8YnI+DQo8L3Nw YW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4geWlueGlueGluZzxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB0bHNAaWV0Zi5vcmc8YnI+DQo8L3Nw YW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gUmU6IFtUTFNdIENvbm5lY3Rpb24gSUQgRHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFdl ZCwgT2N0IDI1LCAyMDE3IGF0IDg6MDIgUE0sIHlpbnhpbnhpbmcgJmx0OzxhIGhyZWY9Im1haWx0 bzp5aW54aW54aW5nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj55aW54aW54aW5nQGh1YXdl aS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRWtyLDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvcnJ5IGZvciB0aGUgZGVsYXkuIEkgZG9u4oCZdCBxdWl0 ZSB1bmRlcnN0YW5kIOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHdheSB0aGF0DQog dGhpcyBtZWNoYW5pc20gd29ya3MgaXMgdGhhdCBpdCBlaXRoZXIgcmVwbGFjZXMgYWxsIG9mIHRo ZW0gb3Igc3VwcGxlbWVudHMgdGhlIHNldC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0gSSBzZWUgdGhlIG5ldyBDSUQgaXMg ZW5jcnlwdGVkIGluIHRoZSBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlIGFuZCB0cmFuc2ZlcnJlZA0K IHRvIHRoZSBwZWVyLiBTbywgdGhlIHJlY29yZCBoZWFkZXIgb2YgdGhpcyBtZXNzYWdlIG5lZWRz IHRvIGNvbnRhaW4gdGhlIOKAnG9sZOKAnSBDSUQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLiBJIGRvbid0IHVuZGVyc3RhbmQg d2hhdCB5b3VyIHF1ZXN0aW9uIGlzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaGVuIHlvdSBzZW5kIGEg bmV3IENJRCwgeW91IGNhbiBlaXRoZXIgbGFiZWwgaXQgYXMmbmJzcDsgY2lkX2ltbWVkaWF0ZSBv ciBjaWRfc3BhcmUuICZxdW90O2ltbWVkaWF0ZSZxdW90OyBtZWFucyAmcXVvdDtzdG9wIHVzaW5n IGFsbCB0aGUgb3RoZXIgQ0lEcyB5b3UgaGF2ZSBhbmQgJnF1b3Q7c3BhcmUmcXVvdDsgbWVhbnMg JnF1b3Q7dGhpcyBpcyBhIENJRCB5b3UgY2FuIHVzZSBpbiBhZGRpdGlvbiB0byB0aGUgb3RoZXJz IHlvdSBoYXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzaWRlcywgSSBoYXZlIHN1 bW1hcml6ZWQgdGhlIHdheXMgb2YgZGlzdGluZ3Vpc2hpbmcgdGhlIENJRCBwYWNrZXQgYW5kIHN0 YW5kYXJkIHBhY2tldA0KIHRoYXQgcGVvcGxlIGhhdmUgZGlzY3Vzc2VkIGluIHRoZSBtYWlsaW5n IGxpc3Q6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iZ21haWwtbTkxMDcyODQyMDUyNjczNDEwOG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+YSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QWRkaW5nIG5ldyBDb250ZW50VHlwZS48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tOTEwNzI4 NDIwNTI2NzM0MTA4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5i KTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZGRp bmcgbmV3IHZlcnNpb24uIChBcyB5b3UgcmVwbGllZCwgc2luY2UgMS4zIGlzIGdvaW5nIHRvIHJl bW92ZSB2ZXJzaW9uIGZpZWxkIGluIHRoZSByZWNvcmQgaGVhZGVyLCBzbyB0aGlzIGNob2ljZSBt YXkgbm90IGJlIHByb3Blci4pPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTkxMDcyODQyMDUyNjczNDEwOG1zb2xpc3RwYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Yyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VXNpbmcgc3BlY2lmaWNhbGx5LWNvbnN0cnVj dGVkIENJRC4gKEkgc2F3IHlvdSByZXBsaWVkIHRoYXQgaXQgd291bGQgYmUgYSB3YXkgZm9yIERU TFMgMS4yLiBCdXQgZm9yIDEuMywgeW91IHdhbnQgYSBkaWZmZXJlbnQgd2F5Lik8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1t OTEwNzI4NDIwNTI2NzM0MTA4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5kKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5CeSBjb21wYXJpbmcgdGhlIDUtdHVwbGUuIE1hcnRpbiBtYWRlIHRoaXMuIChJZiBJIHVuZGVy c3RhbmQgcmlnaHQpIEhpcyBpZGVhIGlzIHRoYXQgZmlyc3QgY2hlY2sgdGhlIDUtdHVwbGUgb2Yg dGhlIHBhY2tldCwgaWYgdGhlcmUgaXMgYSBtYXRjaCwgdGhlbiB1c2UgdGhlDQogY29ycmVzcG9u ZGluZyBrZXkuIElmIHRoZXJlIGlzIG5vIG1hdGNoLCB0aGVuIHRyZWF0IHRoZSBwYWNrZXQgYXMg YSBDSUQgcGFja2V0IGFuZCBmaW5kIHRoZSBDSUQgaW4gdGhlIHBhY2tldCBhY2NvcmRpbmcgdG8g dGhlIG5ldyBmb3JtYXQuIEJ1dCwgdGhlIHByZWNvbmRpdGlvbiBmb3Igd2VsbCB3b3JraW5nIGlz IHRoYXQgdGhlIDUtdHVwbGUgb2YgdGhlIENJRCBwYWNrZXQgd2lsbCBub3QgYmUgc3VjY2Vzc2Z1 bGx5IG1hdGNoZWQgaW4gdGhlDQogcmVjZWl2ZXIncyA1LXR1cGxlIHRhYmxlLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW05 MTA3Mjg0MjA1MjY3MzQxMDhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciB0aGUgYWJvdmUgY2hvaWNlcywgd2hhdCBkbyB5 b3UgdGhpbms/IE9yIGRvIHlvdSBoYXZlIGFueSBvdGhlciBnb29kIHNvbHV0aW9uIHRvDQogYmUg dXBkYXRlZCBpbiB0aGUgZHJhZnQ/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SSB0aGluayB3ZSBzaG91bGQgZG8gbmVpdGhlciAoYSkgbm9yIChiKS4gSSBkb24ndCBy ZWFsbHkgdW5kZXJzdGFuZCAoYykgYnV0IEkgdGhpbmsgKGQpIGlzIGZpbmUsIHRob3VnaCBub3Qg dGhlIG9ubHkgdGVjaG5pcXVlIGltcGxlbWVudG9ycyBjb3VsZCB1c2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tRWtyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllpbiBYaW54 aW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGNsYXNzPSJnbWFp bC0iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lj5Hku7bkuro8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iZ21haWwt Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIEVyaWMg UmVzY29ybGEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9i bGFuayI+ZWtyQHJ0Zm0uY29tPC9hPl0NCjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+5bm0PHNw YW4gbGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMzwvc3Bhbj7m l6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMjA6MTM8YnI+DQo8L3NwYW4+PHNwYW4gY2xhc3M9Imdt YWlsLSI+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4geWlueGlueGluZzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NCjwvc3Bhbj48c3BhbiBjbGFzcz0iZ21haWwtIj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGEgaHJlZj0ibWFpbHRvOnRsc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRsc0BpZXRmLm9yZzwvYT48L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLSI+PGI+5Li7 6aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6 IFtUTFNdIENvbm5lY3Rpb24gSUQgRHJhZnQ8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gTW9uLCBPY3QgMjMsIDIwMTcgYXQgMTI6NTMg QU0sIHlpbnhpbnhpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp5aW54aW54aW5nQGh1YXdlaS5jb20i IHRhcmdldD0iX2JsYW5rIj55aW54aW54aW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEVrciw8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgdGhlIHBvc3QtaGFuZHNoYWtl IG1lc3NhZ2VzIGluIHRoZSBkcmFmdCwgSSBoYXZlIHNvbWUgY29tbWVudHMuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iZ21haWwtbTkxMDcyODQyMDUyNjczNDEwOG05MTg5ODE0NDEyMjE3MDkwMTMz bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjEuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZW4gb25lIHBlZXIg c2VuZHMgTmV3Y29ubmVjdGlvbklEIG1lc3NhZ2UgdG8gdGhlIG90aGVyLCBpdCB1c2VzIGEgbmV3 bHkgZGVmaW5lZCBoYW5kc2hha2UgdHlwZS4gVGhpcyBuZXcgQ0lEIGlzIGF0dGFjaGVkIGluIHRo ZSBwYXlsb2FkIG9mIHRoZSByZWNvcmQgbWVzc2FnZS4NCiBCdXQgdGhlcmUgbXVzdCBiZSBzb21l IGluZm9ybWF0aW9uIGZvciB0aGUgcmVjZWl2ZXIgdG8ga25vdyB3aGljaCBDSUQgaXMgZ29pbmcg dG8gYmUgdXBkYXRlZC4gSSBtZWFuIHRoYXQgd2hlbiBzZW5kaW5nIG5ldyBDSUQgdGhyb3VnaCB0 aGUgTmV3Q29ubmVjdGlvbklEIG1lc3NhZ2UsIHRoZSByZWNvcmQgaGVhZGVyIHNob3VsZCBpbmNs dWRlIHRoZSDigJxvbGTigJ0gQ0lELCBzbyB0aGF0IHRoZSByZWNlaXZlciBrbm93cyB3aGljaCBv bmUgdG8gcmVwbGFjZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHdheSB0aGF0IHRoaXMgbWVjaGFuaXNt IHdvcmtzIGlzIHRoYXQgaXQgZWl0aGVyIHJlcGxhY2VzIGFsbCBvZiB0aGVtIG9yIHN1cHBsZW1l bnRzIHRoZSBzZXQuIEknbSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMgdGhlIHJpZ2h0IGR5bmFtaWMs IGJ1dCBJJ2QgZmlyc3Qgd2FudA0KIHRvIHNlZSBzb21lIHdvcmtlZCB0aHJvdWdoIGNhc2VzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJnbWFpbC1tOTEwNzI4NDIwNTI2NzM0MTA4bTkxODk4MTQ0MTIy MTcwOTAxMzNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Mi48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gdGhl IGRyYWZ0LCBpcyB0aGUgbmV3IENJRCBlbmNyeXB0ZWQ/IEkgc3VnZ2VzdCB0aGF0IHRoZSBuZXcg Q0lEIChmb3IgdGhlIGZpcnN0IHRpbWUgc2VuZGluZykgY2FuIGJlIGVuY3J5cHRlZCAmbmJzcDt0 byBtYWtlIHN1cmUgdGhhdCBhbiBhdHRhY2tlciBjYW4gbm90IGFzc29jaWF0ZQ0KIGEgbmV3IENJ RCB3aXRoIGFuIG9sZCBDSUQuIExldOKAmXMgY29uc2lkZXIgYSBjYXNlIHdoZXJlIGFuIGF0dGFj a2VyIHdhbnRzIHRvIHRyYWNrIGFuIElPVCBkZXZpY2UuIElmIHRoZSBuZXdseSBnZW5lcmF0ZWQg Q0lEIGlzIG5vdCBlbmNyeXB0ZWQgd2hlbiB1cGRhdGluZywgdGhlIGF0dGFja2VyIGNhbiBhc3Nv Y2lhdGUgdGhlIG5ldyBDSUQgd2l0aCB0aGUgb2xkIG9uZS4gVGhlbiwgd2hlbiB0aGUgcGVlciBz ZW5kcyBtZXNzYWdlIHdpdGggdGhlDQogbmV3IENJRCBsYXRlciwgdGhlIGF0dGFja2VyIGtub3dz IHRoaXMgcGFja2V0IGlzIHNlbnQgZnJvbSB0aGUgdmljdGltLiBJZiB3ZSBlbmNyeXB0IHRoZSBu ZXcgQ0lEIHdoZW4gdXBkYXRpbmcsIHRoaXMgdHJhY2tpbmcgcHJvYmxlbSBjYW4gYmUgYXZvaWRl ZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VExTIDEuMyBw b3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBhcmUgYWx3YXlzIGVuY3J5cHRlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7QW5vdGhlciBjb21tZW50IGlzIGFib3V0IHN5bW1l dHJpY2FsIENJRC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJnbWFpbC1tOTEwNzI4NDIwNTI2NzM0MTA4bTkxODk4MTQ0MTIyMTcwOTAx MzNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgYSBj bGllbnQgc2VuZHMgYSBub3JtYWwgQ0lEIChDSUQgbGVuZ3RoIGlzIG5vdCB6ZXJvLCBuYW1lZCBD LUNJRCkgdG8gc2VydmVyLCBidXQgdGhlIHNlcnZlciBkb2VzbuKAmXQgd2FudHMgdG8gdXNlIGNs aWVudOKAmXMgQ0lEIGFuZCBzZW5kcyBhIENJRCBnZW5lcmF0ZWQNCiBieSB0aGUgc2VydmVyIChu YW1lZCBTLUNJRCkgdG8gdGhlIGNsaWVudC4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vLiBUaGUgQ0lEIGlz IGZvciB0aGUgY2xpZW50J3MgYmVuZWZpdCwgc28gd2h5IHdvdWxkIHRoaXMgYmUgdXNlZnVsPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJnbWFpbC1tOTEwNzI4NDIwNTI2NzM0MTA4bTkxODk4MTQ0MTIy MTcwOTAxMzNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXQg dGhlIHNhbWUgdGltZSwgY2xpZW50IG5lZWRzIHRvIGtub3cgc2VydmVyIGhhcyBpZ25vcmVkIEMt Q0lEICh3aGljaCBtZWFucyB0aGUgZG93bmxpbmsgYXBwbGljYXRpb24gbWVzc2FnZSBmcm9tIHRo ZSBzZXJ2ZXIgd2lsbCBub3QgaW5jbHVkZSBDLUNJRCksIGFuZCBjbGllbnQgd2lsbA0KIHVzZSBT LUNJRCBpbiBpdHMgYXBwbGljYXRpb24gbWVzc2FnZS4gV2lsbCB0aGUgZHJhZnQgY292ZXIgdGhp cyBzY2VuYXJpbz88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Tm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LUVrcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9ImdtYWlsLW05MTA3Mjg0MjA1MjY3MzQxMDhtOTE4OTgxNDQxMjIxNzA5MDEzM21z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5ZaW4gWGlueGluZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIEVyaWMgUmVzY29ybGEgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0u Y29tPC9hPl0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ 5Y+R6YCB5pe26Ze0PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiAyMDE3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7lubQ8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEwPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjEzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7m l6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIDIxOjAw PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7mlLbku7bkuro8 L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHlpbnhpbnhp bmc8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuaKhOmAgTwv c3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9 Im1haWx0bzp0bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+PGJy Pg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7kuLvpopg8L3NwYW4+ PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJlOiBbVExTXSBDb25u ZWN0aW9uIElEIERyYWZ0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5PbiBGcmksIE9jdCAxMywgMjAxNyBhdCAxOjExIEFNLCB5aW54aW54aW5nICZsdDs8YSBocmVm PSJtYWlsdG86eWlueGlueGluZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWlueGlueGlu Z0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEVrciw8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgZWZmb3J0LiBUaGUgZHJhZnQg bG9va3MgZ29vZC4gQSBmZXcgY29tbWVudHMgYXJlIGxpc3RlZCBiZWxvdy48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJnbWFpbC1tOTEwNzI4NDIwNTI2NzM0MTA4bTkxODk4MTQ0MTIyMTcwOTAxMzNn bWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4xLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5CYXNlZCBvbiB0aGUgZHJhZnQsIGZvciBlaXRoZXIgRFRMUzEuMiBvciAxLjMs IHNlcnZlciBjYW7igJl0IGRpZmZlcmVudGlhdGUgd2hldGhlciB0aGUgcGFja2V0IGZyb20gY2xp ZW50IGlzIGEg4oCcY29ubmVjdGlvbiBJROKAnSBwYWNrZXQgb3IgYSBzdGFuZGFyZCBEVExTIDEu Mi8xLjMNCiBwYWNrZXQuIChJIHNhdyBUaG9tYXMgRm9zc2F0aSBhbmQgTmlrb3MgYWxzbyBpbnRy b2R1Y2VkIHRoaXMgcHJvYmxlbSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tOTEwNzI4NDIwNTI2NzM0MTA4bTkxODk4MTQ0 MTIyMTcwOTAxMzNnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXliZSB3ZSBjYW4gYWRkIGEgbmV3IOKAnENvbnRl bnRUeXBl4oCdIGluIHRoZSBEVExTIHJlY29yZCBmb3JtYXQgdG8gaGVscCBzZXJ2ZXIgaWRlbnRp ZnkgdGhlIOKAnGNvbm5lY3Rpb24gSUTigJ0gcGFja2V0LiBJbiBhZGRpdGlvbiwgeW91IHNlZSB0 aGUgbGVuZ3RoIG9mIHRoZSByZWNvcmQgcGF5bG9hZA0KIGlzIGxpbWl0ZWQgYnkgMl4xNC0xLCB0 aGlzIG1lYW5zIHRoZSBmaXJzdCB0d28gYml0cyBvZiDigJxsZW5ndGjigJ0gaXMgemVyby4gV2Ug Y291bGQgdXRpbGl6ZSB0aGlzIGZlYXR1cmUgYW5kIHNldCB0aGUgZmlyc3QgdHdvIGJpdHMgb3Ig bW9yZSBiaXRzIG9mIENJRCBiZWluZyBvbmUsIGUuZy4sIDExMTHigKYuKGJ1dCB0aGUgQ0lEIG11 c3QgYmUgcHV0IGJldHdlZW4gc2VxdWVuY2UgbnVtYmVyIGFuZCBsZW5ndGgpLiBXaGVuIHNlcnZl ciBmaW5kcyAxMTExDQogYWZ0ZXIgc2VxdWVuY2UgbnVtYmVyLCBpdCBrbm93cyB0aGlzIGlzIGEg 4oCcY29ubmVjdGlvbiBJROKAnSBwYWNrZXQuIEhvd2V2ZXIsIEkgZG9u4oCZdCBrbm93IHdoZXRo ZXIgaXQgaXMgcHJvcGVyIHRvIHVzZSBzdWNoIG1hZ2ljIG51bWJlci4gSW4gbXkgdmlldywgYWRk aW5nIG5ldyBjb250ZW50dHlwZSBtYXkgYmUgYSBjaG9pY2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIEkgc2FpZCB0byBOaWtvcywgZm9yIERUTFMgMS4y LCB5b3UgY2FuIHVzZSBhIHNwZWNpYWxseS1jb25zdHJ1Y3RlZCBDSUQgdGhhdCB3b3VsZCBub3Qg YmUgYSB2YWxpZCBsZW5ndGggZmllbGQuIFRoaXMgY2FuIGFjdHVhbGx5IGp1c3QgaGF2ZSB0aGUg bGVhZGluZyBiaXQNCiBzZXQuIEFzIHdlJ3JlIHJldmlzaW5nIHRoZSBEVExTIDEuMyByZWNvcmQg Zm9ybWF0LCB3ZSB3b3VsZCBuZWVkIHRvIGRvIHNvbWV0aGluZyBkaWZmZXJlbnQgZm9yIHRoYXQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLW05MTA3Mjg0MjA1MjY3MzQxMDhtOTE4OTgxNDQx MjIxNzA5MDEzM2dtYWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwO0ZvciBEVExTIDEuMiwgdGhlcmUgaXMgbm8gTmV3 Q29ubmVjdGlvbklEIGFuZCBSZXF1ZXN0Q29ubmVjdGlvbklEIG1lc3NhZ2UuIERUTFMgMS4yIHNl cnZlciBhbmQgY2xpZW50IGFsc28gaGFzIHRoZSByZXF1aXJlbWVudCB0byByZXF1ZXN0IGZvciBh IG5ldyBDSUQsIGFuZA0KIGF0IHByZXNlbnQsIG1hbnkgcHJvZHVjdHMgc3RpbGwgdXNlIERUTFMx LjIgYW5kIEkgYmVsaWV2ZSBpdCB3aWxsIGNvbnRpbnVlIHRvIGJlIHVzZWQgZm9yIGEgbG9uZyB0 aW1lIGV2ZW4gaWYgVExTL0RUTFMxLjMgaXMgcHVibGlzaGVkLiBNeSBwb2ludCBpcyB0aGF0IHdl IG5lZWQgYSBjb3JyZXNwb25kaW5nIG1ldGhvZCBmb3IgdXBkYXRpbmcgQ0lEIGZvciBEVExTMS4y IHRvby48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+SW4gZ2VuZXJhbCwgdGhlIFdHIGlzIHdvcmtpbmcgb24gVExT IDEuMywgbm90IFRMUyAxLjIsIHNvIEknbSBub3QgcmVhbGx5IHRoYXQgZXhjaXRlZCBhYm91dCBw dXR0aW5nIGEgbG90IG9mIGVmZm9ydCBpbnRvIGVuaGFuY2luZyBUTFMgMS4yLiBUaGUgYmFzaWMg ZXh0ZW5zaW9uDQogd29ya3MgZmluZSBmb3IgdGhlbSwgYnV0IGlmIHRoZXkgd2FudCB0byBjaGFu Z2UgQ0lEcywgdGhlbiB0aGV5IHNob3VsZCBhZG9wdCBEVExTIDEuMy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iZ21haWwtbTkxMDcyODQyMDUyNjczNDEwOG05MTg5ODE0NDEyMjE3MDkwMTMzZ21haWwt bS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQgdGhlIGZvbGxvd2luZyBzZW50ZW5j ZXMNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9ImdtYWlsLW05MTA3Mjg0MjA1MjY3MzQxMDhtOTE4OTgxNDQxMjIxNzA5MDEzM2dtYWls LW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPuKAnEluIERUTFMgMS4yLCBjb25uZWN0aW9uIGlkcyBhcmUgZXhjaGFuZ2VkIGF0 IHRoZSBiZWdpbm5pbmcgb2YgdGhlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTkxMDcyODQyMDUyNjczNDEwOG05MTg5ODE0 NDEyMjE3MDkwMTMzZ21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29saXN0cGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IERUTFMgc2Vzc2lvbiBvbmx5 LiZuYnNwOyBUaGVyZSBpcyBubyBkZWRpY2F0ZWQgJnF1b3Q7Y29ubmVjdGlvbiBpZCB1cGRhdGUm cXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJnbWFpbC1tOTEwNzI4NDIwNTI2NzM0MTA4bTkxODk4MTQ0MTIyMTcwOTAxMzNnbWFp bC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbWVzc2FnZSB0aGF0IGFsbG93cyBuZXcgY29ubmVjdGlv biBpZHMgdG8gYmUgZXN0YWJsaXNoZWQgbWlkLXNlc3Npb24sPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTkxMDcyODQyMDUy NjczNDEwOG05MTg5ODE0NDEyMjE3MDkwMTMzZ21haWwtbS02NTEzNjA1MzMzMTM4MjUwNDNtc29s aXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGJl Y2F1c2UgRFRMUyAxLjIgaW4gZ2VuZXJhbCBkb2VzIG5vdCBhbGxvdyBwb3N0LWhhbmRzaGFrZSBt ZXNzYWdlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9ImdtYWlsLW05MTA3Mjg0MjA1MjY3MzQxMDhtOTE4OTgxNDQxMjIxNzA5MDEzM2dt YWlsLW0tNjUxMzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB0aGF0IGRvIG5vdCB0aGVtc2VsdmVzIGJlZ2luIG90 aGVyIGhhbmRzaGFrZXMu4oCdPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPlRoZSBvbmx5IHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzIGFsbG93ZWQgaW4gRFRMUyAx LjIgYXJlIENsaWVudEhlbGxvIGFuZCBIZWxsb1JlcXVlc3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 ImdtYWlsLW05MTA3Mjg0MjA1MjY3MzQxMDhtOTE4OTgxNDQxMjIxNzA5MDEzM2dtYWlsLW0tNjUx MzYwNTMzMzEzODI1MDQzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkJlc2lkZXMsIGZvciBDSUQgaW4gRFRMUzEuMywgSSB0aGluayB0aGUgY29ycmVzcG9uZGlu ZyByZXNwb25kaW5nIG1lc3NhZ2VzIG9mICZuYnNwO05ld0Nvbm5lY3Rpb25JRCBhbmQgUmVxdWVz dENvbm5lY3Rpb25JRCBhcmUgYWxzbyBuZWVkZWQgdG8gZW5zdXJlIHRoYXQgdGhlIHBlZXIgaGFz IHJlY2VpdmVkDQogQ0lELjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5ObywgeW91IHVzZSB0aGUgQUNLIGZvciB0aGVzZSAoPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLWR0bHMxMy0wMSNzZWN0aW9uLTciIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtZHRs czEzLTAxI3NlY3Rpb24tNzwvYT4pLg0KIFRoaXMgaXMgb25lIHJlYXNvbiB3aHkgdGhlcmUgaXMg bm90IGEgc3RyYWlnaHRmb3J3YXJkIHBvcnQgdG8gRFRMUyAxLjIgZm9yIHRoZXNlIG1lc3NhZ2Vz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJnbWFpbC1tOTEwNzI4NDIwNTI2NzM0MTA4bTkx ODk4MTQ0MTIyMTcwOTAxMzNnbWFpbC1tLTY1MTM2MDUzMzMxMzgyNTA0M21zb2xpc3RwYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj40Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZ2VuZXJhdGlvbiBvZiBDSUQgc2hvdWxk IGJlIG1vcmUgY29uY3JldGUuIEZvciBleGFtcGxlLCB1c2luZyByYW5kb20gbnVtYmVyIG9yIGEg Y291bnRlcj88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBleHBsaWNpdGx5IGRpZCBub3Qgd2FudCB0byBkbyB0 aGF0LCBiZWNhdXNlIHRoZXJlIGFyZSBhIGxvdCBvZiB2YWxpZCB3YXlzIHRvIGdlbmVyYXRlIENJ RC4gVGhpcyBpcyBhbHNvIHdoYXQgd2UgZGlkIGluIFFVSUMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LUVrcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllpbiBY aW54aW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogVExTIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRscy1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7ku6Pooag8L3NwYW4+ PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RXJpYyBSZXNjb3JsYTxicj4NCjwvc3Bhbj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5Y+R6YCB5pe26Ze0PC9zcGFuPjwvYj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiAyMDE3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjEwPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7m nIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEzPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7ml6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIDc6MTQ8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuaUtuS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij7kuLvpopg8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IFtUTFNdIENvbm5lY3Rpb24gSUQgRHJhZnQ8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+SGkgZm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PkkgaGF2ZSBqdXN0IHBvc3RlZCBhIGZpcnN0IGN1dCBhdCBhIGNvbm5lY3Rpb24gSUQgZHJhZnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1kdGxzLWNvbm5lY3Rpb24taWQtMDAiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLWR0bHMt Y29ubmVjdGlvbi1pZC0wMDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5Db21tZW50cyB3ZWxjb21lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPi1Fa3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_DBDF9AE44733284D808F0E585E1919022D1503BCdggeml511mbschi_-- From nobody Thu Oct 26 08:03:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F4613F5B0 for ; Thu, 26 Oct 2017 08:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbnvEnvFaDkT for ; Thu, 26 Oct 2017 08:03:32 -0700 (PDT) Received: from esa2.dyson.c3s2.iphmx.com (esa2.dyson.c3s2.iphmx.com [68.232.133.94]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C9113F0A8 for ; Thu, 26 Oct 2017 08:03:31 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8695"; a="25080944" X-IronPort-AV: E=Sophos; i="5.43,434,1503356400"; d="scan'208,217"; a="25080944" Received: from unknown (HELO uk-dlp-smtp-02.dyson.global.corp) ([62.189.202.16]) by esa2.dyson.c3s2.iphmx.com with ESMTP; 26 Oct 2017 16:07:14 +0100 Received: from uk-dlp-smtp-02.dyson.global.corp (uk-dlp-smtp-02.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id D18DD94711 for ; Thu, 26 Oct 2017 14:12:20 +0000 (GMT) Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id B90D094702 for ; Thu, 26 Oct 2017 14:12:20 +0000 (GMT) Received: from UK-MAL-OWA-02.dyson.global.corp (10.1.108.7) by UK-MAL-CAS-02.dyson.global.corp (10.1.108.3) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 26 Oct 2017 16:03:29 +0100 Received: from UK-MAL-MBOX-02.dyson.global.corp ([fe80::d06f:fa07:f6dd:5a9c]) by UK-MAL-OWA-02.dyson.global.corp ([fe80::f9b6:1719:a6d9:1eca%10]) with mapi id 14.03.0319.002; Thu, 26 Oct 2017 16:03:29 +0100 From: Tony Putman To: "tls@ietf.org" Thread-Topic: Preshared Keypairs for (D)TLS 1.2 Thread-Index: AdNOZUbbVUBYiVMUSduzwinXMAIY6A== Date: Thu, 26 Oct 2017 15:03:28 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC2CEB42UKMALMBOX02dysong_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 15:03:35 -0000 --_000_140080C241BAA1419B58F093108F9EDC2CEB42UKMALMBOX02dysong_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've recently started working in the IoT space and wish to standardize our transport security by introducing the use of DTLS. It seems that the usual practice is to use PSK for mutual authentication, but I'm not happy with this solution. A breach of server security allows not only server impersonation, but also, due to the PSK symmetry, client impersonation. We are already using static ECDH keys for authentication (at the application layer), so I looked for a way to make use of these in DTLS and came up with the following solution using (D)TLS 1.2: Assume the client is provisioned with an Id, a corresponding private key 'c_id' and a corresponding server public key 'S_id' (the server key may be different for each Id or it may be common across all clients); the server has a list of client public keys 'C_id' and corresponding server private key(s) 's_id'. This OOB pre-provisioning corresponds to that of a symmetric PSK. The TLS 1.2 message exchange is identical to that for a TLS_(EC)DHE_PSK handshake as in RFC4279. This solution applies to both DH/DHE keys and to ECDH/ECDHE keys. The IoT solutions will typically use ECDH/ECDHE, so the following explanation focuses on the EC variant. The messages are: Client Server ------ ------ ClientHello -----> ServerHello ServerKeyExchange <----- ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished -----> ChangeCipherSpec <----- Finished Application Data <----> Application Data The way this differs from TLS_ECDHE_PSK is only in the generation of the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A' (public) from the server; and 'b' (private) and 'B' (public) from the client. Then the client and server form the premaster secret in a struct with the following information (where [x]Y represents multiplication of the point 'Y' by the scalar 'x'): Client Premaster: [b]A || [c_id]A || [b]S_id Server Premaster: [a]B || [a]C_id || [s_id]B The first term provides PFS even if both client and server static private keys become known; the second term provides client authentication even if server keys are compromised; and the third term provides server authentication even if client keys are compromised. My questions to the list are: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 1. Has anything similar to this been proposed before (I found nothing)? 2. Can anyone see a problem with this formulation? 3. Is there any interest in this (I would be happy to write an ID)? The reason that I advocate this for IoT devices over signature schemes is that the code for ECDH will already have to be present if modern key agreement methods with PFS are to be used. So this solution uses fewer resources than ECDHE together with a signature scheme in terms of code space and RAM, and improves execution speed (I believe ECDH is about twice as fast as equivalent signature generation/checking). Also, fewer messages are needed and the messages are smaller (even if using raw keys). A constraint not made explicit above is that the (EC)DHE keys must use the same group/curve parameters as define the preshared keypairs. Since the ClientHello does not contain any client information, this means the server endpoint (e.g. as defined by SNI) can only support a single form of preshared keypair. This could be improved on in TLS 1.3. I don't believe that this constraint is serious, because this method is designed to be used in the same scenarios as PSK; that is, where client and server have an OOB method of receiving authentication credentials from a common source. In this situation, the server is unlikely to be serving clients which use multiple types of preshared keypairs, though it does mean that if the keypair format is changed (e.g. strengthened) during the life of an IoT product then a new server endpoint will have to be defined for the upgraded products. Additionally, this method is proposed to prevent the leaking of client credentials if the server is compromised. This means that the client private key must be high-entropy: this method is not suitable for keys derived from passwords or other low-entropy sources. Lastly, I have had a look at extending this to TLS 1.3 and it seems pretty straightforward; however, there is no urgency and I feel we can defer that to after the TLS 1.3 draft has been approved. Regards, Tony --_000_140080C241BAA1419B58F093108F9EDC2CEB42UKMALMBOX02dysong_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I've recently started working in the IoT space and wish to= standardize

our transport security by introducing the use of DTLS. It = seems that the

usual practice is to use PSK for mutual authentication, bu= t I'm not

happy with this solution. A breach of server security allo= ws not only

server impersonation, but also, due to the PSK symmetry, c= lient

impersonation.

 

We are already using static ECDH keys for authentication (= at the

application layer), so I looked for a way to make use of t= hese in DTLS

and came up with the following solution using (D)TLS 1.2:<= o:p>

 

Assume the client is provisioned with an Id, a correspondi= ng private key

'c_id' and a corresponding server public key 'S_id' (the s= erver key may

be different for each Id or it may be common across all cl= ients); the

server has a list of client public keys 'C_id' and corresp= onding server

private key(s) 's_id'. This OOB pre-provisioning correspon= ds to that of

a symmetric PSK.

 

The TLS 1.2 message exchange is identical to that for a TL= S_(EC)DHE_PSK

handshake as in RFC4279. This solution applies to both DH/= DHE keys and

to ECDH/ECDHE keys. The IoT solutions will typically use E= CDH/ECDHE, so

the following explanation focuses on the EC variant. The m= essages are:

 

    Client     &nb= sp;            =             &nb= sp;  Server

    ------     &nb= sp;            =             &nb= sp;  ------

    ClientHello    &nbs= p;    ----->

         &nbs= p;            &= nbsp;           &nbs= p;   ServerHello

         &nbs= p;            &= nbsp;         ServerKeyExchange

         &nbs= p;            &= nbsp; <-----    ServerHelloDone

    ClientKeyExchange

    ChangeCipherSpec

    Finished     &= nbsp;      ----->

         &nbs= p;            &= nbsp;          ChangeCipherSpe= c

         &nbs= p;            &= nbsp; <-----           = ;Finished

    Application Data    <= ---->   Application Data

 

The way this differs from TLS_ECDHE_PSK is only in the gen= eration of

the premaster secret. Suppose the ECDHE keys are 'a' (priv= ate) and 'A'

(public) from the server; and 'b' (private) and 'B' (publi= c) from the

client. Then the client and server form the premaster secr= et in a struct

with the following information (where [x]Y represents mult= iplication of

the point 'Y' by the scalar 'x'):

    Client Premaster:   [b]A || [= c_id]A || [b]S_id

    Server Premaster:   [a]B || [= a]C_id || [s_id]B

 

The first term provides PFS even if both client and server= static

private keys become known; the second term provides client

authentication even if server keys are compromised; and th= e third term

provides server authentication even if client keys are com= promised.

 

My questions to the list are:

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

1. Has anything similar to this been proposed before (I fo= und nothing)?

2. Can anyone see a problem with this formulation?

3. Is there any interest in this (I would be happy to writ= e an ID)?

 

The reason that I advocate this for IoT devices over signa= ture schemes

is that the code for ECDH will already have to be present = if modern

key agreement methods with PFS are to be used. So this sol= ution uses

fewer resources than ECDHE together with a signature schem= e in terms of

code space and RAM, and improves execution speed (I believ= e ECDH is about

twice as fast as equivalent signature generation/checking)= . Also, fewer

messages are needed and the messages are smaller (even if = using raw keys).

 

A constraint not made explicit above is that the (EC)DHE k= eys must use

the same group/curve parameters as define the preshared ke= ypairs. Since

the ClientHello does not contain any client information, t= his means the

server endpoint (e.g. as defined by SNI) can only support = a single form

of preshared keypair. This could be improved on in TLS 1.3= .

 

I don't believe that this constraint is serious, because t= his method is

designed to be used in the same scenarios as PSK; that is,= where client

and server have an OOB method of receiving authentication = credentials

from a common source. In this situation, the server is unl= ikely to be

serving clients which use multiple types of preshared keyp= airs, though

it does mean that if the keypair format is changed (e.g. s= trengthened)

during the life of an IoT product then a new server endpoi= nt will have

to be defined for the upgraded products.=

 

Additionally, this method is proposed to prevent the leaki= ng of client

credentials if the server is compromised. This means that = the client

private key must be high-entropy: this method is not suita= ble for keys

derived from passwords or other low-entropy sources.<= /o:p>

 

Lastly, I have had a look at extending this to TLS 1.3 and= it seems

pretty straightforward; however, there is no urgency and I= feel we can

defer that to after the TLS 1.3 draft has been approved.

 

Regards,

Tony

--_000_140080C241BAA1419B58F093108F9EDC2CEB42UKMALMBOX02dysong_-- From nobody Thu Oct 26 08:21:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1675B138D8F for ; Thu, 26 Oct 2017 08:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9lRWqISbFZK for ; Thu, 26 Oct 2017 08:21:34 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA48A137C2E for ; Thu, 26 Oct 2017 08:21:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8DFE597B2F; Thu, 26 Oct 2017 18:21:32 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Gj1cKIVP-p16; Thu, 26 Oct 2017 18:21:32 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 06E922313; Thu, 26 Oct 2017 18:21:29 +0300 (EEST) Date: Thu, 26 Oct 2017 18:21:29 +0300 From: Ilari Liusvaara To: Tony Putman Cc: "tls@ietf.org" Message-ID: <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 15:21:37 -0000 On Thu, Oct 26, 2017 at 03:03:28PM +0000, Tony Putman wrote: > > The way this differs from TLS_ECDHE_PSK is only in the generation of > the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A' > (public) from the server; and 'b' (private) and 'B' (public) from the > client. Then the client and server form the premaster secret in a struct > with the following information (where [x]Y represents multiplication of > the point 'Y' by the scalar 'x'): > Client Premaster: [b]A || [c_id]A || [b]S_id > Server Premaster: [a]B || [a]C_id || [s_id]B > > The first term provides PFS even if both client and server static > private keys become known; the second term provides client > authentication even if server keys are compromised; and the third term > provides server authentication even if client keys are compromised. So basically triple-DH. > My questions to the list are: > ============================= > 1. Has anything similar to this been proposed before (I found nothing)? Triple-DH is defined in some protocols. > 2. Can anyone see a problem with this formulation? As with any new mode, it would require security analysis (which is not exactly simple). > The reason that I advocate this for IoT devices over signature schemes > is that the code for ECDH will already have to be present if modern > key agreement methods with PFS are to be used. So this solution uses > fewer resources than ECDHE together with a signature scheme in terms of > code space and RAM, and improves execution speed (I believe ECDH is about > twice as fast as equivalent signature generation/checking). Also, fewer > messages are needed and the messages are smaller (even if using raw keys). I think the gap between the two in speed is smaller than that. The dominant factor in signing is fixed-base scalarmult and in verification double scalarmult (which can be optimized). Whereas with ECDH, it is fixed-base scalarmult and variable-base scalarmult. > Lastly, I have had a look at extending this to TLS 1.3 and it seems > pretty straightforward; however, there is no urgency and I feel we can > defer that to after the TLS 1.3 draft has been approved. I don't think this is straightforward to extend to TLS 1.3. There has been proposal which had mode similar to this, but the TLS 1.3 key exchange looks pretty different from it. Especially annoying would be that since TLS 1.3 is three-flight key exchange, the client authentication can not affect traffic keys. So presumably the best thing that could be archived is mixing the DH authentication terms into Finished messages. -Ilari From nobody Thu Oct 26 08:48:35 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47161389C1 for ; Thu, 26 Oct 2017 08:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85WxLm7dO-Ei for ; Thu, 26 Oct 2017 08:48:31 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF8A137C2E for ; Thu, 26 Oct 2017 08:48:31 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u142so3299609ywg.4 for ; Thu, 26 Oct 2017 08:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E67m8jCJQ+DPIh5Q9/Z6CVkGldvyZKpQamBDiY8VJzE=; b=IkVlCWutHCmeD/7lU6cUoBX2wQ9q5BzLk+hrzwX382QamCl0hW6fWlyrp66HVgDpwN kLNotwwxiu14kwFi+qYksOqnfy6q5F9gt7wWzWhfuuG0TlUkRziYB3eDxxZcDL/BuK74 2kgBHHC8Gy5M+49ugjqs8XVJbztIhbqSC9SLAXLrVP1zmUmeG8xhPs5BmvfrcpEz1vf+ 8UclgYgdvw8+MKHRGhGdFnCvlbJjAxKDVWuleYTvFxlds4/2gn2OSkPpjvJTZNKmjS7W d/b+GzfGUJz189ZoZNUt3ipNaAhO/BKRcHhWaTW2ftdctBADpq4NzXIemI1mWiIR36/b RS+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E67m8jCJQ+DPIh5Q9/Z6CVkGldvyZKpQamBDiY8VJzE=; b=qyfvvXrc0iwmIxgLDwG9PWKWnFjvwZylTK1I7G5XyBH8rlWfYbx9HEA9KWk/trIore +uZ3ETnwNU9ArVKSNy+OTECrzWdyPQ9vGqDa8DB82lMaGlwE7CAIUR2Y48jJTZTiohLe hamw9J5rsq3UVPt7MWnN633MVFTV9YecrLAE6D5wx73dV+7Uuo/eXOSIFvFnMrUevBYL 95hDwEONzgph7lHLmdR0qaQSiceQMqyovGuCzeAaCzRPAeSb31x/Y7aiAwh6rSuyB7mj 6Bjhg/MKnl6OmifA0B24SbSvTNLqdNHILME9susD1GrEhhpHPf1O8ElhPk9qlzi2XZ2m lIRA== X-Gm-Message-State: AMCzsaVbu9kkZZkCDibymT2AMn2xVmTM82sBVxW6BURsVN1Yd7DpVL5i FLmVgfpplh3H79QgxxmUzfhlr5j/1QV/uN+NZ5A++w== X-Google-Smtp-Source: ABhQp+QNnjxOMxZizwNdJRRhWxTJI3zwDO0q0hjAzFcPFEIWbJOTCq28dSnCx+Wv2fkI0tjMAjG/alK0o+piaGjkjr4= X-Received: by 10.129.173.99 with SMTP id l35mr16213686ywk.132.1509032910147; Thu, 26 Oct 2017 08:48:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Thu, 26 Oct 2017 08:47:49 -0700 (PDT) In-Reply-To: <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> From: Eric Rescorla Date: Thu, 26 Oct 2017 08:47:49 -0700 Message-ID: To: Ilari Liusvaara Cc: Tony Putman , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045e8bde907a5e055c751a62" Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 15:48:33 -0000 --f403045e8bde907a5e055c751a62 Content-Type: text/plain; charset="UTF-8" Interesting suggestion. As Ilari mentions, we did look at this a bit previously, but ended up with a signature-based scheme for compat reasons. I'd definitely be interested in seeing this fleshed out some more and will try to take a look soon... On Thu, Oct 26, 2017 at 8:21 AM, Ilari Liusvaara wrote: > > Lastly, I have had a look at extending this to TLS 1.3 and it seems > > pretty straightforward; however, there is no urgency and I feel we can > > defer that to after the TLS 1.3 draft has been approved. > > I don't think this is straightforward to extend to TLS 1.3. There > has been proposal which had mode similar to this, but the TLS 1.3 > key exchange looks pretty different from it. > > Especially annoying would be that since TLS 1.3 is three-flight key > exchange, the client authentication can not affect traffic keys. So > presumably the best thing that could be archived is mixing the DH > authentication terms into Finished messages. > It's pretty straightforward to mix the static server DH share into the final traffic keys (that last 0 input in the key schedule is kind of a placeholder for that). As you say, the client's key is more difficult, but mixing into the Finished MAC would be relatively straightforward, though we might need to mess with the key schedule a bit to make that work. -Ekr > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403045e8bde907a5e055c751a62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inte= resting suggestion. As Ilari mentions, we did look at this a bit
previously, but ended up with a signature-based schem= e for compat
reasons. I'd definitely be= interested in seeing this fleshed out some
more and will try to take a look soon...
<= br>
On Thu, Oct 26, 2017 at 8:21 AM, Ilari = Liusvaara <ilariliusvaara@welho.com> wrote:
> Lastly, I have had a look at= extending this to TLS 1.3 and it seems
> pretty straightforward; however, there is no urgency and I feel we can=
> defer that to after the TLS 1.3 draft has been approved.

I don't think this is straightforward to extend to TLS 1.3. Ther= e
has been proposal which had mode similar to this, but the TLS 1.3
key exchange looks pretty different from it.

Especially annoying would be that since TLS 1.3 is three-flight key
exchange, the client authentication can not affect traffic keys. So
presumably the best thing that could be archived is mixing the DH
authentication terms into Finished messages.

It's pretty straightforward to mix the static server DH share int= o the final
traffic keys (that last 0 input in the key schedule i= s kind of a placeholder
for that). As you say, the client's k= ey is more difficult, but mixing into the
Finished MAC would be r= elatively straightforward, though we might
need to mess with the = key schedule a bit to make that work.

-Ekr




-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--f403045e8bde907a5e055c751a62-- From nobody Thu Oct 26 09:02:34 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A64713F5CC for ; Thu, 26 Oct 2017 09:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjboWGUwrY6j for ; Thu, 26 Oct 2017 09:02:26 -0700 (PDT) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) (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 351EB13F597 for ; Thu, 26 Oct 2017 09:02:24 -0700 (PDT) Received: by mail-wm0-f41.google.com with SMTP id p75so8936041wmg.3 for ; Thu, 26 Oct 2017 09:02:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=aEQ5Xn83Xkf1ZgUbST/ZgcX8cmOH0XpZMFezM43HXH4=; b=oYIsHYMGbs5SCX7fx6zDoOmI3/KYPvD50fc/0BCkXDG6IW3dqwbYc4HCqiJrpzEOn5 OTl9U8cyQr9SOr7MA/q8BgV/YWH3dlNLQclXSgd25AardL/QLk1TauKcrPEYoZQufFC7 dUdvTDLXYqTFLdeeO5AGqyquSS+IsMIrHT/u9ixf1Zn1XV+iECondtHBlgq417FEE/8x 92eJkY6+tBZreGK6iTRc+4rXsH3g2eQLe16cM6S+vJNaVhttcAPOckCl0/ji2G4GPZ2N v0TckoZptqpoltejXuCS/y5zW8+LJPWF2K05xTWChxoO7KDWhTY3/pQjJ/4aImK7ZCRX 66Wg== X-Gm-Message-State: AMCzsaWvhEmBUOD7bbZ0RC2QFw60rE2mGd67a4XS07HCYBS3aeJ0P5+K Kugh8QX7VbiOFEP+3q/VrgGMGLLxzg4= X-Google-Smtp-Source: ABhQp+TXUkFDB0S6yQrb55LkW/x1EkYS52PrS3s2UR2sS8wz4a2UziVwOkPaGUPJ7hb36cqbjPYOhw== X-Received: by 10.28.68.130 with SMTP id r124mr1827023wma.96.1509033742648; Thu, 26 Oct 2017 09:02:22 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id e131sm1509442wmg.15.2017.10.26.09.02.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 26 Oct 2017 09:02:21 -0700 (PDT) Message-ID: <1509033740.10211.90.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Tony Putman , "tls@ietf.org" Date: Thu, 26 Oct 2017 18:02:20 +0200 In-Reply-To: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 16:02:27 -0000 On Thu, 2017-10-26 at 15:03 +0000, Tony Putman wrote: > Hi all, > > I've recently started working in the IoT space and wish to > standardize > our transport security by introducing the use of DTLS. It seems that > the > usual practice is to use PSK for mutual authentication, but I'm not > happy with this solution. A breach of server security allows not only > server impersonation, but also, due to the PSK symmetry, client > impersonation. If you worry about server impersonation in TLS1.2 there are the RSA-PSK ciphersuites which require the server to utilize its private key in RFC4279. If you worry about client impersonation there is TLS with SRP (RFC5054), which can also provide protection against server impersonation on the SRP-RSA mode. The latter is only defined over FF, i.e, there is no EC-based version of SRP defined for TLS. regards, Nikos From nobody Thu Oct 26 09:25:50 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5E813F5C3 for ; Thu, 26 Oct 2017 09:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_zW5WUhd4sJ for ; Thu, 26 Oct 2017 09:25:42 -0700 (PDT) Received: from esa4.dyson.c3s2.iphmx.com (esa4.dyson.c3s2.iphmx.com [68.232.139.183]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A5E13F5BD for ; Thu, 26 Oct 2017 09:25:41 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8695"; a="24288225" X-IronPort-AV: E=Sophos;i="5.44,299,1505775600"; d="scan'208";a="24288225" Received: from unknown (HELO uk-dlp-smtp-02.dyson.global.corp) ([62.189.202.16]) by esa4.dyson.c3s2.iphmx.com with ESMTP; 26 Oct 2017 17:25:39 +0100 Received: from uk-dlp-smtp-02.dyson.global.corp (uk-dlp-smtp-02.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 2E7C494711; Thu, 26 Oct 2017 15:34:30 +0000 (GMT) Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 20D6F94702; Thu, 26 Oct 2017 15:34:30 +0000 (GMT) Received: from UK-MAL-MBOX-02.dyson.global.corp ([fe80::d06f:fa07:f6dd:5a9c]) by UK-MAL-CAS-02.dyson.global.corp ([fe80::d0fe:1c2d:58fc:2dbb%17]) with mapi id 14.03.0319.002; Thu, 26 Oct 2017 17:25:39 +0100 From: Tony Putman To: "ilariliusvaara@welho.com" CC: "tls@ietf.org" Thread-Topic: [TLS] Preshared Keypairs for (D)TLS 1.2 Thread-Index: AdNOZUbbVUBYiVMUSduzwinXMAIY6AAAG/6AAAQ15qA= Date: Thu, 26 Oct 2017 16:25:38 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC2CEBD8@UK-MAL-MBOX-02.dyson.global.corp> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> In-Reply-To: <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 16:25:44 -0000 RnJvbTogaWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tIFttYWlsdG86aWxhcmlsaXVzdmFhcmFAd2Vs aG8uY29tXQ0KPiBTbyBiYXNpY2FsbHkgdHJpcGxlLURILg0KPiANCj4gQXMgd2l0aCBhbnkgbmV3 IG1vZGUsIGl0IHdvdWxkIHJlcXVpcmUgc2VjdXJpdHkgYW5hbHlzaXMgKHdoaWNoIGlzIG5vdA0K PiBleGFjdGx5IHNpbXBsZSkuDQoNClRoYW5rcyBmb3IgdGhlIGtleXdvcmQsIElsYXJpOiBJJ3Zl IG5vdyBmb3VuZCBodHRwOi8vaWVlZS1zZWN1cml0eS5vcmcvVEMvU1AyMDE1L3BhcGVycy1hcmNo aXZlZC82OTQ5YTIzMi5wZGYgd2hpY2ggdGFsa3MgYWJvdXQgdHJpcGxlLURILiBJJ2xsIHJlYWQg dXAgc29tZSBtb3JlIG9uIGl0IGFuZCBzZWUgaWYgdGhlcmUncyBhIHJlYXNvbmFibGUgc2VjdXJp dHkgYW5hbHlzaXMuDQoNClRvbnkNCg0K From nobody Thu Oct 26 09:41:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498B4138F21 for ; Thu, 26 Oct 2017 09:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMJUYQfa686p for ; Thu, 26 Oct 2017 09:41:16 -0700 (PDT) Received: from esa1.dyson.c3s2.iphmx.com (esa1.dyson.c3s2.iphmx.com [68.232.133.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5DE13A441 for ; Thu, 26 Oct 2017 09:41:15 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8695"; a="28804144" X-IronPort-AV: E=Sophos; i="5.44,299,1505775600"; d="scan'208,217"; a="28804144" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa1.dyson.c3s2.iphmx.com with ESMTP; 26 Oct 2017 17:51:18 +0100 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id E260EFA10; Thu, 26 Oct 2017 15:30:57 +0000 (GMT) Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id CA855FA02; Thu, 26 Oct 2017 15:30:57 +0000 (GMT) Received: from UK-MAL-CAS-03.dyson.global.corp (10.1.108.111) by UK-MAL-CAS-02.dyson.global.corp (10.1.108.3) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 26 Oct 2017 17:41:13 +0100 Received: from UK-MAL-MBOX-02.dyson.global.corp ([fe80::d06f:fa07:f6dd:5a9c]) by UK-MAL-CAS-03.dyson.global.corp ([10.1.108.111]) with mapi id 14.03.0319.002; Thu, 26 Oct 2017 17:41:13 +0100 From: Tony Putman To: Eric Rescorla CC: "tls@ietf.org" , Ilari Liusvaara Thread-Topic: [TLS] Preshared Keypairs for (D)TLS 1.2 Thread-Index: AdNOZUbbVUBYiVMUSduzwinXMAIY6AAAG/6AAADrcIAAA5PfEA== Date: Thu, 26 Oct 2017 16:41:12 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC2CEBEF@UK-MAL-MBOX-02.dyson.global.corp> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC2CEBEFUKMALMBOX02dysong_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 16:41:18 -0000 --_000_140080C241BAA1419B58F093108F9EDC2CEBEFUKMALMBOX02dysong_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NCkl0J3MgcHJldHR5IHN0 cmFpZ2h0Zm9yd2FyZCB0byBtaXggdGhlIHN0YXRpYyBzZXJ2ZXIgREggc2hhcmUgaW50byB0aGUg ZmluYWwNCnRyYWZmaWMga2V5cyAodGhhdCBsYXN0IDAgaW5wdXQgaW4gdGhlIGtleSBzY2hlZHVs ZSBpcyBraW5kIG9mIGEgcGxhY2Vob2xkZXINCmZvciB0aGF0KS4gQXMgeW91IHNheSwgdGhlIGNs aWVudCdzIGtleSBpcyBtb3JlIGRpZmZpY3VsdCwgYnV0IG1peGluZyBpbnRvIHRoZQ0KRmluaXNo ZWQgTUFDIHdvdWxkIGJlIHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3YXJkLCB0aG91Z2ggd2UgbWln aHQNCm5lZWQgdG8gbWVzcyB3aXRoIHRoZSBrZXkgc2NoZWR1bGUgYSBiaXQgdG8gbWFrZSB0aGF0 IHdvcmsuDQoNCkkgdGhvdWdodCB3ZSB3b3VsZCBuZWVkIHRvIG1vZGlmeSB0aGUga2V5IHNjaGVk dWxlIGluIHNlY3Rpb24gNy4xLCByZXBsYWNpbmcgdGhlDQpQU0sgaW5wdXQgYXQgdGhlIHN0YXJ0 IHdpdGggdGhlIHN0YXRpYyBzaGFyZSBbY19pZF1TX2lkIChvciBbc19pZF1DX2lkKSBhbmQgdGhl biByZXBsYWNlDQp0aGUgKEVDKURIRSBpbnB1dCBsb3dlciBkb3duIHdpdGggdGhlIFRyaXBsZS1E SC4NCg0KQnV0IEknZCByYXRoZXIgbm90IGdldCB0b28gc2lkZXRyYWNrZWQgYnkgdGhlIFRMUyAx LjMgY2hhbmdlcyByaWdodCBub3cuIEkgYW0gaW4gYW55DQpjYXNlIG5vdCB1cCB0byBzcGVlZCBv biBhbGwgdGhlIGNoYW5nZXMgYW5kIGRpc2N1c3Npb25zIGFyb3VuZCB0aGF0Lg0KLS0NClRvbnkN Cg0K --_000_140080C241BAA1419B58F093108F9EDC2CEBEFUKMALMBOX02dysong_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0 Zm0uY29tXQ0KPGJyPg0KPC9zcGFuPkl0J3MgcHJldHR5IHN0cmFpZ2h0Zm9yd2FyZCB0byBtaXgg dGhlIHN0YXRpYyBzZXJ2ZXIgREggc2hhcmUgaW50byB0aGUgZmluYWw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+dHJhZmZpYyBrZXlzICh0aGF0IGxhc3QgMCBpbnB1dCBpbiB0aGUga2V5IHNjaGVk dWxlIGlzIGtpbmQgb2YgYSBwbGFjZWhvbGRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9yIHRoYXQpLiBBcyB5b3Ugc2F5LCB0aGUgY2xpZW50 J3Mga2V5IGlzIG1vcmUgZGlmZmljdWx0LCBidXQgbWl4aW5nIGludG8gdGhlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaW5pc2hlZCBNQUMgd291 bGQgYmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQsIHRob3VnaCB3ZSBtaWdodDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bmVlZCB0byBtZXNz IHdpdGggdGhlIGtleSBzY2hlZHVsZSBhIGJpdCB0byBtYWtlIHRoYXQgd29yay48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+SSB0aG91Z2h0IHdlIHdvdWxkIG5lZWQgdG8gbW9kaWZ5IHRoZSBrZXkgc2NoZWR1bGUg aW4gc2VjdGlvbiA3LjEsIHJlcGxhY2luZyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBTSyBpbnB1dCBh dCB0aGUgc3RhcnQgd2l0aCB0aGUgc3RhdGljIHNoYXJlIFtjX2lkXVNfaWQgKG9yIFtzX2lkXUNf aWQpIGFuZCB0aGVuIHJlcGxhY2UNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGhlIChFQylESEUgaW5wdXQg bG93ZXIgZG93biB3aXRoIHRoZSBUcmlwbGUtREguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkJ1dCBJJ2QgcmF0aGVyIG5vdCBnZXQgdG9vIHNpZGV0cmFja2VkIGJ5IHRo ZSBUTFMgMS4zIGNoYW5nZXMgcmlnaHQgbm93LiBJIGFtIGluIGFueQ0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5jYXNlIG5vdCB1cCB0byBzcGVlZCBvbiBhbGwgdGhlIGNoYW5nZXMgYW5kIGRpc2N1c3Npb25z IGFyb3VuZCB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG9ueTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_140080C241BAA1419B58F093108F9EDC2CEBEFUKMALMBOX02dysong_-- From nobody Thu Oct 26 09:45:48 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6507513EF48 for ; Thu, 26 Oct 2017 09:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts_m3f7Z1X_r for ; Thu, 26 Oct 2017 09:45:41 -0700 (PDT) Received: from esa4.dyson.c3s2.iphmx.com (esa4.dyson.c3s2.iphmx.com [68.232.139.183]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E98813A441 for ; Thu, 26 Oct 2017 09:45:40 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8695"; a="24288792" X-IronPort-AV: E=Sophos;i="5.44,301,1505775600"; d="scan'208";a="24288792" Received: from unknown (HELO uk-dlp-smtp-02.dyson.global.corp) ([62.189.202.16]) by esa4.dyson.c3s2.iphmx.com with ESMTP; 26 Oct 2017 17:45:39 +0100 Received: from uk-dlp-smtp-02.dyson.global.corp (uk-dlp-smtp-02.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id A9B6D94711; Thu, 26 Oct 2017 15:54:29 +0000 (GMT) Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 9BF7494702; Thu, 26 Oct 2017 15:54:29 +0000 (GMT) Received: from UK-MAL-MBOX-02.dyson.global.corp ([fe80::d06f:fa07:f6dd:5a9c]) by UK-MAL-CAS-01.dyson.global.corp ([fe80::ac29:a07c:fbf9:9f84%15]) with mapi id 14.03.0319.002; Thu, 26 Oct 2017 17:45:39 +0100 From: Tony Putman To: Nikos Mavrogiannopoulos CC: "tls@ietf.org" Thread-Topic: [TLS] Preshared Keypairs for (D)TLS 1.2 Thread-Index: AdNOZUbbVUBYiVMUSduzwinXMAIY6AABiTgAAAOAe4A= Date: Thu, 26 Oct 2017 16:45:38 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC2CEC01@UK-MAL-MBOX-02.dyson.global.corp> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> <1509033740.10211.90.camel@redhat.com> In-Reply-To: <1509033740.10211.90.camel@redhat.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 16:45:43 -0000 RnJvbTogTmlrb3MgTWF2cm9naWFubm9wb3Vsb3MgW21haWx0bzpubWF2QHJlZGhhdC5jb21dDQo+ IElmIHlvdSB3b3JyeSBhYm91dCBjbGllbnQgaW1wZXJzb25hdGlvbiB0aGVyZSBpcyBUTFMgd2l0 aCBTUlANCj4gKFJGQzUwNTQpLCB3aGljaCBjYW4gYWxzbyBwcm92aWRlIHByb3RlY3Rpb24gYWdh aW5zdCBzZXJ2ZXINCj4gaW1wZXJzb25hdGlvbiBvbiB0aGUgU1JQLVJTQSBtb2RlLiBUaGUgbGF0 dGVyIGlzIG9ubHkgZGVmaW5lZCBvdmVyIEZGLA0KPiBpLmUsIHRoZXJlIGlzIG5vIEVDLWJhc2Vk IHZlcnNpb24gb2YgU1JQIGRlZmluZWQgZm9yIFRMUy4NCg0KSSB3b3JyeSBtb3N0IGFib3V0IGNs aWVudCBpbXBlcnNvbmF0aW9uLCBiZWNhdXNlIHRoYXQgaXMgZWFzeSANCnRvIHNjYWxlIGlmIHRo ZXJlIGlzIGEgc2VydmVyIGJyZWFjaC4gSSBhZ3JlZSB0aGF0IHRoZSBTUlAtUlNBIG1ldGhvZA0K ZGVmZW5kcyBhZ2FpbnN0IHRoaXMsIGJ1dCBJIGRvbid0IGZlZWwgdGhhdCBpdCB3aWxsIG1ha2Ug aXQgaW50byB0aGUgSW9UIA0Kc3BhY2UuDQotLSANClRvbnkNCg0K From nobody Thu Oct 26 09:46:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7613B488 for ; Thu, 26 Oct 2017 09:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgeVVRDM4qlE for ; Thu, 26 Oct 2017 09:46:51 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D7313AD2D for ; Thu, 26 Oct 2017 09:46:51 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id q126so3444075ywq.10 for ; Thu, 26 Oct 2017 09:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5fuucJn7Pvv28bBXiVb22JJFqYva0iSC5mJjECbM40o=; b=CTOC38qWKWlUykjjxklhFhaPkP7/6WC6OXN0aNfL9VhCaQBwtlUbHDzfn9qaCQaTHV 9yQzQ0MKNrpnb62mUIcQvjrAe6emaOiRJNhYfl4xt7z0uVWtqeQdklBq1/+shaZHK0zw YhZ85oJO2npeSUj8hqwDakVYbe4f/kggPvRxQaXMx9m/k/jnylf2gNp6QjMuD+i+LJlh hLluXXKMWYgdd5UtWsZtr/OD4iPx0W5XLMVbgqIA7990qWMWoZNo2u6ejXwoy0OjoHsp W6XhDjI4CYGwBPzzK1NQlrKV2UnoL8l4Npd9VD+Euu0jrrC0HzmdQBYTW1gBO/Lf6Ijk NvWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5fuucJn7Pvv28bBXiVb22JJFqYva0iSC5mJjECbM40o=; b=Evfnogmif0YbnnAASpsct8aMEtuiU702EnVF1hAOX570eIf7XN+8hmmMiKUA0hNOj/ DM/rg2Qm42+Ze0RrhPJ3q8rloLnThNVP+hg4bF2Aq16J4q9G955S8zdE6wbzKKZejnvs umY5YyauWmhO4PCFA1IPyTxYK2BPScjpwtGtUuNQGdoU7OeCg8ERCpw4MOQhF1PkNY0k 0Ln6r/9kSbMljNpGxZ4qDLneFbaR81xx0q1SZZ6PhybPilvXNUPNnRUTudNS6VlBySW7 Xcr9+LT4PkungwuRZuJnNWTjf0wCkhTIieREO0X1iVor9bFsraAUHH1IxmvAIuCukt5n X5BA== X-Gm-Message-State: AMCzsaVF6f1UUhmH7iK2M+4oXYk0s2GM53eX7BFu1Jp/+aJjfmmcn6jv iX80NffkJ5TVFAqufrohw63WcMaq8JI69gWKs4lQPI23 X-Google-Smtp-Source: ABhQp+R68Dd1Os4Gv0Uj1GRE/68F38kHdalqrcu0pVzrLoV0yTJCewDwRsVr6Ke2EqbZ0+QLhGyF3sJJ5R96xLT1DEg= X-Received: by 10.37.230.200 with SMTP id d191mr3691165ybh.348.1509036410460; Thu, 26 Oct 2017 09:46:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Thu, 26 Oct 2017 09:46:09 -0700 (PDT) In-Reply-To: <140080C241BAA1419B58F093108F9EDC2CEBEF@UK-MAL-MBOX-02.dyson.global.corp> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> <140080C241BAA1419B58F093108F9EDC2CEBEF@UK-MAL-MBOX-02.dyson.global.corp> From: Eric Rescorla Date: Thu, 26 Oct 2017 09:46:09 -0700 Message-ID: To: Tony Putman Cc: "tls@ietf.org" , Ilari Liusvaara Content-Type: multipart/alternative; boundary="94eb2c0afb1432f209055c75ebd3" Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 16:46:52 -0000 --94eb2c0afb1432f209055c75ebd3 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 26, 2017 at 9:41 AM, Tony Putman wrote: > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > It's pretty straightforward to mix the static server DH share into the > final > > traffic keys (that last 0 input in the key schedule is kind of a > placeholder > > for that). As you say, the client's key is more difficult, but mixing into > the > > Finished MAC would be relatively straightforward, though we might > > need to mess with the key schedule a bit to make that work. > > > > I thought we would need to modify the key schedule in section 7.1, > replacing the > > PSK input at the start with the static share [c_id]S_id (or [s_id]C_id) > and then replace > > the (EC)DHE input lower down with the Triple-DH. > That's one option. But I'd rather not get too sidetracked by the TLS 1.3 changes right now. I > am in any > > case not up to speed on all the changes and discussions around that. > Fair enough. I would say that we want an anonymous client mode to work properly (the same mode that QUIC Crypto uses) -Ekr > --94eb2c0afb1432f209055c75ebd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 26, 2017 at 9:41 AM, Tony Putman <Tony.Putman@dyson.co= m> wrote:

From: Eric Rescorla [mailto:ekr@rtfm.com]
It's pretty straightforward to mix the static s= erver DH share into the final

traffic keys (that last 0 input in the key schedule = is kind of a placeholder

for that). As you say, the client's key is more = difficult, but mixing into the

Finished MAC would be relatively straightforward, th= ough we might

need to mess with the key schedule a bit to make tha= t work.

=C2=A0

I thought we would need to modify the k= ey schedule in section 7.1, replacing the

PSK input at the start with the static = share [c_id]S_id (or [s_id]C_id) and then replace

the (EC)DHE input lower down with the T= riple-DH.


That's= one option.=C2=A0


But I'd rather not get too sidetrac= ked by the TLS 1.3 changes right now. I am in any

case not up to speed on all the changes= and discussions around that.


<= /div>
Fair enough. I would say that we want an anonymous client mode to= work properly
(the same mode that QUIC Crypto uses)

-Ekr
=C2=A0


--94eb2c0afb1432f209055c75ebd3-- From nobody Thu Oct 26 09:58:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F373013B1A9 for ; Thu, 26 Oct 2017 09:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h-P8RWZiaXAV for ; Thu, 26 Oct 2017 09:58:01 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BDF139059 for ; Thu, 26 Oct 2017 09:58:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 4AAAD97A4D; Thu, 26 Oct 2017 19:57:59 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id RTb5NCYPKk84; Thu, 26 Oct 2017 19:57:58 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id DB8002315; Thu, 26 Oct 2017 19:57:55 +0300 (EEST) Date: Thu, 26 Oct 2017 19:57:55 +0300 From: Ilari Liusvaara To: Tony Putman Cc: "tls@ietf.org" Message-ID: <20171026165755.l2mj6hen2owopyjw@LK-Perkele-VII> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> <140080C241BAA1419B58F093108F9EDC2CEBD8@UK-MAL-MBOX-02.dyson.global.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <140080C241BAA1419B58F093108F9EDC2CEBD8@UK-MAL-MBOX-02.dyson.global.corp> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 16:58:04 -0000 On Thu, Oct 26, 2017 at 04:25:38PM +0000, Tony Putman wrote: > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > > So basically triple-DH. > > > > As with any new mode, it would require security analysis (which is not > > exactly simple). > > Thanks for the keyword, Ilari: I've now found > http://ieee-security.org/TC/SP2015/papers-archived/6949a232.pdf which > talks about triple-DH. I'll read up some more on it and see if there's > a reasonable security analysis. Sorry, I was unclear. I didn't mean security analysis of Triple DH in general, but security analysis of triple DH as embedded to TLS. -Ilari From nobody Thu Oct 26 10:10:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6DF13F3AC for ; Thu, 26 Oct 2017 10:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7tGS3qNZLs1 for ; Thu, 26 Oct 2017 10:10:27 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1162D13EF48 for ; Thu, 26 Oct 2017 10:10:26 -0700 (PDT) X-Spoof: Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2017 13:10:25 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0319.002; Thu, 26 Oct 2017 13:10:25 -0400 From: Dan Brown To: Tony Putman , "tls@ietf.org" Thread-Topic: Preshared Keypairs for (D)TLS 1.2 Thread-Index: AdNOZUbbVUBYiVMUSduzwinXMAIY6AAFvh7Q Date: Thu, 26 Oct 2017 17:10:25 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501BF1D7A@XMB116CNC.rim.net> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> In-Reply-To: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF501BF1D7AXMB116CNCrimnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 17:10:30 -0000 --_000_810C31990B57ED40B2062BA10D43FBF501BF1D7AXMB116CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tony, Perhaps (some variant of) Menezes-Qu-Vanstone MQV key agreement might work = for your problem. There are some security analyses for variants MQV, e.g. HMQV, and it offers= even better efficiency than triple-DH. The original MQV appears in a few standards (NIST SP 63a, IEEE 1363, ANSI X= 9.63, even SEC1, and was dropped from Suite B ...). I believe that some I-= Ds were written on using MQV in TLS (or elsewhere in IETF), but they expire= d. Best regards, Dan From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Tony Putman Sent: Thursday, October 26, 2017 11:03 AM To: tls@ietf.org Subject: [TLS] Preshared Keypairs for (D)TLS 1.2 Hi all, I've recently started working in the IoT space and wish to standardize our transport security by introducing the use of DTLS. It seems that the usual practice is to use PSK for mutual authentication, but I'm not happy with this solution. A breach of server security allows not only server impersonation, but also, due to the PSK symmetry, client impersonation. We are already using static ECDH keys for authentication (at the application layer), so I looked for a way to make use of these in DTLS and came up with the following solution using (D)TLS 1.2: Assume the client is provisioned with an Id, a corresponding private key 'c_id' and a corresponding server public key 'S_id' (the server key may be different for each Id or it may be common across all clients); the server has a list of client public keys 'C_id' and corresponding server private key(s) 's_id'. This OOB pre-provisioning corresponds to that of a symmetric PSK. The TLS 1.2 message exchange is identical to that for a TLS_(EC)DHE_PSK handshake as in RFC4279. This solution applies to both DH/DHE keys and to ECDH/ECDHE keys. The IoT solutions will typically use ECDH/ECDHE, so the following explanation focuses on the EC variant. The messages are: Client Server ------ ------ ClientHello -----> ServerHello ServerKeyExchange <----- ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished -----> ChangeCipherSpec <----- Finished Application Data <----> Application Data The way this differs from TLS_ECDHE_PSK is only in the generation of the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A' (public) from the server; and 'b' (private) and 'B' (public) from the client. Then the client and server form the premaster secret in a struct with the following information (where [x]Y represents multiplication of the point 'Y' by the scalar 'x'): Client Premaster: [b]A || [c_id]A || [b]S_id Server Premaster: [a]B || [a]C_id || [s_id]B The first term provides PFS even if both client and server static private keys become known; the second term provides client authentication even if server keys are compromised; and the third term provides server authentication even if client keys are compromised. My questions to the list are: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 1. Has anything similar to this been proposed before (I found nothing)? 2. Can anyone see a problem with this formulation? 3. Is there any interest in this (I would be happy to write an ID)? The reason that I advocate this for IoT devices over signature schemes is that the code for ECDH will already have to be present if modern key agreement methods with PFS are to be used. So this solution uses fewer resources than ECDHE together with a signature scheme in terms of code space and RAM, and improves execution speed (I believe ECDH is about twice as fast as equivalent signature generation/checking). Also, fewer messages are needed and the messages are smaller (even if using raw keys). A constraint not made explicit above is that the (EC)DHE keys must use the same group/curve parameters as define the preshared keypairs. Since the ClientHello does not contain any client information, this means the server endpoint (e.g. as defined by SNI) can only support a single form of preshared keypair. This could be improved on in TLS 1.3. I don't believe that this constraint is serious, because this method is designed to be used in the same scenarios as PSK; that is, where client and server have an OOB method of receiving authentication credentials from a common source. In this situation, the server is unlikely to be serving clients which use multiple types of preshared keypairs, though it does mean that if the keypair format is changed (e.g. strengthened) during the life of an IoT product then a new server endpoint will have to be defined for the upgraded products. Additionally, this method is proposed to prevent the leaking of client credentials if the server is compromised. This means that the client private key must be high-entropy: this method is not suitable for keys derived from passwords or other low-entropy sources. Lastly, I have had a look at extending this to TLS 1.3 and it seems pretty straightforward; however, there is no urgency and I feel we can defer that to after the TLS 1.3 draft has been approved. Regards, Tony --_000_810C31990B57ED40B2062BA10D43FBF501BF1D7AXMB116CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tony,

 

Perhaps (some variant of) Menezes—Qu—Van= stone MQV key agreement might work for your problem. 

 

There are some security analyses for variants MQV, e= .g. HMQV, and it offers even better efficiency than triple-DH. 

 

The original MQV appears in a few standards (NIST SP= 63a, IEEE 1363, ANSI X9.63, even SEC1, and was dropped from Suite B …= ;).  I believe that some I-Ds were written on using MQV in TLS (or els= ewhere in IETF), but they expired.

 

Best regards,

 

Dan

 

From: TLS [mailto:tls-bounces@ietf.org] On= Behalf Of Tony Putman
Sent: Thursday, October 26, 2017 11:03 AM
To: tls@ietf.org
Subject: [TLS] Preshared Keypairs for (D)TLS 1.2

 

Hi all,

 

I've recently started working in the IoT sp= ace and wish to standardize

our transport security by introducing the u= se of DTLS. It seems that the

usual practice is to use PSK for mutual aut= hentication, but I'm not

happy with this solution. A breach of serve= r security allows not only

server impersonation, but also, due to the = PSK symmetry, client

impersonation.

 

We are already using static ECDH keys for a= uthentication (at the

application layer), so I looked for a way t= o make use of these in DTLS

and came up with the following solution usi= ng (D)TLS 1.2:

 

Assume the client is provisioned with an Id= , a corresponding private key

'c_id' and a corresponding server public ke= y 'S_id' (the server key may

be different for each Id or it may be commo= n across all clients); the

server has a list of client public keys 'C_= id' and corresponding server

private key(s) 's_id'. This OOB pre-provisi= oning corresponds to that of

a symmetric PSK.

 

The TLS 1.2 message exchange is identical t= o that for a TLS_(EC)DHE_PSK

handshake as in RFC4279. This solution appl= ies to both DH/DHE keys and

to ECDH/ECDHE keys. The IoT solutions will = typically use ECDH/ECDHE, so

the following explanation focuses on the EC= variant. The messages are:

 

    Client   =             &nb= sp;            =      Server

    ------   =             &nb= sp;            =      ------

    ClientHello  &= nbsp;      ----->

       &= nbsp;           &nbs= p;            &= nbsp;     ServerHello

       &= nbsp;           &nbs= p;            Server= KeyExchange

       &= nbsp;           &nbs= p;    <-----    ServerHelloDone=

    ClientKeyExchange

    ChangeCipherSpec

    Finished  &nbs= p;         ----->

       &= nbsp;           &nbs= p;             = ChangeCipherSpec

       &= nbsp;           &nbs= p;    <-----        &n= bsp;  Finished

    Application Data &n= bsp;  <---->   Application Data

 

The way this differs from TLS_ECDHE_PSK is = only in the generation of

the premaster secret. Suppose the ECDHE key= s are 'a' (private) and 'A'

(public) from the server; and 'b' (private)= and 'B' (public) from the

client. Then the client and server form the= premaster secret in a struct

with the following information (where [x]Y = represents multiplication of

the point 'Y' by the scalar 'x'):

    Client Premaster: &= nbsp; [b]A || [c_id]A || [b]S_id

    Server Premaster: &= nbsp; [a]B || [a]C_id || [s_id]B

 

The first term provides PFS even if both cl= ient and server static

private keys become known; the second term = provides client

authentication even if server keys are comp= romised; and the third term

provides server authentication even if clie= nt keys are compromised.

 

My questions to the list are:

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

1. Has anything similar to this been propos= ed before (I found nothing)?

2. Can anyone see a problem with this formu= lation?

3. Is there any interest in this (I would b= e happy to write an ID)?

 

The reason that I advocate this for IoT dev= ices over signature schemes

is that the code for ECDH will already have= to be present if modern

key agreement methods with PFS are to be us= ed. So this solution uses

fewer resources than ECDHE together with a = signature scheme in terms of

code space and RAM, and improves execution = speed (I believe ECDH is about

twice as fast as equivalent signature gener= ation/checking). Also, fewer

messages are needed and the messages are sm= aller (even if using raw keys).

 

A constraint not made explicit above is tha= t the (EC)DHE keys must use

the same group/curve parameters as define t= he preshared keypairs. Since

the ClientHello does not contain any client= information, this means the

server endpoint (e.g. as defined by SNI) ca= n only support a single form

of preshared keypair. This could be improve= d on in TLS 1.3.

 

I don't believe that this constraint is ser= ious, because this method is

designed to be used in the same scenarios a= s PSK; that is, where client

and server have an OOB method of receiving = authentication credentials

from a common source. In this situation, th= e server is unlikely to be

serving clients which use multiple types of= preshared keypairs, though

it does mean that if the keypair format is = changed (e.g. strengthened)

during the life of an IoT product then a ne= w server endpoint will have

to be defined for the upgraded products.

 

Additionally, this method is proposed to pr= event the leaking of client

credentials if the server is compromised. T= his means that the client

private key must be high-entropy: this meth= od is not suitable for keys

derived from passwords or other low-entropy= sources.

 

Lastly, I have had a look at extending this= to TLS 1.3 and it seems

pretty straightforward; however, there is n= o urgency and I feel we can

defer that to after the TLS 1.3 draft has b= een approved.

 

Regards,

Tony

--_000_810C31990B57ED40B2062BA10D43FBF501BF1D7AXMB116CNCrimnet_-- From nobody Thu Oct 26 10:10:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8357413EF48 for ; Thu, 26 Oct 2017 10:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ihs5WvlXAkHb for ; Thu, 26 Oct 2017 10:10:29 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D35513F088 for ; Thu, 26 Oct 2017 10:10:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id F1457B538F; Thu, 26 Oct 2017 20:10:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id nvhFz4F8MbqY; Thu, 26 Oct 2017 20:10:26 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 31D302315; Thu, 26 Oct 2017 20:10:22 +0300 (EEST) Date: Thu, 26 Oct 2017 20:10:22 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: Tony Putman , "tls@ietf.org" Message-ID: <20171026171022.ur3jcpir7jjr552h@LK-Perkele-VII> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> <140080C241BAA1419B58F093108F9EDC2CEBEF@UK-MAL-MBOX-02.dyson.global.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 17:10:31 -0000 On Thu, Oct 26, 2017 at 09:46:09AM -0700, Eric Rescorla wrote: > On Thu, Oct 26, 2017 at 9:41 AM, Tony Putman wrote: > > > I thought we would need to modify the key schedule in section 7.1, > > replacing the > > > > PSK input at the start with the static share [c_id]S_id (or [s_id]C_id) > > and then replace > > > > the (EC)DHE input lower down with the Triple-DH. > > > > That's one option. Allowing PSK key slot to hold a keypair? However, that would only work for server authentication, not client authentication, which would need its own mechanisms. Which are rendered more interesting by being in the last flight and thus not being able to affect server encryption keys. Also, I would be real careful about how such thing would interact with 0-RTT. 0-RTT is difficult to analyze as is, you don't need unbound keys to make it even more exciting. -Ilari From nobody Thu Oct 26 10:31:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F5813F3D7 for ; Thu, 26 Oct 2017 10:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 DpAu2Xh7vDec for ; Thu, 26 Oct 2017 10:31:32 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id B900E13F3C7 for ; Thu, 26 Oct 2017 10:31:31 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v9QHTCcd027098; Thu, 26 Oct 2017 13:29:28 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Dan Brown , "tls@ietf.org" Thread-Topic: [TLS] Preshared Keypairs for (D)TLS 1.2 Thread-Index: AQHTTn/JVUBYiVMUSduzwinXMAIY6A== Date: Thu, 26 Oct 2017 17:28:07 +0000 Message-ID: <1F08F49E-7E55-49ED-A890-3F85F7E1F302@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-originating-ip: [172.25.177.154] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3591869287_241266563" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-26_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710260228 Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 17:31:35 -0000 --B_3591869287_241266563 Content-type: multipart/alternative; boundary="B_3591869287_1320826591" --B_3591869287_1320826591 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable MQV was not licensed as a part of the NSA ECC deal. =20 If I has a choice, I=E2=80=99d pick HMQV or FHMQV =E2=80=93 with understanding that the= re are likely to be licensing issues. And I think those protocols would rule= out use of EC keys on most of the currently available hardware tokens. -- Regards, Uri Blumenthal =20 From: TLS on behalf of Dan Brown Date: Thursday, October 26, 2017 at 13:11 To: Tony Putman , "tls@ietf.org" Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 =20 Hi Tony, =20 Perhaps (some variant of) Menezes=E2=80=94Qu=E2=80=94Vanstone MQV key agreement might w= ork for your problem. =20 =20 There are some security analyses for variants MQV, e.g. HMQV, and it offers= even better efficiency than triple-DH. =20 =20 The original MQV appears in a few standards (NIST SP 63a, IEEE 1363, ANSI X= 9.63, even SEC1, and was dropped from Suite B =E2=80=A6). I believe that some I-D= s were written on using MQV in TLS (or elsewhere in IETF), but they expired. =20 Best regards, =20 Dan =20 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Tony Putman Sent: Thursday, October 26, 2017 11:03 AM To: tls@ietf.org Subject: [TLS] Preshared Keypairs for (D)TLS 1.2 =20 Hi all, =20 I've recently started working in the IoT space and wish to standardize=20 our transport security by introducing the use of DTLS. It seems that the=20 usual practice is to use PSK for mutual authentication, but I'm not=20 happy with this solution. A breach of server security allows not only=20 server impersonation, but also, due to the PSK symmetry, client=20 impersonation. =20 We are already using static ECDH keys for authentication (at the=20 application layer), so I looked for a way to make use of these in DTLS=20 and came up with the following solution using (D)TLS 1.2: =20 Assume the client is provisioned with an Id, a corresponding private key=20 'c_id' and a corresponding server public key 'S_id' (the server key may=20 be different for each Id or it may be common across all clients); the=20 server has a list of client public keys 'C_id' and corresponding server=20 private key(s) 's_id'. This OOB pre-provisioning corresponds to that of=20 a symmetric PSK. =20 The TLS 1.2 message exchange is identical to that for a TLS_(EC)DHE_PSK=20 handshake as in RFC4279. This solution applies to both DH/DHE keys and=20 to ECDH/ECDHE keys. The IoT solutions will typically use ECDH/ECDHE, so=20 the following explanation focuses on the EC variant. The messages are: =20 Client Server ------ ------ ClientHello -----> ServerHello ServerKeyExchange <----- ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished -----> ChangeCipherSpec <----- Finished Application Data <----> Application Data =20 The way this differs from TLS_ECDHE_PSK is only in the generation of=20 the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A'=20 (public) from the server; and 'b' (private) and 'B' (public) from the=20 client. Then the client and server form the premaster secret in a struct=20 with the following information (where [x]Y represents multiplication of=20 the point 'Y' by the scalar 'x'): Client Premaster: [b]A || [c_id]A || [b]S_id Server Premaster: [a]B || [a]C_id || [s_id]B =20 The first term provides PFS even if both client and server static=20 private keys become known; the second term provides client=20 authentication even if server keys are compromised; and the third term=20 provides server authentication even if client keys are compromised. =20 My questions to the list are: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Has anything similar to this been proposed before (I found nothing)? 2. Can anyone see a problem with this formulation? 3. Is there any interest in this (I would be happy to write an ID)? =20 The reason that I advocate this for IoT devices over signature schemes=20 is that the code for ECDH will already have to be present if modern=20 key agreement methods with PFS are to be used. So this solution uses=20 fewer resources than ECDHE together with a signature scheme in terms of=20 code space and RAM, and improves execution speed (I believe ECDH is about=20 twice as fast as equivalent signature generation/checking). Also, fewer=20 messages are needed and the messages are smaller (even if using raw keys). =20 A constraint not made explicit above is that the (EC)DHE keys must use=20 the same group/curve parameters as define the preshared keypairs. Since=20 the ClientHello does not contain any client information, this means the=20 server endpoint (e.g. as defined by SNI) can only support a single form=20 of preshared keypair. This could be improved on in TLS 1.3. =20 I don't believe that this constraint is serious, because this method is=20 designed to be used in the same scenarios as PSK; that is, where client=20 and server have an OOB method of receiving authentication credentials=20 from a common source. In this situation, the server is unlikely to be=20 serving clients which use multiple types of preshared keypairs, though=20 it does mean that if the keypair format is changed (e.g. strengthened)=20 during the life of an IoT product then a new server endpoint will have=20 to be defined for the upgraded products. =20 Additionally, this method is proposed to prevent the leaking of client=20 credentials if the server is compromised. This means that the client=20 private key must be high-entropy: this method is not suitable for keys=20 derived from passwords or other low-entropy sources. =20 Lastly, I have had a look at extending this to TLS 1.3 and it seems=20 pretty straightforward; however, there is no urgency and I feel we can=20 defer that to after the TLS 1.3 draft has been approved.=20 =20 Regards, Tony --B_3591869287_1320826591 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

MQV was not licensed as a part of th= e NSA ECC deal.

 

If I has a choice, I=E2=80=99d pick HMQV or FHMQV =E2=80=93 with understand= ing that there are likely to be licensing issues. And I think those protocol= s would rule out use of EC keys on most of the currently available hardware = tokens.

--

Regards,

<= /div>

Uri Blume= nthal

 

From: TLS &= lt;tls-bounces@ietf.org> on behalf of Dan Brown <danibrown@blackberry.= com>
Date: Thursday, October 26, 2017 at 13:11
To: To= ny Putman <Tony.Putman@dyson.com>, "tls@ietf.org" <tls@ie= tf.org>
Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2

 

Hi Tony= ,

 

Perhaps (some variant of) M= enezes=E2=80=94Qu=E2=80=94Vanstone MQV key agreement might work for your problem.  =

 =

There are some security anal= yses for variants MQV, e.g. HMQV, and it offers even better efficiency than = triple-DH. 

=  

The origina= l MQV appears in a few standards (NIST SP 63a, IEEE 1363, ANSI X9.63, even S= EC1, and was dropped from Suite B =E2=80=A6).  I believe that some I-Ds were = written on using MQV in TLS (or elsewhere in IETF), but they expired.

 

Best regards,

 

Dan

 

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of <= /b>Tony Putman
Sent: Thursday, October 26, 2017 11:03 AM
To:= tls@ietf.org
Subject: [TLS] Preshared Keypairs for (D)TLS 1.2=

 = ;

Hi all,

 

I've recently started working= in the IoT space and wish to standardize

our transport security by introducing the use = of DTLS. It seems that the

usual practice is to use PSK for mutual authentication, but I= 'm not

happy= with this solution. A breach of server security allows not only

server impersonation, b= ut also, due to the PSK symmetry, client

impersonation.

 

We are already using static ECDH keys for authentic= ation (at the

and came up wit= h the following solution using (D)TLS 1.2:

 

Assume the client is provisioned with an Id, a corre= sponding private key

be diff= erent for each Id or it may be common across all clients); the <= /o:p>

server has a list of clie= nt public keys 'C_id' and corresponding server

private key(s) 's_id'. This OOB pre-provi= sioning corresponds to that of

a symmetric PSK.

 

The TLS 1.2 message exchange is identical to that for a TLS= _(EC)DHE_PSK

handshake as in RFC4279. This solution applies to both DH/DHE keys and

to ECDH/ECDHE ke= ys. The IoT solutions will typically use ECDH/ECDHE, so

the following explanation focuse= s on the EC variant. The messages are:

 

    Client     &= nbsp;            = ;            &nb= sp;  Server

    ------        = ;            &nb= sp;            ------=

  =   ClientHello         ----->=

  =             &nbs= p;            &n= bsp;          ServerHello

   =             &nbs= p;            &n= bsp;   ServerKeyExchange

         =             &nbs= p;  <-----    ServerHelloDone

    ClientKeyExchange=

  =   ChangeCipherSpec

    Finished      &n= bsp;     ----->

        &n= bsp;            =             ChangeCip= herSpec

 = ;            &nb= sp;          <-----  &n= bsp;        Finished

    Applicati= on Data    <---->   Application Data

 

The way this differs from T= LS_ECDHE_PSK is only in the generation of

the premaster secret. Suppose the ECDHE keys a= re 'a' (private) and 'A'

(public) from the server; and 'b' (private) and 'B' (public) fr= om the

clien= t. Then the client and server form the premaster secret in a struct <= o:p>

with the following i= nformation (where [x]Y represents multiplication of

the point 'Y' by the scalar 'x'):

  &nb= sp; Client Premaster:   [b]A || [c_id]A || [b]S_id

    Server Pr= emaster:   [a]B || [a]C_id || [s_id]B

 

The first term provides PFS even if both client= and server static

private keys become known; the second term provides client

authentication even if= server keys are compromised; and the third term

provides server authentication even if = client keys are compromised.

 

My questions to the list are:

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

1. Has anything similar to this = been proposed before (I found nothing)?

2. Can anyone see a problem with this formulation= ?

3. Is there= any interest in this (I would be happy to write an ID)?

 

The reason that I advocate this for Io= T devices over signature schemes

is that the code for ECDH will already have to be prese= nt if modern

key agreement methods with PFS are to be used. So this solution uses

fewer resources th= an ECDHE together with a signature scheme in terms of

=

code space and RAM, and improves e= xecution speed (I believe ECDH is about

twice as fast as equivalent signature generation= /checking). Also, fewer

messages are needed and the messages are smaller (even if using = raw keys).

= &n= bsp;

A constr= aint not made explicit above is that the (EC)DHE keys must use <= /o:p>

the same group/curve para= meters as define the preshared keypairs. Since

the ClientHello does not contain any clie= nt information, this means the

server endpoint (e.g. as defined by SNI) can only support= a single form

of preshared keypair. This could be improved on in TLS 1.3.

 

I don't believe that this constr= aint is serious, because this method is

designed to be used in the same scenarios as PSK= ; that is, where client

and server have an OOB method of receiving authentication creden= tials

from a= common source. In this situation, the server is unlikely to be =

serving clients which us= e multiple types of preshared keypairs, though

it does mean that if the keypair format i= s changed (e.g. strengthened)

during the life of an IoT product then a new server endpoi= nt will have

to be defined for the upgraded products.

 

Additionally, this method is proposed to prevent the = leaking of client

credentials if the server is compromised. This means that the client <= /span>

private key m= ust be high-entropy: this method is not suitable for keys =

derived from passwords or othe= r low-entropy sources.

 

Lastly, I have had a look at extending this to TLS 1.3 and it seems

pretty straightf= orward; however, there is no urgency and I feel we can

defer that to after the TLS 1.3 d= raft has been approved.

 

Regards,

Hi all, > >   > > I've recently started working in the IoT space and wish to standardize > > our transport security by introducing the use of DTLS. It seems that the > > usual practice is to use PSK for mutual authentication, but I'm not > > happy with this solution. A breach of server security allows not only > > server impersonation, but also, due to the PSK symmetry, client > > impersonation. > >   > > We are already using static ECDH keys for authentication (at the > > application layer), so I looked for a way to make use of these in DTLS > > and came up with the following solution using (D)TLS 1.2: > >   > > Assume the client is provisioned with an Id, a corresponding private key > > 'c_id' and a corresponding server public key 'S_id' (the server key may > > be different for each Id or it may be common across all clients); the > > server has a list of client public keys 'C_id' and corresponding server > > private key(s) 's_id'. This OOB pre-provisioning corresponds to that of > > a symmetric PSK. > >   > > The TLS 1.2 message exchange is identical to that for a TLS_(EC)DHE_PSK > > handshake as in RFC4279. This solution applies to both DH/DHE keys and > > to ECDH/ECDHE keys. The IoT solutions will typically use ECDH/ECDHE, so > > the following explanation focuses on the EC variant. The messages are: > >   > >     Client                                 Server > >     ------                                 ------ > >     ClientHello         -----> > >                                       ServerHello > >                                 ServerKeyExchange > >                         <-----    ServerHelloDone > >     ClientKeyExchange > >     ChangeCipherSpec > >     Finished            -----> > >                                  ChangeCipherSpec > >                         <-----           Finished > >     Application Data    <---->   Application Data > >   > > The way this differs from TLS_ECDHE_PSK is only in the generation of > > the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A' > > (public) from the server; and 'b' (private) and 'B' (public) from the > > client. Then the client and server form the premaster secret in a struct > > with the following information (where [x]Y represents multiplication of > > the point 'Y' by the scalar 'x'): > >     Client Premaster:   [b]A || [c_id]A || [b]S_id > >     Server Premaster:   [a]B || [a]C_id || [s_id]B > >   > > The first term provides PFS even if both client and server static > > private keys become known; the second term provides client > > authentication even if server keys are compromised; and the third term > > provides server authentication even if client keys are compromised. > >   > > My questions to the list are: > > ============================= > > 1. Has anything similar to this been proposed before (I found nothing)? > > 2. Can anyone see a problem with this formulation? > > 3. Is there any interest in this (I would be happy to write an ID)? > >   > > The reason that I advocate this for IoT devices over signature schemes > > is that the code for ECDH will already have to be present if modern > > key agreement methods with PFS are to be used. So this solution uses > > fewer resources than ECDHE together with a signature scheme in terms of > > code space and RAM, and improves execution speed (I believe ECDH is about > > twice as fast as equivalent signature generation/checking). Also, fewer > > messages are needed and the messages are smaller (even if using raw keys). > >   > > A constraint not made explicit above is that the (EC)DHE keys must use > > the same group/curve parameters as define the preshared keypairs. Since > > the ClientHello does not contain any client information, this means the > > server endpoint (e.g. as defined by SNI) can only support a single form > > of preshared keypair. This could be improved on in TLS 1.3. > >   > > I don't believe that this constraint is serious, because this method is > > designed to be used in the same scenarios as PSK; that is, where client > > and server have an OOB method of receiving authentication credentials > > from a common source. In this situation, the server is unlikely to be > > serving clients which use multiple types of preshared keypairs, though > > it does mean that if the keypair format is changed (e.g. strengthened) > > during the life of an IoT product then a new server endpoint will have > > to be defined for the upgraded products. > >   > > Additionally, this method is proposed to prevent the leaking of client > > credentials if the server is compromised. This means that the client > > private key must be high-entropy: this method is not suitable for keys > > derived from passwords or other low-entropy sources. > >   > > Lastly, I have had a look at extending this to TLS 1.3 and it seems > > pretty straightforward; however, there is no urgency and I feel we can > > defer that to after the TLS 1.3 draft has been approved. > >   > > Regards, > > Tony > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Oct 26 16:38:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D078713B472 for ; Thu, 26 Oct 2017 16:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seroXSVJzcKR for ; Thu, 26 Oct 2017 16:38:29 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A511389AC for ; Thu, 26 Oct 2017 16:38:29 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id k3so4355587ywk.8 for ; Thu, 26 Oct 2017 16:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=zMCmo91KjxONbJLdO+NMP835MhJVgMCTCIBWz1rHfZc=; b=qGMwT2ZdjGdUvHo2uNJurJB8dcxtcD3aFd6C0N0w1uxlkXXrhsCr5dHMVVimTSrQjg Hcr9Bce3Jeqs1OQRRhN7Pb2RQC7bnFKu42M67qfvcUr5vXXRKfkvw0WKj3JpdEpUivoC 4/HHqHjTl6wkDSP3ZcFXLl9CIrAla4FL2Z1X4tsfwd9xcAZlmqC8hWtmJ6zbqMa9D6K6 ddUGFksdg6V7SYwHURIdL0iGk7FxeqZ5cr4VgAHMe8V6ZYxbYmam/wspojCMQekwu+Kc rEntsDkN+5cWmEHYf/KWN0TWbjRl8GnsCdf9k3Y3uCUqz/yiWtfcOBveIxmV6TdkypeF e9Kw== 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=zMCmo91KjxONbJLdO+NMP835MhJVgMCTCIBWz1rHfZc=; b=JRXkNfYRjBhZlerl9njFS8tJLxMK0kKcSVXayIAc018EP6QjoxJOYuy+HX+Q4bBlRE Cq4hml3AbUd6euQmV5AjwmwEFwuMdQ7znkJKQ/qXjqOmlcGgtL57ckA/1c+YTd6Ivfrx qTQRyEwoRtQpSw7tvrFVj0ao5mpGxL6YkKtEBGle43VDmgmhDskJYs4/4r1WNwngSy6j DVtF5hWu58vQ6fA0PY7NUqVSSKcNdHUQ5GJwognviiUtF2iOkYytZW3vfKklhd4yJHMw q/JJrLozGMb48M1+woDg8ECorfUZ4QO5jXQbrqK4t7cjXRrX+XSwL/yj58EgQ0aScF89 RHwQ== X-Gm-Message-State: AMCzsaUrCnrld3ag/F5bJCLENgOL+WvN82u1PRS1AbL34TLqy5omAOm8 LFPDOUV+gWvgwrDzeMdQt7+yAPrVn8mfLOMT71+8uWM3YWg= X-Google-Smtp-Source: ABhQp+Rmp7c/j8NrMV3Dsy3If1TbbYvRewSwv/S/L5w9Ed6k7dc6llMBMcK2GTHvpC5ayob+hOU8LE64OGYiuVpoiIA= X-Received: by 10.37.83.66 with SMTP id h63mr4375785ybb.397.1509061108421; Thu, 26 Oct 2017 16:38:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Thu, 26 Oct 2017 16:37:47 -0700 (PDT) From: Eric Rescorla Date: Thu, 26 Oct 2017 16:37:47 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113e688e4feca5055c7bab72" Archived-At: Subject: [TLS] New header PRs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 23:38:31 -0000 --001a113e688e4feca5055c7bab72 Content-Type: text/plain; charset="UTF-8" Hi folks, Building on our discussion in Prague I've posted two PRs for shrinking the header size: https://github.com/tlswg/dtls13-spec/pull/16 - This introduces a shortened header format that just has a truncated sequence number and epoch but no length so it has to be packet one per datagram https://github.com/tlswg/dtls13-spec/pull/20 - This builds on top of PR#16 to reduce the long header format, removing the version number and shortening the epoch/sequence number. Please take a look. In the interest of forward progress, I intend to merge before I do the next draft but I recognize that is getting ahead of consensus, so we can discuss in Singapore too. -Ekr --001a113e688e4feca5055c7bab72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi folks,

Building on our discussion in= Prague I've posted two PRs for shrinking the
header size:

- This = introduces a shortened header format that just has a truncated sequence
number and epoch but no length so it has to be packet one per datagr= am

- = This builds on top of PR#16 to reduce the long header format, removing the<= /div>
version number and shortening the epoch/sequence number.

Please take a look. In the interest of forward progress, I= intend to merge before
I do the next draft but I recognize that = is getting ahead of consensus, so we can
discuss in Singapore too= .

-Ekr

--001a113e688e4feca5055c7bab72-- From nobody Thu Oct 26 22:37:55 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0FE13AAC7 for ; Thu, 26 Oct 2017 22:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMrh3vkx9yZs for ; Thu, 26 Oct 2017 22:37:50 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46EB0137C4A for ; Thu, 26 Oct 2017 22:37:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 15C475DE5E; Fri, 27 Oct 2017 08:37:47 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id cf_yJFJ-eg-s; Fri, 27 Oct 2017 08:37:46 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 781022317; Fri, 27 Oct 2017 08:37:44 +0300 (EEST) Date: Fri, 27 Oct 2017 08:37:44 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20171027053743.b454rtj5qhup2k34@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] New header PRs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 05:37:52 -0000 On Thu, Oct 26, 2017 at 04:37:47PM -0700, Eric Rescorla wrote: > Hi folks, > > Building on our discussion in Prague I've posted two PRs for shrinking the > header size: > > https://github.com/tlswg/dtls13-spec/pull/16 > - This introduces a shortened header format that just has a truncated > sequence > number and epoch but no length so it has to be packet one per datagram > > https://github.com/tlswg/dtls13-spec/pull/20 > - This builds on top of PR#16 to reduce the long header format, removing the > version number and shortening the epoch/sequence number. > How does the latter one interact with the stuff in "Establishing New Associations with Existing Parameters"? The initial packets are distinguishable yes, but that subsection talks about possibly doing full handshake before discarding old state, which could prove rather messy. Also, I think that due to DTLS 1.2 compatiblity, only record type 23 (and 25) can use new record format. In practicular, I think 21 and 22 can not, since existing DTLS 1.2 libraries use those without negotiation. Also, on fast transmission, loss burst of ~2000 packets doesn't take much time. Such loss burst could result, e.g., from transient routing failure. One might want to discuss how to prevent desyncs from those. -Ilari From nobody Fri Oct 27 04:56:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5F613A8A1 for ; Fri, 27 Oct 2017 04:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i48wLYj51X7 for ; Fri, 27 Oct 2017 04:56:51 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCB91387BC for ; Fri, 27 Oct 2017 04:56:49 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id k3so5487422ywk.8 for ; Fri, 27 Oct 2017 04:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HwG472BZFVwuraRAuKvRU1yfABm12Oqvsm6UzboGxto=; b=QXacgZLLtxGQwCMYC8R6plLcNLV6BAzWvDEOSikN3B9P4INU+xAyHyCYWn6Ips7HyP VDKd/sOCWkae7i1wECxhnq8DrNri2dLiUfjCHTw12/ysj9EVzVLn6KWIxcd3YDgGym/L DPnrLRcq1Uf7WEBqq1WEXc6zdPgmxclV6gZmxct/LcnvQU7nVOxkGhf/MNmhL1HCvIyj 2UQ7m9ZJW3p31+Thi4AlX6L6+34T7azvVL5v82nthJRa9aMjcWadBn3XAMJomfZGiQBx Q+OXAwjbIzS/3aVPC20PbJ/j78tL4xI7KBMzHyl5pbck3cOnfX3RYpUHpdJQN4XNYa95 yUng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HwG472BZFVwuraRAuKvRU1yfABm12Oqvsm6UzboGxto=; b=he8B5vYbs9LRdRC/KM5ic1hetzc7OWWhXwPeYY/TUDhNmdFq8yjIw96K242ldmupmY s4Q32CJ8sc4EZ9EOuPGEvHqGKPGbE2xU8FiOC1CxTnt3+OZEUA4PqYP+zSBLFjc1Qo1g VpAU9pSrmP+lSYY8440REWOFz7Ic6AcKwzAXHu24CC+p3GZJjK7ecOV+vaX3itF5bdp9 mmjoCdAVqcTc0hW84MZMLUsizzyTfmgR7OL05f+YhQHwG0kH5Zkf1+h17aqoSFHvrcg1 IWQ9sW1C2BI4vhL+eoP1di76eKeHUc5Z5cVfbmKnY8Bu/qdoHi3WfCrqcO4r8KVwItGb NEng== X-Gm-Message-State: AMCzsaUiSb8f0BmIOUVLVAj6QqRScwmvY299m3Nz3h92htBBjdpzLUnX K2ZNqesU2QxOA9rA1kNfWQUJBGjmZAWMTYAhwvPanw== X-Google-Smtp-Source: ABhQp+TxGAzu6KDssMYCHc8v42oBijRW1UO6DpwZSj1XtZzhGtgfeyADE3tFiKHf8K68oSY9q/FTsGOlEHVvkzk5ECA= X-Received: by 10.129.26.208 with SMTP id a199mr141883ywa.280.1509105408940; Fri, 27 Oct 2017 04:56:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 27 Oct 2017 04:56:08 -0700 (PDT) In-Reply-To: <20171027053743.b454rtj5qhup2k34@LK-Perkele-VII> References: <20171027053743.b454rtj5qhup2k34@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 27 Oct 2017 04:56:08 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1142d0d4d431ac055c85fba9" Archived-At: Subject: Re: [TLS] New header PRs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 11:56:53 -0000 --001a1142d0d4d431ac055c85fba9 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 26, 2017 at 10:37 PM, Ilari Liusvaara wrote: > On Thu, Oct 26, 2017 at 04:37:47PM -0700, Eric Rescorla wrote: > > Hi folks, > > > > Building on our discussion in Prague I've posted two PRs for shrinking > the > > header size: > > > > https://github.com/tlswg/dtls13-spec/pull/16 > > - This introduces a shortened header format that just has a truncated > > sequence > > number and epoch but no length so it has to be packet one per datagram > > > > https://github.com/tlswg/dtls13-spec/pull/20 > > - This builds on top of PR#16 to reduce the long header format, removing > the > > version number and shortening the epoch/sequence number. > > > > How does the latter one interact with the stuff in "Establishing New > Associations with Existing Parameters"? The initial packets are > distinguishable yes, but that subsection talks about possibly doing > full handshake before discarding old state, which could prove rather > messy. I'm not sure I understand your concern here. Is it that you would have packets from both connections in the short format and not be able to know which is which? That seems like it's a problem now too just made a bit worse by the reduced epoch/seq. The real answer here is, of course, conn-id. > Also, I think that due to DTLS 1.2 compatiblity, only record type 23 > (and 25) can use new record format. In practicular, I think 21 and 22 > can not, since existing DTLS 1.2 libraries use those without > negotiation. > Sorry, I'm not following you here: this is only for DTLSCipherText, so the external type will always be 23. All the other external types will be using the old format, so easily distinguishable. Also, on fast transmission, loss burst of ~2000 packets doesn't take > much time. Such loss burst could result, e.g., from transient routing > failure. One might want to discuss how to prevent desyncs from those. > Sure. The answer for this is to use the longer header :) -Ekr > > -Ilari > --001a1142d0d4d431ac055c85fba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 26, 2017 at 10:37 PM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Thu, Oct 26, 2017 at 04:37:47PM -0700, Eric Rescorla wrote: > Hi folks,
>
> Building on our discussion in Prague I've posted two PRs for shrin= king the
> header size:
>
> https://github.com/tlswg/dtls13-spec/pull/16
> - This introduces a shortened header format that just has a truncated<= br> > sequence
> number and epoch but no length so it has to be packet one per datagram=
>
> https://github.com/tlswg/dtls13-spec/pull/20
> - This builds on top of PR#16 to reduce the long header format, removi= ng the
> version number and shortening the epoch/sequence number.
>

How does the latter one interact with the stuff in "Establishin= g New
Associations with Existing Parameters"? The initial packets are
distinguishable yes, but that subsection talks about possibly doing
full handshake before discarding old state, which could prove rather
messy.

Also, I think that due to DTLS 1.2 compatiblity, only record type 23
(and 25) can use new record format. In practicular, I think 21 and 22
can not, since existing DTLS 1.2 libraries use those without
negotiation.


Also, on fast transmission, loss burst of ~2000 packets d= oesn't take
much time. Such loss burst could result, e.g., from transient routing
failure. One might want to discuss how to prevent desyncs from those.

Sure. The answer for this is to use the long= er header :)

-Ekr



-Ilari

--001a1142d0d4d431ac055c85fba9-- From nobody Fri Oct 27 05:25:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1713A8A1 for ; Fri, 27 Oct 2017 05:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNpkjsGsQ6DR for ; Fri, 27 Oct 2017 05:25:38 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3891394E4 for ; Fri, 27 Oct 2017 05:25:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 399DF97B31; Fri, 27 Oct 2017 15:25:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id ocblcIX5Jjhv; Fri, 27 Oct 2017 15:25:34 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 6279721C; Fri, 27 Oct 2017 15:25:32 +0300 (EEST) Date: Fri, 27 Oct 2017 15:25:31 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20171027122531.6crnbpy54mbbjswf@LK-Perkele-VII> References: <20171027053743.b454rtj5qhup2k34@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] New header PRs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 12:25:40 -0000 On Fri, Oct 27, 2017 at 04:56:08AM -0700, Eric Rescorla wrote: > On Thu, Oct 26, 2017 at 10:37 PM, Ilari Liusvaara > wrote: > > > On Thu, Oct 26, 2017 at 04:37:47PM -0700, Eric Rescorla wrote: > > > Hi folks, > > > > > > Building on our discussion in Prague I've posted two PRs for shrinking > > the > > > header size: > > > > > > https://github.com/tlswg/dtls13-spec/pull/16 > > > - This introduces a shortened header format that just has a truncated > > > sequence > > > number and epoch but no length so it has to be packet one per datagram > > > > > > https://github.com/tlswg/dtls13-spec/pull/20 > > > - This builds on top of PR#16 to reduce the long header format, removing > > the > > > version number and shortening the epoch/sequence number. > > > > > > > How does the latter one interact with the stuff in "Establishing New > > Associations with Existing Parameters"? The initial packets are > > distinguishable yes, but that subsection talks about possibly doing > > full handshake before discarding old state, which could prove rather > > messy. > > > I'm not sure I understand your concern here. Is it that you would > have packets from both connections in the short format and not be > able to know which is which? That seems like it's a problem now too > just made a bit worse by the reduced epoch/seq. The real answer > here is, of course, conn-id. Yes, the problem is not being able to tell apart epochs 0-2 used by the handshake and epochs 3- used by established connection. And with regards to conn-id, unless the server just aborts every connection attempt without conn-id extension, you can get situations where one of the overlapping connections has conn-id and the other not. > > Also, I think that due to DTLS 1.2 compatiblity, only record type 23 > > (and 25) can use new record format. In practicular, I think 21 and 22 > > can not, since existing DTLS 1.2 libraries use those without > > negotiation. > > > > Sorry, I'm not following you here: this is only for DTLSCipherText, so > the external type will always be 23. All the other external types will > be using the old format, so easily distinguishable. " Implementations can distinguish the two header formats by examining the first byte, which in the DTLSCiphertext header represents the content type. The only valid values for the content type are alert(21), handshake(22), application_data(23), and ack(25), with application_data actually representing protected data with the true content type being encrypted. If any of these values is present, then the record MUST be handled as DTLSCiphertext. " That seems to imply that records starting with 22 have 32-bit shortened RSN, which obviously is not correct. > Also, on fast transmission, loss burst of ~2000 packets doesn't take > > much time. Such loss burst could result, e.g., from transient routing > > failure. One might want to discuss how to prevent desyncs from those. > > > > Sure. The answer for this is to use the longer header :) Might put a note that if one should use longer header if there can be more than about 2000 consequtive lost packets. -Ilari From nobody Fri Oct 27 06:15:07 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE7D13F4CE for ; Fri, 27 Oct 2017 06:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-G5HIZPT7bG for ; Fri, 27 Oct 2017 06:15:04 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A5813955B for ; Fri, 27 Oct 2017 06:15:04 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id q1so5689712ywh.5 for ; Fri, 27 Oct 2017 06:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v5GiiqR7VlBIvsLhPwrfJKHgU8IYDGA9jqpKIJj/Sa8=; b=Rq5JH31yD3kHymEr9NVkcL5df0F4khcDOrlqlpxWuFdNBK33irEoZFxbKMl7WYXZmH 0OBWmZ/7oAz6Tu+Dlgwp/en5YWDDR+wlBJ1DR/t1chD39sSazAqzRgeTmfOy15bnfh+S W/9QCEAmuiiwRU1rvs9NMBYPuvFjZgEEu4Tsw1Mw45I0ua9s75N5ZPQzvareClgIhsa2 ImHL9WHj9YnKIyLrP5xZvzY2JF4ZaDe4N6/+UdTLqEQEAxPOM5cIyW568ELJ6mUskfuK YSdhvafOSfANbV0q2roOG/i72g3DELRPrpojq7oftAlIRCX+xFqavltwUnEI2o+gCDyc xqJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v5GiiqR7VlBIvsLhPwrfJKHgU8IYDGA9jqpKIJj/Sa8=; b=qCU2a2JpLBVSrQXu4kBz4DYDwCGz0cX0BnJyiK37vsXoVnpp6j6TEL57d/9/3aZVU5 cGeAoL2NwKuwStCXoB9IqXhiLg/cQnrPp1j5iyidEdYuUa9GBoLaPMKxjw+PIhHG1uJ4 dcXdCm1aCa6nGw72xuBGoieAceD1KPlfCT05IRxuGN2GqJD42EQsztpeIZBizWHBVOIZ tj38t8I7C6KRDo8iPrNljUf2dhMvFs37nbv5ZSEsak2uAVI/ZsUxlP+/MHOMDgXEHe13 kQA7QZKJ5PjcVQuACRlu9qGrRT9VFGDjRD+J0pT50eaddHFH0VJ1pHF3X3ZsSO1klBGa ui4Q== X-Gm-Message-State: AMCzsaXqJ48T6N3NCHTTE0uOVFF26EkiSbx268rBt81EHHFWvynoNLZT ZRi3DyRJK6bFXK3+AgqrpDn8ysigVQy2Ibbjui9NJLqA X-Google-Smtp-Source: ABhQp+R9rShDCLjm1LF+5v0GYmvYKxte1p+KkgN6/GjRbgUGlElbFZmN5DKREu4GVQNwZxvAWj1iZV1Vm351oYVwr4Y= X-Received: by 10.129.26.208 with SMTP id a199mr300911ywa.280.1509110103590; Fri, 27 Oct 2017 06:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 27 Oct 2017 06:14:22 -0700 (PDT) In-Reply-To: <20171027122531.6crnbpy54mbbjswf@LK-Perkele-VII> References: <20171027053743.b454rtj5qhup2k34@LK-Perkele-VII> <20171027122531.6crnbpy54mbbjswf@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 27 Oct 2017 06:14:22 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1142d0d4a6e085055c871307" Archived-At: Subject: Re: [TLS] New header PRs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 13:15:06 -0000 --001a1142d0d4a6e085055c871307 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 27, 2017 at 5:25 AM, Ilari Liusvaara wrote: > On Fri, Oct 27, 2017 at 04:56:08AM -0700, Eric Rescorla wrote: > > On Thu, Oct 26, 2017 at 10:37 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Thu, Oct 26, 2017 at 04:37:47PM -0700, Eric Rescorla wrote: > > > > Hi folks, > > > > > > > > Building on our discussion in Prague I've posted two PRs for > shrinking > > > the > > > > header size: > > > > > > > > https://github.com/tlswg/dtls13-spec/pull/16 > > > > - This introduces a shortened header format that just has a truncated > > > > sequence > > > > number and epoch but no length so it has to be packet one per > datagram > > > > > > > > https://github.com/tlswg/dtls13-spec/pull/20 > > > > - This builds on top of PR#16 to reduce the long header format, > removing > > > the > > > > version number and shortening the epoch/sequence number. > > > > > > > > > > How does the latter one interact with the stuff in "Establishing New > > > Associations with Existing Parameters"? The initial packets are > > > distinguishable yes, but that subsection talks about possibly doing > > > full handshake before discarding old state, which could prove rather > > > messy. > > > > > > I'm not sure I understand your concern here. Is it that you would > > have packets from both connections in the short format and not be > > able to know which is which? That seems like it's a problem now too > > just made a bit worse by the reduced epoch/seq. The real answer > > here is, of course, conn-id. > > Yes, the problem is not being able to tell apart epochs 0-2 used by > the handshake and epochs 3- used by established connection. > > And with regards to conn-id, unless the server just aborts every > connection attempt without conn-id extension, you can get situations > where one of the overlapping connections has conn-id and the other > not. Sure, this was already sort of an issue with epoch=1 for DTLS 1.2 connections, though content type helped. I'll add some text with suggestions > > Also, I think that due to DTLS 1.2 compatiblity, only record type 23 > > > (and 25) can use new record format. In practicular, I think 21 and 22 > > > can not, since existing DTLS 1.2 libraries use those without > > > negotiation. > > > > > > > Sorry, I'm not following you here: this is only for DTLSCipherText, so > > the external type will always be 23. All the other external types will > > be using the old format, so easily distinguishable. > > " > Implementations can distinguish the two header formats by examining > the first byte, which in the DTLSCiphertext header represents the > content type. The only valid values for the content type are > alert(21), handshake(22), application_data(23), and ack(25), > with application_data actually > representing protected data with the true content type being > encrypted. If any of these values is present, then the record MUST be > handled as DTLSCiphertext. > " > > That seems to imply that records starting with 22 have 32-bit > shortened RSN, which obviously is not correct. > Oh, I see. Yes, I got stuck in QUIC-think and forgot that in DTLS we use "DTLSPlaintext" here. I'll fix that. > Also, on fast transmission, loss burst of ~2000 packets doesn't take > > > much time. Such loss burst could result, e.g., from transient routing > > > failure. One might want to discuss how to prevent desyncs from those. > > > > > > > Sure. The answer for this is to use the longer header :) > > Might put a note that if one should use longer header if there can be > more than about 2000 consequtive lost packets. > Yes, thanks. -Ekr > > > -Ilari > --001a1142d0d4a6e085055c871307 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 27, 2017 at 5:25 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Fri, Oct 27, 2017 at 04:56:08AM -0700, = Eric Rescorla wrote:
> On Thu, Oct 26, 2017 at 10:37 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Thu, Oct 26, 2017 at 04:37:47PM -0700, Eric Rescorla wrote: > > > Hi folks,
> > >
> > > Building on our discussion in Prague I've posted two PRs= for shrinking
> > the
> > > header size:
> > >
> > > https://github.com/tlswg/dtls13-spec= /pull/16
> > > - This introduces a shortened header format that just has a = truncated
> > > sequence
> > > number and epoch but no length so it has to be packet one pe= r datagram
> > >
> > > https://github.com/tlswg/dtls13-spec= /pull/20
> > > - This builds on top of PR#16 to reduce the long header form= at, removing
> > the
> > > version number and shortening the epoch/sequence number.
> > >
> >
> > How does the latter one interact with the stuff in "Establis= hing New
> > Associations with Existing Parameters"? The initial packets = are
> > distinguishable yes, but that subsection talks about possibly doi= ng
> > full handshake before discarding old state, which could prove rat= her
> > messy.
>
>
> I'm not sure I understand your concern here. Is it that you would<= br> > have packets from both connections in the short format and not be
> able to know which is which? That seems like it's a problem now to= o
> just made a bit worse by the reduced epoch/seq. The real answer
> here is, of course, conn-id.

Yes, the problem is not being able to tell apart epochs 0-2 use= d by
the handshake and epochs 3- used by established connection.

And with regards to conn-id, unless the server just aborts every
connection attempt without conn-id extension, you can get situations
where one of the overlapping connections has conn-id and the other
not.

Sure, this was already sort of an issu= e with epoch=3D1 for DTLS 1.2 connections,
though content type he= lped. I'll add some text with suggestions

> > Also, I think that due to DTLS 1.2 compatiblity, only record type= 23
> > (and 25) can use new record format. In practicular, I think 21 an= d 22
> > can not, since existing DTLS 1.2 libraries use those without
> > negotiation.
> >
>
> Sorry, I'm not following you here: this is only for DTLSCipherText= , so
> the external type will always be 23. All the other external types will=
> be using the old format, so easily distinguishable.

"
Implementations can distinguish the two header formats by examining<= br> the first byte, which in the DTLSCiphertext header represents the
content type. The only valid values for the content type are
alert(21), handshake(22), application_data(23), and ack(25),
with application_data actually
representing protected data with the true content type being
encrypted. If any of these values is present, then the record MUST be
handled as DTLSCiphertext.
"

That seems to imply that records starting with 22 have 32-bit
shortened RSN, which obviously is not correct.

Oh, I see. Yes, I got stuck in QUIC-think and forgot that in DTLS w= e
use "DTLSPlaintext" here. I'll fix that.


> Also, on fast transmission, loss burst of ~2000 packets doesn't ta= ke
> > much time. Such loss burst could result, e.g., from transient rou= ting
> > failure. One might want to discuss how to prevent desyncs from th= ose.
> >
>
> Sure. The answer for this is to use the longer header :)

Might put a note that if one should use longer header if there can b= e
more than about 2000 consequtive lost packets.

Yes, thanks.

-Ekr
=C2=A0


-Ilari

--001a1142d0d4a6e085055c871307-- From nobody Fri Oct 27 07:37:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E330C13F572 for ; Fri, 27 Oct 2017 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP5QQcNe02Np for ; Fri, 27 Oct 2017 07:37:18 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3696E13F4F5 for ; Fri, 27 Oct 2017 07:37:12 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e85ky-0001Jw-EJ for tls@ietf.org; Fri, 27 Oct 2017 16:37:09 +0200 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 1e85kt-0000ZT-2N for tls@ietf.org; Fri, 27 Oct 2017 10:37:07 -0400 Received: (qmail 32633 invoked from network); 27 Oct 2017 14:36:59 -0000 Received: from unknown (HELO [IPv6:2607:fb90:7825:7f2d:2cf8:f1a1:ecfc:282e]) (Authenticated-user:_huitema@huitema.net@[172.58.41.110]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Oct 2017 14:36:59 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15A432) In-Reply-To: <20171026165755.l2mj6hen2owopyjw@LK-Perkele-VII> Date: Fri, 27 Oct 2017 07:36:58 -0700 Cc: Tony Putman , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <598487B4-6E3A-4426-96D7-DE1985951856@huitema.net> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> <20171026152129.3yuzb4wsz34b3e7r@LK-Perkele-VII> <140080C241BAA1419B58F093108F9EDC2CEBD8@UK-MAL-MBOX-02.dyson.global.corp> <20171026165755.l2mj6hen2owopyjw@LK-Perkele-VII> To: Ilari Liusvaara X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.12) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5kHlcS1TDjtqIVh6lBmXg0oXv9krsgRhBn0ayn6qsUc7RO6saVKtiei5 uUZjs8uJrOfHzJ6mVE7ewsipSVIfs4a9BdCCK2x31hqCB8drhyCGLB67TLnlh9i6Dr2tTQ7u+gp4 1QbiwlnsEyGOKeo1xL2Z3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA/itEW1aHIJYDvx6uGLOm1Bi99Or0uXh6FskGQ3mtr4LUU/Qweyn+lg7TbDa2rNOWNaHCnN rMSSA7xor9tnUlOY8pSJo/Vkdr+FbBdda40x5B/NGyVcjXsZLVHUb2pmaEmDh4PRiBbRliPgaurB TRjstfheF24EjrGuHVHIMu1lYZhMr2sR3cQs/oU/axm99b2jdwip2wrbEvxHA2swIjN6PhFSfsse t38tyDP81cDf6vvg7iEFLP+SSY+Av5+AiC4aVs0Hp0Cnl8jp9pzVFvXx5JJH7sE99y6PfNYG0JlM o3C2vtQ8krYTazicUoqDOrfGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATyzYT8K6rd4RA3UMT6Em/UONoJfh+XjGSeeT90H/uIGQ /MN7v8bPChM+FPlbR1XJOmsk5GHOGUlEf8hiFpdUEWbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW/a7J4lI9dq2HBFg+iT3zKvfFcHV2tQAVqGdj/zM7G/H0fgN5y0tqqfuQuS1mj2Wr5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 14:37:20 -0000 > On Oct 26, 2017, at 9:57 AM, Ilari Liusvaara wr= ote: > ... >=20 > Sorry, I was unclear. I didn't mean security analysis of Triple DH in > general, but security analysis of triple DH as embedded to TLS. >=20 Not just security, but also privacy. The triple DH exposes the public keys o= f server and client in clear text during the initial exchange. That=E2=80=99= s a big privacy issue! =E2=80=94 Christian Huitema=20= From nobody Fri Oct 27 16:18:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9891397F3 for ; Fri, 27 Oct 2017 16:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r5843XPP-JR for ; Fri, 27 Oct 2017 16:18:29 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 28A1713AF2F for ; Fri, 27 Oct 2017 16:18:28 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 793013741019 for ; Fri, 27 Oct 2017 21:11:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id etDsZOAG-zze for ; Fri, 27 Oct 2017 17:11:20 -0400 (EDT) Received: from maxs-mbp.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 43F89374101D for ; Fri, 27 Oct 2017 17:11:17 -0400 (EDT) To: TLS WG From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <33a450b5-0515-68df-4ed1-f04907bb154c@openca.org> Date: Fri, 27 Oct 2017 15:11:16 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000509040102070001070206" Archived-At: Subject: [TLS] New I-D for OCSP over DNS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 23:18:30 -0000 This is a cryptographically signed message in MIME format. --------------ms000509040102070001070206 Content-Type: multipart/alternative; boundary="------------904816D92A5B8D8C3055BDC2" Content-Language: en-US This is a multi-part message in MIME format. --------------904816D92A5B8D8C3055BDC2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello all, As suggested by some people from other WGs, I just wanted to cross-post=20 this message here since the proposal heavily rely on DNS and can be=20 leveraged in many different environments (e.g., Server and Client=20 (browsers) authentication, document validation, IoT identities, etc.)=20 and we would like to receive feedback from anybody who might be=20 interested in the topic. *Context. *We are currently working on specifying how to use DNS as a=20 transport protocol for revocation information for digital certificates.=20 In particular, we are working on how to leverage the distributed nature=20 of DNS to efficiently (and possibly at a lower operational costs)=20 distribute OCSP (Online Certificate Status Protocol) responses to=20 applications/devices/etc. *Current Status.* We started this work sometime ago but never really had = the time to finish it. Now it seems we can focus more on the topic and=20 would like to discuss this work in a more public venue. We have recently = updated the two competing I-D we submitted sometime ago into the latest=20 reference I-D that is available here: https://datatracker.ietf.org/doc/draft-pala-odin/ Please feel free to contact us for any help (you might require or you=20 might provide), feedback, etc. Thanks, Max --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------904816D92A5B8D8C3055BDC2 Content-Type: multipart/related; boundary="------------AE1B9DF14B971A61E8164E10" --------------AE1B9DF14B971A61E8164E10 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello all,

As suggested by some people from other WGs, I just wanted to cross-post this message here since the proposal heavily rely on DNS and can be leveraged in many different environments (e.g., Server and Client (browsers) authentication, document validation, IoT identities, etc.) and we would like to receive feedback from anybody who might be interested in the topic.

Context. We are currently working on specifying how to use DNS as a transport protocol for revocation information for digital certificates. In particular, we are working on how to leverage the distributed nature of DNS to efficiently (and possibly at a lower operational costs) distribute OCSP (Online Certificate Status Protocol) responses to applications/devices/etc.

Current Status. We started this work sometime ago but never really had the time to finish it. Now it seems we can focus more on the topic and would like to discuss this work in a more public venue. We have recently updated the two competing I-D we submitted sometime ago into the latest reference I-D that is available here:<= /p>

=C2=A0=C2=A0=C2=A0 https:= //datatracker.ietf.org/doc/draft-pala-odin/

Please feel free to contact us for any help (you might require or you might provide), feedback, etc.

Thanks,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------AE1B9DF14B971A61E8164E10 Content-Type: image/png; name="neclidddbhbeiffe.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="neclidddbhbeiffe.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------AE1B9DF14B971A61E8164E10-- --------------904816D92A5B8D8C3055BDC2-- --------------ms000509040102070001070206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEw MjcyMTExMTZaMC8GCSqGSIb3DQEJBDEiBCDqBpidVLtadCSxF/dFo4t10c8fd9OJiCM1LM7f 74kOYjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBABP4ucgpGs8/2QlB JejCa5fREezHOnjXmDdkgjOG79sMjxhKrpelwqs840wFt33Z8kqRvK8jvLyg7uwqSsCKQDH0 9E9cQU4GKSH1amtS29Ukqi/y2xv+/LejPC5C6n7XKuU8c+MtcqPBh9NCwRSpRkJqsPAXGA49 Pae80xKJz5iK7kZo+tqqSCEEJ5RTVsEwRkW7DlGul/aSd983onKSrS0dxlW1etbghvhqKvbJ vN3WPL//GWFf+E3dG6NO4lyDN5SsKn7G+qB7uWfA2mDXGybNneSIhHFyXLsGnQBFoMULmkjK SvoSsIdyZSW+6ASZFqP8Tt9G2Oy8x/vlaI5Zd2AAAAAAAAA= --------------ms000509040102070001070206-- From nobody Sat Oct 28 02:45:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4248613F60A for ; Sat, 28 Oct 2017 02:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 T6JBWj6z4Y0V for ; Sat, 28 Oct 2017 02:45:14 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A8913A214 for ; Sat, 28 Oct 2017 02:45:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 148B3B5305; Sat, 28 Oct 2017 12:45:03 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 78KAXIsFjF1w; Sat, 28 Oct 2017 12:45:02 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 794E6287; Sat, 28 Oct 2017 12:45:00 +0300 (EEST) Date: Sat, 28 Oct 2017 12:45:00 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20171028094459.vqhzrt4woshjesbb@LK-Perkele-VII> References: <20171027053743.b454rtj5qhup2k34@LK-Perkele-VII> <20171027122531.6crnbpy54mbbjswf@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] New header PRs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 09:45:20 -0000 On Fri, Oct 27, 2017 at 06:14:22AM -0700, Eric Rescorla wrote: > On Fri, Oct 27, 2017 at 5:25 AM, Ilari Liusvaara > wrote: > > > Also, on fast transmission, loss burst of ~2000 packets doesn't take > > > > much time. Such loss burst could result, e.g., from transient routing > > > > failure. One might want to discuss how to prevent desyncs from those. > > > > > > > > > > Sure. The answer for this is to use the longer header :) > > > > Might put a note that if one should use longer header if there can be > > more than about 2000 consequtive lost packets. > > " +Note: the DTLSShortCiphertext format does not allow for easy +reconstruction of sequence numbers if ~2000 datagrams in sequence +are lost. Implementations which may encounter this situation +SHOULD use the DTLSDCiphertext format. " I presume s/DTLSDCiphertext/DTLSCiphertext/ as I don't see the definition of "DTLSDCiphertext" anywhere. -Ilari From nobody Sat Oct 28 05:03:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A6B13F3FE for ; Sat, 28 Oct 2017 05:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, 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 9jmzYefwVRlq for ; Sat, 28 Oct 2017 05:03:07 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF0213B408 for ; Sat, 28 Oct 2017 05:03:07 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id EC81822405E for ; Sat, 28 Oct 2017 12:03:03 +0000 (UTC) Received: from [192.168.0.64] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Sat, 28 Oct 2017 14:03:04 +0200 References: <150919169114.2759.558152859745295707.idtracker@ietfa.amsl.com> To: "tls@ietf.org" From: Marco Tiloca X-Forwarded-Message-Id: <150919169114.2759.558152859745295707.idtracker@ietfa.amsl.com> Message-ID: <80b86a97-b145-a77f-715e-189de5e5024e@ri.se> Date: Sat, 28 Oct 2017 14:02:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <150919169114.2759.558152859745295707.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x7In12Ft2wg4holklfC5rHkxCwlKPvLh8" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=02M-m0pO-4AA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=uTM5gQLEAAAA:8 a=gKmFwSsBAAAA:8 a=9fwJlEpZ8Nv3anrwbpQA:9 a=IWKwkP1Q1byq8h0G:21 a=dPmHYuPje44u2cGz:21 a=QEXdDO2ut3YA:10 a=cp3AFWUYeU8A:10 a=mNYzIwZSk3wA:10 a=0kjPXZDHvJTYLN9VHW4A:9 a=8iKuxtZhZIEBJ6YD:21 a=5H0_ofgks1GuoSAu:21 a=6LaQZc35xbrGp-AD:21 a=_W_S_7VecoQA:10 a=q5cmx8AcIeGNkYk5dt8A:9 a=ONNS8QRKHyMA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=X0a8wEfk66sNBbu13Lvv:22 a=nnPW6aIcBuj1ljLj_o6Q:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 12:03:10 -0000 --x7In12Ft2wg4holklfC5rHkxCwlKPvLh8 Content-Type: multipart/mixed; boundary="gTeP0GbfROnUA049ApU77PpJvM242OaiN"; protected-headers="v1" From: Marco Tiloca To: "tls@ietf.org" Message-ID: <80b86a97-b145-a77f-715e-189de5e5024e@ri.se> Subject: Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-01.txt References: <150919169114.2759.558152859745295707.idtracker@ietfa.amsl.com> In-Reply-To: <150919169114.2759.558152859745295707.idtracker@ietfa.amsl.com> --gTeP0GbfROnUA049ApU77PpJvM242OaiN Content-Type: multipart/alternative; boundary="------------69480F87235411E31DCA846E" Content-Language: en-US This is a multi-part message in MIME format. --------------69480F87235411E31DCA846E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, We have just submitted an updated version of draft-tiloca-tls-dos-handsha= ke This revised version especially considers the comments from Eric Rescorla and following discussion [1]. Thanks again, Eric! Comments are very welcome. Best, /Marco [1] https://www.ietf.org/mail-archive/web/tls/current/msg23824.html -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-tls-dos-handshake-01.txt Date: Sat, 28 Oct 2017 04:54:51 -0700 From: internet-drafts@ietf.org To: Maarten Hoeve , Ludwig Seitz , Olaf Bergmann , Marco Tiloca A new version of I-D, draft-tiloca-tls-dos-handshake-01.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-tls-dos-handshake Revision: 01 Title: Extension for protecting (D)TLS handshakes against Denial of Serv= ice Document date: 2017-10-28 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-tiloca-tls-dos= -handshake-01.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-han= dshake/ Htmlized: https://tools.ietf.org/html/draft-tiloca-tls-dos-handshak= e-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-tls-do= s-handshake-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tiloca-tls-dos-= handshake-01 Abstract: This document describes an extension for TLS and DTLS to protect the server from Denial of Service attacks against the handshake protocol, carried out by an on-path adversary. The extension includes a nonce and a Message Authentication Code (MAC) over that nonce, encoded as a Handshake Token that a Trust Anchor entity computes and provides to the client. The server registered at the Trust Anchor verifies the MAC to determine whether continuing or aborting the handshake. = =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------69480F87235411E31DCA846E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,

We have just submitted an updated version of draft-tiloca-tls-dos-handshake

This revised version especially considers the comments from Eric Rescorla and following discussion [1]. Thanks again, Eric!

Comments are very welcome.

Best,
/Marco

[1] https://www.ietf.org/mail-arch= ive/web/tls/current/msg23824.html


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-tls-dos-handshake-01.txt
Dat= e: Sat, 28 Oct 2017 04:54:51 -0700
Fro= m: internet-drafts@ietf.org
To:= Maarten Hoeve <maarten.hoeve@encs.eu>, Ludwig Seitz <ludwig.seitz@ri.se>, Olaf Bergmann <bergmann@tzi.org>, Marco Tiloca <marco.tiloca@ri.se> 


A new version of I-D, draft-tiloca-tls-dos-handshake-01.txt
has been successfully submitted by Marco Tiloca and posted to the
IETF repository.

Name:		draft-tiloca-tls-dos-handshake
Revision:	01
Title:		Extension for protecting (D)TLS handshakes against Denial of Serv=
ice
Document date:	2017-10-28
Group:		Individual Submission
Pages:		14
URL:            https://www=
=2Eietf.org/internet-drafts/draft-tiloca-tls-dos-handshake-01.txt
Status:         https://datatracker.i=
etf.org/doc/draft-tiloca-tls-dos-handshake/
Htmlized:       https://tools.ietf.org/h=
tml/draft-tiloca-tls-dos-handshake-01
Htmlized:       https://datatr=
acker.ietf.org/doc/html/draft-tiloca-tls-dos-handshake-01
Diff:           https://www.ietf=
=2Eorg/rfcdiff?url2=3Ddraft-tiloca-tls-dos-handshake-01

Abstract:
   This document describes an extension for TLS and DTLS to protect the
   server from Denial of Service attacks against the handshake protocol,
   carried out by an on-path adversary.  The extension includes a nonce
   and a Message Authentication Code (MAC) over that nonce, encoded as a
   Handshake Token that a Trust Anchor entity computes and provides to
   the client.  The server registered at the Trust Anchor verifies the
   MAC to determine whether continuing or aborting the handshake.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------69480F87235411E31DCA846E-- --gTeP0GbfROnUA049ApU77PpJvM242OaiN-- --x7In12Ft2wg4holklfC5rHkxCwlKPvLh8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ9HHrAAoJEO4mZLQOWNpDDjkH/iKAZynJ2FVb6zthIVdt3kLO 4hCMX+KpXxCkP9xXeEa2vLSHn6CvYwyJduzOpJvAp9kvhorDqd2pdi+ehdLOsQ9m K74NNW+gbkoVjGJRzhhOcmjSgWe2/3Daj712PT3BA59tIdctzwTVOXKX3N7ptdJS m5iInR7Saa/A+ooa7stW8qz0nhzftRp3K4Yk7plW6J3+Rge/7A7KAavcbTUeuGcK 7yvjVnOYIJvAZ6kqSGJYVt4xV6/6YYFvNreP8c7sBBY4QZglpHeXKpIgjbaejPB1 BTvF4evvl5qm9AG+ojuFFjCP4gOoFgfnd4yGtmkPIaMjlegnynGxOLPK6vHJBcI= =OMZu -----END PGP SIGNATURE----- --x7In12Ft2wg4holklfC5rHkxCwlKPvLh8-- From nobody Sun Oct 29 14:42:15 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 240F213F418; Sun, 29 Oct 2017 14:42:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150931332609.11223.826367524172956971@ietfa.amsl.com> Date: Sun, 29 Oct 2017 14:42:06 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 21:42:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename : draft-ietf-tls-dtls13-02.txt Pages : 41 Date : 2017-10-29 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls13-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 29 20:10:51 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55FF13FD75 for ; Sun, 29 Oct 2017 20:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 RGYPxmKd5vbE for ; Sun, 29 Oct 2017 20:10:48 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B551E13FB8C for ; Sun, 29 Oct 2017 20:10:48 -0700 (PDT) Received: from [169.254.80.112] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9U39JRu099799 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 Oct 2017 20:09:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.80.112] From: "Paul Hoffman" To: "Richard Barnes" Cc: "Stephen Farrell" , tls@ietf.org Date: Sun, 29 Oct 2017 20:10:41 -0700 Message-ID: In-Reply-To: References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 03:10:50 -0000 On 25 Oct 2017, at 15:37, Richard Barnes wrote: > Sorry, what? The current draft proposes an extension, literally the > opposite of a standard, supported feature. I agree with Stephen on this (narrow) point. The draft is on Standards Track, which means is proposes a standard. The fact that it is an "extension" is irrelevant in TLS: lots of things that are part of the standard; see Section 4.2 draft-ietf-tls-tls13. > It's explicitly optional. I can find nothing in the draft that says that. > I don't really have a dog in this fight, but let's please be accurate. Agree on both counts. --Paul Hoffman From nobody Sun Oct 29 22:40:27 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CD11394F2; Sun, 29 Oct 2017 22:40:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150934202123.3511.15961087841948193593@ietfa.amsl.com> Date: Sun, 29 Oct 2017 22:40:21 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dnssec-chain-extension-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 05:40:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : A DANE Record and DNSSEC Authentication Chain Extension for TLS Authors : Melinda Shore Richard Barnes Shumon Huque Willem Toorop Filename : draft-ietf-tls-dnssec-chain-extension-05.txt Pages : 23 Date : 2017-10-29 Abstract: This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dnssec-chain-extension-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 00:07:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D393C13FE09 for ; Mon, 30 Oct 2017 00:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqCcuPgqLlgY for ; Mon, 30 Oct 2017 00:07:43 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 B83C413FE0E for ; Mon, 30 Oct 2017 00:07:43 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id v9so20336445oif.13 for ; Mon, 30 Oct 2017 00:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=AbnoLV7XMKuGX5yH1fMAVQElKa4zCLJxCwLpLWwEldM=; b=ludJxvUmm4/tLmL81hzl+7YYT9JageYW4EdGtY9H9W/LoltWovlz0PPEnSnQONLjc9 C6agfg180slGZMw/9ZSKdKv1655144SurgkE71D4AuLHlFhOHO2tT8Jvom6qHypBy5MM 7zugnDEB0H8t6J9iWjQtTLeVeDpCh6ZuB6Z/MFF5gHzuXNQSM5OrDrsqjoWXrlhqLtYZ HVzOE/OH6rMOAEVYuvke8dEUWeD53S0sll/BJoE5dWWqupQq0lVRLDqvSSaokxXMcY9t V9Zf2mPohE70BYo02Y+sim/mVfZPh6fAPEwZXAwD3V5VPk9eGR00PrsnJ8lK0nMRrKwJ wNrg== 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 :content-transfer-encoding; bh=AbnoLV7XMKuGX5yH1fMAVQElKa4zCLJxCwLpLWwEldM=; b=kCE+aqkngVrTuSqiVy4Ebg0iWwJSFAB0KILsvA5mRMvn9hzPTLpzNdSpI2fTPCEgVb YiO5YoJ0vWMgMi0U5/R3avXuty2Q7t7AjDcFBUZ7faiPN0PdtNYpf6oqkZYhFuhq4DqY 91c/k9X73NZTzLoDUnmWj211dMjVeQcV/bw4g8V5uzw3XTCogxPMCAErqmEs9QpxlA4G Ks/4Ki6PtytmzMW8Wx7MfISKn7QXnSDi9saeUPXM8LyMQ22/xNefwQaoBbslh2W0wuqr Nxes85KLdogpOIaVm2MTYKBUuI/Wy6qcEHQKx+6ojzxEayV2DVBuTzR5mIsyrl/s3vVv OMXw== X-Gm-Message-State: AMCzsaWFOqmjvlk0msHNzXATK/nKbIEjvx7T+Hp6a5h8AmhgEa0a7TGk vyL9rgrtroR73GINsnaTShkPX5OMM6GccuzZhZA0vA== X-Google-Smtp-Source: ABhQp+SZ48OXdxytsgw0OXO9bR6Pn8fTww8PAFUQDI+diH7Nv+t2wKHwRWeVv6v5Wr3N5cdmUoRpVsy1GnJat/dhRi8= X-Received: by 10.157.66.227 with SMTP id c32mr5291189otj.273.1509347262880; Mon, 30 Oct 2017 00:07:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.88.141 with HTTP; Mon, 30 Oct 2017 00:07:42 -0700 (PDT) From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Mon, 30 Oct 2017 09:07:42 +0200 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Cookie reuse subsequent connections X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 07:07:45 -0000 Hi, is there ANY security issue with reusing Cookie from previous TLS connection? In current draft there is text: "Clients MUST NOT use cookies in their initial ClientHello in subsequent connections." I can't think of any security implication, but can think of situations where it could be useful. --=20 Ar cie=C5=86u, J=C4=81nis =C4=8Coders From nobody Mon Oct 30 00:10:33 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D67B813F680; Mon, 30 Oct 2017 00:10:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150934743183.3426.7899967473958319655@ietfa.amsl.com> Date: Mon, 30 Oct 2017 00:10:31 -0700 Archived-At: Subject: [TLS] I-D Action: draft-rescorla-tls-subcerts-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 07:10:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Delegated Credentials for TLS Authors : Richard Barnes Subodh Iyengar Nick Sullivan Eric Rescorla Filename : draft-rescorla-tls-subcerts-02.txt Pages : 11 Date : 2017-10-30 Abstract: The organizational separation between the operator of a TLS server and the certificate authority that provides it credentials can cause problems, for example when it comes to reducing the lifetime of certificates or supporting new cryptographic algorithms. This document describes a mechanism to allow TLS server operators to create their own credential delegations without breaking compatibility with clients that do not support this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rescorla-tls-subcerts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-rescorla-tls-subcerts-02 https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-rescorla-tls-subcerts-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 02:31:52 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB0313F95E for ; Mon, 30 Oct 2017 02:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH5v9Ilo9zdx for ; Mon, 30 Oct 2017 02:31:49 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B1913F8EF for ; Mon, 30 Oct 2017 02:31:47 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id v9so20825900oif.13 for ; Mon, 30 Oct 2017 02:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6KmbYPNUcoHQANib+LifSQPnNMse3VjR6gBu2S0ynKE=; b=j4YuOgSpL31Lo47Y/NgmMWWamLZq8lfsigOK3oPEB488fQCFac2eDxH7ebYLXK+F4r Phhz0BKGuuPDwu9OMWW4YYMp/eElFv1wIUZX0Xz9U+9l4BdYVXyKfE9cFyNjtmFmT3k7 3jFPYa7elMjMnABd0VWG5IVfx0+TF/XzHO6jj5UMmqVXFFyuGZcjZqRRvEDZGztEdF74 lFzNoS2Jf092ipv5BODlQ9Ae9CBjiXyQD8yaG1g3BpYeIlMtEphk1TeQhYSO3RfVrOOq hv1wCyQhxLuoq/+1ObhYtl53+R2hbgeSp/cHcf0vl0+eufutVARMV22hOtvJ2OeoizMS bJbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6KmbYPNUcoHQANib+LifSQPnNMse3VjR6gBu2S0ynKE=; b=DVGGDq8DTHiZ0RaNpWg3wFdAnZWUX4MACOTJICYVhngvQNjYddgGPbR0VIOsrPeZ97 NGXHVEEcmAxecrTgzAKFjA0Yh5ps5zh4CRZHe+3lcRb1sBcTki08qQ5yomKnw/HQGngj LDxy50igAJdZJZPYXMzOGx8zsr8I6i6Hgjobdm50mIAJgnwoY90bsFozZf3808UJGt9l AO3SMtUKApcMju7QORPmjCc9BTmZrh7xmfcoYW0Aml9EIRTRqfwQslRau4miHsPDTGFu gfvEBuNCCJ14XyCqcuumEVlZZp4WW5PKw6v2K/6Ikm+y+jXIsP1OFnZuE7LNG4DW7zsK 8Nmg== X-Gm-Message-State: AMCzsaXbLcvkppw5eWnmgW9JBCYU6JEIPNmmIL6bKhuSUSHwcfH1ps4g 3yVb9pC+OaDY2TgFvs2fTtTL9hZh5wpSXzrlPafvHw== X-Google-Smtp-Source: ABhQp+SNM46qQlPMXBdHuQmwJVlbGoLkX1wZ9aimkUqh3jg0WzbmPCJ/Y9HtVv2buj1PvYT+6GyD6CaTcKZK7MFXkAE= X-Received: by 10.157.91.61 with SMTP id x58mr5527273oth.89.1509355906796; Mon, 30 Oct 2017 02:31:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 30 Oct 2017 02:31:46 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 30 Oct 2017 20:31:46 +1100 Message-ID: To: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Cookie reuse subsequent connections X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 09:31:51 -0000 What is most likely to happen is that the cookie will be invalid and the connection will be rejected. Many TLS servers assume that presence of a cookie means that they previously sent a HelloRetryRequest on that connection. For instance, NSS packs a hash of the original ClientHello into the cookie so that it can restore the handshake transcript. Reusing the cookie will just lead to the server restoring the handshake transcript from the wrong handshake. And that's even assuming that it accepts the cookie in the first place. On Mon, Oct 30, 2017 at 6:07 PM, J=C4=81nis =C4=8Coders wrote: > Hi, is there ANY security issue with reusing Cookie from previous TLS > connection? In current draft there is text: "Clients MUST NOT use > cookies in their initial ClientHello in subsequent connections." I > can't think of any security implication, but can think of situations > where it could be useful. > > -- > Ar cie=C5=86u, > J=C4=81nis =C4=8Coders > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Oct 30 02:52:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9CB13B133 for ; Mon, 30 Oct 2017 02:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjjV1AG3xMJv for ; Mon, 30 Oct 2017 02:51:57 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE3E13F85D for ; Mon, 30 Oct 2017 02:51:57 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id m198so20941598oig.5 for ; Mon, 30 Oct 2017 02:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=H7OMxUEwa0kV2fzPC2od5oMAYN7970zvk2G/QfB6H5Y=; b=dHNArVrAe2ZsHUIe+f2OUqtiPdbmBzQXLMHlMid5lrhad//VDw4zzCxs5dZydQjU/U 0B9DXPIaUNbUnLErBsrB33EQ7NuDZnGGTQ4M5K2+Ax8jK3hIW18Uk+TTwXAI07oj97rj f6+eUvKw4wTrCRN2vL1xfT1y2u2yPQpUgSwSpu7ra5JL73+0oCfMCs5CfRXFl8dPa1wI tfQ/zUzKdEG/7B8r1YodID9xdO6s7H6s+Rew6wnFvFsQme+5eTiSdSFwU4Dr6Qr+QTeD XJFBI/iZVebLoQ++gRPrUW9URzOrtElL7e3bwtRtU9QlxOTOJhkiCF/MFJR2kDBUdzhO 3rTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=H7OMxUEwa0kV2fzPC2od5oMAYN7970zvk2G/QfB6H5Y=; b=o4sKjRbRsQZTMKOQa8HzJ29Nmy35Oiq+ee0mI+F0PzkBJJ5r19icYOVEBxnBNavvNR jm30kEpOKSvGd11aPRF81uTkFiAfvPfEDt+jvJ5VANjWzDntshRHOdPeZ/ocakAUSGSr ZnpTqmDPzsalLrz4JhLgUe6okL666IaHmF63xmtYin044f4uYn+lwN4dD9YaKickVBF9 hXftujj+IAlBx8f8UhMhdtDyPDSRobW1l+C9x870q5bxW3RhEv3g/sRcusWKZPyXktqM JlYs1P6TM0x2t6QwW2PpdvdRMj5WQex4hGs+ZBt8d3aej2ay/7Z2daY6KmjBs3oHYJIc Sd4g== X-Gm-Message-State: AMCzsaU4T24m6pJghKckP9LzkdeQIJrlx8JJWgrfj+6Az0Ihueich90A AU5jAJxBa66CrmDcdzQFtvI+hExl8SnR/tvvA+g= X-Google-Smtp-Source: ABhQp+Q6XsD8dv0XG88VkXLwDyQEgD0J9+JjUMx9QH1YX5yELLSyxPb1zUPkUbqFx05IN2C/4SjP27K2R47q1ss2rT4= X-Received: by 10.157.41.206 with SMTP id g14mr4534628otd.42.1509357116956; Mon, 30 Oct 2017 02:51:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.88.141 with HTTP; Mon, 30 Oct 2017 02:51:56 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Mon, 30 Oct 2017 11:51:56 +0200 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Cookie reuse subsequent connections X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 09:51:59 -0000 Thank you. Ok, I understand that some servers could not allow reuse of cookie, but why is it FORBIDDEN by standard? It could be suggested to not reuse in general cases, but if I wanted to use TLS 1.3 with my custom server, which uses cookies to only prevent spoofing attacks (in UDP (DTLS) case). And clients know that they can reuse previous cookies for fast handshake, then why would it be prohibited? On 30 October 2017 at 11:31, Martin Thomson wrot= e: > What is most likely to happen is that the cookie will be invalid and > the connection will be rejected. > > Many TLS servers assume that presence of a cookie means that they > previously sent a HelloRetryRequest on that connection. For instance, > NSS packs a hash of the original ClientHello into the cookie so that > it can restore the handshake transcript. Reusing the cookie will just > lead to the server restoring the handshake transcript from the wrong > handshake. And that's even assuming that it accepts the cookie in the > first place. > > On Mon, Oct 30, 2017 at 6:07 PM, J=C4=81nis =C4=8Coders wrote: >> Hi, is there ANY security issue with reusing Cookie from previous TLS >> connection? In current draft there is text: "Clients MUST NOT use >> cookies in their initial ClientHello in subsequent connections." I >> can't think of any security implication, but can think of situations >> where it could be useful. >> >> -- >> Ar cie=C5=86u, >> J=C4=81nis =C4=8Coders >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls --=20 Ar cie=C5=86u, J=C4=81nis =C4=8Coders From nobody Mon Oct 30 04:21:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FBB13F8D3 for ; Mon, 30 Oct 2017 04:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, 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 oM4SXjkS14wk for ; Mon, 30 Oct 2017 04:21:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B72913F717 for ; Mon, 30 Oct 2017 04:21:16 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 322536A7CC; Mon, 30 Oct 2017 11:10:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 322536A7CC Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (ovpn-200-18.brq.redhat.com [10.40.200.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E1B17D1B7E; Mon, 30 Oct 2017 11:10:47 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 30 Oct 2017 12:10:44 +0100 Message-ID: <150941212.DozKjUoLUJ@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13129913.bLXXLhTknM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 30 Oct 2017 11:10:48 +0000 (UTC) Archived-At: Subject: Re: [TLS] TLS 1.3 Record Boundaries X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 11:21:19 -0000 --nextPart13129913.bLXXLhTknM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 24 October 2017 02:42:01 CET Andrei Popov wrote: > Draft-21 says: > "Handshake messages MUST NOT span key changes. Implementations > MUST verify that all messages immediately preceding a key change > align with a record boundary; if not, then they MUST terminate the > connection with an "unexpected_message" alert. Because the > ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate > messages can immediately precede a key change, implementations > MUST send these messages in alignment with a record boundary." >=20 > It is not clear to me what "sending messages in alignment with a record > boundary" means.=20 Reminder: a single record layer message can include multiple handshake=20 messages. In particular, it can include only a part of a single message=20 (beginning, middle or end). To answer the question: it means that the last record message with handshak= e=20 message content must have included the end part of that handshake message a= nd=20 first byte of a "key change" message needs to be the first byte of a record= =20 message. Note that this is a change from TLS1.2 where for renegotiation, the=20 application data could continue to be transmitted during the handshake and = be=20 interspaced with handshake messages, and the handshake messages could be=20 fragmented. > Does it mean that each record is either all plaintext or > all encrypted with key X? > > And therefore one cannot combine, e.g., > ServerHello (plaintext) and EncryptedExtensions (encrypted with the > handshake traffic key) messages in one record? given that it's the record layer that is encryped, not the handshake messag= e,=20 I'm not sure how would you put an unencrypted and encrypted handshake messa= ge=20 into a single record... =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart13129913.bLXXLhTknM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZ9wi0AAoJEJKo0bgB0vX1yL4P/1L6fKGISDPH4PG/TlGm6gb7 MfmExpClJGknDU0RGkU3G6QRsMIdzSHonzmOYn1ltEzpm0kq4d/vOD626/MVdqpk X1l4rv82AqIn4ZT+ZsLyZikJGLgPOPaboKHGKxu2VJbjF3oPR6Q0ZLB3rENxGRXc smQg744heIERRRVJonXv607iWN/NjxXN30IuvsqrYT1IA4gfNkcwY3wLPOUEB2CK M84J2yx2wGTK63vOeS2QV79DwZhJc6ri42i7gN+7ZSlD+SSvIt3dHAbHAYB5XOPl lINU0wzOX1h8MMav/5qm/VHOEQqtWdHENB1zzisUvHGSVs8FNrzwZWHGq7WlNPOL Io9eEEmjHJ0oCKoqMlA+0Gahy6ZhdefOw2A+RWP1tiXRjGKmqOC9L71PgNo6rBMR Xl0cYLEgoULwKsHhqIz6T2oEYkCokpulCxJ6mtYuXPabVOQ1SaIBsuOXdUoQpwzp QNZkKpKUyObCCq8kUsreFGOk/bQoPO6X/pW6jS+ivhJTFEMYyxAZeo6pSyaxqx1Q kykLfzJrzXvhjXHzsi0fJKPsc9RpIZoE5dyE2wO9AbmjKSzTkwNL3omgy4qCGPtj Mg0EGP1JoVPvMO70qRKjSA9cs8+yG8tcwhcirK6M3aejmz2UuywnQZTe71j4NGm6 pmHmhyP5ZcFCG9JyHdNu =XscM -----END PGP SIGNATURE----- --nextPart13129913.bLXXLhTknM-- From nobody Mon Oct 30 04:42:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6680013F660 for ; Mon, 30 Oct 2017 04:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6COe4Uhg1hVK for ; Mon, 30 Oct 2017 04:42:21 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC691397F9 for ; Mon, 30 Oct 2017 04:42:21 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id j4so11242894ywb.2 for ; Mon, 30 Oct 2017 04:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9XUMi3aTI6Irg5kN73kjLpX3CPDj7bxASVAq1uO59RA=; b=ZTF/5wEcLgPB7k3NyWVof7xi7hynPW6n4Kqx8vqhcW6isJo4j9r8eoRb4yVhru0rw6 Cwb/bS0YDQrlgrvI6edAgqB61/iTgGZqbXIIshFH2/OuXfHhJka79CWEn5NGRPaRUxaX l7V5Yk2950/4z5GiHpSpqCHotyqC8SYr2XpILTF6+vovm2QOYG48KmYHUDWxEl9FY7dF QcAj2Cy5XThWIj/gCI1j4s/jtlofPoRFAZex+8/a1hz0LFSIQRfkdo4Hl88ISuvaYHgl kYFWAUT2EuWSyBCAtqOWxFj+pyp/hEnG3SfNgf7m9sUSS+JhwjYY53DZZhoRsxPfePz1 gSZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9XUMi3aTI6Irg5kN73kjLpX3CPDj7bxASVAq1uO59RA=; b=AoLc1QdVM4iCTWIOuxz4pdQ3QVdghkmpjBGbWkMhEVHrMERcqalSLl4w9KuYkatZMu 5szQMOreOIStmUcOr6EinZgnf9+GpX3L3XXj91IA78lnHIvnNqRHRgkL0gujLaunJWDj Bb/FODwwRGBd8IeaACTBFjHEsB7PGvAyvqJw8qfiE5AYu0mZwv6J4rexeqVFdCv5pWvT Zm00lU9TGrZwt4e9ar6XB9j3RqLlgTYDhUUwvfPyjfRKkX8RVExEyJ9bP/H9D2fM8bWx XoXRng1XEVs3jIoHORvFlVCPNj/sz0JPBRag/6Ff3RVxSbZlfeYjcJ/sQXiHV3vi7Ew/ 1tyg== X-Gm-Message-State: AMCzsaUMMJ702krMiyEWPqfG0r9Jlb0Rc3eqknYWnSN/Wq3EL9Bqzrup VyaGLhI7/1o3WE9qNPqBipZYGQ136MTESmcgcTqiyg== X-Google-Smtp-Source: ABhQp+RBAFHI2xdpq/ug61D8nhcEcMd33g7ZGtFoFPv51GmxYIQippaDsPWmFJ6DPcy96Aroqs7RPZykP0mUXdSAEog= X-Received: by 10.37.44.141 with SMTP id s135mr5379392ybs.400.1509363740556; Mon, 30 Oct 2017 04:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 30 Oct 2017 04:41:39 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 30 Oct 2017 04:41:39 -0700 Message-ID: To: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Cc: Martin Thomson , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11431c6497f06f055cc22175" Archived-At: Subject: Re: [TLS] Cookie reuse subsequent connections X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 11:42:23 -0000 --001a11431c6497f06f055cc22175 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's a privacy leak. -Ekr On Mon, Oct 30, 2017 at 2:51 AM, J=C4=81nis =C4=8Coders wrote: > Thank you. Ok, I understand that some servers could not allow reuse of > cookie, but why is it FORBIDDEN by standard? It could be suggested to > not reuse in general cases, but if I wanted to use TLS 1.3 with my > custom server, which uses cookies to only prevent spoofing attacks (in > UDP (DTLS) case). And clients know that they can reuse previous > cookies for fast handshake, then why would it be prohibited? > > On 30 October 2017 at 11:31, Martin Thomson > wrote: > > What is most likely to happen is that the cookie will be invalid and > > the connection will be rejected. > > > > Many TLS servers assume that presence of a cookie means that they > > previously sent a HelloRetryRequest on that connection. For instance, > > NSS packs a hash of the original ClientHello into the cookie so that > > it can restore the handshake transcript. Reusing the cookie will just > > lead to the server restoring the handshake transcript from the wrong > > handshake. And that's even assuming that it accepts the cookie in the > > first place. > > > > On Mon, Oct 30, 2017 at 6:07 PM, J=C4=81nis =C4=8Coders > wrote: > >> Hi, is there ANY security issue with reusing Cookie from previous TLS > >> connection? In current draft there is text: "Clients MUST NOT use > >> cookies in their initial ClientHello in subsequent connections." I > >> can't think of any security implication, but can think of situations > >> where it could be useful. > >> > >> -- > >> Ar cie=C5=86u, > >> J=C4=81nis =C4=8Coders > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > -- > Ar cie=C5=86u, > J=C4=81nis =C4=8Coders > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11431c6497f06f055cc22175 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's a privacy leak.

-Ekr


On Mon, Oct = 30, 2017 at 2:51 AM, J=C4=81nis =C4=8Coders <janis.coders@gmail.com= > wrote:
Thank you. Ok, I u= nderstand that some servers could not allow reuse of
cookie, but why is it FORBIDDEN by standard? It could be suggested to
not reuse in general cases, but if I wanted to use TLS 1.3 with my
custom server, which uses cookies to only prevent spoofing attacks (in
UDP (DTLS) case). And clients know that they can reuse previous
cookies for fast handshake, then why would it be prohibited?

On 30 October 2017 at 11:31, Martin Thomson <martin.thomson@gmail.com> wrote:
> What is most likely to happen is that the cookie will be invalid and > the connection will be rejected.
>
> Many TLS servers assume that presence of a cookie means that they
> previously sent a HelloRetryRequest on that connection.=C2=A0 For inst= ance,
> NSS packs a hash of the original ClientHello into the cookie so that > it can restore the handshake transcript.=C2=A0 Reusing the cookie will= just
> lead to the server restoring the handshake transcript from the wrong > handshake.=C2=A0 And that's even assuming that it accepts the cook= ie in the
> first place.
>
> On Mon, Oct 30, 2017 at 6:07 PM, J=C4=81nis =C4=8Coders <janis.coders@gmail.com> wrote:
>> Hi, is there ANY security issue with reusing Cookie from previous = TLS
>> connection? In current draft there is text: "Clients MUST NOT= use
>> cookies in their initial ClientHello in subsequent connections.&qu= ot; I
>> can't think of any security implication, but can think of situ= ations
>> where it could be useful.
>>
>> --
>> Ar cie=C5=86u,
>> J=C4=81nis =C4=8Coders
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls=



--
Ar cie=C5=86u,
J=C4=81nis =C4=8Coders

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a11431c6497f06f055cc22175-- From nobody Mon Oct 30 06:30:51 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA19813F665 for ; Mon, 30 Oct 2017 06:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 yuUx9z4_FdGf for ; Mon, 30 Oct 2017 06:30:49 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 7BD7813F89F for ; Mon, 30 Oct 2017 06:30:49 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id v41so16278295qtv.12 for ; Mon, 30 Oct 2017 06:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=VOCYkdJHYm1hgRTo/+RTxpzUeJVNE+UWKM75av5qxdI=; b=eOdHj1KFdXaV6irR9LARih3JYYd9OAoO7Q2BkaItDh6zDQ3Ftug8QZw3Su32fpJE5H dSUa5k1rvKXhAA/4IIiGdYqKXginBvp3OlZXiw/nIpi+1IjVkB+TMJygdlxm9fnkgjea DRk/HbUj3J6a5RsoodZ+/62cvZ6EPTwqmi4/4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=VOCYkdJHYm1hgRTo/+RTxpzUeJVNE+UWKM75av5qxdI=; b=WzO1+A7CWym5hjFx26Wxl+E/JuUL5nmxWvtLX7m/IlauWDev8UUiF3XykimTM72jrL u1Nk6ZhPBiObw9VpTVsXWmUeWyYiaRt0h/2v0tJs/WZ1SD9FWJ+ziKbhj5Ew5bPhZ9M2 fYQdUxe3lyahPAki7I+EoJ3TWohvU+Jwy8QPLqGNvdUv7pPXtlNRYsiS0sr+acMBuMjQ zbNHH9Aw/0rYtZyEwhSGd5xvtt/Hq1OoOKMd5qSzbhweZxRq6JFBnklYTCps5J39yThz UMYqRKC0POlP1INbhYDLpp+BKJfhtPQ7pzU7Lq38Uv8VfboYdRCMA5dddz0D0G9/5mnF CFSw== X-Gm-Message-State: AMCzsaU4LskvI5iFUeAHBjb1LBBgPp5tQIh1XeJhTuLhoo/Zvv4AWXHL qnkXwibkqyJgvRhJknpWDZRYWOzsmKaEAw== X-Google-Smtp-Source: ABhQp+QZr5NQuCB/hvEWLmbw18JKtsciz+4g4YQY9i3X0tmYuYaTqdP3F+oUXZmzqRbGO3ca3CZCJw== X-Received: by 10.200.50.193 with SMTP id a1mr13840234qtb.94.1509370243529; Mon, 30 Oct 2017 06:30:43 -0700 (PDT) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id z3sm9294686qkc.17.2017.10.30.06.30.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 06:30:42 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 30 Oct 2017 09:30:41 -0400 References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> To: "" In-Reply-To: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:30:51 -0000 This is just a reminder to get those requests in. spt > On Oct 24, 2017, at 12:32, Sean Turner wrote: >=20 > All, >=20 > You will have seen that the chairs requested two sessions for IETF 100 = TLS (on 20170929) and you will have also seen the that our request was = granted (on 20171020). The sessions are currently scheduled as follows: >=20 > tls Session 1 (2:30:00) > Thursday, Morning Session I 0930-1200 > Room Name: Canning size: 250 > --------------------------------------------- > tls Session 2 (1:00:00) > Monday, Afternoon Session III 1740-1840 > Room Name: Padang size: 300 > --------------------------------------------- >=20 > We would like to get a sense of who wants to request agenda time so = please send in your requests by 20171029; this will give the chairs time = to upload a draft agenda due on 20171030. Along with your request = please let us know how long you would like. >=20 > NOTE: Those that have already submitted requests need not do so again. >=20 > J&S From nobody Mon Oct 30 06:52:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E6513F9D8 for ; Mon, 30 Oct 2017 06:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MQRa65DFIZ2a for ; Mon, 30 Oct 2017 06:52:25 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86DB513F9FC for ; Mon, 30 Oct 2017 06:52:25 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9UDkiwI016245; Mon, 30 Oct 2017 13:52:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=alYdS2h6vY3h95yJ9Z5Mxo67VDtzE1SidLTu0bn1i0U=; b=U1ZrG8hrBLSd00gLQAtflgpRug17D6CZpIRhm9XIe7c6ykRDHWei/9XZGVXWwRARqHvH oAuSok5XluiCjcih5xeZ/8QTvrrxTyP0K1BI34EhUmGG8XHUUVJLHt4Nfhq2nSY+3ryd nB3I0IhKAYKelwaYB/SD3QQfHh4qC2xpHXhUDNAWw3Aq1VsUabngnuUs1ks0WyI1ADlT 87Ewc1Ya6Sh2Vj38CSxTJFvFsiC00kI6VzDhgmlw/yY6S3RL0Xzhr5FMdKvYMEQqUNjA Try/9Siml1bGmDEPWiz9V75OG7dhdadjjrWo1DyImiqdxTjO8o5nS+wLYRAashqzI7kv tw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2dvmnt6wqj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 13:52:24 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9UDow30029100; Mon, 30 Oct 2017 09:52:23 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2dvn7vx314-1; Mon, 30 Oct 2017 09:52:23 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id E45A38005C; Mon, 30 Oct 2017 07:52:22 -0600 (MDT) To: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Cc: "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: Date: Mon, 30 Oct 2017 08:52:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710300189 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710300188 Archived-At: Subject: Re: [TLS] Cookie reuse subsequent connections X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:52:27 -0000 On 10/30/2017 04:51 AM, JÄnis ÄŒoders wrote: > Thank you. Ok, I understand that some servers could not allow reuse of > cookie, but why is it FORBIDDEN by standard? It could be suggested to > not reuse in general cases, but if I wanted to use TLS 1.3 with my > custom server, which uses cookies to only prevent spoofing attacks (in > UDP (DTLS) case). And clients know that they can reuse previous > cookies for fast handshake, then why would it be prohibited? > > The standard must ensure that compliant clients interoperate with compliant servers.  Compliant servers are permitted (expected, even, for DTLS!) to offload state such as the handshake hash into the cookie.  A client that reused a cookie from an old connection on a new connection to such a server would fail to interoperate, as the server would use the wrong handshake transcript.  Ergo, the spec strictly forbids clients from implementing this behavior in order to preserve interoperability. There is "nothing" to stop some actor from deploying a noncompliant implementation on their own private network where interoperability with compliant implementations is not needed, but of course then that actor must take responsibility for any changes to the security and privacy properties as a result of those noncompliant modifications. In this case, for example, the routability proof embedded in the cookie could become stale with time (in case of readdressing), and the repeated cookie provides linkability between ClientHellos from the same client (to an adversary observing at some point in the middle of the network), for a start.  No one could guarantee that there are not more changes to the security and privacy properties than those already listed, of course. -Ben From nobody Mon Oct 30 07:00:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AF513F9D8 for ; Mon, 30 Oct 2017 07:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZQy3NOJ9L4b for ; Mon, 30 Oct 2017 07:00:43 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26AC13F950 for ; Mon, 30 Oct 2017 07:00:42 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id v132so22101582oie.1 for ; Mon, 30 Oct 2017 07:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lQq7tClrPr5NbEcmX/qUoL+aEr7NYLNgQlyX3hvmLa8=; b=Lh4pB70paSNlCBeiviYSsqICXIFtzqCTvpVuzQ5MkQru0+STOyvbdXP8S7rvS/ysH0 iNZkofbS5FPmz43klwQ3i7I7b1fxMoctqlvoiZXRHOWFJZtQm4I38O/yQZcQKRkRPoPH eePNjFt1nLt6NoXNw3CeNBm/Ibz3jKmSd4GvsHUtvL3TPH1y/m5/yOiVI9S6w/9x/Xw+ 20mixCxAwFefbO/mVm8mPZILM4b3pLiP7YbGHIF8Bd+ile0EKrgXF1zsDQFk5CWZxwDE UccTE/kKnmxIF5IqBzxRTH+2wsUedB1bRqk5ReOl4NHs9Qw7CISX0hNPd0VbSZZomkBO jeKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lQq7tClrPr5NbEcmX/qUoL+aEr7NYLNgQlyX3hvmLa8=; b=mNxkILK90J7mUbkdsaHJK9N8MzxqQPQPq29spA6U2Y5c3n+cDPtL3fO6vZmwIEMgVQ ejH4ErrU8ervhV64i0oq6MxnTvXyAo6gwqQiVYlTxj0hcRA4NTeCd2VOW1FA81ASd3g3 ivPcIKkhPLBW7OrWHrcJnbm4ic/4AqMyXYh8i/Ng6zUe62CE44tQBR4Gm9i2EawYluNJ cuGJ6DBJr/LLSW2uSTd7f9yCAIh2UnLfdZ/KZ9f64W8vpftS7o7eJAud0s5Qp0hse3/w eg+iK6+0fvLL1yZOkWRDe/OWJ59ROpmFfTIY8D6vCsfVmlJU9k0+N131sm95/rM+8vMQ 2gBQ== X-Gm-Message-State: AMCzsaW/1Un/2ylXojykljx00/Jds6wMaENwadGFM0HGOPSjrYl2+uy3 B/XxR/DIceei0KjzCUZYMWeb5W4uG9QdOW4ey5GTuQ== X-Google-Smtp-Source: ABhQp+S+CDTzxVHpOhjDfaImy8fulTKMsAScVnuvlF+w7KxeRt992QikR0V+dT5UnxDpj6GXMlLVE91WI5FBvHWxLbQ= X-Received: by 10.202.166.15 with SMTP id p15mr4699681oie.51.1509372040300; Mon, 30 Oct 2017 07:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.88.141 with HTTP; Mon, 30 Oct 2017 07:00:39 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Mon, 30 Oct 2017 16:00:39 +0200 Message-ID: To: Benjamin Kaduk Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Cookie reuse subsequent connections X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:00:45 -0000 Thank you all for you answers. On 30 October 2017 at 15:52, Benjamin Kaduk wrote: > On 10/30/2017 04:51 AM, J=C4=81nis =C4=8Coders wrote: >> Thank you. Ok, I understand that some servers could not allow reuse of >> cookie, but why is it FORBIDDEN by standard? It could be suggested to >> not reuse in general cases, but if I wanted to use TLS 1.3 with my >> custom server, which uses cookies to only prevent spoofing attacks (in >> UDP (DTLS) case). And clients know that they can reuse previous >> cookies for fast handshake, then why would it be prohibited? >> >> > > The standard must ensure that compliant clients interoperate with > compliant servers. Compliant servers are permitted (expected, even, for > DTLS!) to offload state such as the handshake hash into the cookie. A > client that reused a cookie from an old connection on a new connection > to such a server would fail to interoperate, as the server would use the > wrong handshake transcript. Ergo, the spec strictly forbids clients > from implementing this behavior in order to preserve interoperability. > > There is "nothing" to stop some actor from deploying a noncompliant > implementation on their own private network where interoperability with > compliant implementations is not needed, but of course then that actor > must take responsibility for any changes to the security and privacy > properties as a result of those noncompliant modifications. In this > case, for example, the routability proof embedded in the cookie could > become stale with time (in case of readdressing), and the repeated > cookie provides linkability between ClientHellos from the same client > (to an adversary observing at some point in the middle of the network), > for a start. No one could guarantee that there are not more changes to > the security and privacy properties than those already listed, of course. > > -Ben --=20 Ar cie=C5=86u, J=C4=81nis =C4=8Coders From nobody Mon Oct 30 07:21:35 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4D313F444 for ; Mon, 30 Oct 2017 07:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Mr7iD9iSjEsQ for ; Mon, 30 Oct 2017 07:21:27 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFC5138BD8 for ; Mon, 30 Oct 2017 07:21:27 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9UEJqMJ005615; Mon, 30 Oct 2017 14:21:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=KhNdgq43DrG3xRs4eLD/iB7lcrLa9lRL/1hmO6dUScE=; b=YV8ydh2XAil2eZm4ylF4RaWYXJa7D4gwEsSaVVXboyrRF8KThmGq4hBXy0c+BnRWAPUD bmBvf86PU6/Wq3bJ3grJnx/gggQ6rHH0X5JbFqn5SVi4i7sNZPn7QuuFpzngxPL5hhZd cX3kUlNe7d+yLCCoWxN+nBI1z0QP1VFQDjLrAnZxFu7zmhvKc3ihnNwk4jaC5BV32yr1 HogpcBZPwzCehmePYjJMFbDrt2ycZbrzqvi5GwNtqe5V1Oxsf0IlWX2lwehrcqCVdgUP 0+HEqgz+f/6CJOzURokLxJHim3xq8Ov98JQxGy/08vWUeWbxJ49m3GsUGMKZ+JyiJIlH Mg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2dvmw2ek8v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 14:21:24 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9UEG2cx015311; Mon, 30 Oct 2017 10:21:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dvn7tw14d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 10:21:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 30 Oct 2017 10:21:22 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 30 Oct 2017 10:21:22 -0400 From: "Salz, Rich" To: Sean Turner , "" Thread-Topic: [TLS] TLS@IETF100: Agenda Requests Thread-Index: AQHTTOWwew2Q2aAdy06XmH3DbvIHJqL8r9KAgAAOKIA= Date: Mon, 30 Oct 2017 14:21:21 +0000 Message-ID: <29EEDF0E-E14F-4AD2-9BFD-00D959434F1E@akamai.com> References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.149] Content-Type: text/plain; charset="utf-8" Content-ID: <6814A307347EF8478E2C9987D90ECA5E@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710300195 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710300195 Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:21:33 -0000 V2lsbCB0aGVyZSBiZSBhbiB1cGRhdGUgZnJvbSB0aG9zZSBmb2xrcyBsb29raW5nIGF0IHR3ZWFr cyBhbmQgZGVwbG95bWVudCBpc3N1ZXM/DQoNCg== From nobody Mon Oct 30 07:24:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC8F13F577 for ; Mon, 30 Oct 2017 07:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiTPwwybC4GN for ; Mon, 30 Oct 2017 07:24:21 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB28113A5CF for ; Mon, 30 Oct 2017 07:24:20 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id j4so11695574ywb.2 for ; Mon, 30 Oct 2017 07:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CaRrw0xuhbAhJG3mXUZoLCvCGl48AYSAg++IlXY1w/Y=; b=pZV7o9g8SJ0d9MEPIaEN5kAj9StYlAlOkPAAKdMJLe4/EoLhDTXEPEEUQZMNnGCu2G TxYRdSrWDoLoZm+RQ1heTtFPCnkNtOzo504Cnx3bzy5vXdGjFGaOuEF7akT1bEhFVLxQ nrrSKqKmXgunYLHwPFq7HQ8L7FvPjM/iRpsoLvTWxLlAOFTObVUOvfEOBIcFdnxV6p2K 1jsHBv/oWreVBHO1lhRIGLOaCOFxfCloyKd+1QmbZSn1yJ0z+OKj3sApD8O8nluTZkGd IjPbE5u2SEqqA9ZDM4dlRC5HtDh/ELyFVFjRc7TF+GI6haq0uryVM4JoINswDNiKHm/A YoOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CaRrw0xuhbAhJG3mXUZoLCvCGl48AYSAg++IlXY1w/Y=; b=ses4CqAs5C7INzHN+WPZZDX6OZ6fmVj0cV7h2JukVb6qCQ0sLs9x2zBmlWl+EDKgqt D7UUesygoPKrovZ3odac2B6R2oOReiQq3zHM2s3VErkOhE45Byo9aEGIaet9m/m+9SgM ksBJvZJ2AdNuhy4NxvA74le/hD35pyO2OWcUDUS90Ehd8yU+Z/G3J2LhXyHOl/AkBGjN UfiS1HoeEHHL7eUPEwOXgR44wq2WkeDegoAi3UR/cti6Tg23qOPlMS6wsO1ojxjDT4NO xLinVwaOIEQQzu+w2VmK3Ktjn+hKyQVknPqTBJYzOuPiHVd8vYgyA3J+G5hTBkaDaQeA 8GZg== X-Gm-Message-State: AMCzsaWfPXhdmx8Ca5dpPpJIhX+k7IAVzjXnEUrsDrFzH9cEG9s5cKPt 99thvqjqP5AEdhYvzDcpM1dVmzYfndEHBoKvfC+GNg== X-Google-Smtp-Source: ABhQp+Qa0Z7JvlisbhwulKsA+8ud2dIy1I/9HNbzgyRLIZYpk+cw/10d04JXR7yNHskFnvZdNop+MsF3rAAFZf5+Qxg= X-Received: by 10.129.26.208 with SMTP id a199mr5850997ywa.280.1509373459913; Mon, 30 Oct 2017 07:24:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 30 Oct 2017 07:23:39 -0700 (PDT) In-Reply-To: <29EEDF0E-E14F-4AD2-9BFD-00D959434F1E@akamai.com> References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <29EEDF0E-E14F-4AD2-9BFD-00D959434F1E@akamai.com> From: Eric Rescorla Date: Mon, 30 Oct 2017 07:23:39 -0700 Message-ID: To: "Salz, Rich" Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary="001a1142d0d4e9762c055cc46494" Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:24:22 -0000 --001a1142d0d4e9762c055cc46494 Content-Type: text/plain; charset="UTF-8" Yes, I expect so. -Ekr On Mon, Oct 30, 2017 at 7:21 AM, Salz, Rich wrote: > Will there be an update from those folks looking at tweaks and deployment > issues? > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1142d0d4e9762c055cc46494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I expect so.

-Ekr


On Mon,= Oct 30, 2017 at 7:21 AM, Salz, Rich <rsalz@akamai.com> wrote= :
Will there be an update from those folk= s looking at tweaks and deployment issues?

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1142d0d4e9762c055cc46494-- From nobody Mon Oct 30 09:37:16 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A10B66F0; Mon, 30 Oct 2017 09:37:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150938142936.7882.174082990249782936@ietfa.amsl.com> Date: Mon, 30 Oct 2017 09:37:09 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:37:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : IANA Registry Updates for TLS and DTLS Authors : Joe Salowey Sean Turner Filename : draft-ietf-tls-iana-registry-updates-02.txt Pages : 16 Date : 2017-10-30 Abstract: This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates many (D)TLS RFCs (see updates header). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 09:50:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644D713FA99 for ; Mon, 30 Oct 2017 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 MFX0XTP1AiUh for ; Mon, 30 Oct 2017 09:50:56 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7DD413FABE for ; Mon, 30 Oct 2017 09:45:57 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id q83so16937630qke.6 for ; Mon, 30 Oct 2017 09:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=/LaZzRzsPtr1tFX3gIjvWNMy4N4EnBFmokySrqlcfCk=; b=PRTA/29CcPbgB+T8KBc0/r/J7sjHAHgGsKbl4IPMy43wYCchwvg1KR4NggGt9S6OfU JBneWOxsFaEX3Cc1jNOpco9ykEMgD3KlD2m5V7MggqABLwA8tv18w30sIWYzAsAbxIfU duVmfr02MgH19D5GsVVW1T4+npWKpwg83sGN0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=/LaZzRzsPtr1tFX3gIjvWNMy4N4EnBFmokySrqlcfCk=; b=FzGSpLmpFlJ+3sXElml82FTM3GFO8M0YthMXMn2U5NVYnq85vU0oiOXpmdobxW3aNB ejyyLNyz1HF9lg/fFZYjupzIPgiYtLlfke4uSVtt9gw5XJjOaaZDsrjJJaPQKYZmcs1j Zyua//lm9Gdmn7/KXbC94WawSLda1Lp8tpQiOrQbTTYuCbPUYqFE7CycjT2f1+/d0sfm tHDxoP8dJyFw2HlLxb/4OqkUfuscgqdaITBSeJELKhk2ZbYz1XJxlc9bSql3xF+Gktoo tO+7wFBmM7MdKWFgiSVrUtdxunMqur1d7h+11QdFkHvZNDihH6ehaXEREEs+9pZCZwyT yqhw== X-Gm-Message-State: AMCzsaWYbks1Xqzano22snagEObywg01cZYoqjvZt23cUx5sVQ7oqafD X5+aGMVRxIozqOnEXeEh1pycLt0tUXw= X-Google-Smtp-Source: ABhQp+QxBs1kaNbY1k1mNssBIeoiOMt5Qw8e+VJfVIdpMLHvrBB12TDDbnOg9LZFDFJgKQqvwG2oiw== X-Received: by 10.55.159.88 with SMTP id i85mr14163238qke.350.1509381956722; Mon, 30 Oct 2017 09:45:56 -0700 (PDT) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id g128sm4841885qkb.16.2017.10.30.09.45.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 09:45:55 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 30 Oct 2017 12:45:55 -0400 References: <150938142936.7882.174082990249782936@ietfa.amsl.com> To: "" In-Reply-To: <150938142936.7882.174082990249782936@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:50:58 -0000 All, Joe and I updated the draft. GH repo is @: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates This version incorporates the changes I suggested we do last time, = namely making the intro briefer and moving the rationale to the = individual sections. We also added security considerations, added = warnings for crypto-related registries, removed CCM_8 cipher from = recommended list, etc. In other words, PR#26 and later minus the one = closed issue. Joe and I believe this draft i ready for WGLC, which Kathleen will run = for us. spt > On Oct 30, 2017, at 12:37, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : IANA Registry Updates for TLS and DTLS > Authors : Joe Salowey > Sean Turner > Filename : draft-ietf-tls-iana-registry-updates-02.txt > Pages : 16 > Date : 2017-10-30 >=20 > Abstract: > This document describes a number of changes to (D)TLS IANA = registries > that range from adding notes to the registry all the way to changing > the registration policy. These changes were mostly motivated by WG > review of the (D)TLS-related registries undertaken as part of the > TLS1.3 development process. This document updates many (D)TLS RFCs > (see updates header). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-02 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates= -02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-0= 2 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Oct 30 09:52:02 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2491B7F7B for ; Mon, 30 Oct 2017 09:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 OQGyeLGRsqxE for ; Mon, 30 Oct 2017 09:51:46 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36DF7D8F for ; Mon, 30 Oct 2017 09:46:56 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id h4so17196261qtk.8 for ; Mon, 30 Oct 2017 09:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=GFEVxuZ/WB0+kJk3sZYoXZHL0gDoRhSNq72CcMUtVDQ=; b=lzd1DEwqSdyoqhGRTitMDT0gU9KdA4dy4FtAQOq/GDWUlxxqKi7GYeRqZIEttecX9w lZ0GjhyrXIXXiWslXjqiDbOzp99iNtq8ursqP5iuX8PXGLkrjgTEsuBfIYfNSplmAbf/ p+tBKdQQzE+hUrwQNipAFKD+KSuY8DPbQre7M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=GFEVxuZ/WB0+kJk3sZYoXZHL0gDoRhSNq72CcMUtVDQ=; b=FGHp6RE0JVSgO/GfWZpH8TytIpnn4vrkRmMdHQ+QoqpiMEIgt1UwHzEAnsAcY2MmVF hMDrgJ57qBIxr/Hn9LZ7pPSewM1MYl/9FBSzt0pPwtpq4q/7DHo2Q0zc+vQ9Uw502+3I 7e54OsJ6lTv8rEDs3H4OlaaU4zYIGkcNk5A8jKdcJqCZE6kohiuoOQVvd8t6QZLTHZw4 n006mXVdgHIB3jEK9qkq0JwvmILTGqRKijxd58nnUDtv/ZDwK+V0OyFQaxGnTKR0NkE1 0xKRtMAl4EurTu6W0QlsDv+MmoUk/f3kJG/3U1ceBEVbSaPsC100OXDrXHC1QdkrwDk6 nPng== X-Gm-Message-State: AMCzsaWuU65m0NCFfDXtey0oE9Pxmtvf17q03jiumFOsc+WOfpbv9V61 6Mo8NxrJyM3s+lpVnsw4NArV8cWu9pM= X-Google-Smtp-Source: ABhQp+S6IAD0wTDEX1Hpo0p4hthKs+BtENum+YawCpFCvQgjAnzZbWDipg0bDJSS5a5NUPfxhY5zUQ== X-Received: by 10.200.27.171 with SMTP id z40mr15263639qtj.151.1509382015827; Mon, 30 Oct 2017 09:46:55 -0700 (PDT) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id g128sm4841885qkb.16.2017.10.30.09.46.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 09:46:55 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 30 Oct 2017 12:46:54 -0400 References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> To: "" In-Reply-To: Message-Id: <81BE0C5C-DF0F-4292-B036-B021A6CEEB2E@sn3rd.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:51:49 -0000 In terms of full disclosure, Joe and I are going to ask for a short slot = to discuss draft-ietf-tls-iana-registry-updates. spt > On Oct 30, 2017, at 09:30, Sean Turner wrote: >=20 > This is just a reminder to get those requests in. >=20 > spt >=20 >> On Oct 24, 2017, at 12:32, Sean Turner wrote: >>=20 >> All, >>=20 >> You will have seen that the chairs requested two sessions for IETF = 100 TLS (on 20170929) and you will have also seen the that our request = was granted (on 20171020). The sessions are currently scheduled as = follows: >>=20 >> tls Session 1 (2:30:00) >> Thursday, Morning Session I 0930-1200 >> Room Name: Canning size: 250 >> --------------------------------------------- >> tls Session 2 (1:00:00) >> Monday, Afternoon Session III 1740-1840 >> Room Name: Padang size: 300 >> --------------------------------------------- >>=20 >> We would like to get a sense of who wants to request agenda time so = please send in your requests by 20171029; this will give the chairs time = to upload a draft agenda due on 20171030. Along with your request = please let us know how long you would like. >>=20 >> NOTE: Those that have already submitted requests need not do so = again. >>=20 >> J&S >=20 From nobody Mon Oct 30 10:36:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEE89327 for ; Mon, 30 Oct 2017 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYlhlM7_DUcx for ; Mon, 30 Oct 2017 10:36:40 -0700 (PDT) Received: from esa1.dyson.c3s2.iphmx.com (esa1.dyson.c3s2.iphmx.com [68.232.133.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F249343 for ; Mon, 30 Oct 2017 10:36:29 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8699"; a="28928958" X-IronPort-AV: E=Sophos;i="5.44,320,1505775600"; d="scan'208";a="28928958" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa1.dyson.c3s2.iphmx.com with ESMTP; 30 Oct 2017 17:49:31 +0000 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id A92E9FA10 for ; Mon, 30 Oct 2017 16:25:25 +0000 (GMT) Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id 9C69EFA02 for ; Mon, 30 Oct 2017 16:25:25 +0000 (GMT) Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-02.dyson.global.corp ([fe80::d0fe:1c2d:58fc:2dbb%17]) with mapi id 14.03.0319.002; Mon, 30 Oct 2017 17:36:25 +0000 From: Tony Putman To: "tls@ietf.org" Thread-Topic: [TLS] Preshared Keypairs for (D)TLS 1.2 Thread-Index: AdNOZUbbVUBYiVMUSduzwinXMAIY6AAIzHCAAMXqw3A= Date: Mon, 30 Oct 2017 17:36:24 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC2D8961@UK-MAL-MBOX-01.dyson.global.corp> References: <140080C241BAA1419B58F093108F9EDC2CEB42@UK-MAL-MBOX-02.dyson.global.corp> <18fd6543-5738-d7da-f66e-f410ad988b7a@gmx.net> In-Reply-To: <18fd6543-5738-d7da-f66e-f410ad988b7a@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 17:36:42 -0000 All, Thanks for your many comments. I still feel that this would be a useful add= ition to the TLS authentication methods, and Eric expressed an interest in = seeing this fleshed out more, so should my next step be to compose a draft = document? In response to the comments, I have searched the past draft documents and h= ave found nothing on triple DH. It is used in the Signal protocol, which re= ferences some papers, but does not seem to have been taken up by the IETF a= nywhere.=20 @Dan, thanks for the pointer to MQV variants. This seems to be more efficie= nt and there have been a couple of TLS drafts on using this (last one in 20= 10). I could find no discussion of this in the list archives, which is odd,= so I don't know why they did not progress. However, if there are licensing= matters then I feel this would impede widespread implementation so I would= not be interested in pursuing that path.=20 @Hannes, I want to improve on PSK in the cheapest way possible. This means = removing the overheads of certificates, but it also means removing the need= for an ECDSA implementation in the IoT device. The associated protocol sim= plifications are also attractive for small devices.=20 @Christian, I don't propose to expose the public keys, but the respective i= dentities are exposed. As the protocol messages are identical to the ECDHE_= PSK protocol, the privacy issues are likewise identical. Right now, I don't= see a way around this in TLS 1.2.=20 @Eric, I had not given any thought to anonymous client, as this was intende= d to improve on ECDHE_PSK. However, if you think that it's important then i= t seems straightforward to add, though additional security checks may be ne= eded (I'll investigate).=20 @Eric, @Ilari, if you think that I should also address the use of 3DH in TL= S 1.3 then I'm happy to do so, but I would like to undertake it as a separa= te activity. I feel that there are too many differences to try to undertake= it in a single document.=20 --=20 Tony From nobody Mon Oct 30 14:33:02 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A58313FBD1; Mon, 30 Oct 2017 14:32:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150939917601.7765.15864392190939816519@ietfa.amsl.com> Date: Mon, 30 Oct 2017 14:32:56 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-subcerts-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:32:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Delegated Credentials for TLS Authors : Richard Barnes Subodh Iyengar Nick Sullivan Eric Rescorla Filename : draft-ietf-tls-subcerts-00.txt Pages : 11 Date : 2017-10-30 Abstract: The organizational separation between the operator of a TLS server and the certificate authority that provides it credentials can cause problems, for example when it comes to reducing the lifetime of certificates or supporting new cryptographic algorithms. This document describes a mechanism to allow TLS server operators to create their own credential delegations without breaking compatibility with clients that do not support this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-subcerts-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 14:44:39 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F7013FBDC; Mon, 30 Oct 2017 14:44:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150939987158.7857.14302357156892186600@ietfa.amsl.com> Date: Mon, 30 Oct 2017 14:44:31 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:44:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-04.txt Pages : 7 Date : 2017-10-30 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 15:18:04 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4B613FC45 for ; Mon, 30 Oct 2017 15:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ0fo9oZHZjr for ; Mon, 30 Oct 2017 15:17:59 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 6C60313FDB3 for ; Mon, 30 Oct 2017 15:17:46 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id b9so19380291wmh.0 for ; Mon, 30 Oct 2017 15:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DP+EEhNGZkAwuSTmlsdnP3NJLyJj+Iit9LM7+Q/ezJo=; b=thn0B/TTt2Q9Bp9xR8ZkQTPt+wk9+U3Lr8PZGkPEmui5HAEv4FTlD1gLOfswZFRKfg Fuszb5Lo3gRUat9okx0NVA3tcYFSDffz+9g3JlrTElc8M+ROX7GCfSwlASS/g+A1t5yb LyJeUyFKTRrcfy6JcMMpIKp18DafviIde3MVKlFwXQE0bXsFxSQUYX0DjmqH0k0fA0NJ 0StRx5hSsGvCXpO9TQjkjJI7ZBUWUfG760rqw6/L2oXvOmNkL4kmPnGMAEBMUvoJWwZH F2PMOD85oDmZOtzXk/+vWKJNhepxyRKzOas7+bvuo60LOo2sbS1oQmEr6uv1N27P2ZaH UnxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DP+EEhNGZkAwuSTmlsdnP3NJLyJj+Iit9LM7+Q/ezJo=; b=hlXM9JsmHV/flVbKej4ukNRSqdCD6TqkGxw3/4AUWBKekeElTMAvMXwO71tOhPu2l7 bBfJQKhP5IiJy1sFv0lP0nmHi/YVXCDe9Dhn0Gvn8qZJ5/r/otyil3xYOTENC7Sb6pD/ VlzSSiUVG9+QxwFiQ9ZzCCFtpBoN5cVe6PaFR44mA0IFqFI7Bbxk7oetzwK4WbX/C1vm pu943G2cs5OLqmE6jTKj7G/F/qZRu1OjjNDwhQS4e7SMc4bLS61DP5/vl1MfBOeMMDEu oTu7UFNzjFwg6UlU631RqnQYNd2KuxEiNN6VbU1vVv8MXLdHezJsY4xJpcpbl07yURA8 CMHQ== X-Gm-Message-State: AMCzsaXlCldbQ4RaICcE9eP+ZPnGgynXkyV44JAqaRNgOgkwrW/t13fk LMyfBafIopoCXk1xjFrJworHEjAOE+w3uw4oisXOgae8 X-Google-Smtp-Source: ABhQp+RPrnCOxpbi2YFxd9nb0gpoi4xjw0MEWukQIzsHSLlnF2lmfdpLGEbqU/LMwgig0MeFAOuIkpSTaniMYi/GBug= X-Received: by 10.28.156.67 with SMTP id f64mr151337wme.42.1509401864662; Mon, 30 Oct 2017 15:17:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Mon, 30 Oct 2017 15:17:44 -0700 (PDT) In-Reply-To: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Mon, 30 Oct 2017 18:17:44 -0400 Message-ID: To: "" Content-Type: multipart/alternative; boundary="001a114b3208f78517055ccb01bf" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:18:03 -0000 --001a114b3208f78517055ccb01bf Content-Type: text/plain; charset="UTF-8" Hey TLS folks, Owen, Max, and I have been kicking around some ideas for how to make secure connections in environments where HTTPS is subject to MitM / proxying. The below draft lays out a way to tunnel TLS over HTTPS, in hopes of creating a channel you could use when you really need things to be private, even from the local MitM. Feedback obviously very welcome. Interested in whether folks think this is a useful area in which to develop an RFC, and any thoughts on how to do this better. Thanks, --Richard On Mon, Oct 30, 2017 at 3:47 PM, wrote: > > A new version of I-D, draft-friel-tls-over-http-00.txt > has been successfully submitted by Owen Friel and posted to the > IETF repository. > > Name: draft-friel-tls-over-http > Revision: 00 > Title: Application-Layer TLS > Document date: 2017-10-30 > Group: Individual Submission > Pages: 20 > URL: https://www.ietf.org/internet-drafts/draft-friel-tls-over- > http-00.txt > Status: https://datatracker.ietf.org/ > doc/draft-friel-tls-over-http/ > Htmlized: https://tools.ietf.org/html/draft-friel-tls-over-http-00 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-friel-tls-over-http-00 > > > Abstract: > Many clients need to establish secure connections to application > services but face challenges establishing these connections due to > the presence of middleboxes that terminate TLS connections from the > client and restablish new TLS connections to the service. This > document defines a mechanism for transporting TLS records in HTTP > message bodies between clients and services. This enables clients > and services to establish secure connections using TLS at the > application layer, and treat any middleboxes that are intercepting > traffic at the network layer as untrusted transport. In short, this > mechanism moves the TLS handshake up the OSI stack to the application > layer. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > --001a114b3208f78517055ccb01bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey TLS folks,

Owen, Max, an= d I have been kicking around some ideas for how to make secure connections = in environments where HTTPS is subject to MitM / proxying.

The below draft lays out a way to tunnel TLS over HTTPS, in hopes = of creating a channel you could use when you really need things to be priva= te, even from the local MitM.=C2=A0

Feedback = obviously very welcome.=C2=A0 Interested in whether folks think this is a u= seful area in which to develop an RFC, and any thoughts on how to do this b= etter.

Thanks,
--Richard


= On Mon, Oct 30, 2017 at 3:47 PM, <internet-drafts@ietf.org>= wrote:

A new version of I-D, draft-friel-tls-over-http-00.txt
has been successfully submitted by Owen Friel and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-friel-tls-over-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Layer TLS
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-friel-tls-ov= er-http-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-friel-tls-over-http-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http= -00


Abstract:
=C2=A0 =C2=A0Many clients need to establish secure connections to applicati= on
=C2=A0 =C2=A0services but face challenges establishing these connections du= e to
=C2=A0 =C2=A0the presence of middleboxes that terminate TLS connections fro= m the
=C2=A0 =C2=A0client and restablish new TLS connections to the service.=C2= =A0 This
=C2=A0 =C2=A0document defines a mechanism for transporting TLS records in H= TTP
=C2=A0 =C2=A0message bodies between clients and services.=C2=A0 This enable= s clients
=C2=A0 =C2=A0and services to establish secure connections using TLS at the<= br> =C2=A0 =C2=A0application layer, and treat any middleboxes that are intercep= ting
=C2=A0 =C2=A0traffic at the network layer as untrusted transport.=C2=A0 In = short, this
=C2=A0 =C2=A0mechanism moves the TLS handshake up the OSI stack to the appl= ication
=C2=A0 =C2=A0layer.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a114b3208f78517055ccb01bf-- From nobody Mon Oct 30 15:26:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6761A13FC39 for ; Mon, 30 Oct 2017 15:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 abbJtF2RZ3Pl for ; Mon, 30 Oct 2017 15:26:14 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 1DCDB13FC11 for ; Mon, 30 Oct 2017 15:26:09 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id n38so10656391uai.11 for ; Mon, 30 Oct 2017 15:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DKTMTNIoxufYjTZHUnL3yZlRg8OBHTWVq0GjLLp7uNw=; b=SNdkGoGNJyAMWmwp2h4tC1IH6Ae5R2GDkVeDJ4wiLmK5/gydhwNrPLIjA2FmSudRtA tZ4YWhqAB/rUgYegbt481M4Cyloeq+unh1QEsMOEunYDWub7YtspXrXVo6n9JsflHDGT HKFn/Hh+humZ5bk/+JHG9qnX3OppypFm7bB8y0uE7gJrzFwqjbz8yuslrvGuN8ybpvdB Int46WP/WxkybCepI9nLKtBT2X4MtXrOUY4s36hKU4rYDn3MPIigpTBmbhTYOxYpBZ50 N9Xbm3Rj9rGTYd+ulye+myIT/gaKeGdHjoVW6kDAsql31ZQOARR/1zwjgvRb6CEE0jbM tMrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DKTMTNIoxufYjTZHUnL3yZlRg8OBHTWVq0GjLLp7uNw=; b=sjJ5GPYgwF2bTU2jsqZsuQEP14DApd20O9ytA78lUFIRMKJxbDu5fBJe1tZ7iY8e64 Mjcn6ocemSvnRTk4YZBrnaOWWZjkLeGbMb4lgG7BlL1jVHvbO7GsNYL/EZvTp7rdkhqQ AmGTttkDUu0RTaZk+i30doziSWetAv0DKB0Yft5Ksc9E6IQbhEfwMgWvqa9RV25GERWp 1jLcQOAI6WJEQ7USo/1fN47ZNQ252fbxU1GdTuJTWgiC6vz2rCuujUQbzVWXvghiqvSg c4xYbGsbVl0MBTQnTkSatXbf/ptomyzdpCx3sQjFtHMpu7xvsEs0sPOEohQFAOqjSPS0 t8yw== X-Gm-Message-State: AMCzsaV/Tlklv7Kf7PSFGrU/wV7ZygDIZXC0/IYNaEi4KaoCoC3fuy4b DQLy64vP7tObwnC9FkwQ6d3cNBaQV201qDmAsAxLlA== X-Google-Smtp-Source: ABhQp+QWE2KwWnKHVYT/9E6ecykVfpM3LOYMFFxRbeNspOreUQerydUGRwvVW37JpDGxZfP3vwn7whPUmSgIYUV4pyU= X-Received: by 10.176.89.81 with SMTP id o17mr8982496uad.12.1509402367807; Mon, 30 Oct 2017 15:26:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.145 with HTTP; Mon, 30 Oct 2017 15:26:07 -0700 (PDT) In-Reply-To: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Ben Schwartz Date: Mon, 30 Oct 2017 18:26:07 -0400 Message-ID: To: Richard Barnes Cc: "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11465c36fe7c7b055ccb1f67" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:26:16 -0000 --001a11465c36fe7c7b055ccb1f67 Content-Type: multipart/alternative; boundary="001a11465c36f542e7055ccb1fc6" --001a11465c36f542e7055ccb1fc6 Content-Type: text/plain; charset="UTF-8" Why not use HTTP CONNECT? Or rather, it would be helpful to have a section on when/why one would do this vs. CONNECT. On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes wrote: > Hey TLS folks, > > Owen, Max, and I have been kicking around some ideas for how to make > secure connections in environments where HTTPS is subject to MitM / > proxying. > > The below draft lays out a way to tunnel TLS over HTTPS, in hopes of > creating a channel you could use when you really need things to be private, > even from the local MitM. > > Feedback obviously very welcome. Interested in whether folks think this > is a useful area in which to develop an RFC, and any thoughts on how to do > this better. > > Thanks, > --Richard > > > On Mon, Oct 30, 2017 at 3:47 PM, wrote: > >> >> A new version of I-D, draft-friel-tls-over-http-00.txt >> has been successfully submitted by Owen Friel and posted to the >> IETF repository. >> >> Name: draft-friel-tls-over-http >> Revision: 00 >> Title: Application-Layer TLS >> Document date: 2017-10-30 >> Group: Individual Submission >> Pages: 20 >> URL: https://www.ietf.org/internet- >> drafts/draft-friel-tls-over-http-00.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-friel-tls-over-http/ >> Htmlized: https://tools.ietf.org/html/draft-friel-tls-over-http-00 >> Htmlized: https://datatracker.ietf.org/ >> doc/html/draft-friel-tls-over-http-00 >> >> >> Abstract: >> Many clients need to establish secure connections to application >> services but face challenges establishing these connections due to >> the presence of middleboxes that terminate TLS connections from the >> client and restablish new TLS connections to the service. This >> document defines a mechanism for transporting TLS records in HTTP >> message bodies between clients and services. This enables clients >> and services to establish secure connections using TLS at the >> application layer, and treat any middleboxes that are intercepting >> traffic at the network layer as untrusted transport. In short, this >> mechanism moves the TLS handshake up the OSI stack to the application >> layer. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11465c36f542e7055ccb1fc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why not use HTTP CONNECT?=C2=A0 Or rather, it would be hel= pful to have a section on when/why one would do this vs. CONNECT.

On Mon, Oct 30, 2017 = at 6:17 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey TLS folks,

Owen, Max, and I have been kicking around some ideas for how to make secur= e connections in environments where HTTPS is subject to MitM / proxying.

The below draft lays out a way to tunnel TLS over HT= TPS, in hopes of creating a channel you could use when you really need thin= gs to be private, even from the local MitM.=C2=A0

=
Feedback obviously very welcome.=C2=A0 Interested in whether folks thi= nk this is a useful area in which to develop an RFC, and any thoughts on ho= w to do this better.

Thanks,
--R= ichard


On Mon, Oct 30, 2017 at 3:47 PM, <internet-drafts@ie= tf.org> wrote:

A new version of I-D, draft-friel-tls-over-http-00.txt
has been successfully submitted by Owen Friel and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-friel-tls-over-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Layer TLS
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-friel-tls-ov= er-http-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-friel-tls-over-http-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http= -00


Abstract:
=C2=A0 =C2=A0Many clients need to establish secure connections to applicati= on
=C2=A0 =C2=A0services but face challenges establishing these connections du= e to
=C2=A0 =C2=A0the presence of middleboxes that terminate TLS connections fro= m the
=C2=A0 =C2=A0client and restablish new TLS connections to the service.=C2= =A0 This
=C2=A0 =C2=A0document defines a mechanism for transporting TLS records in H= TTP
=C2=A0 =C2=A0message bodies between clients and services.=C2=A0 This enable= s clients
=C2=A0 =C2=A0and services to establish secure connections using TLS at the<= br> =C2=A0 =C2=A0application layer, and treat any middleboxes that are intercep= ting
=C2=A0 =C2=A0traffic at the network layer as untrusted transport.=C2=A0 In = short, this
=C2=A0 =C2=A0mechanism moves the TLS handshake up the OSI stack to the appl= ication
=C2=A0 =C2=A0layer.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a11465c36f542e7055ccb1fc6-- --001a11465c36fe7c7b055ccb1f67 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t /WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo 7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm 9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/ UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAlLcE6TswhrXz1np2Mg2DJ 9ugpj1e09SUYaPgHEdSFiDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzEwMzAyMjI2MDhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAN4/XjqnHpJUeQSgoLuphNkmllSA1gJiONTEWCR0c S0uyWvR2RXiLtg8PuLAb9ppkozCgDduL3/POAYmkel8+ARRdZ1TY1XYnNl1PEB5WaH21YIrApO+0 IsVt4TkCjdiM3Y7CCqD6TAhZjei97+NRKHP0K9TSJP69QG5w7nG97FwwuVlLvLUIAl4NlsmReX7m If9qK2yJ+1/R3DYLzF7RzCTqXGcz96fl6ldb6tt8qzwZN5+Ei5bOZ2UtVkZzrP2Knv13nnz0F8Kd Psocm94FV01noB6BaScos42bFQYjJes3fil3afCBa52LGDXajf7KkSlz6vVf6iqnRPuWfLYa6A== --001a11465c36fe7c7b055ccb1f67-- From nobody Mon Oct 30 15:37:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48804C23A for ; Mon, 30 Oct 2017 15:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk8Bq05LIN1Q for ; Mon, 30 Oct 2017 15:37:42 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB8713942C for ; Mon, 30 Oct 2017 15:37:41 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n74so10927208wmi.1 for ; Mon, 30 Oct 2017 15:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cn/wRSuJsf/e/0fos53q6+hDYbNTTf7PlpygzzMldis=; b=A/nwUfOu9mWf32HeJYMxCT/R/z1Q9c3UcxWsufM/vi2A+6Nrwu9ULxMeQtoGcCrcvO XVZbFpfif4N/SWuxMtRYRVgJUwb8UBpUHLirSOJ1D5Llr+1MwrJUuKc3DXuiu5LKo9bP vuKiyfBWl6CzPWZNEV8QYJUCtYMAVjCVLicD2Absp1mhCghnWoBf/T2it8c1CzZIvZ5h /RF/41dTZj2ZZTzbKyCpRiBFZxVWR/eaW87RozEwJ0nQAr6vLqUuNSDS2eOUkZIIeWt7 5Iem6aqh28fipH3rrMmeGNoZRfJatbyWC8tdW1xi+NWWwddaXBbwy66vY7s2ZZhD111D 1PqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cn/wRSuJsf/e/0fos53q6+hDYbNTTf7PlpygzzMldis=; b=dfACwK7liBIOVarMPA12BoNiVrXC3oTd3n+vDFDU7CU4c33cHmtA6R2oF1g5XXjrZC wvx887Tc57LFKOXIBYrY5cYVjLgcEWBUViOgQ5CzfnoRgwZX9l3s+xTrfRz5nypdybLN sjD++VOGwimKq4pYelhrcVXusUzWbiKa3e+JqPnSbB0TY2jlwqAiPbDN5edqK8Md0Q5W 2FUVjhmAV98cVs1pyv2RO1MKFY7NMgyu05Pz4887Q1LNksgA9gLClAyD3+B9MyNVHXcS Xi2JONvWDQ6pEbA9sshBVBtJG8m4z9+rRTLMa4nQPFJF03kOZkRF+SDvwzg1BNgu7Y+O jh6A== X-Gm-Message-State: AMCzsaXHRG4/OBJ+yh6VCVYuUFS+Ht/12g1DIXNdr3TmoTH7YmoHYA7k l83UfRr0lyIFusut6h2byfPRQD+ngn9oatUSkaz4WA== X-Google-Smtp-Source: ABhQp+T8G6PGHKZYTLmPb82guVY13532Iur4ILgdrx7E5dHVZCUr39vl1DwQulPEbul1Fp0RS6PhbG1+n92u2ZNQy/I= X-Received: by 10.28.21.10 with SMTP id 10mr161388wmv.41.1509403060374; Mon, 30 Oct 2017 15:37:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Mon, 30 Oct 2017 15:37:39 -0700 (PDT) In-Reply-To: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Mon, 30 Oct 2017 18:37:39 -0400 Message-ID: To: Ben Schwartz Cc: "" Content-Type: multipart/alternative; boundary="001a1145a9323ca0f4055ccb4971" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:37:44 -0000 --001a1145a9323ca0f4055ccb4971 Content-Type: text/plain; charset="UTF-8" HTTP CONNECT is not great for some use cases because it requires the app to be aware that it's dealing with a proxy. It's simpler if you can just have one code path that works whether your TLS is intermediated or not. With the solution outlined in the draft, you can just always ignore the certificate the server sends in the first TLS connection (because it might be from a MitM), and then do all your cert validation, pin checks, etc. at the application layer. On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz wrote: > Why not use HTTP CONNECT? Or rather, it would be helpful to have a > section on when/why one would do this vs. CONNECT. > > On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes wrote: > >> Hey TLS folks, >> >> Owen, Max, and I have been kicking around some ideas for how to make >> secure connections in environments where HTTPS is subject to MitM / >> proxying. >> >> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of >> creating a channel you could use when you really need things to be private, >> even from the local MitM. >> >> Feedback obviously very welcome. Interested in whether folks think this >> is a useful area in which to develop an RFC, and any thoughts on how to do >> this better. >> >> Thanks, >> --Richard >> >> >> On Mon, Oct 30, 2017 at 3:47 PM, wrote: >> >>> >>> A new version of I-D, draft-friel-tls-over-http-00.txt >>> has been successfully submitted by Owen Friel and posted to the >>> IETF repository. >>> >>> Name: draft-friel-tls-over-http >>> Revision: 00 >>> Title: Application-Layer TLS >>> Document date: 2017-10-30 >>> Group: Individual Submission >>> Pages: 20 >>> URL: https://www.ietf.org/internet- >>> drafts/draft-friel-tls-over-http-00.txt >>> Status: https://datatracker.ietf.org/ >>> doc/draft-friel-tls-over-http/ >>> Htmlized: https://tools.ietf.org/html/draft-friel-tls-over-http-00 >>> Htmlized: https://datatracker.ietf.org/ >>> doc/html/draft-friel-tls-over-http-00 >>> >>> >>> Abstract: >>> Many clients need to establish secure connections to application >>> services but face challenges establishing these connections due to >>> the presence of middleboxes that terminate TLS connections from the >>> client and restablish new TLS connections to the service. This >>> document defines a mechanism for transporting TLS records in HTTP >>> message bodies between clients and services. This enables clients >>> and services to establish secure connections using TLS at the >>> application layer, and treat any middleboxes that are intercepting >>> traffic at the network layer as untrusted transport. In short, this >>> mechanism moves the TLS handshake up the OSI stack to the application >>> layer. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --001a1145a9323ca0f4055ccb4971 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HTTP CONNECT is not great for some use cases because it re= quires the app to be aware that it's dealing with a proxy.=C2=A0 It'= ;s simpler if you can just have one code path that works whether your TLS i= s intermediated or not.=C2=A0 With the solution outlined in the draft, you = can just always ignore the certificate the server sends in the first TLS co= nnection (because it might be from a MitM), and then do all your cert valid= ation, pin checks, etc. at the application layer.

On Mon, Oct 30, 2017 at 6:26 PM, = Ben Schwartz <bemasc@google.com> wrote:
Why not use HTTP CONNECT?=C2=A0 Or rather, i= t would be helpful to have a section on when/why one would do this vs. CONN= ECT.

On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes <rlb@ipv.sx= > wrote:
Hey TLS folks,

Owen, Max, and I have been kicking around some ideas for how to make secu= re connections in environments where HTTPS is subject to MitM / proxying.

The below draft lays out a way to tunnel TLS over H= TTPS, in hopes of creating a channel you could use when you really need thi= ngs to be private, even from the local MitM.=C2=A0

Feedback obviously very welcome.=C2=A0 Interested in whether folks th= ink this is a useful area in which to develop an RFC, and any thoughts on h= ow to do this better.

Thanks,
--= Richard


On Mon, Oct 30, 2017 at 3:47 PM, <internet-drafts= @ietf.org> wrote:

A new version of I-D, draft-friel-tls-over-http-00.txt
has been successfully submitted by Owen Friel and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-friel-tls-over-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Layer TLS
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-friel-tls-ov= er-http-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-friel-tls-over-http-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http= -00


Abstract:
=C2=A0 =C2=A0Many clients need to establish secure connections to applicati= on
=C2=A0 =C2=A0services but face challenges establishing these connections du= e to
=C2=A0 =C2=A0the presence of middleboxes that terminate TLS connections fro= m the
=C2=A0 =C2=A0client and restablish new TLS connections to the service.=C2= =A0 This
=C2=A0 =C2=A0document defines a mechanism for transporting TLS records in H= TTP
=C2=A0 =C2=A0message bodies between clients and services.=C2=A0 This enable= s clients
=C2=A0 =C2=A0and services to establish secure connections using TLS at the<= br> =C2=A0 =C2=A0application layer, and treat any middleboxes that are intercep= ting
=C2=A0 =C2=A0traffic at the network layer as untrusted transport.=C2=A0 In = short, this
=C2=A0 =C2=A0mechanism moves the TLS handshake up the OSI stack to the appl= ication
=C2=A0 =C2=A0layer.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--001a1145a9323ca0f4055ccb4971-- From nobody Mon Oct 30 15:38:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7210D13942C for ; Mon, 30 Oct 2017 15:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j1ZqnIJZ5RM for ; Mon, 30 Oct 2017 15:38:15 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 9F5EBC261 for ; Mon, 30 Oct 2017 15:38:10 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id r68so19457313wmr.3 for ; Mon, 30 Oct 2017 15:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aizKT+Fp6bUS68AJww0U4+Y5R3QXW/ml3Wcn9VQsnW0=; b=wKM+sjT7T6PZW0ho09RVzEv3Z1sUJY1Ii0rSvn8vSguMEodLR5PPwcpMflP8h1t77y RzSSk1VDImFsghvoKK7urgKcb1DvEnytN/RSUEUhc780z4XllKBxJVANkKrlXDYyZN/X xk4zH3I3NEIiIaQLBOdMG5mzeHgn56Vf87FGjGQm4Mjr4lyFU4P9bY1mqrU2ik0KHQef 5MhqgRt3wiQ7hJJ5+oyYE9eU3G5bWABnKGxhWUpcIlT/vdZL7cO38ti3mdwpdiP5FfRV LogclrnWv4lbG7H1u0QT7NAWi20M88Rwd6C7hH4OPmpyfS42Jqq+55LK52lxP8sLbWjS RPOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aizKT+Fp6bUS68AJww0U4+Y5R3QXW/ml3Wcn9VQsnW0=; b=IW0sIjJ9wHaVKYRzFh4Z6IoCT5YtfKySR894xsT0KETKmMRmNUSFrtMeuslavJQpTp lIBlqYr36L9suv8C4afV197dg9KgSjwFj5W0RiF8P0N/1urgvJmcRPcpzL7k7P1Hv1yz 01XOMP+Vm/AvcgVcNhCDK3CHhZblAPR/xU+6ZxPPL7qso4eTiMumanR59/0sIVNosb8u 6bJHfntQA3omu5QUyx5//22V3X40YezHUTxmRvUMV1KP0slBWwhq9iauqd8ebYdK6fiM vVfOxmD4EdYUw7BVDIWvJd7KJVq3zhr0G9acDPyvdQCwSPOy1+xK0j0OPICRQpROJBzk dQGw== X-Gm-Message-State: AMCzsaW+aNNNqnkFbgNU+xgtYogCp7rzyXkjUtX6zSfnH/cdtGNz4jE5 PfEiXjJWYA1YXrQh5XPuMrPV/oaPDm0evpX/Vd2X0sdG X-Google-Smtp-Source: ABhQp+T+TxR4nMTufxe0SN989m/T3qshP02gVIHgku4KH/BVYvBZkfok7uMvzMBsGoHuODbqSi9dJDJ1Y6MUO/pkORs= X-Received: by 10.28.156.67 with SMTP id f64mr176938wme.42.1509403089099; Mon, 30 Oct 2017 15:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Mon, 30 Oct 2017 15:38:08 -0700 (PDT) In-Reply-To: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Mon, 30 Oct 2017 18:38:08 -0400 Message-ID: To: Ben Schwartz Cc: "" Content-Type: multipart/alternative; boundary="001a114b3208f2ea76055ccb4a5d" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:38:17 -0000 --001a114b3208f2ea76055ccb4a5d Content-Type: text/plain; charset="UTF-8" But I agree, it would be good to have some more clarity around use cases and why not other solutions. On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes wrote: > HTTP CONNECT is not great for some use cases because it requires the app > to be aware that it's dealing with a proxy. It's simpler if you can just > have one code path that works whether your TLS is intermediated or not. > With the solution outlined in the draft, you can just always ignore the > certificate the server sends in the first TLS connection (because it might > be from a MitM), and then do all your cert validation, pin checks, etc. at > the application layer. > > On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz wrote: > >> Why not use HTTP CONNECT? Or rather, it would be helpful to have a >> section on when/why one would do this vs. CONNECT. >> >> On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes wrote: >> >>> Hey TLS folks, >>> >>> Owen, Max, and I have been kicking around some ideas for how to make >>> secure connections in environments where HTTPS is subject to MitM / >>> proxying. >>> >>> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of >>> creating a channel you could use when you really need things to be private, >>> even from the local MitM. >>> >>> Feedback obviously very welcome. Interested in whether folks think this >>> is a useful area in which to develop an RFC, and any thoughts on how to do >>> this better. >>> >>> Thanks, >>> --Richard >>> >>> >>> On Mon, Oct 30, 2017 at 3:47 PM, wrote: >>> >>>> >>>> A new version of I-D, draft-friel-tls-over-http-00.txt >>>> has been successfully submitted by Owen Friel and posted to the >>>> IETF repository. >>>> >>>> Name: draft-friel-tls-over-http >>>> Revision: 00 >>>> Title: Application-Layer TLS >>>> Document date: 2017-10-30 >>>> Group: Individual Submission >>>> Pages: 20 >>>> URL: https://www.ietf.org/internet- >>>> drafts/draft-friel-tls-over-http-00.txt >>>> Status: https://datatracker.ietf.org/ >>>> doc/draft-friel-tls-over-http/ >>>> Htmlized: https://tools.ietf.org/html/d >>>> raft-friel-tls-over-http-00 >>>> Htmlized: https://datatracker.ietf.org/ >>>> doc/html/draft-friel-tls-over-http-00 >>>> >>>> >>>> Abstract: >>>> Many clients need to establish secure connections to application >>>> services but face challenges establishing these connections due to >>>> the presence of middleboxes that terminate TLS connections from the >>>> client and restablish new TLS connections to the service. This >>>> document defines a mechanism for transporting TLS records in HTTP >>>> message bodies between clients and services. This enables clients >>>> and services to establish secure connections using TLS at the >>>> application layer, and treat any middleboxes that are intercepting >>>> traffic at the network layer as untrusted transport. In short, this >>>> mechanism moves the TLS handshake up the OSI stack to the application >>>> layer. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> > --001a114b3208f2ea76055ccb4a5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But I agree, it would be good to have some more clarity ar= ound use cases and why not other solutions.

On Mon, Oct 30, 2017 at 6:37 PM, Richar= d Barnes <rlb@ipv.sx> wrote:
HTTP CONNECT is not great for some use cases because it requir= es the app to be aware that it's dealing with a proxy.=C2=A0 It's s= impler if you can just have one code path that works whether your TLS is in= termediated or not.=C2=A0 With the solution outlined in the draft, you can = just always ignore the certificate the server sends in the first TLS connec= tion (because it might be from a MitM), and then do all your cert validatio= n, pin checks, etc. at the application layer.

On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz <bemasc@google.com>= ; wrote:
Why not = use HTTP CONNECT?=C2=A0 Or rather, it would be helpful to have a section on= when/why one would do this vs. CONNECT.
On= Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey TLS folks,

Owen, Max, and I have been kicking around some ideas for how to make secur= e connections in environments where HTTPS is subject to MitM / proxying.

The below draft lays out a way to tunnel TLS over HT= TPS, in hopes of creating a channel you could use when you really need thin= gs to be private, even from the local MitM.=C2=A0

=
Feedback obviously very welcome.=C2=A0 Interested in whether folks thi= nk this is a useful area in which to develop an RFC, and any thoughts on ho= w to do this better.

Thanks,
--R= ichard


On Mon, Oct 30, 2017 at 3:47 PM, <internet-drafts@ie= tf.org> wrote:

A new version of I-D, draft-friel-tls-over-http-00.txt
has been successfully submitted by Owen Friel and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-friel-tls-over-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Layer TLS
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-friel-tls-ov= er-http-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-friel-tls-over-http-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http= -00


Abstract:
=C2=A0 =C2=A0Many clients need to establish secure connections to applicati= on
=C2=A0 =C2=A0services but face challenges establishing these connections du= e to
=C2=A0 =C2=A0the presence of middleboxes that terminate TLS connections fro= m the
=C2=A0 =C2=A0client and restablish new TLS connections to the service.=C2= =A0 This
=C2=A0 =C2=A0document defines a mechanism for transporting TLS records in H= TTP
=C2=A0 =C2=A0message bodies between clients and services.=C2=A0 This enable= s clients
=C2=A0 =C2=A0and services to establish secure connections using TLS at the<= br> =C2=A0 =C2=A0application layer, and treat any middleboxes that are intercep= ting
=C2=A0 =C2=A0traffic at the network layer as untrusted transport.=C2=A0 In = short, this
=C2=A0 =C2=A0mechanism moves the TLS handshake up the OSI stack to the appl= ication
=C2=A0 =C2=A0layer.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls




--001a114b3208f2ea76055ccb4a5d-- From nobody Mon Oct 30 15:43:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902CE13FC5B for ; Mon, 30 Oct 2017 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 780WBY7QBRwd for ; Mon, 30 Oct 2017 15:43:32 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 7465213FC57 for ; Mon, 30 Oct 2017 15:43:32 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id n22so10712191uaj.13 for ; Mon, 30 Oct 2017 15:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2wUtExXtbkhbnVUs6exF0k2wFJMIMRjih7C85U5G8Ag=; b=UAy5I2PsiS/mbYFiEyD98GRi6+7wgAJ33y7V3AGwexsgOJzipK71I0Pi3xESIADbxZ wdquvC0xwKT3rLJ2uwhU2P6ni6JMKa8WetYl4C7TxFPkHAUe71kGe38lHPU6rFUhY+BJ FjXnBrLUnThRNFACWOKiWt59Damqe15bSFUcUbSJw5UbRD6/Gnlb8FabpsY7pIMWZp0q MHt/T34cBiyck32b86RRKLJx+iN8A49Vu8MtSqSRsM3DO8gPxvp3cmlA66GALakz1cs3 0ZCiD0XOBu9X+WK2CpplNpErQgEmI5eQftmhl7L4QPay8zYluO7M3A4Ky5t2brzDEAUy n+gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2wUtExXtbkhbnVUs6exF0k2wFJMIMRjih7C85U5G8Ag=; b=sog1SaQM45jllrTHwagB0zF1xLu/4c9TB8WGqQuV+9O8CO0j0wkL70Tw9VDva2tq/o qbJAjSQQksU4fCs0nlnwI98FMo7TR5BW+6/jlxzJYr8sv1k5qouoYKVLoqdYT6xDPjNt KmFl7gVKAOXxt8WGzoI9sRSz0m1g9hI6sERW6fNEZXwHtpNocq77tbj5i69F09DZUMlB LTe7k4ewvU225F7t52FR5lE1Y+5gxHtgNjvJDBsvS6cVBCpoXSgbcgMBDggBS5H/oGYe aQInLoZRoamJDhhVC4rDyk28dnGok8gw++j9+NRAXQurPJcQRDgwb3PURHWUK31zlpe4 g+yg== X-Gm-Message-State: AMCzsaU07hdJ3S6E1HZeBe8Vd27+Hs+KmOZ0ZrPklMIdZN6kikP7c9jh peQrTvAZ1RV6xfa8vBNNHp2AnYmT06/RuNmsgSawpg== X-Google-Smtp-Source: ABhQp+R43cH/OMZYIZ807/Au+WpaqI3vCTVNmQfg04t2xQl53vIib+KihtAKL8S5xwgYDMLLl0a3WJ6+ef9daf0+bpk= X-Received: by 10.159.48.137 with SMTP id j9mr9100650uab.102.1509403411097; Mon, 30 Oct 2017 15:43:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.145 with HTTP; Mon, 30 Oct 2017 15:43:30 -0700 (PDT) In-Reply-To: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Ben Schwartz Date: Mon, 30 Oct 2017 18:43:30 -0400 Message-ID: To: Richard Barnes Cc: "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045e368e2e84e3055ccb5e14" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:43:38 -0000 --f403045e368e2e84e3055ccb5e14 Content-Type: multipart/alternative; boundary="f403045e368e24b8b9055ccb5ee2" --f403045e368e24b8b9055ccb5ee2 Content-Type: text/plain; charset="UTF-8" I don't understand why ATLS allows the app to be less "aware" than HTTP CONNECT. I also don't understand how an ATLS client is closer to "one code path" than HTTP CONNECT. It seems to me that your description of client behavior applies equally to ATLS and HTTP CONNECT. On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes wrote: > But I agree, it would be good to have some more clarity around use cases > and why not other solutions. > > On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes wrote: > >> HTTP CONNECT is not great for some use cases because it requires the app >> to be aware that it's dealing with a proxy. It's simpler if you can just >> have one code path that works whether your TLS is intermediated or not. >> With the solution outlined in the draft, you can just always ignore the >> certificate the server sends in the first TLS connection (because it might >> be from a MitM), and then do all your cert validation, pin checks, etc. at >> the application layer. >> >> On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz wrote: >> >>> Why not use HTTP CONNECT? Or rather, it would be helpful to have a >>> section on when/why one would do this vs. CONNECT. >>> >>> On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes wrote: >>> >>>> Hey TLS folks, >>>> >>>> Owen, Max, and I have been kicking around some ideas for how to make >>>> secure connections in environments where HTTPS is subject to MitM / >>>> proxying. >>>> >>>> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of >>>> creating a channel you could use when you really need things to be private, >>>> even from the local MitM. >>>> >>>> Feedback obviously very welcome. Interested in whether folks think >>>> this is a useful area in which to develop an RFC, and any thoughts on how >>>> to do this better. >>>> >>>> Thanks, >>>> --Richard >>>> >>>> >>>> On Mon, Oct 30, 2017 at 3:47 PM, wrote: >>>> >>>>> >>>>> A new version of I-D, draft-friel-tls-over-http-00.txt >>>>> has been successfully submitted by Owen Friel and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-friel-tls-over-http >>>>> Revision: 00 >>>>> Title: Application-Layer TLS >>>>> Document date: 2017-10-30 >>>>> Group: Individual Submission >>>>> Pages: 20 >>>>> URL: https://www.ietf.org/internet- >>>>> drafts/draft-friel-tls-over-http-00.txt >>>>> Status: https://datatracker.ietf.org/ >>>>> doc/draft-friel-tls-over-http/ >>>>> Htmlized: https://tools.ietf.org/html/d >>>>> raft-friel-tls-over-http-00 >>>>> Htmlized: https://datatracker.ietf.org/ >>>>> doc/html/draft-friel-tls-over-http-00 >>>>> >>>>> >>>>> Abstract: >>>>> Many clients need to establish secure connections to application >>>>> services but face challenges establishing these connections due to >>>>> the presence of middleboxes that terminate TLS connections from the >>>>> client and restablish new TLS connections to the service. This >>>>> document defines a mechanism for transporting TLS records in HTTP >>>>> message bodies between clients and services. This enables clients >>>>> and services to establish secure connections using TLS at the >>>>> application layer, and treat any middleboxes that are intercepting >>>>> traffic at the network layer as untrusted transport. In short, this >>>>> mechanism moves the TLS handshake up the OSI stack to the >>>>> application >>>>> layer. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>> >> > --f403045e368e24b8b9055ccb5ee2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't understand why ATLS allows the app to be less = "aware" than HTTP CONNECT.=C2=A0 I also don't understand how = an ATLS client is closer to "one code path" than HTTP CONNECT.=C2= =A0 It seems to me that your description of client behavior applies equally= to ATLS and HTTP CONNECT.

On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes <rlb@ipv.sx= > wrote:
But I= agree, it would be good to have some more clarity around use cases and why= not other solutions.

On Mon, Oct 30, 2017 = at 6:37 PM, Richard Barnes <rlb@ipv.sx> wrote:
HTTP CONNECT is not great for some use cases= because it requires the app to be aware that it's dealing with a proxy= .=C2=A0 It's simpler if you can just have one code path that works whet= her your TLS is intermediated or not.=C2=A0 With the solution outlined in t= he draft, you can just always ignore the certificate the server sends in th= e first TLS connection (because it might be from a MitM), and then do all y= our cert validation, pin checks, etc. at the application layer.

On Mon, Oc= t 30, 2017 at 6:26 PM, Ben Schwartz <bemasc@google.com> wrot= e:
Why not use HTTP CONN= ECT?=C2=A0 Or rather, it would be helpful to have a section on when/why one= would do this vs. CONNECT.

On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes &= lt;rlb@ipv.sx> wrote:
Hey TLS= folks,

Owen, Max, and I have been kicking around = some ideas for how to make secure connections in environments where HTTPS i= s subject to MitM / proxying.

The below draft lays= out a way to tunnel TLS over HTTPS, in hopes of creating a channel you cou= ld use when you really need things to be private, even from the local MitM.= =C2=A0

Feedback obviously very welcome.=C2=A0= Interested in whether folks think this is a useful area in which to develo= p an RFC, and any thoughts on how to do this better.

Thanks,
--Richard


On Mon, Oct 30, 2017 at 3:4= 7 PM, <internet-drafts@ietf.org> wrote:

A new version of I-D, draft-friel-tls-over-http-00.txt
has been successfully submitted by Owen Friel and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-friel-tls-over-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Layer TLS
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-friel-tls-ov= er-http-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-friel-tls-over-http-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http= -00


Abstract:
=C2=A0 =C2=A0Many clients need to establish secure connections to applicati= on
=C2=A0 =C2=A0services but face challenges establishing these connections du= e to
=C2=A0 =C2=A0the presence of middleboxes that terminate TLS connections fro= m the
=C2=A0 =C2=A0client and restablish new TLS connections to the service.=C2= =A0 This
=C2=A0 =C2=A0document defines a mechanism for transporting TLS records in H= TTP
=C2=A0 =C2=A0message bodies between clients and services.=C2=A0 This enable= s clients
=C2=A0 =C2=A0and services to establish secure connections using TLS at the<= br> =C2=A0 =C2=A0application layer, and treat any middleboxes that are intercep= ting
=C2=A0 =C2=A0traffic at the network layer as untrusted transport.=C2=A0 In = short, this
=C2=A0 =C2=A0mechanism moves the TLS handshake up the OSI stack to the appl= ication
=C2=A0 =C2=A0layer.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls





--f403045e368e24b8b9055ccb5ee2-- --f403045e368e2e84e3055ccb5e14 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t /WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo 7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm 9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/ UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDKKufb3oO0D/Kq6Fs/Qdu9 03jyIqo8JnzWT7r4Zl2fGTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzEwMzAyMjQzMzFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAAjgVbe9k9kDflRoE0wCCR+kvOQBDiGAi/koAv1y9 K7FFP01ZvwPiI4DcguEiLPLtg/VlOFafacma0CeiVZSsVXIzCpEoP36mASZqqb5CYJdA44vT7MSn BYKjoB/dvH+vVtAY8eeizxnR2p3G2dKKEhv/Rm5I4XClujTQy2JGfPqNzf8azlEHmnAPXwQ3txAS jniJ626F3dbFe22sgHBRAkQKQ5iHzRn3fpziPw2wdJGrivbPM0jIPvUBQCD7cowDYb5pDbXObNdJ Dkfomk8jjWH8oN8eBABBBi+Sb18oIT3UEDUUeyGhE1DrpGQlJBxFZGAMZsFCAQFcf7DJwgME/g== --f403045e368e2e84e3055ccb5e14-- From nobody Mon Oct 30 15:56:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AEB13F48E for ; Mon, 30 Oct 2017 15:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 7pVchpuUX-JG for ; Mon, 30 Oct 2017 15:56:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F67913F43F for ; Mon, 30 Oct 2017 15:56:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 143AABE74; Mon, 30 Oct 2017 22:56:07 +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 EjdYlV-cx-KY; Mon, 30 Oct 2017 22:56:02 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AA5E8BDCC; Mon, 30 Oct 2017 22:56:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509404162; bh=hZIsLaqGJu0C5gg1secEyT3Ll0pbyf8EqI3iNoIDM9g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lmpxPaFHPsoJiv5SbIyNivL2gjeYxZ6hfFf6FqKaZNtZGic34PCkzldTMqnwF6x+9 xn1vditYsy/jpo3s7gvkbi/j8do4xhjzynOvvEVT+4nvnspW9QVUn93RjlKcuyR755 XPszOown0Sat9bo6xDu0Q9WNBFwURs0kLfyWMY6U= To: Richard Barnes , "" References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2f5fba1a-2ee4-4881-7df1-b925a4468fba@cs.tcd.ie> Date: Mon, 30 Oct 2017 22:56:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dOwaxqjpphSVm4cCApQUUAOiNRLBm3mJ4" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:56:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dOwaxqjpphSVm4cCApQUUAOiNRLBm3mJ4 Content-Type: multipart/mixed; boundary="Rk3uGjKpS9AGUx2fox7Ho2MXXU3UbFtF2"; protected-headers="v1" From: Stephen Farrell To: Richard Barnes , "" Message-ID: <2f5fba1a-2ee4-4881-7df1-b925a4468fba@cs.tcd.ie> Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> In-Reply-To: --Rk3uGjKpS9AGUx2fox7Ho2MXXU3UbFtF2 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 30/10/17 22:17, Richard Barnes wrote: > Hey TLS folks, >=20 > Owen, Max, and I have been kicking around some ideas for how to make se= cure > connections in environments where HTTPS is subject to MitM / proxying. Interesting. One bit puzzles me: wouldn't the new content-type give the game away and cause middleboxes to block this? S. >=20 > The below draft lays out a way to tunnel TLS over HTTPS, in hopes of > creating a channel you could use when you really need things to be priv= ate, > even from the local MitM. >=20 > Feedback obviously very welcome. Interested in whether folks think thi= s is > a useful area in which to develop an RFC, and any thoughts on how to do= > this better. >=20 > Thanks, > --Richard >=20 >=20 > On Mon, Oct 30, 2017 at 3:47 PM, wrote: >=20 >> >> A new version of I-D, draft-friel-tls-over-http-00.txt >> has been successfully submitted by Owen Friel and posted to the >> IETF repository. >> >> Name: draft-friel-tls-over-http >> Revision: 00 >> Title: Application-Layer TLS >> Document date: 2017-10-30 >> Group: Individual Submission >> Pages: 20 >> URL: https://www.ietf.org/internet-drafts/draft-friel-tls-o= ver- >> http-00.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-friel-tls-over-http/ >> Htmlized: https://tools.ietf.org/html/draft-friel-tls-over-http-= 00 >> Htmlized: https://datatracker.ietf.org/ >> doc/html/draft-friel-tls-over-http-00 >> >> >> Abstract: >> Many clients need to establish secure connections to application >> services but face challenges establishing these connections due to >> the presence of middleboxes that terminate TLS connections from the= >> client and restablish new TLS connections to the service. This >> document defines a mechanism for transporting TLS records in HTTP >> message bodies between clients and services. This enables clients >> and services to establish secure connections using TLS at the >> application layer, and treat any middleboxes that are intercepting >> traffic at the network layer as untrusted transport. In short, thi= s >> mechanism moves the TLS handshake up the OSI stack to the applicati= on >> layer. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --Rk3uGjKpS9AGUx2fox7Ho2MXXU3UbFtF2-- --dOwaxqjpphSVm4cCApQUUAOiNRLBm3mJ4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ964BAAoJEC88hzaAX42izLAIAKLTd4Rl6vGbN39qZsS42/JS e8/om8rw3vZG8pFLiZ+4/1OG8IYnI5BsnpjcqELBldhS1lBhPwLxLa6Ad5LcTsOJ n69xostDUFXuYRzwgNseMYy8eyhHT12isICYl4OHPWcW8h/gkXPlRk68dZFhp10e LDFhS35jT6AvVNbK5mWtPWzJMYU4BA0IjNC2brUgrwCpxnHTqcr6wu7oTlfSsIc8 LW1OhHCTTGYr9Lt4KIMFRBntRtwsVCsEbdD4/iCmMiknB+1q7wDvHRAw+coFnlIj 9wv5IyDT/1aOG3/cqdW+MzJa393nWFiUtY9z+ze/TNwsHKn6QbgoS5rzx/Irxu8= =aO4y -----END PGP SIGNATURE----- --dOwaxqjpphSVm4cCApQUUAOiNRLBm3mJ4-- From nobody Mon Oct 30 16:02:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16E813FC70 for ; Mon, 30 Oct 2017 16:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL_9sK8wQTRF for ; Mon, 30 Oct 2017 16:02:41 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 775B71C943C for ; Mon, 30 Oct 2017 16:02:19 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id l8so14211055wre.12 for ; Mon, 30 Oct 2017 16:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cNA3wAtsIHwbpwpy8pRv04sQH4JgsYqPpdsbo6mVSiw=; b=YZjaN5vTJd3NtwAS6IgKcHUbKaHYhjCtk7yNDJFHk2NYmL2Zh/6E2GEJ8co2d1YQPS 7d+yRKijw8SicBWOXa/gQMAbDQ2Qo+0wSyTQyqS9B/hKDFH9ahVEMa/1eyVEOBYcbedH 1IXHNfI1aPxqTWDtVTiwWGjCElM09808foW3p9hz4eNGTQDUNZV+wfcy6UQ8DpS5hFut UTyHsjgQzEXru8JUByANEjDIEhkNnLdNSsrGMETUadjU+/FJ09UqDCAl2BtBEttJS5qo MFC1uCtI7eX1x05DmoEDlt/pmD6Fp7p9EUxb7VmBI0q6+a0aI86m7tYToeDhHjeVZ7eN zsEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cNA3wAtsIHwbpwpy8pRv04sQH4JgsYqPpdsbo6mVSiw=; b=QxX8aKUGsEiHoTN94eCw7YVhynPB3oeNiTgQHiUgGJ89HHbrTJTIX5dlWIbQ/4dTJQ fC0/zTp2FwLskG4QuC4yfuiijaXhn1WwgJKF/HkPa7WLN81saAIeZ82f9RZAW42nDPQK O6uyRxtexAaGM90fbFNqmDx/cy7VUhbNmJ99SCcBmMNHnFUdMcwoMT+ipketMV01LIXl XuSH4PzcL7aZfMFsWgwieVqxfoGdq+mFKc9jfynzChvbZXmOuav6UKlpC5zew8G1tzNv oo+ZsomYOnfJsL15s6PHHSbCo8VX2WQMJ9AOynZ6e4i3/tQAJoUTnJMus9WvGrYmiHAn H/lw== X-Gm-Message-State: AMCzsaVf1mQc3Gw3fv8f+D0x4S0mpLt/RLfSBdaiQlB4aN+pEvUDrCXk /Dwbm/WJi8naUIXag5vQQhJfA2n7LqEH+Ur9WPzmNA== X-Google-Smtp-Source: ABhQp+Qe2FRltNNmVz+X5e/1rdGehAqi8BmTIk9vAw/BD9U1mKVCzEsJyUlIM5vsshnSKWdsH/lEnhPVAjEXp6OQyGE= X-Received: by 10.223.136.170 with SMTP id f39mr7994596wrf.162.1509404537804; Mon, 30 Oct 2017 16:02:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Mon, 30 Oct 2017 16:02:17 -0700 (PDT) In-Reply-To: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Mon, 30 Oct 2017 19:02:17 -0400 Message-ID: To: Ben Schwartz Cc: "" Content-Type: multipart/alternative; boundary="001a11460aac4c6d5d055ccba168" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:02:44 -0000 --001a11460aac4c6d5d055ccba168 Content-Type: text/plain; charset="UTF-8" It requires awareness in the following sense: If by chance the client is in a nice, open network and the base TLS connection goes directly to the server, CONNECT is kind of unnatural; you would want the client to do something different in that case. You're correct that you *could* configure the server to handle connect properly, but all of the options for doing this are kind of cumbersome -- either you have to stick a possibly-unnecessary proxy in front of the server, or handle CONNECT on the server, which is not really well-supported by web application frameworks. By contrast, running data over POST is ubiquitous. It was also pointed to me off-list that you can generate POST requests from Javascript in XHR, but not CONNECT requests. So doing this over POSTs also makes it accessible to web apps. (`emscripten libssl.a` left as an exercise to the reader.) --Richard On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz wrote: > I don't understand why ATLS allows the app to be less "aware" than HTTP > CONNECT. I also don't understand how an ATLS client is closer to "one code > path" than HTTP CONNECT. It seems to me that your description of client > behavior applies equally to ATLS and HTTP CONNECT. > > On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes wrote: > >> But I agree, it would be good to have some more clarity around use cases >> and why not other solutions. >> >> On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes wrote: >> >>> HTTP CONNECT is not great for some use cases because it requires the app >>> to be aware that it's dealing with a proxy. It's simpler if you can just >>> have one code path that works whether your TLS is intermediated or not. >>> With the solution outlined in the draft, you can just always ignore the >>> certificate the server sends in the first TLS connection (because it might >>> be from a MitM), and then do all your cert validation, pin checks, etc. at >>> the application layer. >>> >>> On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz wrote: >>> >>>> Why not use HTTP CONNECT? Or rather, it would be helpful to have a >>>> section on when/why one would do this vs. CONNECT. >>>> >>>> On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes wrote: >>>> >>>>> Hey TLS folks, >>>>> >>>>> Owen, Max, and I have been kicking around some ideas for how to make >>>>> secure connections in environments where HTTPS is subject to MitM / >>>>> proxying. >>>>> >>>>> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of >>>>> creating a channel you could use when you really need things to be private, >>>>> even from the local MitM. >>>>> >>>>> Feedback obviously very welcome. Interested in whether folks think >>>>> this is a useful area in which to develop an RFC, and any thoughts on how >>>>> to do this better. >>>>> >>>>> Thanks, >>>>> --Richard >>>>> >>>>> >>>>> On Mon, Oct 30, 2017 at 3:47 PM, wrote: >>>>> >>>>>> >>>>>> A new version of I-D, draft-friel-tls-over-http-00.txt >>>>>> has been successfully submitted by Owen Friel and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Name: draft-friel-tls-over-http >>>>>> Revision: 00 >>>>>> Title: Application-Layer TLS >>>>>> Document date: 2017-10-30 >>>>>> Group: Individual Submission >>>>>> Pages: 20 >>>>>> URL: https://www.ietf.org/internet- >>>>>> drafts/draft-friel-tls-over-http-00.txt >>>>>> Status: https://datatracker.ietf.org/ >>>>>> doc/draft-friel-tls-over-http/ >>>>>> Htmlized: https://tools.ietf.org/html/d >>>>>> raft-friel-tls-over-http-00 >>>>>> Htmlized: https://datatracker.ietf.org/ >>>>>> doc/html/draft-friel-tls-over-http-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> Many clients need to establish secure connections to application >>>>>> services but face challenges establishing these connections due to >>>>>> the presence of middleboxes that terminate TLS connections from the >>>>>> client and restablish new TLS connections to the service. This >>>>>> document defines a mechanism for transporting TLS records in HTTP >>>>>> message bodies between clients and services. This enables clients >>>>>> and services to establish secure connections using TLS at the >>>>>> application layer, and treat any middleboxes that are intercepting >>>>>> traffic at the network layer as untrusted transport. In short, >>>>>> this >>>>>> mechanism moves the TLS handshake up the OSI stack to the >>>>>> application >>>>>> layer. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>> >>>>> >>>> >>> >> > --001a11460aac4c6d5d055ccba168 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It requires awareness in the following sense: If by c= hance the client is in a nice, open network and the base TLS connection goe= s directly to the server, CONNECT is kind of unnatural; you would want the = client to do something different in that case.=C2=A0 You're correct tha= t you *could* configure the server to handle connect properly, but all of t= he options for doing this are kind of cumbersome -- either you have to stic= k a possibly-unnecessary proxy in front of the server, or handle CONNECT on= the server, which is not really well-supported by web application framewor= ks.=C2=A0 By contrast, running data over POST is ubiquitous.

It was also pointed = to me off-list that you can generate POST requests from Javascript in XHR, = but not CONNECT requests.=C2=A0 So doing this over POSTs also makes it acce= ssible to web apps.=C2=A0 (`emscripten libssl.a` left as an exercise to the= reader.)

--Richard


On Mon, Oct 30, 2017 = at 6:43 PM, Ben Schwartz <bemasc@google.com> wrote:
I don= 't understand why ATLS allows the app to be less "aware" than= HTTP CONNECT.=C2=A0 I also don't understand how an ATLS client is clos= er to "one code path" than HTTP CONNECT.=C2=A0 It seems to me tha= t your description of client behavior applies equally to ATLS and HTTP CONN= ECT.

On Mon, Oct 30, 2017 at 6:38 PM, Richard B= arnes <rlb@ipv.sx> wrote:
But I agree, it would be good to have some more clarity around us= e cases and why not other solutions.

On Mon, Oct 30, 2017 at 6:37 PM, Richar= d Barnes <rlb@ipv.sx> wrote:
HTTP CONNECT is not great for some use cases because it requir= es the app to be aware that it's dealing with a proxy.=C2=A0 It's s= impler if you can just have one code path that works whether your TLS is in= termediated or not.=C2=A0 With the solution outlined in the draft, you can = just always ignore the certificate the server sends in the first TLS connec= tion (because it might be from a MitM), and then do all your cert validatio= n, pin checks, etc. at the application layer.

On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz <bemasc@google= .com> wrote:
Why not use HTTP CONNECT?=C2=A0 Or rather, it would be helpful to have a= section on when/why one would do this vs. CONNECT.

On Mon, Oct 30, 2017 at= 6:17 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey TLS folks,

Owen, Max, and I have been kicking around some ideas= for how to make secure connections in environments where HTTPS is subject = to MitM / proxying.

The below draft lays out a way= to tunnel TLS over HTTPS, in hopes of creating a channel you could use whe= n you really need things to be private, even from the local MitM.=C2=A0

Feedback obviously very welcome.=C2=A0 Intereste= d in whether folks think this is a useful area in which to develop an RFC, = and any thoughts on how to do this better.

Tha= nks,
--Richard


On Mon, Oct 30, 2017 at 3:47 PM, <internet-drafts@ietf.org> wrote:

A new version of I-D, draft-friel-tls-over-http-00.txt
has been successfully submitted by Owen Friel and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-friel-tls-over-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Layer TLS
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-friel-tls-ov= er-http-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-friel-tls-over-http-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http= -00


Abstract:
=C2=A0 =C2=A0Many clients need to establish secure connections to applicati= on
=C2=A0 =C2=A0services but face challenges establishing these connections du= e to
=C2=A0 =C2=A0the presence of middleboxes that terminate TLS connections fro= m the
=C2=A0 =C2=A0client and restablish new TLS connections to the service.=C2= =A0 This
=C2=A0 =C2=A0document defines a mechanism for transporting TLS records in H= TTP
=C2=A0 =C2=A0message bodies between clients and services.=C2=A0 This enable= s clients
=C2=A0 =C2=A0and services to establish secure connections using TLS at the<= br> =C2=A0 =C2=A0application layer, and treat any middleboxes that are intercep= ting
=C2=A0 =C2=A0traffic at the network layer as untrusted transport.=C2=A0 In = short, this
=C2=A0 =C2=A0mechanism moves the TLS handshake up the OSI stack to the appl= ication
=C2=A0 =C2=A0layer.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls






--001a11460aac4c6d5d055ccba168-- From nobody Mon Oct 30 16:26:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA90C9F8 for ; Mon, 30 Oct 2017 16:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=lVqeR2Ym; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ofhiU0vD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze9xIq7Pga6K for ; Mon, 30 Oct 2017 16:26:14 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3125913F57C for ; Mon, 30 Oct 2017 16:26:14 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8714C20BC4; Mon, 30 Oct 2017 19:26:13 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 30 Oct 2017 19:26:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=KU+ITxp+p/EStVjPHdgVcO57mVONU H6n//YLfJ4x2v0=; b=lVqeR2YmEjEN1+G3/4y31ykqeAyycq+Pl0tU5Sv6p4vKx qHjk54Beg5ai6Tj5KSAY3Nmf13zULYiHuGTkJ6K5tzKwdVbKu/q9SxXP3yGKlst+ YCzXO8SsiWbz7ni80wC/e4qErPl64dkjy9yv+vop69s0vDe/NYEAs4/agtQn6mT3 Wc2XFOgo6QusBBtyoZqGgRYBWP+sa7dSVB9XmEue+HaKjDYwJHclTDrOKLGxpDmL YBYHgswGHqfB1laV/9wMWUQKoEVwN6tcMqGaC3IMnD7l9GliBV3BO0HRUewq7Mwx 08jrU6p5/y9Hz1dza1zhxtq2J9IQPbvsh+3JhSvbA== 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-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KU+ITx p+p/EStVjPHdgVcO57mVONUH6n//YLfJ4x2v0=; b=ofhiU0vD67APsHM6FbfcjP p+1VnaqkcoXA0r9gT7zGeeasAQYAV/dQ6wAucr4gwHnQjwkoaLPjN3iUOgRPpgIM qqoYIXLDhzP0ec6OAT92aVWu95NqYSZ9Js4dkzcMwmpzkH+hoXPEVKEsrIZeVRin z1h51deULVi3uL8G1BDy9AvqnOazqL9Ng2N3/BhkGr6TU76MP12YitA/Oks1Z/eY nl79MYcbulZWiZ8gMgO4wscJoZcThTfTr/gVujwcngCf2H3euzycdsykz2MOtYXb ke71TyOrENHXV7tjOoaXe4EA+Hq2zQpDVpRI4r2EVAwVUAyndhvwd9vaVrIMpksw == X-ME-Sender: Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 99220244C7; Mon, 30 Oct 2017 19:26:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Mark Nottingham In-Reply-To: Date: Tue, 31 Oct 2017 10:26:11 +1100 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: <3E00833D-ED75-4F60-B655-0DE4D324C82B@mnot.net> References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> To: Richard Barnes X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:26:17 -0000 Please consult with the HTTP WG *before* you start work in this area. Thanks, > On 31 Oct 2017, at 9:17 am, Richard Barnes wrote: >=20 > Hey TLS folks, >=20 > Owen, Max, and I have been kicking around some ideas for how to make = secure connections in environments where HTTPS is subject to MitM / = proxying. >=20 > The below draft lays out a way to tunnel TLS over HTTPS, in hopes of = creating a channel you could use when you really need things to be = private, even from the local MitM. =20 >=20 > Feedback obviously very welcome. Interested in whether folks think = this is a useful area in which to develop an RFC, and any thoughts on = how to do this better. >=20 > Thanks, > --Richard >=20 >=20 > On Mon, Oct 30, 2017 at 3:47 PM, wrote: >=20 > A new version of I-D, draft-friel-tls-over-http-00.txt > has been successfully submitted by Owen Friel and posted to the > IETF repository. >=20 > Name: draft-friel-tls-over-http > Revision: 00 > Title: Application-Layer TLS > Document date: 2017-10-30 > Group: Individual Submission > Pages: 20 > URL: = https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt > Status: = https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ > Htmlized: = https://tools.ietf.org/html/draft-friel-tls-over-http-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 >=20 >=20 > Abstract: > Many clients need to establish secure connections to application > services but face challenges establishing these connections due to > the presence of middleboxes that terminate TLS connections from the > client and restablish new TLS connections to the service. This > document defines a mechanism for transporting TLS records in HTTP > message bodies between clients and services. This enables clients > and services to establish secure connections using TLS at the > application layer, and treat any middleboxes that are intercepting > traffic at the network layer as untrusted transport. In short, = this > mechanism moves the TLS handshake up the OSI stack to the = application > layer. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Mark Nottingham https://www.mnot.net/ From nobody Mon Oct 30 18:35:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8B313FBF0 for ; Mon, 30 Oct 2017 18:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsk2A01kr8N2 for ; Mon, 30 Oct 2017 18:35:18 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 6BBE413EDE3 for ; Mon, 30 Oct 2017 18:35:18 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id s41so10908555uab.10 for ; Mon, 30 Oct 2017 18:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3Dt2yj1ac7mk2ZS3WFSp5jrDw8C4cwOY19cvmJBeZQg=; b=vxwLzVeBujMENaKQWQhTrAivo0KPVLBCKnmBIHYw5xrdIYnxBUvEZvsNZ+Q8cFDUwe o5GnPRNgY7fgWJ94Vre4OIaL31rCQss4FsXPqZxejj/pCpP04zOMI5pXE2XtMn969fG+ IcA/uVzthJa3Byvq/lmMUAu0CBDvZL7YCVHcEWn8/dI59oP+lfmsfxtZKi4IV375HRb4 DCTsRWS5yB1BPxzfYPYxjMNdbD5cOMaS46fZJ6r4ZUEuAdOSP5gCcr+aErXBOTXlkpg/ 4cqs6NJdA7h0HDOKxblEy/FyWLhd1KnaPdyGs0mG2nzPemCDOHCZgzsUqzwlv/Rxmglm 1cQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Dt2yj1ac7mk2ZS3WFSp5jrDw8C4cwOY19cvmJBeZQg=; b=YeLWg0fpFDfTVGUJFDjNEJWbrRDhY5pImeayPKMinpMLOd6pcf81CwobPo0k8bigmi gkIZRPjoTdPHctQo9THENXZS6+MmG6S27pwgyCLaMb+/s2B/U51P9qRLrTBRKIScEz7v jgHfiAPw3WoI08jTWE6yeMtyz5FL9DuzAr+5zTCxgwXM3Hezgo6KAovKHJWstECFHK98 h9I4j+u/BiRIABWTEvorudU7IDcJgJEDuzY0vy+vWKjjReVJ+XcNvROBFg+uc8Kwo9YS V1y/XiEk8bvucLeEjzHjEAczuyIW0SPgubB7+SQuSFU3LrFLgcXlX6mgbIqaY/9n6dLB Zqvg== X-Gm-Message-State: AMCzsaX38Tl8vOGXPNRW9fbdAvE6m4v88coy7jIYKxdfFyEb9xpGKjQU yLIGpC6WecMbclWc7br26vDW7vDvvQVSALeuLjbGOORy X-Google-Smtp-Source: ABhQp+Rjxtveezw1OJ+x9hYa/8AeYCdqVXYUV2WXgKTfLkoYHITCRj0oKFWBdiQkBLa2T2kPo3Pio/bjoFYrWCddFj4= X-Received: by 10.159.58.76 with SMTP id r12mr229699uag.141.1509413717109; Mon, 30 Oct 2017 18:35:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.145 with HTTP; Mon, 30 Oct 2017 18:35:16 -0700 (PDT) In-Reply-To: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Ben Schwartz Date: Mon, 30 Oct 2017 21:35:16 -0400 Message-ID: To: Richard Barnes Cc: "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="089e08e4b65d772749055ccdc477" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 01:35:22 -0000 --089e08e4b65d772749055ccdc477 Content-Type: multipart/alternative; boundary="089e08e4b65d6dd83f055ccdc4d5" --089e08e4b65d6dd83f055ccdc4d5 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes wrote: > It requires awareness in the following sense: If by chance the client is > in a nice, open network and the base TLS connection goes directly to the > server, CONNECT is kind of unnatural; you would want the client to do > something different in that case. > Surely this is equally true/untrue of ATLS. Why do double-TLS if it can be avoided? But then, how does the application know whether to do ATLS encapsulation? It's the same question in both cases. > You're correct that you *could* configure the server to handle connect > properly, but all of the options for doing this are kind of cumbersome -- > either you have to stick a possibly-unnecessary proxy in front of the > server, or handle CONNECT on the server, which is not really well-supported > by web application frameworks. By contrast, running data over POST is > ubiquitous. > This makes a certain amount of sense to me. If it were up to me, rather than design a TLS-specific transport, I'd be more inclined to propose a standardized version of something like Crowbar . (Or just document that reverse proxies and frameworks ought to do something reasonable with CONNECT.) Otherwise this seems to be ossifying the proxy, privileging TLS and preventing deployment of Noise protocol or whatever the future may hold. It was also pointed to me off-list that you can generate POST requests from > Javascript in XHR, but not CONNECT requests. So doing this over POSTs also > makes it accessible to web apps. (`emscripten libssl.a` left as an > exercise to the reader.) > It seems your threat model assumes an adversary who is an active intermediary in your HTTP session. If so, then this wouldn't seem to protect the user against the threat. > > > --Richard > > > On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz wrote: > >> I don't understand why ATLS allows the app to be less "aware" than HTTP >> CONNECT. I also don't understand how an ATLS client is closer to "one code >> path" than HTTP CONNECT. It seems to me that your description of client >> behavior applies equally to ATLS and HTTP CONNECT. >> >> On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes wrote: >> >>> But I agree, it would be good to have some more clarity around use cases >>> and why not other solutions. >>> >>> On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes wrote: >>> >>>> HTTP CONNECT is not great for some use cases because it requires the >>>> app to be aware that it's dealing with a proxy. It's simpler if you can >>>> just have one code path that works whether your TLS is intermediated or >>>> not. With the solution outlined in the draft, you can just always ignore >>>> the certificate the server sends in the first TLS connection (because it >>>> might be from a MitM), and then do all your cert validation, pin checks, >>>> etc. at the application layer. >>>> >>>> On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz >>>> wrote: >>>> >>>>> Why not use HTTP CONNECT? Or rather, it would be helpful to have a >>>>> section on when/why one would do this vs. CONNECT. >>>>> >>>>> On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes wrote: >>>>> >>>>>> Hey TLS folks, >>>>>> >>>>>> Owen, Max, and I have been kicking around some ideas for how to make >>>>>> secure connections in environments where HTTPS is subject to MitM / >>>>>> proxying. >>>>>> >>>>>> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of >>>>>> creating a channel you could use when you really need things to be private, >>>>>> even from the local MitM. >>>>>> >>>>>> Feedback obviously very welcome. Interested in whether folks think >>>>>> this is a useful area in which to develop an RFC, and any thoughts on how >>>>>> to do this better. >>>>>> >>>>>> Thanks, >>>>>> --Richard >>>>>> >>>>>> >>>>>> On Mon, Oct 30, 2017 at 3:47 PM, wrote: >>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-friel-tls-over-http-00.txt >>>>>>> has been successfully submitted by Owen Friel and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Name: draft-friel-tls-over-http >>>>>>> Revision: 00 >>>>>>> Title: Application-Layer TLS >>>>>>> Document date: 2017-10-30 >>>>>>> Group: Individual Submission >>>>>>> Pages: 20 >>>>>>> URL: https://www.ietf.org/internet- >>>>>>> drafts/draft-friel-tls-over-http-00.txt >>>>>>> Status: https://datatracker.ietf.org/ >>>>>>> doc/draft-friel-tls-over-http/ >>>>>>> Htmlized: https://tools.ietf.org/html/d >>>>>>> raft-friel-tls-over-http-00 >>>>>>> Htmlized: https://datatracker.ietf.org/ >>>>>>> doc/html/draft-friel-tls-over-http-00 >>>>>>> >>>>>>> >>>>>>> Abstract: >>>>>>> Many clients need to establish secure connections to application >>>>>>> services but face challenges establishing these connections due to >>>>>>> the presence of middleboxes that terminate TLS connections from >>>>>>> the >>>>>>> client and restablish new TLS connections to the service. This >>>>>>> document defines a mechanism for transporting TLS records in HTTP >>>>>>> message bodies between clients and services. This enables clients >>>>>>> and services to establish secure connections using TLS at the >>>>>>> application layer, and treat any middleboxes that are intercepting >>>>>>> traffic at the network layer as untrusted transport. In short, >>>>>>> this >>>>>>> mechanism moves the TLS handshake up the OSI stack to the >>>>>>> application >>>>>>> layer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission >>>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> TLS mailing list >>>>>> TLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>> >>>>>> >>>>> >>>> >>> >> > --089e08e4b65d6dd83f055ccdc4d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Oct 30, 2017 at 7:02 PM, Richard Barnes <rlb@ipv.sx> wrote:
It requires awarenes= s in the following sense: If by chance the client is in a nice, open networ= k and the base TLS connection goes directly to the server, CONNECT is kind = of unnatural; you would want the client to do something different in that c= ase.

Surely this is equally tru= e/untrue of ATLS.=C2=A0 Why do double-TLS if it can be avoided?=C2=A0 But t= hen, how does the application know whether to do ATLS encapsulation?=C2=A0 = It's the same question in both cases.
=C2=A0
=C2=A0 You're correct that yo= u *could* configure the server to handle connect properly, but all of the o= ptions for doing this are kind of cumbersome -- either you have to stick a = possibly-unnecessary proxy in front of the server, or handle CONNECT on the= server, which is not really well-supported by web application frameworks.= =C2=A0 By contrast, running data over POST is ubiquitous.

This makes a certain amount of sense to me.=C2= =A0 If it were up to me, rather than design a TLS-specific transport, I'= ;d be more inclined to propose a standardized version of something like Crowbar.=C2=A0 (Or just documen= t that reverse proxies and frameworks ought to do something reasonable with= CONNECT.)=C2=A0 Otherwise this seems to be ossifying the proxy, privilegin= g TLS and preventing deployment of=C2=A0Noise protocol=C2=A0or whatever the future may hold.
<= br>
It was also pointed to me off-list that you can generate POST requ= ests from Javascript in XHR, but not CONNECT requests.=C2=A0 So doing this = over POSTs also makes it accessible to web apps.=C2=A0 (`emscripten libssl.= a` left as an exercise to the reader.)

It seems your threat model assumes an adversary who is an active in= termediary in your HTTP session.=C2=A0 If so, then this wouldn't seem t= o protect the user against the threat.
=C2=A0


--Richard
<= div class=3D"gmail_extra">

On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz <be= masc@google.com> wrote:
I don't understand why ATLS al= lows the app to be less "aware" than HTTP CONNECT.=C2=A0 I also d= on't understand how an ATLS client is closer to "one code path&quo= t; than HTTP CONNECT.=C2=A0 It seems to me that your description of client = behavior applies equally to ATLS and HTTP CONNECT.

On Mon, Oct 30, 2017 at 6:3= 8 PM, Richard Barnes <rlb@ipv.sx> wrote:
But I agree, it would be good to have some more cl= arity around use cases and why not other solutions.

On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes <rlb@ipv.sx= > wrote:
HTTP = CONNECT is not great for some use cases because it requires the app to be a= ware that it's dealing with a proxy.=C2=A0 It's simpler if you can = just have one code path that works whether your TLS is intermediated or not= .=C2=A0 With the solution outlined in the draft, you can just always ignore= the certificate the server sends in the first TLS connection (because it m= ight be from a MitM), and then do all your cert validation, pin checks, etc= . at the application layer.

On Mon, Oct 30, 2017 at 6:26 PM, Ben = Schwartz <bemasc@google.com> wrote:
Why not use HTTP CONNECT?=C2=A0 Or rather, it w= ould be helpful to have a section on when/why one would do this vs. CONNECT= .

On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes <rlb@ipv.s= x> wrote:
=
Hey TLS folks,
=
Owen, Max, and I have been kicking around some ideas for how= to make secure connections in environments where HTTPS is subject to MitM = / proxying.

The below draft lays out a way to tunn= el TLS over HTTPS, in hopes of creating a channel you could use when you re= ally need things to be private, even from the local MitM.=C2=A0
<= div>
Feedback obviously very welcome.=C2=A0 Interested in whe= ther folks think this is a useful area in which to develop an RFC, and any = thoughts on how to do this better.

Thanks,
=
--Richard

On Mon, Oct 30, 2017 at 3:47 PM, <inte= rnet-drafts@ietf.org> wrote:
https://www.ietf.org/internet-drafts/draft-friel-tls-ov= er-http-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-friel-tls-over-http-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http= -00


Abstract:
=C2=A0 =C2=A0Many clients need to establish secure connections to applicati= on
=C2=A0 =C2=A0services but face challenges establishing these connections du= e to
=C2=A0 =C2=A0the presence of middleboxes that terminate TLS connections fro= m the
=C2=A0 =C2=A0client and restablish new TLS connections to the service.=C2= =A0 This
=C2=A0 =C2=A0document defines a mechanism for transporting TLS records in H= TTP
=C2=A0 =C2=A0message bodies between clients and services.=C2=A0 This enable= s clients
=C2=A0 =C2=A0and services to establish secure connections using TLS at the<= br> =C2=A0 =C2=A0application layer, and treat any middleboxes that are intercep= ting
=C2=A0 =C2=A0traffic at the network layer as untrusted transport.=C2=A0 In = short, this
=C2=A0 =C2=A0mechanism moves the TLS handshake up the OSI stack to the appl= ication
=C2=A0 =C2=A0layer.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls







--089e08e4b65d6dd83f055ccdc4d5-- --089e08e4b65d772749055ccdc477 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t /WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo 7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm 9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/ UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCt6xjf3YtPbG65dJKkfjw+ gqY14FHdNt60outbaeZ7qTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzEwMzEwMTM1MTdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAzKbSzgOomKPZmdc0RIwofX/ECoSUczzOIb5O6j1f qt8uRfotCDB4Qum5+vbis2BoKA0xvdci+g3xP4PC18cmLOHPnMvUb2FWonoEDnXKjtMuaiylDYvb b+cfJSUkYRZBJjHwU7Q5TkzNAv86+TYOzr6oUJK9O6/wAkkhbKWJgP+2Y7d0v49X42hjkdNZf127 0vfTGX1KxK6k4WXvx/Uz3UNb59kV1jBaElUT6a8l7X0UC4DkWt6nzS76T2QIP87bLshwMnXw+YrE a0nO8UtWlwzMBBLRu0Er4L6Zeu/cldhjAepNMNxtQpZ15Wl6FbsxGHvYsNv0stg67AOM8BZbNQ== --089e08e4b65d772749055ccdc477-- From nobody Tue Oct 31 13:07:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D027013F689 for ; Tue, 31 Oct 2017 13:07:20 -0700 (PDT) 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 mfK2J2TvU0x3 for ; Tue, 31 Oct 2017 13:07:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1072C13F68D for ; Tue, 31 Oct 2017 13:07:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C348DBE8A for ; Tue, 31 Oct 2017 20:07:07 +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 0BqHy4Ic0Xaz for ; Tue, 31 Oct 2017 20:07:06 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EE4AFBE80 for ; Tue, 31 Oct 2017 20:07:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509480426; bh=i22hMJWvclhxcghdglZ80QRf1FzzVkr29O038q1ZD/4=; h=Subject:References:To:From:Date:In-Reply-To:From; b=nzpDb1KP7jWCvvEfHaE9PNXco1o3ykDfykvTv18YyegPD3tN7L/zEJDFSd+NLmghG WUl/at8XxIMAcywNZUbkwAwiR3eKRwtvjxrBUwOg2GBG8uzh2C2NajhyATMUxBX2x8 kOMPsVU3+WUL5UNyK9G482aDcuvSUfBEUyr+j2Sc= References: <20170726205732.784F41A6CB@ld9781.wdf.sap.corp> <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie> <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu> <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B78355@XMB116CNC.rim.net> To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <95f9078a-ab3d-28d4-c2db-34507a022af0@cs.tcd.ie> Date: Tue, 31 Oct 2017 20:07:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2akDielOWolL1BjOCl02b2TR3FV6h0xR5" Archived-At: Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 20:07:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2akDielOWolL1BjOCl02b2TR3FV6h0xR5 Content-Type: multipart/mixed; boundary="UGLs6jnJ9SPB6locrETnMndedTiIJxmD9"; protected-headers="v1" From: Stephen Farrell To: "tls@ietf.org" Message-ID: <95f9078a-ab3d-28d4-c2db-34507a022af0@cs.tcd.ie> Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's References: <20170726205732.784F41A6CB@ld9781.wdf.sap.corp> <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie> <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu> <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B78355@XMB116CNC.rim.net> In-Reply-To: --UGLs6jnJ9SPB6locrETnMndedTiIJxmD9 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, > Hasn=E2=80=99t this been the whole point of the discussion?! The propos= al to > separate PRNGs into those that supply publicly-visible randomness > (nonces, etc), and those that supply =E2=80=9Csecret=E2=80=9D randomnes= s (keying > material and such)? Thus, having *two* PRNGs, each (hopefully) > properly seeded? >=20 > I=E2=80=99m glad you=E2=80=99re now agreeing that the above is a good p= lan. >=20 This discussion we had back in July was mostly motivated by dual-ec. I think it's worth noting for the record that we now have another instance of a very similar issue. [1] Personally I think this argues for strengthening the text we include in TLS1.3 to a RECOMMENDATION, in the body of the document (as opposed to Appendix C.1 where it is now) to separate the streams of randomness along the lines described above. The basic change would be to move the 2nd paragraph of C.1 to 4.1.2 where Random is defined, maybe to add a reference to DUHK, and to insert a statement that implementers are RECOMMENDED to put in place such separation. (I don't think we need to say how they ought do that, as it's quite OS/RNG- implementation dependent.) I wonder if the new information (i.e. DUHK) convinces folks that such a change is warranted? If so, great. I'd be happy to submit a new PR or we could re-open [2] or whatever. (I'd be just as happy that the editor figure out the precise wording if that's easier.) If not, I don't we need to debate this again, nor do we need to hold up TLS1.3. If the answer to the above isn't clear from the list between now and the IETF meeting it might be worth asking the room about this in Singapore if time permits. Cheers, S. [1] https://duhkattack.com/ [2] https://github.com/tlswg/tls13-spec/pull/1068 --UGLs6jnJ9SPB6locrETnMndedTiIJxmD9-- --2akDielOWolL1BjOCl02b2TR3FV6h0xR5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+NfpAAoJEC88hzaAX42ijQAH/RK7CKa2OniRMwoifVRvlNnj UupAQ6zufA5dy0VtqUSd/ojjgv6B9Rp1ChfjN0FWfxG1effHXDymvZjf0riK1t4o sfgPR4OvTEMxG5Ug7an4J2RPC+YfD+SyuLC7D7SWNMQHU/h93tqPJVmzNcGR9NPO UEAqKviOLSbwiT0T3DWi+OZmabjuA3Xk67juAPhkw6/l/3h0pgTaaiYweaESpe9C 8F1JnFCU2wOYpD4U1hiyTTiRszGvMeETBkdRCWKqrSFvX0fQR0QELITHJw6YXIqL jQvG1ZyDQ9POsZIC/bQfUn/x7fGFgJVoOPOngU6wyD9EOAC/iqu1GWjx321KLq4= =HP+K -----END PGP SIGNATURE----- --2akDielOWolL1BjOCl02b2TR3FV6h0xR5-- From nobody Tue Oct 31 14:03:39 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9779813F679 for ; Tue, 31 Oct 2017 14:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 aUZT73Ywl2Bg for ; Tue, 31 Oct 2017 14:03:36 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DAF213875A for ; Tue, 31 Oct 2017 14:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4660; q=dns/txt; s=iport; t=1509483816; x=1510693416; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=s8oTIGzQ/qk/hwgqrgDMowQlZhlFOSUbIvua0qSV/CY=; b=hIe6dRm19G7fGhV5OvwDDsiuCIFFKqYUp9o+rQZKd8+biZG8YrlGKV2t /G2LmktrCVB7mPrtE1qkwHRp329uw3PyAMyAPqyE6Duo3CF3AjTmyZ4Hi q7KDGdby75PxK2QAJY8x2vd/hCUP8EolX8+L2tutnHLIn6cjysjlQLD9O M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAABu5PhZ/5RdJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNfZG4nB4N1ih+REpZCghEKGAuFGAIahFo/GAECAQEBAQEBAWs?= =?us-ascii?q?ohR0BAQEBAwEBIRE6CQ4EAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBEgiKGxCoc?= =?us-ascii?q?IIniw4BAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQ+CH4IHgVOBaYMqgiSCQ0GCfoJ?= =?us-ascii?q?hBZFbkCsCh2SNDYIeXoUiixmMX4kGAhEZAYE4AR84gWt6FR8qgmQJglAfgWd3i?= =?us-ascii?q?1WBEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,326,1505779200"; d="scan'208";a="24853887" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2017 21:03:35 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v9VL3ZQn032276 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Oct 2017 21:03:35 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 31 Oct 2017 16:03:34 -0500 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Tue, 31 Oct 2017 16:03:34 -0500 From: "Owen Friel (ofriel)" To: Stephen Farrell , Richard Barnes , "" Thread-Topic: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt Thread-Index: AQHTUbfdWlszSrswCU+9CVrREn/H1KL9SjIAgAAKs4CAARHUsA== Date: Tue, 31 Oct 2017 21:03:34 +0000 Message-ID: <9989a0aee6784a7ba96bda23cf51d69b@XCH-RCD-012.cisco.com> References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <2f5fba1a-2ee4-4881-7df1-b925a4468fba@cs.tcd.ie> In-Reply-To: <2f5fba1a-2ee4-4881-7df1-b925a4468fba@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.243.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 21:03:39 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVExTIFttYWlsdG86dGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNCj4gU2VudDog MzAgT2N0b2JlciAyMDE3IDIyOjU2DQo+IFRvOiBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeD47 IDx0bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbVExTXSBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZyaWVsLXRscy1vdmVyLWh0dHAtMDAudHh0 DQo+IA0KPiANCj4gDQo+IE9uIDMwLzEwLzE3IDIyOjE3LCBSaWNoYXJkIEJhcm5lcyB3cm90ZToN Cj4gPiBIZXkgVExTIGZvbGtzLA0KPiA+DQo+ID4gT3dlbiwgTWF4LCBhbmQgSSBoYXZlIGJlZW4g a2lja2luZyBhcm91bmQgc29tZSBpZGVhcyBmb3IgaG93IHRvIG1ha2UNCj4gPiBzZWN1cmUgY29u bmVjdGlvbnMgaW4gZW52aXJvbm1lbnRzIHdoZXJlIEhUVFBTIGlzIHN1YmplY3QgdG8gTWl0TSAv DQo+IHByb3h5aW5nLg0KPiANCj4gSW50ZXJlc3RpbmcuIE9uZSBiaXQgcHV6emxlcyBtZTogd291 bGRuJ3QgdGhlIG5ldyBjb250ZW50LXR5cGUgZ2l2ZSB0aGUgZ2FtZQ0KPiBhd2F5IGFuZCBjYXVz ZSBtaWRkbGVib3hlcyB0byBibG9jayB0aGlzPw0KPiANCj4gUy4NCj4gDQoNCltvZnJpZWxdIFRo ZSBpbnRlbnRpb24gaXNu4oCZdCB0byB0cnkgYW5kIG9ic2N1cmUgdGhlIGZhY3QgdGhhdCB0aGVy ZSBpcyBhbiBBVExTIHNlc3Npb24uIEV2ZW4gaWYgdGhhdCBuZXcgY29udGVudC10eXBlIHdhcyBu b3QgZGVmaW5lZCwgaXQgd291bGQgYmUgZWFzeSB0byB3cml0ZSBhIHNpbXBsZSBwYXR0ZXJuIG1h dGNoIHNjcmlwdCBvbiB0aGUgbWlkZGxlYm94IHRvIGlkZW50aXR5IHRoZSBKU09OIGJvZHkgYW5k IGxlYWRpbmcgYmFzZTY0IGJ5dGVzIG9mIHRoZSBUTFMgcmVjb3JkcyBpbiB0aGUgYm9keS4NCg0K DQo+ID4NCj4gPiBUaGUgYmVsb3cgZHJhZnQgbGF5cyBvdXQgYSB3YXkgdG8gdHVubmVsIFRMUyBv dmVyIEhUVFBTLCBpbiBob3BlcyBvZg0KPiA+IGNyZWF0aW5nIGEgY2hhbm5lbCB5b3UgY291bGQg dXNlIHdoZW4geW91IHJlYWxseSBuZWVkIHRoaW5ncyB0byBiZQ0KPiA+IHByaXZhdGUsIGV2ZW4g ZnJvbSB0aGUgbG9jYWwgTWl0TS4NCj4gPg0KPiA+IEZlZWRiYWNrIG9idmlvdXNseSB2ZXJ5IHdl bGNvbWUuICBJbnRlcmVzdGVkIGluIHdoZXRoZXIgZm9sa3MgdGhpbmsNCj4gPiB0aGlzIGlzIGEg dXNlZnVsIGFyZWEgaW4gd2hpY2ggdG8gZGV2ZWxvcCBhbiBSRkMsIGFuZCBhbnkgdGhvdWdodHMg b24NCj4gPiBob3cgdG8gZG8gdGhpcyBiZXR0ZXIuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gLS1S aWNoYXJkDQo+ID4NCj4gPg0KPiA+IE9uIE1vbiwgT2N0IDMwLCAyMDE3IGF0IDM6NDcgUE0sIDxp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KPiA+DQo+ID4+DQo+ID4+IEEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLTAwLnR4dCBoYXMgYmVlbg0K PiA+PiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE93ZW4gRnJpZWwgYW5kIHBvc3RlZCB0byB0 aGUgSUVURg0KPiA+PiByZXBvc2l0b3J5Lg0KPiA+Pg0KPiA+PiBOYW1lOiAgICAgICAgICAgZHJh ZnQtZnJpZWwtdGxzLW92ZXItaHR0cA0KPiA+PiBSZXZpc2lvbjogICAgICAgMDANCj4gPj4gVGl0 bGU6ICAgICAgICAgIEFwcGxpY2F0aW9uLUxheWVyIFRMUw0KPiA+PiBEb2N1bWVudCBkYXRlOiAg MjAxNy0xMC0zMA0KPiA+PiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ ID4+IFBhZ2VzOiAgICAgICAgICAyMA0KPiA+PiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZyaWVsLXRscy1vdmVyLQ0KPiA+PiBodHRw LTAwLnR4dA0KPiA+PiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy8NCj4gPj4gZG9jL2RyYWZ0LWZyaWVsLXRscy1vdmVyLWh0dHAvDQo+ID4+IEh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0 cC0wMA0KPiA+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy8N Cj4gPj4gZG9jL2h0bWwvZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0cC0wMA0KPiA+Pg0KPiA+Pg0K PiA+PiBBYnN0cmFjdDoNCj4gPj4gICAgTWFueSBjbGllbnRzIG5lZWQgdG8gZXN0YWJsaXNoIHNl Y3VyZSBjb25uZWN0aW9ucyB0byBhcHBsaWNhdGlvbg0KPiA+PiAgICBzZXJ2aWNlcyBidXQgZmFj ZSBjaGFsbGVuZ2VzIGVzdGFibGlzaGluZyB0aGVzZSBjb25uZWN0aW9ucyBkdWUgdG8NCj4gPj4g ICAgdGhlIHByZXNlbmNlIG9mIG1pZGRsZWJveGVzIHRoYXQgdGVybWluYXRlIFRMUyBjb25uZWN0 aW9ucyBmcm9tIHRoZQ0KPiA+PiAgICBjbGllbnQgYW5kIHJlc3RhYmxpc2ggbmV3IFRMUyBjb25u ZWN0aW9ucyB0byB0aGUgc2VydmljZS4gIFRoaXMNCj4gPj4gICAgZG9jdW1lbnQgZGVmaW5lcyBh IG1lY2hhbmlzbSBmb3IgdHJhbnNwb3J0aW5nIFRMUyByZWNvcmRzIGluIEhUVFANCj4gPj4gICAg bWVzc2FnZSBib2RpZXMgYmV0d2VlbiBjbGllbnRzIGFuZCBzZXJ2aWNlcy4gIFRoaXMgZW5hYmxl cyBjbGllbnRzDQo+ID4+ICAgIGFuZCBzZXJ2aWNlcyB0byBlc3RhYmxpc2ggc2VjdXJlIGNvbm5l Y3Rpb25zIHVzaW5nIFRMUyBhdCB0aGUNCj4gPj4gICAgYXBwbGljYXRpb24gbGF5ZXIsIGFuZCB0 cmVhdCBhbnkgbWlkZGxlYm94ZXMgdGhhdCBhcmUgaW50ZXJjZXB0aW5nDQo+ID4+ICAgIHRyYWZm aWMgYXQgdGhlIG5ldHdvcmsgbGF5ZXIgYXMgdW50cnVzdGVkIHRyYW5zcG9ydC4gIEluIHNob3J0 LCB0aGlzDQo+ID4+ICAgIG1lY2hhbmlzbSBtb3ZlcyB0aGUgVExTIGhhbmRzaGFrZSB1cCB0aGUg T1NJIHN0YWNrIHRvIHRoZSBhcHBsaWNhdGlvbg0KPiA+PiAgICBsYXllci4NCj4gPj4NCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+ID4+IHRvb2xzLmlldGYu b3JnLg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+Pg0KPiA+Pg0KPiA+DQo+ ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gVExTIG1haWxpbmcgbGlzdA0KPiA+IFRMU0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+ID4NCg0K From nobody Tue Oct 31 14:03:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA6C13F6DC for ; Tue, 31 Oct 2017 14:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 7Ih14owQYc4h for ; Tue, 31 Oct 2017 14:03:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8EB13F6DF for ; Tue, 31 Oct 2017 14:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36388; q=dns/txt; s=iport; t=1509483820; x=1510693420; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5khoAl3b0Cl0LmZ+qQ3ZXBHrZN7a6lRI2cY812Bdr+8=; b=ZRQK8y5Hlo8rGXoo6CW/fSolhHsXp2sUnJF/hiYGKNT/cvy8zwIWjZMM pJoZQjoNRgGK2aTbo4/Lx3gMmP4U19v+2GxzbcQngU9/ibXcdYMor60MO zWdy1+qVfCwae4/chdJXGDLmLkhm7JnFqC7uw/pmn5tRuVpS4XfThyEeT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAACr5PhZ/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9CLmRuJweDdYofkRKCfJNGgTIDXAoYAQqBXoM6AhqEWj8YAQI?= =?us-ascii?q?BAQEBAQEBayiFHQEBAQEDAQEhCkEJAhACAQgOAwQBASEHAwICAiULFAkIAgQBC?= =?us-ascii?q?QQFCBOJJGQQqG2CJ4sOAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMugQ4nUoFTgWm?= =?us-ascii?q?CHYENhHtMCIJXgmEFii6HLZArAodkjQ2CHl6FIosZjF+JBgIRGQGBOAEPEDhPg?= =?us-ascii?q?Rx6FR8qgmQJhFZ3AYojLIEFgREBAQE?= X-IronPort-AV: E=Sophos;i="5.44,326,1505779200"; d="scan'208,217";a="312917800" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2017 21:03:39 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v9VL3dv8032313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Oct 2017 21:03:39 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 31 Oct 2017 16:03:38 -0500 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Tue, 31 Oct 2017 16:03:38 -0500 From: "Owen Friel (ofriel)" To: Ben Schwartz , Richard Barnes CC: "" Thread-Topic: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt Thread-Index: AQHTUbfdWlszSrswCU+9CVrREn/H1KL9SjIAgAACWICAAAM5gIAAACMAgAABfwCAAAVAgIAAKr4AgADoaBA= Date: Tue, 31 Oct 2017 21:03:38 +0000 Message-ID: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.243.16] Content-Type: multipart/alternative; boundary="_000_fddcd65297054fd1b54b05b767bcd474XCHRCD012ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 21:03:44 -0000 --_000_fddcd65297054fd1b54b05b767bcd474XCHRCD012ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QmVuIFNjaHdhcnR6DQpTZW50OiAzMSBPY3RvYmVyIDIwMTcgMDE6MzUNClRvOiBSaWNoYXJkIEJh cm5lcyA8cmxiQGlwdi5zeD4NCkNjOiA8dGxzQGlldGYub3JnPiA8dGxzQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtUTFNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZnJpZWwt dGxzLW92ZXItaHR0cC0wMC50eHQNCg0KT24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgNzowMiBQTSwg UmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCkl0 IHJlcXVpcmVzIGF3YXJlbmVzcyBpbiB0aGUgZm9sbG93aW5nIHNlbnNlOiBJZiBieSBjaGFuY2Ug dGhlIGNsaWVudCBpcyBpbiBhIG5pY2UsIG9wZW4gbmV0d29yayBhbmQgdGhlIGJhc2UgVExTIGNv bm5lY3Rpb24gZ29lcyBkaXJlY3RseSB0byB0aGUgc2VydmVyLCBDT05ORUNUIGlzIGtpbmQgb2Yg dW5uYXR1cmFsOyB5b3Ugd291bGQgd2FudCB0aGUgY2xpZW50IHRvIGRvIHNvbWV0aGluZyBkaWZm ZXJlbnQgaW4gdGhhdCBjYXNlLg0KDQpTdXJlbHkgdGhpcyBpcyBlcXVhbGx5IHRydWUvdW50cnVl IG9mIEFUTFMuICBXaHkgZG8gZG91YmxlLVRMUyBpZiBpdCBjYW4gYmUgYXZvaWRlZD8gIEJ1dCB0 aGVuLCBob3cgZG9lcyB0aGUgYXBwbGljYXRpb24ga25vdyB3aGV0aGVyIHRvIGRvIEFUTFMgZW5j YXBzdWxhdGlvbj8gIEl0J3MgdGhlIHNhbWUgcXVlc3Rpb24gaW4gYm90aCBjYXNlcy4NCg0KW29m cmllbF0gVGhlIGRyYWZ0IGRvZXMgc3RhdGUg4oCcQXMgYW4gb3B0aW1pc2F0aW9uLCBjbGllbnRz IG1heSBjaG9vc2UgdG8gb25seSB1c2UgQVRMUyBhcyBhIGZhbGxiYWNrDQogICBtZWNoYW5pc20g aWYgY2VydGlmaWNhdGUgdmFsaWRhdGlvbiBmYWlscyBvbiB0aGUgdHJhbnNwb3J0IGxheWVyIFRM Uw0KICAgY29ubmVjdGlvbiB0byB0aGUgc2VydmljZQ0K4oCdDQpJdCBzaG91bGQgYmUgZWFzeSBm b3IgYSBkZXZpY2UgdG8gZGV0ZWN0IHRoZSBwcmVzZW5jZSBvZiBhIG1pZGRsZWJveCBpZiB0aGUg bmV0d29yayBsYXllciBUTFMgY29ubmVjdGlvbiBwcmVzZW50cyBhIHNlcnZpY2UgY2VydGlmaWNh dGUgdGhhdCBoYXMgdGhlIGV4cGVjdGVkIFNBTi9DTiwgYnV0IGlzIHNpZ25lZCBieSBhbiB1bmV4 cGVjdGVkL3VudHJ1c3RlZCBDQSAoaS5lLiBvbmUgbm90IGJha2VkIGludG8vZXhwbGljaXRseSBj b25maWd1cmVkIG9uIHRoZSBkZXZpY2UpLg0KDQogIFlvdSdyZSBjb3JyZWN0IHRoYXQgeW91ICpj b3VsZCogY29uZmlndXJlIHRoZSBzZXJ2ZXIgdG8gaGFuZGxlIGNvbm5lY3QgcHJvcGVybHksIGJ1 dCBhbGwgb2YgdGhlIG9wdGlvbnMgZm9yIGRvaW5nIHRoaXMgYXJlIGtpbmQgb2YgY3VtYmVyc29t ZSAtLSBlaXRoZXIgeW91IGhhdmUgdG8gc3RpY2sgYSBwb3NzaWJseS11bm5lY2Vzc2FyeSBwcm94 eSBpbiBmcm9udCBvZiB0aGUgc2VydmVyLCBvciBoYW5kbGUgQ09OTkVDVCBvbiB0aGUgc2VydmVy LCB3aGljaCBpcyBub3QgcmVhbGx5IHdlbGwtc3VwcG9ydGVkIGJ5IHdlYiBhcHBsaWNhdGlvbiBm cmFtZXdvcmtzLiAgQnkgY29udHJhc3QsIHJ1bm5pbmcgZGF0YSBvdmVyIFBPU1QgaXMgdWJpcXVp dG91cy4NCg0KVGhpcyBtYWtlcyBhIGNlcnRhaW4gYW1vdW50IG9mIHNlbnNlIHRvIG1lLiAgSWYg aXQgd2VyZSB1cCB0byBtZSwgcmF0aGVyIHRoYW4gZGVzaWduIGEgVExTLXNwZWNpZmljIHRyYW5z cG9ydCwgSSdkIGJlIG1vcmUgaW5jbGluZWQgdG8gcHJvcG9zZSBhIHN0YW5kYXJkaXplZCB2ZXJz aW9uIG9mIHNvbWV0aGluZyBsaWtlIENyb3diYXI8aHR0cHM6Ly9naXRodWIuY29tL3Ezay9jcm93 YmFyPi4NCltvZnJpZWxdIC9tZSByZWFkcy4g4oCYbGlrZeKAmSBhcHBlYXJzIHRvIGJlIHRoZSBv cGVyYXRpdmUgd29yZCBoZXJlIGJhc2VkIG9uIGF1dGhvciBjb21tZW50cyBvbiBodHRwczovL2dp dGh1Yi5jb20vcTNrL2Nyb3diYXI6IOKAnENyb3diYXIgRE9FUyBOT1QgUFJPVklERSBBTlkgREFU QSBDT05GSURFTlRJQUxJVFnigJ0NCg0KKE9yIGp1c3QgZG9jdW1lbnQgdGhhdCByZXZlcnNlIHBy b3hpZXMgYW5kIGZyYW1ld29ya3Mgb3VnaHQgdG8gZG8gc29tZXRoaW5nIHJlYXNvbmFibGUgd2l0 aCBDT05ORUNULg0KW29mcmllbF0gQ09OTkVDVCB3b3VsZCBqdXN0IG9wZW4gYSB0dW5uZWwgdG8g Z2V0IHBhY2tldHMgdGhyb3VnaCB0aGUgcHJveHkgdG8gdGhlIHNlcnZpY2UsIGJ1dCB3b3VsZCBy ZXF1aXJlIHRoZSBwcm94eSB0byAqbm90KiBhdHRlbXB0IHRvIGRvIFRMUyBpbnRlcmNlcHRpb24s IHdoaWNoIGlzIGV4YWN0bHkgd2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIGFsbG93LiBJZiBwb2xpY3kg ZGljdGF0ZXMgdGhhdCBldmVyeXRoaW5nIG11c3QgYmUgaW50ZXJjZXB0ZWQsIHRoaXMgbWVjaGFu aXNtIGVuYWJsZXMgdGhhdC4NCg0KKSAgT3RoZXJ3aXNlIHRoaXMgc2VlbXMgdG8gYmUgb3NzaWZ5 aW5nIHRoZSBwcm94eSwgcHJpdmlsZWdpbmcgVExTIGFuZCBwcmV2ZW50aW5nIGRlcGxveW1lbnQg b2YgTm9pc2UgcHJvdG9jb2w8aHR0cDovL25vaXNlcHJvdG9jb2wub3JnLz4gb3Igd2hhdGV2ZXIg dGhlIGZ1dHVyZSBtYXkgaG9sZC4NCltvZnJpZWxdIE9uZSBvZiB0aGUgcmVhc29uIGZvciBibGlu ZGx5IHRyYW5zcG9ydGluZyBUTFMgYW5kIG5vdCBpbiBhbnkgd2F5IHJlc3RyaWN0aW5nIG9yIGN1 c3RvbWlzaW5nIHRoZSBUTFMgcmVjb3JkcyB0cmFuc2ZlcnJlZCB3YXMgdG8gYmUgZnV0dXJlIGNv bXBhdGlibGUgd2l0aCBhbGwgZnV0dXJlIHZlcnNpb25zIG9mIFRMUzsgYW5kIGFsc28gdG8gYWxs b3cgYW4gYXBwbGljYXRpb24gdG8gbGV2ZXJhZ2UgYSBzaW5nbGUgc29mdHdhcmUgbGlicmFyeSBm b3IgYm90aCBuZXR3b3JrIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24gY3J5cHRvIGV4Y2hhbmdl cy4NCg0KSXQgd2FzIGFsc28gcG9pbnRlZCB0byBtZSBvZmYtbGlzdCB0aGF0IHlvdSBjYW4gZ2Vu ZXJhdGUgUE9TVCByZXF1ZXN0cyBmcm9tIEphdmFzY3JpcHQgaW4gWEhSLCBidXQgbm90IENPTk5F Q1QgcmVxdWVzdHMuICBTbyBkb2luZyB0aGlzIG92ZXIgUE9TVHMgYWxzbyBtYWtlcyBpdCBhY2Nl c3NpYmxlIHRvIHdlYiBhcHBzLiAgKGBlbXNjcmlwdGVuIGxpYnNzbC5hYCBsZWZ0IGFzIGFuIGV4 ZXJjaXNlIHRvIHRoZSByZWFkZXIuKQ0KDQpJdCBzZWVtcyB5b3VyIHRocmVhdCBtb2RlbCBhc3N1 bWVzIGFuIGFkdmVyc2FyeSB3aG8gaXMgYW4gYWN0aXZlIGludGVybWVkaWFyeSBpbiB5b3VyIEhU VFAgc2Vzc2lvbi4gIElmIHNvLCB0aGVuIHRoaXMgd291bGRuJ3Qgc2VlbSB0byBwcm90ZWN0IHRo ZSB1c2VyIGFnYWluc3QgdGhlIHRocmVhdC4NCltvZnJpZWxdIENhbiB5b3UgY2xhcmlmeSB3aHkg dGhpcyBkb2VzbuKAmXQgcHJvdGVjdCBhZ2FpbnN0IGFuIGFjdGl2ZSBpbnRlcm1lZGlhcnkgaW4g dGhlIEhUVFAgc2Vzc2lvbj8gVHJhbnNmZXJyaW5nIHRoZSBUTFMgcmVjb3JkcyBwYXlsb2FkcyBp biBIVFRQIGJvZGllcyBpcyBkaXJlY3RseSBhbmFsb2dvdXMgdG8gIHRyYW5zZmVycmluZyBUTFMg cmVjb3JkcyBvdmVyIHVudHJ1c3RlZCBUQ1AgbmV0d29yayB0cmFuc3BvcnQuDQoNCg0KDQotLVJp Y2hhcmQNCg0KDQpPbiBNb24sIE9jdCAzMCwgMjAxNyBhdCA2OjQzIFBNLCBCZW4gU2Nod2FydHog PGJlbWFzY0Bnb29nbGUuY29tPG1haWx0bzpiZW1hc2NAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KSSBk b24ndCB1bmRlcnN0YW5kIHdoeSBBVExTIGFsbG93cyB0aGUgYXBwIHRvIGJlIGxlc3MgImF3YXJl IiB0aGFuIEhUVFAgQ09OTkVDVC4gIEkgYWxzbyBkb24ndCB1bmRlcnN0YW5kIGhvdyBhbiBBVExT IGNsaWVudCBpcyBjbG9zZXIgdG8gIm9uZSBjb2RlIHBhdGgiIHRoYW4gSFRUUCBDT05ORUNULiAg SXQgc2VlbXMgdG8gbWUgdGhhdCB5b3VyIGRlc2NyaXB0aW9uIG9mIGNsaWVudCBiZWhhdmlvciBh cHBsaWVzIGVxdWFsbHkgdG8gQVRMUyBhbmQgSFRUUCBDT05ORUNULg0KDQpPbiBNb24sIE9jdCAz MCwgMjAxNyBhdCA2OjM4IFBNLCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeDxtYWlsdG86cmxi QGlwdi5zeD4+IHdyb3RlOg0KQnV0IEkgYWdyZWUsIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBz b21lIG1vcmUgY2xhcml0eSBhcm91bmQgdXNlIGNhc2VzIGFuZCB3aHkgbm90IG90aGVyIHNvbHV0 aW9ucy4NCg0KT24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgNjozNyBQTSwgUmljaGFyZCBCYXJuZXMg PHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCkhUVFAgQ09OTkVDVCBpcyBu b3QgZ3JlYXQgZm9yIHNvbWUgdXNlIGNhc2VzIGJlY2F1c2UgaXQgcmVxdWlyZXMgdGhlIGFwcCB0 byBiZSBhd2FyZSB0aGF0IGl0J3MgZGVhbGluZyB3aXRoIGEgcHJveHkuICBJdCdzIHNpbXBsZXIg aWYgeW91IGNhbiBqdXN0IGhhdmUgb25lIGNvZGUgcGF0aCB0aGF0IHdvcmtzIHdoZXRoZXIgeW91 ciBUTFMgaXMgaW50ZXJtZWRpYXRlZCBvciBub3QuICBXaXRoIHRoZSBzb2x1dGlvbiBvdXRsaW5l ZCBpbiB0aGUgZHJhZnQsIHlvdSBjYW4ganVzdCBhbHdheXMgaWdub3JlIHRoZSBjZXJ0aWZpY2F0 ZSB0aGUgc2VydmVyIHNlbmRzIGluIHRoZSBmaXJzdCBUTFMgY29ubmVjdGlvbiAoYmVjYXVzZSBp dCBtaWdodCBiZSBmcm9tIGEgTWl0TSksIGFuZCB0aGVuIGRvIGFsbCB5b3VyIGNlcnQgdmFsaWRh dGlvbiwgcGluIGNoZWNrcywgZXRjLiBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIuDQoNCk9uIE1v biwgT2N0IDMwLCAyMDE3IGF0IDY6MjYgUE0sIEJlbiBTY2h3YXJ0eiA8YmVtYXNjQGdvb2dsZS5j b208bWFpbHRvOmJlbWFzY0Bnb29nbGUuY29tPj4gd3JvdGU6DQpXaHkgbm90IHVzZSBIVFRQIENP Tk5FQ1Q/ICBPciByYXRoZXIsIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZSBhIHNlY3Rpb24g b24gd2hlbi93aHkgb25lIHdvdWxkIGRvIHRoaXMgdnMuIENPTk5FQ1QuDQoNCk9uIE1vbiwgT2N0 IDMwLCAyMDE3IGF0IDY6MTcgUE0sIFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PG1haWx0bzpy bGJAaXB2LnN4Pj4gd3JvdGU6DQpIZXkgVExTIGZvbGtzLA0KDQpPd2VuLCBNYXgsIGFuZCBJIGhh dmUgYmVlbiBraWNraW5nIGFyb3VuZCBzb21lIGlkZWFzIGZvciBob3cgdG8gbWFrZSBzZWN1cmUg Y29ubmVjdGlvbnMgaW4gZW52aXJvbm1lbnRzIHdoZXJlIEhUVFBTIGlzIHN1YmplY3QgdG8gTWl0 TSAvIHByb3h5aW5nLg0KDQpUaGUgYmVsb3cgZHJhZnQgbGF5cyBvdXQgYSB3YXkgdG8gdHVubmVs IFRMUyBvdmVyIEhUVFBTLCBpbiBob3BlcyBvZiBjcmVhdGluZyBhIGNoYW5uZWwgeW91IGNvdWxk IHVzZSB3aGVuIHlvdSByZWFsbHkgbmVlZCB0aGluZ3MgdG8gYmUgcHJpdmF0ZSwgZXZlbiBmcm9t IHRoZSBsb2NhbCBNaXRNLg0KDQpGZWVkYmFjayBvYnZpb3VzbHkgdmVyeSB3ZWxjb21lLiAgSW50 ZXJlc3RlZCBpbiB3aGV0aGVyIGZvbGtzIHRoaW5rIHRoaXMgaXMgYSB1c2VmdWwgYXJlYSBpbiB3 aGljaCB0byBkZXZlbG9wIGFuIFJGQywgYW5kIGFueSB0aG91Z2h0cyBvbiBob3cgdG8gZG8gdGhp cyBiZXR0ZXIuDQoNClRoYW5rcywNCi0tUmljaGFyZA0KDQoNCk9uIE1vbiwgT2N0IDMwLCAyMDE3 IGF0IDM6NDcgUE0sIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4+IHdyb3RlOg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZnJp ZWwtdGxzLW92ZXItaHR0cC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgT3dlbiBGcmllbCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OiAgICAgICAgICAgZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0cA0KUmV2aXNpb246ICAgICAgIDAw DQpUaXRsZTogICAgICAgICAgQXBwbGljYXRpb24tTGF5ZXIgVExTDQpEb2N1bWVudCBkYXRlOiAg MjAxNy0xMC0zMA0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6 ICAgICAgICAgIDIwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWZyaWVsLXRscy1vdmVyLWh0dHAtMDAudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZnJpZWwtdGxzLW92ZXIt aHR0cC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZnJpZWwtdGxzLW92ZXItaHR0cC0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0cC0wMA0KDQoNCkFi c3RyYWN0Og0KICAgTWFueSBjbGllbnRzIG5lZWQgdG8gZXN0YWJsaXNoIHNlY3VyZSBjb25uZWN0 aW9ucyB0byBhcHBsaWNhdGlvbg0KICAgc2VydmljZXMgYnV0IGZhY2UgY2hhbGxlbmdlcyBlc3Rh Ymxpc2hpbmcgdGhlc2UgY29ubmVjdGlvbnMgZHVlIHRvDQogICB0aGUgcHJlc2VuY2Ugb2YgbWlk ZGxlYm94ZXMgdGhhdCB0ZXJtaW5hdGUgVExTIGNvbm5lY3Rpb25zIGZyb20gdGhlDQogICBjbGll bnQgYW5kIHJlc3RhYmxpc2ggbmV3IFRMUyBjb25uZWN0aW9ucyB0byB0aGUgc2VydmljZS4gIFRo aXMNCiAgIGRvY3VtZW50IGRlZmluZXMgYSBtZWNoYW5pc20gZm9yIHRyYW5zcG9ydGluZyBUTFMg cmVjb3JkcyBpbiBIVFRQDQogICBtZXNzYWdlIGJvZGllcyBiZXR3ZWVuIGNsaWVudHMgYW5kIHNl cnZpY2VzLiAgVGhpcyBlbmFibGVzIGNsaWVudHMNCiAgIGFuZCBzZXJ2aWNlcyB0byBlc3RhYmxp c2ggc2VjdXJlIGNvbm5lY3Rpb25zIHVzaW5nIFRMUyBhdCB0aGUNCiAgIGFwcGxpY2F0aW9uIGxh eWVyLCBhbmQgdHJlYXQgYW55IG1pZGRsZWJveGVzIHRoYXQgYXJlIGludGVyY2VwdGluZw0KICAg dHJhZmZpYyBhdCB0aGUgbmV0d29yayBsYXllciBhcyB1bnRydXN0ZWQgdHJhbnNwb3J0LiAgSW4g c2hvcnQsIHRoaXMNCiAgIG1lY2hhbmlzbSBtb3ZlcyB0aGUgVExTIGhhbmRzaGFrZSB1cCB0aGUg T1NJIHN0YWNrIHRvIHRoZSBhcHBsaWNhdGlvbg0KICAgbGF5ZXIuDQoNCg0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQoNCg0K DQoNCg0K --_000_fddcd65297054fd1b54b05b767bcd474XCHRCD012ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uaG9lbnpi DQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMDBCMDUwO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMEIwNTA7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDBCMDUwO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkJlbiBTY2h3YXJ0ejxicj4NCjxiPlNlbnQ6PC9iPiAzMSBPY3RvYmVyIDIwMTcgMDE6 MzU8YnI+DQo8Yj5Ubzo8L2I+IFJpY2hhcmQgQmFybmVzICZsdDtybGJAaXB2LnN4Jmd0Ozxicj4N CjxiPkNjOjwvYj4gJmx0O3Rsc0BpZXRmLm9yZyZndDsgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0cC0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE9jdCAz MCwgMjAxNyBhdCA3OjAyIFBNLCBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJs YkBpcHYuc3giIHRhcmdldD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCByZXF1aXJlcyBhd2FyZW5lc3MgaW4gdGhlIGZvbGxvd2luZyBzZW5zZTogSWYgYnkgY2hh bmNlIHRoZSBjbGllbnQgaXMgaW4gYSBuaWNlLCBvcGVuIG5ldHdvcmsgYW5kIHRoZSBiYXNlIFRM UyBjb25uZWN0aW9uIGdvZXMgZGlyZWN0bHkgdG8gdGhlIHNlcnZlciwgQ09OTkVDVCBpcyBraW5k IG9mIHVubmF0dXJhbDsgeW91IHdvdWxkIHdhbnQgdGhlIGNsaWVudCB0byBkbyBzb21ldGhpbmcg ZGlmZmVyZW50DQogaW4gdGhhdCBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmVseSB0aGlz IGlzIGVxdWFsbHkgdHJ1ZS91bnRydWUgb2YgQVRMUy4mbmJzcDsgV2h5IGRvIGRvdWJsZS1UTFMg aWYgaXQgY2FuIGJlIGF2b2lkZWQ/Jm5ic3A7IEJ1dCB0aGVuLCBob3cgZG9lcyB0aGUgYXBwbGlj YXRpb24ga25vdyB3aGV0aGVyIHRvIGRvIEFUTFMgZW5jYXBzdWxhdGlvbj8mbmJzcDsgSXQncyB0 aGUgc2FtZSBxdWVzdGlvbiBpbiBib3RoIGNhc2VzLjxvOnA+PC9vOnA+PC9wPg0KPHByZT48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+W29mcmllbF0gVGhlIGRyYWZ0IGRvZXMg c3RhdGUg4oCcPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BcyBhbiBv cHRpbWlzYXRpb24sIGNsaWVudHMgbWF5IGNob29zZSB0byBvbmx5IHVzZSBBVExTIGFzIGEgZmFs bGJhY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtIGlmIGNlcnRpZmljYXRlIHZh bGlkYXRpb24gZmFpbHMgb24gdGhlIHRyYW5zcG9ydCBsYXllciBUTFM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IGNvbm5lY3Rpb24gdG8gdGhlIHNlcnZpY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+ 4oCdPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+SXQgc2hvdWxkIGJlIGVhc3kgZm9y IGEgZGV2aWNlIHRvIGRldGVjdCB0aGUgcHJlc2VuY2Ugb2YgYSBtaWRkbGVib3ggaWYgdGhlIG5l dHdvcmsgbGF5ZXIgVExTIGNvbm5lY3Rpb24gcHJlc2VudHMgYSBzZXJ2aWNlIGNlcnRpZmljYXRl IHRoYXQgaGFzIHRoZSBleHBlY3RlZA0KIFNBTi9DTiwgYnV0IGlzIHNpZ25lZCBieSBhbiB1bmV4 cGVjdGVkL3VudHJ1c3RlZCBDQSAoaS5lLiBvbmUgbm90IGJha2VkIGludG8vZXhwbGljaXRseSBj b25maWd1cmVkIG9uIHRoZSBkZXZpY2UpLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDBCMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IFlvdSdyZSBjb3Jy ZWN0IHRoYXQgeW91ICpjb3VsZCogY29uZmlndXJlIHRoZSBzZXJ2ZXIgdG8gaGFuZGxlIGNvbm5l Y3QgcHJvcGVybHksIGJ1dCBhbGwgb2YgdGhlIG9wdGlvbnMgZm9yIGRvaW5nIHRoaXMgYXJlIGtp bmQgb2YgY3VtYmVyc29tZSAtLSBlaXRoZXIgeW91IGhhdmUgdG8gc3RpY2sgYSBwb3NzaWJseS11 bm5lY2Vzc2FyeSBwcm94eSBpbiBmcm9udCBvZiB0aGUgc2VydmVyLCBvciBoYW5kbGUgQ09OTkVD VA0KIG9uIHRoZSBzZXJ2ZXIsIHdoaWNoIGlzIG5vdCByZWFsbHkgd2VsbC1zdXBwb3J0ZWQgYnkg d2ViIGFwcGxpY2F0aW9uIGZyYW1ld29ya3MuJm5ic3A7IEJ5IGNvbnRyYXN0LCBydW5uaW5nIGRh dGEgb3ZlciBQT1NUIGlzIHViaXF1aXRvdXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtYWtl cyBhIGNlcnRhaW4gYW1vdW50IG9mIHNlbnNlIHRvIG1lLiZuYnNwOyBJZiBpdCB3ZXJlIHVwIHRv IG1lLCByYXRoZXIgdGhhbiBkZXNpZ24gYSBUTFMtc3BlY2lmaWMgdHJhbnNwb3J0LCBJJ2QgYmUg bW9yZSBpbmNsaW5lZCB0byBwcm9wb3NlIGEgc3RhbmRhcmRpemVkIHZlcnNpb24gb2Ygc29tZXRo aW5nIGxpa2UNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xM2svY3Jvd2JhciI+Q3Jvd2Jh cjwvYT4uJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDBCMDUwIj5bb2ZyaWVsXSAvbWUgcmVhZHMuIOKAmGxpa2XigJkgYXBwZWFycyB0byBiZSB0aGUg b3BlcmF0aXZlIHdvcmQgaGVyZSBiYXNlZCBvbiBhdXRob3IgY29tbWVudHMgb24NCjxhIGhyZWY9 Imh0dHBzOi8vZ2l0aHViLmNvbS9xM2svY3Jvd2JhciI+aHR0cHM6Ly9naXRodWIuY29tL3Ezay9j cm93YmFyPC9hPjog4oCcPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI0MjkyRTtiYWNrZ3JvdW5kOndo aXRlIj5Dcm93YmFyJm5ic3A7PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+RE9FUyBOT1QgUFJPVklERSBBTlkNCiBEQVRBIENP TkZJREVOVElBTElUWTwvc3Bhbj48L3N0cm9uZz48L3NwYW4+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMEIwNTAiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KE9y IGp1c3QgZG9jdW1lbnQgdGhhdCByZXZlcnNlIHByb3hpZXMgYW5kIGZyYW1ld29ya3Mgb3VnaHQg dG8gZG8gc29tZXRoaW5nIHJlYXNvbmFibGUgd2l0aCBDT05ORUNULjxzcGFuIHN0eWxlPSJjb2xv cjojMDBCMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+W29mcmllbF0gQ09OTkVDVCB3b3Vs ZCBqdXN0IG9wZW4gYSB0dW5uZWwgdG8gZ2V0IHBhY2tldHMgdGhyb3VnaCB0aGUgcHJveHkgdG8g dGhlIHNlcnZpY2UsIGJ1dCB3b3VsZCByZXF1aXJlIHRoZSBwcm94eSB0byAqbm90KiBhdHRlbXB0 IHRvIGRvIFRMUyBpbnRlcmNlcHRpb24sDQogd2hpY2ggaXMgZXhhY3RseSB3aGF0IHdlIGFyZSB0 cnlpbmcgdG8gYWxsb3cuIElmIHBvbGljeSBkaWN0YXRlcyB0aGF0IGV2ZXJ5dGhpbmcgbXVzdCBi ZSBpbnRlcmNlcHRlZCwgdGhpcyBtZWNoYW5pc20gZW5hYmxlcyB0aGF0LjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+KSZuYnNwOyBPdGhlcndpc2UgdGhpcyBzZWVtcyB0byBiZSBv c3NpZnlpbmcgdGhlIHByb3h5LCBwcml2aWxlZ2luZyBUTFMgYW5kIHByZXZlbnRpbmcgZGVwbG95 bWVudCBvZiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9ub2lzZXByb3RvY29sLm9yZy8iPk5vaXNlIHBy b3RvY29sPC9hPiZuYnNwO29yIHdoYXRldmVyIHRoZSBmdXR1cmUgbWF5IGhvbGQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwQjA1MCI+W29mcmllbF0gT25lIG9mIHRoZSByZWFzb24gZm9yIGJsaW5kbHkgdHJhbnNwb3J0 aW5nIFRMUyBhbmQgbm90IGluIGFueSB3YXkgcmVzdHJpY3Rpbmcgb3IgY3VzdG9taXNpbmcgdGhl IFRMUyByZWNvcmRzIHRyYW5zZmVycmVkIHdhcyB0byBiZSBmdXR1cmUgY29tcGF0aWJsZQ0KIHdp dGggYWxsIGZ1dHVyZSB2ZXJzaW9ucyBvZiBUTFM7IGFuZCBhbHNvIHRvIGFsbG93IGFuIGFwcGxp Y2F0aW9uIHRvIGxldmVyYWdlIGEgc2luZ2xlIHNvZnR3YXJlIGxpYnJhcnkgZm9yIGJvdGggbmV0 d29yayB0cmFuc3BvcnQgYW5kIGFwcGxpY2F0aW9uIGNyeXB0byBleGNoYW5nZXMuPC9zcGFuPjwv aT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JdCB3YXMgYWxzbyBwb2ludGVkIHRvIG1lIG9mZi1saXN0IHRoYXQgeW91IGNhbiBnZW5l cmF0ZSBQT1NUIHJlcXVlc3RzIGZyb20gSmF2YXNjcmlwdCBpbiBYSFIsIGJ1dCBub3QgQ09OTkVD VCByZXF1ZXN0cy4mbmJzcDsgU28gZG9pbmcgdGhpcyBvdmVyIFBPU1RzIGFsc28gbWFrZXMgaXQg YWNjZXNzaWJsZSB0byB3ZWIgYXBwcy4mbmJzcDsgKGBlbXNjcmlwdGVuIGxpYnNzbC5hYCBsZWZ0 IGFzIGFuIGV4ZXJjaXNlIHRvIHRoZQ0KIHJlYWRlci4pPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQg c2VlbXMgeW91ciB0aHJlYXQgbW9kZWwgYXNzdW1lcyBhbiBhZHZlcnNhcnkgd2hvIGlzIGFuIGFj dGl2ZSBpbnRlcm1lZGlhcnkgaW4geW91ciBIVFRQIHNlc3Npb24uJm5ic3A7IElmIHNvLCB0aGVu IHRoaXMgd291bGRuJ3Qgc2VlbSB0byBwcm90ZWN0IHRoZSB1c2VyIGFnYWluc3QgdGhlIHRocmVh dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDBCMDUwIj5bb2ZyaWVsXSBDYW4geW91IGNsYXJpZnkgd2h5IHRoaXMgZG9l c27igJl0IHByb3RlY3QgYWdhaW5zdCBhbiBhY3RpdmUgaW50ZXJtZWRpYXJ5IGluIHRoZSBIVFRQ IHNlc3Npb24/IFRyYW5zZmVycmluZyB0aGUgVExTIHJlY29yZHMgcGF5bG9hZHMgaW4gSFRUUCBi b2RpZXMNCiBpcyBkaXJlY3RseSBhbmFsb2dvdXMgdG8gJm5ic3A7dHJhbnNmZXJyaW5nIFRMUyBy ZWNvcmRzIG92ZXIgdW50cnVzdGVkIFRDUCBuZXR3b3JrIHRyYW5zcG9ydC48L3NwYW4+PC9pPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojODg4ODg4Ij4tLVJpY2hhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE9jdCAzMCwg MjAxNyBhdCA2OjQzIFBNLCBCZW4gU2Nod2FydHogJmx0OzxhIGhyZWY9Im1haWx0bzpiZW1hc2NA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlbWFzY0Bnb29nbGUuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGRvbid0IHVuZGVyc3RhbmQgd2h5IEFUTFMgYWxsb3dzIHRoZSBhcHAgdG8g YmUgbGVzcyAmcXVvdDthd2FyZSZxdW90OyB0aGFuIEhUVFAgQ09OTkVDVC4mbmJzcDsgSSBhbHNv IGRvbid0IHVuZGVyc3RhbmQgaG93IGFuIEFUTFMgY2xpZW50IGlzIGNsb3NlciB0byAmcXVvdDtv bmUgY29kZSBwYXRoJnF1b3Q7IHRoYW4gSFRUUCBDT05ORUNULiZuYnNwOyBJdCBzZWVtcyB0byBt ZSB0aGF0IHlvdXIgZGVzY3JpcHRpb24gb2YgY2xpZW50IGJlaGF2aW9yIGFwcGxpZXMNCiBlcXVh bGx5IHRvIEFUTFMgYW5kIEhUVFAgQ09OTkVDVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBPY3QgMzAsIDIwMTcgYXQg NjozOCBQTSwgUmljaGFyZCBCYXJuZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4IiB0 YXJnZXQ9Il9ibGFuayI+cmxiQGlwdi5zeDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgSSBhZ3JlZSwgaXQg d291bGQgYmUgZ29vZCB0byBoYXZlIHNvbWUgbW9yZSBjbGFyaXR5IGFyb3VuZCB1c2UgY2FzZXMg YW5kIHdoeSBub3Qgb3RoZXIgc29sdXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE9jdCAzMCwgMjAxNyBhdCA2 OjM3IFBNLCBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIHRh cmdldD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhUVFAgQ09OTkVDVCBpcyBu b3QgZ3JlYXQgZm9yIHNvbWUgdXNlIGNhc2VzIGJlY2F1c2UgaXQgcmVxdWlyZXMgdGhlIGFwcCB0 byBiZSBhd2FyZSB0aGF0IGl0J3MgZGVhbGluZyB3aXRoIGEgcHJveHkuJm5ic3A7IEl0J3Mgc2lt cGxlciBpZiB5b3UgY2FuIGp1c3QgaGF2ZSBvbmUgY29kZSBwYXRoIHRoYXQgd29ya3Mgd2hldGhl ciB5b3VyIFRMUyBpcyBpbnRlcm1lZGlhdGVkIG9yIG5vdC4mbmJzcDsgV2l0aCB0aGUgc29sdXRp b24NCiBvdXRsaW5lZCBpbiB0aGUgZHJhZnQsIHlvdSBjYW4ganVzdCBhbHdheXMgaWdub3JlIHRo ZSBjZXJ0aWZpY2F0ZSB0aGUgc2VydmVyIHNlbmRzIGluIHRoZSBmaXJzdCBUTFMgY29ubmVjdGlv biAoYmVjYXVzZSBpdCBtaWdodCBiZSBmcm9tIGEgTWl0TSksIGFuZCB0aGVuIGRvIGFsbCB5b3Vy IGNlcnQgdmFsaWRhdGlvbiwgcGluIGNoZWNrcywgZXRjLiBhdCB0aGUgYXBwbGljYXRpb24gbGF5 ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgT2N0IDMwLCAyMDE3IGF0IDY6MjYgUE0sIEJlbiBTY2h3YXJ0eiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJlbWFzY0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmVtYXNj QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IG5vdCB1c2UgSFRUUCBDT05ORUNUPyZuYnNw OyBPciByYXRoZXIsIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZSBhIHNlY3Rpb24gb24gd2hl bi93aHkgb25lIHdvdWxkIGRvIHRoaXMgdnMuIENPTk5FQ1QuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgT2N0IDMwLCAy MDE3IGF0IDY6MTcgUE0sIFJpY2hhcmQgQmFybmVzICZsdDs8YSBocmVmPSJtYWlsdG86cmxiQGlw di5zeCIgdGFyZ2V0PSJfYmxhbmsiPnJsYkBpcHYuc3g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhleSBUTFMgZm9sa3MsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk93ZW4sIE1heCwgYW5kIEkg aGF2ZSBiZWVuIGtpY2tpbmcgYXJvdW5kIHNvbWUgaWRlYXMgZm9yIGhvdyB0byBtYWtlIHNlY3Vy ZSBjb25uZWN0aW9ucyBpbiBlbnZpcm9ubWVudHMgd2hlcmUgSFRUUFMgaXMgc3ViamVjdCB0byBN aXRNIC8gcHJveHlpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBiZWxvdyBkcmFmdCBsYXlzIG91dCBhIHdheSB0byB0dW5uZWwgVExT IG92ZXIgSFRUUFMsIGluIGhvcGVzIG9mIGNyZWF0aW5nIGEgY2hhbm5lbCB5b3UgY291bGQgdXNl IHdoZW4geW91IHJlYWxseSBuZWVkIHRoaW5ncyB0byBiZSBwcml2YXRlLCBldmVuIGZyb20gdGhl IGxvY2FsIE1pdE0uJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RmVlZGJhY2sgb2J2aW91c2x5IHZlcnkgd2VsY29tZS4mbmJzcDsg SW50ZXJlc3RlZCBpbiB3aGV0aGVyIGZvbGtzIHRoaW5rIHRoaXMgaXMgYSB1c2VmdWwgYXJlYSBp biB3aGljaCB0byBkZXZlbG9wIGFuIFJGQywgYW5kIGFueSB0aG91Z2h0cyBvbiBob3cgdG8gZG8g dGhpcyBiZXR0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tUmljaGFyZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBNb24sIE9jdCAzMCwgMjAxNyBhdCAzOjQ3IFBNLCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZyaWVsLXRscy1vdmVyLWh0dHAtMDAu dHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBPd2VuIEZyaWVsIGFu ZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1mcmllbC10bHMtb3Zl ci1odHRwPGJyPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpU aXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFwcGxpY2F0aW9uLUxheWVy IFRMUzxicj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMTctMTAtMzA8YnI+DQpHcm91cDombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4N ClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjA8YnI+DQpVUkw6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZyaWVsLXRscy1vdmVyLWh0dHAtMDAu dHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0cC0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZyaWVsLXRscy1vdmVyLWh0 dHAvPC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLTAw IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZyaWVs LXRscy1vdmVyLWh0dHAtMDA8L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1mcmllbC10bHMtb3Zlci1odHRwLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLTAwPC9hPjxi cj4NCjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtNYW55IGNsaWVudHMg bmVlZCB0byBlc3RhYmxpc2ggc2VjdXJlIGNvbm5lY3Rpb25zIHRvIGFwcGxpY2F0aW9uPGJyPg0K Jm5ic3A7ICZuYnNwO3NlcnZpY2VzIGJ1dCBmYWNlIGNoYWxsZW5nZXMgZXN0YWJsaXNoaW5nIHRo ZXNlIGNvbm5lY3Rpb25zIGR1ZSB0bzxicj4NCiZuYnNwOyAmbmJzcDt0aGUgcHJlc2VuY2Ugb2Yg bWlkZGxlYm94ZXMgdGhhdCB0ZXJtaW5hdGUgVExTIGNvbm5lY3Rpb25zIGZyb20gdGhlPGJyPg0K Jm5ic3A7ICZuYnNwO2NsaWVudCBhbmQgcmVzdGFibGlzaCBuZXcgVExTIGNvbm5lY3Rpb25zIHRv IHRoZSBzZXJ2aWNlLiZuYnNwOyBUaGlzPGJyPg0KJm5ic3A7ICZuYnNwO2RvY3VtZW50IGRlZmlu ZXMgYSBtZWNoYW5pc20gZm9yIHRyYW5zcG9ydGluZyBUTFMgcmVjb3JkcyBpbiBIVFRQPGJyPg0K Jm5ic3A7ICZuYnNwO21lc3NhZ2UgYm9kaWVzIGJldHdlZW4gY2xpZW50cyBhbmQgc2VydmljZXMu Jm5ic3A7IFRoaXMgZW5hYmxlcyBjbGllbnRzPGJyPg0KJm5ic3A7ICZuYnNwO2FuZCBzZXJ2aWNl cyB0byBlc3RhYmxpc2ggc2VjdXJlIGNvbm5lY3Rpb25zIHVzaW5nIFRMUyBhdCB0aGU8YnI+DQom bmJzcDsgJm5ic3A7YXBwbGljYXRpb24gbGF5ZXIsIGFuZCB0cmVhdCBhbnkgbWlkZGxlYm94ZXMg dGhhdCBhcmUgaW50ZXJjZXB0aW5nPGJyPg0KJm5ic3A7ICZuYnNwO3RyYWZmaWMgYXQgdGhlIG5l dHdvcmsgbGF5ZXIgYXMgdW50cnVzdGVkIHRyYW5zcG9ydC4mbmJzcDsgSW4gc2hvcnQsIHRoaXM8 YnI+DQombmJzcDsgJm5ic3A7bWVjaGFuaXNtIG1vdmVzIHRoZSBUTFMgaGFuZHNoYWtlIHVwIHRo ZSBPU0kgc3RhY2sgdG8gdGhlIGFwcGxpY2F0aW9uPGJyPg0KJm5ic3A7ICZuYnNwO2xheWVyLjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8 L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_fddcd65297054fd1b54b05b767bcd474XCHRCD012ciscocom_-- From nobody Tue Oct 31 14:17:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0EE13F71E for ; Tue, 31 Oct 2017 14:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBq6H0_7hpcf for ; Tue, 31 Oct 2017 14:16:55 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A1E13F733 for ; Tue, 31 Oct 2017 14:16:53 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id g69so241343vke.5 for ; Tue, 31 Oct 2017 14:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4QFax/N1gaaGVxgQ8/1iPY19DUfgMhYL1XvY2XKyw5c=; b=g/8+R4qI8U5PXHXr5SuK4acKo/P3st4Q4pnomeAkScxuLu0+Q0RoOmj4coavRs2FDo St0SYxWxwsrpkUYnFWazXk2W/2yj6q8XvE3dbpamUaJxCaDi7ozI1iytxg9SLM2YsOxc 5cvMFSq3dwMV/8cg2J5fpviqpc9gy0ood/Jqlq5iwD4LYW2hven1zYyLZBJg5smcS+Uq /3bTwa54pJQueKLpW2zw4OaOJ7GGVLC7ma4geJkLjprzHXGNfaHqLo2oRJ9v5JO8tOyx Fv/09PvCNvIjtCTDOsU99jSzj70i6Y1FeYvsnE3TSue7JNlJzbAzrb6R4Nion2fdo4xG h2oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4QFax/N1gaaGVxgQ8/1iPY19DUfgMhYL1XvY2XKyw5c=; b=m6FEmVC5nAxqR8bDvs9ZcUxpAb/UQU9dX/8OEAXJth86Jut5dzS3PYwsDZXHnQYewq HObT3n9rJ0imiJOhuKZN6jSHqvL1UNZ2JwQfQHpKponipPnoFeDXXTMOZe4W1JfMtOrr 02queZBdzzWHhNr6zfPwyq2eLs7rjrD/cnBoHqXm3cwU/pUY0zkvkbX0oIEDk1I2qjLq luV647/kPlPQPpV2oNPhU/ganRVKDWHJbRZL5bVsei+YS3whguVRZaN3Ke9nS0IZ8Jzp 1tbhKfwb3kpL88cPStpb7VYsA5ddpAx+1RtHXThyfgI+yvIuFdtklFpt3Vclfs5xr0YO Rh6g== X-Gm-Message-State: AMCzsaXRyZ/mt+xTdXLxrcf+pFbjTlp2knTKjw9Nps+du/liTEbWMO6z HPLno8BlmMoS1owrSU3uUBrChlR8Zt23OYWNEPDVlqLChTc= X-Google-Smtp-Source: ABhQp+TrL0r4C1KCkqv0LbaUoLC0nwguibCZpHdoZiUAj1EidqLv0aHwBigLygOsXxM0jIyGLdXW9g0Vkc28Y2/lBVc= X-Received: by 10.31.61.8 with SMTP id k8mr2787411vka.171.1509484612240; Tue, 31 Oct 2017 14:16:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.145 with HTTP; Tue, 31 Oct 2017 14:16:51 -0700 (PDT) In-Reply-To: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Ben Schwartz Date: Tue, 31 Oct 2017 17:16:51 -0400 Message-ID: To: "Owen Friel (ofriel)" Cc: Richard Barnes , "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114d9bde275e9f055cde462a" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 21:16:58 -0000 --001a114d9bde275e9f055cde462a Content-Type: multipart/alternative; boundary="001a114d9bde1bdb2b055cde4650" --001a114d9bde1bdb2b055cde4650 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 31, 2017 at 5:03 PM, Owen Friel (ofriel) wrote: > > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Ben Schwartz > *Sent:* 31 October 2017 01:35 > *To:* Richard Barnes > *Cc:* > *Subject:* Re: [TLS] New Version Notification for > draft-friel-tls-over-http-00.txt > > > > On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes wrote: > > It requires awareness in the following sense: If by chance the client is > in a nice, open network and the base TLS connection goes directly to the > server, CONNECT is kind of unnatural; you would want the client to do > something different in that case. > > > > Surely this is equally true/untrue of ATLS. Why do double-TLS if it can > be avoided? But then, how does the application know whether to do ATLS > encapsulation? It's the same question in both cases. > > *[ofriel] The draft does state =E2=80=9C*As an optimisation, clients may = choose to only use ATLS as a fallback > > mechanism if certificate validation fails on the transport layer TLS > > connection to the service > > *=E2=80=9D* > > *It should be easy for a device to detect the presence of a middlebox if > the network layer TLS connection presents a service certificate that has > the expected SAN/CN, but is signed by an unexpected/untrusted CA (i.e. on= e > not baked into/explicitly configured on the device).* > Yes, but the client could equally well fall back to HTTP CONNECT in this case. My comments are all directed to the question of why to use ATLS instead of an existing solution, such as "TLS over HTTP CONNECT". > > > You're correct that you *could* configure the server to handle connect > properly, but all of the options for doing this are kind of cumbersome -- > either you have to stick a possibly-unnecessary proxy in front of the > server, or handle CONNECT on the server, which is not really well-support= ed > by web application frameworks. By contrast, running data over POST is > ubiquitous. > > > > This makes a certain amount of sense to me. If it were up to me, rather > than design a TLS-specific transport, I'd be more inclined to propose a > standardized version of something like Crowbar > . > > *[ofriel] /me reads. =E2=80=98like=E2=80=99 appears to be the operative w= ord here based on > author comments on https://github.com/q3k/crowbar > : =E2=80=9C*Crowbar *DOES NOT PROVIDE ANY= DATA > CONFIDENTIALITY**=E2=80=9D* > Yes, but "TLS over Crowbar" does provide confidentiality, and that is the alternative to ATLS that I am proposing in this sentence. (Or just document that reverse proxies and frameworks ought to do something > reasonable with CONNECT. > > *[ofriel] CONNECT would just open a tunnel to get packets through the > proxy to the service, but would require the proxy to *not* attempt to do > TLS interception, which is exactly what we are trying to allow. If policy > dictates that everything must be intercepted, this mechanism enables that= .* > I don't understand which proxy you're referring to, or how this distinguishes ATLS from "TLS over HTTP CONNECT". ) Otherwise this seems to be ossifying the proxy, privileging TLS and > preventing deployment of Noise protocol or > whatever the future may hold. > > *[ofriel] One of the reason for blindly transporting TLS and not in any > way restricting or customising the TLS records transferred was to be futu= re > compatible with all future versions of TLS; and also to allow an > application to leverage a single software library for both network > transport and application crypto exchanges.* > OK, but you can be even more abstracted by simply transporting a byte-stream, and letting the application developer choose what protocol to speak in that stream. This shares even more code between the "network" and "application" usage of TLS, since they both flow over bytestream abstractions (no need to expose the TLS record layer). > It was also pointed to me off-list that you can generate POST requests > from Javascript in XHR, but not CONNECT requests. So doing this over POS= Ts > also makes it accessible to web apps. (`emscripten libssl.a` left as an > exercise to the reader.) > > > > It seems your threat model assumes an adversary who is an active > intermediary in your HTTP session. If so, then this wouldn't seem to > protect the user against the threat. > > *[ofriel] Can you clarify why this doesn=E2=80=99t protect against an act= ive > intermediary in the HTTP session? Transferring the TLS records payloads i= n > HTTP bodies is directly analogous to transferring TLS records over > untrusted TCP network transport.* > In a "web app", the emscripten-compiled copy of libssl would necessarily be transmitted over the insecure HTTP connection that also contains ATLS. An active intermediary therefore could, for example, replace the library with a modified version that uses a broken PRNG. > > > > > > > --Richard > > > > > > On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz wrote: > > I don't understand why ATLS allows the app to be less "aware" than HTTP > CONNECT. I also don't understand how an ATLS client is closer to "one co= de > path" than HTTP CONNECT. It seems to me that your description of client > behavior applies equally to ATLS and HTTP CONNECT. > > > > On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes wrote: > > But I agree, it would be good to have some more clarity around use cases > and why not other solutions. > > > > On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes wrote: > > HTTP CONNECT is not great for some use cases because it requires the app > to be aware that it's dealing with a proxy. It's simpler if you can just > have one code path that works whether your TLS is intermediated or not. > With the solution outlined in the draft, you can just always ignore the > certificate the server sends in the first TLS connection (because it migh= t > be from a MitM), and then do all your cert validation, pin checks, etc. a= t > the application layer. > > > > On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz wrote: > > Why not use HTTP CONNECT? Or rather, it would be helpful to have a > section on when/why one would do this vs. CONNECT. > > > > On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes wrote: > > Hey TLS folks, > > > > Owen, Max, and I have been kicking around some ideas for how to make > secure connections in environments where HTTPS is subject to MitM / > proxying. > > > > The below draft lays out a way to tunnel TLS over HTTPS, in hopes of > creating a channel you could use when you really need things to be privat= e, > even from the local MitM. > > > > Feedback obviously very welcome. Interested in whether folks think this > is a useful area in which to develop an RFC, and any thoughts on how to d= o > this better. > > > > Thanks, > > --Richard > > > > > > On Mon, Oct 30, 2017 at 3:47 PM, wrote: > > > A new version of I-D, draft-friel-tls-over-http-00.txt > has been successfully submitted by Owen Friel and posted to the > IETF repository. > > Name: draft-friel-tls-over-http > Revision: 00 > Title: Application-Layer TLS > Document date: 2017-10-30 > Group: Individual Submission > Pages: 20 > URL: https://www.ietf.org/internet-drafts/draft-friel-tls-over= - > http-00.txt > Status: https://datatracker.ietf.org/ > doc/draft-friel-tls-over-http/ > Htmlized: https://tools.ietf.org/html/draft-friel-tls-over-http-00 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-friel-tls-over-http-00 > > > Abstract: > Many clients need to establish secure connections to application > services but face challenges establishing these connections due to > the presence of middleboxes that terminate TLS connections from the > client and restablish new TLS connections to the service. This > document defines a mechanism for transporting TLS records in HTTP > message bodies between clients and services. This enables clients > and services to establish secure connections using TLS at the > application layer, and treat any middleboxes that are intercepting > traffic at the network layer as untrusted transport. In short, this > mechanism moves the TLS handshake up the OSI stack to the application > layer. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > > > > > > --001a114d9bde1bdb2b055cde4650 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a114d9bde1bdb2b055cde4650-- --001a114d9bde275e9f055cde462a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t /WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo 7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm 9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/ UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCC85Px4oSL3TtI7mYgZPCKc /t58RdtxKORMVVBzs7cAYDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzEwMzEyMTE2NTNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAr7H6N00Xug06PEExhM2iMaqc1IG9b1gdk2h0nhrR QgwikOYMLh4k3cDmWrj5riJDlFnutD6Pg1J7mODHT91n/W/I/ymmU1K55tDVAjwqhNQ4vxT7K38w OJR369c9UodF2h8OVaJHhYoD8jWHjPH+Wkhk5qdGQwrabpb0oKoDhyR4VgiY7o7HnaGxMT1M+4HI Yc7GJsWyjUNy1ypI4yUwt1J7Ok2lGEVPqsZDomU6n2YnQjZ5u6dxKlqqYrdux7RRDqOT64yylen9 YqYJs1Ud3TdUPakuNFRCWW+fx0MI1N7h47cGlBrk9Awci0Qc9MmG4sq35SAblY7/914AhH3Niw== --001a114d9bde275e9f055cde462a-- From nobody Tue Oct 31 14:26:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AC013F74B for ; Tue, 31 Oct 2017 14:26:34 -0700 (PDT) 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 jG4uBpVw-c-z for ; Tue, 31 Oct 2017 14:26:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C3F13F745 for ; Tue, 31 Oct 2017 14:26:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A7E7EBE79; Tue, 31 Oct 2017 21:26:29 +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 1I9ABSajA4Q5; Tue, 31 Oct 2017 21:26:28 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 37A39BE74; Tue, 31 Oct 2017 21:26:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509485188; bh=YerkZLsYLQdqLi/SXwpT0xKou+WyikftVKzdyJYHPKs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JkxG2hG5mtnDWvv0Oi1Rj6KXyT4ZBf8zJSd+xtgxdmLQ0HtN6sKfekEZUtQKTKUal iAZQ4ua56D74AkLIgHbNhn8g7s3qAmGtCBRl2CU7Tx/5JQy39HYq81Q22bU4AYGNxq dGSO1Q2j61SdeBkcx4o/djVFkMvNBJlka522cN6U= To: "Owen Friel (ofriel)" , Richard Barnes , "" References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <2f5fba1a-2ee4-4881-7df1-b925a4468fba@cs.tcd.ie> <9989a0aee6784a7ba96bda23cf51d69b@XCH-RCD-012.cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6d448c71-8585-be88-302d-feee7e098ac9@cs.tcd.ie> Date: Tue, 31 Oct 2017 21:26:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <9989a0aee6784a7ba96bda23cf51d69b@XCH-RCD-012.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PRK0APALIKBuI8rxmI4a2sLw0cm3S2hTQ" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 21:26:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PRK0APALIKBuI8rxmI4a2sLw0cm3S2hTQ Content-Type: multipart/mixed; boundary="2kUuUlKj4jvKSSV9spASUAiPsISLOt50c"; protected-headers="v1" From: Stephen Farrell To: "Owen Friel (ofriel)" , Richard Barnes , "" Message-ID: <6d448c71-8585-be88-302d-feee7e098ac9@cs.tcd.ie> Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <2f5fba1a-2ee4-4881-7df1-b925a4468fba@cs.tcd.ie> <9989a0aee6784a7ba96bda23cf51d69b@XCH-RCD-012.cisco.com> In-Reply-To: <9989a0aee6784a7ba96bda23cf51d69b@XCH-RCD-012.cisco.com> --2kUuUlKj4jvKSSV9spASUAiPsISLOt50c Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Owen, On 31/10/17 21:03, Owen Friel (ofriel) wrote: >> Interesting. One bit puzzles me: wouldn't the new content-type >> give the game away and cause middleboxes to block this? >>=20 >> S. >>=20 > [ofriel] The intention isn=E2=80=99t to try and obscure the fact that t= here=20 > is an ATLS session. Even if that new content-type was not defined, > it would be easy to write a simple pattern match script on the > middlebox to identity the JSON body and leading base64 bytes of the > TLS records in the body. So that leaves me puzzled still, sorry. I can't think of a situation with a middlebox that isn't ok with the client doing proper TLS but is ok with ATLS. Can you give an example of such a situation? In case it helps, I can imagine that some middleboxes won't (yet) know about this and will let it through for a while, but that seems fairly brittle. So, I'd have thought it may be worthwhile trying to hide what's what here if you want it to be robust against an antagonistic middlebox or censor. But maybe you guys analysed that already and figured it'd not work. (Which brings me back to "puzzled":-) Cheers, S. >=20 >=20 --2kUuUlKj4jvKSSV9spASUAiPsISLOt50c-- --PRK0APALIKBuI8rxmI4a2sLw0cm3S2hTQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+OqDAAoJEC88hzaAX42ivEMH/RpcT6gb3adyFOJ9AeXvq9Pl RiBztHU2MCEhQSaAbGsEqBRB5/89htXJ4mLwckTTSR3khVMinVKoemmpdz79D3dw eFirjW09/I4pwVtkGl4JDirTFfw25UURA2voH9lIMj6kvTPlxmq+WMsHsTGQPSMe aczHAMyfMjFvXYvfFnUkYXcM8HM0tTKMNb67RVN/VzYU1xh0e6IhNFaL0kv7F3+Y yESrs0fbw/6g6xdWzIGhhl3BLIV3ioPzT58QzwdTBPzLxTZrq3cL1/DJF/gBaBDt VOoc7HtK6cKA3an2aE07N5ZowGNVpC3dJm/OVN5qk7t2PZ4bja0L8RRYO8JbkgI= =uETr -----END PGP SIGNATURE----- --PRK0APALIKBuI8rxmI4a2sLw0cm3S2hTQ-- From nobody Tue Oct 31 22:45:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592A113FCBC for ; Tue, 31 Oct 2017 22:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHkTwKtruHd1 for ; Tue, 31 Oct 2017 22:45:03 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 45BF913FCB1 for ; Tue, 31 Oct 2017 22:45:03 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id g125so1905542oib.12 for ; Tue, 31 Oct 2017 22:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wPfvWqcJqzv0SweMahEkLIRjcFAKajJ81caCb+goHuQ=; b=mCuSFjBkzdGYPP8D1aMA4Ere5Mh3HGnF3CggPHGm9OVGTjJeT0VgynU4FBWbFBp5qw S1shiCEwr5FzvJ7lxIpd1wvbGpiZZ+cBeIKWLaAdnboPCcM2KT+kE07lNA4r6GdP82p5 YmLbpk5zAMtYKBbufgfCbcsHwrM9VOjfkXGdhmpgN8VAo3QAy+4EeEFFi1pIYy2bg0YP HazTZbDmyDsPz5Pmx3jrn3COko2WEuyO4AxooskUq/NtkD+krYBd5Ag+xw/Ly21WAM3B pwtTRPXeRWfxhaJiy6iRa0gfkiPx/iYzXFvBq8ADf82Q26iiVw0CTFnGeTil9hRsTyj2 TjaA== 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=wPfvWqcJqzv0SweMahEkLIRjcFAKajJ81caCb+goHuQ=; b=ltreu3f7x1zg9gnd4yPQiyoWLq6YcXm773lXvyIqZV0u1vXXxNTX9iffeDh95Ljs15 qTuHaXf25A/9QosfpLe5hH9maUnXY0DZF5J4Nan1UoyZnH12Naqv/AC+2nyPunf+6pHF Bzz7lj8pjksPN/gYQE1iz0TOCuBDc/8U9zd9ytKQvYPqy0GhKtYguNL7sfEJ2g1Q4jFw jXzSleL83Vx5zDGpKX6X5lyJmgn0zE+fxRZis1KdfzlZ82g61qlSk6vZtRKPTTJ2yfsm ylP5rgE5nG8OfO8UeAFYymAP6oT5qPusbAJ3HfHCfrI+L9sf0GyTNiNPpx806BC8sDWi OJvg== X-Gm-Message-State: AMCzsaXE/NNt4XIio5RuE/nM0X0tiLxny64+O/mFp5dSuAtX8qduiUWr 0OdmgecfZSP0JzD/P8Sp68U8eqbohSA6EvEBJiNvEdCK X-Google-Smtp-Source: ABhQp+Q+KmRXmsmyIQ4CfTO0Pe8MJx4hpMenczTAX/UBWmhwrFokuZHmzyHUD8+20+OLvHBbak2hJokeqi2U4gU1Um0= X-Received: by 10.202.166.141 with SMTP id t13mr2255527oij.392.1509515102283; Tue, 31 Oct 2017 22:45:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Tue, 31 Oct 2017 22:45:01 -0700 (PDT) From: Martin Thomson Date: Wed, 1 Nov 2017 16:45:01 +1100 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] DTLS KeyUpdate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 05:45:06 -0000 (From https://github.com/tlswg/dtls13-spec/issues/25) Using the TLS process for KeyUpdate - as the current draft does - leads to a suboptimal set of choices in implementations. Sending KeyUpdate followed immediately by a key change means that KeyUpdate isn't a reliable indicator of a key change at the receiver. If the record containing the KeyUpdate is lost, then the receiver will be unable to decrypt anything sent after it unless it looks at the epoch and tries the new keys. That suggests a receiver design much closer to the one in QUIC, where the KEY_PHASE bit (here, the low bit of the epoch) is the only signal of a key update. The receiver could buffer those records, but I don't see why it would choose head-of-line blocking and a potentially-large memory commitment over trialing the new epoch. I would prefer a different design, even if it diverges from the TLS design. 1. That could be the same design as QUIC uses, with the epoch bit signaling intent. The cost there is that you need to use the bit as an acknowledgment of a key update, so you end up having to keep key updates in lock step, even if no update is needed. If there are asymmetric sending patterns, this isn't ideal. 2. Wait until the KeyUpdate is acknowledged before installing new keys. When KeyUpdate is received, the receiver installs new keys, but retains old keys on a timer (the holddown timer would do). The sender waits for the ACK and starts using new keys when it sees it. The cost here is that switching keys can't be immediate and it requires hooks into the ACK handling logic, neither of which is ideal. I have implemented the former and it's a little ugly, but I haven't tried the latter.


On Tue, Oct 31, 2017 at 5:03 PM, Owen Friel (ofriel) = <ofriel@cisco.com<= /a>> wrote:

=C2=A0

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ben Schwartz
Sent: 31 October 2017 01:35
To: Richard Barnes <rlb@ipv.sx>
Cc: <tls@ietf.o= rg> <tls@ietf.o= rg>
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over= -http-00.txt

=C2=A0

On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes <= rlb@ipv.sx> wrote:

It requires awareness in the following sense: If by = chance the client is in a nice, open network and the base TLS connection go= es directly to the server, CONNECT is kind of unnatural; you would want the= client to do something different in that case.

=C2=A0

Surely this is equally true/untrue of ATLS.=C2=A0 Wh= y do double-TLS if it can be avoided?=C2=A0 But then, how does the applicat= ion know whether to do ATLS encapsulation?=C2=A0 It's the same question= in both cases.

[ofriel] The draft does state =E2=80=9C=
As an optimisation, clients may choose to o=
nly use ATLS as a fallback

=C2=A0=C2=A0 mechanism if certificate validation= fails on the transport layer TLS

=C2=A0=C2=A0 connection to the service=

=E2=80=9D<= /p>

It should be easy for a device to detec= t the presence of a middlebox if the network layer TLS connection presents = a service certificate that has the expected SAN/CN, but is signed by an unexpected/untrusted CA (i.e. one not baked in= to/explicitly configured on the device).


Yes, but the cli= ent could equally well fall back to HTTP CONNECT in this case.=C2=A0 My com= ments are all directed to the question of why to use ATLS instead of an exi= sting solution, such as "TLS over HTTP CONNECT".
=C2=A0=

=C2=A0

=C2=A0 You're correct that you *could* configure= the server to handle connect properly, but all of the options for doing th= is are kind of cumbersome -- either you have to stick a possibly-unnecessar= y proxy in front of the server, or handle CONNECT on the server, which is not really well-supported by web application frame= works.=C2=A0 By contrast, running data over POST is ubiquitous.

=C2=A0

This makes a certain amount of sense to me.=C2=A0 If= it were up to me, rather than design a TLS-specific transport, I'd be = more inclined to propose a standardized version of something like Crowbar.= =C2=A0

[ofriel] /me reads. =E2=80=98lik= e=E2=80=99 appears to be the operative word here based on author comments o= n https://github= .com/q3k/crowbar: =E2=80=9CCr= owbar=C2=A0DOES NOT PROVIDE ANY DATA CONFIDENTIALITY=E2=80=9D


<= /div>
Yes, but "TLS over Crowbar" does provide confidentialit= y, and that is the alternative to ATLS that I am proposing in this sentence= .

(Or just document that reverse proxies and framework= s ought to do something reasonable with CONNECT.

[ofriel] CONNECT would just open= a tunnel to get packets through the proxy to the service, but would requir= e the proxy to *not* attempt to do TLS interception, which is exactly what we are trying to allow. If policy dictates that ever= ything must be intercepted, this mechanism enables that.

=

I don't understand w= hich proxy you're referring to, or how this distinguishes ATLS from &qu= ot;TLS over HTTP CONNECT".

)=C2=A0 Otherwise this seems to be ossifying the pro= xy, privileging TLS and preventing deployment of=C2=A0Noise protocol=C2=A0or whatever the = future may hold.

[ofriel] One of the reason for b= lindly transporting TLS and not in any way restricting or customising the T= LS records transferred was to be future compatible with all future versions of TLS; and also to allow an application to lever= age a single software library for both network transport and application cr= ypto exchanges.


<= /div>
OK, but you can be even more abstracted by simply transporting a = byte-stream, and letting the application developer choose what protocol to = speak in that stream.=C2=A0 This shares even more code between the "ne= twork" and "application" usage of TLS, since they both flow = over bytestream abstractions (no need to expose the TLS record layer).

It was also pointed to me off-list that you can gene= rate POST requests from Javascript in XHR, but not CONNECT requests.=C2=A0 = So doing this over POSTs also makes it accessible to web apps.=C2=A0 (`emsc= ripten libssl.a` left as an exercise to the reader.)

=C2=A0

It seems your threat model assumes an adversary who = is an active intermediary in your HTTP session.=C2=A0 If so, then this woul= dn't seem to protect the user against the threat.

[ofriel] Can you clarify why thi= s doesn=E2=80=99t protect against an active intermediary in the HTTP sessio= n? Transferring the TLS records payloads in HTTP bodies is directly analogous to =C2=A0transferring TLS records over untrusted TCP= network transport.

=

In a "web app", the emscripten-compiled copy = of libssl=C2=A0would necessarily be transmitted over the insecure HTTP conn= ection that also contains ATLS.=C2=A0 An active intermediary therefore coul= d, for example, replace the library with a modified version that uses a bro= ken PRNG.
=C2=A0

=C2=A0

=C2=A0

=C2=A0=

--Richard<= /u>

=C2=A0

=C2=A0

On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz <bemasc@google.com&= gt; wrote:

I don't understand why ATLS allows the app to be= less "aware" than HTTP CONNECT.=C2=A0 I also don't understan= d how an ATLS client is closer to "one code path" than HTTP CONNE= CT.=C2=A0 It seems to me that your description of client behavior applies equally to ATLS and HTTP CONNECT.

=C2=A0

On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes <= rlb@ipv.sx> wrote:

But I agree, it would be good to have some more clar= ity around use cases and why not other solutions.

=C2=A0

On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes <= rlb@ipv.sx> wrote:

HTTP CONNECT is not great for some use cases because= it requires the app to be aware that it's dealing with a proxy.=C2=A0 = It's simpler if you can just have one code path that works whether your= TLS is intermediated or not.=C2=A0 With the solution outlined in the draft, you can just always ignore the certificate the serv= er sends in the first TLS connection (because it might be from a MitM), and= then do all your cert validation, pin checks, etc. at the application laye= r.

=C2=A0

On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz <bemasc@google.com&= gt; wrote:

Why not use HTTP CONNECT?=C2=A0 Or rather, it would = be helpful to have a section on when/why one would do this vs. CONNECT.<= /u>

=C2=A0

On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes <= rlb@ipv.sx> wrote:

Hey TLS folks,

=C2=A0

Owen, Max, and I have been kicking around some ideas= for how to make secure connections in environments where HTTPS is subject = to MitM / proxying.

=C2=A0

The below draft lays out a way to tunnel TLS over HT= TPS, in hopes of creating a channel you could use when you really need thin= gs to be private, even from the local MitM.=C2=A0

=C2=A0

Feedback obviously very welcome.=C2=A0 Interested in= whether folks think this is a useful area in which to develop an RFC, and = any thoughts on how to do this better.

=C2=A0

Thanks,

--Richard

=C2=A0

=C2=A0

On Mon, Oct 30, 2017 at 3:47 PM, <internet-drafts@ietf.org= > wrote:


A new version of I-D, draft-friel-tls-over-http-00.txt
has been successfully submitted by Owen Friel and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-friel-tls-over-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Layer TLS
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00= .txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker= .ietf.org/doc/draft-friel-tls-over-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html= /draft-friel-tls-over-http-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatrack= er.ietf.org/doc/html/draft-friel-tls-over-http-00


Abstract:
=C2=A0 =C2=A0Many clients need to establish secure connections to applicati= on
=C2=A0 =C2=A0services but face challenges establishing these connections du= e to
=C2=A0 =C2=A0the presence of middleboxes that terminate TLS connections fro= m the
=C2=A0 =C2=A0client and restablish new TLS connections to the service.=C2= =A0 This
=C2=A0 =C2=A0document defines a mechanism for transporting TLS records in H= TTP
=C2=A0 =C2=A0message bodies between clients and services.=C2=A0 This enable= s clients
=C2=A0 =C2=A0and services to establish secure connections using TLS at the<= br> =C2=A0 =C2=A0application layer, and treat any middleboxes that are intercep= ting
=C2=A0 =C2=A0traffic at the network layer as untrusted transport.=C2=A0 In = short, this
=C2=A0 =C2=A0mechanism moves the TLS handshake up the OSI stack to the appl= ication
=C2=A0 =C2=A0layer.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=C2=A0

=C2=A0

_______________________= ________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0