From nobody Fri Aug 4 05:50: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 CA6C1132165 for ; Fri, 4 Aug 2017 05:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 PW_iyGcx2zbe for ; Fri, 4 Aug 2017 05:50:37 -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 4FF3D131CB6 for ; Fri, 4 Aug 2017 05:50:35 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id x191so8140131qka.5 for ; Fri, 04 Aug 2017 05:50:35 -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=8ONh8vnjnNGMVklU4qZtLX6461RThs/0tGAa5peiIAs=; b=IqXh8OiuL4HH7tXGHnr7p12xozdYMucdm5tZK0tUZYMoPZI2ytOx9Bd9VN8VrDrZ4g +XJI5UN9AqhAFTs+o/8UlTHwHKFvCXZszoGFfgJGk02d+xdu1CVOCYl06aIAGjRIcKXx ojsFXW9d38iEdnUDAdU6UFJBEhRrURX5fHz74= 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=8ONh8vnjnNGMVklU4qZtLX6461RThs/0tGAa5peiIAs=; b=UDiHC47axTgTJKQN+eyXo5qH0dmsxLxOi275NSgrEPU6pSDmbl7QAs6d52ADtQICDg ubdY0abIslXKQHAhL86ORd2jgxh1pd8tsIxp1jPDPeyjdESfOc64GuAMaXxk/Z89mez8 3cjo5b9YY8Zq9KG3S8UxXVSNu9ow8WuuRx0DuFRQG5MF7cQOWHFVF7as6YWUStrW4Llu PF+1gVdVGCkv/cHgte9j608cF8VUVOdz/HDgZXMbtUIDIYcfnSQFOjdb/lnRHPc5JiNT WuBRk6njimW4Ywa+trGMuC7G9PRkXwLjriBPGl3vl4ts/Ac3v8elN+QoMSENTyL5PNVb 8zNQ== X-Gm-Message-State: AHYfb5g4jNqWNN5SbW3SglVM0N42hv23ne7QAAUUW9PrsWT5iIXsdPET de1KItxJUcWuwLEGMZQP7g== X-Received: by 10.55.124.130 with SMTP id x124mr2574207qkc.54.1501851034183; Fri, 04 Aug 2017 05:50:34 -0700 (PDT) Received: from [172.16.0.18] ([96.231.223.191]) by smtp.gmail.com with ESMTPSA id t1sm929641qkb.91.2017.08.04.05.50.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 05:50:32 -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: Date: Fri, 4 Aug 2017 08:50:31 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] WG adoption call: draft-thomson-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 12:50:39 -0000 At our IETF 99 session, there was support in the room to adopt = draft-thomson-tls-record-limit [0]. We need to confirm this support on = the list so please let the list know whether you support adoption of the = draft and are willing to review/comment on the draft before 20170818. = If you object to its adoption, please let us know why. Cheers, J&S [0] https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/= From nobody Fri Aug 4 05:50: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 512CD13216F for ; Fri, 4 Aug 2017 05:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xjHUmktvC3Qe for ; Fri, 4 Aug 2017 05:50:38 -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 E55A9129AF9 for ; Fri, 4 Aug 2017 05:50:36 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id d145so8352428qkc.2 for ; Fri, 04 Aug 2017 05:50:36 -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=38NmGhkQpTdMJ9G2Y6H+fA0OCP755zHB8WKwtvLccqQ=; b=TPbCMBAvxWrYSHylVo4ETwu12ITwEAoczsi+7BzRHcdM1FXMH1nTu5dcvTNKGEwFrN sFYQW66FFZ0Dr/YQU8rkz70hDp9S/UVVKZZD4GCW54705v2g+Yk38OsnbDLoaJwaHIKy LuNmKpcYsG+pcsGddufXpNvSH57w5PZR0K2dk= 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=38NmGhkQpTdMJ9G2Y6H+fA0OCP755zHB8WKwtvLccqQ=; b=AJDlMmBx9fA0zFev+rZbPcKMqhx7V9mqwWRHzVy2eCIAL6w9CU2rUgtfWzxTT839my fC/XJjY4dNQXdG3auxiYOy4oPXp/a9jCoWCj0IIFT/7bmCyZv0n0bQrUtnaml24vOIxE Y5Xc0ntmW2Qoij5b8/eio9weXAgA32WoZ8PsR5Pn9BhQN1B8cWUohttk11GO5vQg0D0v sFk1Q9PmFK+l/K2CHdQwhaYM6Z0P7m8Um3X4CIbJe7W5m4xeTbV+Bim/aO8bvA7H4Cvv wkXcJuIg5b5c8jQ/O8uDktZwoa3RnFanVpbJX8WP/YH6R8OdIoc6x3tagRQPbdQg6nml +WOg== X-Gm-Message-State: AHYfb5jS2C/K6yrdQfgbYJ4Os3Lanj/EaVBVLzzVRKhbOTQwamGg9cS2 SAYo9v7AAZq8aaUrSbesQQ== X-Received: by 10.55.137.71 with SMTP id l68mr2631778qkd.166.1501851035893; Fri, 04 Aug 2017 05:50:35 -0700 (PDT) Received: from [172.16.0.18] ([96.231.223.191]) by smtp.gmail.com with ESMTPSA id t1sm929641qkb.91.2017.08.04.05.50.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 05:50:34 -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: Date: Fri, 4 Aug 2017 08:50:33 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 12:50:40 -0000 At our IETF 99 session, there was support in the room to adopt = draft-huitema-tls-sni-encryption [0]. We need to confirm this support = on the list so please let the list know whether you support adoption of = the draft and are willing to review/comment on the draft before = 20170818. If you object to its adoption, please let us know why. Cheers, J&S [0] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/= From nobody Fri Aug 4 06:21: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 6369E129AF3 for ; Fri, 4 Aug 2017 06:21:47 -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 tZnTOw_oDdBP for ; Fri, 4 Aug 2017 06:21:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id C393A1321BB for ; Fri, 4 Aug 2017 06:21:41 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id A1A37F99A; Fri, 4 Aug 2017 09:21:39 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 44A3220578; Fri, 4 Aug 2017 09:21:37 -0400 (EDT) From: Daniel Kahn Gillmor To: Sean Turner , "\" In-Reply-To: References: Date: Fri, 04 Aug 2017 09:21:37 -0400 Message-ID: <87pocbwjry.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 13:21:47 -0000 On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote: > At our IETF 99 session, there was support in the room to adopt > draft-huitema-tls-sni-encryption [0]. We need to confirm this support > on the list so please let the list know whether you support adoption > of the draft and are willing to review/comment on the draft before > 20170818. If you object to its adoption, please let us know why. I support wg adoption of this draft and am willing to review before 20170818. --dkg From nobody Fri Aug 4 06:42: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 2E23E131C8D for ; Fri, 4 Aug 2017 06:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjFxz8C4O0zC for ; Fri, 4 Aug 2017 06:42:05 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 13D57132179 for ; Fri, 4 Aug 2017 06:42:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id E72C4C6A8C; Fri, 4 Aug 2017 16:42:02 +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 RJuQc9i1U3hm; Fri, 4 Aug 2017 16:42:02 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 97BD52317; Fri, 4 Aug 2017 16:42:00 +0300 (EEST) Date: Fri, 4 Aug 2017 16:42:00 +0300 From: Ilari Liusvaara To: Sean Turner Cc: "" Message-ID: <20170804134200.c4hguugiv2yzbr4b@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] WG adoption call: draft-thomson-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 13:42:07 -0000 On Fri, Aug 04, 2017 at 08:50:31AM -0400, Sean Turner wrote: > At our IETF 99 session, there was support in the room to adopt > draft-thomson-tls-record-limit [0]. We need to confirm this > support on the list so please let the list know whether you support > adoption of the draft and are willing to review/comment on the draft > before 20170818. Yeah, adopt. I have experimentented with implementing extremely similar extension. Reviewing the draft, one technical comment: 1) It is really the ciphertext size that needs to be limited, due to in-place decryption being possible. As proposed by PR #1 in the repository, One way to limit the ciphertext is to give the record size limit as payload size and then apply minmax limit to ciphertext size. -Ilari From nobody Fri Aug 4 07:17: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 910B9131C8D for ; Fri, 4 Aug 2017 07:17:08 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AJiUoWrTg_Ht for ; Fri, 4 Aug 2017 07:17:05 -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 75BD3132334 for ; Fri, 4 Aug 2017 07:17:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 13809BE39; Fri, 4 Aug 2017 15:17: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 hYA9SgyFaprt; Fri, 4 Aug 2017 15:17:01 +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 53032BE2D; Fri, 4 Aug 2017 15:17:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1501856221; bh=75l7YLlvrqPgzlw30D7S0OKyz7N+6BdRKC0/wQMu5gI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mn6A8cdKoA/kA+p1kHVuANdShFcJONpbrze8g9nDzNuqMaXE5kmEmEpMUcZvQs3N1 QbsK3rOGH2TCwVkpypJehc+6AhxOo1dH+1QABwtniwtQNxwcGB4KE3MPoD/hLq+3vV DstUPA53uyXZSrBFoWZIzW7mgGLFbA1syzV3NCtY= To: Daniel Kahn Gillmor , Sean Turner , "" References: <87pocbwjry.fsf@fifthhorseman.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <4185d677-716a-e6a9-1f4b-7ec82b0a89a6@cs.tcd.ie> Date: Fri, 4 Aug 2017 15:17:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <87pocbwjry.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wGPJd6xllnVg87hN2Fg94kHe3B8qFhlkB" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 14:17:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wGPJd6xllnVg87hN2Fg94kHe3B8qFhlkB Content-Type: multipart/mixed; boundary="Gu2v5mfijqXFPblXBHctr6gXNfNcFgOhp"; protected-headers="v1" From: Stephen Farrell To: Daniel Kahn Gillmor , Sean Turner , "" Message-ID: <4185d677-716a-e6a9-1f4b-7ec82b0a89a6@cs.tcd.ie> Subject: Re: [TLS] WG adoption call: SNI Encryption References: <87pocbwjry.fsf@fifthhorseman.net> In-Reply-To: <87pocbwjry.fsf@fifthhorseman.net> --Gu2v5mfijqXFPblXBHctr6gXNfNcFgOhp Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 04/08/17 14:21, Daniel Kahn Gillmor wrote: > On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote: >> At our IETF 99 session, there was support in the room to adopt >> draft-huitema-tls-sni-encryption [0]. We need to confirm this support= >> on the list so please let the list know whether you support adoption >> of the draft and are willing to review/comment on the draft before >> 20170818. If you object to its adoption, please let us know why. >=20 > I support wg adoption of this draft and am willing to review=20 +1 > before > 20170818. Not sure about the date - if it's finished by then that'd be pretty speedy:-) S >=20 > --dkg >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --Gu2v5mfijqXFPblXBHctr6gXNfNcFgOhp-- --wGPJd6xllnVg87hN2Fg94kHe3B8qFhlkB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZhIHcAAoJEC88hzaAX42inawH/iUAn6OI7XefnQ2MtmB6dZCh W4kKXqaj2R+DgDqzJ/WHZpjPFRdUnRSQzwkNrK3zWmJlR25LqPCzXt341G3b3eZO 9tFll6q0NXh0zR0IkJl+HcVJ2Abh8D7iTqDeHnSqO1P8n4vtAlxPmbli6Wtrg3am 5lhTD5dKapJbRa3yzy52pJe3bMvqu7P3IE4Y1s/Ihr7z7zA8wFeIXj+II9uEN+mS 0X5f74xyxkKv5UfqD66bCyFtV6n7d4Y2uQOvu+Q9mSrDuUFoBPghrDBCVtXEiaMA MYpPGNTjYjXM9AKNXLt1bfrFSReZoq2yO00p9SFjZKI/iUvXduoJxK/Aa1gdMoc= =UAXi -----END PGP SIGNATURE----- --wGPJd6xllnVg87hN2Fg94kHe3B8qFhlkB-- From nobody Fri Aug 4 07:53: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 953AC131FE1 for ; Fri, 4 Aug 2017 07:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1BNedUlof4q for ; Fri, 4 Aug 2017 07:53:48 -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 311C7131F5A for ; Fri, 4 Aug 2017 07:53:47 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id r199so6730343vke.4 for ; Fri, 04 Aug 2017 07:53:47 -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=qa74sOnMfKvpuuvpk+tnSSaha7K0HVSGxk8uchxWpjs=; b=ZTBcyRDmKDGyWPcw7QYqlmxlSz2Q/tCDCg2+jbLz7CY55L602M6tINJBybNEZFxki2 +xkbnvx5H8R6KXZmYsoHjhzhv4Zv9l4DemdF1UkSB8LVUtPlaR92fcWKm53vosWkwjdn kyj9F6qIt8uAIjxZ53afdXr7cvMlepqf9kahNheeGgeCuZgau2aFocIAxmUNos2KSSyl bcc0939xQH9aWaf6ZKYmhBEhCed2YiTayVsZicBoAzEdo/sCm0HDI4NGAyoaBpe5Nygm so2aXSDCL5y/+j3VGBdxYVShWDalbBEA0eKql3+xlV4GjCPjtsD16aoWyb4w0PrwuRH+ /0Tg== 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=qa74sOnMfKvpuuvpk+tnSSaha7K0HVSGxk8uchxWpjs=; b=cPQChtoW7UZderhJUCD6+PmMOPyK1DzPHhgzt4wNIRr3HPyjzP32LH0ZZ0PoOGavUL 7SSUlD76XRFJt3WqJ6xqr/eQjM82KMqXmJJvU0ZtruBtjrrGvvntdlhXa2FiSZPLAAdF PJ6lR5ueXYMrj44q7LRMZZfcDcpth4PXEcCbrcM07Luk1nLhI22n5eGLzzybYQEuZSAk G018iXg4sZR+nJ3ItXkq1UUmlGO3b4kwqDAed8jTxl0s7XEItFnggv748S+eUza/2rnC qjDUZreyF2r6lleHJxirn1bI9LpaSZ9E0lXXld1Kc75C9hl5AkhQr6+tmvh43Nvy4yTw x56w== X-Gm-Message-State: AHYfb5iphgjUA4KZrTALC8CpgeOk5K0HM5PfZp1tu0pYjYDr0u5a+vzr 5Ha64/QASGtaep+P326t2kexClM3lWVphAs= X-Received: by 10.31.139.207 with SMTP id n198mr1617633vkd.3.1501858425954; Fri, 04 Aug 2017 07:53:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.147.73 with HTTP; Fri, 4 Aug 2017 07:53:45 -0700 (PDT) In-Reply-To: <4185d677-716a-e6a9-1f4b-7ec82b0a89a6@cs.tcd.ie> References: <87pocbwjry.fsf@fifthhorseman.net> <4185d677-716a-e6a9-1f4b-7ec82b0a89a6@cs.tcd.ie> From: Ben Schwartz Date: Fri, 4 Aug 2017 10:53:45 -0400 Message-ID: To: Stephen Farrell Cc: Daniel Kahn Gillmor , Sean Turner , "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114584d0035c240555eeaad9" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 14:53:51 -0000 --001a114584d0035c240555eeaad9 Content-Type: multipart/alternative; boundary="001a114584d0fbf4460555eea92e" --001a114584d0fbf4460555eea92e Content-Type: text/plain; charset="UTF-8" I support adoption and have reviewed the draft. On Fri, Aug 4, 2017 at 10:17 AM, Stephen Farrell wrote: > > > On 04/08/17 14:21, Daniel Kahn Gillmor wrote: > > On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote: > >> At our IETF 99 session, there was support in the room to adopt > >> draft-huitema-tls-sni-encryption [0]. We need to confirm this support > >> on the list so please let the list know whether you support adoption > >> of the draft and are willing to review/comment on the draft before > >> 20170818. If you object to its adoption, please let us know why. > > > > I support wg adoption of this draft and am willing to review > > +1 > > > before > > 20170818. > > Not sure about the date - if it's finished by then that'd > be pretty speedy:-) > > S > > > > > --dkg > > > > _______________________________________________ > > 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 > > --001a114584d0fbf4460555eea92e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption and have reviewed the draft.

On Fri, Aug 4, 2017 at= 10:17 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 04/08/17 14:21, Daniel Kahn Gillmor wrote:
> On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote:
>> At our IETF 99 session, there was support in the room to adopt
>> draft-huitema-tls-sni-encryption [0].=C2=A0 We need to confir= m this support
>> on the list so please let the list know whether you support adopti= on
>> of the draft and are willing to review/comment on the draft before=
>> 20170818.=C2=A0 If you object to its adoption, please let us know = why.
>
> I support wg adoption of this draft and am willing to review

+1

> before
> 20170818.

Not sure about the date - if it's finished by then that'd
be pretty speedy:-)

S

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--dkg
>
> _______________________________________________
> 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


--001a114584d0fbf4460555eea92e-- --001a114584d0035c240555eeaad9 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 oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAoDdVHleUz/sSuMwwLTLD4 By/Wn5ZjjNvQQf8jUAyDOzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MDQxNDUzNDZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAIWF50ShhBI9DHq8YAtO6zc9YK1kIxX2mfpMpufL5 qwP5qnTq4ocLni9zsyhiYIntrwfZxPyDlBh0scPBqcZZmJ14o+qETiOTUSc4ciYLbNk2TLP21ozP ev83piP/GMn23WwVGhdPiuXEa/ign+JIOeKVjNlrEwUiDzU+HMUhUrxmB3iL0PfHQK6YlhndfDZW Tc1Kmgs7jmbtSrrAFBcbMSTyXne3TT1RX8aKre+ZNSmNPfLBpcaCzdZFXAqo5LPfL/iZIjXQiQR3 dQ47HodYiVitf2cs/MVsQIvG+lVBTlWfl6IsyfnnCNyZ/IicSTeY+VKos8wqA4LHCfVNh/E9qQ== --001a114584d0035c240555eeaad9-- From nobody Fri Aug 4 08:03: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 CB73E132334 for ; Fri, 4 Aug 2017 08:03:54 -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 1vOD5D4DMeDc for ; Fri, 4 Aug 2017 08:03:53 -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 5D59B132331 for ; Fri, 4 Aug 2017 08:03:52 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id d71so17462062oih.0 for ; Fri, 04 Aug 2017 08:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hAeabZ/1ejItC0JRhLfzQyCa0vJJj5SdWA0K8fcj5Ts=; b=LuTdVn2CH6OS5f3/BYDrOPig0HLn7rp14FtVWJpao6f13P5xfu0DRVXdJRVfJ5p0We ZJ0qetLBTi98EmgDa3fdAlVvB28ThlKQGGuIhTqClqbJgbAfySmj6voURo/lVehlYGp5 S7aG39jhxEFzzk1gXVJm6II/ElRt/Ui1883DmXGOJrxY/7AUAaZe+0Wbhf98jRo/OGhK AEZwN8BTRypMffgcF55nC1C4dT794BlMRq2BI64W+RHBjWgiWiiCun17AlV/cOG40rWs jcaN0JfAtqNtUrQBXyvHVHWdoBVruHRgUtluD1uaqqPDP8GznoImtafVS6yaZpEiqKFO 7uRQ== 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=hAeabZ/1ejItC0JRhLfzQyCa0vJJj5SdWA0K8fcj5Ts=; b=CnUa2baB5/Fqybi1T9lIS3K2x6nftN/OwlUHQhbE3bjChY8C3x8df1M0WGyH7FtaBP vHiR9NLqm+mIV8dDugtVvR04JcsDKrMW8A+NQLiBBwSSGQZbEip5WsBkvmvTSH0rSdKH 6vnePm+Nj5JTEX6dkrn7kcCkVDXV15wjJJcZZKDjlcvMAO4zb/msI/u6ADH5B3xbyCub wM/zyInfiZVqh3IIYr0cRFsVHdoKOZgLVmIsTfNcEbzGRYONh7R5CREpavRtoNrmNLLI jssCLQCHprafzOZimbe/GMzBduKc5kUhkA8soUjcN4zcvK0ewR5DxywHTYrKbFhL1z0f P2ow== X-Gm-Message-State: AHYfb5gMzNdUoEjrIOWB860B8f1FIcQia083ANj99gxXC3n0quIf+NdI r/8FP7LZXpMgyLM93IP39m5+Wy8AMKYt X-Received: by 10.202.244.129 with SMTP id s123mr2248730oih.318.1501859029709; Fri, 04 Aug 2017 08:03:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.91.73 with HTTP; Fri, 4 Aug 2017 08:03:49 -0700 (PDT) In-Reply-To: References: <87pocbwjry.fsf@fifthhorseman.net> <4185d677-716a-e6a9-1f4b-7ec82b0a89a6@cs.tcd.ie> From: Christopher Wood Date: Fri, 4 Aug 2017 08:03:49 -0700 Message-ID: To: Ben Schwartz Cc: Stephen Farrell , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 15:03:55 -0000 I also support adoption, have reviewed it, and will continue to do so. Best, Chris On Fri, Aug 4, 2017 at 7:53 AM, Ben Schwartz wrote: > I support adoption and have reviewed the draft. > > On Fri, Aug 4, 2017 at 10:17 AM, Stephen Farrell > wrote: >> >> >> >> On 04/08/17 14:21, Daniel Kahn Gillmor wrote: >> > On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote: >> >> At our IETF 99 session, there was support in the room to adopt >> >> draft-huitema-tls-sni-encryption [0]. We need to confirm this support >> >> on the list so please let the list know whether you support adoption >> >> of the draft and are willing to review/comment on the draft before >> >> 20170818. If you object to its adoption, please let us know why. >> > >> > I support wg adoption of this draft and am willing to review >> >> +1 >> >> > before >> > 20170818. >> >> Not sure about the date - if it's finished by then that'd >> be pretty speedy:-) >> >> S >> >> > >> > --dkg >> > >> > _______________________________________________ >> > 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 > From nobody Fri Aug 4 08:17: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 94F44132452 for ; Fri, 4 Aug 2017 08:17:19 -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 (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 EKJL7NTIEKPQ for ; Fri, 4 Aug 2017 08:17:18 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA1C13243D for ; Fri, 4 Aug 2017 08:17:18 -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 v74FCOqo010016; Fri, 4 Aug 2017 16:17:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type; s=jan2016.eng; bh=8Rv4MyeSB4KvoGKgsyL7AWLbzJ2ydsVuODbDyFB6UY0=; b=LeNfIs8OTCjZh9R2qyPsjaMQmdcxRsUDtejxrPjVg1k/WN9tdyZxjJByltplwal/mWo7 wTtHrVTo2mufnfuzqTcpkZ/nF5mESFyBDKgVHE0F6BbH6VyVyOrh5LDiYxHsIYjCEVYN gYYXtnK1z3+o+mKvUY9AAsnovrvfK+OkFuRNewmKls/xDVacNS/BlRC33TwyxWPNLpPs qXhVoPZ9D1/0+YP0USdAkSPrGAzgC7kh4rSDRB+L7W2h+jUsg0QFSxptHAUUlo6ppuAT sTwuwF5tvVm29kMd+9ud/sCr348gaWKYndOGbFITZ6/2AN1ZSjmQq/7FklncIQgBC9vT JA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2c40tk1re7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Aug 2017 16:17:16 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v74FGSYK007273; Fri, 4 Aug 2017 11:17:15 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2c0npw100j-1; Fri, 04 Aug 2017 11:17:15 -0400 Received: from bos-mpeve.kendall.corp.akamai.com (unknown [172.28.17.141]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 2165520067; Fri, 4 Aug 2017 09:17:15 -0600 (MDT) From: Brian Sniffen To: Sean Turner , "\" In-Reply-To: References: Date: Fri, 04 Aug 2017 11:17:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-04_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708040234 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-04_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 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-1706020000 definitions=main-1708040233 Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 15:17:19 -0000 Sean Turner writes: > At our IETF 99 session, there was support in the room to adopt draft-huitema-tls-sni-encryption [0]. We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170818. If you object to its adoption, please let us know why. I support wg adoption of this draft and am willing to review before 20170818. -Brian -- Brian Sniffen Akamai Technologies From nobody Fri Aug 4 08:31: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 41544132360 for ; Fri, 4 Aug 2017 08:31:05 -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 LkKfO3jm51o3 for ; Fri, 4 Aug 2017 08:31:04 -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 1B9AD132343 for ; Fri, 4 Aug 2017 08:31:04 -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 v74FQxvt015711; Fri, 4 Aug 2017 16:30:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type; s=jan2016.eng; bh=NzCEfRY6e2wmmBZINSeMzU+b9qq3eOACNvuKYNj3RNE=; b=JXISaEoVG91yc/zE2Lo/SqSwqpKlf53jp+yL1E+/e+ayOcDPZuz4m4t+Y4roEiKyjK7Q ild35r4I57wiKY8WL9PlaT8BkPfrPmCgNHjFTa+CXJOmK0Fufqk5YSXjmHp3fgq4AuMq TW+LnVbcx7RjRmyZUNG8To1b51EGyDDck7yxsQyp3lBkr+adTuCgo2vh9tziudKyHYRd B1U28+ek/1ySYaPZTUUnN3bnadatjYZKfhY3dlLkTrwt8+9e0Tf9lXX6+LOyCONR/ZsI zJVw+lFperc21y8iXEDH6BG7TnwUQXVFGx8gu9R1Uk2T/IB96LWTIPGonyFWCFe3WBct uQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2c3xvmswtx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Aug 2017 16:30:53 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v74FPfFM016102; Fri, 4 Aug 2017 11:30:53 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2c0npv7tsr-1; Fri, 04 Aug 2017 11:30:52 -0400 Received: from bos-mpeve.kendall.corp.akamai.com (unknown [172.28.17.141]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id E61681FC71; Fri, 4 Aug 2017 15:30:52 +0000 (GMT) From: Brian Sniffen To: Christian Huitema , "tls\@ietf.org" In-Reply-To: <422ef2c7-4d99-20d2-8a39-ffd61277e0bd@huitema.net> References: <149810504637.30481.937244297632371838.idtracker@ietfa.amsl.com> <422ef2c7-4d99-20d2-8a39-ffd61277e0bd@huitema.net> Date: Fri, 04 Aug 2017 11:30:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-04_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708040237 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-04_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 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-1706020000 definitions=main-1708040237 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-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: Fri, 04 Aug 2017 15:31:05 -0000 Having promised a review before August 18, I have three issues I'd like to talk about. But first, thanks for keeping pushing on this. I am not sure it will ever see wide adoption, but we'll surely never find out if we don't try. ## Don't stand out I think the requirement that the browser check the CT log and perform DNSSEC in 3.2 is likely to violate the don't-stand-out requirement, as I don't expect most browsers to do that most times. Am I missing something? ## CDN integration > If N multiple domains on a CDN are acceptable fronts, then we may > want some way to indicate this without publishing and maintaining N > separate tokens. Those multiple domains will not share TLS keys (or will be under a TLS wildcard), so delegation to a certificate is enough to cover this. I think you can just cut this paragraph, but maybe I don't know something about some sort of CDN? ## Security considerations: DDoS In section 6, I'm glad to see analysis vs the ddos requirements in 2.3. I'm not sure I agree with the quick result: 1) The forwarding server can be used as a reflector. Under some circumstances it should back off. 2) Under CPU load, the forwarding server will presumably start refusing early data (especially early data with TCP Fast Open!). Is it necessary to say anything more here? Or is the ordinary behavior of flaky early data sufficient? Particularly: what should clients do when early data is refused? Try again with this in the main data section? Give up? -Brian From nobody Fri Aug 4 10:39: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 C00BD132423 for ; Fri, 4 Aug 2017 10:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 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, 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 3aw_LcTI3glE for ; Fri, 4 Aug 2017 10:39:08 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD88132428 for ; Fri, 4 Aug 2017 10:39:08 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id g35so8332457ioi.3 for ; Fri, 04 Aug 2017 10:39:08 -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; bh=/b+BmVva+2J7SuXQUC1mA2+vNoyxxqFM/T76EpRRVkk=; b=jk++xqJM6ddwnbl9Hbdurp3ITvDe10du0c3btXrV7oZdAle4gJyRb1WO4o0qLFHd5r Vr137cu4gfxzmKWzUPGzTRF4D1IUGm5gfwFpWJ7uUm9a/+VZrscWDrvcoQMWUmVRJ3AQ o5/Gx7luEpx3GEYrfS0/D815so6QpsEhdsuOHivwljZlRItzodBUkdk2NExHv5tkXx8N pQSVvd0nFhsm9J/Iy4+hycEu+MOV/qnuYWTxlk5AF22C+2jAzvngonSOZlOYwDIgNBMi qrSO5fbnnGuVVLuAZGrKkPV8Pnf6tDODW4eMPQ/oFcLEL9OMp0BzQkbzfWm11Uwqlwzc V45w== 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; bh=/b+BmVva+2J7SuXQUC1mA2+vNoyxxqFM/T76EpRRVkk=; b=r7bZjJrGIxNgrSu4GCjJJYv/vTaSJPHUpK21svxsqRdU8fyTdTRECYjPC5IbE0GKWU 7HqqGODAmb0FNhRCZB93hJjJhqcQ6rdd1xrbi6o/yAovt4WIh6aYCju649MRYEij4KO6 bVCXyws8/ov7wQFLAG7GJ+Cers94yZqrwYLCTl6Q5qfpzRg9mZNztoukXKHGmw+DcqAH hH/QERoyleHwAwRPTcAah2fv3dSn44kUMNygGX2jZadWw1RSJlHjlMoHXmJZ+SKJEH1t XIJh19Bdx8ggKxlxE39eZGZLxZIkw8Y8jijSrVQDKUr1P43QmQv05bJ72w0kIItHRUHT DxCA== X-Gm-Message-State: AHYfb5jXGw+CDwjtf5kQrIPOLnlcA+TR+eykocrkJ8sW8ioDsC5O5J9v AEMG2VGAKIxMQJIcQWTMGZVNVPsUqxsddCk= X-Received: by 10.107.34.193 with SMTP id i184mr3544154ioi.223.1501868347844; Fri, 04 Aug 2017 10:39:07 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.38.216 with HTTP; Fri, 4 Aug 2017 10:39:07 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Fri, 4 Aug 2017 10:39:07 -0700 X-Google-Sender-Auth: Q1yuxJgq2JMcYH1wkn5CMkEUasE Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary="001a1140e7865f6c4f0555f0f9dd" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 17:39:11 -0000 --001a1140e7865f6c4f0555f0f9dd Content-Type: text/plain; charset="UTF-8" On Fri, Aug 4, 2017 at 5:50 AM, Sean Turner wrote: > At our IETF 99 session, there was support in the room to adopt > draft-huitema-tls-sni-encryption [0]. We need to confirm this support on > the list so please let the list know whether you support adoption of the > draft and are willing to review/comment on the draft before 20170818. If > you object to its adoption, please let us know why. > Section two of the draft discusses the design space, which is to be welcomed, but also MUST/MUST NOTs sections of that design space. While I generally agree with its opinions, it's confused about whether it's a technical document or a policy document. If it decides to be a policy document, then I'm unconvinced of its utility. If it wants to be a technical document, then the draft includes two very different designs with a note saying that one will be chosen at some point. So which are we talking about adopting? While drafts evolve during the WG process, there's a big gap between the two ideas and I'd support one but not the other. Thus I'm not sure that the draft is ready for an adoption call at this time. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --001a1140e7865f6c4f0555f0f9dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 4, 2017 at 5:50 AM, Sean Turner <sean@sn3rd.com> wrote:=
At our IETF 99 sessio= n, there was support in the room to adopt draft-huitema-tls-sni-encryp= tion [0].=C2=A0 We need to confirm this support on the list so please let t= he list know whether you support adoption of the draft and are willing to r= eview/comment on the draft before 20170818.=C2=A0 If you object to its adop= tion, please let us know why.

Sect= ion two of the draft discusses the design space, which is to be welcomed, b= ut also MUST/MUST NOTs sections of that design space. While I generally agr= ee with its opinions, it's confused about whether it's a technical = document or a policy document. If it decides to be a policy document, then = I'm unconvinced of its utility.

If it wa= nts to be a technical document, then the draft includes two very different = designs with a note saying that one will be chosen at some point. So which = are we talking about adopting? While drafts evolve during the WG process, t= here's a big gap between the two ideas and I'd support one but not = the other.

Thus I'm not sure that the draft is= ready for an adoption call at this time.


Cheers

AGL

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
--001a1140e7865f6c4f0555f0f9dd-- From nobody Fri Aug 4 10:43: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 96F81132256 for ; Fri, 4 Aug 2017 10:43: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, 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 D2gsv_z1ac2L for ; Fri, 4 Aug 2017 10:43:00 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e: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 98FE3132224 for ; Fri, 4 Aug 2017 10:43:00 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id v77so10576840pgb.3 for ; Fri, 04 Aug 2017 10:43:00 -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=bxiaqki6SSSliaAoOxs09zidrLGz+0UvXLtBWEmPz6k=; b=yB9Nq/QNjZSd40JHEAEQ2buGJPkbtzKBlPDfRsJcpyGgNKdthTjzrwcAyTB3NplUZV KddGb+7KvZ7FLgrTJuqSXCVvqPLCXciDCMmZmagcdhSEynVlsol7wz7giGy5v1WaDexT K8cI3xiIGM6zhXKu5pXCNnuRt25PvPHGCymc2H4eZNmnvYxAzYTykhynaNmVDeStkUiW mr/XS4ESblymWDm38ouuGUaOgIXG5Qo4NwqMjew7tICmDcORe9Ky+spO4kfQeSFLNtpb HLUgE5z9crL+i96QM0l2wxcK8TvPGNkxaD/Fx6kt/yA40skeXbPr7niwTC16Gar0NRzP 232Q== 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=bxiaqki6SSSliaAoOxs09zidrLGz+0UvXLtBWEmPz6k=; b=N6cS/f3x8Kp51y6K59DpzHFG2eeLEgXq97BceqgvtSo5Ej6j2Vs+jMHE01NTByCN4r QOrt6rfMMkjNQ/iP8st20Qq0cj7N5gEiyyZhcaih1x2FS8RX1/H5szhi5fa31pHumeZN y1OkCA4LA7j1+r4ggkK9lBqSd1U9len6i0n4xfCT+M3UOE4qdwnK4VE4TTtlj9XO1Tcw nIAJAZ2uNGX2flWns5WK9F5BmrCfJp9Bpsf3acmwlbXA7I2woFRhqDAgi+jn1hx4hdjd LfXNdsLWbtDvu5Yg99lbQxfXzle6DHZJ4ZlCZ7YCds6s31XvZ9LIvXBTLKp7Mg8biVG3 mCCw== X-Gm-Message-State: AIVw1112LL1kYQj68YjF7aCCLZsMTvNwWhc3vJWsteJgiv4dilN7DK1Z 6+cP5CA+u6pMI7SDM3O772Su/bD4m/fEr6k= X-Received: by 10.98.155.133 with SMTP id e5mr3289406pfk.186.1501868579823; Fri, 04 Aug 2017 10:42:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.72 with HTTP; Fri, 4 Aug 2017 10:42:39 -0700 (PDT) From: Joseph Salowey Date: Fri, 4 Aug 2017 10:42:39 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c143dbc332f760555f10789" Archived-At: Subject: [TLS] WG Call for Adoption of draft-rescorla-tls-subcerts continued X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 17:43:03 -0000 --94eb2c143dbc332f760555f10789 Content-Type: text/plain; charset="UTF-8" In the previous call for adoption there were some issues raised that needed more discussion. The summary sent to the list [1] and subsequent discussions indicate support for the approach outlined in this draft. Therefore we would like to continue the call for adoption. If you have concerns about adopting this draft as a working group item please respond to the list by August 18, 2017. Thanks, J&S [1] https://www.ietf.org/mail-archive/web/tls/current/msg24092.html --94eb2c143dbc332f760555f10789 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the previous call for = adoption there were some issues raised that needed more discussion. =C2=A0 = The summary sent to the list [1] and subsequent discussions indicate suppor= t for the approach outlined in this draft. Therefore we would like to conti= nue the call for adoption.=C2=A0 If you have concerns about adopting this d= raft as a working group item please respond to the list by August 18, 2017.= =C2=A0

Thanks,

J&S

<= /div> --94eb2c143dbc332f760555f10789-- From nobody Fri Aug 4 11:03: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 662F913240D for ; Fri, 4 Aug 2017 11:03:54 -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 KFVIR_F_536d for ; Fri, 4 Aug 2017 11:03:52 -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 A53F0132409 for ; Fri, 4 Aug 2017 11:03:52 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id u207so14372122ywc.3 for ; Fri, 04 Aug 2017 11:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D28q2vfBM0MELbb3iCQyB/uIng4mIftDX1oYy6pG17s=; b=GN5KPk8KKuhTwNTh067nbWEgRaGSlOY7m+/vRCurN4tXcP0ueBlApRWpwLAZW4XubX bO8a0dmYzZQuPZlNNo0rTTP/sfhcgoGtSKH+BeF1034e5hD5t8mg3w1KFLit/AWUbPFd a08QB8ohND3CF5BaHaS6cRhfLwCUMAxOfgIvzEUw5nQPUuH5Fmopy0VR7sNMuuqeY/U/ +XKdT8WjzOFzK5s4Xpz2cdJ5Qd8RUS5ee2Knjalyrm6qo1bjFgNOqcYUuNkEONHZWDre lSpQKETZTctuJQC2q9oOFax/yERLUjvsRiZeKl5bb4wk0kFc8vWRXn6nRepq4OG6s/CX wi2g== 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=D28q2vfBM0MELbb3iCQyB/uIng4mIftDX1oYy6pG17s=; b=ugdP5dhFS99cWfKgSGDxL03hMBq1hNfJ8pZhl4Y2TJFvmhPS2M4n1rNZcflXeV+RfS ootYBToKYnQzDM9nM8ja4n6sNZprcY+C7/i1mRwgRVOSxDP8Zm1cF5GYgxr45+ps6clp Z2l0IXO4pSLS7q+c4cqatAK60Y9UTnk4nSCdVXW4AbN1Cj+ViIqxXRpQEJOp9Q5CKfTy aWVhmqGEk/rzg0ERHPEtyLZPCohIIMshHF+cVCxNaF8vfEkqB+spIgrkbH+EStJzZLI5 AAGZddeJQjLIzw/BV0ruYwUiPBJvAwqxhGAu9ogZco3cHa5+a/4TLTPAMvugEJbz05+s nwgQ== X-Gm-Message-State: AHYfb5iCuKwb7s+8OPVgFWBRFlB6lGWB7TAPJTa+frUvF1H9ggc+rufl acloeoFx8LMOnPFpBzEforsXvcOUmQ== X-Received: by 10.37.217.14 with SMTP id q14mr2445194ybg.8.1501869831704; Fri, 04 Aug 2017 11:03:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.132 with HTTP; Fri, 4 Aug 2017 11:03:31 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Fri, 4 Aug 2017 11:03:31 -0700 Message-ID: To: Adam Langley Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary="94eb2c06c5c2d16fea0555f1518b" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 18:03:54 -0000 --94eb2c06c5c2d16fea0555f1518b Content-Type: text/plain; charset="UTF-8" On Fri, Aug 4, 2017 at 10:39 AM, Adam Langley wrote: > If it wants to be a technical document, then the draft includes two very > different designs with a note saying that one will be chosen at some point. > So which are we talking about adopting? While drafts evolve during the WG > process, there's a big gap between the two ideas and I'd support one but > not the other. > The tunneling mechanism described in Section 4.1 seems useful (at least to me) for more things than encrypted SNI, such as being able to use different TLS extensions for the frontend load balancer versus a backend service, while still eventually negotiating an end-to-end encrypted session with the backend service. I wonder if the draft should be framed around the TLS-in-TLS tunneling mechanism, with encrypted SNI as a potential use case. -- Tony Arcieri --94eb2c06c5c2d16fea0555f1518b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 4, 2017 at 10:39 AM, Adam Langley <agl@imperialviolet.org= > wrote:
If it wants to be a t= echnical document, then the draft includes two very different designs with = a note saying that one will be chosen at some point. So which are we talkin= g about adopting? While drafts evolve during the WG process, there's a = big gap between the two ideas and I'd support one but not the other.

The tunneling mechani= sm described in Section 4.1 seems useful (at least to me) for more things t= han encrypted SNI, such as being able to use different TLS extensions for t= he frontend load balancer versus a backend service, while still eventually = negotiating an end-to-end encrypted session with the backend service.
=

I wonder if the draft should be framed around the TLS-i= n-TLS tunneling mechanism, with encrypted SNI as a potential use case.=C2= =A0

--
Tony Arcieri
--94eb2c06c5c2d16fea0555f1518b-- From nobody Fri Aug 4 11:42: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 AF24C1321A3 for ; Fri, 4 Aug 2017 11:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 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, 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 3kVJuLwb2Hzt for ; Fri, 4 Aug 2017 11:42:50 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 6EA4D1321DA for ; Fri, 4 Aug 2017 11:42:50 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id v127so8782751itd.0 for ; Fri, 04 Aug 2017 11:42:50 -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; bh=WDOIdwk9YlxCWv3zbMm9XUu75bCmjOv2dTtloPm1eVg=; b=SedyyaKmrvvvN88Snb33HOE03cBZ3ls+cbDA761hoYDWKY5lx8xFslfFBNkcnnRGQg /nerd2vAPS6uoIus0aJS86qTLqMfLhPdT91aS9/ECe8gC7tfxuAqFjKh5q+GB/qh1TwK iS9TTowqRX364+aCvSobgDlS/Tu7QIijHB98TVyDzA5BsXmIbdK+TU+fIGdYHrk8hl21 W+RCzsdD8MyDAGr6pHVfumupnwvwEQx2eDArJBp7v/WWFyOxprRlvNjJLgrxj/7sSfGM p0rnyAV5nSR4ZvJIkru0axocimSm9htITIbtZKfE+fDUPTZSDurHvvmvaIR2pIRDleOA ldWQ== 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; bh=WDOIdwk9YlxCWv3zbMm9XUu75bCmjOv2dTtloPm1eVg=; b=VKmsiip4bSmUSZaVH4E+X0vOOUJ33Es1Dgyqc2bp9OVhSivCkWhUdrE2UTMfb2/xG9 B1qO5+YMJ/d6W0hiM1s4Rv+PyPar7UMlrYHwAuaFTmJ7zgmkCLrGr0fly6k8ijYhRjtu WabjPyZyfjXFwoDy7xn/QRgMEidRKQXK9/xB5z5GeFL2+KQVT3NTtm///uQ4Ric9IsZu pd4rdZJmRFXqru5fWnwBbqpf1OJuEJy5O7xC50y5wiq+9SzywUQCDUuX+iV6eP4J2N+I TGexG0SRM3XoV4ikboGUVUipySwKjQc8nnFXLnmSKeBp9gZ3Pp5rnJKwY48qZaKWntZw nZzA== X-Gm-Message-State: AHYfb5jAB8Q9TTYanlcuSUs0u6X+ZiVS9eIpPTUHtgU7y0yTUR3KinPd Obp64lPDoXY3B+Bh15EOZtYHRrzLG0y6uNo= X-Received: by 10.36.173.91 with SMTP id a27mr3245554itj.130.1501872169784; Fri, 04 Aug 2017 11:42:49 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.38.216 with HTTP; Fri, 4 Aug 2017 11:42:48 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Fri, 4 Aug 2017 11:42:48 -0700 X-Google-Sender-Auth: 3QhHEsLCiOzA3NZiJjMupfR8VGg Message-ID: To: Tony Arcieri Cc: "" Content-Type: multipart/alternative; boundary="94eb2c1fd0b42d9bee0555f1dd2c" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 18:42:53 -0000 --94eb2c1fd0b42d9bee0555f1dd2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 4, 2017 at 11:03 AM, Tony Arcieri wrote: > On Fri, Aug 4, 2017 at 10:39 AM, Adam Langley > wrote: > >> If it wants to be a technical document, then the draft includes two very >> different designs with a note saying that one will be chosen at some poi= nt. >> So which are we talking about adopting? While drafts evolve during the W= G >> process, there's a big gap between the two ideas and I'd support one but >> not the other. >> > > The tunneling mechanism described in Section 4.1 seems useful (at least t= o > me) for more things than encrypted SNI, such as being able to use differe= nt > TLS extensions for the frontend load balancer versus a backend service, > while still eventually negotiating an end-to-end encrypted session with t= he > backend service. > > I wonder if the draft should be framed around the TLS-in-TLS tunneling > mechanism, with encrypted SNI as a potential use case. > But my point is that, in this situation, I would expect there to be two competing drafts=E2=80=94one for each proposal. The WG would then only adop= t one of them. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --94eb2c1fd0b42d9bee0555f1dd2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 4, 2017 at 11:03 AM, Tony Arcieri <bascule@gmail.com> wrote:
On Fri, Aug 4, 2017 at 10:39 AM, Adam Langley <<= a href=3D"mailto:agl@imperialviolet.org" target=3D"_blank">agl@imperialviol= et.org> wrote:
If it wants to be a technical document, then the draft includes two= very different designs with a note saying that one will be chosen at some = point. So which are we talking about adopting? While drafts evolve during t= he WG process, there's a big gap between the two ideas and I'd supp= ort one but not the other.

The tunneling mechanism described in Section 4.1 seems usefu= l (at least to me) for more things than encrypted SNI, such as being able t= o use different TLS extensions for the frontend load balancer versus a back= end service, while still eventually negotiating an end-to-end encrypted ses= sion with the backend service.

I wonder if the dra= ft should be framed around the TLS-in-TLS tunneling mechanism, with encrypt= ed SNI as a potential use case.=C2=A0
<= div>
But my point is that, in this situation, I would expect = there to be two competing drafts=E2=80=94one for each proposal. The WG woul= d then only adopt one of them.


Chee= rs

AGL

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
--94eb2c1fd0b42d9bee0555f1dd2c-- From nobody Fri Aug 4 13:07: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 31E3F128C9C for ; Fri, 4 Aug 2017 13:07:14 -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, 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 zVZwtC3RvvyO for ; Fri, 4 Aug 2017 13:07:12 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6DF126BFD for ; Fri, 4 Aug 2017 13:07:12 -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 v74K2hhP012491; Fri, 4 Aug 2017 21:07:10 +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=R0jtNJYD2WgnZxzz8G7MJoLaOdi4Aqj61Vy/O9/YMQA=; b=b8wq9rykFvnvuZpyyb6vHqIRFm3EkqptX0U20jQ7fek368QoxQDuCixtlVQRwg4xCt/L r4M33+KAVe+ISuBL9oaex7rbC57OckUYFF0Lsbz0jQ8tcC9FRLOr77FHiaQk9EuCqImz IFJQRAfbxB8PqbbfChRfIqsezLgcXstkO8tXxzW9f1QGNQ0KEiKlQ+tDF31Zo4ROK+DQ kPkkMgng/Jg9GhhTLAfJwu8eA89ipnYvc/FpWzUx5HUZvhFsw6DdkGNh9Do1lCv/kVEF 0GjSy2vubcXBNBKacfyq7NZCGBNT0DafyKwX63Nj7DvZ/CVJWaSIDtSBu3WNFEVmB63a 7Q== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2c40tk3mjh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Aug 2017 21:07:10 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v74K5nMl025357; Fri, 4 Aug 2017 16:07:09 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2c0npw1kx3-1; Fri, 04 Aug 2017 16:07:09 -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 D20C28005D; Fri, 4 Aug 2017 14:07:08 -0600 (MDT) To: Sean Turner , "" References: From: Benjamin Kaduk Message-ID: <69a96715-3a58-f5c9-e801-57c84c12c29c@akamai.com> Date: Fri, 4 Aug 2017 15:07:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C65D5AFFC0A496AA821A07F5" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-04_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-1706020000 definitions=main-1708040311 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-04_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-1706020000 definitions=main-1708040310 Archived-At: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2017 20:07:14 -0000 This is a multi-part message in MIME format. --------------C65D5AFFC0A496AA821A07F5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit It is currently before 20170818, and I support adoption of this draft and am willing to review it as it progresses. I do agree with Ilari that limiting the ciphertext size seems to make more sense, but of course we can discuss that post adoption. -Ben On 08/04/2017 07:50 AM, Sean Turner wrote: > At our IETF 99 session, there was support in the room to adopt draft-thomson-tls-record-limit [0]. We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170818. If you object to its adoption, please let us know why. > > Cheers, > > J&S > > [0] https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------C65D5AFFC0A496AA821A07F5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit It is currently before 20170818, and I support adoption of this draft and am willing to review it as it progresses.

I do agree with Ilari that limiting the ciphertext size seems to make more sense, but of course we can discuss that post adoption.

-Ben

On 08/04/2017 07:50 AM, Sean Turner wrote:
At our IETF 99 session, there was support in the room to adopt draft-thomson-tls-record-limit [0].  We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170818.  If you object to its adoption, please let us know why.

Cheers,

J&S

[0] https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--------------C65D5AFFC0A496AA821A07F5-- From nobody Fri Aug 4 20:37: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 D3CA312EA95 for ; Fri, 4 Aug 2017 20:37:41 -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 ts-KoVakNUip for ; Fri, 4 Aug 2017 20:37:39 -0700 (PDT) Received: from mx19.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458D1128D86 for ; Fri, 4 Aug 2017 20:37:37 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx19.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ddpuB-0003ZX-PU for tls@ietf.org; Sat, 05 Aug 2017 05:37:37 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ddpu6-0000Qj-6N for tls@ietf.org; Fri, 04 Aug 2017 23:37:34 -0400 Received: (qmail 21053 invoked from network); 5 Aug 2017 03:37:26 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.186]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Aug 2017 03:37:26 -0000 To: tls@ietf.org References: From: Christian Huitema Message-ID: <3bfb829b-c7b0-ee7e-eee7-d7b525b8d209@huitema.net> Date: Fri, 4 Aug 2017 20:37:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FC87A4929EF9C4D0D01147CD" X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.08) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23gbbD8eC/xd3qmUvgCBP6q2vDGBF9tbZRxk/9 3gtVCjR6uoREg9CYgfDsyOlDBDlYYOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRP6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGybXhIPdntdTjMQ+95/+BMmPeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj237lbbxdoi07KbLoeZB/AeCPNdSMuNhZC3X/nGdDKYyg+xII1yJ8udUSd8siDlV+9cBL pGLKbiMLMKI7KIsgfDrl6J1fhOzjF0b4LXcjJZ5lokd/SMjLkKcTxKFyOtoymTcmM9wtvvopM8mT NCUAE7Sw6EKi9t9GgDGZ/MT3bNt67c0yU2LI0GQUDn3k/srNlrrRG8CNIo3Sx0BJZHAPrCs7tyb7 Rrgi3wKcZ6DOEZP9h2AocVYAMa9P02RGLBmw4yrPswsv/ZJCuOdVX3JdPZ1jMLn6MURQGfriekzS 9Ga3AA== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Aug 2017 03:37:42 -0000 This is a multi-part message in MIME format. --------------FC87A4929EF9C4D0D01147CD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/4/2017 10:39 AM, Adam Langley wrote: > On Fri, Aug 4, 2017 at 5:50 AM, Sean Turner > wrote: > > At our IETF 99 session, there was support in the room to adopt > draft-huitema-tls-sni-encryption [0]. We need to confirm this > support on the list so please let the list know whether you > support adoption of the draft and are willing to review/comment on > the draft before 20170818. If you object to its adoption, please > let us know why. > > > Section two of the draft discusses the design space, which is to be > welcomed, but also MUST/MUST NOTs sections of that design space. While > I generally agree with its opinions, it's confused about whether it's > a technical document or a policy document. If it decides to be a > policy document, then I'm unconvinced of its utility. Clearly, Section 2 could be turned into some kind of 'problem statement" draft. I personally don't like splitting problem statement and proposed solution in separate documents, but if that's the group consensus, why no= t. > > If it wants to be a technical document, then the draft includes two > very different designs with a note saying that one will be chosen at > some point. So which are we talking about adopting? While drafts > evolve during the WG process, there's a big gap between the two ideas > and I'd support one but not the other. > My goal was to list the current state of solutions. The document could be split with different drafts presenting different solutions, but I believe there is value in an attempt at unification. --=20 Christian Huitema --------------FC87A4929EF9C4D0D01147CD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 8/4/2017 10:39 AM, Adam Langley wrote:
On Fri, Aug 4, 2017 at 5:50 AM, Sean Turner <sean@sn3rd.com> wrote:
At our IETF 99 session, there was support in the room to adopt draft-huitema-tls-sni-encryption [0].  We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170818.  If you object to its adoption, please let us know why.

Section two of the draft discusses the design space, which is to be welcomed, but also MUST/MUST NOTs sections of that design space. While I generally agree with its opinions, it's confused about whether it's a technical document or a policy document. If it decides to be a policy document, then I'm unconvinced of its utility.
Clearly, Section 2 could be turned into some kind of 'problem statement" draft. I personally don't like splitting problem statement and proposed solution in separate documents, but if that's the group consensus, why not.


If it wants to be a technical document, then the draft includes two very different designs with a note saying that one will be chosen at some point. So which are we talking about adopting? While drafts evolve during the WG process, there's a big gap between the two ideas and I'd support one but not the other.

My goal was to list the current state of solutions. The document could be split with different drafts presenting different solutions, but I believe there is value in an attempt at unification.
-- 
Christian Huitema
--------------FC87A4929EF9C4D0D01147CD-- From nobody Fri Aug 4 21:30: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 44F6012EBF9 for ; Fri, 4 Aug 2017 21:30:54 -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=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo8j5yh4AhYB for ; Fri, 4 Aug 2017 21:30:52 -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 09CF312DDD0 for ; Fri, 4 Aug 2017 21:30:51 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 80so14514508uas.0 for ; Fri, 04 Aug 2017 21:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0nX0LMU/JO0fFLrGh+oiKrwev/41GPrIPZmFgLrKU+w=; b=l9Vet/AtxQ97a9e4PQfQ3pxlavOt4p3bkHI977UXkKpd2QRsKQ0G3avAYY9NjMOd3B YZtYhO6VjLvAjDUFuJRH59rvNsXiCRuuZd2Wpfz2+nw7n+O0LnWMiYXsWxmhoYSxlRKV DuiLMgNC4UbrQ2JSlW2gPBvVMKyhV1lUgZAn4= 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=0nX0LMU/JO0fFLrGh+oiKrwev/41GPrIPZmFgLrKU+w=; b=A6JI3lfCxrnvdGq32F8nFOQudnXGScPL0jQoJeUXJz3+kmNvedk76QL53jF8UvibiZ oBcQeaQa4j2V7/UvW5yHRa8U4s21Naqu9OOtim8hr6yHwapOq08lOtnQJPE/vXeW1H13 2LH4pP17WhtusJ0LAeLDoRGk3VUOK3pakr/a7n87iwryRRxUM8oAtVMNziv81S2xi1dP nsdlOlzml57NUC2Rad0+6u09w+uxaKjFNvHKszxYGLxksEXl1CrOeO0pg00Q8AEit5sG XhpboVyGjQlR0EKcnZ5IF/N3vknwC6PqlhRvI2f3Jv6nQvv8swfLi9OvhNDRaNRHtboB 7SBw== X-Gm-Message-State: AIVw111D/ajhXtBHarWThjHWTWvWM23a9KrjnBxLJZKPcfYRnxFHHMCK Ym810v8TxQfiZmWfZS5RXwlFPMC/kJIDo9U= X-Received: by 10.159.59.19 with SMTP id i19mr3433507uah.147.1501907450930; Fri, 04 Aug 2017 21:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.195 with HTTP; Fri, 4 Aug 2017 21:30:50 -0700 (PDT) Received: by 10.176.65.195 with HTTP; Fri, 4 Aug 2017 21:30:50 -0700 (PDT) In-Reply-To: <87pocbwjry.fsf@fifthhorseman.net> References: <87pocbwjry.fsf@fifthhorseman.net> From: Tom Ritter Date: Fri, 4 Aug 2017 23:30:50 -0500 Message-ID: To: dkg Cc: tls@ietf.org, Sean Turner Content-Type: multipart/alternative; boundary="f403043c3a241943370555fa145d" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Aug 2017 04:30:54 -0000 --f403043c3a241943370555fa145d Content-Type: text/plain; charset="UTF-8" On Aug 4, 2017 9:22 AM, "Daniel Kahn Gillmor" wrote: On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote: > At our IETF 99 session, there was support in the room to adopt > draft-huitema-tls-sni-encryption [0]. We need to confirm this support > on the list so please let the list know whether you support adoption > of the draft and are willing to review/comment on the draft before > 20170818. If you object to its adoption, please let us know why. I support wg adoption of this draft and am willing to review before 20170818. +1 although I agree with AGL about must/must nots setting policy (and that the section should be reworked in the frame of "we have chosen a design to avoid these undesirable characteristics) and that it's odd to adopt the draft without choosing which of the designs we're adopting. However I at this time I'm not opposed to either design. -tom --f403043c3a241943370555fa145d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Aug 4, 2017 9:22 AM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote:
O= n Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote:
> At our IETF 99 session, there was support in the room to adopt
> draft-huitema-tls-sni-encryption [0].=C2=A0 We need to confirm th= is support
> on the list so please let the list know whether you support adoption > of the draft and are willing to review/comment on the draft before
> 20170818.=C2=A0 If you object to its adoption, please let us know why.=

I support wg adoption of this draft and am willing to review before 20170818.

+1 although I agree with AGL about must/must nots setting policy= (and that the section should be reworked in the frame of "we have cho= sen a design to avoid these undesirable characteristics) and that it's = odd to adopt the draft without choosing which of the designs we're adop= ting.

However I at this = time I'm not opposed to either design.

-tom
<= br>
--f403043c3a241943370555fa145d-- From nobody Sat Aug 5 03:52: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 40C35128AA1 for ; Sat, 5 Aug 2017 03:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnX3308zKlB9 for ; Sat, 5 Aug 2017 03:52:50 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001: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 965CF128C81 for ; Sat, 5 Aug 2017 03:52:50 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id g35so13220702ioi.3 for ; Sat, 05 Aug 2017 03:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cccFZ0gRfMZT00JA9jLsOsiiJD7U/HAwDt/ExLI2aOk=; b=oE+ljEaxNRxV8Gb2i4x5griVv+EVTSCeqy8K897ZD9hpUoXZkVWyVHW2TthA6nhaNa k3zJOGNxhyZ3A74A0JFJrv9cCuTBTNCUPwThwzWVAcV4DQCTqg5Vinbe6kmLxWCI0LPC wSuAe5Cu2h5yr0BbT3SKyrgock26Pwb0N6eWMgHudzc59E0KCmdHt7boASYPC9pVbImQ cTVkgQkN5dV5y8n45hBYUmIiThANQ5Mlm39c512dIAVW1pUKUrvBi3OPJvW3m+9RscoT Y+Z2oTMBnIWD8NNnEzIM6371OXvKAwhlUz5dfPY/yzFLYNuOnEB0cApn52IZlHXbEtyn PSWA== 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=cccFZ0gRfMZT00JA9jLsOsiiJD7U/HAwDt/ExLI2aOk=; b=HwQBH9JSGFbtGrYl5/4MEM4IhnvmLLKRAN6F/L+uMl72vuwk2N1JcDy6proAeUouUL t4AyZeFkyMGks/8KUUhVVxkJIG6kBwah4kSUNCyUYJVsQ/3WjcNqexwOfRvLeYt9kbsh /wreHwSPtuGhZfmJqg+Vr/voAC1izpY9cUwspvPU1NoCt2rhRRcE9dcJpCt0c1+tAAKU DBDKohEeQSAPQgZhl6d1AsL++yjfYvQI4BGWAeh+fJQmo6RyY4Ys4t46IBiA3dTys7Ex u6HdQTv3FqGho4e3PSnSuW1Od/FllzqGdrQfqi8poP4rZyNzkG3F9H/yENY2id46olb2 l54w== X-Gm-Message-State: AIVw112KC17ZyFXh2Lx8rwlFMwjhxWYkyGcpF6c/zS3GyOWLydciEeJo p3zf2dBn0/IKSWftFUwYwIk4WyPoUw== X-Received: by 10.107.134.196 with SMTP id q65mr5324087ioi.193.1501930369903; Sat, 05 Aug 2017 03:52:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Sat, 5 Aug 2017 03:52:49 -0700 (PDT) In-Reply-To: References: <149810504637.30481.937244297632371838.idtracker@ietfa.amsl.com> <422ef2c7-4d99-20d2-8a39-ffd61277e0bd@huitema.net> From: Martin Thomson Date: Sat, 5 Aug 2017 20:52:49 +1000 Message-ID: To: Brian Sniffen Cc: Christian Huitema , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-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: Sat, 05 Aug 2017 10:52:52 -0000 On 5 August 2017 at 01:30, Brian Sniffen wrote: > ## Don't stand out > > I think the requirement that the browser check the CT log and perform > DNSSEC in 3.2 is likely to violate the don't-stand-out requirement, as I > don't expect most browsers to do that most times. Am I missing > something? Checking the CT log or doing DNSSEC validation would definitely cause a red flag, but if the DNSSEC chain extension to TLS is used (consistently), then the information is already on hand. I don't know what can be done for CT (SCT likely isn't what we're looking for here). The conclusion to the ORIGIN frame discussion ended with two choices that increase confidence that a certificate isn't mis-issued without violating this principle. That was OCSP stapling or SCT. It's an important principle, maybe this draft should be clearer about that. From nobody Sat Aug 5 03:58: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 75F6B131CE7 for ; Sat, 5 Aug 2017 03:57:58 -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, 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 W9Fc7s2Rm19x for ; Sat, 5 Aug 2017 03:57:56 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 6998B12EC13 for ; Sat, 5 Aug 2017 03:57:51 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id m88so13249607iod.2 for ; Sat, 05 Aug 2017 03:57:51 -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=iyIdyEAvXtKD7438mJVZTZ177Ihg0q3q7p7LYrXfy7k=; b=ckAKTfY6Ajs1NvsXYMTEvA+Ql/iXjrIs1C9prGw1R9sm1MildJ/vdqas58VbdDRK44 FadgJ/lTl5Dm9FwO7LG4Dr2tp17ykQl1wyouU02bEwxv04tY5Pt2gyBc81BqV9FmT77i mRZx/MjYfb+CM55FwlOiZO4Hb27eMijnPM8uw5yKFvEKg/MeiOPc4ZUUKiZx37FsTYDZ nXmePtvTUA5hirqtizR+B1giyYHkulvcna6pEr2jkr2XXZahxjWneq3Y9Dj4wLke4YLS 4tTl9CUG84v9QLxH0knhaMYVlrZQ9O2Sj4xSZl2Nizgd027C9vIwGLG7fq3YmiQue1xq dZ9A== 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=iyIdyEAvXtKD7438mJVZTZ177Ihg0q3q7p7LYrXfy7k=; b=IxiQt6ARH6crTX9jc6QQ+mmDS9d2nMKDWyCoOzcf6XgRfXqRwN6f9T15hzbDGKMMdf h5B/BJ7KRUAcz6nyDuxLaIbQRBYU6YOI4ojQDB9c33vAGKC8hM5qO2uRfl5b35NShdNu VFn2b4mJ2lO45rGbd2luZQtEFF0vTMgdCb+ukZh8IeOixNzPcKprcSb0IQ0c/t5fiFhB vw8av3+9d3ErakIqXj6yWLJ0Po2mT0iRAaMygZSbw81T/oQS9xoRgTmXlYjIrifq0oB4 PPKKpIZ/1eV8TLC+kif8PTaCcft2lz1hULg/ydJZ0QMmgti2ozmzs475ZxUoZCLLqBCk 5X6w== X-Gm-Message-State: AHYfb5jnZRjOr92wjYQ/XDos+R3YBhymw9Oyi7o+z+lWwZUnry959OMa GrkVUypP8pcM+cfBCI6R/CijJEfuMNMC X-Received: by 10.107.16.196 with SMTP id 65mr6032724ioq.297.1501930670847; Sat, 05 Aug 2017 03:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Sat, 5 Aug 2017 03:57:50 -0700 (PDT) In-Reply-To: <69a96715-3a58-f5c9-e801-57c84c12c29c@akamai.com> References: <69a96715-3a58-f5c9-e801-57c84c12c29c@akamai.com> From: Martin Thomson Date: Sat, 5 Aug 2017 20:57:50 +1000 Message-ID: To: Benjamin Kaduk Cc: Sean Turner , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Aug 2017 10:57:58 -0000 On 5 August 2017 at 06:07, Benjamin Kaduk wrote: > It is currently before 20170818, and I support adoption of this draft and am > willing to review it as it progresses. > > I do agree with Ilari that limiting the ciphertext size seems to make more > sense, but of course we can discuss that post adoption. FWIW, I hope to merge PR #1 that addresses this point. It isn't perfect, but it keeps the happy path - those who don't pad more than the minimum - happy. We should discuss pros and cons, of course, and I'd prefer to do that as an official WG product. From nobody Sat Aug 5 09:44: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 C7D70131CEB for ; Sat, 5 Aug 2017 09:44:22 -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 IHEmEUqADaaG for ; Sat, 5 Aug 2017 09:44:20 -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 5C74012711E for ; Sat, 5 Aug 2017 09:44:20 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id m34so11342570iti.1 for ; Sat, 05 Aug 2017 09:44:20 -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; bh=p2KbqWHUH9tEIMhP/nTK/DjmYaSk3ObCKdZVHS8E6eA=; b=oxT137++kFdfAWYfg/OiLsbDfwvJ5DqhYMTXl/Ln7u8SoVfw0E/t6BXRktbpKXUsQ0 Lz6SNXLoTbc0WaK4C8MUFvptL+DrnJHX854BDGSTO3X9iyK9xtbwq9a8qsHL27gMGApq 1OQFBCJkeS2tFMOwChNqRGN8r/SB8ja0WBRebTWKs8xjNC4LBQ24n4q52ELugG8qbR5I G4Xo/zUbBvhVdym8QYDSUF/XwtKKfVBgAfhoOObFEkjmt6vdqfa3w2gD6J9G6SIYR+Zh 1IWjwiE9vCT0Q6vbaq+xyqw8uHlXUZbtQFzQjHu9I8kHZsGCopTxM0VDg0cIGBZePdjt eHYQ== 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; bh=p2KbqWHUH9tEIMhP/nTK/DjmYaSk3ObCKdZVHS8E6eA=; b=YjlfzN/IpoCtG3yAY+7ssU9e8J9RHQezz6jhuYhzwOKerQPTx1SVay/P2rUEsA73p0 oA89egCgYsVqH35yE76FaTVtQy/CrAsxGq9bwN13mCVaB/ZkPDUH2NqSpY9NzpgUaL5Z RjVm7qdPviky4lXhFLC/+cSSavD9NtSiW1Hr4C5HL4qkP28y1Au56Xavo2zDSGJUXtKH O9TCMphlErrPQzeWFX1UPCBn/vJ3Jhf1va5rDW0Eu/WKKmkc3TXtr8lOV7acUDzd4cWB PsnxtnOdI0/wtI4A0dADlBxTuw0plWZ8wDWdZxxf4NP19S20LI92I7hNAwMyUeCQ0HeS boug== X-Gm-Message-State: AIVw110F++yUCd4FrrSwufrJGPbUkuwxiHBKcgLjGHWxDfqxJnlff0rf DM0wYHi1RXiV+fQx+NBVaJOiNLFBi0vcAfc= X-Received: by 10.36.218.133 with SMTP id z127mr5903301itg.74.1501951459616; Sat, 05 Aug 2017 09:44:19 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.38.216 with HTTP; Sat, 5 Aug 2017 09:44:18 -0700 (PDT) In-Reply-To: <3bfb829b-c7b0-ee7e-eee7-d7b525b8d209@huitema.net> References: <3bfb829b-c7b0-ee7e-eee7-d7b525b8d209@huitema.net> From: Adam Langley Date: Sat, 5 Aug 2017 09:44:18 -0700 X-Google-Sender-Auth: 2cAVIBXV7HaTemqbFcNyN9IjHuI Message-ID: To: Christian Huitema Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0b09c0386d940556045376" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Aug 2017 16:44:23 -0000 --94eb2c0b09c0386d940556045376 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 4, 2017 at 8:37 PM, Christian Huitema wrote: > Clearly, Section 2 could be turned into some kind of 'problem statement" > draft. I personally don't like splitting problem statement and proposed > solution in separate documents, but if that's the group consensus, why not. > I don't think it need be split into a separate document. Indeed, I think explaining the design space and the reasons for that a specific design was selected should be welcomed in an RFC. What makes this document distinct are the sentences like "SNI encryption designs MUST mitigate this attack." This appears to be constraining /other/ documents by saying that such designs are not merely unattractive (in the views of the author), but forbidden to be considered. The IETF does do such policy documents from time-to-time, but not mixed with a technical document like this in my experience. > If it wants to be a technical document, then the draft includes two very > different designs with a note saying that one will be chosen at some point. > So which are we talking about adopting? While drafts evolve during the WG > process, there's a big gap between the two ideas and I'd support one but > not the other. > > My goal was to list the current state of solutions. The document could be > split with different drafts presenting different solutions, but I believe > there is value in an attempt at unification. > Eventually we have to pick one, right? I feel that drafts are generally more opinionated before a call for adoption, although the chairs might well feel that the design-space span is this document is focused enough already. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --94eb2c0b09c0386d940556045376 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 4, 2017 at 8:37 PM, Christian Huitema <huitema@huitema.net&g= t; wrote:
=20 =20 =20

Clearly, Section 2 could be turned into some kind of 'problem statement" draft. I personally don't like splitting problem statement and proposed solution in separate documents, but if that'= s the group consensus, why not.=C2=A0

I= don't think it need be split into a separate document. Indeed, I think= explaining the design space and the reasons for that a specific design was= selected should be welcomed in an RFC.

What makes= this document distinct are the sentences like "SNI encryption designs MUST mitigate = this attack." This appears to be constraining /other/ documents by say= ing that such designs are not merely=C2=A0unattractive (in the views of the= author), but forbidden to be considered.

=
The IETF d= oes do such policy documents from time-to-time, but not mixed with a techni= cal document like this in my experience.
=20
If it wants to be a technical document, then the draft includes two very different designs with a note saying that one will be chosen at some point. So which are we talking about adopting? While drafts evolve during the WG process, there's a big gap between the two ideas and I'd support one but not the other.
 My goal was to list the current state of solutions. The document could be split with different drafts presenting different solutions, but I believe there is value in an attempt at unification.

Eventually we have to pick one, right? I feel tha= t drafts are generally more opinionated before a call for adoption, althoug= h the chairs might well feel that the design-space span is this document is= focused enough already.


Cheers

AGL=C2=A0

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
--94eb2c0b09c0386d940556045376-- From nobody Sat Aug 5 10:41: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 A3198127058 for ; Sat, 5 Aug 2017 10:41:06 -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 pCtctfwPckVi for ; Sat, 5 Aug 2017 10:41:03 -0700 (PDT) Received: from mx5.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 16601131D6D for ; Sat, 5 Aug 2017 10:41:01 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1de34L-0003l2-Ur for tls@ietf.org; Sat, 05 Aug 2017 19:40:58 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1de34G-0006bl-MO for tls@ietf.org; Sat, 05 Aug 2017 13:40:56 -0400 Received: (qmail 32069 invoked from network); 5 Aug 2017 17:40:52 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.186]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Aug 2017 17:40:51 -0000 To: Adam Langley References: <3bfb829b-c7b0-ee7e-eee7-d7b525b8d209@huitema.net> Cc: "tls@ietf.org" From: Christian Huitema Message-ID: Date: Sat, 5 Aug 2017 10:40:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6FCCF570371871504A3179F8" X-Originating-IP: 168.144.250.234 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.14) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJY8hyefn/FOeAH6Zsqubs62ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23LMLOdqMY/d8RSHDKuLGl2jDTrViDQv2P8bTs WZuN92FvYtrO2M3//Zf5wul2JQ6bYOEkjsX7F8KmpUaZQHV+SWsC1ltxhvDAAiytf1zpGXO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKOHi0RYvlOYvJoUtCbvS/b6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyfQKSqJvkr19iYipIOA+FEfeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj235bvepmUNZsalPsiyi0NyxkWezJa7xDQcOg5ET5/LmCvakjSWDcjZyDseb0cBFM1p7J 0ZI2Cud2W8ULqpclZpX6sJqelmxqtloshGkSoDyZkYWbGwW5p2QNYx3a2iv3sPWs2JeFHWWIEKPk bLTy6zsKKEN9GFyvA5FuruPstREneXBZ7pmcPPET1gsbqYqsHO2B1AyhUYt13ZFWiMbSDOe6Tsut 9Ntwqm/jmjsUXZwk2AT7Y9cRih4Det7+7EbH8nOCZxyu+vYijoy9/Cd+DtyRRIbZK0lCbLYw/2Y2 Z+15FA== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Aug 2017 17:41:07 -0000 This is a multi-part message in MIME format. --------------6FCCF570371871504A3179F8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/5/2017 9:44 AM, Adam Langley wrote: > On Fri, Aug 4, 2017 at 8:37 PM, Christian Huitema > wrote: > > Clearly, Section 2 could be turned into some kind of 'problem > statement" draft. I personally don't like splitting problem > statement and proposed solution in separate documents, but if > that's the group consensus, why not.=20 > > I don't think it need be split into a separate document. Indeed, I > think explaining the design space and the reasons for that a specific > design was selected should be welcomed in an RFC. > > What makes this document distinct are the sentences like "SNI > encryption designs MUST mitigate this attack." This appears to be > constraining /other/ documents by saying that such designs are not > merely unattractive (in the views of the author), but forbidden to be > considered. I see your point. How about we remove the MUST/SHOULD language from section 2, and put it instead in the actual specification sections, something like "choosing a design that mitigates the attacks described in section 2?" > > The IETF does do such policy documents from time-to-time, but not > mixed with a technical document like this in my experience. > >> If it wants to be a technical document, then the draft includes >> two very different designs with a note saying that one will be >> chosen at some point. So which are we talking about adopting? >> While drafts evolve during the WG process, there's a big gap >> between the two ideas and I'd support one but not the other. > My goal was to list the current state of solutions. The document > could be split with different drafts presenting different > solutions, but I believe there is value in an attempt at unificatio= n. > > > Eventually we have to pick one, right? I feel that drafts are > generally more opinionated before a call for adoption, although the > chairs might well feel that the design-space span is this document is > focused enough already. I expect that we will see that eventually, focusing on one solution, or on an architecture that mixes several mechanisms. When I wrote the draft, I was collecting ideas from various places and I did not feel like making choices without WG input. But there are three main ideas: some kind of "delegation token" that expresses the agreement by a hidden site to be access through a front-end; the possibility of sending a second Client Hello as 0-RTT data; and, the idea of expressing a fronting SNI as part of a resumption ticket. I am not sure that we know at this stage whether these are three different solutions or three components of a single solution. -- Christian Huitema --=20 Christian Huitema --------------6FCCF570371871504A3179F8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 8/5/2017 9:44 AM, Adam Langley wrote:
On Fri, Aug 4, 2017 at 8:37 PM, Christian Huitema <huitema@huitema.net> wrote:

Clearly, Section 2 could be turned into some kind of 'problem statement" draft. I personally don't like splitting problem statement and proposed solution in separate documents, but if that's the group consensus, why not. 

I don't think it need be split into a separate document. Indeed, I think explaining the design space and the reasons for that a specific design was selected should be welcomed in an RFC.

What makes this document distinct are the sentences like "SNI encryption designs MUST mitigate this attack." This appears to be constraining /other/ documents by saying that such designs are not merely unattractive (in the views of the author), but forbidden to be considered.

I see your point. How about we remove the MUST/SHOULD language from section 2, and put it instead in the actual specification sections, something like "choosing a design that mitigates the attacks described in section 2?"


The IETF does do such policy documents from time-to-time, but not mixed with a technical document like this in my experience.
If it wants to be a technical document, then the draft includes two very different designs with a note saying that one will be chosen at some point. So which are we talking about adopting? While drafts evolve during the WG process, there's a big gap between the two ideas and I'd support one but not the other.
 My goal was to list the current state of solutions. The document could be split with different drafts presenting different solutions, but I believe there is value in an attempt at unification.

Eventually we have to pick one, right? I feel that drafts are generally more opinionated before a call for adoption, although the chairs might well feel that the design-space span is this document is focused enough already.

I expect that we will see that eventually, focusing on one solution, or on an architecture that mixes several mechanisms. When I wrote the draft, I was collecting ideas from various places and I did not feel like making choices without WG input. But there are three main ideas: some kind of "delegation token" that expresses the agreement by a hidden site to be access through a front-end; the possibility of sending a second Client Hello as 0-RTT data; and, the idea of expressing a fronting SNI as part of a resumption ticket. I am not sure that we know at this stage whether these are three different solutions or three components of a single solution.

-- Christian Huitema

-- 
Christian Huitema
--------------6FCCF570371871504A3179F8-- From nobody Sun Aug 6 13:40: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 BAF1613207A for ; Sun, 6 Aug 2017 13:40: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 a6fp1hKJcNt3 for ; Sun, 6 Aug 2017 13:40: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 51ECF131EF8 for ; Sun, 6 Aug 2017 13:40:28 -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 v76Kaaap017348 for ; Sun, 6 Aug 2017 21:40:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=PST+lvSirI9BX8zj/jHhxf8FGiQlrk9JI+Qha7poK0c=; b=EA4pNORahE6JE0fitKO/brccigERZW8l9+TaNDiNI4EMXCQJbhUipvALDgobrWkuPDdi 2P9NDqlCN4FMXnZHsS7gBXGylj6OWw31C46qkeGRlfC+cYCs/+TEO884YiQQOba1Rq2b tV6OOiLc/Xn3/z5kvG8WmQJeLfzJtJOn0ZuRdsWx1Yg/gTqCCCin3cwvp/zSambwBIBy vHjxx9kDKB/aDQ5IHh7G4rVhb1RM6txFcKDrpKJ0TvHV4xvu1jzET8OOdljt/kpz1CwE w3oavpPO36UU4rBbvPAoLiUnLG4TzAsrYRETvdLEoSxf89ArU3IVPruMm29viJE88pZL ag== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2c55jcnpwg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 06 Aug 2017 21:40:26 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v76KarKu013992 for ; Sun, 6 Aug 2017 16:40:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2c59butnj5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sun, 06 Aug 2017 16:40:25 -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; Sun, 6 Aug 2017 16:40:24 -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, 6 Aug 2017 16:40:24 -0400 From: "Salz, Rich" To: "tls@ietf.org" CC: "tls@ietf.org" Thread-Topic: [TLS] WG adoption call: SNI Encryption Thread-Index: AQHTDSBfZW3LT3FQUkixbI8dTc6jxaJ0cgCAgAD+CACAAl3kEA== Date: Sun, 6 Aug 2017 20:40:23 +0000 Message-ID: <6718e91d39ac4faf82a97c6895165614@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87pocbwjry.fsf@fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.168] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-06_14:, , 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-1706020000 definitions=main-1708060358 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-06_14:, , 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-1706020000 definitions=main-1708060358 Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Aug 2017 20:40:30 -0000 PiBpdCdzIG9kZCB0byBhZG9wdCB0aGUgZHJhZnQgd2l0aG91dCBjaG9vc2luZyB3aGljaCBvZiB0 aGUgZGVzaWducyB3ZSdyZSBhZG9wdGluZy4NCg0KT24gdGhlIGNvbnRyYXJ5LCBJIHRoaW5rIGl0 J3MgcmlkaWN1bG91cyBmb3IgdGhlIFdHIHRvIHBpY2sgb25lIGRlc2lnbiB3aXRob3V0IGRpc2N1 c3Npb24uICBJIHJlYWxseSBsb29rIGZvcndhcmQgdG8gQUdMJ3MgY29tbWVudHMgb24gZWFjaA0K From nobody Mon Aug 7 05:00: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 AE0BF129ABE for ; Mon, 7 Aug 2017 05:00:15 -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 BYLCakhuPFzG for ; Mon, 7 Aug 2017 05:00:14 -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 178FF1321A6 for ; Mon, 7 Aug 2017 05:00:14 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id a77so1210920qkb.0 for ; Mon, 07 Aug 2017 05:00:14 -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=9Mqupzgfl8blfw+rO7Ui4tI/Kds/HAVg9Cvr9C0xPFE=; b=H/lH9K1DEYcduAnVu/I9NowglGFGGwwVYfHtic1JpO8umrnoOCaMKx162YYODG6kXC +WYj5GQJ/IGwJ7aLgR7dk/ThpZwQW51liH+uDNYZXdciO7vb0ICqrbBT9unPRHiNwfmE 1lk5H21oS6Xnu400l+yyzveKFiL4i5wGpdk+bPeBm/AmAsUBdDxZcaJNS18u8PSaEFDW W3Io3tcVAFWN/RdOvYtXyrsSs/csi0iuUQKh9XdXeZMXZ27illTLwlpHA0ymhpRHvwlz 39AMi1cIdXaY8cjqDOakXTOuoSNIgl9MVqZY6meFAtDqG2y8U+Fafegrl3m1PK6ScZRl sYMA== 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=9Mqupzgfl8blfw+rO7Ui4tI/Kds/HAVg9Cvr9C0xPFE=; b=gwPCarrOkWswvR0Z1e4BqfSBjSbGtGJoy2i/1LSVyeTSc8zPil5fdtOiKGocbi4cZd 4m342v86IaI2RP+pyibQhesPrrjFlHxST3vkZfMuHc2Ne3GGpfwRqHI6j+K/oe+wKtWQ 72yJ2VN8nLhzrbm56NaLRZWl/l3dlcuEgsvOffMbc0Pa2ycb0XwkmJCNrmlAkP1sG3IY nonrmFsiYivjPfHVB/13YFitbZ3DBxGWZw/6qz/LXnwFuDel5n8obZw/CLfq0yZEEd34 LJSEkW5dRl93+ZjxZqpHzvU6DEe1QwPW5qXShJvfu+tI7dF1+/GUiPDEhBrXyPEA7kU3 HLPw== X-Gm-Message-State: AHYfb5jZFOQHLg8VAO/wQQDVBH8zs7US7468ai0i8QIQSLVEazNDm6OZ DhNZIv3D3n5RJuzvV6et7ZKdA4/6Lg== X-Received: by 10.233.223.68 with SMTP id t65mr361438qkf.122.1502107213225; Mon, 07 Aug 2017 05:00:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.209.147 with HTTP; Mon, 7 Aug 2017 05:00:12 -0700 (PDT) From: Debapriyay Mukhopadhyay Date: Mon, 7 Aug 2017 17:30:12 +0530 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c043a6cdbe578055628967d" Archived-At: Subject: [TLS] Looking for sample captures involving ChaCha20-Poly1305 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Aug 2017 12:00:16 -0000 --94eb2c043a6cdbe578055628967d Content-Type: text/plain; charset="UTF-8" Hi, I am in need of a sample capture through which I can get to see the packet exchanges involving CHACHA20_POLY1305 cipher suites. Can anyone please point me to any such sample capture. That would be helpful. Thanks. Regards Debapriyay Mukhopadhyay --94eb2c043a6cdbe578055628967d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0 =C2=A0I am in need of a sample capture thro= ugh which I can get to see the packet exchanges involving CHACHA20_POLY1305= cipher suites. Can anyone please point me to any such sample capture.
=C2=A0 =C2=A0That would be helpful.

=C2=A0 = =C2=A0Thanks.

Regards
Debapriyay Mukhopa= dhyay
--94eb2c043a6cdbe578055628967d-- From nobody Mon Aug 7 07:16: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 AD28613231E for ; Mon, 7 Aug 2017 07:16: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, 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 eXxv6afWSZr4 for ; Mon, 7 Aug 2017 07:16: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 C6A2B132353 for ; Mon, 7 Aug 2017 07:16:08 -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 v77EC0ek026819; Mon, 7 Aug 2017 15:16:06 +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=DbmDQuswoM/0joMvWhkaqrSi3WvjgKAzdcYf4MiPE2w=; b=Ya1YJJvW5RrXZIlm3qQtKNN+Vlk4ctuB/i4h185E/ap1nZkD16RC9+eHBXMF//fkfBtt AddzvHURqw2xKbUvDccwm/9zAZ5OSn714Zi7khwfJSwMsa2VZYGRSFb0SluB/J0OIGNc s50GnbuMWC7wGwgbNZ2kxvVKZ9sTjy1ReFuL3RZMvi8cPR2AU6Ncwp6K3ESCniZ0/5Sg TdkQWul/jyGnapcd4pVE/DCPNuQAaXxvoU4lcUlYavof0Dv0pV4zS2s2qo56GBKHogze O8RCH1dcGQYni/5sFKKq2mpBp2Om0rU4x9kRCoSVeF5a9PpZRR1kgfToh1u32PaGgyjU KQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2c55jctvfq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2017 15:16:06 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v77EBDZR003976; Mon, 7 Aug 2017 10:16:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c59bupy74-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2017 10:16:04 -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, 7 Aug 2017 10:16:01 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Mon, 7 Aug 2017 10:15:59 -0400 From: "Short, Todd" To: Martin Thomson CC: "Kaduk, Ben" , "" Thread-Topic: [TLS] WG adoption call: draft-thomson-tls-record-limit Thread-Index: AQHTDSBM8soqgpN9rE6Vol9T0Pg8BKJ0400AgAD43ACAA1wFAA== Date: Mon, 7 Aug 2017 14:15:58 +0000 Message-ID: References: <69a96715-3a58-f5c9-e801-57c84c12c29c@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.233] Content-Type: multipart/alternative; boundary="_000_EFE554848C604451BDCED7395DDC8FD9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_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-1706020000 definitions=main-1708070237 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_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-1706020000 definitions=main-1708070237 Archived-At: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Aug 2017 14:16:11 -0000 --_000_EFE554848C604451BDCED7395DDC8FD9akamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adoption too. -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 5, 2017, at 6:57 AM, Martin Thomson > wrote: On 5 August 2017 at 06:07, Benjamin Kaduk > wrote: It is currently before 20170818, and I support adoption of this draft and a= m willing to review it as it progresses. I do agree with Ilari that limiting the ciphertext size seems to make more sense, but of course we can discuss that post adoption. FWIW, I hope to merge PR #1 that addresses this point. It isn't perfect, but it keeps the happy path - those who don't pad more than the minimum - happy. We should discuss pros and cons, of course, and I'd prefer to do that as an official WG product. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_EFE554848C604451BDCED7395DDC8FD9akamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable I support adoption too.
--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

On Aug 5, 2017, at 6:57 AM, Martin Thomson <martin.thomson@gmail.com>= wrote:

On 5 August 2017 at 06:07, Benjamin Kaduk <bkaduk@akamai.com> wrote:
It is currently before 20170818, and I= support adoption of this draft and am
willing to review it as it progresses.

I do agree with Ilari that limiting the ciphertext size seems to make more<= br class=3D""> sense, but of course we can discuss that post adoption.

FWIW, I hope to merge PR #1 that addresses this point.  It isn't
perfect, but it keeps the happy path - those who don't pad more than
the minimum - happy.  We should discuss pros and cons, of course, and<= br class=3D""> I'd prefer to do that as an official WG product.

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

--_000_EFE554848C604451BDCED7395DDC8FD9akamaicom_-- From nobody Mon Aug 7 08: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 7F7AA1321DC for ; Mon, 7 Aug 2017 08:10:25 -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 NEMeiVeIHKI5 for ; Mon, 7 Aug 2017 08:10:18 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DCB13202C for ; Mon, 7 Aug 2017 08:10:18 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id m88so3612081iod.2 for ; Mon, 07 Aug 2017 08:10:18 -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; bh=QN3aidBrLfpZON1rEsmh9OTzWpBnBteM4u5gfjBlQqk=; b=WZq0w/SCAWV2iipafEkBgkhZ/1AmAQ4hIbzbeR/YvTmDx7pory52wY4XsTAes+MlLy BP+rT6TgkzLR4jjUxSPMjaKP6a8aZHUMpL24XNF6e6SHh/hC5ltrjN++sI5ulGnBA1EF Eb3HKEuP2FZ74zHZ0tVoRQJbysYH/4Zsyt66gliRLSq8rAiveOLuatnLcCrrcrv1qxkk mEFT2DMzuRe7zjvjT2nB7Fz+iZ1y+5reap/4aQTBF7i+qrNt7yP95/3fnqb0wJ4+uGey qITarYVuCBMOyTy0GjjmcHBdt7cpSjQNsBY43tQ+YI4VLhcy5qww+txMKRE0eW5h9vlG X3sg== 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; bh=QN3aidBrLfpZON1rEsmh9OTzWpBnBteM4u5gfjBlQqk=; b=XFkfyoDM0qFGZuYAsxKkZ0fkEEePsPq50HqM1GsO6JPYrPWwj8TBO7n1CPtnZS0w1I /RQhZoyXsiW/lpC/nJjh9rB0ngLUDRIJn/Xg3isSRqlJ2tE8O8OhzhyTFrDsrIb/Gplh qUxlXc7PzP1ARQrva4OjAHs8/oiX16FbTKFchDTdyRVVMztdIkyfRtoj6SxYsib9yURs M9JlBdextUXEJIcg3VncVCPOakQK5Uielb5MBo7KUYdb1dqs4/lwHKlXhiyF/xVgMVf5 f6j2BV0KEloXKWSylL5v5V77nKdjwMhyIAgmpnF3io83pSU1Vefv5ZMircLk1Xfzylc+ LmiQ== X-Gm-Message-State: AHYfb5in38jX6s+sFVmx2FhqX0ClF5BYmacXIL3hOvVxKQPM/A+pYDz+ UDL8Z7hRA9Z1WP+eFb3sFwUp/kyAEcVH X-Received: by 10.107.171.198 with SMTP id u189mr642736ioe.287.1502118618005; Mon, 07 Aug 2017 08:10:18 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.38.216 with HTTP; Mon, 7 Aug 2017 08:10:17 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Mon, 7 Aug 2017 08:10:17 -0700 X-Google-Sender-Auth: P8dK2wYhSWcpL3I2SZaBY03Iayo Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary="94eb2c05a384a306cc05562b3e93" Archived-At: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Aug 2017 15:10:25 -0000 --94eb2c05a384a306cc05562b3e93 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 4, 2017 at 5:50 AM, Sean Turner wrote: > At our IETF 99 session, there was support in the room to adopt > draft-thomson-tls-record-limit [0]. We need to confirm this support on the > list so please let the list know whether you support adoption of the draft > and are willing to review/comment on the draft before 20170818. If you > object to its adoption, please let us know why. > I support adoption. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --94eb2c05a384a306cc05562b3e93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 4, 2017 at 5:50 AM, Sean Turner <sean@sn3rd.com> wrote:=
At our IETF 99 session, there was suppor= t in the room to adopt draft-thomson-tls-record-limit [0].=C2=A0 We need to= confirm this support on the list so please let the list know whether you s= upport adoption of the draft and are willing to review/comment on the draft= before 20170818.=C2=A0 If you object to its adoption, please let us know w= hy.

I support adoption.


Cheers

AGL

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
--94eb2c05a384a306cc05562b3e93-- From nobody Wed Aug 9 22:55: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 AD9DF132559 for ; Wed, 9 Aug 2017 22:55:11 -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 jdzN3CEATcfc for ; Wed, 9 Aug 2017 22:55:08 -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 72AC6132554 for ; Wed, 9 Aug 2017 22:55:08 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id s143so52653966ywg.1 for ; Wed, 09 Aug 2017 22:55:08 -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=5ASOLWwDH5Cx2vtgpegfJnULtVFtkF++OwKKU11WVqo=; b=eHpWTa2tmP8/LrdT1KzKOM45n01BPhxekM8wwe2UDGZ8wOE5q4rbLNP7jklNEDV0Dm VOZ6CK03f5ZV73Na4idNW1J9bU6tYHz5nKCz9l5nU7AVMfcy/yJRPRHu4AWNzsjJWi2l G97cxiaij2HkG+Y0st5fX8qlXSICNF+0XRAeCeoTgM0+sqxkxVM+x3tu3jCqu+I1IVqc i6GSdrQ0OuSEL6W1NFhOm3679nYJByrvlTO4VbCbSbU9I5fvTILsjMZiobjks3aRolSe mYGjXIXHFEXSEVH3aAJBO3QlAtVo7y2Tv1HD31mZs98XSLCfPDY9G9mxiOKgUh1LmS7B bMIA== 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=5ASOLWwDH5Cx2vtgpegfJnULtVFtkF++OwKKU11WVqo=; b=h8pGQx+So9dhe/0VW4LL+WbtmZvov6KlE7FyE/aja0iUAh6z2jTWrgjeBIQQVQxGQH aCEebWHrVOV5j01S8GBQkdQ8wQqe9ED8/V73Yzg7FBfrA1AlLguutGMiX/z813EikwGk JE8/Zo8XxWx0+fO5JAFQJVqxZx0H9A3JlkJ46E6MjqwcrSR7hmC2BxNgi3SQkG1kXr93 e+pTrGR22GtnZ8PiOyQIC/f/1DaST1OK2s/NYFeo/ts7N1AJ0BNVZjkHrMHOKsGzdXFg ZjY2EicmCvM+8er8iR9SytAQEb+mfzh0ls4HGXl0x4n4VpxUuehJj86r8nJh08LkMTfe QK1A== X-Gm-Message-State: AHYfb5geNZcRXScKh7/avYr1qJe0GkaQsytKnrypEkelysE4Ml8flYn8 gQGZ+N5ubo5qiJ4Vi/cDakUJXM7x6J1VCSQ= X-Received: by 10.129.197.73 with SMTP id o9mr8382272ywj.183.1502344507434; Wed, 09 Aug 2017 22:55:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.132 with HTTP; Wed, 9 Aug 2017 22:54:46 -0700 (PDT) From: Tony Arcieri Date: Wed, 9 Aug 2017 22:54:46 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="94eb2c1a4f38b2bb3e05565fd611" Archived-At: Subject: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Aug 2017 05:55:11 -0000 --94eb2c1a4f38b2bb3e05565fd611 Content-Type: text/plain; charset="UTF-8" As I look at draft-huitema-tls-sni-encryption[1], I really think it's putting the cart before the horse. I really like the proposed TLS-in-TLS tunneling mechanism, but I feel it is a generally useful mechanism, and this draft relegates it to providing a point solution specifically for the purposes of SNI encryption and considering only that use case. One of the things I like the most about TLS 1.3 is how it has harmonized the sort of chunky stew of ill-conceived features found in previous TLS versions (with nebulous and overlapping responsibilities) into a smaller set of clearly-defined parsimonious ones which cover a wide range of use cases. In considering the general problem of "SNI encryption", and particularly within the context of TLS-in-TLS tunneling solution, I humbly ask that other use cases which would benefit from a TLS-in-TLS tunneling mechanism are considered. I think any draft about this should have TLS-in-TLS tunneling itself as the centerpiece, and "SNI encryption" off to the side as one potential use case. So, what other use cases are worth considering? Egress proxies! Consider: a gateway server acting as an external proxy which bridges an internal network with the Internet, acting as a forward proxy to authenticated clients (either human-driven apps/tools or backend services). What I think is particularly interesting about this use case in the context of the SNI encryption discussion is it is in fact almost entirely the same problem from a technical perspective. Where it differs is largely in the framing of the problem: instead of using the gateway to reach a hidden host from the Internet, we are using the gateway to talk to the Internet from an internal network which needs to go through a proxy host to reach the Internet. More tangibly, I would like the following as the administrator of an internal network: - All outbound traffic flows through centrally managed gateway hosts which act as TCP proxies. Outbound connections to the Internet are otherwise NOT allowed - As we're fans of actually using TLS to provide end-to-end transport security and not "SSL added and removed here ;-)", we want the resulting connection to be encrypted end-to-end between the internal network TLS client and the requested destination server. Also, all "setup" communication to the gateway should also happen over TLS - The gateway authenticates clients (using e.g. a TLS client certificate) and authorizes the outbound hostnames against an ACL. This way we can control which clients are allowed to reach which external endpoints. There are a few additional things which are different between the cases beyond some of what I've just mentioned. Ideally the client verifies the gateway's server cert against an internal-only CA bundle, then verifies the tunneled destination host against a public CA bundle. We might want a client to present an internal client certificate to the gateway, but present no cert/a different cert to the destination host. That said, aside from minutia like that, the machinery seems largely the same. What are the real-world "rough consensus and running code" solutions to this sort of problem in place today? There are all sorts of options that are sort-of-not-quite like what I just described, e.g. a SOCKS proxy. But the one I'm thinking of as I write this is CONNECT tunnels: https://wiki.squid-cache.org/Features/HTTPS These sorts of tunnels (ab)use a HTTP(S) forward-proxy to establish outbound TCP connections (which, if you care about security, will carry TLS encrypted traffic). This approach is partly described in RFC 2817[2], but to tick all of the checkboxes on the points I mentioned earlier using this method, you need to implement features in draft-luotonen-web-proxy-tunneling-01[3], which has never received an RFC and, as far as I can tell, is only properly implemented by Squid. Using Squid as a TLS-in-TLS tunneling solution seems less than ideal to me, and yet in many ways it seems like the "least friction" option, especially for access control purposes. I would really love a simple, straightforward approach to this problem with a published RFC instead of an expired draft that's only implemented by Squid. I also think TLS-in-TLS tunneling can solve this same problem in a much more straightforward manner. tl;dr: when making drafts regarding TLS-in-TLS tunneling, please consider the forward-proxy use case in addition to the reverse-proxy case [1]: https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ [2]: https://www.rfc-editor.org/rfc/rfc2817.txt [3]: https://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01 -- Tony Arcieri --94eb2c1a4f38b2bb3e05565fd611 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I look at draft-huitema-tls-= sni-encryption[1], I really think it's putting the cart before the hors= e. I really like the proposed TLS-in-TLS tunneling mechanism, but I feel it= is a generally useful mechanism, and this draft relegates it to providing = a point solution specifically for the purposes of SNI encryption and consid= ering only that use case.

One of the things I like the most about TLS 1.3 is how = it has harmonized the sort of chunky stew of ill-conceived features found i= n previous TLS versions (with nebulous and overlapping responsibilities) in= to a smaller set of clearly-defined parsimonious ones which cover a wide ra= nge of use cases.

In considering the general problem of "SNI encryption"= ;, and particularly within the context of TLS-in-TLS tunneling solution, I = humbly ask that other use cases which would benefit from a TLS-in-TLS tunne= ling mechanism are considered. I think any draft about this should have TLS= -in-TLS tunneling itself as the centerpiece, and "SNI encryption"= off to the side as one potential use case.

So, what other use cases are worth co= nsidering? Egress proxies!

Consider: a gateway server acting as an external proxy= which bridges an internal network with the Internet, acting as a forward p= roxy to authenticated clients (either human-driven apps/tools or backend se= rvices).

What I think is particularly interesting about this use case in the = context of the SNI encryption discussion is it is in fact almost entirely t= he same problem from a technical perspective. Where it differs is largely i= n the framing of the problem: instead of using the gateway to reach a hidde= n host from the Internet, we are using the gateway to talk to the Internet = from an internal network which needs to go through a proxy host to reach th= e Internet.

More tangibly, I would like the following as the administrator of an = internal network:

- All outbound traffic flows through centrally managed gateway = hosts which act as TCP proxies. Outbound connections to the Internet are ot= herwise NOT allowed

- As we'r= e fans of actually using TLS to provide end-to-end transport security and n= ot "SSL added and removed here ;-)", we want the resulting connec= tion to be encrypted end-to-end between the internal network TLS client and= the requested destination server. Also, all "setup" communicatio= n to the gateway should also happen over TLS

=
- The gateway authenticates clients (using= e.g. a TLS client certificate) and authorizes the outbound hostnames again= st an ACL. This way we can control which clients are allowed to reach which= external endpoints.

There are a few additional things which are different betw= een the cases beyond some of what I've just mentioned. Ideally the clie= nt verifies the gateway's server cert against an internal-only CA bundl= e, then verifies the tunneled destination host against a public CA bundle. = We might want a client to present an internal client certificate to the gat= eway, but present no cert/a different cert to the destination host. That sa= id, aside from minutia like that, the machinery seems largely the same.

What are = the real-world "rough consensus and running code" solutions to th= is sort of problem in place today? There are all sorts of options that are = sort-of-not-quite like what I just described, e.g. a SOCKS proxy. But the o= ne I'm thinking of as I write this is CONNECT tunnels:

https://wiki.squid-cache.org/Features/HT= TPS

These sorts of tunnels (ab)use a HTTP(S) forward-proxy to establish o= utbound TCP connections (which, if you care about security, will carry TLS = encrypted traffic).

This approach is partly described in RFC 2817[2], but to tick= all of the checkboxes on the points I mentioned earlier using this method,= you need to implement features in=C2=A0draft-luotonen-web-proxy-tunneling-= 01[3], which has never received an RFC and, as far as I can tell, is only p= roperly implemented by Squid. Using Squid as a TLS-in-TLS tunneling solutio= n seems less than ideal to me, and yet in many ways it seems like the "= ;least friction" option, especially for access control purposes.
=

I would rea= lly love a simple, straightforward approach to this problem with a publishe= d RFC instead of an expired draft that's only implemented by Squid. I a= lso think TLS-in-TLS tunneling can solve this same problem in a much more s= traightforward manner.

tl;dr: when making drafts regarding TLS-in-TLS tunneling, = please consider the forward-proxy use case in addition to the reverse-proxy= case

= [1]:=C2=A0https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryp= tion/
[2]:=C2=A0https://www.rfc-editor.org/rfc/rfc2817.txt<= /a>
[3]:=C2=A0https://tools.ietf.org/htm= l/draft-luotonen-web-proxy-tunneling-01

--
Tony Arcieri
--94eb2c1a4f38b2bb3e05565fd611-- From nobody Thu Aug 10 02:23: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 B2A44128AA1 for ; Thu, 10 Aug 2017 02:23: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, 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 eNxiOc9RKX7I for ; Thu, 10 Aug 2017 02:23:55 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47446132665 for ; Thu, 10 Aug 2017 02:23:54 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g71so7355910ioe.5 for ; Thu, 10 Aug 2017 02:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZWOAxzKTO5ORdeCeBsvVAkqieN2NE5KGqLjHG19zW8g=; b=R5sk6RXNm22W3B4YLY/wUIq8FwDjl68OVW9Dq7WB7Y5a2N9cbDot6ocn2nPuGWizLa Hf3cc9yJOKtz8j5QmFwOzuiekJRRbsQHwvWFOUiZ5aIDHJOLToBK+WiRszoB+p8xTRKK j6jeiAHRd3r0LJXB2i0ofNsdibzANucOuVHhglDiTdr03ZCkfMbaAhVnXGJjo0+H7pzp GOGN/WiU0QZrlQwcl67LKLvIjlX6Kz+eaEFjJaH5eqIjaN3SOYN/NSQSILx8x68+5FWW VvSDvWEL7/5ki1FCRo/k7KpyuwXM/lqdGdWZ1ohoFNPj/XSR6a4PLD/xHScnuzqmoQ5b oqzg== 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=ZWOAxzKTO5ORdeCeBsvVAkqieN2NE5KGqLjHG19zW8g=; b=go313uF+VWkKeTUfbeiE5uMRn3BRiRC4zzX/K3JBgz3+8SsKiKDcrBhx2cGVmQJDkM f1IbKqvkHy//ctufuDrucGlD/uZwqCjCQzEL1lbF19zK5LdbWRzffYfmPQoN5YH3H6Uj 0EdCHTEbz5oUJCzlMz2K90TSo/U1prLQgBxybTYxIbqKCgltmTgI1A3gmt4UWqfwxoER Wt/2Hq/1b+tT65s3vZEL/A9AIyvPdgY835+FpKpb39REflhgTyQ/0XUOyJqFV9vWVemk sc58Ie4qIKZXHtPlYIvwgrIOsY6rTiB45mV/kq7e8XA1uEEMda1EYLu9tPryal6bfqIa lgnA== X-Gm-Message-State: AHYfb5gJ7U9WccDCbHmkwAensYf0ImAAEBu0Co+MStHrn6qc5qacM0iX qx3blVSm8Vu1UycHDU/YPZitHC7obg== X-Received: by 10.107.46.155 with SMTP id u27mr8628698iou.107.1502357033525; Thu, 10 Aug 2017 02:23:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 10 Aug 2017 02:23:52 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 10 Aug 2017 19:23:52 +1000 Message-ID: To: Tony Arcieri Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Aug 2017 09:23:57 -0000 I'm trying to work out whether there is anything new here. I know that browsers implement proxying over HTTPS and CONNECT. Can you summarize the ask more succinctly? Because I'm thinking that this is a solved problem. See Section 8.3 of RFC 7540. We didn't put that there for a lark. On 10 August 2017 at 15:54, Tony Arcieri wrote: > As I look at draft-huitema-tls-sni-encryption[1], I really think it's > putting the cart before the horse. I really like the proposed TLS-in-TLS > tunneling mechanism, but I feel it is a generally useful mechanism, and this > draft relegates it to providing a point solution specifically for the > purposes of SNI encryption and considering only that use case. > > One of the things I like the most about TLS 1.3 is how it has harmonized the > sort of chunky stew of ill-conceived features found in previous TLS versions > (with nebulous and overlapping responsibilities) into a smaller set of > clearly-defined parsimonious ones which cover a wide range of use cases. > > In considering the general problem of "SNI encryption", and particularly > within the context of TLS-in-TLS tunneling solution, I humbly ask that other > use cases which would benefit from a TLS-in-TLS tunneling mechanism are > considered. I think any draft about this should have TLS-in-TLS tunneling > itself as the centerpiece, and "SNI encryption" off to the side as one > potential use case. > > So, what other use cases are worth considering? Egress proxies! > > Consider: a gateway server acting as an external proxy which bridges an > internal network with the Internet, acting as a forward proxy to > authenticated clients (either human-driven apps/tools or backend services). > > What I think is particularly interesting about this use case in the context > of the SNI encryption discussion is it is in fact almost entirely the same > problem from a technical perspective. Where it differs is largely in the > framing of the problem: instead of using the gateway to reach a hidden host > from the Internet, we are using the gateway to talk to the Internet from an > internal network which needs to go through a proxy host to reach the > Internet. > > More tangibly, I would like the following as the administrator of an > internal network: > > - All outbound traffic flows through centrally managed gateway hosts which > act as TCP proxies. Outbound connections to the Internet are otherwise NOT > allowed > > - As we're fans of actually using TLS to provide end-to-end transport > security and not "SSL added and removed here ;-)", we want the resulting > connection to be encrypted end-to-end between the internal network TLS > client and the requested destination server. Also, all "setup" communication > to the gateway should also happen over TLS > > - The gateway authenticates clients (using e.g. a TLS client certificate) > and authorizes the outbound hostnames against an ACL. This way we can > control which clients are allowed to reach which external endpoints. > > There are a few additional things which are different between the cases > beyond some of what I've just mentioned. Ideally the client verifies the > gateway's server cert against an internal-only CA bundle, then verifies the > tunneled destination host against a public CA bundle. We might want a client > to present an internal client certificate to the gateway, but present no > cert/a different cert to the destination host. That said, aside from minutia > like that, the machinery seems largely the same. > > What are the real-world "rough consensus and running code" solutions to this > sort of problem in place today? There are all sorts of options that are > sort-of-not-quite like what I just described, e.g. a SOCKS proxy. But the > one I'm thinking of as I write this is CONNECT tunnels: > > https://wiki.squid-cache.org/Features/HTTPS > > These sorts of tunnels (ab)use a HTTP(S) forward-proxy to establish outbound > TCP connections (which, if you care about security, will carry TLS encrypted > traffic). > > This approach is partly described in RFC 2817[2], but to tick all of the > checkboxes on the points I mentioned earlier using this method, you need to > implement features in draft-luotonen-web-proxy-tunneling-01[3], which has > never received an RFC and, as far as I can tell, is only properly > implemented by Squid. Using Squid as a TLS-in-TLS tunneling solution seems > less than ideal to me, and yet in many ways it seems like the "least > friction" option, especially for access control purposes. > > I would really love a simple, straightforward approach to this problem with > a published RFC instead of an expired draft that's only implemented by > Squid. I also think TLS-in-TLS tunneling can solve this same problem in a > much more straightforward manner. > > tl;dr: when making drafts regarding TLS-in-TLS tunneling, please consider > the forward-proxy use case in addition to the reverse-proxy case > > [1]: https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ > [2]: https://www.rfc-editor.org/rfc/rfc2817.txt > [3]: https://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01 > > -- > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Aug 10 07:04: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 44F921326BF for ; Thu, 10 Aug 2017 07:04:06 -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 as0TCcw7uLzh for ; Thu, 10 Aug 2017 07:04:04 -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 F0B8D13219F for ; Thu, 10 Aug 2017 07:04:03 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id s143so5185701ywg.1 for ; Thu, 10 Aug 2017 07:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6CX363Ozz1VSQNpWYYquS2rOeEKw5SjOo+Kkd/YvJ/o=; b=KxJqwWF6NT7Uk/WT4cB2zM2GuV2gejftz2wN90kw+04WqUd9o+d9wnEsaKCUDy3pV2 GoslUZa0QZ+PfAveoUfh/yTNuEzPbsPjexfboXs+43HRUphUTqg5t6nirwSFHjGw4Y9B UFHHhH/pTbr6PpYZ0k22lC46CRKBfktG02xQhzoKi7LErhspYoxXUxxXnXeFlW5rwZ7G LkHDOj/D2mq/z3JRSFT6PWgeNeMg3iS0H206mN+I5gbApuGnWBu4pHucjDNT5+l2KeZG N3CII/PFGPHyrTdOuG1aL2z0znVMpumYSVnBnWEfhqQzCxnQUBnPQd6uYcPjVpn4XkQM lvyg== 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=6CX363Ozz1VSQNpWYYquS2rOeEKw5SjOo+Kkd/YvJ/o=; b=mXie+gCr+hv32L4VN99/whEHCmTm+zlJ/rD+fbuPAKMztdgGVEaWjkJXwQmykaswnS AgV3Mt3IivNkE/dLFM8kMnybEALwSicikYmgXfNKKlp93l4UmD847XsV7Q1nb+un1oy0 MxSP2N+NkiUlEf4IQF9578Bv3PgUmL6ZcbHvs/Wrz3sxWr+71nmg4koCAt3ZFUrNvaem ZO/DQ8iTMgaXHTbPEhlWOFsFh/1XRVscnzQ8CVPBnmaw5Q/CIvdSQgbDpCFJYR6DIqOH Drp3i1KRamrlQkcGOB1PinnRrqyNFlb1e+JKv7ZoTVMRAzRQ9w2keu0WErW0pRbaOBiC DLzA== X-Gm-Message-State: AHYfb5hhzw5YvmJ7XylHrOVfE3kJCssQ/opmbu7SIy8DMmKzTIZnPnYX rmKL2SPLrwpgKlNFCuzQ0cu6IcwKaQ== X-Received: by 10.129.178.200 with SMTP id q191mr9374513ywh.386.1502373843109; Thu, 10 Aug 2017 07:04:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.132 with HTTP; Thu, 10 Aug 2017 07:03:42 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Thu, 10 Aug 2017 07:03:42 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="94eb2c1462543d117a055666abeb" Archived-At: Subject: Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Aug 2017 14:04:06 -0000 --94eb2c1462543d117a055666abeb Content-Type: text/plain; charset="UTF-8" On Thu, Aug 10, 2017 at 2:23 AM, Martin Thomson wrote: > I'm trying to work out whether there is anything new here. I know > that browsers implement proxying over HTTPS and CONNECT. Can you > summarize the ask more succinctly? Because I'm thinking that this is > a solved problem. > > See Section 8.3 of RFC 7540. We didn't put that there for a lark. Backing up a bit: my personal primary use cases are services running on a network trying to speak outbound. Yes it's great browsers have support, but what about anything else that wants to make an outbound TLS connection to the Internet? Trying to solve this problem with HTTP, rather than the TLS, forces every single network client library on earth that wants to talk through these proxies to implement both CONNECT and enough HTTP to speak to the proxy and request CONNECT. Do you really think (ab)using an HTTP proxy this way is a good idea? I don't. I also don't think it's been particularly successful: - We've wound up with a server-side ecosystem where, as far as I can tell, Squid is the only service which implements all the features needed to provide an HTTPS-authenticated outbound CONNECT gateway with client-by-client ACLs - Support is not as ubiquitous as you may think. For example Go's net/http library does not support CONNECT through an HTTPS proxy: https://github.com/golang/go/issues/11332 Solving this problem with TLS instead of HTTPS could result in a solution where once it's implemented in a TLS library, any clients using that TLS library could take advantage of it, rather than each client having to implement CONNECT themselves. I say this all as someone looking at rolling out Squid for this purpose as we speak, and having worked places who have run Squid this way in the past. CONNECT is widely supported enough to mostly make this work, but I think things could be... much better than they are. -- Tony Arcieri --94eb2c1462543d117a055666abeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 10, 2017 at 2:23 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
I'm trying to work out whether there is anything new here.=C2=A0 I= know
that browsers implement proxying over HTTPS and CONNECT.=C2=A0 Can you
summarize the ask more succinctly?=C2=A0 Because I'm thinking that this= is
a solved problem.

See Section 8.3 of RFC 7540.=C2=A0 We didn't put that there for a lark.=

Backing up a bit: my personal primary use = cases are services running on a network trying to speak outbound. Yes it= 9;s great browsers have support, but what about anything else that wants to= make an outbound TLS connection to the Internet?

= Trying to solve this problem with HTTP, rather than the TLS, forces every s= ingle network client library on earth that wants to talk through these prox= ies to implement both CONNECT and enough HTTP to speak to the proxy and req= uest CONNECT.

Do you really think (ab)using an HTT= P proxy this way is a good idea? I don't. I also don't think it'= ;s been particularly successful:

- We've wound= up with a server-side ecosystem where, as far as I can tell, Squid is the = only service which implements all the features needed to provide an HTTPS-a= uthenticated outbound CONNECT gateway with client-by-client ACLs
=
- Support is not as ubiquitous as you may think. For example= Go's net/http library does not support CONNECT through an HTTPS proxy:= =C2=A0https://github.= com/golang/go/issues/11332

Solving this = problem with TLS instead of HTTPS could result in a solution where once it&= #39;s implemented in a TLS library, any clients using that TLS library coul= d take advantage of it, rather than each client having to implement CONNECT= themselves.

I say this all as someone looking at = rolling out Squid for this purpose as we speak, and having worked places wh= o have run Squid this way in the past. CONNECT is widely supported enough t= o mostly make this work, but I think things could be... much better than th= ey are.

--
Tony Arci= eri
--94eb2c1462543d117a055666abeb-- From nobody Thu Aug 10 07:39:51 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 A50321321AF; Thu, 10 Aug 2017 07:39:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-tls-ecdhe-psk-aead@ietf.org, Joseph Salowey , tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150237598967.11871.16700348530940949770.idtracker@ietfa.amsl.com> Date: Thu, 10 Aug 2017 07:39:49 -0700 Archived-At: Subject: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT) 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: Thu, 10 Aug 2017 14:39:50 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-tls-ecdhe-psk-aead-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The citations to TLS 1.3 still seem pretty muddled. I think you should just stop referencing and discussing 1.3. S 2. I'm not sure that the discussion of the PRF is helpful here in mandating the non-use of these cipher suites with TLS 1.1 and below. From nobody Thu Aug 10 19:07: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 9EADC120720 for ; Thu, 10 Aug 2017 19:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAUxoeF4FKbh for ; Thu, 10 Aug 2017 19:07:53 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 74650127077 for ; Thu, 10 Aug 2017 19:07:53 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 76so21350544ith.0 for ; Thu, 10 Aug 2017 19:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vpNUC50PrjcE00d5rs7BmfRfn1vEPn8+DTKKuUvjoiQ=; b=ZPaW7mDtRFJph81jrUvpEbehzTqKVW78C7vYi63Jk6ZxMQADpaiv+uw9TST9H9oS80 d2yut44hN3vL5o+3LdbBo5zvFJlvghyK9tXS84yMhLWKpLmxupkyVcdpgWy4A5G+bTm0 y22qq5IZOf1Kp61uEuDi/0VqLXY/v6ESnWbrmjp1rBBbAeirte8vv1sgk4TGuYMEPFQG DnLoUhFQiTtqejATO8RJy6YgKAG8YlXkrGohe7agb5ag5MfDpNNcSsY+InZiVGFDnyF6 ZOrqflRqam7UKW60CBLAL3+UixDdp7No6NQzGfktCIb7bXradBapUvDUxuigGerZkdMQ l8sw== 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=vpNUC50PrjcE00d5rs7BmfRfn1vEPn8+DTKKuUvjoiQ=; b=kNzJmOwDCusGpIqKICYLFDBf+mnSk8mv6rlhPA2HhKYvgSeQCxeptRNAtTfqeG9yZB cl3QVYmjsjUwaDLfnX225b7oBfuhsNlC6u6nPonlY8eDmZkEP5DbNB4IVzqskS7d7h7a W+mBdSQoOzfDcqwnP0O2Jwuq6+q9K4PhMovaxfsjMFLFZiZun9fWSnqD005SZ70kzY9B JGbg4ot6NDUm3KIX//EV6YK+FgpLZKjvOarjN5u/0Cb5VYkutesA1824Z9w2z4X4ezUe HrDnZibQ/f++DBzG5vn3qU5blPitl3JfrBSSUcaZzJ/i4wlU77HvA8xwvRz2fiTSf7sd dM8g== X-Gm-Message-State: AIVw111I+Tv3Alwtaz6dW23eWzctSbVYCz9wvKANQTydr8uWIiiVCWk4 bxjaQOYOmESJjypdoUQl0gEpEUJypA== X-Received: by 10.36.13.10 with SMTP id 10mr3041460itx.51.1502417272794; Thu, 10 Aug 2017 19:07:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 10 Aug 2017 19:07:52 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 11 Aug 2017 12:07:52 +1000 Message-ID: To: Tony Arcieri Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 02:07:55 -0000 So you want CONNECT for TLS? You could have said that. What makes you think that the implementation story here would be any different? I'm not trying to destroy your idea, which seems fine on face value, but just trying to understanding the value proposition better. On 11 August 2017 at 00:03, Tony Arcieri wrote: > On Thu, Aug 10, 2017 at 2:23 AM, Martin Thomson > wrote: >> >> I'm trying to work out whether there is anything new here. I know >> that browsers implement proxying over HTTPS and CONNECT. Can you >> summarize the ask more succinctly? Because I'm thinking that this is >> a solved problem. >> >> See Section 8.3 of RFC 7540. We didn't put that there for a lark. > > > Backing up a bit: my personal primary use cases are services running on a > network trying to speak outbound. Yes it's great browsers have support, but > what about anything else that wants to make an outbound TLS connection to > the Internet? > > Trying to solve this problem with HTTP, rather than the TLS, forces every > single network client library on earth that wants to talk through these > proxies to implement both CONNECT and enough HTTP to speak to the proxy and > request CONNECT. > > Do you really think (ab)using an HTTP proxy this way is a good idea? I > don't. I also don't think it's been particularly successful: > > - We've wound up with a server-side ecosystem where, as far as I can tell, > Squid is the only service which implements all the features needed to > provide an HTTPS-authenticated outbound CONNECT gateway with > client-by-client ACLs > > - Support is not as ubiquitous as you may think. For example Go's net/http > library does not support CONNECT through an HTTPS proxy: > https://github.com/golang/go/issues/11332 > > Solving this problem with TLS instead of HTTPS could result in a solution > where once it's implemented in a TLS library, any clients using that TLS > library could take advantage of it, rather than each client having to > implement CONNECT themselves. > > I say this all as someone looking at rolling out Squid for this purpose as > we speak, and having worked places who have run Squid this way in the past. > CONNECT is widely supported enough to mostly make this work, but I think > things could be... much better than they are. > > -- > Tony Arcieri From nobody Thu Aug 10 22:41: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 3D2FB1324D8 for ; Thu, 10 Aug 2017 22:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 lnasmcql8G4w for ; Thu, 10 Aug 2017 22:41:11 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 21D7D1324DA for ; Thu, 10 Aug 2017 22:41:11 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id s143so16846113ywg.1 for ; Thu, 10 Aug 2017 22:41: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=fz+N3A12kNXLyLyCWG86+dKYYaebnfJAqJiulsF5sw4=; b=ip6CHFHSMU6ZBum1o3Foy0RYVHgrchTEO/GQDhEaVgtc58qzU6C3oe+sYDfQ5wEVUg 0ALLfN5FUwQVNirdIPJqiQDJ0yNURcGHAa1Bx+3hL/kk/qpQVrnu+tmH/18SINcs9URV u0xfluRQOvtZhWDLIXwQ0OgUdLCgdBW+Br2J+rzoqQqj4EXPCbgBYlTuhG5mYIW9CgVB fWgqGa7KPnMUcQKMiPmPtCMpLPlbVd/lNMcdMXBTmaCoSYnNqqsLNyUSOm1/FqKUv1z7 cHhpVJBHTd9npsA69uI9zCTwK0Jn0Sep8PoSkpnJwfuJ8DhZ25o+KLWDJFBSvpyECSb1 Slrg== 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=fz+N3A12kNXLyLyCWG86+dKYYaebnfJAqJiulsF5sw4=; b=ssiskUElt/qqdP9w1RAzVgOIEIahDkSleg52YRzitMKOhBAd0dlceXpSXeq88tlBBD yNs9Al9j4lt/MDcVVhbgZ9C+oYElgaX8K5nTxLaGjeHOMKZsZkwjxYLu1M/NS3tMXUFg p3M7S04tulfU5vBk2CTkD/Vxsujs36cXZ+7ubXm8QvjJWStXxN4Fee52W66GM+mx57Ya B9Sa5ZABaovfXkudaAfXLBBjy1aqwWUe3ABwFawtp9WwhNnD3rxnZifju44us5Hlt/NG t9yk4NwNgevUuv9oHaPa0zLNLnJvYxDZZ6/JVNJSWIBlmlMv3vgVD1uG7sKV2kSMVB6H iwKg== X-Gm-Message-State: AHYfb5hKoW7W4SLD78oIz0Ikkz36BVTxcE93eS/58oQsQmQBGYADlOZ2 e0SwjU9Y+7yNURDeXLuXDkFbkCmrjA== X-Received: by 10.37.207.148 with SMTP id f142mr11300425ybg.13.1502430070425; Thu, 10 Aug 2017 22:41:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.132 with HTTP; Thu, 10 Aug 2017 22:40:49 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Thu, 10 Aug 2017 22:40:49 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="94eb2c059acca5d625055673c269" Archived-At: Subject: Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 05:41:13 -0000 --94eb2c059acca5d625055673c269 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 10, 2017 at 7:07 PM, Martin Thomson wrote: > What makes you think that the implementation story here would be any > different? I'm not trying to destroy your idea, which seems fine on > face value, but just trying to understanding the value proposition > better. As I said earlier, the implementation story is the same (or extremely similar), but it's looking at the problem from a different perspective: What I think is particularly interesting about this use case in the context > of the SNI encryption discussion is it is in fact almost entirely the same > problem from a technical perspective. Where it differs is largely in the > framing of the problem: instead of using the gateway to reach a hidden host > from the Internet, we are using the gateway to talk to the Internet from an > internal network which needs to go through a proxy host to reach the > Internet. I did also list a few things I think are tangibly different: There are a few additional things which are different between the cases > beyond some of what I've just mentioned. Ideally the client verifies the > gateway's server cert against an internal-only CA bundle, then verifies the > tunneled destination host against a public CA bundle. We might want a > client to present an internal client certificate to the gateway, but > present no cert/a different cert to the destination host. That said, aside > from minutia like that, the machinery seems largely the same. Support for using different CA bundles for the gateway versus the destination host seems important in this use case, IMO. Also: support for sending different certs to the gateway versus the destination host. While these are ultimately just implementation details, I think they're worth at least considering when such a draft is being authored. -- Tony Arcieri --94eb2c059acca5d625055673c269 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 10, 2017 at 7:07 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
What makes you think that the implementation story here would be any different?=C2=A0 I'm not trying to destroy your idea, which seems fine = on
face value, but just trying to understanding the value proposition
better.

As I said earlier, the implementati= on story is the same (or extremely similar), but it's looking at the pr= oblem from a different perspective:

What I think is particularly interesting about this u= se case in the context of the SNI encryption discussion is it is in fact al= most entirely the same problem from a technical perspective. Where it diffe= rs is largely in the framing of the problem: instead of using the gateway t= o reach a hidden host from the Internet, we are using the gateway to talk t= o the Internet from an internal network which needs to go through a proxy h= ost to reach the Internet.=C2=A0

I did also list a few things I think are tangibly different:
<= br>
There are a few additional things which are different betw= een the cases beyond some of what I've just mentioned. Ideally the clie= nt verifies the gateway's server cert against an internal-only CA bundl= e, then verifies the tunneled destination host against a public CA bundle. = We might want a client to present an internal client certificate to the gat= eway, but present no cert/a different cert to the destination host. That sa= id, aside from minutia like that, the machinery seems largely the same.

Support for using different CA bundles = for the gateway versus the destination host seems important in this use cas= e, IMO.
Also: support for sending different certs to the gateway = versus the destination host.

While these are ultim= ately just implementation details, I think they're worth at least consi= dering when such a draft is being authored.

--
Tony Arcieri
--94eb2c059acca5d625055673c269-- From nobody Fri Aug 11 07:11: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 D01C5132659 for ; Fri, 11 Aug 2017 07:11:16 -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 Es-7DA_6Bafl for ; Fri, 11 Aug 2017 07:11:14 -0700 (PDT) Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D26A132651 for ; Fri, 11 Aug 2017 07:11:14 -0700 (PDT) Received: by mail-wr0-f178.google.com with SMTP id 33so13853516wrz.4 for ; Fri, 11 Aug 2017 07:11:14 -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:mime-version :content-transfer-encoding; bh=Zxq0S5oXaWVgGDJ/r11eFbQNVji7XtZCB4tdkVzMrmE=; b=TGATreT9GvwlFB1Qmhu2Gz6E6Pn/3m6r1ddYpY79E8waklPFnBBufjmUy98A70iE// bpCw+9VKlDbFKoTriZmlCtBFADnWuYFay13CL8fyuEmhpw1PEvJgpMi+ArHmfc24GCr1 ZUUWkIJ15A1xjmBdLmUu3IOnAa16xMl/vp0TqRGl3yhBJgOFgwtHzWSi8iGGENKhBMFY Qe0TtaO4Gwxi7oX/2ZLc9HmoeUBSJIkAg37UpTH1lq9LI7Ca3CCxyEAVQ6pJU4GJsagk oMnpA5Wo/0lNqOHlMOUV2sgFjhArOZoVZ2bZgOUVnP48QUC3H+aHdX+qEfUWTpyo865A eL4g== X-Gm-Message-State: AHYfb5ggM8FWqRkEOUjNN5L0A2O5AvigyIaWL8PnNSiZIOecci9AWyfq admmRRMYZK/qCU9UmHf7Tw== X-Received: by 10.223.172.21 with SMTP id v21mr10547331wrc.153.1502460672251; Fri, 11 Aug 2017 07:11:12 -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 e21sm936439wme.17.2017.08.11.07.11.11 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 11 Aug 2017 07:11:11 -0700 (PDT) Message-ID: <1502460670.3202.8.camel@redhat.com> From: Nikos Mavrogiannopoulos To: tls@ietf.org Date: Fri, 11 Aug 2017 16:11:10 +0200 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.4 (3.24.4-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 14:11:17 -0000 Imagine the following scenario, where the server and client have this repeated communication N times per day: client server --X--> <--Y-- the client puts in X a message A of 1 byte or B of 1024 bytes, and pads it to the maximum size of TLS record. The server replies with the message "ok" (same every time), padded to the maximum size just after it reads X. However, TLS 1.3 detects the message size by iterating through all the padding bytes, and thus there is a timing leak observed by the time difference between receiving X and sending Y. Thus as an adversary I could take enough measurements and be able to distinguish between X having the value A or B. While I'd expect these iterations to be unmeasurable in desktop or server hardware, I am not sure about the situation in low-end IoT hardware. Is the design choice for having the padding removal depending on padding length intentional? There is mentioning of possible timing channels in: https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 However I don't quite understand how is this section intended to be read. The sentence for example: "Because the padding is encrypted alongside the actual content, an attacker cannot directly determine the length of the padding, but may be able to measure it indirectly by the use of timing channels exposed during record processing", what is its intention? Is it to acknowledge the above timing leak? Shouldn't instead be guidance in section 'Implementation Pitfalls' on how to remove padding in a way that there are no timing leaks? (the timing leak here is not in crypto algorithms, but TLS itself). Ideally TLS 1.3 itself shouldn't use data-size depending calculations itself such as the one described here. regards, Nikos From nobody Fri Aug 11 08:17: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 85BEB132125 for ; Fri, 11 Aug 2017 08:17:34 -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 ikMW_CydK8YW for ; Fri, 11 Aug 2017 08:17: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 D5A4A1321A3 for ; Fri, 11 Aug 2017 08:17:31 -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 v7BFHQBa029703; Fri, 11 Aug 2017 16:17: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=a8q9dJQzI/SweFrVPMzt0BU4jam6XAYqaDpZLiYev6A=; b=bsrL0FPY7nXiCsS61XzEhJwGggFP2eGlxjkwL5tRXlhitCrxMij+HoyKgH/RWMNUU00B W0txjEv0Lw+PbmQAgtVAzA4Yhs2TzvDfBzK/KC2XOYMeT4CewtHXammEeu2OvTlhK50t 2p06AZVD6UEeNG1w7I/oWqnI0FEjFIKXtacZc/mBrNvCDdJBOUzwao1nz/WkOSZ+hr8T 1nzs6PTKFgH59fP+Fru4HxBsLAbYB5/LL9XEqPhnAXpGhBmY2ZPzss4y/3tSiIpM3lCU +LtWUMZAg9bcXyuuwVgZUto/LO0/o5PwI4vl4wNugCymzsrVIq3OKMNNTrG+hUyAYP5J ZQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2c8548qd2k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2017 16:17:29 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7BFFkKu021876; Fri, 11 Aug 2017 11:17:28 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c59bv8p1t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2017 11:17:28 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 11 Aug 2017 11:17:27 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Fri, 11 Aug 2017 11:17:27 -0400 From: "Short, Todd" To: Nikos Mavrogiannopoulos CC: "tls@ietf.org" Thread-Topic: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size Thread-Index: AQHTEqu4UDB35x1gLEG+JKMOxcPabqJ/h5iA Date: Fri, 11 Aug 2017 15:17:27 +0000 Message-ID: <075C47B6-A601-441F-B881-A7F78648B5F1@akamai.com> References: <1502460670.3202.8.camel@redhat.com> In-Reply-To: <1502460670.3202.8.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.244] Content-Type: multipart/alternative; boundary="_000_075C47B6A601441FB881A7F78648B5F1akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-11_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-1706020000 definitions=main-1708110244 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-11_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-1706020000 definitions=main-1708110244 Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 15:17:34 -0000 --_000_075C47B6A601441FB881A7F78648B5F1akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGFwcGxpY2F0aW9uIGNhbiBzb2x2ZSB0aGlzIGJ5IGhhdmluZyBpdHMgb3duIHBhZGRpbmcu IElmIGl04oCZcyBnb2luZyB0byBmb3JjZSBhbGwgbWVzc2FnZXMgdG8gYmUgcGFkZGVkIG91dCB0 byAxMDI0IGJ5dGVzIGJ5IFRMUywgd2h5IG5vdCBqdXN0IG1ha2UgdGhhdCBwYXJ0IG9mIHRoZSBh cHBsaWNhdGlvbiBwcm90b2NvbD8gSXRzIG5vdCBhcyB0aG91Z2ggaXTigJlzIHRyeWluZyB0byBz YXZlIGJ5dGVzIGhlcmUuDQotLQ0KLVRvZGQgU2hvcnQNCi8vIHRzaG9ydEBha2FtYWkuY29tPG1h aWx0bzp0c2hvcnRAYWthbWFpLmNvbT4NCi8vICJPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNl YSwgdGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiINCg0KT24gQXVnIDExLCAyMDE3LCBhdCAxMDox MSBBTSwgTmlrb3MgTWF2cm9naWFubm9wb3Vsb3MgPG5tYXZAcmVkaGF0LmNvbTxtYWlsdG86bm1h dkByZWRoYXQuY29tPj4gd3JvdGU6DQoNCkltYWdpbmUgdGhlIGZvbGxvd2luZyBzY2VuYXJpbywg d2hlcmUgdGhlIHNlcnZlciBhbmQgY2xpZW50IGhhdmUgdGhpcw0KcmVwZWF0ZWQgY29tbXVuaWNh dGlvbiBOIHRpbWVzIHBlciBkYXk6DQoNCmNsaWVudCAgICAgc2VydmVyDQogICAtLVgtLT4NCiAg IDwtLVktLQ0KDQoNCnRoZSBjbGllbnQgcHV0cyBpbiBYIGEgbWVzc2FnZSBBIG9mIDEgYnl0ZSBv ciBCIG9mIDEwMjQgYnl0ZXMsIGFuZCBwYWRzDQppdCB0byB0aGUgbWF4aW11bSBzaXplIG9mIFRM UyByZWNvcmQuIFRoZSBzZXJ2ZXIgcmVwbGllcyB3aXRoIHRoZQ0KbWVzc2FnZSAib2siIChzYW1l IGV2ZXJ5IHRpbWUpLCBwYWRkZWQgdG8gdGhlIG1heGltdW0gc2l6ZSBqdXN0IGFmdGVyDQppdCBy ZWFkcyBYLg0KDQpIb3dldmVyLCBUTFMgMS4zIGRldGVjdHMgdGhlIG1lc3NhZ2Ugc2l6ZSBieSBp dGVyYXRpbmcgdGhyb3VnaCBhbGwgdGhlDQpwYWRkaW5nIGJ5dGVzLCBhbmQgdGh1cyB0aGVyZSBp cyBhIHRpbWluZyBsZWFrIG9ic2VydmVkIGJ5IHRoZSB0aW1lDQpkaWZmZXJlbmNlIGJldHdlZW4g cmVjZWl2aW5nIFggYW5kIHNlbmRpbmcgWS4gVGh1cyBhcyBhbiBhZHZlcnNhcnkgSQ0KY291bGQg dGFrZSBlbm91Z2ggbWVhc3VyZW1lbnRzIGFuZCBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoIGJldHdl ZW4gWA0KaGF2aW5nIHRoZSB2YWx1ZSBBIG9yIEIuDQoNCldoaWxlIEknZCBleHBlY3QgdGhlc2Ug aXRlcmF0aW9ucyB0byBiZSB1bm1lYXN1cmFibGUgaW4gZGVza3RvcCBvcg0Kc2VydmVyIGhhcmR3 YXJlLCBJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBzaXR1YXRpb24gaW4gbG93LWVuZCBJb1QNCmhh cmR3YXJlLiBJcyB0aGUgZGVzaWduIGNob2ljZSBmb3IgaGF2aW5nIHRoZSBwYWRkaW5nIHJlbW92 YWwgZGVwZW5kaW5nDQpvbiBwYWRkaW5nIGxlbmd0aCBpbnRlbnRpb25hbD8NCg0KVGhlcmUgaXMg bWVudGlvbmluZyBvZiBwb3NzaWJsZSB0aW1pbmcgY2hhbm5lbHMgaW46DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtdGxzMTMtMjEjYXBwZW5kaXgtRS4zDQpIb3dl dmVyIEkgZG9uJ3QgcXVpdGUgdW5kZXJzdGFuZCBob3cgaXMgdGhpcyBzZWN0aW9uIGludGVuZGVk IHRvIGJlDQpyZWFkLiBUaGUgc2VudGVuY2UgZm9yIGV4YW1wbGU6ICJCZWNhdXNlIHRoZSBwYWRk aW5nIGlzIGVuY3J5cHRlZA0KYWxvbmdzaWRlIHRoZSBhY3R1YWwgY29udGVudCwgYW4gYXR0YWNr ZXIgY2Fubm90IGRpcmVjdGx5IGRldGVybWluZSB0aGUNCmxlbmd0aCBvZiB0aGUgcGFkZGluZywg YnV0IG1heSBiZSBhYmxlIHRvIG1lYXN1cmUgaXQgaW5kaXJlY3RseSBieSB0aGUNCnVzZSBvZiB0 aW1pbmcgY2hhbm5lbHMgZXhwb3NlZCBkdXJpbmcgcmVjb3JkIHByb2Nlc3NpbmciLCB3aGF0IGlz IGl0cw0KaW50ZW50aW9uPyBJcyBpdCB0byBhY2tub3dsZWRnZSB0aGUgYWJvdmUgdGltaW5nIGxl YWs/DQoNClllcywgSSBwcmVzdW1lIHNvLg0KDQoNCg0KU2hvdWxkbid0IGluc3RlYWQgYmUgZ3Vp ZGFuY2UgaW4gc2VjdGlvbiAnSW1wbGVtZW50YXRpb24gUGl0ZmFsbHMnIG9uDQpob3cgdG8gcmVt b3ZlIHBhZGRpbmcgaW4gYSB3YXkgdGhhdCB0aGVyZSBhcmUgbm8gdGltaW5nIGxlYWtzPyAodGhl DQp0aW1pbmcgbGVhayBoZXJlIGlzIG5vdCBpbiBjcnlwdG8gYWxnb3JpdGhtcywgYnV0IFRMUyBp dHNlbGYpLiBJZGVhbGx5DQpUTFMgMS4zIGl0c2VsZiBzaG91bGRuJ3QgdXNlIGRhdGEtc2l6ZSBk ZXBlbmRpbmcgY2FsY3VsYXRpb25zIGl0c2VsZg0Kc3VjaCBhcyB0aGUgb25lIGRlc2NyaWJlZCBo ZXJlLg0KDQpyZWdhcmRzLA0KTmlrb3MNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86 VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMN Cg0K --_000_075C47B6A601441FB881A7F78648B5F1akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhlIGFwcGxpY2F0aW9uIGNhbiBz b2x2ZSB0aGlzIGJ5IGhhdmluZyBpdHMgb3duIHBhZGRpbmcuIElmIGl04oCZcyBnb2luZyB0byBm b3JjZSBhbGwgbWVzc2FnZXMgdG8gYmUgcGFkZGVkIG91dCB0byAxMDI0IGJ5dGVzIGJ5IFRMUywg d2h5IG5vdCBqdXN0IG1ha2UgdGhhdCBwYXJ0IG9mIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbD8g SXRzIG5vdCBhcyB0aG91Z2ggaXTigJlzIHRyeWluZyB0byBzYXZlIGJ5dGVzIGhlcmUuPGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPi0tPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPi1Ub2RkIFNob3J0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8vIDxhIGhyZWY9 Im1haWx0bzp0c2hvcnRAYWthbWFpLmNvbSIgY2xhc3M9IiI+dHNob3J0QGFrYW1haS5jb208L2E+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8vICZxdW90O09uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkg c2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuJnF1b3Q7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEF1ZyAxMSwgMjAxNywgYXQgMTA6MTEgQU0sIE5p a29zIE1hdnJvZ2lhbm5vcG91bG9zICZsdDs8YSBocmVmPSJtYWlsdG86bm1hdkByZWRoYXQuY29t IiBjbGFzcz0iIj5ubWF2QHJlZGhhdC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5JbWFnaW5lIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW8sIHdoZXJlIHRoZSBzZXJ2ZXIgYW5k IGNsaWVudCBoYXZlIHRoaXM8YnIgY2xhc3M9IiI+DQpyZXBlYXRlZCBjb21tdW5pY2F0aW9uIE4g dGltZXMgcGVyIGRheTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpjbGllbnQgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7c2VydmVyPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 LS1YLS0mZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy0tWS0tPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KdGhlIGNsaWVudCBwdXRzIGlu IFggYSBtZXNzYWdlIEEgb2YgMSBieXRlIG9yIEIgb2YgMTAyNCBieXRlcywgYW5kIHBhZHM8YnIg Y2xhc3M9IiI+DQppdCB0byB0aGUgbWF4aW11bSBzaXplIG9mIFRMUyByZWNvcmQuIFRoZSBzZXJ2 ZXIgcmVwbGllcyB3aXRoIHRoZSA8YnIgY2xhc3M9IiI+DQptZXNzYWdlICZxdW90O29rJnF1b3Q7 IChzYW1lIGV2ZXJ5IHRpbWUpLCBwYWRkZWQgdG8gdGhlIG1heGltdW0gc2l6ZSBqdXN0IGFmdGVy PGJyIGNsYXNzPSIiPg0KaXQgcmVhZHMgWC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpI b3dldmVyLCBUTFMgMS4zIGRldGVjdHMgdGhlIG1lc3NhZ2Ugc2l6ZSBieSBpdGVyYXRpbmcgdGhy b3VnaCBhbGwgdGhlPGJyIGNsYXNzPSIiPg0KcGFkZGluZyBieXRlcywgYW5kIHRodXMgdGhlcmUg aXMgYSB0aW1pbmcgbGVhayBvYnNlcnZlZCBieSB0aGUgdGltZTxiciBjbGFzcz0iIj4NCmRpZmZl cmVuY2UgYmV0d2VlbiByZWNlaXZpbmcgWCBhbmQgc2VuZGluZyBZLiBUaHVzIGFzIGFuIGFkdmVy c2FyeSBJPGJyIGNsYXNzPSIiPg0KY291bGQgdGFrZSBlbm91Z2ggbWVhc3VyZW1lbnRzIGFuZCBi ZSBhYmxlIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gWDxiciBjbGFzcz0iIj4NCmhhdmluZyB0aGUg dmFsdWUgQSBvciBCLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldoaWxlIEknZCBleHBl Y3QgdGhlc2UgaXRlcmF0aW9ucyB0byBiZSB1bm1lYXN1cmFibGUgaW4gZGVza3RvcCBvcjxiciBj bGFzcz0iIj4NCnNlcnZlciBoYXJkd2FyZSwgSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgc2l0dWF0 aW9uIGluIGxvdy1lbmQgSW9UPGJyIGNsYXNzPSIiPg0KaGFyZHdhcmUuIElzIHRoZSBkZXNpZ24g Y2hvaWNlIGZvciBoYXZpbmcgdGhlIHBhZGRpbmcgcmVtb3ZhbCBkZXBlbmRpbmc8YnIgY2xhc3M9 IiI+DQpvbiBwYWRkaW5nIGxlbmd0aCBpbnRlbnRpb25hbD88YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGVyZSBpcyBtZW50aW9uaW5nIG9mIHBvc3NpYmxlIHRpbWluZyBjaGFubmVscyBp bjo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi10bHMtdGxzMTMtMjEjYXBwZW5kaXgtRS4zIiBjbGFzcz0iIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtdGxzMTMtMjEjYXBwZW5kaXgtRS4zPC9hPjxi ciBjbGFzcz0iIj4NCkhvd2V2ZXIgSSBkb24ndCBxdWl0ZSB1bmRlcnN0YW5kIGhvdyBpcyB0aGlz IHNlY3Rpb24gaW50ZW5kZWQgdG8gYmU8YnIgY2xhc3M9IiI+DQpyZWFkLiBUaGUgc2VudGVuY2Ug Zm9yIGV4YW1wbGU6ICZxdW90O0JlY2F1c2UgdGhlIHBhZGRpbmcgaXMgZW5jcnlwdGVkPGJyIGNs YXNzPSIiPg0KYWxvbmdzaWRlIHRoZSBhY3R1YWwgY29udGVudCwgYW4gYXR0YWNrZXIgY2Fubm90 IGRpcmVjdGx5IGRldGVybWluZSB0aGU8YnIgY2xhc3M9IiI+DQpsZW5ndGggb2YgdGhlIHBhZGRp bmcsIGJ1dCBtYXkgYmUgYWJsZSB0byBtZWFzdXJlIGl0IGluZGlyZWN0bHkgYnkgdGhlPGJyIGNs YXNzPSIiPg0KdXNlIG9mIHRpbWluZyBjaGFubmVscyBleHBvc2VkIGR1cmluZyByZWNvcmQgcHJv Y2Vzc2luZyZxdW90Oywgd2hhdCBpcyBpdHM8YnIgY2xhc3M9IiI+DQppbnRlbnRpb24/IElzIGl0 IHRvIGFja25vd2xlZGdlIHRoZSBhYm92ZSB0aW1pbmcgbGVhaz88YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+WWVzLCBJIHByZXN1bWUgc28uPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpTaG91bGRuJ3QgaW5zdGVhZCBi ZSBndWlkYW5jZSBpbiBzZWN0aW9uICdJbXBsZW1lbnRhdGlvbiBQaXRmYWxscycgb248YnIgY2xh c3M9IiI+DQpob3cgdG8gcmVtb3ZlIHBhZGRpbmcgaW4gYSB3YXkgdGhhdCB0aGVyZSBhcmUgbm8g dGltaW5nIGxlYWtzPyAodGhlPGJyIGNsYXNzPSIiPg0KdGltaW5nIGxlYWsgaGVyZSBpcyBub3Qg aW4gY3J5cHRvIGFsZ29yaXRobXMsIGJ1dCBUTFMgaXRzZWxmKS4gSWRlYWxseTxiciBjbGFzcz0i Ij4NClRMUyAxLjMgaXRzZWxmIHNob3VsZG4ndCB1c2UgZGF0YS1zaXplIGRlcGVuZGluZyBjYWxj dWxhdGlvbnMgaXRzZWxmPGJyIGNsYXNzPSIiPg0Kc3VjaCBhcyB0aGUgb25lIGRlc2NyaWJlZCBo ZXJlLiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpyZWdhcmRzLDxiciBjbGFzcz0iIj4N Ck5pa29zPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpUTFMgbWFpbGluZyBsaXN0 PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgY2xhc3M9IiI+VExT QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_075C47B6A601441FB881A7F78648B5F1akamaicom_-- From nobody Fri Aug 11 08:39: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 643471323D7 for ; Fri, 11 Aug 2017 08:39:27 -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 wZKkd7CKKGJu for ; Fri, 11 Aug 2017 08:39:25 -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 A49E0132360 for ; Fri, 11 Aug 2017 08:39:25 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id d136so22436645qkg.3 for ; Fri, 11 Aug 2017 08:39: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=8DKnONLRHU5U3pZCwyepKVJlh0ct31GO6nC7iDe9u0A=; b=acGDKH7xSbD+QqdDsPLuj0UaP61J38fjQUO9VF1XNdoznjs0GxJo95P/CYqPYMfBiG JgcyY+R9jgVNaZUfBGdCh2PaH3l5KVhKUFtQAqtjobrIF2MxD2DTUBMpRZeolIoO1NiD 28YxVHb4t+sVktfF20uMfM6k0jNI7CgquGMUhkO9gqfcOgq+6oy0NuEV/gyMgcPJnhdS CkGUefOwPERI4xnImm8PlPALZJ6dxU6niDkLZHHikl0PcvUbrSQlOO4+plOPXfPydkug O6zyVpwrzU2b9dAKrj3y4JZKfuS7bsHYHtT9F6uQE5x0xm2adVwz2kn3aJz2jTP9MLKd EMhw== 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=8DKnONLRHU5U3pZCwyepKVJlh0ct31GO6nC7iDe9u0A=; b=Rlgodo8wkQ4zOAfi3S63IFs2W0mr8awkzfRROljiy2N3dxQVjxyhQp0Y0Hlc+2cgF8 CnEx7QVITSA6kdgpZb+kOJtyZhXwGfDGRI8T0a8wsk8Pa7t+eyu6QB52cC6Z6hde4YAq e9WaB7c+ZnzjuHzJ7EH+m0urU16UFNFdQUJT1n5Y4Hf5BDN5vps2dqkfKAQBdv1eiMyj JJYGar4JhQD4Z1+8Yv0ZtclQGUwDtwr2nSUdGe81fZg6WAN7+hdmKmtDP3g5mdYHKM0k rcO41bEdN5dkLJjBW8XHwrhzWRqvWT+qRntvSUcl5lpKKU2nuMAkG5Tct9iY0vMp+cIr tq4g== X-Gm-Message-State: AHYfb5jdBgbD61L3muZHn3ZH6BQnNHdExgJDLXaPoCI8ONkcoTpS/GOr m0VzcfTB8SW96vGVv3bkgQ== X-Received: by 10.55.58.130 with SMTP id h124mr15880563qka.192.1502465964857; Fri, 11 Aug 2017 08:39:24 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id q53sm741986qte.35.2017.08.11.08.39.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 08:39:23 -0700 (PDT) From: Ted Lemon Message-Id: <4DDA22F3-A859-48AF-A94D-4EC8F5555E64@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7965DCC0-900D-46ED-A5AD-F4C66EC45642" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 11 Aug 2017 11:39:23 -0400 In-Reply-To: <075C47B6-A601-441F-B881-A7F78648B5F1@akamai.com> Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" To: "Short, Todd" References: <1502460670.3202.8.camel@redhat.com> <075C47B6-A601-441F-B881-A7F78648B5F1@akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 15:39:27 -0000 --Apple-Mail=_7965DCC0-900D-46ED-A5AD-F4C66EC45642 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 11, 2017, at 11:17 AM, Short, Todd wrote: > The application can solve this by having its own padding. If it=E2=80=99= s going to force all messages to be padded out to 1024 bytes by TLS, why = not just make that part of the application protocol? Its not as though = it=E2=80=99s trying to save bytes here. The downside to this is that now you have to get it right in each = protocol that does it, instead of getting it right once. --Apple-Mail=_7965DCC0-900D-46ED-A5AD-F4C66EC45642 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 11, 2017, at 11:17 AM, Short, Todd <tshort@akamai.com> = wrote:
The application can solve this = by having its own padding. If it=E2=80=99s going to force all messages = to be padded out to 1024 bytes by TLS, why not just make that part of = the application protocol? Its not as though it=E2=80=99s trying to save = bytes here.

The downside to this is that now you have to get it right in = each protocol that does it, instead of getting it right once.

= --Apple-Mail=_7965DCC0-900D-46ED-A5AD-F4C66EC45642-- From nobody Fri Aug 11 08:58: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 5F14E127601 for ; Fri, 11 Aug 2017 08:58:41 -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 KwfDNK8bUUbx for ; Fri, 11 Aug 2017 08:58: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 6983713201A for ; Fri, 11 Aug 2017 08:58:39 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l82so24688454ywc.2 for ; Fri, 11 Aug 2017 08:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+G23g2pGx5brUoYS80MDZR7UkPGWBO5WXkuQb3eaITo=; b=pw2s2nJ92ekE8D9QhdWMut7RtRy5TqlBEwHfyv9gNOy//aNMTmgaYSVZIRhs4/cvzB meE6HZpQ+rnhyxuP4cWXKsmC1/QIa2nV8JaPphm9fWw+fR0W3j3nhIJ5y51QmXi//nlf Y8sl3/206sYgvZcFB0IqmzpAmLRjSI212SbZ5WKBgVkEnWVrHAIMsXgMyTdx1wpLLU1Q IGOhhKHpYM0K9ySvr5VFZCzz8Ig3bVvJrVo4kU320PyaS6Qz7nsMo+9fQmE3UWKkoBcI s/57FTeLGZUz+gAJoCCncoa8fXVeBESC45/KQQP6XdNUID/pyu+18+WcWoHuxRgtHvcV cVEw== 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=+G23g2pGx5brUoYS80MDZR7UkPGWBO5WXkuQb3eaITo=; b=evGUgN41OTxj6kV62AtprZXh7lvqm+kIhZ2S9mYSD6c6J7yHvCs7caQw0mrIN6DPqt HiAEiod5aKzaNdEMfiajDvZgRLTtBNMakFLE/WlyVPxh3eUlpPqSeB78U0Dhdg1y/cYh odqiX1T0gVWAcJR6FokzOHuCp6iNgMqLyajqDyYW4TCNYukOVr084DVru+xhc/ZMIyP2 gK12TGNLNHNVXvj9Og36YBqDo7qjCU2REPHIrNFMz3TjIInOuUZAtVU5Tao+pG+ze0CR yYRSJtLSgKBYewkVMJOyI+/ijJelNYhqdp9mhH3tBgrfRmwxMF1PV9yDDHUc+g09jJND bl3A== X-Gm-Message-State: AHYfb5g5khyHT1Hv5z/nFwetnA5uiLrCeia4QyPtzLObU1iHbIB5G9rd 9HlOYuZbEBAHd94uzObjamC2UP98DEsS X-Received: by 10.37.248.12 with SMTP id u12mr12848436ybd.248.1502467118650; Fri, 11 Aug 2017 08:58:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 11 Aug 2017 08:57:58 -0700 (PDT) In-Reply-To: <1502460670.3202.8.camel@redhat.com> References: <1502460670.3202.8.camel@redhat.com> From: Eric Rescorla Date: Fri, 11 Aug 2017 08:57:58 -0700 Message-ID: To: Nikos Mavrogiannopoulos Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045db866e5234805567c62ed" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 15:58:41 -0000 --f403045db866e5234805567c62ed Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos wrote: > Imagine the following scenario, where the server and client have this > repeated communication N times per day: > > client server > --X--> > <--Y-- > > > the client puts in X a message A of 1 byte or B of 1024 bytes, and pads > it to the maximum size of TLS record. The server replies with the > message "ok" (same every time), padded to the maximum size just after > it reads X. > > However, TLS 1.3 detects the message size by iterating through all the > padding bytes, and thus there is a timing leak observed by the time > difference between receiving X and sending Y. Thus as an adversary I > could take enough measurements and be able to distinguish between X > having the value A or B. > > While I'd expect these iterations to be unmeasurable in desktop or > server hardware, I am not sure about the situation in low-end IoT > hardware. Is the design choice for having the padding removal depending > on padding length intentional? Yes, we're aware of this, and it's an intentional design choice. The reasoning was that once you have the padding removed, you'll need to operate on/copy the unpadded content somewhere, and that's timing dependent anyway. > There is mentioning of possible timing channels in: > https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 > However I don't quite understand how is this section intended to be > read. The sentence for example: "Because the padding is encrypted > alongside the actual content, an attacker cannot directly determine the > length of the padding, but may be able to measure it indirectly by the > use of timing channels exposed during record processing", what is its > intention? Is it to acknowledge the above timing leak? > Yes. -Ekr > Shouldn't instead be guidance in section 'Implementation Pitfalls' on > how to remove padding in a way that there are no timing leaks? (the > timing leak here is not in crypto algorithms, but TLS itself). Ideally > TLS 1.3 itself shouldn't use data-size depending calculations itself > such as the one described here. > > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403045db866e5234805567c62ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos = <nmav@redhat.com> wrote:
Imagine the following= scenario, where the server and client have this
repeated communication N times per day:

client=C2=A0 =C2=A0 =C2=A0server
=C2=A0 =C2=A0 --X-->
=C2=A0 =C2=A0 <--Y--


the client puts in X a message A of 1 byte or B of 1024 bytes, and pads
it to the maximum size of TLS record. The server replies with the
message "ok" (same every time), padded to the maximum size just a= fter
it reads X.

However, TLS 1.3 detects the message size by iterating through all the
padding bytes, and thus there is a timing leak observed by the time
difference between receiving X and sending Y. Thus as an adversary I
could take enough measurements and be able to distinguish between X
having the value A or B.

While I'd expect these iterations to be unmeasurable in desktop or
server hardware, I am not sure about the situation in low-end IoT
hardware. Is the design choice for having the padding removal depending
on padding length intentional?

Yes, we'= re aware of this, and it's an intentional design choice. The reasoning<= /div>
was that once you have the padding removed, you'll need to op= erate on/copy
the unpadded content somewhere, and that's timi= ng dependent anyway.



There is mentioning of possible timing channels in:
https://tools.ietf.org/html/dra= ft-ietf-tls-tls13-21#appendix-E.3
However I don't quite understand how is this section intended to be
read. The sentence for example: "Because the padding is encrypted
alongside the actual content, an attacker cannot directly determine the
length of the padding, but may be able to measure it indirectly by the
use of timing channels exposed during record processing", what is its<= br> intention? Is it to acknowledge the above timing leak?

Yes.

-Ekr
=C2=A0
Shouldn't instead be guidance in section &= #39;Implementation Pitfalls' on
how to remove padding in a way that there are no timing leaks? (the
timing leak here is not in crypto algorithms, but TLS itself). Ideally
TLS 1.3 itself shouldn't use data-size depending calculations itself such as the one described here.

=C2=A0<= /div>

regards,
Nikos

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

--f403045db866e5234805567c62ed-- From nobody Fri Aug 11 09:43: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 ED239132125 for ; Fri, 11 Aug 2017 09:43:19 -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 v0Qcb2pSQqxs for ; Fri, 11 Aug 2017 09:43:17 -0700 (PDT) Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com [209.85.128.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCFF131D22 for ; Fri, 11 Aug 2017 09:43:17 -0700 (PDT) Received: by mail-wr0-f180.google.com with SMTP id 33so15263110wrz.4 for ; Fri, 11 Aug 2017 09:43:17 -0700 (PDT) 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=g014CJT9jj5U3NJ8z5ovsKHPIvLRqrL1AV6F7VEt4wo=; b=odKJ1T+o5MnhcTjfZhzEHiv+60H/8KRUysp1voaw4Tht3EoxuAIx53V1YiepiY0qsQ T5BZB1AFoElnLs0NIUUV5jAwjcrKkwZqvephFHj55t7cQN7SzTclEckWF09u46qzigE/ aeRQ2L1sxiS5S4dUTWweQi/FWKm3bDVz19kG17X7AU+LvUlzE9OGnHXHd8PiGG5GKx1t q2yOkB3+niGkABTttq2ohG+Nt/a8Z7dqIlwYCdtd9iauRsyvSWTdqJaWcWlQAJvEWfCu bE8dWoCKqpZ9UtuXC2QIeiT1dRX3FmkO5bnwVOrSA+ACEA+BOqNuChLvwxHbGkucyhj4 lqPA== X-Gm-Message-State: AHYfb5hhycY+dnnEs/zltWuK0+zZRhf6h56jvdiKMCyIg3xoWm8Hj0oA 5m/QKP8WKrTbQHUeclg/UctPqLopgHut X-Received: by 10.223.181.10 with SMTP id a10mr12974770wrd.239.1502469795964; Fri, 11 Aug 2017 09:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.24.213 with HTTP; Fri, 11 Aug 2017 09:43:15 -0700 (PDT) In-Reply-To: <075C47B6-A601-441F-B881-A7F78648B5F1@akamai.com> References: <1502460670.3202.8.camel@redhat.com> <075C47B6-A601-441F-B881-A7F78648B5F1@akamai.com> From: Nikos Mavrogiannopoulos Date: Fri, 11 Aug 2017 18:43:15 +0200 Message-ID: To: "Short, Todd" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cd1a879813e05567d0209" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 16:43:20 -0000 --94eb2c1cd1a879813e05567d0209 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 11, 2017 at 5:17 PM, Short, Todd wrote: > The application can solve this by having its own padding. If it=E2=80=99s= going to > force all messages to be padded out to 1024 bytes by TLS, why not just ma= ke > that part of the application protocol? Its not as though it=E2=80=99s try= ing to > save bytes here. > I don't argue with this but this is not the approach TLS 1.3 took. It provides a generic padding mechanism to be used across application protocols. regards, Nikos --94eb2c1cd1a879813e05567d0209 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 11, 2017 at 5:17 PM, Short, Todd <tshort@akam= ai.com> wrote:
The application can solve this by having its own padding. If it=E2=80=99s g= oing to force all messages to be padded out to 1024 bytes by TLS, why not j= ust make that part of the application protocol? Its not as though it=E2=80= =99s trying to save bytes here.

I= don't argue with this but this is not the approach TLS 1.3 took. It pr= ovides a generic padding mechanism to be used across application protocols.=

regards,
Nikos

--94eb2c1cd1a879813e05567d0209-- From nobody Fri Aug 11 09:47: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 3B3BF131EA9 for ; Fri, 11 Aug 2017 09:47:06 -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, HTML_MESSAGE=0.001, 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 oQxvUJVNuDHN for ; Fri, 11 Aug 2017 09:47:03 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B1A13242C for ; Fri, 11 Aug 2017 09:47:03 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id m85so45867651wma.0 for ; Fri, 11 Aug 2017 09:47:03 -0700 (PDT) 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=7Nm0J1qfbou/CEE/TDDG9RvtxfqSoyF3Vw03sBJ4mWg=; b=K2zz5Q9cvZ+wU9xbJFPNQxTA4Be5vN0/00T+mo26G5GCyI5ATH4dc55IXA/Cu6OVVt Iocmle04xOVfDrUjGJdgTxl2qBbmDpccCc77lczinMPSg700NylnYhsRLhLzXWxOO9PS i34dfJYb7UCZPCvGpXLbtSTBXAUxNqQYXKcDqwmCcj+GARFlyHe65i/FNUOeIGgUwVNF mDeSqHqIW75oX+5gsvqLh4slV0SzP726+SI/QqwvDl69twtA91cX+PPT860+YhKFVlKX pj2Tgc837W3UQ59NaIuaPeWp0obQlJ6uay0Y1INfm89TLPb4QflXdQMd4t/6Shr93dpH WQ7Q== X-Gm-Message-State: AHYfb5i6GR17CMIR0+VQfedWl3gNesgGjm+0Yb6Ej+pxk3Cec2uUSY8+ FUbnpvETVAHAFcIpfktrHJbo4kPpLi/QRq8= X-Received: by 10.28.5.193 with SMTP id 184mr10426438wmf.108.1502470021838; Fri, 11 Aug 2017 09:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.24.213 with HTTP; Fri, 11 Aug 2017 09:47:01 -0700 (PDT) In-Reply-To: References: <1502460670.3202.8.camel@redhat.com> From: Nikos Mavrogiannopoulos Date: Fri, 11 Aug 2017 18:47:01 +0200 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114435b8f0340a05567d0fc6" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 16:47:06 -0000 --001a114435b8f0340a05567d0fc6 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 5:57 PM, Eric Rescorla wrote: > > On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos > wrote: > >> Imagine the following scenario, where the server and client have this >> repeated communication N times per day: >> >> client server >> --X--> >> <--Y-- >> >> >> the client puts in X a message A of 1 byte or B of 1024 bytes, and pads >> it to the maximum size of TLS record. The server replies with the >> message "ok" (same every time), padded to the maximum size just after >> it reads X. >> >> However, TLS 1.3 detects the message size by iterating through all the >> padding bytes, and thus there is a timing leak observed by the time >> difference between receiving X and sending Y. Thus as an adversary I >> could take enough measurements and be able to distinguish between X >> having the value A or B. >> >> While I'd expect these iterations to be unmeasurable in desktop or >> server hardware, I am not sure about the situation in low-end IoT >> hardware. Is the design choice for having the padding removal depending >> on padding length intentional? > > > Yes, we're aware of this, and it's an intentional design choice. The > reasoning > was that once you have the padding removed, you'll need to operate on/copy > the unpadded content somewhere, and that's timing dependent anyway. > That is certainly an incorrect assumption. gnutls for example provides a zero-copy API, and I guess it is not the only implementation to have that. > > >> There is mentioning of possible timing channels in: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 >> However I don't quite understand how is this section intended to be >> read. The sentence for example: "Because the padding is encrypted >> alongside the actual content, an attacker cannot directly determine the >> length of the padding, but may be able to measure it indirectly by the >> use of timing channels exposed during record processing", what is its >> intention? Is it to acknowledge the above timing leak? >> > > Yes. > I am not sure if that text is sufficient to cover that issue. It seems as if the cbc timing attack is re-introduced here and pushing the fix to implementers. It may be better no to provide padding functionality with this "feature", as unfortunately it will be used by applications. regards, Nikos --001a114435b8f0340a05567d0fc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 11, 2017 at 5:57 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>

On Fri, Aug 11, 2017 at = 7:11 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Imagine the following scenario, where the ser= ver and client have this
repeated communication N times per day:

client=C2=A0 =C2=A0 =C2=A0server
=C2=A0 =C2=A0 --X-->
=C2=A0 =C2=A0 <--Y--


the client puts in X a message A of 1 byte or B of 1024 bytes, and pads
it to the maximum size of TLS record. The server replies with the
message "ok" (same every time), padded to the maximum size just a= fter
it reads X.

However, TLS 1.3 detects the message size by iterating through all the
padding bytes, and thus there is a timing leak observed by the time
difference between receiving X and sending Y. Thus as an adversary I
could take enough measurements and be able to distinguish between X
having the value A or B.

While I'd expect these iterations to be unmeasurable in desktop or
server hardware, I am not sure about the situation in low-end IoT
hardware. Is the design choice for having the padding removal depending
on padding length intentional?

Yes, = we're aware of this, and it's an intentional design choice. The rea= soning
was that once you have the padding removed, you'll nee= d to operate on/copy
the unpadded content somewhere, and that'= ;s timing dependent anyway.

That is certainly an incorrect assumption. gnutls for example prov= ides a zero-copy API, and I guess it is not the only implementation to have= that.
=C2=A0


There is mentioning of possible timing channels in:
https://tools.ietf.org/html/dra= ft-ietf-tls-tls13-21#appendix-E.3
However I don't quite understand how is this section intended to be
read. The sentence for example: "Because the padding is encrypted
alongside the actual content, an attacker cannot directly determine the
length of the padding, but may be able to measure it indirectly by the
use of timing channels exposed during record processing", what is its<= br> intention? Is it to acknowledge the above timing leak?

Yes.

I am not sure if that text is sufficient to cover that issue. It s= eems as if the cbc timing attack is re-introduced here and pushing the fix = to implementers. It may be better no to provide padding functionality with = this "feature", as unfortunately it will be used by applications.=
=C2=A0
regards,
Nikos

--001a114435b8f0340a05567d0fc6-- From nobody Fri Aug 11 10:04: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 3937512711B for ; Fri, 11 Aug 2017 10:04:10 -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_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 CAynofo9Bo53 for ; Fri, 11 Aug 2017 10:04:07 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0134.outbound.protection.outlook.com [104.47.42.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 77FF01321BB for ; Fri, 11 Aug 2017 10:04:07 -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=DNZvSTrDzbYMxZ60SHNrpgg5BoIEdZETA6jQ9IS/Z9Y=; b=dJkaIsk+BzC3GOnzMM2+pkLcITubLKTofilKD9z45ONGF/5DluNO3gvYBwIpSnDkPz8AMZNnkjJ32he6HNX2vYzvwfGgGgJ+N3DB8JeYvnhWVAxPnQ/4h08JJ5oAH1Mf9oM8ws2U7yLyr+2cwThsgsGMuUCMojT7vdBOezYGxn4= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0028.namprd21.prod.outlook.com (10.161.140.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.3; Fri, 11 Aug 2017 17:04:05 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::bd51:190c:183c:e9]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::bd51:190c:183c:e9%13]) with mapi id 15.01.1362.012; Fri, 11 Aug 2017 17:04:05 +0000 From: Andrei Popov To: Nikos Mavrogiannopoulos , "Short, Todd" CC: "tls@ietf.org" Thread-Topic: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size Thread-Index: AQHTEqu6d1uODXFnckaUfIvCR1w2JqJ/RIqAgAAX+YCAAAQzkA== Date: Fri, 11 Aug 2017 17:04:05 +0000 Message-ID: References: <1502460670.3202.8.camel@redhat.com> <075C47B6-A601-441F-B881-A7F78648B5F1@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:3::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0028; 6:Ijn6Z5q5opRKqIwFtP/geLiFjzEAX6xbfFVzBQfyCCOYTROjfVrfM2vcoFUjFrkS4qJNAs1TTrCiTqY8J5MtgA//LsWS7my2YG2OQRlnTtdH3+V9M/rTUuRjPql1d8cNP0AR0N8zlyBVOL16dtvpFEoYIKGwcFzIrX13Kz4B63uEXpX3Usq7rscPEWspsVCZsLgMLKtTTi0xzCgt7JPHsD+hCVVB9NqaMEwlzQ7FfSN1dFrnTPyC/9wP1F2AcZITdF/z5eGclD/ZglWCBFiZhWHuAJTgKfmK+1aaOTYOVzrI71g43pHBPhK3y0FHyKZfgZLyq2u6ZKMymGgWZR0RZA==; 5:e1GF6qCq9WMDfTUKnc7gMEJxkWYqJ5ec2+ltlwEhE3yPPPbG+7yby147dmrh/HjS+1Z+2NKV3C1HRkbBKJ6Cq5HZzKC6B9Dudk7i558d7D2K6IR3ptFIJbl2Kf95mwxzRp7eszqF5DU2tzL4pZUuVQ==; 24:UBmP2tQ7eXB4ZopSNJj3xyhPwJl5BVldl29HUwVj5F+Ep1uyUoG2LDtFguMwHx+ow1hbOfgttsNvh5djlO79+LR/B9E3Il9K8V+rRL8wmEo=; 7:38T3bB6j4fMESfXiM6S6d/Jo1SyQ/S7Jc3xwCGe6bmZQzF4s146Oq+mIUS+AxcAqeHrfst3iReaxMv/Chvm1Nqcf2YXeuRC+JrjoSiHLou1NMASxiHHx1QqK9QwgtQheFDxN7Iw2mjsUebMaX1TyQAqX8qcl6kLV0aQZ7qaAdp0XxMEZ/SU4w7CpYJaHfRqBQtjntwGj+WHXI+0HZLVop7oRAo7Z4zk7PZFmO75zj1Q= x-ms-office365-filtering-correlation-id: 21706dc1-710a-4b61-0705-08d4e0daf93b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603137)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR21MB0028; x-ms-traffictypediagnostic: DM2PR21MB0028: 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)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0028; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0028; x-forefront-prvs: 03965EFC76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(199003)(189002)(8676002)(81166006)(81156014)(10290500003)(8990500004)(105586002)(189998001)(7736002)(68736007)(8936002)(5250100002)(33656002)(2900100001)(72206003)(5660300001)(2906002)(478600001)(229853002)(6506006)(5005710100001)(6246003)(7696004)(106356001)(86362001)(50986999)(102836003)(76176999)(6436002)(6116002)(2950100002)(790700001)(101416001)(99286003)(54356999)(25786009)(55016002)(9686003)(53936002)(6306002)(86612001)(54896002)(14454004)(3660700001)(3280700002)(10090500001)(4326008)(97736004)(230783001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0028; H:DM2PR21MB0091.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_DM2PR21MB0091750568F7FDBF1939F7B88C890DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2017 17:04:05.3548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0028 Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 17:04:10 -0000 --_000_DM2PR21MB0091750568F7FDBF1939F7B88C890DM2PR21MB0091namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBkb24ndCBhcmd1ZSB3aXRoIHRoaXMgYnV0IHRoaXMgaXMgbm90IHRoZSBhcHByb2Fj aCBUTFMgMS4zIHRvb2suIEl0IHByb3ZpZGVzIGEgZ2VuZXJpYyBwYWRkaW5nIG1lY2hhbmlzbSB0 byBiZSB1c2VkIGFjcm9zcyBhcHBsaWNhdGlvbiBwcm90b2NvbHMuDQpBdCBzb21lIHBvaW50IEkg dGhvdWdodCB3ZSBzYWlkIHRoYXQgdGhlIFRMUyAxLjMgcGFkZGluZyBtZWNoYW5pc20gd2FzIHN1 cHBvc2VkIHRvIGJlIGFwcGxpY2F0aW9uLWRyaXZlbiAoaW4gdGhlIGZvcm0gb2YgYXBwbGljYXRp b24tcHJvdmlkZWQgcG9saWN5IG9yIHNpbXBseSBkZXNpcmVkIHBhZCBzaXplKSwgd2hpY2ggd291 bGQgbWVhbiB0aGF0IHRoZSBhcHBsaWNhdGlvbiBoYXMgdG8gYmUgaW52b2x2ZWQgYW55d2F5Lg0K DQpDaGVlcnMsDQoNCkFuZHJlaQ0K --_000_DM2PR21MB0091750568F7FDBF1939F7B88C890DM2PR21MB0091namp_ 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 YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyOTQ3NTU3Njk7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTExOTgxNTI0IC0xMTM4OTc2MTAg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0 Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkkgZG9uJ3QgYXJndWUgd2l0aCB0aGlzIGJ1 dCB0aGlzIGlzIG5vdCB0aGUgYXBwcm9hY2ggVExTIDEuMyB0b29rLiBJdCBwcm92aWRlcyBhIGdl bmVyaWMgcGFkZGluZyBtZWNoYW5pc20gdG8gYmUgdXNlZCBhY3Jvc3MgYXBwbGljYXRpb24gcHJv dG9jb2xzLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgc29t ZSBwb2ludCBJIHRob3VnaHQgd2Ugc2FpZCB0aGF0IHRoZSBUTFMgMS4zIHBhZGRpbmcgbWVjaGFu aXNtIHdhcyBzdXBwb3NlZCB0byBiZSBhcHBsaWNhdGlvbi1kcml2ZW4gKGluIHRoZSBmb3JtIG9m IGFwcGxpY2F0aW9uLXByb3ZpZGVkIHBvbGljeSBvciBzaW1wbHkgZGVzaXJlZCBwYWQgc2l6ZSks IHdoaWNoIHdvdWxkIG1lYW4gdGhhdCB0aGUgYXBwbGljYXRpb24gaGFzIHRvIGJlIGludm9sdmVk IGFueXdheS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbmRyZWk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM2PR21MB0091750568F7FDBF1939F7B88C890DM2PR21MB0091namp_-- From nobody Fri Aug 11 10:21: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 EEC94132461 for ; Fri, 11 Aug 2017 10:21:07 -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 DdZ3QnocrO2o for ; Fri, 11 Aug 2017 10:21:06 -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 1011513252D for ; Fri, 11 Aug 2017 10:21:06 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id u207so26093336ywc.3 for ; Fri, 11 Aug 2017 10:21: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=xm0ac41mIax2dzhQ19wzP0aCXUutgYBidvM2TPHni+g=; b=pZvASXzceArzbMfTO7fr93rKaLXZmf6EqY18BxHHvlQs0OpZjxVdSOdHfe08RdMiz+ QXaVqzc8mNjNFfqsVlFhszosC1lDVsExjDurTwXxOFwJcK8FSUvb2j33w5i5o2RdwZTi DTtAF+wEh5NTvSVJzNkkNhdWvpxeUlpSHnS5VTWd4xsR9x6Bw7WpjImUI01VsZgZz5Ru 6wrX3H+fsiyH23qQkfuPO9RTiox/qgkpeOeRdFzPqOk7AOfqwb3RlP4Mm5b5WQdaGHVs CUAFcrb02vsrncyl4Q1Iq3EyEHGuaZmou3p8yjlUulfm1waNiU2WtmMod+8yH0rnAPkm IfgQ== 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=xm0ac41mIax2dzhQ19wzP0aCXUutgYBidvM2TPHni+g=; b=thr6HcODBpBv+La24XXhXSnYZSWYVZQlSqJW343MThI+MsXDbsCGqqVcOJUWjJiEZ2 wikVgZfgXA1xcb4FhmlnFQFATY7wO41dDpfNEjf9O/30AySkt2FnO5zoZO7gFuTkT0Pr 9YszaqTvCd7Rlrrl2Kze+wea0vheEtxeEl+g1PbH5Th3DTxFjYaKo6z0AhDDuNVz5sKI HtBa2tUbhGpQtHm+PvfnLwdMgQwj13eH1qQyg3ZRFw8nXQWJji9Ub2iGIK65tYLwqfKo awrQn/TdOdwpXlsJnEKMwrXMcxy5yc2DDYlQXTLuahvyc+Pt+X+mUOkZuLwdSx44dwop dE6g== X-Gm-Message-State: AHYfb5hLQaHElIl79BdPQbf+2J99AetcHKzsDK5v/xEXbJ5AsaGt1VEX EwNUru6ygu2GdNwLdUTl9Q12tl/w6ETr X-Received: by 10.37.248.12 with SMTP id u12mr13068141ybd.248.1502472065300; Fri, 11 Aug 2017 10:21:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 11 Aug 2017 10:20:24 -0700 (PDT) In-Reply-To: References: <1502460670.3202.8.camel@redhat.com> From: Eric Rescorla Date: Fri, 11 Aug 2017 10:20:24 -0700 Message-ID: To: Nikos Mavrogiannopoulos Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045db866bd00c005567d8907" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 17:21:08 -0000 --f403045db866bd00c005567d8907 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 9:47 AM, Nikos Mavrogiannopoulos wrote: > On Fri, Aug 11, 2017 at 5:57 PM, Eric Rescorla wrote: > >> >> On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos > > wrote: >> >>> Imagine the following scenario, where the server and client have this >>> repeated communication N times per day: >>> >>> client server >>> --X--> >>> <--Y-- >>> >>> >>> the client puts in X a message A of 1 byte or B of 1024 bytes, and pads >>> it to the maximum size of TLS record. The server replies with the >>> message "ok" (same every time), padded to the maximum size just after >>> it reads X. >>> >>> However, TLS 1.3 detects the message size by iterating through all the >>> padding bytes, and thus there is a timing leak observed by the time >>> difference between receiving X and sending Y. Thus as an adversary I >>> could take enough measurements and be able to distinguish between X >>> having the value A or B. >>> >>> While I'd expect these iterations to be unmeasurable in desktop or >>> server hardware, I am not sure about the situation in low-end IoT >>> hardware. Is the design choice for having the padding removal depending >>> on padding length intentional? >> >> >> Yes, we're aware of this, and it's an intentional design choice. The >> reasoning >> was that once you have the padding removed, you'll need to operate on/copy >> the unpadded content somewhere, and that's timing dependent anyway. >> > > That is certainly an incorrect assumption. gnutls for example provides a > zero-copy API, and I guess it is not the only implementation to have that. > And then the next thing that will happen is that the application will read the data, which is length-dependent. The problem is that the plaintext is variable length. There is mentioning of possible timing channels in: >>> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 >>> However I don't quite understand how is this section intended to be >>> read. The sentence for example: "Because the padding is encrypted >>> alongside the actual content, an attacker cannot directly determine the >>> length of the padding, but may be able to measure it indirectly by the >>> use of timing channels exposed during record processing", what is its >>> intention? Is it to acknowledge the above timing leak? >>> >> >> Yes. >> > > I am not sure if that text is sufficient to cover that issue. It seems as > if the cbc timing attack is re-introduced here and pushing the fix to > implementers. It may be better no to provide padding functionality with > this "feature", as unfortunately it will be used by applications. > I don't believe that this is analysis is correct. This timing channel only applies to the data after message integrity has been established (i.e., after AEAD processing), which is different from the situation in Lucky 13. It seems like what leaks here is the length of the plaintext, which is also what would be leaked if we simply did not have padding. -Ekr > regards, > Nikos > > --f403045db866bd00c005567d8907 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 11, 2017 at 9:47 AM, Nikos Mavrogiannopoulos <nmav@redhat.co= m> wrote:
=
On F= ri, Aug 11, 2017 at 5:57 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>

On Fri, Aug 11, 2017 at 7:11 AM, Ni= kos Mavrogiannopoulos <nmav@redhat.com> wrote:
Imagine the following scenario, where the server and cli= ent have this
repeated communication N times per day:

client=C2=A0 =C2=A0 =C2=A0server
=C2=A0 =C2=A0 --X-->
=C2=A0 =C2=A0 <--Y--


the client puts in X a message A of 1 byte or B of 1024 bytes, and pads
it to the maximum size of TLS record. The server replies with the
message "ok" (same every time), padded to the maximum size just a= fter
it reads X.

However, TLS 1.3 detects the message size by iterating through all the
padding bytes, and thus there is a timing leak observed by the time
difference between receiving X and sending Y. Thus as an adversary I
could take enough measurements and be able to distinguish between X
having the value A or B.

While I'd expect these iterations to be unmeasurable in desktop or
server hardware, I am not sure about the situation in low-end IoT
hardware. Is the design choice for having the padding removal depending
on padding length intentional?

Yes, = we're aware of this, and it's an intentional design choice. The rea= soning
was that once you have the padding removed, you'll nee= d to operate on/copy
the unpadded content somewhere, and that'= ;s timing dependent anyway.

That is certainly an incorrect assumption. gnutls for examp= le provides a zero-copy API, and I guess it is not the only implementation = to have that.=C2=A0

And then the next thing that will happen is that the application will read= the data, which is length-dependent. The problem is that the plaintext is = variable length.


There is mentioning of possible timing channels in:
https://tools.ietf.org/html/dra= ft-ietf-tls-tls13-21#appendix-E.3
However I don't quite understand how is this section intended to be
read. The sentence for example: "Because the padding is encrypted
alongside the actual content, an attacker cannot directly determine the
length of the padding, but may be able to measure it indirectly by the
use of timing channels exposed during record processing", what is its<= br> intention? Is it to acknowledge the above timing leak?

Yes.

I am not sure if that text is sufficient to cover that issu= e. It seems as if the cbc timing attack is re-introduced here and pushing t= he fix to implementers. It may be better no to provide padding functionalit= y with this "feature", as unfortunately it will be used by applic= ations.

I don&#= 39;t believe that this is analysis is correct. This timing channel only app= lies to the data after message integrity has been established (i.e., after = AEAD processing), which is different from the situation in Lucky 13. It see= ms like what leaks here is the length of the plaintext, which is also what = would be leaked if we simply did not have padding.

-Ekr

<= div class=3D"gmail_extra">
=C2=A0=
regards,
Nikos


--f403045db866bd00c005567d8907-- From nobody Fri Aug 11 11:13: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 E4EF11321B6; Fri, 11 Aug 2017 11:13:53 -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 JjaVw1yjaoTe; Fri, 11 Aug 2017 11:13:51 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4967E131C9F; Fri, 11 Aug 2017 11:13:51 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id t128so19376444lff.2; Fri, 11 Aug 2017 11:13:51 -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; bh=aHwZ1Xf1nxZ4tJ5oVa/Y6/Y96umALD3fBh8Fx3zKxlA=; b=BaO7rs1qy3LhPjEkOt/f6nlkmRLtu5CrI/vz1S20KfdoZxJliq1YlIXkEuCk/7+Hwq 4HMwXPdPCASdiE69bRnde5r65BItgvbcusFesiFQk13r8a4j6G8ci/WR12FYr9DHGsiO 0apCeLK6VGR5UQs9P2TpcL+qSdkbPNC9noL3EPXr9ohp4xLI7ywwePBfwMlZ7L1rWR0e MCdBujpUGcioUuIOG6+C3PSg7O/d+Gskv/1ggXac2NhialetpxQkn90gPPALHygTxy7z UfAAurPyYA6KXvQ7VMiw3gRtXE2g4l5QdHmhi95QTx4Z1ICXWoXWU8OVu6fO5GG0a0EO AyLQ== 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; bh=aHwZ1Xf1nxZ4tJ5oVa/Y6/Y96umALD3fBh8Fx3zKxlA=; b=hCwtFp53kewc2XliC5ETNV4OKLfPuXoiYC5v+/C+jqqiNnQ0jIfkLP3nBEOanwa1VD Foagw+XPCY3CmhVbrVTxZkhptpNTQQcEPZHFtZO59WBfHlsaYv0rlBcZqQmOQ1Tv1tI9 ipMuG90gDDnIufV9vxlsatlAprnSU3ct8y9VGwy8O1UCVvGLDG+qtVDCwcUC8oGXSs6W qvM9iL0fC3EfcuDQGHJN1aZwr7DwrOKR+Zym0C4xS2avYr4Z4ePI+06WTCFowjsxu31C cCs3Ruli6I/j8YXMqQPAB7kyrp9RFAzuSdDXmZ+rpPDLJpQV4qNhk85cqJgRWEJdzp3r 8DJA== X-Gm-Message-State: AHYfb5gDebVK3+YvFLiQJ5EP6bQiN6Onsipm1sd94N4BEWDuV8lTrOtL TJ2Zyhb17T8jl+1Mi7SWt5hQW9C6OOEP X-Received: by 10.25.83.1 with SMTP id h1mr3600101lfb.183.1502475229451; Fri, 11 Aug 2017 11:13:49 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.18 with HTTP; Fri, 11 Aug 2017 11:13:48 -0700 (PDT) In-Reply-To: <150237598967.11871.16700348530940949770.idtracker@ietfa.amsl.com> References: <150237598967.11871.16700348530940949770.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Fri, 11 Aug 2017 14:13:48 -0400 X-Google-Sender-Auth: BLNzMTDH0P1B8diyArK9flf1CGg Message-ID: To: Eric Rescorla Cc: The IESG , tls , tls-chairs , draft-ietf-tls-ecdhe-psk-aead@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1cdc6e55d9b605567e4619" Archived-At: Subject: Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 18:13:54 -0000 --94eb2c1cdc6e55d9b605567e4619 Content-Type: text/plain; charset="UTF-8" Hi Eric, Thank you for reviewing the document. Given your second comment, I suspect you are reading the version 04 while the current version is version 05 [1]. I believe your comments have been addressed in the version 05.However let me know if you have other concerns. Regarding TLS1.3. we were asked to position the new code points toward TLS1.3, but I guess that was at the time the version was not indicated in the title, so in principle we could remove these references.I believe the text in version 05 address your comment, but here are the current version still cites TLS 1.3 in the following sections: - introduction: """AEAD algorithms that combine encryption and integrity protection are strongly recommended for (D)TLS [RFC7525 ] and non-AEAD algorithms are forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13 ]. """. Would you prefer to remove "and non-AEAD algorithms are forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13 ]" or it is fine to leave it as it is ? - section 3: """ Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to support equivalent functionality in TLS 1.3 [ I-D.ietf-tls-tls13 ]. """. Would you prefer to have all mentioned text being removed or is it fine to leave it as it is ? Regarding the reference to the PRF of TLS 1.1, I think it concerns the text below which has been removed in the version 05. """ [...] The PRF results from mixing the two pseudorandom streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK authentication, the PSK and pre-master are treated by distinct hash function with distinct properties. This may introduce vulnerabilities over the expected security provided by the constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK. The cipher suites defined in this document make use of the authenticated encryption with additional data (AEAD) defined in TLS 1.2 [RFC5246 ] and DTLS 1.2 [RFC6347 ]. Earlier versions of TLS do not have support for AEAD and consequently, the cipher suites defined in this document MUST NOT be negotiated in TLS versions prior to 1.2. In addition, it is worth noting that TLS 1.0 [RFC2246 ] and TL1.2 [RFC4346 ] splits the pre-master in two parts. The PRF results from mixing the two pseudorandom streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK authentication, the PSK and pre-master are treated by distinct hash function with distinct properties. This may introduce vulnerabilities over the expected security provided by the constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK. """ Yours, Daniel [1] https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05 On Thu, Aug 10, 2017 at 10:39 AM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-tls-ecdhe-psk-aead-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The citations to TLS 1.3 still seem pretty muddled. I think you > should just stop referencing and discussing 1.3. > > S 2. > I'm not sure that the discussion of the PRF is helpful here in > mandating the non-use of these cipher suites with TLS 1.1 and > below. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1cdc6e55d9b605567e4619 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Thank you for reviewing the do= cument. Given your second comment, I suspect you are reading the version 04= while the current version is version 05 [1]. I believe your comments have = been addressed in the version 05.However let me know if you have other conc= erns.

Regarding TLS1.3. we were asked to positi= on the new code points toward TLS1.3, but I guess that was at the time the version was not indicated=20 in the title, so in principle we could remove these references.I believe th= e text in version 05 address your comment, but here are the current version= still cites TLS 1.3 in the following sections:
  • introducti= on: """AEAD algorithms that combine encryption and integrity= protection are strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms are forbidden to use in TLS 1.3 [<= a href=3D"https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05#ref-= I-D.ietf-tls-tls13">I-D.ietf-tls-tls13]. """. Would you = prefer to remove "and non-AEAD algorithms are forbidden to use in TLS = 1.3 [I-D.ietf-tls-tls13]&qu= ot; or it is fine to leave it as it is ?
  • section 3: &quo= t;"" Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384= , TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to support e= quivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13= ]. """. Would you prefer to have all mentioned text being remov= ed or is it fine to leave it as it is ?

Regarding the reference= to the PRF of TLS 1.1, I think it concerns the text below which has been r= emoved in the version 05.

"""

   [...]  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and pre-master are treated by
   distinct hash function with distinct properties.  This may introduce
   vulnerabilities over the expected security provided by the
   constructed pre-master.  As such TLS 1.0 and TLS 1.1 should not be
   used with ECDHE_PSK.   The cipher suites defined in this document make u=
se of the
   authenticated encryption with additional data (AEAD) defined in TLS
   1.2 [RFC5246] and=
 DTLS 1.2 [RFC6347].  Earlier =
versions of TLS do not
   have support for AEAD and consequently, the cipher suites defined in
   this document MUST NOT be negotiated in TLS versions prior to 1.2.
   In addition, it is worth noting that TLS 1.0 [RF=
C2246] and TL1.2
   [RFC4346] splits =
the pre-master in two parts.  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and pre-master are treated by
   distinct hash function with distinct properties.  This may introduce
   vulnerabilities over the expected security provided by the
   constructed pre-master.  As such TLS 1.0 and TLS 1.1 should not be
   used with ECDHE_PSK.
"""

Yours, 
Daniel

[1] https://tools.ietf.org/html/draft-ietf-t=
ls-ecdhe-psk-aead-05

On Thu, Aug 10, =
2017 at 10:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Eric Rescorla has entered the fol=
lowing ballot position for

draft-ietf-tls-ecdhe-psk-aead-05: No Objection



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/<=
wbr>statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc=
/draft-ietf-tls-ecdhe-psk-aead/







-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



The citations to TLS 1.3 still seem pretty muddled. I think you

should just stop referencing and discussing 1.3. 



S 2.

I'm not sure that the discussion of the PRF is helpful here in

mandating the non-use of these cipher suites with TLS 1.1 and

below.



=C2=A0



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

--94eb2c1cdc6e55d9b605567e4619-- From nobody Fri Aug 11 11:33: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 9D0AF131C9F for ; Fri, 11 Aug 2017 11:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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_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 YYsNi1TKth6g for ; Fri, 11 Aug 2017 11:33:04 -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 6BDC6131CCF for ; Fri, 11 Aug 2017 11:33: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 v7BIWK6H009947; Fri, 11 Aug 2017 19:33:01 +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=NkZg3GoquYKGssT6lhGdhG7WaiS2pDXkW1vhQ2CQD9g=; b=BYt4HWLEiKYaBCmiGhdshMxVIMP7QblfCXmXwMH9r6W9JikXX7AOXQhgYzEvbLNV0dZD ths1GeE+98BcdCV9FjDGXAWULxVV5V6eSiRwUIA2vilX64wckcFt89ZbOBKjHIdkt4wy 5xkFnHC3xVsl3IklKgXg+KH1346LTItOaJCqT3Q8up7t+6rCWmWdOrqJPxeGJjnGqPqj oGw9tp4FQw/pSu5TyLMRFcW+YNjjRt+ZBD2hveyDW/XTZ0tJ6fQlfXgIedbIC4hm/b48 UavMTilrYNyTlfxFmgV2rG07d8JVoHnHAbwZlSiOYCbUkWq7HgJsvqcVjovOuQ1hRCaH Xg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2c7yd0rst3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2017 19:33:00 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7BIUxQD023655; Fri, 11 Aug 2017 14:32:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2c59bv9h52-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2017 14:32:59 -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; Fri, 11 Aug 2017 14:32:58 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Fri, 11 Aug 2017 14:32:58 -0400 From: "Short, Todd" To: Eric Rescorla CC: Nikos Mavrogiannopoulos , "tls@ietf.org" Thread-Topic: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size Thread-Index: AQHTEqu4UDB35x1gLEG+JKMOxcPabqJ/kuoAgAANtICAAAlUAIAAFEWA Date: Fri, 11 Aug 2017 18:32:57 +0000 Message-ID: <14329E27-DBCC-4A6F-BB4C-7CFAFD7ADF53@akamai.com> References: <1502460670.3202.8.camel@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.244] Content-Type: multipart/alternative; boundary="_000_14329E27DBCC4A6FBB4C7CFAFD7ADF53akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-11_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-1706020000 definitions=main-1708110289 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-11_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-1706020000 definitions=main-1708110290 Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 18:33:07 -0000 --_000_14329E27DBCC4A6FBB4C7CFAFD7ADF53akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlIHBsYWludGV4dCBsZW5ndGggaW5kaWNhdGVzIGEgbWVzc2FnZSB0eXBlLCB0aGVuIHRo aXMgY291bGQgbGVhZCB0byB0aGUgaXNzdWUgdGhlIG9yaWdpbmFsIHF1ZXJ5IHBvc3RlZC4gSW4g dGhhdCBhbiBvYnNlcnZlciBtaWdodCBrbm93IHdoYXQgbWVzc2FnZSB0eXBlIHdhcyBwYXNzZWQu IFRMUyBwYWRkaW5nIGlzIHN1cHBvc2VkIHRvIHByZXZlbnQgdGhpcyAoYnV0IGl0IGRvZXNu4oCZ dCBuZWNlc3NhcmlseSkuDQoNCkhvd2V2ZXIsIEkgYXJndWUgdGhhdCBoYXZpbmcgVExTIGRvIHNp Z25pZmljYW50IHBhZGRpbmcgZm9yIGEgcHJvdG9jb2wgaXMgYmFkIGRlc2lnbiBmb3IgdGhhdCBw cm90b2NvbC4gSXTigJlzIG9uZSB0aGluZyBpZiBpdOKAmXMgYSBmZXcgcGFkZGluZyBieXRlcywg YnV0IHRoZSBleGFtcGxlIGdpdmVuIHdhcyAxMDIzIGJ5dGVzIG9mIHBhZGRpbmcuDQoNCkFsc28g YXMgcG9pbnRlZCBvdXQgYnkgQW5kcmVpIFBvcG92LCB0aGUgYXBwbGljYXRpb24gbmVlZHMgdG8g dGVsbCBUTFMgaG93IG11Y2ggcGFkZGluZyB0byBhcHBseSwgc28gZWl0aGVyIHdheSwgdGhlIGFw cGxpY2F0aW9uIGhhcyB0byBkZWFsIHdpdGggZGV0ZXJtaW5pbmcgdGhlIHBhZGRpbmcgbGVuZ3Ro LiBXaHkgbm90IGp1c3QgbWFrZSBpdCBwYXJ0IG9mIHRoZSBwcm90b2NvbCBpbiB0aGUgZmlyc3Qg cGxhY2U/DQoNCk9wZW5TU0wgaGFzIGEgY2FsbGJhY2sgc2NoZW1lLCBhbmQgYSBibG9jay1iYXNl ZCBzY2hlbWUgZm9yIGRldGVybWluaW5nIHRoZSBhbW91bnQgb2YgcGFkZGluZy4gRWl0aGVyIHdh eSwgdGhlIGFwcGxpY2F0aW9uIGlzIGludm9sdmVkLg0KDQpCdXQgbXkgZmluYWwgcG9pbnQgaXMg dGhhdCB3ZSBhcmUgaWdub3JpbmcgdGhlIGFtb3VudCBvZiBub24tVExTIHByb2Nlc3NpbmcgdGhh dCBtdXN0IGJlIGRvbmUgb24gdmFyaW91cyBtZXNzYWdlIHR5cGVzIChiZWZvcmUgdGhlIHJlc3Bv bnNlIGlzIHNlbnQpLCBhbmQgVEhBVCBtaWdodCBiZSBldmVuIG1vcmUgb2YgYSBnaXZlYXdheSB0 aGFuIHRoZSBtaW51c2N1bGUgdGltaW5nIGRpZmZlcmVuY2UgZHVlIHRvIGNvdW50aW5nIHBhZGRp bmcgaW4gVExTLg0KDQotLQ0KLVRvZGQgU2hvcnQNCi8vIHRzaG9ydEBha2FtYWkuY29tPG1haWx0 bzp0c2hvcnRAYWthbWFpLmNvbT4NCi8vICJPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwg dGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiINCg0KT24gQXVnIDExLCAyMDE3LCBhdCAxOjIwIFBN LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3Rl Og0KDQoNCg0KT24gRnJpLCBBdWcgMTEsIDIwMTcgYXQgOTo0NyBBTSwgTmlrb3MgTWF2cm9naWFu bm9wb3Vsb3MgPG5tYXZAcmVkaGF0LmNvbTxtYWlsdG86bm1hdkByZWRoYXQuY29tPj4gd3JvdGU6 DQpPbiBGcmksIEF1ZyAxMSwgMjAxNyBhdCA1OjU3IFBNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRm bS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQpPbiBGcmksIEF1ZyAxMSwgMjAx NyBhdCA3OjExIEFNLCBOaWtvcyBNYXZyb2dpYW5ub3BvdWxvcyA8bm1hdkByZWRoYXQuY29tPG1h aWx0bzpubWF2QHJlZGhhdC5jb20+PiB3cm90ZToNCkltYWdpbmUgdGhlIGZvbGxvd2luZyBzY2Vu YXJpbywgd2hlcmUgdGhlIHNlcnZlciBhbmQgY2xpZW50IGhhdmUgdGhpcw0KcmVwZWF0ZWQgY29t bXVuaWNhdGlvbiBOIHRpbWVzIHBlciBkYXk6DQoNCmNsaWVudCAgICAgc2VydmVyDQogICAgLS1Y LS0+DQogICAgPC0tWS0tDQoNCg0KdGhlIGNsaWVudCBwdXRzIGluIFggYSBtZXNzYWdlIEEgb2Yg MSBieXRlIG9yIEIgb2YgMTAyNCBieXRlcywgYW5kIHBhZHMNCml0IHRvIHRoZSBtYXhpbXVtIHNp emUgb2YgVExTIHJlY29yZC4gVGhlIHNlcnZlciByZXBsaWVzIHdpdGggdGhlDQptZXNzYWdlICJv ayIgKHNhbWUgZXZlcnkgdGltZSksIHBhZGRlZCB0byB0aGUgbWF4aW11bSBzaXplIGp1c3QgYWZ0 ZXINCml0IHJlYWRzIFguDQoNCkhvd2V2ZXIsIFRMUyAxLjMgZGV0ZWN0cyB0aGUgbWVzc2FnZSBz aXplIGJ5IGl0ZXJhdGluZyB0aHJvdWdoIGFsbCB0aGUNCnBhZGRpbmcgYnl0ZXMsIGFuZCB0aHVz IHRoZXJlIGlzIGEgdGltaW5nIGxlYWsgb2JzZXJ2ZWQgYnkgdGhlIHRpbWUNCmRpZmZlcmVuY2Ug YmV0d2VlbiByZWNlaXZpbmcgWCBhbmQgc2VuZGluZyBZLiBUaHVzIGFzIGFuIGFkdmVyc2FyeSBJ DQpjb3VsZCB0YWtlIGVub3VnaCBtZWFzdXJlbWVudHMgYW5kIGJlIGFibGUgdG8gZGlzdGluZ3Vp c2ggYmV0d2VlbiBYDQpoYXZpbmcgdGhlIHZhbHVlIEEgb3IgQi4NCg0KV2hpbGUgSSdkIGV4cGVj dCB0aGVzZSBpdGVyYXRpb25zIHRvIGJlIHVubWVhc3VyYWJsZSBpbiBkZXNrdG9wIG9yDQpzZXJ2 ZXIgaGFyZHdhcmUsIEkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIHNpdHVhdGlvbiBpbiBsb3ctZW5k IElvVA0KaGFyZHdhcmUuIElzIHRoZSBkZXNpZ24gY2hvaWNlIGZvciBoYXZpbmcgdGhlIHBhZGRp bmcgcmVtb3ZhbCBkZXBlbmRpbmcNCm9uIHBhZGRpbmcgbGVuZ3RoIGludGVudGlvbmFsPw0KDQpZ ZXMsIHdlJ3JlIGF3YXJlIG9mIHRoaXMsIGFuZCBpdCdzIGFuIGludGVudGlvbmFsIGRlc2lnbiBj aG9pY2UuIFRoZSByZWFzb25pbmcNCndhcyB0aGF0IG9uY2UgeW91IGhhdmUgdGhlIHBhZGRpbmcg cmVtb3ZlZCwgeW91J2xsIG5lZWQgdG8gb3BlcmF0ZSBvbi9jb3B5DQp0aGUgdW5wYWRkZWQgY29u dGVudCBzb21ld2hlcmUsIGFuZCB0aGF0J3MgdGltaW5nIGRlcGVuZGVudCBhbnl3YXkuDQoNClRo YXQgaXMgY2VydGFpbmx5IGFuIGluY29ycmVjdCBhc3N1bXB0aW9uLiBnbnV0bHMgZm9yIGV4YW1w bGUgcHJvdmlkZXMgYSB6ZXJvLWNvcHkgQVBJLCBhbmQgSSBndWVzcyBpdCBpcyBub3QgdGhlIG9u bHkgaW1wbGVtZW50YXRpb24gdG8gaGF2ZSB0aGF0Lg0KDQpBbmQgdGhlbiB0aGUgbmV4dCB0aGlu ZyB0aGF0IHdpbGwgaGFwcGVuIGlzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIHdpbGwgcmVhZCB0aGUg ZGF0YSwgd2hpY2ggaXMgbGVuZ3RoLWRlcGVuZGVudC4gVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUg cGxhaW50ZXh0IGlzIHZhcmlhYmxlIGxlbmd0aC4NCg0KDQpUaGVyZSBpcyBtZW50aW9uaW5nIG9m IHBvc3NpYmxlIHRpbWluZyBjaGFubmVscyBpbjoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXRscy10bHMxMy0yMSNhcHBlbmRpeC1FLjM8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2Ry YWZ0LTJEaWV0Zi0yRHRscy0yRHRsczEzLTJEMjEtMjNhcHBlbmRpeC0yREUuMyZkPUR3TUZhUSZj PTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1RQkVjUXNxb1VEZGsxUTI2Q3psek5QUFVrS1lXSWgx TFlzaUhBd210UmlrJm09WEpZeE4yR2Ywck5YUGwzeWFkaXM4dXRIRHV5UmV0VUNlWWRGLU9td0Fj USZzPUNKVWZQNU9QbDRVeTNJZ3BtOWh2QXZ1TGlKbFdkUkx4U25hZ3FmTlpFWk0mZT0+DQpIb3dl dmVyIEkgZG9uJ3QgcXVpdGUgdW5kZXJzdGFuZCBob3cgaXMgdGhpcyBzZWN0aW9uIGludGVuZGVk IHRvIGJlDQpyZWFkLiBUaGUgc2VudGVuY2UgZm9yIGV4YW1wbGU6ICJCZWNhdXNlIHRoZSBwYWRk aW5nIGlzIGVuY3J5cHRlZA0KYWxvbmdzaWRlIHRoZSBhY3R1YWwgY29udGVudCwgYW4gYXR0YWNr ZXIgY2Fubm90IGRpcmVjdGx5IGRldGVybWluZSB0aGUNCmxlbmd0aCBvZiB0aGUgcGFkZGluZywg YnV0IG1heSBiZSBhYmxlIHRvIG1lYXN1cmUgaXQgaW5kaXJlY3RseSBieSB0aGUNCnVzZSBvZiB0 aW1pbmcgY2hhbm5lbHMgZXhwb3NlZCBkdXJpbmcgcmVjb3JkIHByb2Nlc3NpbmciLCB3aGF0IGlz IGl0cw0KaW50ZW50aW9uPyBJcyBpdCB0byBhY2tub3dsZWRnZSB0aGUgYWJvdmUgdGltaW5nIGxl YWs/DQoNClllcy4NCg0KSSBhbSBub3Qgc3VyZSBpZiB0aGF0IHRleHQgaXMgc3VmZmljaWVudCB0 byBjb3ZlciB0aGF0IGlzc3VlLiBJdCBzZWVtcyBhcyBpZiB0aGUgY2JjIHRpbWluZyBhdHRhY2sg aXMgcmUtaW50cm9kdWNlZCBoZXJlIGFuZCBwdXNoaW5nIHRoZSBmaXggdG8gaW1wbGVtZW50ZXJz LiBJdCBtYXkgYmUgYmV0dGVyIG5vIHRvIHByb3ZpZGUgcGFkZGluZyBmdW5jdGlvbmFsaXR5IHdp dGggdGhpcyAiZmVhdHVyZSIsIGFzIHVuZm9ydHVuYXRlbHkgaXQgd2lsbCBiZSB1c2VkIGJ5IGFw cGxpY2F0aW9ucy4NCg0KSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhpcyBpcyBhbmFseXNpcyBpcyBj b3JyZWN0LiBUaGlzIHRpbWluZyBjaGFubmVsIG9ubHkgYXBwbGllcyB0byB0aGUgZGF0YSBhZnRl ciBtZXNzYWdlIGludGVncml0eSBoYXMgYmVlbiBlc3RhYmxpc2hlZCAoaS5lLiwgYWZ0ZXIgQUVB RCBwcm9jZXNzaW5nKSwgd2hpY2ggaXMgZGlmZmVyZW50IGZyb20gdGhlIHNpdHVhdGlvbiBpbiBM dWNreSAxMy4gSXQgc2VlbXMgbGlrZSB3aGF0IGxlYWtzIGhlcmUgaXMgdGhlIGxlbmd0aCBvZiB0 aGUgcGxhaW50ZXh0LCB3aGljaCBpcyBhbHNvIHdoYXQgd291bGQgYmUgbGVha2VkIGlmIHdlIHNp bXBseSBkaWQgbm90IGhhdmUgcGFkZGluZy4NCg0KLUVrcg0KDQoNCnJlZ2FyZHMsDQpOaWtvcw0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMg bWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_14329E27DBCC4A6FBB4C7CFAFD7ADF53akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSWYgdGhlIHBsYWludGV4dCBsZW5n dGggaW5kaWNhdGVzIGEgbWVzc2FnZSB0eXBlLCB0aGVuIHRoaXMgY291bGQgbGVhZCB0byB0aGUg aXNzdWUgdGhlIG9yaWdpbmFsIHF1ZXJ5IHBvc3RlZC4gSW4gdGhhdCBhbiBvYnNlcnZlciBtaWdo dCBrbm93IHdoYXQgbWVzc2FnZSB0eXBlIHdhcyBwYXNzZWQuIFRMUyBwYWRkaW5nIGlzIHN1cHBv c2VkIHRvIHByZXZlbnQgdGhpcyAoYnV0IGl0IGRvZXNu4oCZdCBuZWNlc3NhcmlseSkuDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ib3dldmVyLCBJ IGFyZ3VlIHRoYXQgaGF2aW5nIFRMUyBkbyBzaWduaWZpY2FudCBwYWRkaW5nIGZvciBhIHByb3Rv Y29sIGlzIGJhZCBkZXNpZ24gZm9yIHRoYXQgcHJvdG9jb2wuIEl04oCZcyBvbmUgdGhpbmcgaWYg aXTigJlzIGEgZmV3IHBhZGRpbmcgYnl0ZXMsIGJ1dCB0aGUgZXhhbXBsZSBnaXZlbiB3YXMgMTAy MyBieXRlcyBvZiBwYWRkaW5nLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWxzbyBhcyBwb2ludGVkIG91dCBieSBBbmRyZWkgUG9wb3Ys IHRoZSBhcHBsaWNhdGlvbiBuZWVkcyB0byB0ZWxsIFRMUyBob3cgbXVjaCBwYWRkaW5nIHRvIGFw cGx5LCBzbyBlaXRoZXIgd2F5LCB0aGUgYXBwbGljYXRpb24gaGFzIHRvIGRlYWwgd2l0aCBkZXRl cm1pbmluZyB0aGUgcGFkZGluZyBsZW5ndGguIFdoeSBub3QganVzdCBtYWtlIGl0IHBhcnQgb2Yg dGhlIHByb3RvY29sIGluIHRoZSBmaXJzdCBwbGFjZT88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk9wZW5TU0wgaGFzIGEgY2FsbGJhY2sg c2NoZW1lLCBhbmQgYSBibG9jay1iYXNlZCBzY2hlbWUgZm9yIGRldGVybWluaW5nIHRoZSBhbW91 bnQgb2YgcGFkZGluZy4gRWl0aGVyIHdheSwgdGhlIGFwcGxpY2F0aW9uIGlzIGludm9sdmVkLjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkJ1dCBteSBmaW5hbCBwb2ludCBpcyB0aGF0IHdlIGFyZSBpZ25vcmluZyB0aGUgYW1v dW50IG9mIG5vbi1UTFMgcHJvY2Vzc2luZyB0aGF0IG11c3QgYmUgZG9uZSBvbiB2YXJpb3VzIG1l c3NhZ2UgdHlwZXMgKGJlZm9yZSB0aGUgcmVzcG9uc2UgaXMgc2VudCksIGFuZCBUSEFUIG1pZ2h0 IGJlIGV2ZW4gbW9yZSBvZiBhIGdpdmVhd2F5IHRoYW4gdGhlIG1pbnVzY3VsZSB0aW1pbmcgZGlm ZmVyZW5jZSBkdWUgdG8gY291bnRpbmcNCiBwYWRkaW5nIGluIFRMUy48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pi0tPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1Ub2RkIFNob3J0PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pi8vIDxhIGhyZWY9Im1haWx0bzp0c2hvcnRAYWthbWFpLmNvbSIgY2xhc3M9IiI+dHNob3J0QGFr YW1haS5jb208L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8vICZxdW90O09uZSBpZiBieSBsYW5k LCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuJnF1b3Q7PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEF1ZyAxMSwgMjAxNywgYXQg MToyMCBQTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIg Y2xhc3M9IiI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgQXVnIDExLCAyMDE3IGF0IDk6NDcgQU0sIE5pa29z IE1hdnJvZ2lhbm5vcG91bG9zPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOm5t YXZAcmVkaGF0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm5tYXZAcmVkaGF0LmNvbTwv YT4mZ3Q7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj53cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDogMXB4 OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVmdC1zdHls ZTogc29saWQ7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48c3Bh biBjbGFzcz0iIj5PbiBGcmksIEF1ZyAxMSwgMjAxNyBhdCA1OjU3IFBNLCBFcmljIFJlc2Nvcmxh PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGRp cj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPmVrckBydGZtLmNvbTwvYT4mZ3Q7PC9zcGFuPjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53cm90ZTo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHgg MHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1jb2xvcjogcmdi KDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmctbGVmdDog MWV4OyI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PHNwYW4gY2xhc3M9IiI+ T24gRnJpLCBBdWcgMTEsIDIwMTcgYXQgNzoxMSBBTSwgTmlrb3MgTWF2cm9naWFubm9wb3Vsb3M8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gZGly PSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWlsdG86bm1hdkByZWRoYXQuY29tIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+bm1hdkByZWRoYXQuY29tPC9hPiZndDs8L3NwYW4+PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4 IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LWNvbG9y OiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZy1s ZWZ0OiAxZXg7Ij4NCkltYWdpbmUgdGhlIGZvbGxvd2luZyBzY2VuYXJpbywgd2hlcmUgdGhlIHNl cnZlciBhbmQgY2xpZW50IGhhdmUgdGhpczxiciBjbGFzcz0iIj4NCnJlcGVhdGVkIGNvbW11bmlj YXRpb24gTiB0aW1lcyBwZXIgZGF5OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmNsaWVu dCZuYnNwOyAmbmJzcDsgJm5ic3A7c2VydmVyPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAt LVgtLSZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZsdDstLVktLTxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCnRoZSBjbGllbnQgcHV0cyBpbiBYIGEg bWVzc2FnZSBBIG9mIDEgYnl0ZSBvciBCIG9mIDEwMjQgYnl0ZXMsIGFuZCBwYWRzPGJyIGNsYXNz PSIiPg0KaXQgdG8gdGhlIG1heGltdW0gc2l6ZSBvZiBUTFMgcmVjb3JkLiBUaGUgc2VydmVyIHJl cGxpZXMgd2l0aCB0aGU8YnIgY2xhc3M9IiI+DQptZXNzYWdlICZxdW90O29rJnF1b3Q7IChzYW1l IGV2ZXJ5IHRpbWUpLCBwYWRkZWQgdG8gdGhlIG1heGltdW0gc2l6ZSBqdXN0IGFmdGVyPGJyIGNs YXNzPSIiPg0KaXQgcmVhZHMgWC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIb3dldmVy LCBUTFMgMS4zIGRldGVjdHMgdGhlIG1lc3NhZ2Ugc2l6ZSBieSBpdGVyYXRpbmcgdGhyb3VnaCBh bGwgdGhlPGJyIGNsYXNzPSIiPg0KcGFkZGluZyBieXRlcywgYW5kIHRodXMgdGhlcmUgaXMgYSB0 aW1pbmcgbGVhayBvYnNlcnZlZCBieSB0aGUgdGltZTxiciBjbGFzcz0iIj4NCmRpZmZlcmVuY2Ug YmV0d2VlbiByZWNlaXZpbmcgWCBhbmQgc2VuZGluZyBZLiBUaHVzIGFzIGFuIGFkdmVyc2FyeSBJ PGJyIGNsYXNzPSIiPg0KY291bGQgdGFrZSBlbm91Z2ggbWVhc3VyZW1lbnRzIGFuZCBiZSBhYmxl IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gWDxiciBjbGFzcz0iIj4NCmhhdmluZyB0aGUgdmFsdWUg QSBvciBCLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldoaWxlIEknZCBleHBlY3QgdGhl c2UgaXRlcmF0aW9ucyB0byBiZSB1bm1lYXN1cmFibGUgaW4gZGVza3RvcCBvcjxiciBjbGFzcz0i Ij4NCnNlcnZlciBoYXJkd2FyZSwgSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgc2l0dWF0aW9uIGlu IGxvdy1lbmQgSW9UPGJyIGNsYXNzPSIiPg0KaGFyZHdhcmUuIElzIHRoZSBkZXNpZ24gY2hvaWNl IGZvciBoYXZpbmcgdGhlIHBhZGRpbmcgcmVtb3ZhbCBkZXBlbmRpbmc8YnIgY2xhc3M9IiI+DQpv biBwYWRkaW5nIGxlbmd0aCBpbnRlbnRpb25hbD88L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBjbGFzcz0iIj5ZZXMsIHdlJ3Jl IGF3YXJlIG9mIHRoaXMsIGFuZCBpdCdzIGFuIGludGVudGlvbmFsIGRlc2lnbiBjaG9pY2UuIFRo ZSByZWFzb25pbmc8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+d2FzIHRoYXQgb25jZSB5b3UgaGF2ZSB0 aGUgcGFkZGluZyByZW1vdmVkLCB5b3UnbGwgbmVlZCB0byBvcGVyYXRlIG9uL2NvcHk8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+dGhlIHVucGFkZGVkIGNvbnRlbnQgc29tZXdoZXJlLCBhbmQgdGhhdCdz IHRpbWluZyBkZXBlbmRlbnQgYW55d2F5LjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvc3Bh bj4NCjxkaXYgY2xhc3M9IiI+VGhhdCBpcyBjZXJ0YWlubHkgYW4gaW5jb3JyZWN0IGFzc3VtcHRp b24uIGdudXRscyBmb3IgZXhhbXBsZSBwcm92aWRlcyBhIHplcm8tY29weSBBUEksIGFuZCBJIGd1 ZXNzIGl0IGlzIG5vdCB0aGUgb25seSBpbXBsZW1lbnRhdGlvbiB0byBoYXZlIHRoYXQuJm5ic3A7 PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BbmQgdGhlbiB0aGUgbmV4 dCB0aGluZyB0aGF0IHdpbGwgaGFwcGVuIGlzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIHdpbGwgcmVh ZCB0aGUgZGF0YSwgd2hpY2ggaXMgbGVuZ3RoLWRlcGVuZGVudC4gVGhlIHByb2JsZW0gaXMgdGhh dCB0aGUgcGxhaW50ZXh0IGlzIHZhcmlhYmxlIGxlbmd0aC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4 IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtY29sb3I6IHJn YigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5nLWxlZnQ6 IDFleDsiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRy YSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PHNwYW4gY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBi b3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAy MDQpOyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj48c3BhbiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdp ZHRoOiAxcHg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci1s ZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NClRoZXJlIGlzIG1lbnRpb25p bmcgb2YgcG9zc2libGUgdGltaW5nIGNoYW5uZWxzIGluOjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9v bHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkR0bHMtMkR0bHMxMy0yRDIxLTIzYXBwZW5k aXgtMkRFLjMmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9 UUJFY1FzcW9VRGRrMVEyNkN6bHpOUFBVa0tZV0loMUxZc2lIQXdtdFJpayZhbXA7bT1YSll4TjJH ZjByTlhQbDN5YWRpczh1dEhEdXlSZXRVQ2VZZEYtT213QWNRJmFtcDtzPUNKVWZQNU9QbDRVeTNJ Z3BtOWh2QXZ1TGlKbFdkUkx4U25hZ3FmTlpFWk0mYW1wO2U9IiByZWw9Im5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHI8d2Jy IGNsYXNzPSIiPmFmdC1pZXRmLXRscy10bHMxMy0yMSNhcHBlbmRpeDx3YnIgY2xhc3M9IiI+LUUu MzwvYT48YnIgY2xhc3M9IiI+DQpIb3dldmVyIEkgZG9uJ3QgcXVpdGUgdW5kZXJzdGFuZCBob3cg aXMgdGhpcyBzZWN0aW9uIGludGVuZGVkIHRvIGJlPGJyIGNsYXNzPSIiPg0KcmVhZC4gVGhlIHNl bnRlbmNlIGZvciBleGFtcGxlOiAmcXVvdDtCZWNhdXNlIHRoZSBwYWRkaW5nIGlzIGVuY3J5cHRl ZDxiciBjbGFzcz0iIj4NCmFsb25nc2lkZSB0aGUgYWN0dWFsIGNvbnRlbnQsIGFuIGF0dGFja2Vy IGNhbm5vdCBkaXJlY3RseSBkZXRlcm1pbmUgdGhlPGJyIGNsYXNzPSIiPg0KbGVuZ3RoIG9mIHRo ZSBwYWRkaW5nLCBidXQgbWF5IGJlIGFibGUgdG8gbWVhc3VyZSBpdCBpbmRpcmVjdGx5IGJ5IHRo ZTxiciBjbGFzcz0iIj4NCnVzZSBvZiB0aW1pbmcgY2hhbm5lbHMgZXhwb3NlZCBkdXJpbmcgcmVj b3JkIHByb2Nlc3NpbmcmcXVvdDssIHdoYXQgaXMgaXRzPGJyIGNsYXNzPSIiPg0KaW50ZW50aW9u PyBJcyBpdCB0byBhY2tub3dsZWRnZSB0aGUgYWJvdmUgdGltaW5nIGxlYWs/PGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv c3Bhbj4NCjxkaXYgY2xhc3M9IiI+WWVzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvc3Bh bj4NCjxkaXYgY2xhc3M9IiI+SSBhbSBub3Qgc3VyZSBpZiB0aGF0IHRleHQgaXMgc3VmZmljaWVu dCB0byBjb3ZlciB0aGF0IGlzc3VlLiBJdCBzZWVtcyBhcyBpZiB0aGUgY2JjIHRpbWluZyBhdHRh Y2sgaXMgcmUtaW50cm9kdWNlZCBoZXJlIGFuZCBwdXNoaW5nIHRoZSBmaXggdG8gaW1wbGVtZW50 ZXJzLiBJdCBtYXkgYmUgYmV0dGVyIG5vIHRvIHByb3ZpZGUgcGFkZGluZyBmdW5jdGlvbmFsaXR5 IHdpdGggdGhpcyAmcXVvdDtmZWF0dXJlJnF1b3Q7LCBhcyB1bmZvcnR1bmF0ZWx5DQogaXQgd2ls bCBiZSB1c2VkIGJ5IGFwcGxpY2F0aW9ucy48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgYW5h bHlzaXMgaXMgY29ycmVjdC4gVGhpcyB0aW1pbmcgY2hhbm5lbCBvbmx5IGFwcGxpZXMgdG8gdGhl IGRhdGEgYWZ0ZXIgbWVzc2FnZSBpbnRlZ3JpdHkgaGFzIGJlZW4gZXN0YWJsaXNoZWQgKGkuZS4s IGFmdGVyIEFFQUQgcHJvY2Vzc2luZyksIHdoaWNoIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBzaXR1 YXRpb24gaW4gTHVja3kgMTMuIEl0IHNlZW1zIGxpa2Ugd2hhdCBsZWFrcw0KIGhlcmUgaXMgdGhl IGxlbmd0aCBvZiB0aGUgcGxhaW50ZXh0LCB3aGljaCBpcyBhbHNvIHdoYXQgd291bGQgYmUgbGVh a2VkIGlmIHdlIHNpbXBseSBkaWQgbm90IGhhdmUgcGFkZGluZy48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1Fa3I8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0 aDogMXB4OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVm dC1zdHlsZTogc29saWQ7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij4NCjxkaXYgY2xhc3M9IiI+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5yZWdhcmRzLDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5OaWtvczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPlRMUw0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPlRMU0BpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs YXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 bHMiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RsczwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_14329E27DBCC4A6FBB4C7CFAFD7ADF53akamaicom_-- From nobody Fri Aug 11 11:46: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 E819E132646 for ; Fri, 11 Aug 2017 11:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 (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 Ha9gZcM9qIM4 for ; Fri, 11 Aug 2017 11:46:51 -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 7422713257A for ; Fri, 11 Aug 2017 11:46:51 -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=cgB/Fq/8RM3TDCbvdvoJy2ZVlCOhg8dk/y5NKlWa8zk=; b=phOnt5cvUu+uebmifZWTEt4wbTlaA9WlbN8Q98PEtq8DvOgTWAyzxJ1YT9fPI7+/id3Ynw+vp1yPzfoHrWzAL5Ps8CB5tNJsJeBDtL9PoMYoYF8fYT0mY1s2f3Tqw6h3Sijv7CAlK3xTav1ffkqUTRMp9WSs0TGWzefIt3jOPBCYqwJqQfAmZb8o9OxeDiEanYJGLxcHT3+Dz/+xwftNDuBDyd3Ni0Tm3icnlmg2FrYnzCZIo9oeM6t0AOnZJ2Q23p4zCOysERrO1bWc7Ge9lVJFV7bamo9AaQJeAYk5cdgV9H2FlqA99wy6VXoZOVQ0Jf1rA5FsbM4IFcIMkh7uFA==; Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dgExM-0007ap-9Z; Fri, 11 Aug 2017 20:46:49 +0200 Date: Fri, 11 Aug 2017 20:46:44 +0200 From: Peter Wu To: Debapriyay Mukhopadhyay Cc: tls@ietf.org Message-ID: <20170811184644.GB12026@al> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [TLS] Looking for sample captures involving ChaCha20-Poly1305 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 18:46:54 -0000 Hi Debapriyay, On Mon, Aug 07, 2017 at 05:30:12PM +0530, Debapriyay Mukhopadhyay wrote: > I am in need of a sample capture through which I can get to see the > packet exchanges involving CHACHA20_POLY1305 cipher suites. Can anyone > please point me to any such sample capture. The Wireshark test suite has captures involving the ChaCha20-Poly1305 cipher suite. See https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=57b0527821b69dc8aa0786a3b5a425192795aff2 TLS 1.2: test/captures/tls12-chacha20poly1305.pcap TLS 1.3 (draft -20): test/captures/tls13-20-chacha20poly1305.pcap -- Kind regards, Peter Wu https://lekensteyn.nl From nobody Fri Aug 11 12:18: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 94E5F131E08 for ; Fri, 11 Aug 2017 12:18:04 -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 AyPTIyX2MRuy for ; Fri, 11 Aug 2017 12:18:01 -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 85A6012711B for ; Fri, 11 Aug 2017 12:18:01 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u207so27793378ywc.3 for ; Fri, 11 Aug 2017 12:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2H2LPJjp2qcTTszff2kH3Ze8PkUIvimp4cL2ajtovhM=; b=b4TxSsEHiDdWwebf1mCvc00Ih4kHbFcrNfbZfdgP9IAbY6tY8xqsP3aWJBuwwlhMZU alMneoZMTSAYWTgn9N31xhJb9dkERmL11TLgm0gpKKOtFzLdAL/xfoJzNaQ2IhlEOMiN m2LNTStpTsSPA/H0xPn98QI/8kYpHp+CvHSLPrs1OL2aeazbZOI1OkScy01i8qjELARi DC8kqpXLV1K7HGWyphpQEvohRdAA2k77ax0j1QRjENSaUeppRzB01FrmGFObaJotEQyI 17ekgVb+Bafbuyjp8IK8DPi9mFx0/+JiGdldVpKVCMDe6us+KwNlo9lpI6XuBVaVXV+X XO7Q== 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=2H2LPJjp2qcTTszff2kH3Ze8PkUIvimp4cL2ajtovhM=; b=ir1tjp2+3Zn4JELmQdkZAfncFhBzYtB+knjCSopqYtxk6s/RgUgodMLZXxRjoe06vE u9Fa2qctIq4upBTWK5KTOdNgzvKDF2EhG+XJKat5uU1MrWoHNR6cxWV6pSd5WvrPYzSB ABl5XXo5MN9FYZGwypZk0cBQ7F9fa+BzTNNcDhOBvr/RHNXxuEPUw8EgqwjRtQ8MlOtG 4OipO9T/zhSpEuINgZbgEDcSsu2goiFcHv5P1+C1DriWwPNy4W7ltCUwsJvBfy4Nlr2+ X2oQxGzkyEUnCy3ceLKwFHpCTEyoA4zyJhT+rO36TB5ws3Wcz8DPUA+KZXeNdDeB9yyg rvlw== X-Gm-Message-State: AHYfb5hbRAiYQFEBVnJwaWW4wwudFc6Q/XN1/dKqXCpcfq40bkU/gEv7 6w4B2p6vdXNKTTjBjNBPtDjq8fBRrfV2 X-Received: by 10.37.203.79 with SMTP id b76mr7325786ybg.256.1502479080753; Fri, 11 Aug 2017 12:18:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 11 Aug 2017 12:17:20 -0700 (PDT) In-Reply-To: References: <150237598967.11871.16700348530940949770.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Fri, 11 Aug 2017 12:17:20 -0700 Message-ID: To: Daniel Migault Cc: The IESG , tls , tls-chairs , draft-ietf-tls-ecdhe-psk-aead@ietf.org Content-Type: multipart/alternative; boundary="94eb2c05a962e4390305567f2b47" Archived-At: Subject: Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 19:18:05 -0000 --94eb2c05a962e4390305567f2b47 Content-Type: text/plain; charset="UTF-8" This is just a result of goofy tooling. I.e., I removed my discuss but didn't edit the rest of my comments.... -Ekr On Fri, Aug 11, 2017 at 11:13 AM, Daniel Migault < daniel.migault@ericsson.com> wrote: > Hi Eric, > > Thank you for reviewing the document. Given your second comment, I suspect > you are reading the version 04 while the current version is version 05 [1]. > I believe your comments have been addressed in the version 05.However let > me know if you have other concerns. > > Regarding TLS1.3. we were asked to position the new code points toward > TLS1.3, but I guess that was at the time the version was not indicated in > the title, so in principle we could remove these references.I believe the > text in version 05 address your comment, but here are the current version > still cites TLS 1.3 in the following sections: > > - introduction: """AEAD algorithms that combine encryption and > integrity protection are strongly recommended for (D)TLS [RFC7525 > ] and non-AEAD algorithms are > forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13 > ]. > """. Would you prefer to remove "and non-AEAD algorithms are forbidden to > use in TLS 1.3 [I-D.ietf-tls-tls13 > > ]" or it is fine to leave it as it is ? > - section 3: """ Cipher suites TLS_AES_128_GCM_SHA256, > TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 > are used to support equivalent functionality in TLS 1.3 [ > I-D.ietf-tls-tls13 > ]. > """. Would you prefer to have all mentioned text being removed or is it > fine to leave it as it is ? > > Regarding the reference to the PRF of TLS 1.1, I think it concerns the > text below which has been removed in the version 05. > > """ > > [...] The PRF results from > mixing the two pseudorandom streams with distinct hash functions (MD5 > and SHA-1) by exclusive-ORing them together. In the case of > ECDHE_PSK authentication, the PSK and pre-master are treated by > distinct hash function with distinct properties. This may introduce > vulnerabilities over the expected security provided by the > constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be > used with ECDHE_PSK. The cipher suites defined in this document make use of the > authenticated encryption with additional data (AEAD) defined in TLS > 1.2 [RFC5246 ] and DTLS 1.2 [RFC6347 ]. Earlier versions of TLS do not > have support for AEAD and consequently, the cipher suites defined in > this document MUST NOT be negotiated in TLS versions prior to 1.2. > In addition, it is worth noting that TLS 1.0 [RFC2246 ] and TL1.2 > [RFC4346 ] splits the pre-master in two parts. The PRF results from > mixing the two pseudorandom streams with distinct hash functions (MD5 > and SHA-1) by exclusive-ORing them together. In the case of > ECDHE_PSK authentication, the PSK and pre-master are treated by > distinct hash function with distinct properties. This may introduce > vulnerabilities over the expected security provided by the > constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be > used with ECDHE_PSK. > """ > > Yours, > > Daniel > > [1] https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05 > > On Thu, Aug 10, 2017 at 10:39 AM, Eric Rescorla wrote: > >> Eric Rescorla has entered the following ballot position for >> draft-ietf-tls-ecdhe-psk-aead-05: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> The citations to TLS 1.3 still seem pretty muddled. I think you >> should just stop referencing and discussing 1.3. >> > >> S 2. >> I'm not sure that the discussion of the PRF is helpful here in >> mandating the non-use of these cipher suites with TLS 1.1 and >> below. >> >> > > >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --94eb2c05a962e4390305567f2b47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is just a result of goofy tooling. I.e., I removed my= discuss but didn't edit the rest of my comments....
-Ekr


= On Fri, Aug 11, 2017 at 11:13 AM, Daniel Migault <daniel.migault= @ericsson.com> wrote:
Hi Eric,

Thank you for reviewing the documen= t. Given your second comment, I suspect you are reading the version 04 whil= e the current version is version 05 [1]. I believe your comments have been = addressed in the version 05.However let me know if you have other concerns.=

Regarding TLS1.3. we were asked to position th= e new code points toward TLS1.3, but I guess that was at the time the version was not indicated=20 in the title, so in principle we could remove these references.I believe th= e text in version 05 address your comment, but here are the current version= still cites TLS 1.3 in the following sections:

Regarding the reference= to the PRF of TLS 1.1, I think it concerns the text below which has been r= emoved in the version 05.

"""

   [...]  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and pre-master are treated by
   distinct hash function with distinct properties.  This may introduce
   vulnerabilities over the expected security provided by the
   constructed pre-master.  As such TLS 1.0 and TLS 1.1 should not be
   used with ECDHE_PSK.   The cipher suites defined in this document make u=
se of the
   authenticated encryption with additional data (AEAD) defined in TLS
   1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
   have support for AEAD and consequently, the cipher suites defined in
   this document MUST NOT be negotiated in TLS versions prior to 1.2.
   In addition, it is worth noting that TLS 1.0 [RFC2246] and TL1.2
   [RF=
C4346] splits the pre-master in two parts.  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and pre-master are treated by
   distinct hash function with distinct properties.  This may introduce
   vulnerabilities over the expected security provided by the
   constructed pre-master.  As such TLS 1.0 and TLS 1.1 should not be
   used with ECDHE_PSK.
"""

Yours, 
Daniel

[1] https://tools.i= etf.org/html/draft-ietf-tls-ecdhe-psk-aead-05

On Thu, Aug 10, 2017 at 10:39 AM,= Eric Rescorla <ekr@rtfm.com> wrote:
Eric Rescorla has entered the following ballot pos= ition for
draft-ietf-tls-ecdhe-psk-aead-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-tls-ecdhe-psk-aead/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

The citations to TLS 1.3 still seem pretty muddled. I think you
should just stop referencing and discussing 1.3.

S 2.
I'm not sure that the discussion of the PRF is helpful here in
mandating the non-use of these cipher suites with TLS 1.1 and
below.


=C2=A0

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


--94eb2c05a962e4390305567f2b47-- From nobody Fri Aug 11 12:19: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 14FC91323C8 for ; Fri, 11 Aug 2017 12:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7] 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 xovefu9rvMY7 for ; Fri, 11 Aug 2017 12:19:47 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 8E55A1323A4 for ; Fri, 11 Aug 2017 12:19:47 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id s143so27869888ywg.1 for ; Fri, 11 Aug 2017 12:19:47 -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=6kcwH5rPal0rQ5fW+JdUVkSc1q5K1fYWlbqgECMoUSU=; b=TKWBgsyM2dgp4agQBB/Kio9GZC3XGV1W8qoasRJEWxIsQrFj4VYrrfEUcZEmt4Or4E D0gKUjp5kLulgMfEfV8SFfYzV6hH3DA1kZNCSxpZKz4bIwY/LvYYJGvrRdTC47bajJ2v UtCZ1BsZZVTycXzxAn2DTEKAHo3OM/M2r3jkMy6tqJFrACWrCxVkjV5V859if2MFIb/v iWUJPSileWl/oyL/385oPgN9TPPQGTHpkwL4RN3yj+65O6Q1N0DPOaDWDTvvP2wSwLen UhrXu9ecHfyGjR4tn8YHE7S9e5k8hDW52mQpfpD2BpyaTcDsbwaopuybT7rrtUACDxp2 DCVw== 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=6kcwH5rPal0rQ5fW+JdUVkSc1q5K1fYWlbqgECMoUSU=; b=twCSRZm2uEkRD4OFUFk8PKvHG2vZmsX2R1GeZ2ivNwzjmPQR364jZjSJfVu6I5s0AS dRm+h5qkYCfFAThKudT0QaSiA6XHsm2KJQgOxk5ZYwkSBVg6s5zojLNlyq1XGK/+ROHT dVN4NIOULVwAH1e9KP50aQpJ3D+xtdznTy3xRGTEjHu7x4t7L3rAMewvUaleuwJz7nNy RrgfuUyUJ9ax8vKe2oNaSQ9y8MwJoLmgvN8IEiZft0bCYuFp4j4vddQB+tuDsEd5ChBz jb0oc4z/09EwfH+wuzscYwDjESYsh1OOwz6JeoDVerz7k+VEgzAEB6eAZJK93s2izN6G N8oQ== X-Gm-Message-State: AHYfb5h69pA+bjHRcTRm6HXAT6fuevl0EDJojJtF1bHaWBGGlShf8G0M AjHXDlwDuDDLfUPfNMExk3KpatlNV6gD X-Received: by 10.37.181.25 with SMTP id p25mr12762096ybj.249.1502479186798; Fri, 11 Aug 2017 12:19:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 11 Aug 2017 12:19:06 -0700 (PDT) In-Reply-To: <14329E27-DBCC-4A6F-BB4C-7CFAFD7ADF53@akamai.com> References: <1502460670.3202.8.camel@redhat.com> <14329E27-DBCC-4A6F-BB4C-7CFAFD7ADF53@akamai.com> From: Eric Rescorla Date: Fri, 11 Aug 2017 12:19:06 -0700 Message-ID: To: "Short, Todd" Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045e6ed0367b0b05567f32c8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 19:19:50 -0000 --f403045e6ed0367b0b05567f32c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 11, 2017 at 11:32 AM, Short, Todd wrote: > If the plaintext length indicates a message type, then this could lead to > the issue the original query posted. In that an observer might know what > message type was passed. TLS padding is supposed to prevent this (but it > doesn=E2=80=99t necessarily). > > However, I argue that having TLS do significant padding for a protocol is > bad design for that protocol. It=E2=80=99s one thing if it=E2=80=99s a fe= w padding bytes, > but the example given was 1023 bytes of padding. > > Also as pointed out by Andrei Popov, the application needs to tell TLS ho= w > much padding to apply, so either way, the application has to deal with > determining the padding length. Why not just make it part of the protocol > in the first place? > The consensus was to provide a generic scheme that applications could use, or not. -Ekr > > OpenSSL has a callback scheme, and a block-based scheme for determining > the amount of padding. Either way, the application is involved. > > But my final point is that we are ignoring the amount of non-TLS > processing that must be done on various message types (before the respons= e > is sent), and THAT might be even more of a giveaway than the minuscule > timing difference due to counting padding in TLS. > > -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Aug 11, 2017, at 1:20 PM, Eric Rescorla wrote: > > > > On Fri, Aug 11, 2017 at 9:47 AM, Nikos Mavrogiannopoulos > wrote: > >> On Fri, Aug 11, 2017 at 5:57 PM, Eric Rescorla wrote: >> >>> >>> On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos >> redhat.com> wrote: >>> >>>> Imagine the following scenario, where the server and client have this >>>> repeated communication N times per day: >>>> >>>> client server >>>> --X--> >>>> <--Y-- >>>> >>>> >>>> the client puts in X a message A of 1 byte or B of 1024 bytes, and pad= s >>>> it to the maximum size of TLS record. The server replies with the >>>> message "ok" (same every time), padded to the maximum size just after >>>> it reads X. >>>> >>>> However, TLS 1.3 detects the message size by iterating through all the >>>> padding bytes, and thus there is a timing leak observed by the time >>>> difference between receiving X and sending Y. Thus as an adversary I >>>> could take enough measurements and be able to distinguish between X >>>> having the value A or B. >>>> >>>> While I'd expect these iterations to be unmeasurable in desktop or >>>> server hardware, I am not sure about the situation in low-end IoT >>>> hardware. Is the design choice for having the padding removal dependin= g >>>> on padding length intentional? >>> >>> >>> Yes, we're aware of this, and it's an intentional design choice. The >>> reasoning >>> was that once you have the padding removed, you'll need to operate >>> on/copy >>> the unpadded content somewhere, and that's timing dependent anyway. >>> >> >> That is certainly an incorrect assumption. gnutls for example provides a >> zero-copy API, and I guess it is not the only implementation to have tha= t. >> > > And then the next thing that will happen is that the application will rea= d > the data, which is length-dependent. The problem is that the plaintext is > variable length. > > > There is mentioning of possible timing channels in: >>>> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 >>>> >>>> However I don't quite understand how is this section intended to be >>>> read. The sentence for example: "Because the padding is encrypted >>>> alongside the actual content, an attacker cannot directly determine th= e >>>> length of the padding, but may be able to measure it indirectly by the >>>> use of timing channels exposed during record processing", what is its >>>> intention? Is it to acknowledge the above timing leak? >>>> >>> >>> Yes. >>> >> >> I am not sure if that text is sufficient to cover that issue. It seems a= s >> if the cbc timing attack is re-introduced here and pushing the fix to >> implementers. It may be better no to provide padding functionality with >> this "feature", as unfortunately it will be used by applications. >> > > I don't believe that this is analysis is correct. This timing channel onl= y > applies to the data after message integrity has been established (i.e., > after AEAD processing), which is different from the situation in Lucky 13= . > It seems like what leaks here is the length of the plaintext, which is al= so > what would be leaked if we simply did not have padding. > > -Ekr > > >> regards, >> Nikos >> >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --f403045e6ed0367b0b05567f32c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 11, 2017 at 11:32 AM, Short, Todd <tshort@akamai.com&g= t; wrote:
If the plaintext length indicates a message type, then this could lead to t= he issue the original query posted. In that an observer might know what mes= sage type was passed. TLS padding is supposed to prevent this (but it doesn= =E2=80=99t necessarily).

However, I argue that having TLS do significant padding for a protocol= is bad design for that protocol. It=E2=80=99s one thing if it=E2=80=99s a = few padding bytes, but the example given was 1023 bytes of padding.

Also as pointed out by Andrei Popov, the application needs to tell TLS= how much padding to apply, so either way, the application has to deal with= determining the padding length. Why not just make it part of the protocol = in the first place?

The consens= us was to provide a generic scheme that applications could use, or not.

-Ekr
=C2=A0

OpenSSL has a callback scheme, and a block-based scheme for determinin= g the amount of padding. Either way, the application is involved.

But my final point is that we are ignoring the amount of non-TLS proce= ssing that must be done on various message types (before the response is se= nt), and THAT might be even more of a giveaway than the minuscule timing di= fference due to counting padding in TLS.

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

On Aug 11, 2017, at 1:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Fri, Aug 11, 2017 at 9:47 AM, Nikos Mavrogian= nopoulos=C2=A0<= /span><nmav@redhat.com>=C2=A0wrote:
On Fri, Aug 11, 2017 at 5:57 PM, Eric Resc= orla=C2=A0<e= kr@rtfm.com>=C2=A0wrote:

On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mav= rogiannopoulos= =C2=A0<nmav@redhat.com>=C2=A0wrote:
Imagine the following scenario, where the server and client have this
repeated communication N times per day:

client=C2=A0 =C2=A0 =C2=A0server
=C2=A0 =C2=A0 --X-->
=C2=A0 =C2=A0 <--Y--


the client puts in X a message A of 1 byte or B of 1024 bytes, and pads
it to the maximum size of TLS record. The server replies with the
message "ok" (same every time), padded to the maximum size just a= fter
it reads X.

However, TLS 1.3 detects the message size by iterating through all the
padding bytes, and thus there is a timing leak observed by the time
difference between receiving X and sending Y. Thus as an adversary I
could take enough measurements and be able to distinguish between X
having the value A or B.

While I'd expect these iterations to be unmeasurable in desktop or
server hardware, I am not sure about the situation in low-end IoT
hardware. Is the design choice for having the padding removal depending
on padding length intentional?
Yes, we're aware of this, and it's an intentional design choic= e. The reasoning
was that once you have the padding removed, you'll need to operate= on/copy
the unpadded content somewhere, and that's timing dependent anyway= .
That is certainly an incorrect assumption. gnutls for example provides= a zero-copy API, and I guess it is not the only implementation to have tha= t.=C2=A0

And then the next thing that will happen is that the application will = read the data, which is length-dependent. The problem is that the plaintext= is variable length.


There is mentioning of possible timing channels in:
https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix<= wbr>-E.3
However I don't quite understand how is this section intended to be
read. The sentence for example: "Because the padding is encrypted
alongside the actual content, an attacker cannot directly determine the
length of the padding, but may be able to measure it indirectly by the
use of timing channels exposed during record processing", what is its<= br> intention? Is it to acknowledge the above timing leak?
Yes.
I am not sure if that text is sufficient to cover that issue. It seems= as if the cbc timing attack is re-introduced here and pushing the fix to i= mplementers. It may be better no to provide padding functionality with this= "feature", as unfortunately it will be used by applications.

I don't believe that this is analysis is correct. This timing chan= nel only applies to the data after message integrity has been established (= i.e., after AEAD processing), which is different from the situation in Luck= y 13. It seems like what leaks here is the length of the plaintext, which is also what would be leaked if= we simply did not have padding.

-Ekr

=C2=A0
regards,
Nikos


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


--f403045e6ed0367b0b05567f32c8-- From nobody Fri Aug 11 12:23: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 74990131D22 for ; Fri, 11 Aug 2017 12:22:59 -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 vlHOzyJDC8h0 for ; Fri, 11 Aug 2017 12:22:49 -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 EA2C11321E6 for ; Fri, 11 Aug 2017 12:22:41 -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 v7BJMHfj026589; Fri, 11 Aug 2017 20:22: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=T+XtMPgGZah6Z5Q6zAY+j9DSbd49GS//BHPrrRdYG0g=; b=oqa1If+mVuzdH+ocKmNEMEmedwt1W3r3Qf4Rb3BGPPNJCJU2tVDl/CJlS2K+rmwFAo2h b8OMF2iKzfLZ3PQbkoRuZhE/6BF8rbatoXv6BF0hA7J90qMHi9mlqIT8pTSpRD5S7ehj sa34OSdx26zW01jTURoSOyH+LwN9n51pbsLor8P6guO42My5KjnaLKJbUVGWWuM04HJW F0vmYkJvJ+8VgltVrNuCbGlWmc1ZFBnODkm7yOsVrPc1CDC1Nwmrh2Qz939TjKXoCZA6 PDVgfsaC2/vGZ0bqClGCfG8cw729nvG3bVprZKjzl4LaQkOJI/PUbavDgUrNoieT82ya 6A== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2c806yrw2x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2017 20:22:40 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7BJLL2S030578; Fri, 11 Aug 2017 15:22:39 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c59bv9ejt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2017 15:22:39 -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; Fri, 11 Aug 2017 15:22:38 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Fri, 11 Aug 2017 15:22:38 -0400 From: "Short, Todd" To: Eric Rescorla CC: Nikos Mavrogiannopoulos , "tls@ietf.org" Thread-Topic: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size Thread-Index: AQHTEqu4UDB35x1gLEG+JKMOxcPabqJ/kuoAgAANtICAAAlUAIAAFEWAgAAM5QCAAAD8gA== Date: Fri, 11 Aug 2017 19:22:37 +0000 Message-ID: <28A2F771-AFC4-494D-944E-FD7EF334BAA9@akamai.com> References: <1502460670.3202.8.camel@redhat.com> <14329E27-DBCC-4A6F-BB4C-7CFAFD7ADF53@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.244] Content-Type: multipart/alternative; boundary="_000_28A2F771AFC4494D944EFD7EF334BAA9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-11_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-1706020000 definitions=main-1708110303 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-11_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-1706020000 definitions=main-1708110303 Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 19:22:59 -0000 --_000_28A2F771AFC4494D944EFD7EF334BAA9akamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 11, 2017, at 3:19 PM, Eric Rescorla > wrote: On Fri, Aug 11, 2017 at 11:32 AM, Short, Todd > wrote: Also as pointed out by Andrei Popov, the application needs to tell TLS how = much padding to apply, so either way, the application has to deal with dete= rmining the padding length. Why not just make it part of the protocol in th= e first place? The consensus was to provide a generic scheme that applications could use, = or not. -Ekr I was referring to the protocol over TLS, not TLS itself, sorry for the con= fusion. -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." --_000_28A2F771AFC4494D944EFD7EF334BAA9akamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 11, 2017, at 3:19 PM, Eric Rescorla <ekr@rtfm.com> wrote:
On Fri, Aug 11, 2017 at 11:32 AM, Short, Todd <tshor= t@akamai.com> wrote:

Also as pointed out by Andrei Popov, the application needs = to tell TLS how much padding to apply, so either way, the application has t= o deal with determining the padding length. Why not just make it part of th= e protocol in the first place?

The consensus was to provide a generic scheme that applicat= ions could use, or not.

-Ekr
 

I was referring to the protocol over TLS, not TLS itself, sorry for th= e confusion.

--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

--_000_28A2F771AFC4494D944EFD7EF334BAA9akamaicom_-- From nobody Fri Aug 11 14:05:00 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 22E8013238E; Fri, 11 Aug 2017 14:04:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-tls-ecdhe-psk-aead@ietf.org, Kathleen.Moriarty.ietf@gmail.com, Joseph Salowey , tls@ietf.org, joe@salowey.net, rfc-editor@rfc-editor.org, tls-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150248549813.24449.14054837192162058533.idtracker@ietfa.amsl.com> Date: Fri, 11 Aug 2017 14:04:58 -0700 Archived-At: Subject: [TLS] Protocol Action: 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2' to Proposed Standard (draft-ietf-tls-ecdhe-psk-aead-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: Fri, 11 Aug 2017 21:04:58 -0000 The IESG has approved the following document: - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2' (draft-ietf-tls-ecdhe-psk-aead-05.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ Technical Summary This document defines several new cipher suites for the Transport Layer Security (TLS) protocol. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides perfect forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. Working Group Summary There is general support for this document in the working group. The main issues focused around trimming down the list of cipher suites to the minimum number required. Document Quality The document has been review by the TLS working group. The SecDir review triggered additional useful conversation and draft updates. Personnel Joseph Salowey is the Document Shepherd. Kathleen Moriarty is the responsible AD. IANA Note Code points are requested for existing registries. From nobody Fri Aug 11 14:56: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 38E821326B6 for ; Fri, 11 Aug 2017 14:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=levangong-org.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 5UAJ4oM39vqC for ; Fri, 11 Aug 2017 14:56:06 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001: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 DF5541326B3 for ; Fri, 11 Aug 2017 14:56:05 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id g71so24433546ioe.5 for ; Fri, 11 Aug 2017 14:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=levangong-org.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=GskzQhIqqtvhHPoqbP9q+tYsCvslWkXbiMsS3r515qI=; b=xxnT2sXvD0bm1CeX13JFYA1Wgdwe/2XL0RGX17d4bOLx1sDYIwY10WqQ6Sxlw0TeuQ eKYfF+qbOG6G7rFvQdhocbz7Y4h7DgGRg0EWLf9Gj+5R/Zo/EcgpNQlsf6wBUU972NYJ T4pTedsqLWiz2vpUtyEbmN0lq0WFtYkcI8/RjvhRpmL8Zu6xg0DjwaaDbrvqs8+Fbkn0 TSQFxrG0kaIqBcr+YdpwunKHN/qb5upwJy8B3o+4KoE4atGl+SgYQTgNuLOkbDFVMqwr liQBW3Zgix9h5OZwk3U11YeBGSUKmpGl8c9mEXgpBdYrAFbuiKYOMhXwdx+uDgoj+A8U F8ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=GskzQhIqqtvhHPoqbP9q+tYsCvslWkXbiMsS3r515qI=; b=C6i9fgemZCLu9fT5So66uSxBAqZ51/VYwH656tyYWfWKoBk1Lm0H9dGkMq0EaF9Px6 euzaKRVD2s8TH1CYobx+Uj/4VjMRDX+x0l/vXrDYaTKPF9EQP25gM8svIcmT3G1CivpK qexIJRWB4UExZVOzlsd3T4dKqzF/sSL2U45SDngbyaeGs6Zh7939K2wThTIRCFK14Jbv ZIMsqM7BPYaWBkLxfntiHub41Pca+dDIbXO/+BAZNlsuWgmzrUUq6EgxjrYh5gr1F4/v Bqpc+b+K4Cs1rkBgUEADx1Idyg2BQ9krWJj8WIhtPJTNMB5MyVlrtwCmfgCjy5/yYQMl t99g== X-Gm-Message-State: AHYfb5jOQDDubldNYnRP4cNAUZQkPgWzX27MQZ56bXiyREcB3N2dYFQk AVvtdgNiGVHTXc2v X-Received: by 10.107.37.140 with SMTP id l134mr13690365iol.182.1502488565224; Fri, 11 Aug 2017 14:56:05 -0700 (PDT) Received: from [10.225.88.49] ([173.224.162.69]) by smtp.gmail.com with ESMTPSA id w207sm70161itc.34.2017.08.11.14.56.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 14:56:04 -0700 (PDT) From: "Le Van Gong, Hubert" To: tls@ietf.org Message-ID: <72964498-cbde-2bb1-75fa-cf8d2551e8aa@levangong.org> Date: Fri, 11 Aug 2017 14:56:03 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] draft-ietf-tls-tls13-21: actual early data... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 21:56:08 -0000 Hithere, While looking into leveraging early data, it occurred to me that the actual effectiveness of 0-RTT is going to be highly dependent on implementationdetails. In section 2.3 (Zero-RTT Data) -tls13-21 [1], the first sentence says "TLS 1.3 allows clients to send data on the first flight ("early data")" which I initially interpreted as "you can send data in the ClientHelloitself.Part of figure 4 (reproduced below), seemed to confirm my perceptionthat Application Data is indeed in the ClientHello msg: -------- ClientHello + early_data + key_share* + psk_key_exchange_modes + pre_shared_key (Application Data*) -------- Alas, upon experimentation (using latest OpenSSL), we've observed that our early data (no matter how small) gets shipped in a separate TCP packet after the TCP packet containing the ClientHello. This becomes a significant performance hit when the underlying network stack uses something like the Nagle algorithm (or similar [2]) because the TCP packet with early data will only be sent *after* a server TCP ACK (for the ClientHello) has been received by the client. So much for zero roundtrip in that case. It is not a lot of effort to modify the OpenSSL client (and server) to not delay the early data TCP packet but it something not everyone will be comfortable doing, esp. in an enterprise setting. Looking into the data structure of ClientHello, I could not find a place to put early data either: the ClientHello early_data extension can only contain an empty EarlyDataIndication structure. I wonder what was the rationale for not allowing the early_data extension to contain actual data? Was the intent to preserve protocol cleanliness? i.e., ClientHello is a handshake protocol message and the early data is a Record protocol message? Cheers, Hubert & Jeff [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-2.3 [2] https://en.wikipedia.org/wiki/Nagle%27s_algorithm From nobody Fri Aug 11 15:14: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 86233132444 for ; Fri, 11 Aug 2017 15:14:38 -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 Cxh5ZYaAJ0Zc for ; Fri, 11 Aug 2017 15:14:36 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF6E1321AC for ; Fri, 11 Aug 2017 15:14:36 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 99B48F99F; Fri, 11 Aug 2017 18:14:34 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1F8CA20745; Fri, 11 Aug 2017 14:45:18 -0400 (EDT) From: Daniel Kahn Gillmor To: Nikos Mavrogiannopoulos , "Short\, Todd" Cc: "tls\@ietf.org" In-Reply-To: References: <1502460670.3202.8.camel@redhat.com> <075C47B6-A601-441F-B881-A7F78648B5F1@akamai.com> Date: Fri, 11 Aug 2017 14:45:15 -0400 Message-ID: <87shgyndtw.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 22:14:38 -0000 --=-=-= Content-Type: text/plain On Fri 2017-08-11 18:43:15 +0200, Nikos Mavrogiannopoulos wrote: > I don't argue with this but this is not the approach TLS 1.3 took. It > provides a generic padding mechanism to be used across application > protocols. The design approach that TLS 1.3 took was to provide a mechanism for padding at the TLS layer, not to prescribe padding at the application layer. You actually probably need both to defend against traffic analysis in the big picture. Thoughtful, well-designed application-layer padding is likely to be better than generic TLS-layer padding. But not all applications can actually accomodate padding (and it's not clear that folks have done the thoughtful work even on those applications which *can* accomodate padding). TLS offers a generic mechanism to support the cases where the application can't do padding, or where the implementer has no control over (or insight into) the application itself. It'll probably leak in the way you describe, but it'll probably also be better than cleartext. Furthermore, there are TLS messages that are not application data at all -- so those parts *have* to be padded at the TLS layer, as the application cannot directly affect their size. A robust and safe padding approach needs to take into account all layers of the stack at once and coordinate between them. Without the padding mechanism in TLS, it wouldn't be possible to coordinate across the whole stack. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlmN+zsACgkQFJitxsGS MjfZURAAldiHJEMc/j4M0p5p3Blw1hX1/WCeKCAagRAy6zFhOlclRYHeKTvwdkh4 Z9rnne3rssQdAAM+GuWnonUZrgMu0KqN4B8vMmcXVUdWuHDZt7ld8d7MEgorWz6+ X0e7A++oPzwpgdxHnNRUq/wDe+0haLZWsvhYrBTQ1orkAFDkwDpaAeeDL25g4orD 7Ejf48SwKNGuT2cE8RmyRs8Wd1VM1nmMpXJH0mGgodHCOxQDZka5wDmZok7pflBm 3ZToincqR/UNFy2guKoFmR7MVZgNXexSblF+E+7kGOLoanQTexPPhb4p1VcY2aq5 NSD3qDmnpC7I6QTnE2yO8n2WUjpUqb9KLKYkQF1pJB3+l72WKQ1/9HMjKDFQHAmx +czDs0ca8IRYu1d1E2f0Kbou4BtznFQ65z47s/x7Pv5IFzH0jG6sxxws3oqctOta ZxE64J2YdZkM8Te4f+4Hsz+gi6Ah+BhflmbVlyAPypCFYVkpMQiLIeW+VOYyqbsk oRnKBDwOArGyGbcYCGI5/ghzLo9LttJd9DIcCspWSGPAfgbev02NjlDrnSJLfwM0 p84PtPMlCmDiFObou0gSYadpKNNV9Lz+MCdUotw/A2Yh4BnHvCFmvwQhicyMDauS SrQ0f/IL5tH+L4m1D1txCYKtV1Ot9ptnf2W5E0Zv7+xxYiUzVsY= =Uz8u -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 11 15:35: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 24249132668 for ; Fri, 11 Aug 2017 15:35: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, 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 QGTpiSyAC1Nt for ; Fri, 11 Aug 2017 15:35:26 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 3A1C413264B for ; Fri, 11 Aug 2017 15:35:26 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id p68so30247872ywg.0 for ; Fri, 11 Aug 2017 15:35: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=6Us0CwIKBAe1qDfPPtCajQSWrdpWAPAFRKc1ootqaD8=; b=WZJfSOC57tzLFLxrch6fIG3gvDm11SCjSvOCSFPYleNBVkyvc13d+4iIIllfx8Op2d U52nyTcZqhxDjgFbjd7hh21pg7zJSxOhX50QRlGHE22/dZScDz/b9mt1dUTnCK3PJQ5Y EWIXvhO9ywx202SSpl8mG6/k/lg63KqZgFPlKSi0BK8vUIbsxck7BKPO+ACEzQtJAeDC IaHqdo9mLyYBVg5YMJiLxw44TEGHLUpsTYeLoZQmMQOGZPBbbYg34RYmeLJYQAnELb++ 46WiTu4FZp31sXk3ZIgw+kkCH4XADVEUUrBl9U/7uSRdUFJICjQ2yApciOqhGQ3/OebK Wstg== 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=6Us0CwIKBAe1qDfPPtCajQSWrdpWAPAFRKc1ootqaD8=; b=FUQ4b5it8U9z6UWOLVKcf4Zql52kdKqg6PkcDppGBL1QKPCvKEZ6prVspb0sREEekh KHBv8L9Gaq00J6LblsYn4mo2XdUI26nafZLpfTuZRQL/e4ApIEi/RvJ3l/XiNTsbiRPw WBezmhCkLDzZ85HdZofZBzoT3n2hlM0DyuNyveolS9riY+LupygUOhQGAb2hxSA6S0fP fkvUZxHNT58x/nz/kP9hMPaU1mZpPb0EloOWx7W4bC8XJ0c15E14bz6/RIc8+h9WZ/xH ZNXmwkqrrLfIsPRRv9WegUouH3vM5uF7AVlHMS9gYDMxv7gb6Lqzgbgys5iXcS+TnK7G WyjQ== X-Gm-Message-State: AHYfb5iQLvkfsWETpITZxsxqHzwTDaBUA2ef1FvNVDOAYoet5AX+5/am E1kCyKZbRWMOpiyx4Em6mBYrIAHS4mGD6eQ= X-Received: by 10.13.251.3 with SMTP id l3mr14446331ywf.71.1502490925512; Fri, 11 Aug 2017 15:35:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 11 Aug 2017 15:34:45 -0700 (PDT) In-Reply-To: <72964498-cbde-2bb1-75fa-cf8d2551e8aa@levangong.org> References: <72964498-cbde-2bb1-75fa-cf8d2551e8aa@levangong.org> From: Eric Rescorla Date: Fri, 11 Aug 2017 15:34:45 -0700 Message-ID: To: "Le Van Gong, Hubert" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07f036e4da18055681ede6" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: actual early data... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2017 22:35:29 -0000 --94eb2c07f036e4da18055681ede6 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 2:56 PM, Le Van Gong, Hubert wrote: > Hithere, > > While looking into leveraging early data, it occurred to me that the > actual effectiveness of 0-RTT is going to be highly dependent on > implementationdetails. > > In section 2.3 (Zero-RTT Data) -tls13-21 [1], the first sentence says "TLS > 1.3 allows clients to send data on the first flight ("early data")" which I > initially interpreted as "you can send data in the ClientHelloitself.Part > of figure 4 (reproduced below), seemed to confirm my perceptionthat > Application Data is indeed in the ClientHello msg: > > -------- > ClientHello > + early_data > + key_share* > + psk_key_exchange_modes > + pre_shared_key > (Application Data*) > -------- > No, it's not. That's the meaning of the phrase "first flight" as opposed to "in the ClientHello" > Alas, upon experimentation (using latest OpenSSL), we've observed that our > early data (no matter how small) gets shipped in a separate TCP packet > after the TCP packet containing the ClientHello. This becomes a significant > performance hit when the underlying network stack uses something like the > Nagle algorithm (or similar [2]) because the TCP packet with early data > will only be sent *after* a server TCP ACK (for the ClientHello) has been > received by the client. So much for zero roundtrip in that case. > > It is not a lot of effort to modify the OpenSSL client (and server) to not > delay the early data TCP packet but it something not everyone will be > comfortable doing, esp. in an enterprise setting. > This seems like a not that appropriate test: anyone who is doing 0-RTT really needs to know what they are doing (for reasons the draft lays out in pretty excruciating detail) and should at least be capable of managing their writes to TCP. It's not like they're using s_client. Looking into the data structure of ClientHello, I could not find a place to > put early data either: the ClientHello early_data extension can only > contain an empty EarlyDataIndication structure. > > I wonder what was the rationale for not allowing the early_data extension > to contain actual data? > Was the intent to preserve protocol cleanliness? i.e., ClientHello is a > handshake protocol message and the early data is a Record protocol message? > Amongst other things. In particular, we wanted to enable streaming of early data and then it obviously can't be part of the ClientHello, unless you want to allow it in two places. We actually did have some support for this kind of thing in early versions but it was really hard to reason about and implement. -Ekr > > > Cheers, > Hubert & Jeff > > > [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-2.3 > [2] https://en.wikipedia.org/wiki/Nagle%27s_algorithm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c07f036e4da18055681ede6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 11, 2017 at 2:56 PM, Le Van Gong, Hubert = <hubert@levang= ong.org> wrote:
Hithere,
While looking into leveraging early data, it occurred to me that the actual= effectiveness of 0-RTT is going to be highly dependent on implementationde= tails.

In section 2.3 (Zero-RTT Data) -tls13-21 [1], the first sentence says "= ;TLS 1.3 allows clients to send data on the first flight ("early data&= quot;)" which I initially interpreted as "you can send data in th= e ClientHelloitself.Part of figure 4 (reproduced below), seemed to confirm = my perceptionthat Application Data is indeed in the ClientHello msg:

--------
ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*)
--------

No, it's not. That's t= he meaning of the phrase "first flight" as opposed to "in th= e ClientHello"

=C2=A0
Alas, upon experimentation (using latest OpenSSL), we've observed that = our early data (no matter how small) gets shipped in a separate TCP packet = after the TCP packet containing the ClientHello. This becomes a significant= performance hit when the underlying network stack uses something like the = Nagle algorithm (or similar [2]) because the TCP packet with early data wil= l only be sent *after* a server TCP ACK (for the ClientHello) has been rece= ived by the client. So much for zero roundtrip in that case.

It is not a lot of effort to modify the OpenSSL client (and server) to not = delay the early data TCP packet but it something not everyone will be comfo= rtable doing, esp. in an enterprise setting.

This seems like a not that appropriate test: anyone who is doing 0-RT= T really needs to know what they are doing (for reasons the draft lays out = in pretty excruciating detail) and should at least be capable of managing t= heir writes to TCP. It's not like they're using s_client.


Looking into the data structure of ClientHello, I could not find a place to= put early data either: the ClientHello early_data extension can only conta= in an empty EarlyDataIndication structure.

I wonder what was the rationale for not allowing the early_data extension t= o contain actual data?
Was the intent to preserve protocol cleanliness? i.e., ClientHello is a han= dshake protocol message and the early data is a Record protocol message?

Amongst other things. In particular, we w= anted to enable streaming of early data and then it obviously can't be = part of the ClientHello, unless you want to allow it in two places. We actu= ally did have some support for this kind of thing in early versions but it = was really hard to reason about and implement.

-Ek= r

=C2=A0


Cheers,
Hubert & Jeff


[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-2.3
[2] https://en.wikipedia.org/wiki/Nagle%27s_al= gorithm

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

--94eb2c07f036e4da18055681ede6-- From nobody Mon Aug 14 00:12: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 88FD5131CF2 for ; Mon, 14 Aug 2017 00:11:59 -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 iMBVmkjvKHxQ for ; Mon, 14 Aug 2017 00:11:57 -0700 (PDT) Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com [209.85.128.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42B7C131D24 for ; Mon, 14 Aug 2017 00:11:57 -0700 (PDT) Received: by mail-wr0-f180.google.com with SMTP id y41so6884519wrd.3 for ; Mon, 14 Aug 2017 00:11:57 -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:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=taCyjqW26Nv/Iy74gEMGnRZwAflM9c2YKBDosATe0Co=; b=Vu2rEltnF+gr2dUwW04gt1Dcs0gp/D0GVFfB9MM1N+3wwRQVrohteDnXReZaitH7KY SeurVDZXXrcse9aZRe7H9QkLaavwuGsr+WAUNSoU13nHNmaDBpLB85w46+LXinoS8u9Q woe+xQKYSttgj9RMJlkuhvnCtJVPHpXRyABW8C1UDlLTfMacLsJN9gFQx7kQ3roewo7r GiFdxiXTdWen1IOsMYZR9VM/9gjoO33qzpkH874rmSLti/vOWWQCdaUzFon8/ivczQ6E ElKpX2ADX2NIfSnp3k+LykY1d33qhOfQ3hTIuFbgy5F59BSUfodh5zvLCjw8nJNGXHLP 6aKw== X-Gm-Message-State: AHYfb5hZjBXjZRSGdGLKkhjm7k2TLiwqrhVGB9pxvz0/SmbeYKezUWAe Pxk1n6Si3S5dxL7qZlQRLQ== X-Received: by 10.223.179.71 with SMTP id k7mr16982711wrd.232.1502694715670; Mon, 14 Aug 2017 00:11:55 -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 m4sm7093186wmf.2.2017.08.14.00.11.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 14 Aug 2017 00:11:54 -0700 (PDT) Message-ID: <1502694713.4288.3.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Daniel Kahn Gillmor , "Short, Todd" Cc: "tls@ietf.org" Date: Mon, 14 Aug 2017 09:11:53 +0200 In-Reply-To: <87shgyndtw.fsf@fifthhorseman.net> References: <1502460670.3202.8.camel@redhat.com> <075C47B6-A601-441F-B881-A7F78648B5F1@akamai.com> <87shgyndtw.fsf@fifthhorseman.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.4 (3.24.4-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Aug 2017 07:12:00 -0000 On Fri, 2017-08-11 at 14:45 -0400, Daniel Kahn Gillmor wrote: > On Fri 2017-08-11 18:43:15 +0200, Nikos Mavrogiannopoulos wrote: > > I don't argue with this but this is not the approach TLS 1.3 took. > > It > > provides a generic padding mechanism to be used across application > > protocols. > > The design approach that TLS 1.3 took was to provide a mechanism for > padding at the TLS layer, not to prescribe padding at the application > layer. You actually probably need both to defend against traffic > analysis in the big picture. > > Thoughtful, well-designed application-layer padding is likely to be > better than generic TLS-layer padding. But not all applications can > actually accomodate padding (and it's not clear that folks have done > the > thoughtful work even on those applications which *can* accomodate > padding). > > TLS offers a generic mechanism to support the cases where the > application can't do padding, or where the implementer has no control > over (or insight into) the application itself. It'll probably leak > in > the way you describe, but it'll probably also be better than > cleartext. > > Furthermore, there are TLS messages that are not application data at > all -- so those parts *have* to be padded at the TLS layer, as the > application cannot directly affect their size. > > A robust and safe padding approach needs to take into account all > layers > of the stack at once and coordinate between them. Without the > padding > mechanism in TLS, it wouldn't be possible to coordinate across the > whole stack. Typically protocol design which is build on top of other protocols assumes that they operate as reasonably. I doubt a TLS implementor who knows about this timing leak will be the one designing the application protocol on top, so my bet is that we are going to see application protocols defined which take advantage of that padding and believing they offer a plaintext length protection. That's why, I'd urge to underline this timing leak in the document rather than hiding it in generic timing leak considerations text. We already have experience with that. TLS 1.1 documented a similar leak prominently: "Implementation Note: Canvel et al. [CBCTIME] have demonstrated a ..." Note however that documenting the problem itself didn't help in that case, all implementations were vulnerably to the later lucky13 attack. The best IMHO is to document the way to address the timing leak. regards, Nikos From nobody Mon Aug 14 11:03: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 E45D41323CA for ; Mon, 14 Aug 2017 11:03:16 -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 q9fbEiq4lRgE for ; Mon, 14 Aug 2017 11:03:15 -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 286D31323C9 for ; Mon, 14 Aug 2017 11:03:15 -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 C43A919D018 for ; Mon, 14 Aug 2017 18:03:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C43A919D018 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.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 923445D6A4 for ; Mon, 14 Aug 2017 18:03:14 +0000 (UTC) From: Hubert Kario To: "tls@ietf.org" Date: Mon, 14 Aug 2017 20:03:08 +0200 Message-ID: <1743998.0aoAkZaxpO@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1667039.Z2HyZ8NY0u"; 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.29]); Mon, 14 Aug 2017 18:03:14 +0000 (UTC) Archived-At: Subject: [TLS] OCSP status_request_v2 extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Aug 2017 18:03:17 -0000 --nextPart1667039.Z2HyZ8NY0u Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Current (21) draft references RFC 6961 in multiple places, in particular * Section 4.4.2: Valid extensions include OCSP Status extensions ([RFC6066] and [RFC6961]) * and therein implicitly: If an extension applies to the entire chain, it SHOULD be included in the first CertificateEntry. at the same time section B.3.1 ExtensionType and table from Section 4.2 do = not=20 list status_request_v2 as a valid extension. If the intention was to deprecate status_request_v2, I think the references= to=20 RFC 6961 should be a bit more cautious. If it wasn't (as old messages sent = to=20 the list would indicate), quite a bit of text is missing. =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 --nextPart1667039.Z2HyZ8NY0u 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 iQIcBAABCgAGBQJZkeXcAAoJEJKo0bgB0vX1BnEP/jpHgWzsJ6njOMzZ3xRqPMWn ybDLwL0xKTtDOQwllAlDD11CmxINf86CtNWraMfdrg4RR9zQObFNfgOWJ/whStcO ZNceoOIG8TLwyJsZxnHsaGAyjNjBVeMLNsX+ym6Dl4wKbv0t4l0tT5NxwA6oMdUo wio7nGJH9NV37uBxHNj446LRI9gSRcSq8cnAj1goc5ePE/aiE1PslWmz7o9SefCE 4Ra6T1RaOmd0+Q+PvKx3nfFmVkTmhByKzwoToU/iwpLsOG84FGd2Z4DZe8ADA/gM I55N0KTubMx6kixui4TxR6K9icDMiVxHq5BXuXIB7vXghFV+3iX4xGHLTzfzf6Qm x0SMcSRb4R1ny4jtHVc3NvPiDyipB9g/EcRE2X5zvFxXjLqL8l5Rl5cHgNSzdHR2 H+cEM0mc/eOYIduXPFiczoLjUZEF3P+L1nN98jumAIVk5qnKjmhvAGLEJ1qIqOlu 6Vz5gNsquIzj7EzCYbXbvU0YZaE95cCMtYFduy9BYYnQ/nPkroCKvR2ibyoDjByG PHtJe0G5Dh4d0tHdbWQJpaoOEulOi8kRoNu483wnDHk2Z4M0CW9hM3nI5lSU8L+B FeJ0OE4SM7K34bGWex5ucEVhkzJLrpt+/MMY1aJhYZ4cT58fi8tAfVWmsEL/gOBg xz/aXdRWkod2DR4eENRE =Q8h5 -----END PGP SIGNATURE----- --nextPart1667039.Z2HyZ8NY0u-- From nobody Mon Aug 14 11:07: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 A6BF91323CA for ; Mon, 14 Aug 2017 11:07:03 -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 aAmwmDZ2OzAR for ; Mon, 14 Aug 2017 11:07:02 -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 80B901323C9 for ; Mon, 14 Aug 2017 11:07:02 -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 F1232686AA; Mon, 14 Aug 2017 18:07:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F1232686AA 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 (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 54EFA5D967; Mon, 14 Aug 2017 18:06:59 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 14 Aug 2017 20:06:57 +0200 Message-ID: <1708503.gcSoZQpuhk@pintsize.usersys.redhat.com> In-Reply-To: References: <1502460670.3202.8.camel@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4110553.B2nBj1sAOJ"; 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.27]); Mon, 14 Aug 2017 18:07:02 +0000 (UTC) Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Aug 2017 18:07:03 -0000 --nextPart4110553.B2nBj1sAOJ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 11 August 2017 19:04:05 CEST Andrei Popov wrote: > * I don't argue with this but this is not the approach TLS 1.3 took. = It > provides a generic padding mechanism to be used across application > protocols. > At some point I thought we said that the TLS 1.3 padding > mechanism was supposed to be application-driven (in the form of > application-provided policy or simply desired pad size), which would mean > that the application has to be involved anyway.=20 Problem is, that the application doesn't know how much time did processing = of=20 the message took (even if it gets the information that the received message= =20 was padded, which is not possible with current common library APIs). So even if the application takes exactly as much time to process a long=20 request as it does to process a short request, the length of that processin= g=20 will leak. =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 --nextPart4110553.B2nBj1sAOJ 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 iQIcBAABCgAGBQJZkebBAAoJEJKo0bgB0vX18HIP/06VKtaSoeQQLFEe4iM19GxD rzvw/9NNFvWdHuQFpmx1yFtGEVjNTTRElr/7PgkbkyeE7qhVkvh6VrCts0+NNDR5 yEQlxz9qrxXudAEcJMoCLfl8062pWPmlsi7bF8SqiGyNQt8YKvLjG+g9YWVCHQf2 9EEpmI5wYchargD6ulRMSpxa8w42dv6jvZt4ppi7WpZhuOH+VdrOUxDO8u6SWzMr ozAQrPhE31Lt2ADilFgUtnof8AxXlZygqPiH4NnxzBBjxOIxxD6lUkSLsUXizWyU 1wwqG6G0RyUGoU8K4kttVlpbwJjFrPQFhkjDZSthD4bbZgWEYvgLmMgbAJ8q8t+S isHqxcJtRyedG9WEH1pZZIkiUguX4vXi1FrsfQxB5aisi9mc5d+fy/+NV9hX4MjS UwxdBZp9gUY2DLpR0Qpsx5idCDUFa5bDXHmZbEH6BMZ8LbzfUlwev3wNCCIWfhah Wo9Zu3BuzVs0KGsFg0mAOpNw13cX86TIJgmVYy4dfvPDbkWg/x+KrU16yQ+tC8z2 dk5QTknslh9U1O0ZZ9wHduodpDU+pJCzWCKo/jgxDB8sog9GjIgV/7DtMJboH5Xs tQcQxpkxPBlROvc5sSINz6P00ra6S73miCcw3Z+P1NTKByRhe/GcA73eKdL+CDLc lab5YBFc8QPLIXOGcDDC =JUFl -----END PGP SIGNATURE----- --nextPart4110553.B2nBj1sAOJ-- From nobody Mon Aug 14 11:16: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 A1B471323D3 for ; Mon, 14 Aug 2017 11:16:05 -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 OxCclpjtlUsC for ; Mon, 14 Aug 2017 11:16:04 -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 3FD7D1323C8 for ; Mon, 14 Aug 2017 11:16:04 -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 A5236B06A2; Mon, 14 Aug 2017 18:16:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A5236B06A2 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.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 482D86E507; Mon, 14 Aug 2017 18:16:03 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 14 Aug 2017 20:16:01 +0200 Message-ID: <2492694.vcgQpB2T86@pintsize.usersys.redhat.com> In-Reply-To: <14329E27-DBCC-4A6F-BB4C-7CFAFD7ADF53@akamai.com> References: <1502460670.3202.8.camel@redhat.com> <14329E27-DBCC-4A6F-BB4C-7CFAFD7ADF53@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1933778.G14JdJ80pV"; 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.39]); Mon, 14 Aug 2017 18:16:04 +0000 (UTC) Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Aug 2017 18:16:06 -0000 --nextPart1933778.G14JdJ80pV Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 11 August 2017 20:32:57 CEST Short, Todd wrote: > However, I argue that having TLS do significant padding for a protocol is > bad design for that protocol. It=E2=80=99s one thing if it=E2=80=99s a fe= w padding bytes, > but the example given was 1023 bytes of padding. the difference in processing that is equal to just few clock cycles is=20 detectable over network[1] =20 > Also as pointed out by Andrei Popov, the application needs to tell TLS how > much padding to apply, so either way, the application has to deal with > determining the padding length. Why not just make it part of the protocol > in the first place? The problem is not when the application adds padding. The problem is when t= he=20 padding is removed on the receiver side. =20 > But my final point is that we are ignoring the amount of non-TLS processi= ng > that must be done on various message types (before the response is sent), > and THAT might be even more of a giveaway than the minuscule timing > difference due to counting padding in TLS. Sure, it can, and in most cases it will be. We are not talking about this=20 situation. When you are careful on the application level (which is fairly simple when = you=20 just are sending acknowledgement message), the timing will still be leaked. =20 1 - https://www.imperialviolet.org/2013/02/04/luckythirteen.html (very bott= om) =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 --nextPart1933778.G14JdJ80pV 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 iQIcBAABCgAGBQJZkejhAAoJEJKo0bgB0vX1e8EP/3bmc/rMfR022CISk/oZuzaA MyEcGv4f62vzT/Ku82TWkk1CIIKXcJpTDF0+gPliSZuiv2YXmirhmRlqaSzmQ46k xwSIEVlp2LrE8C+iWBLcgpbaRRAMKBxss/cws+HXRbA2gJKR6vCTWD3+e8io/UlA iLZqBUTiW7EuieC2JDIdb6Qoqe9yuLvOAzyWfn0i/wP3OftaUaamMk66X2MvgSWd flRILmLzP2liVjH6/MaGFJLukCwEGOtNn1BrW0aWsRFkoOAnlpFiqTNN7OZDcaJJ RcIhXTNXwVnn0vSSIjL2OqI/QMRrjDlZATnH0ybLap6ylP6KOboG7MNJL8E6KjWC +0SSKAFM+NK9zYMyr18JDo9GMMAL2Ofg0C272ZuXPk2nHlnVamdALY8Jn01obbOv 9M2hDRIrR9isUcNqJRzkHu6pNNA22tPcbJTG7adSm4MSq301Un/m3EgIkHPxwXy7 CRSxLcWbY/tKdwPSjeZMFTgSwy0Z3gbbhUTh4Hc7kBEI698qa5gG80rznXzkNrcj B0bFEyuBeGI7rNucERymTyhGpD1GNgACyItmn7jOHoxxYiDEOvRqa0TENcCrWpje hcg12PFo5rF3vXO9+rzI/MAQenwwjuCFww6/sXriIhkRN0RLOukJ8fTSvoJ9VGON oQFU+Zf+LuHJaut4/b3S =d9ir -----END PGP SIGNATURE----- --nextPart1933778.G14JdJ80pV-- From nobody Mon Aug 14 11:26: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 7BADB1323B5 for ; Mon, 14 Aug 2017 11:26: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, 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 lVgbjJb9g2b0 for ; Mon, 14 Aug 2017 11:26:21 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 46E35132399 for ; Mon, 14 Aug 2017 11:26:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 58225ACD5E; Mon, 14 Aug 2017 21:26:19 +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 4iEP1SRYzD-u; Mon, 14 Aug 2017 21:26:19 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 054C027B; Mon, 14 Aug 2017 21:26:16 +0300 (EEST) Date: Mon, 14 Aug 2017 21:26:16 +0300 From: Ilari Liusvaara To: Hubert Kario Cc: "tls@ietf.org" Message-ID: <20170814182616.46cnqvpk3kmh4led@LK-Perkele-VII> References: <1743998.0aoAkZaxpO@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1743998.0aoAkZaxpO@pintsize.usersys.redhat.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] OCSP status_request_v2 extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Aug 2017 18:26:23 -0000 On Mon, Aug 14, 2017 at 08:03:08PM +0200, Hubert Kario wrote: > Current (21) draft references RFC 6961 in multiple places, in particular > * Section 4.4.2: > Valid extensions > include OCSP Status extensions ([RFC6066] and [RFC6961]) > * and therein implicitly: > If > an extension applies to the entire chain, it SHOULD be included in > the first CertificateEntry. > > at the same time section B.3.1 ExtensionType and table from Section 4.2 do not > list status_request_v2 as a valid extension. > > > If the intention was to deprecate status_request_v2, I think the references to > RFC 6961 should be a bit more cautious. If it wasn't (as old messages sent to > the list would indicate), quite a bit of text is missing. The introduction suggests that TLS 1.3 intends to deprecate status_request_v2. And indeed, if status_request_v2 was to be supported, extra text would be required. Like how to map the list of certificates inside the message to certificates sent. I think that clause about extensions to whole chain are more for things like server_certificate_type. Furthermore, in WebPKI, CA certificate OCSP is at best useless due to the very long response lifetimes. And getting the liftimes down to reasonable range is not realistic. -Ilari From nobody Mon Aug 14 15:55: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 B3EB2132448 for ; Mon, 14 Aug 2017 15:55:53 -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 7nK0flvOIlKo for ; Mon, 14 Aug 2017 15:55:52 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C84013241C for ; Mon, 14 Aug 2017 15:55:51 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id p68so63590143ywg.0 for ; Mon, 14 Aug 2017 15:55:51 -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=wBwfXLWocLfhwK6wosBB8avGImnFjSpp+UbONmCXDIM=; b=CmVYYFRLm1Qg+CORfKVoYHY5sCJLFGBCS1FI8H9TtOcMGT95i2rjKfnXqEIiazreDC 0Y3jwwQotY1fmvGPsjxt2AB8ugd638otcORWSUcnyIsxdQhn5wk0yDwqwTpIohqYk0ag 9BOcWwRDCH7vyXaxriXWgQR/Wv4DNDsrcToLOj8Otot1HybbGf4OuRoF9OrFjwLajzsJ u/wzCqd1ZFefHAGddb9n7CSPPnNYei3fspBh9YpuIaJ7kvPM6NJ3NOeIALcUYJkHb1h4 gDBspJdLjWnGZZ4Mhr73EnaWBWk9HtgP3d7/z1u0W8XSv+n/3RDDEkjrJGMoEpJ52rgp SOXQ== 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=wBwfXLWocLfhwK6wosBB8avGImnFjSpp+UbONmCXDIM=; b=crRfvCqrUMj5CJ//7D5az8znNx96Z8CKRCviZsC8QdQJ4zkcd+nGjrr0f7DBRGV8CP BD3CPXOMkwm094/dbXHu6RJ7qV9piQp1VUDdiEYcWJMn4Nby7vr6paVVbX1xzpZAai51 RBz0CGF7m6g3rJNJHfYzlGRJlzK9HJ6pRdMz4RcRjpBYmiMDFWngo/MbYJFeYPY+a5ri mQCz85drwpASffA4ysmwToTUVYll4an7CiSy2Q5rPGxWOZyI7XYU1zWk8ATqbk2afqYK iUrQf1OT29dOEsOu11cbW094evLnrAMvzqwxGDtPnhKII6vf5AoWz/cFCxgtsqL76Z1Z bmGA== X-Gm-Message-State: AHYfb5gqbKlLZw34AWMtIqgVRN7Ry/n3jEKy92c1dnOsdqgbLaa+n/UQ aJEg4hTM7yVxPYEFt3IRqs5f/hI3d3t/ X-Received: by 10.37.207.82 with SMTP id f79mr21571921ybg.103.1502751351013; Mon, 14 Aug 2017 15:55:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.71 with HTTP; Mon, 14 Aug 2017 15:55:50 -0700 (PDT) In-Reply-To: <2492694.vcgQpB2T86@pintsize.usersys.redhat.com> References: <1502460670.3202.8.camel@redhat.com> <14329E27-DBCC-4A6F-BB4C-7CFAFD7ADF53@akamai.com> <2492694.vcgQpB2T86@pintsize.usersys.redhat.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 15 Aug 2017 00:55:50 +0200 Message-ID: To: Hubert Kario Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Aug 2017 22:55:54 -0000 On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario wrote: > the difference in processing that is equal to just few clock cycles is > detectable over network[1] The post you reference actually says the opposite; "20 CPU cycles is probably too small to exploit" ... and even today with very low latency networks and I/O schedulers it remains very difficult to measure that kind of timing difference remotely. But per the post, the larger point is that it is prudent to be cautious. > When you are careful on the application level (which is fairly simple when you > just are sending acknowledgement message), the timing will still be leaked. There are application-level and tls-implementation-level approaches that can prevent the network timing leak. The easiest is to only write TLS records during fixed period slots. For example, suppose your process can handle 100 connections concurrently, then you can divide 1ms into 100 slots of 10 microseconds each. Every 1ms you have a writer thread or process 'visit' each connection (you may use an epoll/kqueue driven I/O loop or similar for this) during its fixed slot and send its pending output. -- Colm From nobody Tue Aug 15 04:55: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 4A39D132143 for ; Tue, 15 Aug 2017 04:55:49 -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 LHCwt0-Mowt5 for ; Tue, 15 Aug 2017 04:55:47 -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 2824A13208E for ; Tue, 15 Aug 2017 04:55:47 -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 AF51B6880E; Tue, 15 Aug 2017 11:55:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AF51B6880E 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 7E77E600CB; Tue, 15 Aug 2017 11:55:46 +0000 (UTC) From: Hubert Kario To: Colm =?ISO-8859-1?Q?MacC=E1rthaigh?= Cc: "tls@ietf.org" Date: Tue, 15 Aug 2017 13:55:40 +0200 Message-ID: <2019211.eGXEvq8HFX@pintsize.usersys.redhat.com> In-Reply-To: References: <1502460670.3202.8.camel@redhat.com> <2492694.vcgQpB2T86@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2632006.RnK4tyegLp"; 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]); Tue, 15 Aug 2017 11:55:46 +0000 (UTC) Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2017 11:55:49 -0000 --nextPart2632006.RnK4tyegLp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 15 August 2017 00:55:50 CEST Colm MacC=C3=A1rthaigh wrote: > On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario wrote: > > the difference in processing that is equal to just few clock cycles is > > detectable over network[1] >=20 > The post you reference actually says the opposite; "20 CPU cycles is > probably too small to exploit" exactly what we though about cbc padding at the time TLS 1.1 was published.= =2E. > ... and even today with very low > latency networks and I/O schedulers it remains very difficult to > measure that kind of timing difference remotely. simply not true[1], you can measure the times to arbitrary precision with a= ny=20 real world network connection, it will just take more tries, not infinite=20 tries > But per the post, the > larger point is that it is prudent to be cautious. exactly, unless you can show that the difference is not measurable, under a= ll=20 conditions, you have to assume that it is. > > When you are careful on the application level (which is fairly simple w= hen > > you just are sending acknowledgement message), the timing will still be > > leaked. > There are application-level and tls-implementation-level approaches > that can prevent the network timing leak. The easiest is to only write > TLS records during fixed period slots. sure it is, it also limits available bandwidth and it will always use that= =20 amount of bandwidth, something which is not always needed we are not concerned if the issue can be workarouded, we want to be sure th= at=20 the TLS stack does not undermine application stack work towards constant ti= me=20 behaviour 1 - http://www.isg.rhul.ac.uk/tls/TLStiming.pdf =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 --nextPart2632006.RnK4tyegLp 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 iQIcBAABCgAGBQJZkuE8AAoJEJKo0bgB0vX1ic8P/1m/QbEASLWHc4MtUUf1TFnr jiLvO0ADg6o4j8tj95/2rgXQS9XzH4j0f9m83OXxP/kJYUDBCCAE5IRloP25O8Oj t7oOmayeltLWsfI0F/id6rlp07MdO8qGxlotuVF/Zkyg36CoSx6v2mSDWYSWzHnB W/2yzmCjueKTUd2hRWMyCKaWlxY+jGh9gvPDJphoDTiK0I0ovsdDxN03D8mEK5fB tq/2UkiIwULnh21qpz2LZ76yZXcTanxx49ovLDcHTiW07QZ50HcFd0FR1Qcuv9yj 2rA3DogG3Dl+XZ9L3XrWHGCg58dleBZbCnjUunbnCp+3kPi8DPG30lEgCGmuTFBV 0DwhsvhoQszNRKw0gW0ylTQDQSGN/ALJug4VTwJ3NnTtF03opHwmoMwFybmCTefT g+5fYCCHoc2t7nnjOByVeXAkpWFNU1RZEdfRFioNwHnAh/7M/swOtSVOpyjo65qR o2v32LUdi55s1SjeqIoaekoFbpaA9FdMW5quvNvW9TM+lYcyeF8eSmgNeENNr/ez ItoozB9bvkOsu0igtf3cj3E7TZ3IklGCZUK+pPk0qbxLj6J8pk9ILByhULYno1Hd oMNbP5PjarVz3chvBU2XJ4TGDMxEbob0rsSi2mnE5MOCtrD8I0eopnK4ggyEu9YP 1P97+XvhNVQubIZFeuno =4rqz -----END PGP SIGNATURE----- --nextPart2632006.RnK4tyegLp-- From nobody Tue Aug 15 06:32: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 D4AC11321C4 for ; Tue, 15 Aug 2017 06:32:09 -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 ujK2-46NI1ZF for ; Tue, 15 Aug 2017 06:32:07 -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 990C41321BE for ; Tue, 15 Aug 2017 06:32:07 -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 E2660C29B5F1 for ; Tue, 15 Aug 2017 13:32:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E2660C29B5F1 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 2B7B161F2D; Tue, 15 Aug 2017 13:32:03 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 15 Aug 2017 15:31:56 +0200 Message-ID: <1853204.q6hYlzKLln@pintsize.usersys.redhat.com> In-Reply-To: <1502460670.3202.8.camel@redhat.com> References: <1502460670.3202.8.camel@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3168534.Jfy5HMcmGh"; 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]); Tue, 15 Aug 2017 13:32:07 +0000 (UTC) Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2017 13:32:10 -0000 --nextPart3168534.Jfy5HMcmGh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" I've created a Pull Request that introduces requirement for constant time=20 processing of padding and an example on how to do it: https://github.com/tlswg/tls13-spec/pull/1073 On Friday, 11 August 2017 16:11:10 CEST Nikos Mavrogiannopoulos wrote: > Imagine the following scenario, where the server and client have this > repeated communication N times per day: >=20 > client server > --X--> > <--Y-- >=20 >=20 > the client puts in X a message A of 1 byte or B of 1024 bytes, and pads > it to the maximum size of TLS record. The server replies with the > message "ok" (same every time), padded to the maximum size just after > it reads X. >=20 > However, TLS 1.3 detects the message size by iterating through all the > padding bytes, and thus there is a timing leak observed by the time > difference between receiving X and sending Y. Thus as an adversary I > could take enough measurements and be able to distinguish between X > having the value A or B. >=20 > While I'd expect these iterations to be unmeasurable in desktop or > server hardware, I am not sure about the situation in low-end IoT > hardware. Is the design choice for having the padding removal depending > on padding length intentional? >=20 > There is mentioning of possible timing channels in: > https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 > However I don't quite understand how is this section intended to be > read. The sentence for example: "Because the padding is encrypted > alongside the actual content, an attacker cannot directly determine the > length of the padding, but may be able to measure it indirectly by the > use of timing channels exposed during record processing", what is its > intention? Is it to acknowledge the above timing leak? >=20 > Shouldn't instead be guidance in section 'Implementation Pitfalls' on > how to remove padding in a way that there are no timing leaks? (the > timing leak here is not in crypto algorithms, but TLS itself). Ideally > TLS 1.3 itself shouldn't use data-size depending calculations itself > such as the one described here. >=20 > regards, > Nikos >=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 --nextPart3168534.Jfy5HMcmGh 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 iQIcBAABCgAGBQJZkvfMAAoJEJKo0bgB0vX1yBYP/RTFCMVQBXC5rgTEj/9/eeUW ozCJcZyezKGXtCytZueZg/NlxfS1kVmYu85rPkjDyauiPmsnJOwTn/v28/FM2V6/ vcCYWxLzSS835h9vKhEj4zpvzf2jwWvlrF+/0UUHAC0CATSRcaU6oCXs6D17bhJW uKhLFAXHt8z182SdmOLOjngnNEy4Os2aIMyVmzlu3AWnDVRqcCl3PMoNx7jVtpnQ BL2pYXHdRP1X8pxdSyRMauTLcnG1CQxGf+KZsmMbNkr5hfJmNzOoFpNazkZg5/fY 8yBKqse13hZUJGbGddbXoxD7iQTf7YHVnPEsAIeSBr1GDxZOaiZzarWPEp2PSFAh WL3DLJ0vvN8GAWCLhfy7SqR7x2fNLZj3/Yfifp43RkU2dKXExkp/qea5qXyiXwSl SilAkww14fyAYGoPnl2wM4Ilq/5y039Fua7A1tOdkvUzfyilA+1ItOQjRvDsrx9+ TTkCGFXn80Vn1dDmNduGjFJQBPYhbBIGWVpXC8/fpd8qOcM7slAlQT5PZHYCFX0k bR0wmTBoXzykVi3rWk/rrb/9306izqufagc8XXYQQaGugHWKRDLJwKtBWN0rbDJP GBN417vuQa/EYwThfx0XvUXVvdA2Cui0IuaYmSjG2a6XMy7awHNG3nFPND4ZNqLp yCoIbUHDcabcIhOdqZh/ =L8eq -----END PGP SIGNATURE----- --nextPart3168534.Jfy5HMcmGh-- From nobody Tue Aug 15 06:54: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 248E21321C0 for ; Tue, 15 Aug 2017 06:54:23 -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 Rr6r0TgvPHG9 for ; Tue, 15 Aug 2017 06:54:20 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6989E13219F for ; Tue, 15 Aug 2017 06:54:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 8E69E52790; Tue, 15 Aug 2017 16:54:18 +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 p7a3VxEqZMSn; Tue, 15 Aug 2017 16:54:18 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id E629A286; Tue, 15 Aug 2017 16:54:15 +0300 (EEST) Date: Tue, 15 Aug 2017 16:54:15 +0300 From: Ilari Liusvaara To: Hubert Kario Cc: tls@ietf.org Message-ID: <20170815135415.rxupa7zixqs3tt7c@LK-Perkele-VII> References: <1502460670.3202.8.camel@redhat.com> <1853204.q6hYlzKLln@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1853204.q6hYlzKLln@pintsize.usersys.redhat.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2017 13:54:23 -0000 On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote: > I've created a Pull Request that introduces requirement for constant time > processing of padding and an example on how to do it: > > https://github.com/tlswg/tls13-spec/pull/1073 -1 Except doing the depad in constant-time is useless if you just re- introduce the timing leaks at the next step. Actually not introducing timing leaks in TLS library requires special API for passing the data to application... API that has had no reason to exist so far, and is more complicated to use than current read or zerocopy callback APIs. And even if you have such special API, it is extremely doubtful how many applications could use it correctly. Constant-time processing of variable-length data is extremely hard (LUCKY13 anyone?) Oh, and then there are timing leaks when sending data too... -Ilari From nobody Tue Aug 15 07:16: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 4BFE3132626 for ; Tue, 15 Aug 2017 07:16:17 -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 4rc-Ynz1sxog for ; Tue, 15 Aug 2017 07:16:14 -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 71A281321D2 for ; Tue, 15 Aug 2017 07:16:14 -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 2BA336AAF3; Tue, 15 Aug 2017 14:16:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2BA336AAF3 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.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 916DE60601; Tue, 15 Aug 2017 14:16:12 +0000 (UTC) From: Hubert Kario To: Ilari Liusvaara Cc: tls@ietf.org Date: Tue, 15 Aug 2017 16:16:10 +0200 Message-ID: <15658972.z11fxi4GSl@pintsize.usersys.redhat.com> In-Reply-To: <20170815135415.rxupa7zixqs3tt7c@LK-Perkele-VII> References: <1502460670.3202.8.camel@redhat.com> <1853204.q6hYlzKLln@pintsize.usersys.redhat.com> <20170815135415.rxupa7zixqs3tt7c@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart25915195.tS1x7ihDYp"; 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.26]); Tue, 15 Aug 2017 14:16:14 +0000 (UTC) Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2017 14:16:17 -0000 --nextPart25915195.tS1x7ihDYp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 15 August 2017 15:54:15 CEST Ilari Liusvaara wrote: > On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote: > > I've created a Pull Request that introduces requirement for constant ti= me > > processing of padding and an example on how to do it: > >=20 > > https://github.com/tlswg/tls13-spec/pull/1073 >=20 > -1 >=20 > Except doing the depad in constant-time is useless if you just re- > introduce the timing leaks at the next step. Actually not introducing > timing leaks in TLS library requires special API for passing the data > to application... In C you pass data to application using pointer to memory location and a=20 length variable. Padding influences only the length variable value. How=20 exactly can you do that in _non_ constant time? > API that has had no reason to exist so far, and is > more complicated to use than current read or zerocopy callback APIs. with current read(3), you require the application to provide a buffer the s= ize=20 of the whole padded data, you copy the whole padded data, you return a leng= th=20 that truncates the content type and padding. I fail to see how is that a "special API" > And even if you have such special API, it is extremely doubtful how > many applications could use it correctly. Constant-time processing of > variable-length data is extremely hard (LUCKY13 anyone?) right, so because it is hard, we should just throw our hands in the air and= =20 walk away? The point is that, if possible, we shouldn't undermine the work of=20 applications that *do* have constant-time processing of variable-length dat= a. =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 --nextPart25915195.tS1x7ihDYp 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 iQIcBAABCgAGBQJZkwIqAAoJEJKo0bgB0vX1EqkP/0/npJSNe2YFjQBq1OZymtyy qZ4CdCgk1f80FEdEOS4YFoPxx8/Le/VT3MAaJB1sntmWdHv4fBA8T40PjNJ8yoft wSt09CdemH7fZ1akbfTK77i22sFd6bfhjfwVYSA0AnM42G9dPoyA+oogTIIv44Pd DCzknXhvUv94yY7sJou1bSFxEF4qwQZ7yizdWBTRV98dmP/jD60ZyOyPg559UccF +rw99YHENMAodnCED1xBkfrtU+nwxxIlXECh9gSn4SEFc23bZl9lEptzH3Unk4GW BU/Ekc79RsTlYpws5YhhKNRKjrizEQ34ZwP7TNVhJwUqxQD+GD8bTVmdn9Nt/M3z Q4bHEBHIZWwF5ta7CzdVY4+laRkOUZacmH2pVJ4JuMpozkCq3z02RFO1Dl7mSYVf cRR1VeMjp3qwFE7nSDnLAuD18gOlXGiVofSUbHi/Dq555eITlnMi9TBoV49NOdRb 4LBc0qKONF/XDL8bgpPNnfKrBvx3u5xNtTw7LULgMOlHqxNaLd/B9Yyjl9aKZOrF 5UE0Soh8EWXIm3vi1006ri0I/HrF5g+CsX//joOCNsRKda7ylEjT7W0AOyO7lTWp ERjyvm2CSwYiRbHdDLUfN/Qzrkyc7TbE6yg22h/CRU1KwtlNSwp0sPSNCAqjw+pA fes2vEiU3Drieah4nBvY =MQQx -----END PGP SIGNATURE----- --nextPart25915195.tS1x7ihDYp-- From nobody Tue Aug 15 08:29: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 E329E1321D8 for ; Tue, 15 Aug 2017 08:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.981, 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 QHYuvJneFuQX for ; Tue, 15 Aug 2017 08:29:04 -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 CD7A1132332 for ; Tue, 15 Aug 2017 08:29:03 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id u207so6717356ywc.3 for ; Tue, 15 Aug 2017 08:29:03 -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=zIsIV9wrny+Wmm7e3qCDQSjVr80S+EvgWYMsya20WCI=; b=MCNqeHNluQLgD09Fl/TUoOWbeOI/yB5N7mek9koSDb+3u4O0GwGv5UaGA0YHRvZ67D XEhPrpvaRA7ebdPcLomyUD+E5FYbyl8Qt+NLIP7Gl9fort3Rl1N7D4ycGUtsKytypNkL GhrekEaThPo6hcLfMA/iy0aj1XyLFsNrCs2G46T+06R5pX0uNKI6IPy68Iyu/OJHQcgX E23hv1f7eqoPjbL9weHMybKXjeyQgtYPCpIi86oXTEOCoItGkf2S1rv+XmjongByZwnL 8JE6VXXBwWMwo8K5UdgSUbRXXyw3CjjdJK61CuuetL0bjnuNBhdulE3siQqXlNwvcf9k apJw== 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=zIsIV9wrny+Wmm7e3qCDQSjVr80S+EvgWYMsya20WCI=; b=AZ5Z1WY94FOEgk9a68/1rsavURAjYYbvy8DKKCiSkos/5rTGJDeBe0ZhxsTUhjFSOR xiYZL34/YfnLjYi/hINwLtqg0MKrsQtgxfmA6QyYUP/Phg5ma1htF8QZI16HNb7WsYSw bZZZeIQsW2DiJKXuZ9lWbYIlGdyT2umffNE3c1qAMb3s9Unfg5fu47Up67oHvIA6EDZP 6vha7QgQzGaifaUfuK9Km7iEAKgpvbDfBcvrfcP4Ywn/EgAjFsifBTiSF9YtLMavzXUX QSR7QtDVZeBm6i1FT/tt+VtIH6m7ZP9f6mLAznLn5xSRLJdipADeiRlmpfkiCFEb0pag p8ug== X-Gm-Message-State: AHYfb5jUzz6uSHDLtaIVkICYeTFQMoBAS9ClkRwZ1k2OIru0iCeQatJw 6jnjc3tfqahFcRnwb/7IPvyFDKgxpD5F X-Received: by 10.37.248.12 with SMTP id u12mr23211449ybd.248.1502810943077; Tue, 15 Aug 2017 08:29:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Tue, 15 Aug 2017 08:28:22 -0700 (PDT) In-Reply-To: <20170815135415.rxupa7zixqs3tt7c@LK-Perkele-VII> References: <1502460670.3202.8.camel@redhat.com> <1853204.q6hYlzKLln@pintsize.usersys.redhat.com> <20170815135415.rxupa7zixqs3tt7c@LK-Perkele-VII> From: Eric Rescorla Date: Tue, 15 Aug 2017 08:28:22 -0700 Message-ID: To: Ilari Liusvaara Cc: Hubert Kario , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045db8666d487f0556cc70e6" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2017 15:29:07 -0000 --f403045db8666d487f0556cc70e6 Content-Type: text/plain; charset="UTF-8" I generally agree with Ilari. To recap what I said on the PR: I think it would be fine to sharpen the point about padding leaking information and I'd take a short PR for that. I don't believe it's necessary either to require that it be constant time (for the reasons I indicated on-list and already documented in the spec) or to describe a specific algorithm, especially at this point on the document life cycle. -Ekr On Tue, Aug 15, 2017 at 6:54 AM, Ilari Liusvaara wrote: > On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote: > > I've created a Pull Request that introduces requirement for constant time > > processing of padding and an example on how to do it: > > > > https://github.com/tlswg/tls13-spec/pull/1073 > > -1 > > Except doing the depad in constant-time is useless if you just re- > introduce the timing leaks at the next step. Actually not introducing > timing leaks in TLS library requires special API for passing the data > to application... API that has had no reason to exist so far, and is > more complicated to use than current read or zerocopy callback APIs. > > And even if you have such special API, it is extremely doubtful how > many applications could use it correctly. Constant-time processing of > variable-length data is extremely hard (LUCKY13 anyone?) > > Oh, and then there are timing leaks when sending data too... > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403045db8666d487f0556cc70e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I generally agree with Ilari. To recap what I sa= id on the PR:
I think it would be fine to sharpen= the point about padding leaking information and I'd take a short PR fo= r that. I don't believe it's necessary either to require that it be= constant time (for the reasons I indicated on-list and already documented = in the spec) or to describe a specific algorithm, especially at this point = on the document life cycle.

-Ekr



On Tue, Aug 15, 2017 at 6= :54 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wr= ote:
On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote:
> I've created a Pull Request that introduces requirement for consta= nt time
> processing of padding and an example on how to do it:
>
> https://github.com/tlswg/tls13-spec/pull/1073=

-1

Except doing the depad in constant-time is useless if you just re-
introduce the timing leaks at the next step. Actually not introducing
timing leaks in TLS library requires special API for passing the data
to application... API that has had no reason to exist so far, and is
more complicated to use than current read or zerocopy callback APIs.

And even if you have such special API, it is extremely doubtful how
many applications could use it correctly. Constant-time processing of
variable-length data is extremely hard (LUCKY13 anyone?)

Oh, and then there are timing leaks when sending data too...


-Ilari

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

--f403045db8666d487f0556cc70e6-- From nobody Tue Aug 15 09:27: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 114F613234E for ; Tue, 15 Aug 2017 09:27:32 -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 WQO-JCs-sfFU for ; Tue, 15 Aug 2017 09:27:29 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 05862132357 for ; Tue, 15 Aug 2017 09:27:29 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id s143so7726645ywg.1 for ; Tue, 15 Aug 2017 09:27:28 -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:content-transfer-encoding; bh=SpxpZc9jCPwdAQyZ979ETDtz8uMHm4ZYpJWy2dhp4Nw=; b=ubn9FPRMCsiCTGNZ6e0au45hCl0xEjedNQPUTaFmN4MB6xBFAQ1DAPALBMXsi1QIDH egAg+9j/3NX12YReeZr0owMRDqw8bWTmOcMkfJIHQj5tiBHpOKJgBxpHdBAjLQjNmffD Ft782/ulzhY3JDbqYyuPFFNLadfSg0MlzL2AtgMQtn1ztKZMr+aaMyoweK4LJnN0TCy5 TipbW98zBvhYwxSL1L5iXnQosU0MWnaPs6jzBlh0ssX0jPn4AdxaaAla830ZHs44vDVl TKuS/Bx5r3p4Px+Taek5Mf/kf3zUw3yjwEBjBsUPzUT0OFKKx5JfoEzwftwFf7jRJFXj 5ISA== 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=SpxpZc9jCPwdAQyZ979ETDtz8uMHm4ZYpJWy2dhp4Nw=; b=aJWDdTXJVphpPi3dW6mG2DjIBMzSHENfn+uEWQtsYDfZvdZ1FHIcBKb2noR1SOOHaf QnC356faBaDlA3CdJf3gNgrJSyr/crN5OHUCZjJfkgaY1rWPZzGRqh8/fflq+WH926ma r9o9gLzECEIFOrgfubngG8dzSNza5eswFfMi06NcfTMKy2ZJWiXpzyxgSdnCiTzH25XG NSf9IEE0sbmFUkSNmDpKhAOPPrAJ6RTlvmx4YOyJta652155nKLtZkszPa+P7tE3Spwu i5I2EBGdMS7jAlKQyGoemWHN0jGzGVssGFUeNHC+2jz9XUwAiN4IXuHzJ6fd4UfnMz0M 91NA== X-Gm-Message-State: AHYfb5h8Cu0KW7+dKKMYNSqFkamqLJ9F4k3U43l0bAjG67pp+1F5Oig/ HJDHGFfJeAjcZ5TGM0jvv2WVGY44CI2s X-Received: by 10.37.164.68 with SMTP id f62mr22250623ybi.25.1502814448032; Tue, 15 Aug 2017 09:27:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.71 with HTTP; Tue, 15 Aug 2017 09:27:27 -0700 (PDT) In-Reply-To: <2019211.eGXEvq8HFX@pintsize.usersys.redhat.com> References: <1502460670.3202.8.camel@redhat.com> <2492694.vcgQpB2T86@pintsize.usersys.redhat.com> <2019211.eGXEvq8HFX@pintsize.usersys.redhat.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 15 Aug 2017 18:27:27 +0200 Message-ID: To: Hubert Kario Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2017 16:27:32 -0000 On Tue, Aug 15, 2017 at 1:55 PM, Hubert Kario wrote: > On Tuesday, 15 August 2017 00:55:50 CEST Colm MacC=C3=A1rthaigh wrote: >> On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario wrote: >> > the difference in processing that is equal to just few clock cycles is >> > detectable over network[1] >> >> The post you reference actually says the opposite; "20 CPU cycles is >> probably too small to exploit" > > exactly what we though about cbc padding at the time TLS 1.1 was publishe= d... I'm not going to defend the poor design of TLS1.1 padding, but it does remain unexploitable over real-world networks. The Lucky13 attack that you reference is practical against DTLS, but not TLS. It is worth understanding the nuance, because the differences can help us continue to make TLS more robust and hint where to optimize. The property that has protected has TLS Vs DTLS is non-replayability, so it's important we keep that. >> ... and even today with very low >> latency networks and I/O schedulers it remains very difficult to >> measure that kind of timing difference remotely. > > simply not true[1], you can measure the times to arbitrary precision with= any > real world network connection, it will just take more tries, not infinite > tries Surely the Nyquist limits apply? The fundamental resolution of networks is finite. Clock cycles are measured in partial billionths of a second, but even 10Gbit/sec networks use framing (85 byte minimum) in a way that gives you a resolution of around 70 billionths of a second. Nyquist says that to measure a signal you need a sampling resolution twice that of the signal itself ... that's about 2 orders of magnitude of distance to cover in this case. >> But per the post, the >> larger point is that it is prudent to be cautious. > > exactly, unless you can show that the difference is not measurable, under= all > conditions, you have to assume that it is. > >> > When you are careful on the application level (which is fairly simple = when >> > you just are sending acknowledgement message), the timing will still b= e >> > leaked. >> There are application-level and tls-implementation-level approaches >> that can prevent the network timing leak. The easiest is to only write >> TLS records during fixed period slots. > > sure it is, it also limits available bandwidth and it will always use tha= t > amount of bandwidth, something which is not always needed Constant-time schemes work by taking the maximum amount of time in every case. This fundamentally reduces the throughput; because small payloads don't get a speed benefit. > we are not concerned if the issue can be workarouded, we want to be sure = that > the TLS stack does not undermine application stack work towards constant = time > behaviour The TLS stack can take a constant amount of time to encrypt/decrypt a record, regardless of padding length, but it's very difficult to see how it can pass data to/from the application in constant time; besides the approach I outlined, which you don't like. Note that these problems get harder with larger amounts of padding. Today the lack of padding makes passive traffic analysis attacks very easy. It's extremely feasible for an attacker to categorize request and content lengths (e.g. every page on Wikipedia) and figure out what page is user is browsing. That's a practical attack, that definitely works, today, and it's probably the most practical and most serious attack that we do know works. The fix for that attack is padding, and quite large amounts are needed to defeat traffic analysis. But that will make the timing challenges harder. In that context: it's important to remember; so far those timing attacks have not been practical. We don't want to optimize for the wrong problem. --=20 Colm From nobody Tue Aug 15 10: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 EFFEF132376 for ; Tue, 15 Aug 2017 10:02:19 -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 XVpJQqgC-yNr for ; Tue, 15 Aug 2017 10:02: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 13EE5132194 for ; Tue, 15 Aug 2017 10:02:17 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E5F3272D8F; Tue, 15 Aug 2017 17:02:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E5F3272D8F Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.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 290E5516F0; Tue, 15 Aug 2017 17:02:16 +0000 (UTC) From: Hubert Kario To: Colm =?ISO-8859-1?Q?MacC=E1rthaigh?= Cc: "tls@ietf.org" Date: Tue, 15 Aug 2017 19:02:13 +0200 Message-ID: <4822293.CXcAoRAZci@pintsize.usersys.redhat.com> In-Reply-To: References: <1502460670.3202.8.camel@redhat.com> <2019211.eGXEvq8HFX@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart375709707.fL5kNvt3Ml"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 15 Aug 2017 17:02:17 +0000 (UTC) Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2017 17:02:20 -0000 --nextPart375709707.fL5kNvt3Ml Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 15 August 2017 18:27:27 CEST Colm MacC=C3=A1rthaigh wrote: > On Tue, Aug 15, 2017 at 1:55 PM, Hubert Kario wrote: > > On Tuesday, 15 August 2017 00:55:50 CEST Colm MacC=C3=A1rthaigh wrote: > >> On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario wrot= e: > >> ... and even today with very low > >> latency networks and I/O schedulers it remains very difficult to > >> measure that kind of timing difference remotely. > >=20 > > simply not true[1], you can measure the times to arbitrary precision wi= th > > any real world network connection, it will just take more tries, not > > infinite tries >=20 > Surely the Nyquist limits apply? The fundamental resolution of > networks is finite. Clock cycles are measured in partial billionths of > a second, but even 10Gbit/sec networks use framing (85 byte minimum) > in a way that gives you a resolution of around 70 billionths of a > second. Nyquist says that to measure a signal you need a sampling > resolution twice that of the signal itself ... that's about 2 orders > of magnitude of distance to cover in this case. Nyquist applies to a single sample, not to multiple sampling of the same=20 signal. In other words, if I sample a signal 4 times, and once I get 0 and 3 times = I=20 get 1, then assuming uniform distribution[1] I can deduce that the signal i= s=20 closer to 0.75 than it is to 1, 0 or 0.5. 1 - yes, it's a "spherical cow in a vacuum" example > >> But per the post, the > >> larger point is that it is prudent to be cautious. > >=20 > > exactly, unless you can show that the difference is not measurable, und= er > > all conditions, you have to assume that it is. > >=20 > >> > When you are careful on the application level (which is fairly simple > >> > when > >> > you just are sending acknowledgement message), the timing will still= be > >> > leaked. > >>=20 > >> There are application-level and tls-implementation-level approaches > >> that can prevent the network timing leak. The easiest is to only write > >> TLS records during fixed period slots. > >=20 > > sure it is, it also limits available bandwidth and it will always use t= hat > > amount of bandwidth, something which is not always needed >=20 > Constant-time schemes work by taking the maximum amount of time in > every case. This fundamentally reduces the throughput; because small > payloads don't get a speed benefit. My point is that if I don't care about the side channel of presence or abse= nce=20 of the communication, then I am limited by the size of the maximal record, = not=20 amount of records I can send in a second. So my bandwidth is limited in=20 "Transaction Per Second" sense, not actual bandwidth (measured in bytes per= =20 second) =20 > > we are not concerned if the issue can be workarouded, we want to be sure > > that the TLS stack does not undermine application stack work towards > > constant time behaviour >=20 > The TLS stack can take a constant amount of time to encrypt/decrypt a > record, regardless of padding length, but it's very difficult to see > how it can pass data to/from the application in constant time; besides > the approach I outlined, which you don't like. As I said in a different email, in C you pass a pointer and length, that ca= n=20 be returned in constant time quite easily (even in read(3)-like API). encryption is indeed much harder > Note that these problems get harder with larger amounts of padding. > Today the lack of padding makes passive traffic analysis attacks very > easy. It's extremely feasible for an attacker to categorize request > and content lengths (e.g. every page on Wikipedia) and figure out what > page is user is browsing. That's a practical attack, that definitely > works, today, and it's probably the most practical and most serious > attack that we do know works. The fix for that attack is padding, and > quite large amounts are needed to defeat traffic analysis. But that > will make the timing challenges harder. In that context: it's > important to remember; so far those timing attacks have not been > practical. We don't want to optimize for the wrong problem. True, that being said, I'd prefer if we did release protocol in which we ca= n't=20 poke holes before the official release... =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 --nextPart375709707.fL5kNvt3Ml 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 iQIcBAABCgAGBQJZkykVAAoJEJKo0bgB0vX1qPcQAJdIdl6yNxYlbAp9iUpT1gmT zTndplcMVIG8V7JLAcWkJchoxk5zqbQDudl/lUaMuxluiO/kwayy/6UIwmVhnIpq UUJ1XhUujjze4Pa6f0KIfWGefc1hOqMN8RCUEnNIOP/TzXcXV1oVA+P9s3T3WRIl knIRA/0oTsIXxjJ56n/yCjXH3JwarOkPq6L37jX8RJHpLA3C9f5LBh/rGuOmsS+t nNqxEhYj9zpVeJFpcQlai1ou/phtRMnFzaKP5m00eMRJ60bP9nhhToX1ChKman1D iLRZJLlFdLCeufCljkJajLa87i61CjUjgU7igsG9kbeZsoyMnQY7r6rO6NmgTx9Z /bkMnu0jI3CuICEbUIezENHluPwVxJuOogPo7ZGCOyw+48/9f9cVmgr34ItcF6KL NrPXAUpi++XI1ccSxwKH2urpisDx0jYb2rL4vicT20o+IBwMKEN/kpTyklNbqc/c G3PAviK7fq0cO+Pp9m6fJ35fRRjcjz9ippahoFeQhF1w9Dq0byPMHi/ktLAY/n1o bT/PEJYkQMcZktgsioniPpv6D6k243+fA3rDd6tgUhAmYDCc85+lzZHrMJCj5ISl SlDA0AuwsDg5+4M3p62VUdabhZY2125dl5VW3Qs2rWuDEJvfIc2fI8ZPGKrXr7T4 q9tFlm8LiPt0PghtDepL =vvtr -----END PGP SIGNATURE----- --nextPart375709707.fL5kNvt3Ml-- From nobody Tue Aug 15 10:42: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 761E5124207 for ; Tue, 15 Aug 2017 10:42: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 qOtwhEBgSWGK for ; Tue, 15 Aug 2017 10:42: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 06F28120713 for ; Tue, 15 Aug 2017 10:42:33 -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 v7FHgWcT010474; Tue, 15 Aug 2017 18:42: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=85xT0pSF3t+wVRfV5f6NkY2CyMjG1/1oULPtjrJXXaY=; b=XMwdgXBlygaPPgIShYzlIynuCpAcRXlThgWrUs71TMcqL3zK3UBiHgCf9Y/yq8ayQlAG KdlWLGI682WKmvZgci51q+K2xZFoIB6x2dkrMOWxfyOduwsbSHxzR2IPrqmgRwMeWVCU kHQvaFApQZGjAunDy7hkw4jpcNX04cyKpxWcIJhkgk1Snu6AeUVRzmEn4LoWxhsDPkaB WqGhFkDCWtuG5zecE2QM9lvRlHXhQ1iHj2Hsd+5kyOhqoIvR7ejhlVJnKkb7Z11AcHsT Ybi9J0HBds4MwjjTiYHRuNJf40qZ5g/oltyKNvy8ao1iUUYm2n27ZcA2XEbKW9DAdGsb MQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2c9s6ywha7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Aug 2017 18:42:32 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7FHeYG7029528; Tue, 15 Aug 2017 13:42:31 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c9w0v3ggx-1; Tue, 15 Aug 2017 13:42:31 -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 D1CEF1FC7B; Tue, 15 Aug 2017 17:42:30 +0000 (GMT) To: Ilari Liusvaara , Hubert Kario Cc: "tls@ietf.org" References: <1743998.0aoAkZaxpO@pintsize.usersys.redhat.com> <20170814182616.46cnqvpk3kmh4led@LK-Perkele-VII> From: Benjamin Kaduk Message-ID: Date: Tue, 15 Aug 2017 12:42:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170814182616.46cnqvpk3kmh4led@LK-Perkele-VII> Content-Type: multipart/alternative; boundary="------------92A2B0C428AE1AB70A6C9A78" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-15_13:, , 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-1706020000 definitions=main-1708150297 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-15_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708150297 Archived-At: Subject: Re: [TLS] OCSP status_request_v2 extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2017 17:42:35 -0000 This is a multi-part message in MIME format. --------------92A2B0C428AE1AB70A6C9A78 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/14/2017 01:26 PM, Ilari Liusvaara wrote: > On Mon, Aug 14, 2017 at 08:03:08PM +0200, Hubert Kario wrote: >> Current (21) draft references RFC 6961 in multiple places, in particular >> * Section 4.4.2: >> Valid extensions >> include OCSP Status extensions ([RFC6066] and [RFC6961]) >> * and therein implicitly: >> If >> an extension applies to the entire chain, it SHOULD be included in >> the first CertificateEntry. >> >> at the same time section B.3.1 ExtensionType and table from Section 4.2 do not >> list status_request_v2 as a valid extension. >> >> >> If the intention was to deprecate status_request_v2, I think the references to >> RFC 6961 should be a bit more cautious. If it wasn't (as old messages sent to >> the list would indicate), quite a bit of text is missing. > The introduction suggests that TLS 1.3 intends to deprecate > status_request_v2. > Yes, the intention was to deprecate status_request_v2. -Ben --------------92A2B0C428AE1AB70A6C9A78 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/14/2017 01:26 PM, Ilari Liusvaara wrote:
On Mon, Aug 14, 2017 at 08:03:08PM +0200, Hubert Kario wrote:

Current (21) draft references RFC 6961 in multiple places, in particular
 * Section 4.4.2:
     Valid extensions
     include OCSP Status extensions ([RFC6066] and [RFC6961])
 * and therein implicitly:
     If
     an extension applies to the entire chain, it SHOULD be included in
     the first CertificateEntry.

at the same time section B.3.1 ExtensionType and table from Section 4.2 do not 
list status_request_v2 as a valid extension.


If the intention was to deprecate status_request_v2, I think the references to 
RFC 6961 should be a bit more cautious. If it wasn't (as old messages sent to 
the list would indicate), quite a bit of text is missing.

The introduction suggests that TLS 1.3 intends to deprecate
status_request_v2.

Yes, the intention was to deprecate status_request_v2.

-Ben
--------------92A2B0C428AE1AB70A6C9A78-- From nobody Tue Aug 15 10:49: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 1836413219E for ; Tue, 15 Aug 2017 10:49:13 -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 kdOr5rwykdyS for ; Tue, 15 Aug 2017 10:49:11 -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 45056124207 for ; Tue, 15 Aug 2017 10:49:11 -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 22DA937E68; Tue, 15 Aug 2017 17:42:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 22DA937E68 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.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 A7D15604A8; Tue, 15 Aug 2017 17:42:52 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: Ilari Liusvaara , "tls@ietf.org" Date: Tue, 15 Aug 2017 19:42:46 +0200 Message-ID: <1703674.O0iAYpFHJh@pintsize.usersys.redhat.com> In-Reply-To: References: <1502460670.3202.8.camel@redhat.com> <20170815135415.rxupa7zixqs3tt7c@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2268855.VR3Mq3YK3d"; 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.29]); Tue, 15 Aug 2017 17:42:53 +0000 (UTC) Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2017 17:49:13 -0000 --nextPart2268855.VR3Mq3YK3d Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 15 August 2017 17:28:22 CEST Eric Rescorla wrote: > I generally agree with Ilari. To recap what I said on the PR: > I think it would be fine to sharpen the point about padding leaking > information and I'd take a short PR for that. I've prepared https://github.com/tlswg/tls13-spec/pull/1074 with that in mi= nd. > I don't believe it's > necessary either to require that it be constant time (for the reasons I > indicated on-list and already documented in the spec) or to describe a > specific algorithm, especially at this point on the document life cycle. >=20 > -Ekr >=20 >=20 >=20 > On Tue, Aug 15, 2017 at 6:54 AM, Ilari Liusvaara >=20 > wrote: > > On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote: > > > I've created a Pull Request that introduces requirement for constant > > > time > > > processing of padding and an example on how to do it: > > >=20 > > > https://github.com/tlswg/tls13-spec/pull/1073 > >=20 > > -1 > >=20 > > Except doing the depad in constant-time is useless if you just re- > > introduce the timing leaks at the next step. Actually not introducing > > timing leaks in TLS library requires special API for passing the data > > to application... API that has had no reason to exist so far, and is > > more complicated to use than current read or zerocopy callback APIs. > >=20 > > And even if you have such special API, it is extremely doubtful how > > many applications could use it correctly. Constant-time processing of > > variable-length data is extremely hard (LUCKY13 anyone?) > >=20 > > Oh, and then there are timing leaks when sending data too... > >=20 > >=20 > > -Ilari > >=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 --nextPart2268855.VR3Mq3YK3d 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 iQIcBAABCgAGBQJZkzKWAAoJEJKo0bgB0vX1m/0P/2gzKbM6sqjcJX7jgn+dsWzr BJGh+DF0yo+ToJlpEa+SPQYjGJAIceE38weM7whcO3j/msnFYB2VXd6RP/PnYasj E0NZB6NpbS9LcdicTrE//E0quogcCc950y7wRuUxvrPPfX+nL9LUwgTfbARQW263 Fn9HXEgCf8mPorYhTtqi3VSvlO5+AnQv5Wpd+YHC1W3YIPCLl1ziSLyM/0/wRsZx AO2xohaxzvLYySGrAHbdkusaoBMDnsk1EmsV0PAQ1Ho8XHknqdgdj7ohJEuZwIpp Q+io7Lu29X9ZaU4R25H/Vyh8MBIRtssq4xKhFPbAwyhMgzyIuDe8gHa1nWQSNDZP NekKFVfJ+8nKYFiJCPdAX7wG1+RDCBHpMrraCRGnKLUfBLBO42XWjMVKPBFABlUf lspM5oFuYRpstWwvu/S0YrLeaDhMbJBy0mbMU1PPKCnEC1hJaBZBr+i7pfISU3C0 ln3v2r4JEL5061eQ1ipNti/ineCoqKK8IBA2UgSP1FHofEY8JVREMaAr/eOF2ITP cfND3crAiN3+nc4kYvRzMPbcqjbW3dBmJLN+aLN9QHUPxBPy6DjFRYPIfwEAjEdy TfDG/jJuFXB1iD0CmXdpjvDnoSaWjrtrhQfLNJWulgKrKXKdOHKOAKh1wJTQgW4x LbC0JR6vVB70n//WRile =52DI -----END PGP SIGNATURE----- --nextPart2268855.VR3Mq3YK3d-- From nobody Wed Aug 16 04:55: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 0805713265D for ; Wed, 16 Aug 2017 04:55:02 -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 D-2puvl3HVLh for ; Wed, 16 Aug 2017 04:55:00 -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 247BF132361 for ; Wed, 16 Aug 2017 04:55:00 -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 62C40923BC; Wed, 16 Aug 2017 11:54:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 62C40923BC 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 E1EC17D927; Wed, 16 Aug 2017 11:54:58 +0000 (UTC) From: Hubert Kario To: Benjamin Kaduk Cc: Ilari Liusvaara , "tls@ietf.org" Date: Wed, 16 Aug 2017 13:54:52 +0200 Message-ID: <3208954.mX73NnCEIe@pintsize.usersys.redhat.com> In-Reply-To: References: <1743998.0aoAkZaxpO@pintsize.usersys.redhat.com> <20170814182616.46cnqvpk3kmh4led@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2100583.TOlkEofT9l"; 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.25]); Wed, 16 Aug 2017 11:54:59 +0000 (UTC) Archived-At: Subject: Re: [TLS] OCSP status_request_v2 extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Aug 2017 11:55:02 -0000 --nextPart2100583.TOlkEofT9l Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 15 August 2017 19:42:30 CEST Benjamin Kaduk wrote: > On 08/14/2017 01:26 PM, Ilari Liusvaara wrote: > > On Mon, Aug 14, 2017 at 08:03:08PM +0200, Hubert Kario wrote: > >> Current (21) draft references RFC 6961 in multiple places, in particul= ar > >>=20 > >> * Section 4.4.2: > >> Valid extensions > >> include OCSP Status extensions ([RFC6066] and [RFC6961]) > >> =20 > >> * and therein implicitly: > >> If > >> an extension applies to the entire chain, it SHOULD be included in > >> the first CertificateEntry. > >>=20 > >> at the same time section B.3.1 ExtensionType and table from Section 4.2 > >> do not list status_request_v2 as a valid extension. > >>=20 > >>=20 > >> If the intention was to deprecate status_request_v2, I think the > >> references to RFC 6961 should be a bit more cautious. If it wasn't (as > >> old messages sent to the list would indicate), quite a bit of text is > >> missing. > >=20 > > The introduction suggests that TLS 1.3 intends to deprecate > > status_request_v2. >=20 > Yes, the intention was to deprecate status_request_v2. Proposed text to remove the ambiguity: https://github.com/tlswg/tls13-spec/pull/1075 =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 --nextPart2100583.TOlkEofT9l 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 iQIcBAABCgAGBQJZlDKMAAoJEJKo0bgB0vX135gP/1UiiQXgrVzHGyvcYADQrTcw bKJFbyu3UYSAlHCZTjyX7vATVrNj7cqQrPYUu9K/0nrIakvuHIbLWkrs6FqgzM8e RCNAWCUBVeQxFFHH2+5KcYSI6eADcI/UIHp8qTGLq62FjldNsTD8+5ZIR16uX2Xx 607ydDAaqhU7Zf14+ZJxn4oqib3PVyPfE0tjzkV1GxjZP6Ry1iLgXu1mZFPUF/6z QZtC/T799pjG/Z/AsYf+f3wDzjKVQAWZcduSHnr2UWOhwokS4m5cIEtDMkDZbsx7 42RZiCUUn76yGLobasGmtvNBp1hRj/s0r2ZFrRfScn7Hu7yzc9h/mBQ6We67ORL4 dJHqQU0erGOzwgTXEb1h03+7JIwKQXj5RHj36IJnhk23i3kjXzpqpMZW1aWwnIe5 yMAeaFHR9hA03eDhJT5e5ZzxQG55SOWLO32/c9mhSsW0CR/BJ4NhsWAirYPTasJt rau/IAv05qzKmRz4PQIRxQE4eGRIZErHuPUC6RORKaOCL/fKEs37flDt93FmfKW8 pR/OJZ/L6Sa/6v+aKrhccFwUo1h1ZKsqnjhp/Cc13OBeVDKe/t1cPH3sNXU9vzv3 QyqR62wSIfJk+Tx3uRvVnI8XZ0n0MPtjxoz8kLUEulaXagzWCkehgH9bHWV9gv1o 3/vXoHWBHNic7UQP0kDx =HkL/ -----END PGP SIGNATURE----- --nextPart2100583.TOlkEofT9l-- From nobody Wed Aug 16 14:40: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 7545D132710 for ; Wed, 16 Aug 2017 14:40:53 -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 HP7Ow-SY3DC2 for ; Wed, 16 Aug 2017 14:40:51 -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 A726813271A for ; Wed, 16 Aug 2017 14:40:51 -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 v7GLbw9g032206; Wed, 16 Aug 2017 22:40:50 +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=+bnvbVbPjyvF8HyAi2BxFbSUgZNhUVUOAe+Fj1f17ng=; b=BsS5740qa+v2PP+6F7ovpwFVHbvtuL6v5U80HgvKLcrvbwI8cGP9YPtjXVYCzG293+tx mJTxWGUwwhybskOE1MfR3UFovmTpfSmL7n1jJlq0aznnDGvDJ/HVN/6tesZvxA5MCoz8 9KDQ//SdRkOOxqgZocplhRw1imsKvyeDek//HQPey083LgDdfnrBfTgJrXznlBd9PIUM nmwbt8BAjle8yww3KwPAsKoNTwso/hcIUJNAJOG/JxyWkdgO/YZik7b/xwjqFFgrrzZZ wvYUgpbRsdg/1pgrdWj53+fjqCJ14FN8EmrMvxWS9Hxsu8yFOuG34T7nD4aP9efjDQMx Mw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2cc6dv456e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Aug 2017 22:40:50 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7GLa93I021684; Wed, 16 Aug 2017 17:40:48 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2cc6cvcjdg-1; Wed, 16 Aug 2017 17:40:48 -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 67CA11FC7E; Wed, 16 Aug 2017 21:40:48 +0000 (GMT) To: Sean Turner , "" References: From: Benjamin Kaduk Message-ID: <9e7d7c7a-9668-704e-4f38-ee057e48587e@akamai.com> Date: Wed, 16 Aug 2017 16:40:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0252F4B1A4BCB924EA564480" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-16_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-1708160354 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-16_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-1708160354 Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Aug 2017 21:40:53 -0000 This is a multi-part message in MIME format. --------------0252F4B1A4BCB924EA564480 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/04/2017 07:50 AM, Sean Turner wrote: > At our IETF 99 session, there was support in the room to adopt draft-huitema-tls-sni-encryption [0]. We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170818. If you object to its adoption, please let us know why. > It is before 20170818, and so I make my reply to the call for adoption now. I think that the WG should discuss this topic and produce a document with it, but I am not convinced that this document, as it stands, is a good starting point for a product of the WG. As has already been discussed, it is a bit strange to have normative language in the catalog of known attacks, but removing those is easy and also uncontroversial. That said, my main reason for believing that changes are needed before this is a good starting point for a WG document is that it does not present itself as a single cohesive solution, but rather a choice. This, of course, has also already been noted, but I will note that I also prefer to have the choice resolved before adopting a WG document. (It is possible, of course, that the choice of the WG will be that both flavors are necessary, or even something not yet included.) That said, I am happy to review and comment on drafts in this area as the WG discusses options and settles on a consensus choice. -Ben --------------0252F4B1A4BCB924EA564480 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 08/04/2017 07:50 AM, Sean Turner wrote:
At our IETF 99 session, there was support in the room to adopt draft-huitema-tls-sni-encryption [0].  We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170818.  If you object to its adoption, please let us know why.

It is before 20170818, and so I make my reply to the call for adoption now.

I think that the WG should discuss this topic and produce a document with it, but I am not convinced that this document, as it stands, is a good starting point for a product of the WG.  As has already been discussed, it is a bit strange to have normative language in the catalog of known attacks, but removing those is easy and also uncontroversial.  That said, my main reason for believing that changes are needed before this is a good starting point for a WG document is that it does not present itself as a single cohesive solution, but rather a choice.  This, of course, has also already been noted, but I will note that I also prefer to have the choice resolved before adopting a WG document.  (It is possible, of course, that the choice of the WG will be that both flavors are necessary, or even something not yet included.)

That said, I am happy to review and comment on drafts in this area as the WG discusses options and settles on a consensus choice.

-Ben
--------------0252F4B1A4BCB924EA564480-- From nobody Wed Aug 16 17:13: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 AC1CC132432 for ; Wed, 16 Aug 2017 17:13: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, 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 vI_wwQhhHRMU for ; Wed, 16 Aug 2017 17:13:52 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE170132143 for ; Wed, 16 Aug 2017 17:13:51 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g71so18330847ioe.5 for ; Wed, 16 Aug 2017 17:13:51 -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=O/j05vcVYhBk8RS6qZJjLWSzZo+AVN8i0SDjqrgHBaI=; b=Tyd4QvfwFuMW6HkWgP7+2hc3HxRSKSGMp3nGh5/4DPLf5NVcCSZ3SEemoQ1iPPjHDs /zQ1odcLmEsn4x8v7LJUk5qPxIatdUxaFkarSu3KsNusKVMXIG1R4/g8GQEvlhhrKPVi UJMQKIhE0BSt4RJ2YYgkWQ4bACp56jATDKe9KSBLmgZZaD6QSjK5mtiEpvKkw32hl8L5 dKOKGvwnXsO9Yyd8wjO72avkUfSUJ/ZaRlYUegH0Q6Snh4XuWDa2DUSrCh2zKnuKC0U0 I+Hmct0lbEABUbt7Ybhtg8KDt40ScRLwXZlytyUiEADVPfASVuaMBdhZWmDqeGwx2l6/ sEkQ== 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=O/j05vcVYhBk8RS6qZJjLWSzZo+AVN8i0SDjqrgHBaI=; b=dfTKMnWyp+0aSGh9fpwCU5EjeXsEuKvg1BwUmaprZVftDmCBz5gxw0KygWEQm59I46 7THqSpRdCkMtAM+ZcOaX0isLJNAdexZ7gmqZAcWdCusb2OWSIODyfqW6ubJJarypFAym bbkc0ICcn0Tjpa6R7vFvKFdVT873gty7tdz1iYZa77cMpHLo+IDtGjgtL9FiC5sTen0h EyMaeQ3Tviu5q9PK1F+xL5RlbMpZdy1wEvGnwdvBr3TVOWk2Vd6yr0e6xR+vKciTSno5 wmGX8x8YmHT/K6VhnSFoFfW8xpV0bd6C25WK1jwMkZBF6uouxna0u9UZVGLVVdUyXLxR UYvQ== X-Gm-Message-State: AHYfb5iuqj0z4aUpe1cmStmWmjTFg1NMCR5VWdyVi99t9DJsuP3/PT5r xMxtL4U0OgTdGr/OhWDnZMjnqpQZaA== X-Received: by 10.107.16.196 with SMTP id 65mr3518032ioq.297.1502928831211; Wed, 16 Aug 2017 17:13:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 17:13:50 -0700 (PDT) In-Reply-To: <9e7d7c7a-9668-704e-4f38-ee057e48587e@akamai.com> References: <9e7d7c7a-9668-704e-4f38-ee057e48587e@akamai.com> From: Martin Thomson Date: Thu, 17 Aug 2017 10:13:50 +1000 Message-ID: To: Benjamin Kaduk Cc: Sean Turner , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2017 00:13:54 -0000 On 17 August 2017 at 07:40, Benjamin Kaduk wrote: > I think that the WG should discuss this topic and produce a document with > it, but I am not convinced that this document, as it stands, is a good > starting point for a product of the WG. Maybe the right answer here is to declare that we have consensus for working on the problem, but that we need more time to find the solution we want to write down (or solutions, which seems like an entirely plausible outcome in this case). Note that I am NOT arguing for a requirements document. From nobody Wed Aug 16 19:19: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 E57751321F0 for ; Wed, 16 Aug 2017 19:19:25 -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 zKthKgTwQ6cK for ; Wed, 16 Aug 2017 19:19: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 0F6F113217D for ; Wed, 16 Aug 2017 19:19:24 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r199so18164384vke.4 for ; Wed, 16 Aug 2017 19:19: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=+BioBBnNn2kGF8u/riJWdEtroeW3Pz/h5DYbztwawCk=; b=Jkn6d/uHD82H533UbU2x9P84l1HESN64rWFl6fdpSxf9d3FjQOmet6cwBeW4LBZHVw jhF60G/+iQdxcRyz1c19r0xONLmyJqa3tDZ0uVwqqe13cMda3ntd30Vxj9onmjDsI7SV hQgwx1qpBF2MXycZB3qzYGM+aY3CZR7raK5Kxah/VHqvGSJn2OtMKdeintuvuJ/zi9d1 tsNB2qs3dssv9lwe6G6QLbBxPZockrnEzXPEjOckBt1JXDGiGf1RrOihebe2yvQzyXy3 iT3Rvf0hVqMWQrFCuVZHs5xvyzRR52pUjCv+O9RHnIuRMC63DKZ/Rv4Q9a4JcPl5mLmL fX3g== 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=+BioBBnNn2kGF8u/riJWdEtroeW3Pz/h5DYbztwawCk=; b=buFxgeEWHFHdfEE4H+QcRQOmx/AnHBTvVzgbcADkAeIolXyiMc4KPGIHN3dpZdqg4p ZsVG79msy8pItCh9eaI/5HXzNOY31EpRy0I3IATE4idxkzUgmrZW6Ngx3AJtlj8v2hqx 7q/+TatGQ8WNNLukpxcV9aIMW4WS9m9Mf55hiF6xu6MrrQFR0ENN3aKp3aZG++2wZ2xD XSvemNrBEMFPbwYuh4EFUp8SQ0DSvEmxx5nQI5qjAVTR+4UFNEBbFppAffnzDKSptVRJ quJ1ek2ZbPhiaPyuEw5VY4+TV22UljJAk66jzSIinDbfFfPva54Sopd8savxW16fOD75 a9QQ== X-Gm-Message-State: AHYfb5i0thy78MeLHmuJJdQqNx6T4hN5jfkiNlQQ+/a2YOcCIz76yfzc 30HDntr100BOxCBWM9oNOEVIcrijHA== X-Received: by 10.31.13.78 with SMTP id 75mr2240442vkn.121.1502936363208; Wed, 16 Aug 2017 19:19:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.108 with HTTP; Wed, 16 Aug 2017 19:19:22 -0700 (PDT) In-Reply-To: <6718e91d39ac4faf82a97c6895165614@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87pocbwjry.fsf@fifthhorseman.net> <6718e91d39ac4faf82a97c6895165614@usma1ex-dag1mb1.msg.corp.akamai.com> From: Watson Ladd Date: Wed, 16 Aug 2017 19:19:22 -0700 Message-ID: To: "Salz, Rich" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11440f440c95230556e9a478" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2017 02:19:26 -0000 --001a11440f440c95230556e9a478 Content-Type: text/plain; charset="UTF-8" We don't need to adopt to have the discussion. I think we definitely can have a discussion of the merits of the solutions before going to adoption On Aug 6, 2017 1:40 PM, "Salz, Rich" wrote: > it's odd to adopt the draft without choosing which of the designs we're adopting. On the contrary, I think it's ridiculous for the WG to pick one design without discussion. I really look forward to AGL's comments on each _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --001a11440f440c95230556e9a478 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a11440f440c95230556e9a478-- From nobody Wed Aug 16 20: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 DF4CD1321D8 for ; Wed, 16 Aug 2017 20:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 94mMTXo6aTgH for ; Wed, 16 Aug 2017 20:07:19 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 6F27013217D for ; Wed, 16 Aug 2017 20:07:19 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id f9so20470299uaf.4 for ; Wed, 16 Aug 2017 20:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YeapObwV05zBS8xS4+xGCcCW120MuRxfyUCuWgoTrAs=; b=KivWvaW+NH+/lvD6aeXDVlqHapykph6+WTEPpGlMIUf+DVtQVk63pmXewZi0B/KtlQ 2jdzbQ7ZMiheRYdM6KbX8z/PCXV0RJbrGbTP9wQO5iR6p7rKr9YpMCc+TU933IndyKeX M75uW17+O+CICcdrGw7V/GKGhGNnlHUH/sHM4A0z4AktJVW/3VfSYfBTQP7+O4WchpmQ +VPdOCZFp4c2iKKRgYdQP5/mqXFdbikBJSThtSatXw0h8ZEJVrnH6/sSvFQp3E6DMCWM vqqfSZKFJI7PUqt5AsQIXGmnhwbyPbTtpuxhdVm9pvwNt6wBRqohTCzBqKOn++YM2koN jciw== 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=YeapObwV05zBS8xS4+xGCcCW120MuRxfyUCuWgoTrAs=; b=Xc0eXC4AtTT+pUv65W9ZBDv0/BRTkQie5HgL9lEaZQU5LHKOT2Fn5z90wDQcsCeD0a Ylx6uNbodxkk1/AWlQGh8AdqKk1LyOY1hDxN4LrIfNSveKk8GRJhu4+xneCxF/Nb5gm5 /8DwOEjW5QFz6qSU7DtRWxfsZlLqZ6qorNybgkcbdLGrJOB42K32lIBGE7d0XRZ14Wl7 lhlgCAgoSTsdqAIKgaQnBQMMeoemnLX+GH7PznKmS3cjlXbhUdfVljg9UG23zeUS62sB 1XYHMjcRkWSVIALOHH2dGdVoTw2BDq35s6u0C3drDqQ8nVCcN8b0nicIN1gFXTToK6v1 OuMQ== X-Gm-Message-State: AHYfb5hTA6fdWnPCm/4oZDjzn3h8GysbFpPlBJ2OWWEZJcbskXTAdcfG Ikk3ko7WONQVcxiRKVKOqLGGbpAM1Qee X-Received: by 10.176.66.229 with SMTP id j92mr2637863uaj.76.1502939238302; Wed, 16 Aug 2017 20:07:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.18.67 with HTTP; Wed, 16 Aug 2017 20:06:57 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 16 Aug 2017 20:06:57 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="94eb2c05017c6b0aa10556ea4f28" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2017 03:07:21 -0000 --94eb2c05017c6b0aa10556ea4f28 Content-Type: text/plain; charset="UTF-8" As I expressed on a separate thread, I think tunneling TLS is a very interesting problem with many potential use cases, from SNI encryption to egress proxies to service discovery proxies (e.g. linkerd, Envoy). SNI encryption is one of the use cases, but SNI encryption is pointless until we have encrypted DNS. That's not to say we shouldn't work on SNI encryption, but that SNI encryption isn't immediately valuable, whereas I think there are many other TLS tunneling use cases where the same proposed mechanism is immediately valuable as opposed to a future "when the DNS loophole is closed" scenario for SNI encryption. I am all for tunneling as a general WG item, but I think framing the discussion specifically in terms of SNI encryption is missing the forest for the trees. -- Tony Arcieri --94eb2c05017c6b0aa10556ea4f28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I expressed on a separate thread, I think tunneling TLS= is a very interesting problem with many potential use cases, from SNI encr= yption to egress proxies to service discovery proxies (e.g. linkerd, Envoy)= .

SNI encryption is one of the use cases, but SNI encryp= tion is pointless until we have encrypted DNS. That's not to say we sho= uldn't work on SNI encryption, but that SNI encryption isn't immedi= ately valuable, whereas I think there are many other TLS tunneling use case= s where the same proposed mechanism is immediately valuable as opposed to a= future "when the DNS loophole is closed" scenario for SNI encryp= tion.

I am all for tunneling as a general WG item, but I= think framing the discussion specifically in terms of SNI encryption is mi= ssing the forest for the trees.

--
Tony Arcieri
--94eb2c05017c6b0aa10556ea4f28-- From nobody Wed Aug 16 21:18: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 C08491323CA for ; Wed, 16 Aug 2017 21:18:16 -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 YB2hJ30z-AWw for ; Wed, 16 Aug 2017 21:18:15 -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 C33791323B7 for ; Wed, 16 Aug 2017 21:18:14 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 76so26267586ith.0 for ; Wed, 16 Aug 2017 21:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bOsAo0HrlGPkMvt8jj4+XPEyXgZFnXLdyzrqrMa1wys=; b=mlkbLnnBdSqPrJ+sKLsXx4hRDEYPytNnrxgVsUdJDxhG/93GifpjnUBtjRN16VmAlO BYJRNNAyWXR3BWkp8qRW1aZXi9I/HD9XIDMzQmJt6+qvtidcJwCaiJW/K3cGEIacLiWZ Y2YXwCG0b0AtJtGTHxYJALC4f1oDdHns7xDOsZKbxUrf7VPqCGkJ6TIXvhpPiYFtA2e3 v1PNeCvGqKJWf2d7XQtl8Ksyeuot+KTA6oJ1BFKYjBh2KpCS2jGGEEeAgXLz4UgIu9U1 tyhEm6faXSicEW0+bNZ30RNq1+aT5G+eDjZ9g+0QTKaIWFXe+t537FHWvYHFEL8e/F/L fkOw== 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=bOsAo0HrlGPkMvt8jj4+XPEyXgZFnXLdyzrqrMa1wys=; b=rHokSYMOqv+14xUuRHeeAInFJalYP586u4pbV0RpHlK215E4Fkal402Ct13yeC20vP bz7QmLU8q0z4lPHH44bvRxKD6nT4oYGE9KnZw56SrK3iTEBd2HJIW6LNqVh6md2qfarS JymTE8pKjtA1IomfKVJeu3TtmUhw20f5owz87Umsh04Nd6II0VppesQEGJ2CGtQL7jrh RDmxlPd+aKntQKEDcAenyVFM0u5nlRZiF6noG0dZNaqQKXgi2yu5KzfVLTyIR7Kmm0j9 M1FQjs43hN4kTAK8WfkDbfdnGJb6o1/0JdORDoHsN3RuV7I5c2sdGV0EKGFBgCllHLng hEuw== X-Gm-Message-State: AHYfb5hQ+/BJQHTMqJLssCzZkviO5eyRSXceqMvGc/gE4H6ZRg/8RfKe taO7TNmwOVm7OJirIgddBwBvLH8wH8XATVw= X-Received: by 10.36.13.10 with SMTP id 10mr667946itx.51.1502943494159; Wed, 16 Aug 2017 21:18:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 21:18:13 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 17 Aug 2017 14:18:13 +1000 Message-ID: To: Tony Arcieri Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2017 04:18:17 -0000 On 17 August 2017 at 13:06, Tony Arcieri wrote: > SNI encryption is one of the use cases, but SNI encryption is pointless > until we have encrypted DNS. https://tools.ietf.org/html/rfc7858 I hear that there are even implementations and deployments. It's certainly time to have the discussion about closing the next gap. From nobody Thu Aug 17 01:31: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 0F906132645 for ; Thu, 17 Aug 2017 01:31: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 f-YNC9jwOeK6 for ; Thu, 17 Aug 2017 01:31:39 -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 9C24D1324A3 for ; Thu, 17 Aug 2017 01:31:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4E867BE74; Thu, 17 Aug 2017 09:31: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 zXkOoAIe79Wr; Thu, 17 Aug 2017 09:31: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 E3D4BBE64; Thu, 17 Aug 2017 09:31:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1502958694; bh=nhSpSgkUxmpq30atp0A/0v81wh1IKrAiUIuet/307/c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=yb7wY8TSwlDbd0bHiofC1SeoUQe9njPKNCQwSR54qZzdA6bGzw7qGjWPlS6mSzPUB iGEcVydYZdKJeGyuK07NOF0KmBijbafDE+eK0Bqy4i0f4TCSX2qIVxCMF9z9dZjnFT LmdCMn3eqccr7MRd1HBnMGMdtCNjZK6o1Dt2qPhM= To: Martin Thomson , Tony Arcieri Cc: "" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 17 Aug 2017 09:31:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r0sJ1AgP0MQpDli3OCcK4avGkgxGsI41S" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2017 08:31:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --r0sJ1AgP0MQpDli3OCcK4avGkgxGsI41S Content-Type: multipart/mixed; boundary="IaFAK6gXuxKwJUjV0ofvnrxxx84aHnwE8"; protected-headers="v1" From: Stephen Farrell To: Martin Thomson , Tony Arcieri Cc: "" Message-ID: Subject: Re: [TLS] WG adoption call: SNI Encryption References: In-Reply-To: --IaFAK6gXuxKwJUjV0ofvnrxxx84aHnwE8 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17/08/17 05:18, Martin Thomson wrote: > https://tools.ietf.org/html/rfc7858 >=20 > I hear that there are even implementations and deployments. Yes, I used the resolver doing this at the last IETF meeting. It worked. Not "just worked," but pretty good. >=20 > It's certainly time to have the discussion about closing the next gap. Yes. I'm in favour of adopting as a strong signal that this is a WG item. I don't think anyone needs to be allergic to a wg draft-00 that still documents more than one proposal, there's no specific place in the evolution of an RFC before which such things MUST get sorted out, so while being a bit concerned that we still have two options is very reasonable, that's not IMO a winning argument against wg adoption. S. --IaFAK6gXuxKwJUjV0ofvnrxxx84aHnwE8-- --r0sJ1AgP0MQpDli3OCcK4avGkgxGsI41S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZlVRlAAoJEC88hzaAX42iLScH/R72je+Wf0gCVbjaZawQrZNZ 33tp8xfTUhsLyALcBOAbEk0DQx6/kp75I9I6/jHXdJjCTOqqSVgJTYCgO9EnCcfR AvjMWb5b+jor8ZKL5bSb88ulNQsI36cQ7wSWqh5k0DqMDDIuGB12vvQ5apcm7xXM OyHmbhSC3MhJHxpVy2ALm/Bl3e/9fRh1xuW4YTHABTlL67lAfEqmZL31k8hJxz8C IEYlufqwAEHkVF9sEPDmZwqnGC5D6YBwcyM5e7CF81RvvgYl5026ELfmdw/9UCIr fzO62rbjIPifcBAffmV/AxP/7NDluFJFJdryZDcbHtGaDr6Rzaytz2d7F+yUf2s= =AzUd -----END PGP SIGNATURE----- --r0sJ1AgP0MQpDli3OCcK4avGkgxGsI41S-- From nobody Thu Aug 17 21:33: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 932771321D2 for ; Thu, 17 Aug 2017 21:33:56 -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 Ah1K79YfP8_3 for ; Thu, 17 Aug 2017 21:33:55 -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 04F611323BD for ; Thu, 17 Aug 2017 21:33:55 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 76so2715303ith.0 for ; Thu, 17 Aug 2017 21:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3jbHnrtVrCd/eb2htbt/ekSetI8CkZE7Ia1JMwv1LwE=; b=ggJRSwhMHph6MeTtQjWPAKGCPgjEKEOoXNwCHCsOqacn8tsFo8XvZooroaogvgMXCg kFcz7+gUuTq4W4bV1vLxbibXWYbqG2YfS+4YGlZCLDrXpb2HW3DA1hSE7duC7Prix40B w/a34gkxv83v4mGBuXHeh47tPQ7YWMB6R76eYDuge/8J2zETrz5z2Z7DvsCWHtuSrZ0s ZwpoZLLfGhIDwRlef9vD2I8qvLzWV1Ps716FnJ3c8W/SSA9FM5OMN0GItEuJm5lvC5MW CTciWkC1j9lTBcvWbFKunwsLZkT2Sz/Lyo0eFDPs+9WXC8soitfhgpBsKu9UjCGQYVgL dyhg== 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=3jbHnrtVrCd/eb2htbt/ekSetI8CkZE7Ia1JMwv1LwE=; b=cDPRCn+LzXuNwyQJA9EvRZq1jNRi+elNZ53spiIZ1yHNhAv2tWUIh1TLf7rOAaH5PU MIPWaq7VpN4ENJ9pqxX4LHwMKd/C5Q1k1v029GTveEe7HnbxVG3oR6uLyQKWMjsGt6BM T/y5WgcM1IUyx8P2fGAYE0K7XPDfvRnItIAcHhyQa98gBbM5b7I8Lan3Ogxk5D0De11W avOzOXf5FceB0FVfPLsPWMwPSwkMQ6CASZD6H8AHCko4qrick3TFSewSQUEVAHmSLegk PNwdYH28OFS8A0su72JvclXGAJmi37Nzu4PSXxuJMnL2RpSH5AZP9idZtfhHgRpItsJh RrJQ== X-Gm-Message-State: AHYfb5gjN2rYrlK+RedlA66WTq5M2/nbRszHxUD4sXgCjkwCaxcofJjx lfbfP4zHHf/14JRy7MCAqTd/iEkaS1esgiw= X-Received: by 10.36.193.199 with SMTP id e190mr696716itg.122.1503030834321; Thu, 17 Aug 2017 21:33:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.159.75 with HTTP; Thu, 17 Aug 2017 21:33:52 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 18 Aug 2017 14:33:52 +1000 Message-ID: To: Sean Turner Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2017 04:33:57 -0000 On 4 August 2017 at 22:50, Sean Turner wrote: > At our IETF 99 session, there was support in the room to adopt draft-thom= son-tls-record-limit [0]. We need to confirm this support on the list so p= lease let the list know whether you support adoption of the draft and are w= illing to review/comment on the draft before 20170818. If you object to it= s adoption, please let us know why. It is 20170818 now where I am, so I'm going to provide an update before the chairs make their minds up. I have a patch for NSS that implements this (including the assumptions in PR #1). TLS was easy. For some structural reasons DTLS wasn't as simple because you have to be aware of record size limits when fragmenting handshake messages. I ended up having to restructure a function or two and break down some bad/previously-ok assumptions, but it wasn't especially difficult. As a bonus, we will now be marginally more efficient with our DTLS handshake. I ended up implementing for SSLv3 through to TLS 1.3. Should anyone want to test, please contact me privately. This will eventually hit NSS trunk, but probably not until we sort out the TLS 1.3 deployment challenges. From nobody Fri Aug 18 18:34: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 6784A13244F for ; Fri, 18 Aug 2017 18:34:01 -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 V5vnmSJw-iov for ; Fri, 18 Aug 2017 18:33:59 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id DA114132430 for ; Fri, 18 Aug 2017 18:33:59 -0700 (PDT) Received: from fifthhorseman.net (c-73-227-237-205.hsd1.ct.comcast.net [73.227.237.205]) by che.mayfirst.org (Postfix) with ESMTPSA id 6FF27F99A; Fri, 18 Aug 2017 21:33:58 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 431DA215E8; Fri, 18 Aug 2017 18:46:21 -0400 (EDT) From: Daniel Kahn Gillmor To: Tony Arcieri , tls@ietf.org In-Reply-To: References: Date: Fri, 18 Aug 2017 18:46:13 -0400 Message-ID: <87bmncfqa2.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 19 Aug 2017 01:34:01 -0000 --=-=-= Content-Type: text/plain On Wed 2017-08-09 22:54:46 -0700, Tony Arcieri wrote: > - The gateway authenticates clients (using e.g. a TLS client certificate) > and authorizes the outbound hostnames against an ACL. This way we can > control which clients are allowed to reach which external endpoints. While i think i understand where you're coming from, Tony, i can't help but note that this use case is difficult to distinguish from a regime that: (a) wants to forbid anonymous speech, and (b) wants to censor "unapproved" information sources, and (c) wants the capacity to undermine freedom of association. That makes me wary, and i hope that SNI Encryption is *not* conflated with these particular use cases. In particular, the requirement of user identification/authentication in combination with a heavily constrained network seems problematic. I don't think that we should design SNI encryption with an intent to facilitate this scenario. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlmXbjUACgkQFJitxsGS Mjew3g/+Lwt0pXFgzJ1a1mYtFLxW+xPRm/fILgDQKBC7hdqtDv6W+Za44pal/uub SdeghXi60F1JnabapTk75iemExPcxEYaj535QRYymrlqYH5WoY3rW9eCbVnzqN8P gMLPbDYT4f0X292Z1r9Zd9tyUmP8L1vlf3prOADptPWPwXpX/HlXjL0tAcBumrCX CAonqDp+DBtVuRFECALdhTCiOv7jrq8p56HegmuCwJNOF2dDtz2NQvDx7mK92EoS b37nDd5ji8a46mitloGlyClXAktkwwqOqmVOpAsNTlPIykm3pjRW3+Eql3HfyNjc aoj1Gx+wF56pVgG2gH4jXE0vzYdlDVD4ruUPiIEqXP409cEI3LKVmim17VyD48Pr S7ljhkGg+G29d8B39LPx5gqjd538IbR4uhkXp/uphlFelJm8N0UQMPhYaWMNcu8R tUz7WBxMsHmsob0qwwFGdoaXrQi22fXVNAA9gAfFFbns+vU23myJgy/tvvXeZ71h c6IR3hnj5nqgdImlG2nL6iHQx/s9qLVzdRlh1X8nb8daxix9fkiOne04gW8FZFhG dDsukqW8FCIl4Hxxk3kLvObWmh3RYpb6uebW3xTf/24ztRcChKCXnv1hp5yMPi7H IWfFXo1ciKAfFLXKSQaGp2U4vrD3kxqwryXvSoiAbaBhdbZzWW4= =u2gG -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 19 07:06: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 D00BE13281D for ; Sat, 19 Aug 2017 07:06: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] 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 WH9fja_U7IkK for ; Sat, 19 Aug 2017 07:06:18 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 01D711321A5 for ; Sat, 19 Aug 2017 07:06:17 -0700 (PDT) Received: from fifthhorseman.net (c-73-227-237-205.hsd1.ct.comcast.net [73.227.237.205]) by che.mayfirst.org (Postfix) with ESMTPSA id 3DD4CF99A; Sat, 19 Aug 2017 10:06:16 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6F38C20C5E; Sat, 19 Aug 2017 10:06:12 -0400 (EDT) From: Daniel Kahn Gillmor To: Christian Huitema , tls@ietf.org In-Reply-To: <422ef2c7-4d99-20d2-8a39-ffd61277e0bd@huitema.net> Date: Sat, 19 Aug 2017 10:06:09 -0400 Message-ID: <87tw13ejou.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-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: Sat, 19 Aug 2017 14:06:20 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed 2017-06-21 21:25:21 -0700, Christian Huitema wrote: > We has many discussions of SNI encryption on this list recently, and > that was enough motivation to write a draft about it. I am pretty sure > that this will be met with wide approval and no discussion at all :-). This is my (hopefully not too tardy) review of draft-huitema-tls-sni-encryption. fwiw, i still believe that the WG should adopt this draft. Thanks for writing it, Christian and ekr! * i agree with concerns raised about RFC 2119-style language -- they don't really fit in the requirements and overall description. That said, the natural english variants of those words are still relevant, and shouldn't be ignored. The WG should try to prioritize the different technical risks and opportunities. Below are some comments/questions/nitpicks: * The document uses the terms "Fronting server" and "Gateway", i think interchangeably. It would be clearer if it stuck to a single term. * =C2=A72.1 (Mitigate Replay Attacks) says "SNI encryption designs MUST mitigate this attack", but "mitigate" sounds unclear and weak. do you mean "must successfully prevent this attack" ? It seems like this is all-or-nothing to me, not something that can be partially alleviated. * =C2=A72.4 (Do not stick out) While i understand the motivation of this section, I think it's interesting that it rules out an entire (simple) class of solution, namely the ssh-style approach: encrypt first (without authenticating the server), then authenticate within the encrypted tunnel. While this approach has several drawbacks (an extra round-trip; leakage of SNI to an active adversary willing to break connections to learn the desired SNI; difficulties for non-crypto loadbalancers), it is really simple and straightforward to implement and deploy (no third-party coordination, etc). (this proposed approach also violates =C2=A72.7, "Fronting Server Spoofing") If this approach were widely implemented, it wouldn't "stick out" any more than SNI-free TLS handshakes did 10 years ago. Is it worth documenting some solution of this class, just to provide a standard way to do it, so that everyone doing it would at least be mixed into a single (hopefully large) anonymity set? * =C2=A72.5 (Forward Secrecy) -- "If the corresponding public key was compromised" should probably be "=E2=80=A6corresponding private key=E2= =80=A6". "Forward secrecy" is also something of an ill-defined term, since the window of the forward secrecy depends on key deletion schedules. What if the private key for SNI encryption was rotated out (and deleted) daily? would that be "forward secret" enough? how about weekly? Perhaps this section should state that "designs should clearly state their temporal window of vulnerable communications should any non-ephemeral key be compromised" * =C2=A73.2 (Delegation Token) -- i think the delegation token idea might end up useful not only for =C2=A73 ("HTTP Co-Tenancy Fronting"). for example, it might be usful for announcing either SNI encapsulations (e.g., =C2=A74.2.3) or combined tickets (e.g., =C2=A75.3). so its locat= ion in the document is a bit odd. * =C2=A74.1 (Tunneling TLS in TLS) says "an attacker should not be able to distinguish these cases" but does not mention timing analysis. if the Hidden server is not physically adjacent to (or co-tenanted with) the Gateway, then the response ServerHello will have a different latency than would a ServerHello that comes from the Gateway itself. I don't think this is a deal-breaker, but we should probably acknowledge it. * =C2=A74.2 (Tunneling design issues) this section introduces the idea of a "RealSNI scheme" without defining it. I think i know what it's referring to, but perhaps it could be spelled out earlier for contrast if this document is really exploring the full design space? I think "conversely, these modes=E2=80=A6" is referring to "RealSNI"-sty= le modes, but it could be mis-read as referring to the tunnelled ClientHello described in =C2=A74. * =C2=A74.2.1 (Gateway Logic) "EncryptedExtensions would be the most natural, but they were removed from the ClientHello during the TLS standardization." For those of us with either bad memory or bad search skills, it would be nice to have a one-sentence summary of *why* encryptedextensions were shot down, rather than just a "we can't have this natural thing because reasons" argument by authority. * =C2=A74.2.2 (Early data) "would requires" =E2=86=92 "would require" "delimitate" =E2=86=92 "delimit", and "end of these" =E2=86=92 "end of t= he" Another difference between the posited schemes seems to be that the double encryption scheme doesn't require the ClientHello to be in its own separated EarlyData TLS record, while the blind relay case expects the ClientHello to be isolated to a single record. Is that correct? if so, it might be worth stating explicitly. * =C2=A75 (SNI encryption with combined tickets) This proposal seems to require trial decryption by the Fronting server against both its own preferred STEK, and by the K_sni that it shares with the Hidden service. If one Fronting server wants to front for N Hidden services, it will need N different K_sni values, and it will need to do N+1 trial decryptions on each proposed session resumption. This seeems to run afoul of =C2=A72.3 ("Prevent SNI-based Denial of Service Attacks"). =C2=A76 appears to claim that this is OK because it is not an asymmetric operation, though. How many symmetric trial decryptions can we expect a Fronting server to perform for each incoming Client Hello before it amounts to a DoS threat? * =C2=A75.1 (Session resumption with combined tickets) "as follow:" =E2=86= =92 "as follows:" and "three of requirements" =E2=86=92 "three requirements" * =C2=A75.2 (New Combined Session Ticket) =20 It's not clear what specifically is impractical about the hidden server encrypting its tickets with the public key of the fronting server, or on which hops those tickets are encrypted. That parenthetical aside probably needs to either be fleshed out more or dropped, since as it stands it seems like it adds confusion. "stateful design" sounds like the traditional TLS "session ID", but with some coordination between Hidden and Fronting servers so that there is no session ID collision between the two. Is it worth describing in this way explicitly? Perhaps the "stateful design" and "shared key design" should be broken out as separate subsections for clarity. "When the client reconnects to the fronting server, it decrypts" =E2=86= =92 "When the client reconnects to the fronting server, the fronting server decrypts" "CH" =E2=86=92 "Client Hello" "to hides behind" =E2=86=92 "to hide behind" "Frinting Service" =E2=86=92 "Fronting Service" * =C2=A75.3 (First session) "directly connects to" =E2=86=92 "directly connect to" "and then asks for" =E2=86=92 "and then ask for" "exposes clients to" =E2=86=92 "exposes the client to" It's unclear what is meant by "the second Client Hello can be sent as 0-RTT data" here. It sounds more like this refers to =C2=A74 than to the shared ticket approach. Do you maybe mean "subsequent Client Hello", as in "the Client Hello that contains the shared ticket"? If so, why mention 0-RTT data? * =C2=A76.1 (Replay attacks and side channels) This section starts by claiming to address =C2=A72.1 ("replay attacks") b= ut is mainly about side channels observable by a global netowrk adversary, which are not mentioned in =C2=A72 at all. In prior sections, the adversary appears to have the capacity to monitor the link between the client and the fronting server. This section apparently expands the scope of the adversary's monitoring capacity. "adversaries cannot receive" =E2=86=92 "adversaries cannot decrypt" "Adversaries can associate" =E2=86=92 "An adversary capable of observing = all network traffic at the fronting server can associate" "the setting of a connection to" =E2=86=92 "the TCP handshake between the fronting server and" This section doesn't clearly describe what an acceptable, leak-free alternative would be. * =C2=A76.3 (Forward Secrecy) The final paragraph of this section refers to the "encapsulation protocol", which i think is the proposal in =C2=A74. However, the paragraph mentions K_sni, which is only relevant to the "combined ticket" proposal from =C2=A75. This is confusing guidance, unless we pl= an to implement a combination of the plans. Maybe the final paragraph is meant to refer to "implementations of the combined ticket protocol" instead of "implementations of the TLS encapsulation protocol"? The guidance to rotate K_sni frequently is constrained by "If they do rely STEK-protected tickets" -- why should that be relevant to the forward secrecy of the SNI information? Shouldn't the recommendation to rotate (and destroy old copies) K_sni frequently be made without reservation if the goal is to promote forward secrecy? OK, i think that's it from me for now, sorry that it's such a long note, and that it's later than i meant it to be. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlmYRdEACgkQFJitxsGS Mjdg6xAAuv/PUEcXRLn58XGkWw+eVuvvg9Xu4HJznDrJfs2PmpF1vvsII6x4Pb8r Mfbz46t4VdWYeW/+oR87Q67SIzD1XaXMgFnkGfCVhADQNPdYvtkA8rGo4z2nfYRF 04P6wypOzTGzzqK3eHWE2U7wddcz3c+hIpuLv22pgwKBksRAIZln+nURipEL1J+G Yk64DXZzuIz8EHyYAdllMSrsLDcz0OKaAgh8Wve6c8P3fQzeAr4YL8XwoCbwh8dw 9DYv87wv+cUsSkz/DjeByXLhM/qJptcJMbnCE/gHHs/QghqJkoQK266K58kzZZpd QJVbDVFvueCeV6v0rvbcKve3yAglYKG8tjJzBIL/Gg4QNfo6k512EgHmgOOMjUE1 Cl8ejulkFXoQgArxD5SsLdV27eV/aXjkilqmQyoE+6FxrDlSZcxUXCb9ZYvDOHds lDCPluv90EkBadP93HJvmyYzltNLRBWmO0Vk5aFTMXEbHKE+ud1fRaedHD6fmcSQ +7OQdlVUyG1K9HD+x0Jv+Ch6RNlw/f31Cc055RFUVDQJHehNoQL9c0XB6CAq7sqa djyA+PflQE9SuFq1sYaWJCiEmnO18J9M/YBFXt/0OiQI5VfEGr3T2A+uLH3Pculm hd1w4MzLxWtai1vHijbZfejBKzj9JaackVUovDJJ9/tcITvfdn8= =yp7o -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 19 09:20: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 4848513292F for ; Sat, 19 Aug 2017 09:20:11 -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 sBI18HTTtAee for ; Sat, 19 Aug 2017 09:20:09 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id F25631320D9 for ; Sat, 19 Aug 2017 09:20:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id B6F8C93639; Sat, 19 Aug 2017 19:20:07 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id uA71jnmXxzUN; Sat, 19 Aug 2017 19:20:07 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 6EB7FC4; Sat, 19 Aug 2017 19:20:05 +0300 (EEST) Date: Sat, 19 Aug 2017 19:20:05 +0300 From: Ilari Liusvaara To: Tony Arcieri Cc: "" Message-ID: <20170819162005.bwjmos4rtij7rdmj@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-in-TLS tunneling use cases (was: SNI Encryption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 19 Aug 2017 16:20:11 -0000 On Wed, Aug 09, 2017 at 10:54:46PM -0700, Tony Arcieri wrote: > Consider: a gateway server acting as an external proxy which bridges an > internal network with the Internet, acting as a forward proxy to > authenticated clients (either human-driven apps/tools or backend services). > These sorts of tunnels (ab)use a HTTP(S) forward-proxy to establish > outbound TCP connections (which, if you care about security, will carry TLS > encrypted traffic). > > This approach is partly described in RFC 2817[2], but to tick all of the > checkboxes on the points I mentioned earlier using this method, you need to > implement features in draft-luotonen-web-proxy-tunneling-01[3], which has > never received an RFC and, as far as I can tell, is only properly > implemented by Squid. Using Squid as a TLS-in-TLS tunneling solution seems > less than ideal to me, and yet in many ways it seems like the "least > friction" option, especially for access control purposes. As far as I can see, draft-luotonen-web-proxy-tunneling-01 doesn't really bring anything new on top of RFC 2817 (and in fact, is older than the RFC). Neither seemingly describes TLS-in-TLS (SSL-in-SSL) tunnels. But those are a straightforward extension of the normal HTTP tunneling mechanism. Including cases where trustpiles for inner and outer connections are different and where client certificates are different. However, some non-TLS protocols will not work over HTTPS CONNECT, unless both client and proxy break TLS semantics (specifically the behavior of close_notify alert). In terms of complexity, as far as I can see, the complexity of minimal implementation of HTTPS tunneling is comparable to dedicated TLS layer method. HTTPS tunneling does double-encrypt, but eliminating that double encryption is nontrivial (at least for analysis). One annoyance in HTTPS tunneling is that the hostname can be duplicated in three places: 1) The CONNECT target (this is actual place to connect to). 2) The host header (this is supposed to be absent in HTTP/1.0, and MAY be blank in HTTP/1.1). 3) The SNI in TLS handshake (in plaintext, can be extracted). -Ilari From nobody Tue Aug 22 07:16: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 59BD41329B6 for ; Tue, 22 Aug 2017 07:16:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.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 JLBTGvy9R4xQ for ; Tue, 22 Aug 2017 07:16:24 -0700 (PDT) Received: from asbsmtoutape02.symantec.com (asbsmtoutape02.symantec.com [155.64.138.34]) (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 5A6A51329B8 for ; Tue, 22 Aug 2017 07:16:24 -0700 (PDT) Received: from asbsmtmtaapi02.symc.symantec.com (asb1-f5-symc-ext-prd-snat8.net.symantec.com [10.90.75.8]) by asbsmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id 62.02.30714.7BC3C995; Tue, 22 Aug 2017 14:16:23 +0000 (GMT) X-AuditID: 0a5af81a-737859a0000177fa-01-599c3cb7ffb2 Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat7.net.symantec.com [10.90.75.7]) by asbsmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 9D.6A.58537.3BC3C995; Tue, 22 Aug 2017 14:16:23 +0000 (GMT) Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 22 Aug 2017 07:16:18 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.128.4) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Tue, 22 Aug 2017 07:16:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LH3OstLQc68ATqbEhhPy32QDpny066o235lb3CPCG6w=; b=N6lLhGTYSCIFDviQe+WXO9jPVonJp2ILtowbHlqAJN5VshW464IhOpmkbEdqCO55SIwy4M+gjA2KD4WJsxfp2sFcYfX//CfrrXSVmKxwys3omFx6XVdej4TZGmPVTsmXPQg/usb1ICQ6XjN9zg/DlQruJhBQ3nmcqZHmf3drIzg= Received: from DM5PR16MB1723.namprd16.prod.outlook.com (10.172.44.16) by DM5PR16MB1530.namprd16.prod.outlook.com (10.173.212.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Tue, 22 Aug 2017 14:16:16 +0000 Received: from DM5PR16MB1723.namprd16.prod.outlook.com ([10.172.44.16]) by DM5PR16MB1723.namprd16.prod.outlook.com ([10.172.44.16]) with mapi id 15.01.1362.019; Tue, 22 Aug 2017 14:16:17 +0000 From: Noah Robbin To: "tls@ietf.org" Thread-Topic: What counts as the same ClientHello? Thread-Index: AQHTG1E3oLw1mAaE8UCKW3rg0dt+vQ== Date: Tue, 22 Aug 2017 14:16:16 +0000 Message-ID: <66EC4BBA-6082-40BA-B723-7C9F0A35E6EA@symantec.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=Noah_Robbin@symantec.com; x-originating-ip: [72.23.5.194] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1530; 6:EqwCTzcAapBl3CguG0cV1DkvQboEA5nBCvc07bN+mCiriX0Fo6CgKXhYq15jTQnxhmNIg0uqmArj2tXAnLntCEh+H4zyAD8qHke2vzaiUTN19L4FaXNn2UVK3Uqs9L6XLMcNtdhUw1+MpYNO06oKiRY32lkgBsVXBlwLqvHLggcF9VWm6CT2YTgl5/B5Gv/sKBFUFgXRa4sCOOgqrjTEo+SV3LMBuikLBIB8JQ/ipBHXJGxQ7hLlIIJr7SM+aBR9LO6v5T5N0WhK+pVrhLaUuT5jb07mwt7sSi686DbOFD2soeflmMIV42FjgLMT2Avf0WsDTB6MRPOhAAvtKw/EJg==; 5:ATHy38snaNMR4NPqjp0aTjWZ8hkJTDlZcKjbdg/z9Oz1anjwp9gsxZiL/tfDWc/PNLqPzpLAbYrpGklxDlKYOIVXlUi1ndcXjhhEp+zREQ3hKO/yv8hLfXTZe9xWrxm+ddBPDdga4u1D03CoFaANTw==; 24:AN9tn5Yn8Z3GQteDhVcNBvomhYritr5DF2xMN71SYcFYOVTL1xT7u7VHc495XjJlnr77MVg24REejDC2sXInIhrb2Dbn5fzZ7tprj3fIRbQ=; 7:bYP53MiY8xryeFrMudBFdCgPdkWnCeV4Zac/GV98+wPAlyAlCi94TbQBU0Lv0fkEYe8hRVlSprT36riiRMSDJ+z/eL4a9J48zZakkBj0SwoMziBQ5gThDL0Tm05/8QQfNvrD5nbFCubNLtRtryQJHtOXxBYdVhP0v+j2tGmvIZtbxeR7i/+qX5xzv+1bz98QOCC36XfGfRn8k0ayHNTHsHiHR7Gfp4jAYR2AYLAyYx4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 83caf91c-2446-4930-965c-08d4e9685a8b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1530; x-ms-traffictypediagnostic: DM5PR16MB1530: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1530; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1530; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(81166006)(2501003)(110136004)(36756003)(81156014)(53936002)(14454004)(66066001)(478600001)(101416001)(8676002)(83716003)(82746002)(33656002)(6512007)(54896002)(6306002)(86362001)(10290500003)(80792005)(25786009)(6436002)(2900100001)(1730700003)(50986999)(54356999)(102836003)(3846002)(6116002)(189998001)(6506006)(106356001)(77096006)(5660300001)(105586002)(68736007)(6486002)(2351001)(3280700002)(8936002)(97736004)(6916009)(2906002)(5640700003)(7736002)(99286003)(72206003)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1530; H:DM5PR16MB1723.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_66EC4BBA608240BAB7237C9F0A35E6EAsymanteccom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 14:16:16.9644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1530 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsXCFeXNobvdZk6kwdc2EYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsbX3CGvBAfOKxyu+szUwfjbtYuTkkBAwkdg78QhzFyMXh5DA R0aJu50r2bsYOcASG4/nQcS/MUo03JrLDuEcYZTYeeobK0i3kMALRomruwRAEiwCncwSP8/d gKqaxiSxZmkLQsu9i11sIC1sAjoSr6esYQKxRQQUJXZc7WYHsYUFdCW2rnvPDhE3krh99DAL hK0n8eTnSjCbRUBVYu+6L2A1vAL2Es87ToDNYRQQk/h+CmIms4C4xK0n85kgnhOQWLLnPDOE LSrx8vE/Voj6aIkNk/eyQ8TlJe4/Pc0IYctKXJrfzQhytIRAG7vE2atbWCESehJbJ76FKvKV 2LT7NRtE0SMmid9LjkFt05L4tucZ1FRvie2nrrNA2NkSMz4eYoVouMwq8fH1VqhJMhLLfnaz TmDUm4Xkcgg7WaJryRz2WWCfCkqcnPmEZRYwVpgFNCXW79KHKFGUmNL9kB3C1pBonTMXyvaQ mLBhIRuymgWMHKsYFRKLk4pzS/JLSxILUg2M9Iorc5NBRCIwMSXrJefnbmIEJ6cfUjsYn9zx OcQowMGoxMN7Sn5OpBBrYhlQ5SFGCQ5mJRHej5ZAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryH f5lFCgmkJ5akZqemFqQWwWSZODilGhhjRRKXH2j8c0L87v8QEcH9HzdlR8cxaOh8n2HS/sr6 WforA4FzWzZwGc+IcmyKvCVxU+4645RfBTrs4ZGPnBsZe+fMiWQyuLVgXfjaF7IvNxVtqbHy FLoheDJIs9jIPuvi1WdeFtXBp6cV9Siz8rT0laxf5yk+4YCDOuv5KHGvSAur76K3xZVYijMS DbWYi4oTAcLxXGFKAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsXCFeXNrrvdZk6kweHr7BafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoErY2vvEdaCA+YVj1d8Z2tg/GzaxcjBISFgIrHxeF4XIxeHkMA3 RomGW3PZIZwjjBI7T31j7WLkBHJeMEpc3SUAkmAR6GSW+HnuBlTVNCaJNUtbEFruXexiA2lh E9CReD1lDROILSKgKLHjajc7iC0soCuxdd17doi4kcTto4dZIGw9iSc/V4LZLAKqEnvXfQGr 4RWwl3jecQJsDqOAmMT3UxAzmQXEJW49mQ9mSwgISCzZc54ZwhaVePn4HytEfbTEhsl72SHi 8hL3n55mhLBlJS7N72YEOVpCoI1d4uzVLawQCT2JrRPfQhX5Smza/ZoNougRk8TvJcegtmlJ fNvzDGqqt8T2U9dZIOxsiRkfD7FCNFxmlfj4eivUJBmJZT+7oTbsZpX4MiMIFPRCAqkS22eo T2DUmoXkIQg7WaJryRz2WeAAEJQ4OfMJyyygDmYBTYn1u/QhShQlpnQ/ZIewNSRa58yFsj0k JmxYyIasZgEjxypGhcTipOLcktySxMSCTAMjveLK3GQQkQhMSsl6yfm5mxjBiem3+A7Gc398 DjEKcDAq8fBaWM+JFGJNLAOqPMQozcGiJM6rvUokUkggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAOjxmpbZi2/yxp/N5g2yrEabpBpmsN43+amqtWzqKmW3AmvJJYc4yo72s4s6JL+vbDAVOc4 Q/meDY1TtB8IBIZE/ct2dg4RZbufqnLMaOmxJSz1/M3GiR/WP1+Rc2aJCv8y80WV/brlfCzz b9hqxehNfet9gMX90XSVuQI+z++qMUnlfbP7+FeJpTgj0VCLuag4EQAuP+ySLQMAAA== X-CFilter-Loop: ASB03 Archived-At: Subject: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 Aug 2017 14:16:26 -0000 --_000_66EC4BBA608240BAB7237C9F0A35E6EAsymanteccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VjdGlvbiA0LjEuMiBvZiB0aGUgVExTIDEuMyBkcmFmdCBSRkMgc3BlY2lmaWVzIHRoYXQgdGhl IENsaWVudEhlbGxvIHNlbnQgaW4gcmVzcG9uc2UgdG8gYSBIZWxsb1JldHJ5UmVxdWVzdCDigJxN VVNUIGJlIHRoZSBzYW1lICh3aXRob3V0IG1vZGlmaWNhdGlvbikgZXhjZXB04oCdIGZvciBhIGxp c3Qgb2Ygc3BlY2lmaWMgZXhjZXB0aW9ucy4gIEkgaGF2ZSBmb3VuZCBvbmUgc2VydmVyIHRoYXQg dmVyaWZpZXMgdGhhdCB0aGUgcmFuZG9tIGluIHRoZSBmaXJzdCBDbGllbnRIZWxsbyBpcyB0aGUg c2FtZSBhcyB0aGUgcmFuZG9tIGluIHRoZSBzZWNvbmQgQ2xpZW50SGVsbG8uICBJIGhhdmUgYWxz byBmb3VuZCBzZXJ2ZXJzIHRoYXQgYWNjZXB0IHRoZSBzZWNvbmQgQ2xpZW50SGVsbG8gd2l0aCBh IGRpZmZlcmVudCByYW5kb20uICBNYW55IGNsaWVudHMgYXJlIHNlbmRpbmcgYSBkaWZmZXJlbnQg cmFuZG9tIGluIHRoZSBzZWNvbmQgQ2xpZW50SGVsbG8uDQpNeSByZWFkaW5nIG9mIHRoZSBzcGVj aWZpY2F0aW9uIGlzIHRoYXQgdGhlIHJhbmRvbSBtdXN0IGJlIHRoZSBzYW1lLCBidXQgaWYgdGhl cmUgYXJlIGNsaWVudHMgYW5kIHNlcnZlcnMgdGFraW5nIGRpZmZlcmVudCBwb3N0dXJlcyBvbiB0 aGlzIHdlIHdpbGwgcnVuIGludG8gaW50ZXJvcCBpc3N1ZXMuDQpJIGFsc28gaGF2ZSB0d28gYWRk aXRpb25hbCBxdWVzdGlvbnMuDQoxIC0gVGhlIGNoYW5nZXMgdG8ga2V5X3NoYXJlLCBlYXJseV9k YXRhLCBhbmQgcHJlX3NoYXJlZF9rZXkgZXh0ZW5zaW9ucywgYW5kIHRoZSBhZGRpdGlvbiBvZiB0 aGUgY29va2llIGV4dGVuc2lvbiBtYXkgY2hhbmdlIHRoZSBvdmVyYWxsIGxlbmd0aCBvZiB0aGUg Q2xpZW50SGVsbG8gc3VjaCB0aGF0IGl0IGlzIG5vdyBpbiB0aGUgMjU2LTUxMSByYW5nZSB0aGF0 IHNvbWUgaW1wbGVtZW50YXRpb25zIGhhdmUgaXNzdWVzIHdpdGguICBJcyBpdCBwZXJtaXNzaWJs ZSB0byBhbHRlciB0aGUgcGFkZGluZyBleHRlbnNpb24/DQoyIC0gIFRoZSBNVVNUIGxhbmd1YWdl IG1lYW5zIHRoYXQgdGhlIG9yZGVyIG9mIHRoZSBleHRlbnNpb25zIG11c3QgcmVtYWluIHRoZSBz YW1lLiAgSG93IHN0cmljdGx5IHNob3VsZCBhIHNlcnZlciBlbmZvcmNlIHRoaXMgYW5kIGRvZXMg dGhpcyBjcmVhdGUgYSByZXF1aXJlbWVudCBmb3Igd2hlcmUgdGhlIGNvb2tpZSBleHRlbnNpb24g c2hvdWxkIGJlIGluc2VydGVkIGludG8gdGhlIGxpc3Q/DQoNClRoYW5rIHlvdSwNCk5vYWggUm9i YmluDQoNCg== --_000_66EC4BBA608240BAB7237C9F0A35E6EAsymanteccom_ Content-Type: text/html; charset="utf-8" Content-ID: <3C3048A4E6C95A4DA8B399E24210AAFE@namprd16.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWN0aW9u IDQuMS4yIG9mIHRoZSBUTFMgMS4zIGRyYWZ0IFJGQyBzcGVjaWZpZXMgdGhhdCB0aGUgQ2xpZW50 SGVsbG8gc2VudCBpbiByZXNwb25zZSB0byBhIEhlbGxvUmV0cnlSZXF1ZXN0IOKAnE1VU1QgYmUg dGhlIHNhbWUgKHdpdGhvdXQgbW9kaWZpY2F0aW9uKSBleGNlcHTigJ0gZm9yIGEgbGlzdCBvZiBz cGVjaWZpYyBleGNlcHRpb25zLiZuYnNwOyBJIGhhdmUgZm91bmQNCiBvbmUgc2VydmVyIHRoYXQg dmVyaWZpZXMgdGhhdCB0aGUgcmFuZG9tIGluIHRoZSBmaXJzdCBDbGllbnRIZWxsbyBpcyB0aGUg c2FtZSBhcyB0aGUgcmFuZG9tIGluIHRoZSBzZWNvbmQgQ2xpZW50SGVsbG8uJm5ic3A7IEkgaGF2 ZSBhbHNvIGZvdW5kIHNlcnZlcnMgdGhhdCBhY2NlcHQgdGhlIHNlY29uZCBDbGllbnRIZWxsbyB3 aXRoIGEgZGlmZmVyZW50IHJhbmRvbS4mbmJzcDsgTWFueSBjbGllbnRzIGFyZSBzZW5kaW5nIGEg ZGlmZmVyZW50IHJhbmRvbSBpbiB0aGUNCiBzZWNvbmQgQ2xpZW50SGVsbG8uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NeSByZWFkaW5nIG9mIHRoZSBzcGVjaWZpY2F0aW9u IGlzIHRoYXQgdGhlIHJhbmRvbSBtdXN0IGJlIHRoZSBzYW1lLCBidXQgaWYgdGhlcmUgYXJlIGNs aWVudHMgYW5kIHNlcnZlcnMgdGFraW5nIGRpZmZlcmVudCBwb3N0dXJlcyBvbiB0aGlzIHdlIHdp bGwgcnVuIGludG8gaW50ZXJvcCBpc3N1ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5JIGFsc28gaGF2ZSB0d28gYWRkaXRpb25hbCBxdWVzdGlvbnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjEgLSBUaGUgY2hhbmdlcyB0byBrZXlfc2hhcmUsIGVhcmx5X2RhdGEsIGFuZCBwcmVf c2hhcmVkX2tleSBleHRlbnNpb25zLCBhbmQgdGhlIGFkZGl0aW9uIG9mIHRoZSBjb29raWUgZXh0 ZW5zaW9uIG1heSBjaGFuZ2UgdGhlIG92ZXJhbGwgbGVuZ3RoIG9mIHRoZSBDbGllbnRIZWxsbyBz dWNoIHRoYXQgaXQgaXMgbm93IGluIHRoZSAyNTYtNTExIHJhbmdlIHRoYXQNCiBzb21lIGltcGxl bWVudGF0aW9ucyBoYXZlIGlzc3VlcyB3aXRoLiZuYnNwOyBJcyBpdCBwZXJtaXNzaWJsZSB0byBh bHRlciB0aGUgcGFkZGluZyBleHRlbnNpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjIgLSZuYnNwOyBU aGUgTVVTVCBsYW5ndWFnZSBtZWFucyB0aGF0IHRoZSBvcmRlciBvZiB0aGUgZXh0ZW5zaW9ucyBt dXN0IHJlbWFpbiB0aGUgc2FtZS4mbmJzcDsgSG93IHN0cmljdGx5IHNob3VsZCBhIHNlcnZlciBl bmZvcmNlIHRoaXMgYW5kIGRvZXMgdGhpcyBjcmVhdGUgYSByZXF1aXJlbWVudCBmb3Igd2hlcmUg dGhlIGNvb2tpZSBleHRlbnNpb24gc2hvdWxkIGJlIGluc2VydGVkDQogaW50byB0aGUgbGlzdD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rIHlvdSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Tm9haCBSb2JiaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_66EC4BBA608240BAB7237C9F0A35E6EAsymanteccom_-- From nobody Tue Aug 22 08:06: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 B973D1329DC for ; Tue, 22 Aug 2017 08:06:37 -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=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 8F1ggqr0xuyW for ; Tue, 22 Aug 2017 08:06:35 -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 B9E851321A8 for ; Tue, 22 Aug 2017 08:06:34 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by m0122331.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7MF536D024787; Tue, 22 Aug 2017 16:06: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=X8q6S+Ud6SToPBG+9R2HYAQqJciUJY02J/+LQVfMr3g=; b=j6XutJwxX3zVZuT0zQpKtLbsFFQ+rTIBl3UvdBQxcLlVpdWGg5DM8qwF+Eo1TPxXWg+n 90rvv7/SXpp8rgdv4qUMBlE2bMABhAwSvG7CLDZydo/DoPGgAz/HteCSYEpog/bysVZn EZOY/K0STFFuXqRZYBBCzohOGE22u75Lm46aVMAy8CVuKV9MvmWIkr1JyucomgB6wyCp Vq7vexpgpegC/6SP2UsjYk5FqhLcdf6aBrazcDGdEy0oMIP8eZk4f8AWKYAP7ptHI2GV 6Us3dOXr21za7FJySk8m5w5W41AowTdzywrd2vtacmci2raNrRF7pb3y9Iw1/3EDn/UD jA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2cea6q3d8q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Aug 2017 16:06:30 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7MF5uY9026658; Tue, 22 Aug 2017 11:06:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cegnu3f1j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 22 Aug 2017 11:06:30 -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; Tue, 22 Aug 2017 08:06:29 -0700 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Tue, 22 Aug 2017 11:06:29 -0400 From: "Short, Todd" To: Noah Robbin CC: "tls@ietf.org" Thread-Topic: [TLS] What counts as the same ClientHello? Thread-Index: AQHTG1E3oLw1mAaE8UCKW3rg0dt+vaKQvN4A Date: Tue, 22 Aug 2017 15:06:28 +0000 Message-ID: References: <66EC4BBA-6082-40BA-B723-7C9F0A35E6EA@symantec.com> In-Reply-To: <66EC4BBA-6082-40BA-B723-7C9F0A35E6EA@symantec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.62] Content-Type: multipart/alternative; boundary="_000_A86E25C6157A40D5B5480C3BD4C4652Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-22_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-1708220233 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-22_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-1708220232 Archived-At: Subject: Re: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 Aug 2017 15:06:38 -0000 --_000_A86E25C6157A40D5B5480C3BD4C4652Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTm9haCENCg0KU2VlIGJlbG934oCmDQoNCi0tDQotVG9kZCBTaG9ydA0KLy8gdHNob3J0QGFr YW1haS5jb208bWFpbHRvOnRzaG9ydEBha2FtYWkuY29tPg0KLy8gIk9uZSBpZiBieSBsYW5kLCB0 d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuIg0KDQpPbiBBdWcgMjIsIDIw MTcsIGF0IDEwOjE2IEFNLCBOb2FoIFJvYmJpbiA8Tm9haF9Sb2JiaW5Ac3ltYW50ZWMuY29tPG1h aWx0bzpOb2FoX1JvYmJpbkBzeW1hbnRlYy5jb20+PiB3cm90ZToNCg0KU2VjdGlvbiA0LjEuMiBv ZiB0aGUgVExTIDEuMyBkcmFmdCBSRkMgc3BlY2lmaWVzIHRoYXQgdGhlIENsaWVudEhlbGxvIHNl bnQgaW4gcmVzcG9uc2UgdG8gYSBIZWxsb1JldHJ5UmVxdWVzdCDigJxNVVNUIGJlIHRoZSBzYW1l ICh3aXRob3V0IG1vZGlmaWNhdGlvbikgZXhjZXB04oCdIGZvciBhIGxpc3Qgb2Ygc3BlY2lmaWMg ZXhjZXB0aW9ucy4gIEkgaGF2ZSBmb3VuZCBvbmUgc2VydmVyIHRoYXQgdmVyaWZpZXMgdGhhdCB0 aGUgcmFuZG9tIGluIHRoZSBmaXJzdCBDbGllbnRIZWxsbyBpcyB0aGUgc2FtZSBhcyB0aGUgcmFu ZG9tIGluIHRoZSBzZWNvbmQgQ2xpZW50SGVsbG8uICBJIGhhdmUgYWxzbyBmb3VuZCBzZXJ2ZXJz IHRoYXQgYWNjZXB0IHRoZSBzZWNvbmQgQ2xpZW50SGVsbG8gd2l0aCBhIGRpZmZlcmVudCByYW5k b20uICBNYW55IGNsaWVudHMgYXJlIHNlbmRpbmcgYSBkaWZmZXJlbnQgcmFuZG9tIGluIHRoZSBz ZWNvbmQgQ2xpZW50SGVsbG8uDQpNeSByZWFkaW5nIG9mIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHRo YXQgdGhlIHJhbmRvbSBtdXN0IGJlIHRoZSBzYW1lLCBidXQgaWYgdGhlcmUgYXJlIGNsaWVudHMg YW5kIHNlcnZlcnMgdGFraW5nIGRpZmZlcmVudCBwb3N0dXJlcyBvbiB0aGlzIHdlIHdpbGwgcnVu IGludG8gaW50ZXJvcCBpc3N1ZXMuDQoNCkJhc2VkIG9uIHRoZSByZWFkaW5nLCB0aGUgQ2xpZW50 UmFuZG9tIG11c3QgYmUgaWRlbnRpY2FsIGluIGJvdGggQ2xpZW50SGVsbG9zLCBhbHRob3VnaCBJ IGRvIG5vdCBzZWUgYSByZWFzb24gdGhhdCB0aGV5IG5lZWQgdG8gYmUgdGhlIHNhbWUuIEl0IGlz IGxpa2VseSB0aGF0IHRoZSBzZXJ2ZXIgZG9lcyBub3Qga2VlcCB0aGUgb3JpZ2luYWwgQ2xpZW50 SGVsbG8gYXJvdW5kIGZvciBjb21wYXJpc29uLiBNb3JlIHRoYW4gbGlrZWx5IHRoZSBzZXJ2ZXIg Z2VuZXJhdGVzIGEgaGFzaCBvZiB0aGUgQ2xpZW50SGVsbG8gYW5kIHN0dWZmcyBpdCBpbnRvIHRo ZSBjb29raWUgZXh0ZW5zaW9uLg0KDQpJIGFsc28gaGF2ZSB0d28gYWRkaXRpb25hbCBxdWVzdGlv bnMuDQoxIC0gVGhlIGNoYW5nZXMgdG8ga2V5X3NoYXJlLCBlYXJseV9kYXRhLCBhbmQgcHJlX3No YXJlZF9rZXkgZXh0ZW5zaW9ucywgYW5kIHRoZSBhZGRpdGlvbiBvZiB0aGUgY29va2llIGV4dGVu c2lvbiBtYXkgY2hhbmdlIHRoZSBvdmVyYWxsIGxlbmd0aCBvZiB0aGUgQ2xpZW50SGVsbG8gc3Vj aCB0aGF0IGl0IGlzIG5vdyBpbiB0aGUgMjU2LTUxMSByYW5nZSB0aGF0IHNvbWUgaW1wbGVtZW50 YXRpb25zIGhhdmUgaXNzdWVzIHdpdGguICBJcyBpdCBwZXJtaXNzaWJsZSB0byBhbHRlciB0aGUg cGFkZGluZyBleHRlbnNpb24/DQoNCklNSE8sIHRoaXMgc2hvdWxkIG5vdCBtYXR0ZXIgd2l0aCBU TFN2MS4zLiBUaG9zZSBvbGRlciwgYnJva2VuLCBpbXBsZW1lbnRhdGlvbnMgd291bGQgbm90IHN1 cHBvcnQgVExTdjEuMywgYW5kIHN1YnNlcXVlbnRseSB3aWxsIG5vdCBzZW5kIGJhY2sgYSBIZWxs b1JldHJ5UmVxdWVzdC4gSSB3b3VsZCBob3BlIHRoYXQgdGhvc2Ugb2xkZXIsIGJyb2tlbiBpbXBs ZW1lbnRhdGlvbnMgd291bGQgYmUgdXBkYXRlZCB0byBmaXggdGhlaXIgaXNzdWUgd2l0aCBDbGll bnRIZWxsbyBsZW5ndGggd2hlbiB0aGV5IHVwZ3JhZGUgdG8gVExTdjEuMy4NCg0KMiAtICBUaGUg TVVTVCBsYW5ndWFnZSBtZWFucyB0aGF0IHRoZSBvcmRlciBvZiB0aGUgZXh0ZW5zaW9ucyBtdXN0 IHJlbWFpbiB0aGUgc2FtZS4gIEhvdyBzdHJpY3RseSBzaG91bGQgYSBzZXJ2ZXIgZW5mb3JjZSB0 aGlzIGFuZCBkb2VzIHRoaXMgY3JlYXRlIGEgcmVxdWlyZW1lbnQgZm9yIHdoZXJlIHRoZSBjb29r aWUgZXh0ZW5zaW9uIHNob3VsZCBiZSBpbnNlcnRlZCBpbnRvIHRoZSBsaXN0Pw0KDQpUaGUgbG9n aWNhbCBjaG9pY2Ugd291bGQgYmUgdG8gYXBwZW5kIGl0IHRvIHRoZSBlbmQsIHNvIGFzIHRvIG5v dCBjaGFuZ2UgdGhlIG9yZGVyIG9mIHRoZSBvdGhlciBleHRlbnNpb25zLiBCdXQgdGhlIHByZS1z aGFyZWQga2V5IG11c3QgYmUgbGFzdC4gU28sIG5ldmVyIG1pbmQuDQoNCk9wZW5TU0wgaW5zZXJ0 cyB0aGUgY29va2llIGFmdGVyIHRoZSBrZXkgc2hhcmUsIGJ1dCBiZWZvcmUgY2VydGlmaWNhdGUg YXV0aG9yaXRpZXMsIGJhc2ljYWxseSB0aGUgc2FtZSBwbGFjZSBhcyB0aGUgZWFybHkgZGF0YSBl eHRlbnNpb24gKHdoaWNoIGhhcyB0byBiZSByZW1vdmVkKSwgd2hpY2ggd291bGQgYWxzbyBiZSBh IGxvZ2ljYWwgY2hvaWNlLg0KDQpBZ2FpbiwgSSBkb27igJl0IHRoaW5rIHRoYXQgYSBzZXJ2ZXIg d291bGQga2VlcCBhbiBvbGRlciBDbGllbnRIZWxsbyBhcm91bmQsIGFuZCB3b3VsZCBpbnN0ZWFk IHN0b3JlIHRoZSBzdGF0ZSBpbiB0aGUgQ29va2llIGV4dGVuc2lvbiAoc2VlIHNlY3Rpb24gNC4y LjIsIHNlY29uZCByZWFzb24pLg0KDQoNClRoYW5rIHlvdSwNCk5vYWggUm9iYmluDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBs aXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_A86E25C6157A40D5B5480C3BD4C4652Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2D197276552D7640AD75B9E9634229CE@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBOb2Fo ITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClNlZSBiZWxvd+KA pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdo aXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+LS08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LVRvZGQgU2hvcnQ8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Ly8gPGEgaHJlZj0ibWFpbHRvOnRzaG9ydEBha2FtYWkuY29tIiBjbGFzcz0i Ij50c2hvcnRAYWthbWFpLmNvbTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ly8gJnF1b3Q7T25l IGlmIGJ5IGxhbmQsIHR3byBpZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4mcXVv dDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXVnIDIy LCAyMDE3LCBhdCAxMDoxNiBBTSwgTm9haCBSb2JiaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpOb2Fo X1JvYmJpbkBzeW1hbnRlYy5jb20iIGNsYXNzPSIiPk5vYWhfUm9iYmluQHN5bWFudGVjLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdl OiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tn cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgY2xhc3M9IiI+U2VjdGlv biA0LjEuMiBvZiB0aGUgVExTIDEuMyBkcmFmdCBSRkMgc3BlY2lmaWVzIHRoYXQgdGhlIENsaWVu dEhlbGxvIHNlbnQgaW4gcmVzcG9uc2UgdG8gYSBIZWxsb1JldHJ5UmVxdWVzdCDigJxNVVNUIGJl IHRoZSBzYW1lICh3aXRob3V0IG1vZGlmaWNhdGlvbikgZXhjZXB04oCdIGZvciBhIGxpc3Qgb2Yg c3BlY2lmaWMgZXhjZXB0aW9ucy4mbmJzcDsgSSBoYXZlIGZvdW5kIG9uZSBzZXJ2ZXINCiB0aGF0 IHZlcmlmaWVzIHRoYXQgdGhlIHJhbmRvbSBpbiB0aGUgZmlyc3QgQ2xpZW50SGVsbG8gaXMgdGhl IHNhbWUgYXMgdGhlIHJhbmRvbSBpbiB0aGUgc2Vjb25kIENsaWVudEhlbGxvLiZuYnNwOyBJIGhh dmUgYWxzbyBmb3VuZCBzZXJ2ZXJzIHRoYXQgYWNjZXB0IHRoZSBzZWNvbmQgQ2xpZW50SGVsbG8g d2l0aCBhIGRpZmZlcmVudCByYW5kb20uJm5ic3A7IE1hbnkgY2xpZW50cyBhcmUgc2VuZGluZyBh IGRpZmZlcmVudCByYW5kb20gaW4gdGhlIHNlY29uZCBDbGllbnRIZWxsby48L3NwYW4+PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHls ZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2Fs aWJyaTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGNsYXNzPSIi PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj5NeSByZWFkaW5nIG9m IHRoZSBzcGVjaWZpY2F0aW9uIGlzIHRoYXQgdGhlIHJhbmRvbSBtdXN0IGJlIHRoZSBzYW1lLCBi dXQgaWYgdGhlcmUgYXJlIGNsaWVudHMgYW5kIHNlcnZlcnMgdGFraW5nIGRpZmZlcmVudCBwb3N0 dXJlcyBvbiB0aGlzIHdlIHdpbGwgcnVuIGludG8gaW50ZXJvcCBpc3N1ZXMuPC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2PkJhc2VkIG9uIHRoZSByZWFkaW5nLCB0aGUgQ2xpZW50UmFuZG9tIG11c3QgYmUg aWRlbnRpY2FsIGluIGJvdGggQ2xpZW50SGVsbG9zLCBhbHRob3VnaCBJIGRvIG5vdCBzZWUgYSBy ZWFzb24gdGhhdCB0aGV5IG5lZWQgdG8gYmUgdGhlIHNhbWUuIEl0IGlzIGxpa2VseSB0aGF0IHRo ZSBzZXJ2ZXIgZG9lcyBub3Qga2VlcCB0aGUgb3JpZ2luYWwgQ2xpZW50SGVsbG8gYXJvdW5kIGZv ciBjb21wYXJpc29uLiBNb3JlIHRoYW4gbGlrZWx5IHRoZQ0KIHNlcnZlciBnZW5lcmF0ZXMgYSBo YXNoIG9mIHRoZSBDbGllbnRIZWxsbyBhbmQgc3R1ZmZzIGl0IGludG8gdGhlIGNvb2tpZSBleHRl bnNpb24uPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsi IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgY2xhc3M9 IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj5JIGFs c28gaGF2ZSB0d28gYWRkaXRpb25hbCBxdWVzdGlvbnMuPG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj4xIC0gVGhlIGNoYW5nZXMgdG8ga2V5X3NoYXJlLCBl YXJseV9kYXRhLCBhbmQgcHJlX3NoYXJlZF9rZXkgZXh0ZW5zaW9ucywgYW5kIHRoZSBhZGRpdGlv biBvZiB0aGUgY29va2llIGV4dGVuc2lvbiBtYXkgY2hhbmdlIHRoZSBvdmVyYWxsIGxlbmd0aCBv ZiB0aGUgQ2xpZW50SGVsbG8gc3VjaCB0aGF0IGl0IGlzIG5vdyBpbiB0aGUgMjU2LTUxMSByYW5n ZSB0aGF0IHNvbWUgaW1wbGVtZW50YXRpb25zDQogaGF2ZSBpc3N1ZXMgd2l0aC4mbmJzcDsgSXMg aXQgcGVybWlzc2libGUgdG8gYWx0ZXIgdGhlIHBhZGRpbmcgZXh0ZW5zaW9uPzwvc3Bhbj48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5JTUhPLCB0aGlzIHNob3VsZCBub3QgbWF0dGVyIHdpdGggVExTdjEuMy4gVGhv c2Ugb2xkZXIsIGJyb2tlbiwgaW1wbGVtZW50YXRpb25zIHdvdWxkIG5vdCBzdXBwb3J0IFRMU3Yx LjMsIGFuZCBzdWJzZXF1ZW50bHkgd2lsbCBub3Qgc2VuZCBiYWNrIGEgSGVsbG9SZXRyeVJlcXVl c3QuIEkgd291bGQgaG9wZSB0aGF0IHRob3NlIG9sZGVyLCBicm9rZW4gaW1wbGVtZW50YXRpb25z IHdvdWxkIGJlIHVwZGF0ZWQgdG8gZml4IHRoZWlyIGlzc3VlDQogd2l0aCBDbGllbnRIZWxsbyBs ZW5ndGggd2hlbiB0aGV5IHVwZ3JhZGUgdG8gVExTdjEuMy48L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsiIGNsYXNzPSIiPjIgLSZuYnNwOyBUaGUgTVVTVCBsYW5ndWFnZSBtZWFucyB0aGF0 IHRoZSBvcmRlciBvZiB0aGUgZXh0ZW5zaW9ucyBtdXN0IHJlbWFpbiB0aGUgc2FtZS4mbmJzcDsg SG93IHN0cmljdGx5IHNob3VsZCBhIHNlcnZlciBlbmZvcmNlIHRoaXMgYW5kIGRvZXMgdGhpcyBj cmVhdGUgYSByZXF1aXJlbWVudCBmb3Igd2hlcmUgdGhlIGNvb2tpZSBleHRlbnNpb24gc2hvdWxk IGJlIGluc2VydGVkIGludG8NCiB0aGUgbGlzdD88L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhlIGxv Z2ljYWwgY2hvaWNlIHdvdWxkIGJlIHRvIGFwcGVuZCBpdCB0byB0aGUgZW5kLCBzbyBhcyB0byBu b3QgY2hhbmdlIHRoZSBvcmRlciBvZiB0aGUgb3RoZXIgZXh0ZW5zaW9ucy4gQnV0IHRoZSBwcmUt c2hhcmVkIGtleSBtdXN0IGJlIGxhc3QuIFNvLCBuZXZlciBtaW5kLjwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+T3BlblNTTCBpbnNlcnRzIHRoZSBjb29raWUgYWZ0ZXIg dGhlIGtleSBzaGFyZSwgYnV0IGJlZm9yZSBjZXJ0aWZpY2F0ZSBhdXRob3JpdGllcywgYmFzaWNh bGx5IHRoZSBzYW1lIHBsYWNlIGFzIHRoZSBlYXJseSBkYXRhIGV4dGVuc2lvbiAod2hpY2ggaGFz IHRvIGJlIHJlbW92ZWQpLCB3aGljaCB3b3VsZCBhbHNvIGJlIGEgbG9naWNhbCBjaG9pY2UuPC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5BZ2FpbiwgSSBkb27igJl0IHRo aW5rIHRoYXQgYSBzZXJ2ZXIgd291bGQga2VlcCBhbiBvbGRlciBDbGllbnRIZWxsbyBhcm91bmQs IGFuZCB3b3VsZCBpbnN0ZWFkIHN0b3JlIHRoZSBzdGF0ZSBpbiB0aGUgQ29va2llIGV4dGVuc2lv biAoc2VlIHNlY3Rpb24gNC4yLjIsIHNlY29uZCByZWFzb24pLjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IiBjbGFzcz0iIj5UaGFuayB5b3UsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IiBjbGFzcz0iIj5Ob2FoIFJvYmJpbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGZsb2F0OiBu b25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg MjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UTFMNCiBtYWls aW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4NCjxh IGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcmdiKDE0OSwgNzksIDEx NCk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xh c3M9IiI+VExTQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9 IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIg c3R5bGU9ImNvbG9yOiByZ2IoMTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A86E25C6157A40D5B5480C3BD4C4652Bakamaicom_-- From nobody Tue Aug 22 10:10: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 37DF913213D for ; Tue, 22 Aug 2017 10:10:33 -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 ffGRcadY2utP for ; Tue, 22 Aug 2017 10:10:31 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id CD690132026 for ; Tue, 22 Aug 2017 10:10:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id D385E5370B; Tue, 22 Aug 2017 20:10:28 +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 zZcSvrzbKm1m; Tue, 22 Aug 2017 20:10:28 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7D62827F; Tue, 22 Aug 2017 20:10:26 +0300 (EEST) Date: Tue, 22 Aug 2017 20:10:26 +0300 From: Ilari Liusvaara To: Noah Robbin Cc: "tls@ietf.org" Message-ID: <20170822171026.d2vbcjq3cye4yyzi@LK-Perkele-VII> References: <66EC4BBA-6082-40BA-B723-7C9F0A35E6EA@symantec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <66EC4BBA-6082-40BA-B723-7C9F0A35E6EA@symantec.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 Aug 2017 17:10:33 -0000 On Tue, Aug 22, 2017 at 02:16:16PM +0000, Noah Robbin wrote: > Section 4.1.2 of the TLS 1.3 draft RFC specifies that the ClientHello > sent in response to a HelloRetryRequest “MUST be the same (without > modification) except†for a list of specific exceptions. I have > found one server that verifies that the random in the first > ClientHello is the same as the random in the second ClientHello. I > have also found servers that accept the second ClientHello with a > different random. Many clients are sending a different random in the > second ClientHello. The actual reason for this requirement appears to be that the server might have committed several decisions that it can't back off of (e.g., ALPN), and which are not apparent in HelloRetryRequest. The implementation I have written indeed does this sort of commitment with every parameter that is actually used (but not ClientRandom, because it isn't actually used in TLS 1.3). In fact, it does not even check if the decisions are consistent with the new Client Hello (only that the needed key share is present). -Ilari From nobody Tue Aug 22 10:51: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 05FCB132192 for ; Tue, 22 Aug 2017 10:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.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 ZBqiMTSzYxxT for ; Tue, 22 Aug 2017 10:50:58 -0700 (PDT) Received: from tussmtoutape02.symantec.com (tussmtoutape02.symantec.com [155.64.38.232]) (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 4B0681326F6 for ; Tue, 22 Aug 2017 10:50:58 -0700 (PDT) Received: from tussmtmtaapi02.symc.symantec.com (tus3-f5-symc-ext-prd-snat8.net.symantec.com [10.44.130.8]) by tussmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id 30.47.12137.10F6C995; Tue, 22 Aug 2017 17:50:57 +0000 (GMT) X-AuditID: 0a2c7e32-c08bc9a000012f69-75-599c6f013e43 Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat4.net.symantec.com [10.44.130.4]) by tussmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 0A.A3.51370.10F6C995; Tue, 22 Aug 2017 17:50:57 +0000 (GMT) Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 22 Aug 2017 10:50:55 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.128.8) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Tue, 22 Aug 2017 10:50:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=76QEkY+AnjOuqYrXB8vV9rXU7PDm4EuL9whm1aeL2Jw=; b=J1V56Qd7wqAwRp6qwZbvfRoNFZ02980EhMLaCErtIal89nZF0fNrlc4pYn5rbOoQmYOgyv3D43TZYynWl4BtMNGgLLevmjdX/4lPW4SHo8CupODj/M2eew7d4jqLTwNUA8RoZmQdf0WUrrC4bFO81nsGMQK00gd01TxTkExD11o= Received: from DM5PR16MB1723.namprd16.prod.outlook.com (10.172.44.16) by DM5PR16MB1753.namprd16.prod.outlook.com (10.172.44.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Tue, 22 Aug 2017 17:50:49 +0000 Received: from DM5PR16MB1723.namprd16.prod.outlook.com ([10.172.44.16]) by DM5PR16MB1723.namprd16.prod.outlook.com ([10.172.44.16]) with mapi id 15.01.1362.019; Tue, 22 Aug 2017 17:50:49 +0000 From: Noah Robbin To: "tls@ietf.org" , "Short, Todd" Thread-Topic: [TLS] What counts as the same ClientHello? Thread-Index: AQHTG28w7fmdIaOCV0yhonBkpJAAwA== Date: Tue, 22 Aug 2017 17:50:49 +0000 Message-ID: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.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=Noah_Robbin@symantec.com; x-originating-ip: [72.23.5.194] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1753; 6:tlhsLv4FHLy1h7d8h2vvMVEZFEfK2qLmOEZ2wCv1Wwgbb7EWvyg+0t5bR8Qr8RZ7X8GKUeEPcMzi8VOuGF1OekMY3PvncKVvP3ZTAElvMrqQcVxuN3gFeQAaBrFVm/92WZ1itJuGJUtzKO3VVuAeHqsEkbC0DaM1fw1P+rSQ+SBghnPjck7RopxotBp2HVsuvWnDWi11DW02elr2Aw+lINTkQLi47wFHzQeDPsq9MwtbG+LU+nWja+RddCGnasmRxVh4jeSNIWdPUjKA2l8ZTDkCS2B3Sx4C/Bx4idHJOmeXyZEtMqyOZwb9Z/YcIHaERtzFQUFprijkj/tbrD1QmA==; 5:0QcaXVGx+E4LI+re43D1kUQEqP+a56pJ0ULiYEFS0u7DA5CNwb9UKG6RyRLlJEJmehn6B/UiycmSQW13KhclWfOtZg/6W/vRPVJrZrU7y13PIFcNH/NrZdLfrCZYfasL+kIDNFNO8zskBQSraZ0vFg==; 24:FqcKlUNgyIpNAVyadktszpkvLkD9rG1HDFIKtwCbSpsUoAPKpTLB19YtB7b3YPts2mqcD8WKfqJ2DWJcY22Oi2oGeLderwNMpbgqT6AqBiw=; 7:T+0yj6kXPXOEg3ipl0ZR5WVe0aElDw2K0aPLWlw+yvSTETidACSYkEDGfZ4YVorQgBUMFojKGYXkQaDacVTPtsEO8IDoaOWoOWGsxMSHZfrwWzabWVd/CQSTXebWdBX6p68OXzpqabekxwhK9cnVAJumaJUsp+uFSBagQwoeNCzuXAwJGH2AytgKqLksqNY90BbVkNP6LrOYs++uh3yifmMtIlZKfSDjcm+ngNh2p7E= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ce5eb7e2-6a50-41a3-6ecd-08d4e9865324 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603171)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1753; x-ms-traffictypediagnostic: DM5PR16MB1753: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1753; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1753; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(24454002)(377454003)(189002)(97736004)(7736002)(66066001)(82746002)(3846002)(6116002)(102836003)(189998001)(77096006)(2900100001)(6486002)(8936002)(101416001)(83716003)(54356999)(50986999)(6506006)(81156014)(81166006)(2906002)(86362001)(8676002)(5660300001)(966005)(6512007)(6436002)(68736007)(3280700002)(53546010)(25786009)(3660700001)(72206003)(236005)(99286003)(14454004)(6246003)(53936002)(105586002)(54896002)(106356001)(6306002)(478600001)(2501003)(10290500003)(80792005)(229853002)(606006)(33656002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1753; H:DM5PR16MB1723.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_89458B97EEB14F3C8624796447B21CC2symanteccom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 17:50:49.3681 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1753 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed7L9rpavN4PmlgLwcw2lch9iBTyw7pRH1sZNuZb3pVdLAuv 0UAtMt00h6nUUCo1V5iXDGPoB6fgJcMZsi5OS8uaSpiGktuzwi8Pv/P//5/DOXAY0meADmJS szScKkuRIeIJKEFkCXMQZdfJo8atB6TLI2VIuqAr5scTsqr+RlJmMq0RZ4nzgiPJXEZqLqeS HL0kSPnRN4dyHj5C12qmpokitFKPypAXA+wh6Jw2kGVIwPiwywiKVz7+NzY6ennYWEUwZisj cDGA4JO91OPMI2ipbqZdBcWWkvBr/b7HMRDwbrCSxkU/gvplM+3qzGMj4Zu+hXCxH5sATtMf t+7LxsJKzRCFdSnoW2ZJzGJYH3vqZooNgze1L9x/hWwc/DZ8deuIDYBVK+5JsoHw3tFA4C1Y MPWOkJj9YX5mk8b5C9Be9ZqP9VD4MDvk2ToExhvKkWtoYHV8qDa85GFDDB33Fj2h01A7bOfh 0GcCFpv7PZ0iYLB7lMJ8Ejqtkx5OB8eShcIf3tJQYRj0GLuhaa2crkBi47bJMSvBrO/iGd2b esNgrYMyImZL3w/PeiQ4shf05Z/4mMPhVt0DD8vA1vST3p5pRMwTtEejVaszNdlajSKHi4oR q/Myla5HsXVaSrEyO/M5ch9XQUwXWm4/ZUEsg0Q7hdLEOrkPrcjdSloQMKTITxh6cUsSJivy rnOq7CSVNoNTW1AwQ4kChXZdudyHvaLQcOkcl8Op/rkE4xVUhIJjg+JDWlJ8NzeKqmzSgsoz fdqbcKdw39LltATbwnEvZ5Jljs6HL6tz0SX+3ubxqz3fF++qlflttFN27NwNZ9Bhs6z5sbVv 2Dg/09gzPC2RtM6WVmTsCNeFjctfNU1afdO6Jybkt5PNAUv2trFdo3GtqkJN4gmtf7iz0NEz JaLUKYroCFKlVvwFtfyKVlgDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsXCpdPEosuYPyfS4NktMYtP57sYLV61NbI7 MHlMPrKA2WPJkp9MAUxRXDYpqTmZZalF+nYJXBnv9j9jLFi0mLFi+s07TA2Mn+cxdjFyckgI mEj83bqHrYuRi0NI4DujxMUbXUwQzlFGiYf3OqEyLxkl1kxbzgrisAh0Mkt8/TUDKjOVSeLq yUmsEM4RRol5nzaygkxmE9CReD1lDROILSLgIvFhyW+wuLCAucTn6adZIOIWElPWPGWGsPUk fl1cDWazCKhKHJi5GayXV8Be4sfUF2BxRgExie+nIGYyC4hL3HoynwniCwGJJXvOM0PYohIv H/9jhaiPltgweS87RFxe4v7T01Bfy0pcmt/NCHK0hEAbu8S0qdvYIBJ6ElsnvoUq8pWYeeYe G0TRIyaJt8uPQE3Skji58wILhO0tsf3UdSg7W+LJx0MsEA2XWSUmTD0JlZCRWPazmxUicYJV 4tWS80BjOYABliqxfYb6BEatWUg+grCTJTZO2cE2CxwCghInZz5hmQXUwSygKbF+lz5EiaLE lO6H7BC2hkTrnLlQtofEjWXvWZHVLGDkWMWoUFJaXJxbkluSmFiQaWCkV1yZmwwiEoEpK1kv OT93EyM4bTlL7mA89MfnEKMAB6MSD6+F9ZxIIdbEMqDKQ4zSHCxK4rwmq0QihQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTBOWaF8x63ddRlvvQWPWv/ORQEekek9Xe1r7a3YdMWmXvGWT/za b1yRXsi5fP3K3njupIsbFk9t4qxMa+9ju13I7DTVYf+sawcOzDh/2C7oy48ZnoeuR+l3uF5Z zGj/PODFzCV6l/2qnkxdmX9/7fcJh35dKtilVHlucdUynx7bFfPThTYphBYpsRRnJBpqMRcV JwIATap8azwDAAA= X-CFilter-Loop: TUS03 Archived-At: Subject: Re: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 Aug 2017 17:51:01 -0000 --_000_89458B97EEB14F3C8624796447B21CC2symanteccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gVG9kZCENCg0KSSBhbHNvIGRpZCBub3Qgc2VlIGEgcmVhc29uIHdoeSB0aGUgcmFuZG9t IHZhbHVlcyBoYWQgdG8gYmUgdGhlIHNhbWUgYnV0IHRoZSBsYW5ndWFnZSBkb2VzIG1hbmRhdGUg aXQuICBJIHNlZSBzb21lIG9mIHRoZSBUTFMgMS4zIGNsaWVudHMgdXNpbmcgdGhlIHNhbWUgcmFu ZG9tIGFuZCBzb21lIGFyZSBub3QuICBUaGVyZSBwcm9iYWJseSBpc24ndCBhbnl0aGluZyB0aGF0 IG5lZWRzIHRvIGJlIGNoYW5nZWQgaW4gdGhlIHNwZWMsIGJ1dCBjbGllbnQgaW1wbGVtZW50ZXJz IHNob3VsZCBiZSBhd2FyZSBvZiB0aGUgcG90ZW50aWFsIGludGVyb3BlcmFiaWxpdHkgaXNzdWUg aWYgdGhlIHJhbmRvbSBpcyBub3QgbWFpbnRhaW5lZC4NCg0KWW91IG1ha2UgYSBnb29kIGFyZ3Vt ZW50IGZvciBub3QgYWx0ZXJpbmcgdGhlIHBhZGRpbmcgb24gdGhlIHNlY29uZCBDbGllbnRIZWxs by4NCg0KLU5vYWgNCg0KRnJvbTogIlNob3J0LCBUb2RkIiA8dHNob3J0QGFrYW1haS5jb20+DQpE YXRlOiBUdWVzZGF5LCBBdWd1c3QgMjIsIDIwMTcgYXQgMTE6MDYgQU0NClRvOiBOb2FoIFJvYmJp biA8Tm9haF9Sb2JiaW5Ac3ltYW50ZWMuY29tPg0KQ2M6ICJ0bHNAaWV0Zi5vcmciIDx0bHNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbRVhUXSBSZTogW1RMU10gV2hhdCBjb3VudHMgYXMgdGhlIHNhbWUg Q2xpZW50SGVsbG8/DQoNCkhpIE5vYWghDQoNClNlZSBiZWxvd+KApg0KDQotLQ0KLVRvZGQgU2hv cnQNCi8vIHRzaG9ydEBha2FtYWkuY29tPG1haWx0bzp0c2hvcnRAYWthbWFpLmNvbT4NCi8vICJP bmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiIN Cg0KT24gQXVnIDIyLCAyMDE3LCBhdCAxMDoxNiBBTSwgTm9haCBSb2JiaW4gPE5vYWhfUm9iYmlu QHN5bWFudGVjLmNvbTxtYWlsdG86Tm9haF9Sb2JiaW5Ac3ltYW50ZWMuY29tPj4gd3JvdGU6DQoN ClNlY3Rpb24gNC4xLjIgb2YgdGhlIFRMUyAxLjMgZHJhZnQgUkZDIHNwZWNpZmllcyB0aGF0IHRo ZSBDbGllbnRIZWxsbyBzZW50IGluIHJlc3BvbnNlIHRvIGEgSGVsbG9SZXRyeVJlcXVlc3Qg4oCc TVVTVCBiZSB0aGUgc2FtZSAod2l0aG91dCBtb2RpZmljYXRpb24pIGV4Y2VwdOKAnSBmb3IgYSBs aXN0IG9mIHNwZWNpZmljIGV4Y2VwdGlvbnMuICBJIGhhdmUgZm91bmQgb25lIHNlcnZlciB0aGF0 IHZlcmlmaWVzIHRoYXQgdGhlIHJhbmRvbSBpbiB0aGUgZmlyc3QgQ2xpZW50SGVsbG8gaXMgdGhl IHNhbWUgYXMgdGhlIHJhbmRvbSBpbiB0aGUgc2Vjb25kIENsaWVudEhlbGxvLiAgSSBoYXZlIGFs c28gZm91bmQgc2VydmVycyB0aGF0IGFjY2VwdCB0aGUgc2Vjb25kIENsaWVudEhlbGxvIHdpdGgg YSBkaWZmZXJlbnQgcmFuZG9tLiAgTWFueSBjbGllbnRzIGFyZSBzZW5kaW5nIGEgZGlmZmVyZW50 IHJhbmRvbSBpbiB0aGUgc2Vjb25kIENsaWVudEhlbGxvLg0KTXkgcmVhZGluZyBvZiB0aGUgc3Bl Y2lmaWNhdGlvbiBpcyB0aGF0IHRoZSByYW5kb20gbXVzdCBiZSB0aGUgc2FtZSwgYnV0IGlmIHRo ZXJlIGFyZSBjbGllbnRzIGFuZCBzZXJ2ZXJzIHRha2luZyBkaWZmZXJlbnQgcG9zdHVyZXMgb24g dGhpcyB3ZSB3aWxsIHJ1biBpbnRvIGludGVyb3AgaXNzdWVzLg0KDQpCYXNlZCBvbiB0aGUgcmVh ZGluZywgdGhlIENsaWVudFJhbmRvbSBtdXN0IGJlIGlkZW50aWNhbCBpbiBib3RoIENsaWVudEhl bGxvcywgYWx0aG91Z2ggSSBkbyBub3Qgc2VlIGEgcmVhc29uIHRoYXQgdGhleSBuZWVkIHRvIGJl IHRoZSBzYW1lLiBJdCBpcyBsaWtlbHkgdGhhdCB0aGUgc2VydmVyIGRvZXMgbm90IGtlZXAgdGhl IG9yaWdpbmFsIENsaWVudEhlbGxvIGFyb3VuZCBmb3IgY29tcGFyaXNvbi4gTW9yZSB0aGFuIGxp a2VseSB0aGUgc2VydmVyIGdlbmVyYXRlcyBhIGhhc2ggb2YgdGhlIENsaWVudEhlbGxvIGFuZCBz dHVmZnMgaXQgaW50byB0aGUgY29va2llIGV4dGVuc2lvbi4NCg0KSSBhbHNvIGhhdmUgdHdvIGFk ZGl0aW9uYWwgcXVlc3Rpb25zLg0KMSAtIFRoZSBjaGFuZ2VzIHRvIGtleV9zaGFyZSwgZWFybHlf ZGF0YSwgYW5kIHByZV9zaGFyZWRfa2V5IGV4dGVuc2lvbnMsIGFuZCB0aGUgYWRkaXRpb24gb2Yg dGhlIGNvb2tpZSBleHRlbnNpb24gbWF5IGNoYW5nZSB0aGUgb3ZlcmFsbCBsZW5ndGggb2YgdGhl IENsaWVudEhlbGxvIHN1Y2ggdGhhdCBpdCBpcyBub3cgaW4gdGhlIDI1Ni01MTEgcmFuZ2UgdGhh dCBzb21lIGltcGxlbWVudGF0aW9ucyBoYXZlIGlzc3VlcyB3aXRoLiAgSXMgaXQgcGVybWlzc2li bGUgdG8gYWx0ZXIgdGhlIHBhZGRpbmcgZXh0ZW5zaW9uPw0KDQpJTUhPLCB0aGlzIHNob3VsZCBu b3QgbWF0dGVyIHdpdGggVExTdjEuMy4gVGhvc2Ugb2xkZXIsIGJyb2tlbiwgaW1wbGVtZW50YXRp b25zIHdvdWxkIG5vdCBzdXBwb3J0IFRMU3YxLjMsIGFuZCBzdWJzZXF1ZW50bHkgd2lsbCBub3Qg c2VuZCBiYWNrIGEgSGVsbG9SZXRyeVJlcXVlc3QuIEkgd291bGQgaG9wZSB0aGF0IHRob3NlIG9s ZGVyLCBicm9rZW4gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIHVwZGF0ZWQgdG8gZml4IHRoZWly IGlzc3VlIHdpdGggQ2xpZW50SGVsbG8gbGVuZ3RoIHdoZW4gdGhleSB1cGdyYWRlIHRvIFRMU3Yx LjMuDQoNCg0KMiAtICBUaGUgTVVTVCBsYW5ndWFnZSBtZWFucyB0aGF0IHRoZSBvcmRlciBvZiB0 aGUgZXh0ZW5zaW9ucyBtdXN0IHJlbWFpbiB0aGUgc2FtZS4gIEhvdyBzdHJpY3RseSBzaG91bGQg YSBzZXJ2ZXIgZW5mb3JjZSB0aGlzIGFuZCBkb2VzIHRoaXMgY3JlYXRlIGEgcmVxdWlyZW1lbnQg Zm9yIHdoZXJlIHRoZSBjb29raWUgZXh0ZW5zaW9uIHNob3VsZCBiZSBpbnNlcnRlZCBpbnRvIHRo ZSBsaXN0Pw0KDQpUaGUgbG9naWNhbCBjaG9pY2Ugd291bGQgYmUgdG8gYXBwZW5kIGl0IHRvIHRo ZSBlbmQsIHNvIGFzIHRvIG5vdCBjaGFuZ2UgdGhlIG9yZGVyIG9mIHRoZSBvdGhlciBleHRlbnNp b25zLiBCdXQgdGhlIHByZS1zaGFyZWQga2V5IG11c3QgYmUgbGFzdC4gU28sIG5ldmVyIG1pbmQu DQoNCk9wZW5TU0wgaW5zZXJ0cyB0aGUgY29va2llIGFmdGVyIHRoZSBrZXkgc2hhcmUsIGJ1dCBi ZWZvcmUgY2VydGlmaWNhdGUgYXV0aG9yaXRpZXMsIGJhc2ljYWxseSB0aGUgc2FtZSBwbGFjZSBh cyB0aGUgZWFybHkgZGF0YSBleHRlbnNpb24gKHdoaWNoIGhhcyB0byBiZSByZW1vdmVkKSwgd2hp Y2ggd291bGQgYWxzbyBiZSBhIGxvZ2ljYWwgY2hvaWNlLg0KDQpBZ2FpbiwgSSBkb27igJl0IHRo aW5rIHRoYXQgYSBzZXJ2ZXIgd291bGQga2VlcCBhbiBvbGRlciBDbGllbnRIZWxsbyBhcm91bmQs IGFuZCB3b3VsZCBpbnN0ZWFkIHN0b3JlIHRoZSBzdGF0ZSBpbiB0aGUgQ29va2llIGV4dGVuc2lv biAoc2VlIHNlY3Rpb24gNC4yLjIsIHNlY29uZCByZWFzb24pLg0KDQoNCg0KVGhhbmsgeW91LA0K Tm9haCBSb2JiaW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tL2EvMS9IYzN2V1dXZGVIUVdienF3WEZEb1JlT1JiV3JFZ1M3WGow LTIyNlVEdk53PT9kPU9JdTBnajlQVW5HNWZJM244Zm5raEpQYmMxOUR3Z01uTF9ZVXV4YVp5TzN4 TnpLb1Zxb1pRdURwRDVkZEV1NHVkNTNlZlRZWmNUOHpQTDJTc252TVNLdnZaUE83b0l6c01ic3Fq YU9oVVd4N3R1c3QyWUk3STlQRElXMDg3SXBrMjJqeVpXRTZOZUQ1UXlXaEdGYTlQU0lYVkRkZU5y b0prTmx0dXB3RjVkcmVhUURTSHAtQzBUSWNFc0VHU1Y0clJSanFaaVRGNUxiVG1UM3F0YkU3ZFJY dWRCakdRb2RqMEZwWXA1VkRmNE53NVpxdVNvdHZ4dTkxZy14aEh1NXBDQWZhY2pQTnBuUlVPbEh6 N2lOTkZFQW1tOFRaVjByQjZNY1ZBRURZSllNVTFJOXBIMkt0V2Rlb1V1TklCMXdBNFZmcFRBckRC OFBCOXQ0UDZlYmJ1a0hxZndHa3lON2lHZGM0ZEpHclFEWkR3S25FUTVHOGN4Vzgtb0FTTzlQaVA2 bDRGU050JnU9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZ0bHM+DQoNCg== --_000_89458B97EEB14F3C8624796447B21CC2symanteccom_ Content-Type: text/html; charset="utf-8" Content-ID: <22E754AAE3D6F340B4E1CF83CFC660E1@namprd16.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPkhlbGxvIFRvZGQhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SSBhbHNvIGRp ZCBub3Qgc2VlIGEgcmVhc29uIHdoeSB0aGUgcmFuZG9tIHZhbHVlcyBoYWQgdG8gYmUgdGhlIHNh bWUgYnV0IHRoZSBsYW5ndWFnZSBkb2VzIG1hbmRhdGUgaXQuJm5ic3A7IEkgc2VlIHNvbWUgb2Yg dGhlIFRMUyAxLjMgY2xpZW50cyB1c2luZyB0aGUgc2FtZSByYW5kb20gYW5kIHNvbWUgYXJlIG5v dC4mbmJzcDsgVGhlcmUNCiBwcm9iYWJseSBpc24ndCBhbnl0aGluZyB0aGF0IG5lZWRzIHRvIGJl IGNoYW5nZWQgaW4gdGhlIHNwZWMsIGJ1dCBjbGllbnQgaW1wbGVtZW50ZXJzIHNob3VsZCBiZSBh d2FyZSBvZiB0aGUgcG90ZW50aWFsIGludGVyb3BlcmFiaWxpdHkgaXNzdWUgaWYgdGhlIHJhbmRv bSBpcyBub3QgbWFpbnRhaW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Zb3UgbWFrZSBh IGdvb2QgYXJndW1lbnQgZm9yIG5vdCBhbHRlcmluZyB0aGUgcGFkZGluZyBvbiB0aGUgc2Vjb25k IENsaWVudEhlbGxvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPi1Ob2FoPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+JnF1b3Q7U2hv cnQsIFRvZGQmcXVvdDsgJmx0O3RzaG9ydEBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UdWVzZGF5LCBBdWd1c3QgMjIsIDIwMTcgYXQgMTE6MDYgQU08YnI+DQo8Yj5UbzogPC9iPk5v YWggUm9iYmluICZsdDtOb2FoX1JvYmJpbkBzeW1hbnRlYy5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj4mcXVvdDt0bHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+W0VYVF0gUmU6IFtUTFNdIFdoYXQgY291bnRzIGFzIHRoZSBzYW1lIENsaWVu dEhlbGxvPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgTm9haCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TZWUgYmVsb3figKYgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LVRvZGQgU2hvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPi8vIDxhIGhyZWY9Im1haWx0bzp0c2hvcnRAYWthbWFpLmNvbSI+DQp0c2hvcnRA YWthbWFpLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi8vICZxdW90O09uZSBp ZiBieSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuJnF1b3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgMjIsIDIwMTcsIGF0IDEwOjE2IEFNLCBOb2Fo IFJvYmJpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOk5vYWhfUm9iYmluQHN5bWFudGVjLmNvbSI+Tm9h aF9Sb2JiaW5Ac3ltYW50ZWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+U2VjdGlvbiA0LjEu MiBvZiB0aGUgVExTIDEuMyBkcmFmdCBSRkMgc3BlY2lmaWVzIHRoYXQgdGhlIENsaWVudEhlbGxv IHNlbnQgaW4gcmVzcG9uc2UgdG8gYSBIZWxsb1JldHJ5UmVxdWVzdCDigJxNVVNUIGJlIHRoZSBz YW1lICh3aXRob3V0IG1vZGlmaWNhdGlvbikgZXhjZXB04oCdIGZvcg0KIGEgbGlzdCBvZiBzcGVj aWZpYyBleGNlcHRpb25zLiZuYnNwOyBJIGhhdmUgZm91bmQgb25lIHNlcnZlciB0aGF0IHZlcmlm aWVzIHRoYXQgdGhlIHJhbmRvbSBpbiB0aGUgZmlyc3QgQ2xpZW50SGVsbG8gaXMgdGhlIHNhbWUg YXMgdGhlIHJhbmRvbSBpbiB0aGUgc2Vjb25kIENsaWVudEhlbGxvLiZuYnNwOyBJIGhhdmUgYWxz byBmb3VuZCBzZXJ2ZXJzIHRoYXQgYWNjZXB0IHRoZSBzZWNvbmQgQ2xpZW50SGVsbG8gd2l0aCBh IGRpZmZlcmVudCByYW5kb20uJm5ic3A7IE1hbnkNCiBjbGllbnRzIGFyZSBzZW5kaW5nIGEgZGlm ZmVyZW50IHJhbmRvbSBpbiB0aGUgc2Vjb25kIENsaWVudEhlbGxvLjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+TXkgcmVhZGluZyBvZiB0aGUgc3BlY2lmaWNhdGlvbiBpcyB0 aGF0IHRoZSByYW5kb20gbXVzdCBiZSB0aGUgc2FtZSwgYnV0IGlmIHRoZXJlIGFyZSBjbGllbnRz IGFuZCBzZXJ2ZXJzIHRha2luZyBkaWZmZXJlbnQgcG9zdHVyZXMgb24gdGhpcyB3ZSB3aWxsIHJ1 biBpbnRvIGludGVyb3ANCiBpc3N1ZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFzZWQgb24gdGhlIHJlYWRpbmcs IHRoZSBDbGllbnRSYW5kb20gbXVzdCBiZSBpZGVudGljYWwgaW4gYm90aCBDbGllbnRIZWxsb3Ms IGFsdGhvdWdoIEkgZG8gbm90IHNlZSBhIHJlYXNvbiB0aGF0IHRoZXkgbmVlZCB0byBiZSB0aGUg c2FtZS4gSXQgaXMgbGlrZWx5IHRoYXQgdGhlIHNlcnZlciBkb2VzIG5vdCBrZWVwIHRoZSBvcmln aW5hbCBDbGllbnRIZWxsbyBhcm91bmQgZm9yIGNvbXBhcmlzb24uIE1vcmUNCiB0aGFuIGxpa2Vs eSB0aGUgc2VydmVyIGdlbmVyYXRlcyBhIGhhc2ggb2YgdGhlIENsaWVudEhlbGxvIGFuZCBzdHVm ZnMgaXQgaW50byB0aGUgY29va2llIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PkkgYWxzbyBoYXZlIHR3byBhZGRpdGlvbmFsIHF1ZXN0aW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4xIC0gVGhlIGNoYW5n ZXMgdG8ga2V5X3NoYXJlLCBlYXJseV9kYXRhLCBhbmQgcHJlX3NoYXJlZF9rZXkgZXh0ZW5zaW9u cywgYW5kIHRoZSBhZGRpdGlvbiBvZiB0aGUgY29va2llIGV4dGVuc2lvbiBtYXkgY2hhbmdlIHRo ZSBvdmVyYWxsIGxlbmd0aCBvZiB0aGUgQ2xpZW50SGVsbG8NCiBzdWNoIHRoYXQgaXQgaXMgbm93 IGluIHRoZSAyNTYtNTExIHJhbmdlIHRoYXQgc29tZSBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBpc3N1 ZXMgd2l0aC4mbmJzcDsgSXMgaXQgcGVybWlzc2libGUgdG8gYWx0ZXIgdGhlIHBhZGRpbmcgZXh0 ZW5zaW9uPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklNSE8sIHRoaXMgc2hvdWxkIG5vdCBtYXR0ZXIgd2l0aCBUTFN2 MS4zLiBUaG9zZSBvbGRlciwgYnJva2VuLCBpbXBsZW1lbnRhdGlvbnMgd291bGQgbm90IHN1cHBv cnQgVExTdjEuMywgYW5kIHN1YnNlcXVlbnRseSB3aWxsIG5vdCBzZW5kIGJhY2sgYSBIZWxsb1Jl dHJ5UmVxdWVzdC4gSSB3b3VsZCBob3BlIHRoYXQgdGhvc2Ugb2xkZXIsIGJyb2tlbiBpbXBsZW1l bnRhdGlvbnMgd291bGQgYmUgdXBkYXRlZCB0bw0KIGZpeCB0aGVpciBpc3N1ZSB3aXRoIENsaWVu dEhlbGxvIGxlbmd0aCB3aGVuIHRoZXkgdXBncmFkZSB0byBUTFN2MS4zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+MiAtJm5ic3A7IFRoZSBNVVNUIGxhbmd1YWdlIG1lYW5zIHRoYXQgdGhlIG9yZGVyIG9mIHRo ZSBleHRlbnNpb25zIG11c3QgcmVtYWluIHRoZSBzYW1lLiZuYnNwOyBIb3cgc3RyaWN0bHkgc2hv dWxkIGEgc2VydmVyIGVuZm9yY2UgdGhpcyBhbmQgZG9lcyB0aGlzIGNyZWF0ZSBhIHJlcXVpcmVt ZW50DQogZm9yIHdoZXJlIHRoZSBjb29raWUgZXh0ZW5zaW9uIHNob3VsZCBiZSBpbnNlcnRlZCBp bnRvIHRoZSBsaXN0Pzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBsb2dpY2FsIGNob2ljZSB3b3VsZCBiZSB0byBh cHBlbmQgaXQgdG8gdGhlIGVuZCwgc28gYXMgdG8gbm90IGNoYW5nZSB0aGUgb3JkZXIgb2YgdGhl IG90aGVyIGV4dGVuc2lvbnMuIEJ1dCB0aGUgcHJlLXNoYXJlZCBrZXkgbXVzdCBiZSBsYXN0LiBT bywgbmV2ZXIgbWluZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T3BlblNTTCBpbnNlcnRzIHRoZSBjb29raWUgYWZ0ZXIgdGhlIGtleSBzaGFy ZSwgYnV0IGJlZm9yZSBjZXJ0aWZpY2F0ZSBhdXRob3JpdGllcywgYmFzaWNhbGx5IHRoZSBzYW1l IHBsYWNlIGFzIHRoZSBlYXJseSBkYXRhIGV4dGVuc2lvbiAod2hpY2ggaGFzIHRvIGJlIHJlbW92 ZWQpLCB3aGljaCB3b3VsZCBhbHNvIGJlIGEgbG9naWNhbCBjaG9pY2UuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFnYWluLCBJIGRvbuKAmXQg dGhpbmsgdGhhdCBhIHNlcnZlciB3b3VsZCBrZWVwIGFuIG9sZGVyIENsaWVudEhlbGxvIGFyb3Vu ZCwgYW5kIHdvdWxkIGluc3RlYWQgc3RvcmUgdGhlIHN0YXRlIGluIHRoZSBDb29raWUgZXh0ZW5z aW9uIChzZWUgc2VjdGlvbiA0LjIuMiwgc2Vjb25kIHJlYXNvbikuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5UaGFuayB5b3UsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Tm9haCBSb2JiaW48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2E7YmFja2dyb3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj5UTFMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjwvc3Bhbj48YSBocmVm PSJtYWlsdG86VExTQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkhlbHZldGljYTtjb2xvcjojOTU0RjcyO2JhY2tncm91bmQ6d2hpdGUiPlRMU0BpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI ZWx2ZXRpY2EiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vYS8xL0hjM3ZXV1dkZUhRV2J6cXdYRkRvUmVPUmJXckVnUzdYajAtMjI2VUR2Tnc9P2Q9 T0l1MGdqOVBVbkc1ZkkzbjhmbmtoSlBiYzE5RHdnTW5MX1lVdXhhWnlPM3hOektvVnFvWlF1RHBE NWRkRXU0dWQ1M2VmVFlaY1Q4elBMMlNzbnZNU0t2dlpQTzdvSXpzTWJzcWphT2hVV3g3dHVzdDJZ STdJOVBESVcwODdJcGsyMmp5WldFNk5lRDVReVdoR0ZhOVBTSVhWRGRlTnJvSmtObHR1cHdGNWRy ZWFRRFNIcC1DMFRJY0VzRUdTVjRyUlJqcVppVEY1TGJUbVQzcXRiRTdkUlh1ZEJqR1FvZGowRnBZ cDVWRGY0Tnc1WnF1U290dnh1OTFnLXhoSHU1cENBZmFjalBOcG5SVU9sSHo3aU5ORkVBbW04VFpW MHJCNk1jVkFFRFlKWU1VMUk5cEgyS3RXZGVvVXVOSUIxd0E0VmZwVEFyREI4UEI5dDRQNmViYnVr SHFmd0dreU43aUdkYzRkSkdyUURaRHdLbkVRNUc4Y3hXOC1vQVNPOVBpUDZsNEZTTnQmYW1wO3U9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0bHMiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM5 NTRGNzI7YmFja2dyb3VuZDp3aGl0ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90bHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_89458B97EEB14F3C8624796447B21CC2symanteccom_-- From nobody Tue Aug 22 13:14: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 858EA132A28 for ; Tue, 22 Aug 2017 13:14:02 -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 yj1pUmn0QoTm for ; Tue, 22 Aug 2017 13:14:00 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id D12E1132A0B for ; Tue, 22 Aug 2017 13:13:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id B3F7553710; Tue, 22 Aug 2017 23:13:57 +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 k6a36m4EE0mU; Tue, 22 Aug 2017 23:13:57 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 4F3AE28A; Tue, 22 Aug 2017 23:13:54 +0300 (EEST) Date: Tue, 22 Aug 2017 23:13:54 +0300 From: Ilari Liusvaara To: Noah Robbin Cc: "tls@ietf.org" , "Short, Todd" Message-ID: <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 Aug 2017 20:14:02 -0000 On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote: > Hello Todd! > > I also did not see a reason why the random values had to be the same > but the language does mandate it. I really do not think there is any technical or security reason why the randoms have to be the same. After all, TLS 1.3 does not directly use the randoms anywhere (they only affect things indirectly via hashes of the handshake). > You make a good argument for not altering the padding on the second > ClientHello. I read that argument as "TLS 1.3 implementations should not need padding". I took a look at struct ClientHello and the extensions list: There are technical reasons for not altering (the client has no idea what the heck server did with these): - server_name - max_fragment_length - status_request - signature_algorithms - use_srtp - heartbeat - application_layer_protocol_negotiation - signed_certificate_timestamp - client_certificate_type - server_certificate_type - psk_key_exchange_modes (due to side-effects) - certificate_authorities - post_handshake_auth The following are explicitly listed as to be altered/deleted: - key_share - pre_shared_key - early_data - cookie The following do not negotiate state: - - padding The following can't appear in ClientHello: - oid_filters The following client gains information about in HRR: - - supported_groups (partially if key_share was not present). - supported_versions (the client knows what server selected). However the last group seems to be kind of things that are rather questionable to prune (might be okay, but those make me wary). Also, I came accross one edge case: What if client discovers that all tickets in pre_shared_key are incompatible? The definition does not allow 0 tickets, so choices are: 1) Leave all the tickets (which is not going to work) in. 2) Leave one ticket (which is not going to work) in. 3) Strip the entiere extension. -Ilari From nobody Mon Aug 28 07: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 8CA7A132D10 for ; Mon, 28 Aug 2017 07:03: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 YE5ra8ly9OcP for ; Mon, 28 Aug 2017 07:03:41 -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 BACEC132D0F for ; Mon, 28 Aug 2017 07:03:39 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id k126so2569505qkb.4 for ; Mon, 28 Aug 2017 07:03:39 -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=+Rp3x0I65CRAyGSt4Oo3B3kQJMti4lpjM4AmvUkOBFE=; b=Qqk74xWJrDzS25wPOse4fSlVWOVd5NWGvRkcYdnhxwFetz8TPRamL/5oAkcHF3lBvP gk3WoLZDEzZQHdTfLV6zOHaIVr0QXjkbDcNH2czYwmDn4R3CEB7F3oqNq/WBwvaAUCJs i8En7R0k2pKhvphqQwpikqyPBujetUhZRQpcA= 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=+Rp3x0I65CRAyGSt4Oo3B3kQJMti4lpjM4AmvUkOBFE=; b=s6S6AOCb4orZb6nzgt49Yzrf6rHel0TGHsLrkzPj2dLVBZc+BxXXVW817TOsQ9jt6f L+8gbqDB9QtbbUve0dPVUQnjGxL42nbDbpUikq3BWNyZAgTZyRIOVk084dZ4N8PlqkbK ugZ09013zzOqUFhvZ6j9RThjhfEsbSqVCWWUbcHg7AqbPxq9AVa9YDSQM9A7kKBzSwVm ThnDTGKwfVi3ltgHcA/ZBPrtpo/HhKBI6ouCrvKOsKYR1k5/qY4h9y+a1u0hCvmjNrfM j5LdTiaWJR9opV1pmKvoAA6fcWzhIWVgbh49sCg4jqq5QDFfQHJ6qn+bOAgKa0EKpVo+ mYKA== X-Gm-Message-State: AHPjjUiBBfxunGOhMQPCELbG2sLBg1/3YlmALgCBOHwIR2P0tDXuehpJ qeZ0bDDjd123YZ1abFxXAw== X-Received: by 10.55.161.214 with SMTP id k205mr870293qke.188.1503929017188; Mon, 28 Aug 2017 07:03:37 -0700 (PDT) Received: from [172.16.0.18] ([96.231.223.191]) by smtp.gmail.com with ESMTPSA id c1sm301109qkd.32.2017.08.28.07.03.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 07:03:36 -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, 28 Aug 2017 10:03:34 -0400 References: To: "" In-Reply-To: Message-Id: <86B6983F-FFB2-444F-A2CD-1E681E6C0563@sn3rd.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2017 14:03:44 -0000 It looks like we have consensus to adopt this draft as a working group = item. I=E2=80=99ve set up a GH repo in the TLSWG = repo:https://github.com/tlswg/tls-record-limit. Please submit the current draft as a working group item with the = filename draft-ietf-tls-record-limit. If you can hold off on merging = PR#1 until it=E2=80=99s a WG item, that would be great (i.e., publish = then merge). Thanks, J&S > On Aug 4, 2017, at 08:50, Sean Turner wrote: >=20 > At our IETF 99 session, there was support in the room to adopt = draft-thomson-tls-record-limit [0]. We need to confirm this support on = the list so please let the list know whether you support adoption of the = draft and are willing to review/comment on the draft before 20170818. = If you object to its adoption, please let us know why. >=20 > Cheers, >=20 > J&S >=20 > [0] https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/ From nobody Mon Aug 28 07:11: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 7F053132D0C for ; Mon, 28 Aug 2017 07:11:53 -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 rsPGR0UpRWvg for ; Mon, 28 Aug 2017 07:11:51 -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 A23A9132D04 for ; Mon, 28 Aug 2017 07:11:51 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id w42so2587060qtg.5 for ; Mon, 28 Aug 2017 07:11:51 -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=6lfdsPmDM5O/8kzZ99FtcyRQIOYs3CDpWru+01ydZCQ=; b=ihot5hoQzlAvdSUe9gHGTmzjCGPFfxImtLg80b0t9waR/59BGHEEeN0U3tPfXyaR6Y rv2q9N0CqZUb7A6ihPhl7bWJOf3KZrGcLV3gNcF1Qjuy8MuRMn1irHBxE7fE1OcJ7MF1 CwV0lm6UfUFY+xlCk14JKWusyOnvvjh0tOeGo= 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=6lfdsPmDM5O/8kzZ99FtcyRQIOYs3CDpWru+01ydZCQ=; b=AOBKCSeNs5B/lmC9ykfGiChNRe1odcY9ZvLqDso5oIx+Zx9KBUfbCyPBQytoh1zZAJ 6bTZNDDmaAMaaFgGRTHyKuybmmIS9vaMqxV1atjjQLqC4J1w/gJteJBMxXbfD5Gl7Gjs 9eYXfjw17YWS45BWsl9oNsbXd5NP6futtFhX9zF9hdT+gESnjAK9Csi8r8ERphHP+mbB euCUpg/G3exLGIZEj3EiFLfLtjYMKUIQtcuArVU8FaSHGkZOBi8i6NUtzcvwxg1+Wplk AUfGiug/8wCEGMTiCmGwFFijqbjvk91nIf2tNQYhpwcuRUphRbLB2o5cTbzSiu/IOCcL TTrw== X-Gm-Message-State: AHYfb5h5uzrJ5SnW2msH4+y5FAqXTzxlD0YCZ3sEbt6VuMPGkCEtDYAg 1RVCisG8OJYdaydfTqGJtA== X-Received: by 10.200.63.173 with SMTP id d42mr912500qtk.325.1503929510451; Mon, 28 Aug 2017 07:11:50 -0700 (PDT) Received: from [172.16.0.18] ([96.231.223.191]) by smtp.gmail.com with ESMTPSA id q53sm302240qte.46.2017.08.28.07.11.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 07:11:49 -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, 28 Aug 2017 10:11:47 -0400 References: To: "tls@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] WG Call for Adoption of draft-rescorla-tls-subcerts continued X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2017 14:11:53 -0000 It looks like we have consensus after the 2nd WG call for adoption to = adopt this draft as a working group item as the draft was revised to = address concerns brought up during the 1st WG call for adoption. I=E2=80=99= ve set up a GH repo at: https://github.com/tlswg/tls-subcerts. Please = submit the current draft as a working group item with the filename = draft-ietf-tls-subcerts. Thanks, J&S > On Aug 4, 2017, at 13:42, Joseph Salowey wrote: >=20 > In the previous call for adoption there were some issues raised that = needed more discussion. The summary sent to the list [1] and = subsequent discussions indicate support for the approach outlined in = this draft. Therefore we would like to continue the call for adoption. = If you have concerns about adopting this draft as a working group item = please respond to the list by August 18, 2017. =20 >=20 > Thanks, >=20 > J&S >=20 > [1] https://www.ietf.org/mail-archive/web/tls/current/msg24092.html > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Aug 28 16:00: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 598071321C8; Mon, 28 Aug 2017 16:00:38 -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.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150396123832.13171.2429115245800949824@ietfa.amsl.com> Date: Mon, 28 Aug 2017 16:00:38 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-record-limit-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, 28 Aug 2017 23:00:38 -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 : Record Size Limit Extension for Transport Layer Security (TLS) Author : Martin Thomson Filename : draft-ietf-tls-record-limit-00.txt Pages : 6 Date : 2017-08-28 Abstract: An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-record-limit-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-record-limit-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 Aug 28 16:01: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 99B5D1329BC for ; Mon, 28 Aug 2017 16:01:51 -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 viEoc5b4Cz-S for ; Mon, 28 Aug 2017 16:01:49 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6D7132403 for ; Mon, 28 Aug 2017 16:01:49 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id k22so9162447iod.2 for ; Mon, 28 Aug 2017 16:01:49 -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=RPdZJ1TRa2c/BKLeFULfrUN48yA9DG3rW48nFmTkQTI=; b=TYAvB2hVNRPqnL9jpPkj91q/ibjpCyxueDcqHthNy6H+yE80uwdVCF0VzdWSN5ReZv ZR97etclk1DNXASBsPvntEPQ4uo9u9U1tsep1YSWAB/LKzS5YMq3OM9xoSqnvLrN1pdg QXuERL9l8nEhKPClmDJbRPhABfV0x9F4XHlJoe9UXr5B3wXkZEvmv8G8zola1gvmQ+T/ NQHSAPIsZWWeWQTkOe+wrZAlHfUoGFRObLcpz2KyEHw8m8SaGQa1xRomthDl6xHWwzIZ VwpyVQEgJwc8+/8LhElY6iruBlyKk/XDi/7t93hYfBuoeLuf6QLX4dqdzasMTEc5XElx PJyw== 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=RPdZJ1TRa2c/BKLeFULfrUN48yA9DG3rW48nFmTkQTI=; b=fM5MnKrdwJ9rqUuokCC3a8c8t09lYOPcxcXdx2RJSUB1B4rfTGWOR881RD9APZ5UHQ 82eUmb0Cw2Zko8OU1KEkYQOXK1RlBjIL6KyvwgfaRCxpuxELSp2B0yd5s+IYKeQfY8Jp GaerIUSzdKdpJQCuKS289QOYqn0rWUwVfSGz3+DRa9tWrAOF7wecJetvfmSkYJ0Eonmh 2R1LCRj7VW+LIZeiWa4+Ny91lDcR3s2qPV5j/hJ9TtEdvdrxbqh8pkehd2B+qVS9TFfU n+HmB72gPatqxnn+qcTsRoWAXSIzVxCokL4Lt/YEkEFF8zeIXjn5NK/z0WWT8EJrgLG5 fCRw== X-Gm-Message-State: AHYfb5gIBey+RgOOc0CvKhAUL8WOn99u8yNNmayRXjhf6RhMGb9JphNr 29jWeOIGL2oG5zm4NkYBh5wjelCjXSjk X-Received: by 10.107.44.81 with SMTP id s78mr2045650ios.160.1503961308341; Mon, 28 Aug 2017 16:01:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Mon, 28 Aug 2017 16:01:47 -0700 (PDT) In-Reply-To: <86B6983F-FFB2-444F-A2CD-1E681E6C0563@sn3rd.com> References: <86B6983F-FFB2-444F-A2CD-1E681E6C0563@sn3rd.com> From: Martin Thomson Date: Tue, 29 Aug 2017 09:01:47 +1000 Message-ID: To: Sean Turner Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2017 23:01:52 -0000 All done, including the PR being merged into the editor's copy. On 29 August 2017 at 00:03, Sean Turner wrote: > It looks like we have consensus to adopt this draft as a working group it= em. I=E2=80=99ve set up a GH repo in the TLSWG repo:https://github.com/tls= wg/tls-record-limit. > Please submit the current draft as a working group item with the filename= draft-ietf-tls-record-limit. If you can hold off on merging PR#1 until = it=E2=80=99s a WG item, that would be great (i.e., publish then merge). > > Thanks, > > J&S > >> On Aug 4, 2017, at 08:50, Sean Turner wrote: >> >> At our IETF 99 session, there was support in the room to adopt draft-tho= mson-tls-record-limit [0]. We need to confirm this support on the list so = please let the list know whether you support adoption of the draft and are = willing to review/comment on the draft before 20170818. If you object to i= ts adoption, please let us know why. >> >> Cheers, >> >> J&S >> >> [0] https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Aug 28 20:13: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 401C9132661 for ; Mon, 28 Aug 2017 20:13:07 -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 fEp6VYeHiPXR for ; Mon, 28 Aug 2017 20:13:05 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e: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 7AAC3132650 for ; Mon, 28 Aug 2017 20:13:05 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id t3so7060868pgt.0 for ; Mon, 28 Aug 2017 20:13:05 -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=Onqy11TqWjxjHkxoSA001s0oWB2hXQueCDw8KdCzOZA=; b=skez23p1t8LbbBbh5HxKgehQgndi4rNzOwpj7z8NZ6hNDWOaVUScMlb6hUuq0zhWa/ U9IbGzObYqtBKtJgVkPmhgxbHF+EY8RQqQ3X9/bkGLVLJMM2jsmam1WLt/panI/KB0B2 at1EaYOGx/ouViOLLE9gv3ePJxBCy5LPb3jaY/33FTiWug4iwGJwQAn9HOVKTU5dBwv6 RkgWUDVPmq4rkzNIDDzR8CJXx2KAjXZ6SYzwqipr42rcPgeA88LdSRXqiNxLnHbYVoFJ BONkE5GKX2kUxoL+NwisJHPyiMF1yrj7sNPjysR6mtJQvPwzHqtJ05Jh6sP8Z0wVRAxP CUcA== 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=Onqy11TqWjxjHkxoSA001s0oWB2hXQueCDw8KdCzOZA=; b=SWwQ+jWyy+pgJ+IqQwSH9M33IkCjN2yskb8aFb0MIABkhXUxjYmm0xSJh8I48uVvqN neUqdrwhowA8Ml0XEdGE92Ga2Nn+N7rOl7zQZQdVc57bfYl5HqXBniQZ8zXNKq4XlXnZ ytybgQkEQk/l1dR2D2m5l2/21Km7JV6S769ybcfRiHx9SBtRN4fNXIhJCGmil8Il98Ro zE7pndNtIH+qsImaznOMsThBal4nAg/kvzIPKtRsO6i/BUm/seEW41Wccfs25+64tJIL Co5gOPh5D+A/AvYAr+Hkq6ncQD/eIZKna/nrtzEnzSdGH3GDLIZxkQ6KDQtiM2I2/xzo 9auw== X-Gm-Message-State: AHYfb5gIxkwosTPH+xbHP5qP3b/gO3lOgLk7mlzjJrtr0IZwK1AHuZcT VjF+ogJ/8zoNLT8UgVsCp8YKjOzn1RurwM0= X-Received: by 10.98.22.214 with SMTP id 205mr2538360pfw.285.1503976384858; Mon, 28 Aug 2017 20:13:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.72 with HTTP; Mon, 28 Aug 2017 20:12:44 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Mon, 28 Aug 2017 20:12:44 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="94eb2c037f022b9d400557dbca64" Archived-At: Subject: Re: [TLS] WG adoption call: SNI Encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2017 03:13:07 -0000 --94eb2c037f022b9d400557dbca64 Content-Type: text/plain; charset="UTF-8" The working has expressed consensus to work on the problem of SNI encryption. More work is needed to determine the technical approach to SNI encryption. The chairs believe there is enough interest and energy to adopt this draft and continue work within the working group instead of asking the constituents to arrive at a solution before adoption. This document will serve as the basis for discussion. Whether the document will cover the solution to the problem will be determined by the chairs at a later point in time. The chairs request the author remove the normative text from the description of the attacks and submit draft-ietf-tls-sni-encr yption-00.txt. Thanks, J&S On Thu, Aug 17, 2017 at 1:31 AM, Stephen Farrell wrote: > > > On 17/08/17 05:18, Martin Thomson wrote: > > https://tools.ietf.org/html/rfc7858 > > > > I hear that there are even implementations and deployments. > > Yes, I used the resolver doing this at the last IETF meeting. > It worked. Not "just worked," but pretty good. > > > > > It's certainly time to have the discussion about closing the next gap. > > Yes. I'm in favour of adopting as a strong signal that this > is a WG item. I don't think anyone needs to be allergic to > a wg draft-00 that still documents more than one proposal, > there's no specific place in the evolution of an RFC before > which such things MUST get sorted out, so while being a bit > concerned that we still have two options is very reasonable, > that's not IMO a winning argument against wg adoption. > > S. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c037f022b9d400557dbca64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The working has expressed = consensus to work on the problem of SNI encryption.=C2=A0 More work is need= ed to determine the technical approach to SNI encryption.=C2=A0 The chairs = believe there is enough interest and energy to adopt this draft and continu= e work within the working group instead of asking the constituents to arriv= e at a solution before adoption. =C2=A0

This document will serve as the= basis for discussion.=C2=A0 Whether the document will cover the solution t= o the problem will be determined by the chairs at a later point in time.=C2= =A0 The chairs request the author remove the normative text from the descri= ption of the attacks and submit=C2=A0draft-ietf-tls-sni-encryption-00= .txt.

Thanks,

J&S

On Thu, Aug 17, 2017 at 1:3= 1 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wr= ote:


On 17/08/17 05:18, Martin Thomson wrote:
> https://tools.ietf.org/html/rfc7858
>
> I hear that there are even implementations and deployments.

Yes, I used the resolver doing this at the last IETF meeting.
It worked. Not "just worked," but pretty good.

>
> It's certainly time to have the discussion about closing the next = gap.

Yes. I'm in favour of adopting as a strong signal that this
is a WG item. I don't think anyone needs to be allergic to
a wg draft-00 that still documents more than one proposal,
there's no specific place in the evolution of an RFC before
which such things MUST get sorted out, so while being a bit
concerned that we still have two options is very reasonable,
that's not IMO a winning argument against wg adoption.

S.


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


--94eb2c037f022b9d400557dbca64-- From nobody Tue Aug 29 04:20: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 E584613202D for ; Tue, 29 Aug 2017 04:20:43 -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, FREEMAIL_FROM=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 mp0dKG_nr1FX for ; Tue, 29 Aug 2017 04:20:41 -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 53A1813213F for ; Tue, 29 Aug 2017 04:20:41 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.73]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LmrZY-1dJ67T0RDA-00h9EE; Tue, 29 Aug 2017 13:20:35 +0200 To: Ilari Liusvaara , Noah Robbin Cc: "tls@ietf.org" References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <0d245ef4-78c7-3050-0d52-0a185180476e@gmx.net> Date: Tue, 29 Aug 2017 13:20:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EEENwApH8B662Iv8JP3TYNCb8MxSGRA8GlbhYeaCmou9fM9pb29 GW3wewaqwKsT309nHxfPpnLofVribg+aggy3ih3wpA2SBzUL4RgBYKG4Qmj4KEuC86ggcPY njaehn/KdujtqkcIJRnn9wV0vd6TmReI0DR1X3dnEQsItPJRxFz1lqAeQoE/euTY4/N95A5 KV+uteQcc9Pg2q/XB5PjA== X-UI-Out-Filterresults: notjunk:1;V01:K0:jAjatWU5hxQ=:vq4AemOTij/BrJYwmRvNTQ vfwCOaNfPKWfKgSaKR0rPhFsTQo07IF/Q9mMS8XHXObNEpWVCwUvb5lPU2uViZRpfgxhTQAom ajejRRagaDXIMQSS3M4N58TCPw2n8om6xEpYehovPcDrNt0ixYtmGucBrjel3mHrjiSHUJC/I wMq3KRoMec7v808d9jazeGX72nOAO9VDuePad+LKzPCp+P8OLJNNUgyMCWksOwr1obpCGf5yA 4XEHTnOoRIILfOcVQX3hJf89Pd6Z3/jiYktil4zWzq2hPT5bLOYjMM9vwRYbNw5o/v0FzJzdE iCuQ5zM7n0iOVThG2ri8sb2/X0OzLys90BJXR0U9pIsqocBfrxMdU8OKB82rYKj5uaJhEqdOX GtSW0A+86BtbMJ55AROW1yU867QJQE8OE9YsVNjBpEknK/nMvirStcer7YBXDmtZ3ph5aPbk/ QkhYaiMUkdrX8/Zv+JCLCm4l0enwY+wrqD+Tyf+CKfrJqQ/zIEre7U/Am+ffEjLBcznAkUrYC YkmG4A4u7mObZhjJUO1BzNbyLx3iwpSK0G8eglkFJCyGj+ASMp9crQNGehUDvy1EF1gogz54k Jh8i0SAZ+RwJri/F/8RldxBQt8FnD58WAhrIzQK0b4o7Iqn4VLz+JMqUslUu8kmapaW7/x2Hm 30Fif+T9Wufs3gjXC/eRcCn+JV+G+PbuI6FiwygLJ0NJgJ1scjEQjJR20nBKQOKyeEv9OwJ3Y Zhr2PdF+mpmmE0q+oWHrzhGqz1bjyAln6YHFSSISYbAC7if7a7P7SVfShYKYCO9q/L7/OBNYJ F61opCW6OBDUa73ZbAcKR/nS9IMOvJ9zHkZv1axWJ3JIVX9Xs4= Archived-At: Subject: Re: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2017 11:20:44 -0000 Hi Noah, Todd, Ilari, the HRR is used for two purposes, namely * to report an error (with the key shares), and * for DoS protection. In both cases it feels excessive to require that the two ClientHellos are the same (with some minor exceptions). I see this as particularly problematic for the use with DTLS since with connectionless transport protocols the use of the HRR is obviously common and we are essentially wasting bytes on the wire for no good reason(with every handshake). For the return-routability check there will be a cookie in the HRR and the RR check is useful primarily for connectionless transports. Re-transmitting the same information twice in this case is of doubtful value since (a) either the cookie contains the necessary info already or (b) the second ClientHello carries the relevant information. Does this make sense? Ciao Hannes On 08/22/2017 10:13 PM, Ilari Liusvaara wrote: > On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote: >> Hello Todd! >> >> I also did not see a reason why the random values had to be the same >> but the language does mandate it. > > I really do not think there is any technical or security reason why the > randoms have to be the same. After all, TLS 1.3 does not directly use > the randoms anywhere (they only affect things indirectly via hashes of > the handshake). > >> You make a good argument for not altering the padding on the second >> ClientHello. > > I read that argument as "TLS 1.3 implementations should not need > padding". > > I took a look at struct ClientHello and the extensions list: > > There are technical reasons for not altering (the client has no idea > what the heck server did with these): > > - server_name > - max_fragment_length > - status_request > - signature_algorithms > - use_srtp > - heartbeat > - application_layer_protocol_negotiation > - signed_certificate_timestamp > - client_certificate_type > - server_certificate_type > - psk_key_exchange_modes (due to side-effects) > - certificate_authorities > - post_handshake_auth > > The following are explicitly listed as to be altered/deleted: > > - key_share > - pre_shared_key > - early_data > - cookie > > The following do not negotiate state: > > - > - padding > > The following can't appear in ClientHello: > > - oid_filters > > The following client gains information about in HRR: > > - > - supported_groups (partially if key_share was not present). > - supported_versions (the client knows what server selected). > > > However the last group seems to be kind of things that are rather > questionable to prune (might be okay, but those make me wary). > > > > Also, I came accross one edge case: What if client discovers that all > tickets in pre_shared_key are incompatible? The definition does not > allow 0 tickets, so choices are: > > 1) Leave all the tickets (which is not going to work) in. > 2) Leave one ticket (which is not going to work) in. > 3) Strip the entiere extension. > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Aug 29 06: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 4C7CD132A81 for ; Tue, 29 Aug 2017 06:40:01 -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, 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 pyKiLYPXtJuL for ; Tue, 29 Aug 2017 06:39:58 -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 A3BCE13217D for ; Tue, 29 Aug 2017 06:39:58 -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 v7TDbuwW000307; Tue, 29 Aug 2017 14:39:54 +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=fREg7PfoVrZl1J65US8/e3szZEiEhcTX7N5xOof/aFA=; b=StneLq80ZuYys6qJLqlRpgLEuY5YfLKvSO2ruA4pFIJBLD5WZOnn7KK/jB1cxfVuN6BE pwgPFZOMa8/nZwGichlMArQ/1pqMw+uOCPMhW2HXcBP0Ahq4kUjqT0ArCxK0vA/VdjBS /iVZw2KWCHu15NbJzTzslh3Jl8lS4YHu7ArXTX895wmlkqJGwuOIbHRmHbOHYXXyfw2p BVJb0Z27G2UMGAjMhx2PZ2M1KX/zCBJrTi/sr1l7/Ax6Op7RqVVbxChKD+70FVu4SGwP McTkq0T6K167SdV5ZSTnJqQ6ZkyIwFKr6tAykZxZMwh+t+rdZ4JTXWpuzIrR/qEx178u Qw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2ck08414j3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Aug 2017 14:39:54 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7TDa1Xn030616; Tue, 29 Aug 2017 09:39:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ck4aw5sd6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Aug 2017 09:39:53 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 29 Aug 2017 06:39:52 -0700 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, 29 Aug 2017 09:39:52 -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, 29 Aug 2017 09:39:52 -0400 From: "Short, Todd" To: Hannes Tschofenig CC: Ilari Liusvaara , Noah Robbin , "tls@ietf.org" Thread-Topic: [TLS] What counts as the same ClientHello? Thread-Index: AQHTG28woLw1mAaE8UCKW3rg0dt+vaKREooAgAprToCAACbrgA== Date: Tue, 29 Aug 2017 13:39:51 +0000 Message-ID: <9989C9A4-2F70-44E4-BC13-62A260EBF86E@akamai.com> References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <0d245ef4-78c7-3050-0d52-0a185180476e@gmx.net> In-Reply-To: <0d245ef4-78c7-3050-0d52-0a185180476e@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.105] Content-Type: multipart/alternative; boundary="_000_9989C9A42F7044E4BC1362A260EBF86Eakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-29_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-1708290205 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-29_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-1708290205 Archived-At: Subject: Re: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2017 13:40:01 -0000 --_000_9989C9A42F7044E4BC1362A260EBF86Eakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFubmVzOg0KDQpUaGUgSUQgaW5kaWNhdGVzIHRoYXQgdGhlIHR3byBDbGllbnRIZWxsb3MgbXVz dCBiZSBpZGVudGljYWwgZXhjZXB0IGZvciB0aGUgZmllbGRzIGV4cGxpY2l0bHkgbGlzdGVkLiBJ ZiB5b3Ugc3Ryb25nbHkgZGlzYWdyZWUsIHRoZW4geW91IHNob3VsZCByZXF1ZXN0IGEgY2hhbmdl IHRvIHRoZSBJRC4gSSB1bmRlcnN0YW5kIHlvdXIgb3BpbmlvbnMgb24gdGhlIG1hdHRlcjsgYnV0 IGFzIHdyaXR0ZW4sIHRoZSBJRCByZXF1aXJlcyB0aG9zZSBmaWVsZHMgZXh0ZW5zaW9ucyB0byBi ZSB0aGUgc2FtZS4gSGVyZSBpcyB0aGUgdGV4dCBpbiBxdWVzdGlvbiwgZW1waGFzaXMgbWluZToN Cg0KDQo0LjEuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtdGxz MTMtMjEjc2VjdGlvbi00LjEuMj4uICBDbGllbnQgSGVsbG8NCg0KDQogICBXaGVuIGEgY2xpZW50 IGZpcnN0IGNvbm5lY3RzIHRvIGEgc2VydmVyLCBpdCBpcyBSRVFVSVJFRCB0byBzZW5kIHRoZQ0K ICAgQ2xpZW50SGVsbG8gYXMgaXRzIGZpcnN0IG1lc3NhZ2UuICBUaGUgY2xpZW50IHdpbGwgYWxz byBzZW5kIGENCiAgIENsaWVudEhlbGxvIHdoZW4gdGhlIHNlcnZlciBoYXMgcmVzcG9uZGVkIHRv IGl0cyBDbGllbnRIZWxsbyB3aXRoIGENCiAgIEhlbGxvUmV0cnlSZXF1ZXN0LiAgSW4gdGhhdCBj YXNlLCB0aGUgY2xpZW50IE1VU1Qgc2VuZCB0aGUgc2FtZQ0KICAgQ2xpZW50SGVsbG8gKHdpdGhv dXQgbW9kaWZpY2F0aW9uKSBleGNlcHQ6DQoNCiAgIC0gIElmIGEgImtleV9zaGFyZSIgZXh0ZW5z aW9uIHdhcyBzdXBwbGllZCBpbiB0aGUgSGVsbG9SZXRyeVJlcXVlc3QsDQogICAgICByZXBsYWNp bmcgdGhlIGxpc3Qgb2Ygc2hhcmVzIHdpdGggYSBsaXN0IGNvbnRhaW5pbmcgYSBzaW5nbGUNCiAg ICAgIEtleVNoYXJlRW50cnkgZnJvbSB0aGUgaW5kaWNhdGVkIGdyb3VwLg0KDQogICAtICBSZW1v dmluZyB0aGUgImVhcmx5X2RhdGEiIGV4dGVuc2lvbiAoU2VjdGlvbiA0LjIuOTxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtdGxzMTMtMjEjc2VjdGlvbi00LjIuOT4p IGlmIG9uZSB3YXMNCiAgICAgIHByZXNlbnQuICBFYXJseSBkYXRhIGlzIG5vdCBwZXJtaXR0ZWQg YWZ0ZXIgSGVsbG9SZXRyeVJlcXVlc3QuDQoNCiAgIC0gIEluY2x1ZGluZyBhICJjb29raWUiIGV4 dGVuc2lvbiBpZiBvbmUgd2FzIHByb3ZpZGVkIGluIHRoZQ0KICAgICAgSGVsbG9SZXRyeVJlcXVl c3QuDQoNCiAgIC0gIFVwZGF0aW5nIHRoZSAicHJlX3NoYXJlZF9rZXkiIGV4dGVuc2lvbiBpZiBw cmVzZW50IGJ5IHJlY29tcHV0aW5nDQogICAgICB0aGUgIm9iZnVzY2F0ZWRfdGlja2V0X2FnZSIg YW5kIGJpbmRlciB2YWx1ZXMgYW5kIChvcHRpb25hbGx5KQ0KICAgICAgcmVtb3ZpbmcgYW55IFBT S3Mgd2hpY2ggYXJlIGluY29tcGF0aWJsZSB3aXRoIHRoZSBzZXJ2ZXIncw0KICAgICAgaW5kaWNh dGVkIGNpcGhlciBzdWl0ZS4NCg0KDQpUbyBhdm9pZCBET1MgYW5kIG1haW50ZW5hbmNlIG9mIHN0 YXRlLCB0aGUgc2VydmVyIHNob3VsZCBub3QgbWFpbnRhaW4gYW55IG9mIHRoaXMgaW5mb3JtYXRp b24gKGV4Y2VwdCwgcGVyaGFwcyBpbmRpcmVjdGx5IHZpYSB0aGUgY29va2llKSBpZiBhbiBIUlIg aXMgcmV0dXJuZWQuIFRodXMgdGhlIENsaWVudEhlbGxvIGlzIHNlbnQgd2l0aCBhbGwgdGhlIGlu Zm9ybWF0aW9uIHByb3ZpZGVkIGFnYWluLiBZZXMsIGl04oCZcyBhIHNsaWdodCB3YXN0ZSBvZiBi YW5kd2lkdGgsIGJ1dCBJ4oCZZCByYXRoZXIgdXNlIGJhbmR3aWR0aCB0aGF0IGZsZWV0cyBhd2F5 IGxpa2UgdGltZSAodXNlIGl0IG9yIGxvc2UgaXQpLCB0aGFuIG1lbW9yeSBpbiBteSBkZXZpY2Uu IFRoaXMgYWxzbyBwZXJtaXRzIG11bHRpcGxlIG1ldGhvZHMgb2YgaW1wbGVtZW50YXRpb24gb2Yg dGhlIGluaXRpYWwgY29ubmVjdGlvbiBpZiBhbGwgdGhlIGluZm9ybWF0aW9uIGlzIHByb3ZpZGVk IGFnYWluLg0KDQotLQ0KLVRvZGQgU2hvcnQNCi8vIHRzaG9ydEBha2FtYWkuY29tPG1haWx0bzp0 c2hvcnRAYWthbWFpLmNvbT4NCi8vICJPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhy ZWUgaWYgYnkgdGhlIEludGVybmV0LiINCg0KT24gQXVnIDI5LCAyMDE3LCBhdCA3OjIwIEFNLCBI YW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0KDQpIaSBOb2FoLCBUb2RkLCBJbGFyaSwNCg0K dGhlIEhSUiBpcyB1c2VkIGZvciB0d28gcHVycG9zZXMsIG5hbWVseQ0KKiB0byByZXBvcnQgYW4g ZXJyb3IgKHdpdGggdGhlIGtleSBzaGFyZXMpLCBhbmQNCiogZm9yIERvUyBwcm90ZWN0aW9uLg0K DQpJbiBib3RoIGNhc2VzIGl0IGZlZWxzIGV4Y2Vzc2l2ZSB0byByZXF1aXJlIHRoYXQgdGhlIHR3 byBDbGllbnRIZWxsb3MNCmFyZSB0aGUgc2FtZSAod2l0aCBzb21lIG1pbm9yIGV4Y2VwdGlvbnMp LiBJIHNlZSB0aGlzIGFzIHBhcnRpY3VsYXJseQ0KcHJvYmxlbWF0aWMgZm9yIHRoZSB1c2Ugd2l0 aCBEVExTIHNpbmNlIHdpdGggY29ubmVjdGlvbmxlc3MgdHJhbnNwb3J0DQpwcm90b2NvbHMgdGhl IHVzZSBvZiB0aGUgSFJSIGlzIG9idmlvdXNseSBjb21tb24gYW5kIHdlIGFyZSBlc3NlbnRpYWxs eQ0Kd2FzdGluZyBieXRlcyBvbiB0aGUgd2lyZSBmb3Igbm8gZ29vZCByZWFzb24od2l0aCBldmVy eSBoYW5kc2hha2UpLg0KDQpGb3IgdGhlIHJldHVybi1yb3V0YWJpbGl0eSBjaGVjayB0aGVyZSB3 aWxsIGJlIGEgY29va2llIGluIHRoZSBIUlIgYW5kDQp0aGUgUlIgY2hlY2sgaXMgdXNlZnVsIHBy aW1hcmlseSBmb3IgY29ubmVjdGlvbmxlc3MgdHJhbnNwb3J0cy4NClJlLXRyYW5zbWl0dGluZyB0 aGUgc2FtZSBpbmZvcm1hdGlvbiB0d2ljZSBpbiB0aGlzIGNhc2UgaXMgb2YgZG91YnRmdWwNCnZh bHVlIHNpbmNlIChhKSBlaXRoZXIgdGhlIGNvb2tpZSBjb250YWlucyB0aGUgbmVjZXNzYXJ5IGlu Zm8gYWxyZWFkeSBvcg0KKGIpIHRoZSBzZWNvbmQgQ2xpZW50SGVsbG8gY2FycmllcyB0aGUgcmVs ZXZhbnQgaW5mb3JtYXRpb24uDQoNCkRvZXMgdGhpcyBtYWtlIHNlbnNlPw0KDQpDaWFvDQpIYW5u ZXMNCg0KT24gMDgvMjIvMjAxNyAxMDoxMyBQTSwgSWxhcmkgTGl1c3ZhYXJhIHdyb3RlOg0KT24g VHVlLCBBdWcgMjIsIDIwMTcgYXQgMDU6NTA6NDlQTSArMDAwMCwgTm9haCBSb2JiaW4gd3JvdGU6 DQpIZWxsbyBUb2RkIQ0KDQpJIGFsc28gZGlkIG5vdCBzZWUgYSByZWFzb24gd2h5IHRoZSByYW5k b20gdmFsdWVzIGhhZCB0byBiZSB0aGUgc2FtZQ0KYnV0IHRoZSBsYW5ndWFnZSBkb2VzIG1hbmRh dGUgaXQuDQoNCkkgcmVhbGx5IGRvIG5vdCB0aGluayB0aGVyZSBpcyBhbnkgdGVjaG5pY2FsIG9y IHNlY3VyaXR5IHJlYXNvbiB3aHkgdGhlDQpyYW5kb21zIGhhdmUgdG8gYmUgdGhlIHNhbWUuIEFm dGVyIGFsbCwgVExTIDEuMyBkb2VzIG5vdCBkaXJlY3RseSB1c2UNCnRoZSByYW5kb21zIGFueXdo ZXJlICh0aGV5IG9ubHkgYWZmZWN0IHRoaW5ncyBpbmRpcmVjdGx5IHZpYSBoYXNoZXMgb2YNCnRo ZSBoYW5kc2hha2UpLg0KDQpZb3UgbWFrZSBhIGdvb2QgYXJndW1lbnQgZm9yIG5vdCBhbHRlcmlu ZyB0aGUgcGFkZGluZyBvbiB0aGUgc2Vjb25kDQpDbGllbnRIZWxsby4NCg0KSSByZWFkIHRoYXQg YXJndW1lbnQgYXMgIlRMUyAxLjMgaW1wbGVtZW50YXRpb25zIHNob3VsZCBub3QgbmVlZA0KcGFk ZGluZyIuDQoNCkkgdG9vayBhIGxvb2sgYXQgc3RydWN0IENsaWVudEhlbGxvIGFuZCB0aGUgZXh0 ZW5zaW9ucyBsaXN0Og0KDQpUaGVyZSBhcmUgdGVjaG5pY2FsIHJlYXNvbnMgZm9yIG5vdCBhbHRl cmluZyAodGhlIGNsaWVudCBoYXMgbm8gaWRlYQ0Kd2hhdCB0aGUgaGVjayBzZXJ2ZXIgZGlkIHdp dGggdGhlc2UpOg0KDQotIHNlcnZlcl9uYW1lDQotIG1heF9mcmFnbWVudF9sZW5ndGgNCi0gc3Rh dHVzX3JlcXVlc3QNCi0gc2lnbmF0dXJlX2FsZ29yaXRobXMNCi0gdXNlX3NydHANCi0gaGVhcnRi ZWF0DQotIGFwcGxpY2F0aW9uX2xheWVyX3Byb3RvY29sX25lZ290aWF0aW9uDQotIHNpZ25lZF9j ZXJ0aWZpY2F0ZV90aW1lc3RhbXANCi0gY2xpZW50X2NlcnRpZmljYXRlX3R5cGUNCi0gc2VydmVy X2NlcnRpZmljYXRlX3R5cGUNCi0gcHNrX2tleV9leGNoYW5nZV9tb2RlcyAoZHVlIHRvIHNpZGUt ZWZmZWN0cykNCi0gY2VydGlmaWNhdGVfYXV0aG9yaXRpZXMNCi0gcG9zdF9oYW5kc2hha2VfYXV0 aA0KDQpUaGUgZm9sbG93aW5nIGFyZSBleHBsaWNpdGx5IGxpc3RlZCBhcyB0byBiZSBhbHRlcmVk L2RlbGV0ZWQ6DQoNCi0ga2V5X3NoYXJlDQotIHByZV9zaGFyZWRfa2V5DQotIGVhcmx5X2RhdGEN Ci0gY29va2llDQoNClRoZSBmb2xsb3dpbmcgZG8gbm90IG5lZ290aWF0ZSBzdGF0ZToNCg0KLSA8 cmFuZG9tPg0KLSBwYWRkaW5nDQoNClRoZSBmb2xsb3dpbmcgY2FuJ3QgYXBwZWFyIGluIENsaWVu dEhlbGxvOg0KDQotIG9pZF9maWx0ZXJzDQoNClRoZSBmb2xsb3dpbmcgY2xpZW50IGdhaW5zIGlu Zm9ybWF0aW9uIGFib3V0IGluIEhSUjoNCg0KLSA8Y2lwaGVyc3VpdGVzPg0KLSBzdXBwb3J0ZWRf Z3JvdXBzIChwYXJ0aWFsbHkgaWYga2V5X3NoYXJlIHdhcyBub3QgcHJlc2VudCkuDQotIHN1cHBv cnRlZF92ZXJzaW9ucyAodGhlIGNsaWVudCBrbm93cyB3aGF0IHNlcnZlciBzZWxlY3RlZCkuDQoN Cg0KSG93ZXZlciB0aGUgbGFzdCBncm91cCBzZWVtcyB0byBiZSBraW5kIG9mIHRoaW5ncyB0aGF0 IGFyZSByYXRoZXINCnF1ZXN0aW9uYWJsZSB0byBwcnVuZSAobWlnaHQgYmUgb2theSwgYnV0IHRo b3NlIG1ha2UgbWUgd2FyeSkuDQoNCg0KDQpBbHNvLCBJIGNhbWUgYWNjcm9zcyBvbmUgZWRnZSBj YXNlOiBXaGF0IGlmIGNsaWVudCBkaXNjb3ZlcnMgdGhhdCBhbGwNCnRpY2tldHMgaW4gcHJlX3No YXJlZF9rZXkgYXJlIGluY29tcGF0aWJsZT8gVGhlIGRlZmluaXRpb24gZG9lcyBub3QNCmFsbG93 IDAgdGlja2V0cywgc28gY2hvaWNlcyBhcmU6DQoNCjEpIExlYXZlIGFsbCB0aGUgdGlja2V0cyAo d2hpY2ggaXMgbm90IGdvaW5nIHRvIHdvcmspIGluLg0KMikgTGVhdmUgb25lIHRpY2tldCAod2hp Y2ggaXMgbm90IGdvaW5nIHRvIHdvcmspIGluLg0KMykgU3RyaXAgdGhlIGVudGllcmUgZXh0ZW5z aW9uLg0KDQoNCg0KDQotSWxhcmkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExT QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1h aWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQo= --_000_9989C9A42F7044E4BC1362A260EBF86Eakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <0E94E6566EB6E644846C8EE16F915E07@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IYW5uZXM6 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KVGhlIElEIGluZGlj YXRlcyB0aGF0IHRoZSB0d28gQ2xpZW50SGVsbG9zIG11c3QgYmUgaWRlbnRpY2FsIGV4Y2VwdCBm b3IgdGhlIGZpZWxkcyBleHBsaWNpdGx5IGxpc3RlZC4gSWYgeW91IHN0cm9uZ2x5IGRpc2FncmVl LCB0aGVuIHlvdSBzaG91bGQgcmVxdWVzdCBhIGNoYW5nZSB0byB0aGUgSUQuIEkgdW5kZXJzdGFu ZCB5b3VyIG9waW5pb25zIG9uIHRoZSBtYXR0ZXI7IGJ1dCBhcyB3cml0dGVuLCB0aGUgSUQgcmVx dWlyZXMgdGhvc2UgZmllbGRzDQogZXh0ZW5zaW9ucyB0byBiZSB0aGUgc2FtZS4gSGVyZSBpcyB0 aGUgdGV4dCBpbiBxdWVzdGlvbiwgZW1waGFzaXMgbWluZToNCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5 bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206 IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7 IG9ycGhhbnM6IDI7IHdpZG93czogMjsiPjxzcGFuIGNsYXNzPSJoNCIgc3R5bGU9ImxpbmUtaGVp Z2h0OiAwcHQ7IGRpc3BsYXk6IGlubGluZTsgZm9udC1zaXplOiAxZW07IGZvbnQtd2VpZ2h0OiBi b2xkOyI+PGg0IHN0eWxlPSJsaW5lLWhlaWdodDogMHB0OyBkaXNwbGF5OiBpbmxpbmU7IGZvbnQt c2l6ZTogMWVtOyIgY2xhc3M9IiI+PGEgY2xhc3M9InNlbGZsaW5rIiBuYW1lPSJzZWN0aW9uLTQu MS4yIiBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtdGxz MTMtMjEjc2VjdGlvbi00LjEuMiIgc3R5bGU9ImNvbG9yOiBibGFjazsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyI+NC4xLjI8L2E+LiAgQ2xpZW50IEhlbGxvPC9oND48L3NwYW4+DQoNCiAgIFdoZW4g YSBjbGllbnQgZmlyc3QgY29ubmVjdHMgdG8gYSBzZXJ2ZXIsIGl0IGlzIFJFUVVJUkVEIHRvIHNl bmQgdGhlDQogICBDbGllbnRIZWxsbyBhcyBpdHMgZmlyc3QgbWVzc2FnZS4gIFRoZSBjbGllbnQg d2lsbCBhbHNvIHNlbmQgYQ0KICAgQ2xpZW50SGVsbG8gd2hlbiB0aGUgc2VydmVyIGhhcyByZXNw b25kZWQgdG8gaXRzIENsaWVudEhlbGxvIHdpdGggYQ0KICAgSGVsbG9SZXRyeVJlcXVlc3QuICA8 YiBjbGFzcz0iIj48aSBjbGFzcz0iIj5JbiB0aGF0IGNhc2UsIHRoZSBjbGllbnQgTVVTVCBzZW5k IHRoZSBzYW1lDQogICBDbGllbnRIZWxsbyAod2l0aG91dCBtb2RpZmljYXRpb24pIGV4Y2VwdDoN CjwvaT48L2I+DQogICAtICBJZiBhICZxdW90O2tleV9zaGFyZSZxdW90OyBleHRlbnNpb24gd2Fz IHN1cHBsaWVkIGluIHRoZSBIZWxsb1JldHJ5UmVxdWVzdCwNCiAgICAgIHJlcGxhY2luZyB0aGUg bGlzdCBvZiBzaGFyZXMgd2l0aCBhIGxpc3QgY29udGFpbmluZyBhIHNpbmdsZQ0KICAgICAgS2V5 U2hhcmVFbnRyeSBmcm9tIHRoZSBpbmRpY2F0ZWQgZ3JvdXAuDQoNCiAgIC0gIFJlbW92aW5nIHRo ZSAmcXVvdDtlYXJseV9kYXRhJnF1b3Q7IGV4dGVuc2lvbiAoPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLXRsczEzLTIxI3NlY3Rpb24tNC4yLjkiIGNs YXNzPSIiPlNlY3Rpb24gNC4yLjk8L2E+KSBpZiBvbmUgd2FzDQogICAgICBwcmVzZW50LiAgRWFy bHkgZGF0YSBpcyBub3QgcGVybWl0dGVkIGFmdGVyIEhlbGxvUmV0cnlSZXF1ZXN0Lg0KDQogICAt ICBJbmNsdWRpbmcgYSAmcXVvdDtjb29raWUmcXVvdDsgZXh0ZW5zaW9uIGlmIG9uZSB3YXMgcHJv dmlkZWQgaW4gdGhlDQogICAgICBIZWxsb1JldHJ5UmVxdWVzdC4NCg0KICAgLSAgVXBkYXRpbmcg dGhlICZxdW90O3ByZV9zaGFyZWRfa2V5JnF1b3Q7IGV4dGVuc2lvbiBpZiBwcmVzZW50IGJ5IHJl Y29tcHV0aW5nDQogICAgICB0aGUgJnF1b3Q7b2JmdXNjYXRlZF90aWNrZXRfYWdlJnF1b3Q7IGFu ZCBiaW5kZXIgdmFsdWVzIGFuZCAob3B0aW9uYWxseSkNCiAgICAgIHJlbW92aW5nIGFueSBQU0tz IHdoaWNoIGFyZSBpbmNvbXBhdGlibGUgd2l0aCB0aGUgc2VydmVyJ3MNCiAgICAgIGluZGljYXRl ZCBjaXBoZXIgc3VpdGUuDQo8L3ByZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPlRvIGF2b2lkIERPUyBhbmQgbWFpbnRlbmFuY2Ugb2Ygc3RhdGUs IHRoZSBzZXJ2ZXIgc2hvdWxkIG5vdCBtYWludGFpbiBhbnkgb2YgdGhpcyBpbmZvcm1hdGlvbiAo ZXhjZXB0LCBwZXJoYXBzIGluZGlyZWN0bHkgdmlhIHRoZSBjb29raWUpIGlmIGFuIEhSUiBpcyBy ZXR1cm5lZC4gVGh1cyB0aGUgQ2xpZW50SGVsbG8gaXMgc2VudCB3aXRoIGFsbCB0aGUgaW5mb3Jt YXRpb24gcHJvdmlkZWQgYWdhaW4uIFllcywgaXTigJlzIGENCiBzbGlnaHQgd2FzdGUgb2YgYmFu ZHdpZHRoLCBidXQgSeKAmWQgcmF0aGVyIHVzZSBiYW5kd2lkdGggdGhhdCBmbGVldHMgYXdheSBs aWtlIHRpbWUgKHVzZSBpdCBvciBsb3NlIGl0KSwgdGhhbiBtZW1vcnkgaW4gbXkgZGV2aWNlLiBU aGlzIGFsc28gcGVybWl0cyBtdWx0aXBsZSBtZXRob2RzIG9mIGltcGxlbWVudGF0aW9uIG9mIHRo ZSBpbml0aWFsIGNvbm5lY3Rpb24gaWYgYWxsIHRoZSBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCBh Z2Fpbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPi0tPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPi1Ub2RkIFNob3J0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8vIDxhIGhyZWY9 Im1haWx0bzp0c2hvcnRAYWthbWFpLmNvbSIgY2xhc3M9IiI+dHNob3J0QGFrYW1haS5jb208L2E+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8vICZxdW90O09uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkg c2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuJnF1b3Q7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEF1ZyAyOSwgMjAxNywgYXQgNzoyMCBBTSwgSGFu bmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgu bmV0IiBjbGFzcz0iIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+SGkgTm9haCwgVG9kZCwgSWxhcmksPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KdGhlIEhSUiBpcyB1c2VkIGZvciB0d28gcHVycG9zZXMsIG5hbWVseTxiciBj bGFzcz0iIj4NCiogdG8gcmVwb3J0IGFuIGVycm9yICh3aXRoIHRoZSBrZXkgc2hhcmVzKSwgYW5k PGJyIGNsYXNzPSIiPg0KKiBmb3IgRG9TIHByb3RlY3Rpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KSW4gYm90aCBjYXNlcyBpdCBmZWVscyBleGNlc3NpdmUgdG8gcmVxdWlyZSB0aGF0 IHRoZSB0d28gQ2xpZW50SGVsbG9zPGJyIGNsYXNzPSIiPg0KYXJlIHRoZSBzYW1lICh3aXRoIHNv bWUgbWlub3IgZXhjZXB0aW9ucykuIEkgc2VlIHRoaXMgYXMgcGFydGljdWxhcmx5PGJyIGNsYXNz PSIiPg0KcHJvYmxlbWF0aWMgZm9yIHRoZSB1c2Ugd2l0aCBEVExTIHNpbmNlIHdpdGggY29ubmVj dGlvbmxlc3MgdHJhbnNwb3J0PGJyIGNsYXNzPSIiPg0KcHJvdG9jb2xzIHRoZSB1c2Ugb2YgdGhl IEhSUiBpcyBvYnZpb3VzbHkgY29tbW9uIGFuZCB3ZSBhcmUgZXNzZW50aWFsbHk8YnIgY2xhc3M9 IiI+DQp3YXN0aW5nIGJ5dGVzIG9uIHRoZSB3aXJlIGZvciBubyBnb29kIHJlYXNvbih3aXRoIGV2 ZXJ5IGhhbmRzaGFrZSkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRm9yIHRoZSByZXR1 cm4tcm91dGFiaWxpdHkgY2hlY2sgdGhlcmUgd2lsbCBiZSBhIGNvb2tpZSBpbiB0aGUgSFJSIGFu ZDxiciBjbGFzcz0iIj4NCnRoZSBSUiBjaGVjayBpcyB1c2VmdWwgcHJpbWFyaWx5IGZvciBjb25u ZWN0aW9ubGVzcyB0cmFuc3BvcnRzLjxiciBjbGFzcz0iIj4NClJlLXRyYW5zbWl0dGluZyB0aGUg c2FtZSBpbmZvcm1hdGlvbiB0d2ljZSBpbiB0aGlzIGNhc2UgaXMgb2YgZG91YnRmdWw8YnIgY2xh c3M9IiI+DQp2YWx1ZSBzaW5jZSAoYSkgZWl0aGVyIHRoZSBjb29raWUgY29udGFpbnMgdGhlIG5l Y2Vzc2FyeSBpbmZvIGFscmVhZHkgb3I8YnIgY2xhc3M9IiI+DQooYikgdGhlIHNlY29uZCBDbGll bnRIZWxsbyBjYXJyaWVzIHRoZSByZWxldmFudCBpbmZvcm1hdGlvbi48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpEb2VzIHRoaXMgbWFrZSBzZW5zZT88YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpDaWFvPGJyIGNsYXNzPSIiPg0KSGFubmVzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KT24gMDgvMjIvMjAxNyAxMDoxMyBQTSwgSWxhcmkgTGl1c3ZhYXJhIHdyb3RlOjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9uIFR1ZSwgQXVnIDIy LCAyMDE3IGF0IDA1OjUwOjQ5UE0gJiM0MzswMDAwLCBOb2FoIFJvYmJpbiB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5IZWxsbyBUb2RkITxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgYWxzbyBkaWQgbm90IHNlZSBhIHJlYXNvbiB3aHkg dGhlIHJhbmRvbSB2YWx1ZXMgaGFkIHRvIGJlIHRoZSBzYW1lPGJyIGNsYXNzPSIiPg0KYnV0IHRo ZSBsYW5ndWFnZSBkb2VzIG1hbmRhdGUgaXQuICZuYnNwOzxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgcmVhbGx5IGRvIG5vdCB0aGluayB0aGVyZSBpcyBhbnkg dGVjaG5pY2FsIG9yIHNlY3VyaXR5IHJlYXNvbiB3aHkgdGhlPGJyIGNsYXNzPSIiPg0KcmFuZG9t cyBoYXZlIHRvIGJlIHRoZSBzYW1lLiBBZnRlciBhbGwsIFRMUyAxLjMgZG9lcyBub3QgZGlyZWN0 bHkgdXNlPGJyIGNsYXNzPSIiPg0KdGhlIHJhbmRvbXMgYW55d2hlcmUgKHRoZXkgb25seSBhZmZl Y3QgdGhpbmdzIGluZGlyZWN0bHkgdmlhIGhhc2hlcyBvZjxiciBjbGFzcz0iIj4NCnRoZSBoYW5k c2hha2UpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPllvdSBtYWtlIGEgZ29vZCBhcmd1bWVudCBmb3Igbm90IGFsdGVyaW5nIHRo ZSBwYWRkaW5nIG9uIHRoZSBzZWNvbmQ8YnIgY2xhc3M9IiI+DQpDbGllbnRIZWxsby48YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJIHJlYWQgdGhhdCBhcmd1bWVu dCBhcyAmcXVvdDtUTFMgMS4zIGltcGxlbWVudGF0aW9ucyBzaG91bGQgbm90IG5lZWQ8YnIgY2xh c3M9IiI+DQpwYWRkaW5nJnF1b3Q7LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgdG9v ayBhIGxvb2sgYXQgc3RydWN0IENsaWVudEhlbGxvIGFuZCB0aGUgZXh0ZW5zaW9ucyBsaXN0Ojxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZXJlIGFyZSB0ZWNobmljYWwgcmVhc29ucyBm b3Igbm90IGFsdGVyaW5nICh0aGUgY2xpZW50IGhhcyBubyBpZGVhPGJyIGNsYXNzPSIiPg0Kd2hh dCB0aGUgaGVjayBzZXJ2ZXIgZGlkIHdpdGggdGhlc2UpOjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCi0gc2VydmVyX25hbWU8YnIgY2xhc3M9IiI+DQotIG1heF9mcmFnbWVudF9sZW5ndGg8 YnIgY2xhc3M9IiI+DQotIHN0YXR1c19yZXF1ZXN0PGJyIGNsYXNzPSIiPg0KLSBzaWduYXR1cmVf YWxnb3JpdGhtczxiciBjbGFzcz0iIj4NCi0gdXNlX3NydHA8YnIgY2xhc3M9IiI+DQotIGhlYXJ0 YmVhdDxiciBjbGFzcz0iIj4NCi0gYXBwbGljYXRpb25fbGF5ZXJfcHJvdG9jb2xfbmVnb3RpYXRp b248YnIgY2xhc3M9IiI+DQotIHNpZ25lZF9jZXJ0aWZpY2F0ZV90aW1lc3RhbXA8YnIgY2xhc3M9 IiI+DQotIGNsaWVudF9jZXJ0aWZpY2F0ZV90eXBlPGJyIGNsYXNzPSIiPg0KLSBzZXJ2ZXJfY2Vy dGlmaWNhdGVfdHlwZTxiciBjbGFzcz0iIj4NCi0gcHNrX2tleV9leGNoYW5nZV9tb2RlcyAoZHVl IHRvIHNpZGUtZWZmZWN0cyk8YnIgY2xhc3M9IiI+DQotIGNlcnRpZmljYXRlX2F1dGhvcml0aWVz PGJyIGNsYXNzPSIiPg0KLSBwb3N0X2hhbmRzaGFrZV9hdXRoPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KVGhlIGZvbGxvd2luZyBhcmUgZXhwbGljaXRseSBsaXN0ZWQgYXMgdG8gYmUgYWx0 ZXJlZC9kZWxldGVkOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0ga2V5X3NoYXJlIDxi ciBjbGFzcz0iIj4NCi0gcHJlX3NoYXJlZF9rZXk8YnIgY2xhc3M9IiI+DQotIGVhcmx5X2RhdGE8 YnIgY2xhc3M9IiI+DQotIGNvb2tpZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBm b2xsb3dpbmcgZG8gbm90IG5lZ290aWF0ZSBzdGF0ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQotICZsdDtyYW5kb20mZ3Q7PGJyIGNsYXNzPSIiPg0KLSBwYWRkaW5nPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KVGhlIGZvbGxvd2luZyBjYW4ndCBhcHBlYXIgaW4gQ2xpZW50SGVs bG86PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLSBvaWRfZmlsdGVyczxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoZSBmb2xsb3dpbmcgY2xpZW50IGdhaW5zIGluZm9ybWF0aW9u IGFib3V0IGluIEhSUjo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotICZsdDtjaXBoZXJz dWl0ZXMmZ3Q7PGJyIGNsYXNzPSIiPg0KLSBzdXBwb3J0ZWRfZ3JvdXBzIChwYXJ0aWFsbHkgaWYg a2V5X3NoYXJlIHdhcyBub3QgcHJlc2VudCkuPGJyIGNsYXNzPSIiPg0KLSBzdXBwb3J0ZWRfdmVy c2lvbnMgKHRoZSBjbGllbnQga25vd3Mgd2hhdCBzZXJ2ZXIgc2VsZWN0ZWQpLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkhvd2V2ZXIgdGhlIGxhc3QgZ3JvdXAg c2VlbXMgdG8gYmUga2luZCBvZiB0aGluZ3MgdGhhdCBhcmUgcmF0aGVyPGJyIGNsYXNzPSIiPg0K cXVlc3Rpb25hYmxlIHRvIHBydW5lIChtaWdodCBiZSBva2F5LCBidXQgdGhvc2UgbWFrZSBtZSB3 YXJ5KS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpBbHNvLCBJIGNhbWUgYWNjcm9zcyBvbmUgZWRnZSBjYXNlOiBXaGF0IGlmIGNsaWVu dCBkaXNjb3ZlcnMgdGhhdCBhbGw8YnIgY2xhc3M9IiI+DQp0aWNrZXRzIGluIHByZV9zaGFyZWRf a2V5IGFyZSBpbmNvbXBhdGlibGU/IFRoZSBkZWZpbml0aW9uIGRvZXMgbm90PGJyIGNsYXNzPSIi Pg0KYWxsb3cgMCB0aWNrZXRzLCBzbyBjaG9pY2VzIGFyZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQoxKSBMZWF2ZSBhbGwgdGhlIHRpY2tldHMgKHdoaWNoIGlzIG5vdCBnb2luZyB0byB3 b3JrKSBpbi48YnIgY2xhc3M9IiI+DQoyKSBMZWF2ZSBvbmUgdGlja2V0ICh3aGljaCBpcyBub3Qg Z29pbmcgdG8gd29yaykgaW4uPGJyIGNsYXNzPSIiPg0KMykgU3RyaXAgdGhlIGVudGllcmUgZXh0 ZW5zaW9uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi1JbGFyaTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNs YXNzPSIiPg0KVExTIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpU TFNAaWV0Zi5vcmciIGNsYXNzPSIiPlRMU0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KVExTIG1haWxpbmcg bGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIGNsYXNzPSIi PlRMU0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RsczxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_9989C9A42F7044E4BC1362A260EBF86Eakamaicom_-- From nobody Tue Aug 29 11:30: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 3F21B13219B for ; Tue, 29 Aug 2017 11:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDptxI7Y3QwQ for ; Tue, 29 Aug 2017 11:29:59 -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 4C500132941 for ; Tue, 29 Aug 2017 11:29:59 -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 v7TIQoLp011148; Tue, 29 Aug 2017 19:29:57 +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=tK71XSc7A+5b6uqRqg3T2lkZ52h7wir8w4NQLv4ftYo=; b=kAJv5ZhztjUVSsDpwN9LGNtHRVC+/jn4UHs67VbYE/jwmJel0KlwQ7y6yZVe5XZzNULS yGQSLxGvJqq2DUqTQ5+jevbcWXuoEX/CnnCF9nwbMM3QzhTCtnxW3+41BuLRZguPzBrE 88DVCO1NJq4B3mDJeITdO46NMu4Bq1nl2A1w7L0wABVeD+zOL+k9McvcYEFp7muMLOCA L10hCqUKzeIviNkgYam4642HaOwDqjagWSZeGFTzQ6h1BL3Fi6OPo7zOVCCWz87Smr3e vb6FzKVgZM8+X11/bT6GClkJQUezCEh9GiSQ6ZAVar1QCEoeXOs51ZlWbtUBswn1SlD3 vQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2cjx2bjtwb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Aug 2017 19:29:56 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7TIPlnY028836; Tue, 29 Aug 2017 14:29:56 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4avfchw-1; Tue, 29 Aug 2017 14:29:56 -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 88DC420136; Tue, 29 Aug 2017 12:29:55 -0600 (MDT) To: Ilari Liusvaara , Noah Robbin Cc: "tls@ietf.org" References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> From: Benjamin Kaduk Message-ID: <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com> Date: Tue, 29 Aug 2017 13:29:55 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> Content-Type: multipart/alternative; boundary="------------74B53C905AA8544945537B3C" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-29_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-1708290280 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-29_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-1708290280 Archived-At: Subject: Re: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2017 18:30:01 -0000 This is a multi-part message in MIME format. --------------74B53C905AA8544945537B3C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Ilari, Thanks for the by-extension categorization/breakdown. On 08/22/2017 03:13 PM, Ilari Liusvaara wrote: > On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote: >> Hello Todd! >> >> I also did not see a reason why the random values had to be the same >> but the language does mandate it. > I really do not think there is any technical or security reason why the > randoms have to be the same. After all, TLS 1.3 does not directly use > the randoms anywhere (they only affect things indirectly via hashes of > the handshake). IIRC there was at some point talk of reconstructing the original ClientHello based on the second one, but I guess we explicitly decided to not allow that with https://github.com/tlswg/tls13-spec/pull/678 . So, I guess I am just saying that I agree. >> You make a good argument for not altering the padding on the second >> ClientHello. > I read that argument as "TLS 1.3 implementations should not need > padding". IIRC at least some of the need for padding was due to middleboxes, and I don't have data on to what extent existing middleboxes choke on TLS 1.3 traffic. (I believe others do have such data, though.) > Also, I came accross one edge case: What if client discovers that all > tickets in pre_shared_key are incompatible? The definition does not > allow 0 tickets, so choices are: > > 1) Leave all the tickets (which is not going to work) in. > 2) Leave one ticket (which is not going to work) in. > 3) Strip the entiere extension. > My conceptual preference would be for (3), though I have a hard time convincing myself that the current text actually permits doing so. Maybe it's simplest to just add a short not about removing the extension if no compatible PSKs are known. -Ben --------------74B53C905AA8544945537B3C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Ilari,

Thanks for the by-extension categorization/breakdown.

On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote:

Hello Todd!

I also did not see a reason why the random values had to be the same
but the language does mandate it.  

I really do not think there is any technical or security reason why the
randoms have to be the same. After all, TLS 1.3 does not directly use
the randoms anywhere (they only affect things indirectly via hashes of
the handshake).

IIRC there was at some point talk of reconstructing the original ClientHello based on the second one, but I guess we explicitly decided to not allow that with https://github.com/tlswg/tls13-spec/pull/678 .  So, I guess I am just saying that I agree.


      

        
You make a good argument for not altering the padding on the second
ClientHello.


      

      
I read that argument as "TLS 1.3 implementations should not need
padding".


    

    

    IIRC at least some of the need for padding was due to middleboxes,
    and I don't have data on to what extent existing middleboxes choke
    on TLS 1.3 traffic.  (I believe others do have such data, though.)

    

    

      
Also, I came accross one edge case: What if client discovers that all
tickets in pre_shared_key are incompatible? The definition does not
allow 0 tickets, so choices are:

1) Leave all the tickets (which is not going to work) in.
2) Leave one ticket (which is not going to work) in.
3) Strip the entiere extension.



    

    

    My conceptual preference would be for (3), though I have a hard time
    convincing myself that the current text actually permits doing so. 
    Maybe it's simplest to just add a short not about removing the
    extension if no compatible PSKs are known.

    

    -Ben

  


--------------74B53C905AA8544945537B3C--


From nobody Tue Aug 29 12:03: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 CC7A6132351 for ; Tue, 29 Aug 2017 12:03:33 -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 Z5wE0Mx03QjZ for ; Tue, 29 Aug 2017 12:03:30 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C454213248B for ; Tue, 29 Aug 2017 12:03:29 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id s143so21489787ywg.0 for ; Tue, 29 Aug 2017 12:03:29 -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=57u5YZEScYoxoi9ndyciXlPw1ytFvCM90CDtMkoYXVw=; b=u6qQ3zMTOx9P1SEnMI8Y5DX1VDpijAtBL+e/itQ/KhrJ8Fa6j19orJbdxNOA+AAcNd C8c4jzeWPoZ8eOxhRPQVXz9dBtYtM9TbkKiZWSXjgC0j07x4iuO8DI9koSq/kBnUEOz3 jlZpNhpgfOMKtlZuOLzQ9kXGvMqSLQS5etkL9jsjmMMok4lLcTnB0pmVgCn0HzpQHN7k 0Bdmu4i5zIlAdkIqO3egoZ0Wb/pr5JQsBJEzEsRwQ0q5P4X6vOC5ykPiKEqDVFR8YXFj A9nBzB+GRt7oTQdcMJrVHn/7iZwg3e+SF+QnHX4gkz1IkYzOV+N5nfbIGeKSHxXLX4Dc JOkA==
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=57u5YZEScYoxoi9ndyciXlPw1ytFvCM90CDtMkoYXVw=; b=GAvM+JYJZZVWsC85iMUUJ0/EWOtL8oZZiPVXwlYqCLOE23wqcOz9vttHe41jdDA3cb vRcQpAUmTyCR2CaRXo4+ME4aO8l2X+Ys0QCXkEOcG0W0mrf64ZLspSP8hgAUiCmjFwgl Yyi3iloFEijZRbMZXREwk1zjby0RaFfghn5/CR1obY/x3vGKwqpppJ+VDJ5bjjkvAO9x Q28/1BbcDaKkqUPE/wRoVN5MuVMjEB2a8GdC9Ngv/5gdPxmAgYQ2T9YutuHRKnga1jJa GJDNI8uTqXJHOGkofhjgq2nualyEpLEcfgtdhjMNohVa9b6oLysheTgEby+XES6+iZ8I bodg==
X-Gm-Message-State: AHYfb5ihimFM753FJTLKS8OSrWkZMoEyc9UT7/38QDel0lMoCfbN9Rkm b+po/4rPJ8PgJ2veyg2sWCT2LbB899JZY1Y=
X-Received: by 10.129.147.195 with SMTP id k186mr1399284ywg.72.1504033409011;  Tue, 29 Aug 2017 12:03:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.218.130 with HTTP; Tue, 29 Aug 2017 12:02:48 -0700 (PDT)
In-Reply-To: <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com>
References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com>
From: Eric Rescorla 
Date: Tue, 29 Aug 2017 12:02:48 -0700
Message-ID: 
To: Benjamin Kaduk 
Cc: Ilari Liusvaara , Noah Robbin , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c07d56c1327a00557e911c2"
Archived-At: 
Subject: Re: [TLS] What counts as the same ClientHello?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Aug 2017 19:03:34 -0000

--94eb2c07d56c1327a00557e911c2
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk  wrote:

> Hi Ilari,
>
> Thanks for the by-extension categorization/breakdown.
>
> On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
>
> On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote:
>
> Hello Todd!
>
> I also did not see a reason why the random values had to be the same
> but the language does mandate it.
>
> I really do not think there is any technical or security reason why the
> randoms have to be the same. After all, TLS 1.3 does not directly use
> the randoms anywhere (they only affect things indirectly via hashes of
> the handshake).
>
>
> IIRC there was at some point talk of reconstructing the original
> ClientHello based on the second one, but I guess we explicitly decided to
> not allow that with https://github.com/tlswg/tls13-spec/pull/678 .  So, I
> guess I am just saying that I agree.
>
> You make a good argument for not altering the padding on the second
> ClientHello.
>
> I read that argument as "TLS 1.3 implementations should not need
> padding".
>
>
> IIRC at least some of the need for padding was due to middleboxes, and I
> don't have data on to what extent existing middleboxes choke on TLS 1.3
> traffic.  (I believe others do have such data, though.)
>

The padding isn't for middleboxes, it's for terminating endpoints.
 in favor of removing these restrictions.



> Also, I came accross one edge case: What if client discovers that all
> tickets in pre_shared_key are incompatible? The definition does not
> allow 0 tickets, so choices are:
>
> 1) Leave all the tickets (which is not going to work) in.
>
> 2) Leave one ticket (which is not going to work) in.
>
> 3) Strip the entiere extension.
>
>
>
> My conceptual preference would be for (3), though I have a hard time
> convincing myself that the current text actually permits doing so.  Maybe
> it's simplest to just add a short not about removing the extension if no
> compatible PSKs are known.
>

I think the current text says #1, which, AFAIK, doesn't cause any interop
problems, so I think we should just leave it as-is.

-Ekr


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

--94eb2c07d56c1327a00557e911c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=
On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk <bkaduk@akamai.com>=
; wrote:

 =20
   =20
 =20
  

    Hi Ilari,

    

    Thanks for the by-extension categorization/breakdown.<=
br>
    

    On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:

    

      
On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote:


      

        
Hello Todd!

I also did not see a reason why the random values had to be the same
but the language does mandate it. =20


      

      
I really do not think there is any technical or security reason =
why the
randoms have to be the same. After all, TLS 1.3 does not directly use
the randoms anywhere (they only affect things indirectly via hashes of
the handshake).


    

    

    IIRC there was at some point talk of reconstructing the original
    ClientHello based on the second one, but I guess we explicitly
    decided to not allow that with
    https://github.co=
m/tlswg/tls13-spec/pull/678 .=C2=A0 So, I guess I am
    just saying that I agree.

    

    

      

      

        
You make a good argument for not altering the padding on the s=
econd
ClientHello.


      

      
I read that argument as "TLS 1.3 implementations should not=
 need
padding".


    

    

    IIRC at least some of the need for padding was due to middleboxes,
    and I don't have data on to what extent existing middleboxes choke
    on TLS 1.3 traffic.=C2=A0 (I believe others do have such data, though.)=


The padding isn't for middleboxe=
s, it's for terminating endpoints.
=C2=A0in favor of removing=
 these restrictions.

=C2=A0

    

      
Also, I came accross one edge case: What if client discovers tha=
t all
tickets in pre_shared_key are incompatible? The definition does not
allow 0 tickets, so choices are:

1) Leave all the tickets (which is not going to work) in.
2)=
 Leave one ticket (which is not going to work) in.
3) Strip =
the entiere extension.



    

    

    My conceptual preference would be for (3), though I have a hard time
    convincing myself that the current text actually permits doing so.=C2=
=A0
    Maybe it's simplest to just add a short not about removing the
    extension if no compatible PSKs are known.
<=
br>
I think the current text says #1, which, AFAIK, doesn't c=
ause any interop problems, so I think we should just leave it as-is.
<=
div>
-Ekr

=


    

    -Ben

  



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c07d56c1327a00557e911c2--


From nobody Tue Aug 29 12:41: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 0820B132812 for ; Tue, 29 Aug 2017 12:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level: 
X-Spam-Status: No, score=-0.71 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JywufF1vTbFG for ; Tue, 29 Aug 2017 12:40: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 9DFD91321F1 for ; Tue, 29 Aug 2017 12:40: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 v7TJb2Jb006215; Tue, 29 Aug 2017 20:40:58 +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=/2JIXSDbaODx3il550jzswwUXvBD5bZWKjUvmtZOLyo=; b=NoEKNZEpCshYLb0p4EgqdBxlKinxXZODrU1Pb21ZgBS6hPYIAxdyRoPH3smbV74TOPnP wTt0Q25GmkJbJna6csSJfbKFbsXXziHrlSMrRvpYRsSqN0Z/n1Uj0qQ0FBiREldnbQeb 45v9fKT5cFqgA81/xKTtvmK4Y2L2ERb718Zhmk5D4XifFlstZ3zZlWXn1dUTktBnIGJS nb3sJ0StSIYn/2cnvnsYcyj6ebpiwYo/ippZaFDeuqQZa7VOYidT+DzACwHe0254L6OK d4Qk5CSjPVIm3dvAW8i32fHjPyDzglbCN33pbi8GOuWoHsgwwBEN5ckZKZEsCgDV7mAU hg== 
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2ck08kkcd8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Aug 2017 20:40:58 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7TJaQJ1011583; Tue, 29 Aug 2017 15:40:56 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ck4av3bxn-1; Tue, 29 Aug 2017 15:40:56 -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 525F81FC73; Tue, 29 Aug 2017 19:40:56 +0000 (GMT)
To: Eric Rescorla 
Cc: Ilari Liusvaara , Noah Robbin , "tls@ietf.org" 
References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com> 
From: Benjamin Kaduk 
Message-ID: 
Date: Tue, 29 Aug 2017 14:40:56 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9F6E05D970CE6EBFBA18B9B0"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-29_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-1708290297
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-29_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-1708290297
Archived-At: 
Subject: Re: [TLS] What counts as the same ClientHello?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Aug 2017 19:41:02 -0000

This is a multi-part message in MIME format.
--------------9F6E05D970CE6EBFBA18B9B0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 08/29/2017 02:02 PM, Eric Rescorla wrote:
>
> On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk  > wrote:
>
>     Hi Ilari,
>
>     Thanks for the by-extension categorization/breakdown.
>
>     On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
>>     On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote:
>>>     Hello Todd!
>>>
>>>     I also did not see a reason why the random values had to be the same
>>>     but the language does mandate it.  
>>     I really do not think there is any technical or security reason why the
>>     randoms have to be the same. After all, TLS 1.3 does not directly use
>>     the randoms anywhere (they only affect things indirectly via hashes of
>>     the handshake).
>
>     IIRC there was at some point talk of reconstructing the original
>     ClientHello based on the second one, but I guess we explicitly
>     decided to not allow that with
>     https://github.com/tlswg/tls13-spec/pull/678
>     
>     .  So, I guess I am just saying that I agree.
>
>>>     You make a good argument for not altering the padding on the second
>>>     ClientHello.
>>     I read that argument as "TLS 1.3 implementations should not need
>>     padding".
>
>     IIRC at least some of the need for padding was due to middleboxes,
>     and I don't have data on to what extent existing middleboxes choke
>     on TLS 1.3 traffic.  (I believe others do have such data, though.)
>
>
> The padding isn't for middleboxes, it's for terminating endpoints.
>  in favor of removing these restrictions.
>

No objection to removing the restriction from me.

>  
>
>>     Also, I came accross one edge case: What if client discovers that all
>>     tickets in pre_shared_key are incompatible? The definition does not
>>     allow 0 tickets, so choices are:
>>
>>     1) Leave all the tickets (which is not going to work) in.
>
>>     2) Leave one ticket (which is not going to work) in.
>
>>     3) Strip the entiere extension.
>>
>
>     My conceptual preference would be for (3), though I have a hard
>     time convincing myself that the current text actually permits
>     doing so.  Maybe it's simplest to just add a short not about
>     removing the extension if no compatible PSKs are known.
>
>
> I think the current text says #1, which, AFAIK, doesn't cause any
> interop problems, so I think we should just leave it as-is.
>

The editor's copy says the client can update the "pre_shared_key"
extension by removing any PSKs that are incompatible with the server's
indicated cipher suite, which is not exactly #1.

-Ben

--------------9F6E05D970CE6EBFBA18B9B0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 08/29/2017 02:02 PM, Eric Rescorla wrote:

    

      
      

        


          
On Tue, Aug 29, 2017 at 11:29 AM,
            Benjamin Kaduk <bkaduk@akamai.com>
            wrote:

            

              
 Hi Ilari,

                

                Thanks for the by-extension categorization/breakdown.

                  

                  On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:

                  

                    
On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote:


                    

                      
Hello Todd!

I also did not see a reason why the random values had to be the same
but the language does mandate it.  


                    

                    
I really do not think there is any technical or security reason why the
randoms have to be the same. After all, TLS 1.3 does not directly use
the randoms anywhere (they only affect things indirectly via hashes of
the handshake).


                  

                  

                 IIRC there was at some point talk of
                reconstructing the original ClientHello based on the
                second one, but I guess we explicitly decided to not
                allow that with https://github.com/tlswg/tls13-spec/pull/678
                .  So, I guess I am just saying that I agree.

                  

                  

                    

                      
You make a good argument for not altering the padding on the second
ClientHello.


                    

                    
I read that argument as "TLS 1.3 implementations should not need
padding".


                  

                  

                 IIRC at least some of the need for padding was
                due to middleboxes, and I don't have data on to what
                extent existing middleboxes choke on TLS 1.3 traffic. 
                (I believe others do have such data, though.)

            

            


            

            
The padding isn't for middleboxes, it's for terminating
              endpoints.

            
 in favor of removing these restrictions.

            

            


            

          

        

      

    

    

    No objection to removing the restriction from me.

    

    

      

        

          

            
 

            

              

                  

                    
Also, I came accross one edge case: What if client discovers that all
tickets in pre_shared_key are incompatible? The definition does not
allow 0 tickets, so choices are:

1) Leave all the tickets (which is not going to work) in.

                  

                

            

            

              

                  

                    
2) Leave one ticket (which is not going to work) in.

                  

                

            

            

              

                  

                    
3) Strip the entiere extension.



                  

                  

                 My conceptual preference would be for (3),
                though I have a hard time convincing myself that the
                current text actually permits doing so.  Maybe it's
                simplest to just add a short not about removing the
                extension if no compatible PSKs are known.

              

            

            


            

            
I think the current text says #1, which, AFAIK, doesn't
              cause any interop problems, so I think we should just
              leave it as-is.

            

          

        

      

    

    

    The editor's copy says the client can update the "pre_shared_key"
    extension by removing any PSKs that are incompatible with the
    server's indicated cipher suite, which is not exactly #1.

    

    -Ben

  


--------------9F6E05D970CE6EBFBA18B9B0--


From nobody Tue Aug 29 12:50: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 54DA6132925 for ; Tue, 29 Aug 2017 12:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.609
X-Spam-Level: 
X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhsxeKay8sgN for ; Tue, 29 Aug 2017 12:50:40 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 41D15132D85 for ; Tue, 29 Aug 2017 12:50:40 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id h127so22074117ywf.3 for ; Tue, 29 Aug 2017 12:50: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=wQQUgB3OWi32K0fub8uz65k6Yv9yxG134J1VAM8EYMM=; b=G32X/aFwG5sKMY57kVgMNm5DkVyAaG6c5+GLz3SpkHrI/fS0R0Bldxt6CJ0zWd149R //45yUTl3aAu8e1gTdCrusTj1cI4rXpGmf6bEdvpUNQ4eE3B9b9Cjh4C6t1lu2QBqCr1 N8L3i6AgRO03qf6yqn6OGeqy/F3A7GvncMDcCKI23/pZzm/hpVncKvW63/cnVA3Zymvj fKLAoVZTBj1gH3Rjv7k2Jc0Fn5uazDEBoPthawG2mAwn2vgISfCLKXDYioNoCXSk9F8E RO+uVHycgD+jgqLlCsavXomJjJiZC4V4jyNIeyGuTwIJzTuVYaVav42I1H6UeA9kcBQo WN+g==
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=wQQUgB3OWi32K0fub8uz65k6Yv9yxG134J1VAM8EYMM=; b=GMt1jnFmcORuhib+CyiIFgkS6QzG5I2eIgldfPdIN/sEuVCni8q0v1lq8DS4Iu9g0g 2Zctc7ezacNDUbyzUNQOyF8jC2OchMDH0pWOB97jJQhBTVOh1Rm0KBAl4giI+LnJhPsa dfBif9FwaiA35WWitP5djvm1ua+neHtgurIRTp0JYgj3MD5xXTOSE/sMzt3Ww1IBRQbT NL95KHz3zj0kpR0MzIpCezar/P6xSoffWHQgenm3wS3I7WpV4VcUn9iEYuQft+bue/8d WXqLRBePEo4tKz+Oc/hh6Z5Tkr6ig7OuPOf4vGw/b7Iy1zNYkHD4xIbomEqkD2iC2NSa IJDQ==
X-Gm-Message-State: AHYfb5iBYqcsALGwx5e/3rRf5wJXA75lbAUmJmAIQLXmXq0KI9/KxHi1 ByYch5EQ5yUI+2EXaNaSHFqSxghUWhep
X-Received: by 10.37.160.143 with SMTP id y15mr1320684ybh.339.1504036239539; Tue, 29 Aug 2017 12:50:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.211.1 with HTTP; Tue, 29 Aug 2017 12:49:58 -0700 (PDT)
In-Reply-To: 
References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com>  
From: Eric Rescorla 
Date: Tue, 29 Aug 2017 13:49:58 -0600
Message-ID: 
To: Benjamin Kaduk 
Cc: Ilari Liusvaara , Noah Robbin , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="089e0828f0ccc99d320557e9b976"
Archived-At: 
Subject: Re: [TLS] What counts as the same ClientHello?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Aug 2017 19:50:47 -0000

--089e0828f0ccc99d320557e9b976
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 29, 2017 at 1:40 PM, Benjamin Kaduk  wrote:

> On 08/29/2017 02:02 PM, Eric Rescorla wrote:
>
>
> On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk 
> wrote:
>
>> Hi Ilari,
>>
>> Thanks for the by-extension categorization/breakdown.
>>
>> On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
>>
>> On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote:
>>
>> Hello Todd!
>>
>> I also did not see a reason why the random values had to be the same
>> but the language does mandate it.
>>
>> I really do not think there is any technical or security reason why the
>> randoms have to be the same. After all, TLS 1.3 does not directly use
>> the randoms anywhere (they only affect things indirectly via hashes of
>> the handshake).
>>
>>
>> IIRC there was at some point talk of reconstructing the original
>> ClientHello based on the second one, but I guess we explicitly decided t=
o
>> not allow that with https://github.com/tlswg/tls13-spec/pull/678
>> 
>> .  So, I guess I am just saying that I agree.
>>
>> You make a good argument for not altering the padding on the second
>> ClientHello.
>>
>> I read that argument as "TLS 1.3 implementations should not need
>> padding".
>>
>>
>> IIRC at least some of the need for padding was due to middleboxes, and I
>> don't have data on to what extent existing middleboxes choke on TLS 1.3
>> traffic.  (I believe others do have such data, though.)
>>
>
> The padding isn't for middleboxes, it's for terminating endpoints.
>  in favor of removing these restrictions.
>
>
> No objection to removing the restriction from me.
>
>
>
>> Also, I came accross one edge case: What if client discovers that all
>> tickets in pre_shared_key are incompatible? The definition does not
>> allow 0 tickets, so choices are:
>>
>> 1) Leave all the tickets (which is not going to work) in.
>>
>> 2) Leave one ticket (which is not going to work) in.
>>
>> 3) Strip the entiere extension.
>>
>>
>>
>> My conceptual preference would be for (3), though I have a hard time
>> convincing myself that the current text actually permits doing so.  Mayb=
e
>> it's simplest to just add a short not about removing the extension if no
>> compatible PSKs are known.
>>
>
> I think the current text says #1, which, AFAIK, doesn't cause any interop
> problems, so I think we should just leave it as-is.
>
>
> The editor's copy says the client can update the "pre_shared_key"
> extension by removing any PSKs that are incompatible with the server's
> indicated cipher suite, which is not exactly #1.
>

That'll teach me not to go look at the spec before I talk. Sounds like we
should perhaps just remove that text and do #1, but I could also live with
#3.

-Ekr


> -Ben
>

--089e0828f0ccc99d320557e9b976
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Aug 29, 2017 at 1:40 PM, Benjamin Kaduk <<=
a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com=
> wrote:

 =20
   =20
 =20
  

    On 08/29/2017 02:02 PM, Eric Rescorla wrote:

    

     =20
      

        


          
On Tue, Aug 29, 2017 at 11:29 AM,
            Benjamin Kaduk <bkaduk@akamai.com>
            wrote:

            

              
 Hi Ilari,

                

                Thanks for the by-extension categorization/breakdown.=


                  

                  On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:

                  

                    
On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Rob=
bin wrote:


                    

                      
Hello Todd!

I also did not see a reason why the random values had to be the same
but the language does mandate it. =20


                    

                    
I really do not think there is any technical or se=
curity reason why the
randoms have to be the same. After all, TLS 1.3 does not directly use
the randoms anywhere (they only affect things indirectly via hashes of
the handshake).


                  

                  

                 IIRC there was at some point talk of
                reconstructing the original ClientHello based on the
                second one, but I guess we explicitly decided to not
                allow that with https:/=
/github.com/tlswg/tls13-spec/pull/678
                .=C2=A0 So, I guess I am just saying that I agree.
                  

                  

                    

                      
You make a good argument for not altering the pa=
dding on the second
ClientHello.


                    

                    
I read that argument as "TLS 1.3 implementati=
ons should not need
padding".


                  

                  

                 IIRC at least some of the need for padding was
                due to middleboxes, and I don't have data on to what
                extent existing middleboxes choke on TLS 1.3 traffic.=C2=A0
                (I believe others do have such data, though.)

            

            


            

            
The padding isn't for middleboxes, it's for termin=
ating
              endpoints.

            
=C2=A0in favor of removing these restrictions.

            

            


            

          

        

      

    

    

    No objection to removing the restriction from me.

    

    

      

        

          

            
=C2=A0

            

              

                  

                    
Also, I came accross one edge case: What if client=
 discovers that all
tickets in pre_shared_key are incompatible? The definition does not
allow 0 tickets, so choices are:

1) Leave all the tickets (which is not going to work) in.

                  

                

            

            

              

                  

                    
2) Leave one ticket (which is not going to work) i=
n.

                  

                

            

            

              

                  

                    
3) Strip the entiere extension.



                  

                  

                 My conceptual preference would be for (3),
                though I have a hard time convincing myself that the
                current text actually permits doing so.=C2=A0 Maybe it'=
s
                simplest to just add a short not about removing the
                extension if no compatible PSKs are known.

              

            

            


            

            
I think the current text says #1, which, AFAIK, doesn'=
t
              cause any interop problems, so I think we should just
              leave it as-is.

            

          

        

      

    

    

    The editor's copy says the client can update the "pre_shared_k=
ey"
    extension by removing any PSKs that are incompatible with the
    server's indicated cipher suite, which is not exactly #1.
=


That'll teach me not to go look at the=
 spec before I talk. Sounds like we should perhaps just remove that text an=
d do #1, but I could also live with #3.

-Ekr
=



    

    -Ben

  






--089e0828f0ccc99d320557e9b976--


From nobody Tue Aug 29 13:23: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 CC724132D85 for ; Tue, 29 Aug 2017 13:23: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=symc.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 GkCMvYDOrYOg for ; Tue, 29 Aug 2017 13:23:46 -0700 (PDT)
Received: from tussmtoutape01.symantec.com (Tussmtoutape01.symantec.com [155.64.38.231]) (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 EF80D132D96 for ; Tue, 29 Aug 2017 13:23:39 -0700 (PDT)
Received: from tussmtmtaapi02.symc.symantec.com (tus3-f5-symc-ext-prd-snat4.net.symantec.com [10.44.130.4]) by tussmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id 77.3D.04051.B4DC5A95; Tue, 29 Aug 2017 20:23:39 +0000 (GMT)
X-AuditID: 0a2c7e31-2d2719c000000fd3-b4-59a5cd4b2c5b
Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat4.net.symantec.com [10.44.130.4]) by tussmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 73.0E.04468.B4DC5A95; Tue, 29 Aug 2017 20:23:39 +0000 (GMT)
Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 29 Aug 2017 13:23:38 -0700
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.128.5) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Tue, 29 Aug 2017 13:23:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com;  s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r1BZNnp04jY1V3N6n+R5B4OSCYGCmomTDNZTOU27yno=; b=CGoVa+ktsjjEs7i7b4lzKIGxqX/CY+7RNftPSKGGhltqaVoqkmo2iQj10VFzpHOrQlCITIdzUW0BD3WAaTbzJn3E1QWZc5crvN/v17puWdrlt7r80uNKFTK9mkrZxTe8w0/5l9Cz/qPQH7jHInLy6fcX6z5ABqSuaslwcq7dOFw=
Received: from DM5PR16MB1723.namprd16.prod.outlook.com (10.172.44.16) by DM5PR16MB0042.namprd16.prod.outlook.com (10.172.92.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Tue, 29 Aug 2017 20:23:36 +0000
Received: from DM5PR16MB1723.namprd16.prod.outlook.com ([10.172.44.16]) by DM5PR16MB1723.namprd16.prod.outlook.com ([10.172.44.16]) with mapi id 15.01.1385.014; Tue, 29 Aug 2017 20:23:36 +0000
From: Noah Robbin 
To: Eric Rescorla , Benjamin Kaduk 
CC: Ilari Liusvaara , "tls@ietf.org" 
Thread-Topic: [EXT] Re: [TLS] What counts as the same ClientHello?
Thread-Index: AQHTG28w7fmdIaOCV0yhonBkpJAAwKKQz3wAgArjRICAAAkwAIAACqgAgAAChgD//8ZXAA==
Date: Tue, 29 Aug 2017 20:23:36 +0000
Message-ID: <130D59BC-82A3-4E7A-AF84-8F37D42E8CCF@symantec.com>
References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@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=Noah_Robbin@symantec.com; 
x-originating-ip: [72.23.5.194]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR16MB0042; 6:x0X48blZdGOI/fgprSuv17nbV6HW5oZUyR8ceipir773uwpHez4RdisZ0bn/iVwicuJ8r9VDbLiSgWv5caKLopjFzTRbI808SIngsQ8lFM1pJfnhXNmIxaGfl6MFmlpe5MK/MtnURiR1i+kjpJsqiEzszw+86+78XUOBBDveyGlT+5iWs20B3P5sJoWnsyduhKHJptCzDp7ZW3E9IZpT0+Q5xAk5IAXgqRICTftxxtUjbIK4rv8vRuemzRIyTrb6e9OekDTY5HhCUk+zn4qmXjvUtCKScA5XD23L1aedpRwQtI9LXP79+NyR3Ohzh3ILz3478O4RqoILknJyILkXgw==; 5:krpSYQmvHG90Rd3qZt9A0L2s+TzQ1QDP1t8FjK+kTJOXpejIz7W/YJ6heIQdhJd2sXC5kEg2u+TwmXCxX5mBy23KHqdohe4g5z7kiXqfhhqzzPRxyHnuCCC/FbD8krI4GA2GD2MbueDlTs3ImdVigw==; 24:hll1N+5OnDPRNo76UrnfIofsZ9blz3OJ9BLGJynjq/VkaE4XhBSvQdTHajFKhiDA03GG4csJTnHc2TDG+2LYVvLS1fm1l/2uG3Wl0HNFGDU=; 7:3AAuCp9MzoC0n0qoUHWesk+2sWbelFD0Gq5GLcUOLxxB6hMjaBomtgqyCqg44RuZjB+i8ie3QNOometklaskZ5y3BVCW4cVn8CM9T5TwsADsUAg+IHff78CDmLklE+1hL39vpo4cTrFyJDlg/an7lkhCsGYNiOYzLYon9JBW+o/LFziTBW+yn/Av0zckDhc6lQGaXBZ2Tr0y9iJIfxYELhQiwdk0QZFuYpO9fUmYzKs=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: dd0803e3-ffbe-4363-f2a8-08d4ef1bd416
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB0042; 
x-ms-traffictypediagnostic: DM5PR16MB0042:
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)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB0042; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB0042; 
x-forefront-prvs: 0414DF926F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(14454004)(6512007)(54896002)(6306002)(99286003)(6246003)(2900100001)(54906002)(93886005)(36756003)(53936002)(82746002)(76176999)(50986999)(33656002)(54356999)(558084003)(7736002)(4326008)(81156014)(8936002)(101416001)(8676002)(80792005)(97736004)(189998001)(81166006)(229853002)(77096006)(105586002)(106356001)(6506006)(6486002)(6436002)(2950100002)(10290500003)(72206003)(5660300001)(478600001)(3280700002)(3660700001)(68736007)(86362001)(6116002)(25786009)(3846002)(102836003)(66066001)(83716003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB0042; H:DM5PR16MB1723.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_130D59BC82A34E7AAF848F37D42E8CCFsymanteccom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 20:23:36.5949 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB0042
X-OriginatorOrg: symantec.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCKsWRmVeSWpSXmKPExsXCpdPEout9dmmkweETkhaNmxtZLVa8Psdu 8X73dBaLT+e7GB1YPCYfWcDssWTJTyaPyY/bmD1ud89hC2CJ4rJJSc3JLEst0rdL4Mr4Pf0t S8E+mYrT544xNjCelu5i5OSQEDCRuLZrL3MXIxeHkMAnRomV/fNZYRLfprSxQCS+M0pcXXuF CSQhJHCUUaJ3vjhE4iWjxNMLCxlBHBaBTmaJM/u2s0JkpjBJfJoxkw3COQLU0jyPGaSfTUBH 4vWUNWCzRARcJI7uvAlmMwv4Svx7tpcdxBYWcJR4tP0HI0SNk8Sh36fYIOwwiQ2PPgHVcwCt U5WYd1EJJMwrYC8x6cF9dohdL5gklk18B9bLKRAocah7FZjNKCAm8f3UGqhd4hK3nsxngnhU QGLJnvPMELaoxMvH/1gh6qMlNkyGuEdCQF7i/tPTjBC2rMSl+d1gL0sItLFL7L5+FqpZT2Lr xLeMIMdJAD2zeZ42RM0jJonzexuhmrUkWj9+ZYGwrSQ6Jh5nncBoOAvJTRB2ssSFWw2ss8Ce E5Q4OfMJyyygscwCmhLrd+lDlChKTOl+yA5ha0i0zpkLZXtIrPh5jxlZzQJGjlWMCiWlxcW5 JfmlJYkFqQaGesWVuckgIhGY0pL1kvNzNzGC01qd4Q7GRxt8DjEKcDAq8fBG7lgaKcSaWAZU eYhRgoNZSYRX8AxQiDclsbIqtSg/vqg0J7X4EKM0B4uSOO+9tu5IIYH0xJLU7NTUgtQimCwT B6dUA2P2IVs+7xV/b127WiH7tcZU6iJztmey9rJX5bHGXbU39+hu6vXauuvbIgPn61vl2xyK bmjw1Jf+Lu0Iuc6yqPbthHm3VeYXNtypFFsk8j867aBz2i/vRWrGmvelzbpi47q2lR+Jdig2 WPbe+/f3zSlrAk/+b7q3u0i/XtVzjkPD9egTyneMziqxFGckGmoxFxUnAgB932wRZwMAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsXCpdPEout9dmmkwfY7IhaNmxtZLVa8Psdu 8X73dBaLT+e7GB1YPCYfWcDssWTJTyaPyY/bmD1ud89hC2CJ4rJJSc3JLEst0rdL4Mr4Pf0t S8E+mYrT544xNjCelu5i5OSQEDCR+DaljaWLkYtDSOA7o8TVtVeYQBJCAkcZJXrni0MkXjJK PL2wkBHEYRHoZJY4s287K0RmCpPEpxkz2SCcI0AtzfOYQfrZBHQkXk9ZAzZLRMBF4ujOm2A2 s4CvxL9ne9lBbGEBR4lH238wQtQ4SRz6fYoNwg6T2PDoE1A9B9A6VYl5F5VAwrwC9hKTHtxn h9j1gkli2cR3YL2cAoESh7pXgdmMAmIS30+tgdolLnHryXwmiEcFJJbsOc8MYYtKvHz8jxWi Plpiw2SIeyQE5CXuPz3NCGHLSlya3w32soRAG7vE7utnoZr1JLZOfMsIcpwE0DOb52lD1Dxi kji/txGqWUui9eNXFgjbSqJj4nFWCDtb4vuvTywQDZdZJVb9WM02gVF3FpJjIexkiQu3Glhn gX0tKHFy5hOWWUD7mAU0Jdbv0ocoUZSY0v2QHcLWkGidMxfK9pBY8fMeM7KaBYwcqxgVSkqL i3NLcksSEwsyDYz0iitzk0FEIjClJesl5+duYgSnNWfJHYyH/vgcYhTgYFTi4d1RujRSiDWx DKjyEKM0B4uSOK/JKpFIIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxq4Y1ZcYsqRWO3ddnl vTm8XaM3KUI1vey7WNVWjx5dI399f/t7llMmeqyZacbeE3+l2/f3s4+O0oflFC7uZha6VPqV ayu/bUluheTe0/66y/dce5ldvH2iqcVZA8+vUw/MzLl7r4r7l6VTyP2Dgl90Zhn/kFKpe35J 4X/J8qhPhSdXfv17+5oSS3FGoqEWc1FxIgBJaR+3TAMAAA==
X-CFilter-Loop: TUS04
Archived-At: 
Subject: Re: [TLS] [EXT] Re:  What counts as the same ClientHello?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Aug 2017 20:23:48 -0000

--_000_130D59BC82A34E7AAF848F37D42E8CCFsymanteccom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB3YW50IHRvIGJyaW5nIHVwIG15IG9yaWdpbmFsIHF1ZXN0aW9uIG9uIENIIHJhbmRvbSB2YWx1
ZXMgYWdhaW4uICBUaGUgZHJhZnQgcmVxdWlyZXMgdGhlIHR3byBDSCByYW5kb20gdmFsdWVzIHRv
IGJlIHRoZSBzYW1lIHdpdGhvdXQgYSByZWFsIHJlYXNvbiBmb3IgZG9pbmcgc28uICBTaG91bGQg
d2UgcmVsYXggdGhpcyByZXF1aXJlbWVudD8NCg0KLU5vYWgNCg==

--_000_130D59BC82A34E7AAF848F37D42E8CCFsymanteccom_
Content-Type: text/html; charset="utf-8"
Content-ID: <456CE28D4F8CDF4D96A99F7730CD583B@namprd16.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u
cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46
MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpz
cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h
dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb3VyaWVyO30NCnNwYW4uRW1haWxTdHls
ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpl
eHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4N
Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSB3YW50IHRvIGJyaW5nIHVwIG15IG9yaWdpbmFsIHF1ZXN0aW9uIG9uIENIIHJhbmRvbSB2YWx1
ZXMgYWdhaW4uJm5ic3A7IFRoZSBkcmFmdCByZXF1aXJlcyB0aGUgdHdvIENIIHJhbmRvbSB2YWx1
ZXMgdG8gYmUgdGhlIHNhbWUgd2l0aG91dCBhIHJlYWwgcmVhc29uIGZvciBkb2luZyBzby4mbmJz
cDsgU2hvdWxkIHdlIHJlbGF4IHRoaXMgcmVxdWlyZW1lbnQ/PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPi1Ob2FoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_130D59BC82A34E7AAF848F37D42E8CCFsymanteccom_--


From nobody Tue Aug 29 13:38: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 2CB13132D91 for ; Tue, 29 Aug 2017 13:38:40 -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 BnXGHspl2Mh7 for ; Tue, 29 Aug 2017 13:38:37 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id DF3F2132940 for ; Tue, 29 Aug 2017 13:38:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 58F8483733; Tue, 29 Aug 2017 23:38:34 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id uLaD6ud7uMMa; Tue, 29 Aug 2017 23:38:33 +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 4B01EC4; Tue, 29 Aug 2017 23:38:29 +0300 (EEST)
Date: Tue, 29 Aug 2017 23:38:28 +0300
From: Ilari Liusvaara 
To: Benjamin Kaduk 
Cc: Eric Rescorla , Noah Robbin , "tls@ietf.org" 
Message-ID: <20170829203828.um5yeh56tyqs63mn@LK-Perkele-VII>
References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.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] What counts as the same ClientHello?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Aug 2017 20:38:40 -0000

On Tue, Aug 29, 2017 at 02:40:56PM -0500, Benjamin Kaduk wrote:
> On 08/29/2017 02:02 PM, Eric Rescorla wrote:
> >
> > On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk  > > wrote:
> >
> >     Hi Ilari,
> >
> >     Thanks for the by-extension categorization/breakdown.
> >
> >     On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
> >>     On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote:
> >>>     Hello Todd!
> >>>
> >>>     I also did not see a reason why the random values had to be the same
> >>>     but the language does mandate it.  
> >>     I really do not think there is any technical or security reason why the
> >>     randoms have to be the same. After all, TLS 1.3 does not directly use
> >>     the randoms anywhere (they only affect things indirectly via hashes of
> >>     the handshake).
> >
> >     IIRC there was at some point talk of reconstructing the original
> >     ClientHello based on the second one, but I guess we explicitly
> >     decided to not allow that with
> >     https://github.com/tlswg/tls13-spec/pull/678
> >     
> >     .  So, I guess I am just saying that I agree.
> >
> >>>     You make a good argument for not altering the padding on the second
> >>>     ClientHello.
> >>     I read that argument as "TLS 1.3 implementations should not need
> >>     padding".
> >
> >     IIRC at least some of the need for padding was due to middleboxes,
> >     and I don't have data on to what extent existing middleboxes choke
> >     on TLS 1.3 traffic.  (I believe others do have such data, though.)
> >
> >
> > The padding isn't for middleboxes, it's for terminating endpoints.
> >  in favor of removing these restrictions.
> >
> 
> No objection to removing the restriction from me.

Looking back at the list I posted, there are pretty few extensions that
are safe to alter or delete:

- key_share
- pre_shared_key
- early_data
- cookie
-  (not actually an extension)
- padding

The remaining extensions are either very much unsafe to alter due to
unknown commitments, or look potentially dangerous to security to alter
(with known commitments).
 
Hmm... Could pre_shared_key also belong to "potentially dangerous to
security to alter"? It is part of cipher negotiation after all, and
there is no bounding set, unlike with key_share.

The ClientHellos are tied together by handshake hash, which makes
attacks quite a lot more difficult, especially given that weak hashes
are unsafe for other reasons. Unfortunately, properly analyzing this is
way beyond my pay grade.



-Ilari


From nobody Tue Aug 29 14:11: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 3F66C1321B9 for ; Tue, 29 Aug 2017 14:11:54 -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 E-3GUpYzQMf2 for ; Tue, 29 Aug 2017 14:11:52 -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 6EE5B126B6D for ; Tue, 29 Aug 2017 14:11:52 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id t188so23068067ywb.1 for ; Tue, 29 Aug 2017 14:11:52 -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=P7SVm9jUGq66qSuiWgtFcu4khpwPK2pyRHzQQftDsPY=; b=qQOgockoSQ60My6PDradPicgcHx+nX/pphhVrF8JpIkGr/0hkXmbuyU+ctwjwh/+y4 beAjUk4+toXXtoppI9CnV1kfdJ/M/q+4GLBFkhFtq1/tYMPKaYhZ0MiwOtjB7knmapkg UtW30Vpdo7avJlDg022+62uLd7udvulSnbh8d+zoPGNO5T2hj8cE0nQXjYA8I5fT9Y4v GaOqb06VelX1/RqkIsDEwgHiQWmqUrBT1sY/79W3fwgbWChEHlin735BPpazRCdGyTZ2 7+QS94Q2kCJzdk39IdkAWeXsFODNkA0m/BCzTrrS7PAIDKxSDmnUOScX7pDRUlbEKLoP Fr6g==
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=P7SVm9jUGq66qSuiWgtFcu4khpwPK2pyRHzQQftDsPY=; b=qQQGqu+XVcxkoIrI860H57TjDUe1q3ThTF5gw23kluOqw6nuv+9XchQ1KQjDzlBxpc Xi6jm4KUmwv9+nrlWFzTkwiVkZb5cVwPHz0IKmeULii8KdLCu79FGpl/8XCEykreru6i ROUnY3CmFYQKwy/5g7XBa1wPNEZPNZWPHCG7zlmh95awMeDnf05Vz2KFdOiGEdkWtUgx sXZ4WwgY3rKtkCEQ2B15k683M12OAVraKZtVV7aojZmBxpgijfVxxSGtmVzege4dZRW2 5MhdijNDnq8O2DAQKGCjakDey4LMC2/t8vrJC4eJtIsxEcVssD/0ynuS+nel0WIBqbgQ Kq5Q==
X-Gm-Message-State: AHYfb5hTbqwf6YHy9ZWIYgiRaypNhEByn4mP5emxNBpR3oEXoNWZLPzS os3KM3ObACzUaU50c/ZB1tmZzft6s8mB
X-Received: by 10.129.79.202 with SMTP id d193mr1554149ywb.37.1504041111677; Tue, 29 Aug 2017 14:11:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.218.130 with HTTP; Tue, 29 Aug 2017 14:11:11 -0700 (PDT)
In-Reply-To: <130D59BC-82A3-4E7A-AF84-8F37D42E8CCF@symantec.com>
References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com>    <130D59BC-82A3-4E7A-AF84-8F37D42E8CCF@symantec.com>
From: Eric Rescorla 
Date: Tue, 29 Aug 2017 15:11:11 -0600
Message-ID: 
To: Noah Robbin 
Cc: Benjamin Kaduk , Ilari Liusvaara , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114d3b0e3085c20557eadc77"
Archived-At: 
Subject: Re: [TLS] [EXT] Re:  What counts as the same ClientHello?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Aug 2017 21:11:54 -0000

--001a114d3b0e3085c20557eadc77
Content-Type: text/plain; charset="UTF-8"

No, I don't think so. I don't see that it makes anyone's life significantly
easier too relax.

-Ekr


On Tue, Aug 29, 2017 at 2:23 PM, Noah Robbin 
wrote:

> I want to bring up my original question on CH random values again.  The
> draft requires the two CH random values to be the same without a real
> reason for doing so.  Should we relax this requirement?
>
>
>
> -Noah
>

--001a114d3b0e3085c20557eadc77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


No, I don't think so. I don't see that it makes an=
yone's life significantly easier too relax.

-Ekr


On Tue, Aug =
29, 2017 at 2:23 PM, Noah Robbin <Noah_Robbin@symantec.com><=
/span> wrote:













I want to bring up my original question on CH random=
 values again.=C2=A0 The draft requires the two CH random values to be the =
same without a real reason for doing so.=C2=A0 Should we relax this require=
ment?<=
u>


=C2=A0


-Noah










--001a114d3b0e3085c20557eadc77--


From nobody Tue Aug 29 22:36: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 A2A5313239C; Tue, 29 Aug 2017 22:36:25 -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.59.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150407138561.21512.9139870120874867860@ietfa.amsl.com>
Date: Tue, 29 Aug 2017 22:36:25 -0700
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-sni-encryption-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: Wed, 30 Aug 2017 05:36:26 -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           : SNI Encryption in TLS Through Tunneling
        Authors         : Christian Huitema
                          Eric Rescorla
	Filename        : draft-ietf-tls-sni-encryption-00.txt
	Pages           : 22
	Date            : 2017-08-29

Abstract:
   This draft describes the general problem of encryption of the Server
   Name Identification (SNI) parameter.  The proposed solutions hide a
   Hidden Service behind a Fronting Service, only disclosing the SNI of
   the Fronting Service to external observers.  The draft starts by
   listing known attacks against SNI encryption, discusses the current
   "co-tenancy fronting" solution, and then presents two potential TLS
   layer solutions that might mitigate these attacks.
   The first solution is based on TLS in TLS "quasi tunneling", and the
   second solution is based on "combined tickets".  These solutions only
   require minimal extensions to the TLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00
https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-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 Tue Aug 29 23:19: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 7251F126B71 for ; Tue, 29 Aug 2017 23:19:29 -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 KamASlDv-X7z for ; Tue, 29 Aug 2017 23:19:28 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 D9B3A1241FC for ; Tue, 29 Aug 2017 23:19:27 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id j46so16253061uag.5 for ; Tue, 29 Aug 2017 23:19: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=8uiwgrIgWGIqE4GV4yPAnHNcCBpt3SiD2XD+essIobQ=; b=NmaZy02eOu/ZW+HY302BhJt7V48+RfBwf1MDSZMyN1rVBXXImeP+P9odDec87mpBt/ xDREsFdBdBG85jEn0eSyyWnpgQ2fcc1zh1C/vKXQPAS4+7PcYygn+LLPHSHB4haQtTBU DyfmjEBT97agJb23qqKCDJvPANQVO3OEABkbe0g9CTSYkBWolu8qfyasbmxnEMLfmGam qPYELTswicFfzUsUfu5zkea1r+VOPU6Rw6ywZ8fgMP39sJxk70UE99fNO0OD88mqYUHp AIn+thgEANaYBxkRIEZbL1v5CJNw4m3Tl4aI+LoUg88MuATEzkEJjtguGXCHUQgbhdfd jMqA==
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=8uiwgrIgWGIqE4GV4yPAnHNcCBpt3SiD2XD+essIobQ=; b=BkJWyGOaMez36SLJwSULDVlrQnbtMrk3Cwyr0Rie0nUztKS1tX948v3B4yJXbZq5ke Q+g9CQ/BfhFoyHYvjPDER0e3S7uAVkp1ROinlXCkaMVtJodZma9kQMdhynH0dIYVc1YK /sIPNcYYxm4Sm0h+XL/X2IxaeDw9b7oQ5Qt/2jV9w8JdTpXvtcR6fi0jeKUGLSFJMs1C ybBMoENZ6/ZvX2HpRnN8SXhRB7XaTmNyTxsKQE64SmC1h7eJDiTQWL9Shcy6wcbN88Rw tBwesy5b9/q6rPpFwv/sKR2Ex4lp9oBbxKOA9NOjFhdRu3reb/dVENVrFQATTzbee635 2IfQ==
X-Gm-Message-State: AHPjjUhw0xW2xni19Wk8WfKQ/0JZlQCDuw/Fd5RI4xak/tgAjE7d2vCP xU1IiCCVjpjQawLmddqE7GrIBNTcjvXb
X-Google-Smtp-Source: ADKCNb7DoEO0kr4n2kUH+fP42XOF1yNZITnIXgQV5sr4JmnF3oZFL3JzO4Spo/NKAvU5ZYtg1Iz/tU+Se5w1cKWc2lw=
X-Received: by 10.176.26.24 with SMTP id a24mr290256uai.102.1504073966833; Tue, 29 Aug 2017 23:19:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.18.67 with HTTP; Tue, 29 Aug 2017 23:19:06 -0700 (PDT)
In-Reply-To: <87bmncfqa2.fsf@fifthhorseman.net>
References:  <87bmncfqa2.fsf@fifthhorseman.net>
From: Tony Arcieri 
Date: Tue, 29 Aug 2017 23:19:06 -0700
Message-ID: 
To: Daniel Kahn Gillmor 
Cc: "" 
Content-Type: multipart/alternative; boundary="f403043665288257930557f282f4"
Archived-At: 
Subject: Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 30 Aug 2017 06:19:29 -0000

--f403043665288257930557f282f4
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 18, 2017 at 3:46 PM, Daniel Kahn Gillmor 
wrote:

> While i think i understand where you're coming from, Tony, i can't help
> but note that this use case is difficult to distinguish from a regime
> that:
>
>  (a) wants to forbid anonymous speech, and
>
>  (b) wants to censor "unapproved" information sources, and
>
>  (c) wants the capacity to undermine freedom of association.
>
> That makes me wary, and i hope that SNI Encryption is *not* conflated
> with these particular use cases.
>

TLS tunnels have a multitude of use cases, from SNI encryption to service
discovery-aware load balancers to Tor-like anonymity networks to
privacy-preserving payment channel networks to my much more mundane
"Squid-like authenticated egress proxy" problem.

I'm simply asking that if tunnels become the mechanism by which SNI
encryption is ultimately implemented, that all of the potential use cases
of tunnels are considered, rather than observing the problem through the
microcosm that is "SNI Encryption".

Note that I'm proposing absolutely nothing new, just asking that the
tunneling problem be considered from more angles than one. If TLS contains
(mis)features which forbid anonymous speech or censor unapproved
information sources, I'm afraid that the ship has already sailed there. But
perhaps, well-implemented TLS tunnels could ultimately help route around
censorship.

-- 
Tony Arcieri

--f403043665288257930557f282f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On F=
ri, Aug 18, 2017 at 3:46 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.ne=
t> wrote:
While i think i u=
nderstand where you're coming from, Tony, i can't help

but note that this use case is difficult to distinguish from a regime

that:



=C2=A0(a) wants to forbid anonymous speech, and



=C2=A0(b) wants to censor "unapproved" information sources, and


=C2=A0(c) wants the capacity to undermine freedom of association.



That makes me wary, and i hope that SNI Encryption is *not* conflated

with these particular use cases.

TLS tu=
nnels have a multitude of use cases, from SNI encryption to service discove=
ry-aware load balancers to Tor-like anonymity networks to privacy-preservin=
g payment channel networks to my much more mundane "Squid-like authent=
icated egress proxy" problem.

I'm simply =
asking that if tunnels become the mechanism by which SNI encryption is ulti=
mately implemented, that all of the potential use cases of tunnels are cons=
idered, rather than observing the problem through the microcosm that is &qu=
ot;SNI Encryption".

Note that I'm proposi=
ng absolutely nothing new, just asking that the tunneling problem be consid=
ered from more angles than one. If TLS contains (mis)features which forbid =
anonymous speech or censor unapproved information sources, I'm afraid t=
hat the ship has already sailed there. But perhaps, well-implemented TLS tu=
nnels could ultimately help route around censorship.

-- 
Tony Arcieri




--f403043665288257930557f282f4--


From nobody Wed Aug 30 01: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 189C21326DF for ; Wed, 30 Aug 2017 01:07:08 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4Ra5e_xNHUB for ; Wed, 30 Aug 2017 01:07:06 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65F9132386 for ; Wed, 30 Aug 2017 01:07:05 -0700 (PDT)
Received: from [192.168.91.203] ([195.149.223.129]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LabZr-1d5uUy2j8R-00mMzB for ; Wed, 30 Aug 2017 10:07:03 +0200
To: tls@ietf.org
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <560d1f68-ba41-a65c-6a90-15c370455eea@gmx.net>
Date: Wed, 30 Aug 2017 10:07:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:64TOKqqqJQESWoluXjdHgq9+25Uu9E2z1WYYqsYdTHzoF/rxCMQ +kNds7n4CEIXhPEu5eGoGsR+u1uli3vXLY7txr5eL8JOlZK51iyXKhCi4iHUira3Y8aSlGG SwMc1NQbY/7thZGc5y4F4N6fQ+rWVxaiQd6gQwuL6qXx6RpNGPg69XZ3g/qv3XHjvbY31jp Sp9R6BbrsK1s7Sn0V5Pvg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:1tVO47r1aaY=:a4AyU7B/kLqKkA2sFqhCYQ Iq6peHhicLCtQvl6x2ZlsfXs3d5RGGoboZ3szMRqdTUr8O7Gn9gGDWz67eYAWF7UHZ4v+6AbN tGDu+Ngu5Ptp3QC+PKXNzbGiAGoD+Z86zQ07HZkSAwLhx9/e8PfyMVM/rmGyQhvA7j7bb0tp/ gOeP7XdF3JtWDIiX56JchuPgn8hKGWt0uSDo0qt9grgu+RwZMh627IbjRId4jFwI9RRX20owo jO0ITqSpG+Myk77k1SYWn1DgsfLZb/Sy9Pz143+WaZDN4FoZHM/VR5J+pXAOyMzYwmmxv7fmH 8w1ErQjnpEg+M53Ifcf5r0a6787PwSwtz0SnVf8Gnjl3Iv5e/Lz2y3K7swfuxpN6sv7o6byWO QCQnwIsJsn6I6wEvanWQJFyB4S9uJoKDYKmbTboRhFzK5ZpkeOChejP4pG+t2zYKSl3+e4kvq ed9Ej63S9L7akEtALhtqRCQ8VdF9v6nTL89KcxHKsl6DeXCqOOu408J0pzCRc0zBOiZVhwqgH LUVTygWWyVcpm+6Hxk+N+Vg7KcJZ9YPL4RX8gLnWs6zM8PYoPxKUU/ISQAAXdq/IWi3lmTHWX VcX8TsxYlRDyogh2RvrqzQ7N3EXOD3mJKUJk4CgOi4zjZP0pYxlYUdjW3ji6LNQ6D8dHNcm35 0LoKLQs0/4ZZNq9Tu03+83YI7RUCD7lYE9JeFQ08ANFF6/EBOE+yKCcu4OY+KdMS8NFAUTMX2 Zwf09qxCBy3jG9u4swSJOoMJ7+YeyUow97thkscWaU1gJfgFWnm58loqI4HISaNN0ioJn53wd kH+qLnC2jk16Yl10j09pHtkx94TJlfzFOVh/DwYJL/ZXl+msfM=
Archived-At: 
Subject: [TLS] CoAP, TLS and ALPN
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 30 Aug 2017 08:07:08 -0000

Hi all,

I would need your deployment experience with the use of ALPN.

Here is the background: With the CoAP over TCP/TLS described in
https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09
we are defining how to run CoAP over TCP and TLS. CoAP is a protocol
typically used in the Internet of Things environment, which was
initially designed to operate over UDP.

To ensure proper multiplexing we offer two approaches, namely one using
ALPN and the other one is to use a dedicated port.

The suggestion was made to only use ALPN (see
https://github.com/core-wg/coap-tcp-tls/issues/155).

This is may be fine since many stacks implement ALPN already (including
embedded TLS stacks).

What is the situation on the TLS loadbalancer/concentrator side? Do
these boxes also forward the ALPN information to the application server?
Has someone run into operational issues with ALPN on the server-side?

Ciao
Hannes


From nobody Wed Aug 30 05:57: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 4D348133200 for ; Wed, 30 Aug 2017 05:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 VFChk8r0ki_c for ; Wed, 30 Aug 2017 05:57:41 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB2E1321A6 for ; Wed, 30 Aug 2017 05:57:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id CA7CA53695; Wed, 30 Aug 2017 15:57:38 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id BiYO62tMjgIq; Wed, 30 Aug 2017 15:57:38 +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 2BD1B2313; Wed, 30 Aug 2017 15:57:34 +0300 (EEST)
Date: Wed, 30 Aug 2017 15:57:34 +0300
From: Ilari Liusvaara 
To: Benjamin Kaduk 
Cc: Noah Robbin , "tls@ietf.org" 
Message-ID: <20170830125734.6gcnuwez4fprsajo@LK-Perkele-VII>
References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] What counts as the same ClientHello?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 30 Aug 2017 12:57:44 -0000

On Tue, Aug 29, 2017 at 01:29:55PM -0500, Benjamin Kaduk wrote:
> Hi Ilari,
> 
> Thanks for the by-extension categorization/breakdown.

Sigh, I missed cached_info, because that does not appear in TLS 1.3
extension lists. It falls into "unsafe to alter because unknown
commitments" category.

However, I identified a new category of extensions that I didn't notice
before: Dependent on altered extensions. There are no such standardized
extensions, but there is at least one proposal (in WG draft stage).


The latter kind of extensions is incompatible with MUST be the same
except  requirement.




-Ilari


From nobody Wed Aug 30 16:50: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 AF339132332 for ; Wed, 30 Aug 2017 16:50: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, 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 TQPNnBfWsjc8 for ; Wed, 30 Aug 2017 16:50:08 -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 8F6261321B9 for ; Wed, 30 Aug 2017 16:50:08 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id t75so63679528oie.3 for ; Wed, 30 Aug 2017 16:50: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=txOLuT2Tr07hF10BxE+IhOO1R5YOtI8PJyf3HL0phDE=; b=NIWAZ1i+aXzWTzPqKk5ZDTAB91gH8cf0MFWO+Hqa6un6IbOAH1QDOLXPCbRmSyZC2M 4i3MLAkbAVna1Ln6eshvd3Aun/58dBpVdXXR/BS1G+jaFKSVEuCgtKMWWh3UhZgprjYe OgIj84OlYxlRVJo95gGpiW1h6STgEksdHToHqp4ysWsqTQc67iBntW8yuY0GcLRy8umc 75w/DEdRYXcbgmzy9oqJ9f6ePLf2b4kraFi9lvUTBmMSbBa059hC6/TApcJwyR7GlLt+ O8znsmaVltIWY1p61e1V3gC+Q2xztg++1ZSfdDPY0TwLRwiz1+N6QRAWmyHxsp1r/6X6 6Zug==
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=txOLuT2Tr07hF10BxE+IhOO1R5YOtI8PJyf3HL0phDE=; b=r0Rraw7tjQzZmE9JOio8T1Sv4PxKbagpBuquSKnuvq9KlzaRam1Ls55ZwGST99OnOw uPF+GfjV2/fsljPNoLyA72VGRqWrIybTb5Br/qAKjGO1VHnQzoX7z4xYTz34zSU9SPCL SuFRqJS1L4ViC4L4aClqUSCPVO6qGncaG3T6qXOjz4kQkqaKcul9fAIR93RQ6XHPjLcP 0moRdFBZNlYH378tziQKA8zveA/krKnmDmB+0l8oCXxahfD02ApVqSlTWtluBIGlKmD+ fxpN4Pm/T4YeQLCi53NAR1o6SU3GjzaJk9OvBnPdwtlj1JC2N0seLoxaIRc0ybUSN3jg jmuQ==
X-Gm-Message-State: AHYfb5j9xt4bwGrpGYUDSOH5kZyOLpRYzRbm7e52RFfRhJhi+r76mT5P i7mDzs/FQNq2cLS7T3qYcmrG5fM61Q==
X-Received: by 10.202.231.135 with SMTP id e129mr2883246oih.277.1504137007936;  Wed, 30 Aug 2017 16:50:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.63.163 with HTTP; Wed, 30 Aug 2017 16:50:07 -0700 (PDT)
In-Reply-To: <20170830125734.6gcnuwez4fprsajo@LK-Perkele-VII>
References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com> <20170830125734.6gcnuwez4fprsajo@LK-Perkele-VII>
From: Martin Thomson 
Date: Thu, 31 Aug 2017 09:50:07 +1000
Message-ID: 
To: Ilari Liusvaara 
Cc: Benjamin Kaduk , Noah Robbin , "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] What counts as the same ClientHello?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 30 Aug 2017 23:50:13 -0000

On 30 August 2017 at 22:57, Ilari Liusvaara  wrote:
> However, I identified a new category of extensions that I didn't notice
> before: Dependent on altered extensions. There are no such standardized
> extensions, but there is at least one proposal (in WG draft stage).

Is it possible that you could help us by sharing which one?

I would however suggest that this sort of dependency is already
possible.  We have a few places in our code that checks certain
conditions after extension processing because of dependencies between
extensions.  In particular, the pre_shared_key and early_data
extensions trigger a lot of cross checking because they change the
protocol in fairly fundamental ways.


From nobody Thu Aug 31 03:58: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 6ABF9132D57 for ; Thu, 31 Aug 2017 03:58:13 -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 BmWhL8gTMkbk for ; Thu, 31 Aug 2017 03:58:11 -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 393AB132D56 for ; Thu, 31 Aug 2017 03:58:11 -0700 (PDT)
Received: from [192.168.91.203] ([80.92.118.205]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MbbWD-1e3Wyr3DLJ-00IzFz for ; Thu, 31 Aug 2017 12:58:08 +0200
To: tls@ietf.org
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <773c1ad5-cf22-ef1c-485a-74556ac6630a@gmx.net>
Date: Thu, 31 Aug 2017 12:58:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:+6PzwnWnPSpT4PR9Y71LTI0De/jCZCgSSD9os46UX3ysBFBEvAO LGpOBeM0LhLevb002NrjFRjYsbp9HtnfF8YsmS5FTQDt04+VpcxdkxMS6WKCHlK38wJ+o0a Lm0JcEhksRi+ygxkJ19zClBcew3+eyhe1msknLXo1U+RE+EEuLijEwKiyADzrfLQoBJwyYX lE4OtNuIbHDa8Az/zVRlA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:S+9p70g+SsM=:cLB8SFAP0/dg3jLlN7DTUf 9FgtDD3bEPlXYO9fIvnUbaQWKdhEID5zk3qTawMQZ6VSU3LaCLC+rKprdDw/JA6w+ovE2XiTk jpiZfeweknfpbliBj3EPkFqbiV0QJ/MMnm4RWjk1ALrY6ag107kaeaRgMLHAhDQCk8PWai7LF 1ybbvQP/3mntF3XOS2qMPumCdKbXXJ7vjLC2JuZsZdIxG/INCiooZWUPi6zmH3orIS56SE+vz +rDSUasGQNMJIKlh8kRJWq/Bk0VxwRpy2iGdbN/4CdM1WF6p5fo3fpgBq29KN794XjfhLyzYb 9To2nFZRvFkkjM5FQgHGBzJc16vtXDF9uSRWsutr/PnB5kD9klkjOP3TSt0dlyf+oq3Pvuv/K KjsNaW4p4pum9eu1e2KL3yJORemOMgayxLhRO/QgIY097BxWdLy+G37J78c53oO860aNsP8QR Yb9HcYl4TQ8wUH/D5Z7lId7wdr/GPsHJTR5iCiDBV5nnSLZs/5xI1athwQgS9XzCmDwNhVsqW 1uf/aTPSGKROka+RiH2Hnb/ZM0DeKJLPTCX5jlSc2yMVxk3KYkH9yc+RV9Jc7q1hiYrNGZsca 1BUzZIR8C2GsQDJlptzm+xrR4eof9AFWf3nqOOBVJPEVXfE6RiWdBHnOwBT9b62l9qBbXdJo+ PMFFrW3KkZYdmu3yIr2HaxDHbtODBsFJXBOTINYh0a4Bgh43tqkg/1r2GzbdrPWc+7n2hXSBu 34bvFYV2FFJb3NRyQKh5vz5QBHHz4Q5D8pO0KZg4D+9GIsu6o4jRNYR/8yz1dVYAIkGVsgi4Z 0JUAq7mupFthlpV1YBLirBMmPVQ1Use/eomuwno5INacdZyneA=
Archived-At: 
Subject: [TLS] draft-ietf-tls-record-limit-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, 31 Aug 2017 10:58:13 -0000

Hi Martin,


In Section 4 you define what is meant by the "maximum size of record"
and in TLS 1.3 it refers to the complete length of TLSInnerPlaintext,
namely

   struct {
       opaque content[TLSPlaintext.length];
       ContentType type;
       uint8 zeros[length_of_padding];
   } TLSInnerPlaintext;


For TLS 1.2 you are less explicit. Is it the complete length of the
TLSPlaintext or just the fragment?

      struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          opaque fragment[TLSPlaintext.length];
      } TLSPlaintext;

I prefer it to be the TLSPlaintext structure.

You write:
"an endpoint MUST NOT generate a protected
   record with plaintext that is larger than the RecordSizeLimit value
   it receives from its peer.
"

I think it would be good to say that a TLS stack has to check this limit
and to return an error to the application through the API so that the
application has a possibility to correct the size of the transmitted
data or to select other ways to recover from the situation.

You write:

"Unprotected messages - handshake messages
   in particular - are not subject to this limit.
"

I believe what you are trying to say is that this restriction is not
applicable to the handshake protocol and also not to the alert protocol.
Whether messages are protected or unprotected does not really matter for
the code idea of this document (which is about the buffer sizes).

It might also be good to indicate a recommended value. A meaningful
value is one that is equal to or larger than the handshake messages. If
you have buffer to store the large handshake messages, such as the
Certificate message then you will also be able to have the buffer for
the subsequent data packets. Currently, the minimum size is indicated as
64 bytes, which I believe is a bit unrealistic since even a PSK-based
exchange will need larger handshake message sizes than that.

The RecordSizeLimit is indicated in bytes, correct?

I also think it might be worthwhile to move the following paragraph to
the beginning of the document since it motivates the use of this extension:

   An Authentication Encryption with Additional Data (AEAD) ciphers (see
   [RFC5116]) API requires that an entire record be present to decrypt
   and authenticate it.  Some implementations choose not to implement an
   AEAD interface in this way to avoid this problem, but that exposes
   them to risks that an AEAD is intended to protect against.


Ciao
Hannes


From nobody Thu Aug 31 14:59: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 7DE7E132153 for ; Thu, 31 Aug 2017 14:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=cloudflare.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMVTg2rUJ24X for ; Thu, 31 Aug 2017 14:59:06 -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 6F9431321D8 for ; Thu, 31 Aug 2017 14:59:06 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id r203so8183887oih.0 for ; Thu, 31 Aug 2017 14:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=+wTd8G3smsDAlVKn9Ki0btSQ6m9LnXyeyLpqim8h8rE=; b=yLWvacPAno0rxV4GMP8DnDCq6vvg6ziK46BUa25TZfjo4N0S5sGgXL0dB3rzwpoPGF 1Z9k3HBEcBbuFiqkDyVOQFcK1d3mAR1P18ZBVrnwumq5czicfS7wJ/T86QQxhWp00tz5 ZCXJzcW2Q/nqFQIuiiF8d45T3Gs3yHiGISGyU=
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:cc; bh=+wTd8G3smsDAlVKn9Ki0btSQ6m9LnXyeyLpqim8h8rE=; b=NUn9VI2fUhLxWD32MGMtxEaS322UrXre5j3Zkd/5UW4UtMqzpTRFm55wFCHvqHXHrS kfV+fX08jUdQDhm4qLi8p4waDm8U1wIeTLWSXb7UO+U+4bCM7y61cp7IoWZMdWWOJWTs OhV2daY07jOImZckep/dlgWtkAjfBn20GGaS4cb1wq0fFip5/Av/plKXz/ICCi/+HOa5 AfL7d77M1gXTeN1hB/HNtM1hcW7OVhI7TGkQkDrkMtcjwGUxLaUTgiF0WrYzsHGFajn+ /KYMNUIzY2qgW9lR3CdmsQBoox5fi/Vz0Hx5Oli2N3WJgxbn/LxWA4x1GrcfArbtlAPH fmhg==
X-Gm-Message-State: AHYfb5jFxBy+jCbg9ZH0k/ui9vLwOOLEcsvWG/3Wgb9+5YPMjbiPmFBk NE2/uVtKyB11rrb7XHx1hLjP5Ijzz7AfF2Q=
X-Google-Smtp-Source: ADKCNb5YvrMqGu1oyWMHl8awfP4Sp/DBZUB0vPbrCg9pyw5h5STtIl+VW293fgMF2lviiO/0meBnCw4vZUq6qRZKvto=
X-Received: by 10.202.252.18 with SMTP id a18mr6658873oii.213.1504216745804; Thu, 31 Aug 2017 14:59:05 -0700 (PDT)
MIME-Version: 1.0
From: Nick Sullivan 
Date: Thu, 31 Aug 2017 21:58:55 +0000
Message-ID: 
To: "hackathon@ietf.org" 
Cc: Loganaden Velvindron , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113b046ccca04e055813c0d9"
Archived-At: 
Subject: [TLS] TLS Hackathon in Singapore
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 31 Aug 2017 21:59:08 -0000

--001a113b046ccca04e055813c0d9
Content-Type: text/plain; charset="UTF-8"

I just added a TLS section to the hackathon wiki for IETF 100 (
https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100hackathon).
There are currently three main goals:

   - TLS 1.3 draft 21 testing and interop
   - Implementation in applications (wget)
   - Implementation and interoperability of adopted drafts

Feel free to contribute ideas if you want to participate.

Nick Sullivan

--001a113b046ccca04e055813c0d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I just added a TLS section to the hackathon wiki for IETF =
100 (https://www.ietf.org/registration/MeetingWiki/wiki/doku=
.php?id=3D100hackathon). There are currently three main goals:
    =

  • TLS 1.3 draft 21 testing and interop
  • Implementation in appl=
ications (wget)
  • Implementation and interoperability of adopted =
drafts
Feel free to contribute ideas if you want to parti=
cipate.

Nick Sullivan


--001a113b046ccca04e055813c0d9--


From nobody Thu Aug 31 19:01: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 3528E132F82 for ; Thu, 31 Aug 2017 19:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZmo516ly9ZS for ; Thu, 31 Aug 2017 19:01:33 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 C9D73132EA1 for ; Thu, 31 Aug 2017 19:01:30 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id n18so7748029oig.2 for ; Thu, 31 Aug 2017 19:01:30 -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=3C04EHk47/wA27xSnGiJTTkBH5aIAqCHj31bSkxfAAI=; b=phPaXFRYT+RBLzmVx5EkJDxhZEKNhu7HzXnzXJzWfV+mZ0Ujvx+YWojR4kLH6kW3Y5 xxh0arK4YJqC29stkLzHujitkSDqeyzYmD4vhJg8Lq7w2mutu7pw5pixCiWfc7kW9uV4 MM3bhpXCQMuZS2xbf37EnJf/9csQposTTNzS5K+4fg/LO1EXM1Jf8C4IFSFUF5gDHKhn RMHziJjta3Rf/tEX3sKPREG3jSzkzOE8jDnrqq1lx5N33WbCbRe0SL7txA+0j89MYXa6 SuZE55rM4V+eEeMnUpiPTPhoazZEQPsj4/R5l9I0bQq1dvBjiw7dXCnZ8/hsvq5mAqIV xT+g==
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=3C04EHk47/wA27xSnGiJTTkBH5aIAqCHj31bSkxfAAI=; b=GTG6/awcyVfDUTqN2zJhtXTK/FnzMAL3QYp0cSSG4NGEUXy6KGBuKnv1PEZk2nLI83 136Ttc6k5b0zaPbPzto1H98AeHgvv+x6XF+jpa80KuExTCnaoMwlbSynY8VANgBAO351 2D2neH/P/2n/vP5/MOcG2yq4yROd+/TmBUS/belvVxQ4pMwAqVFXqLx/yCnybzsyD6S1 xZTEYvu8UhzZwLxJmwFtXiJeuWuqkuWVXsOX3DuZjj7efunMOXeMuezxsh3J3fHRDuEz tKkkXWp/u8hhaRPdFEiiH92Q97VppaFDSKd+XXGcnJgTsXGruYYHIFOwEXrUhaxwC3ue 31ew==
X-Gm-Message-State: AHPjjUi6s+vVlAnF+NTou9AtkFFgWlegQay3rilE4NK0MjcF7r7e6uWr kUuoiI9lTBAy1PEBJBNT7nIPZ7vcJw==
X-Google-Smtp-Source: ADKCNb5sWE4kjOldV39D0/X2PG5k/kGbKXviGMF68onM0GJzKrdLkjxZlr1MD+t6l86hZXpS48LdzctaFZV/9GrKFDM=
X-Received: by 10.202.76.20 with SMTP id z20mr312717oia.257.1504231289869; Thu, 31 Aug 2017 19:01:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.63.163 with HTTP; Thu, 31 Aug 2017 19:01:29 -0700 (PDT)
In-Reply-To: <773c1ad5-cf22-ef1c-485a-74556ac6630a@gmx.net>
References: <773c1ad5-cf22-ef1c-485a-74556ac6630a@gmx.net>
From: Martin Thomson 
Date: Fri, 1 Sep 2017 12:01:29 +1000
Message-ID: 
To: Hannes Tschofenig 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] draft-ietf-tls-record-limit-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, 01 Sep 2017 02:01:35 -0000

Hi Hannes,

Thanks for taking a look at this.

On Thu, Aug 31, 2017 at 8:58 PM, Hannes Tschofenig
 wrote:
> Hi Martin,
> For TLS 1.2 you are less explicit. Is it the complete length of the
> TLSPlaintext or just the fragment?

The problem here is that TLS 1.2 doesn't have a structure that
corresponds to the thing that we are describing.  As you can see,
TLSPlaintext is an entire plaintext (unprotected) record.  In TLS 1.3,
we don't cover the record header.

>       struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           opaque fragment[TLSPlaintext.length];
>       } TLSPlaintext;
>
> I prefer it to be the TLSPlaintext structure.

I think that the best would could do is identify
TlsPlaintext.fragment.length for TLS 1.2.  That would be more
consistent with the description in 1.3.

Proposed text (since we don't have a repo at this moment):

> In TLS 1.2 and earlier, the limit covers all input to compression and encryption, that is the data that ultimately produces  TLSCiphertext.fragment.

> You write:
> "an endpoint MUST NOT generate a protected
>    record with plaintext that is larger than the RecordSizeLimit value
>    it receives from its peer.
> "
>
> I think it would be good to say that a TLS stack has to check this limit
> and to return an error to the application through the API so that the
> application has a possibility to correct the size of the transmitted
> data or to select other ways to recover from the situation.

I don't think that's necessary.  Today, if an application writes 60k
to the stack, the stack is free to fragment that data as it chooses.
(e.g., OpenSSL has a strategy for fragmentation, NSS fragments at the
maximum record size.)  This draft shouldn't change that.

> You write:
>
> "Unprotected messages - handshake messages
>    in particular - are not subject to this limit.
> "
>
> I believe what you are trying to say is that this restriction is not
> applicable to the handshake protocol and also not to the alert protocol.
> Whether messages are protected or unprotected does not really matter for
> the code idea of this document (which is about the buffer sizes).

No.  This is explicitly about protected vs. unprotected.  In TLS 1.2,
this means that you can send the server's first flight in a single
record.  The problem that this solves is the forced blocking of a
connection until an entire encrypted record is available for
decryption.  That doesn't apply for cleartext data.  (Also, the client
can't know the server's value when it sends the ClientHello.)

> It might also be good to indicate a recommended value. A meaningful
> value is one that is equal to or larger than the handshake messages. If
> you have buffer to store the large handshake messages, such as the
> Certificate message then you will also be able to have the buffer for
> the subsequent data packets. Currently, the minimum size is indicated as
> 64 bytes, which I believe is a bit unrealistic since even a PSK-based
> exchange will need larger handshake message sizes than that.

Yes, 64 bytes is ridiculously small, but the protocol can work with
that.  I know, my tests verify this.  You just end up sending lots and
lots of fragmented handshake messages.

> The RecordSizeLimit is indicated in bytes, correct?

I can't believe that I missed that.

> I also think it might be worthwhile to move the following paragraph to
> the beginning of the document since it motivates the use of this extension:
>
>    An Authentication Encryption with Additional Data (AEAD) ciphers (see
>    [RFC5116]) API requires that an entire record be present to decrypt
>    and authenticate it.  Some implementations choose not to implement an
>    AEAD interface in this way to avoid this problem, but that exposes
>    them to risks that an AEAD is intended to protect against.

Good idea.

I have changes for all of these comments staged on a branch on my
local copy.  When our repository-deficit is corrected, I will push
this so that you can review all the changes.

Now I have to go change my patch so that it generates a
record_overflow alert when someone sends a too-large record.  I
completely forgot to add that (I have a patch for that too).